RE: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h

RE: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h

[Hicks, Jamey]

Are there any large-memory machines that need pci_alloc_consistent() in the
USB controller driver?  If not, then let's just set up an uncached mapping
of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.
It gets around all the issues of having a better allocator of uncached
memory.  Even with a slab allocator for uncached memory, modified versions
of virt_to_bus and bus_to_virt would have to be used.

The other choice is cache invalidation and flushing around all the code that
touches ED's and TD's.  This might not be too bad if it is encapsulated in
_read and _write macros.  How performance critical is the ED and TD code?

The latest ARM -NP patches work on SA1110 with the SA1111 controller (which
is OHCI-like).  With minimal tweaks they work on SA110/Footbridge with an
OHCI controller.  We will be submitting these patches as tweaks.  It's not
beautiful, but it doesn't change the mainstream (x86) code significantly.

Jamey

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc

[Alan Cox]

> USB controller driver?  If not, then let's just set up an uncached mapping
> of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.

If your CPU supports uncached mappings..

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h

[Russell King]

On Fri, Mar 09, 2001 at 09:27:53AM -0500, Hicks, Jamey wrote:
> Are there any large-memory machines that need pci_alloc_consistent() in the
> USB controller driver?  If not, then let's just set up an uncached mapping
> of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.

Yuck!  Some machines have 256MB, and I think 512MB of RAM image is just
plain stupid.  (256MB cached, 256MB uncached).  Looking further, one
such machine has:

	cached ram:	256MB
	uncached ram:	256MB
	ioremap space:	512MB	(from PhilB)
	io space:	256MB

In order to follow your suggestion, we'd have to drop the kernel from 0xc*
down to 0xb*.

> It gets around all the issues of having a better allocator of uncached
> memory.  Even with a slab allocator for uncached memory, modified versions
> of virt_to_bus and bus_to_virt would have to be used.

Not if it follows the pci_alloc_consistent interface where we get returned
the DMA and CPU cookies.

> The other choice is cache invalidation and flushing around all the code that
> touches ED's and TD's.  This might not be too bad if it is encapsulated in
> _read and _write macros.  How performance critical is the ED and TD code?

When I went through the OHCI code (which has been eaten by many kernel
updates and rsync), I got down to the TDs and EDs, and realised that the
old cache tricks wouldn't work - there are situations where both the
controller and the CPU need access within the same cache line.

> The latest ARM -NP patches work on SA1110 with the SA1111 controller (which
> is OHCI-like).  With minimal tweaks they work on SA110/Footbridge with an
> OHCI controller.  We will be submitting these patches as tweaks.  It's not
> beautiful, but it doesn't change the mainstream (x86) code significantly.

Comparing the SA11x0 documentation I have here and the OHCI controller
docs, certainly the register sets are significantly different.

It was also my understanding that the SA11x0 USB patches were completely
separate from the existing Linux USB code (or that is what I was told).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h

[Alan Cox]

> 	ioremap space:	512MB	(from PhilB)
> 	io space:	256MB
> 
> In order to follow your suggestion, we'd have to drop the kernel from 0xc*
> down to 0xb*.

And there are PA risc boxes with > 2Gig of RAM you might want to plug USB
controllers into