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 if that is so,
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 controlled by some device-tree
key.
Does it have a unique
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 be fixed elsewhere, e.g. by masking non-wired
devices in
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. Perhaps hanging is not the best idea...
but maybe it should be fixed elsewhere, e.g. by masking non-wired
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. Perhaps hanging is not the best idea...
but maybe it should be fixed
On Thu, 29 May 2014, Nikita Yushchenko wrote:
I've checked these... all values read as 0x - which does not
look correct
You could have the platform setup code read one of those hardware
registers, such as FMINTERVAL. If it obtains 0x, don't
register the OHCI
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 originally done only for NVIDIA
hardware and only
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 inserting printk's as below
---
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 done only for NVIDIA
hardware and only later
Hello.
On 28-05-2014 11:21, 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 done only for NVIDIA
hardware and only later (in c6187597) was turned unconditional, and
On Wed, 28 May 2014, Nikita Yushchenko wrote:
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
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
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?
Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
hardware and only later (in c6187597) was
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 done only for NVIDIA
hardware and only later (in c6187597) was turned unconditional, and
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 originally done only for NVIDIA
hardware and only later (in c6187597) was turned
This access causes hang on Freescale P2020DS board (that has OHCI
provided by ULI 1533 chip).
Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
hardware and only later (in c6187597) was turned unconditional, and
c6187597 commit message again mentions only NVIDIA, I think it
16 matches
Mail list logo
