On Tue, 2010-08-10 at 11:33 +0200, ext Taneja, Archit wrote: > [Archit] I have collected some information about what these revision > numbers mean from the TI folks. The following is what I have gathered: > > -For each broad version of OMAP, like OMAP3430, OMAP3630, OMAP4430 and so on, > there is an independent revision list. These are changed/incremented when > the corresponding IP blocks are modified. The numbers which we see are probably > the ones which were chosen to put into the silicon. > > So, it is possible that the revision numbers of ES_1 of OMAP3430 is exactly the > same as the ES_1 of OMAP3630 even if the IP blocks have changed. This is what is > seen in the prints of the revision of 3430 and 3630 I sent in the previous mail. > > These revision numbers are hence useful only within the revisions of a particular > OMAP. It looks like that there is no single revision chain since OMAP2. > > -After discussions with more TI DSS folks, it seems that some changes that we may > need to make in DSS software may not be dependent on the DSS hardware at all. For example, > the patch "OMAP3630:DSS2: Updating MAX divider value" was introduced because of a change > in PRCM. > > So it seems that we will need to have omap2, omap3 and omap4 checks , best we can > do is prevent them from scattering around, i.e have them at a single place during > initialization. Ok. Well, good that it's clear now =). > How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). Tomi -- 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
