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
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
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-
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
>
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 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 un
>>> 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
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?
>
> thin
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
c6187597
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 o
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
---
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
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 unconditi
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
c6187
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
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 shou
17 matches
Mail list logo
