On Mon, Oct 14, 2013 at 08:30:28AM +0300, Terje Bergström wrote: > On 12.10.2013 14:24, Thierry Reding wrote: > > Yeah, I don't like very much how this is currently done. I mean about > > half of this is actually duplicate code because of the static inline > > functions used for register defines. As discussed elsewhere this was > > originally meant to be used for coverage testing, but nobody's done > > anything like that as far as I know. I'm also not convinced that these > > would be very useful in coverage testing, but adding Terje on Cc and > > unless he or anyone else has any (strong) objections I'll go and remove > > the duplicate definitions and while at it see if I can come up with a > > way to share more code/definitions between versions of host1x. > > > > Do you see this as a blocker for 3.13 or can I do the cleanup after > > that? As far as I know Tegra124 has a more heavily modified version of > > host1x so implementing Tegra124 support might be a good opportunity to > > clean this up anyway. > > For Tegra114 the register level changes are small (one channel added, > wait bases, expanded fifo, etc) but for Tegra124 they're bigger. So > let's keep the long term in mind. I agree with Stephen here. We should really be working together with HW to prevent as many incompatibilities as we can. > I'm ok with removing the inlines. Just the energy spent in discussing it > over and over again is more than the benefits that a proper compiler > gives over the preprocessor (type checking, real syntax checking, > coverage, gdb breakpoints, etc). For some reason (which escapes me) > preprocessor magic seems to be the norm in Linux kernel. > > Parameterized code gets easily really ugly, difficult to debug and > difficult to port to new chips. There's much less work and opportunity > of mistake in maintaining data in a couple of files than subtle > algorithms all over the driver. If we don't have inlines in hw headers, > the headers become tiny and any benefits of parameterized code versus > per-hw version headers vanish. I'll keep that in mind when I revisit this. Thierry
Attachment:
pgpyEz4DiVezo.pgp
Description: PGP signature
