Nishanth, > -----Original Message----- > From: Menon, Nishanth > Sent: Wednesday, October 07, 2009 11:47 PM > To: linux-omap > Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; > Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, > Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; > Aguirre Rodriguez, Sergio Alberto; Tony Lindgren > Subject: [RFC][PATCH] OMAP3: introduce OMAP3630 > > Device intro: > OMAP3630 is the latest in the family of OMAP3 devices > and among the changes it introduces are: > > New OPP levels for new voltage and frequency levels. a bunch of > Bug fixes to various modules feature additions, notably with ISP, > sDMA etc. > > Details about the chip is available here: > http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t > emplateId=6123&navigationId=12836&contentId=52606 > > Strategy used: > Strategy to introduce this device into Linux was discussed here: > Ref: http://marc.info/?t=125343303400003&r=1&w=2 > > Two approaches were available: > a) Consider 3630 generation of devices as a new family of silicon > b) Consider 3630 as an offshoot of 3430 family of devices > > As a common consensus, (b) seems to be more valid for 3630 as: > * There are changes which are easily handled by looking at rev > * Most of existing 34xx infrastructure can be reused(almost 90%+) > - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) > all over the place And how about cpu_is_omap3() ? That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and 36xx (zoom3). IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the code quite unreadable. 1. If you need to do something 34xx specific, then use cpu_is_34xx() 2. If your code is valid for all 34xx, 35xx, 36xx, then why not using cpu_is_omap3() ? What do you think? > - lesser chance of bugs due to reuse of proven code flow > - 36xx specific handling can still be done where required > within the existing infrastructure > > NOTE: > * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be > added on top of the existing 3630 ones are renumbered > > This patch was tested on SDP3430. Maybe this should say: This patch didn't broke SDP3430. XD Regards, Sergio -- 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
