Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Aug 2009 08:48:53 -0700
From:      Sam Leffler <sam@errno.com>
To:        Rafal Jaworowski <raj@semihalf.com>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r196380 - head/sys/dev/usb
Message-ID:  <4A8C1EE5.3030103@errno.com>
In-Reply-To: <81BE0575-26B5-4EBE-90D5-4B3DDB42F79F@semihalf.com>
References:  <200908191439.n7JEd892057035@svn.freebsd.org> <4A8C1AA0.20303@errno.com> <81BE0575-26B5-4EBE-90D5-4B3DDB42F79F@semihalf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Rafal Jaworowski wrote:
> 
> On 2009-08-19, at 17:30, Sam Leffler wrote:
> 
>> Rafal Jaworowski wrote:
>>> Author: raj
>>> Date: Wed Aug 19 14:39:08 2009
>>> New Revision: 196380
>>> URL: http://svn.freebsd.org/changeset/base/196380
>>> Log:
>>>  Fix USB cache sync operations for platforms with non-coherent DMA.
>>>    - usb_pc_cpu_invalidate() is called between [consecutive] reads 
>>> from a device,
>>>    so a sequence of BUS_DMASYNC_POSTREAD and _PREREAD should be used. 
>>> Note we
>>>    cannot use or'ed shorthand ( _POSTREAD | _PREREAD) for BUS_DMASYNC 
>>> flags, as
>>>    the low level bus dma sync operation is implementation dependent 
>>> and we
>>>    cannot assume the required order of operations to be guaranteed.
>>>    - usb_pc_cpu_flush() is called before writing to a device, so
>>>    BUS_DMASYNC_PREWRITE should be used.
>>>    Submitted by:    Grzegorz Bernacki
>>>  Reviewed by:    HPS, arm@, usb@ ML
>>>  Tested by:    HPS, Mike Tancsa
>>>  Approved by:    re (kib)
>>>  Obtained from:    Semihalf
>>
>> Is this different from the patch I tested on Gateworks 2358 boards 
>> which didn't completely resolve problems?
> 
> Hm, not sure what patch you have tested with GW. There was an initial 
> workaround for this problem from late June time frame, and this commit 
> is a refined fix identical to the patch posted 05 Aug to arm@. There 
> were other ARM patches in the meantime involving cache sync, but they 
> were pmap-related.

I'm pretty sure it's the same one and was combined with other changes 
you describe.  Unfortunately reproducing the problem requires an 
out-of-tree driver so we can't be sure whether all issues are resolved 
on the platform.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A8C1EE5.3030103>