Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Aug 2012 22:03:19 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Partial cacheline flush problems on ARM and MIPS
Message-ID:  <6639450F-11BB-4D01-8D0C-CD66B427EF08@bsdimp.com>
In-Reply-To: <1345769488.27688.625.camel@revolution.hippie.lan>
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> <1345769488.27688.625.camel@revolution.hippie.lan>

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

On Aug 23, 2012, at 6:51 PM, Ian Lepore wrote:

> On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote:
>> On 23 August 2012 16:45, Ian Lepore <freebsd@damnhippie.dyndns.org> =
wrote:
>>=20
>>> So do you think it's safe to assume that any given dma tag that has =
an
>>> alignment constraint also implicitly has a buffer size constraint =
that
>>> the size must be a multiple of the alignment?
>>>=20
>>> What if we have a platform with a 32-byte cacheline / DMA =
granularity,
>>> and then we have a builtin device on that SoC which can only do DMA =
on a
>>> 64K alignment (which its tag would reflect), but the hardware can =
move
>>> as little as 1 byte at a time?  Children of that bridge device come
>>> along and allocate little 16-byte buffers that eat 16 pages each.  =
It
>>> doesn't seem all that far-fetched to me.
>>=20
>> That hardware would suck, wouldn't it?
>>=20
>=20
> Thinking about this some more, I think that at least for now we don't
> have to communicate a new constraint to bus_dma_tag_create(), nor do =
we
> need to assume that a size constraint is the same as an alignment
> constraint.  The size constraint is machine dependant in nature, and =
the
> busdma implementation code is also MD, and thus should have some MD =
way
> of knowing about this constraint for itself without being told by
> callers.

And also allow for different cache line sizes for different CPUs within =
the same MACHINE/MACHINE_ARCH, which is common in MIPS land, at least.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6639450F-11BB-4D01-8D0C-CD66B427EF08>