On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote: > On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > > > the vc4_hdmi driver has some custom structures to hold the data it needs to > > associate with the drm_encoder and drm_connector structures. > > > > However, it allocates them separately from the vc4_hdmi structure which > > makes it more complicated than it needs to be. > > > > Move those structures to be contained by vc4_hdmi and update the code > > accordingly. > > > > @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) > > struct drm_device *drm = dev_get_drvdata(master); > > struct vc4_dev *vc4 = drm->dev_private; > > struct vc4_hdmi *hdmi; > > - struct vc4_hdmi_encoder *vc4_hdmi_encoder; > > + struct drm_encoder *encoder; > > struct device_node *ddc_node; > > u32 value; > > int ret; > > @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) > > if (!hdmi) > > return -ENOMEM; > > > > - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder), > > - GFP_KERNEL); > > - if (!vc4_hdmi_encoder) > > - return -ENOMEM; > > - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0; > > - hdmi->encoder = &vc4_hdmi_encoder->base.base; > > - > > hdmi->pdev = pdev; > > + encoder = &hdmi->encoder.base.base; > > + encoder->base.type = VC4_ENCODER_TYPE_HDMI0; > > Wait, does this patch build? All those patches were build tested, so yep > setting struct drm_encoder->base.type = VC4_* seems very wrong, when > previously we were setting struct vc4_hdmi_encoder->base.type (struct > vc4_encoder->type). So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder. vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and vc4_encoder's base is a drm_encoder. so encoder being a drm_encoder is correct there. However, drm_encoder's base is drm_mode_object that does have a type field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just fine... Now, drm_encoder_init will then kick in and call drm_mode_object_add which will override it to a proper value and since the clock select bit in the PV is the same for both HDMI0 and HDMI1, everything works just fine... Good catch, I'll fix it. And I guess it's a good indication we don't need a separate HDMI0 and HDMI1 encoder type. > Other than this, patch 68-78 r-b. Thanks for your review! Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
