linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Samuel Holland <samuel@sholland.org>
Cc: Alistair Francis <alistair@alistair23.me>,
	Liam Girdwood <lgirdwood@gmail.com>,
	 Lee Jones <lee.jones@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	 Rob Herring <robh+dt@kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>,
	 Sascha Hauer <s.hauer@pengutronix.de>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 Andreas Kemnade <andreas@kemnade.info>,
	Amit Kucheria <amitk@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	 linux-hwmon@vger.kernel.org, dl-linux-imx <linux-imx@nxp.com>,
	 Guenter Roeck <linux@roeck-us.net>,
	Zhang Rui <rui.zhang@intel.com>,
	 devicetree <devicetree@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v21 4/4] ARM: dts: imx7d-remarkable2: Enable lcdif
Date: Tue, 2 Aug 2022 22:43:02 +1000	[thread overview]
Message-ID: <CAKmqyKPLanGCWkofWh7rEiAhpTFF865BGQNg1q-8avpObJ+J3A@mail.gmail.com> (raw)
In-Reply-To: <ea5e1659-5842-6685-52eb-f77ac4247a2d@sholland.org>

On Sun, May 29, 2022 at 4:20 AM Samuel Holland <samuel@sholland.org> wrote:
>
> Hi Alistair,
>
> On 5/25/22 6:55 AM, Alistair Francis wrote:
> > Connect the dispaly on the reMarkable2.
> >
> > Signed-off-by: Alistair Francis <alistair@alistair23.me>
> > ---
> >  arch/arm/boot/dts/imx7d-remarkable2.dts | 74 +++++++++++++++++++++++++
> >  1 file changed, 74 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts b/arch/arm/boot/dts/imx7d-remarkable2.dts
> > index 99ac0d242936..03a4029e1e57 100644
> > --- a/arch/arm/boot/dts/imx7d-remarkable2.dts
> > +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> > @@ -68,6 +68,16 @@ reg_digitizer: regulator-digitizer {
> >               startup-delay-us = <100000>; /* 100 ms */
> >       };
> >
> > +     reg_sdoe: regulator-sdoe {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "SDOE";
> > +             pinctrl-names = "default", "sleep";
> > +             pinctrl-0 = <&pinctrl_sdoe_reg>;
> > +             pinctrl-1 = <&pinctrl_sdoe_reg>;
> > +             gpio = <&gpio3 27 GPIO_ACTIVE_HIGH>;
> > +             enable-active-high;
> > +     };
> > +
> >       wifi_pwrseq: wifi_pwrseq {
> >               compatible = "mmc-pwrseq-simple";
> >               pinctrl-names = "default";
> > @@ -76,6 +86,16 @@ wifi_pwrseq: wifi_pwrseq {
> >               clocks = <&clks IMX7D_CLKO2_ROOT_DIV>;
> >               clock-names = "ext_clock";
> >       };
> > +
> > +     panel {
> > +             compatible = "eink,vb3300-kca";
> > +
> > +             port {
> > +                     panel_in: endpoint {
> > +                             remote-endpoint = <&display_out>;
> > +                     };
> > +             };
> > +     };
>
> From the discussion at [1], this is not safe to merge. It exposes an
> electrophoretic display to fbcon/userspace as if it was an LCD, which it very
> much is not. Trying to write RGB pixel data to the panel could damage it.

Hey Samuel,

From what I can tell it's difficult to damage the display, but I see your point.

>
> So at the very least before hooking this up, the LCD controller has to know that
> the EPD needs special handling and that it cannot accept RGB.

Looking at [1] it seems like no decision was made about how to handle
a case like this where the EPC driving is all done in software. We
currently drive it from userspace via proprietary software. It seems
unlikely we will be able to support this in the kernel, so it would be
nice to somehow expose it to userspace.

>
> That doesn't necessarily mean there is a problem with the content of this patch
> -- the special handling may all be taken care of based on the compatible string

Ah ok. So it sounds like adding a check to the LCD controller based on
compatible string to reject RGB values would be a good start here.
That would at least block bogus values from making it to the screen

Alistair

> -- but I think it's a really bad idea to merge this with how "eink,vb3300-kca"
> is currently represented in panel-simple.
>
> Regards,
> Samuel
>
> [1]: https://lore.kernel.org/lkml/Yo5kz%2F9cSd6ewC5f@phenom.ffwll.local/
>
> >  };
> >
> >  &clks {
> > @@ -132,6 +152,20 @@ reg_epdpmic: vcom {
> >       };
> >  };
> >
> > +&lcdif {
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&pinctrl_lcdif>;
> > +     lcd-supply = <&reg_epdpmic>;
> > +     lcd2-supply = <&reg_sdoe>;
> > +     status = "okay";
> > +
> > +     port {
> > +             display_out: endpoint {
> > +                     remote-endpoint = <&panel_in>;
> > +             };
> > +     };
> > +};
> > +
> >  &snvs_pwrkey {
> >       status = "okay";
> >  };
> > @@ -246,6 +280,46 @@ MX7D_PAD_I2C4_SCL__I2C4_SCL              0x4000007f
> >               >;
> >       };
> >
> > +     pinctrl_lcdif: lcdifgrp {
> > +             fsl,pins = <
> > +                     MX7D_PAD_LCD_DATA00__LCD_DATA0          0x79
> > +                     MX7D_PAD_LCD_DATA01__LCD_DATA1          0x79
> > +                     MX7D_PAD_LCD_DATA02__LCD_DATA2          0x79
> > +                     MX7D_PAD_LCD_DATA03__LCD_DATA3          0x79
> > +                     MX7D_PAD_LCD_DATA04__LCD_DATA4          0x79
> > +                     MX7D_PAD_LCD_DATA05__LCD_DATA5          0x79
> > +                     MX7D_PAD_LCD_DATA06__LCD_DATA6          0x79
> > +                     MX7D_PAD_LCD_DATA07__LCD_DATA7          0x79
> > +                     MX7D_PAD_LCD_DATA08__LCD_DATA8          0x79
> > +                     MX7D_PAD_LCD_DATA09__LCD_DATA9          0x79
> > +                     MX7D_PAD_LCD_DATA10__LCD_DATA10         0x79
> > +                     MX7D_PAD_LCD_DATA11__LCD_DATA11         0x79
> > +                     MX7D_PAD_LCD_DATA12__LCD_DATA12         0x79
> > +                     MX7D_PAD_LCD_DATA13__LCD_DATA13         0x79
> > +                     MX7D_PAD_LCD_DATA14__LCD_DATA14         0x79
> > +                     MX7D_PAD_LCD_DATA15__LCD_DATA15         0x79
> > +
> > +                     MX7D_PAD_LCD_DATA17__LCD_DATA17         0x79
> > +                     MX7D_PAD_LCD_DATA18__LCD_DATA18         0x79
> > +                     MX7D_PAD_LCD_DATA19__LCD_DATA19         0x79
> > +                     MX7D_PAD_LCD_DATA20__LCD_DATA20         0x79
> > +                     MX7D_PAD_LCD_DATA21__LCD_DATA21         0x79
> > +
> > +                     MX7D_PAD_LCD_DATA23__LCD_DATA23         0x79
> > +                     MX7D_PAD_LCD_CLK__LCD_CLK               0x79
> > +                     MX7D_PAD_LCD_ENABLE__LCD_ENABLE         0x79
> > +                     MX7D_PAD_LCD_VSYNC__LCD_VSYNC           0x79
> > +                     MX7D_PAD_LCD_HSYNC__LCD_HSYNC           0x79
> > +                     MX7D_PAD_LCD_RESET__LCD_RESET           0x79
> > +             >;
> > +     };
> > +
> > +     pinctrl_sdoe_reg: sdoereggrp {
> > +             fsl,pins = <
> > +                     MX7D_PAD_LCD_DATA22__GPIO3_IO27         0x74
> > +             >;
> > +     };
> > +
> >       pinctrl_uart1: uart1grp {
> >               fsl,pins = <
> >                       MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX    0x79
> >
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2022-08-02 12:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25 11:55 [PATCH v21 0/4] Add support for the silergy,sy7636a Alistair Francis
2022-05-25 11:55 ` [PATCH v21 1/4] mfd: silergy,sy7636a: Add config option Alistair Francis
2022-05-25 18:03   ` Mark Brown
2022-05-26  8:30     ` Lee Jones
2022-08-09 11:28       ` Alistair Francis
2022-08-09 13:33   ` Lee Jones
2022-05-25 11:55 ` [PATCH v21 2/4] ARM: imx_v6_v7_defconfig: Enable silergy,sy7636a Alistair Francis
2022-05-25 11:55 ` [PATCH v21 3/4] ARM: dts: imx7d-remarkable2: " Alistair Francis
2022-05-25 11:55 ` [PATCH v21 4/4] ARM: dts: imx7d-remarkable2: Enable lcdif Alistair Francis
2022-05-28 18:20   ` Samuel Holland
2022-08-02 12:43     ` Alistair Francis [this message]

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=CAKmqyKPLanGCWkofWh7rEiAhpTFF865BGQNg1q-8avpObJ+J3A@mail.gmail.com \
    --to=alistair23@gmail.com \
    --cc=alistair@alistair23.me \
    --cc=amitk@kernel.org \
    --cc=andreas@kemnade.info \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=s.hauer@pengutronix.de \
    --cc=samuel@sholland.org \
    --cc=shawnguo@kernel.org \
    /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).