Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
Nuno Sá <[email protected]>
| Newsgroups | org.kernel.vger.linux-spi,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <zeooo2jqsp7rkovhdxtra6qjlzjsppyppe3nqojrskcv2sc2x3@2npaf56m66p7> |
On Fri, Jul 17, 2026 at 12:51:53PM +0100, Mark Brown wrote: > On Thu, Jul 16, 2026 at 06:06:13PM +0100, Conor Dooley wrote: > > On Thu, Jul 16, 2026 at 01:28:15PM +0100, Mark Brown wrote: > > > > Oh, isn't that just multi-pin chip selects then: > > > > https://patch.msgid.link/[email protected] > > > No, I think that's something different. > > > In this case, there is one chip select that all instances of the device > > share. Both the ADI and Microchip devices then use the upper bits of the > > first/address byte during reads and write to access individual devices. > > In the microchip case that I'm familiar with, what upper bits the device > > responds to are set by fuses in the factory. They also share the same MOSI > > and MISO. > > I'm struggling to identify a way in which this is functionally different > to a multi-pin chip select. > > > The SPI core already supports two of these devices from Microchip, since > > it just modifies the contents of tx_buf in a spi_transfer. > > When I said we'd have to modify the bitstream I was told that wasn't the > case and this was just asserting more pins along with the "chip select". Oh sorry, Likely I was not clear. The part as some ID pins which are just configuration! So they are two pins and depending on how they are set (low/high) each chip can have four possible addresses! Now all of the chips (to a max of 4) are connected to same CS of the controller so just one CS get's asserted. Of course the above will assert on all devices on that same CS but only the one where the ID pins combo match the spi xfer high bits (part of the address) will reply. Hopefully the above makes it clear. - Nuno Sá