#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:14 arjs]:
 > Hi dilinger,
 >
 >
 > > > 1) Control of V_REFOUT must be independent of control of Analog
 Input while capture device is open.
 > > >
 > >
 > > What should control this?  Should there be an additional alsa mixer
 knob that allows this to be set and unset?  If so, what's a good name for
 it?
 >
 >
 > 'V_REFOUT' and 'Analog Input' are two controls already present in
 AlsaMixer. What it seems is happening is that whenever 'Analog Input' is
 unmuted, 'V_REFOUT' becomes muted or something like that. It seems that
 muting or unmuting either of them affects the state of the other. This is
 what I meant by the fact that their control needs to be independent of
 each other.


 "High Pass Filter Enable" is also a control present in alsamixer.  If we
 tie it to the Analog Input in the driver, we should probably make it
 immutable.. or remove it completely.  Are there any reasons that a user
 would want to toggle HPF without toggling Analog Input?


 >
 >
 > > > 2) Control of High Pass Filter must be coupled to control of Analog
 Input. That is, when one is enabled the other one must be disabled.
 > >
 > > Er, so when analog input is enabled, HPF should be disabled?  I
 believe we have that reversed at the moment; HPF is enabled when analog in
 is enabled.
 >
 >
 > Unmuting 'Analog Input' means going into the DC mode - this requires
 'High Pass Filter Enable' (which is also a control  already present in
 Alsamixer) to be muted. The control of 'High Pass Filter Enable' must be
 reverted back i.e. unmuted when one comes back from DC mode back to AC
 mode (indicated by 'Analog Input' control being muted)
 >

 What about toggling HPF Enable?  Should that change Analog Input?

 >
 > > > 3) V_REFOUT and Analog Input must be disabled when capture device is
 closed.
 > > >
 > >
 > > Does it matter what state it's in when it's closed?  How about we
 reset it when we open the capture device, instead?   Opening the device
 means we disable VREFOUT and analog in as part of preparing the device for
 the user.
 >
 > Activities/applications (like Measure for example) might fiddle around
 with these settings during operation. So it is important to ensure that
 the device is in a sane state when closed;


 Can you please clarify this?  Why must it be in a sane state when closed?
 Is an application not expected to first open the device, then enable
 Analog Input, and then start recording?  If that's the use case, it
 shouldn't matter whether we disable V_REFOUT and Analog In during open or
 during close.  Also, what about alsamixer?  If a user enables V_REFOUT
 from alsamixer and then opens an activity that records, won't V_REFOUT be
 in an incorrect state?  Am I missing something?


 which means  --  1) 'Analog Input' is muted  2) V_REFOUT is also muted  3)
 By virtue of 1, 'High Pass Filter Enable' would be enabled; i.e. unmuted
 >
 >
 > I wish to mention that it seems that there is no EC command to read the
 state of 'Analog Input' and so the state is always stored in the Kernel in
 a variable. While I was trying to test out my patch, I was looking at
 Alsamixer while opening the capture device - this might or might not be
 the right thing to do. Please suggest how to check the settings while
 having the capture device open.


 As richard mentioned, we do that through GPIOs now.  Analog Input is not
 supported on B1s.

 >
 >
 > Please let me know if I can help in any way.
 >
 >
 > thanks,
 > Arjun

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