Tom On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <tr...@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 >> <swar...@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.red...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot