On 10/06/2015 03:09 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [150814 05:36]:
Basically the question with this set is, whether the DT node layout /
compatible string arrangement looks sane or not. Some of the compatibles
can be squashed together especially at clkdm data side, seeing the
remaining stub data portions are rather minimal. They could also just be
retained just in case we need to tweak something later....
Well does this play along with the genpd? Let's assume that within
a few merge cycles we have proper s3220 interconnect driver for
each L4 instance along the lines of simple-pm-bus ;)
I guess the question is what shall we represent under genpd. This series
represents/registers each clockdomain / powerdomain as a single genpd
entity (see patch #6, it adds the support for registering genpds.) If
the plan is to represent also each hwmod device as a genpd entity, it
should work fine I think, as each device can have a single clkdm as
their parent.
Patch #6 is still missing support for actual control of the domains, the
functions are just dummies. Hwmod should use genpd also instead of
direct control of clkdms.
We could also add support for voltagedomains under genpd if required.
This RFC series is rather minimal in functionality still just to get
some feedback of the approaches taken.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
