Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Eduardo Horvath <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
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
>> 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
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191