linux-kernel - Re: [PATCH v3 3/3] PCI: qcom: Add rx margining settings for 16GT/s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53c0e508-60fe-ee5d-cb2b-a5392c330377@quicinc.com>
Date: Tue, 30 Apr 2024 13:37:50 -0700
From: Shashank Babu Chinta Venkata <quic_schintav@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>, <agross@...nel.org>,
        <andersson@...nel.org>, <mani@...nel.org>
CC: <quic_msarkar@...cinc.com>, <quic_kraravin@...cinc.com>,
        Lorenzo Pieralisi
	<lpieralisi@...nel.org>,
        Krzysztof Wilczyński
	<kw@...ux.com>,
        Rob Herring <robh@...nel.org>, Bjorn Helgaas
	<bhelgaas@...gle.com>,
        Jingoo Han <jingoohan1@...il.com>,
        Gustavo Pimentel
	<gustavo.pimentel@...opsys.com>,
        Manivannan Sadhasivam
	<manivannan.sadhasivam@...aro.org>,
        Serge Semin <fancer.lancer@...il.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Conor Dooley
	<conor.dooley@...rochip.com>,
        <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] PCI: qcom: Add rx margining settings for 16GT/s



On 4/22/24 15:58, Konrad Dybcio wrote:
> 
> 
> On 4/19/24 02:09, Shashank Babu Chinta Venkata wrote:
>> Add rx lane margining settings for 16GT/s(GEN 4) data rate. These
>> settings improve link stability while operating at high date rates
>> and helps to improve signal quality.
>>
>> Signed-off-by: Shashank Babu Chinta Venkata <quic_schintav@...cinc.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-designware.h  | 18 ++++++++++++++
>>   drivers/pci/controller/dwc/pcie-qcom-common.c | 24 +++++++++++++++++++
>>   drivers/pci/controller/dwc/pcie-qcom-common.h |  1 +
>>   drivers/pci/controller/dwc/pcie-qcom-ep.c     |  4 +++-
>>   drivers/pci/controller/dwc/pcie-qcom.c        |  4 +++-
>>   5 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
>> index ad771bb52d29..e8c48855143f 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -203,6 +203,24 @@
>>     #define PCIE_PL_CHK_REG_ERR_ADDR            0xB28
>>   +/*
>> + * GEN4 lane margining register definitions
>> + */
>> +#define GEN4_LANE_MARGINING_1_OFF        0xb80
>> +#define MARGINING_MAX_VOLTAGE_OFFSET(n)        FIELD_PREP(GENMASK(29, 24), n)
>> +#define MARGINING_NUM_VOLTAGE_STEPS(n)        FIELD_PREP(GENMASK(22, 16), n)
>> +#define MARGINING_MAX_TIMING_OFFSET(n)        FIELD_PREP(GENMASK(13, 8), n)
>> +#define MARGINING_NUM_TIMING_STEPS(n)        FIELD_PREP(GENMASK(5, 0), n)
>> +
>> +#define GEN4_LANE_MARGINING_2_OFF        0xb84
>> +#define MARGINING_IND_ERROR_SAMPLER(n)        FIELD_PREP(BIT(28), n)
>> +#define MARGINING_SAMPLE_REPORTING_METHOD(n)    FIELD_PREP(BIT(27), n)
>> +#define MARGINING_IND_LEFT_RIGHT_TIMING(n)    FIELD_PREP(BIT(26), n)
>> +#define MARGINING_IND_UP_DOWN_VOLTAGE(n)    FIELD_PREP(BIT(25), n)
>> +#define MARGINING_VOLTAGE_SUPPORTED(n)        FIELD_PREP(BIT(24), n)
>> +#define MARGINING_MAXLANES(n)            FIELD_PREP(GENMASK(20, 16), n)
>> +#define MARGINING_SAMPLE_RATE_TIMING(n)        FIELD_PREP(GENMASK(13, 8), n)
>> +#define MARGINING_SAMPLE_RATE_VOLTAGE(n)    FIELD_PREP(GENMASK(5, 0), n)
> 
> That's a.. rather unusual.. use of FIELD_/GENMASK.. Usually, the fields are
> defined with GENMASK and then referenced through FIELD_xyz(BITFIELD_NAME, val)
> 
> That said, I'm not entirely against this if Mani is ok with it
will fall back to conventional approach in my next series to avoid confusion.
> 
>>   /*
>>    * iATU Unroll-specific register definitions
>>    * From 4.80 core version the address translation will be made by unroll
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom-common.c b/drivers/pci/controller/dwc/pcie-qcom-common.c
>> index a6f3eb4c3ee6..3279314ae78c 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom-common.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom-common.c
>> @@ -46,6 +46,30 @@ void qcom_pcie_common_set_16gt_eq_settings(struct dw_pcie *pci)
>>   }
>>   EXPORT_SYMBOL_GPL(qcom_pcie_common_set_16gt_eq_settings);
>>   +void qcom_pcie_common_set_16gt_rx_margining_settings(struct dw_pcie *pci)
>> +{
>> +    u32 reg;
>> +
>> +    reg = dw_pcie_readl_dbi(pci, GEN4_LANE_MARGINING_1_OFF);
>> +    reg = MARGINING_MAX_VOLTAGE_OFFSET(0x24) |
>> +        MARGINING_NUM_VOLTAGE_STEPS(0x78) |
>> +        MARGINING_MAX_TIMING_OFFSET(0x32) |
>> +        MARGINING_NUM_TIMING_STEPS(0x10);
>> +    dw_pcie_writel_dbi(pci, GEN4_LANE_MARGINING_1_OFF, reg);
> 
> Since this is DW-common, why is this inside the qcom driver?
Though this register space is in dw-common specific, these settings are purely vendor specific . These settings are determined by systems team on vendor hardware, as these settings are used as margin to compensate signal variance due to various physical factors(like connection length, retimers etc).
> 
> Konrad