[PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation

[Felipe Balbi]

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.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140421/fe8fb9ab/attachment.sig>