On 7/8/2011 12:11 AM, Paul Walmsley wrote:
On Thu, 7 Jul 2011, Martin Fouts wrote:
From: Tony Lindgren [tony@xxxxxxxxxxx]
The second problem we have here is "why does adding 4460 support depend
on a cosmetic clean-up patch". That dependency should not exist at all
as it seems the 4460 patches should work even without this patch.
I agree. Had the original submitter had the foresight to realize that
the code should work for all 44xx family processors, we would have no
issue at all.
Uhhh...
The original 4430 data, which is mostly what we're talking about here, was
added in 2009. Maybe a few people inside TI knew what was going to change
and what was going to be the same for future OMAP4 parts. But even if
someone did know, the decision of what to call a chip often isn't up to
engineers, it's up to marketing, which picks whatever name they like.
You know, like Linux 2.6.40^H^H^H^H^H^H3.0.
So back in 2009, the submitter and maintainers were faced with a choice:
Option 1. Submit patches with facts. "OMAP4430". Don't speculate what
future, as-yet-nonexistent products will be numbered, and what their
feature set will be. Plan to generalize later once it is known exactly
what needs to be generalized.
Option 2. Try to predict what marketing will call the next chip, and what
features will still be present, then put that into the codebase.
"OMAP44XX". Hope you guess right so you don't have to change them all if
marketing or engineering comes up with something different.
So, what's the right answer?
I probably can't tell you that, but I can tell you that in 2009, option 1
seemed more technically conservative. So that's what we did. Maybe that
isn't the right answer, though.
I completely agree with Paul. What if the 4460 of today was called
4640 for some reason. (Well we do have a 3630, don't we)
Would the OMAP44XX work then, no. We would need a OMAP4XXX instead.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html