| Message ID | 46c300b3827190dbb066f1af7b9d32088f8b5542.1494492646.git.joabreu@synopsys.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11.05.2017 11:06, Jose Abreu wrote: > This changes the connector probe helper function to use the new > encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() > helper callbacks to validate the modes. > > The new callbacks are optional so the behaviour remains the same > if they are not implemented. If they are, then the code loops > through all the connector's encodersXbridgesXcrtcs and calls the > callback. > > If at least a valid encoderXbridgeXcrtc combination is found which > accepts the mode then the function returns MODE_OK. > > Signed-off-by: Jose Abreu <joabreu@synopsys.com> > Cc: Carlos Palminha <palminha@synopsys.com> > Cc: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Dave Airlie <airlied@linux.ie> > Cc: Andrzej Hajda <a.hajda@samsung.com> > Cc: Archit Taneja <architt@codeaurora.org> > --- > > Changes v2->v3: > - Call also bridge->mode_valid (Daniel) > Changes v1->v2: > - Use new helpers suggested by Ville > - Change documentation (Daniel) > > drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++++++++++++++++++++++++-- > 1 file changed, 62 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c > index f01abdc..84d660e 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -83,6 +83,61 @@ > return MODE_OK; > } > > +static enum drm_mode_status > +drm_mode_validate_connector(struct drm_connector *connector, > + struct drm_display_mode *mode) > +{ > + struct drm_device *dev = connector->dev; > + uint32_t *ids = connector->encoder_ids; > + enum drm_mode_status ret = MODE_OK; > + unsigned int i; > + > + /* Step 1: Validate against connector */ > + ret = drm_connector_mode_valid(connector, mode); > + if (ret != MODE_OK) > + return ret; > + > + /* Step 2: Validate against encoders and crtcs */ > + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]); > + struct drm_crtc *crtc; > + > + if (!encoder) > + continue; > + > + ret = drm_encoder_mode_valid(encoder, mode); > + if (ret != MODE_OK) { > + /* No point in continuing for crtc check as this encoder > + * will not accept the mode anyway. If all encoders > + * reject the mode then, at exit, ret will not be > + * MODE_OK. */ > + continue; > + } > + > + ret = drm_bridge_mode_valid(encoder->bridge, mode); > + if (ret != MODE_OK) { > + /* There is also no point in continuing for crtc check > + * here. */ > + continue; > + } Maybe it is a bikeshedding, but wouldn't be better to call drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all bridge related stuff from corresponding encoder stuff? This is more question about role of encoder->bridge, should it be treated as encoder's extension, or as 1st class citizen in drm? Another concern is about order of calls, it is from sink to source, to keep it consistent bridge should be called before encoder, am I right? Beside this: Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > + > + drm_for_each_crtc(crtc, dev) { > + if (!drm_encoder_crtc_ok(encoder, crtc)) > + continue; > + > + ret = drm_crtc_mode_valid(crtc, mode); > + if (ret == MODE_OK) { > + /* If we get to this point there is at least > + * one combination of encoder+crtc that works > + * for this mode. Lets return now. */ > + return ret; > + } > + } > + } > + > + return ret; > +} > + > static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector) > { > struct drm_cmdline_mode *cmdline_mode; > @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev) > * - drm_mode_validate_flag() checks the modes against basic connector > * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed) > * - the optional &drm_connector_helper_funcs.mode_valid helper can perform > - * driver and/or hardware specific checks > + * driver and/or sink specific checks > + * - the optional &drm_crtc_helper_funcs.mode_valid, > + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid > + * helpers can perform driver and/or source specific checks which are also > + * enforced by the modeset/atomic helpers > * > * 5. Any mode whose status is not OK is pruned from the connector's modes list, > * accompanied by a debug message indicating the reason for the mode's > @@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, > if (mode->status == MODE_OK) > mode->status = drm_mode_validate_flag(mode, mode_flags); > > - if (mode->status == MODE_OK && connector_funcs->mode_valid) > - mode->status = connector_funcs->mode_valid(connector, > + if (mode->status == MODE_OK) > + mode->status = drm_mode_validate_connector(connector, > mode); > } >
On Mon, May 15, 2017 at 10:39:35AM +0200, Andrzej Hajda wrote: > On 11.05.2017 11:06, Jose Abreu wrote: > > This changes the connector probe helper function to use the new > > encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() > > helper callbacks to validate the modes. > > > > The new callbacks are optional so the behaviour remains the same > > if they are not implemented. If they are, then the code loops > > through all the connector's encodersXbridgesXcrtcs and calls the > > callback. > > > > If at least a valid encoderXbridgeXcrtc combination is found which > > accepts the mode then the function returns MODE_OK. > > > > Signed-off-by: Jose Abreu <joabreu@synopsys.com> > > Cc: Carlos Palminha <palminha@synopsys.com> > > Cc: Alexey Brodkin <abrodkin@synopsys.com> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Dave Airlie <airlied@linux.ie> > > Cc: Andrzej Hajda <a.hajda@samsung.com> > > Cc: Archit Taneja <architt@codeaurora.org> > > --- > > > > Changes v2->v3: > > - Call also bridge->mode_valid (Daniel) > > Changes v1->v2: > > - Use new helpers suggested by Ville > > - Change documentation (Daniel) > > > > drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 62 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c > > index f01abdc..84d660e 100644 > > --- a/drivers/gpu/drm/drm_probe_helper.c > > +++ b/drivers/gpu/drm/drm_probe_helper.c > > @@ -83,6 +83,61 @@ > > return MODE_OK; > > } > > > > +static enum drm_mode_status > > +drm_mode_validate_connector(struct drm_connector *connector, > > + struct drm_display_mode *mode) > > +{ > > + struct drm_device *dev = connector->dev; > > + uint32_t *ids = connector->encoder_ids; > > + enum drm_mode_status ret = MODE_OK; > > + unsigned int i; > > + > > + /* Step 1: Validate against connector */ > > + ret = drm_connector_mode_valid(connector, mode); > > + if (ret != MODE_OK) > > + return ret; > > + > > + /* Step 2: Validate against encoders and crtcs */ > > + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > > + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]); > > + struct drm_crtc *crtc; > > + > > + if (!encoder) > > + continue; > > + > > + ret = drm_encoder_mode_valid(encoder, mode); > > + if (ret != MODE_OK) { > > + /* No point in continuing for crtc check as this encoder > > + * will not accept the mode anyway. If all encoders > > + * reject the mode then, at exit, ret will not be > > + * MODE_OK. */ > > + continue; > > + } > > + > > + ret = drm_bridge_mode_valid(encoder->bridge, mode); > > + if (ret != MODE_OK) { > > + /* There is also no point in continuing for crtc check > > + * here. */ > > + continue; > > + } > > Maybe it is a bikeshedding, but wouldn't be better to call > drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all > bridge related stuff from corresponding encoder stuff? > This is more question about role of encoder->bridge, should it be > treated as encoder's extension, or as 1st class citizen in drm? > > Another concern is about order of calls, it is from sink to source, to > keep it consistent bridge should be called before encoder, am I right? For the atomic_check stuff (where we do change the passed-in mode) this would be correct, and calling order and layering would matter. But this just validates the mode in turn with everything, not taking any cross-component constraint or other configuration-dependent constraints into account. Hence it doesn't matter in which order we call stuff. Note that the passed-in mode is const, so you can't escape. And v3 of patch 1 now has added wording that you're not allowed to look at anything else dynamie either. Does that address your concern? -Daniel > Beside this: > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> > > -- > Regards > Andrzej > > > + > > + drm_for_each_crtc(crtc, dev) { > > + if (!drm_encoder_crtc_ok(encoder, crtc)) > > + continue; > > + > > + ret = drm_crtc_mode_valid(crtc, mode); > > + if (ret == MODE_OK) { > > + /* If we get to this point there is at least > > + * one combination of encoder+crtc that works > > + * for this mode. Lets return now. */ > > + return ret; > > + } > > + } > > + } > > + > > + return ret; > > +} > > + > > static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector) > > { > > struct drm_cmdline_mode *cmdline_mode; > > @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev) > > * - drm_mode_validate_flag() checks the modes against basic connector > > * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed) > > * - the optional &drm_connector_helper_funcs.mode_valid helper can perform > > - * driver and/or hardware specific checks > > + * driver and/or sink specific checks > > + * - the optional &drm_crtc_helper_funcs.mode_valid, > > + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid > > + * helpers can perform driver and/or source specific checks which are also > > + * enforced by the modeset/atomic helpers > > * > > * 5. Any mode whose status is not OK is pruned from the connector's modes list, > > * accompanied by a debug message indicating the reason for the mode's > > @@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, > > if (mode->status == MODE_OK) > > mode->status = drm_mode_validate_flag(mode, mode_flags); > > > > - if (mode->status == MODE_OK && connector_funcs->mode_valid) > > - mode->status = connector_funcs->mode_valid(connector, > > + if (mode->status == MODE_OK) > > + mode->status = drm_mode_validate_connector(connector, > > mode); > > } > > > >
On 15.05.2017 11:30, Daniel Vetter wrote: > On Mon, May 15, 2017 at 10:39:35AM +0200, Andrzej Hajda wrote: >> On 11.05.2017 11:06, Jose Abreu wrote: >>> This changes the connector probe helper function to use the new >>> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() >>> helper callbacks to validate the modes. >>> >>> The new callbacks are optional so the behaviour remains the same >>> if they are not implemented. If they are, then the code loops >>> through all the connector's encodersXbridgesXcrtcs and calls the >>> callback. >>> >>> If at least a valid encoderXbridgeXcrtc combination is found which >>> accepts the mode then the function returns MODE_OK. >>> >>> Signed-off-by: Jose Abreu <joabreu@synopsys.com> >>> Cc: Carlos Palminha <palminha@synopsys.com> >>> Cc: Alexey Brodkin <abrodkin@synopsys.com> >>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> >>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> >>> Cc: Dave Airlie <airlied@linux.ie> >>> Cc: Andrzej Hajda <a.hajda@samsung.com> >>> Cc: Archit Taneja <architt@codeaurora.org> >>> --- >>> >>> Changes v2->v3: >>> - Call also bridge->mode_valid (Daniel) >>> Changes v1->v2: >>> - Use new helpers suggested by Ville >>> - Change documentation (Daniel) >>> >>> drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++++++++++++++++++++++++-- >>> 1 file changed, 62 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c >>> index f01abdc..84d660e 100644 >>> --- a/drivers/gpu/drm/drm_probe_helper.c >>> +++ b/drivers/gpu/drm/drm_probe_helper.c >>> @@ -83,6 +83,61 @@ >>> return MODE_OK; >>> } >>> >>> +static enum drm_mode_status >>> +drm_mode_validate_connector(struct drm_connector *connector, >>> + struct drm_display_mode *mode) >>> +{ >>> + struct drm_device *dev = connector->dev; >>> + uint32_t *ids = connector->encoder_ids; >>> + enum drm_mode_status ret = MODE_OK; >>> + unsigned int i; >>> + >>> + /* Step 1: Validate against connector */ >>> + ret = drm_connector_mode_valid(connector, mode); >>> + if (ret != MODE_OK) >>> + return ret; >>> + >>> + /* Step 2: Validate against encoders and crtcs */ >>> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { >>> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]); >>> + struct drm_crtc *crtc; >>> + >>> + if (!encoder) >>> + continue; >>> + >>> + ret = drm_encoder_mode_valid(encoder, mode); >>> + if (ret != MODE_OK) { >>> + /* No point in continuing for crtc check as this encoder >>> + * will not accept the mode anyway. If all encoders >>> + * reject the mode then, at exit, ret will not be >>> + * MODE_OK. */ >>> + continue; >>> + } >>> + >>> + ret = drm_bridge_mode_valid(encoder->bridge, mode); >>> + if (ret != MODE_OK) { >>> + /* There is also no point in continuing for crtc check >>> + * here. */ >>> + continue; >>> + } >> Maybe it is a bikeshedding, but wouldn't be better to call >> drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all >> bridge related stuff from corresponding encoder stuff? >> This is more question about role of encoder->bridge, should it be >> treated as encoder's extension, or as 1st class citizen in drm? >> >> Another concern is about order of calls, it is from sink to source, to >> keep it consistent bridge should be called before encoder, am I right? > For the atomic_check stuff (where we do change the passed-in mode) this > would be correct, and calling order and layering would matter. But this > just validates the mode in turn with everything, not taking any > cross-component constraint or other configuration-dependent constraints > into account. Hence it doesn't matter in which order we call stuff. > > Note that the passed-in mode is const, so you can't escape. And v3 of > patch 1 now has added wording that you're not allowed to look at anything > else dynamie either. > > Does that address your concern? Yes, I know it practically does not matter. I have mistakenly written "Beside this: R-b", it should be rather "Anyway: R-b" :) Regards Andrzej > -Daniel > >> Beside this: >> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> >> >> -- >> Regards >> Andrzej >> >>> + >>> + drm_for_each_crtc(crtc, dev) { >>> + if (!drm_encoder_crtc_ok(encoder, crtc)) >>> + continue; >>> + >>> + ret = drm_crtc_mode_valid(crtc, mode); >>> + if (ret == MODE_OK) { >>> + /* If we get to this point there is at least >>> + * one combination of encoder+crtc that works >>> + * for this mode. Lets return now. */ >>> + return ret; >>> + } >>> + } >>> + } >>> + >>> + return ret; >>> +} >>> + >>> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector) >>> { >>> struct drm_cmdline_mode *cmdline_mode; >>> @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev) >>> * - drm_mode_validate_flag() checks the modes against basic connector >>> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed) >>> * - the optional &drm_connector_helper_funcs.mode_valid helper can perform >>> - * driver and/or hardware specific checks >>> + * driver and/or sink specific checks >>> + * - the optional &drm_crtc_helper_funcs.mode_valid, >>> + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid >>> + * helpers can perform driver and/or source specific checks which are also >>> + * enforced by the modeset/atomic helpers >>> * >>> * 5. Any mode whose status is not OK is pruned from the connector's modes list, >>> * accompanied by a debug message indicating the reason for the mode's >>> @@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, >>> if (mode->status == MODE_OK) >>> mode->status = drm_mode_validate_flag(mode, mode_flags); >>> >>> - if (mode->status == MODE_OK && connector_funcs->mode_valid) >>> - mode->status = connector_funcs->mode_valid(connector, >>> + if (mode->status == MODE_OK) >>> + mode->status = drm_mode_validate_connector(connector, >>> mode); >>> } >>> >>
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index f01abdc..84d660e 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -83,6 +83,61 @@ return MODE_OK; } +static enum drm_mode_status +drm_mode_validate_connector(struct drm_connector *connector, + struct drm_display_mode *mode) +{ + struct drm_device *dev = connector->dev; + uint32_t *ids = connector->encoder_ids; + enum drm_mode_status ret = MODE_OK; + unsigned int i; + + /* Step 1: Validate against connector */ + ret = drm_connector_mode_valid(connector, mode); + if (ret != MODE_OK) + return ret; + + /* Step 2: Validate against encoders and crtcs */ + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]); + struct drm_crtc *crtc; + + if (!encoder) + continue; + + ret = drm_encoder_mode_valid(encoder, mode); + if (ret != MODE_OK) { + /* No point in continuing for crtc check as this encoder + * will not accept the mode anyway. If all encoders + * reject the mode then, at exit, ret will not be + * MODE_OK. */ + continue; + } + + ret = drm_bridge_mode_valid(encoder->bridge, mode); + if (ret != MODE_OK) { + /* There is also no point in continuing for crtc check + * here. */ + continue; + } + + drm_for_each_crtc(crtc, dev) { + if (!drm_encoder_crtc_ok(encoder, crtc)) + continue; + + ret = drm_crtc_mode_valid(crtc, mode); + if (ret == MODE_OK) { + /* If we get to this point there is at least + * one combination of encoder+crtc that works + * for this mode. Lets return now. */ + return ret; + } + } + } + + return ret; +} + static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector) { struct drm_cmdline_mode *cmdline_mode; @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev) * - drm_mode_validate_flag() checks the modes against basic connector * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed) * - the optional &drm_connector_helper_funcs.mode_valid helper can perform - * driver and/or hardware specific checks + * driver and/or sink specific checks + * - the optional &drm_crtc_helper_funcs.mode_valid, + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid + * helpers can perform driver and/or source specific checks which are also + * enforced by the modeset/atomic helpers * * 5. Any mode whose status is not OK is pruned from the connector's modes list, * accompanied by a debug message indicating the reason for the mode's @@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, if (mode->status == MODE_OK) mode->status = drm_mode_validate_flag(mode, mode_flags); - if (mode->status == MODE_OK && connector_funcs->mode_valid) - mode->status = connector_funcs->mode_valid(connector, + if (mode->status == MODE_OK) + mode->status = drm_mode_validate_connector(connector, mode); }
This changes the connector probe helper function to use the new encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() helper callbacks to validate the modes. The new callbacks are optional so the behaviour remains the same if they are not implemented. If they are, then the code loops through all the connector's encodersXbridgesXcrtcs and calls the callback. If at least a valid encoderXbridgeXcrtc combination is found which accepts the mode then the function returns MODE_OK. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@linux.ie> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Archit Taneja <architt@codeaurora.org> --- Changes v2->v3: - Call also bridge->mode_valid (Daniel) Changes v1->v2: - Use new helpers suggested by Ville - Change documentation (Daniel) drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 62 insertions(+), 3 deletions(-)