Opened 8 years ago

Closed 7 years ago

#1476 closed defect (fixed)

microphone circuits never powered down

Reported by: dwmw2 Owned by: wad
Priority: normal Milestone: Trial-2
Component: kernel Version: Build 406
Keywords: power Cc: jaykumar
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

Whenever the B3 unit is powered on, the 'microphone active' warning light is on. The microphone should be powered down except when we're using it.

Attachments (2)

suspend.PNG (27.8 KB) - added by wmb@… 8 years ago.
MIC VREFOUT waveform on entry to suspend.
resume.PNG (28.5 KB) - added by wmb@… 8 years ago.
MIC VREFOUT waveform on resume, with OFW fix to turn it off as soon as possible.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 years ago by chiaying.lin

The same as Camera circuits.

It start to shine when booting.(BIOS:Q2C11, Image:406)

comment:2 Changed 8 years ago by jg

  • Cc jaykumar added
  • Milestone set to BTest-4
  • Version set to Build 406

comment:3 Changed 8 years ago by wmb@…

From OFW, you can turn off the microphone bias with:

select /audio vbias-off unselect

I need to make this automatic on power-up.

Unfortunately, there are some wrinkles:

a) This one is minor: If you do not have an internal microphone attached, the LED will stay on for several minutes instead of going out immediately. The VREFOUT signal goes to hi-Z state when turned off, and with no microphone to discharge the node, the voltage stays high for a long time (the LED is isolated from the node via a FET). This could be fixed, if indeed it is a problem, by adding a 100K resistor to discharge the node.

b) This is a bad one: Since the CODEC powers up in bias-voltage-on state, the light will come on automatically upon a resume from S3, and explicit action must be taken to turn it off. That turn-off action is not trivial, because the only way to communicate with the CODEC is via the audio sample stream. It is not as simple at hitting a GPIO register and being done with it. You have to tell the AC97 engine to insert a control frame in the sample stream, which involves some amount of setup (I haven't yet worked out the mininum sequence).

Worse yet, the LED is going to flash when this happens - it will come up in the on state and stay that way for several milliseconds at the very least, until the software can get to the point where it can tell the CODEC to turn it off.

Not only that, but the LED flashes on briefly when the system is going down into suspend state. I'm not sure why, but it is easy to observe with the following OFW commands:

ok select /camera
ok s vbias-off many

Every time you press the power button, the system will wake up, turn the LED off as soon as possible, and go back to sleep; you can observe the flicker on the the LED for every wakeup. Well, actually, not quite as soon as possible - it first waits for the display to sync up, so the flicker could be be shortened by doing the codec thing before the display re-synce. But that won't solve the problem, because the human eye is very good at detecting brief flashes, so making the flash a little shorter won't eliminate the visual artifact.

comment:4 Changed 8 years ago by jg

  • Keywords power added
  • Verified unset

comment:5 Changed 8 years ago by wad

  • Owner changed from dilinger to wad
  • Status changed from new to assigned
  • Verified unset

I've got a fix wired into B3 Cuy (in cjb's hands in Cambridge). It eliminates all blinking of the LED as it transitions into and out of suspend mode.

The basic idea is to filter the control signal to eliminate the minor glitch when going into suspend, along with another circuit with a longer time period which ensures that the LED is kept off for the first N milliseconds after +3.3V is turned on.

I still need a good estimate on the worst case value for N from the firmware team, but that adjusting that value is just a BOM change.

I will forward to Quanta for their usual review and cost reduction. I'm leaving the ticket open to ensure that we get the hardware fix into B4.

Changed 8 years ago by wmb@…

MIC VREFOUT waveform on entry to suspend.

Changed 8 years ago by wmb@…

MIC VREFOUT waveform on resume, with OFW fix to turn it off as soon as possible.

comment:6 Changed 8 years ago by wmb@…

I changed the OFW early startup code to turn off VREFOUT as soon as possible. That eliminates the LED blink on power-on and resume. See the VREFOUT waveform in the resume.PNG attachment. Apparently VREFOUT does not reach the FET threshold before it is turned off.

The VREFOUT waveform for suspend is shown in suspend.PNG. I have not found a software remedy for the LED blink on suspend. The assertion of VREFOUT on suspend occurs 300 nS after the assertion of PCI_RST# , which happens as part of the suspend sequence.

comment:7 Changed 8 years ago by wad

The circuit submitted to Quanta was revised to work with the new OFW. The longer time period circuit (and associated transistor) were thrown out. But the glitch on suspend was tough. The AD1888 asserts VREFOUT as 2V 300nS after PCI_RST# is asserted. It then rises to AVDD and tracks it down as it discharges over a period of 20-40 mS.

A clamp to PCI_RST# was inserted in place of the short time period circuit.

No blinks were seen using Q2c13b, and the "s vbias-off many" test with a bare board in a dark room.

Leaving open until confirmed in the schematics.

comment:8 Changed 7 years ago by wad

  • Resolution set to fixed
  • Status changed from assigned to closed

Circuit present in B4 and later.

Note: See TracTickets for help on using tickets.