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
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191