lkml.org 
[lkml]   [2014]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation
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@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.

--
Regards,
Nishanth Menon


\
 
 \ /
  Last update: 2014-04-21 15:21    [W:0.421 / U:1.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site