[alsa-devel] [PATCH] soundwire: fix pm_runtime_get_sync return code checks
When PM is disabled it returns -EACCES, which is currently threated as an error, and prevents accessing the slave's registers.
This patch ignores the -EACCES return value from pm_runtime_get_sync() to let the SoundWire work in systems without runtime PM.
Signed-off-by: Jan Kotas jank@cadence.com --- drivers/soundwire/bus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 1cbfedfc2..6567ff439 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -328,7 +328,7 @@ int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val) return ret;
ret = pm_runtime_get_sync(slave->bus->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return ret;
ret = sdw_transfer(slave->bus, &msg); @@ -356,7 +356,7 @@ int sdw_nwrite(struct sdw_slave *slave, u32 addr, size_t count, u8 *val) return ret;
ret = pm_runtime_get_sync(slave->bus->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return ret;
ret = sdw_transfer(slave->bus, &msg);
On 4/5/19 2:26 AM, Jan Kotas wrote:
When PM is disabled it returns -EACCES, which is currently threated as an error, and prevents accessing the slave's registers.
This patch ignores the -EACCES return value from pm_runtime_get_sync() to let the SoundWire work in systems without runtime PM.
Signed-off-by: Jan Kotas jank@cadence.com
drivers/soundwire/bus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 1cbfedfc2..6567ff439 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -328,7 +328,7 @@ int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val) return ret;
ret = pm_runtime_get_sync(slave->bus->dev);
- if (ret < 0)
- if (ret < 0 && ret != -EACCES)
There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an alternate solution for exactly the same code.
+ if (pm_runtime_enabled(slave->bus->dev)) { + ret = pm_runtime_get_sync(slave->bus->dev); + if (ret < 0) + return ret;
I am far from an expert on pm_runtime but Srinivas' solution looks more elegant to me. -Pierre
On 5 Apr 2019, at 17:04, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 4/5/19 2:26 AM, Jan Kotas wrote:
ret = pm_runtime_get_sync(slave->bus->dev);
- if (ret < 0)
- if (ret < 0 && ret != -EACCES)
There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an alternate solution for exactly the same code.
- if (pm_runtime_enabled(slave->bus->dev)) {
ret = pm_runtime_get_sync(slave->bus->dev);if (ret < 0)return ret;I am far from an expert on pm_runtime but Srinivas' solution looks more elegant to me.
Hello Pierre,
Please take a look at this patch, that was my inspiration: https://lists.linuxfoundation.org/pipermail/linux-pm/2011-June/031930.html
I also took a look, and it seems the value returned by pm_runtime_get_syncis simply ignored in a lot of places, so checking its value may be excessive.
Regards, Jan
On 4/8/19 2:12 AM, Jan Kotas wrote:
On 5 Apr 2019, at 17:04, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 4/5/19 2:26 AM, Jan Kotas wrote:
ret = pm_runtime_get_sync(slave->bus->dev);
- if (ret < 0)
- if (ret < 0 && ret != -EACCES)
There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an alternate solution for exactly the same code.
- if (pm_runtime_enabled(slave->bus->dev)) {
ret = pm_runtime_get_sync(slave->bus->dev);if (ret < 0)return ret;I am far from an expert on pm_runtime but Srinivas' solution looks more elegant to me.
Hello Pierre,
Please take a look at this patch, that was my inspiration: https://lists.linuxfoundation.org/pipermail/linux-pm/2011-June/031930.html
The two patches seems to be identical:
static inline bool pm_runtime_enabled(struct device *dev) { return !dev->power.disable_depth; }
static int rpm_resume() [...] else if (dev->power.disable_depth > 0) retval = -EACCES;
However I am still not clear on why this might fail.
I can only think of one possible explanation: there is no explicit pm_runtime_enable() in the soundwire code, so maybe the expectation is that the pm_runtime status is inherited from the parent (in the intel case the PCI driver), and that's missing in non-intel configurations?
I also took a look, and it seems the value returned by pm_runtime_get_syncis simply ignored in a lot of places, so checking its value may be excessive.
But not checking seems careless at best...
On 8 Apr 2019, at 19:43, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.commailto:pierre-louis.bossart@linux.intel.com> wrote:
On 4/8/19 2:12 AM, Jan Kotas wrote: On 5 Apr 2019, at 17:04, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.commailto:pierre-louis.bossart@linux.intel.com> wrote:
On 4/5/19 2:26 AM, Jan Kotas wrote:
ret = pm_runtime_get_sync(slave->bus->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES)
There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an alternate solution for exactly the same code.
+ if (pm_runtime_enabled(slave->bus->dev)) { + ret = pm_runtime_get_sync(slave->bus->dev); + if (ret < 0) + return ret;
I am far from an expert on pm_runtime but Srinivas' solution looks more elegant to me. Hello Pierre, Please take a look at this patch, that was my inspiration: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linuxfoundation.o...
The two patches seems to be identical:
static inline bool pm_runtime_enabled(struct device *dev) { return !dev->power.disable_depth; }
static int rpm_resume() [...] else if (dev->power.disable_depth > 0) retval = -EACCES;
However I am still not clear on why this might fail.
I can only think of one possible explanation: there is no explicit pm_runtime_enable() in the soundwire code, so maybe the expectation is that the pm_runtime status is inherited from the parent (in the intel case the PCI driver), and that's missing in non-intel configurations?
The PM implementation for soundwire seems to be incomplete. I think it relies on either PCIe or some other Intel-specific code. There are just a few pm_ function calls in the entire drivers/soundwire directory. I’m testing SoundWire as a platform, with an arm64 CPU, and it doesn’t seem to be working in its current form.
I also took a look, and it seems the value returned by pm_runtime_get_syncis simply ignored in a lot of places, so checking its value may be excessive. But not checking seems careless at best… I’m not an expert on pm, just looked in the sources. It may be best to consult it with the pm maintainers.
Jan
On 08-04-19, 12:43, Pierre-Louis Bossart wrote:
On 4/8/19 2:12 AM, Jan Kotas wrote:
On 5 Apr 2019, at 17:04, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 4/5/19 2:26 AM, Jan Kotas wrote:
ret = pm_runtime_get_sync(slave->bus->dev);
- if (ret < 0)
- if (ret < 0 && ret != -EACCES)
There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an alternate solution for exactly the same code.
- if (pm_runtime_enabled(slave->bus->dev)) {
ret = pm_runtime_get_sync(slave->bus->dev);if (ret < 0)return ret;I am far from an expert on pm_runtime but Srinivas' solution looks more elegant to me.
Hello Pierre,
Please take a look at this patch, that was my inspiration: https://lists.linuxfoundation.org/pipermail/linux-pm/2011-June/031930.html
The two patches seems to be identical:
static inline bool pm_runtime_enabled(struct device *dev) { return !dev->power.disable_depth; }
static int rpm_resume() [...] else if (dev->power.disable_depth > 0) retval = -EACCES;
However I am still not clear on why this might fail.
I can only think of one possible explanation: there is no explicit pm_runtime_enable() in the soundwire code, so maybe the expectation is that the pm_runtime status is inherited from the parent (in the intel case the PCI driver), and that's missing in non-intel configurations?
IIRC that needs to be called by the Intel driver and those patches were not upstreamed. So we dont have fully supported PM on upstream yet!
I also took a look, and it seems the value returned by pm_runtime_get_syncis simply ignored in a lot of places, so checking its value may be excessive.
But not checking seems careless at best...
participants (3)
-
Jan Kotas -
Pierre-Louis Bossart -
Vinod Koul