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?
Thanks,
Archit--
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
