* Tero Kristo <t-kristo@xxxxxx> [151006 06:27]: > 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. I think we can replace the ti,hwmods eventually with the following: 1. L4 specific interconnect bus code for each L4 instance that I have in the works 2. Support for genpd like you've done 3. Using reset controllers like you've done 4. Some binding for the sysc/syss registers like I suggested earlier and have the L4 interconnect code manage these for each device So I don't think we'll have much non-standard things left there to represent except #4 above. > 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. I think these might be automatic if we split things into separate L4 bus instances? For L4_WKUP, it's really within L4_CORE at least on some SoCs, but probably in a different segment. > This RFC series is rather minimal in functionality still just to get some > feedback of the approaches taken. Yes I think this is nice in general. Regards, Tony -- 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
