> -----Original Message-----
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 5:52 AM
> To: Menon, Nishanth; me@xxxxxxxxxxxxxxx
> Cc: linux-omap@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH] [OMAP] GPIO Module is reset during initialization
>
> -----snippet----
> >>>>
> >>>> && attemp)
> >>>>
> >>>>> + udelay(1);
> >>>>
> >>>> i guess cpu_relax() is better here.
> >> I guess cpu_relax is not required because this part of code is called
> only
> >> from
> >> board file during boot-up. Hence this would be the only code to be
> >> executed.
> What is your opinion on this?
Cpu_relax is still the better way of doing it.
> >>>>
> >>>>> + attempt++;
> >>>>>
> >>>>> attempt--;
> >>>>>
> >>>>cant we improve this code as following:
> >>>{
> >>> u8 attempts = 25;
> >>> /* Software Reset of GPIO module */
> >>> __raw_writel(0x0002, bank->base
> >>> + OMAP24XX_GPIO_SYSCONFIG);
> >>> /* wait for reset to be done */
> >>> while (((__raw_readl(bank->base +
> >>> OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
> >>> && attempts) {
> >>> cpu_relax();
> >>> if (attempts % 5)
> >>> udelay(1);
> >>> attempts--;
> >>> }
> >>>
> >>>allows the kernel to do somethin else while we also ensure we have a 5
> >>>usec guarenteed delay before giving up..
> >> Doesn't modulo operation cost more in terms of performance? Any
> specific
> >> reason for specific 5 microseconds?
> >You could replace it with >> operator if you like and use 2^x multiples..
> >I am just sticking 5 us there based on your original code..
> >so the same logic over here I suppose.. unless I missed something?
> I was using attempts as 5, as my intension was to attempt only 5 times and
> not
> in terms of usec as I could not find any details in any document for
> maximum
> time for the bit to get set/reset. According to your code, it would
> attempt to read
> the register 25 times with a delay of 5 microseconds min during worst case
> scenario.
Please find the h/w timeout value and resubmit the patch..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
