#1829 BLOC Trial-3: Control of VREF_OUT and HPF is coupled to Analog Input control

[Zarro Boogs per Child]

#1829: Control of VREF_OUT and HPF is coupled to Analog Input control
----------------------+-----------------------------------------------------
  Reporter:  arjs     |       Owner:  dilinger
      Type:  defect   |      Status:  new     
  Priority:  blocker  |   Milestone:  Trial-3 
 Component:  kernel   |     Version:          
Resolution:           |    Keywords:  relnote 
  Verified:  0        |  
----------------------+-----------------------------------------------------
Comment (by dilinger):

 Replying to [comment:17 arjs]:
 > After our discussion on IRC and a little thinking --
 >
 >
 > 1. HPF control in Alsamixer: Making HPF exposed in Alsamixer to the user
 for changing doesn't make sense. It'd be best if we could eliminate it
 from Alsamixer and tie its functionality internally with Analog Input (one
 is muted when the other is unmuted and vice versa). One doesn't forsee any
 situation when the user would want to toggle HPF without toggling
 AnalogInput.

 I wrote up a patch to drop the generic AD1888 HPF control, and instead
 replace it with OLPC's HPF (that also toggles AnalogInput).  Are you
 saying that we should expose it to the user as AnalogInput, or HPF?

 >
 >
 > 2. Requirements regarding capture_open : VREF and AnalogInput must be
 set to default states when capture device is open. This is because anybody
 who writes a simple recording application, or just even uses arecord to do
 some basic recording shouldn't have to worry about these things.
 >

 Noted.  HPF should certainly be set to a default state.  Does VREF need to
 be set?  VREF is part of the AD1888/AC97 stuff, and the driver (none of
 the drivers, afaik) have bothered to reset VREF.

 >
 > 3. Requirements regarding capture_close: If an application enables VREF
 and doesn't disable it on quit, the LED will remain ON all the time. (the
 LED turns on whenever VREF is enabled). So on capture_close we need to
 disable VREF. We should also disable AnalogInput on capture_close.

 Yep, I verified that VREF controls the LED last night; I have a patch for
 this..

 >
 >
 > 4. Name of VREF in Alsamixer: The name V_REFOUT doesn't make sense to a
 non-technical user. Thinking back a little, why would a user want to
 toggle this control at all ? IMHO in a case when he/she wants to simply
 say something into the mic/external-mic  and hear it in real time (not
 capture). So why not rename the control to something like MIC_ENABLE ?

 This is part of the AC97 code.  If V_REF acts the same for OLPC as it does
 for other AD1888 users, then I can send a patch upstream to change the
 name to MIC_ENABLE; if it does something different, we need to consider
 whether it's worth changing.

 >
 >
 > 5. V_REFOUT (build561, B4) : When I go the Alsamixer control of V_REFOUT
 and unmute it, shouldn't the LED light up  ?(it doesn't) In some random
 instances, when I open the capture device and then close it (for example
 do a simple recording using arecord and then ctrl-c the recording
 process), and when I subsequently go to Alsamixer and toggle the VREF
 control, it seems to work (switches ON the LED when I unmute it).


 I talked to wad about this yesterday; there was a hardware change made
 that makes VREF only light the LED when we're actually recording.  So, if
 you toggle VREF from alsamixer, the LED won't come on; however, if you
 toggle VREF from alsamixer while running the Record activity (or any other
 activity that is actually recording), the LED will turn on and off.

 If you're around today, I can give you a kernel to test..

-- 
Ticket URL: <https://dev.laptop.org/ticket/1829#comment:18>
One Laptop Per Child <http://laptop.org/>