(adding linux-spi+lkml) Hi Lach, On 17/04/23 12:36, Lachezar Temelkov wrote: > Hi Chris, > > My name is Lach Temelkov and I saw your device tree implementation here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/spi/spi-mux.yaml (note changed URL to point to the canonical upstream, content is the same) > Since my Zynz Z7000 SoC does not have enough SPI, I am using one SPI > host and multiplexing the slave select pins as you do in the link above. > > However, in my application, one master board with Zynq Z7000 sends > spi_clk, spi_mosi and spi_miso ( along with slave selects) to 8 other > IO boards, so I mux the spi_clk, mosi and miso as well. > > So, n the end, I have 2 multiplexers( that i control from one 8 bit > gpio) , 1 mux controls the slave select( as in the url above) and > another mux controlling which IO board the spi_clk, mosi and miso will go. > > This is done so that an EMI( electromagnetic interference) and > radiation does not occur- e.g, it prevents the spi _clock signals to > simultaneously go to 8 different boards- 12" appart. Also it helps > with signal integrity. > > Could you please tell me ( a dts snippet maybe), how the device tree > would look like with 2 muxes. How can i combine them > > - mux 1: 4 bits - chooses 16 slave selects > - mux 2 :3 bits - chooses 8 IO boards > > I really appreciate your input, > I developed the spi-mux support with boards that connected just the CS via a mux, the other lines were wired together. So it's not really something that I considered. The complication for you is in the mux itself. The spi-mux code should work fine provided there is a mux driver that does what you need. I don't think the existing gpio-mux driver will handle having 1 state mapped to >1 gpio so you'd probably need to create your own mux driver that deals with that. You might be able to do some kind of multi-level mux but that probably won't play nice with the CS lines.