Re: [PATCH 1/7] ARM: dts: imx: keep the SY7636A VCOM on

From: Alistair

Date: Tue Nov 10 2026 - 18:59:18 EST


On Tue, 2026-11-10 at 10:34 +0100, Andreas Kemnade wrote:
> On Tue, 10 Nov 2026 15:23:03 +1000
> Alistair <alistair@xxxxxxxxxxxxx> wrote:
>
> > On Mon, 2026-10-26 at 08:30 +0100, Andreas Kemnade wrote:
> > > On Mon, 26 Oct 2026 00:39:12 +0000
> > > Pablo Mazzini <pmazzini@xxxxxxxxx> wrote:
> > >  
> > > > The SY7636A hwmon driver turns VCOM on at probe. The reMarkable
> > > > 2,
> > > > Kobo
> > > > Libra H2O and Tolino Vision 5 have had the rails on so far.
> > > > Mark
> > > > VCOM
> > > > always-on before the driver stops doing it.
> > > >
> > > > Signed-off-by: Pablo Mazzini <pmazzini@xxxxxxxxx>
> > > > ---
> > > >  arch/arm/boot/dts/nxp/imx/e70k02.dtsi           | 1 +
> > > >  arch/arm/boot/dts/nxp/imx/imx7d-remarkable2.dts | 1 +
> > > >  2 files changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/nxp/imx/e70k02.dtsi
> > > > b/arch/arm/boot/dts/nxp/imx/e70k02.dtsi
> > > > index dc7ff108aa85..bd9c6c6fa117 100644
> > > > --- a/arch/arm/boot/dts/nxp/imx/e70k02.dtsi
> > > > +++ b/arch/arm/boot/dts/nxp/imx/e70k02.dtsi
> > > > @@ -154,6 +154,7 @@ sy7636: pmic@62 {
> > > >   regulators {
> > > >   reg_epdpmic: vcom {
> > > >   regulator-name = "vcom";
> > > > + regulator-always-on;
> > > >   };
> > > >   };
> > > >   }; 
> > > No, please not. That regulator is in practice used with a not yet
> > > upstreamed
> > > driver for the EPDC on that platform used to deal with the
> > > current
> > > kernels
> > > fp9931 / tps65185 drivers. So it is very welcome to have it not
> > > always turned
> > > on.
> > >
> > >  
> > > > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-remarkable2.dts
> > > > b/arch/arm/boot/dts/nxp/imx/imx7d-remarkable2.dts
> > > > index ff9d50942884..6cf5603c0752 100644
> > > > --- a/arch/arm/boot/dts/nxp/imx/imx7d-remarkable2.dts
> > > > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-remarkable2.dts
> > > > @@ -327,6 +327,7 @@ sy7636a: pmic@62 {
> > > >   regulators {
> > > >   reg_epdpmic: vcom {
> > > >   regulator-name = "vcom";
> > > > + regulator-always-on;
> > > >   regulator-boot-on;
> > > >   };
> > > >   }; 
> > >
> > >
> > > Here the situation is a bit different. If I remember correctly,
> > > there
> > > is some special EPD logic in userspace on top of some ordinary
> > > kernel
> > > display driver. But thesse things are missing is devicetree?!
> > > But 
> >
> > Yeah, the kernel just exposes a framebuffer and a special secret
> > sauce
> > userspace program writes to that.
>
> Looking at that processor. It seems to have an EPDC like the i.MX6
> has.

It has been awhile since I looked at this, but from memory the display
isn't connected to the EPDC. It's connected like a normal (non-eInk)
display. Which is why it needs special userspace software

> Looking even further. The Kobo factory kernel for i.MX6SLL devices
> specifies
> fsl,imx7d-epdc as compatible for that.
> So if your display is just connected to that EPDC, then you could
> probably
> wire up things on top of my EPDC driver with DRM interface.

I remember that it isn't that simple

>
> So you still too need to run your own fork for the display?

Yep, it needs a custom kernel (with the FB display driver in the
kernel) and then a custom userspace.

At the time there didn't seem to be anyway around that. I haven't
looked in a few years, but short of reverse engineering their userspace
(which would be easier to do today) there isn't much to do.

Alistair

>
> >
> > > that might need to learn to deal with regulator
> > > enabling/disabling.
> > >
> > > Regulator always on is probably not desired here, either. 
> >
> > Yeah, I **think** we don't need that
> >
> You just need to add logic to enable/disable the regulator (if it is
> not
> wired up yet). But it is nothing from the perspective of mainline to
> worry
> about.
>
> Regards,
> Andreas