From: Tony Lindgren <tony@atomide.com>
To: Suman Anna <s-anna@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] Couple of dmtimer fixes
Date: Tue, 17 Mar 2015 10:45:29 -0700 [thread overview]
Message-ID: <20150317174529.GG31346@atomide.com> (raw)
In-Reply-To: <1426554843-42641-1-git-send-email-s-anna@ti.com>
* Suman Anna <s-anna@ti.com> [150316 18:14]:
> Hi Tony,
>
> Please find couple of non-urgent fixes to the OMAP dmtimer driver.
> The patches are based on 4.0-rc1.
>
> The first patch is a fix for the issue I reported earlier on the
> DRA7 dmtimer hwmod patches [1]. DRA7 has timers 13 through 16 disabled
> in DT currently, and enabling any of them would cause a kernel hang.
> This fix properly checks the pm_runtime_get_sync() calls in the OMAP
> dmtimer driver irrespective of whether the hwmods are added or not.
> In the case that they are not added, the runtime_pm calls should return
> the value as returned from _od_fail_runtime_resume(), and the probe
> should bail out properly fixing the boot hang.
>
> Second patch is a minor fix that balances the pm_runtime_enable() call
> in probe with pm_runtime_disable() call in remove, so that the devices
> can be bound again properly after doing an unbind through sysfs.
OK thanks applying both into omap-for-v4.0/fixes.
Tony
> [1] http://marc.info/?l=linux-omap&m=142653933112526&w=2
>
> Suman Anna (2):
> ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure
> ARM: OMAP: dmtimer: disable pm runtime on remove
>
> arch/arm/plat-omap/dmtimer.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> --
> 2.3.2
>
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] Couple of dmtimer fixes
Date: Tue, 17 Mar 2015 10:45:29 -0700 [thread overview]
Message-ID: <20150317174529.GG31346@atomide.com> (raw)
In-Reply-To: <1426554843-42641-1-git-send-email-s-anna@ti.com>
* Suman Anna <s-anna@ti.com> [150316 18:14]:
> Hi Tony,
>
> Please find couple of non-urgent fixes to the OMAP dmtimer driver.
> The patches are based on 4.0-rc1.
>
> The first patch is a fix for the issue I reported earlier on the
> DRA7 dmtimer hwmod patches [1]. DRA7 has timers 13 through 16 disabled
> in DT currently, and enabling any of them would cause a kernel hang.
> This fix properly checks the pm_runtime_get_sync() calls in the OMAP
> dmtimer driver irrespective of whether the hwmods are added or not.
> In the case that they are not added, the runtime_pm calls should return
> the value as returned from _od_fail_runtime_resume(), and the probe
> should bail out properly fixing the boot hang.
>
> Second patch is a minor fix that balances the pm_runtime_enable() call
> in probe with pm_runtime_disable() call in remove, so that the devices
> can be bound again properly after doing an unbind through sysfs.
OK thanks applying both into omap-for-v4.0/fixes.
Tony
> [1] http://marc.info/?l=linux-omap&m=142653933112526&w=2
>
> Suman Anna (2):
> ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure
> ARM: OMAP: dmtimer: disable pm runtime on remove
>
> arch/arm/plat-omap/dmtimer.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> --
> 2.3.2
>
next prev parent reply other threads:[~2015-03-17 17:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 1:14 [PATCH 0/2] Couple of dmtimer fixes Suman Anna
2015-03-17 1:14 ` Suman Anna
2015-03-17 1:14 ` [PATCH 1/2] ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure Suman Anna
2015-03-17 1:14 ` Suman Anna
2015-03-17 1:14 ` [PATCH 2/2] ARM: OMAP: dmtimer: disable pm runtime on remove Suman Anna
2015-03-17 1:14 ` Suman Anna
2015-03-17 17:45 ` Tony Lindgren [this message]
2015-03-17 17:45 ` [PATCH 0/2] Couple of dmtimer fixes Tony Lindgren
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=20150317174529.GG31346@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=s-anna@ti.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.