AnsweredAssumed Answered

Linux 4.1.6 [using devicetree] - ESAI configuration problem [i.MX6S based custom board]

Question asked by jbd64 on Oct 5, 2015

Hi,

 

We have developed a custom board based on i.MX6 Solo processor, integrating an ADAU1461 CODEC.

We decided to use linux kernel 4.1.6 because ADAU1461 CODEC support comes with it (sound/soc/adau1761* and sound/soc/adau17x1.*).

ADAU1461 CODEC is connected with i.MX6S using i2c for configuration / control and ESAI for the audio data.

As ADAU1461 is not fully supported by Freescale (no machine driver), we created one in sound/soc/fsl directory (file imx-adau1761.c in attachment) inspired by sound/soc/blackfin/bfin-eval-adau1x61.c

In linux, board startup configuration is done using device tree (file imx6s_spu_board.dtsi in attachment).

ADAU1461 CODEC I2C driver is correctly registered and communication with i.MX6Solo by I2C is OK.

ALSA device is also correctly registered as you can see in the linux startup log (call_sequence_audio.txt in attachment).

Hardware connections between i.MX6 ESAI and ADAU1461 are OK.

 

i.MX6 ESAI is used as Master, so the processor has to generate MCLK clock, using PLL3 Main, PLL3 PFD2, PLL3 PFD3 or PLL4.

Currently, MCLK is our main problem : using alsa tool "aplay" with any audio file, MCLK is not generated.

With an audio file in 44100Hz, aplay terminates with an error : aplay: pcm_write:1737: write error: Input/output error

Not surprising because no MCLK is generated...

 

As you can see in the device tree code, ESAI fsys clock is configured using PPL3 PFD2 508M clock, and AUDAU1461 CODEC using ESAI PODF (post divisor clock).

First, can you tell us if clock configuration code is already done in linux kernel 4.1.6 in freescale support code, or it needs to be done in a specific alsa component (machine driver, or codec driver...) or in device tree code ? But I don't find any example...

 

Using devmem in linux, we noted that esai iomux configuration is not done by linux kernel, so we are currently doing it in u-boot startup code.

Are we doing something wrong ? Or is ESAI iomux configuration not supported in linux 4.1.6 version ?

 

We also want to note that we faced problems configuring I2C, resolved using a weird configuration of SW_PAD_CTL_PAD mux register.

Initially, I2C 3 did not work using this code in device tree :

    pinctrl_i2c3: i2c3grp {
        fsl,pins = <
            MX6QDL_PAD_GPIO_5__I2C3_SCL   0x1b0b0
            MX6QDL_PAD_GPIO_6__I2C3_SDA   0x1b0b0
        >;
    };

 

So with this code, I2C 3 was not able to generated SCL clock...

After a lot of manipulations and by despair, we tried to add the 0x4000000 bit (inspired by imx6qdl-sabresd.dtsi) in SCL and SDA register value, and it works with it :

 

    pinctrl_i2c3: i2c3grp {
        fsl,pins = <
            MX6QDL_PAD_GPIO_5__I2C3_SCL   0x4001b8b1
            MX6QDL_PAD_GPIO_6__I2C3_SDA   0x4001b8b1
        >;
    };

As far as I understand, 0x4001b8b1 is written in IOMUXC_SW_PAD_CTL_PAD_GPIO05 for SCL and IOMUXC_SW_PAD_CTL_PAD_GPIO01 for SDA, but the 0x40000000 bit corresponds to a Read-only field... What's the point ? Does the linux code configure something else with this bit ?

 

After facing this issue, we are wondering if there is the same problem with the ESAI iomux configuration, so it cannot generate the clock ?

As I already mentioned, iomux ESAI configuration is not done by linux kernel with our device tree code, so we cannot modify SW_PAD_CTL_PAD values...

We tried it by u-boot code, but it does not solve the issue...

 

We are currently stuck with this problem, since a week.

Any idea ?

 

Thanks a lot,

Original Attachment has been moved to: imx-adau1761.c.zip

Original Attachment has been moved to: call_sequence_audio.txt.zip

Original Attachment has been moved to: imx6s_spu_board.dtsi.zip

Outcomes