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

[Ian Campbell <ijc@hellion.org.uk>]

On Fri, 2014-10-31 at 10:07 +0100, Hans de Goede wrote:
> Hi Ian,
> 
> On 30 October 2014 04:14, Ian Campbell <ijc@hellion.org.uk> wrote:
> > 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.
> 
> I assume that it will take a string, e.g. "uart0" and a pin, since
> uart0 can be routed to either porta or portb, other then that having the
> function directly call sunxi_gpio_set_cfgpin rather then returning the
> value to pass to sunxi_gpio_set_cfgpin is a good idea.

Actually right now we don't actually dynamically select anything for
uarts, so we could just as easily hardcode which pins to use in this new
function as we do now, it's still a step in the right direction.

> >> 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)
> 
> Ah, so you mainly just want to clean up the existing #ifdef mess ? I was aiming
> for something which we could eventually use to get the info from devicetree
> and not have any uart info hardcoded into the binaries at all.

What I'm really hoping for is to enable Simon to get his DM series
accepted, but in a way which won't get in the way of future work to use
DT fully. Even better if it takes us a little nearer to the full DT
path, at least in terms of the interfaces used.

This subthreaded initially started with the suggestion from Simon: "We
can easily write the function to enable the pins for a particular port,
and this could go in arch/arm/...sunxi/ perhaps.". Which sounded OK to
me so long as it doesn't get in the way of future work to fully use DT.
So with that in mind I suggested that using the DT function name as the
key passed to that function would help achieve that aim.

My thinking was that this function would be a nexus point where we could
independently replace the callers (individually on a driver by driver
basis) with code parsing the DT to find the function name and the
backend with code to lookup the correct pinmux stuff in DT and do the
necessary setup.

Maybe I've misjudged what the final DT pinmux thing would look like
though, in which case maybe this suggestion doesn't actually achieve the
aim of not getting in the way.

Ian.