[PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation
balbi at ti.com
Mon Apr 21 08:11:17 PDT 2014
On Mon, Apr 21, 2014 at 08:08:43AM -0500, Nishanth Menon wrote:
> On 04/17/2014 05:00 PM, Felipe Balbi wrote:
> > On Thu, Apr 17, 2014 at 03:49:22PM -0500, Nishanth Menon wrote:
> >> just simplify derefencing that is equivalent.
> >> Signed-off-by: Nishanth Menon <nm at ti.com>
> >> ---
> >> V2: just ordering change
> >> V1: https://patchwork.kernel.org/patch/3984201/
> >> drivers/bus/omap_l3_noc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
> >> index c8facb0..f7d3bf4 100644
> >> --- a/drivers/bus/omap_l3_noc.c
> >> +++ b/drivers/bus/omap_l3_noc.c
> >> @@ -76,7 +76,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
> >> err_src = __ffs(err_reg);
> >> /* Read the stderrlog_main_source from clk domain */
> >> - l3_targ_base = base + *(l3_targ[i] + err_src);
> >> + l3_targ_base = base + l3_targ[i][err_src];
> > hmmm, wasn't it so that pointer arithmetic was slightly faster than
> > array indexing ? In that case would it be best to:
> > l3_targ_base = base + *(l3_targ + i + err_src);
> Yes, if this was a hot path (example: interrupt handler that gets
> invoked very often), I would probably have preferred optimization at
> this point.
> However, the patch is just a step away from patches that converts the
> target information into a structure under flagmux structure allowing
> us to get rid of multiple array operations.
> This patch just makes the further changes a bit readable.
alright, the error IRQ doesn't fire very often indeed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the linux-arm-kernel