Received-SPF: pass (google.com: domain of linux-kernel+bounces-155116-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 23 Apr 2024 13:59:01 +0200
From: Johan Hovold <johan@kernel.org>
To: srinivas.kandagatla@linaro.org
Cc: broonie@kernel.org, perex@perex.cz, tiwai@suse.com, lgirdwood@gmail.com,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	Bjorn Andersson <quic_bjorande@quicinc.com>
Subject: Re: [PATCH v2 0/4] ASoC: qcom: display port changes
Message-ID: <ZieihZRKe7OtP-nV@hovoldconsulting.com>
References: <20240422134354.89291-1-srinivas.kandagatla@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240422134354.89291-1-srinivas.kandagatla@linaro.org>

On Mon, Apr 22, 2024 at 02:43:50PM +0100, Srinivas Kandagatla wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> 
> This patchset adds support for.
> 	1. parse Display Port module tokens from ASoC topology
> 	2. add support to DP/HDMI Jack events.
> 	3. fixes a typo in function name in sm8250
> 
> Verified these patches on X13s along with changes to tplg in 
> https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
> and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp

It looks like your UCM changes are still muxing the speaker and *each*
displayport output so that you can only use one device at a time (i.e.
only Speaker or DP1 or DP2 can be used).

As we discussed off list last week, this seems unnecessarily limited and
as far as I understood is mostly needed to work around some
implementation details (not sure why DP1 and DP2 can't be used in
parallel either).

Can you please describe the problem here so that we can discuss this
before merging an unnecessarily restricted solution which may later be
harder to change (e.g. as kernel, topology and ucm may again need to be
updated in lock step).

From what I could tell after a quick look, this series does not
necessarily depend on muxing things this way, but please confirm that
too.

Johan