On Tue, Jan 30, 2018 at 09:03:10AM +0100, Jan Kundrát wrote: > On úterý 30. ledna 2018 2:13:37 CET, Trent Piepho wrote: > > Another way to fix it, besides default to 0 or to select an unused > > chipselect, is to use the cs number of the slave modulus the number of > > native chip selects. They are or were some other drivers that do this. > Hi Trent, are you talking about an integer modulo here? I don't think that > modulo is a correct approach. If my HW has two CS and I use the following > DT: > cs-gpios = <0>, <&gpio0 1>, <&gpio0 2>, <0>; > ...then the logical CS2 (at gpio0 pin 2) conflicts with the native CS0. You can't physically design working hardware for a system with this limitation that doesn't have a free chip select somehow - if the hardware requires that it controls an internal chip select line then using a GPIO chip select is going to require that there's some internal chip select line that's getting controlled so you need one that's not connected to an actual device that can be used for this purpose. > Also, the spi-orion driver currently hard-codes that each and every model is > supposed to have exactly eight HW CS pins. That's not true for my SoC > (Marvell Armada 388, the Solidrun Clearfog Base board); the 88F6828 CPU only > has four SPI CS signals. > What my patch does is simply picking the *first* unused CS and going with > that one because that looks like the easiest and also safest option. I would expect that you want to have this selected by the board designer (unless there's something convenient like a chip select present in the controller but not routed out of the IP you can guarantee will never be used). That will avoid issues if for example the DT is still not complete.
Attachment:
signature.asc
Description: PGP signature
