Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: "Wenbin Yao (Consultant)" <quic_wenbyao@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <vkoul@kernel.org>, <kishon@kernel.org>, <p.zabel@pengutronix.de>,
	<abel.vesa@linaro.org>, <quic_qianyu@quicinc.com>,
	<neil.armstrong@linaro.org>, <manivannan.sadhasivam@linaro.org>,
	<quic_devipriy@quicinc.com>, <konrad.dybcio@oss.qualcomm.com>,
	<linux-arm-msm@vger.kernel.org>, <linux-phy@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add PHY register retention support
Date: Wed, 22 Jan 2025 15:17:39 +0800	[thread overview]
Message-ID: <a2cc5a5a-6cbd-7564-a8df-8af2a652de2f@quicinc.com> (raw)
In-Reply-To: <CAA8EJppXQpDrdXzJsTE7HWs=POt7yFAw0JVZFabN6Ks3fhZiWQ@mail.gmail.com>

On 1/21/2025 6:36 PM, Dmitry Baryshkov wrote:
> On Tue, 21 Jan 2025 at 11:43, Wenbin Yao <quic_wenbyao@quicinc.com> wrote:
>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>
>> Currently, BCR reset and PHY register setting are mandatory for every port
>> before link training. However, some QCOM PCIe PHYs support no_csr reset.
>> Different than BCR reset that is used to reset entire PHY including
>> hardware and register, once no_csr reset is toggled, only PHY hardware will
>> be reset but PHY registers will be retained,
> I'm sorry, I can't parse this.
The difference between no_csr reset and bcr reset is that no_csr reset
doesn't reset the phy registers. If a phy is enabled in UEFI, its registers
are programed. After Linux boot up, the registers will not be reset but
keep the value programmed by UEFI if we only do no_csr reset, so we can
skip phy setting.
>
>> which means PHY setting can
>> be skipped during PHY init if PCIe link was enabled in booltloader and only
>> no_csr is toggled after that.
>>
>> Hence, determine whether the PHY has been enabled in bootloader by
>> verifying QPHY_START_CTRL register. If it is programmed and no_csr reset is
>> present, skip BCR reset and PHY register setting, so that PCIe link can be
>> established with no_csr reset only.
> This doesn't tell us why we want to do so. The general rule is not to
> depend on the bootloaders at all. The reason is pretty simple: it is
> hard to update bootloaders, while it is relatively easy to update the
> kernel. If the hardware team issues any kind of changes to the
> programming tables, the kernel will get them earlier than the
> bootloader.
With this change, we don't need to upstream phy setting for all phys
support no_csr reset, this will save a great deal of efforts and simplify
the phy driver. Our goal is to remove proprietary PCIe firmware operations
from kernel. PHY is just the start and will be followed by controller,
clocks, regulators, etc. If program table need to be changed, the place to
do that will be UEFI.
>
>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
>> ---
>>   drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 91 +++++++++++++++---------
>>   1 file changed, 58 insertions(+), 33 deletions(-)
>>

  reply	other threads:[~2025-01-22  7:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-21  9:41 [PATCH 0/2] phy: qcom: qmp-pcie: Add PCIe PHY no_csr reset support Wenbin Yao
2025-01-21  9:41 ` [PATCH 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically Wenbin Yao
2025-01-21  9:55   ` Abel Vesa
2025-01-24  7:10   ` Manivannan Sadhasivam
2025-01-21  9:41 ` [PATCH 2/2] phy: qcom: qmp-pcie: Add PHY register retention support Wenbin Yao
2025-01-21 10:36   ` Dmitry Baryshkov
2025-01-22  7:17     ` Wenbin Yao (Consultant) [this message]
2025-01-22  9:43       ` Dmitry Baryshkov
2025-01-24  6:22         ` Qiang Yu
2025-01-24  7:08           ` Manivannan Sadhasivam
2025-01-25 13:10             ` Konrad Dybcio
2025-01-29  8:29               ` neil.armstrong
2025-01-29 11:29                 ` Konrad Dybcio
2025-01-29 13:41                   ` neil.armstrong
2025-01-29 13:55                     ` Konrad Dybcio
2025-01-29 14:19                       ` neil.armstrong
2025-02-08  2:24                         ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2cc5a5a-6cbd-7564-a8df-8af2a652de2f@quicinc.com \
    --to=quic_wenbyao@quicinc.com \
    --cc=abel.vesa@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=quic_devipriy@quicinc.com \
    --cc=quic_qianyu@quicinc.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox