| Message ID | 1351241899-7870-3-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2012/10/26 Daniel Vetter <daniel.vetter@ffwll.ch>: > According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], > Display Mode Set Sequence" We need to write the TU size register > of the fdi RX unit _before_ starting to train the link. Well, we are still writing it before training the link, but it's waaaaay before :) But I agree with the patch, it makes the code look more like our mode set sequence docs. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/i915/intel_display.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 0261d18..6cc9cb9 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2681,9 +2681,6 @@ static void ironlake_fdi_pll_enable(struct intel_crtc *intel_crtc) > int pipe = intel_crtc->pipe; > u32 reg, temp; > > - /* Write the TU size bits so error detection works */ > - I915_WRITE(FDI_RX_TUSIZE1(pipe), > - I915_READ(PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); > > /* enable PCH FDI RX PLL, wait warmup plus DMI latency */ > reg = FDI_RX_CTL(pipe); > @@ -2996,6 +2993,11 @@ static void ironlake_pch_enable(struct drm_crtc *crtc) > > assert_transcoder_disabled(dev_priv, pipe); > > + /* Write the TU size bits before fdi link training, so that error > + * detection works. */ > + I915_WRITE(FDI_RX_TUSIZE1(pipe), > + I915_READ(PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); > + > /* For PCH output, training FDI link */ > dev_priv->display.fdi_link_train(crtc); > > -- > 1.7.11.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sat, Oct 27, 2012 at 1:51 PM, Paulo Zanoni <przanoni@gmail.com> wrote: > 2012/10/26 Daniel Vetter <daniel.vetter@ffwll.ch>: >> According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], >> Display Mode Set Sequence" We need to write the TU size register >> of the fdi RX unit _before_ starting to train the link. > > Well, we are still writing it before training the link, but it's > waaaaay before :) > But I agree with the patch, it makes the code look more like our mode > set sequence docs. Indeed, I've confused myself with the placement of the fdi pll code quite a bit. I think that's actually a remnant of the pre-modeset world, where we could potentially enter the modeset functions with unknown states. I think I'll keep things as-is, and instead add a comment to the fdi_pll function that we need to evetually move this to the pch/fdi enabling ... -Daniel
2012/10/27 Daniel Vetter <daniel.vetter@ffwll.ch>: > On Sat, Oct 27, 2012 at 1:51 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >> 2012/10/26 Daniel Vetter <daniel.vetter@ffwll.ch>: >>> According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], >>> Display Mode Set Sequence" We need to write the TU size register >>> of the fdi RX unit _before_ starting to train the link. >> >> Well, we are still writing it before training the link, but it's >> waaaaay before :) >> But I agree with the patch, it makes the code look more like our mode >> set sequence docs. > > Indeed, I've confused myself with the placement of the fdi pll code > quite a bit. I think that's actually a remnant of the pre-modeset > world, where we could potentially enter the modeset functions with > unknown states. I think I'll keep things as-is, and instead add a > comment to the fdi_pll function that we need to evetually move this to > the pch/fdi enabling ... I don't understand. Why not just apply the current patch? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sat, Oct 27, 2012 at 3:03 PM, Paulo Zanoni <przanoni@gmail.com> wrote: > 2012/10/27 Daniel Vetter <daniel.vetter@ffwll.ch>: >> On Sat, Oct 27, 2012 at 1:51 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >>> 2012/10/26 Daniel Vetter <daniel.vetter@ffwll.ch>: >>>> According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], >>>> Display Mode Set Sequence" We need to write the TU size register >>>> of the fdi RX unit _before_ starting to train the link. >>> >>> Well, we are still writing it before training the link, but it's >>> waaaaay before :) >>> But I agree with the patch, it makes the code look more like our mode >>> set sequence docs. >> >> Indeed, I've confused myself with the placement of the fdi pll code >> quite a bit. I think that's actually a remnant of the pre-modeset >> world, where we could potentially enter the modeset functions with >> unknown states. I think I'll keep things as-is, and instead add a >> comment to the fdi_pll function that we need to evetually move this to >> the pch/fdi enabling ... > > I don't understand. Why not just apply the current patch? We could move the call to enable_fdi_pll to the right place, where we enable all fdi/pch resources, instead of just the TU_SIZE write. Or do you think that's worse? -Daniel
2012/10/27 Daniel Vetter <daniel.vetter@ffwll.ch>: > On Sat, Oct 27, 2012 at 3:03 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >> 2012/10/27 Daniel Vetter <daniel.vetter@ffwll.ch>: >>> On Sat, Oct 27, 2012 at 1:51 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >>>> 2012/10/26 Daniel Vetter <daniel.vetter@ffwll.ch>: >>>>> According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], >>>>> Display Mode Set Sequence" We need to write the TU size register >>>>> of the fdi RX unit _before_ starting to train the link. >>>> >>>> Well, we are still writing it before training the link, but it's >>>> waaaaay before :) >>>> But I agree with the patch, it makes the code look more like our mode >>>> set sequence docs. >>> >>> Indeed, I've confused myself with the placement of the fdi pll code >>> quite a bit. I think that's actually a remnant of the pre-modeset >>> world, where we could potentially enter the modeset functions with >>> unknown states. I think I'll keep things as-is, and instead add a >>> comment to the fdi_pll function that we need to evetually move this to >>> the pch/fdi enabling ... >> >> I don't understand. Why not just apply the current patch? > > We could move the call to enable_fdi_pll to the right place, where we > enable all fdi/pch resources, instead of just the TU_SIZE write. Or do > you think that's worse? Our mode set sequence says the FDI PLL should be enabled way earlier than the other FDI/PCH resources, and that's what we currently do, so I believe it is currently being called at the "right place" or at least close to the right place. It seems RX TU_SIZE enablement is not part of the "FDI PLL enablement", but part of the "other FDI/PCH resources" enablement (at least that's that the HSW mode set sequence says), and that's why I agree with the patch. (I have the feeling I am trying to explain to you why your patch is correct...) Well, it's your patch, your choice :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sat, Oct 27, 2012 at 3:18 PM, Paulo Zanoni <przanoni@gmail.com> wrote: > Our mode set sequence says the FDI PLL should be enabled way earlier > than the other FDI/PCH resources, and that's what we currently do, so > I believe it is currently being called at the "right place" or at > least close to the right place. It seems RX TU_SIZE enablement is not > part of the "FDI PLL enablement", but part of the "other FDI/PCH > resources" enablement (at least that's that the HSW mode set sequence > says), and that's why I agree with the patch. > > (I have the feeling I am trying to explain to you why your patch is correct...) > > Well, it's your patch, your choice :) Ok, I've rechecked the modeset sequence, and we need to indeed enable fdi plls _before_ we enable the cpu pipe. I think I'll merge v1, plus throw another patch on top to explain why fdi_pll_enable is so damn early. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0261d18..6cc9cb9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2681,9 +2681,6 @@ static void ironlake_fdi_pll_enable(struct intel_crtc *intel_crtc) int pipe = intel_crtc->pipe; u32 reg, temp; - /* Write the TU size bits so error detection works */ - I915_WRITE(FDI_RX_TUSIZE1(pipe), - I915_READ(PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); /* enable PCH FDI RX PLL, wait warmup plus DMI latency */ reg = FDI_RX_CTL(pipe); @@ -2996,6 +2993,11 @@ static void ironlake_pch_enable(struct drm_crtc *crtc) assert_transcoder_disabled(dev_priv, pipe); + /* Write the TU size bits before fdi link training, so that error + * detection works. */ + I915_WRITE(FDI_RX_TUSIZE1(pipe), + I915_READ(PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); + /* For PCH output, training FDI link */ dev_priv->display.fdi_link_train(crtc);
According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence" We need to write the TU size register of the fdi RX unit _before_ starting to train the link. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_display.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)