| Message ID | 1360828494-16207-1-git-send-email-thierry.reding@avionic-design.de |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Warren |
| Headers | show |
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
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
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
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.
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
-----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 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
-----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-----
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.
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
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"; };
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(-)