Premi, Sanjeev had written, on 11/13/2009 04:53 AM, the following:
-----Original Message-----
From: Menon, Nishanth
Sent: Friday, November 13, 2009 3:46 PM
To: Premi, Sanjeev
Cc: Gadiyar, Anand; Tony Lindgren; linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Change the default silicon
Premi, Sanjeev had written, on 11/13/2009 04:10 AM, the following:
-----Original Message-----
From: Gadiyar, Anand
Sent: Friday, November 13, 2009 10:41 AM
To: Tony Lindgren; Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] omap3: Change the default silicon
Tony Lindgren wrote:
* Sanjeev Premi <pr...@ti.com> [091029 07:35]:
Currently the default silicon - in absence of
identification - is set to OMAP3630 ES1.0.
Though, condition may/should not arise; but
the default should be latest in the most
common silicon variant - currently OMAP3430
ES3.1.
Is this still needed? To me it seems more likely there will
more 3630 based silicon than 3430 based silicon?
3430 ES3.1s are the most common I believe. All boards in the wild
are 3430 based.
3630 is just coming up and will take a while to be as common.
IMO, 3430 ES3.1 should be default.
- Anand
[sp] That's exactly the reason for this patch.
There is a small typo in the comment though :(
/* Unknown. Default to latest among all variants */
Should be:
/* Unknown. Default to common among all variants */
Sending a v2 for the same.
I believe this patch should be dropped -> here is why -> if
you have new
silicons that are in 3430 category, you should be sending patches for
them ;)..
Default != new si
IMHO, I would rather have it as a BUG() instead of giving something
default there.. essentially hitting that case points at: "hey here is a
chip the programmers did not think about, let me be smart and try to
dream up what they might be using" - lets face it, our code aint' that
smart.. we have two options:
a) Make a guess what it might be
b) force the programmer to fix the bug and send us the patch ;)..
just my 2 cents..
The latest and greatest in the bucket of silicons is 3630 and I would
rather go with felipe's patch [1] cleaning up the id.c than
No issues with felipe's patch. It is cleaning the code style.
this -> in
my opinion, hitting this condition is only because you have the next
generation of devices..
Since we are talking OMAP3 derivatives, the default should be the
base - in case the condition ever arises. The fall back should
usually be 'most common' than 'latest'.
~sanjeev
--
Regards,
Nishanth Menon
Ref:
[1]: http://patchwork.kernel.org/patch/59540/
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
