devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
Cc: p.zabel@pengutronix.de, airlied@linux.ie, daniel@ffwll.ch,
	robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
	kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, alistair@alistair23.me,
	samuel@sholland.org, josua.mayer@jm0.eu,
	letux-kernel@openphoenux.org
Subject: Re: [RFC PATCH 1/6] dt-bindings: display: imx: Add EPDC
Date: Mon, 14 Mar 2022 23:04:46 +0100	[thread overview]
Message-ID: <20220314230446.5cc52121@aktux> (raw)
In-Reply-To: <YizzRKSDvHon83ks@latitude>

On Sat, 12 Mar 2022 20:23:48 +0100
Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:

> Hello Andreas,
> 
> Sorry for the delay, I finally got around to having a look at the
> patchset.
> 
> Some comments from skimming the patches below, and in my other replies.
> 
> 
> On Sun, Feb 06, 2022 at 09:00:11AM +0100, Andreas Kemnade wrote:
> > Add a binding for the Electrophoretic Display Controller found at least
> > in the i.MX6.
> > The timing subnode is directly here to avoid having display parameters
> > spread all over the plate.
> > 
> > Supplies are organized the same way as in the fbdev driver in the
> > NXP/Freescale kernel forks. The regulators used for that purpose,
> > like the TPS65185, the SY7636A and MAX17135 have typically a single bit to
> > start a bunch of regulators of higher or negative voltage with a
> > well-defined timing. VCOM can be handled separately, but can also be
> > incorporated into that single bit.
> > 
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> >  .../bindings/display/imx/fsl,mxc-epdc.yaml    | 159 ++++++++++++++++++
> >  1 file changed, 159 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > new file mode 100644
> > index 000000000000..7e0795cc3f70
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > @@ -0,0 +1,159 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---  
> [...]
> > +  - vscan-holdoff
> > +  - sdoed-width
> > +  - sdoed-delay
> > +  - sdoez-width
> > +  - sdoez-delay
> > +  - gdclk-hp-offs
> > +  - gdsp-offs
> > +  - gdoe-offs
> > +  - gdclk-offs
> > +  - num-ce  
> 
> These parameters should perhaps have sane defaults in the driver, and be
> optional in the DT.
> 
First of all I think I should document them better (as said in an
earlier review mail)

I doubt there are sane defaults, in vendor kernels, there is typically a
definition of these parameters and a video mode per display.

> 
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/imx6sl-clock.h>
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +    epdc: epdc@20f4000 {  
> [...]
> > +
> > +        timing {
> > +                clock-frequency = <80000000>;
> > +                hactive = <1448>;
> > +                hback-porch = <16>;
> > +                hfront-porch = <102>;
> > +                hsync-len = <28>;
> > +                vactive = <1072>;
> > +                vback-porch = <4>;
> > +                vfront-porch = <4>;
> > +                vsync-len = <2>;
> > +        };
> > +    };  
> 
> The way you did it here, the timing parameters are directly under the
> EPDC node in the DT, but I wonder if it would be better to have a
> separate node for the display panel, which can then provide the timing
> parameters either in the DT or in the panel driver (selected by compatible
> string of the panel).
> 
IMHO it makes sense to store these timing parameters together with the
timing parameters from above. If that all somehow comes from a panel
driver, we need to design an interface for it. So for simplicity I
added the stuff just to the EPDC node.

Vendor kernel has this:
struct imx_epdc_fb_mode {
    struct fb_videomode *vmode;
    int vscan_holdoff;
    int sdoed_width;
    int sdoed_delay;
    int sdoez_width;
    int sdoez_delay;
    int gdclk_hp_offs;
    int gdsp_offs;
    int gdoe_offs;
    int gdclk_offs;
    int num_ce;
};

So things are basically combined here.

Regards,
Andreas

  reply	other threads:[~2022-03-14 22:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-06  8:00 [RFC PATCH 0/6] drm: EPDC driver for i.MX6 Andreas Kemnade
2022-02-06  8:00 ` [RFC PATCH 1/6] dt-bindings: display: imx: Add EPDC Andreas Kemnade
2022-02-11 15:46   ` Rob Herring
2022-02-14 22:45     ` Andreas Kemnade
2022-02-16 23:52       ` Rob Herring
2022-02-17  9:21   ` Krzysztof Kozlowski
2022-02-17 11:31     ` Andreas Kemnade
2022-02-17 11:43       ` Krzysztof Kozlowski
2022-03-12 19:23   ` Jonathan Neuschäfer
2022-03-14 22:04     ` Andreas Kemnade [this message]
2022-02-06  8:00 ` [RFC PATCH 2/6] drm: Add skeleton for EPDC driver Andreas Kemnade
2022-03-12 19:41   ` Jonathan Neuschäfer
2022-02-06  8:00 ` [RFC PATCH 3/6] drm: mxc-epdc: Add display and waveform initialisation Andreas Kemnade
2022-03-12 20:12   ` Jonathan Neuschäfer
2022-02-06  8:00 ` [RFC PATCH 4/6] drm: mxc-epdc: Add update management Andreas Kemnade
2022-03-12 20:21   ` Jonathan Neuschäfer
2022-02-06  8:00 ` [RFC PATCH 5/6] ARM: dts: imx6sll: add EPDC Andreas Kemnade
2022-02-06  8:00 ` [RFC PATCH 6/6] arm: dts: imx6sl: Add EPDC Andreas Kemnade

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=20220314230446.5cc52121@aktux \
    --to=andreas@kemnade.info \
    --cc=airlied@linux.ie \
    --cc=alistair@alistair23.me \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=j.neuschaefer@gmx.net \
    --cc=josua.mayer@jm0.eu \
    --cc=kernel@pengutronix.de \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=samuel@sholland.org \
    --cc=shawnguo@kernel.org \
    --cc=tzimmermann@suse.de \
    /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).