linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tsuchiya Yuto <kitakar@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Patrik Gfeller <patrik.gfeller@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Kaixu Xia <kaixuxia@tencent.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [BUG 5/5] [BUG] media: atomisp: atomisp causes touchscreen to stop working on Microsoft Surface 3
Date: Tue, 26 Oct 2021 18:35:26 +0900	[thread overview]
Message-ID: <b86b8c1257d535cd03e6ded145aa0467b91929e7.camel@gmail.com> (raw)
In-Reply-To: <552baf68-8fed-9a6f-d18c-5634f93a58f8@redhat.com>

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!
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).

> 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.
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.

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



  reply	other threads:[~2021-10-26  9:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-17 16:23 [BUG 0/5] bug reports for atomisp to make it work Tsuchiya Yuto
2021-10-17 16:23 ` [BUG/RFC PATCH 1/5] [BUG][RFC] media: atomisp: pci: assume run_mode is PREVIEW Tsuchiya Yuto
     [not found]   ` <20211029100259.2cdfdfce@sal.lan>
2021-11-11  8:00     ` Tsuchiya Yuto
2021-10-17 16:23 ` [BUG/RFC PATCH 2/5] [BUG][RFC] media: atomisp: pci: remove dummy_ptr NULL check to avoid duplicate active_bo Tsuchiya Yuto
2021-10-17 16:23 ` [BUG/RFC PATCH 3/5] [BUG][RFC] media: atomisp: pci: add NULL check for asd obtained from atomisp_video_pipe Tsuchiya Yuto
2021-11-02 13:02   ` Dan Carpenter
2021-11-02 14:44     ` Andy Shevchenko
2021-11-02 14:45       ` Andy Shevchenko
2021-11-02 15:05         ` Dan Carpenter
2021-11-02 15:49           ` Andy Shevchenko
2021-11-02 22:52             ` Mauro Carvalho Chehab
2021-11-08 15:48     ` Tsuchiya Yuto
2021-10-17 16:23 ` [BUG 4/5] [BUG] media: atomisp: `modprobe -r` not working well (dup video4linux, ATOMISP_SUBDEV_{0,1}) Tsuchiya Yuto
2021-10-17 16:23 ` [BUG 5/5] [BUG] media: atomisp: atomisp causes touchscreen to stop working on Microsoft Surface 3 Tsuchiya Yuto
2021-10-18  8:30   ` Hans de Goede
2021-10-21  9:52     ` Tsuchiya Yuto
2021-10-24  8:32       ` Hans de Goede
2021-10-26  9:35         ` Tsuchiya Yuto [this message]
2021-10-26 15:41           ` Hans de Goede
2021-10-27 16:07             ` Tsuchiya Yuto
2021-11-07 23:39       ` Hans de Goede
2021-11-08  7:41         ` Mauro Carvalho Chehab
2021-11-08  7:55           ` Hans de Goede
2021-11-08  8:01             ` Mauro Carvalho Chehab
2021-11-09  4:18             ` Tsuchiya Yuto
2021-11-09  9:08               ` Mauro Carvalho Chehab
2021-11-09  4:15         ` Tsuchiya Yuto
2021-11-09  7:35           ` Mauro Carvalho Chehab
2021-10-18  7:50 ` [BUG 0/5] bug reports for atomisp to make it work Hans de Goede
2021-10-18  8:10   ` Andy Shevchenko
2021-10-19 12:58     ` Tsuchiya Yuto
2021-10-19 14:06       ` Andy Shevchenko
2021-10-20  6:48 ` Mauro Carvalho Chehab
2021-10-20 12:35   ` Tsuchiya Yuto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b86b8c1257d535cd03e6ded145aa0467b91929e7.camel@gmail.com \
    --to=kitakar@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=kaixuxia@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=mingo@kernel.org \
    --cc=patrik.gfeller@gmail.com \
    --cc=peterz@infradead.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).