All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] drm/panel: simple: Support reset GPIOs
Date: Mon, 16 Dec 2019 14:10:36 +0100	[thread overview]
Message-ID: <20191216141036.24c22899@xps13> (raw)
In-Reply-To: <20191216130615.qs6ub7bwqofwvhr7@gilmour.lan>

Hi Maxime,

Maxime Ripard <maxime@cerno.tech> wrote on Mon, 16 Dec 2019 14:06:15
+0100:

> Hi,
> 
> On Fri, Dec 13, 2019 at 07:13:25PM +0100, Miquel Raynal wrote:
> > The panel common bindings provide a gpios-reset property which is
> > active low by default. Let's support it in the simple driver.
> >
> > De-asserting the reset pin implies a physical high, which in turns is
> > a logic low.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> 
> The GPIOd API asks for a logical state, so it doesn't really matter
> what the polarity of the GPIO, OUT_LOW will always mean that the reset
> is deasserted (and thus, it will work even if the reset pin is active
> high).
> 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 5d487686d25c..15dd495c347d 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -110,6 +110,7 @@ struct panel_simple {
> >  	struct i2c_adapter *ddc;
> >
> >  	struct gpio_desc *enable_gpio;
> > +	struct gpio_desc *reset_gpio;
> >
> >  	struct drm_display_mode override_mode;
> >  };
> > @@ -433,12 +434,21 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> >  	if (IS_ERR(panel->supply))
> >  		return PTR_ERR(panel->supply);
> >
> > +	panel->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > +						    GPIOD_OUT_LOW);
> > +	if (IS_ERR(panel->reset_gpio)) {
> > +		err = PTR_ERR(panel->reset_gpio);
> > +		if (err != -EPROBE_DEFER)
> > +			dev_err(dev, "failed to request reset pin: %d\n", err);
> > +		return err;
> > +	}
> > +  
> 
> However, I'm wondering if it wouldn't be better to just have the
> device maintained in reset at probe (so OUT_HIGH) and moved out of
> reset during either the prepare or enable callbacks.
> 
> This is pretty much what is happening with the enable-gpios already.
> 
> Also, panels usually need to wait for a minimum time after you
> deassert the reset line. How is that dealt with?
> 
> I guess a good way to do that would be to add that duration to the
> panel description, since this is pretty much device specific.

What about the case were your Bootloader displays something and you
don't want the panel to blink ?

Right now I am just forcing the reset to be deasserted.

Thanks,
Miquèl
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH] drm/panel: simple: Support reset GPIOs
Date: Mon, 16 Dec 2019 14:10:36 +0100	[thread overview]
Message-ID: <20191216141036.24c22899@xps13> (raw)
In-Reply-To: <20191216130615.qs6ub7bwqofwvhr7@gilmour.lan>

Hi Maxime,

Maxime Ripard <maxime@cerno.tech> wrote on Mon, 16 Dec 2019 14:06:15
+0100:

> Hi,
> 
> On Fri, Dec 13, 2019 at 07:13:25PM +0100, Miquel Raynal wrote:
> > The panel common bindings provide a gpios-reset property which is
> > active low by default. Let's support it in the simple driver.
> >
> > De-asserting the reset pin implies a physical high, which in turns is
> > a logic low.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> 
> The GPIOd API asks for a logical state, so it doesn't really matter
> what the polarity of the GPIO, OUT_LOW will always mean that the reset
> is deasserted (and thus, it will work even if the reset pin is active
> high).
> 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 5d487686d25c..15dd495c347d 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -110,6 +110,7 @@ struct panel_simple {
> >  	struct i2c_adapter *ddc;
> >
> >  	struct gpio_desc *enable_gpio;
> > +	struct gpio_desc *reset_gpio;
> >
> >  	struct drm_display_mode override_mode;
> >  };
> > @@ -433,12 +434,21 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> >  	if (IS_ERR(panel->supply))
> >  		return PTR_ERR(panel->supply);
> >
> > +	panel->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > +						    GPIOD_OUT_LOW);
> > +	if (IS_ERR(panel->reset_gpio)) {
> > +		err = PTR_ERR(panel->reset_gpio);
> > +		if (err != -EPROBE_DEFER)
> > +			dev_err(dev, "failed to request reset pin: %d\n", err);
> > +		return err;
> > +	}
> > +  
> 
> However, I'm wondering if it wouldn't be better to just have the
> device maintained in reset at probe (so OUT_HIGH) and moved out of
> reset during either the prepare or enable callbacks.
> 
> This is pretty much what is happening with the enable-gpios already.
> 
> Also, panels usually need to wait for a minimum time after you
> deassert the reset line. How is that dealt with?
> 
> I guess a good way to do that would be to add that duration to the
> panel description, since this is pretty much device specific.

What about the case were your Bootloader displays something and you
don't want the panel to blink ?

Right now I am just forcing the reset to be deasserted.

Thanks,
Miquèl

  reply	other threads:[~2019-12-17 10:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 18:13 [PATCH] drm/panel: simple: Support reset GPIOs Miquel Raynal
2019-12-13 18:13 ` Miquel Raynal
2019-12-14 10:23 ` Sam Ravnborg
2019-12-14 10:23   ` Sam Ravnborg
2019-12-16 10:53   ` Miquel Raynal
2019-12-16 10:53     ` Miquel Raynal
2019-12-16 13:06 ` Maxime Ripard
2019-12-16 13:06   ` Maxime Ripard
2019-12-16 13:10   ` Miquel Raynal [this message]
2019-12-16 13:10     ` Miquel Raynal
2019-12-16 13:27     ` Maxime Ripard
2019-12-16 13:27       ` Maxime Ripard
2019-12-16 13:48       ` Miquel Raynal
2019-12-16 13:48         ` Miquel Raynal

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=20191216141036.24c22899@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=maxime@cerno.tech \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=sam@ravnborg.org \
    --cc=thierry.reding@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.