On Sun, 3 Dec 2006 09:23:03 +0100
S0ven Luther <[EMAIL PROTECTED]> wrote:
> > Not that I know. But we could have a cleaner approach. The #include one
> > dates a bit... we could have for example an ohci-core.ko with the core
> > bits, and ochi-pci.ko, ohci-patform.ko etc... be separate modules li
Alan Stern wrote:
No, I don't want to use it. It's too complicated for the relatively small
advantage it offers.
Ok.
This all sounds very strange. Here's an idea. Add
unsigned char unused[32];
struct list_head remove_list_copy;
to the end of the uhci_qh structure. The remove
Sven Luther wrote:
This requires a lot of care to do right. Remember that on PC systems
interrupts can be substantially posted. A "stop_interrupt" may prevent
IRQ issue but if an IRQ is already on the PC APIC bus it will kill you
later on because the IRQ delivery and PCI bus access on the PC class
David Brownell wrote:
Except that the UHCI spec is clear that in a given QH (or TD),
only one word is modified and the others are read-only. So
I see no way that "real UHCI" would ever write more than one
32-bit word at a time. Whose UHCI silicon is this, and do you
know for a fact that something
David Brownell wrote:
I think most of the PowerPC machine works just like the x86.
About this one (Pegasos II), it does support cache coherency/bus
snooping.
So, IMO, dma_alloc_coherent is correct (otherwise, nothing would work,
and we would need to rewrote each Linux driver ...)
But you DID nee
Alan Cox wrote:
It makes me nervous. The first thing I see is the question about
ordering between posted writes to the IntEnable reg in PCI space and the
software register. The second thing is returning IRQ_NONE causing the
"screaming interrupt" warning.
outw() takes care of the ordering. by the wa
David Brownell wrote:
>
> I'm reading it as: on the PPC boxes in question,
> dma_alloc_coherent() -- used indirectly to allocate
> the memory in question -- is returning memory that
> doesn't work as required by the text I quoted.
>
> Specifically, caching effects DO exist, ones where
> the CPU's
Alan Cox wrote:
> This requires a lot of care to do right. Remember that on PC systems
> interrupts can be substantially posted. A "stop_interrupt" may prevent
> IRQ issue but if an IRQ is already on the PC APIC bus it will kill you
> later on because the IRQ delivery and PCI bus access on the PC c
Hello !
I'm Nicolas DET. And I've a patch for the Linux 2.6.6 UHCI driver.
Some users complain that our computers (Pegasos II
http://www.pegasosppc.com/) are instable (systems hangs) when stressing
the USB (we use a VIA-8231 SouthBridge) on Linux 2.6.x (2.4.x is fine).
Then we st
Hello !
I'm Nicolas DET. And I've a patch for the Linux 2.6.6 UHCI driver.
Some users complain that our computers (Pegasos II
http://www.pegasosppc.com/) are instable (systems hangs) when stressing
the USB (we use a VIA-8231 SouthBridge) on Linux 2.6.x (2.4.x is fine).
Then we st
10 matches
Mail list logo
