[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <103b5438-9f7c-7e89-28b9-29fe11eb818c@redhat.com>
Date: Mon, 18 Oct 2021 10:30:04 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Tsuchiya Yuto <kitakar@...il.com>
Cc: Patrik Gfeller <patrik.gfeller@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Kaixu Xia <kaixuxia@...cent.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
Arnd Bergmann <arnd@...db.de>, linux-media@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [BUG 5/5] [BUG] media: atomisp: atomisp causes touchscreen to
stop working on Microsoft Surface 3
Hi,
On 10/17/21 18:23, Tsuchiya Yuto wrote:
> Touchscreen input works fine before loading atomisp driver on Surface 3.
>
> However, after loading atomisp driver, touchscreen works only when
> capturing images. This sounds like atomisp turns off something needed
> for touchscreen when atomisp is idle.
>
> There is no useful kernel log. Just the touchscreen stops working
> with no log.
>
> I'll update if I find something further. First of all, can someone
> reproduce this issue on the other devices?
My first bet would be some regulator getting turned off.
What you can do is:
1. ls -l /dev/bus/i2c/devices
And then write down the number of the i2c-bus to which the
CRC PMIC is connected, lets say it is number "4". Then:
2. Before loading the atomisp drivers run:
"sudo i2cdump -y -f 4 0x6e > crc-regs-good"
3. After loading the atomisp drivers run:
"sudo i2cdump -y -f 4 0x6e > crc-regs-bad
4. "diff -u crc-regs-good crc-regs-bad"
And see what changed.
There are 2 possible root causes here:
1. Some regulator is shared between the cameras and
touchscreen
2. The crc code in atomisp which you are using is
poking registers assuming the Bay Trail version of
the Crystal Cove PMIC (aka CRC PMIC) but your
Surface 3 has the Cherry Trail version and we know
that the regulators are add different register
addresses there, see the comment in:
drivers/acpi/pmic/intel_pmic_chtcrc.c
so it is possible that the atomisp code is simply
poking the wrong register for one of the regulators
I also wonder if this goes away if you do the
hrv = 0x03;
Hack inside drivers/mfd/intel_soc_pmic_core.c ?
Without that we end up using the wrong PMIC
OpRegion driver which also uses the wrong
regulator addresses.
Regards,
Hans
p.s.
Here are the 2 different regulator drivers the
comment in drivers/acpi/pmic/intel_pmic_chtcrc.c
refers to:
https://github.com/Zenfone2-Dev/android_kernel_asus_moorefield-1/blob/stock/drivers/regulator/pmic_crystal_cove.c
https://github.com/Zenfone2-Dev/android_kernel_asus_moorefield-1/blob/stock/drivers/regulator/pmic_crystal_cove_plus.c
Powered by blists - more mailing lists