Hi David,
On Fri, Sep 22, 2017 at 11:00 AM, David Müller (ELSOFT AG)
wrote:
> Hello
>
> Does the code below really work?
>
> On my custom MX6Q board, the code hangs on the read of the
> "PCIE_PL_PFLR". Please note that this code sequence is not entered the
> first time after a power up; I have to
On Fri, Sep 22, 2017 at 7:00 AM, David Müller (ELSOFT AG)
wrote:
> Hello
>
> Does the code below really work?
Hi Dave,
This patch does work to resolve the issue stated in the commit log
which was to fix failing to boot on a 4.11+ kernel which stems from
the fact that we have no reliable way to r
On 09/25/2017 11:05 AM, David Müller (ELSOFT AG) wrote:
> Marek Vasut wrote:
>
>> On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote:
>>> On my custom MX6Q board, the code hangs on the read of the
>>> "PCIE_PL_PFLR". Please note that this code sequence is not entered
>>> the first time after
Marek Vasut wrote:
> On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote:
>> On my custom MX6Q board, the code hangs on the read of the
>> "PCIE_PL_PFLR". Please note that this code sequence is not entered
>> the first time after a power up; I have to execute a U-Boot reset
>> to actually trig
On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote:
> Hello
>
> Does the code below really work?
>
> On my custom MX6Q board, the code hangs on the read of the
> "PCIE_PL_PFLR". Please note that this code sequence is not entered the
> first time after a power up; I have to execute a U-Boot re
Hello
Does the code below really work?
On my custom MX6Q board, the code hangs on the read of the
"PCIE_PL_PFLR". Please note that this code sequence is not entered the
first time after a power up; I have to execute a U-Boot reset to
actually trigger the hang. Any ideas what is going wrong?
Whi
Hi Tim,
On 18/05/2017 16:35, Stefano Babic wrote:
>> Stefano,
>>
>> My patch is not intrusive and it appears several people are wanting
>> it. Why not accept my patch which will end up getting re-written once
>> the PCI driver is moved to DM?
>
> Well, most drivers are already moved to DM and the
Hi Tim,
On 18/05/2017 16:22, Tim Harvey wrote:
> On Thu, May 18, 2017 at 2:12 AM, Stefano Babic wrote:
>> On 12/05/2017 21:58, Tim Harvey wrote:
>>> There is no dedicated reset signal wired up for the MX6QDL thus if the
>>> bootloader enables the link we need some special handling to get the core
On Thu, May 18, 2017 at 2:12 AM, Stefano Babic wrote:
> On 12/05/2017 21:58, Tim Harvey wrote:
>> There is no dedicated reset signal wired up for the MX6QDL thus if the
>> bootloader enables the link we need some special handling to get the core
>> back into a state where it is safe to touch it fo
On 12/05/2017 21:58, Tim Harvey wrote:
> There is no dedicated reset signal wired up for the MX6QDL thus if the
> bootloader enables the link we need some special handling to get the core
> back into a state where it is safe to touch it for configuration.
>
> While there has been some special hand
On Fri, May 12, 2017 at 05:25:22PM -0300, Fabio Estevam wrote:
> Hi Tim,
>
> On Fri, May 12, 2017 at 4:58 PM, Tim Harvey wrote:
> > There is no dedicated reset signal wired up for the MX6QDL thus if the
> > bootloader enables the link we need some special handling to get the core
> > back into a
Hi Tim,
On Fri, May 12, 2017 at 4:58 PM, Tim Harvey wrote:
> There is no dedicated reset signal wired up for the MX6QDL thus if the
> bootloader enables the link we need some special handling to get the core
> back into a state where it is safe to touch it for configuration.
>
> While there has b
There is no dedicated reset signal wired up for the MX6QDL thus if the
bootloader enables the link we need some special handling to get the core
back into a state where it is safe to touch it for configuration.
While there has been some special handling in the Linux kernel to do this,
it was remov
13 matches
Mail list logo
