On Sun, 28 May 2000, Mike Smith wrote:
Speaking about bus_space_*(): Does it make the thing follow the PCI
ordering rules? Very probably not since it is impossible on some systems.
There's no attempt to do this, no. However, it's possible to implement
this if there's a need.
Typically, a driver may want to order some operations and also not break
post buffering each time a write is performed. It may for example want to
order some operations, but not flush all writes immediately. I didn't see
how to tell bus about that.
The bus_space_barrier()
On Fri, 2 Jun 2000, Mike Smith wrote:
Typically, a driver may want to order some operations and also not break
post buffering each time a write is performed. It may for example want to
order some operations, but not flush all writes immediately. I didn't see
how to tell bus
On Tue, 30 May 2000, Mike Smith wrote:
This is still pretty straightforward, actually. Your problem is that
you're looking at an API with *more* functionality, and you need to
incorporate the superset. You'll typically find that everything your
Linux driver does can be handled with a
Hi Dennis,
I can see that you disagree with some of the design decisions that have been
made. However, your tone makes that people will not listen to what you say,
but hammer into your person instead.
I'm not quite sure what you are trying to achieve by trampling all over
people's shoes like
some people need more density than your obviously trivial needs, and the
"new" bus-oriented implementation makes writing drivers with complex
controllers much more difficult than need-be.
Speaking from some experience dealing with what would have to be
considered "complex" controllers, this
At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
Existing bus abstractions tend to let think that the same software driver
can deal with different buses, bridges or IO methods without having to
care about how these things actually behave, notably regarding buffering
and ordering rules. This
At 08:32 AM 5/30/00 -0700, you wrote:
At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
Existing bus abstractions tend to let think that the same software
driver
can deal with different buses, bridges or IO methods without having to
care about how these things actually behave, notably regarding
A good bus abstraction lets you care as much or as little as necessary.
The NetBSD framework (which we use) allows you to do this.
The best "portable" coding method is with memory-mapped registers, which
seems to have been omitted from this "implementation", which is the gripe
At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
Existing bus abstractions tend to let think that the same software driver
can deal with different buses, bridges or IO methods without having to
care about how these things actually behave, notably regarding buffering
and ordering rules. This is
At 07:30 PM 5/27/00 -0400, Jeroen C. van Gelderen wrote:
Dennis wrote:
At 09:54 AM 5/27/00 +0200, John Hay wrote:
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style
In message [EMAIL PROTECTED], Dennis writes:
Uhm, the very fact that you are too simple-minded to understand the
new, flexible, structured, high-performance bus architecture is sad.
That you take it out on the people reading -current is beyond sad.
If you can't behave like an adult shut up
in the other direction.
Dennis: you just posted a private email to a public mailing list:
From:"Jeroen C. van Gelderen" [EMAIL PROTECTED]
Time:Sat 19:30
Subject: Re: 4.0 - Isa devices not being probed
To: Dennis [EMAIL PROTECTED]
'Nuff said.
Cheers,
Jeroen
--
Jeroen C. va
On Mon, 29 May 2000, Dennis wrote:
At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
Existing bus abstractions tend to let think that the same software driver
can deal with different buses, bridges or IO methods without having to
care about how these things actually behave, notably regarding
In message [EMAIL PROTECTED] Dennis writes:
: The best "portable" coding method is with memory-mapped registers, which
: seems to have been omitted from this "implementation", which is the gripe
: here.
SYS_RES_MEMORY does exactly this. What are you talking about? I'm
using this in 5
On Sat, 27 May 2000, Warner Losh wrote:
[ ... ]
: 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
Doug Rabson wrote:
On Sat, 27 May 2000, Dennis wrote:
At 09:54 AM 5/27/00 +0200, John Hay wrote:
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
Speaking about bus_space_*(): Does it make the thing follow the PCI
ordering rules? Very probably not since it is impossible on some systems.
There's no attempt to do this, no. However, it's possible to implement
this if there's a need.
Typically, a driver may want to order some operations
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
They probe great for me. what, specifically, isn't probing?
He is probably talking about their own driver. In
At 09:54 AM 5/27/00 +0200, John Hay wrote:
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
They probe great for me. what, specifically, isn't probing?
He is
At 09:54 AM 5/27/00 +0200, John Hay wrote:
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
They probe great for me. what, specifically, isn't probing?
On Sat, 27 May 2000, Dennis wrote:
At 09:54 AM 5/27/00 +0200, John Hay wrote:
In message [EMAIL PROTECTED] Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
They probe great for me.
On Sat, May 27, 2000 at 03:51:24PM -0400, [EMAIL PROTECTED] wrote:
YesWhose brainstorm was it to use the new convoluted bus nonsense in
FreeBSD 4.0? Clearly someone who never wrote a driver with a complex
controller with indexed memory mapped registers.Whats next, assembler drivers?
[...]
-On [2527 21:06], Dennis ([EMAIL PROTECTED]) wrote:
Its seems rather humorous that the "generic" bus implementation requires
that isa drivers be hacked into the kernel with a build-time include. Very
humorous indeed. Is this a temporary condition as was the deboggle in v3.0?
Yeah I laugh my
On Sat, 27 May 2000, Jeroen Ruigrok van der Werven wrote:
-On [2527 21:06], Dennis ([EMAIL PROTECTED]) wrote:
Its seems rather humorous that the "generic" bus implementation requires
that isa drivers be hacked into the kernel with a build-time include. Very
humorous indeed. Is this a
YesWhose brainstorm was it to use the new convoluted bus nonsense in
FreeBSD 4.0? Clearly someone who never wrote a driver with a complex
controller with indexed memory mapped registers.Whats next, assembler drivers
If you cannot conduct yourself in a professional manner in these
mailing
In message [EMAIL PROTECTED]
=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
: Existing bus abstractions tend to let think that the same software driver
: can deal with different buses, bridges or IO methods without having to
: care about how these things actually behave, notably regarding buffering
:
On Sat, 27 May 2000, Warner Losh wrote:
In message [EMAIL PROTECTED]
=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
: Existing bus abstractions tend to let think that the same software driver
: can deal with different buses, bridges or IO methods without having to
: care about how these things
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
:
Existing bus abstractions tend to let think that the same software driver
can deal with different buses, bridges or IO methods without having to
care about how these things actually behave, notably regarding buffering
and ordering rules. This is untrue.
A good bus abstraction lets you care
My 4.0 system doesnt probe ISA devices on my system.
Whats the trick? Is there a config requirement with old-style drivers?
Dennis
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
31 matches
Mail list logo
