The autotest is good - https://wmatrix.googleplex.com/unfiltered?platforms=lars,kevin,auron_paine&suites=chameleon_audio_perbuild&days_back=7&releases=63&hide_missing=True&tests=audio_AudioBasicHeadphone&builds=R63-10032.17.0

Sontis will diagnoze further.

3.5 headset is working fine after suspend/resume.

Note: EC reboot (F3 + power) resolves this issue.

Removing RBB. 

Additional feedback from jachuang@ being able to reproduce relatively consistently:
https://listnr.corp.google.com/report/77887030460

Description:
3.5 jack not detecting

UI language:
en-US

Version:
63.0.3239.20 dev

Product Specific Data (whitelisted):
CHROME VERSION: 63.0.3239.20 dev
CHROMEOS_AUSERVER: <URL: 1>
CHROMEOS_RELEASE_BOARD: bob-signed-mpkeys
CHROMEOS_RELEASE_DESCRIPTION: 10032.17.0 (Official Build) dev-channel bob
CHROMEOS_RELEASE_TRACK: dev-channel
CHROMEOS_RELEASE_VERSION: 10032.17.0


Log uploaded at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/778802


Adding RBS label

Updated my image to R62 9901.54.0 test image  
I wasn't able to address the DA7219 on the I2C bus .
Could that be a initial sequencing issue ? Or the pin mux 
on RK wasn't config correctly ?

should be one of the address here 0x18,0x19,0x1A,0x1B



localhost / # i2cdetect -l
i2c-1   i2c             rk3x-i2c                                I2C adapter
i2c-3   i2c             rk3x-i2c                                I2C adapter
i2c-5   i2c             rk3x-i2c                                I2C adapter
i2c-8   i2c             rk3x-i2c                                I2C adapter
i2c-9   i2c             cros-ec-i2c-tunnel                      I2C adapter
i2c-10  i2c             DP-AUX                                  I2C adapter
localhost / # i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
localhost / # i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
localhost / # i2cdetect -y -r 5
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

I don't think this qualifies for a release blocker. This is not easy to reproduce. Removing RBS and punt to M64.

I still can not reproduce this issue on bob.
Adding some information that might be helpful in debugging:

Hi Dexter, da7219 is on i2c bus 8, address 0x1a.
I get the register dump by :

cd /sys/kernel/debug/regmap/8-001a
echo  1 > cache_bypass
cat registers > /tmp/regs (as attached)

c6: d1

The last bit of C6 is the detection (which is 1 now, so the detection is enabled).[1][2]
With this bit set, da7219 should trigger the interrupt when headphone is plugged or unplugged.


Hi Jack, do you still have the device in #4 ?
In dev mode, you can check whether evtest shows anything.


localhost ~ # evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      cros_ec
/dev/input/event1:      cros_ec_buttons
/dev/input/event2:      Elan Touchscreen
/dev/input/event3:      Elan Touchpad
/dev/input/event4:      rk3399-gru-sound Headset Jack
/dev/input/event5:      rk3399-gru-sound DP Jack
/dev/input/event6:      gpio-keys
Select the device event number [0-6]: 4
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "rk3399-gru-sound Headset Jack"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 226 (KEY_MEDIA)
    Event code 582 (?)
  Event type 5 (EV_SW)
    Event code 2 (SW_HEADPHONE_INSERT)
    Event code 4 (SW_MICROPHONE_INSERT)
    Event code 6 (SW_LINEOUT_INSERT)
Properties:
Testing ... (interrupt to exit)
Event: time 1511426269.968804, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1511426269.968804, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
Event: time 1511426269.968804, -------------- SYN_REPORT ------------
Event: time 1511426272.940289, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1511426272.940289, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 0
Event: time 1511426272.940289, -------------- SYN_REPORT ------------


Or, goes one step further: check the debug message at interrupt handler:

When plugged:

2017-11-23T16:36:05.131489+08:00 DEBUG kernel: [  139.836204] da7219 8-001a: IRQ events = 0x1|0x0, status = 0x1
2017-11-23T16:36:05.274557+08:00 DEBUG kernel: [  139.979671] da7219 8-001a: IRQ events = 0x4|0x0, status = 0x3

When unplugged:

2017-11-23T16:36:11.211192+08:00 DEBUG kernel: [  145.916377] da7219 8-001a: IRQ events = 0x2|0x0, status = 0x0

(Need to add #define DEBUG in the beginning of da7219-aad.c https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/786694/1/sound/soc/codecs/da7219-aad.c )

(submitted a tryjob https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/release/builds/17610 )

[1] https://cs.corp.google.com/chromeos_public/src/third_party/kernel/v4.4/sound/soc/codecs/da7219-aad.c?q=da7219-aad+package:%5Echromeos_public$&dr=C&l=46
[2] https://cs.corp.google.com/chromeos_public/src/third_party/kernel/v4.4/sound/soc/codecs/da7219-aad.h?l=114

Deleted: regs 1.7 KB

regs 1.7 KB View Download

Is there any update on this bug? is this bug still relevant?

We've experienced this on 85% of our latest machine the ASUS C101P on 62.0.3202. The way we have directed our staff to remedy the issue is by Shutting lid ( to cause suspension) & log back & replug in the aux device to trigger a response. This is working but my team and I are not sure if this is the best long term resolution but we can't update our domains CBs for several weeks due to State testing. 

avkodipelli@ sontis@ kalin@ Is there a bob device that you can easily reproduce this? If yes, can you send it to Taipei?

I am unable to reproduce this issue with a Bob device running the latest stable release (R63-10032.88.0)  

I followed these steps:
1) Play video with no audio peripherals connected
2) Plug 3.5 headphones after playing video for 30 min.

The audio node switched successfully to 3.5 headphones.  Additionally, we tried to reproduce with Apple Earbuds and Fujack In Ear Earbuds. The audio node switched without issue both times.

Chatted with sontis@, and as he commented in c#2, the EC reboot(Esc+Refresh+Power) resolves the issue. And seems like permanent fix/workaround. The original reporter also has not reproduced it since.

I'm going to report to my environment to use the workaround and to see what happens after I open the domain up for updates in a few weeks.  

Hi guys,

sounds like a dup to https://partnerissuetracker.corp.google.com/issues/70247949

which is fixed(workaround) by:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/877702

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.