[U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

[Tom Warren]

Tom,

On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini <trini at 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 at 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