lkml.org 
[lkml]   [2021]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [BUG 5/5] [BUG] media: atomisp: atomisp causes touchscreen to stop working on Microsoft Surface 3
From
Hi,

On 10/26/21 11:35, Tsuchiya Yuto wrote:
> On Sun, 2021-10-24 at 10:32 +0200, Hans de Goede wrote:
>> Hi,
>>
>> [...]
>>
>> <note going a bit offtopic from atomisp here>
>>
>> Friday I've resized the Android data partition on my Mi Pad 2 Android,
>> 16G eMMC model and installed Fedora 35 in the free space.
>>
>> And yesterday I've been poking at the Mi Pad 2 the entire day,
>> both under Fedora and under the original Android install to figure
>> out which chips there are and how they are used, etc. This has
>> diverted me from looking into atomisp2 stuff, but it was fun :)
>>
>> I've also managed to make the i915 driver work. It still gives one
>> warning during boot which I need to look into. But it works now.
>> ATM my i915 fix is just a hack. I plan to turn it into something
>> which I hope I can get upstream, I'll Cc you (Tsuchiya) on the
>> upstream submission of the i915 submission.
>
> Thank you! I just tried your patch and now mipad2 can boot with GPU!

I'm happy to hear that it works for you to, is it ok if I add
a "Tested-by: Tsuchiya Yuto <kitakar@gmail.com>" to the next version
of the patch?

> So, I tried if I can reproduce touchscreen issue with atomisp, but
> there was no such issue. Touchscreen works regardless of atomisp drivers.
> I guess this is maybe a PMIC difference (mipad2/wcove and surface3/ccove).

Yeah, I actually bought a 2nd hand Surface 3 this weekend so that
I have the same platforms as you to test on as we work on improving
the atomisp2 driver. I've not run any atomisp tests on either device
yet, but I hope to get around to that soon. Then I should also be
able to see if I can reproduce the touchscreen issue and try to
debug it.

>> I've also figured out all the other chips used in the Mi Pad 2
>> and I believe I should be able to get things battery monitoring
>> and switching the USB plug between host <-> device mode to work
>> without too much issues (but it will take some time). This is
>> all pretty similar to all the special handling which I've already
>> added to the kernel for the GPD win / pocket devices which also
>> use the CHT Whiskey Cove PMIC.
>
> Thanks. I haven't looked into anything other than atomisp yet, so I
> can't comment anything but it's really interesting to see how drivers
> are developed :-)
>
>> Here are my notes about all the non standard chips used in the
>> Mi Pad 2:
>>
>> PMIC/charger/fuel-gauge:
>> -The Type-C connector is used as / wired up as a regular micro-USB connector
>>
>> -There is a Cherry Trail Whiskey Cove PMIC on the I2C7 i2c_designware ctrl
>> -This is used for ID pin detection
>> -Charger-type detection does not work though, because the USB-2 data-lines are
>> not connected to it
>> -The 2 GPIOs which are used to enable an external V5 boost converter for
>> Vbus resp Vconn on other designs are both configured as inputs (register value 0x18)
>> -The extcon-intel-cht-wc driver should control the USB mux according to the
>> ID pin, identically to how the extcon-axp288 code does this
>> -The extcon-intel-cht-wc driver should control the Vboost converter in the
>> bq25890 charger IC based on the ID pin
>>
>> -There is a bq25890 charger hanging from the CHT-WC PMIC charger I2C-bus at addr 0x6a
>> -At boot the BIOS clears bit 4 of register 3, disabling charging so the device
>> will still be powered from an external supply, but it will not charge!
>> Linux needs to fix this up
>> -This charger is connected to the USB-2 data-lines and automatically sets its
>> input-current-limit based on the detected charger
>> -Bit 5 of register 3 controls the Vboost converter for sending 5V to attached
>> USB-devices this bit needs to be controller by Linux based on the ID pin
>> detection from the PMIC. The BIOS does leave this enabled when booting with
>> a USB-device plugged in.
>>
>> -There is a BQ27520 fuel-gauge at address 0x55 of the I2C1 i2c_designware ctrl
>>
>> I2C1: addr 0x55 BQ27520 fuel-gauge
>>
>> I2C2: addr 0x0e unknown
>> I2C2: addr 0x1b Realtek 5659 codec ? (not detected by i2cdetect)
>> I2C2: addr 0x2c TI lp855x backlight controller:
>> https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/latte-l-oss/drivers/video/backlight/lp855x_bl.c
>> I2C2: addr 0x34 NXP9890 audio amplifier
>> I2C2: addr 0x37 NXP9890 audio amplifier
>> I2C2: addr 0x3e unknown
>>
>> I2C3: addr 0x30 KTD2026 RGB LED driver, controlling the status LED
>> https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/latte-l-oss/drivers/leds/leds-ktd2026.c
>>
>> I2C4: addr 0x36? OVTI5693 camera sensor
>> I2C4: addr 0x37 t3ka3 camera sensor
>>
>> I2C5: addr 0x5a Motor DRV2604 Driver ? the tablet has no haptic feedback motor!
>> Also nothing seen here by i2c-detect, probably bogus
>
> This must be a motor for the world-facing camera! I see "DW9761" in DSDT.

Interesting I checked and the world facing camera indeed has
a variable focus length. But the VCM (Voice Coil Motor) for this likely
sits on the same bus as the sensors.

> Currently, I have no idea if motors are working with the upstreamed
> atomisp because there is no userspace driver for Linux that can use
> motors.

No the code attaching to the DRV2604 ACPI ID really is a motor driver
for haptic feedback, see:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/latte-l-oss/drivers/misc/tspdrv/ImmVibeSPI.c

(never mind the SPI in the name it is actually an I2C driver).

I also noticed that the driver is using an enable GPIO, but even
if I drive that high i2cdetect still does not see anything and
AFAIK the Mi Pad 2 does not have haptics / a buzzer motor.

Regards,

Hans


>
> Regards,
> Tsuchiya Yuto
>
>> I2C6: addr 0x38 FTSC touchscreen
>>
>> I2C7: PMIC bus
>>
>> -TPS61158: LED controller for menu keys LEDS, driven by PWM controller, max brightness
>> 80/255 !!!!
>> https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/latte-l-oss/drivers/leds/leds-tps61158.c
>> Android behavior: light up menu keys for 5 seconds on any human input:
>> -Write a special HID driver for mainline linux to fix the key-events send by the
>> touchscreen and to light up the keys for 5 seconds on any HID input reports
>>
>> -Sensors (accel, als) through hid-ishtp
>>
>> -Panel 1536x2048 on card0-DSI-1
>> https://bugs.freedesktop.org/show_bug.cgi?id=108714
>>
>> -DSDT: Android: OSID == 0x04, Windows OSID == 0x01
>>
>> Regards,
>>
>> Hans
>
>

\
 
 \ /
  Last update: 2021-10-26 17:43    [W:0.081 / U:1.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site