Re: CM32181 Bug Report (Linux 6.0+)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



------- Original Message -------
On Thursday, January 12th, 2023 at 5:48 AM, Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> wrote:


> Hi Wahaj,
> 
> On Sun, Jan 8, 2023 at 8:33 PM Jonathan Cameron jic23@xxxxxxxxxx wrote:
> 
> > On Sat, 07 Jan 2023 00:37:40 +0000
> > Wahaj wahajaved@xxxxxxxxxxxxxx wrote:
> > 
> > > ------- Original Message -------
> > > On Friday, January 6th, 2023 at 9:08 AM, Kai-Heng Feng kai.heng.feng@xxxxxxxxxxxxx wrote:
> > > 
> > > > Hi Wahaj,
> > > > 
> > > > On Fri, Jan 6, 2023 at 12:26 AM Wahaj wahajaved@xxxxxxxxxxxxxx wrote:
> > > > 
> > > > > ------- Original Message -------
> > > > > 
> > > > > On Tuesday, January 3rd, 2023 at 2:26 PM, Jonathan Cameron Jonathan.Cameron@xxxxxxxxxx wrote:
> > > > > 
> > > > > > On Wed, 28 Dec 2022 14:05:24 +0000
> > > > > > Wahaj wahajaved@xxxxxxxxxxxxxx wrote:
> > > > > 
> > > > > > > Hi Jonathan
> > > > > > > 
> > > > > > > Hope you're doing well. I have been using a laptop that comes with a
> > > > > > > CM32181 Light Sensor and after upgrading to the Linux kernel 6.0+, my
> > > > > > > laptop cannot seem to suspend because of the PM subsystem error. I
> > > > > > > have narrowed the problem down to this module and I believe that the
> > > > > > > commit 68c1b3dd5c48b2323067f8c1f0649ae2f31ab20bis the culprit
> > > > > > > 
> > > > > > > The following lines were provided from the journalctl logs:
> > > > > > > 
> > > > > > > > cm32181 i2c-CPLM3218:00: PM: dpm_run_callback():
> > > > > > > > acpi_subsys_suspend+0x0/0x60 returns -121 cm32181 i2c-CPLM3218:00:
> > > > > > > > PM: failed to suspend async: error -121
> > > > > > > 
> > > > > > > I would love the chance to be able to work on this given any guidance
> > > > > > > on where to start
> > > > > > 
> > > > > > Hi Wahaj,
> > > > > > 
> > > > > > Certainly seems likely that you have identified the right commit.
> > > > > > As a starting point, resend this email to linux-iio@xxxxxxxxxxxxxxx
> > > > > > and Kai-Heng Feng kai.heng.feng@xxxxxxxxxxxxx
> > > > > > 
> > > > > > If you could try reverting the commit to be completely sure it is
> > > > > > the cause that would help avoid any doubt.
> > > > > > Superficially the only thing that I can see causing this problem is
> > > > > > a fail of the i2c bus write.
> > > > > > 
> > > > > > Does the device work prior to suspend? Try cat /sys/bus/iio/iio:device0/*
> > > > > > and see if you get any errors (may be device1 etc)
> > > > > > 
> > > > > > If the device wasn't working at all the register writes in probe() should
> > > > > > have failed so we shouldn't be trying to suspend it.
> > > > > > It's possible your machine has some unusual power dependencies or
> > > > > > similar that mean the device is getting powered down before we try to
> > > > > > suspend it.
> > > > > > 
> > > > > > Anyhow, better to have this discussion on list as there are many other people
> > > > > > who may have more insight than me or be able to replicate and help debug.
> > > > > > 
> > > > > > Jonathan
> > > > > > 
> > > > > > > Best Regards,
> > > > > > > Wahaj Javed
> > > > > 
> > > > > Hi Jonathan and Kai-Heng Feng,
> > > > > 
> > > > > I am currently using the 5.15 linux kernel for a while now which works perfectly fine.
> > > > > 
> > > > > From what I gather the suspend functionality does work when using an older Linux version without the PM i2c bus writes.
> > > > 
> > > > Does your system use S3 or S2idle to perform suspend?
> > > 
> > > My system uses S3 to perform suspend
> > > 
> > > > > The device does work fine prior to and post attempted suspend with no errors showing in cat /sys/bus/iio/iio:device0/*
> > > > 
> > > > Does in_illuminance_input value change after system suspend?
> > > > Yes, the in_illuminance_input value changes after system suspend with or without the suspend and resume functions
> > > 
> > > > Kai-Heng
> > > > 
> > > > > Let me know if there's anything I should start looking into
> > > > > 
> > > > > Best Regards
> > > > > Wahaj Javed
> > > 
> > > How did the kernel used to suspend/resume before using the suspend and resume functions in the light sensor?
> > > 
> > > Was the DEFINE_SIMPLE_DEV_PM_OPS introduced as a part of the Linux 6.0+ PM rework?
> > 
> > Until https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68c1b3dd5c48b2323067f8c1f0649ae2f31ab20b
> > which will have hit mainline in 6.0, the driver had no suspend / resume support.
> > 
> > That patch introduced an i2c write to put the chip into a low power mode.
> > My best guess for a cause would be that something else is incorrectly being disabled
> > before this call and hence breaking the i2c comms.
> 
> 
> Can you please try the patch here and see if the device supports
> DISABLE command at all:
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1988346/comments/52

I've tried it, this is the response 

  tee: '/sys/bus/iio/devices/iio:device0/disable': Permission denied

I don't think it supports the disable command

Wahaj Javed

> 
> Kai-Heng
> 
> > Jonathan
> > 
> > > I would like to take on this bug and try to solve it if that's possible
> > > 
> > > Best Regards
> > > Wahaj Javed




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux