devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gerlach <d-gerlach@ti.com>
To: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	devicetree@vger.kernel.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 13:47:19 -0600	[thread overview]
Message-ID: <54F8B2C7.7060202@ti.com> (raw)
In-Reply-To: <20150305184952.GF13520@atomide.com>

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

Regards,
Dave

> So maybe the comments in the $subject patch are incorrect for that?
> 
> What we really should have is also status = "incomplete" where the
> dev entry gets created, but the driver never probes. This would be for
> devices that are still there within the SoC, but not pinned out for
> the board in question.
> 
> We still may need also ti,no-init too for devices that we don't want
> hwmod to do anything with, for example in secure mode if some blocks
> are not available to Linux at all. I believe that's what's going on with
> n900 crypto accelerators for example.
> 
> Regards,
> 
> Tony
> 


  reply	other threads:[~2015-03-05 19:47 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 [this message]
2015-03-05 20:17         ` Tony Lindgren
2015-03-06  0:41           ` Tony Lindgren
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=54F8B2C7.7060202@ti.com \
    --to=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 \
    --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: 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).