On Mon, Jan 16, 2017 at 12:06:56PM +0200, Srinivas, Vidya wrote: > > > > -----Original Message----- > > From: Ville Syrjälä [mailto:ville.syrjala@xxxxxxxxxxxxxxx] > > Sent: Friday, January 13, 2017 9:02 PM > > To: Deak, Imre <imre.deak@xxxxxxxxx> > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>; Kahola, Mika > > <mika.kahola@xxxxxxxxx>; Srinivas, Vidya <vidya.srinivas@xxxxxxxxx>; intel- > > gfx@xxxxxxxxxxxxxxxxxxxxx; Conselvan De Oliveira, Ander > > <ander.conselvan.de.oliveira@xxxxxxxxx>; imre.deak@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH 10/14] drm/i915: Add MIPI_IO WA > > > > On Fri, Jan 13, 2017 at 05:03:33PM +0200, Imre Deak wrote: > > > On pe, 2017-01-13 at 09:55 +0200, Jani Nikula wrote: > > > > On Thu, 12 Jan 2017, Mika Kahola <mika.kahola@xxxxxxxxx> wrote: > > > > > This is definitely needed to pass igt test on bxt > > > > > > > > > > 'gem_exec_suspend --run-subtest basic-S3' > > > > > > > > > > Tested-by: Mika Kahola <mika.kahola@xxxxxxxxx> > > > > > > > > > > On Mon, 2017-01-09 at 14:46 +0530, Vidya Srinivas wrote: > > > > > > From: Uma Shankar <uma.shankar@xxxxxxxxx> > > > > > > > > > > > > Enable MIPI IO WA for BXT DSI as per bspec. > > > > > > > > > > > > Signed-off-by: Uma Shankar <uma.shankar@xxxxxxxxx> > > > > > > --- > > > > > > drivers/gpu/drm/i915/i915_reg.h | 3 +++ > > > > > > drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++ > > > > > > 2 files changed, 12 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > > > > b/drivers/gpu/drm/i915/i915_reg.h index 71b978a..b9d7e98 100644 > > > > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > > > > @@ -8301,6 +8301,9 @@ enum { > > > > > > #define _BXT_MIPIC_PORT_CTRL > > 0x6B8C0 > > > > > > #define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc, > > > > > > _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL) > > > > > > > > > > > > +#define BXT_P_CR_GT_DISP_PWRON_0_2_0_GTTMMADR > > _MMIO(0 > > > > > > x138090) > > > > > > > > Observe that this register is already defined as > > > > BXT_P_CR_GT_DISP_PWRON, and already used in intel_dpio_phy.c. It > > > > seems to me changing the bits in this register should be hooked at the > > dpio level. > > > > > > > > Imre? > > > > > > At least the RMW access for this register would need locking against a > > > concurrent access via the DDI encoder enable/disable code? > > > > Full modesets should be serialized by connection_mutex, or perhaps by > > some other thing with async modesets. Although I have a feeling that if > > we're doing async modeset commits without locks half the driveer is going to > > be on fire. Not sure what people are doing/have planned there. Ok. I assume the async case will need a generic solution then. > I hope, with the current design, writing to this register from DSI path should > be okay and we don't need to take any explicit locks. Is this understanding > correct ? Yes, based on the above the connection_mutex provides for the serialization. Just use the existing define as Jani said. > > > > > > We should also make sure the IO is turned off during booting/resuming > > > if DSI won't be used (and so the DSI disable hook won't be called), > > > see the BSpec "Broxton Sequences to Initialize Display". We could do > > > this by enabling/disabling the IO via the power well code which would > > > solve the locking issue too. This would mean using > > > POWER_DOMAIN_PORT_DSI, or adding a new power domain if diverging > > from > > > the BSpec sequence is a problem (would be worth checking with HW > > > people, since AFAICS we've been doing this so far). > AFAIK, this will be taken care in BIOS itself if there is no DSI connected. > If DSI is connected, this can be controlled in DSI disable/enable sequence. Yes ideally, but checking at least if this is really the case would make sense. But I'm ok with the current approach for now. > > > > > > Btw, what about the 0x160020, 0x160054 regs? According to BSpec we > > > need to program these too in the same sequence. > Yes, this is needed. We have a patch for this. Will float the same for review. > Thanks for the input. Any reason for having separate patches? --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
