Re: [Regression]: Commit 74d905d2 breaks the touchpad and touchscreen of Google Chromebook "samus"

ted. @dmitry I would suggest to revert the commit until we find out the root cause Thanks, Jiada On 2020/11/24 15:15, Andre Muller wrote: On 24/11/2020 04.02, Wang, Jiada wrote: Hello Andre Thanks for the log, can you add more debug information like following diff, and get full log? Hi Ji

Re: [Regression]: Commit 74d905d2 breaks the touchpad and touchscreen of Google Chromebook "samus"

; + } } dev_warn(>dev, "Enabling RETRIGEN workaround\n"); Thanks, Jiada On 2020/11/05 23:23, Andre Muller wrote: On 05/11/2020 14.25, Wang, Jiada wrote: Hi Andre Thanks for your report, could you also please post the log when with this commit reverted? T

Re: [Regression]: Commit 74d905d2 breaks the touchpad and touchscreen of Google Chromebook "samus"

Hi Andre Thanks for your report, could you also please post the log when with this commit reverted? Thanks, Jiada On 2020/11/04 17:13, Andre wrote: Hi, commit 74d905d2: Input: atmel_mxt_ts - only read messages in mxt_acquire_irq() when necessary breaks the touchpad and touchscreen of the

Re: [PATCH v3 0/3] implement I2C retries for mXT1368

Hello Dmitry and all Kind reminder on this patch-set Thanks, Jiada On 2020/10/01 0:12, Jiada Wang wrote: According to datasheet, mXT1386 chip has a WAKE line, it is used to wake the chip up from deep sleep mode before communicating with it via the I2C-compatible interface. if the WAKE

Re: [PATCH v2 1/3] dt-bindings: input: atmel: add compatible for mXT1386

Hi Thierry Thanks for your comment On 2020/09/28 15:59, Thierry Reding wrote: On Fri, Sep 25, 2020 at 10:52:55PM +0900, Jiada Wang wrote: Document the mXT1386 compatible string. Signed-off-by: Jiada Wang --- Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 1 + 1 file

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

Hi Dmitry On 2020/09/20 23:21, Dmitry Osipenko wrote: 20.09.2020 16:13, Wang, Jiada пишет: Hi Dmitry On 2020/09/20 15:02, Dmitry Torokhov wrote: On Sat, Sep 19, 2020 at 10:28 PM Wang, Jiada wrote: Hi Dmitry On 2020/09/20 4:49, Dmitry Osipenko wrote: 18.09.2020 18:55, Wang, Jiada пишет

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

Hi Dmitry On 2020/09/20 15:02, Dmitry Torokhov wrote: On Sat, Sep 19, 2020 at 10:28 PM Wang, Jiada wrote: Hi Dmitry On 2020/09/20 4:49, Dmitry Osipenko wrote: 18.09.2020 18:55, Wang, Jiada пишет: ... +static void mxt_wake(struct mxt_data *data) +{ +struct i2c_client *client = data

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

Hi Dmitry On 2020/09/20 4:49, Dmitry Osipenko wrote: 18.09.2020 18:55, Wang, Jiada пишет: ...   +static void mxt_wake(struct mxt_data *data) +{ +    struct i2c_client *client = data->client; +    struct device *dev = >client->dev; +    struct device_node *np = dev->of_node

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

Hi Dmitry Thanks for your quick comments On 2020/09/18 22:32, Dmitry Osipenko wrote: 18.09.2020 15:56, Jiada Wang пишет: According to datasheet, mXT1386 chip has a WAKE line, it is used to wake the chip up from deep sleep mode before communicating with it via the I2C-compatible interface. if

Re: [PATCH v4 1/1] Input: atmel_mxt_ts - implement I2C retries

Hi Dmitry On 2020/09/15 6:33, Dmitry Osipenko wrote: 14.09.2020 22:36, Dmitry Torokhov пишет: On Mon, Sep 14, 2020 at 12:33:40PM -0700, Dmitry Torokhov wrote: On Mon, Sep 14, 2020 at 08:29:44PM +0300, Dmitry Osipenko wrote: 13.09.2020 19:56, Dmitry Torokhov пишет: Hi Jiada, On Sat, Sep 12,

Re: [PATCH v2 1/1] Input: atmel_mxt_ts - implement I2C retries

Hi Andy Thanks for your comment On 2020/09/06 3:02, Andy Shevchenko wrote: On Thursday, September 3, 2020, Jiada Wang > wrote: From: Nick Dyer mailto:nick.d...@itdev.co.uk>> Some maXTouch chips (eg mXT1386) will not respond on the first I2C

Re: [PATCH 1/1] Input: atmel_mxt_ts - implement I2C retries

Hi Dmitry On 2020/08/28 17:19, Dmitry Osipenko wrote: 21.08.2020 11:22, Jiada Wang пишет: From: Nick Dyer Some maXTouch chips (eg mXT1386) will not respond on the first I2C request when they are in a sleep state. It must be retried after a delay for the chip to wake up. Signed-off-by: Nick

Re: [PATCH 1/1] Input: atmel_mxt_ts - allow specification of firmware file name

Hi Dmitry On 2020/08/10 5:11, Dmitry Osipenko wrote: 31.07.2020 10:57, Jiada Wang пишет: From: Nick Dyer On platforms which have multiple device instances using this driver, the firmware may be different on each device. This patch makes the user give the name of the firmware file when

Re: [PATCH v11 00/56] atmel_mxt_ts misc

Hello All I am thinking it doesn't make sense to keep the series with such a big chunk of patches, I will divide the series into several small series Thanks, Jiada On 2020/07/08 22:05, Wang, Jiada wrote: Hello Dmitry I am working on refining this series, regarding your comment about drop

Re: [PATCH v11 00/56] atmel_mxt_ts misc

help to confirm if this is the case? Thanks, Jiada On 2020/06/25 22:50, Wang, Jiada wrote: Hello Dmitry sorry for the delay, On 2020/05/27 15:43, Dmitry Torokhov wrote: Hi Jiada, On Thu, May 07, 2020 at 10:56:00PM -0700, Jiada Wang wrote: This patch-set forward ports Nick Dyer's work

Re: [PATCH v11 05/56] Input: atmel_mxt_ts - output status from T48 Noise Supression

Hello Dmitry On 2020/05/12 7:23, Dmitry Torokhov wrote: On Thu, May 07, 2020 at 10:56:05PM -0700, Jiada Wang wrote: From: Nick Dyer This patch outputs status from T48 Noise Supression Signed-off-by: Nick Dyer Acked-by: Benson Leung Acked-by: Yufeng Shen (cherry picked from

Re: [PATCH v11 07/56] Input: atmel_mxt_ts - implement T9 vector/orientation support

Hello Dmitry On 2020/05/12 7:53, Dmitry Torokhov wrote: On Thu, May 07, 2020 at 10:56:07PM -0700, Jiada Wang wrote: From: Nick Dyer The atmel touch messages contain orientation information as a byte in a packed format which can be passed straight on to Android if the input device

Re: [PATCH v11 04/56] Input: atmel_mxt_ts - split large i2c transfers into blocks

Hello Dmitry On 2020/05/12 7:19, Dmitry Torokhov wrote: Hi Jiada, Nick, On Thu, May 07, 2020 at 10:56:04PM -0700, Jiada Wang wrote: From: Nick Dyer On some firmware variants, the size of the info block exceeds what can be read in a single transfer. Is this limitation of the mXT controller

Re: [PATCH v11 00/56] atmel_mxt_ts misc

Hello Dmitry sorry for the delay, On 2020/05/27 15:43, Dmitry Torokhov wrote: Hi Jiada, On Thu, May 07, 2020 at 10:56:00PM -0700, Jiada Wang wrote: This patch-set forward ports Nick Dyer's work in ndyer/linux github repository as long as some other features and fixes Sorry for ignoring the

Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

Hello Dmitry On 2020/05/17 22:26, Dmitry Osipenko wrote: 17.05.2020 16:08, Dmitry Osipenko пишет: 17.05.2020 06:32, Wang, Jiada пишет: Hello Dmitry On 2020/05/14 13:53, Dmitry Osipenko wrote: 13.05.2020 08:07, Wang, Jiada пишет: Hello Dmitry On 2020/05/12 8:13, Dmitry Osipenko wrote

Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

Hello Dmitry On 2020/05/14 13:53, Dmitry Osipenko wrote: 13.05.2020 08:07, Wang, Jiada пишет: Hello Dmitry On 2020/05/12 8:13, Dmitry Osipenko wrote: 11.05.2020 05:05, Wang, Jiada пишет: Hello Dmitry Thanks for your comment and test, can you let me know which platform (board) you

Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

Hello Dmitry On 2020/05/12 8:13, Dmitry Osipenko wrote: 11.05.2020 05:05, Wang, Jiada пишет: Hello Dmitry Thanks for your comment and test, can you let me know which platform (board) you are using for test, and DTS changes if you have added any. That's this device-tree [1] without any

Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

Hello Dmitry Thanks for your comment and test, can you let me know which platform (board) you are using for test, and DTS changes if you have added any. Thanks, Jiada On 2020/05/11 10:05, Dmitry Osipenko wrote: 08.05.2020 08:56, Jiada Wang пишет: The path of enabling the IRQ in the probe

unload Audio drivers while playback stream is active case kernel crash

Hi Community Sorry previous email doesn't have formatted crash log. I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, wm8962 codec and SSI CPU DAI, I got Kernel crash when unloading audio drivers (playback stream is active) modprobe -r snd_soc_imx_wm8962 modprobe -r

unload Audio drivers while playback stream is active case kernel crash

Hi Community I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, wm8962 codec and SSI CPU DAI, I got Kernel crash when unloading audio drivers (playback stream is active) modprobe -r snd_soc_imx_wm8962 modprobe -r snd_soc_fsl_ssi modprobe -r snd_soc_wm8962 [ 208.666868]

unload Audio drivers while playback stream is active case kernel crash

Hi Community I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, wm8962 codec and SSI CPU DAI, I got Kernel crash when unloading audio drivers (playback stream is active) modprobe -r snd_soc_imx_wm8962 modprobe -r snd_soc_fsl_ssi modprobe -r snd_soc_wm8962 [ 208.666868]

unload Audio drivers while playback stream is active case kernel crash

Hi Community Sorry previous email doesn't have formatted crash log. I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, wm8962 codec and SSI CPU DAI, I got Kernel crash when unloading audio drivers (playback stream is active) modprobe -r snd_soc_imx_wm8962 modprobe -r

RE: [PATCH 1/2] serial: imx: remove the DMA wait queue

Hi Shijie After apply this patch into our kernel, We are facing data hang issue when sending big size file (2M used in test) to uart port Note: Rx port is also keep receiving data. After read the implementation of uart_stop(), I feel like, stop_tx() is used to perform flow control when like a

RE: [PATCH 1/2] serial: imx: remove the DMA wait queue

Hi Shijie After apply this patch into our kernel, We are facing data hang issue when sending big size file (2M used in test) to uart port Note: Rx port is also keep receiving data. After read the implementation of uart_stop(), I feel like, stop_tx() is used to perform flow control when like a