bytcr_rt5651 on wintron 7.0

bytcr_rt5651 on wintron 7.0

[Tobias Mädel]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Hello,

we're currently trying to get the new bytcr_rt5651 driver to run on a
TrekStor SurfTab wintron 7.0 (x86 tablet).

Unlike the previous driver for the rt5640 chipset, the new bytcr_rt5651
driver actually detects the card out-of-the-box.

This is the dmesg output on the device:
bytcr_rt5651: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
bytcr_rt5651: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
bytcr_rt5651: Invalid direction for compress P 0, C 0
bytcr_rt5651: ASoC: can't create compress Compress
bytcr_rt5651: ASoC: failed to instantiate card -22
bytcr_rt5651: devm_snd_soc_register_card failed -22
bytcr_rt5651: probe of bytcr_rt5651 failed with error -22

So -- apparently it is successfully initializing 2 of the DAIs, but it
can't find the Compress-DAI. My first guess would just be to try and
disable the Compress DAI in the code just for debugging, but I'm sure
that there's a better way.

I'm running a bleeding edge kernel build from the main linux git tree,
build from yesterday's github.com/torvalds/linux.git repo.

Does anyone have any ideas on how to get alsa to detect the card properly?

Here's the complete dmesg output:
https://gist.github.com/Manawyrm/70d90e95e9c578a7fb26

Attached is a (binary) dump of the ACPI tables of the device.

Best regards,
Tobias Schramm and Tobias Mädel
-- 
This email was encrypted with 2ROT-13.

Tobias Mädel
t.maedel@alfeld.de
PGP: 3A69 E9AF 3FA9 3BCF FE50 9694 494E 2F56 C304 60E1
http://tbspace.de


[-- Attachment #2: dsdt.tar.gz --]
[-- Type: application/gzip, Size: 20334 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: bytcr_rt5651 on wintron 7.0

[Pierre-Louis Bossart]

 
On 01/31/2016 07:51 AM, Tobias Mädel wrote:
> Hello,
> 
> we're currently trying to get the new bytcr_rt5651 driver to run on a
> TrekStor SurfTab wintron 7.0 (x86 tablet).
> 
> Unlike the previous driver for the rt5640 chipset, the new bytcr_rt5651
> driver actually detects the card out-of-the-box.

Good to know.

> 
> This is the dmesg output on the device:
> bytcr_rt5651: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
> bytcr_rt5651: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
> bytcr_rt5651: Invalid direction for compress P 0, C 0
> bytcr_rt5651: ASoC: can't create compress Compress
> bytcr_rt5651: ASoC: failed to instantiate card -22
> bytcr_rt5651: devm_snd_soc_register_card failed -22
> bytcr_rt5651: probe of bytcr_rt5651 failed with error -22
> 
> So -- apparently it is successfully initializing 2 of the DAIs, but it
> can't find the Compress-DAI. My first guess would just be to try and
> disable the Compress DAI in the code just for debugging, but I'm sure
> that there's a better way.
> 
> I'm running a bleeding edge kernel build from the main linux git tree,
> build from yesterday's github.com/torvalds/linux.git repo.
>
> Does anyone have any ideas on how to get alsa to detect the card properly?
> 
> Here's the complete dmesg output:
> https://gist.github.com/Manawyrm/70d90e95e9c578a7fb26

This is weird. I checked the DSDT tables and couldn't see anything blatantly wrong.
If there was a problem with the compress DAI it would show on other platforms as well.
It could also be a configuration issue with bad controls, I put my UCM configuration on github plbosssart/UCM/, you may want to look into this as well.
-Pierre

Re: bytcr_rt5651 on wintron 7.0

[Pierre-Louis Bossart]

On 02/01/2016 08:59 AM, Pierre-Louis Bossart wrote:
>  
> On 01/31/2016 07:51 AM, Tobias Mädel wrote:
>> Hello,
>>
>> we're currently trying to get the new bytcr_rt5651 driver to run on a
>> TrekStor SurfTab wintron 7.0 (x86 tablet).
>>
>> Unlike the previous driver for the rt5640 chipset, the new bytcr_rt5651
>> driver actually detects the card out-of-the-box.
> 
> Good to know.
> 
>>
>> This is the dmesg output on the device:
>> bytcr_rt5651: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
>> bytcr_rt5651: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
>> bytcr_rt5651: Invalid direction for compress P 0, C 0
>> bytcr_rt5651: ASoC: can't create compress Compress
>> bytcr_rt5651: ASoC: failed to instantiate card -22
>> bytcr_rt5651: devm_snd_soc_register_card failed -22
>> bytcr_rt5651: probe of bytcr_rt5651 failed with error -22
>>
>> So -- apparently it is successfully initializing 2 of the DAIs, but it
>> can't find the Compress-DAI. My first guess would just be to try and
>> disable the Compress DAI in the code just for debugging, but I'm sure
>> that there's a better way.
>>
>> I'm running a bleeding edge kernel build from the main linux git tree,
>> build from yesterday's github.com/torvalds/linux.git repo.
>>
>> Does anyone have any ideas on how to get alsa to detect the card properly?
>>
>> Here's the complete dmesg output:
>> https://gist.github.com/Manawyrm/70d90e95e9c578a7fb26
> 
> This is weird. I checked the DSDT tables and couldn't see anything blatantly wrong.
> If there was a problem with the compress DAI it would show on other platforms as well.
> It could also be a configuration issue with bad controls, I put my UCM configuration on github plbosssart/UCM/, you may want to look into this as well.

The same issues happens with an Asus t100 with 4.5-rc2, I get the same message of invalid direction so it's not a codec issue but a regression on all Atom platforms.
The code for this direction check was added by commit " ASoC: compress: Fix compress device direction check"  a1068045883ed4a18363a4ebad0c3d55e473b716pe by Vinod Koul (cc:ed), somehow the logic must be wrong or missing something.

Re: bytcr_rt5651 on wintron 7.0

[Vinod Koul]

On Mon, Feb 01, 2016 at 11:30:09AM -0600, Pierre-Louis Bossart wrote:
> On 02/01/2016 08:59 AM, Pierre-Louis Bossart wrote:
> >  
> > On 01/31/2016 07:51 AM, Tobias Mädel wrote:
> >> Hello,
> >>
> >> we're currently trying to get the new bytcr_rt5651 driver to run on a
> >> TrekStor SurfTab wintron 7.0 (x86 tablet).
> >>
> >> Unlike the previous driver for the rt5640 chipset, the new bytcr_rt5651
> >> driver actually detects the card out-of-the-box.
> > 
> > Good to know.
> > 
> >>
> >> This is the dmesg output on the device:
> >> bytcr_rt5651: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
> >> bytcr_rt5651: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
> >> bytcr_rt5651: Invalid direction for compress P 0, C 0
> >> bytcr_rt5651: ASoC: can't create compress Compress
> >> bytcr_rt5651: ASoC: failed to instantiate card -22
> >> bytcr_rt5651: devm_snd_soc_register_card failed -22
> >> bytcr_rt5651: probe of bytcr_rt5651 failed with error -22
> >>
> >> So -- apparently it is successfully initializing 2 of the DAIs, but it
> >> can't find the Compress-DAI. My first guess would just be to try and
> >> disable the Compress DAI in the code just for debugging, but I'm sure
> >> that there's a better way.
> >>
> >> I'm running a bleeding edge kernel build from the main linux git tree,
> >> build from yesterday's github.com/torvalds/linux.git repo.
> >>
> >> Does anyone have any ideas on how to get alsa to detect the card properly?
> >>
> >> Here's the complete dmesg output:
> >> https://gist.github.com/Manawyrm/70d90e95e9c578a7fb26
> > 
> > This is weird. I checked the DSDT tables and couldn't see anything blatantly wrong.
> > If there was a problem with the compress DAI it would show on other platforms as well.
> > It could also be a configuration issue with bad controls, I put my UCM configuration on github plbosssart/UCM/, you may want to look into this as well.
> 
> The same issues happens with an Asus t100 with 4.5-rc2, I get the same
> message of invalid direction so it's not a codec issue but a regression on
> all Atom platforms.  The code for this direction check was added by commit
> " ASoC: compress: Fix compress device direction check"
> a1068045883ed4a18363a4ebad0c3d55e473b716pe by Vinod Koul (cc:ed), somehow
> the logic must be wrong or missing something.

No the logic is perfectly right. What we are missing is the right DAI
initialization in the driver.

While debugging recently we found that compress core code was not doing
proper justice to figure out the direction, so we fixed it up based on PCM
approach which relies on dai setting channel_min properly. We seem to have
missed that bit in driver code, so this regression.

I see Pierre has already sent a patch for this, so this should be fixed now

Thanks
-- 
~Vinod

Re: bytcr_rt5651 on wintron 7.0

[Tobias Schramm]

Hi,

I'm tinkering on the wintron 7.0 together with Tobias Mädel and have
tested your patch with your UCM config on Linux 4.5.0-rc2. It looks like
we are getting somewhere. The soundcard is now being recognized by ALSA.
But there are still some errors in  that seem to be related to the audio
driver.
As soon as I try to output any sound I get an error:
[   88.906739] intel_sst_acpi 80860F28:00: fw download failed -16
[   88.909262] intel_sst_acpi 80860F28:00: FW download fail -16
[   88.948434]  Audio Port: ASoC: no backend DAIs enabled for Audio Port

Does anybody have an idea why the sound chip is not responding and the
fw download timeouts?

I've uploaded dmesg, lsmod and tree /proc/asound output here:
https://github.com/TobleMiner/wintron7.0/tree/master/logs/4.5.0-rc2-ARCH-tsys-audio-intel-dirty

Regards,
Tobias Mädel and Tobias Schramm
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: bytcr_rt5651 on wintron 7.0

[Pierre-Louis Bossart]

On 2/3/16 5:17 AM, Tobias Schramm wrote:
> Hi,
>
> I'm tinkering on the wintron 7.0 together with Tobias Mädel and have
> tested your patch with your UCM config on Linux 4.5.0-rc2. It looks like
> we are getting somewhere. The soundcard is now being recognized by ALSA.
> But there are still some errors in  that seem to be related to the audio
> driver.
> As soon as I try to output any sound I get an error:
> [   88.906739] intel_sst_acpi 80860F28:00: fw download failed -16
> [   88.909262] intel_sst_acpi 80860F28:00: FW download fail -16
> [   88.948434]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
>
> Does anybody have an idea why the sound chip is not responding and the
> fw download timeouts?
>
> I've uploaded dmesg, lsmod and tree /proc/asound output here:
> https://github.com/TobleMiner/wintron7.0/tree/master/logs/4.5.0-rc2-ARCH-tsys-audio-intel-dirty

It's very likely that you have a BYT-CR device where the BIOS folks 
modified the order of interrupts which causes the IPC/download issue. If 
this was correct you would also need to use the SSP0 interface since 
SSP2 isn't available on the BYT-CR package. I have a set of patches for 
BYT-CR that are still being worked on, i will try to share what I have 
shortly and could use some help to double-check them before sending them 
to Mark, I only have one BYT-CR device (ASUS T100TAF) which is not fully 
working.


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