Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Steve Woodford <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 03/08/2006 13:47:28
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
Yes, I have such hardware. But on my platform its a feature of the bus
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 weird
things about it that you try to solve at the bus level...
> Perhaps a compromise is called for. Add some accessor function pointers
> to com_softc, to be filled in by the bus-specific code.
Oooh.... I like that idea.
> Cheers, Steve
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191