Tom,
On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini trini@ti.com wrote:
On 09/13/2012 01:30 PM, Stephen Warren wrote:
On 09/13/2012 02:16 PM, Tom Warren wrote:
Stephen,
On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 09/12/2012 04:10 PM, Tom Warren wrote:
diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
This whole file is definitely common with Tegra20.
I'm going through your previous comments, but I'll just reply quickly to this one since it needs clearing up.
The intent of this first series of patches for Tegra30 was just to get to the command prompt on T30 in the quickest way, while impacting Tegra20 code as little as possible. Hence, I used Tegra20 files to create a Tegra30 build, and as I ported it to T30 HW, I tried to eliminate what I could that I knew for sure was T20-specific and not useful. But I've made no effort to combine common files/code in this initial pass. I think it's much easier to understand and review these files as a separate SoC build, rather than having to parse common/combined files and code. I intend to do the combination/common-izing of the TegraXX builds once I have a reasonable T30 build in u-boot-tegra, perhaps even before I start porting the drivers. But this is the initial approach I took. Hopefully it'll be an acceptable course - I'd hate to have to back-track.
To be honest, it seems like the patch to add the Tegra30 deltas to the existing Tegra20 code would be massively smaller than duplicating all of Tegra20 as Tegra30 and applying those same changes. In the kernel, we have both Tegra20 and Tegra30 support with run-time differentiation, and the number of places where we have to do something different is not that large at all. With the current patch series, there's a huge amount of code to wade through, so spotting any places that haven't been updated for Tegra30, or weren't intended to be updated yet, is somewhat painful.
Since we know that the delta can be small, yes, let's just do this right the first time (or so). incremental moves, additions and we can work out run-vs-build time a little further down the road.
Sorry, Tom. I'm not clear on exactly which way you'd like to see this go.
Are you advising that I re-cast this patchset as a set of common Tegra files/code, with deltas/diffs for the Tegra30 changes? That implies, I think, that I first have to do a patchset that re-orgs Tegra20 code into common code, and then submit a smaller version of this patchset that is just deltas for Tegra30. That means that I'll be touching everyone's Tegra20 code, and will need Ack's from all the T20 vendors before I can move forward w/T30 code.
The other approach, which is still a 2-(or more)-patchset process, is to continue with this patchset for T30, with corrections as per review, and then immediately work on a 'merge-to-common-code' set of patches to common-ize Tegra20/30. That way Tegra20 is unaffected, I can keep moving forward, and I think the end result will be the same as the approach above.
I can see value in both approaches, and it shouldn't surprise you that I'd favor the 2nd approach, since it's less chaotic for me. Let me know what you think,
Tom
-- Tom