Re: [PATCH] ASoC: wm8962: Do not access WM8962_GPIO_BASE

From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: shengjiu.wang@nxp.com, broonie@kernel.org,
	alsa-devel@alsa-project.org, kuninori.morimoto.gx@renesas.com
Subject: Re: [PATCH] ASoC: wm8962: Do not access WM8962_GPIO_BASE
Date: Thu, 23 Jul 2020 09:21:40 +0000	[thread overview]
Message-ID: <20200723092140.GB10899@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <20200717135959.19212-1-festevam@gmail.com>

On Fri, Jul 17, 2020 at 10:59:59AM -0300, Fabio Estevam wrote:
> According to the WM8962 datasheet, there is no register at address 0x200.
> 
> WM8962_GPIO_BASE is just a base address for the GPIO registers and not a
> real register, so remove it from wm8962_readable_register().
> 
> Also, Register 515 (WM8962_GPIO_BASE + 3) does not exist, so skip
> its access.
> 
> This fixes the following errors:
> 
> wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16
> wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16
> 

Ah ok I think I can see what is going on here, you get an EBUSY
if the regmap is in cache only and you try to read a register
which isn't in the cache. Is that what you are seeing?

> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
> Hi,
> 
> There is still one more soc_component_read_no_lock error left on register 48.
> 
> I can get rid of it with the below change:
> 
> --- a/sound/soc/codecs/wm8962.c
> +++ b/sound/soc/codecs/wm8962.c
> @@ -151,6 +151,7 @@ static const struct reg_default wm8962_reg[] = {
>  	{ 40, 0x0000 },   /* R40    - SPKOUTL volume */
>  	{ 41, 0x0000 },   /* R41    - SPKOUTR volume */
>  
> +	{ 48, 0x0000 },   /* R48    - Additional control(4) */
>  	{ 49, 0x0010 },   /* R49    - Class D Control 1 */
>  	{ 51, 0x0003 },   /* R51    - Class D Control 2 */
>  
> @@ -841,7 +842,6 @@ static bool wm8962_readable_register(struct device *dev, unsigned int reg)
>  	case WM8962_SPKOUTL_VOLUME:
>  	case WM8962_SPKOUTR_VOLUME:
>  	case WM8962_THERMAL_SHUTDOWN_STATUS:
> -	case WM8962_ADDITIONAL_CONTROL_4:
>  	case WM8962_CLASS_D_CONTROL_1:
>  	case WM8962_CLASS_D_CONTROL_2:
>  	case WM8962_CLOCKING_4:
> 
> I haven't submitted it yet because I don't know if this is the correct
> approach.

Yeah this one doesn't look like the right fix to me. Is this also
a cache issue? Since this register is volatile.

I suspect for all of these it would be edifying to know which
reads happen to these registers whilst the cache is set to
cache only.

Thanks,
Charles