TAC5212: Linux Driver for 6.6 kernel

Hello,

You should use the ti.com download or git.ti.com driver. About the kernel I can have our driver developer comment.

Best,

Garret

Thanks, P.S : FWIW is a bug in the master branch for I2S. No no audio on right channel can be fixed by:

1. 0x1F is set to 0x01, must be 0x10 (for TX , ADC, CH2)
2. 0x29 is set to 0x21, must be 0x30 (for RX, DAC, CH2)

At 8Khz ok, but still get an speaker-test Input/Output error after about a second at other data rates. (the IMX93 seems to only support 8/16/48/96) ,after that error, 8K also gives I/O error. Need to reboot to get it back to work at 8K

root@imx93frdm:~/test/emmc/audio# speaker-test -c 2 -D hw:0,0,0 -r 48000 -f 440 -t sine
speaker-test 1.2.11
Playback device is hw:0,0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 131072
Period size range from 16 to 8184
Periods = 4
was set period_size = 8184
was set buffer_size = 32736
 0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error

1] Sorry for the confusion. The only repo which is being actively maintained by TI is 

     https://git.ti.com/cgit/lpaa-android-drivers/tac5x1x-linux-driver/

• tac5x1x_driver - for 6.x and 7.x versions
• tac5x1x_driver_5.10 - for kernel version 5.10 
• tac5x1x_driver_5.15 - for kernel version 5.15

    dev branch are customer specific branches and are old.

    master and 4.14 I think are older ones. I will work internally to 

2] Regarding the IO error, it will be DMA related issue and not related to codec driver. 

with 6.6.36 and the tac5x1x-driver branch the following errors occur

sound/soc/codecs/tac5x1x-i2c.c:518:15: error: implicit declaration of function ‘regmap_multi_reg_read’; did you mean ‘regmap_multi_reg_write’? [-Werror=implicit-function-declaration]
  518 |         ret = regmap_multi_reg_read(tac5x1x->regmap,
      |               ^~~~~~~~~~~~~~~~~~~~~
      |               regmap_multi_reg_write
sound/soc/codecs/tac5x1x-i2c.c: In function ‘tac5x1x_add_widgets’:
sound/soc/codecs/tac5x1x-i2c.c:2167:17: error: implicit declaration of function ‘snd_soc_component_to_dapm’; did you mean ‘snd_soc_component_get_dapm’? [-Werror=implicit-function-declaration]
 2167 |                 snd_soc_component_to_dapm(component);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                 snd_soc_component_get_dapm

Sorry for the trouble, I will fix these issues in a new 6.6 branch and updated the repo.

This is pretty much the biggest nightmare with linux drivers. When patches are released for newer kernal that replace older code, for CVE, but the platform suppliers and Yocto code is far behind in backporting, so the compile  on updated driver occur. 

I can't find the older code to patch the snd_soc_component_to_dapm’ that seems to fix a  CVE for the rt1011 driver

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=30e4b2290cc2a8d1b9ddb9dcb9c981df1f2a7399

For the other issue this I found for the 5.10 driver

        #if LINUX_VERSION_CODE < KERNEL_VERSION(6, 11, 0)        
	ret = regmap_multi_reg_read(tac5x1x->regmap,
				    tac5x1x->irqinfo.latch_regs,
				    tac5x1x->irqinfo.latch_data, latch_count);
        #else
       	ret = tac5x1x_read_latch_registers(tac5x1x);
        #endif

1072.tac5x1x-i2c.c

Attache the driver with hacks. Not sure they are correct. Added comments in the code. Reasons are:

The driver loads at works but still at 8Khz sampling rate only, not unexpectedly , the same I/O error occurs 

[1] snd_soc_component_to_dapm introduced in kernel 6.17 due to CVE 

Commit Date: September 18, 2025 (merged during the v6.17 cycle
Author: Kuninori Morimoto
File Location: Defined inside include/sound/soc-component.h.
Workaround: Gues to use "get" instead of "to" call (I could not find the older code)

nvd.nist.gov/.../CVE-2026-43478  

[2] The regmap_multi_reg_read() function was officially introduced to the mainline Linux Kernel in July 2024 as part of the Linux v6.11 development cycle.

Workaround: apply the code from 5.10 kernel, bit there is a u16 to u8 conversion that may not be correct.

https://lkml.iu.edu/hypermail/linux/kernel/2407.1/03035.html

I wonder if it may be useful that when updating a kernel to keep the older code in comments or with with a f KERNEL_VERSION (even using comments), so that BSP that not have been back-ported and fail compilation can still use the older code. ? The ALSA code stack of  seem to break so very often.  Thank you for adding a 6.6 Kernel branch, the current errors were related to 6.17 and 6.11 changes, Perhaps for v6 is is easier to maintain a #IF KERNEL_VERSION  statement ? For example  for v5.10 and 5.15 use a v5 driver with #IF KERNEL_VERSION switches and for v6,and  stable v7 the same. So that there is just one file for each kernel generation, while master is based on the latest Linus unstable release ?

Thanks for the suggestion. If we have a new case like that, I think I will use this approach to avoid multiple branches.