On Sat, May 02, 2020 at 12:09:13PM +0200, Takashi Iwai wrote:
> On Sat, 02 May 2020 09:27:31 +0200,
> Takashi Iwai wrote:
> >
> > On Sat, 02 May 2020 09:17:28 +0200,
> > Lukas Wunner wrote:
> > >
> > > On Sat, May 02, 2020 at 09:11:58AM +0200, Takashi Iwai wrote:
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > @@ -673,6 +673,12 @@ static int amdgpu_dm_audio_component_bind(struct device *kdev,
> > > > struct amdgpu_device *adev = dev->dev_private;
> > > > struct drm_audio_component *acomp = data;
> > > >
> > > > + if (!device_link_add(hda_kdev, kdev, DL_FLAG_STATELESS |
> > > > + DL_FLAG_PM_RUNTIME)) {
> > > > + DRM_ERROR("DM: cannot add device link to audio device\n");
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > >
> > > Doesn't this duplicate drivers/pci/quirks.c:quirk_gpu_hda() ?
> >
> > Gah, you're right, that was the place I overlooked.
> > It was a typical "false Eureka right-after-wakeup" phenomenon :)
> > Need a vaccine aka coffee...
> >
> > So the runtime PM dependency must be already placed there, and the
> > problem is not the lack of the dependency tree but the really other
> > timing issue. Back to square.
>
> One interesting test is to open the stream while the mode isn't set
> yet and see whether the same problem appears.
> Namely, after the monitor is connected but no mode is set, run
> directly like
> aplay -Dhdmi:1,0 foo.wav
> You might need to wrap the command with pasuspender if PA is active.
I could not figure out how to get the interface for aplay set other than
not specifying it and having it find the default device (which can
change). I even used aplay -L and aplay -l to show devices. I could not
get it working.
Is there anything else I can try? I did not apply the last patch when it
was pointed out that it is already a quirk.
Regards,
Nicholas
>
>
> Takashi
