From: Russell King <rmk@arm.linux.org.uk>
To: "Hicks, Jamey" <Jamey.Hicks@compaq.com>
Cc: "'linux-usb-devel@lists.sourceforge.net'"
<linux-usb-devel@lists.sourceforge.net>,
David Brownell <david-b@pacbell.net>,
Manfred Spraul <manfred@colorfullife.com>,
zaitcev@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h
Date: Fri, 9 Mar 2001 15:38:12 +0000 [thread overview]
Message-ID: <20010309153812.A29122@flint.arm.linux.org.uk> (raw)
In-Reply-To: <879158D1D558D4118DBD0008C7CF32A9015834A7@tayexc07.tay.cpqcorp.net>
In-Reply-To: <879158D1D558D4118DBD0008C7CF32A9015834A7@tayexc07.tay.cpqcorp.net>; from Jamey.Hicks@compaq.com on Fri, Mar 09, 2001 at 09:27:53AM -0500
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
next prev parent reply other threads:[~2001-03-09 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-09 14:27 Hicks, Jamey
2001-03-09 15:04 ` [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc Alan Cox
2001-03-09 15:38 ` Russell King [this message]
2001-03-09 17:00 ` [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patc h Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010309153812.A29122@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=Jamey.Hicks@compaq.com \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=manfred@colorfullife.com \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®