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

[Tom Rini <trini@ti.com>]

-----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@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@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@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROhiQAAoJENk4IS6UOR1Wr50P/RIsDFVP62XXxKOfcpQtAUYX
7QHGLX1+qS58pAFRwclIxs64VzIm2dT5xDplzilABJH8BTE6MnUyKqkKbeP4M8pR
dtwsVROHK8QdI09bZWN3sBn8B9derkLlsg58lzK8YooeOHJznQhdCxNXEa99/5HJ
WLVx7buxUyMYQINyFQH83pCm9e67R/k7KYmr+D3yyvLLpxSyJI++1BpgRDzNhG74
DHacV6gBqD+bMBS62TTtfxGBOHXZgfrSxxuooFHJa8kJef73xt6LKOWwY6KV/eVj
cbk6utg7kiSr50AknVwatIZ+aig/uBuXmoLs6IRIkrgn9fVj4yYmmiLcdgfbqgdU
mZSE//EW9xQ2mL6qQDEFOOdqrZ2xs9ipf59LqAzKloh41SAWzpxrr2KSp5jpz7rX
mjpMPUMZ7lsWNET8x+1rj22MnFWXtfl3EAHTF3WX1FdvWbm63MRLRYmGEf3LzdXW
NuA5vpbQEgjnabwg6IGWcxGtPFKCChePThZ3lsK9DT/ozn4pmlvQMzFGL7PHZjX7
ZJcSW/mHTR5HxZC5P7+sgVbGPpwnuUT/Hia/j0kkM+cyCVaqRka649+fIM3Ozrgh
yvpqPu2R6JhbwGECmW6AusFGx8Vi/XXC70XfryymGGJB8tDU/6h0HogYYB9PS21e
yxBeqziVVusJSwPqn6E1
=d+6W
-----END PGP SIGNATURE-----