[PATCH 2/2] phy: qcom: qmp-pcie: Add PHY register retention support

[neil.armstrong at linaro.org]

On 25/01/2025 14:10, Konrad Dybcio wrote:
> On 24.01.2025 8:08 AM, Manivannan Sadhasivam wrote:
>> + Mayank (with whom I discussed this topic internally)
>>
>> On Fri, Jan 24, 2025 at 02:22:01PM +0800, Qiang Yu wrote:
>>>
>>> On 1/22/2025 5:43 PM, Dmitry Baryshkov wrote:
>>>> On Wed, Jan 22, 2025 at 03:17:39PM +0800, Wenbin Yao (Consultant) wrote:
>>>>> On 1/21/2025 6:36 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, 21 Jan 2025 at 11:43, Wenbin Yao <quic_wenbyao at quicinc.com> wrote:
>>>>>>> From: Qiang Yu <quic_qianyu at 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.
>>>> Please fix capitalization of the abbreviations (PHY, BCR) and add
>>>> similar text to the commit message.
>>>>
>>>>>>> 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.
> 
> We're assuming that if a product has shipped, the sequences used to power up
> the PHY in the bootloader (e.g. for NVMe) are already good.
> 
> If some tragedy happens and an erratum is needed, we can always introduce a
> small override with the existing driver infrastructure (i.e. adding a new
> entry with a couple registers worth of programming sequence, leaving the other
> values in tact)

Assuming Linux will be always ran directly after the bootloader is a wild assumption.

Yes, we should make use the noscr if the PHY is always programmed, but we should be
always able to reprogram the PHY entirely to recover a faulty programmation.

Neil


<snip>