Date: Fri, 17 Jul 2009 14:17:46 +0200 From: Olivier Houchard <cognet@ci0.org> To: Rafal Jaworowski <raj@semihalf.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, Piotr Zi?cik <kosmo@semihalf.com>, freebsd-usb@freebsd.org, freebsd-arm@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB Message-ID: <20090717121746.GA38852@ci0.org> In-Reply-To: <F04328A2-99F7-4F00-B03B-9EFEC51B28C4@semihalf.com> References: <200906231035.43096.kosmo@semihalf.com> <E4BEDDE0-2872-4934-9A53-4121E33390B5@mac.com> <B8FCBB1F-F294-4252-82AE-1466631E548F@semihalf.com> <200907162156.06598.hselasky@c2i.net> <F04328A2-99F7-4F00-B03B-9EFEC51B28C4@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 17, 2009 at 12:23:57PM +0200, Rafal Jaworowski wrote:
>
> >With the following patch in arm/cpufunc.c my UMASS device gets
> >detected at
> >boot time (KB9202B ARM board). Else I get a USB request timeout
> >followed by a
> >panic. But data transfers of more than 16KByte are likely to be
> >broken.
> >
> >struct cpu_functions arm9_cpufuncs = {
> >...
> >- /*XXX*/ arm9_dcache_wbinv_range, /* dcache_inv_range */
> >+ /*XXX*/ arm9_dcache_inv_range, /* dcache_inv_range */
> >
> >};
>
> Hm, this looks indeed strange, but I have no idea why both methods
> point to _wbinv_range; it seems like it was there from the beginning.
> I also looked at NetBSD code (from which FreeBSD/arm originates) and
> they still have it this way too...
>
> Olivier, any thoughts why this was done this way?
>
> (FYI: the cpu we work with fall under ARM9E/ARM10, but the situation
> with dcache_inv_range() is similar as for ARM9 case above).
>
I can't get the reason why it's this way, reading the CVS logs from
NetBSD doesn't enlight me, but I'm pretty sure we should switch to use
the proper function for _inv_range, as done in this patch. That's what we
do for Xscale/Xscale core 3 anyway, and if it breaks something, we should
jut fix it.
Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090717121746.GA38852>