Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Kevin Hilman <hidden>
Date: 2012-02-15 19:59:19
Also in:
linux-omap
"Cousson, Benoit" [off-list ref] writes:
+ Kevin On 2/15/2012 1:51 PM, Tomi Valkeinen wrote:quoted
On Wed, 2012-02-15 at 13:35 +0100, Cousson, Benoit wrote:quoted
I think that changing the device creation to change the dev->parent should be pretty straightforward.That's not possible with the current kernel, right? We are now using omap_device_build() (in arch/arm/mach-omap2/display.c) to build the dss devices. Looking at the omap_device.c, the parent will always forcibly set to omap_device_parent. It'd be nice to be able to construct the device child-parent relationship the same way with both DT and non-DT cases.I guess this should not be needed anymore since now the whole PM runtime stuff is handled using pm_domain. int omap_device_register(struct platform_device *pdev) { pr_debug("omap_device: %s: registering\n", pdev->name); pdev->dev.parent = &omap_device_parent; pdev->dev.pm_domain = &omap_device_pm_domain; return platform_device_add(pdev); } Kevin, Do we still need to set the dev.parent to omap_device_parent?
Nope.
I guess the default &platform_bus parent is good enough and potentially the DSS children should be able to overwrite that.
Yes, now that we use PM domains, we don't need it. I just sent a patch to remove omap_device_parent. Kevin
quoted
Or can I create only the dss_core with omap_device_build(), and create the rest normally with platform device functions, and make dss_core the parent of the rest? But are the hwmods then handled correctly?You can, the only issue if you create a regular platform device is that you will miss the automatic pm_runtime support along with the hwmod device creation mechanism + clock / PM. I think we can add an extra parameter to allow changing the omap_device parent during omap_device_build.