All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: Re: New LCD connector type?
Date: Mon, 09 May 2016 23:07:53 +0300	[thread overview]
Message-ID: <2122267.mZIt9xFc1I@avalon> (raw)
In-Reply-To: <20160509120721.GJ4329@intel.com>

Hi Ville,

On Monday 09 May 2016 15:07:21 Ville Syrjälä wrote:
> On Mon, May 09, 2016 at 02:43:02PM +0300, Laurent Pinchart wrote:
> > On Saturday 07 May 2016 21:11:23 Ville Syrjälä wrote:
> >> On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote:
> >>> (Resending as I couldn't find this message from January in the list
> >>> archives.)
> >>> 
> >>> Hello.
> >>> 
> >>> We have a board which has Newhaven Display LCD [1] connected via a
> >>> what seems to be a custom 40-signal LCD connector. That connector
> >>> includes (6-bit per component) RGB signals, DISP, H/VSYNC, and the
> >>> pixel clock signals; in addition, there are I2C and IRQ signals.
> >>> 
> >>> Now we need to add support for this kind of connector to the R-Car DU
> >>> driver in order to get the LCD panel resolution from the device tree
> >>> (see drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so
> >>> we'd probably need a new DRM_MODE_CONNECTOR_* constant in
> >>> include/uapi/drm/drm_mode.h in order to do that... Laurent advised me
> >>> to ask for the opinions on the dri-devel mailing list first, which I'm
> >>> doing. :-)
> >> 
> >> I'd just make it LVDS.
> > 
> > Even if the connector doesn't carry LVDS signals ?
> 
> No one should really have to care about such details for any purely
> internal connector. IMO the fact that the thing we have is called
> LVDS could be considered a historical accident.
> 
> We do have eDP and DSI types too though, which I might not have even
> bothered to add myself. These days eDP does make some sense as we expose
> the AUX ch via /dev so eDP vs. other internal connectors does have some
> user visible difference at least. And I guess you could justify DSI by
> the fact that it's a widely used standard.
>
> If people feel anal about this, I guess you could always add some kind
> of generic internal connector type to account for everything that isn't
> LVDS/eDP/DSI. But a new type means that you'll have to modify userspace
> to deal with the new connector type, at least if you want to name the
> connector based on its type (which is the norm).

I don't have a too strong opinion on the topic, but given that we've added a 
few connector types semi-randomly (or at least without giving it too much 
thoughts, as you described as "historical accident") I think we should at 
least decide what we want connector types to represent.

For instance, on the topic of DSI, what could have been more interesting than 
the physical protocol is whether the panel supports command mode and partial 
updates, but the DSI connector type doesn't tell anything about that except 
hinting that command mode could be supported.

If the connector type is solely used to describe the shape of the user-
accessible connector then I agree than an "internal connector" type could have 
covered LVDS, DPI and DSI (as well as DBI and possibly eDP). One of the 
question is whether it could be useful to convey more information than that to 
userspace.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-05-09 20:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06 19:01 New LCD connector type? Sergei Shtylyov
2016-05-07 18:11 ` Ville Syrjälä
2016-05-09 11:43   ` Laurent Pinchart
2016-05-09 12:07     ` Ville Syrjälä
2016-05-09 20:07       ` Laurent Pinchart [this message]
2016-05-10  7:03         ` Daniel Vetter
2016-05-09 18:09 ` Eric Anholt

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=2122267.mZIt9xFc1I@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=ville.syrjala@linux.intel.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.