Hi, On Wed, Mar 12, 2014 at 4:58 AM, mrnuke <[email protected]> wrote: > I've been wanting to get SPI up and running on the cubie, which now is as > simple as declaring the relevant nodes in devicetree. The issue here is how > and where to declare the pingroups. > > Take for example the fictional A1l sunli SoC: > SPI0 on sunli has 5 signals, each muxable to one of two pins: > > signal | pin A | pin B > ----------------------- > CLK | PB0 | PF5 > MOSI | PB1 | PF6 > MISO | PB2 | PF6 > CS0 | PB3 | PF8 > CS1 | PB4 | PF0 > > One obvious solution would be to declare group_a and group_b. Simple. However, > some boards may only use one of the CS signals. wens (sorry, I don't know your > real name) suggested making a group for CLK,MOSI,MISO, one for CS0, and one > for CS1. The peripheral would reference thegroup with CLK,MOSI,MISO, and one > of the CS* groups. Considering our muxing options, that's a total of 6 > declarations.
In reality, not all of the options are usable for actual hardware. Let's consider the A20 SPI0, instead of a fictional SoC: signal | pin A / B | ---------------------- CLK | PI11 / PC2 | MOSI | PI12 / PC0 | MISO | PI13 / PC1 | CS0 | PI10 / PC23 | CS1 | PI14 | You should add the pin groups that you will actually use to support whatever boards you currently have, i.e. add the pin groups that are exposed and actually usable. On the Cubie, the PC pingroup is used for NAND, so that's obviously a no-go. Of the PI pingroup, the PI14 is not exposed on any header, so you leave that out. So you add a pingroup for PI10~13. Let's say you also want to support the LIME, which exposes the whole PI group on one of its headers. So you may add PI14 (CS1) as a seperate pingroup, then in the board DTS, you reference both. > And of course, this doesn't handle the case of boards doing funny things, such > as using PF5, PB1, PB2, and PF8 for SPI. Such an arrangement is not > impossible, and ight make sense depending on the arrangements of balls on the > BGA package. I don't think anyone would go through the trouble of designing something like that. The pin functions are grouped together. You choose one, you sacrifice another. > One other solution would be to declare each pin (clk_a, clk_b, mosi_s, mosi_b, > etc) as a group, but that would be a crapload of declarations. That's a ton of > unneeded bloat IMHO. > > I think the best solution here is to just declare the pingroups in the board's > dts, rather than the SoC's dtsi. Would this be acceptable for you guys? I think we should provide reasonable standard pingroups in the DTSI. Mostly everybody will be using the same ones anyway. If you use NAND, you've eliminated one option for SPI0. If you use Ethernet, say goodbye to SPI3, and only one option left for SPI1. If you want JTAG, out goes SPI2 on PB group. If any hardware developer wants to go all crazy, they can declare other pingroups at the board level. The DTSI should provide a sane, commonly used option. Cheers, ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
