From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B8465733A for ; Tue, 14 Jan 2025 09:04:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736845499; cv=none; b=SBVUtX0DqBe1TLrDxNqDa8Yzk8o30QCpbr+mCRAh4oOYith4tWNF/ibUO5X4f49eW/8D2HEYpBQcjqVSSatdHo4V8cijzvqhKrhE56T9FkqeDytzIInnQSYFkRUSJQQFI8fWjzVpfzzvjazxooVHsgdo8Jzhs2lhHy4z7bwt304= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736845499; c=relaxed/simple; bh=7KIvSIu5XPPm9lTFj8UjdCcMTW3CkOGWN34+1V85Zzg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F5rlCuM+IHaRaRzPbJ+zgko4f9ZSMSWyeO1UETFx1rhbsJdayJGjz16h5dZ6RvwwyQMWMkdqL9eFjvr2321zBVVF1ZZfl4LQOOTj3wcre9nvZ7TrufMz+R5L/DDvfVHszHDo4k1V/Ir7uetvTT6ftfEYLAEtiIaWJruMciw2DIs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TqW67rAh; arc=none smtp.client-ip=209.85.208.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TqW67rAh" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5d3cf094768so9119220a12.0 for ; Tue, 14 Jan 2025 01:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736845496; x=1737450296; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wKly9npKXBUSdy5qiIv5yFK78A+KB2EVLPMob+WSOS4=; b=TqW67rAh6J7KeXzf+lvx+yEi/xGwsgI+OnW1AhRXMKchsZ5ebD9n8aO0Orw/BZ2Q5m BSxDCxp2l5PNeAST6sk56Atn28+t0K5RPU465QWfFgAT4DZfl1KjqaSetLx19fd5TS8T Jnhd5ZBZsTIk2N9lloUAuqQfXutulBDx3fOmcc5VmxvDGQfJf7IvSyT4ZGZMYdsRTH9Q kZWDE/m5wcQ7I8BmIe3LPWvQWkImHDu3pFTv2yHl91WUO8jb6FRdcy/KGArL8M+cWh13 sqPx7W1vLBHkh632HuhEoJ4rZIiX0oD8m3e7ze4LcVNhAOe12Q6SCCNCBnnlJrvOd1jJ fw+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736845496; x=1737450296; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wKly9npKXBUSdy5qiIv5yFK78A+KB2EVLPMob+WSOS4=; b=s+cMGJyjl1IbcGzq88YGfj36mDr5S2v149/1VlI4CN5zO6cti70xiV0wh0H8sdep2b 7sevMlAz7/4xdnnCu0FOjf8XiMSZ+opSzZQMMDEDSj1Agn0vEDURbnoaqpq/HvuZfDwD UO70f5P0kVA12fRH7PcKol4yximNSP9iLiMPOBB4BfIIakHEQM8ePtg2n/EjwgJ237Ek qJjr80fyrH3w03sVyeigqVWWfGv4THhGmTVKjwApl/06t362nK+L+G3IAq6OjVvwp2hR vIA8DVyRcbSGWxs2vxZEnWg4J+Oz24mDsuwI9RQ7WNCv+Od5j1bHrIhetPzaOS3kvo6/ aT+A== X-Forwarded-Encrypted: i=1; AJvYcCX4NDNv3Xrv/8cLZixbZnXX5a1Hqw72rtdyJMZMTnIJRJMnrSkdpxVL55z85pDBrK9yFeRPJ47lPVXO6r0=@vger.kernel.org X-Gm-Message-State: AOJu0YxuxLaBTRJRec7WWHAEGotj7t952yifyd6WvI+F54J9tiA0EJZQ GHf5EoexkVlB9+crcyOoDTVtjpUo9ZAYtL9Q4Q0aPGOiXkftC2nA X-Gm-Gg: ASbGnculk21ZgsRd1Gt0DnTGV3WGayPy2bHbJlXJJwruEWKH4Y+ISvsfBpDQqabab6q 5QqcLhu2jF0JhLO7H8MUVmFxRbGKkhj0BvkpRKrMt8oOCvghXdv0H6jxABNJaiQ6+aKcVuLvbXr ilCNN3THuop1uasfe5rt20m45YhQveicPbh2qTwwCeoO4rsJgtU72g/lnsy4ppRwqhdERGU2DJx XVkDMo9iUushl5xwk5h14plM8LG5Sn4vz+Qh0+XKUiiHZd4Lhq+CwgBp2NOKmojk08jgQ== X-Google-Smtp-Source: AGHT+IGsoy18wLlENnC1ImY9x1dKRjyISuUw2UI30yDUuaba5fLugh7Il8pnp4l0QaSrrcFcL68orA== X-Received: by 2002:a17:907:3e9b:b0:aae:d199:6eae with SMTP id a640c23a62f3a-ab2ab6a38bbmr2049046366b.14.1736845496046; Tue, 14 Jan 2025 01:04:56 -0800 (PST) Received: from [192.168.1.10] ([95.43.220.235]) by smtp.googlemail.com with ESMTPSA id a640c23a62f3a-ab2c95b09b2sm607721766b.146.2025.01.14.01.04.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jan 2025 01:04:55 -0800 (PST) Message-ID: <98a19395-7056-48d1-ad89-fb057025f46c@gmail.com> Date: Tue, 14 Jan 2025 11:04:54 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] soc: audio-graph-card2: use correct endpoint when getting link parameters To: Kuninori Morimoto Cc: lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, tony@atomide.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org References: <20241220071126.1066691-1-ivo.g.dimitrov.75@gmail.com> <87y0zdsxme.wl-kuninori.morimoto.gx@renesas.com> Content-Language: en-GB From: Ivaylo Dimitrov In-Reply-To: <87y0zdsxme.wl-kuninori.morimoto.gx@renesas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Morimoto-san On 14.01.25 г. 8:44 ч., Kuninori Morimoto wrote: > > Hi Ivaylo > > Sorry for the late review. > And sorry for the noise on my side. >> We may have multiple links between ports, with each link >> having different parameters. Currently, no matter the topology, >> it is always port endpoint 0 that is used when setting parameters. >> >> On a complex sound system, like the one found on Motorola droid4, >> hifi and voice DAIs require differents formats (i2s vs dsp_a) >> and curently it is impossible to use DT to set that. >> >> Implementing the change leads to partially dropping of at least >> 0dedbde5062d (ASoC: cpcap: Implement set_tdm_slot for voice call >> support), as core does most of what is needed to configure voice DAI. >> >> We (on Maemo Leste ) use the patch (along with few others) to have >> voice calls working properly on d4 through UCM. >> >> The patch is for linux 6.6, I want to know whether the >> approach would be accepted before sending a proper patch for >> current master. >> >> the original commit message follows: >> >> When link parameters are parsed, it is always endpoint@0 that is used and >> parameters set to other endpoints are ignored. >> >> Fix that by using endpoint that is set in DT when parsing link parameters. >> >> Signed-off-by: Ivaylo Dimitrov >> --- > (snip) >> @@ -684,7 +683,6 @@ int audio_graph2_link_dpcm(struct asoc_simple_priv *priv, >> { >> struct device_node *ep = port_to_endpoint(lnk); >> struct device_node *rep = of_graph_get_remote_endpoint(ep); >> - struct device_node *rport = of_graph_get_remote_port(ep); >> struct snd_soc_dai_link *dai_link = simple_priv_to_link(priv, li->link); >> struct simple_dai_props *dai_props = simple_priv_to_props(priv, li->link); >> int is_cpu = asoc_graph_is_ports0(lnk); >> @@ -718,7 +716,7 @@ int audio_graph2_link_dpcm(struct asoc_simple_priv *priv, >> dai_link->dynamic = 1; >> dai_link->dpcm_merged_format = 1; >> >> - ret = graph_parse_node(priv, GRAPH_DPCM, rport, li, 1); >> + ret = graph_parse_node(priv, GRAPH_DPCM, rep, li, 1); > > Please correct me if I was misunderstanding > Is the main issue "remote" side endpoint ? > > You want to parse "remote" endpoint (= rep) directly, but the function > requests "port" (= rport), and it will use endpoint0 ( != rep). > Is this the main issue you want to fix ? > Yes, it is the 'remote' side endpoint, currently it is always remote endpoint0 that is used, because when you get 'port', it is endpoint0 of that port that core uses. See: https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi#L91 https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-mapphone-handset.dtsi#L65 and https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi#L476 as an example DTS that is using multiple endpoints per port and also https://lkml.org/lkml/2018/3/27/1225 for what audio wiring looks like. For voice calls the device does not use CPU, but we have C2C link between modem and cpcap instead. However, we must correctly set DAI format on cpcap side for for that link to work properly. General speaking, we might have multiple endpoints connected for a single port and when getting "link properties" I think we should use remote endpoint that is linked to local endpoint, not always remote endpoint0. If it is still not clear what $subject patch tries to achieve, please LMK and I'll try to elaborate even more, if possible. Also, if you think core allows such 'routing' to be implemented without the $subject functionality, please elaborate. I spent a good amount of time back then with no luck. Thanks and regards, Ivo