On 02/08/2017 06:04 PM, Timur Tabi wrote:
> On 02/08/2017 04:22 PM, Christopher Covington wrote:
>> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
>> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
>> +& uap->vendor->fr_busy)
>>> >
On 02/08/2017 06:04 PM, Timur Tabi wrote:
> On 02/08/2017 04:22 PM, Christopher Covington wrote:
>> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
>> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
>> +& uap->vendor->fr_busy)
>>> >
On 02/08/2017 04:22 PM, Christopher Covington wrote:
>> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
>> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
>> +& uap->vendor->fr_busy)
>
> I really think the XOR logic needs to be documented wherever
On 02/08/2017 04:22 PM, Christopher Covington wrote:
>> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
>> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
>> +& uap->vendor->fr_busy)
>
> I really think the XOR logic needs to be documented wherever
On 02/07/2017 11:05 PM, Timur Tabi wrote:
> Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
>> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
>> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both
On 02/07/2017 11:05 PM, Timur Tabi wrote:
> Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
>> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
>> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both
Hi,
On 02/08/2017 08:27 AM, Timur Tabi wrote:
> Robin Murphy wrote:
>> Is there a reason anyone would ever want to turn this off? AFAICS you
>> save a few dozen bytes in return for a kernel image which you know won't
>> work properly on some hardware. That doesn't seem particularly
>> worthwhile,
Hi,
On 02/08/2017 08:27 AM, Timur Tabi wrote:
> Robin Murphy wrote:
>> Is there a reason anyone would ever want to turn this off? AFAICS you
>> save a few dozen bytes in return for a kernel image which you know won't
>> work properly on some hardware. That doesn't seem particularly
>> worthwhile,
On 02/08/2017 09:35 AM, Marc Zyngier wrote:
Interesting. How will you guarantee that nobody will ever want to run a
mainline kernel on this box after a certain date? Self-destruct timer?
;-)
As someone who runs mainline on HW that exceeded its "sell-by" date by a
few decades, I'm genuinely
On 02/08/2017 09:35 AM, Marc Zyngier wrote:
Interesting. How will you guarantee that nobody will ever want to run a
mainline kernel on this box after a certain date? Self-destruct timer?
;-)
As someone who runs mainline on HW that exceeded its "sell-by" date by a
few decades, I'm genuinely
On Wed, Feb 08 2017 at 2:09:12 pm GMT, Timur Tabi wrote:
> Mark Rutland wrote:
>
>>> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
>>> will have this fixed. We intend to revert these fixes after Falkor
>>> V1 SOCs are no longer supported.
>>
>>
On Wed, Feb 08 2017 at 2:09:12 pm GMT, Timur Tabi wrote:
> Mark Rutland wrote:
>
>>> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
>>> will have this fixed. We intend to revert these fixes after Falkor
>>> V1 SOCs are no longer supported.
>>
>> Supported by whom?
>
>
Mark Rutland wrote:
No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
will have this fixed. We intend to revert these fixes after Falkor
V1 SOCs are no longer supported.
Supported by whom?
Qualcomm.
Generally, once something's upstreamed we expect it to remain
Mark Rutland wrote:
No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
will have this fixed. We intend to revert these fixes after Falkor
V1 SOCs are no longer supported.
Supported by whom?
Qualcomm.
Generally, once something's upstreamed we expect it to remain
On Wed, Feb 08, 2017 at 07:27:29AM -0600, Timur Tabi wrote:
> Robin Murphy wrote:
> >Are we to take it that every SoC now and always with any Kryo or Falkor
> >core which also has an SBSA UART will require this workaround?
>
> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
On Wed, Feb 08, 2017 at 07:27:29AM -0600, Timur Tabi wrote:
> Robin Murphy wrote:
> >Are we to take it that every SoC now and always with any Kryo or Falkor
> >core which also has an SBSA UART will require this workaround?
>
> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
Robin Murphy wrote:
Is there a reason anyone would ever want to turn this off? AFAICS you
save a few dozen bytes in return for a kernel image which you know won't
work properly on some hardware. That doesn't seem particularly
worthwhile, and it's not like the PL011 driver isn't already ripe with
Robin Murphy wrote:
Is there a reason anyone would ever want to turn this off? AFAICS you
save a few dozen bytes in return for a kernel image which you know won't
work properly on some hardware. That doesn't seem particularly
worthwhile, and it's not like the PL011 driver isn't already ripe with
On 08/02/17 00:57, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
> and 2400v1 SoCs.
On 08/02/17 00:57, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
> and 2400v1 SoCs.
Christopher Covington wrote:
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO
Christopher Covington wrote:
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead
24 matches
Mail list logo