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 8BE83369965 for ; Fri, 27 Feb 2026 18:07:56 +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=1772215678; cv=none; b=uC6wrvQaL4T2csdAE+8Ey8z6xT3yOrP67md0spE9S9ToHbiF07uzJ0oL1MZ73FUzWDjPq15dEG4bw3Dzq+MbibykqBXX15dJY11kHLg1woS0JFrJHyNvRpP9g6YbiTLeF+2zJuWPw9pBbxV0+epVaMgRPhTKRPUG/1jZlO5WMyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772215678; c=relaxed/simple; bh=RKAxMw6+tYzq1HQOmAwm5iRGu7fVG2JfPuI6rfBTTi4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L0/vbCLWQkQ65p5c1prsJzk8GSve9mcsD5H84CjKg9MghGioJwfH8OEIp579FqB+04eRH/Fbg7ur8/qllv7nUT57fc5rNU0BzOsCgcB4apmeYfVtp//5r41otTxj2hABB3F0wORGp6tV8hrs2meOVYVLgCMYQ9FavsEQIk5Xi6s= 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=Pijuw8w1; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=ZYvu6nRU; 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="Pijuw8w1"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="ZYvu6nRU" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61RH0HIw3944640 for ; Fri, 27 Feb 2026 18:07:55 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= 823dFt7zxIlJX1RAw6gWs/3BdC5rgbHfxffaZTtrSPA=; b=Pijuw8w1Vc98imyY /KVVjkXvM8rbMbYQcidn6Tiv7F6p2amOiEnWwtzo4jkNJbKv7yvhOJBBGEaGSxbu 7iYi4pelTqePnJotrbqGL7c+QcHz61/58L6E6tnnq8Edf32Nh5fb/Gf7kO7PqgmN B2JPQMkEKbyJiSFc0BcuFjWZGWQGKzh6h02sbhvTDtOe1zDo8rLajpJDcKlc1VUh DDSiOPLMuXy6jP8WqrPvMSIULjo8HlNcoa1HiQPeDA7dBVGJ4zhoIo03zJIz2IKy wivusYmXwGziijs7nuevCHxeoLNAZBNn2hfdgBKq8EGLycAx1K1PCYEp4Tc/iA0T YG17nw== Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ck73q1xrb-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 27 Feb 2026 18:07:55 +0000 (GMT) Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8cb50dfd542so207568485a.0 for ; Fri, 27 Feb 2026 10:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772215674; x=1772820474; 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=823dFt7zxIlJX1RAw6gWs/3BdC5rgbHfxffaZTtrSPA=; b=ZYvu6nRUVvYYo8KTYdYXveYRbb0A+tMCbfAh/ehem4Aw/KsUyLIvEKOV1d80rHUVge YS8PWCcbm2Iw9RWSCHM/F9IcmrKbORIxJ01T3CAjNghyh756LYEvApJA29CkJwA7YJip aZuv5R1l+RRucodk14EUYrMEY/ygcJcrTplD2nvQtpFbRtkWh8W0GGcoxGkkuEqJdur1 1KJEmhd6oYyXhdQw4mTl2or0epNzsN0/FKKJaocTT27DHj3yCKtKjTPqYIxJZubCC4z5 l7ioGd4UVSLJYmfdviikdsYiWNj29Lzhz4Ifr5wGwCcibI0hYZY54c2UcI+439/NSXt4 jgow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772215674; x=1772820474; 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=823dFt7zxIlJX1RAw6gWs/3BdC5rgbHfxffaZTtrSPA=; b=QPPx4PsVzOlxHvYkCQyOOnr9gh5m7f9bIJZ9xjT9MUIibgMaXV59//DoswZT9zhoV0 AMtPgI3UF+g8LJlL71w6jw24ED7br6M6gyoq25Khz7U6ZMj8mNRllX2IcwbCYOkpqWVQ Um0EDIxa/TlakbhCaUyeWQiUcdWnsobmVqgMIJHoM25PfqOL//LIScdPQyz6EGTdkdXw 9AwdsE5i7jW+k2TOYUmQ0YUjLLl1+ibzW9fDKYjxf5ja30JGd8WyyoVlDizkVrWx9cN9 16E6d8YUHKRnXqNAGxp6/vuc4JzGhIePmXL/s/CrhVQukkD63x/8ZeV9MQf8VjQRX2+e 2Yhg== X-Forwarded-Encrypted: i=1; AJvYcCWuATwiaTnHF+/Vj6qMOvqbKzhlooK50BD740NkPk+bMDde1lkAkCAVq2BsI/X74WtlZnyJkmjcNv4skfQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwjGH7OXPvEPE35Mq0No3KMz5SF7J3JjTkxEbb9ZtWBuv8hMmFZ ZZ2YR6xHvuB/rJHAPJAfecMh3XkbSVTCzJBlf5Dx6k6iTvCJAmOtF0jRUv9OZEgxE2+vPUGv/y4 49YZ5aZSJa43Qz0n8v+TJvxjV9ZU7ptkY60kpDgqiUE8ebRGK5VgJAku7HGRpnPgTI38yzNpp3M o= X-Gm-Gg: ATEYQzxwD/vgOv3yPonFQug1begihnhfIP0lcqvJawxl2v55wJvu+AQvH+M09CHx5Yb KK/8UGbjxauK5Ep8A2o69y22gRx0mnlzUgInKUcqVBhMFrb//BaOVZymWxBtMQVeLK8Lzty0KIH QhFJ2C2g+UjwufvhcsLbBPUF8I681HicKgLldlRI8nzekNDso1qR7X2OplkshbVNC1YyXVxEb6E 43Lwh1ObbpOujMUGRIGnGhHZEilhRvLWt8BN6nd8MabKlcvlXkfA/ekXQ7awWDMiVqP1525pXxO D6d5R8+rdoVJz8BZYXSic3pR3sMW4GBwLacxkRrPUdf0J78MlvwZHAoWUiyDGiFMXtq1Jl51B6Z BAhFeb0e2bxfaspDyc4w2KsiLx6uVzvRmQKHi0/1m4Wzojl6Hmw77WU1+/D38bUSXXAtfh7Tw7F vHaVQ= X-Received: by 2002:a05:620a:4004:b0:8c7:1b40:d096 with SMTP id af79cd13be357-8cbc8e79d8bmr361202285a.9.1772215674122; Fri, 27 Feb 2026 10:07:54 -0800 (PST) X-Received: by 2002:a05:620a:4004:b0:8c7:1b40:d096 with SMTP id af79cd13be357-8cbc8e79d8bmr361196785a.9.1772215673496; Fri, 27 Feb 2026 10:07:53 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65fabd4664asm1487000a12.11.2026.02.27.10.07.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Feb 2026 10:07:52 -0800 (PST) Message-ID: <389ca5d3-a698-4dac-911c-39ba057e3d17@oss.qualcomm.com> Date: Fri, 27 Feb 2026 19:07:50 +0100 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] phy: qcom: qmp-combo: Move pipe_clk on/off to common To: Val Packett , Vinod Koul , Kishon Vijay Abraham I , Bjorn Andersson , Wesley Cheng Cc: Dmitry Baryshkov , Neil Armstrong , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org References: <20250927093915.45124-2-val@packett.cool> Content-Language: en-US From: Konrad Dybcio In-Reply-To: <20250927093915.45124-2-val@packett.cool> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjI3MDE2MCBTYWx0ZWRfXz7pLqa+nzHIg 6lIdkyOnJaITcipN/rJb4VWpRL0bwcLCZKRDzCAv+GkP+WhQUnTnbeQRZspHYF4LEv3UOtbIjEU 8Dbv1Dsx2r0N6kEfcx7rM0NvgzHarUfiidG/mlWBRkTD1aySdZ7dtWvqU6g0KQYhPSVKhTjjU12 6ROHg8UHboRg+z36Fff1e4VnSgdeZ8OmxQywvA4NiL5uIdDIp+zjgUhkAqbpRdwZWJzZ+Q8eMZR ErjxLgsg9WEypGjEfO7Z4+fO9B5pBB1U7LeUhHne9/YcfeoP7ylOPkV2uSZnoVB0nZKaePdCdDa wG3uGisGJD4xYkWQKtAeqVFtKoWfDe93jURuhM/uFzozh2JK2JKL9co0gr5F+ayUe+mAEx25sWB dsNCodrD+s/Ppg2N3AJqTBfKuMZHSYVwSSM7rEERIxuuh8rZN+U8E/QsqNZOrNYx0ep+Dd3WgSY LRoDJ4osJ37QvOiATvg== X-Authority-Analysis: v=2.4 cv=KL9XzVFo c=1 sm=1 tr=0 ts=69a1dd7b cx=c_pps a=HLyN3IcIa5EE8TELMZ618Q==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=HzLeVaNsDn8A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=NMrB2pzdCxszCODCV5UA:9 a=QEXdDO2ut3YA:10 a=bTQJ7kPSJx9SKPbeHEYW:22 X-Proofpoint-ORIG-GUID: vDGGErFRkjx5GyVx5hq8kMwTmgJdjKdE X-Proofpoint-GUID: vDGGErFRkjx5GyVx5hq8kMwTmgJdjKdE X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-27_03,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 malwarescore=0 priorityscore=1501 adultscore=0 bulkscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2602270160 On 9/27/25 11:17 AM, Val Packett wrote: > Keep the USB pipe clock working when the phy is in DP-only mode, because > the dwc controller still needs it for USB 2.0 over the same Type-C port. > > Tested with the BenQ RD280UA monitor which has a downstream-facing port > for data passthrough that's manually switchable between USB 2 and 3, > corresponding to 4-lane and 2-lane DP respectively. > > Note: the suspend/resume callbacks were already gating the enable/disable > of this clock only on init_count and not usb_init_count! > > Signed-off-by: Val Packett > --- > o/ > > Just got my hands on a perfect test device for DP alt mode: a monitor with an > on-demand toggle between 2 and 4 lanes. (Started digging because I thought > I needed 4 lanes to use its full resolution and refresh rate, even though > it turned out to be the dpu adjusted mode clock check rejecting the modes, > patches for which are already posted.) > > In [1] Konrad mentioned that "the hardware disagrees" with keeping the USB > PLL always on. I'm not sure what exactly was meant by disagreement there, > and I didn't find any specific code that touches that PLL in the driver, > so I decided to just try it anyway. > > Before the changes, 4-lane mode would actually kill the USB 2.0 functionality > on the port, no recovery until reboot. > > With this patch, I can switch the monitor between 4-lane and 2-lane modes > (with an unplug-replug cycle..) and the USB 2.0 devices attached through > the monitor keep working! (I verified the number of lanes used via dp_debug). > > I'm sure it might not be that simple but from my limited and uninformed > understanding without any internal knowledge, the "sneaky workaround" > might actually be the intended way to do things? +Bjorn, Wesley I wrote a wall of text for you, hopefully it makes sense I now think I have some more knowledge about the setup. The PIPE clock is an *output* of the PHY that feeds back into GCC, which provides a XO-PHY mux, which then has a gate/branch downstream of it. (that's 100% sure) That branch (e.g. GCC_USB3_PRIM_PHY_PIPE_CLK) then feeds into the destination core (PCIe, DWC3..) (that's *almost* 100% sure.. it's surprisingly difficult to fully confirm) Both msm-5.10 (and older) and upstream decided to keep that clock within the PHY device though, and that makes.. some.. sense, because you're not really supposed to turn it off (at least on recent chips), so much so as switch its source from PHY to XO. That of course needs to happen when the PHY is going to be disabled, as otherwise the PIPE clock is absent.. I can't really find information about when that branch is supposed to be *disabled*, but one can probably assume with reasonable confidence that if the PHY is offline (which generally only happens if the controller is offline), that may be disabled as well. The only remaining question remains then, where does the PIPE clock come from? It's most likely not derived from the DP PLL. The PHY has some slow onboard always-on clocks (for USB4 wakeup and USB3 autonomous mode), but those are waay too slow to be driving PIPE (which runs at 125 MHz @ SS, 312.5 MHz @ SS+).. so only the USB PLL remains. But then, in DP-only mode, SW_USB3PHY_RESET is asserted. The documentation uses some imprecise wording with regards to what that entails, but there's not many options left other than it may be leaving the PLL in tact, while halting other parts of the USB3 logic. Conversely, usb3phy_(nocsr_)reset is explicitly promised to reset the USB_PLL. I think the PLL also happens to be disabled when entering either of the aforementioned sleep modes, since the table tells me the required RPMH level is 'retention', which surely isn't enough to feed a big PLL. The solution of teaching DWC3 how to switch clock sources is a little involved, since we (to my understanding) have to/should omit programming the parts that are conditional upon superspeed capabilities, and doing that at runtime would probably realistically require making it type-C aware (I don't think we want to go that route plus micro-b/MHL edge cases *sigh*), or we could count on the suspend/resume work making it magically click into place (since the dwc3 core does quite some re-programming upon any sort of sus/res today anyway, it seems). If the latter happens, we may end up reverting this patch as it may then turn out no longer necessary. Today, i think this commit resolves this immediate issue and I think it's the fix we should take (bumping my request of reordering the clock disables and resubmitting..). On an interesting note, if we take for granted my hypothesis about the soft-reset not impacting the USB_PLL, this seems like an oversight in programming guides, because USB4 transition sequences explicitly mention the names which refer to resets coming from GCC, while DP/USB mix-and- matching explicitly suggests using the soft-resets, but that might have gone unnoticed, since dp-only hasn't been much of a prime use case for in the past, as most of these chips were targetting mobile. Konrad