Re: [alsa-devel] WM5102 - Help to make baytrail machine driver work
Adding alsa list + intel devs (Sorry for that )
Inline answers for Charles Keepax questions bellow:
2017-05-08 5:24 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Sun, May 07, 2017 at 10:42:31PM -0300, Paulo Sergio wrote:
Hi,
I'm trying to make wm5102 work on Lenovo Yoga 2 1051F (Baytrail) again and would like some tips.
With a revised machine driver code [1] ( based on bytcr_rt5640 and some ports from Lenovo kernel [2]) I can initialize and setting routes with alsa mixer [3], I still don't have sound.
However now if I connect 'HPOUT1' to 'Tone Generator 1' I can hear the 1k tone. Question: When I do this association, it is using my route? (in my case CODEC OUT -> SSP0 TX -> AIF1RX) Or this internal tone generator has a direct link to HPOUTs?
Here's some lines from my dmesg output while attemptig to play something (complete dmesg - see [4]):
[ 211.801176] arizona spi-WM510204:00: FLL1: Fref=25000000 Fout=49152000 [ 211.801184] arizona spi-WM510204:00: FLL1: Fvco=98304000Hz [ 211.801190] arizona spi-WM510204:00: FLL1: GCD=4000 [ 211.801195] arizona spi-WM510204:00: FLL1: N=7 THETA=a8d LAMBDA=c35 [ 211.801200] arizona spi-WM510204:00: FLL1: FRATIO=0(0) OUTDIV=2 REFCLK_DIV=1 [ 211.801204] arizona spi-WM510204:00: FLL1: GAIN=4 [ 211.801210] arizona spi-WM510204:00: 173 <= a8d [ 211.801227] arizona spi-WM510204:00: 174 <= c35 [ 211.801234] arizona spi-WM510204:00: 176 <= 40 [ 211.801241] arizona spi-WM510204:00: 179 <= 10 [ 211.813301] arizona spi-WM510204:00: 172 <= 8007 [ 211.813353] arizona spi-WM510204:00: 171 <= 1 [ 211.813366] arizona spi-WM510204:00: FLL1: Waiting for FLL lock... [ 211.814098] arizona spi-WM510204:00: d23 => 100 [ 211.814641] arizona spi-WM510204:00: d23 => 101 [ 211.814651] arizona spi-WM510204:00: FLL1: FLL locked (1 polls) [ 211.814660] arizona spi-WM510204:00: SYSCLK set to 49152000Hz [ 211.814668] arizona spi-WM510204:00: SYSCLK set to 49152000Hz [ 211.814675] arizona spi-WM510204:00: 101 <= 300 [ 211.814882] wm5102-codec wm5102-codec: AIF1: BCLK 1536000Hz LRCLK 48000Hz [ 211.814892] arizona spi-WM510204:00: 80 <= 3 [ 211.815191] arizona spi-WM510204:00: 4dc <= 0 [ 211.815339] arizona spi-WM510204:00: 4dd <= 0 [ 211.815460] arizona spi-WM510204:00: 80 <= 0 [ 211.815662] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp0-port [ 211.816833] wm5102-codec wm5102-codec: AIF1: BCLK 1536000Hz LRCLK 48000Hz [ 211.816845] arizona spi-WM510204:00: 80 <= 3 [ 211.817030] arizona spi-WM510204:00: 4dc <= 0 [ 211.817287] arizona spi-WM510204:00: 4dd <= 0
Thanks in advance!
[1] - https://github.com/pstglia/linux/tree/lenovo_yoga2_returns [2] - https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.... [3] - https://drive.google.com/file/d/0BxO6THtB865fQnQyZkx6c05Nbjg/view?usp=sharin... [4] - https://drive.google.com/file/d/0BxO6THtB865fRy0xV3F0elRrUHM/view?usp=sharin...
OK good news you are getting sound from the Tone generator, that likely implies things are setup sensibly on the CODEC side. My suspicion would be that data is not making it over the I2S. Probalby worth copying the Intel guys on the email, as I don't know know much about that side of things.
Copied alsa list and Intel guys (hit reply instead of reply all - my apologies)
How are you setting up the I2S? As in which side is master, what format are you using? Also do you see any over/underflow error, does the system complain with "Error playing sample".
The only part where I2S is explicity used on machine driver is this setting on backend DAI (SSP0-Codec)
dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS,
And after setting the routes using routes mentioned on [3], I have no errors, but no sound
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
x86_64:/data # alsa_aplay -v TNT.mp3 Playing raw data 'TNT.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono Plug PCM: Rate conversion PCM (48000, sformat=U8) Converter: linear-interpolation Protocol version: 10002 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : U8 subformat : STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 8 buffer_size : 4000 period_size : 1000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 1000 period_event : 0 start_threshold : 4000 stop_threshold : 4000 silence_threshold: 0 silence_size : 0 boundary : 262144000 Slave: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0 1 <- 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : U8 subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 8 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 Slave: Hardware PCM card 0 'baytrailcraudio' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 appl_ptr : 0 hw_ptr : 0
Regards, Pstglia
On 5/8/17 7:57 PM, Paulo Sergio wrote:
Adding alsa list + intel devs (Sorry for that )
Inline answers for Charles Keepax questions bellow:
2017-05-08 5:24 GMT-03:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Sun, May 07, 2017 at 10:42:31PM -0300, Paulo Sergio wrote:
Hi,
I'm trying to make wm5102 work on Lenovo Yoga 2 1051F (Baytrail) again and would like some tips.
With a revised machine driver code [1] ( based on bytcr_rt5640 and some ports from Lenovo kernel [2]) I can initialize and setting routes with alsa mixer [3], I still don't have sound.
However now if I connect 'HPOUT1' to 'Tone Generator 1' I can hear the 1k tone. Question: When I do this association, it is using my route? (in my case CODEC OUT -> SSP0 TX -> AIF1RX) Or this internal tone generator has a direct link to HPOUTs?
Here's some lines from my dmesg output while attemptig to play something (complete dmesg - see [4]):
[ 211.801176] arizona spi-WM510204:00: FLL1: Fref=25000000 Fout=49152000 [ 211.801184] arizona spi-WM510204:00: FLL1: Fvco=98304000Hz [ 211.801190] arizona spi-WM510204:00: FLL1: GCD=4000 [ 211.801195] arizona spi-WM510204:00: FLL1: N=7 THETA=a8d LAMBDA=c35 [ 211.801200] arizona spi-WM510204:00: FLL1: FRATIO=0(0) OUTDIV=2 REFCLK_DIV=1 [ 211.801204] arizona spi-WM510204:00: FLL1: GAIN=4 [ 211.801210] arizona spi-WM510204:00: 173 <= a8d [ 211.801227] arizona spi-WM510204:00: 174 <= c35 [ 211.801234] arizona spi-WM510204:00: 176 <= 40 [ 211.801241] arizona spi-WM510204:00: 179 <= 10 [ 211.813301] arizona spi-WM510204:00: 172 <= 8007 [ 211.813353] arizona spi-WM510204:00: 171 <= 1 [ 211.813366] arizona spi-WM510204:00: FLL1: Waiting for FLL lock... [ 211.814098] arizona spi-WM510204:00: d23 => 100 [ 211.814641] arizona spi-WM510204:00: d23 => 101 [ 211.814651] arizona spi-WM510204:00: FLL1: FLL locked (1 polls) [ 211.814660] arizona spi-WM510204:00: SYSCLK set to 49152000Hz [ 211.814668] arizona spi-WM510204:00: SYSCLK set to 49152000Hz [ 211.814675] arizona spi-WM510204:00: 101 <= 300 [ 211.814882] wm5102-codec wm5102-codec: AIF1: BCLK 1536000Hz LRCLK 48000Hz [ 211.814892] arizona spi-WM510204:00: 80 <= 3 [ 211.815191] arizona spi-WM510204:00: 4dc <= 0 [ 211.815339] arizona spi-WM510204:00: 4dd <= 0 [ 211.815460] arizona spi-WM510204:00: 80 <= 0 [ 211.815662] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp0-port [ 211.816833] wm5102-codec wm5102-codec: AIF1: BCLK 1536000Hz LRCLK 48000Hz [ 211.816845] arizona spi-WM510204:00: 80 <= 3 [ 211.817030] arizona spi-WM510204:00: 4dc <= 0 [ 211.817287] arizona spi-WM510204:00: 4dd <= 0
Thanks in advance!
[1] - https://github.com/pstglia/linux/tree/lenovo_yoga2_returns [2] - https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.... [3] - https://drive.google.com/file/d/0BxO6THtB865fQnQyZkx6c05Nbjg/view?usp=sharin... [4] - https://drive.google.com/file/d/0BxO6THtB865fRy0xV3F0elRrUHM/view?usp=sharin...
OK good news you are getting sound from the Tone generator, that likely implies things are setup sensibly on the CODEC side. My suspicion would be that data is not making it over the I2S. Probalby worth copying the Intel guys on the email, as I don't know know much about that side of things.
Copied alsa list and Intel guys (hit reply instead of reply all - my apologies)
How are you setting up the I2S? As in which side is master, what format are you using? Also do you see any over/underflow error, does the system complain with "Error playing sample".
The only part where I2S is explicity used on machine driver is this setting on backend DAI (SSP0-Codec)
dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS,
And after setting the routes using routes mentioned on [3], I have no errors, but no sound
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
nope. I don't know how many issues we've fixed since 4.4 but it's not a matter of just swapping out one firmware with another. You'll have better luck with plain vanilla 4.11 + regular firmware and restarting modifying one of the latest machine drivers.
x86_64:/data # alsa_aplay -v TNT.mp3 Playing raw data 'TNT.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono Plug PCM: Rate conversion PCM (48000, sformat=U8) Converter: linear-interpolation Protocol version: 10002 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : U8 subformat : STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 8 buffer_size : 4000 period_size : 1000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 1000 period_event : 0 start_threshold : 4000 stop_threshold : 4000 silence_threshold: 0 silence_size : 0 boundary : 262144000 Slave: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0 1 <- 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : U8 subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 8 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 Slave: Hardware PCM card 0 'baytrailcraudio' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 appl_ptr : 0 hw_ptr : 0
Regards, Pstglia
How are you setting up the I2S? As in which side is master, what format are you using? Also do you see any over/underflow error, does the system complain with "Error playing sample".
The only part where I2S is explicity used on machine driver is this setting on backend DAI (SSP0-Codec)
dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS,
And after setting the routes using routes mentioned on [3], I have no errors, but no sound
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
nope. I don't know how many issues we've fixed since 4.4 but it's not a matter of just swapping out one firmware with another. You'll have better luck with plain vanilla 4.11 + regular firmware and restarting modifying one of the latest machine drivers.
Ok, I'll use 4.11 and post the results later
Should I have any special care about I2S other than setting the format um backend DAI? Some module should be loaded?
Regards Pstglia
On 5/9/17 9:45 AM, Paulo Sergio wrote:
How are you setting up the I2S? As in which side is master, what format are you using? Also do you see any over/underflow error, does the system complain with "Error playing sample".
The only part where I2S is explicity used on machine driver is this setting on backend DAI (SSP0-Codec)
dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS,
And after setting the routes using routes mentioned on [3], I have no errors, but no sound
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
nope. I don't know how many issues we've fixed since 4.4 but it's not a matter of just swapping out one firmware with another. You'll have better luck with plain vanilla 4.11 + regular firmware and restarting modifying one of the latest machine drivers.
Ok, I'll use 4.11 and post the results later
Should I have any special care about I2S other than setting the format um backend DAI? Some module should be loaded?
Things to look for - SSP routing: has to be SSP0 on baytrail-CR - number of slots: 2 or 4. if 4 then use DSP mode - DAI format - MCLK
If I can get my hands on a WM5102 eval board I might be able to help with a MinnowMax board.
On Tue, May 09, 2017 at 09:57:14AM -0500, Pierre-Louis Bossart wrote:
On 5/9/17 9:45 AM, Paulo Sergio wrote:
How are you setting up the I2S? As in which side is master, what format are you using? Also do you see any over/underflow error, does the system complain with "Error playing sample".
The only part where I2S is explicity used on machine driver is this setting on backend DAI (SSP0-Codec)
dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS,
And after setting the routes using routes mentioned on [3], I have no errors, but no sound
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
nope. I don't know how many issues we've fixed since 4.4 but it's not a matter of just swapping out one firmware with another. You'll have better luck with plain vanilla 4.11 + regular firmware and restarting modifying one of the latest machine drivers.
Ok, I'll use 4.11 and post the results later
Should I have any special care about I2S other than setting the format um backend DAI? Some module should be loaded?
Things to look for
- SSP routing: has to be SSP0 on baytrail-CR
- number of slots: 2 or 4. if 4 then use DSP mode
- DAI format
- MCLK
If I can get my hands on a WM5102 eval board I might be able to help with a MinnowMax board.
If you really want one I can ask about see if we can send you one over?
Thanks, Charles
Hi everybody
Note: Based on Lenovo code, I concluded this device uses ssp0, so I'm using a fw file "fw_sst_0f28_ssp0.bin" posted another thread. Could use the hacks used on kernel 4.11, but as I'm still testing with kernel 4.4, using this fw would make things easier
nope. I don't know how many issues we've fixed since 4.4 but it's not a matter of just swapping out one firmware with another. You'll have better luck with plain vanilla 4.11 + regular firmware and restarting modifying one of the latest machine drivers.
Ok, I'll use 4.11 and post the results later
Should I have any special care about I2S other than setting the format um backend DAI? Some module should be loaded?
Things to look for
- SSP routing: has to be SSP0 on baytrail-CR
- number of slots: 2 or 4. if 4 then use DSP mode
- DAI format
- MCLK
Hi, I'd like to share a feedback:
I switched to kernel 4.11, applied some previous changes (made with kernel 4.4) and started a new machine driver using bytcr_rt5640 as base.
After some adjustments and a temp fix (see remarks bellow) I was able to route sound using headphones Routing to speaker doesn't give any audio (Lenovo code seems to uses GPIO to power/enable speakers on probe before setting routes...)
Remarks:
* setting pll/fll using snd_soc_dai_set_pll didn't work. I had to map the codec member from snd_soc_dai struct and use snd_soc_codec_set_pll instead (used the same constants used on Lenovo source code)
- Had also to set sysclk to codecs, not only to dai's using snd_soc_codec_set_sysclk
* This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
* Used commands from rt5640 UCM file, removing 5640 specifics and using Wolfson ones (thanks to Charles for point this out previously): cset name='HPOUT1L Input 1' AIF1RX1 cset name='HPOUT1R Input 1' AIF1RX2 cset name='HPOUT1 Digital Switch' on
cset name='Headphone Switch' on
* Used some patches to enable wm5102 ACPI detection (credits to Christian Hartmann)
* Added a voltage supplier needed to wm5102 (added to arizona-ldo directly - Lenovo and rpi register a platform with these) * hardcoded ldoena, reset and irq_gpio on arizona-core (tried to get those from gpio, but they didn't give me the correct values. Lack of knowledge... )
* The codec chip uses SPI, not IC2 like 5640 (don't know if this is relevant for machine driver code)
I've pushed these to github in case you want to check it [A]
Also, this is the Android-x86 testing image generated with these changes [B]
Many thanks for the support!
Regards, Pstglia
[A] - https://github.com/pstglia/linux/tree/lenovo_yoga2_returns-4.11 [B] - https://drive.google.com/file/d/0BxO6THtB865fQ3VhRUZoc1BMNkE/view?usp=sharin...
On Sat, May 13, 2017 at 02:11:31AM -0300, Paulo Sergio wrote:
Remarks:
- setting pll/fll using snd_soc_dai_set_pll didn't work. I had to map
the codec member from snd_soc_dai struct and use snd_soc_codec_set_pll instead (used the same constants used on Lenovo source code)
Yes this is correct you will need to call snd_soc_codec_set_pll to configure the FLLs on the chip. As the FLLs are not tied to a particular DAI it doesn't really make sense to configure them from dai_set_pll.
- Had also to set sysclk to codecs, not only to dai's using
snd_soc_codec_set_sysclk
Again this also makes sense snd_soc_codec_set_sysclk is how you configure the sysclk on this device. Again here the sysclk is chip wide.
- This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios
status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
- Used commands from rt5640 UCM file, removing 5640 specifics and
using Wolfson ones (thanks to Charles for point this out previously): cset name='HPOUT1L Input 1' AIF1RX1 cset name='HPOUT1R Input 1' AIF1RX2 cset name='HPOUT1 Digital Switch' on
cset name='Headphone Switch' on
- Used some patches to enable wm5102 ACPI detection (credits to
Christian Hartmann)
- Added a voltage supplier needed to wm5102 (added to arizona-ldo
directly - Lenovo and rpi register a platform with these)
Should probably look at splitting that out into its own regulator and making it the supply for the LDO.
- hardcoded ldoena, reset and irq_gpio on arizona-core (tried to get
those from gpio, but they didn't give me the correct values. Lack of knowledge... )
Not sure on this front I am afraid.
- The codec chip uses SPI, not IC2 like 5640 (don't know if this is
relevant for machine driver code)
This should not matter from the machine driver it should all be hidden behing regmap at that level.
Thanks, Charles
On 5/13/17 12:11 AM, Paulo Sergio wrote:
- This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios
status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
Are you sure it's Baytrail-CR? where does this information come from? Those fields are tied to which PMIC is used and it would be extremely surprising to have a disconnect.
Hi Pierre
Em 15/05/2017 09:44, "Pierre-Louis Bossart" < pierre-louis.bossart@linux.intel.com> escreveu:
On 5/13/17 12:11 AM, Paulo Sergio wrote:
- This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios
status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
Are you sure it's Baytrail-CR? where does this information come from? Those fields are tied to which PMIC is used and it would be extremely surprising to have a disconnect.
Sorry, I should have said that I assumed it is a Baytrail CR device because these features:
* it's a Z3745 soc * acpi_ipc_irq_index used is 0 (0x1D is the 1st index listed on dsdt, just like other bytcr devices) * ssp0 is being used on this device, not ssp2 * it has a 25mhz clk
But these are not enough to state it is a bytcr right?
Regards Pstglia
Hi Pierre / List, how are you?
2017-05-15 10:10 GMT-03:00 Paulo Sergio pstglia@gmail.com:
Hi Pierre
Em 15/05/2017 09:44, "Pierre-Louis Bossart" pierre-louis.bossart@linux.intel.com escreveu:
On 5/13/17 12:11 AM, Paulo Sergio wrote:
- This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios
status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
Are you sure it's Baytrail-CR? where does this information come from? Those fields are tied to which PMIC is used and it would be extremely surprising to have a disconnect.
Sorry, I should have said that I assumed it is a Baytrail CR device because these features:
- it's a Z3745 soc
- acpi_ipc_irq_index used is 0 (0x1D is the 1st index listed on dsdt, just
like other bytcr devices)
- ssp0 is being used on this device, not ssp2
- it has a 25mhz clk
But these are not enough to state it is a bytcr right?
I tried to find some info/document on web that shows if Z3745 is a CR device or not, but I couldn't (comparing the launch price with other BYT released at the same date, like Z3735G/F, it is not - however, features match the criteria of bytcr like ssp0, acpi_ipc_irq_index, etc )
In any case, in order to use &bytcr_rvp_platform_data, I was thinking to add a quirk to this device. Do you think something like this would be accepted as a patch?
--- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -404,6 +404,7 @@ static unsigned long cht_machine_id;
#define CHT_SURFACE_MACH 1 #define BYT_THINKPAD_10 2 +#define BYT_LENOVO_YOGA2 3
static int cht_surface_quirk_cb(const struct dmi_system_id *id) { @@ -404,6 +404,7 @@ static unsigned long cht_machine_id;
#define CHT_SURFACE_MACH 1 #define BYT_THINKPAD_10 2 +#define BYT_LENOVO_YOGA2 3
static int cht_surface_quirk_cb(const struct dmi_system_id *id) { { @@ -417,6 +418,12 @@ static int byt_thinkpad10_quirk_cb(const struct dmi_system_id *id) return 1; }
+static int byt_yoga2_quirk_cb(const struct dmi_system_id *id) +{ + cht_machine_id = BYT_LENOVO_YOGA2; + return 1; +} +
static const struct dmi_system_id byt_table[] = { { @@ -426,6 +433,13 @@ static const struct dmi_system_id byt_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "20C3001VHH"), }, }, + { + .callback = byt_yoga2_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_CHASSIS_VERSION, "1051F"), + }, + }, { } };
@@ -440,7 +454,6 @@ static const struct dmi_system_id cht_table[] = { { } };
- static struct sst_acpi_mach cht_surface_mach = { "10EC5640", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "cht-bsw", NULL,
&chv_platform_data }; @@ -449,6 +462,14 @@ static struct sst_acpi_mach byt_thinkpad_10 = { "10EC5640", "cht-bsw-rt5672", "intel/fw_sst_0f28.bin", "cht-bsw", NULL,
&byt_rvp_platform_data };
+static struct sst_acpi_mach byt_thinkpad_10 = { + "10EC5640", "cht-bsw-rt5672", "intel/fw_sst_0f28.bin", "cht-bsw", NULL, + &byt_rvp_platform_data }; + +static struct sst_acpi_mach byt_lenovo_yoga2 = { + {"WM510204", "bytcr_wm5102", "intel/fw_sst_0f28.bin", "bytcr_wm5102", NULL, + &bytcr_rvp_platform_data }; + static struct sst_acpi_mach *cht_quirk(void *arg) { struct sst_acpi_mach *mach = arg; @@ -469,6 +490,8 @@ static struct sst_acpi_mach *byt_quirk(void *arg)
if (cht_machine_id == BYT_THINKPAD_10) return &byt_thinkpad_10; + else if (cht_machine_id == BYT_LENOVO_YOGA2) + return &byt_lenovo_yoga2; else return mach;
On 5/18/17 7:49 AM, Paulo Sergio wrote:
Hi Pierre / List, how are you?
2017-05-15 10:10 GMT-03:00 Paulo Sergio pstglia@gmail.com:
Hi Pierre
Em 15/05/2017 09:44, "Pierre-Louis Bossart" pierre-louis.bossart@linux.intel.com escreveu:
On 5/13/17 12:11 AM, Paulo Sergio wrote:
- This device (Lenovo Yoga 2 1051F) is a bytcr device. However bios
status returned by iosf_mbi_read is 1000000001000000000000101000000 (bits 26:27 disabled). Had to force bytcr flag to be true in order to apply correct MCLK frequency (25Mhz) and use SSP0
Are you sure it's Baytrail-CR? where does this information come from? Those fields are tied to which PMIC is used and it would be extremely surprising to have a disconnect.
Sorry, I should have said that I assumed it is a Baytrail CR device because these features:
- it's a Z3745 soc
- acpi_ipc_irq_index used is 0 (0x1D is the 1st index listed on dsdt, just
like other bytcr devices)
- ssp0 is being used on this device, not ssp2
- it has a 25mhz clk
But these are not enough to state it is a bytcr right?
I tried to find some info/document on web that shows if Z3745 is a CR device or not, but I couldn't (comparing the launch price with other BYT released at the same date, like Z3735G/F, it is not - however, features match the criteria of bytcr like ssp0, acpi_ipc_irq_index, etc )
I double-checked the settings. If the bits 26:27 are set to 01 or 11 then for sure it's a BYT-CR device. If the bits are left as 00 then it's the reset value and it could be either of BYT-T or BYT-CR. In all the tests we did the detection worked, looks like this is the exception to the rule.
If the ACPI IRQ index is different then that's a pretty good hint as well. I am not familiar enough with those ACPI resources but if we could part the interrupt table maybe we would avoid the quirk by making the auto detection work better.
In any case, in order to use &bytcr_rvp_platform_data, I was thinking to add a quirk to this device. Do you think something like this would be accepted as a patch?
It'd be fine to have a quirk to set BYT-CR platform data, but I don't think it makes sense to make the tables more complicated than they already are. I'd just change the is_bytcr() function to take quirks into account at that level.
And since it's quite unknown how many configurations we might see like this I would also use a module parameter to override the autodetection (similar to what Takashi did in rt5640).
I'd also use this information in the machine driver to either use SSP2 or SSP0.
--- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -404,6 +404,7 @@ static unsigned long cht_machine_id;
#define CHT_SURFACE_MACH 1 #define BYT_THINKPAD_10 2 +#define BYT_LENOVO_YOGA2 3
static int cht_surface_quirk_cb(const struct dmi_system_id *id) { @@ -404,6 +404,7 @@ static unsigned long cht_machine_id;
#define CHT_SURFACE_MACH 1 #define BYT_THINKPAD_10 2 +#define BYT_LENOVO_YOGA2 3
static int cht_surface_quirk_cb(const struct dmi_system_id *id) { { @@ -417,6 +418,12 @@ static int byt_thinkpad10_quirk_cb(const struct dmi_system_id *id) return 1; }
+static int byt_yoga2_quirk_cb(const struct dmi_system_id *id) +{
cht_machine_id = BYT_LENOVO_YOGA2;return 1;+}
static const struct dmi_system_id byt_table[] = { { @@ -426,6 +433,13 @@ static const struct dmi_system_id byt_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "20C3001VHH"), }, },
{.callback = byt_yoga2_quirk_cb,.matches = {DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),DMI_MATCH(DMI_CHASSIS_VERSION, "1051F"),},}, { }};
@@ -440,7 +454,6 @@ static const struct dmi_system_id cht_table[] = { { } };
static struct sst_acpi_mach cht_surface_mach = { "10EC5640", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "cht-bsw", NULL,
&chv_platform_data }; @@ -449,6 +462,14 @@ static struct sst_acpi_mach byt_thinkpad_10 = { "10EC5640", "cht-bsw-rt5672", "intel/fw_sst_0f28.bin", "cht-bsw", NULL,
&byt_rvp_platform_data };
+static struct sst_acpi_mach byt_thinkpad_10 = {
"10EC5640", "cht-bsw-rt5672", "intel/fw_sst_0f28.bin", "cht-bsw", NULL,&byt_rvp_platform_data };
+static struct sst_acpi_mach byt_lenovo_yoga2 = {
{"WM510204", "bytcr_wm5102", "intel/fw_sst_0f28.bin","bytcr_wm5102", NULL,
&bytcr_rvp_platform_data };
static struct sst_acpi_mach *cht_quirk(void *arg) { struct sst_acpi_mach *mach = arg; @@ -469,6 +490,8 @@ static struct sst_acpi_mach *byt_quirk(void *arg)
if (cht_machine_id == BYT_THINKPAD_10) return &byt_thinkpad_10;
else if (cht_machine_id == BYT_LENOVO_YOGA2)return &byt_lenovo_yoga2; else return mach;
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (3)
-
Charles Keepax -
Paulo Sergio -
Pierre-Louis Bossart