TLV320AIC3104: Wrong reg read by using I2C

Hi Byunghee,

I'm curious about your mention of the I2C access "overlapping." Can you tell me or show me what that means? The two devices have different addresses correct?

You also mention that this only happens sometimes. Is there any pattern to what causes the issue to appear such as a certain write in the FM8802 burst that triggers the issue? Does the issue happen if the FM8802 burst is skipped and just the AIC3104 burst is written?

Thanks,
Jeff McPherson

Dear Jeff McPherson

Thanks for the reply.

I'm checking the issue more to have more data and what the issue is.

I'll have another info for this.

The reason to read wrongly  is related to another i2c device on the same I2c port of host device. 

Overlapping is 

- We write fm8802 bust with 712bytes. 

- And then we start reading and writing AIC3104 I2c around at the end of fm8802 bust write. 

 In detailed view, I can see AIC3104 access between 2 or 3 bytes unit i2c with different i2c address(fm8802, ktd2027).

The addr is 0x60(8bit address) . However, It's my fault. It is a different I2c device, led driver, ktd2027.

That device address is 0x30, 7bit address.

We only write LED driver, ktd2027 by using i2c. We don't read that device due to led driver.

I know even thought we don't read ktd2027, if the read condition hits the device, the device will output 8bit data.

So I have checked below.

- whether the SCL/SDA clock/slope are degraded by a resistor, capacitance by using OSC - scope, but I think it's normal level.

- I blocked the SCL/SDA line of ktd2027 not to read ktd2027. The result shows regmap_read(..) returns -6("No such device or address") and show read failure. The data value show the initial value of variable that I declare.

So seemingly, it seems that the regmap_read(...) for AIC3104 reads ktd2027.

AIC3104 7bit address is 0x18, ktd2027 7bit address is 0x30 . It's one bit difference. 

However, I haven't found any hardwired issue or other software issue. 

One thing is 

ktd2027 is using "i2c_smbus_write_byte_data(...)" function for I2C access.

AIC3104 is using "regmap_read(...).

Is there any issue for those i2c driver difference?

And "sometimes" that I mentioned is that I can't reproduce any time.

It's about 2%, I tried to test. 1031 times, the issue showed 24 time with wrong read.

Before I access AIC3104 i2c, I tried to apply some delay(5ms) or one more read I2C. Then the issue is disappeared.

When read that with two times, I can see wrong read value with the same probability.

Can you advise me about this ?

Many thanks

Byunghee Sohn

Hi Byunghee,

Thank you for the details. I agree the issue is likely with the addressing of the devices. The LED driver and codec are not just one bit different, but shifted of each other (0x18 = 001 1000; 0x30 = 011 0000;). This makes me think that somewhere there is an offset that is misfiring the KTD2027. The KTD2027 is not a TI device so it's difficult to narrow down why this is happening since your scope shot looks nearly identical between both read commands. The only thing I can think of is you might be violating the timing specs of the KTD2027.

Otherwise my recommendation is to either

1) Add the delay (or read twice and discard the first return value) which you saw works if that is acceptable to your system requirements.

2) Remove the shifted relationship between the I2C addresses. Looking at the KTD2027 data sheet you can buy the KTD2027B which is identical except it has an I2C address of 0x31. This may interrupt whatever behavior is causing the problem by introducing a bit difference that doesn't appear like a shift.

3) If another I2C port/bus is available you can separate the two devices that way by using different SDA/SCL lines.

4) Not as ideal since it requires another part, but you could use a digital logic buffer with an enable driven by the host GPIO to break the I2C bus to the KTD2027 when it's writes are completed, leaving the codec to read correctly since the LED driver can't interfere. This part could do that: https://www.ti.com/product/SN74AHC1G126-Q1

Best regards,
Jeff McPherson

Hi Jeff 

Thank you for your recommendation.

However, we have an limitation to currently change hardware.

And current job is that I change the SW for new design of our product that we already is selling.

We need to change a few devices from that. One of those devices is TLV320aic3104.

So new SW must be compatible with old products that existing customers are using.

So change the hardware is not easy. And our plan is almost final step.

By the way, 

I found new issue about i2c access between ktd2027(led driver) and aic3104.

You can see two screes below.

The issue is coincident with the condition case.

When ktd2027 accesses the I2C, there is no stop I2C. SDA line is still low.

At this time, AIC3104 start accessing I2C to read the reg of AIC3104.

However, ktd2027 is seizing i2c due to no stop condition.

At first, I was wondering why aic3104 can't recognize I2C read from the host.

Now from this, I can understand the reason why aic3104 can't recognize i2c.

Is there any idea about this ?

I have contacted kdt2027 vendor. But I couldn't have useful information about this.

As I mentioned before, I think that it's related to i2c driver difference to handle two devices.

- ktd2027 : i2c_smbus_write_byte_data(..). --> written in the past

- AIC3104 : regmap_read(..)

I doubt if there is a difference to make a bus lock between two drivers. 

Can you advise about this 

Many thanks

Byunghee Sohn

Hi Byunghee,

Understood that a SW fix is required. Adding the delay or adding a dummy read to get the KTD2027 to let go of the I2C bus still works here right?

I'm not an expert on the i2c driver. Can you confirm for me that both I2C functions (regmap_read and i2c_smbus_write_byte_data) are both defined in the AIC3104 driver (https://www.ti.com/tool/TLV320AIC31XX-DRIVERS). If so I can loop in our software experts to clarify if there's a clash between the two functions. However I think you found the root cause with the stop condition not occurring before the codec needs the I2C lines.

Best regards,
Jeff McPherson

Hi Jeff

I have another symptoms for this .

First of all, until now, I need to clarify below.

1. ktd2027 led driver(0x30 dev addr) is connected to the same port with tlv320aic3104

2. osc scope shows the issue is to collide with ktd2027.

3. when I disconnected ktd2027, the read command returns -6(No device ~) instead of wrong read(0x7F).

--> So I thought there is an i2c arbitration issue or collision between ktd2027 and aic3104.

Today, I checked more and tested below

A. I disconnected the SCL/SDA of ktd2027

B. I removed ktd2027 in linux DTS file and add return code in the ktd2027_probe(..) to remove the influence of host cpu;

C. I have tested the different value when reading two times for the same register 

The result shows 

The issue still have regardless of ktd2027.

When reading wrongly, regmap_read() returns 0(normal). However the value is wrong , 0xF8@0x58. It must be 0x04@0x58.

And I can two acks pulse that seems wrong. On the issued i2c port, there is no same i2c address with aic3104.

You can see the osc scope that I attached.

And I also added scope raw data. 

Lastly, my ti driver source is added. Is there any additional config?

Please advise me about this issue.

Seemingly it looks about only TI device .

I need to resolve this as soon as possible .

So far we haven't had the same issue for the product.

Old device is wm8978 using regmap_read() instead of aic3104. Old one has no issue.

Many thanks 

Byunghee Sohn

Hi Jeff

I have the update for you.

After two acks, reg addr is not 0x58. So I think that one ack of two acks is not ack. 

Maybe its short on sda line? please advise me about this .

Many thanks

BH

Last Friday, there is one that I missed.

In addition 

We are using the following devices on current issued port.

-. tlv320aic3104(ti) - 0x18 addr

- tusb4041(ti) - 0x47

- tca9534(ti) - 0x27

- fm8802 - 0xc0

- ktd2027 - 0x30

Best regards

Byunghee Sohn

Hi Byunghee,

Thanks for being patient while we had a holiday in the U.S. I doubt that the I2C controller is seeing two ACKs. Whatever is causing that premature pulse is probably affecting the address the device sees by the read command and thus giving a bad value. Since removing the KTD2027 didn't fully solve the issue, have you tried removing all devices from the problem I2C port? This will help narrow down if the issue is interference on the I2C line or something internal to the AIC3104 itself. If it disappears then you can add the devices one by one until it reappears. 

The 2% reproducibility is tricky. Have you noticed any pattern into what causes it? Such as reading x amount of times within a certain time window?

Thanks,
Jeff McPherson 

Hi Jeff

Thanks for the reply.

I'm testing the issue after removing other devices except for tiv320aic3104. 

After completing that, I'll let you know soon.

By the way, I'm sending new analysis. You can see two sheets(*.pdf) from the attached.

1st sheet is the doc that I sent before. the reg byte with two acks is 0x18. Actually the reg addr that I intended to read is 0x58.

For the issue, tlv320aic3104 outputs the value of 0x18. All reg values matchs with the value of0x18 reg.

In this case, I have tested with ktd2027, led driver unloaded. (or disconnected the scl/sda of ktd2027) .

Seemingly, tlv320aic3104 wrongly outputs. Or the device mis-recognizes the reg address for some reason.

You can see the case #1 sheet (2nd sheet) . The sheet shows the details.

Lastly, our product is the ipphone based on Android. (using Linux).

the issue happens when I do off-hook on the speaker phone. It means that I just press the speaker button by toggle, on/off)

Then the phone is running between off-hook (speaker phone mode) and on-hook (idle).

At this time, tlv320aic3104 provides headset audio path, handset path and speaker mode path.

Each path has the tlv320aic3104 register set and idle state set. 

I have attached two sets(idle mode, speaker phone mode). Other register sets are different values , but the same structure.

tlv320aic3104 driver can't know which one is speaker phone mode. The driver just part the register set. And write reg value.

So far, the issue happens only when going to from idle to speaker phone mode. Actually in the view point of lv320aic3104 driver,

there is no difference between speaker register set to  others.

And until now, 1st register, 0x58 only has the issue. So I tested that after changing the register set order.

The result show only 1st register has the issue. It doesn't depend on 0x58 reg.

I'll update my testing.

Many thanks 

Byunghee Sohn

Seemingly it may be related to previous i2c access. 

Hi Jeff

Thanks for the reply, 

Can TI support something about the codec drivers ? Because you have a different export for the codec driver?

I'm checking the issue after removing others. After that, I'll update soon.

By the way, I clicked "This resolved my issue" by my mistake. Can you restore that?

And I have uploaded many attached files. For the security, at least I do want to delete the attached files. 

But I can't do that. How can I delete the attached files. I think that you already reviewed them. 

So Now they are not available. 

Many thanks 

BH

In addition, we were using the different codec before we are using tlv320~. 

That codec has also i2c interface by using regmap_read()/regmao_write() driver.

However there is no issue. There is no difference between I2c interfaces on that port.

We just use tlv320~ instead of other codec.

BH

Hi Jeff

Can you forward or share this ticket to our expert for i2c Linux driver?

And,  Regarding removing other devices except for tlv320aic3104,

So far, according to my testing, fm8802 is dominant role for this issue.

If I connects fm8802, the issue happens regardless of other device connections(scl/sda).

Instead, I disconnects fm8802(scl/sda), the issue is not reproduced regardless of other devices.

In this point, there are two issues for fm8802.

    1. i2c access itself

    2. time room by i2c burst write(712 bytes). no delay for tlv320~ i2c access. 

I can't determine what the main issue from two issues is .

And from this, ktd2027 indirectly affects to tlv320~ i2c.

I found a new surprising situation.

As I said before, the issue happens when changing from audio path for idle state to speaker mode path.

At this time, the first reg(0x58) of the speaker mode register set has the problem.

In the beginning of this issue occurrence,  I tested the issue after changing the 1st reg(0x58) to other reg addr of the speaker mode register set.

However, the issue was the same. 

The 0x18 reg in the previous testing data is changed from 0x58.  I thought the 0x18 reg address is the same with the device address(0x18) of tlv320~ 

And then, another situation is always our led driver(ktd2017) tries to write some data to the same i2c port.

From this sinuation,

(1) I changed the reg order of the speaker mode set. So 1st reg is 0x11, not 0x58.

(2) I remove the i2c write of led driver (ktd2027) .

In this test, I have found two thigs.

1) the issue was not reproduced . I test more than 1000 times. I couldn't see  the issue.

      --> when 0x58 is 1st reg, seemingly the driver conflicts with tlv320aic~ 0x18 device addr. Is it pssible?

2). Even if I changed the register set order, if I add ktd2027 i2c write again, the issue happened.

       --> regmap_read() conflicts with ktd2027 access, value is 0x7F, not the value of 0x11. 

Is there any idea for this ?

Many thanks

BH

----------------------- speaker mode register set -------------

const struct config_control tlv320aic3x_speaker_voip_controls[] = {
{
      .ctl_name = "Left Audio HF Switch", //0x58
      .int_val = {on},
},
{
       .ctl_name = "AuxL Left ADC Switch Volume", // 0x11
       .int_val = {0xf},
},
{ ....}

...

Hi Byunghee,

I deleted your previous attachments and will reassign this ticket to our driver expert to follow up. 

Thank you,
Jeff McPherson

Tell me which driver code you has used for tlv320~ and for TLV320AIC3104?

For other i2c device drivers, which i2c interface they use? is it regmap_read/regmap_write, either?

Dear Shenghao Ding

The tlv320~ that I mention is all tlv320aic3104, which is one of our devices assembled on out product.

I'm using regmap_read() and regmap_write() for tlv320aic3104.

But as I mentioned on this ticket, there are 5 i2c device on one i2c port of the host cpu.

Please review this ticket from the first questions. 

And I attached my docs including tlv320aic3104 driver code of Linux open source . I modified that driver for our purpose.

However most parts are the same with original driver code. You can have them from Jeff if he didn't delete until now.

So far, I can arrange as follows.

1. if I remove fm8802 burst write (712bytes) , there is no issue.

2. In the fm8802 burst write active state, tlv320aic3104 seemingly conflicts with ktd2027 (0x30 device addr) on the i2c.

     2-1)  when activating ktd2027, tlv320aic3104 has i2c read error by remap_read().

             I have  attached my testing data again - "i2c_conflict_w_ktd2027.zip"i2c_conflict_w_ktd2027.zip

     2-2) after blocking ktd2027, when reading 0x58 reg from tlv320aic3104, for some reason, the read value is the value from 0x18 reg.

            In this point, 0x58 is one bit difference from 0x18 tlv320aic3104 device address. (it's reproduced only 100~200 times test).

           So after changing the reg address instead of 0x58 into 0x11, the read value is normal. (no error from 1000 times test)

            -->  relevant testing data is "i2c_conflict_tlv320aic3104_itself.zip

In conclusion, I think that there is an issue from regmap_~() api to host cpu i2c block .

Can you advise me about this issue?

And if you need to check or others, please let me know

Many thanks

BH

i2c_conflict_w_ktd2027.zipi2c_conflict_tlv320aic3104_itself.zip

I have following questions to you:

1) the max bytes per burst write in your platform?

2) tlv320aic3104 driver use snd_soc_component_write/snd_soc_component_write/snd_soc_component_update_bit, have replace them with regmap_xxx?

Hi Shenghao

1. The burst write that I mentioned is to access FM8802 before tlv320aic3104. It's 712 bytes per one time.

    In case of tlv320aic3104 , we read/write tlv320aic3104 i2c by one byte . Therefore, it's 3byte i2c access  (device addr + reg addr + data ) for write.

         Read i2c access is 4 bytes (device addr + reg addr , device addr + read data )

2. Our product don't need to use snd_soc_component~ . So we just use regmap_read()/regmap_write().

       Is there any problem about regmap_read()and regmap_write() for tlv320aic3104?

I think that they are using the same core i2c driver.

Many thanks

BH

Hi, 

Byunghee Sohn said:

     2-2) after blocking ktd2027, when reading 0x58 reg from tlv320aic3104, for some reason, the read value is the value from 0x18 reg.

            In this point, 0x58 is one bit difference from 0x18 tlv320aic3104 device address. (it's reproduced only 100~200 times test).

           So after changing the reg address instead of 0x58 into 0x11, the read value is normal. (no error from 1000 times test)

            -->  relevant testing data is "i2c_conflict_tlv320aic3104_itself.zip

I wonder whether the 0x58 reg is 7-bit i2c address.

Kindly use i2cdetect to check how many i2c device can be detect?

One more thing, do you have i2c analyzer to capture all the i2c communication?

It seemed a hardware conflict issue.

Hi,

There is no i2c device with 0x58 device address on the i2c port with the issue .

Seemingly, 0x30 with 1 bit difference is ktd2027 and the issue seems like address conflict with ktd2027.

And I already mentioned the i2c devices on this ticket as follows. 5 devices

-. tlv320aic3104(ti) - 0x18 addr

- tusb4041(ti) - 0x47

- tca9534(ti) - 0x27

- fm8802 - 0xc0, read command 0x60

- ktd2027 - 0x30

I think you didn't review this ticket. Jeff already mentioned tlv320aic3104 device correctly works . 

And I also think that the issue is related to the i2c driver. 

I already checked the i2c scl/sda hw pulse, which shows normal level.

And we don't have i2c analyzer. 

Many thanks

BH

So, you means i2cset -f -y 1 0x18 xxx xxxx, will set both register of ktd2027 and aic3104, am Iright?

Thanks for the quick reply

As I mentioned before, when ktd2027 access i2c , tlv320aic3104 also access i2c at the same time.

At first, basically I can't understand this, because they are using the same i2c port. So I think that i2c has the locking system to seize the i2c.

2ndly, you can see below that I already uploaded on this ticket.

When ktd2027 doesn't release the i2c, at that time, tlv320aic3104 starts accessing i2c (read). 

tlv320aic3104 reads wrong value (0x7f) . It's another issue

3rd issue,

So I blocked ktd2027 temporarily. In that case, tlv320aic3104 reads the value of 0x18 reg address instead of 0x58 register.

It's one bit difference . seemingly 0x58 reg address is one bit difference from 0x18 device address.

Of course, this test shows the 0x18 is the register address. 

4th, I changed the reg address 0x58 into 0x11 (many difference from 0x18 device address)

Then the result shows normal value ( the value of 0x11 reg )

When I check 3rd issue result, tlv320aic~ device address(0x18) has one bit difference problem. 

Many thanks

BH

In addition to 2nd issue, at that time , if I remove ktd2027 on the board, the regmap_read() for tlv320aic~ reg read (0x59) returns -6(no device) .

It's not always. around 2 %.

Can you confirm the hardware is fine, such as power supply? When this issue occured, can you i2cdump tlv320aic?

Until now, I can't find any hw issue . You can see the scl/sda pulse on the osc~scope. The slope of the pulse is normal level.

What does the power supply that you mentioned mean? The voltage level or circuit diagram?

And as I mentioned before, the issue happen with around 2%. How can I hit, execute "i2cdump" on the shell screen when it happen ?

Many thanks

BH

Until now, I wrote the code with reading two times for the same register of tlv320aic . Then when the read two values are different , I controlled GPIO .

So that I can see the scl/sda by using scope trigger function. But I think that executing "i2cdump" is difficult when the issue occurs.

Can you advise me about this?

Many thanks

BH

in the tlv320aic driver code, add

static bool aic31xx_volatile(struct device *dev, unsigned int reg) { return true; }

remove aic31xx_writeable callback.

Thanks for the quick reply

I'm sorry but I can't understand your guide.

Can you explain how that code works ? How does that code make i2cdump?

BH

set all the register as volatile, so that system will keep the regmap cache and registers inside at the same pace,

Thanks for the quick reply.

I disabled all cache for tlv320aic~. Because of real time hw update necessity.

I can see three parts related to cache.

1. static bool aic3x_volatile_reg(struct device *dev, unsigned int reg) --> default false return.

2. static const struct regmap_config aic3x_regmap = {

        ...

       .cache_type = REGCACHE_NONE, }

3. static int aic3x_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) {

      ...

      regcache_cache_only(aic3x->regmap, false); }

Do Those 3 parts configure true, REGCACHE_RBTREE , true?

Actually, I checked all must be false, REGCACHE_NONE . So that tlv320~ can really read/write.

Many thanks

BH

Glad to hear you fixed your issue. Enjoy Linux development.

This issue is not resolved. Please keep this ticket open state

As I said before, it occurs with around 2%.

So I can test the issue by triggering gpio when it happen below

    ret0 = regmap_read(map, reg, &orig0);
    ret = regmap_read(map, reg, &orig);

I read the reg value with two times. If it normally works, two read values must be same.

However, I can see wrong read value with 2%.

Even if I check "i2cdump" when it happens, the dump data will be update by 2nd time read.

Or like the system call in the user space, I have to execute "i2cdump -f -y 1 0x18" in the kernel driver when it happen.

Is there any easy way to check i2cdump?

Many thanks

BH

When you first-time read or write the register, is the return value abnormal?

I have  two issues for this.

1st is to conflict with ktd2027 led driver (0x30 id). As I said before, when host cpu writes to ktd2027, the read access for the reg (0x058) of tlv320~  inserts like below screen cap.

At this time, if I remove ktd2027(disconnecting physically the scl/sda of ktd2027), the read access for tlv320~ register(0x58) returns -6 (no device ~) .

Apparently, host cpu continue to access ktd2027. 

22nd issue, if i unload ktd2027(by removing ktd2027 in dtsi file), host cpu reads wrongly 0x18 register instead of 0x58 which I intend to read first from tlv320~.

Apparently, host cpu doesn't access ktd2027. When host cpu returns 0(zero) normally.

So, Jeff and me think it's related to host i2c driver issue. That's why Jeff assigned you for this.

Did you catch my issues?

Did you review the issue of this ticket?

BH

For the 1st issue, you can try to remove the code related to ktd2027. As you describe that host cpu continue to access ktd2027, it seemed the ktd2027 code still in the image.

Since this is the hardware conflict, I'm not sure what the software guy can do for you.

For the 2nd issue, are you set the regcache to none? How many tlv320~ do you have? Can try on other tlv320~?

BR

Shenghao Ding

In the 1st issue, yes correct. Even if removing the SCL/SDA interface of ktd2027, sw image is accessing. But it's failed.

However, I can't believe that it's the hardware conflict. Thing is that host cpu start reading 0x58 tlv320aic3104 register while ktd2027 is seizing the i2c line.

If it's normal, because ktd2027 and tlv320aic3104 have different device address, host cpu should not read the reg of tlv320aic3104. 

I2C driver needs to arbitrate i2c bus occupation. The hardware can only affect the slope of the scl/sda pulse or minimum timing margin. They are normal.

Most serial interfaces like SPI, I2C, UART, etc are implemented by software.

The 2nd, I just omitted the full text . tlv320aic3104 is too long word to type. On current i2c port, there is one tlv320aic3104. 

And regarding "regcache"

My setting is ".cache_type = REGCACHE_NONE, " . And I have tested ".cache_type = REGCACHE_RBTREE, " by your saying.

As far as I know, that cache setting is related to reading the reg. The probability that the issue occurs is reduced. 

 And another cache setting is "regcache_cache_only(aic3x->regmap, false);" 

I know that this is related to writing the reg. So it's not the current issue. 

BH

I wonder why host cpu start reading 0x58 register of tlv320~ when host cpu is accessing ktd2027 on the same i2c port.

In addition, If I read 0x11 register of tlv320~ instead of 0x58, the issue is disappear. I think that 0x58 is one bit difference from 0x18 device address of tlv320.

I think that It's drive issue. So Jeff assigned you who are driver expert.

BH

Hi guy,

It's a system issue. Since you have not found any clue in our driver. I have no idea of this.

What is "our driver"? Is it possible for tlv320aic~ i2c driver to access i2c while host cpu is seizing the same i2c?

BH 

Let me ask our codec expert to support, maybe he can offer a different way to help you.

Thank you for the support.

I'll wait for him.

BH

Hi BH,

I spoke briefly with Shenghao and we agree that the issue is stemming from your CPU integration, specifically because your CPU is still trying to access KTD2027 when it's been supposedly removed from the code. You may also need to inquire with the vendor of the KTD2027 since that's the part that we think is stuck holding SDA low. We're not seeing that the issue comes from the TI device specifically.

If you still have questions regarding the TLV320AIC3104 I2C driver specifically, please clarify them. I think they may have gotten lost since the conversation has taken a few different turns.

Thanks,
Jeff McPherson

Hi Jeff

Thanks for the reply

The issue that you mentioned is below 

In this issue, there may a problem of KTD2027. However, on the other side, the regmap_read(0x58) in tlv320aic3104 driver inserted while accessing ktd2027.

By the way, below issue is tlv320aic3104 itself.

As I said before, scl/sda disconnected and doesn't load ktd2027 driver (remove dtsi file) and blocks initializing ktd2027. --> double checked

If I read 0x58 register in tlv320aic3104, the result is the value of 0x18 register . I double checked this issue after writing a few values to 0x18 register.

0x58 reg is one bit difference from 0x18(tlv320aic3104 device address). So I have tested this after changing other reg instead of 0x58.

Register is not one bit difference like 0x11. Then the problem is disappeared.

So in conclusion, I think there is a issue on tlv320aic3104 driver.

Many thank

BH

pls share the dts setting for tlv320aic3104.

In "static int aic3x_i2c_probe(struct i2c_client *i2c)" in  tlv320aic3x-i2c.c, pls print i2c->addr, I wonder what the value is, 0x58 or 0x18.

Hi Shenghao

To begin with, I'm attaching the dtsi setting for tlv320aic3104 below. 

And I'm using tlv320aic3x.c after modifying it. Tomorrow I'll let you know the value of i2c->addr. Today I'm working from home.

Many thanks

BH

Any update?

I apologize for being late .

Yesterday I was off day due to my private issue.

Today as soon as possible, I'll update

BH