[Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison
Daniel Vetter
daniel at ffwll.ch
Wed Apr 13 10:06:02 UTC 2016
On Tue, Apr 05, 2016 at 03:10:39PM +0530, Ramalingam C wrote:
>
> On Tuesday 05 April 2016 02:00 PM, Jani Nikula wrote:
> >On Mon, 04 Apr 2016, Ramalingam C <ramalingam.c at intel.com> wrote:
> >>On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote:
> >>>On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote:
> >>>>On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote:
> >>>>>On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote:
> >>>>>>At BXT DSI, PIPE registers are inactive. So we can't get the
> >>>>>>PIPE's mode parameters from them. The possible option is
> >>>>>>retriving them from the PORT registers. But mode timing
> >>>>>>parameters are progammed to port registers interms of byteclocks.
> >>>>>>
> >>>>>>The formula used to convert the pixels interms of byteclk is
> >>>>>> DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
> >>>>>> 8 * 100), lane_count);
> >>>>>>
> >>>>>>So we retrieve them, interms of pixels as
> >>>>>> DIV_ROUND_UP((clk_hs * lane_count * 8 * 100),
> >>>>>> (bpp * burst_mode_ratio));
> >>>>>>
> >>>>>>Due to the multiple DIV_ROUND_UP in both formulas we get the worst
> >>>>>>case delta in the retrieved PIPE's timing parameter as below
> >>>>>> DIV_ROUND_UP((8 * intel_dsi->lane_count * 100),
> >>>>>> (dsi_pixel_format_bpp(intel_dsi->pixel_format) *
> >>>>>> intel_dsi->burst_mode_ratio)))
> >>>>>>
> >>>>>>This converson of byteclk to pixel is required for hsync, hfp and hbp.
> >>>>>>Which intern impacts horrizontal timing parameters. At worst case to
> >>>>>>get htotal all there parameters are added with hactive.
> >>>>>>Hence delta will be 3 times of above formula. Hence this value is
> >>>>>>considered as tolerance for pipe_config comparison, in case of BXT DSI.
> >>>>>>
> >>>>>>Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
> >>>>>This is the wrong way round imo, better would be to adjust the adjusted
> >>>>>mode in the bxt dsi compute_config function to match the hw granularity.
> >>>>>Stuff _really_ should match exactly, the fuzzy clock matching is mostly
> >>>>>because our clock cod is a mess, and we can't/don't properly
> >>>>>forward-compuate the actual clock timings we program into the hardware.
> >>>>>-Daniel
> >>>>Daniel, I got your point. But the problem will be that difficulty(even if
> >>>>possible) in adjusting the adjusted mode parameters.
> >>>>Reason is we are not programing the mode parameter as such. We will derive
> >>>>the hfp, hsync and hbp from
> >>>>hsync_start, hsync_end, hdisplay and htotal. These will be adjusted(divided
> >>>>by 2) for dual link scenario.
> >>>>And then resultant will go into the conversion as mentioned in the commit
> >>>>message (two DIV_ROUND_UP onwards
> >>>>and one DIV_ROUND_UP backwards). For this we have to make the parameter
> >>>>divisible by three different factors.
> >>>>So IMHO, even if this is possible, it will look more messy.
> >>>>
> >>>>Predicting the max error and tolerating it in pipe_config_compare will be
> >>>>the straight forward and more reasonable.
> >>>>Please let me know if i can go ahead in this approach.
> >>>Yeah I discussed this some more with Jani on irc. I'd say we should store
> >>>this adjusted horizontal timings (the ones fudged with burst_mode_ratio,
> >>>lane_count, dual-link and all these things applied) into
> >>>crtc_state->base.adjusted_mode. And then ofc also read those values out.
> >>>
> >>>The overall idea of the state verify/compare logic is that we start out
> >>>with requested state from userspace, then derive the real hw state. And
> >>>then compare that computed hw state with what's there already. Except for
> >>>clocks, where there's special reasons, we never go back, since going back
> >>>requires us to apply a range. This is the only way to guarnatee that "hw
> >>>has the same exact mode programmed in both cases" iff "intel_crtc_state
> >>>matches per intel_crtc_config_compare".
> >>>
> >>>state->adjusted_mode is never exposed to userspace, so there's no problem
> >>>if it's has "strange" values. And we already have pipe_src_h/w to express
> >>>the logical input rectangle.
> >>>
> >>>The idea is similar to how we set adjusted_mode.flags to what we actually
> >>>program, instead of trying to make something up that's not perfectly
> >>>accurate.
> >>>-Daniel
> >>Daniel,
> >>
> >>I have tested by adjusting the adjusted_mode in set_dsi_timings()
> >>instead of intel_dsi_compute_config().
> >>Reason is if we modify the adjusted mode at intel_dsi_compute_config()
> >>itself, then modified value will
> >>be taken as input for set_dsi_timings. Hence the get_config will deviate
> >>further. I hope this should be fine with you and Jani.
> >>
> >>This will work out, if set_dsi_timings() is called after the
> >>dsi_compute_config() on every suspend and resume or modeset.
> >>I will verify this on Android once and update.
> >>
> >>Please share your view on this, so that can update the patch with
> >>corresponding changes.
> >I can't speak for Daniel, but I think his point was to update adjusted
> >mode in ->compute_config() in a way that can be used directly in
> >set_dsi_timings(). Then, it should be possible to read the timings from
> >the hardware, and compare.
>
> No, thats not possible jani. I think i didn't elaborate the problem
> statement enough.
> If you can read the programmed value from the hardware without any error,
> then there is no need for this patch itself.
>
> Even if we program the modified adjusted mode, timing parameters read from
> get_config() will not be same as of modified adjusted mode.
>
> In BXT DSI only available hw registers doesn't provide all timing parameters
> in terms of pixels but txbyteclkhs.
> adjusted mode has the parameters(start and end of hsync, htotal and hdisplay
> and others) in terms of pixels.
Then fix adjusted_mode to have the timings in terms of txbyteclkhs
already. Problem solved.
-Daniel
> So some conversion involved in programming few parameters (hfp, hsync and
> hbp) and also in retrieving them.
>
> As discussed above port registers expects hfp, hsync and hbp interms of
> txbyteclkhs.
>
> Sequence of programing (set_dsi_timings) the dsi port registers:
> parameters from mode ---> (calc hfp, hsync and hbp) ---> (adjust for dual
> link) ----> (conversion of Pixels to txbyteclkhs) ---> Program to Port
> register
>
> Sequence of get_config():
> Read from port register ---> (conversion of txbyteclkhs to Pixels) --->
> (adjust for dual link) ---> (recalculate the adjusted mode parameters from
> hfp, hsync and hbp and other readings)
>
> Here if we assume the input to the set_dsi_timings is X(adjusted mode
> parameter), output of get_config() will be (X + delta1).
> Here delta1 is error due to multiple DIV_ROUND_UP() in the conversion of
> bytes <===> txbyteclkhs.
> So as daniel says if you modify the adjusted_mode in compute_config()
> itself, input to the set_dsi_timings() will become (X + delta1)
> and the readings from the get_config() will become (X + delta1 + delta2)
>
> And it wouldn't be appropriate to program the hw with modified adjusted
> mode. This modification is just to match it with the pipe_config read from
> hw.
> Hence adjusted mode can be modified after the hw programming only, so the
> place to do is end of set_dsi_timings().
>
> Hope I explained the situation enough.
>
> >
> >BR,
> >Jani.
> >
> >
> >>>>>>---
> >>>>>>Reviewed at https://lists.freedesktop.org/archives/intel-gfx/2016-March/089548.html
> >>>>>>
> >>>>>> drivers/gpu/drm/i915/intel_display.c | 62 +++++++++++++++++++++++++++++++---
> >>>>>> 1 file changed, 57 insertions(+), 5 deletions(-)
> >>>>>>
> >>>>>>diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>index c0627d6..282f036 100644
> >>>>>>--- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>@@ -12557,6 +12557,9 @@ intel_pipe_config_compare(struct drm_device *dev,
> >>>>>> bool adjust)
> >>>>>> {
> >>>>>> bool ret = true;
> >>>>>>+ struct intel_crtc *crtc = to_intel_crtc(current_config->base.crtc);
> >>>>>>+ struct intel_encoder *intel_encoder;
> >>>>>>+ struct intel_dsi *intel_dsi = NULL;
> >>>>>> #define INTEL_ERR_OR_DBG_KMS(fmt, ...) \
> >>>>>> do { \
> >>>>>>@@ -12593,6 +12596,54 @@ intel_pipe_config_compare(struct drm_device *dev,
> >>>>>> ret = false; \
> >>>>>> }
> >>>>>>+/*
> >>>>>>+ * In case of BXT DSI, HW pipe_config will be retrieved from the port's timing
> >>>>>>+ * configuration. This retrival includes some errors due to the DIV_ROUND_UP.
> >>>>>>+ * So we are considering the max possible error at the comparison.
> >>>>>>+ */
> >>>>>>+/*
> >>>>>>+ * htotal = hactive + hfp + hsync + hbp. Here last three lements might have
> >>>>>>+ * the converson error, hence we consider the 3 times of error as tolerance.
> >>>>>>+ */
> >>>>>>+
> >>>>>>+#define MAX_BXT_DSI_TIMING_RETRIVAL_ERR \
> >>>>>>+ (intel_dsi == NULL ? 0 : \
> >>>>>>+ DIV_ROUND_UP((3 * 8 * intel_dsi->lane_count * 100), \
> >>>>>>+ (dsi_pixel_format_bpp(intel_dsi->pixel_format) * \
> >>>>>>+ intel_dsi->burst_mode_ratio)))
> >>>>>>+
> >>>>>>+#define BXT_DSI_PIPE_CONF_CHECK_I_RANGE(name) { \
> >>>>>>+ for_each_encoder_on_crtc(dev, &crtc->base, \
> >>>>>>+ intel_encoder) { \
> >>>>>>+ if (intel_encoder->type == INTEL_OUTPUT_DSI) { \
> >>>>>>+ intel_dsi = enc_to_intel_dsi(&intel_encoder->base); \
> >>>>>>+ } \
> >>>>>>+ } \
> >>>>>>+ if (!(current_config->name < pipe_config->name && \
> >>>>>>+ current_config->name >= (pipe_config->name - \
> >>>>>>+ MAX_BXT_DSI_TIMING_RETRIVAL_ERR))) { \
> >>>>>>+ INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
> >>>>>>+ "(expected %i, found %i(Err tolerance considered))\n", \
> >>>>>>+ current_config->name, \
> >>>>>>+ pipe_config->name); \
> >>>>>>+ ret = false; \
> >>>>>>+ } \
> >>>>>>+}
> >>>>>>+
> >>>>>>+#define PIPE_CONF_CHECK_I_RANGE(name) { \
> >>>>>>+ if (current_config->name != pipe_config->name) { \
> >>>>>>+ if (IS_BROXTON(dev) && crtc->config->has_dsi_encoder) { \
> >>>>>>+ BXT_DSI_PIPE_CONF_CHECK_I_RANGE(name) \
> >>>>>>+ } else { \
> >>>>>>+ INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
> >>>>>>+ "(expected %i, found %i)\n", \
> >>>>>>+ current_config->name, \
> >>>>>>+ pipe_config->name); \
> >>>>>>+ ret = false; \
> >>>>>>+ } \
> >>>>>>+ } \
> >>>>>>+}
> >>>>>>+
> >>>>>> #define PIPE_CONF_CHECK_M_N(name) \
> >>>>>> if (!intel_compare_link_m_n(¤t_config->name, \
> >>>>>> &pipe_config->name,\
> >>>>>>@@ -12697,11 +12748,11 @@ intel_pipe_config_compare(struct drm_device *dev,
> >>>>>> PIPE_CONF_CHECK_I(has_dsi_encoder);
> >>>>>> PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hdisplay);
> >>>>>>- PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_htotal);
> >>>>>>- PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hblank_start);
> >>>>>>- PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hblank_end);
> >>>>>>- PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hsync_start);
> >>>>>>- PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hsync_end);
> >>>>>>+ PIPE_CONF_CHECK_I_RANGE(base.adjusted_mode.crtc_htotal);
> >>>>>>+ PIPE_CONF_CHECK_I_RANGE(base.adjusted_mode.crtc_hblank_start);
> >>>>>>+ PIPE_CONF_CHECK_I_RANGE(base.adjusted_mode.crtc_hblank_end);
> >>>>>>+ PIPE_CONF_CHECK_I_RANGE(base.adjusted_mode.crtc_hsync_start);
> >>>>>>+ PIPE_CONF_CHECK_I_RANGE(base.adjusted_mode.crtc_hsync_end);
> >>>>>> PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_vdisplay);
> >>>>>> PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_vtotal);
> >>>>>>@@ -12779,6 +12830,7 @@ intel_pipe_config_compare(struct drm_device *dev,
> >>>>>> #undef PIPE_CONF_CHECK_X
> >>>>>> #undef PIPE_CONF_CHECK_I
> >>>>>>+#undef PIPE_CONF_CHECK_I_RANGE
> >>>>>> #undef PIPE_CONF_CHECK_P
> >>>>>> #undef PIPE_CONF_CHECK_I_ALT
> >>>>>> #undef PIPE_CONF_CHECK_FLAGS
> >>>>>>--
> >>>>>>1.7.9.5
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Intel-gfx mailing list
> >>>>>>Intel-gfx at lists.freedesktop.org
> >>>>>>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>>>--
> >>>>Thanks,
> >>>>--Ram
> >>>>
>
> --
> Thanks,
> --Ram
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list