Subject: Re: issues with com and non-PCI platforms.... a proposal
To: None <tech-kern@NetBSD.org>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 03/08/2006 11:57:26
On Wed, Mar 08, 2006 at 10:47:44AM +0000, Steve Woodford wrote:
> On Tuesday 07 March 2006 03:13, Garrett D'Amore wrote:
> > 2) use a separate bus space. I don't know of any existing
> > examples outside of my AR5212 com driver. In this case I had to
> > implement a pretty hefty amount of bus space logic *in com_arbus.c".
> > This seems ugly and unwieldy.
> It's also one of the only ways to go.
> > #define GETREG(x) bus_space_read_1(bst, bsh, sc_regoffs[x])
> If the underlying bus does not support byte-wise read/writes, this'll
> still have to bounce through a bus_space(9) shim layer. I've worked with
> hardware which supports 32-bit access only to those registers, for
> Perhaps a compromise is called for. Add some accessor function pointers
> to com_softc, to be filled in by the bus-specific code.
Uhm - in my book, those accessor functions are called bus_space_read_foo()!
I don't like every other port to be penalized on com just because one of
them doesn't want to do a bit of legwork like everybody else in that
situation did. Some of us use com ports at 115200 or 230400 bps.
Besides - as soon as you have one other device with that access method,
it's actually less work!