Hi, On Tue, Mar 11, 2014 at 03:58:38PM -0500, mrnuke 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.
And I agree with that. > Considering our muxing options, that's a total of 6 declarations. Theorically, yes. > 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. Then you would add other combinations. I'm fine with it too. > 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. And I agree with that too. > 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? Nope. The best solution is to add any combination that is actually used. That way, you don't have to worry about all the above. Plus, if you're using that design, probably someone else did it too, so it will benefit to that someone too. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
