Fetch SPI multi-lane support from upstream#3158
Fetch SPI multi-lane support from upstream#3158machschmitt wants to merge 9 commits intoanalogdevicesinc:mainfrom
Conversation
machschmitt
requested review from
CiprianRegus,
amiclaus,
btogorean,
buha,
chegbeli,
danmois,
dbogdan,
mhennerich,
nunojsa,
rbolboac and
stefpopa
as code owners
|
W have some commits in here that are on other PRs. Seems like we need to merge those first. Also, is all of this absolutely necessary? This will bring me some pain next time I need to merge the spi subystem |
Sure, will drop the commits that on the other PR as we merge #3154.
How do the spi subsystem get merged into ADI Linux? If it's just about taking the patches from for-6.?? (e.g. for-6.20 https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-6.20), then I may try do the spi subsystem merge for you. What do you think? |
Unfortunately no. It will be just one big merge (that will also likely bring some AMD/Xilinx changes). Don't worry, I'll bug you if needed |
|
Hi @nunojsa , Not sure how we proceed here. There are some improvements to SPI Engine HDL that we want to test with the new SPI multi-lane patches. I thought we could have those patches on ADI Linux main (since it's all from upstream) before testing the HDL. Though, we may instead keep a separate Linux branch to validate the HDL updates with the updates from Linux. Still, we will probably want the multi-lane patches on Linux main at some point soon otherwise the multi-lane SPS will only be available after the next big merge with AMD/Xilinx Linux. If I recall it correctly, @sarpadi wants the multi-lane thing on current ADI Linux to enable including support for a new ADC in the next Kuiper release. Anyways, just want to clarify what you think are the best way to move forward. (a) Is the plan of getting spi multi-lane support into current ADI Linux actually reasonable? |
Given the patches are upstream, fine by me to backport them. Moreover if we need it for new parts.
Likely. Then whatever you feel it's better. I'll deal with it later :) |
machschmitt
force-pushed
the
main-spi-multi-lane
branch
from
c64b612 to
d429aad
Compare
|
Seems like we have some conflicts with the ad4630 schema but I guess nothing we can do about it (or worth doing it). |
ad4630 dts and bindings will have to be updated to the new multi-lane dt properties. I'll do so in yet another PR. |
Not a must. As long as the current patches make it clear it's a backport, fine by me |
Change spi-rx-bus-width and spi-tx-bus-width properties from single uint32 values to arrays of uint32 values. This allows describing SPI peripherals connected to controllers that have multiple data lanes for receiving or transmitting two or more words in parallel. Each index in the array corresponds to a physical data lane (one or more wires depending on the bus width). Additional mapping properties will be needed in cases where a lane on the controller or peripheral is skipped. Bindings that make use of this property are updated in the same commit to avoid validation errors. The adi,ad4030 binding can now better describe the chips multi-lane capabilities, so that binding is refined and gets a new example. Converting from single uint32 to array of uint32 does not break .dts/ .dtb files since there is no difference between specifying a single uint32 value and an array with a single uint32 value in devicetree. [marcelo.schmitt@analog.com: dropped andestech,ae350-spi.yaml update] Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-1-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add spi-tx-lane-map and spi-rx-lane-map properties to the SPI peripheral device tree binding. These properties allow specifying the mapping of peripheral data lanes to controller data lanes. This is needed e.g. when some lanes are skipped on the controller side so that the controller can correctly route data to/from the peripheral. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-2-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for SPI controllers with multiple physical SPI data lanes.
(A data lane in this context means lines connected to a serializer, so a
controller with two data lanes would have two serializers in a single
controller).
This is common in the type of controller that can be used with parallel
flash memories, but can be used for general purpose SPI as well.
To indicate support, a controller just needs to set ctlr->num_data_lanes
to something greater than 1. Peripherals indicate which lane they are
connected to via device tree (ACPI support can be added if needed).
The spi-{tx,rx}-bus-width DT properties can now be arrays. The length of
the array indicates the number of data lanes, and each element indicates
the bus width of that lane. For now, we restrict all lanes to have the
same bus width to keep things simple. Support for an optional controller
lane mapping property is also implemented.
[marcelo.schmitt@analog.com: adapted to apply on top of kernel 6.12]
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-3-12af183c06eb@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new multi_lane_mode field to struct spi_transfer to allow peripherals that support multiple SPI lanes to be used with a single SPI controller. This requires both the peripheral and the controller to have multiple serializers connected to separate data lanes. It could also be used with a single controller and multiple peripherals that are functioning as a single logical device (similar to parallel memories). Acked-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-4-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new page to Documentation/spi/ describing how multi-lane SPI support works. This is uncommon functionality so it deserves its own documentation page. Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-5-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Extend the ADI AXI SPI engine binding for multiple data lanes. This SPI controller has a capability to read multiple data words at the same time (e.g. for use with simultaneous sampling ADCs). The current FPGA implementation can support up to 8 data lanes at a time (depending on a compile-time configuration option). Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-6-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for SPI_MULTI_LANE_MODE_STRIPE to the AXI SPI engine driver. The v2.0.0 version of the AXI SPI Engine IP core supports multiple lanes. This can be used with SPI_MULTI_LANE_MODE_STRIPE to support reading from simultaneous sampling ADCs that have a separate SDO line for each analog channel. This allows reading all channels at the same time to increase throughput. [marcelo.schmitt@analog.com: adapted to apply on top of kernel 6.12] Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-7-12af183c06eb@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add spi-rx-bus-width property to describe how many SDO lines are wired up on the ADC. These chips are simultaneous sampling ADCs and have one SDO line per channel, either 2 or 4 total depending on the part number. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for multiple SPI lanes to increase throughput. The AD7380 family of ADCs have multiple SDO lines on the chip that can be used to read each channel on a separate SPI lane. If wired up to a SPI controller that supports it, the driver will now take advantage of this feature. This allows reaching the maximum sample rate advertised in the datasheet when combined with SPI offloading. [marcelo.schmitt@analog.com: drop SDO_X_WIRE, making similar to upstream] Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
machschmitt
force-pushed
the
main-spi-multi-lane
branch
from
d429aad to
49d7414
Compare
|
Picked up missing tags and added notes on the patches that were adapted to apply on ADI Linux. |
The ADI Linux ad4630 driver and upstream ad4030 driver both use the same compatible strings. The backported ad4030 is not set to build so any "adi,ad4630-24" -like string will match with the ad4630 driver. Unless I'm missing something, at this point, the only thing we can do is to change ad4630 driver match table to have something like "adi,legacy-ad4630-24". Think doing that might cause more harm than good, though. That doesn't have much to do with the multi-lane stuff so I'll merge this PR if no one has any objection. |
3 participants
PR Description
Fast-forward (or fast-backward?) SPI multi-lane support to ADI Linux.
To minimize the amount of merge conflicts, some updates that preceded SPI multi-lane were also included. Most relevant ones are:
Links to the lore are provided on the description of each patch.
PR Type
PR Checklist