Hi, On Wed, Oct 11, 2023 at 3:11 AM Doug Anderson <dianders@xxxxxxxxxx> wrote: > > Hi, > > On Tue, Oct 10, 2023 at 4:36 AM cong yang > <yangcong5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Tue, Oct 10, 2023 at 4:44 AM Doug Anderson <dianders@xxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > On Fri, Oct 6, 2023 at 11:07 PM Cong Yang > > > <yangcong5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > At present, we have found that there may be a problem of blurred > > > > screen during fast sleep/resume. The direct cause of the blurred > > > > screen is that the IC does not receive 0x28/0x10. Because of the > > > > particularity of the IC, before the panel enters sleep hid must > > > > stop scanning, i2c_hid_core_suspend before ili9882t_disable. > > > > This doesn't look very spec-compliant. > > > > > > Presumably you could be more spec compliant if we used > > > "panel_follower" in this case? Would that be a better solution? > > > > In the "panel_follower" solution, the phenomenon is the same. > > The current order is > > ili9882t_disable=>i2c_hid_core_suspend=>elan_i2c_hid_power_down=>ili9882t_unprepare, > > ili9882t need touchpanel stop scanning,i2c_hid_core_suspend before > > ili9882t_disable. > > Ugh, that's unfortunate. Though is there a reason why you couldn't > just move the `ili9882t_enter_sleep_mode()` to `ili9882t_unprepare()`? > That seems like it should be OK and even perhaps makes it more > symmetric with thue enable? It looks like the test will still fail, because the touchpanel reset was already pulled low before the panel enter sleep, which did not seem to meet the timing requirements. I will explain this in the V3 cover letter. Thanks. > > > > > > @@ -507,7 +526,7 @@ static int ili9882t_prepare(struct drm_panel *panel) > > > > gpiod_set_value(ili->enable_gpio, 1); > > > > usleep_range(1000, 2000); > > > > gpiod_set_value(ili->enable_gpio, 0); > > > > - usleep_range(1000, 2000); > > > > + usleep_range(40000, 50000); > > > > > > nit: use 40000, 41000 instead of 40000, 50000. Linux almost always > > > uses the longer delay, so that'll save ~9 ms. The only reason for the > > > range is to optimize kernel wakeups which is really not a concern > > > here. > > > > We need 50ms delay to meet the requirement. > > I'll respond to your v2, but if you need 50 ms then your current delay is wrong. > > > -Doug
