is the patch that was finally applied to the product (3.10
based).
commit 16cf72cfa72269b55fc5c878689e00c99b640d86
Author: Nikita Yushchenko
Date: Thu Apr 3 08:35:36 2014 +0400
powerpc: fix IRQ routing on Freescale boards with ULI1575 chip
Source: MontaVista Software, LLC
M
23.12.2014 08:36, Arseny Solokha пишет:
>> On Sat, 6 Dec 2014, Arseny Solokha wrote:
>>
>>> From: Arseny Solokha
>>>
>>> Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
>>> introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
>>> board. The code path that was
29.05.2014 19:44, Alan Stern пишет:
> On Thu, 29 May 2014, Nikita Yushchenko wrote:
>
>> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>>> I don't know how linux usb subsystem should behave against such
>>>> "half-existing" hardware. Perhap
29.05.2014 19:33, Nikita Yushchenko пишет:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>> I don't know how linux usb subsystem should behave against such
>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>> but maybe it should
29.05.2014 18:42, One Thousand Gnomes пишет:
>> I don't know how linux usb subsystem should behave against such
>> "half-existing" hardware. Perhaps hanging is not the best idea...
>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>> devices in platform PCI setup. Perhaps control
>>> I think problem is caused by access to OHCI regs from PCI quirks - before
>>> driver was initialized. ULI1553 southbridge chip could be in strange state
>>> at this point.
>>
>> If that is the cause, we ought to be able to see it from the values
>> printed out by the debugging statements. And
> It would help to print the value of fminterval.
> And here to print the value obtained by the readl().
I've checked these... all values read as 0x - which does not
look correct
readl(base + OHCI_CONTROL) several lines before returns 0x
Read of HcRevision register (base + 0x0) at
27.05.2014 20:39, Sergei Shtylyov пишет:
> Hello.
>
> On 05/27/2014 08:56 AM, Nikita Yushchenko wrote:
>
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>
>> Since preserving OHCI_FMINTERVAL was originally don
27.05.2014 19:08, Alan Stern пишет:
> On Tue, 27 May 2014, Nikita Yushchenko wrote:
>
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>
> Which access, the read or the write?
things are a bit more complex.
If ins
28.05.2014 03:27, Greg Kroah-Hartman пишет:
> On Tue, May 27, 2014 at 08:56:42AM +0400, Nikita Yushchenko wrote:
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>>
>> Since preserving OHCI_FMINTERVAL was orig
should be
safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.
Signed-off-by: Nikita Yushchenko
---
drivers/usb/host/pci-quirks.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3
one board test passes and fsl-usb
init succeeds, but on other board test fails, causing fsl-usb init to
fail.
This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on
controller version 1.6 that (per manual) does not have this bit.
Signed-off-by: Nikita Yushchenko
---
drivers/usb/host
12 matches
Mail list logo
