[v2,0/6] ALSA: hda: Unify codec construction

Message

Cezary Rojewski Aug. 15, 2022, 5:42 p.m. UTC

A follow up to the recent HDAudio fixes series [1]. Given the recently
reported regression [2], before the page fault occurring on codec
shutdown can be fixed, codec construction procedure needs to be updated
for skylake and sof-intel drivers. Drivers: pci-hda and avs need no
changes - already making use of snd_hda_codec_device_init().

As subject touches code used by the sof-driver, additional review has
been conducted on thesofproject/linux [3].

Changes in v2:

- dropped snd_hda_ext_core <-> snd_hda_codec dependency by calling
  snd_hda_codec_device_init() directly in skylake and sof drivers probe
  enumeration routines, as suggested by Takashi
- skylake/sof portion of the change has been split into two separate
  patches

- new functions that aim to replace hdac_ext codec init & exit
  functionality are added first - for skylake and sof drivers both
- third patch in the series now combines the "field -> pointer" change
  for hdac_hda_priv->codec plus the codec-enumeration adjustments for
  skylake and sof drivers
  Both above are here to keep git bisect happy, as suggested by Pierre

[1]: https://lore.kernel.org/alsa-devel/[e-mail]/
[2]: https://lore.kernel.org/alsa-devel/[e-mail]/
[3]: https://github.com/thesofproject/linux/pull/3775

Cezary Rojewski (6):
  ASoC: Intel: Skylake: Introduce HDA codec init and exit routines
  ASoC: SOF: Intel: Introduce HDA codec init and exit routines
  ASoC: Intel: Drop hdac_ext usage for codec device creation
  ALSA: hda: Always free codec on the device release
  ALSA: hda: Remove codec init and exit routines
  ALSA: hda: Fix page fault in snd_hda_codec_shutdown()

 include/sound/hda_codec.h                    |  2 -
 include/sound/hdaudio_ext.h                  |  3 --
 sound/hda/ext/hdac_ext_bus.c                 | 53 -------------------
 sound/pci/hda/hda_codec.c                    | 49 ++++++++---------
 sound/soc/codecs/hdac_hda.c                  | 26 ++++-----
 sound/soc/codecs/hdac_hda.h                  |  2 +-
 sound/soc/intel/boards/hda_dsp_common.c      |  2 +-
 sound/soc/intel/boards/skl_hda_dsp_generic.c |  2 +-
 sound/soc/intel/skylake/skl.c                | 53 ++++++++++++++-----
 sound/soc/sof/intel/hda-codec.c              | 55 ++++++++++++++------
 10 files changed, 113 insertions(+), 134 deletions(-)

Comments

Mark Brown Aug. 15, 2022, 10:15 p.m. UTC | #1

On Mon, Aug 15, 2022 at 07:42:24PM +0200, Cezary Rojewski wrote:
> To make snd_hda_codec_device_init() the only constructor for struct
> hda_codec instances remaining tasks are:

Acked-by: Mark Brown <[e-mail]>

Cezary Rojewski Aug. 16, 2022, 8:15 a.m. UTC | #2

On 2022-08-15 7:42 PM, Cezary Rojewski wrote:
> A follow up to the recent HDAudio fixes series [1]. Given the recently
> reported regression [2], before the page fault occurring on codec
> shutdown can be fixed, codec construction procedure needs to be updated
> for skylake and sof-intel drivers. Drivers: pci-hda and avs need no
> changes - already making use of snd_hda_codec_device_init().

...

> Cezary Rojewski (6):
>    ASoC: Intel: Skylake: Introduce HDA codec init and exit routines
>    ASoC: SOF: Intel: Introduce HDA codec init and exit routines
>    ASoC: Intel: Drop hdac_ext usage for codec device creation
>    ALSA: hda: Always free codec on the device release
>    ALSA: hda: Remove codec init and exit routines
>    ALSA: hda: Fix page fault in snd_hda_codec_shutdown()


I've received a message yesterday that patches: 1/6, 3/6 and 6/6 were 
not delivered to recipient: [e-mail]. None else is 
listed there. lore.kernel.org also shows only four letters (3 + 
cover-letter) rather than seven. Given Mark's Ack on patch 3/6 it makes 
me believe that indeed just the alsa-devel did not received some of the 
messages.

What should I do in such situation? Is the server admin about to 
"recover them from the void" or should I resend the entire series as: 
"[RESEND PATCH v2]" as see how it goes this time?


Regards,
Czarek

Takashi Iwai Aug. 16, 2022, 9:59 a.m. UTC | #3

On Tue, 16 Aug 2022 10:15:44 +0200,
Cezary Rojewski wrote:
> 
> On 2022-08-15 7:42 PM, Cezary Rojewski wrote:
> > A follow up to the recent HDAudio fixes series [1]. Given the recently
> > reported regression [2], before the page fault occurring on codec
> > shutdown can be fixed, codec construction procedure needs to be updated
> > for skylake and sof-intel drivers. Drivers: pci-hda and avs need no
> > changes - already making use of snd_hda_codec_device_init().
> 
> ...
> 
> > Cezary Rojewski (6):
> >    ASoC: Intel: Skylake: Introduce HDA codec init and exit routines
> >    ASoC: SOF: Intel: Introduce HDA codec init and exit routines
> >    ASoC: Intel: Drop hdac_ext usage for codec device creation
> >    ALSA: hda: Always free codec on the device release
> >    ALSA: hda: Remove codec init and exit routines
> >    ALSA: hda: Fix page fault in snd_hda_codec_shutdown()
> 
> 
> I've received a message yesterday that patches: 1/6, 3/6 and 6/6 were
> not delivered to recipient: [e-mail]. None else is
> listed there. lore.kernel.org also shows only four letters (3 +
> cover-letter) rather than seven. Given Mark's Ack on patch 3/6 it
> makes me believe that indeed just the alsa-devel did not received some
> of the messages.
> 
> What should I do in such situation? Is the server admin about to
> "recover them from the void" or should I resend the entire series as:
> "[RESEND PATCH v2]" as see how it goes this time?

I guess the full resubmission would be better.


Takashi

Cezary Rojewski Aug. 16, 2022, 10:08 a.m. UTC | #4

On 2022-08-16 11:59 AM, Takashi Iwai wrote:
> On Tue, 16 Aug 2022 10:15:44 +0200,
> Cezary Rojewski wrote:

...

>>> Cezary Rojewski (6):
>>>     ASoC: Intel: Skylake: Introduce HDA codec init and exit routines
>>>     ASoC: SOF: Intel: Introduce HDA codec init and exit routines
>>>     ASoC: Intel: Drop hdac_ext usage for codec device creation
>>>     ALSA: hda: Always free codec on the device release
>>>     ALSA: hda: Remove codec init and exit routines
>>>     ALSA: hda: Fix page fault in snd_hda_codec_shutdown()
>>
>>
>> I've received a message yesterday that patches: 1/6, 3/6 and 6/6 were
>> not delivered to recipient: [e-mail]. None else is
>> listed there. lore.kernel.org also shows only four letters (3 +
>> cover-letter) rather than seven. Given Mark's Ack on patch 3/6 it
>> makes me believe that indeed just the alsa-devel did not received some
>> of the messages.
>>
>> What should I do in such situation? Is the server admin about to

Meant to say 'able' instead of 'about'.

>> "recover them from the void" or should I resend the entire series as:
>> "[RESEND PATCH v2]" as see how it goes this time?
> 
> I guess the full resubmission would be better.


Should I apply Mark's ACKs for patches 2/6 and 3/6 in the 
about-to-be-resent series?

Mark Brown Aug. 16, 2022, 10:30 a.m. UTC | #5

On Tue, Aug 16, 2022 at 12:08:12PM +0200, Cezary Rojewski wrote:
> On 2022-08-16 11:59 AM, Takashi Iwai wrote:

> > > "recover them from the void" or should I resend the entire series as:
> > > "[RESEND PATCH v2]" as see how it goes this time?

> > I guess the full resubmission would be better.

Note that if you do whatever upset the server again it'll happen again.
If it was a blacklisting it does look like there's something going on
there which might be random, I've had some issues with the kernel.org
servers there that don't seem attached to the the actual sending server
as much as you'd expect.

> Should I apply Mark's ACKs for patches 2/6 and 3/6 in the about-to-be-resent
> series?

Yes, if there's tags always carry them formwards unless something
changed to invalidate them.

Takashi Iwai Aug. 16, 2022, 10:33 a.m. UTC | #6

On Tue, 16 Aug 2022 12:30:58 +0200,
Mark Brown wrote:
> 
> On Tue, Aug 16, 2022 at 12:08:12PM +0200, Cezary Rojewski wrote:
> > On 2022-08-16 11:59 AM, Takashi Iwai wrote:
> 
> > > > "recover them from the void" or should I resend the entire series as:
> > > > "[RESEND PATCH v2]" as see how it goes this time?
> 
> > > I guess the full resubmission would be better.
> 
> Note that if you do whatever upset the server again it'll happen again.

If this happens, we need to investigate.  alsa-devel ML is maintained
outside vger by Jaroslav personally.  Let's see...


Takashi

Jaroslav Kysela Aug. 16, 2022, 12:35 p.m. UTC | #7

On 16. 08. 22 12:33, Takashi Iwai wrote:
> On Tue, 16 Aug 2022 12:30:58 +0200,
> Mark Brown wrote:
>>
>> On Tue, Aug 16, 2022 at 12:08:12PM +0200, Cezary Rojewski wrote:
>>> On 2022-08-16 11:59 AM, Takashi Iwai wrote:
>>
>>>>> "recover them from the void" or should I resend the entire series as:
>>>>> "[RESEND PATCH v2]" as see how it goes this time?
>>
>>>> I guess the full resubmission would be better.
>>
>> Note that if you do whatever upset the server again it'll happen again.
> 
> If this happens, we need to investigate.  alsa-devel ML is maintained
> outside vger by Jaroslav personally.  Let's see...

It seems that it was a temporary issue with the DNS resolver. The resend is fine.

				Jaroslav