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@xxxxxxxxxxxxxxx wrote: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
