Hi Laurent,
On Mon, Jul 30, 2018 at 05:12:15PM +0300, Laurent Pinchart wrote:
> Hi Tomi,
>
> (CC'ing Jacopo Mondi for a comment about bus_formats in bridge drivers)
thanks for CC'ing me
>
> Thank you for the patch.
>
> On Monday, 18 June 2018 16:22:37 EEST Tomi Valkeinen wrote:
> > This patch adds a new DRM driver for Texas Instruments DSS6 IP used on
> > Texas Instruments Keystone K2G SoC. The DSS6 IP is a major change to the
> > older DSS IP versions, which are supported by the omapdrm driver, and
> > while on higher level the DSS6 resembles the older DSS versions, the
> > registers and the internal pipelines differ a lot.
> >
> > DSS6 IP on K2G is a "ultra-light" version, and has only a single plane
> > and a single output. The driver will also support future DSS versions,
> > which support multiple planes and outputs, so the driver already has
> > support for those.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
> > ---
[snip]
>
> > +static int tidss_encoder_atomic_check(struct drm_encoder *encoder,
> > + struct drm_crtc_state *crtc_state,
> > + struct drm_connector_state *conn_state)
> > +{
> > + struct drm_device *ddev = encoder->dev;
> > + struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
> > + struct drm_display_info *di = &conn_state->connector->display_info;
> > +
> > + dev_dbg(ddev->dev, "%s\n", __func__);
> > +
> > + // XXX any cleaner way to set bus format and flags?
>
> Not that I know of :-/ Jacopo (CC'ed) started working on support for bus
> formats in bridge drivers, which you might be interested in.
For reference the series Laurent's talking about is:
https://lkml.org/lkml/2018/4/19/143
with these bits being the most relevant ones:
[add DRM bridge helper to store the bus format]
https://lkml.org/lkml/2018/4/19/164
[make use of those helpers in a bridge device]
https://lkml.org/lkml/2018/4/19/161
For my understanding of issue here, more than a requirement for
storing bus formats in bridges (the code here goes directly to the
connector format) this is another driver betting on the first
available media format reported by the next DRM pipeline component
being the 'right' one.
I've seen a few DRM drivers to be honest, but most of them would
benefit from a proper format negotiation API implementation in DRM.
Maybe I've been unlucky and that's actually a corner case? :)
I tend to think it's not, but you people with more DRM experience
could tell better than me, also considering the always growing
complexity of video pipelines in embedded systems.
Thanks
j
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
