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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to