From: Archit Taneja <archit@ti.com> To: Paul Walmsley <paul@pwsan.com>, Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: "Tony Lindgren" <tony@atomide.com>, "Benoît Cousson" <bcousson@baylibre.com>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: OMAP5: DSS hwmod data Date: Thu, 8 May 2014 11:18:12 +0530 [thread overview] Message-ID: <536B1A9C.7050006@ti.com> (raw) In-Reply-To: <alpine.DEB.2.02.1405080432570.23579@utopia.booyaka.com> 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. > > Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() > ? Yes, that's the one that fails. We have the same DSS in OMAP4, but we don't see the issue there. That's because we have modeled the MODULEMODE bits as a fake interface clock. That lets us enable hwmods independently, but it messes up DSS PM as it breaks some rules related to the sequence in which the opt-clocks and MODULEMODE bits need to be disabled. We would want to change OMAP4 to work the way as above too, with the cost of having these prints above. Archit
WARNING: multiple messages have this Message-ID (diff)
From: archit@ti.com (Archit Taneja) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: OMAP5: DSS hwmod data Date: Thu, 8 May 2014 11:18:12 +0530 [thread overview] Message-ID: <536B1A9C.7050006@ti.com> (raw) In-Reply-To: <alpine.DEB.2.02.1405080432570.23579@utopia.booyaka.com> 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. > > Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() > ? Yes, that's the one that fails. We have the same DSS in OMAP4, but we don't see the issue there. That's because we have modeled the MODULEMODE bits as a fake interface clock. That lets us enable hwmods independently, but it messes up DSS PM as it breaks some rules related to the sequence in which the opt-clocks and MODULEMODE bits need to be disabled. We would want to change OMAP4 to work the way as above too, with the cost of having these prints above. Archit
next prev parent reply other threads:[~2014-05-08 5:49 UTC|newest] Thread overview: 43+ 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 ` Tomi Valkeinen 2014-03-12 10:26 ` [PATCH] ARM: OMAP5: Add omap5 DSS related " Tomi Valkeinen 2014-03-12 10:26 ` Tomi Valkeinen 2014-03-12 10:33 ` [PATCH] ARM: OMAP5: DSS " Tomi Valkeinen 2014-03-12 10:33 ` Tomi Valkeinen 2014-03-16 11:41 ` Dmitry Lifshitz 2014-03-16 11:41 ` Dmitry Lifshitz 2014-03-17 6:13 ` Tomi Valkeinen 2014-03-17 6:13 ` Tomi Valkeinen 2014-03-17 13:22 ` Dmitry Lifshitz 2014-03-17 13:22 ` Dmitry Lifshitz 2014-03-17 13:28 ` Tomi Valkeinen 2014-03-17 13:28 ` Tomi Valkeinen 2014-03-17 14:22 ` Dmitry Lifshitz 2014-03-17 14:22 ` Dmitry Lifshitz 2014-03-18 5:29 ` Tomi Valkeinen 2014-03-18 5:29 ` Tomi Valkeinen 2014-03-18 8:19 ` Dmitry Lifshitz 2014-03-18 8:19 ` Dmitry Lifshitz 2014-03-18 8:37 ` Tomi Valkeinen 2014-03-18 8:37 ` Tomi Valkeinen 2014-03-18 12:23 ` Dmitry Lifshitz 2014-03-18 12:23 ` Dmitry Lifshitz 2014-05-08 4:37 ` Paul Walmsley 2014-05-08 4:37 ` Paul Walmsley 2014-05-08 5:48 ` Archit Taneja [this message] 2014-05-08 5:48 ` Archit Taneja 2014-05-08 16:01 ` Paul Walmsley 2014-05-08 16:01 ` Paul Walmsley 2014-05-09 6:19 ` Archit Taneja 2014-05-09 6:19 ` Archit Taneja 2014-05-09 6:36 ` Tomi Valkeinen 2014-05-09 6:36 ` Tomi Valkeinen 2014-05-14 19:44 ` Paul Walmsley 2014-05-14 19:44 ` Paul Walmsley 2014-05-26 10:44 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-05-26 10:44 ` [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields Archit Taneja 2014-05-27 10:20 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Rajendra Nayak 2014-05-27 10:49 ` Archit Taneja 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja 2014-06-17 9:54 ` [RFC v2 1/2] arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-06-17 9:54 ` [RFC v2 2/2] arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields Archit Taneja
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=536B1A9C.7050006@ti.com \ --to=archit@ti.com \ --cc=bcousson@baylibre.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=paul@pwsan.com \ --cc=tomi.valkeinen@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.