On Monday 23 April 2018 16:04:55 Kai Heng Feng wrote: > > > > On Apr 20, 2018, at 8:10 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > On Fri, 20 Apr 2018 11:44:32 +0200, > > Kai-Heng Feng wrote: > > > Now it's a typical discrete-only system. HDMI audio comes from AMD audio > > > controller, others from Intel audio controller. > > > > > > When SG is enabled, the unused AMD audio contoller still exposes its > > > sysfs, so userspace still opens the control file and stream. If > > > userspace tries to output sound through the stream, it hangs the system. > > > > Hm, could you give more information about how it hangs? > > Well, I should say "it hangs the userspace process" instead. > > $ speaker-test -t wav -c 2 -D hw:CARD=HDMI,DEV=3 > ...and it just stopped. Can't Ctrl+C to break it. So userspace process cannot be killed at all? Then it is different bug in kernel and disabling pci device is just a workaround. Not a real fix. I would propose to find out what happen and why it cannot be killed (probably it stuck somewhere in kernel) and fix it properly. > > > > > > > @@ -1627,6 +1629,42 @@ static void check_msi(struct azx *chip) > > > } > > > } > > > > > > +#if IS_ENABLED(CONFIG_DELL_LAPTOP) > > > > This should be IS_REACHABLE(), as both dell-laptop and HD-audio are > > tristate. > > Thanks, will update in next version. > > > > > > +static bool check_dell_switchable_gfx(struct pci_dev *pdev) > > > > I'd remove "_dell" word here. Such a check would be likely needed for > > other vendors, and it's quite possible that the function will be > > extended to cover a wider DMI table. > > Makes sense. Will also update this one. > > Kai-Heng > > > > > > > thanks, > > > > Takashi -- Pali Rohár pali.rohar@xxxxxxxxx
