Re: WM5102 - Help to make baytrail machine driver work

Re: WM5102 - Help to make baytrail machine driver work

[Pierre-Louis Bossart]

On 5/4/16 8:21 PM, 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]

There are quite a few references in the machine driver to concepts 
related to Clovertrail+ and early versions of Baytrail. I am fairly 
convinced the mentions of 'BYT_COMMS_BT' or 'modem mixing' are no longer 
supported with the DPCM platform driver/firmware you used.

To enable this codec it would be simpler to start with a newer machine 
driver derived from the bytcr_rt5640 one, with just a basic SSP0-aif1 
link for starters (+ MCLK). Better yet, do this work with a MinnowBoard 
and an WM5102 eval board and test all this with more control on how the 
hardware is setup.

If you stick to working directly on the Lenovo device, make sure you use 
all the DSP controls set in the UCM files used for baytrail/baytrail-CR 
(see github.com/plbossart/UCM).

>
> 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:
>
> 04-30 13:05:07.877  1784  2078 E audio_hw_primary: out_write: error -1 - cannot prepare channel: Device or resource busy
>
> # This is raised here (external/tinyalsa/pcm.c):
>
> if (ioctl(pcm->fd, SNDRV_PCM_IOCTL_PREPARE) < 0)
>
> return oops(pcm, errno, "cannot prepare channel");
>
>
> Note: As pointed here [5] had to change the acpi_ipc_irq_index to 0 on
> sound/soc/intel/atom/sst/sst_acpi.c because this is the 1st ACPI entry
> listed on DSDT
> I'm also trying to use a fw version that uses SSP0 [6] instead of SSP2
> used as default - but no sound with both
>
>
> I'd like some help from you in order to make this work. I've collect
> several info which can be found here [7]
>  - /proc/asound/cards
>  - /proc/interrupts
>  - amixer controls list
>  - dmesg
>  - DSDT file (decoded with iasl)
>
>
> Source code with changes made so far is available on github [8]
>
> Any hint is appreciated
>
> Thanks,
> Paulo Sérgio Travaglia (pstglia)
>
>
> [1] - https://groups.google.com/forum/#!forum/android-x86
> [2] - http://www.spinics.net/lists/linux-acpi/msg58680.html
> [3] - https://goo.gl/vBKOeI
> [4] - http://goo.gl/zriwbw
> [5] - https://bugzilla.kernel.org/show_bug.cgi?id=86581
> [6] - http://thread.gmane.org/gmane.linux.alsa.devel/134554/focus=140634
> [7]
> - https://drive.google.com/folderview?id=0BxO6THtB865fWjVHLTFfV25ORjQ&usp=sharing
> [8] - https://github.com/pstglia/linux

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

Hi Pierre, how are you?

>> 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]
>
>
> There are quite a few references in the machine driver to concepts related
> to Clovertrail+ and early versions of Baytrail. I am fairly convinced the
> mentions of 'BYT_COMMS_BT' or 'modem mixing' are no longer supported with
> the DPCM platform driver/firmware you used.

Yes, the code I ported was originally wrote for kernel 3.10.x targeted
for Android

In any case, I didn't enable this option on our kernel config

>
> To enable this codec it would be simpler to start with a newer machine
> driver derived from the bytcr_rt5640 one, with just a basic SSP0-aif1 link
> for starters (+ MCLK).

Thanks for the tip. I can try it ( create a machine driver derived
from bytcr_rt5640 ). Will just wait for Charles help on analyzing
CODEC output I provided. [1]
If he says this part seems ok, I will work on machine driver

I'm not sure this hardware uses SSP0 or SSP2, so I'm testing with both
firmwares. Is there any method I can confirm it? (querying an ACPI
entry listed on DSDT maybe?)

> Better yet, do this work with a MinnowBoard and an
> WM5102 eval board and test all this with more control on how the hardware is
> setup.

This is probably the best approach (minnowboard + WM5102 eval board).
But unfortunatelly my skills are limited...


> If you stick to working directly on the Lenovo device, make sure you use all
> the DSP controls set in the UCM files used for baytrail/baytrail-CR (see
> github.com/plbossart/UCM).

In fact, currently I don't have this device. Some volunteers from
Android-x86 google group are testing changes made on their hardware
and provide the info I ask for (logcat / dmesg / mixer output, etc)


Thanks
Pstglia

[1] - https://drive.google.com/file/d/0BxO6THtB865fS2NxUkdOa18zUlE/view?usp=sharing

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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=sharing

Regards
Pstglia

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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=sharing

Regards
Pstglia

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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=sharing

[   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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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=sharing
[2] - https://drive.google.com/folderview?id=0BxO6THtB865fZk5sSEdrbTVsREU&usp=sharing
[3] - https://drive.google.com/folderview?id=0BxO6THtB865fWGU1MTlJazBnZzg&usp=sharing

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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=sharing

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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=sharing

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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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.1/sound/soc/intel/board/byt_bl_wm5102.c
>> [3] - https://drive.google.com/file/d/0BxO6THtB865fQnQyZkx6c05Nbjg/view?usp=sharing
>> [4] - https://drive.google.com/file/d/0BxO6THtB865fRy0xV3F0elRrUHM/view?usp=sharing
>
> 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

Re: WM5102 - Help to make baytrail machine driver work

[Pierre-Louis Bossart]

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.1/sound/soc/intel/board/byt_bl_wm5102.c
>>> [3] - https://drive.google.com/file/d/0BxO6THtB865fQnQyZkx6c05Nbjg/view?usp=sharing
>>> [4] - https://drive.google.com/file/d/0BxO6THtB865fRy0xV3F0elRrUHM/view?usp=sharing
>>
>> 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
>

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

>>> 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

Re: WM5102 - Help to make baytrail machine driver work

[Pierre-Louis Bossart]

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.

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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=sharing

Re: WM5102 - Help to make baytrail machine driver work

[Charles Keepax]

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

Re: WM5102 - Help to make baytrail machine driver work

[Pierre-Louis Bossart]

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.

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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

Re: WM5102 - Help to make baytrail machine driver work

[Paulo Sergio]

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;

Re: WM5102 - Help to make baytrail machine driver work

[Pierre-Louis Bossart]

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
>