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.
> >
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()
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
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
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
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
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
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
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
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
>
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")
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
12 matches
Mail list logo