This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: ecos realtek driver
- From: Gary Thomas <gary at chez-thomas dot org>
- To: Eric Doenges <Eric dot Doenges at DynaPel dot de>
- Cc: Andy Dyer <adyer at righthandtech dot com>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 13 Aug 2003 06:01:33 -0600
- Subject: Re: [ECOS] Re: ecos realtek driver
- Organization:
- References: <B482D8AA59BF244F99AFE7520D74BF96CDC4@server1.RightHand.righthandtech.com> <3F39FCC1.9040905@DynaPel.de>
On Wed, 2003-08-13 at 02:54, Eric Doenges wrote:
> Andy Dyer wrote:
> > I saw your message about cache coherency, and I think
> > you're right that a cache flush needs to happen after
> > the transmit copy to buffers.
> >
> > I'm not so certain about the receive cases - at least
> > on mips the HAL_DCACHE_SYNC is going to write lines
> > out to memory trashing the stuff your net controller
> > just put in there. I think for receive it should be
> > HAL_DCACHE_INVALIDATE, but you would have to make sure
> > that no non-buffer data gets affected by that.
>
> My assumption is that for the receive case, there is no reason for
> the data cache to contain dirty cache lines, since the driver should
> only ever read from that portion of memory. Of course, that means
> a HAL_DCACHE_INVALIDATE is all that is really needed. But that
> opens a new can of worms - how to determine which cache lines need
> to be invalidated, and how to make sure that the buffers allocated
> start and end on cache line boundaries to prevent interfering with
> other memory areas. While this shouldn't be too much of a problem
> for any given platform, doing this in a generic, portable way most
> certainly is.
>
>
> P.S.: I've CCed this mail to ecos-discuss in the hope someone more
> knowledgeable than me has some good ideas on cache coherency in eCos.
I agree with Andy on this one - you should be using invalidate for
read and flush/sync for write.
Look at some of the other drivers that need to worry about this.
In particular devs/eth/powerpc/fcc and devs/eth/powerpc/quicc
Note: I'd actually suggest using this method, over the hack I used
before with the "uncached" address. Mainly because not all platforms
support uncached aliases. Also, by using selective flush/invalidate
calls, you'll only affect that portion of the cache that is important
and this will have limited impact on performance.
--
Gary Thomas <gary@chez-thomas.org>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss