RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: G, Manjunath Kondaiah
> Sent: Monday, October 26, 2009 3:40 AM
> To: Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx
> Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger Quadros; Kalle
> Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul Walmsley; Hogander Jouni
> Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> 
> 
> As per your comments for other patches when ever there is udelay usage,
> cpu_relax is the better option. I see there are lot of udelay(...) calls
> used in this patch. Why can't you use cpu_relax() or schedule().
> Any specific reason?
> 
Don’t really want to do cpu_relax in irq_locked context.. if you look at the code flow, the call from cpu_idle is in irq_locked.. Further this delay is part of bring up form saved context where there is nothing else scheduled + we don’t want anything else scheduled (and causing a change in scheduling decision). So unfortunately, unlike standard drivers, this cannot use the same reasoning.

Regards,
Nishanth Menon
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux