[PATCH] ARM: OMAP5: DSS hwmod data
tomi.valkeinen at ti.com
Thu May 8 23:36:44 PDT 2014
On 08/05/14 19:01, Paul Walmsley wrote:
> Hi Archit,
> On Thu, 8 May 2014, Archit Taneja wrote:
>> Hi Paul,
>> On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote:
>>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote:
>>>> This patch adds hwmod data for omap5 display subsystem. I have tested this
>>>> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet,
>>>> as the
>>>> mainline is missing omap5 HDMI driver.
>>>> I do see this when booting:
>>>> omap_hwmod: dss_dispc: cannot be enabled for reset (3)
>>>> omap_hwmod: dss_dsi1: cannot be enabled for reset (3)
>>>> omap_hwmod: dss_dsi2: cannot be enabled for reset (3)
>>>> omap_hwmod: dss_hdmi: cannot be enabled for reset (3)
>>>> omap_hwmod: dss_rfbi: cannot be enabled for reset (3)
>>>> But at least DSI works just fine.
>>> Am looking at this for v3.16. But I think someone needs to take a look at
>>> those warnings and figure out why they are happening.
>> We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod.
>> The rest of the dss hwmods don't touch MODULEMODE.
>> Therefore, these hwmods cannot be enabled independently, and reset.
>> We don't face this issue in the omapdss driver since the platform devices
>> corresponding to these hwmods have their parent as the platform device
>> corresponding to 'dss_core'. This parent child-relation ensures that
>> 'dss_core' is enabled when the a child calls a pm_runtime_get function.
>> The problem is that we have multiple hwmods which use the same MODULEMODE bit.
>> There is no use-counting done when it comes to enabling/disabling modulemode.
>> If there was such a thing, we could have provided MODULEMODE flags even for
>> the children hwmods.
> Thanks for the summary. This is indeed a long-overdue item for the hwmod
> core code. Can you please patch the hwmod core code to add this? I'd
> suggest making the use-counting functionality conditional on a hwmod flag
> that you can set for all of the DSS hwmods. (Ideally, the core code would
> detect that several modules share the same MODULEMODE bits, and
> automatically set it for those cases, but that seems a bit too complex for
> a first cut.)
Can we still go forward with this patch as it is? As far as I
understand, the warnings are harmless (more or less), but without this
patch we won't have OMAP5 display support.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the linux-arm-kernel