Trying not to top post.. Apologies before hand on my client restrictions. Anyways..
Manjunath,
Yes, the call sequences are common. We may consider using cpu_relax() in the context of dvfs calls.. Except it could result in race connditions not in intrest.
Do me a favor and flag the udelays u'd like to convert and send a patch for fix pls.
Regards,
Nishanth Menon
----- Original Message -----
From: G, Manjunath Kondaiah
To: Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx <linux-omap@xxxxxxxxxxxxxxx>
Cc: Imberton Guilhem <guilhem.imberton@xxxxxxxxxxxx>; Mike Chan <mikechan@xxxxxxxxxx>; Nayak, Rajendra; Roger Quadros <ext-roger.quadros@xxxxxxxxx>; Kalle Jokiniemi <ext-kalle.jokiniemi@xxxxxxxxx>; Reddy, Teerth; Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>; Paul Walmsley <paul@xxxxxxxxx>; Hogander Jouni <jouni.hogander@xxxxxxxxx>
Sent: Mon Oct 26 10:09:07 2009
Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> -----Original Message-----
> From: Menon, Nishanth
> Sent: Monday, October 26, 2009 3:48 PM
> To: G, Manjunath Kondaiah; 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
>
> > -----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.
>
NAK. My understanding is that, SR functions will be called during voltage
scaling also. Voltage scaling will happen in non IRQ locked context.
Please clarify if I am wrong.
-Manjunath
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
