From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Nicolas.Ferre@microchip.com
Cc: alexandre.belloni@bootlin.com, narmstrong@baylibre.com,
agx@sigxcpu.org, dri-devel@lists.freedesktop.org,
paul@crapouillou.net, thierry.reding@gmail.com, sam@ravnborg.org,
stefan@olimex.com, tomi.valkeinen@ti.com,
Tudor.Ambarus@microchip.com, Ludovic.Desroches@microchip.com,
boris.brezillon@collabora.com, jagan@amarulasolutions.com,
robert.chiras@nxp.com, alexandre.torgue@st.com, jonas@kwiboo.se,
jsarha@ti.com, vincent.abriou@st.com, jernej.skrabec@siol.net,
kernel@puri.sm, philippe.cornu@st.com, yannick.fertre@st.com,
kieran.bingham+renesas@ideasonboard.com,
mcoquelin.stm32@gmail.com, Claudiu.Beznea@microchip.com
Subject: Re: [PATCH 1/2] drm/panel: Add and fill drm_panel type field
Date: Fri, 23 Aug 2019 14:10:13 +0300 [thread overview]
Message-ID: <20190823111013.GA5028@pendragon.ideasonboard.com> (raw)
In-Reply-To: <01887051-7cf7-cf52-65d1-85d60c3dd02c@microchip.com>
Hi Nicolas,
On Fri, Aug 23, 2019 at 07:30:07AM +0000, Nicolas.Ferre@microchip.com wrote:
> On 23/08/2019 at 03:40, Laurent Pinchart wrote:
> > Add a type field to the drm_panel structure to report the panel type,
> > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
> > eDP, DSI and DPI). This will be used to initialise the corresponding
> > connector type.
>
> With Microchip/Atmel driver, we mainly (only) use the "Unknown" type of
> connector because our hardware simply uses RGB wires in parallel.
That's called DPI (Display Pixel Interface, sometimes also referred to
as Display Parallel Interface) :-)
> Should we move to another connector type (maybe now that it's created
> and it was not, back when we chose the "Unknown" one)?
I think DRM_MODE_CONNECTOR_DPI would be best, yes.
> What would be the consequences if we move (silently?) to another type
> and particularly on the command line argument like the ones we currently
> use: "Unknown-1:800x480-16"?
That will be nasty to handle :-( As much as I'd love to ignore that
issue, I don't think we can. At the same time it shouldn't prevent us
from moving forward and exposing the real connector type. One option
could be to keep the extra type argument to drm_panel_bridge_add() to
force the connector type, and add another variant of the function that
would derive it automatically from the panel type. Drivers could then
decide to switch to the new variant on a case-by-case basis. Still, that
won't solve your issue, as I'm not sure how you would be able to decide
which variant to call if we want newer systems to expose the right panel
type while keeping backward compatibility.
Another option would be to hack the command line argument parsing to
convert Unknown-* to a panel type when there's no connector with an
unknown type, but that seems fragile.
Any other proposal ? :-)
> > Update all panel drivers to fill the new field.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-08-23 11:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-23 1:40 [PATCH 1/2] drm/panel: Add and fill drm_panel type field Laurent Pinchart
2019-08-23 1:40 ` [PATCH 2/2] drm/bridge: panel: Use drm_panel.type instead of explicit connector_type Laurent Pinchart
2019-08-23 10:04 ` Linus Walleij
2019-08-23 4:49 ` [PATCH 1/2] drm/panel: Add and fill drm_panel type field Sam Ravnborg
2019-08-23 11:28 ` Laurent Pinchart
2019-08-23 7:30 ` Nicolas.Ferre
2019-08-23 11:10 ` Laurent Pinchart [this message]
2019-08-23 11:26 ` Boris Brezillon
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=20190823111013.GA5028@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=agx@sigxcpu.org \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@st.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=jsarha@ti.com \
--cc=kernel@puri.sm \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=narmstrong@baylibre.com \
--cc=paul@crapouillou.net \
--cc=philippe.cornu@st.com \
--cc=robert.chiras@nxp.com \
--cc=sam@ravnborg.org \
--cc=stefan@olimex.com \
--cc=thierry.reding@gmail.com \
--cc=tomi.valkeinen@ti.com \
--cc=vincent.abriou@st.com \
--cc=yannick.fertre@st.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