On Wed, Apr 27, 2011 at 06:57:00AM +0800, Arjan van de Ven wrote:
> On 4/26/2011 12:19 AM, Lu Guanqun wrote:
> > drivers/staging/intel_sst/intelmid_v2_control.c | 19 +++++++++++++++----
> > 1 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/intel_sst/intelmid_v2_control.c
> > b/drivers/staging/intel_sst/intelmid_v2_control.c
> > index 9f1b4a5..ad1b03e 100644
> > --- a/drivers/staging/intel_sst/intelmid_v2_control.c
> > +++ b/drivers/staging/intel_sst/intelmid_v2_control.c
> > @@ -217,6 +217,8 @@ static int nc_power_up_pb(unsigned int port)
> >
> > msleep(30);
> >
> > + snd_pmic_ops_nc.pb_on = 1;
>
> what is the locking model for this variable? which locks prevents this
> from going out of sync ?
Good catch! I'll fix this.
> case STEREO_HEADPHONE:
>
> > + if (snd_pmic_ops_nc.pb_on) {
> > + sst_sc_reg_access(sc_access_HP+2, PMIC_WRITE, 1);
> > + msleep(100);
>
> 100 milliseconds?????? that's an eternity. You're going to make the app
> that caused this code to be called visibly stutter with this.
> Why is this so long (magic number)? And is there some way to offload all
> of this to some work thread ?
Because setting the register will power on headphone, and to reduce the
pop sound, the time delay is added. I'm OK to remove this.
FYI, when this function is called from 'hp_automute' call path, it's
already in a work thread. Of course, when it's called from system call,
it's not.
>
>
--
guanqun
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
