2008-10-27 18:04:22 SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 64250
When testing the SSM2602 driver, using the userspace program tone, I have observed that the VMID voltage drops from ~1.6VDC to ~0VDC immediately upon terminating the program. A subsequent call to tone, done quickly, will result in a low audio level with VMID ~0.2VDC.
This behavior is observed on a custom board using Rev 0.1 silicon. When the same test is performed on the BF527-EZKIT (Rev 0.0 silicon) VMID remains at a constant 1.6VDC.
In trying to diagnose this issue the linux2.6.x/sound/soc/codecs/ssm2602.c file was modified to emit the event value from ssm2602_dapm_event. When starting the initial tone no output is observed. Shortly after terminating tone an event code of 0x300 is observerd. The behavior upon starting tone depends on whether the 0x300 event was observed or not. If the 0x300 event was seen then the 0x100 and 0x000 events are seen (in that order) immediately upon tone starting. If tone is started before the 0x300 event is seen then no events are issued.
The volume I am observing is high whenever the 0x000 event is observed upon starting tone, and low whenever the 0x000 event is not observed. Also, playing a .wav file via vplay results in low output regardless of observed output from ssm2602_dapm_event.
High volumes are always present with VMID at ~1.6VDC and low volumes are always present with VMID at ~0 to 0.2VDC.
The configuration is 2008R1.5 with the SOC audio configured to codec address of 0x1a and SPORT 1 for the custom board and address 0x1b and SPORT0 on Port F for the BF527. I have the patch http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=4448 and http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=4431 applied.
The question is what else in the code would be changing the SSM2602 power register and why is the VMID behavior different between the two boards (or likely silicon revisions)?
QuoteReplyEditDelete
2008-10-28 10:43:05 Re: SSM2602 Codec Volume Behavior
Robin Getz (UNITED STATES)
Message: 64281
Brian:
I will have to get a 0.1 and try it out on an EZkit. I don't know what would be causing the difference.
-Robin
QuoteReplyEditDelete
2008-10-29 10:20:25 Re: SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 64338
Robin,
Thanks for the reply. As I have a board with Rev 1 software I would be happy to assist with testing. If you provide either guidance or a test patch I can build it an let you know the results.
QuoteReplyEditDelete
2008-10-29 10:21:05 Re: SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 64339
Sorry...Rev 1 silicon.
QuoteReplyEditDelete
2008-11-03 22:41:56 Re: SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 64642
Thoughts anyone? We are trying to finalize a board design and this is oing to hold us up soon. I would appretiate any ideas on where to look.
My thought (unsubstantiated or investigated) is that the low level driver code is sending a power down command at the end of transmitting audio data, and before the delay driven linux power management call is issued. Then, if another audio transmission is started before the power management delay expires no power up command is issued. This leaves the hardware in a powered down state (from a VMID perspective) but also generating audio. This make the volume low.
Anyone know the driver well enough to focus my investigations?
Rev 0.0 silicon behaves differently from V0.1 silicon. I suspect, based on observed behavior, that the Rev 0.0 silicon is not responding to the power down command as VMID is always at about 1.6V. I also suspect that this was fixed in the Rev 0.1 silicon.
QuoteReplyEditDelete
2008-11-21 13:20:19 Re: SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 65693
Robin,
Any luck in getting the Rev 0.1 silicon in a BF527 EZKIT yet?
QuoteReplyEditDelete
2008-12-03 08:33:40 Re: SSM2602 Codec Volume Behavior
Brian Wenholz (UNITED STATES)
Message: 66238
Robin,
Just another piece of info for the thoughts... I noticed that vplay was always failing to bring the VMID voltage up regardless of sequence. Changing the vplay open of /dev/dsp to RW instead of WO changed this behavior to now always bringing up VMID.
This leads me to think the power management on the different open types may be treated differently in the ssm2602 driver.
I will write back with more as I have it.