On Wed, 2015-05-27 at 22:13 +0200, Michele Curti wrote:
On Wed, May 27, 2015 at 07:41:56PM +0100, Liam Girdwood wrote:
And dmesg tells me: [ +1.386847] rt5645 i2c-10EC5648:00: Failed to reguest IRQ: -22 [ +0.000102] rt5645 i2c-10EC5648:00: Fail gpio_request hp_det_gpio [ +0.000094] rt5645 i2c-10EC5648:00: Fail gpio_direction hp_det_gpio
Looks like the codec has no platform data and is failing to get a valid IRQ number. Do you know what IRQ the code is actually requesting as it could be bogus ?
The IRQ was indeed -1, using the latest linux-next the IRQ is now 146, so I'll keep using linux-next for my tests. The gpio requested is 0.
GPIO is 0 because there is no platform data coming form the codec ACPI data. This may have to be defined as a quirk in the codec driver. Bard any suggestion here for the HP detect GPIOs ?
Ok, lets get the dev_dbg() output enabled for sst-baytrail*.c and we can take it from there.
Sure, these new lines appeared:
[ 1.515886] baytrail-pcm-audio baytrail-pcm-audio: initialising Byt DSP IPC [ 1.519619] baytrail-pcm-audio baytrail-pcm-audio: header sign=$SST\xffffffb4^M^D size=0x40db4 modules=0x1 fmt=0x100 size=32
That means FW file format is good.
[ 2.000642] byt-rt5645 byt-rt5645: ASoC: CPU DAI baytrail-pcm-audio not registered
We are seeing a lot of these. Can you confirm whether this driver has probed ? If not can you see it's ACPI ID listed under /sys/bus/acpi/devices.
If it's not probing, it may also have a different ACPI ID compared to the reference driver. You may have to add an entry to sst-acpi.c i.e.
static struct sst_acpi_mach baytrail_machines[] = { { "10EC5640", "byt-rt5640", "intel/fw_sst_0f28.bin-48kHz_i2s_master" }, { "193C9890", "byt-max98090", "intel/fw_sst_0f28.bin-48kHz_i2s_master" }, {} };
Liam