On Wed, 26 Apr 2017 15:49:06 +0200, Ville Syrjälä wrote:
On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
On Wed, 26 Apr 2017 09:04:46 +0200, Takashi Iwai wrote:
On Wed, 26 Apr 2017 03:58:57 +0200, Pierre-Louis Bossart wrote:
On 04/25/2017 03:27 PM, ville.syrjala@linux.intel.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
Now that everything is in place let's register a PCM device for each pipe of the display engine. This will make it possible to actually output audio to multiple displays at the same time. And it avoids modesets on unrelated displays from clobbering up the ELD and whatnot for the display currently doing the playback.
The alternative would be to have a PCM device per port, but per-pipe is easier since the hardware actually works that way.
Very nice. I just tested on a CHT Zotac box which has two connectors (1 HDMI and 1 DP), and I get sound concurrently on both, with hdmi being listed as device 2 and DP as device 0. I thought there were hardware restrictions but you proved me wrong. Kudos.
The only point that I find weird is that the jacks are reported as 'on' on the 3 pipes, is there a way to tie them to an actual cable being used?
The pdata check was changed to check port=-1 as the monitor off in the patch 6. Maybe the initialization is missing?
I guess the problem is that the hotplug wq is called at the initialization to retrieve the pdata for all pipes. It's called with uninitialized port=0, so all flags are on at init.
Indeed. That will need to be fixed.
And it implies the potential problem: the pdata contains the information only for a single pipe. Maybe it should keep the status/ELD for all three pipes.
I already did that.
Oh then it' fine, I just didn't find it.
That being said, the entire notify vs. wq is pretty racy. So I was thinking that maybe we could just eliminate the wq and do whatever is needed directly from the notify hook. And then we could eliminate the (ab)use of pdata to transfer the ELD and whatnot between the drivers. I guess the main complication is the driver load case. I didn't really think that one through so far.
One way would be to implement the get_eld() to call at the probe time. HD-audio calls such one (provided via component) at probe and resume time to sync with the actual h/w state. For LPE audio, it's even easier, as we may call i915 exported function directly.
thanks,
Takashi