Izumi Tsutsui wrote:
> garrett_damore@tadpole.com wrote:
>
>   
>> Its not just
>> com_arbus.c, btw, but really com_aubus.c that is most interesting.
>>     
>
> IIRC, you asked to introduce regmap for com_arbus.c on the first
> discission, and then mentioned it was also required for aucom.c.
> I think that might cause unfortunate disagreement at that time.
>
> IMHO, stride is still proper for com_arbus (and similar ones),
> and regmap is acceptable only for variants which have actually
> non-standard registers even on your current implementation.
> Of course people will be able to cut corners by the existing
> regmap on future implementation, but I doubt it's worth to
> convert existing stride ops to regmap.
>   

I disagree.  Having to implement an _entire_ bus space just to
accommodate a single chip is *stupid*.  I've already converted
com_arbus.c, and it greatly shortened the code.  This is significant on
this platform which has only 8MB RAM, though I've not checked to see how
much the _binary_ reduced.

The other hack for something like this is in hpcmips (com_hpcio.c). 
I've left that stride in place, because I can't really test for it.

Anyway, what I have works, imposes no noticeable performance penalty,
and is easily maintainable.  Is there some reason we are arguing about this?

    -- Garrett
> Just my two yen,
> ---
> Izumi Tsutsui
>   


-- 
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