On Fri, 23 Aug 2019 03:34:06 +0300
Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
> >
> > > +/**
> > > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > > + */
> > > +enum drm_bridge_ops {
> > > + /**
> > > + * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > > + * its output. Bridges that set this flag shall implement the
> > > + * &drm_bridge_funcs->detect callback.
> > > + */
> > > + DRM_BRIDGE_OP_DETECT = BIT(0),
> > > + /**
> > > + * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > > + * connected to its output. Bridges that set this flag shall implement
> > > + * the &drm_bridge_funcs->get_edid callback.
> > > + */
> > > + DRM_BRIDGE_OP_EDID = BIT(1),
> > > + /**
> > > + * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > > + * without requiring polling. Bridges that set this flag shall
> > > + * implement the &drm_bridge_funcs->hpd_enable and
> > > + * &drm_bridge_funcs->hpd_disable callbacks if they support enabling
> > > + * and disabling hot-plug detection dynamically.
> > > + */
> > > + DRM_BRIDGE_OP_HPD = BIT(2),
> > > + /**
> > > + * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > > + * by the display at its output. This does not include readind EDID
> > > + * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > > + * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > > + */
> > > + DRM_BRIDGE_OP_MODES = BIT(3),
> > > +};
> > > +
> > > /**
> > > * struct drm_bridge - central DRM bridge control structure
> > > */
> > > @@ -398,6 +538,33 @@ struct drm_bridge {
> > > const struct drm_bridge_funcs *funcs;
> > > /** @driver_private: pointer to the bridge driver's internal context */
> > > void *driver_private;
> > > + /** @ops: bitmask of operations supported by the bridge */
> > > + enum drm_bridge_ops ops;
> >
> > Just realized that you're not checking ->ops and ->funcs consistency at
> > attach() time (you're only checking ->ops in the tfp410 driver before
> > calling ->funcs->detect() and ->funcs->get_modes() and they might be
> > NULL).
>
> Do you think that's an issue ? I would then expect the driver to crash
> right away during development and the issue to be fixed.
I tend to add those checks to avoid random NULL pointer exceptions, but
if others are fine with this solution, I'm fine too.
>
> > > + /**
> > > + * @type: Type of the connection at the bridge output
> > > + * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > > + * identifies the type of connected display.
> > > + */
> > > + int type;
> > > + /**
> > > + * @ddc: Associated I2C adapter for DDC access, if any.
> > > + */
> > > + struct i2c_adapter *ddc;
> > > + /** private: */
> > > + /**
> > > + * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > > + */
> > > + struct mutex hpd_mutex;
> > > + /**
> > > + * @hpd_cb: Hot plug detection callback, registered with
> > > + * drm_bridge_hpd_enable().
> > > + */
> > > + void (*hpd_cb)(void *data, enum drm_connector_status status);
> > > + /**
> > > + * @hpd_data: Private data passed to the Hot plug detection callback
> > > + * @hpd_cb.
> > > + */
> > > + void *hpd_data;
> > > };
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
