From: Tony Lindgren <tony@atomide.com>
To: Dave Gerlach <d-gerlach@ti.com>
Cc: devicetree@vger.kernel.org, Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
KEERTHY <j-keerthy@ti.com>
Subject: Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
Date: Thu, 5 Mar 2015 16:41:57 -0800 [thread overview]
Message-ID: <20150306004157.GI13520@atomide.com> (raw)
In-Reply-To: <20150305201713.GH13520@atomide.com>
* Tony Lindgren <tony@atomide.com> [150305 12:24]:
> * Dave Gerlach <d-gerlach@ti.com> [150305 11:53]:
> > On 03/05/2015 12:49 PM, Tony Lindgren wrote:
> > > * Paul Walmsley <paul@pwsan.com> [150305 10:16]:
> > >> On Thu, 5 Mar 2015, Dave Gerlach wrote:
> > >>
> > >>> Introduce a dt property, ti,no-init, that prevents hwmod initialization.
> > >>> Even if a dt node is marked as disabled, hwmod still at least enables
> > >>> the hwmod and programs the sysconfig before attempting to idle it at
> > >>> boot. If an IP has been disabled by the hardware configuration on a
> > >>> platform, this will cause a hang due to writing to inactive registers.
> > >>> This property prevents that from happening by marking the hwmod as
> > >>> _HWMOD_STATE_DISABLED during init.
> > >>
> > >> I'm kind of wondering if hwmod should even touch a device if it's marked
> > >> as disabled in the DT. Tony, what do you think?
> > >
> > > Well nothing happens if a device is status = "disabled". No dev entry
> > > gets created for it at all and hwmod won't have any data for the device
> > > populated. The only way hwmod code could see that device if the device
> > > gets it's data from the legacy omap_hwmod_*_data.c instead of DT.
> > >
> >
> > We still need this for the sysconfig programming, correct? hwmod programs that
> > regardless of dt status and then idles the IP,
>
> Well hwmod does not even know about the IP IO addresses if it's marked
> with status = "disabled".. Which IP are you having problems with?
>
> > which is why I needed the ti,no-init for the epos evm. It isn't just a
> > matter of we shouldnt write to it because we don't want to use it; we
> > can't write to it because the module is held off so it causes an
> > external abort if we do.
>
> Well hard to say not knowing which module this is.. Pretty much all
> the modules have drivers and the driver just does pm_runtime_get()
> on it?
Heh OK this thread is about the RTC driver, so I assume that's the
problem :) So if you set the rtc to status = "disabled" how can the
hwmod code do anything as AFAIK it won't even get the rtc IO address?
Or am I missing something here?
Regards,
Tony
next prev parent reply other threads:[~2015-03-06 0:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 13:13 [PATCH 0/4] Add AM437x RTC Dave Gerlach
2015-03-05 13:13 ` [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property Dave Gerlach
2015-03-05 18:16 ` Paul Walmsley
2015-03-05 18:49 ` Tony Lindgren
2015-03-05 19:47 ` Dave Gerlach
2015-03-05 20:17 ` Tony Lindgren
2015-03-06 0:41 ` Tony Lindgren [this message]
2015-03-06 17:28 ` Dave Gerlach
[not found] ` <54F9E3BF.5010407-l0cyMroinI0@public.gmane.org>
2015-03-06 17:45 ` Tony Lindgren
2015-03-10 16:12 ` Dave Gerlach
2015-03-10 17:36 ` Grygorii Strashko
2015-03-10 17:59 ` Dave Gerlach
2015-03-11 16:32 ` Grygorii Strashko
2015-03-12 20:05 ` Dave Gerlach
2015-03-05 13:13 ` [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx Dave Gerlach
2015-03-06 4:26 ` Paul Walmsley
2015-03-06 17:30 ` Dave Gerlach
2015-03-06 17:44 ` Paul Walmsley
2015-03-06 17:50 ` Dave Gerlach
2015-03-07 0:37 ` Paul Walmsley
2015-03-05 13:13 ` [PATCH 3/4] ARM: dts: am43x-epos-evm: Add rtc node with ti,no-init property Dave Gerlach
2015-03-05 13:13 ` [PATCH 4/4] ARM: dts: am437x-gp-evm: Enable RTC Dave Gerlach
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=20150306004157.GI13520@atomide.com \
--to=tony@atomide.com \
--cc=d-gerlach@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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: link
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;
as well as URLs for NNTP newsgroup(s).