lkml.org 
[lkml]   [2020]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
    On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai <tiwai@suse.de> wrote:
    >
    > On Wed, 16 Dec 2020 16:50:20 +0100,
    > Kai-Heng Feng wrote:
    > >
    > > On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai <tiwai@suse.de> wrote:
    > > >
    > > > On Wed, 16 Dec 2020 13:47:24 +0100,
    > > > Kai-Heng Feng wrote:
    > > > >
    > > > > Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller
    > > > > initialization even if no codecs found"), when codec probe fails, it
    > > > > doesn't enable runtime suspend, and can prevent graphics card from
    > > > > getting powered down:
    > > > > [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
    > > > >
    > > > > $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status
    > > > > active
    > > > >
    > > > > So mark there's no codec and continue probing to let runtime PM to work.
    > > > >
    > > > > BugLink: https://bugs.launchpad.net/bugs/1907212
    > > > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    > > >
    > > > Hm, but if the probe fails, doesn't it mean something really wrong?
    > > > IOW, how does this situation happen?
    > >
    > > The HDA controller is forcely created by quirk_nvidia_hda(). So
    > > probably there's really not an HDA controller.
    >
    > I still don't understand how non-zero codec_mask is passed.
    > The non-zero codec_mask means that BIOS or whatever believes that
    > HD-audio codecs are present and let HD-audio controller reporting the
    > presence. What error did you get at probing?

    [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
    Full dmesg here:
    https://launchpadlibrarian.net/510351476/dmesg.log

    >
    >
    > > > The usual no-codec state is for the devices that have a bogus HD-audio
    > > > bus remaining while codecs aren't hooked or disabled by BIOS. For
    > > > that, it makes to leave the controller driver and let it idle. But if
    > > > you get really an error, it's something to fix there, not to just
    > > > ignore in general.
    > >
    > > The best approach I can think of is to make current two steps probe
    > > into one. So when probe fails, the driver won't bind to the device.
    > > What's the reason behind the two steps approach?
    >
    > It's a sort of must, as the module loading is involved with binding
    > with the codecs, as well as (optionally) request_firmware()
    > invocation.

    Ok. I also tried to use device_release_driver(), but azx_remove()
    calls "cancel_work_sync(&hda->probe_work)" so there will be a
    deadlock.

    Kai-Heng

    >
    >
    > Takashi



    --
    Kai-Heng

    \
     
     \ /
      Last update: 2020-12-16 17:10    [W:2.547 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site