From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <a0393947@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver
Date: Fri, 24 Aug 2012 06:28:36 +0000 [thread overview]
Message-ID: <1345789716.9287.8.camel@lappyti> (raw)
In-Reply-To: <50371899.6030706@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
On Fri, 2012-08-24 at 11:30 +0530, Archit Taneja wrote:
> On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
> > We currently manage HDMI GPIOs in the board files via
> > platform_enable/disable calls. This won't work with device tree, and in
> > any case the correct place to manage the GPIOs is in the HDMI driver.
> >
> > This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
> > handling is moved to the common hdmi.c file, and this probably needs to
> > be revisited when adding OMAP5 HDMI support to see if the GPIO handling
> > needs to be moved to IP specific files.
<snip>
> > static int __init hdmi_init_display(struct omap_dss_device *dssdev)
> > {
> > + int r;
> > +
> > + struct gpio gpios[] = {
> > + { hdmi.ct_cp_hpd_gpio, GPIOF_OUT_INIT_LOW, "hdmi_ct_cp_hpd" },
> > + { hdmi.ls_oe_gpio, GPIOF_OUT_INIT_LOW, "hdmi_ls_oe" },
> > + { hdmi.hpd_gpio, GPIOF_DIR_IN, "hdmi_hpd" },
> > + };
> > +
> > DSSDBG("init_display\n");
> >
> > dss_init_hdmi_ip_ops(&hdmi.ip_data);
> > +
> > + r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
> > + if (r)
> > + return r;
> > +
>
> Is there a reason to request these gpios in hdmi_init_display()? Why
> can't these be requested simply in the probe of the hdmi platform
> device. These gpios are sort of specific to the hdmi output on OMAP,
> aren't they?
Well, it is a bit ugly, agreed. But I'm not sure it can be helped
easily.
First, the struct omap_dss_hdmi_data where the gpios are passed from
board file, is really "panel" platform data. I.e. it's attached to the
hdmi dssdev, and thus we can't handle it in hdmi output driver's probe,
as we don't have dssdevs there.
Second, the gpios are actually not OMAP HDMI stuff. They belong to the
tpd12s015 chip, sitting between OMAP HDMI output and the HDMI connector,
which is the ESD/level shifter/whatnot (I don't remember exactly what it
does =). So making the GPIOs a property of the OMAP HDMI device wouldn't
be right either.
tpd12s015 is rather simple chip, but it still has the gpios and require
special handling. I think the only way to properly handle this would be
to have a chain of external display devices, and the tpd12s015 would be
handled by a separate driver. Until then, the gpio handling is quite
hacky.
We could move the gpios to omapdss's platform data, but it would still
be wrong, and I'm not sure if it'd be any cleaner hack.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-24 6:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-23 13:45 [PATCH 0/8] OMAPDSS: Misc improvements Tomi Valkeinen
2012-08-23 13:45 ` [PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver Tomi Valkeinen
2012-08-24 6:12 ` Archit Taneja
2012-08-24 6:28 ` Tomi Valkeinen [this message]
2012-09-07 16:21 ` Tony Lindgren
2012-08-23 13:45 ` [PATCH 2/8] OMAPDSS: HDMI: Add delay to wait for 5V power Tomi Valkeinen
2012-08-23 13:45 ` [PATCH 3/8] OMAP4: TWL: add vdda_hdmi_dac regulator supply Tomi Valkeinen
2012-09-06 20:12 ` Tony Lindgren
2012-08-23 13:45 ` [PATCH 4/8] OMAPDSS: HDMI: use vdda_hdmi_dac Tomi Valkeinen
2012-08-24 6:32 ` Archit Taneja
2012-08-24 6:41 ` Tomi Valkeinen
2012-08-23 13:45 ` [PATCH 5/8] OMAPDSS: Add DSI fclk maximum to dss_features Tomi Valkeinen
2012-08-23 13:45 ` [PATCH 6/8] OMAPDSS: DSI: calculate dsi clock Tomi Valkeinen
2012-08-24 6:28 ` Archit Taneja
2012-08-24 8:55 ` Tomi Valkeinen
2012-08-24 9:29 ` Archit Taneja
2012-08-23 13:45 ` [PATCH 7/8] OMAP: 4430SDP: remove DSI clock config from board file Tomi Valkeinen
2012-09-06 20:11 ` Tony Lindgren
2012-08-23 13:45 ` [PATCH 8/8] OMAPDSS: fix use of dssdev->caps Tomi Valkeinen
2012-08-24 5:52 ` Archit Taneja
2012-09-04 7:22 ` [PATCH 0/8] OMAPDSS: Misc improvements Tomi Valkeinen
2012-09-06 20:13 ` Tony Lindgren
2012-09-07 10:16 ` Tomi Valkeinen
2012-09-07 16:22 ` Tony Lindgren
2012-09-07 16:59 ` 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=1345789716.9287.8.camel@lappyti \
--to=tomi.valkeinen@ti.com \
--cc=a0393947@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.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 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).