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'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. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
