On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract the current crtc from the crtc state rather than via
> the legacy encoder->crtc pointer whenever possible.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 17 -
On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove intel_digital_port->port and replace its users with
> intel_encoder->port. intel_encoder->port is a superset of
> intel_digital_port->port, and it works correctly even for
> MST encoders.
>
> Performed with
nits below.
On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Eliminate a ton of pointless 'dev' variables in the DP code, and pass
> around 'dev_priv' instead of 'dev'.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 151
> +
On Wed, 2017-11-01 at 11:55 +0200, Jani Nikula wrote:
> On Tue, 31 Oct 2017, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The main attraction of this series is removal of
> > intel_digital_port->port. Ever since the introduction of
> > intel_encoder->port it has been redundant, and I f
On Tue, 2017-11-14 at 21:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix copy/paste fail in kerneldocs for intel_audio_codec_disable().
>
> Cc: Daniel Vetter
Reviewed-by: Dhinakaran Pandiyan
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/d
On Tue, 2017-11-14 at 19:47 +, Chris Wilson wrote:
> smatch does not track initialised values as well as gcc, and this
> triggers many warnings by smatch not presented by gcc. Silence smatch by
> initialising the error values to -ENODEV, which we use to denote
> internal errors. (If we see a s
On Tue, 2017-11-14 at 22:33 +, Chris Wilson wrote:
> smatch does not track initialised values as well as gcc, and this
> triggers many warnings by smatch not presented by gcc. Silence smatch by
> initialising the error values to -ENODEV, which we use to denote
> internal errors. (If we see a se
On Fri, 2017-09-15 at 20:57 +0300, Ville Syrjala wrote:
> From: Dhinakaran Pandiyan
This should be yours :)
>
> Having registers for nonexistent planes in the dumpo might end up being
> rather confusing. Try to only include real planes.
>
Thanks for resubmitting 3/7 and the cleanups.
One
Reviewed-by: Dhinakaran Pandiyan for the
series.
On Tue, 2017-11-21 at 20:49 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I think the dump is a more legible when the register names
> are right justified. That way the register name and its value
> are right next to each other.
>
> Cc:
On Wed, 2017-10-11 at 12:28 +0200, Maarten Lankhorst wrote:
> Op 10-10-17 om 22:12 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2017-10-10 17:04:27)
> >> Make sure read_all_entries has all outputs possible enabled, but also
> >> add a test that runs with all outputs disabled.
> >>
> >> This
On Wed, 2017-10-25 at 00:09 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp: Clean up intel_dp_check_mst_status
> URL : https://patchwork.freedesktop.org/series/32584/
> State : failure
>
> == Summary ==
>
> Series 32584v1 drm/i915/dp: Clean up intel_dp_check_mst_sta
On Thu, 2017-10-26 at 10:59 +0300, Jani Nikula wrote:
> On Thu, 10 Aug 2017, Dhinakaran Pandiyan wrote:
> > DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state
> >
> > 101 = Set Main-Link for local Sink device and all downstream Sink
> > devices to D3 (power-down mode), keep AUX block
On Thu, 2017-10-26 at 17:35 -0200, Paulo Zanoni wrote:
> Em Qui, 2017-10-26 às 12:32 -0700, Rodrigo Vivi escreveu:
> > On Thu, Oct 26, 2017 at 01:29:57PM +, Paulo Zanoni wrote:
> > > Em Qua, 2017-10-25 às 17:37 -0700, Dhinakaran Pandiyan escreveu:
> > > > The frontbuffer_tracking PSR tests f
On Thu, 2017-10-26 at 16:51 -0700, Dhinakaran Pandiyan wrote:
> The frontbuffer_tracking PSR tests fail if PSR cannot be activated when
> there is sink support. But, there are several other requirements related to
> mode timings that have to be satisfied before PSR can be enabled. No reason
> to f
On Thu, 2017-10-26 at 22:41 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DP dongles may signal downstream HPD via short HPD pulses. Setting the
> sink to DPMS off apparently kills the downstream HPD (at least on my
> DP->VGA dongle), so skip the DPMS off for such dongles when we turn
>
On Sun, 2017-10-29 at 03:04 +, Kumar, Abhay wrote:
> + Subhransu
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Kumar, Abhay
> Sent: Thursday, October 26, 2017 12:10 PM
> To: Jani Nikula ; Dhinakaran Pandiyan
> ; subransu.s.pr
On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> > plane MMIOs are written to. But this flush is not necessary for PSR as
> > hardware tracking takes care of exi
On Tue, 2018-02-13 at 22:15 +, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> >
> >
> >
> > On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> > > Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > > >
On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> From: Andy Lutomirski
>
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR. As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to
On Tue, 2018-02-13 at 22:59 +, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-02-13 22:45:55)
> >
> >
> >
> > On Tue, 2018-02-13 at 22:15 +, Chris Wilson wrote:
> > > Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> > > >
z
On Wed, 2018-02-14 at 19:38 +0200, Jani Nikula wrote:
> Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check where
> we know pipe >= 0 and next to the array indexing where it makes most
> sense.
>
> Fixes: 9965db26ac05 ("drm/i915: Check for fused or unused pipes")
> Fixes: 0b7029
On Thu, 2018-02-15 at 11:55 -0800, Rodrigo Vivi wrote:
> Dave Airlie writes:
>
> > On 6 February 2018 at 06:32, Rodrigo Vivi wrote:
> >> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> >>> Dhinakaran Pandiyan writes:
> >
On Fri, 2018-02-16 at 08:58 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:22)
> > With fbdev, screen freezes after a few continuous PSR exit->enter cycles.
> > Printing out the PSR status register clearly showed this freeze coincided
> > with exiting when the hardware i
On Fri, 2018-02-16 at 08:52 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:18)
> > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
> > DIRTYFB. The callers however are at a vantage point to decide if hardware
> > frontbuffer tracking can do the
On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > Preparing a framebuffer should not require a flush. _post_plane_update()
> > takes care of flushing when a flip is scheduled, this should be
> > sufficient for PSR and FBC.
>
> Makes sen
On Tue, 2018-02-20 at 10:44 -0800, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2018 at 06:25:38PM +0200, Imre Deak wrote:
> > On Tue, Feb 20, 2018 at 05:35:20PM +0200, Imre Deak wrote:
> > > On Mon, Feb 19, 2018 at 05:49:41PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Feb 19, 2018 at 04:47:41PM +0200
On Tue, 2018-02-20 at 19:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since we no longer have a 1:1 correspondence between ports and AUX
> channels, let's give AUX channels their own enum. Makes it easier
> to tell the apples from the oranges, and we get rid of the
> port E AUX pow
On Tue, 2018-02-20 at 21:00 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just store function pointers that give us the correct register offsets
> instead of storing the register offsets themselves. Slightly less
> efficient perhaps but saves a few bytes and better matches how we do
> th
On Tue, 2018-02-20 at 11:31 -0800, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2018 at 07:05:22PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since we no longer have a 1:1 correspondence between ports and AUX
> > channels, let's give AUX channels their own enum. Makes it easier
> > t
On Wed, 2018-02-21 at 23:28 -0800, Dhinakaran Pandiyan wrote:
> From: Ville Syrjälä
>
> Since we no longer have a 1:1 correspondence between ports and AUX
> channels, let's give AUX channels their own enum. Makes it easier
> to tell the apples from the oranges, and we get rid of the
> port E AUX
On Thu, 2018-02-22 at 11:34 -0800, Rodrigo Vivi wrote:
> On Thu, Feb 22, 2018 at 08:59:49PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2018 at 06:23:47PM -0800, José Roberto de Souza wrote:
> > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > > self, so lets use the mu
On Thu, 2018-02-22 at 12:13 -0800, Rodrigo Vivi wrote:
> On Thu, Feb 22, 2018 at 11:57:03AM -0800, Pandiyan, Dhinakaran wrote:
> > On Thu, 2018-02-22 at 11:34 -0800, Rodrigo Vivi wrote:
> > > On Thu, Feb 22, 2018 at 08:59:49PM +0200, Ville Syrjälä wrote:
> > > > On T
On Thu, 2018-02-22 at 14:43 +0200, Ville Syrjälä wrote:
> On Thu, Feb 22, 2018 at 07:16:07AM +0000, Pandiyan, Dhinakaran wrote:
> >
> > On Tue, 2018-02-20 at 21:00 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Just store function
On Thu, 2018-02-22 at 12:44 -0800, Rodrigo Vivi wrote:
> On Thu, Feb 22, 2018 at 12:28:50PM -0800, Dhinakaran Pandiyan wrote:
> > PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
> > for AUX-A enables DC_OFF well too. This is not required, so add a new
> > AUX_IO_A doma
On Thu, 2018-02-22 at 23:47 +0200, Ville Syrjälä wrote:
> On Thu, Feb 22, 2018 at 09:33:10PM +0000, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Thu, 2018-02-22 at 12:44 -0800, Rodrigo Vivi wrote:
> > > On Thu, Feb 22, 2018 at 12:28:50PM -0800, Dhinakara
On Fri, 2018-02-23 at 00:05 +0200, Imre Deak wrote:
> On Thu, Feb 22, 2018 at 11:53:30PM +0200, Imre Deak wrote:
> > On Thu, Feb 22, 2018 at 11:33:10PM +0200, Pandiyan, Dhinakaran wrote:
> > >
> > >
> > >
> > > On Thu, 2018-02-22 at 12:44 -0800, Rod
On Fri, 2018-02-23 at 00:42 +0200, Imre Deak wrote:
> On Fri, Feb 23, 2018 at 12:30:14AM +0200, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-02-23 at 00:05 +0200, Imre Deak wrote:
> > > On Thu, Feb 22, 2018 at 11:53:30PM +0200, Imre Deak wrote:
> > > > On Thu, Fe
On Tue, 2018-02-13 at 16:29 -0800, Rodrigo Vivi wrote:
> According to spec:
> "PSR2 is supported for pipe active sizes up to
> 3640 pixels wide and 2304 lines tall."
>
> BSpec: 7713
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_psr.c | 6 +++---
>
On Wed, 2018-02-14 at 08:03 -0800, Rodrigo Vivi wrote:
> We can still use PSR1 when PSR2 conditions are not met.
>
> So, let's split the check in a way that we make sure has_psr
> gets set independently of PSR2 criteria.
>
> v2: Duh! Handle proper return to avoid breaking PSR2.
>
> Cc: Dhinakara
On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> It is a fact that scheduled work is now improved.
>
> But it is also a fact that on core platforms that shouldn't
> be needed. We only need to actually wait on VLV/CHV.
>
> The immediate enabling is actually not an issue for the
> HW perspe
On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> the CPU host modify writes may not get updated on the Display
> as expected.
> WA: Write 0x to CUR_SURFLIVE_A with every CPU
> host modify write to trigger PSR exit."
>
>
On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> Missing flips when FBC is enabled with PSR
> link off/PSR2 deep sleep scenarios.
>
I am wary of this. Is there a test to compare flip misses before/after
this workaround? We also have to confirm disabling FBC has the same
effect of not havi
On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> Host/Render modifications do not trigger PSR exit
> or Wireless quick capture exit correctly.
>
I don't get this workaround either. The wording indicates frontbuffer
modifications are expected to trigger PSR exit in HW. But we rely on the
d
On Fri, 2018-02-23 at 16:59 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > Missing flips when FBC is enabled with PSR
> > link off/PSR2 deep sleep scenarios.
> >
>
> I am wary of this. Is there a test to compare flip misses before/after
> this wo
On Tue, 2018-02-20 at 18:18 -0800, José Roberto de Souza wrote:
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f5d7bfb4300
On Tue, 2018-02-20 at 18:18 -0800, José Roberto de Souza wrote:
> Just share the common code in PSR and PSR2.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i9
On Tue, 2018-02-20 at 18:18 -0800, José Roberto de Souza wrote:
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index
On Fri, 2018-02-23 at 17:51 -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separated.
>
On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> >>> Preparing a framebuf
On Mon, 2018-02-26 at 18:31 +, Souza, Jose wrote:
> On Fri, 2018-02-23 at 19:12 -0800, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-02-23 at 17:51 -0800, José Roberto de Souza wrote:
> > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > >
On Mon, 2018-02-26 at 15:08 -0800, Rodrigo Vivi wrote:
> On Fri, Feb 23, 2018 at 04:24:35PM -0800, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > > the CP
On Mon, 2018-02-26 at 15:12 -0800, Rodrigo Vivi wrote:
> On Fri, Feb 23, 2018 at 03:46:09PM -0800, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > > It is a fact that scheduled work is now improved.
> > >
> > >
> -Original Message-
> From: Runyan, Arthur J
> Sent: Tuesday, January 9, 2018 11:55 AM
> To: Pandiyan, Dhinakaran ; Singh, Gaurav K
>
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
>
On Mon, 2018-02-26 at 14:41 -0800, Rodrigo Vivi wrote:
> On Mon, Feb 26, 2018 at 01:48:37PM -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent acce
On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used.
I feel this array expresses platform capability concisely and it's easy
to quickly check what rates a platform supports when the array is at the
top. But,that's
On Fri, 2018-02-23 at 18:03 -0800, José Roberto de Souza wrote:
> As gen < 9 hardware don't have the aux ch mutex, we need to exit PSR
> and wait until it is back to inactive state before do any aux ch
> transaction.
>
I wonder if we need this for CHV/VLV since the HW does not send PSR aux
tra
On Tue, 2018-02-27 at 13:29 -0800, Rodrigo Vivi wrote:
> We can still use PSR1 when PSR2 conditions are not met.
>
> So, let's split the check in a way that we make sure has_psr
> gets set independently of PSR2 criteria.
>
> v2: Duh! Handle proper return to avoid breaking PSR2.
> v3: (DK):
>
On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent acc
On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > >
> > >
> > >
> > > On Mon, 2018-02-19 at 10:07
hu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2018-0
On Thu, 2018-03-01 at 22:47 +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to
> > be safe.
> >
> > Cc: Rodrigo Vivi
> > Cc: Elio Martinez Monroy
> > Signed-off-by: Dhi
On Thu, 2018-03-01 at 23:47 +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > to be safe.
> >
> > v2: Use local variables for resolution limits and print them (Vil
On Thu, 2018-03-01 at 12:53 +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote:
> > On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> > > > On Tue, 2018-02-27 at 23:34 +0200, Ville S
On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> From: Gaurav Singh
>
> On Apollolake, with stress test warm reboot, audio card
> was not getting enumerated after reboot. This was a
> spurious issue happening on Apollolake. HW codec and
> HD audio controller link was going out of sync f
On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > to be safe.
> >
> > v3: Update GLK too. (Ville)
> > Longer variable names.
> >
On Tue, 2018-03-06 at 23:24 +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 08:45:44PM +0000, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinak
On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> > bits to 7 bits in DPCD 0x000e. The 8th bit describes a n
On Tue, 2018-03-06 at 16:48 -0800, Dhinakaran Pandiyan wrote:
>
>
> On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> > > From: Matt Atwood
> > >
> > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed
On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> On Wed, Mar 07, 2018 at 12:24:46AM +0000, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, mat
On Fri, 2018-02-16 at 08:54 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:19)
> > From: Rodrigo Vivi
> >
> > So far we are using frontbuffer tracking for everything
> > and ignoring that PSR has a HW capable HW tracking for many
> > modern usages of GPU on Core pla
On Tue, 2018-02-27 at 16:14 -0800, Rodrigo Vivi wrote:
> From: Andy Lutomirski
>
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR. As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
>
On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
> was dropped. We still have some code leftovers from those early days.
> Eliminate them.
>
Not much in the spec about HBR2 other than
On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> changed. The easiest fix is to pretend enable_psr is ignored at
> configure time, and never activate it for !enable_psr, so both cases
> are handled without modesets.
On Wed, 2018-03-07 at 14:46 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
> > DIRTYFB.
On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > plane MMIOs are written to. But this flush should not be necessary for
> > PSR as hardware tracking triggers PSR ex
On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote:
> > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > > > Quotin
On Thu, 2018-03-08 at 14:58 +0200, Ville Syrjälä wrote:
> On Wed, Mar 07, 2018 at 09:41:06PM +0000, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > >
On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> > On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> >> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> >> changed. Th
On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote:
> Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
> >
> >
> > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> >>>
On Wed, 2018-03-07 at 15:34 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > plane MMIOs are written to. But this flush
On Thu, 2018-03-08 at 16:52 -0800, Rodrigo Vivi wrote:
> WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> the CPU host modify writes may not get updated on the Display
> as expected.
> WA: Write 0x to CUR_SURFLIVE_A with every CPU
> host modify write to trigger PSR exit."
>
On Fri, 2018-03-09 at 01:42 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/psr: Kill scheduled work for Core platforms.
> URL : https://patchwork.freedesktop.org/series/39650/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915/psr: Kill scheduled work for Core plat
On Mon, 2018-03-12 at 20:29 +0200, Ville Syrjälä wrote:
> On Thu, Mar 08, 2018 at 04:52:18PM -0800, Rodrigo Vivi wrote:
> > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > the CPU host modify writes may not get updated on the Display
> > as expected.
> > WA: Write 0x to
On Mon, 2018-03-12 at 11:45 -0700, Rodrigo Vivi wrote:
> On Mon, Mar 12, 2018 at 11:07:55AM -0700, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Thu, 2018-03-08 at 16:52 -0800, Rodrigo Vivi wrote:
> > > WA 0884:bxt:all,cnl:*:A - "When FBC is enable
On Mon, 2018-03-12 at 20:49 +0200, Ville Syrjälä wrote:
> On Mon, Mar 12, 2018 at 06:40:26PM +0000, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Mon, 2018-03-12 at 20:29 +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 08, 2018 at 04:52:18PM -0800, Rodrigo
On Thu, 2018-03-08 at 17:17 -0800, Rodrigo Vivi wrote:
> The immediate enabling is actually not an issue for the
> HW perspective for core platforms that have HW tracking.
> HW will wait few identical idle frames before transitioning
> to actual psr active anyways.
>
> Note that this patch also
On Mon, 2018-03-12 at 23:16 +, Souza, Jose wrote:
> What if FBC is disabled? Or FBC can not be activate by any of the
> reasons in intel_fbc_can_activate(). The hardware tracking would never
> trigger a PSR exit by it self?!
>
Only frontbuffer tracking is tied to FBC, PSR exit on plane/pipe
On Tue, 2018-03-13 at 04:23 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's
> own function.
> URL : https://patchwork.freedesktop.org/series/39825/
> State : warning
>
> == Summary ==
>
> Series 39825v1 series s
On Mon, 2017-07-31 at 15:41 -0700, Puthikorn Voravootivat wrote:
> > But now you're suggesting another arbitrary narrow selection of panels
> > based on limited evidence.
>
> I understand your point that the panel I observe is not the
> representative of the real world.
>
> My point is that we
On Tue, 2017-08-01 at 16:51 +0800, Ethan Hsieh wrote:
> We do not update the status of connector when receiving MST unplug event.
> Call detect function to get latest status and then update status of connector.
>
Cc'ing Daniel and Chris.
Thanks for sending this to the list.
The issue is conne
On Wed, 2017-08-02 at 01:49 +, Pandiyan, Dhinakaran wrote:
> On Tue, 2017-08-01 at 16:51 +0800, Ethan Hsieh wrote:
> > We do not update the status of connector when receiving MST unplug event.
> > Call detect function to get latest status and then update status of
On Thu, 2017-08-03 at 11:07 -0700, Rodrigo Vivi wrote:
> On Tue, Jul 18, 2017 at 2:34 PM, Jim Bride wrote:
> > According to the eDP spec, when the count field in TEST_SINK_MISC
> > increments then the six bytes of sink CRC information in the DPCD
> > should be valid. Unfortunately, this doesn'
On Fri, 2017-08-04 at 13:38 +0300, Jani Nikula wrote:
> This is not to try to force a new style; this is my interpretation of
> what the most common existing style is.
>
> With hopes I don't need to answer so many questions about style going
> forward.
>
> Cc: Daniel Vetter
> Signed-off-by: Jani
On Wed, 2017-08-02 at 12:26 -0700, Rodrigo Vivi wrote:
> The idea is to have an unique place to decide the pin-port
> per platform.
>
> So let's create this function now without any functional
> change.
This seems to change the behavior when port A is not eDP.
> Just adding together code from h
On Wed, 2017-08-02 at 10:20 -0700, Rodrigo Vivi wrote:
> We will soon need to make that pin port association per
> platform, so let's try to simplify it beforehand.
>
> Also we are moving the backwards port to pin
> here as well so let's use a standardized way.
>
> One extra possibility here woul
On Thu, 2017-08-10 at 19:45 +0200, Stefan Assmann wrote:
> On 2017-08-10 07:50, Rodrigo Vivi wrote:
> > I'm not sure if this is really the case and I don't believe
> > this is the real fix for the bug mentioned here, but since
> > I don't see a reliable path when mst_port is set and when
> > mode_v
On Thu, 2017-08-10 at 05:47 +, Navare, Manasi D wrote:
> We currently assume port A is connected to a DP sink when VBT is absent,
> instead assume it is connected to an eDP sink, which seems like a more common
> configuration. Although I don't have data to back this up, it is still just
> as
On Thu, 2017-08-10 at 14:23 -0700, Rodrigo Vivi wrote:
> On Wed, Aug 9, 2017 at 9:44 PM, Pandiyan, Dhinakaran
> wrote:
> > On Wed, 2017-08-02 at 12:26 -0700, Rodrigo Vivi wrote:
> >> The idea is to have an unique place to decide the pin-port
> >> per platform.
On Fri, 2017-08-11 at 18:58 +0530, Shashank Sharma wrote:
> It's an observation during some CI tests that few LSPCON chips
> respond slow while system is under load, and need some delay
Thanks for the patch. Can you please explain what you mean by load here?
I can't follow why an external chip wou
On Fri, 2017-08-11 at 18:58 +0530, Shashank Sharma wrote:
> Our current logic to read LSPCON's current mode, stops retries and
> breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the
> core function. This doesn't allow us to try reading the mode again.
>
> This patch removes this con
401 - 500 of 590 matches
Mail list logo
