From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E949D429817 for ; Tue, 16 Jun 2026 11:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781610296; cv=none; b=nclx8eVZJ0Nc4Nv/SaLHwfuP9rP/O2lYIewkh5KCHQ7LHf+Yzx1n2b7SIj1nwE/34gy+jYnmKHEslSVCg+goBHB/WYzBFLCwVhmyaNjdHmjnc94I5j59X2SXaKE5qS/dI+Lh2a++X3biwU4BjVMA6ohLpkP0jyLsGFSUXKfmNUs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781610296; c=relaxed/simple; bh=r9n7rSawhFk2n3APa8yaNvcfOl3foSyuI8+jSLMC6Po=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Rm+2mWiUaPYwxEKiwzYdsq13yJiQZqOlLnXeeea78rnupB9cXdFnbr+HUAEontyTdLsm7pNJz9zIjJyPCaewVtZvoDrpaDMKbz4ErQ4dKC7ZY6j9RruF+Q1nSvjgDs5wvb3Vig2v2/+gj8KGWwwfzG327X7I3OG+tlG9ZA0QhR4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=nPReZeR/; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=SGVGqQWB; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="nPReZeR/"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="SGVGqQWB" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65GABNmn3224162 for ; Tue, 16 Jun 2026 11:44:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= E+dhUIYvMd/ZyhsxJD8pDE5Uwu0gXRWZLv+OMnJz01I=; b=nPReZeR/Nm21IuxS g15voOVsgC/IyaqAszZEKiDHXqD+No87PHZpmFoc8OR8e8oQoNpDaeb3ehXTTGXp 89D/E7PpxBd5sCwOt0nkVWJ/KW0q17ezksDQWn4RD+4zKzLece5a7+JfcQQD2n/n wj3xR9XtHrBGnDtmHdfxK+i9owN1/vhQcJy3UuoWWDeHdEKj9WTisa/abkKMAifZ +sx6E6/EpbNEmzZRv1AxmaxU5RvxzGXIFPB686PuK7aYbcCynh8IrKIyMwlz1IcD oi195vbZ5s03FVpMoKke8HjH7165s2W2ZkrL58Z/eVb34lp6MSvyzdIrzCIn3nL2 WjdLsA== Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4eu1yss2dw-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 16 Jun 2026 11:44:53 +0000 (GMT) Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-915a4ca0a4aso46647585a.1 for ; Tue, 16 Jun 2026 04:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781610293; x=1782215093; 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=E+dhUIYvMd/ZyhsxJD8pDE5Uwu0gXRWZLv+OMnJz01I=; b=SGVGqQWB05UhngCSMlEec0Xh7uSeja9/ualtauT5ptnzHFNOVGUYIRxF9DLerS7YqY noN6hEcTFxQXXIW7YVPdqCVrg2/CI4dwYX4TmuHaW/b8sYSvhRHl/pqZTxiaDwltyynJ nuVWrjtXxCs/6XJQBXsY7ouK5bsECCXSIPEwgBCiyo+39lCw4lSJTwebaLURimtlI7x8 n95CXc90NF6yeRmdDrUe04JiOxypJDFUXUbMEnm+sRK6Z3Dk7z1Q732XpSeBYNmELme1 b4UnoanFBxVBBrfk4V9TJ9ru7jnNd0rYHyA4zvKsp2JGREvgNy6up900Ul54xK5uYGgk bslA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781610293; x=1782215093; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E+dhUIYvMd/ZyhsxJD8pDE5Uwu0gXRWZLv+OMnJz01I=; b=G5KKyrIcjTvTq1Wc4C89xefDjYtIr2Ks0HKPM/CntcT5ql37YlFFoPrQ5hitGy5E5R TiTwSoWGbqhm4IQQ0bJ0drydYZLds2AxouPgCY2WLbvdmkTw3JPAGOccDYZ6spqz0G2m Fq9+KepYpO2sNKE0WNV73GijqapgJJByKzrlZfTkGR9VylH/SULpMP4LK1sZ1j/7GXfz XAKPWN5+EqeOtoocKumUUBJeaB7dbgA8np6LQyC157ExJTURocuF7Y3WVDeAtLkhhITW /+wuXLKT1TK4soIK6sjRo0ZMn/mHBoFRb+n+PmCCgKTvzuSeikUvFRq3iIzK7F/6PZGr CVRg== X-Forwarded-Encrypted: i=1; AFNElJ8CPDZkpMsDRXZtybL09XdHDxrr4FUgs8GOYC6utiaeP8eldniHF7J3WCG8lIJl0BNFZtFuvq2Iu0YFQ6g=@vger.kernel.org X-Gm-Message-State: AOJu0YwW4UsQGr3H+JsOhPFzjWN84JvvxpaFSW9fq/LmFEs1Y/muSQS+ 6fk5HbIa8ujLYVL3rY+i4nNmwcaPQSflFoGWn9ZaMRG2ms1hwsKUJeJV8hiUOw1aIXi2uNycDjR I/j5UNhRySzV7mDqDgu7FPCZlPKbTzVCmS8V0g2bz6ahIoz17+M2av+HuFPpYhyD3xyQfsQTMh4 8= X-Gm-Gg: Acq92OFhcesCML4LI3rciTxadv/2te4u4WJaK0ouiT4M8Phpu948UslDfrNNPMcZXfW riJlhUzDZHbjD3lhQFpa5gw/LzbsrtgrtsFdRSJVkZsMx3lLh08zzn41vlOFqMygHcv14rq6gnW a3RfS6f+Qex43j03AvPUV4vGMMVGPDUeUlpgItwxvufnXaW1otbBvCHUd4j0rwawhRHh6erowPU fuM17ivnz3BnJwkElFFBYpnWx7vP3hjXE7tZ39JX5R/Z3JIBlPm+oeAxhMDsqGv2RpoFKMt8Jzn pSa53z6C1yaW1wtii/wCTRwF2W1/A1diewX4FRnF96McMQ/YSMCdVXGlWvYGM++Frc85tJHqVvZ /CU24erxdO/b+bF9XM3VRc/Fy05Zc1afWlJCYuMkxf31nMg== X-Received: by 2002:a05:620a:31a8:b0:916:1a60:ee05 with SMTP id af79cd13be357-9161b94f702mr1637961185a.0.1781610293043; Tue, 16 Jun 2026 04:44:53 -0700 (PDT) X-Received: by 2002:a05:620a:31a8:b0:916:1a60:ee05 with SMTP id af79cd13be357-9161b94f702mr1637958585a.0.1781610292515; Tue, 16 Jun 2026 04:44:52 -0700 (PDT) Received: from [192.168.120.170] ([178.235.128.140]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bfdb7b6d8c2sm611669866b.38.2026.06.16.04.44.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 04:44:51 -0700 (PDT) Message-ID: <3972248c-acfc-4b31-8c99-69bfdba34b8c@oss.qualcomm.com> Date: Tue, 16 Jun 2026 13:44:48 +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: [PATCH 3/5] phy: qualcomm: qmp-combo: Add preliminary USB4 support To: Dmitry Baryshkov Cc: Konrad Dybcio , Vinod Koul , Neil Armstrong , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, usb4-upstream@oss.qualcomm.com, Raghavendra Thoorpu , Mika Westerberg , Sven Peter References: <20260518-topic-usb4phy-v1-0-71d827c49dca@oss.qualcomm.com> <20260518-topic-usb4phy-v1-3-71d827c49dca@oss.qualcomm.com> <4nqlpu7qfptekyn77sd7sdn446stgn3v3lw2356bvizrnvjgnr@czqgivemigt5> <9aad8e45-b0a5-4c59-8793-8c0747d8fafa@oss.qualcomm.com> <6fb112ae-5919-4c8f-a915-4538d14284da@oss.qualcomm.com> <72b140a7-e95e-491d-8bae-f98a593bdbfb@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: w2eJVxQEvUugLaBHiR-gvAnyRbnlB8nZ X-Proofpoint-Spam-Info: AW1haW4tMjYwNjE2MDExOSBTYWx0ZWRfX9WglTUAdwt9R o54wGJD3rIieK2Wt3+2jzrrqfPgznq2WGcAgQbYbndi4OMIqAz2kf9ihSxCRtsbo4fTNwbnHGhN r61WWcgG13vn09s4Apuuu8TuFF9L5qg= X-Proofpoint-ORIG-GUID: w2eJVxQEvUugLaBHiR-gvAnyRbnlB8nZ X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjE2MDExOSBTYWx0ZWRfX5cE4oHeS9TIt /y8smTNowYLqYlEPZhJESN73OO57BmEiNJ7iBg2XiMwgwuAQs8I2xiGWwxqkVaakJ2cVaMdNHV4 cy7nHcsEnNjad3AEJxH3GLXSQQKjsRP0H81SYsXmP8c4/Guea1FiSoDaHQmsEKvsXO2tiCXewk1 nNtw8QemOTw+m+fSL681fL78B9S2/0+a2SesEPve+xHEEOCUj/CU7Net5N4/YsqgpjG795AeBNw X4bxpyqkmrlf9LMnJkmhSF21K5S/XvWXeszAfDNgA1sqfy+jWy11/gWaIT+sZilceR/gn+iHgTH aCIaHGg4g6pISwDzWmXgyWw/NDmHubA+f9oMGV18Ay7YHMXTv8lUpWwH8L8RbLSiu05H+F/3ohD LafXYOd3DNdY/tvmm1roIwZlrb583QoqiWVJVCCyEVW4zNqaTVLnftFKVX0cm+fMKRHvZOV4reZ 6rqJCAhlyzXs7yFyj3Q== X-Authority-Analysis: v=2.4 cv=JJcLdcKb c=1 sm=1 tr=0 ts=6a313735 cx=c_pps a=50t2pK5VMbmlHzFWWp8p/g==:117 a=PRfkaYvzSr8QmIIGAkY2Sg==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=EUspDBNiAAAA:8 a=zUi1tAqb9gt6XWnjdEwA:9 a=QEXdDO2ut3YA:10 a=IoWCM6iH3mJn3m4BftBB:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-16_03,2026-06-15_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 priorityscore=1501 adultscore=0 impostorscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606160119 On 5/28/26 10:00 AM, Dmitry Baryshkov wrote: > On Fri, May 22, 2026 at 02:05:14PM +0200, Konrad Dybcio wrote: >> On 5/20/26 5:06 PM, Dmitry Baryshkov wrote: >>> On Tue, May 19, 2026 at 10:12:06AM +0200, Konrad Dybcio wrote: >>>> On 5/18/26 5:38 PM, Dmitry Baryshkov wrote: >>>>> On Mon, May 18, 2026 at 04:15:16PM +0200, Konrad Dybcio wrote: >>>>>> On 5/18/26 3:57 PM, Dmitry Baryshkov wrote: >>>>>>> On Mon, May 18, 2026 at 12:29:50PM +0200, Konrad Dybcio wrote: >>>>>>>> From: Konrad Dybcio >>>>>>>> >>>>>>>> Some Combo PHYs (so far only on SC8280XP, X1E80100 and Glymur), come in >>>>>>>> a flavor called USB43DP, which as the name implies, features USB4, USB3 >>>>>>>> and DP signal processing capabilities. In that architecture, USB3 and >>>>>>>> USB4 PHYs share the same USB_PLL while featuring separate logic spaces. >>>>>>>> The DP part is roughly the same as on the instances without USB4. >>>>>>>> >>>>>>>> The USB4 and USB3/DP operation modes of the PHY are mutually exclusive. >>>>>>>> Only one USB protocol (and flavor of pipe clock) can be active at a >>>>>>>> given moment (not to be confused with USB3 not being able to be >>>>>>>> tunneled as USB4 packets - that of course remains possible). >>>>>>>> The DP PLL is still used for clocking tunneled DP links. It may be >>>>>>>> turned off to save power when no tunnels are active, but that's left as >>>>>>>> a TODO item for now. >>>>>>>> >>>>>>>> Due to the nature of USB4, the Type-C handling happens entirely inside >>>>>>>> the Host Router, and as such the QMPPHY's mux_set() function is >>>>>>>> nullified for the period when USB4 PHY remains active. This is strictly >>>>>>>> necessary, as the Host Router driver is going to excercise manual >>>>>>>> control over the USB4 PHY's power state, which is needed by the suspend >>>>>>>> and resume flows. Failure to control that synchronously with other >>>>>>>> parts of the code results in a SoC crash by unlocked access. >>>>>>>> >>>>>>>> Because of that, a new struct phy is spawned to expose the USB4 mode, >>>>>>>> along with a .set_mode callback to allow toggling between USB4 and TBT3 >>>>>>>> submodes. >>>>>>>> >>>>>>>> Thunderbolt 3, having a number of differences vs USB4, requires a >>>>>>>> couple specific overrides, pertaining to electrical characteristics, >>>>>>>> which are easily accommodated for. >>>>>>>> >>>>>>>> Signed-off-by: Konrad Dybcio >>>>>>>> --- >>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 392 ++++++++++++++++++++++++------ >>>>>>>> 1 file changed, 322 insertions(+), 70 deletions(-) >>>>>>>> >>>>>>> >>>>>>> Overall it looks good. The major question (after looking at TODOs), do >>>>>>> we need a separate submode for USB+DP / TBT+DP? >>>>>> >>>>>> The problem space is as follows: >>>>>> >>>>>> After a TBT (collectively TBT3+ and USB4) link has been established and >>>>>> we have a link partner, we may (based on the HW capabilities and user >>>>>> config, such as kernel params but not only) start or stop a DP tunnel at >>>>>> runtime. On Qualcomm hardware, the PHY is kept in USB4 mode and its DP >>>>>> AUX lines are not used (instead, the encapsulated DP AUX packets are r/w >>>>>> entirely within the USB4 subsystem via a pair of FIFOs that Linux sees >>>>>> as a separate DP AUX host) >>>>> >>>>> So far so good. But I still don't grok if having a DP-over-USB4 is a >>>>> separate submode or not. I.e. I see code (and TODOs) to detect and >>>>> handle DP going on and off. Would it be better if we specify that >>>>> explicitly? >>>> >>>> I really don't want to end up in a situation like we have with: >>>> >>>> $ rg _USB include/linux/phy/phy.h >>>> 29: PHY_MODE_USB_HOST, >>>> 30: PHY_MODE_USB_HOST_LS, >>>> 31: PHY_MODE_USB_HOST_FS, >>>> 32: PHY_MODE_USB_HOST_HS, >>>> 33: PHY_MODE_USB_HOST_SS, >>>> 34: PHY_MODE_USB_DEVICE, >>>> 35: PHY_MODE_USB_DEVICE_LS, >>>> 36: PHY_MODE_USB_DEVICE_FS, >>>> 37: PHY_MODE_USB_DEVICE_HS, >>>> 38: PHY_MODE_USB_DEVICE_SS, >>>> 39: PHY_MODE_USB_OTG, >>>> >>>>>> Then, on hamoa/glymur specifically, any of the 3 USB4-capable DP hosts >>>>>> can be muxed to either of the 2 DPIN ports on any of the 3 USB4 routers >>>>>> (and each of these routers is hardwired to one of the PHYs). >>>>>> >>>>>> To underline, we have 3 DP producers and 6 consumers. If there's e.g. a >>>>>> super high-res display at one of the physical ports, or a long >>>>>> daisy-chain, we may need to use 2 DPTXes to service 1 receptacle. Then, >>>>>> we would only need one of the PHYs (associated with the router that's >>>>>> wired to that port) to provide a DP clock. >>>>>> >>>>>> This, along with the normal (logical or physical) present/absent status >>>>>> can change at runtime. My plan is to use phy_set_opts(dp_tunelling=true) >>>>>> or something along those lines to toggle that bit as necessary >>>>> >>>>> I don't see phy_set_opts(). So maybe a submode then... >>>> >>>> Sorry, I misremembered the name. The function is phy_configure(), and it >>>> takes a union phy_configure_opts, hence the confusion >>> >>> So, phy_configure() will be called for the DP PHY to set the DP opts, >>> but how do you plan to determine if DP is on or not? Or do you plan to >>> add phy_tbt_configure_opts ? >>> >>> Another obvious option would be to set the flag if DP PHY is being tuned >>> on / off. I don't know if that fulfills your needs. >> >> Either this or tbt_configure_opts. We still have the muxing question to >> chew through. >> >> The bottom line is that all AUX traffic happens between the "AUX adapters" >> within USB4SS, talking over thunderbolt to other AUX adapters on the LTTPRs >> and the far-end device (and anything inbetween in a chained topology) meaning >> we only need to engage the DP host itself (and therefore the PHY) after we've >> already performed the capability negotiations > > I hope you mean USB link capabilities. DP host still needs to ping LTTPRs > and read all the DP properties on its own. I don't think we want to leak > that to the other layers. I must crush your hopes. There's some preliminary TBT-layer setup (handled by the tbt driver in Linux), followed by the expected DPCD (and alike) r/w accesses, which on our hw must happen through the DP adapters housed inside USB4SS (again, because the DPTX's auxbus is NOPed out). Think of it as just another i2c_aux provider. Konrad