All of lore.kernel.org
 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
> 


WARNING: multiple messages have this Message-ID (diff)
From: d-gerlach@ti.com (Dave Gerlach)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 44+ 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 ` 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 13:13   ` [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti, no-init " Dave Gerlach
2015-03-05 18:16   ` [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init " Paul Walmsley
2015-03-05 18:16     ` Paul Walmsley
2015-03-05 18:49     ` Tony Lindgren
2015-03-05 18:49       ` Tony Lindgren
2015-03-05 19:47       ` Dave Gerlach [this message]
2015-03-05 19:47         ` Dave Gerlach
2015-03-05 20:17         ` Tony Lindgren
2015-03-05 20:17           ` Tony Lindgren
2015-03-06  0:41           ` Tony Lindgren
2015-03-06  0:41             ` Tony Lindgren
2015-03-06 17:28             ` Dave Gerlach
2015-03-06 17:28               ` Dave Gerlach
     [not found]               ` <54F9E3BF.5010407-l0cyMroinI0@public.gmane.org>
2015-03-06 17:45                 ` Tony Lindgren
2015-03-06 17:45                   ` Tony Lindgren
2015-03-10 16:12                   ` Dave Gerlach
2015-03-10 16:12                     ` Dave Gerlach
2015-03-10 17:36                   ` Grygorii Strashko
2015-03-10 17:36                     ` Grygorii Strashko
2015-03-10 17:59                     ` Dave Gerlach
2015-03-10 17:59                       ` Dave Gerlach
2015-03-11 16:32                       ` Grygorii Strashko
2015-03-11 16:32                         ` Grygorii Strashko
2015-03-12 20:05                         ` Dave Gerlach
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-05 13:13   ` Dave Gerlach
2015-03-06  4:26   ` Paul Walmsley
2015-03-06  4:26     ` Paul Walmsley
2015-03-06 17:30     ` Dave Gerlach
2015-03-06 17:30       ` Dave Gerlach
2015-03-06 17:44       ` Paul Walmsley
2015-03-06 17:44         ` Paul Walmsley
2015-03-06 17:50         ` Dave Gerlach
2015-03-06 17:50           ` Dave Gerlach
2015-03-07  0:37           ` Paul Walmsley
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 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
2015-03-05 13:13   ` 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 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.