Message ID | 413d612f-0e31-6281-64e3-6484b85afe06@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1611769dyi; Thu, 11 Jan 2024 09:42:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IFj6CGXxqUn+mTwij5YAtv8MmC/tb6FbMgoVU6aWjKqz4KnTmpkf48BlxD8RfvYkOnOLnyK X-Received: by 2002:a05:6359:6bca:b0:172:b539:3fcd with SMTP id tb10-20020a0563596bca00b00172b5393fcdmr175593rwb.53.1704994971312; Thu, 11 Jan 2024 09:42:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704994971; cv=none; d=google.com; s=arc-20160816; b=SEDP3v/h9XWn1C75AE9Qcw/qe1N1F8W2tQ1aMVBKTJYKm4a7+tPx856Opn3hKQ6o6P MgHcMBlNlxM9Emi8qnOfnXTp/1hDlRBOr2ADfrxXV61u2KOucOZasQaoTzH93e/by+Yx LGwVs1xMjmAd+5J2zEDs5P1iiMS6MtNrR07uNdC9z/BhjBm/gj9vF5nhTxa6qsPsj7ch TLa4SjZU8frhLT688Eail2ox4uBrgKjTpmELZJBCHpcCJxhapFwVaN4F9mzkPlOc3QPO DjZrZPxtAGNqiakRZg1BMLUn8TEFu7oOcS0zwPpUhFOuNIbodCc2rymZzLyvjAHshhJ7 gMmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:date:message-id:dkim-signature; bh=rXpv7UpBmMgFq8OcLbEUaV3lBTiJi6g9qk41Zt53hGY=; fh=gjhGKVzfgVWTwXN8cbvvWTsyrvKiyXyHgEuzfQzHWnU=; b=L8k/YJdaFhaXzTp6mmf8dV+7h6Mf9MdJIUkpJIecQfAai+25UYEv6eB4om/dhHeAL/ MI22G87QJ6S7qnup6K5iHlfK2VyEYi+HoVsg1Hckgp6wlXKTc1FklhdMYfL0ABOkn0da ZA2OGLJjsuVykrQXNhHWnVhY4YxiKWcK31LqDdAPGCQ3oN3aS39tSyd9qH9M7gs9eZx9 PnruMAZ9+tm83+ywG35UvI6/8r3VxMZwJYEsfeawiarC9xqm4hx4f+CelACFUNhYgbQm PqexUU19ihzSn9aETH15/Eio1It/XgZLhegf8H4g6YrM6nZ+cxzSyFBHqPflnLJZ7Sg6 S5Ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=m1DOegKp; spf=pass (google.com: domain of linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id m128-20020a632686000000b005cdfe91fb80si1644337pgm.416.2024.01.11.09.42.50 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 09:42:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=m1DOegKp; spf=pass (google.com: domain of linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23942-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id CE967B2426A for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 17:39:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E03AB53E0A; Thu, 11 Jan 2024 17:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="m1DOegKp" 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 B410351C5E; Thu, 11 Jan 2024 17:39:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40B2nkJk012253; Thu, 11 Jan 2024 17:39:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= message-id:date:mime-version:from:to:cc:subject:content-type :content-transfer-encoding; s=qcppdkim1; bh=rXpv7UpBmMgFq8OcLbEU aV3lBTiJi6g9qk41Zt53hGY=; b=m1DOegKpGWTVGzftQ4HR6D4jrciQYxZPDo+4 4uelwzhwKKtKL5lB/lMKOgsNfsa9Fz8sBqXmrE2roVyF6ij18n3DUuFpW6GgKUpl SaoABHRTQLmcSJ0wIgCI/bTJrH/b9PjNZJ2ebkcKoETrYrzWSIdHbo08THkV4kx+ BCsos992tmSUJ3Hafsg9eK0P+4OK32rIqDkTMBZky3eksIFjLpE5X7s2VmkhgYqw kmgXicJ4u9ogO4XZVhS2qKGeMcSswWFOUMN8ntn93vMTnLP8+OYOJ0ryLVlUZcWF 3ppjtgQxhyTgsyYcCRh0eKfQ9dIE4uocNsqpzIPFnhS8vPJr7A== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3vj7w221at-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 17:39:02 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 40BHd1SQ018445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 17:39:01 GMT Received: from [10.216.55.36] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Thu, 11 Jan 2024 09:38:57 -0800 Message-ID: <413d612f-0e31-6281-64e3-6484b85afe06@quicinc.com> Date: Thu, 11 Jan 2024 23:08:52 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Content-Language: en-US From: Krishna Chaitanya Chundru <quic_krichai@quicinc.com> To: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>, "Veerabhadrarao Badiganti" <quic_vbadigan@quicinc.com>, <quic_skananth@quicinc.com>, <bartosz.golaszewski@linaro.org>, open list <linux-kernel@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "open list:PCIE ENDPOINT DRIVER FOR QUALCOMM" <linux-arm-msm@vger.kernel.org> Subject: Proposal for QCOM PCIe switch power and configuration driver Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: pWA4eBRACFwke8WxsHKijw-Dzf-RzMPf X-Proofpoint-ORIG-GUID: pWA4eBRACFwke8WxsHKijw-Dzf-RzMPf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-09_02,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 priorityscore=1501 spamscore=0 malwarescore=0 impostorscore=0 clxscore=1011 mlxlogscore=999 adultscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401110139 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787816806979720802 X-GMAIL-MSGID: 1787816806979720802 |
Series |
Proposal for QCOM PCIe switch power and configuration driver
|
|
Commit Message
Krishna chaitanya chundru
Jan. 11, 2024, 5:38 p.m. UTC
Hi DT maintainers, We are trying to upstream the QCOM PCIe switch which has I2C interface to configure the switch. In generic a PCIe switch is a device that allows expansion of PCI Express hierarchy, which allows more devices(PCIe endpoints) to be connected to a single PCIe port. We need to configure the QCOM switch like L0s, L1ss entry times, Tx amplitudes etc.. through I2C interface before PCIe link is established as these settings can affect link stability if we don't configure them. Once PCIe switch is configured, PCIe link between the PCIe switch and PCIe port connected should be established by the QCOM PCIe controller driver to enumerate the PCIe endpoints connected to the PCIe switch. We had a QCOM switch driver which powers on the switch and do the I2C configurations. This is how the flow goes. -->Power on the switch -->Do Switch configuration (over i2c) with qcom switch driver -->PCIe link training and enumeration. From the the above requirements we want a I2C client driver which probes first and power's on the switch and do switch configurations through I2C, and then PCIe driver needs to probe and do the link training and enumeration. And for suspend resume usecase also we need these probe dependencies. As we can't keep the probe dependencies between PCIe controller driver and I2C client driver in the DT, we want to propose following solution. Since the I2C driver need to configure the switch and power it on before the PCIe driver attempts to probe the device, we thought of exposing a reset controller from the I2C driver. We came up with this reset controller idea because the I2C driver essentially has to configure the switch and power on the device, then only the PCIe driver has to probe the switch. This aligns with how reset controller operates in general. This is how sample DT looks like we are open for any other suggestions also. Thanks & Regards, Krishna Chaitanya.
Comments
On 11/01/2024 18:38, Krishna Chaitanya Chundru wrote: > Hi DT maintainers, > > We are trying to upstream the QCOM PCIe switch which has I2C interface > to configure the switch. > > In generic a PCIe switch is a device that allows expansion of PCI > Express hierarchy, which allows more devices(PCIe endpoints) to be > connected to a single PCIe port. > > We need to configure the QCOM switch like L0s, L1ss entry times, Tx > amplitudes etc.. through I2C interface before PCIe link is established > as these settings can affect link stability if we don't configure them. > > Once PCIe switch is configured, PCIe link between the PCIe switch and > PCIe port connected should be established by the QCOM PCIe controller > driver to enumerate the PCIe endpoints connected to the PCIe switch. > > We had a QCOM switch driver which powers on the switch and do the I2C > configurations. > > This is how the flow goes. > -->Power on the switch > -->Do Switch configuration (over i2c) with qcom switch driver > -->PCIe link training and enumeration. And where is the PCI controller in this? Why isn't this represented like I2C or GPIO expander? You need to describe what exactly the switch is doing. Also, how about using existing solutions? Aren't there any? I am not going to look for them for you... Anyway, you should ask (means Cc) reset controller maintainers if they are happy for such usage of reset framework for something not being a reset. For similar reasons you should Cc PCI maintainers. If you ask me, then no, PCI switch does not look like reset line so, you should not use reset lines. Best regards, Krzysztof
++CC Philipp Zabel ( reset controller maintainer) & Bjorn & PCI list from PCIe subsytem. On 1/11/2024 11:20 PM, Krzysztof Kozlowski wrote: > On 11/01/2024 18:38, Krishna Chaitanya Chundru wrote: >> Hi DT maintainers, >> >> We are trying to upstream the QCOM PCIe switch which has I2C interface >> to configure the switch. >> >> In generic a PCIe switch is a device that allows expansion of PCI >> Express hierarchy, which allows more devices(PCIe endpoints) to be >> connected to a single PCIe port. >> >> We need to configure the QCOM switch like L0s, L1ss entry times, Tx >> amplitudes etc.. through I2C interface before PCIe link is established >> as these settings can affect link stability if we don't configure them. >> >> Once PCIe switch is configured, PCIe link between the PCIe switch and >> PCIe port connected should be established by the QCOM PCIe controller >> driver to enumerate the PCIe endpoints connected to the PCIe switch. >> >> We had a QCOM switch driver which powers on the switch and do the I2C >> configurations. >> >> This is how the flow goes. >> -->Power on the switch >> -->Do Switch configuration (over i2c) with qcom switch driver >> -->PCIe link training and enumeration. > > And where is the PCI controller in this? Why isn't this represented like > I2C or GPIO expander? You need to describe what exactly the switch is doing. > The PCIe link training and enumeration is handled by PCIe controller driver. Usually a single endpoint will be connected to PCIe port, using a switch we can connect multiple endpoints like WLAN, NVME, PCIe to ethernet bridge etc. So in single instance of PCIe multiple endpoints are connected and enumerated. Like I2C or GPIO expander we don't want to configure any endpoints, here we are trying to solve the initialization part of the switch power to the switch and configuration of the switch before PCIe controller starts link training and enumeration. > Also, how about using existing solutions? Aren't there any? I am not > going to look for them for you... > As of I know we don't have any solutions exiting now, we are trying to explore different ways for it. > Anyway, you should ask (means Cc) reset controller maintainers if they > are happy for such usage of reset framework for something not being a > reset. For similar reasons you should Cc PCI maintainers. If you ask me, > then no, PCI switch does not look like reset line so, you should not use > reset lines. > I added both maintainers now. sorry for the miss. We want to use reset line because I2c driver has to power on the device and configure the switch only before PCIe controller driver probes. This is how reset controller operates(correct me if I was wrong). Thanks & Regards, Krishna Chaitanya. > Best regards, > Krzysztof >
On 12/01/2024 05:16, Krishna Chaitanya Chundru wrote: > ++CC Philipp Zabel ( reset controller maintainer) & Bjorn & PCI list > from PCIe subsytem. > > On 1/11/2024 11:20 PM, Krzysztof Kozlowski wrote: >> On 11/01/2024 18:38, Krishna Chaitanya Chundru wrote: >>> Hi DT maintainers, >>> >>> We are trying to upstream the QCOM PCIe switch which has I2C interface >>> to configure the switch. >>> >>> In generic a PCIe switch is a device that allows expansion of PCI >>> Express hierarchy, which allows more devices(PCIe endpoints) to be >>> connected to a single PCIe port. >>> >>> We need to configure the QCOM switch like L0s, L1ss entry times, Tx >>> amplitudes etc.. through I2C interface before PCIe link is established >>> as these settings can affect link stability if we don't configure them. >>> >>> Once PCIe switch is configured, PCIe link between the PCIe switch and >>> PCIe port connected should be established by the QCOM PCIe controller >>> driver to enumerate the PCIe endpoints connected to the PCIe switch. >>> >>> We had a QCOM switch driver which powers on the switch and do the I2C >>> configurations. >>> >>> This is how the flow goes. >>> -->Power on the switch >>> -->Do Switch configuration (over i2c) with qcom switch driver >>> -->PCIe link training and enumeration. >> >> And where is the PCI controller in this? Why isn't this represented like >> I2C or GPIO expander? You need to describe what exactly the switch is doing. >> > The PCIe link training and enumeration is handled by PCIe controller driver. > Usually a single endpoint will be connected to PCIe port, using a switch > we can connect multiple endpoints like WLAN, NVME, PCIe to ethernet > bridge etc. So in single instance of PCIe multiple endpoints are > connected and enumerated. > Like I2C or GPIO expander we don't want to configure any endpoints, here > we are trying to solve the initialization part of the switch power to > the switch and configuration of the switch before PCIe controller starts > link training and enumeration. Post your datasheet or at least send some diagrams describing everything, so I won't have to keep guessing. > >> Also, how about using existing solutions? Aren't there any? I am not >> going to look for them for you... >> > As of I know we don't have any solutions exiting now, we are trying to > explore different ways for it. So did you look it up? How much? If I find one, in the drivers, what then? Can you look for it first? >> Anyway, you should ask (means Cc) reset controller maintainers if they >> are happy for such usage of reset framework for something not being a >> reset. For similar reasons you should Cc PCI maintainers. If you ask me, >> then no, PCI switch does not look like reset line so, you should not use >> reset lines. >> > I added both maintainers now. sorry for the miss. > We want to use reset line because I2c driver has to power on the device > and configure the switch only before PCIe controller driver probes. Let's don't repeat the style of discussion we have with Luo Jie, where I say this is not reset and you say "but we want" and use some ridiculous argument. > This is how reset controller operates(correct me if I was wrong). I talk about bindings. Otherwise why would you Cc me? Just because something has power it is a reset? No, it is not. You said about configuring lines: reset does not do this. I am really tired of such discussions after last time. Getting half-baked answers from you, incomplete pictures and something just to respond to my question without providing anything valuable, because you do not want to disclose too much. I got really disappointed last time and this will affect further submissions from you. That's how reputation works, sorry. Just because it controls power, among many other things, does not mean it is a reset. Maybe it is a phy? Or a mux? How do I know? Do you expect me to guess? Best regards, Krzysztof
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi index 2ff549f4dc7a..222206902305 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi @@ -414,6 +414,18 @@ &lpass_va_macro { vdd-micb-supply = <&vreg_bob>; }; +&i2c0 { + clock-frequency = <100000>; + status = "okay"; + + pcie_switch: pcie-switch@77 { + compatible = "qcom,switch-i2c"; + reg = <0x77>; + vdda-supply = <&pcie_switch_rest_vreg>; + status = "okay"; + }; +}; + &pcie1 { status = "okay"; perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>; @@ -422,6 +434,10 @@ &pcie1 { pinctrl-names = "default"; pinctrl-0 = <&pcie1_reset_n>, <&pcie1_wake_n>; + + resets = <&gcc GCC_PCIE_1_BCR>, + <&pcie_switch 0>; + reset-names = "pci","device"; }; Can you please tell us whether this approach is acceptable or not?