On 10/02/15 14:14, Krzysztof Kozlowski wrote: > On wto, 2015-02-10 at 14:00 +0100, Sylwester Nawrocki wrote: >> > On 10/02/15 13:46, Javier Martinez Canillas wrote: >>>>>> > >>>> This debugfs code iterates over list of generic_pm_domains (gpd_list). I >>>>>>>>> > >>>> >> > cannot find function for translating from genpd to its platform device >>>>>>>>> > >>>> >> > so only genpd->name can be printed. >>>>>>> > >>> >> >>>>>>> > >>> >> Then why power domains aren't just named with the platform device names? >>>>> > >> > >>>>> > >> > Right, the mach-exynos/pm_domains.c set the name equal to OF node name. >>>>> > >> > I'll send a patch extending the name. >>>>> > >> > >>> > > IIRC the OF core uses the device node unit address and node name to create >>> > > the platform device names so you will have something like 10044000.power-domain. >>> > > >>> > > Same if using the node full_name since it will /power-domain@10044000. In both >>> > > cases the DTS should have to be checked to know which power domain really is >>> > > unless someone knows by heart the power domains addresses. > For the kernel developer that would be descriptive enough to find the > real domain but... as you said each time one would have to grep through > manual or DTS which is slower. However for end-user that still won't be > descriptive enough. > >>> > > >>> > > But if using generic names for the power domains as suggested by ePAPR is so >>> > > important then we should change all the other Exynos DTS files which don't do. >> > >> > Perhaps we could assign OF aliases to the power domain device nodes in DT >> > and then in the power domains driver map those aliases to more descriptive >> > names when creating the power domains? > > That would required additional alias in DT but it could be the most > descriptive for a user. Yes, we could fall back to of_node->full_name if alias is not present in DT. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |