| Message ID | 20250116232118.2694169-2-sean.anderson@linux.dev |
|---|---|
| State | New |
| Headers | show |
| Series | spi: zynqmp-gqspi: Split the bus and add GPIO support | expand |
On 1/16/25 5:21 PM, Sean Anderson wrote: > This device supports two separate SPI busses: ... > @@ -84,5 +94,32 @@ examples: > resets = <&zynqmp_reset ZYNQMP_RESET_QSPI>; > reg = <0x0 0xff0f0000 0x0 0x1000>, > <0x0 0xc0000000 0x0 0x8000000>; > + > + spi-lower { > + #address-cells = <1>; > + #size-cells = <0>; > + num-cs = <2>; > + cs-gpios = <0>, <&gpio 5>; > + > + flash@0 { > + reg = <0>; > + compatible = "jedec,spi-nor"; > + }; > + > + flash@1 { > + reg = <1>; > + compatible = "jedec,spi-nor"; > + }; > + }; > + > + spi-upper { > + #address-cells = <1>; > + #size-cells = <0>; > + > + flash@0 { > + reg = <0>; > + compatible = "jedec,spi-nor"; > + }; > + }; > }; > }; In the IIO subsystem, we've been recently working on several "advanced" ADCs that could use a SPI controller like this. These ADCs have multiple input channels that perform conversions in parallel and the data for each channel needs to be read back on a separate serial line (MISO) at the same time. Another similar case is to have two separate chips, but they share a conversion trigger and essentially operate as a single composite device rather than two distinct devices [1]. This would be similar to some ADCs that are daisy-chained where we consider all of the chips in the chain as a single composite device, but they would be in parallel rather than chained. [1]: https://lore.kernel.org/linux-iio/e5e8eba7-2455-488b-a36f-e246844e11fd@baylibre.com/ For those use cases though, as mentioned above, we only have a single device that would be connected to both buses. So for such a SPI controller with multiple buses, I was envisioning that instead of adding child nodes for each of the child buses, that we would do something like add a spi-buses property to the spi peripheral bindings where you could specify one or more buses that a device was connected to. e.g. a device connected to the lower bus would be spi-buses = <0>; one connected to the upper bus would be spi-buses = <1>; and a device connected to both would be spi-buses = <0>, <1>;. This would also work for SPI controllers that have 4 or 8 busses. SPI controllers like these have a striping feature that allows to control both buses at the same to either mirror the same data on both buses at the same time when writing, e.g. for configuration or to read and write two different bytes at the same time. A peripheral driver for device that was connected to both buses could make use of this feature to craft a single SPI message with transfers containing (new) parameters that specify which bus to use (one or both) and, in the case of using both buses, to mirror or stripe the data. Could we make a single device connected to both buses like this work using the proposed spi-lower and spi-upper or should we consider a different binding like the one I suggested?
On 1/21/25 19:16, David Lechner wrote: > On 1/16/25 5:21 PM, Sean Anderson wrote: >> This device supports two separate SPI busses: > > ... > >> @@ -84,5 +94,32 @@ examples: >> resets = <&zynqmp_reset ZYNQMP_RESET_QSPI>; >> reg = <0x0 0xff0f0000 0x0 0x1000>, >> <0x0 0xc0000000 0x0 0x8000000>; >> + >> + spi-lower { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + num-cs = <2>; >> + cs-gpios = <0>, <&gpio 5>; >> + >> + flash@0 { >> + reg = <0>; >> + compatible = "jedec,spi-nor"; >> + }; >> + >> + flash@1 { >> + reg = <1>; >> + compatible = "jedec,spi-nor"; >> + }; >> + }; >> + >> + spi-upper { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + flash@0 { >> + reg = <0>; >> + compatible = "jedec,spi-nor"; >> + }; >> + }; >> }; >> }; > > In the IIO subsystem, we've been recently working on several "advanced" ADCs > that could use a SPI controller like this. These ADCs have multiple input > channels that perform conversions in parallel and the data for each channel > needs to be read back on a separate serial line (MISO) at the same time. Another > similar case is to have two separate chips, but they share a conversion trigger > and essentially operate as a single composite device rather than two distinct > devices [1]. This would be similar to some ADCs that are daisy-chained where we > consider all of the chips in the chain as a single composite device, but they > would be in parallel rather than chained. > > [1]: https://lore.kernel.org/linux-iio/e5e8eba7-2455-488b-a36f-e246844e11fd@baylibre.com/ > > For those use cases though, as mentioned above, we only have a single device > that would be connected to both buses. So for such a SPI controller with > multiple buses, I was envisioning that instead of adding child nodes for each > of the child buses, that we would do something like add a spi-buses property > to the spi peripheral bindings where you could specify one or more buses that > a device was connected to. > > e.g. a device connected to the lower bus would be spi-buses = <0>; one connected > to the upper bus would be spi-buses = <1>; and a device connected to both would > be spi-buses = <0>, <1>;. This would also work for SPI controllers that have > 4 or 8 busses. > > SPI controllers like these have a striping feature that allows to control both > buses at the same to either mirror the same data on both buses at the same > time when writing, e.g. for configuration or to read and write two different > bytes at the same time. A peripheral driver for device that was connected to > both buses could make use of this feature to craft a single SPI message with > transfers containing (new) parameters that specify which bus to use (one or > both) and, in the case of using both buses, to mirror or stripe the data. > > Could we make a single device connected to both buses like this work using > the proposed spi-lower and spi-upper or should we consider a different binding > like the one I suggested? If you are willing to do the work to rewrite the SPI subsystem to handle this, then I don't object to it in principle. Using a property would also help with forwards compatibility. On the other hand, separate busses are easier to implement since they integrate better with the SPI subsystem (e.g. you can just call spi_register_controller to create all the slaves). There have been some previous patches from Xilinx to handle this use case [1], but IMO they were pretty hacky. They got this feature merged into U-Boot and it broke many other boards and took a lot of cleanup to fix. So I have intentionally only tackled the unsynchronized use case since that requires no modification to areas outside of this driver. I don't need the "parallel" use case and I am not interested in doing the work required to implement it. --Sean [1] https://lore.kernel.org/linux-spi/20221017121249.19061-1-amit.kumar-mahapatra@amd.com/
On 1/23/25 16:59, David Lechner wrote: > On 1/23/25 10:24 AM, Sean Anderson wrote: >> On 1/21/25 19:16, David Lechner wrote: >>> On 1/16/25 5:21 PM, Sean Anderson wrote: > > ... > >>> Could we make a single device connected to both buses like this work using >>> the proposed spi-lower and spi-upper or should we consider a different binding >>> like the one I suggested? >> >> If you are willing to do the work to rewrite the SPI subsystem to handle >> this, then I don't object to it in principle. Using a property would >> also help with forwards compatibility. On the other hand, separate >> busses are easier to implement since they integrate better with the SPI >> subsystem (e.g. you can just call spi_register_controller to create all >> the slaves). >> >> There have been some previous patches from Xilinx to handle this >> use case [1], but IMO they were pretty hacky. They got this feature >> merged into U-Boot and it broke many other boards and took a lot of >> cleanup to fix. So I have intentionally only tackled the unsynchronized >> use case since that requires no modification to areas outside of this >> driver. I don't need the "parallel" use case and I am not interested in >> doing the work required to implement it. >> >> --Sean >> >> [1] https://lore.kernel.org/linux-spi/20221017121249.19061-1-amit.kumar-mahapatra@amd.com/ > > Fair enough, and I think it can be done without breaking things like the multi > CS support did. > > Here are a couple of patches. Feel free to resubmit them with your series if > they work for you. To make it work with your series, you should just need to > modify the .dts to look like this: > > + flash@0 { > + compatible = "jedec,spi-nor"; > + reg = <0>; > + spi-buses = <0>; /* lower */ > + }; > + > + flash@1 { > + reg = <1>; > + compatible = "jedec,spi-nor"; > + /* also OK to omit property in case of spi-buses = <0>; */ > + }; > + > + flash@2 { > + reg = <2>; > + compatible = "jedec,spi-nor"; > + spi-buses = <1>; /* upper */ > + }; > > > Then drop patch "spi: zynqmp-gqspi: Split the bus" of course. > > In zynqmp_qspi_probe(), add a line: > > ctlr->num_buses = 2; > > And in the zynqmp_qspi_transfer_one() function, use spi->buses to select the > correct bus: > > xqspi->genfifobus = FIELD_PREP(GQSPI_GENFIFO_BUS_MASK, spi->buses); > > I don't have a SPI controller on hand with multiple buses, so I don't have > any patch adding support to a specific controller. But I did build and run this > and hacked in some stuff to the drivers I am working on to make sure it is > working as advertised as best as I could with a single bus. Your patches LGTM. I will use them for v2. Mark do you have any comments on this approach? --Sean
On Thu, Jan 23, 2025 at 05:37:16PM -0500, Sean Anderson wrote: > Your patches LGTM. I will use them for v2. Mark do you have any comments on this > approach? It looks fine.
diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml index 901e15fcce2d..12c547c4f1ba 100644 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -39,6 +39,18 @@ properties: resets: maxItems: 1 + spi-lower: + type: object + $ref: spi-controller.yaml# + unevaluatedProperties: false + description: The "lower" bus (SPI0). On the ZynqMP this uses MIO pins 0-5. + + spi-upper: + type: object + $ref: spi-controller.yaml# + unevaluatedProperties: false + description: The "upper" bus (SPI1). On the ZynqMP this uses MIO pins 7-12. + required: - compatible - reg @@ -50,8 +62,6 @@ required: unevaluatedProperties: false allOf: - - $ref: spi-controller.yaml# - - if: properties: compatible: @@ -75,7 +85,7 @@ examples: #address-cells = <2>; #size-cells = <2>; - qspi: spi@ff0f0000 { + qspi: spi-controller@ff0f0000 { compatible = "xlnx,zynqmp-qspi-1.0"; clocks = <&zynqmp_clk QSPI_REF>, <&zynqmp_clk LPD_LSBUS>; clock-names = "ref_clk", "pclk"; @@ -84,5 +94,32 @@ examples: resets = <&zynqmp_reset ZYNQMP_RESET_QSPI>; reg = <0x0 0xff0f0000 0x0 0x1000>, <0x0 0xc0000000 0x0 0x8000000>; + + spi-lower { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <2>; + cs-gpios = <0>, <&gpio 5>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + }; + + flash@1 { + reg = <1>; + compatible = "jedec,spi-nor"; + }; + }; + + spi-upper { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + }; + }; }; };
This device supports two separate SPI busses: "lower" (SPI0) and "upper" (SPI1). Each SPI bus has separate clock and data lines, as well as a hardware-controlled chip select. The current binding does not model this situation. It exposes one bus, where CS 0 uses the lower bus and the lower chip select, and CS 1 uses the upper bus and the upper chip select. It is not possible to use the upper chip select with the lower bus (or vice versa). GPIO chip selects are unsupported, and there would be no way to specify which bus to use if they were. Split the "merged" bus into an upper and lower bus, each with their own subnodes. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> --- .../bindings/spi/spi-zynqmp-qspi.yaml | 43 +++++++++++++++++-- 1 file changed, 40 insertions(+), 3 deletions(-)