From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
Date: Tue, 16 Jul 2013 12:00:03 +0530 [thread overview]
Message-ID: <51E4E86B.30807@ti.com> (raw)
In-Reply-To: <51E44C48.3090905@ti.com>
On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote:
> On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
>> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>>> Hi,
>>>>>
>>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>>> * Felipe Balbi <balbi@ti•com> [130710 09:18]:
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>>> during probe.
>>>>>>>>
>>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>>
>>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>>> Author: Felipe Balbi <balbi@ti•com>
>>>>>>>> Date: Wed Jul 10 18:50:16 2013 +0300
>>>>>>>>
>>>>>>>> arm: omap2plus: unidle devices which are about to probe
>>>>>>>>
>>>>>>>> in order to make HWMOD and pm_runtime agree on the
>>>>>>>> initial state of the device, we will unidle the device
>>>>>>>> and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>> that the device is really active.
>>>>> Don't think that it's good idea (
>>>>> I've checked some driver's and think this patch will enable some devices
>>>>> unpredictably:
>>>>> - hwspinlock
>>>>> - mailbox
>>>>> - iommu
>>>>> - ipu
>>>>> All above devices need to be enabled on demand only (no
>>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>>> specific enabling sequence - like ipu).
>>>>>
>>>>> May be Summan can say more on that.
>>>>
>>>> Indeed, this is a problem for any of the slave processor devices.
>>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>>> a specific sequence of bringing up a processor. The current
>>>> hwmod/omap_device code is such that these devices will be left in reset
>>>> and the driver code use the omap_device_(de)assert_hardreset API
>>>> together with omap_device_enable code to bring up the devices. The
>>>> remoteproc driver also needs to assert the resets (there are other
>>>> problems associated with using omap_device_idle for remoteproc and
>>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>>> and mailbox may get away since they are in CORE domain, but definitely
>>>> an issue for iommu and remoteproc. I would think that this would also
>>>> affect other compute devices like IVAHD, ISS, SGX.
>>>
>>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
>
> Yes, the omap_device_enable bails out if the reset lines are still
> asserted, and the driver code deals with the resets currently. This code
> essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
> added to the corresponding hwmods - we do not want the hwmod/omap_device
> code to enable the processor IPs and leave the enabling/device
> management to the driver.
>
>>>
>>> /*
>>> * If an IP block contains HW reset lines and all of them are
>>> * asserted, we let integration code associated with that
>>> * block handle the enable. We've received very little
>>> * information on what those driver authors need, and until
>>> * detailed information is provided and the driver code is
>>> * posted to the public lists, this is probably the best we
>>> * can do.
>>> */
>>> if (_are_all_hardreset_lines_asserted(oh))
>>> return 0;
>>>
>>> What if this information is send back to omap_device() through a return value
>>> so omap_device() knows about this too, so it avoids marking the omap device as
>>> enabled? Wouldn't that fix the issue?
>>
>> I meant something like this..
>>
>> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
>> From: Rajendra Nayak <rnayak@ti•com>
>> Date: Mon, 15 Jul 2013 15:23:07 +0530
>> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>> enable/idle/shutdown the hwmods
>>
>> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
>> enable/idle/shutdown operations as long as all the hard reset lines are
>> kept asserted. However it does not return an error back to the caller (in some
>> cases the omap_device layer) to communicate back the failure to operate on the
>> hwmod.
>>
>> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
>> cases, and also fix the omap_device layer to look at the return values coming
>> from hwmod operations before doing a omap_device level state transition.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti•com>
>
> Let me test this and get back to you if there are any issues.
Great, thanks for testing.
>
> regards
> Suman
>
next prev parent reply other threads:[~2013-07-16 6:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 13:25 Boot hang regression 3.10.0-rc4 -> 3.10.0 Mark Jackson
2013-07-04 15:14 ` Mark Jackson
2013-07-04 16:00 ` Mark Jackson
2013-07-05 8:11 ` Bedia, Vaibhav
2013-07-05 11:59 ` Tony Lindgren
2013-07-05 13:20 ` Bedia, Vaibhav
2013-07-05 13:31 ` Bedia, Vaibhav
2013-07-08 11:25 ` Tony Lindgren
2013-07-08 12:16 ` Tony Lindgren
2013-07-08 12:41 ` Rajendra Nayak
2013-07-08 13:10 ` Tony Lindgren
2013-07-08 13:20 ` Rajendra Nayak
2013-07-08 13:25 ` Rajendra Nayak
2013-07-08 13:35 ` Felipe Balbi
2013-07-09 5:33 ` Rajendra Nayak
2013-07-09 6:42 ` Felipe Balbi
2013-07-09 7:19 ` Rajendra Nayak
2013-07-09 7:40 ` Felipe Balbi
2013-07-09 18:59 ` Grygorii Strashko
2013-07-09 19:41 ` Felipe Balbi
2013-07-10 12:16 ` Grygorii Strashko
2013-07-10 12:25 ` Felipe Balbi
2013-07-10 8:22 ` Kevin Hilman
2013-07-10 12:10 ` Tony Lindgren
2013-07-10 12:27 ` Tony Lindgren
2013-07-10 14:26 ` Tony Lindgren
2013-07-10 16:07 ` Felipe Balbi
2013-07-10 16:11 ` Felipe Balbi
2013-07-11 6:32 ` Tony Lindgren
2013-07-11 9:59 ` Grygorii Strashko
2013-07-12 0:40 ` Suman Anna
2013-07-15 6:44 ` Rajendra Nayak
2013-07-15 10:01 ` Rajendra Nayak
2013-07-15 19:23 ` Suman Anna
2013-07-16 6:30 ` Rajendra Nayak [this message]
2013-07-11 9:17 ` Rajendra Nayak
2013-07-11 9:26 ` Felipe Balbi
2013-07-11 10:16 ` [PATCH] arm: omap2plus: unidle devices which are about to probe Felipe Balbi
2013-07-12 11:58 ` Grygorii Strashko
2013-07-12 12:10 ` Felipe Balbi
2013-07-12 12:27 ` Rajendra Nayak
2013-07-13 22:21 ` Kevin Hilman
2013-07-11 9:59 ` Boot hang regression 3.10.0-rc4 -> 3.10.0 Grygorii Strashko
2013-07-16 10:27 ` Grygorii Strashko
2013-07-17 7:10 ` Rajendra Nayak
2013-07-11 6:18 ` Rajendra Nayak
2013-07-11 6:24 ` Tony Lindgren
2013-07-11 9:11 ` Rajendra Nayak
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=51E4E86B.30807@ti.com \
--to=rnayak@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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