RE: DSS2 patch series

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

On Tue, 2010-08-17 at 13:16 +0200, ext Taneja, Archit wrote:
> Hi,
> 
> > 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).
> 
> I talked to some more folks about this. To summarize:
> 
> - The revision registers aren't reliable enough, it's better to
> use the combination of cpu_is_xxxx and and omap_rev macros. These
> should be enough for making an DSS specific feature list.
> 
> -The feature framework(HWMOD) can help out with the following things
> 	- The internal IP blocks within DSS.
> 	- The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't
> 	know much about.
> 	- Effectively, the information on how the outside world communicates with DSS.
> 
> -DSS features like number of vid pipelines, supported color modes,internal clocks
> and PLL info, bit fields needs to be managed by us.
> 
> One good input was that we can manage internal DSS clocks using the exisiting
> clock framework and custom clock modes. I don't know much about it. Others
> in the list can probably help out with this :)
> 
> The present way of handling DSS2 clocks is good, but we need to see if it can be
> scalable when more OMAPs come in.
> 
> The dss_features.c idea sounds good, we will still have these new bunch of functions
> scattered around in the code. But it will be much than an if else chain of omap checks.
> 
> So should we stick with this idea?

Yes, and even if the dss_features.c isn't what is needed in the end,
it'll still be easier to convert to whatever way we want in the future.

But this is also not a very high priority thing. So I don't see a need
to start converting everything to use dss_features.c right away. We can
start by converting the places where OMAP4 changes require feature
checks.

 Tomi