[Intel-gfx] [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval
Jani Nikula
jani.nikula at intel.com
Thu Apr 28 14:11:48 UTC 2016
On Wed, 27 Apr 2016, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote:
>> In BXT DSI there is no regs programmed with few horizontal timings
>> in Pixels but txbyteclkhs.. So retrieval process adds some
>> ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
>>
>> Actually here for the given adjusted_mode, we are calculating the
>> value programmed to the port and then back to the horizontal timing
>> param in pixels. This is the expected value at the end of get_config,
>> including roundup errors. And if that is same as retrieved value
>> from port, then retrieved (HW state) adjusted_mode's horizontal
>> timings are corrected to match with SW state to nullify the errors.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_dsi.c | 97 ++++++++++++++++++++++++++++++++++----
>> 1 file changed, 88 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
>> index e0259e6..8a1b872 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -46,6 +46,14 @@ static const struct {
>> },
>> };
>>
>> +/* return pixels in terms of txbyteclkhs */
>> +static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
>> + u16 burst_mode_ratio)
>> +{
>> + return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
>> + 8 * 100), lane_count);
>> +}
>> +
>> /* return pixels equvalent to txbyteclkhs */
>> static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
>> u16 burst_mode_ratio)
>> @@ -779,11 +787,19 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct drm_display_mode *adjusted_mode =
>> &pipe_config->base.adjusted_mode;
>> + struct drm_display_mode *adjusted_mode_sw;
>> + struct intel_crtc *intel_crtc;
>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>> unsigned int lane_count = intel_dsi->lane_count;
>> unsigned int bpp, fmt;
>> enum port port;
>> u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
>> + u16 hfp_sw, hsync_sw, hbp_sw;
>> + u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
>> + crtc_hblank_start_sw, crtc_hblank_end_sw;
>> +
>> + intel_crtc = to_intel_crtc(encoder->base.crtc);
>> + adjusted_mode_sw = &intel_crtc->config->base.adjusted_mode;
>>
>
>> /*
>> * Atleast one port is active as encoder->get_config called only if
>> @@ -847,8 +863,79 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
>> adjusted_mode->crtc_vsync_end = vsync + adjusted_mode->crtc_vsync_start;
>> adjusted_mode->crtc_vblank_start = adjusted_mode->crtc_vdisplay;
>> adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
>> -}
>>
>> + /*
>> + * In BXT DSI there is no regs programmed with few horizontal timings
>> + * in Pixels but txbyteclkhs.. So retrieval process adds some
>> + * ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
>> + * Actually here for the given adjusted_mode, we are calculating the
>> + * value programmed to the port and then back to the horizontal timing
>> + * param in pixels. This is the expected value, including roundup errors
>> + * And if that is same as retrieved value from port, then
>> + * (HW state) adjusted_mode's horizontal timings are corrected to
>> + * match with SW state to nullify the errors.
>> + */
>> + /* Calculating the value programmed to the Port register */
>> + hfp_sw = adjusted_mode_sw->crtc_hsync_start -
>> + adjusted_mode_sw->crtc_hdisplay;
>> + hsync_sw = adjusted_mode_sw->crtc_hsync_end -
>> + adjusted_mode_sw->crtc_hsync_start;
>> + hbp_sw = adjusted_mode_sw->crtc_htotal -
>> + adjusted_mode_sw->crtc_hsync_end;
>
> So during the initial state readout we get passed crtc->config as
> pipe_config, and so we'll end up comparing the thing with itself. That
> should be fine. A bit of extra care is needed to make sure we don't use
> anything from crtc->config before we've filled it out with something,
> but looks like the code does things in the right order (given the
> previous patch which fills out all the htimings with something).
>
> I think the biggest issue with this patch is seeing the forest from the
> trees. Some refactoring would be good so that we'd have some kind of
> htimings_{to,from}_txbyteclkhs() functions instead of duplicating the
> same code multiple times.
Agreed. However, I opted to push them as-is as they fix the boot hang,
and leave the refactoring as follow-up.
BR,
Jani.
>
> So while it does look quite strange to be using crtc->config in the
> .get_config() I think it should work out.
>
> Acked-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
>> +
>> + if (intel_dsi->dual_link) {
>> + hfp_sw /= 2;
>> + hsync_sw /= 2;
>> + hbp_sw /= 2;
>> + }
>> +
>> + hfp_sw = txbyteclkhs(hfp_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> + hsync_sw = txbyteclkhs(hsync_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> + hbp_sw = txbyteclkhs(hbp_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> +
>> + /* Reverse calculating the adjusted mode parameters from port reg vals*/
>> + hfp_sw = pixels_from_txbyteclkhs(hfp_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> + hsync_sw = pixels_from_txbyteclkhs(hsync_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> + hbp_sw = pixels_from_txbyteclkhs(hbp_sw, bpp, lane_count,
>> + intel_dsi->burst_mode_ratio);
>> +
>> + if (intel_dsi->dual_link) {
>> + hfp_sw *= 2;
>> + hsync_sw *= 2;
>> + hbp_sw *= 2;
>> + }
>> +
>> + crtc_htotal_sw = adjusted_mode_sw->crtc_hdisplay + hfp_sw +
>> + hsync_sw + hbp_sw;
>> + crtc_hsync_start_sw = hfp_sw + adjusted_mode_sw->crtc_hdisplay;
>> + crtc_hsync_end_sw = hsync_sw + crtc_hsync_start_sw;
>> + crtc_hblank_start_sw = adjusted_mode_sw->crtc_hdisplay;
>> + crtc_hblank_end_sw = crtc_htotal_sw;
>> +
>> + if (adjusted_mode->crtc_htotal == crtc_htotal_sw)
>> + adjusted_mode->crtc_htotal = adjusted_mode_sw->crtc_htotal;
>> +
>> + if (adjusted_mode->crtc_hsync_start == crtc_hsync_start_sw)
>> + adjusted_mode->crtc_hsync_start =
>> + adjusted_mode_sw->crtc_hsync_start;
>> +
>> + if (adjusted_mode->crtc_hsync_end == crtc_hsync_end_sw)
>> + adjusted_mode->crtc_hsync_end =
>> + adjusted_mode_sw->crtc_hsync_end;
>> +
>> + if (adjusted_mode->crtc_hblank_start == crtc_hblank_start_sw)
>> + adjusted_mode->crtc_hblank_start =
>> + adjusted_mode_sw->crtc_hblank_start;
>> +
>> + if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
>> + adjusted_mode->crtc_hblank_end =
>> + adjusted_mode_sw->crtc_hblank_end;
>> +}
>>
>> static void intel_dsi_get_config(struct intel_encoder *encoder,
>> struct intel_crtc_state *pipe_config)
>> @@ -917,14 +1004,6 @@ static u16 txclkesc(u32 divider, unsigned int us)
>> }
>> }
>>
>> -/* return pixels in terms of txbyteclkhs */
>> -static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
>> - u16 burst_mode_ratio)
>> -{
>> - return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
>> - 8 * 100), lane_count);
>> -}
>> -
>> static void set_dsi_timings(struct drm_encoder *encoder,
>> const struct drm_display_mode *adjusted_mode)
>> {
>> --
>> 1.7.9.5
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list