Re: [alsa-devel] WM5102 - Help to make baytrail machine driver work
On Wed, May 04, 2016 at 10:21:21PM -0300, Paulo Sergio wrote:
Hi list,
I've been trying to make Lenovo Yoga 2 (Model 1051F) sound work on Android-x86/ Linux. [1]
Based on already discussed info from Christian Hartmann with members (see [2] and [3] ) of this list and some efforts (basically patch pxa2xx with Mika Westerberg changes, set the correct gpio int values {246 for reset / 405 for ldoena and 342 for irq_gpio} and set LDO1 vcc suppliers) we could have wm5102 initialized through spi / regmap (arizona code on drivers/mfd) and register the DAI's.
I also ported a machine driver code from a kernel Lenovo made available for a similar hardware (Lenovo yoga 2 1050 - uses the same baytrail Z3745 and wolfson wm5102 audio) [4]
Although machine driver is registered, we still don't have sound. Tried some mixer settings / routes used on raspberry pi, but none help. Application (in this case alsa / Android players) returns a "Device or resource busy" when trying to ioctl pcm device:
A quick look through your machine driver looks like the parts relating the CODEC look ok.
I am not so sure about the AP side routing but for the CODEC,
'HPOUT1L Input 1' AIF1RX1 'HPOUT1R Input 1' AIF1RX2 'HPOUT1 Digital Switch' 1
Should be enough to route some audio out the headphones, assuming AIF1 is connected to the AP and HPOUT1L is the headphones (it is very rare for people to not wire things up that way so its quite a good bet, and your machine driver suggests this is how it is connected).
If you provide some kernel logs with the LOG_DEVICE in drivers/base/regmap/regmap.c set to the CODEC spi device, I am happy to sanity check what is going to the CODEC. Although at the moment I think your issue looks mostly like getting through the AP side.
Thanks, Charles
Hi Charles, how are you?
A quick look through your machine driver looks like the parts relating the CODEC look ok.
I am not so sure about the AP side routing but for the CODEC,
'HPOUT1L Input 1' AIF1RX1 'HPOUT1R Input 1' AIF1RX2 'HPOUT1 Digital Switch' 1
Should be enough to route some audio out the headphones, assuming AIF1 is connected to the AP and HPOUT1L is the headphones (it is very rare for people to not wire things up that way so its quite a good bet, and your machine driver suggests this is how it is connected).
Tried these cmds/routes to enable headphones (got from Raspberry PI wolfson card), but we got no output (except static noise and some "clicks")
alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Switch' on # Set path gain to -6dB for safety. ie mav 0.5Vrms output level. alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Volume' 116 # do we want to clear the HPOUT mixers inputs? alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' AIF1RX1 alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' AIF1RX2 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='Headset Mic Switch' on
Tried also some other controls for speakers, but no audio output
If you provide some kernel logs with the LOG_DEVICE in drivers/base/regmap/regmap.c set to the CODEC spi device, I am happy to sanity check what is going to the CODEC. Although at the moment I think your issue looks mostly like getting through the AP side.
Appreciate your help. Thanks in advance
Here's dmesg with LOG_DEVICE set (in this case to "spi-WM510204:00") [1]
[1] - https://drive.google.com/file/d/0BxO6THtB865fS2NxUkdOa18zUlE/view?usp=sharin...
Regards Pstglia
Hi Charles, how are you?
A quick look through your machine driver looks like the parts relating the CODEC look ok.
I am not so sure about the AP side routing but for the CODEC,
'HPOUT1L Input 1' AIF1RX1 'HPOUT1R Input 1' AIF1RX2 'HPOUT1 Digital Switch' 1
Should be enough to route some audio out the headphones, assuming AIF1 is connected to the AP and HPOUT1L is the headphones (it is very rare for people to not wire things up that way so its quite a good bet, and your machine driver suggests this is how it is connected).
Tried these cmds/routes to enable headphones (got from Raspberry PI wolfson card), but we got no output (except static noise and some "clicks")
alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Switch' on # Set path gain to -6dB for safety. ie mav 0.5Vrms output level. alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Volume' 116 # do we want to clear the HPOUT mixers inputs? alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' AIF1RX1 alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' AIF1RX2 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='Headset Mic Switch' on
Tried also some other controls for speakers, but no audio output
If you provide some kernel logs with the LOG_DEVICE in drivers/base/regmap/regmap.c set to the CODEC spi device, I am happy to sanity check what is going to the CODEC. Although at the moment I think your issue looks mostly like getting through the AP side.
Appreciate your help. Thanks in advance
Here's dmesg with LOG_DEVICE set (in this case to "spi-WM510204:00") [1]
[1] - https://drive.google.com/file/d/0BxO6THtB865fS2NxUkdOa18zUlE/view?usp=sharin...
Regards Pstglia
On Sun, May 08, 2016 at 08:44:09AM -0300, Paulo Sergio wrote:
Hi Charles, how are you?
Good thanks.
A quick look through your machine driver looks like the parts relating the CODEC look ok.
I am not so sure about the AP side routing but for the CODEC,
'HPOUT1L Input 1' AIF1RX1 'HPOUT1R Input 1' AIF1RX2 'HPOUT1 Digital Switch' 1
Should be enough to route some audio out the headphones, assuming AIF1 is connected to the AP and HPOUT1L is the headphones (it is very rare for people to not wire things up that way so its quite a good bet, and your machine driver suggests this is how it is connected).
Tried these cmds/routes to enable headphones (got from Raspberry PI wolfson card), but we got no output (except static noise and some "clicks")
alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Switch' on # Set path gain to -6dB for safety. ie mav 0.5Vrms output level. alsa_amixer -Dhw:0 cset name='HPOUT1 Digital Volume' 116 # do we want to clear the HPOUT mixers inputs? alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1R Input 2' None alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1' AIF1RX1 alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' AIF1RX2 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='Headset Mic Switch' on
From your machine driver I would have expected this last control
to be "Headphone Switch", although I do appear to see things turning on in your log so I guess that switch is already on?
Tried also some other controls for speakers, but no audio output
If you provide some kernel logs with the LOG_DEVICE in drivers/base/regmap/regmap.c set to the CODEC spi device, I am happy to sanity check what is going to the CODEC. Although at the moment I think your issue looks mostly like getting through the AP side.
Appreciate your help. Thanks in advance
Here's dmesg with LOG_DEVICE set (in this case to "spi-WM510204:00") [1]
[1] - https://drive.google.com/file/d/0BxO6THtB865fS2NxUkdOa18zUlE/view?usp=sharin...
[ 52.859420] arizona spi-WM510204:00: 173 <= a8d [ 52.859451] arizona spi-WM510204:00: 174 <= c35 [ 52.859458] arizona spi-WM510204:00: 176 <= 40 [ 52.859466] arizona spi-WM510204:00: 179 <= 10 [ 52.871213] arizona spi-WM510204:00: 172 <= 8007 [ 52.871245] arizona spi-WM510204:00: 171 <= 1
Your FLL setting here look right, assuming a 25MHz MCLK1 and a 48k playback and no sign that the FLL failed to lock, so we very likely have a clock.
[ 52.873069] arizona spi-WM510204:00: 500 <= b [ 52.873082] arizona spi-WM510204:00: 505 <= 20 [ 52.873089] arizona spi-WM510204:00: 506 <= 20 [ 52.873096] arizona spi-WM510204:00: 507 <= 1010 [ 52.873104] arizona spi-WM510204:00: 508 <= 1010
The audio interface looks like it is setup for 16bit 48k I2S.
Looks like both the HPOUTs are being unmuted:
[ 157.115973] arizona spi-WM510204:00: 411 <= 280 [ 157.126963] arizona spi-WM510204:00: 415 <= 280
The left headphone output appears to be powering up:
[ 280.668563] arizona spi-WM510204:00: 400 <= 2
The mixer source appears to be applying (HPOUT1L <= AIF1RX1)
[ 280.686634] arizona spi-WM510204:00: 680 <= 20
Overall, I would say it looks good. One thing I would perhaps try, connect up this path as you have been doing, but whilst the audio is playing (or attempting to at least) connect the route:
'HPOUT1R Input 1' 'Tone Generator 1'
This will hook the right headphone channel up to the chips internal 1k tone generator. Careful it will be loud, but its a good check to make sure the clocks are all happy inside the chip. If you hear that tone, I would say the CODEC side looks happy, but let me know how you get on.
Thanks, Charles
Hi again
2016-05-09 11:22 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
alsa_amixer -Dhw:0 cset name='HPOUT1L Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1' AIF1RX2 alsa_amixer -Dhw:0 cset name='HPOUT1R Input 1 Volume' 32 alsa_amixer -Dhw:0 cset name='Headset Mic Switch' on
From your machine driver I would have expected this last control to be "Headphone Switch", although I do appear to see things turning on in your log so I guess that switch is already on?
It was already on. But just in case, I've added it to alsa_amixer cmd list
Added also the routes/controls that Pierre pointed on his github UCM ( see [1] )
Overall, I would say it looks good. One thing I would perhaps try, connect up this path as you have been doing, but whilst the audio is playing (or attempting to at least) connect the route:
'HPOUT1R Input 1' 'Tone Generator 1'
This will hook the right headphone channel up to the chips internal 1k tone generator. Careful it will be loud, but its a good check to make sure the clocks are all happy inside the chip. If you hear that tone, I would say the CODEC side looks happy, but let me know how you get on.
We tried, but unfortunatelly no tone when hooking the tone generator. Saved dmesg, logcat and alsa_amixer output in case you want to take a look [2]
I'm still having this message on logcat: "out_write: error -1 - cannot prepare channel: Device or resource busy" which happens when trying to ioctl SNDRV_PCM_IOCTL_PREPARE to /dev/snd/pcmC0D0p
Maybe the problem is something wrong/missing on Machine Driver... Pierre said It would be good base the code on bytcr_5640...
* * *
I tried also other thing. So far I've been changing host_ipc_index from 5 to 0 on atom/sst/sst_acpi, because this device's DSDT uses a different IRQ order from what drivers expect. It allows fw loading and card registering, but I was wondering if the other index entries are mapped by the driver.
To ensure all indexes are read in the position driver wants, I modified irq order on DSDT, reverted ipc_host_index to 5 and tried booting it. I tested it, but the results are the samewhen using original DSDT and changing host_ipc_index to 0. Saved replaced DSDT and logs here [3]
* * *
Regards Pstglia
[1] - https://drive.google.com/file/d/0BxO6THtB865fQnQyZkx6c05Nbjg/view?usp=sharin... [2] - https://drive.google.com/folderview?id=0BxO6THtB865fZk5sSEdrbTVsREU&usp=... [3] - https://drive.google.com/folderview?id=0BxO6THtB865fWGU1MTlJazBnZzg&usp=...
On Thu, May 12, 2016 at 11:54:55PM -0300, Paulo Sergio wrote:
Hi again
2016-05-09 11:22 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
'HPOUT1R Input 1' 'Tone Generator 1'
This will hook the right headphone channel up to the chips internal 1k tone generator. Careful it will be loud, but its a good check to make sure the clocks are all happy inside the chip. If you hear that tone, I would say the CODEC side looks happy, but let me know how you get on.
We tried, but unfortunatelly no tone when hooking the tone generator. Saved dmesg, logcat and alsa_amixer output in case you want to take a look [2]
Hmm... that is really odd, I would very much have expected that to work or the FLL to have given us a lock timed out error, which it didn't appear to be from your log.
Could perhaps send through a register dump of the CODEC whilst in this state? You can do this through the regmap debugfs it would be good to turn cache_bypass on as well whilst doing it to make sure we capture the actual hardware status.
I'm still having this message on logcat: "out_write: error -1 - cannot prepare channel: Device or resource busy" which happens when trying to ioctl SNDRV_PCM_IOCTL_PREPARE to /dev/snd/pcmC0D0p
Maybe the problem is something wrong/missing on Machine Driver... Pierre said It would be good base the code on bytcr_5640...
Yeah this is pretty unlikely to be coming from the CODEC side.
Thanks, Charles
Hi Charles,
2016-05-09 11:22 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
'HPOUT1R Input 1' 'Tone Generator 1'
This will hook the right headphone channel up to the chips internal 1k tone generator. Careful it will be loud, but its a good check to make sure the clocks are all happy inside the chip. If you hear that tone, I would say the CODEC side looks happy, but let me know how you get on.
We tried, but unfortunatelly no tone when hooking the tone generator. Saved dmesg, logcat and alsa_amixer output in case you want to take a look [2]
Hmm... that is really odd, I would very much have expected that to work or the FLL to have given us a lock timed out error, which it didn't appear to be from your log.
Could perhaps send through a register dump of the CODEC whilst in this state? You can do this through the regmap debugfs it would be good to turn cache_bypass on as well whilst doing it to make sure we capture the actual hardware status.
Here's the link for info collected [1]. Got info from the following files while attempting to play audio, with cache_bypass set to "Y" and with 'HPOUT1R Input 1' hooked to 'Tone Generator 1':
name registers access range rbtree
Thanks again for your help!
[1] - https://drive.google.com/folderview?id=0BxO6THtB865fSUZ3MDdFYktHanc&usp=...
On Sat, May 14, 2016 at 08:14:57PM -0300, Paulo Sergio wrote:
Hi Charles,
2016-05-09 11:22 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
'HPOUT1R Input 1' 'Tone Generator 1'
This will hook the right headphone channel up to the chips internal 1k tone generator. Careful it will be loud, but its a good check to make sure the clocks are all happy inside the chip. If you hear that tone, I would say the CODEC side looks happy, but let me know how you get on.
We tried, but unfortunatelly no tone when hooking the tone generator. Saved dmesg, logcat and alsa_amixer output in case you want to take a look [2]
Hmm... that is really odd, I would very much have expected that to work or the FLL to have given us a lock timed out error, which it didn't appear to be from your log.
Could perhaps send through a register dump of the CODEC whilst in this state? You can do this through the regmap debugfs it would be good to turn cache_bypass on as well whilst doing it to make sure we capture the actual hardware status.
Here's the link for info collected [1]. Got info from the following files while attempting to play audio, with cache_bypass set to "Y" and with 'HPOUT1R Input 1' hooked to 'Tone Generator 1':
name registers access range rbtree
Thanks again for your help!
[1] - https://drive.google.com/folderview?id=0BxO6THtB865fSUZ3MDdFYktHanc&usp=...
That is a bit of a head scratcher, everything looks setup correctly in the register map, tone gen goes to the output everything is unmuted, everything is turned on. Even the IRQ registers definitely show that the FLL locked. I can only really think of a couple of options:
1) Probably the most likely option is that the clock to the FLL is being removed before you are setting up your route. Probably a reasonable thing to do next for test purposes would be to change the machine driver to use the 32k clock that should be on MCLK2 incase the high quality clock on MCLK1 is being removed and then try again.
2) HPOUT1 is not the headphones, but this is exceptionally unlikely but you could try the other HPOUT's just in case.
Thanks, Charles
participants (2)
-
Charles Keepax -
Paulo Sergio