Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Steve Woodford <scw@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
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 
> example.
>   
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.

    -- Garrett
> Cheers, Steve
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191