On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> th
On Fri, Nov 11, 2016 at 02:57:38PM -0200, Paulo Zanoni wrote:
> It only has two checks now, so it makes sense to just move the code to
> the caller.
>
> Also take this opportunity to make no_fbc_reason make more sense: now
> we'll only list "no suitable CRTC for FBC" instead of maybe giving a
> re
On Fri, Nov 11, 2016 at 02:57:41PM -0200, Paulo Zanoni wrote:
> Because it's shorter, easier to read, newer and cooler. And I don't
> think anybody else has pending FBC patches right now, so the conflicts
> should be minimal.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Chris Wilson
-Chris
--
On Fri, Nov 11, 2016 at 02:57:35PM -0200, Paulo Zanoni wrote:
> We can just call it earlier, so do it. The goal of the loop is to get
> the plane's CRTC state, and we don't need it in order to call
> intel_fbc_can_choose().
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Chris Wilson
-Chris
--
Ch
On Fri, Nov 11, 2016 at 02:57:37PM -0200, Paulo Zanoni wrote:
> Extract that part of the code to a new function and call this function
> only once during intel_fbc_choose_crtc() instead of once per plane.
> Those checks are independent from planes/CRTCs.
>
> Signed-off-by: Paulo Zanoni
Reviewed-b
On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> Not validating the the mode rate against link rate results not pruning
> invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> support 4k @ 60Hz. But, we do not reject this mode currently.
>
> So, make use of th
On Fri, Nov 11, 2016 at 02:57:39PM -0200, Paulo Zanoni wrote:
> Use drm_atomic_get_existing_crtc_state() instead of looping through
> the CRTC states and checking if the FBC CRTC is there.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Techn
On Fri, Nov 11, 2016 at 02:57:36PM -0200, Paulo Zanoni wrote:
> Much simpler. Thanks to Ville for pointing this.
>
> Cc: Ville Syrjälä
> Reported-by: Ville Syrjälä
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 17 +++--
> 1 file changed, 7 insertions(+),
== Series Details ==
Series: drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX
ch specified in the VBT
URL : https://patchwork.freedesktop.org/series/15187/
State : success
== Summary ==
Series 15187v1 drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's
no
On Thu, Nov 10, 2016 at 03:36:34PM +0200, Joonas Lahtinen wrote:
> Update i915_driver_load kerneldoc to match code.
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
Alright, quick question: should we be going with your branch then or
mine?
On Wed, 2016-11-09 at 16:09 +0100, Tomeu Vizoso wrote:
> Hi Lyude,
>
> I think this looks very good.
>
> On 8 November 2016 at 01:05, Lyude wrote:
> >
> >
> > - While writing this patch series, I found that quite a fe
On Fri, Nov 11, 2016 at 05:46:16PM +, Chris Wilson wrote:
> On Fri, Nov 11, 2016 at 02:57:36PM -0200, Paulo Zanoni wrote:
> > Much simpler. Thanks to Ville for pointing this.
> >
> > Cc: Ville Syrjälä
> > Reported-by: Ville Syrjälä
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/dr
On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> Ville pointed out that intel_fbc_choose_crtc() is iterating over all
> planes instead of just the primary planes. There are no real
> consequences of this problem for HSW+, and for the other platforms it
> just means that in some obscu
Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> >
> > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > all
> > planes instead of just the primary planes. There are no real
> > consequences of this prob
On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > >
> > > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > > all
> > > planes instead o
In case of link training failure and requiring user space to set a lower mode,
would full mode set address it? How do we make user mode select lower
resolution?
For example 4k@60Hz monitor, and link training at 4 lane HBR2 fails and
fallback to 4 lanes HBR, 4k@60 is no longer doable. I would
Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> >
> > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > >
> > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > >
> > > >
> > > > Ville p
On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > >
> > > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > >
> > > > On Fri, Nov 11, 2016
On Thu, Nov 10, 2016 at 10:28 AM, Ben Widawsky
wrote:
>
> From: Ben Widawsky
>
> Signed-off-by: Ben Widawsky
> ---
> intel/intel_chipset.h | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 514f659..41fc0
On Fri, 2016-11-11 at 15:39 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> > We store DP link rates as link clock frequencies in kHz, just like all
> > other clock values. But, DP link rates in the DP Spec are expressed in
> > Gbps/lane, which s
On Fri, 2016-11-11 at 19:41 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. Bu
On Tue, 2016-11-08 at 13:04 +0200, Ville Syrjälä wrote:
> On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > Although the short pulse handling path ends up in the MST hotplug function,
> > we do not perfo
Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> >
> > Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > >
> > > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > > >
> > > >
> > > > Em Sex,
On Fri, Nov 11, 2016 at 08:43:53PM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2016-11-08 at 13:04 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > > Although the shor
On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> th
On 9 November 2016 at 16:15, Robert Bragg wrote:
> This normalizes the execbuf utilities in this file to all use memset to
> clear obj, reloc and execbuf structures and set them up in the same
> order. As I was debugging some unpredictable test failures I was getting
> unsure that all these struct
On 9 November 2016 at 16:15, Robert Bragg wrote:
> No functional change, just moving hsw_load_regster_reg test code down
s/regster/register
> below the execbuf utilities in preparation for updating to use them.
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
___
On 9 November 2016 at 16:15, Robert Bragg wrote:
> This generalises hsw_load_register_reg to loop through an array of
> allowed and disallowed registers and to use the exec_batch[_patched]
> utilities.
>
> Signed-off-by: Robert Bragg
> ---
> tests/gem_exec_parse.c | 139
> ++
On 9 November 2016 at 16:15, Robert Bragg wrote:
> This limits testing the oacontrol tracking (required pairing of oa
> enable/disable per batch buffer) to version <= 8 of the command parser.
>
> Version 9 of the command parser removes all special handling for
> OACONTROL which is now going to be
On 9 November 2016 at 16:15, Robert Bragg wrote:
> With v8 of the command parser (where we won't get an EINVAL for an
> access violation) this updates the bitmasks test to explicitly confirm
> that the command became a NOOP by reading back from where the QW_WRITE
> would have otherwise landed.
>
>
On 9 November 2016 at 16:15, Robert Bragg wrote:
> Since an access violation won't return an error to userspace for v >= 8
> of the command parser this updates the cmd-crossing-page test to
> explicitly read back from SO_WRITE_OFFSET[0] to see that the command
> wasn't squashed to a NOOP.
>
> Sign
On 9 November 2016 at 16:16, Robert Bragg wrote:
> This updates the checking of disallowed loads to set a distinguishable
> value before the load and explicitly check the load was a NOOP by
> reading back the final value.
>
> Signed-off-by: Robert Bragg
> ---
> tests/gem_exec_parse.c | 20 ++
On 9 November 2016 at 16:16, Robert Bragg wrote:
> This combines some parts of the recently added store_lri test with the
> registers test to be able to first load a distinguishable value before
> the LRI and explicitly read back the register to determine if the
> command succeeded or was a NOOP.
On 9 November 2016 at 16:16, Robert Bragg wrote:
> OACONTROL is no longer white listed in the command parser so this checks
> at attempted LRI will be disallowed and (more importantly) checks that
> userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
> This is important becase Me
The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.
Instead of having to
== Series Details ==
Series: drm: move allocation out of drm_get_format_name() (rev4)
URL : https://patchwork.freedesktop.org/series/14873/
State : success
== Summary ==
Series 14873v4 drm: move allocation out of drm_get_format_name()
https://patchwork.freedesktop.org/api/1.0/series/14873/revi
On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of the
On Fri, Nov 11, 2016 at 06:05:34PM -0800, Jeff McGee wrote:
> On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> > From: Peter Antoine
> >
> > The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> > is used for both cases.
> >
> > HuC loading needs to be before GuC
Reviewed-by: Jeff McGee
On Thu, Nov 10, 2016 at 04:15:17PM -0800, Anusha Srivatsa wrote:
> This patch adds the HuC Loading for the BXT by using
> the updated file construction.
>
> Version 1.7 of the HuC firmware.
>
> Cc: Jeff Mcgee
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i9
Reviewed-by: Jeff McGee
On Thu, Nov 10, 2016 at 04:15:18PM -0800, Anusha Srivatsa wrote:
> This patch adds the support to load HuC on KBL
> Version 2.0
>
> Cc: Jeff Mcgee
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_huc_loader.c | 15 ++-
> 1 file changed, 1
On Wed, Nov 09, 2016 at 11:11:07AM -0800, Anusha Srivatsa wrote:
> Replace i915.enable_guc_loading and i915.enable_guc_submission
> with a single parameter - i915.enable_guc. Where:
>
> -1 : Platform default (Only load GuC)
> 0 : Do not use GuC
> 1 : Load GuC, do not use Command Submission through
101 - 141 of 141 matches
Mail list logo
