In message <[EMAIL PROTECTED]>
=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
: It seems that some MIPS machines only flush bridge buffering when a
: interrupt is raised. I didn't remember where I read that. For those ones,
: the only way to have workable drivers is to let the device stall until the
: driver will service the interrupt. If such machines exists, there is
: probably no way for any bus abstraction to make drivers, that run
: concurrently to the device firmware regarding bus transactions, to work
: properly.
I've seen several MIPS designs, and I've never seen one that do that.
I have seen several where you have to be extremely careful about DMA.
Generally MIPS designs have cache coherency problems. When one
flushes the cache, these bridges should flush at the same time.
: Hmmm... That's the point I disagree on, btw. Inserting implicit barriers
: in the back of drivers can only be either sub-optimal or sometime not
: match driver expectations about ordering. Bus interface should allow more
: flexibility to drivers regarding ordering, in my opinion.
The bus_space interface in NetBSD makes this explicit.
: I guess that porting to MIPS should need to complexify a lot the bus
: interface, but I bet that this probably will not be enough and that
: changes in some drivers will be needed.
For FreeBSD, yes. For NetBSD many drivers no changes were needed.
: I donnot have NetBSD. If you can give me some pointers to relevant files
: that address the bus interface, I will try to download them and look into.
: I am only interested in the specification, so header files should be
: enough, unless a documentation exists.
src/sys/arch/*/include/bus*.h.
: By the way, as I wrote in my previous mail, I am unable to propose a
: better interface. I only wanted to point out that bus abstractions are far
: from being perfect. They make portability possible without too much code
: complexity, but when working on a driver, I think we must not forget the
: reality of what actually happens inside the machine.
NetBSD's experience has shown that this is mostly possible with very
little work.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
