Date: Fri, 24 Jul 2009 23:34:04 -0400 (EDT) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread Message-ID: <20090724.233404.-399282844.imp@bsdimp.com> In-Reply-To: <200907232209.47729.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200907232209.47729.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: On Thursday 23 July 2009 20:53:06 Marcel Moolenaar wrote:
: > All,
: >
: > I went over the thread and this is what I have to say about it:
: >
: > Using busdma to manage/control CPU caches is wrong for the
: > following simple reason: bus_dmamap_sync() has the side-effect
: > of copying to and from the bounce buffer (if applicable).
: >
: > CPU caches should be kept coherent by using an appropriate API.
: > We already have cpu_flush_dcache(). All we have to do is add
: > cpu_inval_dcache() and let the MD code determine how best to
: > do this -- even if they decide to use busdma.
: >
: > In general: D-cache and I-cache control/handling should not be
: > hidden from MI code. It should not be treated as an artifact of
: > some platform. It should not be implemented by banking on some
: > side-effect of other function(s). We only achieve efficient
: > cache control if MI code calls appropriate APIs so that we can
: > precisely express what we need to achieve at that point.
: >
: > For example: when we write a breakpoint into the text segment
: > of some process by using ptrace(2), the ptrace(2) code must
: > call an appropriate API to make sure that the I-cache is made
: > coherent with memory. This may require a previous D-cache
: > flush! We should not kluge uiomove(9) like we did on PowerPC
: > to deal with this. Note ARM and ia64 are still broken in this
: > respect.
:
: Hi,
:
: I would be fine with a solution where cpufunctions are used directly in USB.
: The only problem is that if bounce pages are used, which happens in the case
: of loading kernel virtual data into DMA, then busdma sync calls would still be
: required.
They are needed on i386 kernels with more than 4GB of ram... Or ram
located above 4GB...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090724.233404.-399282844.imp>