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

[Tom Warren]

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.