From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: sof/hda rework to share more of patch_hdmi.c logic Date: Thu, 15 Aug 2019 16:39:11 +0200 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0BA03F8011F for ; Thu, 15 Aug 2019 16:39:12 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Kai Vehmanen Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Thu, 15 Aug 2019 16:28:02 +0200, Kai Vehmanen wrote: > > Hi Takashi, > > I notice you are doing a lot of cleanups to HDA code. Just FYI I'm looking > into modifying the SOF Intel backend to use > snd-hda-codec-hdmi/patch_hdmi.c for HDMI/DP audio support, i.e. to be able > to share this code between snd-hda-intel and SOF Intel (and not using > hdac-hdmi). > > Let me know if this clashes with something you are already looking into. I > have a very rough version up and running, but it still needs some work. If > the general idea seems ok to you, I'll continue to work on a RFC patch and > send for review. That sounds like a good idea. Currently I've almost done for HD-audio rework for 5.4, so feel free to go ahead. > This will change how HDMI is exposed to user-space with SOF Intel drivers, > so we need to be extra careful how this is introduced. But this really > seems to be the best way to go to avoid the duplicated maintenance work > with two drivers that we now have. Agreed. I guess the biggest difference is the handling of the DP-MST. The legacy HD-audio HDMI driver takes a different approach for DP-MST, namely, it chooses dynamically the pin that is connected with a monitor. It's for keeping the compatibility (more or less) with old behavior; the program just needs to open the device that corresponds to the notification via jack ctl without fiddling with other extra routing. > PS Tracked in SOF github as > https://github.com/thesofproject/linux/issues/1123 OK, will watch out. thanks, Takashi