From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Peter Rosin <peda@axentia.se>
Cc: linux-kernel@vger.kernel.org, David Airlie <airlied@linux.ie>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Gustavo Padovan <gustavo@padovan.org>,
Sean Paul <seanpaul@chromium.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder
Date: Wed, 18 Apr 2018 10:41:28 +0200 [thread overview]
Message-ID: <20180418104128.6747ad47@bbrezillon> (raw)
In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se>
On Wed, 18 Apr 2018 10:02:12 +0200
Peter Rosin <peda@axentia.se> wrote:
> On 2018-04-18 09:36, Boris Brezillon wrote:
> > On Tue, 17 Apr 2018 15:10:51 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> When the of-graph points to a tda998x-compatible HDMI encoder, register
> >> as a component master and bind to the encoder/connector provided by
> >> the tda998x driver.
> >
> > Can't we do the opposite: make the tda998x driver expose its devices as
> > drm bridges. I'd rather not add another way to connect external
> > encoders (or bridges) to display controller drivers, especially since,
> > when I asked DRM maintainers/devs what was the good approach to
> > represent such external encoders they pointed me to the drm_bridge
> > interface.
>
> From the cover letter:
>
> "However, I don't know if the tilcdc driver is interfacing with the
> tda998x driver in a sane and modern way"
>
> So, which way is the future? Should bridges become components or should
> existing bridge-like components no longer be components? Are there others?
Well, what I've been told a while ago is that drm_bridge will take over
drm_encoder_slave and custom drm_encoder/drm_connector implementations
when it comes to representing bridges.
AFAIU, using the component framework to bind all elements of the
pipeline to the display controller is orthogonal to how you represent
elements in the pipeline. I mean, you could have a bridge that
registers as a component so that display controllers drivers who want
to use the component framework don't have to re-code the
component-to-bridge glue every time, and those who don't use the
component framework can still get access to the bridge.
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Peter Rosin <peda@axentia.se>
Cc: Mark Rutland <mark.rutland@arm.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Rob Herring <robh+dt@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder
Date: Wed, 18 Apr 2018 10:41:28 +0200 [thread overview]
Message-ID: <20180418104128.6747ad47@bbrezillon> (raw)
In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se>
On Wed, 18 Apr 2018 10:02:12 +0200
Peter Rosin <peda@axentia.se> wrote:
> On 2018-04-18 09:36, Boris Brezillon wrote:
> > On Tue, 17 Apr 2018 15:10:51 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> When the of-graph points to a tda998x-compatible HDMI encoder, register
> >> as a component master and bind to the encoder/connector provided by
> >> the tda998x driver.
> >
> > Can't we do the opposite: make the tda998x driver expose its devices as
> > drm bridges. I'd rather not add another way to connect external
> > encoders (or bridges) to display controller drivers, especially since,
> > when I asked DRM maintainers/devs what was the good approach to
> > represent such external encoders they pointed me to the drm_bridge
> > interface.
>
> From the cover letter:
>
> "However, I don't know if the tilcdc driver is interfacing with the
> tda998x driver in a sane and modern way"
>
> So, which way is the future? Should bridges become components or should
> existing bridge-like components no longer be components? Are there others?
Well, what I've been told a while ago is that drm_bridge will take over
drm_encoder_slave and custom drm_encoder/drm_connector implementations
when it comes to representing bridges.
AFAIU, using the component framework to bind all elements of the
pipeline to the display controller is orthogonal to how you represent
elements in the pipeline. I mean, you could have a bridge that
registers as a component so that display controllers drivers who want
to use the component framework don't have to re-code the
component-to-bridge glue every time, and those who don't use the
component framework can still get access to the bridge.
_______________________________________________
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: boris.brezillon@bootlin.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder
Date: Wed, 18 Apr 2018 10:41:28 +0200 [thread overview]
Message-ID: <20180418104128.6747ad47@bbrezillon> (raw)
In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se>
On Wed, 18 Apr 2018 10:02:12 +0200
Peter Rosin <peda@axentia.se> wrote:
> On 2018-04-18 09:36, Boris Brezillon wrote:
> > On Tue, 17 Apr 2018 15:10:51 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> When the of-graph points to a tda998x-compatible HDMI encoder, register
> >> as a component master and bind to the encoder/connector provided by
> >> the tda998x driver.
> >
> > Can't we do the opposite: make the tda998x driver expose its devices as
> > drm bridges. I'd rather not add another way to connect external
> > encoders (or bridges) to display controller drivers, especially since,
> > when I asked DRM maintainers/devs what was the good approach to
> > represent such external encoders they pointed me to the drm_bridge
> > interface.
>
> From the cover letter:
>
> "However, I don't know if the tilcdc driver is interfacing with the
> tda998x driver in a sane and modern way"
>
> So, which way is the future? Should bridges become components or should
> existing bridge-like components no longer be components? Are there others?
Well, what I've been told a while ago is that drm_bridge will take over
drm_encoder_slave and custom drm_encoder/drm_connector implementations
when it comes to representing bridges.
AFAIU, using the component framework to bind all elements of the
pipeline to the display controller is orthogonal to how you represent
elements in the pipeline. I mean, you could have a bridge that
registers as a component so that display controllers drivers who want
to use the component framework don't have to re-code the
component-to-bridge glue every time, and those who don't use the
component framework can still get access to the bridge.
next prev parent reply other threads:[~2018-04-18 8:41 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 13:10 [PATCH v2 0/6] Add tda998x (HDMI) support to atmel-hlcdc Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-17 13:10 ` [PATCH v2 1/6] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 Peter Rosin
2018-04-17 13:10 ` [PATCH v2 1/6] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185 Peter Rosin
2018-04-17 13:10 ` [PATCH v2 2/6] dt-bindings: display: atmel: optional video-interface of endpoints Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-18 7:16 ` Boris Brezillon
2018-04-18 7:16 ` Boris Brezillon
2018-04-18 7:16 ` Boris Brezillon
2018-04-18 7:31 ` Peter Rosin
2018-04-18 7:31 ` Peter Rosin
2018-04-18 8:29 ` Boris Brezillon
2018-04-18 8:29 ` Boris Brezillon
2018-04-18 8:29 ` Boris Brezillon
2018-04-17 13:10 ` [PATCH v2 3/6] drm: of: introduce drm_of_media_bus_fmt Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-19 16:22 ` Rob Herring
2018-04-19 16:22 ` Rob Herring
2018-04-19 16:22 ` Rob Herring
2018-04-19 16:40 ` Peter Rosin
2018-04-19 16:40 ` Peter Rosin
2018-04-17 13:10 ` [PATCH v2 4/6] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-18 7:29 ` Boris Brezillon
2018-04-18 7:29 ` Boris Brezillon
2018-04-18 7:29 ` Boris Brezillon
2018-04-18 7:46 ` Peter Rosin
2018-04-18 7:46 ` Peter Rosin
2018-04-18 8:27 ` Boris Brezillon
2018-04-18 8:27 ` Boris Brezillon
2018-04-18 8:27 ` Boris Brezillon
2018-04-17 13:10 ` [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-18 7:36 ` Boris Brezillon
2018-04-18 7:36 ` Boris Brezillon
2018-04-18 7:36 ` Boris Brezillon
2018-04-18 8:02 ` Peter Rosin
2018-04-18 8:02 ` Peter Rosin
2018-04-18 8:41 ` Boris Brezillon [this message]
2018-04-18 8:41 ` Boris Brezillon
2018-04-18 8:41 ` Boris Brezillon
2018-04-17 13:10 ` [PATCH v2 6/6] drm/atmel-hlcdc: fix broken release date Peter Rosin
2018-04-17 13:10 ` Peter Rosin
2018-04-18 7:44 ` Boris Brezillon
2018-04-18 7:44 ` Boris Brezillon
2018-04-18 7:44 ` Boris Brezillon
2018-04-18 8:09 ` Peter Rosin
2018-04-18 8:09 ` Peter Rosin
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=20180418104128.6747ad47@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=airlied@linux.ie \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@free-electrons.com \
--cc=daniel.vetter@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nicolas.ferre@microchip.com \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=seanpaul@chromium.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 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.