Message ID | 20230724124711.2346886-2-quic_ipkumar@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1803934vqg; Mon, 24 Jul 2023 06:34:52 -0700 (PDT) X-Google-Smtp-Source: APBJJlESfEfFfF11z3kc2H+x3/pZsCQ5Lqi1vrlzBntqOg/ZvMooBD/WqBfq4KPyjLsNQx2LBuJ/ X-Received: by 2002:a05:6358:9916:b0:132:f612:1dbd with SMTP id w22-20020a056358991600b00132f6121dbdmr10111387rwa.26.1690205691819; Mon, 24 Jul 2023 06:34:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690205691; cv=none; d=google.com; s=arc-20160816; b=rWg2Tlf1MvEYwVml/5jFEZmhYdeeC210QqL17kNjfc8n2JaO7MVsloQ3bMiADAQ04o SGA0IlUBxkXV95e44ZKHdRxANe0+flnvclE+fdzjBPhPszq6KfmukPIKfnkPkiLbdR6j k3Q/piD4fI4izVa1e3mIYprAqCdHZUeuVLjQvz7K8CRxcBs0g6jrr9dYLf0iNRrTf167 AmaKkqh2Vc89dkx6ULyY+cCMl74t9kiTRRj1ixZxlF6COL06AZQyLhZG+PhgacFZQnvw xi70ktiGbyO9ahs3cLB83V1s4eHShNaRwsrkNz5SoxrILishaQ/lvPMTzzG2JXdpzYGi tmuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ydsySNg3Q4jb9ZF8E2mxqDsppYBtg+mgK0htP0/P++8=; fh=OakHLMebbmhBQyFs/lIDihzT1rDeGmt4wWMDhYlS94c=; b=uTfIsl1+2Knhs5irSGxR4qnualOs8Sqi0RwHSVal7o4EkJRoclAcrtIpTSc9nmWgSd 4YedBQfC41AY9LbM2h9Yoe/CBqN3aHP1T+/9O3QbfMD9TrB5sHcnkdeUBj3Sbj6MJuxq 1jrISXvkC6HJRGUprxag3KjSlAFuf1T5alDUdE9O5osPF2M32T9GQZ46tIfFv+MYvFyD yFIgiID8OnPvaUoOlHixyfUdi7tEbGJX2XS2hJjp1NTwQ+6fOZ6SwIkZXGIpp2Tc1UFe LBS7SNdG5KqjvKPWcIKTRHqhLG624DgxPPaksUkQPpNbQ3VwsMP/qAH13pPsVAf3NHn9 Q08g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=GeJ0m14B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a6566c5000000b0056370a8b95asi8980171pgw.878.2023.07.24.06.34.38; Mon, 24 Jul 2023 06:34:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=GeJ0m14B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231178AbjGXMsS (ORCPT <rfc822;kautuk.consul.80@gmail.com> + 99 others); Mon, 24 Jul 2023 08:48:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231186AbjGXMsB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Jul 2023 08:48:01 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09AB1E63; Mon, 24 Jul 2023 05:47:38 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36OCdNMx015189; Mon, 24 Jul 2023 12:47:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=qcppdkim1; bh=ydsySNg3Q4jb9ZF8E2mxqDsppYBtg+mgK0htP0/P++8=; b=GeJ0m14BtIZMHrXqvwbe0Z/p+6eYj+E6y0Fx2XQshZ5+iMpYhPBoyv4TbjxVFeIaQNhI i8C0cmE8h6S7gzhJrreKDcpKVpQDPAhIDf5RIRutWSqjGSeJZmS3YQCO9E85gOX98T9A o/ra386jGX6Or5fx668kgQdvRdZBVX1DxQUMTn7Rfd+1L3HRz67ft13zrGAX3qDtMCcc BSPgEXBB6QiIMuWGNEzjPw7Y4Hwb/GGgPOXWgIID8K5N8PWMEyHBqjio4Oz0GtpXoooK kOtG0mA8EspRuIgG5KEIj6gjOrpTbm8zDVRU3TiAtkjIWKHIutSA5dNb33+MgAkiCUy3 bg== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3s08deu6j8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2023 12:47:31 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 36OClUmN000608 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2023 12:47:30 GMT Received: from hu-ipkumar-blr.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Mon, 24 Jul 2023 05:47:26 -0700 From: Praveenkumar I <quic_ipkumar@quicinc.com> To: <mani@kernel.org>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <lpieralisi@kernel.org>, <kw@linux.com>, <robh@kernel.org>, <bhelgaas@google.com>, <linux-pci@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <quic_varada@quicinc.com>, <quic_devipriy@quicinc.com> Subject: [PATCH 1/1] PCI: qcom: Add early fixup to set the max payload size for IPQ9574 Date: Mon, 24 Jul 2023 18:17:11 +0530 Message-ID: <20230724124711.2346886-2-quic_ipkumar@quicinc.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230724124711.2346886-1-quic_ipkumar@quicinc.com> References: <20230724124711.2346886-1-quic_ipkumar@quicinc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: qrwMwwu4YmBCpcOPEpZY0lXkGqd2xOFP X-Proofpoint-ORIG-GUID: qrwMwwu4YmBCpcOPEpZY0lXkGqd2xOFP X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-24_09,2023-07-24_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=771 spamscore=0 mlxscore=0 malwarescore=0 impostorscore=0 suspectscore=0 clxscore=1015 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307240113 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772308493124149897 X-GMAIL-MSGID: 1772309123337182262 |
Series |
Set may payload size for IPQ9574
|
|
Commit Message
Praveenkumar I
July 24, 2023, 12:47 p.m. UTC
Set 256 bytes as payload size for IPQ9574 via early fixup. This allows
PCIe RC to use the max payload size when a capable link partner is
connected.
Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
---
This patch depends on the below series which adds support for PCIe
controllers in IPQ9574
https://lore.kernel.org/linux-arm-msm/20230519090219.15925-1-quic_devipriy@quicinc.com/
drivers/pci/controller/dwc/pcie-qcom.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On 7/24/2023 6:23 PM, Konrad Dybcio wrote: > On 24.07.2023 14:47, Praveenkumar I wrote: >> Set 256 bytes as payload size for IPQ9574 via early fixup. This allows >> PCIe RC to use the max payload size when a capable link partner is >> connected. >> >> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> >> --- > [...] > >> +static void qcom_fixup_mps_256(struct pci_dev *dev) >> +{ >> + pcie_set_mps(dev, 256); > Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic > code take care of this. Yes, but that is not helping as the generic code pci_configure_mps() has a check for, / if (!bridge || !pci_is_pcie(bridge))/ / return;/ /Here it is returning and mps is not set to new 256 bytes./ > > Konrad -- Thanks, Praveenkumar
On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: > On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: > > On 24.07.2023 14:47, Praveenkumar I wrote: > > > Set 256 bytes as payload size for IPQ9574 via early fixup. This allows > > > PCIe RC to use the max payload size when a capable link partner is > > > connected. > > > > > > Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> > > > --- > > [...] > > > > > > > > +static void qcom_fixup_mps_256(struct pci_dev *dev) > > > +{ > > > + pcie_set_mps(dev, 256); > > Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic > > code take care of this. > > > > Right, also this setting should not be PCI-PCI bridge specific but rather > controller specific. > Wait, have you tested this patch with PCIe devices having MPS < 256 i.e., default 128? Take a look at this discussion: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ - Mani > - Mani > > > Konrad > > -- > மணிவண்ணன் சதாசிவம்
On 7/24/2023 7:39 PM, Manivannan Sadhasivam wrote: > On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: >> On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: >>> On 24.07.2023 14:47, Praveenkumar I wrote: >>>> Set 256 bytes as payload size for IPQ9574 via early fixup. This allows >>>> PCIe RC to use the max payload size when a capable link partner is >>>> connected. >>>> >>>> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> >>>> --- >>> [...] >>> >>>> +static void qcom_fixup_mps_256(struct pci_dev *dev) >>>> +{ >>>> + pcie_set_mps(dev, 256); >>> Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic >>> code take care of this. >>> >> Right, also this setting should not be PCI-PCI bridge specific but rather >> controller specific. >> > Wait, have you tested this patch with PCIe devices having MPS < 256 i.e., > default 128? > > Take a look at this discussion: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ > > - Mani Yes, tested this patch with PCIe devices having default 128 and RC is falling back to 128 when pci device is added. This is handled inside pci_configure_mps(). / mpss = 128 << dev->pcie_mpss;/ / if (mpss < p_mps && pci_pcie_type(bridge) == PCI_EXP_TYPE_ROOT_PORT) {/ / pcie_set_mps(bridge, mpss);/ / pci_info(dev, "Upstream bridge's Max Payload Size set to %d (was %d, max %d)\n",/ / mpss, p_mps, 128 << bridge->pcie_mpss);/ / p_mps = pcie_get_mps(bridge);/ / }/ // Also getting the below print, /[ 2.011963] pci 0003:01:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)/ >> - Mani >> >>> Konrad >> -- >> மணிவண்ணன் சதாசிவம் -- Thanks, Praveenkumar
On Tue, Jul 25, 2023 at 10:16:04AM +0530, Praveenkumar I wrote: > > On 7/24/2023 7:39 PM, Manivannan Sadhasivam wrote: > > On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: > > > On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: > > > > On 24.07.2023 14:47, Praveenkumar I wrote: > > > > > Set 256 bytes as payload size for IPQ9574 via early fixup. This allows > > > > > PCIe RC to use the max payload size when a capable link partner is > > > > > connected. > > > > > > > > > > Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> > > > > > --- > > > > [...] > > > > > > > > > +static void qcom_fixup_mps_256(struct pci_dev *dev) > > > > > +{ > > > > > + pcie_set_mps(dev, 256); > > > > Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic > > > > code take care of this. > > > > > > > Right, also this setting should not be PCI-PCI bridge specific but rather > > > controller specific. > > > > > Wait, have you tested this patch with PCIe devices having MPS < 256 i.e., > > default 128? > > > > Take a look at this discussion: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ > > > > - Mani > Yes, tested this patch with PCIe devices having default 128 and RC is > falling back to 128 when pci device is added. > This is handled inside pci_configure_mps(). > / mpss = 128 << dev->pcie_mpss;/ > / if (mpss < p_mps && pci_pcie_type(bridge) == > PCI_EXP_TYPE_ROOT_PORT) {/ > / pcie_set_mps(bridge, mpss);/ > / pci_info(dev, "Upstream bridge's Max Payload Size set to %d > (was %d, max %d)\n",/ > / mpss, p_mps, 128 << bridge->pcie_mpss);/ > / p_mps = pcie_get_mps(bridge);/ > / }/ > // > Also getting the below print, > /[ 2.011963] pci 0003:01:00.0: Upstream bridge's Max Payload Size set to > 128 (was 256, max 256)/ Ok. But for setting MPS, you need to change the DEVCTL register in post_init sequence for IPQ9574. It is not a quirk, so you cannot use fixups. - Mani > > > - Mani > > > > > > > Konrad > > > -- > > > மணிவண்ணன் சதாசிவம் > -- > Thanks, > Praveenkumar
On 7/25/2023 11:36 AM, Manivannan Sadhasivam wrote: > On Tue, Jul 25, 2023 at 10:16:04AM +0530, Praveenkumar I wrote: >> On 7/24/2023 7:39 PM, Manivannan Sadhasivam wrote: >>> On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: >>>> On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: >>>>> On 24.07.2023 14:47, Praveenkumar I wrote: >>>>>> Set 256 bytes as payload size for IPQ9574 via early fixup. This allows >>>>>> PCIe RC to use the max payload size when a capable link partner is >>>>>> connected. >>>>>> >>>>>> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> >>>>>> --- >>>>> [...] >>>>> >>>>>> +static void qcom_fixup_mps_256(struct pci_dev *dev) >>>>>> +{ >>>>>> + pcie_set_mps(dev, 256); >>>>> Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic >>>>> code take care of this. >>>>> >>>> Right, also this setting should not be PCI-PCI bridge specific but rather >>>> controller specific. >>>> >>> Wait, have you tested this patch with PCIe devices having MPS < 256 i.e., >>> default 128? >>> >>> Take a look at this discussion: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ >>> >>> - Mani >> Yes, tested this patch with PCIe devices having default 128 and RC is >> falling back to 128 when pci device is added. >> This is handled inside pci_configure_mps(). >> / mpss = 128 << dev->pcie_mpss;/ >> / if (mpss < p_mps && pci_pcie_type(bridge) == >> PCI_EXP_TYPE_ROOT_PORT) {/ >> / pcie_set_mps(bridge, mpss);/ >> / pci_info(dev, "Upstream bridge's Max Payload Size set to %d >> (was %d, max %d)\n",/ >> / mpss, p_mps, 128 << bridge->pcie_mpss);/ >> / p_mps = pcie_get_mps(bridge);/ >> / }/ >> // >> Also getting the below print, >> /[ 2.011963] pci 0003:01:00.0: Upstream bridge's Max Payload Size set to >> 128 (was 256, max 256)/ > Ok. But for setting MPS, you need to change the DEVCTL register in post_init > sequence for IPQ9574. It is not a quirk, so you cannot use fixups. Sure, will add in post_init of IPQ9574. -- Thanks, Praveenkumar > > - Mani > >>>> - Mani >>>> >>>>> Konrad >>>> -- >>>> மணிவண்ணன் சதாசிவம் >> -- >> Thanks, >> Praveenkumar
On 7/25/2023 11:36 AM, Manivannan Sadhasivam wrote: > On Tue, Jul 25, 2023 at 10:16:04AM +0530, Praveenkumar I wrote: >> On 7/24/2023 7:39 PM, Manivannan Sadhasivam wrote: >>> On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: >>>> On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: >>>>> On 24.07.2023 14:47, Praveenkumar I wrote: >>>>>> Set 256 bytes as payload size for IPQ9574 via early fixup. This allows >>>>>> PCIe RC to use the max payload size when a capable link partner is >>>>>> connected. >>>>>> >>>>>> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> >>>>>> --- >>>>> [...] >>>>> >>>>>> +static void qcom_fixup_mps_256(struct pci_dev *dev) >>>>>> +{ >>>>>> + pcie_set_mps(dev, 256); >>>>> Looks like setting "dev->pcie_mpss = 1" here would make the PCIe generic >>>>> code take care of this. >>>>> >>>> Right, also this setting should not be PCI-PCI bridge specific but rather >>>> controller specific. >>>> >>> Wait, have you tested this patch with PCIe devices having MPS < 256 i.e., >>> default 128? >>> >>> Take a look at this discussion: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ >>> >>> - Mani >> Yes, tested this patch with PCIe devices having default 128 and RC is >> falling back to 128 when pci device is added. >> This is handled inside pci_configure_mps(). >> / mpss = 128 << dev->pcie_mpss;/ >> / if (mpss < p_mps && pci_pcie_type(bridge) == >> PCI_EXP_TYPE_ROOT_PORT) {/ >> / pcie_set_mps(bridge, mpss);/ >> / pci_info(dev, "Upstream bridge's Max Payload Size set to %d >> (was %d, max %d)\n",/ >> / mpss, p_mps, 128 << bridge->pcie_mpss);/ >> / p_mps = pcie_get_mps(bridge);/ >> / }/ >> // >> Also getting the below print, >> /[ 2.011963] pci 0003:01:00.0: Upstream bridge's Max Payload Size set to >> 128 (was 256, max 256)/ > Ok. But for setting MPS, you need to change the DEVCTL register in post_init > sequence for IPQ9574. It is not a quirk, so you cannot use fixups. Sorry, if I do so, then the above mentioned issue will come here as well right? This one: https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ > - Mani > >>>> - Mani >>>> >>>>> Konrad >>>> -- >>>> மணிவண்ணன் சதாசிவம் >> -- >> Thanks, >> Praveenkumar
On 7/26/2023 2:52 PM, Praveenkumar I wrote: > > On 7/25/2023 11:36 AM, Manivannan Sadhasivam wrote: >> On Tue, Jul 25, 2023 at 10:16:04AM +0530, Praveenkumar I wrote: >>> On 7/24/2023 7:39 PM, Manivannan Sadhasivam wrote: >>>> On Mon, Jul 24, 2023 at 06:38:55PM +0530, Manivannan Sadhasivam wrote: >>>>> On Mon, Jul 24, 2023 at 02:53:37PM +0200, Konrad Dybcio wrote: >>>>>> On 24.07.2023 14:47, Praveenkumar I wrote: >>>>>>> Set 256 bytes as payload size for IPQ9574 via early fixup. This >>>>>>> allows >>>>>>> PCIe RC to use the max payload size when a capable link partner is >>>>>>> connected. >>>>>>> >>>>>>> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> >>>>>>> --- >>>>>> [...] >>>>>> >>>>>>> +static void qcom_fixup_mps_256(struct pci_dev *dev) >>>>>>> +{ >>>>>>> + pcie_set_mps(dev, 256); >>>>>> Looks like setting "dev->pcie_mpss = 1" here would make the PCIe >>>>>> generic >>>>>> code take care of this. >>>>>> >>>>> Right, also this setting should not be PCI-PCI bridge specific but >>>>> rather >>>>> controller specific. >>>>> >>>> Wait, have you tested this patch with PCIe devices having MPS < 256 >>>> i.e., >>>> default 128? >>>> >>>> Take a look at this discussion: >>>> https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ >>>> >>>> >>>> - Mani >>> Yes, tested this patch with PCIe devices having default 128 and RC is >>> falling back to 128 when pci device is added. >>> This is handled inside pci_configure_mps(). >>> / mpss = 128 << dev->pcie_mpss;/ >>> / if (mpss < p_mps && pci_pcie_type(bridge) == >>> PCI_EXP_TYPE_ROOT_PORT) {/ >>> / pcie_set_mps(bridge, mpss);/ >>> / pci_info(dev, "Upstream bridge's Max Payload Size >>> set to %d >>> (was %d, max %d)\n",/ >>> / mpss, p_mps, 128 << bridge->pcie_mpss);/ >>> / p_mps = pcie_get_mps(bridge);/ >>> / }/ >>> // >>> Also getting the below print, >>> /[ 2.011963] pci 0003:01:00.0: Upstream bridge's Max Payload Size >>> set to >>> 128 (was 256, max 256)/ >> Ok. But for setting MPS, you need to change the DEVCTL register in >> post_init >> sequence for IPQ9574. It is not a quirk, so you cannot use fixups. > Sorry, if I do so, then the above mentioned issue will come here as > well right? > > This one: > https://lore.kernel.org/all/20230608093652.1409485-1-vidyas@nvidia.com/ Sorry, confused a bit here. After moving the MPS setting to post_init, pci_configure_mps() is taking care if 128 byte PCIe device is connected. Posted a updated patch. - Praveenkumar > >> - Mani >> >>>>> - Mani >>>>> >>>>>> Konrad >>>>> -- >>>>> மணிவண்ணன் சதாசிவம் >>> -- >>> Thanks, >>> Praveenkumar
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index cee4e400a695..6695bc3b122f 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1631,6 +1631,11 @@ static void qcom_fixup_class(struct pci_dev *dev) { dev->class = PCI_CLASS_BRIDGE_PCI_NORMAL; } + +static void qcom_fixup_mps_256(struct pci_dev *dev) +{ + pcie_set_mps(dev, 256); +} DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0101, qcom_fixup_class); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0104, qcom_fixup_class); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0106, qcom_fixup_class); @@ -1638,6 +1643,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0107, qcom_fixup_class); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0302, qcom_fixup_class); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1000, qcom_fixup_class); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1001, qcom_fixup_class); +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1108, qcom_fixup_mps_256); static const struct dev_pm_ops qcom_pcie_pm_ops = { NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_suspend_noirq, qcom_pcie_resume_noirq)