Re: DSS2 patch series

["Cousson, Benoit" <b-cousson@ti.com>]

Hi Archit,

On 8/17/2010 1:16 PM, 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.

You can use hwmod to store that as well. Other IPs might require 
features management, so instead of doing a DSS dedicated solution, you 
can directly leverage the existing fmwk and extend it to manage your 
features.

> 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.

Good? It works, but this is still redoing what the clocks framework can 
already do. The good approach will be to encode your clocks nodes using 
the clock framework, as you've just said.

> 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?

Using directly the hwmod struct sound a much better idea for my point of 
view.

Regards,
Benoit