Re:[PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.

Re:[PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.

[luo.penghao]

[-- Attachment #1.1.1: Type: text/plain, Size: 963 bytes --]

> This one we could use. For some reason we hardcode it to



> 1 now, which is correct for our use cases but I don't really> see a reason to hardcode it here. We are supposed to calculate> it correctly after all, and chv_crtc_clock_get() also just blindly> reads it out.> > >      bestm2_frac = crtc_state->dpll.m2 & 0x3fffff;> > -    bestm1 = crtc_state->dpll.m1;> > This one is a bit trickier since I don't think the spec even> gives us other values. But we could assert that it's correct.> > Some something along these lines I think would be best:> + drm_WARN_ON(&dev_priv->drm, bestm1 != 2);>   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW1(port),>                  DPIO_CHV_M1_DIV_BY_2 |> -          1 << DPIO_CHV_N_DIV_SHIFT);> +          bestn << DPIO_CHV_N_DIV_SHIFT);






Thanks for your kind response ! Does that means the variable will be


used by the hardware？if so as far as I see it, I don't seem to see the


relevant interface.

[-- Attachment #1.1.2: Type: text/html , Size: 2862 bytes --]

Re: [Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.

[luo.penghao]

[-- Attachment #1.1.1: Type: text/plain, Size: 963 bytes --]

> This one we could use. For some reason we hardcode it to



> 1 now, which is correct for our use cases but I don't really> see a reason to hardcode it here. We are supposed to calculate> it correctly after all, and chv_crtc_clock_get() also just blindly> reads it out.> > >      bestm2_frac = crtc_state->dpll.m2 & 0x3fffff;> > -    bestm1 = crtc_state->dpll.m1;> > This one is a bit trickier since I don't think the spec even> gives us other values. But we could assert that it's correct.> > Some something along these lines I think would be best:> + drm_WARN_ON(&dev_priv->drm, bestm1 != 2);>   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW1(port),>                  DPIO_CHV_M1_DIV_BY_2 |> -          1 << DPIO_CHV_N_DIV_SHIFT);> +          bestn << DPIO_CHV_N_DIV_SHIFT);






Thanks for your kind response ! Does that means the variable will be


used by the hardware？if so as far as I see it, I don't seem to see the


relevant interface.

[-- Attachment #1.1.2: Type: text/html , Size: 2862 bytes --]

Re:[PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.

[luo.penghao]

[-- Attachment #1.1.1: Type: text/plain, Size: 963 bytes --]

> This one we could use. For some reason we hardcode it to



> 1 now, which is correct for our use cases but I don't really> see a reason to hardcode it here. We are supposed to calculate> it correctly after all, and chv_crtc_clock_get() also just blindly> reads it out.> > >      bestm2_frac = crtc_state->dpll.m2 & 0x3fffff;> > -    bestm1 = crtc_state->dpll.m1;> > This one is a bit trickier since I don't think the spec even> gives us other values. But we could assert that it's correct.> > Some something along these lines I think would be best:> + drm_WARN_ON(&dev_priv->drm, bestm1 != 2);>   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW1(port),>                  DPIO_CHV_M1_DIV_BY_2 |> -          1 << DPIO_CHV_N_DIV_SHIFT);> +          bestn << DPIO_CHV_N_DIV_SHIFT);






Thanks for your kind response ! Does that means the variable will be


used by the hardware？if so as far as I see it, I don't seem to see the


relevant interface.

[-- Attachment #1.1.2: Type: text/html , Size: 2820 bytes --]

Re:[PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.

[luo.penghao]

[-- Attachment #1.1.1: Type: text/plain, Size: 963 bytes --]

> This one we could use. For some reason we hardcode it to



> 1 now, which is correct for our use cases but I don't really> see a reason to hardcode it here. We are supposed to calculate> it correctly after all, and chv_crtc_clock_get() also just blindly> reads it out.> > >      bestm2_frac = crtc_state->dpll.m2 & 0x3fffff;> > -    bestm1 = crtc_state->dpll.m1;> > This one is a bit trickier since I don't think the spec even> gives us other values. But we could assert that it's correct.> > Some something along these lines I think would be best:> + drm_WARN_ON(&dev_priv->drm, bestm1 != 2);>   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW1(port),>                  DPIO_CHV_M1_DIV_BY_2 |> -          1 << DPIO_CHV_N_DIV_SHIFT);> +          bestn << DPIO_CHV_N_DIV_SHIFT);






Thanks for your kind response ! Does that means the variable will be


used by the hardware？if so as far as I see it, I don't seem to see the


relevant interface.

[-- Attachment #1.1.2: Type: text/html , Size: 2778 bytes --]