[Intel-gfx] [BXT DSI timing fixes v1 3/3] drm/i915/bxt: Fixed dsi enc disable and blank at bootup

[Daniel Vetter]

On Wed, Oct 14, 2015 at 10:20:32AM +0000, Shankar, Uma wrote:
> 
> 
> >-----Original Message-----
> >From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
> >Sent: Tuesday, October 13, 2015 9:17 PM
> >To: Shankar, Uma
> >Cc: intel-gfx at lists.freedesktop.org; Kumar, Shobhit
> >Subject: Re: [Intel-gfx] [BXT DSI timing fixes v1 3/3] drm/i915/bxt: Fixed dsi enc
> >disable and blank at bootup
> >
> >On Mon, Oct 12, 2015 at 10:55:03PM +0530, Uma Shankar wrote:
> >> During bootup, mipi display was blanking in BXT. This is because
> >> during driver load, though encoder, connector were active but crtc
> >> returned inactive. This caused sanitize function to disable the DSI
> >> panel. In AOS, this is fine since HWC will do a modeset and crtc,
> >> connector, encoder mapping will be restored. But in Charging OS, no
> >> modeset is called, it just calls DPMS ON/OFF. Hence display doesn't
> >> come in COS. This is needed even for seamless booting to Android without a
> >blank.
> >>
> >> This is fine on BYT/CHT since transcoder is common b/w all encoders.
> >> But for BXT, there is a separate mipi transcoder. Hence this needs
> >> special handling for BXT DSI.
> >>
> >> Signed-off-by: Uma Shankar <uma.shankar at intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h      |    3 +++
> >>  drivers/gpu/drm/i915/intel_display.c |   27 +++++++++++++++++++++++----
> >>  2 files changed, 26 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h index bf14096..ae790ec 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -1948,6 +1948,9 @@ struct drm_i915_private {
> >>  	/* perform PHY state sanity checks? */
> >>  	bool chv_phy_assert[2];
> >>
> >> +	/* To check if DSI is initializing at bootup */
> >> +	bool dsi_enumerating;
> >
> >See my other comment, you're working around the broken design of patch 2
> >here. Special casing fastboot is a big no-no which needs some really good
> >reasons. An example is the special edp clock readout code in the encoder
> >callbacks we have for ilk-ivb cpu edp.
> >-Daniel
> >
> 
> I agree this is not a clean solution but was not getting any better
> ideas. As part of driver load and initialization, readout_state returns
> encoder, connector as active but all crtc return inactive. This make
> sanitize encoder to consider this as inconsistent hw state and it goes
> ahead and disables encoder, thereby disabling the BIOS/GOP
> Initialization.
> 
> After this only way to recover is a modeset which doesn't come in cases
> like Charging OS in Android. Also this will create issues in having a
> seamless boot without a blank (a must have for Android devices).
> 
> For EDP case, we can read DDI_FUNC_CTL and get a pipe number and match
> it with crtc->pipe to detect EDP is on that pipe and map it to crtc.
> 
> In DSI there is no such mechanism to detect this. Can you suggest some
> pointers as to how to approach this issue. 

MIPI_CTRL(port) has BXT_PIPE_SELECT_A/C bits. Which btw we don't ever seem
to check anywhere in intel_dsi_compute_config, which is a pretty stellar
bug that running kms_flip even once should have caught.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch