RE: [PATCH] ARM: OMAP: Add minimal OMAP2430 support

Woodruff, Richard
2006-06-11T13:09:59Z

> > I picked up this encoding from USB which uses it also. In general it
> > makes any kind of porting and sharing between some of our internal code
> > bases easier. It has a nice property of also being more compact (in C
> > file coding space) then other forms.
>
> That encoding has a lot of downsides:
>
> - You're tied to accessing only one instance of the peripheral (trying
> to access e.g. the different GPIO blocks is bound to be ugly).

Yes that is true. That's why it is not used there. We generally have used it in things where there is 1 instance like PRCM.

> - You're tied to MMIO. read_reg/write_reg can basically use whatever
> transport.

Probably. Though as you say some preprocessor tricks can do wonders :)

> - As mentioned before, supporting several base addresses (e.g. on
> different OMAPs) becomes a hassle.
>
> read_reg/write_reg, in my opinion, doesn't. You mention compactness as
> one, but with some preprocessor trickery it's rather easy to come up
> with a very compact read_reg/write_reg notation.
>
> But all in all, this is mostly a readability issue, and therefore
> subject to personal preferences. Mine is read_reg/write_reg. =)

I do agree here. Actually, I don't really mind if one form is used over another. Easier sharing likely happens though yours, and consistency is better. In general you do need to be a bit careful in that only focusing on an overall sharing strategy can limit you to the least common denominator.

The down side to me is we freeze and branch on a kernel version in support of customer release streams. Production is necessary. When the kernel deviates from this it makes pushing back fixes (or taking them in harder). Changes which are more on the cosmetic side hinder exchanges. We do resynchronize as streams come up and also do some live tree tracking so things correct themselves after some time.

Regards,
Richard W.