Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Matt Thomas <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/08/2006 19:39:57
Matt Thomas wrote:
> On Mar 8, 2006, at 3:59 PM, Garrett D'Amore wrote:
>> Jason Thorpe wrote:
>>> On Mar 8, 2006, at 1:47 PM, Garrett D'Amore wrote:
>>>> Steve Woodford wrote:
>>>> Yes, I have such hardware. But on my platform its a feature of the
>>>> I'm on, and not a device specific thing. (So I naturally take care of
>>>> it in the parent bus.) The problem is when the actual *chip* has
>>>> things about it that you try to solve at the bus level...
>>> I think a combination of things are necessary...
>>> 1- Adjusted bus_space tags for the access-width / stride issue
>>> 2- A register offset map for the "registers are laid out differently"
>>>> Oooh.... I like that idea.
>>> I don't... a single indirect function call is bad enough :-)
>> How does an indirect function call compare against say the cost of
>> another array index lookup and an extra shift/mask operation>
> for vax, about an order of magnitude.
>> Also, folks seem *really* concerned about the performance of these
>> things. Are folks really wanting to drive *non-FIFO* older parts at
>> 115200+? For newer parts it shouldn't matter that much.
> Not every platform is N hundred MHz CPU.
Even a 25MHz cpu should be able to get decent performance with a
Yes, there are parts that are *even slower* than 25 MHz, but they
probably aren't very interesting for running NetBSD. (They probably
don't even have MMUs...)
>> FWIW, this is like 14k extra indirect calls per second.
> That's a lot.
It doesn't seem like it to me. But I'll give you the point.
>> I'm also willing to consider that for low performance systems we use an
>> #ifdef that makes the call not go thru the extra indirection.
> Then why bother with the extra indirection?
Because on some platforms you can have *multiple* different com
variants. E.g. you might have one one a PCI bus that is pretty much
standard, and you might also have the onboard one that is really weird.
So you need something at run-time, or you wind up with separate drivers.
>> Its not as if these are really high data rate parts... :-)
> They might seem to be for some platforms!
Yes, on a 1MHz 6502 it would seem that these appear to be fast. But
even on a 386 they aren't that bad. The only problem that older PCs had
with these (older being early generation 386s) was that the 16450's
lacked a FIFO.
On machines with the older busses, it would makes sense IMO, to #ifdef
out this extra run-time logic, because they probably don't need the
bizarro mapping support.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191