X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP
version 1.38.0.
Currently the ops_1_9_0 which is being used for X1E80100 has config_sid
callback to config BDF to SID table. However, this callback is not
required for X1E80100 because it has smmuv3 support and BDF to SID table
will be not present.
Hence add support for X1E80100 by introducing a new ops and cfg structures
that don't require the config_sid callback. This could be reused by the
future platforms based on SMMUv3.
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
---
drivers/pci/controller/dwc/pcie-qcom.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 88a98be930e3..56ba8bc72f78 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1367,6 +1367,16 @@ static const struct qcom_pcie_ops ops_2_9_0 = {
.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
};
+/* Qcom IP rev.: 1.38.0 */
+static const struct qcom_pcie_ops ops_1_38_0 = {
+ .get_resources = qcom_pcie_get_resources_2_7_0,
+ .init = qcom_pcie_init_2_7_0,
+ .post_init = qcom_pcie_post_init_2_7_0,
+ .host_post_init = qcom_pcie_host_post_init_2_7_0,
+ .deinit = qcom_pcie_deinit_2_7_0,
+ .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
+};
+
static const struct qcom_pcie_cfg cfg_1_0_0 = {
.ops = &ops_1_0_0,
};
@@ -1409,6 +1419,10 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
.no_l0s = true,
};
+static const struct qcom_pcie_cfg cfg_1_38_0 = {
+ .ops = &ops_1_38_0,
+};
+
static const struct dw_pcie_ops dw_pcie_ops = {
.link_up = qcom_pcie_link_up,
.start_link = qcom_pcie_start_link,
@@ -1837,7 +1851,7 @@ static const struct of_device_id qcom_pcie_match[] = {
{ .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
{ .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
{ .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
- { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_9_0 },
+ { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_38_0 },
{ }
};
--
2.34.1On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote:
> X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP
> version 1.38.0.
>
> Currently the ops_1_9_0 which is being used for X1E80100 has config_sid
> callback to config BDF to SID table. However, this callback is not
> required for X1E80100 because it has smmuv3 support and BDF to SID table
> will be not present.
>
> Hence add support for X1E80100 by introducing a new ops and cfg structures
> that don't require the config_sid callback. This could be reused by the
> future platforms based on SMMUv3.
>
Oops... I completely overlooked that you are not adding the SoC support but
fixing the existing one :( Sorry for suggesting a commit message that changed
the context.
For this, you can have something like:
"PCI: qcom: Fix the ops for X1E80100 SoC
X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping
present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops
'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the
1_9_0 ones, but they don't have the 'config_sid()' callback that handles the
BDF2SID mapping in the hardware. These new structures could also be used by the
future SoCs making use of SMMUv3."
- Mani
> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 88a98be930e3..56ba8bc72f78 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1367,6 +1367,16 @@ static const struct qcom_pcie_ops ops_2_9_0 = {
> .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
> };
>
> +/* Qcom IP rev.: 1.38.0 */
> +static const struct qcom_pcie_ops ops_1_38_0 = {
> + .get_resources = qcom_pcie_get_resources_2_7_0,
> + .init = qcom_pcie_init_2_7_0,
> + .post_init = qcom_pcie_post_init_2_7_0,
> + .host_post_init = qcom_pcie_host_post_init_2_7_0,
> + .deinit = qcom_pcie_deinit_2_7_0,
> + .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
> +};
> +
> static const struct qcom_pcie_cfg cfg_1_0_0 = {
> .ops = &ops_1_0_0,
> };
> @@ -1409,6 +1419,10 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
> .no_l0s = true,
> };
>
> +static const struct qcom_pcie_cfg cfg_1_38_0 = {
> + .ops = &ops_1_38_0,
> +};
> +
> static const struct dw_pcie_ops dw_pcie_ops = {
> .link_up = qcom_pcie_link_up,
> .start_link = qcom_pcie_start_link,
> @@ -1837,7 +1851,7 @@ static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
> { .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
> { .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
> - { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_9_0 },
> + { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_38_0 },
> { }
> };
>
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
On 9/24/2024 9:50 PM, Manivannan Sadhasivam wrote:
> On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote:
>> X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP
>> version 1.38.0.
>>
>> Currently the ops_1_9_0 which is being used for X1E80100 has config_sid
>> callback to config BDF to SID table. However, this callback is not
>> required for X1E80100 because it has smmuv3 support and BDF to SID table
>> will be not present.
>>
>> Hence add support for X1E80100 by introducing a new ops and cfg structures
>> that don't require the config_sid callback. This could be reused by the
>> future platforms based on SMMUv3.
>>
> Oops... I completely overlooked that you are not adding the SoC support but
> fixing the existing one :( Sorry for suggesting a commit message that changed
> the context.
>
> For this, you can have something like:
>
> "PCI: qcom: Fix the ops for X1E80100 SoC
>
> X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping
> present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops
> 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the
> 1_9_0 ones, but they don't have the 'config_sid()' callback that handles the
> BDF2SID mapping in the hardware. These new structures could also be used by the
> future SoCs making use of SMMUv3."
Never mind, thanks for your suggestions. Will update the commit msg in next
version.
Thanks,
Qiang Yu
>
> - Mani
>
>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
>> ---
>> drivers/pci/controller/dwc/pcie-qcom.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index 88a98be930e3..56ba8bc72f78 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -1367,6 +1367,16 @@ static const struct qcom_pcie_ops ops_2_9_0 = {
>> .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
>> };
>>
>> +/* Qcom IP rev.: 1.38.0 */
>> +static const struct qcom_pcie_ops ops_1_38_0 = {
>> + .get_resources = qcom_pcie_get_resources_2_7_0,
>> + .init = qcom_pcie_init_2_7_0,
>> + .post_init = qcom_pcie_post_init_2_7_0,
>> + .host_post_init = qcom_pcie_host_post_init_2_7_0,
>> + .deinit = qcom_pcie_deinit_2_7_0,
>> + .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
>> +};
>> +
>> static const struct qcom_pcie_cfg cfg_1_0_0 = {
>> .ops = &ops_1_0_0,
>> };
>> @@ -1409,6 +1419,10 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
>> .no_l0s = true,
>> };
>>
>> +static const struct qcom_pcie_cfg cfg_1_38_0 = {
>> + .ops = &ops_1_38_0,
>> +};
>> +
>> static const struct dw_pcie_ops dw_pcie_ops = {
>> .link_up = qcom_pcie_link_up,
>> .start_link = qcom_pcie_start_link,
>> @@ -1837,7 +1851,7 @@ static const struct of_device_id qcom_pcie_match[] = {
>> { .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
>> { .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
>> { .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
>> - { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_9_0 },
>> + { .compatible = "qcom,pcie-x1e80100", .data = &cfg_1_38_0 },
>> { }
>> };
>>
>> --
>> 2.34.1
>>
On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: > On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: > > X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP > > version 1.38.0. > > > > Currently the ops_1_9_0 which is being used for X1E80100 has config_sid > > callback to config BDF to SID table. However, this callback is not > > required for X1E80100 because it has smmuv3 support and BDF to SID table > > will be not present. > > > > Hence add support for X1E80100 by introducing a new ops and cfg structures > > that don't require the config_sid callback. This could be reused by the > > future platforms based on SMMUv3. > > > > Oops... I completely overlooked that you are not adding the SoC support but > fixing the existing one :( Sorry for suggesting a commit message that changed > the context. > > For this, you can have something like: > > "PCI: qcom: Fix the ops for X1E80100 SoC > > X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping > present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops > 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the > 1_9_0 ones, but they don't have the 'config_sid()' callback that handles the > BDF2SID mapping in the hardware. These new structures could also be used by the > future SoCs making use of SMMUv3." Don't we need something like this for sc8280xp and other platforms using SMMUv3 as well? Johan
On 9/24/2024 11:17 PM, Johan Hovold wrote: > On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: >> On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: >>> X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP >>> version 1.38.0. >>> >>> Currently the ops_1_9_0 which is being used for X1E80100 has config_sid >>> callback to config BDF to SID table. However, this callback is not >>> required for X1E80100 because it has smmuv3 support and BDF to SID table >>> will be not present. >>> >>> Hence add support for X1E80100 by introducing a new ops and cfg structures >>> that don't require the config_sid callback. This could be reused by the >>> future platforms based on SMMUv3. >>> >> Oops... I completely overlooked that you are not adding the SoC support but >> fixing the existing one :( Sorry for suggesting a commit message that changed >> the context. >> >> For this, you can have something like: >> >> "PCI: qcom: Fix the ops for X1E80100 SoC >> >> X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping >> present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops >> 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the >> 1_9_0 ones, but they don't have the 'config_sid()' callback that handles the >> BDF2SID mapping in the hardware. These new structures could also be used by the >> future SoCs making use of SMMUv3." > Don't we need something like this for sc8280xp and other platforms using > SMMUv3 as well? From what I know, sc8280xp and other qcom platforms are not using SMMUv3. X1E80100 and newer platforms will use SMMUv3. Thanks, Qiang > > Johan
On Wed, Sep 25, 2024 at 11:47:02AM +0800, Qiang Yu wrote: > > On 9/24/2024 11:17 PM, Johan Hovold wrote: > > On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: > > > On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: > > > > X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP > > > > version 1.38.0. > > > > > > > > Currently the ops_1_9_0 which is being used for X1E80100 has config_sid > > > > callback to config BDF to SID table. However, this callback is not > > > > required for X1E80100 because it has smmuv3 support and BDF to SID table > > > > will be not present. > > > > > > > > Hence add support for X1E80100 by introducing a new ops and cfg structures > > > > that don't require the config_sid callback. This could be reused by the > > > > future platforms based on SMMUv3. > > > > > > > Oops... I completely overlooked that you are not adding the SoC support but > > > fixing the existing one :( Sorry for suggesting a commit message that changed > > > the context. > > > > > > For this, you can have something like: > > > > > > "PCI: qcom: Fix the ops for X1E80100 SoC > > > > > > X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping > > > present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops > > > 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the > > > 1_9_0 ones, but they don't have the 'config_sid()' callback that handles the > > > BDF2SID mapping in the hardware. These new structures could also be used by the > > > future SoCs making use of SMMUv3." > > Don't we need something like this for sc8280xp and other platforms using > > SMMUv3 as well? > From what I know, sc8280xp and other qcom platforms are not using SMMUv3. sc8280xp indeed has SMMUv3 for PCIe, but I'm not sure how it is configured. So not completely sure whether we can avoid the mapping table or not. Qiang, please check with the hw team and let us know. - Mani -- மணிவண்ணன் சதாசிவம்
On 9/25/2024 4:07 PM, Manivannan Sadhasivam wrote: > On Wed, Sep 25, 2024 at 11:47:02AM +0800, Qiang Yu wrote: >> On 9/24/2024 11:17 PM, Johan Hovold wrote: >>> On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: >>>> On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: >>>>> X1E80100 has PCIe ports that support up to Gen4 x8 based on hardware IP >>>>> version 1.38.0. >>>>> >>>>> Currently the ops_1_9_0 which is being used for X1E80100 has config_sid >>>>> callback to config BDF to SID table. However, this callback is not >>>>> required for X1E80100 because it has smmuv3 support and BDF to SID table >>>>> will be not present. >>>>> >>>>> Hence add support for X1E80100 by introducing a new ops and cfg structures >>>>> that don't require the config_sid callback. This could be reused by the >>>>> future platforms based on SMMUv3. >>>>> >>>> Oops... I completely overlooked that you are not adding the SoC support but >>>> fixing the existing one :( Sorry for suggesting a commit message that changed >>>> the context. >>>> >>>> For this, you can have something like: >>>> >>>> "PCI: qcom: Fix the ops for X1E80100 SoC >>>> >>>> X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID mapping >>>> present in the existing cfg_1_9_0 ops. This is fixed by introducing new ops >>>> 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly same as the >>>> 1_9_0 ones, but they don't have the 'config_sid()' callback that handles the >>>> BDF2SID mapping in the hardware. These new structures could also be used by the >>>> future SoCs making use of SMMUv3." >>> Don't we need something like this for sc8280xp and other platforms using >>> SMMUv3 as well? >> From what I know, sc8280xp and other qcom platforms are not using SMMUv3. > sc8280xp indeed has SMMUv3 for PCIe, but I'm not sure how it is configured. So > not completely sure whether we can avoid the mapping table or not. > > Qiang, please check with the hw team and let us know. Sure, will update once I get any response from hw team. Thanks, Qiang > > - Mani >
On 9/26/2024 11:28 AM, Qiang Yu wrote: > > On 9/25/2024 4:07 PM, Manivannan Sadhasivam wrote: >> On Wed, Sep 25, 2024 at 11:47:02AM +0800, Qiang Yu wrote: >>> On 9/24/2024 11:17 PM, Johan Hovold wrote: >>>> On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: >>>>> On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: >>>>>> X1E80100 has PCIe ports that support up to Gen4 x8 based on >>>>>> hardware IP >>>>>> version 1.38.0. >>>>>> >>>>>> Currently the ops_1_9_0 which is being used for X1E80100 has >>>>>> config_sid >>>>>> callback to config BDF to SID table. However, this callback is not >>>>>> required for X1E80100 because it has smmuv3 support and BDF to >>>>>> SID table >>>>>> will be not present. >>>>>> >>>>>> Hence add support for X1E80100 by introducing a new ops and cfg >>>>>> structures >>>>>> that don't require the config_sid callback. This could be reused >>>>>> by the >>>>>> future platforms based on SMMUv3. >>>>>> >>>>> Oops... I completely overlooked that you are not adding the SoC >>>>> support but >>>>> fixing the existing one :( Sorry for suggesting a commit message >>>>> that changed >>>>> the context. >>>>> >>>>> For this, you can have something like: >>>>> >>>>> "PCI: qcom: Fix the ops for X1E80100 SoC >>>>> >>>>> X1E80100 SoC is based on SMMUv3, hence it doesn't need the BDF2SID >>>>> mapping >>>>> present in the existing cfg_1_9_0 ops. This is fixed by >>>>> introducing new ops >>>>> 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are exactly >>>>> same as the >>>>> 1_9_0 ones, but they don't have the 'config_sid()' callback that >>>>> handles the >>>>> BDF2SID mapping in the hardware. These new structures could also >>>>> be used by the >>>>> future SoCs making use of SMMUv3." >>>> Don't we need something like this for sc8280xp and other platforms >>>> using >>>> SMMUv3 as well? >>> From what I know, sc8280xp and other qcom platforms are not using >>> SMMUv3. >> sc8280xp indeed has SMMUv3 for PCIe, but I'm not sure how it is >> configured. So >> not completely sure whether we can avoid the mapping table or not. >> >> Qiang, please check with the hw team and let us know. > Sure, will update once I get any response from hw team. HW team confirmed sc8280xp uses smmv3 for PCIe and doesn't support BDF2SID map. Besides, Abel once got confirmation from Joe that we also need to disable L0s for X1E80100. So can we use cfg_sc8280xp for both X1E80100 and SC8280XP and change its ops to ops_1_38_0? Thanks, Qiang > > Thanks, > Qiang >> >> - Mani >>
On Thu, Sep 26, 2024 at 01:19:18PM +0800, Qiang Yu wrote: > > On 9/26/2024 11:28 AM, Qiang Yu wrote: > > > > On 9/25/2024 4:07 PM, Manivannan Sadhasivam wrote: > > > On Wed, Sep 25, 2024 at 11:47:02AM +0800, Qiang Yu wrote: > > > > On 9/24/2024 11:17 PM, Johan Hovold wrote: > > > > > On Tue, Sep 24, 2024 at 03:50:21PM +0200, Manivannan Sadhasivam wrote: > > > > > > On Tue, Sep 24, 2024 at 03:14:43AM -0700, Qiang Yu wrote: > > > > > > > X1E80100 has PCIe ports that support up to Gen4 x8 > > > > > > > based on hardware IP > > > > > > > version 1.38.0. > > > > > > > > > > > > > > Currently the ops_1_9_0 which is being used for > > > > > > > X1E80100 has config_sid > > > > > > > callback to config BDF to SID table. However, this callback is not > > > > > > > required for X1E80100 because it has smmuv3 support > > > > > > > and BDF to SID table > > > > > > > will be not present. > > > > > > > > > > > > > > Hence add support for X1E80100 by introducing a new > > > > > > > ops and cfg structures > > > > > > > that don't require the config_sid callback. This > > > > > > > could be reused by the > > > > > > > future platforms based on SMMUv3. > > > > > > > > > > > > > Oops... I completely overlooked that you are not adding > > > > > > the SoC support but > > > > > > fixing the existing one :( Sorry for suggesting a commit > > > > > > message that changed > > > > > > the context. > > > > > > > > > > > > For this, you can have something like: > > > > > > > > > > > > "PCI: qcom: Fix the ops for X1E80100 SoC > > > > > > > > > > > > X1E80100 SoC is based on SMMUv3, hence it doesn't need > > > > > > the BDF2SID mapping > > > > > > present in the existing cfg_1_9_0 ops. This is fixed by > > > > > > introducing new ops > > > > > > 'ops_1_38_0' and cfg 'cfg_1_38_0' structures. These are > > > > > > exactly same as the > > > > > > 1_9_0 ones, but they don't have the 'config_sid()' > > > > > > callback that handles the > > > > > > BDF2SID mapping in the hardware. These new structures > > > > > > could also be used by the > > > > > > future SoCs making use of SMMUv3." > > > > > Don't we need something like this for sc8280xp and other > > > > > platforms using > > > > > SMMUv3 as well? > > > > From what I know, sc8280xp and other qcom platforms are not > > > > using SMMUv3. > > > sc8280xp indeed has SMMUv3 for PCIe, but I'm not sure how it is > > > configured. So > > > not completely sure whether we can avoid the mapping table or not. > > > > > > Qiang, please check with the hw team and let us know. > > Sure, will update once I get any response from hw team. > HW team confirmed sc8280xp uses smmv3 for PCIe and doesn't support BDF2SID > map. > > Besides, Abel once got confirmation from Joe that we also need to disable > L0s for X1E80100. So can we use cfg_sc8280xp for both X1E80100 and SC8280XP > and change its ops to ops_1_38_0? > Sounds good. But, OPS naming should be based on the baseline version i.e., it should be based on the IP version of SC8280XP and reused by X1E80100. Not the other way around. - Mani > Thanks, > Qiang > > > > Thanks, > > Qiang > > > > > > - Mani > > > -- மணிவண்ணன் சதாசிவம்
© 2016 - 2024 Red Hat, Inc.