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

login
register
mail settings
Submitter Thierry Reding
Date Feb. 14, 2013, 7:54 a.m.
Message ID <1360828494-16207-1-git-send-email-thierry.reding@avionic-design.de>
Download mbox | patch
Permalink /patch/220391/
State Changes Requested
Delegated to: Tom Warren
Headers show

Comments

Thierry Reding - Feb. 14, 2013, 7:54 a.m.
Move the nand-controller node to the tegra20-tamonten.dtsi so that it
can be shared between all derived boards.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
This depends on Tom's "Tegra: MMC: Add DT support for MMC to T20 boards"
patches.

 board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++++++++++
 board/avionic-design/dts/tegra20-tec.dts       | 11 -----------
 2 files changed, 11 insertions(+), 11 deletions(-)
Tom Warren - March 4, 2013, 8:46 p.m.
Thierry,

On Thu, Feb 14, 2013 at 12:54 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> Move the nand-controller node to the tegra20-tamonten.dtsi so that it
> can be shared between all derived boards.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---
> This depends on Tom's "Tegra: MMC: Add DT support for MMC to T20 boards"
> patches.
>
>  board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++++++++++
>  board/avionic-design/dts/tegra20-tec.dts       | 11 -----------
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi b/board/avionic-design/dts/tegra20-tamonten.dtsi
> index 4766aba..0a95ac1 100644
> --- a/board/avionic-design/dts/tegra20-tamonten.dtsi
> +++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
> @@ -279,6 +279,17 @@
>                 status = "okay";
>         };
>
> +       nand-controller@70008000 {
> +               nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> +               nvidia,width = <8>;
> +               nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> +
> +               nand@0 {
> +                       reg = <0>;
> +                       compatible = "hynix,hy27uf4g2b", "nand-flash";
> +               };
> +       };
> +
>         i2c@7000c000 {
>                 clock-frequency = <400000>;
>                 status = "okay";
> diff --git a/board/avionic-design/dts/tegra20-tec.dts b/board/avionic-design/dts/tegra20-tec.dts
> index 376d279..694682c 100644
> --- a/board/avionic-design/dts/tegra20-tec.dts
> +++ b/board/avionic-design/dts/tegra20-tec.dts
> @@ -32,17 +32,6 @@
>                 clock-frequency = <216000000>;
>         };
>
> -       nand-controller@70008000 {
> -               nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> -               nvidia,width = <8>;
> -               nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> -
> -               nand@0 {
> -                       reg = <0>;
> -                       compatible = "hynix,hy27uf4g2b", "nand-flash";
> -               };
> -       };
> -
>         i2c@7000c000 {
>                 status = "disabled";
>         };
> --
> 1.8.1.2
>
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").

Let me know how you want me to proceed - I'd like to get a PR off to
Albert for ARM/master this week if possible.

Thanks,

Tom
Thierry Reding - March 4, 2013, 10:41 p.m.
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
Tom Warren - March 4, 2013, 11:26 p.m.
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?

Thanks,

Tom
Stephen Warren - March 4, 2013, 11:39 p.m.
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.
Tom Warren - March 8, 2013, 4:36 p.m.
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.

Thierry - assuming the above happens, can you rework/split your
patchset as Stephen outlines above? Then I can apply your patches &
push and we'll be ready for a PR early next week after some
testing/MAKEALL/etc.

Thanks,

Tom
Tom Rini - March 8, 2013, 4:44 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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!

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROhV4AAoJENk4IS6UOR1WgboP/iZFuJFTOf9lLyR38dNHk66p
7h/wexQRQr7CIMYUwHsS55IStunXNif4Njm9u6ehNbjz45v0vpIVUlV37NjhFG82
3XwTRLvt1w9Aag6h8jB/We+Z73rArhHfpq3dbB5FuyX4n+J3Dq+7sRp7kZkRu7gS
skSzcAE5b0eMB6OiPwuG0zkVkMaf0ryYZAzjsRvXgT9302YSigHdM0TnZColzcLt
LQREK58EiQiO20DGuTYIyRUzEG9MlSiv9J7GOLbtgdEbXES/P/v40lybvPwtNdre
q3UmPrDRCMJ2eqtyVZbTRLEAxN9vUhd11cfDBb2HOSsFTilJkpu1GBaR80nmca3p
HgyeHvZnABQ/rvAVRPHP54UT+iXF531Z3CRUF5vQcT0N/JHH1LuyHVuij23b5Fxt
LcM51YNijmFkisZVTxgX4mrFNpGmSvP+4jEky+t6Vz26uZ8YYfa26Lwlby6EFrKy
Nz8QduohPsuSi92QQjSb5LJn86QxFNwz+20UjXPLilQRet/W5WosGJqdUKdH1aun
tkZlUZw7mtu9lIEqJJq4JpNKYP7NoMmDygyob0v+VCUPshqKig6Xs3voQMaAC44i
90OBzokS/Vj/AYJQ7eXwpVsdYkrPc5UXBU70/5QMftEVDR6wk0cLHou18F3wYeQd
HpIFPnhpM0/7rMKXchV3
=FTH6
-----END PGP SIGNATURE-----
Tom Warren - March 8, 2013, 4:48 p.m.
Tom

On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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!
>
> - --
> Tom

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.

Tom
Tom Rini - March 8, 2013, 4:57 p.m.
-----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-----
Tom Warren - March 8, 2013, 4:58 p.m.
On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini <trini@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@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
Will do - thanks.
Tom Warren - March 8, 2013, 5:04 p.m.
Thierry,

On Fri, Mar 8, 2013 at 9:58 AM, Tom Warren <twarren.nvidia@gmail.com> wrote:
> On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini <trini@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@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
> 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

Patch

diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi b/board/avionic-design/dts/tegra20-tamonten.dtsi
index 4766aba..0a95ac1 100644
--- a/board/avionic-design/dts/tegra20-tamonten.dtsi
+++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
@@ -279,6 +279,17 @@ 
 		status = "okay";
 	};
 
+	nand-controller@70008000 {
+		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
+		nvidia,width = <8>;
+		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+
+		nand@0 {
+			reg = <0>;
+			compatible = "hynix,hy27uf4g2b", "nand-flash";
+		};
+	};
+
 	i2c@7000c000 {
 		clock-frequency = <400000>;
 		status = "okay";
diff --git a/board/avionic-design/dts/tegra20-tec.dts b/board/avionic-design/dts/tegra20-tec.dts
index 376d279..694682c 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -32,17 +32,6 @@ 
 		clock-frequency = <216000000>;
 	};
 
-	nand-controller@70008000 {
-		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
-		nvidia,width = <8>;
-		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
-
-		nand@0 {
-			reg = <0>;
-			compatible = "hynix,hy27uf4g2b", "nand-flash";
-		};
-	};
-
 	i2c@7000c000 {
 		status = "disabled";
 	};