CPU Cache and busdma usage in USB

Rafal Jaworowski raj at semihalf.com
Tue Jul 14 17:20:25 UTC 2009


On 2009-07-14, at 18:58, Marcel Moolenaar wrote:

> On Jul 14, 2009, at 2:21 AM, Rafal Jaworowski wrote:
>
>>
>> On 2009-07-14, at 10:36, Hans Petter Selasky wrote:
>>
>>> On Tuesday 14 July 2009 10:31:10 Piotr Zięcik wrote:
>>>>> 1) My analysis: Only the data areas are being flushed/ 
>>>>> invalidated. No
>>>>> transfer descriptors are flushed/invalidated. I see no cache  
>>>>> operations
>>>>> happening on any DMA control structures, even though there are  
>>>>> calls from
>>>>> EHCI to xxx_pc_flush() and xxx_pc_invalidate().
>>>>
>>>
>>>> Probaby you see more on your AT91 device as you know USB stack  
>>>> internals.
>>>> Have you tried to bring up OHCI on you ARM board ?
>>>
>>> Not yet. I'm terribly busy with some LibUSB stuff headed for the 8- 
>>> current
>>> release. As soon as I find time I will fire off a build and debug.
>>
>> Please note these problems should be considered as a showstopper  
>> for the release since USB is currently broken on at least three ARM  
>> platforms in the tree (Marvell).
>
> Rafal,
>
> Anything I can do to help?
> (as a reminder: I have an Orion board)

Your input on the desired final solution to these issues would be  
appreciated. Please see the beginning of this thread (originated on  
usb@ ML), where a quick fix was proposed by Piotr. That patch works  
around the problems for us (also for some MIPS and noncoherent PPC),  
but the problem here is that we believe that using bus dma for the  
purpose of cache synchronization is improper in principle, and cpu- 
specific calls should be used instead, although Hans is rather  
reluctant to embracing the latter path.

>>> BTW: Has pmap been fixed for ARM in 8-current?
>>
>> Seems like the most critical problems (panics) are resolved and  
>> will be pushed into SVN shortly. In case you'd like to apply the  
>> fix directly, see: http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff
>
> Good! I was about to start a discussion about reverting
> rev. 194459 for now. We're about to start BETA-2 and it
> helps (at least Juniper :-) to have 8.0-RELEASE not be
> DOA :-)

No worries, we're also looking forward to 8.0 as a great ARM  
release :-) I will be following up on that pmap-related stuff, but am  
waiting for confirmation from stas@ there are no regressions on AT91  
with this patch.

Rafal



More information about the freebsd-usb mailing list