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

[Wang, Xiaolei]

Hi Jaroslav

When I tested the audio, I found that some registers in the codec of wm8962.c will fail to read in the mainline kernel. I found that wm8962_i2c_probe will enter runtime suspend after startup, but in the following program:

snd_soc_bind_card
     snd_soc_dapm_new_widgets
         soc_dapm_read
             snd_soc_component_read(dapm->component, reg);

There is no runtime resume, which cannot perform normal reading and writing for volatile reg, because it has been switched to regcache only in the process of runtime suspend. I can't find the right place to resume, can you give me any advice?

thanks
xiaolei

Re: wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16

[Charles Keepax]

On Wed, Sep 28, 2022 at 02:44:30AM +0000, Wang, Xiaolei wrote:
> Hi Jaroslav
> 
> When I tested the audio, I found that some registers in the
> codec of wm8962.c will fail to read in the mainline kernel. I
> found that wm8962_i2c_probe will enter runtime suspend after
> startup, but in the following program:
> 
> snd_soc_bind_card
>      snd_soc_dapm_new_widgets
>          soc_dapm_read
>              snd_soc_component_read(dapm->component, reg);
> 
> There is no runtime resume, which cannot perform normal
> reading and writing for volatile reg, because it has been
> switched to regcache only in the process of runtime suspend. I
> can't find the right place to resume, can you give me any
> advice?
> 

I think the first step would be could you clarify which register
is being read here? Reading a volatile register as part of
setting up the widgets does feel rather problematic.

Thanks,
Charles

Re: wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16

[Wang, Xiaolei]

On 9/29/2022 5:24 PM, Charles Keepax wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Wed, Sep 28, 2022 at 02:44:30AM +0000, Wang, Xiaolei wrote:
>> Hi Jaroslav
>>
>> When I tested the audio, I found that some registers in the
>> codec of wm8962.c will fail to read in the mainline kernel. I
>> found that wm8962_i2c_probe will enter runtime suspend after
>> startup, but in the following program:
>>
>> snd_soc_bind_card
>>       snd_soc_dapm_new_widgets
>>           soc_dapm_read
>>               snd_soc_component_read(dapm->component, reg);
>>
>> There is no runtime resume, which cannot perform normal
>> reading and writing for volatile reg, because it has been
>> switched to regcache only in the process of runtime suspend. I
>> can't find the right place to resume, can you give me any
>> advice?
>>
> I think the first step would be could you clarify which register
> is being read here? Reading a volatile register as part of
> setting up the widgets does feel rather problematic.

Yes, this is reading the 0x30 register of the wm8962, it can adjust 
Microphone Bias Voltage.

thanks

xiaolei

>
> Thanks,
> Charles

Re: wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16

[Charles Keepax]

On Fri, Sep 30, 2022 at 12:59:24PM +0800, Wang, Xiaolei wrote:
> On 9/29/2022 5:24 PM, Charles Keepax wrote:
> >On Wed, Sep 28, 2022 at 02:44:30AM +0000, Wang, Xiaolei wrote:
> >>snd_soc_bind_card
> >>      snd_soc_dapm_new_widgets
> >>          soc_dapm_read
> >>              snd_soc_component_read(dapm->component, reg);
> >>
> >>There is no runtime resume, which cannot perform normal
> >>reading and writing for volatile reg, because it has been
> >>switched to regcache only in the process of runtime suspend. I
> >>can't find the right place to resume, can you give me any
> >>advice?
> >>
> >I think the first step would be could you clarify which register
> >is being read here? Reading a volatile register as part of
> >setting up the widgets does feel rather problematic.
> 
> Yes, this is reading the 0x30 register of the wm8962, it can adjust
> Microphone Bias Voltage.

Yes, that is some rather poor hardware design there, the chip has
a bunch of volatile status bits mixed in with a bunch of
non-volatile control bits in the same register. It would seem
the problem is likely the two widgets TEMP_HP and TEMP_SPK.

Probably the simplest solution would be to add an event handler
for TEMP_HP and TEMP_SPK and move the register handling in there,
if there is no register specified on the widgets the core will
not attempt to read it on probe and will assume the widget is
off. Although you will also need to turn them off during probe as
they do default to on.

Is that something you are comfortable writing a patch for or do
you want me to have a look at pulling one together for you?
Although note this might take a few days and I don't have hardware
to test it here.

Thanks,
Charles

Re: wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16

[Adam Ford]

On Mon, Oct 3, 2022 at 5:41 AM Charles Keepax
<ckeepax@opensource.cirrus.com> wrote:
>
> On Fri, Sep 30, 2022 at 12:59:24PM +0800, Wang, Xiaolei wrote:
> > On 9/29/2022 5:24 PM, Charles Keepax wrote:
> > >On Wed, Sep 28, 2022 at 02:44:30AM +0000, Wang, Xiaolei wrote:
> > >>snd_soc_bind_card
> > >>      snd_soc_dapm_new_widgets
> > >>          soc_dapm_read
> > >>              snd_soc_component_read(dapm->component, reg);
> > >>
> > >>There is no runtime resume, which cannot perform normal
> > >>reading and writing for volatile reg, because it has been
> > >>switched to regcache only in the process of runtime suspend. I
> > >>can't find the right place to resume, can you give me any
> > >>advice?
> > >>
> > >I think the first step would be could you clarify which register
> > >is being read here? Reading a volatile register as part of
> > >setting up the widgets does feel rather problematic.
> >
> > Yes, this is reading the 0x30 register of the wm8962, it can adjust
> > Microphone Bias Voltage.
>
> Yes, that is some rather poor hardware design there, the chip has
> a bunch of volatile status bits mixed in with a bunch of
> non-volatile control bits in the same register. It would seem
> the problem is likely the two widgets TEMP_HP and TEMP_SPK.
>
> Probably the simplest solution would be to add an event handler
> for TEMP_HP and TEMP_SPK and move the register handling in there,
> if there is no register specified on the widgets the core will
> not attempt to read it on probe and will assume the widget is
> off. Although you will also need to turn them off during probe as
> they do default to on.
>
> Is that something you are comfortable writing a patch for or do
> you want me to have a look at pulling one together for you?
> Although note this might take a few days and I don't have hardware
> to test it here.

I can test it if someone wants to copy me on the patch.  I see the
same splat, but it doesn't appear to impact the performance in my
application.

adam
>
> Thanks,
> Charles