[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87354pwex9.wl-tiwai@suse.de>
Date: Mon, 24 Apr 2023 16:08:50 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Reaper Li_OC <ReaperLiOC@...nfly.com>
Cc: "perex@...ex.cz" <perex@...ex.cz>,
"tiwai@...e.com" <tiwai@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Jason Tao(SH-RD)" <JasonTao@...nfly.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Subject: Re: 答复: [可能是垃圾邮件] Re: [PATCH]
ALSA: hda: Glenfly: add HD Audio PCI IDs and HDMI Codec Vendor IDs.
On Sun, 23 Apr 2023 11:15:57 +0200,
Reaper Li_OC wrote:
>
>
> Hi
>
> Thanks, I will also submit to alsa-devel ML at the next time.
>
> For the listed questions:
>
> > @@ -1743,6 +1745,8 @@ static int default_bdl_pos_adj(struct azx *chip)
> > }
> >
> > switch (chip->driver_type) {
> > + case AZX_DRIVER_GFHDMI:
> > + return 128;
>
> our chip need increase the bdl as there is limitation on hardware, once hdac
> interrupt interval is too short, the audio data may get lost.
>
> > @@ -1859,6 +1863,9 @@ static int azx_first_init(struct azx *chip)
> > }
> > #endif
> >
> > + if (chip->driver_type == AZX_DRIVER_GFHDMI)
> > + bus->polling_mode = 1;
>
> Our chip has interrupt upon the CORB/RIRB response, when the codec complete
> the command, It sends interrupt and writes response entries to memory, However
> on our hardware, the response entries sometimes are not actually synchronized
> to memory when driver handle the hdac interrupt. If the RIRB status is not
> updated in the hdac interrupt handler, azx_rirb_get_response keeps trying to
> receive a response from rirb until 1s timout before enabling polling_mode,
> some apps treat it as an error. So for our hardware, need to enable
> polling_mode to fix it.
>
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -4489,6 +4489,18 @@ static int patch_via_hdmi(struct hda_codec *codec)
> > return patch_simple_hdmi(codec, VIAHDMI_CVT_NID, VIAHDMI_PIN_NID);
> > }
> >
> > +static int patch_gf_hdmi(struct hda_codec *codec)
> > +{
> > + int err;
> > +
> > + err = patch_generic_hdmi(codec);
> > + if (err)
> > + return err;
> > +
> > + codec->no_sticky_stream = 1;
>
> On our chip, there are two codecs. when stream switch from one codec to
> another codec, our hardware need driver to do actual clean-ups in
> codec_cleanup_stream for the linked codec, otherwise it can't complete switch
> successfully.
OK, then please provide those info as comments briefly in relevant
places, as well as some details in the commit log.
thanks,
Takashi
Powered by blists - more mailing lists