> On 17.03.2015, at 04:18, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>> But then it means in principle that this is a more general issue
>> that just became apparent now.
>
> Yes.
>
...
>> So this is maybe the way forward for the whole default-dt?
>>
>> For SPI it would look like this:
>> &gpio {
>> spi0_pins: spi0_pins {
>> brcm,pins = <7 8 9 10 11>;
>> brcm,function = <4>; /* alt0 */
>> };
>> ...
>> }
>>
>> &spi0 {
>> ...
>> pinctrl-0 = <&spi0_pins>;
>> ...
>> }
>>
>> And if you keep spi0 disabled in the dtsi files then the ALT
>> modes should not be set.
>
> Yes, so long as it's disabled by default that would be OK. However, I
> wonder why we don't just rely on the firmware to set up the pinmux,
> since as you mentioned it does it now?
...
>> Obviously we could also split the gpio-block into
>> "normal SPI" and "CS" pins, which would allow changing the
>> "defaults" also in the dts that gets build.
>>
>> So how should we proceed?
>
> If we do put any default CS GPIO setup in the kernel DT, we should
> indeed put it into a separate node (pinctrl state) so that the user can
> override it easily without any interactions with any other pins/...
So I will create a patch to separate the spi portions out as
mentioned above.
I will actually create 2 gpio-sections:
one for the SPI transfer pins (GPIO 9, 10, 11)
and one for the chipselects (8, 7), which can get overridden
either as output or as ALT0 in a customized device tree.
SPI by default shall be disabled.
Martin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
