RE: DSS2 patch series

[Tomi Valkeinen <tomi.valkeinen@nokia.com>]

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