public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: tomi.valkeinen@ti•com (Tomi Valkeinen)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: OMAP5: DSS hwmod data
Date: Fri, 9 May 2014 09:36:44 +0300	[thread overview]
Message-ID: <536C777C.8000600@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1405081558570.23579@utopia.booyaka.com>

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:
>>> Hi,
>>>
>>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote:
>>>
>>>> This patch adds hwmod data for omap5 display subsystem. I have tested this
>>>> on
>>>> 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.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140509/67aef498/attachment.sig>

  parent reply	other threads:[~2014-05-09  6:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 10:26 [PATCH] ARM: OMAP5: DSS hwmod data Tomi Valkeinen
2014-03-12 10:26 ` [PATCH] ARM: OMAP5: Add omap5 DSS related " Tomi Valkeinen
2014-03-12 10:33 ` [PATCH] ARM: OMAP5: DSS " Tomi Valkeinen
2014-03-16 11:41   ` Dmitry Lifshitz
2014-03-17  6:13     ` Tomi Valkeinen
2014-03-17 13:22       ` Dmitry Lifshitz
2014-03-17 13:28         ` Tomi Valkeinen
2014-03-17 14:22           ` Dmitry Lifshitz
2014-03-18  5:29             ` Tomi Valkeinen
2014-03-18  8:19               ` Dmitry Lifshitz
2014-03-18  8:37                 ` Tomi Valkeinen
2014-03-18 12:23                   ` Dmitry Lifshitz
2014-05-08  4:37 ` Paul Walmsley
2014-05-08  5:48   ` Archit Taneja
2014-05-08 16:01     ` Paul Walmsley
2014-05-09  6:19       ` Archit Taneja
2014-05-09  6:36       ` Tomi Valkeinen [this message]
2014-05-14 19:44         ` Paul Walmsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536C777C.8000600@ti.com \
    --to=tomi.valkeinen@ti$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox