From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio
Date: Wed, 16 Dec 2015 17:35:30 +0000 [thread overview]
Message-ID: <5671A0E2.7000909@ti.com> (raw)
In-Reply-To: <1449753107-11410-4-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> Some displays have a reset input. To assert that the display is
> functional the reset gpio must be deasserted.
>
> Teach the driver to get and drive such a gpio accordingly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 7 +++++++
> 2 files changed, 8 insertions(+)
DT changes should be posted to devicetree@vger.kernel.org. And, I think,
the binding document changes are usually as a separate patch.
> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index a40180b05bab..1a1d8f6f884f 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -7,6 +7,7 @@ Required properties:
> Optional properties:
> - label: a symbolic name for the panel
> - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin
>
> Required nodes:
> - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 1216341a0d19..7e2f9e0813dc 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -32,6 +32,7 @@ struct panel_drv_data {
> int backlight_gpio;
>
> struct gpio_desc *enable_gpio;
> + struct gpio_desc *reset_gpio;
> };
>
> #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> if (r)
> return r;
>
> + gpiod_set_value_cansleep(ddata->reset_gpio, 0);
> gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>
> if (gpio_is_valid(ddata->backlight_gpio))
> @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> if (IS_ERR(ddata->enable_gpio))
> return PTR_ERR(ddata->enable_gpio);
>
> + ddata->reset_gpio = devm_gpiod_get_optional(&pdev->dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ddata->reset_gpio))
> + return PTR_ERR(ddata->reset_gpio);
> +
> ddata->backlight_gpio = -ENOENT;
>
> r = of_get_display_timing(node, "panel-timing", &timing);
>
This looks a bit odd to me. This only ever sets the reset gpio to 0, on
panel enable. If we never toggle the reset, it could be set to 0 at
probe time, right?
Reset is a bit tricky. I've seen panels where you have to have only a
short reset pulse (reset high, wait a short time, reset low). If you
leave the reset high, the panel draws extra power.
So I think the best we can do in a generic way is just to ensure the
reset is not asserted.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-12-16 17:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 13:11 [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display Uwe Kleine-König
2015-12-10 13:11 ` [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio Uwe Kleine-König
2015-12-16 17:35 ` Tomi Valkeinen [this message]
[not found] ` <5671A0E2.7000909-l0cyMroinI0@public.gmane.org>
2015-12-20 10:33 ` Uwe Kleine-König
2015-12-16 17:16 ` [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display Tomi Valkeinen
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=5671A0E2.7000909@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-fbdev@vger.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).