[U-Boot] [PATCH v2 6/6] dm: sunxi: Add support for serial using driver model

[Ian Campbell]

On Thu, 2014-10-30 at 10:36 +0100, Hans de Goede wrote:
> Hi,
> 
> On 10/30/2014 10:08 AM, Ian Campbell wrote:
> > On Wed, 2014-10-29 at 13:28 -0600, Simon Glass wrote:
> >>> In the meantime could we somehow replace/augment the #ifdef chain in
> >>> gpio_init with something keyed off the stdout alias perhaps?
> >>
> >> Tegra has code to convert a device interrupt number (which uniquely
> >> identifies a peripheral in that SoC) to an internal peripheral ID,
> >> then these is a function which can enable a peripheral given the ID
> >> (funcmux). In some cases you could have multiple options for the
> >> funcmux, but there is no easy way to support this.
> > 
> > I think that although there are multiple options for some functions
> > (UARTs come to mind) we haven't yet found the need to make any dynamic
> > choices, so it's all static right now.
> > 
> >>  But this approach
> >> might be good enough for sunxi. We can easily write the function to
> >> enable the pins for a particular port, and this could go in
> >> arch/arm/...sunxi/ perhaps.
> > 
> > I'm ok with it so long as it isn't going to stand in the way of proper
> > dt based pinmux in the future.
> > 
> > One way to help with that might be to use the allwinner,function
> > property in DT as the funcmux name.
> > 
> > Hans, what do you think?
> 
> I'm not 100% sure what you're suggesting here, are you suggesting to
> have a 1:1 mapping between function names as stored in allwinner,function
> in dts and the value to pass to sunxi_gpio_set_cfgpin ?

I was imagining a function which would take the string "uart0" and would
call sunxi_gpio_set_cfgpin with whatever values that would entail in
order to make uart0 work, not one which would try and return something
that the caller would then use.

> This is not going to fly very far, e.g. the "uart0" function has cfg value
> of 2 on portb while it has a value of 4 on portf.

I believe we currently statically use either portb or portf (I've not
looked up which, IIRC it changed recently, but I don't recall which
way), so my proposed function would just DTRT. Of course if we ever find
we need something more dynamic then we would have to do a proper pinmux
implementation (or at least something closer to a proper one)

Ian.