Re: [PATCH v3 0/3] Support wakeup methods of Atmel maXTouch controllers

[Dmitry Torokhov]

On Sat, Dec 12, 2020 at 10:54:35AM +0300, Dmitry Osipenko wrote:
> Hello,
> 
> 12.12.2020 05:43, Dmitry Torokhov пишет:
> > Hi Dmitry,
> > 
> > On Mon, Dec 07, 2020 at 12:22:14AM +0300, Dmitry Osipenko wrote:
> >> Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example,
> >> have a WAKE line that needs to be asserted in order to wake controller
> >> from a deep sleep, otherwise it will be unusable. This series implements
> >> support for the wakeup methods in accordance to the mXT1386 datasheet [1],
> >> see page 29 (chapter "5.8 WAKE Line").
> >>
> >> The mXT1386 is a widely used controller found on many older Android tablet
> >> devices. Touchscreen on Acer A500 tablet now works properly after this
> >> series.
> > 
> > I am trying to understand how your controller is configured on that
> > system. Could you please enable all debug messages in the driver and
> > post the logs? I am a bit confused why the controller needs to be woken
> > up twice in mxt_start() given that according to the spec it is supposed
> > to stay up for 2 seconds after successful I2C transfer...
> 
> From the page 30 in the datasheet:
> 
> "Note that when the mXT1386 is sent into deep sleep mode, it goes to
> sleep immediately. In this case the two-second timeout does not apply
> until the WAKE pin is asserted."
> 
> The debug log seems confirm that quote:
> 
> ...
> [ 1.196404] Family: 160 Variant: 0 Firmware V1.0.AA Objects: 18
> [ 1.196572] T37 Start:118 Size:130 Instances:1 Report IDs:0-0
> [ 1.196586] T44 Start:248 Size:1 Instances:1 Report IDs:0-0
> [ 1.196597] T5 Start:249 Size:9 Instances:1 Report IDs:0-0
> [ 1.196608] T6 Start:258 Size:6 Instances:1 Report IDs:1-1
> [ 1.196617] T38 Start:264 Size:64 Instances:1 Report IDs:0-0
> [ 1.196628] T7 Start:328 Size:3 Instances:1 Report IDs:0-0
> [ 1.196638] T8 Start:331 Size:10 Instances:1 Report IDs:0-0
> [ 1.196648] T9 Start:341 Size:34 Instances:1 Report IDs:2-17
> [ 1.196658] T15 Start:375 Size:11 Instances:2 Report IDs:18-19
> [ 1.196668] T18 Start:397 Size:2 Instances:1 Report IDs:0-0
> [ 1.196678] T22 Start:399 Size:17 Instances:1 Report IDs:20-20
> [ 1.196688] T24 Start:416 Size:19 Instances:1 Report IDs:21-24
> [ 1.196698] T25 Start:435 Size:14 Instances:1 Report IDs:25-25
> [ 1.196708] T27 Start:449 Size:7 Instances:1 Report IDs:26-26
> [ 1.196718] T28 Start:456 Size:6 Instances:1 Report IDs:27-27
> [ 1.196728] T40 Start:462 Size:5 Instances:1 Report IDs:0-0
> [ 1.196738] T41 Start:467 Size:6 Instances:1 Report IDs:0-0
> [ 1.196748] T43 Start:473 Size:6 Instances:1 Report IDs:0-0
> [ 1.196852] Direct firmware load for maxtouch.cfg failed with error -2
> [ 1.197305] T6 Config Checksum: 0x8D7459
> [ 1.197318] T6 Status 0x90 RESET CAL
> [ 1.197543] Initialized power cfg: ACTV 10, IDLE 50
> [ 1.198387] Touchscreen size X1279Y799
> ...
> [ 1.211686] T6 Status 0x00 OK
> ...
> [15.576573] Set T7 ACTV:10 IDLE:50
> [15.592142] T6 Status 0x10 CAL
> [15.597920] T6 Status 0x00 OK
> [15.604846] Set T7 ACTV:0 IDLE:0
> [15.831477] waking up controller
> [15.862912] Set T7 ACTV:10 IDLE:50
> [15.872783] Set T7 ACTV:0 IDLE:0

Thank you for the logs. I am confused where these calls to put the
controller into deep sleep are coming from. Does something constantly
open and close input device? Do you have any additional patches? We
definitely do not issue deep sleep request in mxt_start(). Do you mind
putting dump_stack() into mxt_set_t7_power_cfg() to see where the calls
are coming from?

I also do not see additional "waking up controller" messages after
requesting the chip via T7 to be configured to be active, which I'd
expected to see if we indeed needed to wake it up again for T6 to
succeed.

Thanks.

-- 
Dmitry