Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote: > On Wed, 26 Apr 2017 15:38:53 +0200, > Ville Syrjälä wrote: > > > > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote: > > > On Tue, 25 Apr 2017 22:27:19 +0200, > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > From: Ville Syrjälä > > > > > > > > I was wondering why my VLV no longer runtime suspended, and after some > > > > thinking I decided it had to be the LPE audio preventing it. Turns out > > > > I was right, so here's my attempt at fixing it. > > > > > > > > And while looking at the code I couldn't help but notice that it > > > > couldn't actually handle multiple pipes playing back audio at the > > > > same time. And even having multiple displays active even if only > > > > one was playing audio was probably a recipe for failure. So I > > > > tried to fix that by registering a separate PCM device for each > > > > pipe. > > > > > > > > Note that the patch subjects may not reflect the subsystem > > > > very well since most of these straddle the border between drm > > > > and alsa. I think I just slapped on drm/i915 to most where > > > > there was no clear winner. > > > > > > A nice patchset, thanks for working on it! > > > > > > One slight concern (other than the jack issue Pierre reported) is the > > > incompatible behavior from the current version. With the pipe-based > > > multiple streams, user would need to choose another one even if the > > > device has a single HDMI output, which is pretty common on BYT/CHV > > > tablets. > > > > > > Maybe it's no big problem as the users are still limited at the > > > moment. Or, we may need to handle a bit differently, e.g. assigning > > > the PCM stream dynamically per hotplug. > > > > Yeah, I tied the PCM device to the pipe to match the hardware. But we > > could certainly register the PCM device per port, and then do a > > pipe<->port mapping somewhere to make it all work out. One slight > > complication is that not all ports are necessarily present so we > > might have eg. just port B and port D, but no port C. Not sure if > > it would be a bad thing to register a PCM device even for the > > missing ports anyway? > > > > I don't recall which way HDA works. Device per port I guess? Well, > > for DP SST/HDMI. But for DP MST I presume it's device per stream > > (ie. pipe) even with HDA. > > HD-audio creates the PCM device per HD-audio widget representation, > and they correspond to ports, as it seems. For MST, the situation is > more complex, and we assign the PCM stream dynamically. It's for > keeping the behavior (more or less) consistent with non-MST. OK, I hacked together something that seems to work. I'll still need to squash it with the earlier patch, but in case you want to see what the relative changes look like I pushed it to git://github.com/vsyrjala/linux.git lpe_audio_multipipe -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote: > On Wed, 26 Apr 2017 15:38:53 +0200, > Ville Syrjälä wrote: > > > > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote: > > > On Tue, 25 Apr 2017 22:27:19 +0200, > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > From: Ville Syrjälä > > > > > > > > I was wondering why my VLV no longer runtime suspended, and after some > > > > thinking I decided it had to be the LPE audio preventing it. Turns out > > > > I was right, so here's my attempt at fixing it. > > > > > > > > And while looking at the code I couldn't help but notice that it > > > > couldn't actually handle multiple pipes playing back audio at the > > > > same time. And even having multiple displays active even if only > > > > one was playing audio was probably a recipe for failure. So I > > > > tried to fix that by registering a separate PCM device for each > > > > pipe. > > > > > > > > Note that the patch subjects may not reflect the subsystem > > > > very well since most of these straddle the border between drm > > > > and alsa. I think I just slapped on drm/i915 to most where > > > > there was no clear winner. > > > > > > A nice patchset, thanks for working on it! > > > > > > One slight concern (other than the jack issue Pierre reported) is the > > > incompatible behavior from the current version. With the pipe-based > > > multiple streams, user would need to choose another one even if the > > > device has a single HDMI output, which is pretty common on BYT/CHV > > > tablets. > > > > > > Maybe it's no big problem as the users are still limited at the > > > moment. Or, we may need to handle a bit differently, e.g. assigning > > > the PCM stream dynamically per hotplug. > > > > Yeah, I tied the PCM device to the pipe to match the hardware. But we > > could certainly register the PCM device per port, and then do a > > pipe<->port mapping somewhere to make it all work out. One slight > > complication is that not all ports are necessarily present so we > > might have eg. just port B and port D, but no port C. Not sure if > > it would be a bad thing to register a PCM device even for the > > missing ports anyway? > > > > I don't recall which way HDA works. Device per port I guess? Well, > > for DP SST/HDMI. But for DP MST I presume it's device per stream > > (ie. pipe) even with HDA. > > HD-audio creates the PCM device per HD-audio widget representation, > and they correspond to ports, as it seems. With the slight exception of old stuff like ctg/elk where there is just one audio device IIRC, and that one gets fed into whichever port enables audio, and if both enable it it goes to /dev/null. > For MST, the situation is > more complex, and we assign the PCM stream dynamically. It's for > keeping the behavior (more or less) consistent with non-MST. > > > > In anyway, with the support of multi streams, alsa-lib config needs to > > > be updated. > > > > Hmm. I suppose I'll have to take a gander at what's there. > > The HDMI PCM definition itself is easy, just just adding more (hdmi.1, > hdmi.2, etc). The difficult part would be the front and the default > PCM definition, and I have no good idea about it, so far. > > > Takashi -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
On Wed, 26 Apr 2017 15:38:53 +0200, Ville Syrjälä wrote: > > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote: > > On Tue, 25 Apr 2017 22:27:19 +0200, > > ville.syrj...@linux.intel.com wrote: > > > > > > From: Ville Syrjälä > > > > > > I was wondering why my VLV no longer runtime suspended, and after some > > > thinking I decided it had to be the LPE audio preventing it. Turns out > > > I was right, so here's my attempt at fixing it. > > > > > > And while looking at the code I couldn't help but notice that it > > > couldn't actually handle multiple pipes playing back audio at the > > > same time. And even having multiple displays active even if only > > > one was playing audio was probably a recipe for failure. So I > > > tried to fix that by registering a separate PCM device for each > > > pipe. > > > > > > Note that the patch subjects may not reflect the subsystem > > > very well since most of these straddle the border between drm > > > and alsa. I think I just slapped on drm/i915 to most where > > > there was no clear winner. > > > > A nice patchset, thanks for working on it! > > > > One slight concern (other than the jack issue Pierre reported) is the > > incompatible behavior from the current version. With the pipe-based > > multiple streams, user would need to choose another one even if the > > device has a single HDMI output, which is pretty common on BYT/CHV > > tablets. > > > > Maybe it's no big problem as the users are still limited at the > > moment. Or, we may need to handle a bit differently, e.g. assigning > > the PCM stream dynamically per hotplug. > > Yeah, I tied the PCM device to the pipe to match the hardware. But we > could certainly register the PCM device per port, and then do a > pipe<->port mapping somewhere to make it all work out. One slight > complication is that not all ports are necessarily present so we > might have eg. just port B and port D, but no port C. Not sure if > it would be a bad thing to register a PCM device even for the > missing ports anyway? > > I don't recall which way HDA works. Device per port I guess? Well, > for DP SST/HDMI. But for DP MST I presume it's device per stream > (ie. pipe) even with HDA. HD-audio creates the PCM device per HD-audio widget representation, and they correspond to ports, as it seems. For MST, the situation is more complex, and we assign the PCM stream dynamically. It's for keeping the behavior (more or less) consistent with non-MST. > > In anyway, with the support of multi streams, alsa-lib config needs to > > be updated. > > Hmm. I suppose I'll have to take a gander at what's there. The HDMI PCM definition itself is easy, just just adding more (hdmi.1, hdmi.2, etc). The difficult part would be the front and the default PCM definition, and I have no good idea about it, so far. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote: > On Tue, 25 Apr 2017 22:27:19 +0200, > ville.syrj...@linux.intel.com wrote: > > > > From: Ville Syrjälä > > > > I was wondering why my VLV no longer runtime suspended, and after some > > thinking I decided it had to be the LPE audio preventing it. Turns out > > I was right, so here's my attempt at fixing it. > > > > And while looking at the code I couldn't help but notice that it > > couldn't actually handle multiple pipes playing back audio at the > > same time. And even having multiple displays active even if only > > one was playing audio was probably a recipe for failure. So I > > tried to fix that by registering a separate PCM device for each > > pipe. > > > > Note that the patch subjects may not reflect the subsystem > > very well since most of these straddle the border between drm > > and alsa. I think I just slapped on drm/i915 to most where > > there was no clear winner. > > A nice patchset, thanks for working on it! > > One slight concern (other than the jack issue Pierre reported) is the > incompatible behavior from the current version. With the pipe-based > multiple streams, user would need to choose another one even if the > device has a single HDMI output, which is pretty common on BYT/CHV > tablets. > > Maybe it's no big problem as the users are still limited at the > moment. Or, we may need to handle a bit differently, e.g. assigning > the PCM stream dynamically per hotplug. Yeah, I tied the PCM device to the pipe to match the hardware. But we could certainly register the PCM device per port, and then do a pipe<->port mapping somewhere to make it all work out. One slight complication is that not all ports are necessarily present so we might have eg. just port B and port D, but no port C. Not sure if it would be a bad thing to register a PCM device even for the missing ports anyway? I don't recall which way HDA works. Device per port I guess? Well, for DP SST/HDMI. But for DP MST I presume it's device per stream (ie. pipe) even with HDA. > In anyway, with the support of multi streams, alsa-lib config needs to > be updated. Hmm. I suppose I'll have to take a gander at what's there. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
On Tue, 25 Apr 2017 22:27:19 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > I was wondering why my VLV no longer runtime suspended, and after some > thinking I decided it had to be the LPE audio preventing it. Turns out > I was right, so here's my attempt at fixing it. > > And while looking at the code I couldn't help but notice that it > couldn't actually handle multiple pipes playing back audio at the > same time. And even having multiple displays active even if only > one was playing audio was probably a recipe for failure. So I > tried to fix that by registering a separate PCM device for each > pipe. > > Note that the patch subjects may not reflect the subsystem > very well since most of these straddle the border between drm > and alsa. I think I just slapped on drm/i915 to most where > there was no clear winner. A nice patchset, thanks for working on it! One slight concern (other than the jack issue Pierre reported) is the incompatible behavior from the current version. With the pipe-based multiple streams, user would need to choose another one even if the device has a single HDMI output, which is pretty common on BYT/CHV tablets. Maybe it's no big problem as the users are still limited at the moment. Or, we may need to handle a bit differently, e.g. assigning the PCM stream dynamically per hotplug. In anyway, with the support of multi streams, alsa-lib config needs to be updated. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
From: Ville Syrjälä I was wondering why my VLV no longer runtime suspended, and after some thinking I decided it had to be the LPE audio preventing it. Turns out I was right, so here's my attempt at fixing it. And while looking at the code I couldn't help but notice that it couldn't actually handle multiple pipes playing back audio at the same time. And even having multiple displays active even if only one was playing audio was probably a recipe for failure. So I tried to fix that by registering a separate PCM device for each pipe. Note that the patch subjects may not reflect the subsystem very well since most of these straddle the border between drm and alsa. I think I just slapped on drm/i915 to most where there was no clear winner. Entire series available here: git://github.com/vsyrjala/linux.git lpe_audio_multipipe Cc: Takashi Iwai Cc: Pierre-Louis Bossart Ville Syrjälä (11): drm/i915: Fix runtime PM for LPE audio ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown drm/i915: Stop pretending to mask/unmask LPE audio interrupts drm/i915: Remove the unsued pending_notify from LPE platform data drm/i915: Replace tmds_clock_speed and link_rate with just ls_clock drm/i915: Remove hdmi_connected from LPE audio pdata drm/i915: Reorganize intel_lpe_audio_notify() arguments drm/i915: Clean up the LPE audio platform data ALSA: x86: Prepare LPE audio ctls for multiple PCMs ALSA: x86: Split snd_intelhad into card and PCM specific structures ALSA: x86: Register multiple PCM devices for the LPE audio card drivers/gpu/drm/i915/i915_drv.h| 4 +- drivers/gpu/drm/i915/i915_irq.c| 15 +- drivers/gpu/drm/i915/intel_audio.c | 19 +-- drivers/gpu/drm/i915/intel_lpe_audio.c | 95 --- include/drm/intel_lpe_audio.h | 20 ++- sound/x86/intel_hdmi_audio.c | 288 +++-- sound/x86/intel_hdmi_audio.h | 17 +- 7 files changed, 230 insertions(+), 228 deletions(-) -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
