[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

Thierry,

On Fri, Mar 8, 2013 at 9:58 AM, Tom Warren <twarren.nvidia at gmail.com> wrote:
> On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini <trini at ti.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/08/2013 11:48 AM, Tom Warren wrote:
>>> On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini at ti.com> wrote:
>>>> On 03/08/2013 11:36 AM, Tom Warren wrote:
>>>>> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren
>>>>> <swarren at wwwdotorg.org> wrote:
>>>>>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>>>>>> Thierry,
>>>>>>>
>>>>>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
>>>>>>> <thierry.reding at avionic-design.de> wrote:
>>>>>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren
>>>>>>>> wrote: [...]
>>>>>>>>> I kinda lost track of this patchset. I'd like to move
>>>>>>>>> it into u-boot-tegra/next if you think it's ready, but
>>>>>>>>> I'm not sure if it conflicts with/works with Stephen's
>>>>>>>>> 4th patch of his v2 series ("ARM: tegra: enable a
>>>>>>>>> common set of disk-related commands").
>>>>>>>>
>>>>>>>> I can rebase my patches on top of Stephen's work and
>>>>>>>> resend them if it helps.
>>>>>>>>
>>>>>>>> Thierry
>>>>>>> The only problem I see is that Stephen's patchset isn't
>>>>>>> exclusively Tegra-based, so I'm not sure I want to bring
>>>>>>> it into the Tegra tree and cause problems when I do a PR.
>>>>>>> The other half of the patchset is assigned to Tom Rini.
>>>>>>>
>>>>>>> Stephen - how would you like me to resolve this?
>>>>>>
>>>>>> Hmmm. Thierry's patch series does quite a few things at
>>>>>> once.
>>>>>>
>>>>>> I'd suggest that Thierry posts a series that /just/ enables
>>>>>> NAND support. It should be possible to apply that on its own
>>>>>> without any conflicts/dependencies on my series.
>>>>>>
>>>>>> Enabling FIT could also be a separate series without any
>>>>>> conflicts/dependencies.
>>>>>>
>>>>>> A lot of the rest of that series is effectively part of my
>>>>>> series, since I ended up enabling all those new options in
>>>>>> the various common Tegra config files in my series.
>>>>>>
>>>>>> The only thing left over is the removal of the custom
>>>>>> definition of CONFIG_BOOTCOMMAND in the AD headers. That
>>>>>> should happen after my series.
>>>>>>
>>>>>> Re: How to get my series into Tegra's tree. I think it'd be
>>>>>> fine to apply my series to the Tegra tree even though it
>>>>>> touches disk/partition code if you can get the/a maintainer
>>>>>> for that code to ack it. Probably someone like Tom Rini. That
>>>>>> way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to
>>>>>> wait long I hope.
>>>>> Sorry, kinda dropped the ball on this while I was working on
>>>>> the padcfg changes.
>>>>>
>>>>> Tom Rini - do you agree with Stephen's approach for the disk
>>>>> parts of his patchset? If so, I can apply it to
>>>>> u-boot-tegra/next today & push.
>>>>
>>>> Can you give me some patchwork links?  I'm getting going on
>>>> another round of pulling things into master today.  Thanks!
>>>
>>> Sure:
>>>
>>> http://patchwork.ozlabs.org/patch/224204/
>>> http://patchwork.ozlabs.org/patch/224205/
>>> http://patchwork.ozlabs.org/patch/224206/
>>> http://patchwork.ozlabs.org/patch/224207/
>>>
>>> 204/205 are assigned to you; 206/207 to me.
>>
>> OK, ack'd, lets move them along the tegra tree since that's where
>> they're really used.
>>
>> - --
>> Tom
> Will do - thanks.
I've applied Stephen's patchset to u-boot-tegra/next (on top of my
padcfg/ctrl patchset and the T30 MMC patchset).  PTAL and either send
me new discrete patches as Stephen outlined, or let me know how to
apply your patchset individually w/current /next TOT.

Thanks,

Tom