On Wed, Oct 29, 2014 at 02:42:29PM +0100, Thierry Reding wrote: > On Wed, Oct 22, 2014 at 11:45:23AM +0530, sonika.jindal@xxxxxxxxx wrote: > > From: Sonika Jindal <sonika.jindal@xxxxxxxxx> > > > > v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set (Satheesh) > > > > v3: Moving the utility function to drm_dp_helper (Daniel) > > > > Signed-off-by: Sonika Jindal <sonika.jindal@xxxxxxxxx> > > --- > > drivers/gpu/drm/drm_dp_helper.c | 15 +++++++++++++++ > > include/drm/drm_dp_helper.h | 2 ++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > > index 08e33b8..a54a760 100644 > > --- a/drivers/gpu/drm/drm_dp_helper.c > > +++ b/drivers/gpu/drm/drm_dp_helper.c > > @@ -768,3 +768,18 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux) > > i2c_del_adapter(&aux->ddc); > > } > > EXPORT_SYMBOL(drm_dp_aux_unregister); > > + > > +bool drm_dp_is_edp_v1_4(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE]) > > I'd prefer if this didn't take a dpcd argument but rather directly > accessed the DP_EDP_CONFIGURATION_CAP register so that it can be used > directly rather than rely on the driver to have read a dpcd block in the > appropriate format. The idea is that you'd grab the DPCD field anyway since it's needed all over the place. We have a pile of helpers already that take exactly this block and decode parts of it. So I think this makes sense - dp aux is fast but not entirely free, so caching seems useful. It's a bit strange then that this helper reads more code, but I guess you really only care about the edp_rev field if you want the edp revision, and with your interface suggestion I don't think we'd ever need to read this again. So for me the input fields make sense. I agree that for the output of the function an enum with all the edp revisions is better. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
