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

[Hans de Goede]

Hi Ian,

On 30 October 2014 04:14, Ian Campbell <ijc at 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.

>
>> 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.

Regards,

Hans