From: Suman Anna <s-anna@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>, Roger Quadros <rogerq@ti.com>,
tony@atomide.com, santosh.shilimkar@oracle.com, t-kristo@ti.com,
nm@ti.com, nsekhar@ti.com, bcousson@baylibre.com,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Date: Tue, 13 Jan 2015 19:56:42 -0600 [thread overview]
Message-ID: <54B5CCDA.4040304@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1501132324150.28034@utopia.booyaka.com>
Hi Paul,
On 01/13/2015 05:29 PM, Paul Walmsley wrote:
> Hi Suman,
>
> thanks for pitching in on this!
>
> On Tue, 6 Jan 2015, Suman Anna wrote:
>
>> You have removed the return from the above block on failure. If any DT
>> entry doesn't have the reg property, this will hang the kernel boot.
>> Just remove the "reg" entry from any of the existing DT, and you will
>> run into the issue, this is what 6423d6df1440 ("ARM: OMAP2+: hwmod:
>> check for module address space during init") fixed.
>
> Seems like that's the problem that we need to track down, then. If a
> hwmod has no MPU-accessible registers, it should still be possible to
> init the clocks for the device, etc. ...
Yes true, and I should have rephrased above statement a little better -
its for modules with sysc but with no reg property to supply the base
for the module's SYSCONFIG or SYSSTATUS registers. The commit
6423d6df1440 has the explanation for the hang.
>
>> Also, are you sure you want to turn the WARN into a pr_debug, it won't
>> even show during the kernel boot log if the reg base is missing.
>
> No, I'm not sure :-) I guess it depends how many hwmods we'll have with
> no MPU-accessible registers. We don't seem to have address ranges for the
> interconnects defined; we could fix that fairly easily.
The WARN_ON previously was to throw a eye-catchy print for the case
where hwmods have sysc but no address space defined (is an error
usually, but this is what we run into during the DT conversion of a
device as the hwmod and DTS changes come in through separate topic
branches). I still think that the sysc check should be before the check
for _HWMOD_NO_MPU_PORT, a module with sysc mandates it has an MPU port.
regards
Suman
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Date: Tue, 13 Jan 2015 19:56:42 -0600 [thread overview]
Message-ID: <54B5CCDA.4040304@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1501132324150.28034@utopia.booyaka.com>
Hi Paul,
On 01/13/2015 05:29 PM, Paul Walmsley wrote:
> Hi Suman,
>
> thanks for pitching in on this!
>
> On Tue, 6 Jan 2015, Suman Anna wrote:
>
>> You have removed the return from the above block on failure. If any DT
>> entry doesn't have the reg property, this will hang the kernel boot.
>> Just remove the "reg" entry from any of the existing DT, and you will
>> run into the issue, this is what 6423d6df1440 ("ARM: OMAP2+: hwmod:
>> check for module address space during init") fixed.
>
> Seems like that's the problem that we need to track down, then. If a
> hwmod has no MPU-accessible registers, it should still be possible to
> init the clocks for the device, etc. ...
Yes true, and I should have rephrased above statement a little better -
its for modules with sysc but with no reg property to supply the base
for the module's SYSCONFIG or SYSSTATUS registers. The commit
6423d6df1440 has the explanation for the hang.
>
>> Also, are you sure you want to turn the WARN into a pr_debug, it won't
>> even show during the kernel boot log if the reg base is missing.
>
> No, I'm not sure :-) I guess it depends how many hwmods we'll have with
> no MPU-accessible registers. We don't seem to have address ranges for the
> interconnects defined; we could fix that fairly easily.
The WARN_ON previously was to throw a eye-catchy print for the case
where hwmods have sysc but no address space defined (is an error
usually, but this is what we run into during the DT conversion of a
device as the hwmod and DTS changes come in through separate topic
branches). I still think that the sysc check should be before the check
for _HWMOD_NO_MPU_PORT, a module with sysc mandates it has an MPU port.
regards
Suman
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>, Roger Quadros <rogerq@ti.com>,
<tony@atomide.com>, <santosh.shilimkar@oracle.com>,
<t-kristo@ti.com>, <nm@ti.com>, <nsekhar@ti.com>,
<bcousson@baylibre.com>, <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Date: Tue, 13 Jan 2015 19:56:42 -0600 [thread overview]
Message-ID: <54B5CCDA.4040304@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1501132324150.28034@utopia.booyaka.com>
Hi Paul,
On 01/13/2015 05:29 PM, Paul Walmsley wrote:
> Hi Suman,
>
> thanks for pitching in on this!
>
> On Tue, 6 Jan 2015, Suman Anna wrote:
>
>> You have removed the return from the above block on failure. If any DT
>> entry doesn't have the reg property, this will hang the kernel boot.
>> Just remove the "reg" entry from any of the existing DT, and you will
>> run into the issue, this is what 6423d6df1440 ("ARM: OMAP2+: hwmod:
>> check for module address space during init") fixed.
>
> Seems like that's the problem that we need to track down, then. If a
> hwmod has no MPU-accessible registers, it should still be possible to
> init the clocks for the device, etc. ...
Yes true, and I should have rephrased above statement a little better -
its for modules with sysc but with no reg property to supply the base
for the module's SYSCONFIG or SYSSTATUS registers. The commit
6423d6df1440 has the explanation for the hang.
>
>> Also, are you sure you want to turn the WARN into a pr_debug, it won't
>> even show during the kernel boot log if the reg base is missing.
>
> No, I'm not sure :-) I guess it depends how many hwmods we'll have with
> no MPU-accessible registers. We don't seem to have address ranges for the
> interconnects defined; we could fix that fairly easily.
The WARN_ON previously was to throw a eye-catchy print for the case
where hwmods have sysc but no address space defined (is an error
usually, but this is what we run into during the DT conversion of a
device as the hwmod and DTS changes come in through separate topic
branches). I still think that the sysc check should be before the check
for _HWMOD_NO_MPU_PORT, a module with sysc mandates it has an MPU port.
regards
Suman
next prev parent reply other threads:[~2015-01-14 1:56 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 15:49 [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc Roger Quadros
2014-12-18 15:49 ` Roger Quadros
2014-12-18 15:52 ` Roger Quadros
2014-12-18 15:52 ` Roger Quadros
2014-12-19 5:21 ` Lokesh Vutla
2014-12-19 5:21 ` Lokesh Vutla
2014-12-19 9:06 ` Roger Quadros
2014-12-19 9:06 ` Roger Quadros
2015-01-02 17:29 ` Tony Lindgren
2015-01-02 21:10 ` Paul Walmsley
2015-01-02 21:10 ` Paul Walmsley
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 19:53 ` Suman Anna
2015-01-05 19:53 ` Suman Anna
2015-01-05 19:53 ` Suman Anna
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:31 ` santosh.shilimkar
2015-01-05 22:31 ` santosh.shilimkar at oracle.com
2015-01-06 2:04 ` Paul Walmsley
2015-01-06 2:04 ` Paul Walmsley
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-13 23:45 ` Paul Walmsley
2015-01-13 23:45 ` Paul Walmsley
2015-01-13 23:29 ` Paul Walmsley
2015-01-13 23:29 ` Paul Walmsley
2015-01-14 1:56 ` Suman Anna [this message]
2015-01-14 1:56 ` Suman Anna
2015-01-14 1:56 ` Suman Anna
2015-01-07 11:20 ` Roger Quadros
2015-01-07 11:20 ` Roger Quadros
2015-01-07 11:20 ` Roger Quadros
2015-01-13 23:46 ` Paul Walmsley
2015-01-13 23:46 ` Paul Walmsley
2015-01-14 12:26 ` Roger Quadros
2015-01-14 12:26 ` Roger Quadros
2015-01-14 12:26 ` Roger Quadros
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=54B5CCDA.4040304@ti.com \
--to=s-anna@ti.com \
--cc=bcousson@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=paul@pwsan.com \
--cc=rogerq@ti.com \
--cc=santosh.shilimkar@oracle.com \
--cc=t-kristo@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: 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.