diff mbox series

soundwire: fix pm_runtime_get_sync return code checks

Message ID 20190405072655.25995-1-jank@cadence.com (mailing list archive)
State New, archived
Headers show
Series soundwire: fix pm_runtime_get_sync return code checks | expand

Commit Message

Jan Kotas April 5, 2019, 7:26 a.m. UTC
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(-)

Comments

Pierre-Louis Bossart April 5, 2019, 3:04 p.m. UTC | #1
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
Jan Kotas April 8, 2019, 7:12 a.m. UTC | #2
> 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
Pierre-Louis Bossart April 8, 2019, 5:43 p.m. UTC | #3
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...
Jan Kotas April 12, 2019, 8:29 a.m. UTC | #4
On 8 Apr 2019, at 19:43, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com<mailto: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.com<mailto: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.org_pipermail_linux-2Dpm_2011-2DJune_031930.html&d=DwICaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=g7GAQENVXx_RQdyXHInPMg&m=b7F0tj3iL_iqMB1g24oSHfiZEXr_vcDI2gftqq5H2Mg&s=cSeJz3M34TGYdAbUvh0Crqkw7INgGc8Z2uaIStHArQY&e=

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
Vinod Koul April 14, 2019, 10:26 a.m. UTC | #5
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...
diff mbox series

Patch

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);