Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Eduardo Horvath <>
From: Garrett D'Amore <>
List: tech-kern
Date: 03/10/2006 09:53:51
Eduardo Horvath wrote:
> On Thu, 9 Mar 2006, Garrett D'Amore wrote:
>> Jason Thorpe wrote:
>>> But, again, I think the best way to handle this is:
>>> 1- bus_space tags to deal with the 8-bit vs 32-bit bus access
>>> requirements
>> Reasonable, I think.  The only problem I have is how to distinguish
>> between these cases:
>>     1) a part that has 8-bit registers that are located within the same
>> 32-bit word, and you access them with masks.  (I guess in this case that
>> these must be idempotent for read access, and write accesses are some
>> how "safe", e.g. a write is ignored unless a bit enabling the write is
>> set or a register that ignores zero bits or somesuch).  (Also, only
>> 8-byte registers might have this stride applied.  So you can't just
>> universally apply e.g. a shift to the offset.
>>     2) a part that has its registers spaced by e.g. 4 vs. 2 vs. 1 byte
>> apart (stride)
>>     3) *which* byte of the 32-bit word (as an example) the part in #2
>> has the registers located in (usually either the top or bottom).
>> Bus space tags don't deal well with all of the possible options here.
> You need to expand your imagination a bit.  On several architectures the 
> bus space tag contains a jump table to the actual bus space accessor 
> function.  By replacing individual vectors in the table you can make the 
> bus space calls do anything you want.  Granted, most architectures 
> implement bus space accessor functions as macros instead of indirect 
> function calls for efficiency reasons.  But in some cases you may need to 
> bite the bullet and do things the slow way.
This is exactly what I'm doing now.  It requires me to create a unique
bus space tag just for this device.  Its ugly.  And there isn't really a
compelling reason it has to be so.

This ugliness is why *other* devices have done things like cloning com,
editing it a bit, and creating a new driver like aucom.  Its *less* ugly
that way.

    -- Garrett

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