[U-Boot] [PATCH 4/6] sunxi: GPIO: introduce sunxi_gpio_setup_dt_pins()
Simon Glass
sjg at chromium.org
Fri Jul 14 13:50:08 UTC 2017
+Tom
On 7 July 2017 at 04:30, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Simon,
>
> On 07/07/17 04:58, Simon Glass wrote:
>> Hi Andre,
>>
>> On 2 July 2017 at 18:59, Andre Przywara <andre.przywara at arm.com> wrote:
>>> Instead of hard-coding GPIO pins used for a certain peripheral, we
>>> should just use the pinctrl information from the DT.
>>> The sun8i-emac driver has some simple implementation of that, so
>>> let's just generalize this and copy the code to a more common
>>> location.
>>> On the way we add support for the new, generic pinctrl binding now
>>> used by all Allwinner SoCs.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>> arch/arm/include/asm/arch-sunxi/gpio.h | 3 ++
>>> arch/arm/mach-sunxi/pinmux.c | 79 ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 82 insertions(+)
>>
>> It looks like this should be done with a pinctrl driver, shouldn't it?
>
> I knew you would say this ;-)
>
> So technically you are right, but it looks like this is quite some work.
> And as patch 5/6 demonstrates, this code here was actually already
> mostly in, so this is basically just moving and generalisation.
>
> The whole purpose of this series is to prepare for merging in the Linux
> 4.13-rc1 DTs and still have working Ethernet, so I wanted to keep the
> bar low on this.
>
> I haven't looked in detail what it would take to have a proper Allwinner
> pinctrl DM driver, but the binding Linux uses is not "self-contained",
> as we still need SoC specific knowledge (namely into which actual mux
> value the "emac" string, for instance, translates to; and this is per
> SoC and pin). So that means pulling *a lot of* tables into U-Boot, which
> I am not sure is worth at this point. We might get away with some
> short-cuts, basically keeping our hard coded mux values around or just
> defining those that we actually need.
> But in general I consider this work more long term, and it should not
> halt the more important goal of having the Linux and U-Boot DTs in sync.
With a due sense of foreboding and dread:
Reviewed-by: Simon Glass <sjg at chromium.org>
>
> Cheers,
> Andre.
More information about the U-Boot
mailing list