[U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

[Tom Warren]

Mike,

On Thu, Jan 27, 2011 at 12:41 AM, Mike Rapoport <mike at compulab.co.il> wrote:
> Tom,
>
> On 01/26/11 19:05, Tom Warren wrote:
>> Mike,
>>
>> On Wed, Jan 26, 2011 at 1:13 AM, Mike Rapoport <mike at compulab.co.il> wrote:
>>> My point was that pin muxing belongs to the board code rather than to the
>>> driver. Driver should just assume that pins are configured elsewhere and it does
>>> not need to deal with pin muxing at all.
>> I understand that point - sorry if I wasn't clear. No objection to
>> having pinmux code in board files.
>>
>>> Moreover, I'd prefer to see pinmux_board_init or something similar that
>>> configures all the pins at once rather than collection of pinmux_init_uart,
>>> pinmux_init_sdmmc, pinmux_init_gmi etc that will grow as more drivers are added.
>>>
>> I see a couple of reasons not to do it that way. First, I don't know
>> at this time what all the pinmux settings will be, since I haven't
>> ported all the periph driver code yet. It's vastly different from
>> what's acceptable in U-Boot, and will all need significant rewrite.
>> It'd take me a week to gather all that info, and I'm not at full BW on
>> this project (one of 4 on my plate right now).
>> Second, I've been chastised before for including code/features in this
>> initial patchset that aren't needed or used.  I'm trying to keep the
>> code as simple as possible to make it easier on reviewers and get
>> through the review in as short a time as possible. This has already
>> dragged on far longer than I thought it would.
>> I'm willing to change the pinmux code to make it as generic as
>> possible, but only if there's a consensus on the list that it has to
>> be that way to get accepted & pushed.
>
> I'm Ok with pinmux_init_uart in the board code for now. I think that the generic
> pinmux functionality can be added afterwards.
>
Great. My main goal is to get the baseline Tegra2 support in upstream
U-Boot. I'm happy to refine the pinmux approach in the next patchset.
Either a generic pinmux as you propose, or a set of weak pinmux
configs that can be overridden by another board design, etc. as Peter
proposes.

>>>
>> Thanks,
>> Tom
>
>
> --
> Sincerely yours,
> Mike.
>
Thanks,
Tom