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