Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled

[Kevin Hilman <khilman@ti.com>]

"Cousson, Benoit" <b-cousson@ti.com> writes:

> + Kevin
>
> On 2/15/2012 1:51 PM, Tomi Valkeinen wrote:
>> On Wed, 2012-02-15 at 13:35 +0100, Cousson, Benoit wrote:
>>
>>> 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

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