mbox series

[v1,0/2] *** Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel ***

Message ID 20230519080136.4058243-1-yangcong5@huaqin.corp-partner.google.com (mailing list archive)
Headers show
Series *** Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel *** | expand

Message

cong yang May 19, 2023, 8:01 a.m. UTC
The previous patch is not based on drm-misc-next, resend this series.
Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel,
set the default high for RST at boe_panel_add and add lp11_before_reset flag.

Cong Yang (2):
  drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
  drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c    | 474 +++++++++++++++++-
 1 file changed, 473 insertions(+), 1 deletion(-)

Comments

Neil Armstrong May 22, 2023, 7:24 a.m. UTC | #1
Hi,


On 19/05/2023 10:01, Cong Yang wrote:
> The previous patch is not based on drm-misc-next, resend this series.
> Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel,
> set the default high for RST at boe_panel_add and add lp11_before_reset flag.

If the reset gpio polarity is different, please change it in the DT by using
a different gpio flag instead of changing the driver.

However if the logic is different and reset must never be asserted to low,
the the bindings + driver to make the reset line optional and set a gpio-hog
in DT to keep it at a safe level.

Neil


> Cong Yang (2):
>    drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
>    drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
> 
>   .../gpu/drm/panel/panel-boe-tv101wum-nl6.c    | 474 +++++++++++++++++-
>   1 file changed, 473 insertions(+), 1 deletion(-)
>
cong yang May 22, 2023, 8 a.m. UTC | #2
Hi,neil:
 Thank you for your reply, it's not that the polarity of reset is
different. The state of this rst needs to be high during a certain period
of time (when hid touch communicate,). I have tried to set the default
property to high in DT, but from the log and waveform, the rseet single  is
set to low by boe_panel_add before hid touch communication.As shown in the
picture, rst needs to be high before hid ready. Datasheet:
https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence
[image: image.png]

On Mon, May 22, 2023 at 3:24 PM <neil.armstrong@linaro.org> wrote:

> Hi,
>
>
> On 19/05/2023 10:01, Cong Yang wrote:
> > The previous patch is not based on drm-misc-next, resend this series.
> > Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel,
> > set the default high for RST at boe_panel_add and add lp11_before_reset
> flag.
>
> If the reset gpio polarity is different, please change it in the DT by
> using
> a different gpio flag instead of changing the driver.
>
> However if the logic is different and reset must never be asserted to low,
> the the bindings + driver to make the reset line optional and set a
> gpio-hog
> in DT to keep it at a safe level.
>
> Neil
>
>
> > Cong Yang (2):
> >    drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
> >    drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
> >
> >   .../gpu/drm/panel/panel-boe-tv101wum-nl6.c    | 474 +++++++++++++++++-
> >   1 file changed, 473 insertions(+), 1 deletion(-)
> >
>
>
Doug Anderson May 23, 2023, 9:04 p.m. UTC | #3
Hi,

On Mon, May 22, 2023 at 1:01 AM cong yang
<yangcong5@huaqin.corp-partner.google.com> wrote:
>
> Hi,neil:
>  Thank you for your reply, it's not that the polarity of reset is different. The state of this rst needs to be high during a certain period of time (when hid touch communicate,). I have tried to set the default property to high in DT, but from the log and waveform, the rseet single  is set to low by boe_panel_add before hid touch communication.As shown in the picture, rst needs to be high before hid ready. Datasheet: https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence

To add some breadcrumbs, I think the issues is that panel/touchscreeen
are intertwined and really need a solution like the one proposed in my
series:

https://lore.kernel.org/r/20230523193017.4109557-1-dianders@chromium.org

Cong Yang tested an early version of my series and indicated that it
helped solve his problem. Presumably if that series (or something like
it) can land then we'll unblock the ability to support this hardware.

-Doug