Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Aug 2012 22:00:44 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Adrian Chadd <adrian@FreeBSD.org>
Cc:        Ian Lepore <freebsd@damnhippie.dyndns.org>, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Partial cacheline flush problems on ARM and MIPS
Message-ID:  <F8C9E811-8597-4ED0-9F9D-786EB2301D6F@bsdimp.com>
In-Reply-To: <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com>
References:  <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com> <1345765503.27688.602.camel@revolution.hippie.lan> <CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G%2BB9xB3NvPFJQ@mail.gmail.com> <1345766109.27688.606.camel@revolution.hippie.lan> <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Aug 23, 2012, at 5:59 PM, Adrian Chadd wrote:

> On 23 August 2012 16:55, Ian Lepore <freebsd@damnhippie.dyndns.org> =
wrote:
>=20
>>> In what case though would the hardware say it can only DMA on a 64k
>>> alignment BUT move one byte at a time? Then what would the starting
>>> address be for each DMA?
>>>=20
>>=20
>> Maybe the device has a reduced number of address bits in its =
registers
>> and the low-order bits always start at zero and increment internally =
in
>> a wider register so that any length dma can happen, but it has to =
start
>> on a 64k boundary.
>>=20
>> Maybe the address you pass it has to be a 64k boundary, but then the
>> bytes actually end up in one-of-N slots within that 64k region, based =
on
>> other parameters of the transfer.
>>=20
>> I've worked with some strange hardware over the years.
>=20
> Right. That's pretty odd though. But now I understand where you're =
coming from.
>=20
> I still think the short term solution should be "fix the USB stack to
> not do that!"
>=20
> The longer term problem is likely to figure out what makes sense. Eg,
> if you're going to allow the allocator to interleave 16 byte chunks
> (on a 32 byte cache line platform) with some being DMA buffers and
> others being non-DMA buffers; or whether you enforce that the whole
> chunk is a DMA buffer for your hardware and you look after it, or
> something else..

The bottom line is that you can't mix things like that when cache lines =
are involved.  The current code that tries is doomed to failure. Doomed. =
You just can't control all flushes, as Ian's missive demonstrates, and =
trying to accommodate code that does this I don't think can possibly =
work.  All the interrupt masking, copying in and out, etc I fear is =
doomed to utter and abject failure. =20

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8C9E811-8597-4ED0-9F9D-786EB2301D6F>