Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-08-05 Thread Bjorn Andersson
On Fri 19 Jul 08:50 PDT 2019, Marc Gonzalez wrote: > On 13/06/2019 11:10, Marc Gonzalez wrote: > > > Here are my observations for a 8998 board: > > > > 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready > > fixup) > > qcom_pcie_probe() fails with a timeout in phy_init. > >

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-08-02 Thread Marc Gonzalez
On 23/07/2019 12:31, Marc Gonzalez wrote: > On 19/07/2019 17:50, Marc Gonzalez wrote: > >> On 13/06/2019 11:10, Marc Gonzalez wrote: >> >>> Here are my observations for a 8998 board: >>> >>> 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready >>> fixup) >>> qcom_pcie_probe()

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-07-23 Thread Marc Gonzalez
On 19/07/2019 17:50, Marc Gonzalez wrote: > On 13/06/2019 11:10, Marc Gonzalez wrote: > >> Here are my observations for a 8998 board: >> >> 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready >> fixup) >> qcom_pcie_probe() fails with a timeout in phy_init. >> => this is in

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-07-19 Thread Marc Gonzalez
On 13/06/2019 11:10, Marc Gonzalez wrote: > Here are my observations for a 8998 board: > > 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready fixup) > qcom_pcie_probe() fails with a timeout in phy_init. > => this is in line with your regression analysis. > > 2) Your patch

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-19 Thread Marc Gonzalez
On 13/06/2019 11:10, Marc Gonzalez wrote: > Here are my observations for a 8998 board: > > 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready fixup) > qcom_pcie_probe() fails with a timeout in phy_init. > => this is in line with your regression analysis. > > 2) Your patch

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-13 Thread Marc Gonzalez
On 12/06/2019 19:25, Bjorn Andersson wrote: > On Wed 12 Jun 09:24 PDT 2019, Marc Gonzalez wrote: > >> On 05/06/2019 01:24, Bjorn Andersson wrote: >> >>> After issuing a PHY_START request to the QMP, the hardware documentation >>> states that the software should wait for the PCS_READY_STATUS to

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-12 Thread Bjorn Andersson
On Wed 12 Jun 06:08 PDT 2019, Niklas Cassel wrote: > On Tue, Jun 04, 2019 at 04:24:43PM -0700, Bjorn Andersson wrote: > > After issuing a PHY_START request to the QMP, the hardware documentation > > states that the software should wait for the PCS_READY_STATUS to become > > 1. > > > > With the

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-12 Thread Bjorn Andersson
On Wed 12 Jun 09:24 PDT 2019, Marc Gonzalez wrote: > On 05/06/2019 01:24, Bjorn Andersson wrote: > > > After issuing a PHY_START request to the QMP, the hardware documentation > > states that the software should wait for the PCS_READY_STATUS to become > > 1. > > > > With the introduction of

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-12 Thread Marc Gonzalez
On 05/06/2019 01:24, Bjorn Andersson wrote: > After issuing a PHY_START request to the QMP, the hardware documentation > states that the software should wait for the PCS_READY_STATUS to become > 1. > > With the introduction of c9b589791fc1 ("phy: qcom: Utilize UFS reset > controller") an

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-12 Thread Niklas Cassel
On Tue, Jun 04, 2019 at 04:24:43PM -0700, Bjorn Andersson wrote: > After issuing a PHY_START request to the QMP, the hardware documentation > states that the software should wait for the PCS_READY_STATUS to become > 1. > > With the introduction of c9b589791fc1 ("phy: qcom: Utilize UFS reset >

Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-04 Thread Evan Green
On Tue, Jun 4, 2019 at 4:24 PM Bjorn Andersson wrote: > > After issuing a PHY_START request to the QMP, the hardware documentation > states that the software should wait for the PCS_READY_STATUS to become > 1. > > With the introduction of c9b589791fc1 ("phy: qcom: Utilize UFS reset > controller")

[PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-06-04 Thread Bjorn Andersson
After issuing a PHY_START request to the QMP, the hardware documentation states that the software should wait for the PCS_READY_STATUS to become 1. With the introduction of c9b589791fc1 ("phy: qcom: Utilize UFS reset controller") an additional 1ms delay was introduced between the start request