On Wednesday 29 October 2014 22:31:06 Thomas Gleixner wrote: > On Wed, 29 Oct 2014, Arnd Bergmann wrote: > > On Wednesday 29 October 2014 13:09:47 Kevin Cernekee wrote: > > > generic-chip.c already has a fair amount of indirection, with pointers > > > to saved masks, user-specified register offsets, and such. Is there a > > > concern that introducing, say, a pair of readl/writel function > > > pointers, would cause an unacceptable performance drop? > > > > I don't know. Thomas' reply suggests that it isn't. Doing byteswap > > in software at a register access is usually free in terms of CPU > > cycles, but an indirect function call can be noticeable if we do > > that a lot. > > I did not say that it is free. I merily said that I prefer to have > this solved at the core level rather than at the driver level. Yes, I understood that. > So you have several options to do so: > > 1) Indirections > > 2) Different functions for the different access modes > > 3) Alternatives > > #1 Is the simplest solution, but imposes the overhead of an indirect > function call for something trivial > > #2 The most efficient and flexible way if you have to provide > different access modes for different drivers. But it comes with the > price of increasing the text foot print. > > #3 Smart and efficient, but requires that on a particular system all > drivers use the same access mode. Right. The option that I was explaining earlier basically combines #1 and #3: For all kernels on which we know the endianess of all generic-irqchip users at compile time, we hardcode that, and we use indirections of some sort for the cases where we build a kernel that needs both. Arnd
