Hi Rodrigo,
We will use HuC on BXT.
Thanks
Haihao
> vaapi-intel-driver, the userspace component here is only using HuC
> for
> SKL for now, so I believe this one will be on hold for now, right?
>
>
>
> On Wed, 2016-07-06 at 15:24 +0100, Peter Antoine wrote:
> > This patch adds the HuC Loadin
Daniel Vetter writes:
> On Thu, Jul 07, 2016 at 09:41:12AM +0100, Chris Wilson wrote:
>> This effectively reverts
>>
>> commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
>> Author: Chris Wilson
>> Date: Wed Jun 10 15:58:01 2015 +0100
>>
>> drm: Avoid the double clflush on the last cache li
Upon resetting the GPU, we force the engines to be idle by clearing
their request lists. However, I neglected to clear the GT active status
and so the next request following the reset was not marking the device
as busy again. (We had to wait until any outstanding retire worker
finally ran and clear
This function is no longer used outside of intel_pm.c so we can stop
exposing it and rename the __gen6_update_ring_freq() to take its place.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
driver
Select idle frequency during initialisation, then reset the last known
frequency when re-enabling. This allows us to preserve the user selected
frequency across resets.
v2: Stop CHV from overriding the user's choice in cherryview_enable_rps()
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Mi
To allow the user finer control over waitboosting, allow them to set the
frequency we request for the boost. This also them allows to effectively
disable the boosting by setting the boost request to a low frequency.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
dri
Some hardware requires a valid render context before it can initiate
rc6 power gating of the GPU; the default state of the GPU is not
sufficient and may lead to undefined behaviour. The first execution of
any batch will load the "golden render state", at which point it is safe
to enable rc6. As we
As these RPS frequency values are part of our userspace interface, they
must be established before that userspace interface is registered.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 98 +
1 file changed, 3
Move the overclocking max frequency detection alongside the regular
frequency detection, before we expose the undefined value to userspace.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 24 +++-
1 file changed, 15 insertions(+),
Instead of flushing the outstanding enabling, remember the requested
frequency to apply when the powersave work runs.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 30 ++---
drivers/gpu/drm/i915/i915_sysfs.c
Hi Peter,
Could you provide the interface for UMD driver to detect HuC FW loading
status in your new patch set? A normal user doesn't have permission to
read files in debugfs. Reusing I915_GETPARAM is fine for me.
Thanks
Haihao
>
> > -Original Message-
> > From: Thierry, Michel
> > Se
== Series Details ==
Series: series starting with [1/8] drm/i915: Flush GT idle status upon reset
URL : https://patchwork.freedesktop.org/series/9800/
State : failure
== Summary ==
Series 9800v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9800/revisions/1/mbox
On 12/07/16 17:42, Chris Wilson wrote:
On Tue, Jul 12, 2016 at 04:04:57PM +0100, Tvrtko Ursulin wrote:
@@ -3463,11 +3483,18 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
return -EBUSY;
}
- if (!i915_gem_valid_gtt_
On 12/07/16 17:30, Chris Wilson wrote:
On Tue, Jul 12, 2016 at 05:05:44PM +0100, Tvrtko Ursulin wrote:
On 07/07/16 09:41, Chris Wilson wrote:
@@ -2383,10 +2383,10 @@ void i915_vma_move_to_active(struct i915_vma *vma,
static void
i915_gem_object_retire__write(struct drm_i915_gem_object *ob
From: Ander Conselvan de Oliveira
The value of ddi_pll_sel is derived from the selection of shared dpll,
so just calculate the final value when necessary.
v2: Actually remove it from crtc state and delete remaining usages. (CI)
Reviewed-by: Durgadoss R
Signed-off-by: Ander Conselvan de Oliveir
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes. To address these sce
From: Ander Conselvan de Oliveira
Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.
Reviewed-by: Durgadoss R
Signed-
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
v2:
* Refactored code so that bxt_clk_div need not be exported (Durga)
This patch series adds upfront link training support to enable
USB type C based DP on BXT platform.
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes
From: Ander Conselvan de Oliveira
Decouple intel_dp_set_link_params() from struct intel_crtc_state. This
will be useful for implementing DP upfront link training.
Reviewed-by: Durgadoss R
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c| 3 ++-
drivers/gpu/
Hi Yakui,
thanks for taking a look at these, see my comment below.
On ke, 2016-07-13 at 10:22 +0800, Zhao Yakui wrote:
> On 07/01/2016 09:40 PM, Deak, Imre wrote:
> > The purpose for each MOCS entry isn't well defined atm. Defining these
> > is important to remove any uncertainty about the use of
Patchwork writes:
> == Series Details ==
>
> Series: series starting with [1/8] drm/i915: Flush GT idle status upon reset
> URL : https://patchwork.freedesktop.org/series/9800/
> State : failure
>
> == Summary ==
>
> Series 9800v1 Series without cover letter
> http://patchwork.freedesktop.org/a
On Wed, Jul 13, 2016 at 01:25:26PM +0300, Mika Kuoppala wrote:
> Patchwork writes:
>
> > == Series Details ==
> >
> > Series: series starting with [1/8] drm/i915: Flush GT idle status upon reset
> > URL : https://patchwork.freedesktop.org/series/9800/
> > State : failure
> >
> > == Summary ==
>
== Series Details ==
Series: Add USB typeC based DP support for BXT platform (rev9)
URL : https://patchwork.freedesktop.org/series/1731/
State : failure
== Summary ==
Series 1731v9 Add USB typeC based DP support for BXT platform
http://patchwork.freedesktop.org/api/1.0/series/1731/revisions/9/
> On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
> >>Hi Alan,
> >>
> >>(Adding interested people to this thread)
> >>
> >>On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> >I do feel that the importance of the mentioned bug is currently
> >underestimated. Can anyone here give a note, how
On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote:
> On Thu, Jul 09, 2015 at 07:27:57PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
> > > Adding this for SKL onwards.
> > >
> > > Signed-off-by: Sonika Jindal
> >
> > I think this is
On Tue, Jul 12, 2016 at 03:00:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Dell XPS 13 9350 apparently doesn't like it when we use the panel type
> from OpRegion. The OpRegion panel type (0) tells us to use use low
> vswing for eDP, whereas the VBT panel type (2) tel
On Wed, Jul 13, 2016 at 01:59:52PM +0200, Daniel Vetter wrote:
> I think the proper solution should be to make all the probing and fbdev
> restoring async. As soon as we have working async atomic commit for
> modeset we should be able to do all that.
We're not just blocked on the mode change here
On Wed, Jul 06, 2016 at 11:55:41AM +0200, Maarten Lankhorst wrote:
> This is the same as using config.pipe because the order of crtcs will
> never change.
>
> Signed-off-by: Maarten Lankhorst
In the interest of generic igt, I'm somewhat inclined to instead nuke
crtc->pipe (it's an Intelism) inst
On Wed, Jul 13, 2016 at 01:09:28PM +0100, Chris Wilson wrote:
> On Wed, Jul 13, 2016 at 01:59:52PM +0200, Daniel Vetter wrote:
> > I think the proper solution should be to make all the probing and fbdev
> > restoring async. As soon as we have working async atomic commit for
> > modeset we should be
On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote:
> From: Dave Gordon
>
> intel_lrc.c has a table of "logical rings" (meaning engines), while
> intel_ringbuffer.c has separately open-coded initialisation for each
> engine. We can deduplicate this somewhat by using the same first-sta
On Fri, Jul 01, 2016 at 05:47:15PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Engine contains dev_priv so need to pass it in.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 18 --
> 1 file changed, 8
On Fri, Jul 01, 2016 at 05:47:14PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use it for legacy engine initialization by adding a
> intel_ring_default_irqs helper used by individual engines.
>
> Signed-off-by: Tvrtko Ursulin
Not sure this is worth it. irq handling is fairly gen sp
On Thu, Jun 30, 2016 at 04:12:48PM +0100, Dave Gordon wrote:
> Two different sets of flag bits are stored in the 'flags' member of a
> 'struct drm_i915_gem_exec_object2', and they're defined in two different
> source files, increasing the risk of an accidental clash.
>
> Some flags in this field a
On Thu, Jun 30, 2016 at 04:12:49PM +0100, Dave Gordon wrote:
> Precursor for fix to secure batch execution. We will need to be able to
> retrieve the batch VMA (as well as the batch itself) from the eb list,
> so this patch extracts that part of eb_get_batch() into a separate
> function, and moves
On Wed, Jun 29, 2016 at 12:38:51PM +0100, Chris Wilson wrote:
> Several years ago we made the plan of only having one canonical source
> for i915_pciids.h, the kernel and everyone importing their definitions
> from that. For consistency, we style the intel_device_info after the
> kernel, most notab
On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote:
> On Thu, Jun 30, 2016 at 04:12:49PM +0100, Dave Gordon wrote:
> > Precursor for fix to secure batch execution. We will need to be able to
> > retrieve the batch VMA (as well as the batch itself) from the eb list,
> > so this patch extr
On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote:
> On Thu, 23 Jun 2016, Dave Gordon wrote:
> > On 22/06/16 09:31, Daniel Vetter wrote:
> > No, the *correct* fix is to unify all the firmware loaders we have.
> > There should just be ONE piece of code that can be used to fetch and
> > l
The existing code that accesses the "enable_guc_loading" and
"enable_guc_submission" parameters uses explicit numerical
values for the various possibilities, including in some cases
relying on boolean 0/1 mapping to specific values (which could
be confusing for maintainers).
So this patch just pro
On Wed, Jul 13, 2016 at 02:04:43PM +0200, Daniel Vetter wrote:
> On Tue, Jul 12, 2016 at 03:00:37PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Dell XPS 13 9350 apparently doesn't like it when we use the panel type
> > from OpRegion. The OpRegion panel type (0) tel
On 13/07/16 13:23, Daniel Vetter wrote:
On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote:
From: Dave Gordon
intel_lrc.c has a table of "logical rings" (meaning engines), while
intel_ringbuffer.c has separately open-coded initialisation for each
engine. We can deduplicate this so
On 13/07/16 13:30, Daniel Vetter wrote:
On Fri, Jul 01, 2016 at 05:47:14PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Use it for legacy engine initialization by adding a
intel_ring_default_irqs helper used by individual engines.
Signed-off-by: Tvrtko Ursulin
Not sure this is worth
On 13/07/16 14:16, Tvrtko Ursulin wrote:
On 13/07/16 13:23, Daniel Vetter wrote:
On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote:
From: Dave Gordon
intel_lrc.c has a table of "logical rings" (meaning engines), while
intel_ringbuffer.c has separately open-coded initialisation
From: Ville Syrjälä
Bspec tells us to keep bashing the PCU for up to 3ms when trying to
inform it about an upcoming change in the cdclk frequency. Currently
we only keep at it for 15*10usec (+ whatever delays gets added by
the sandybridge_pcode_read() itself). Let's change the limit to 3ms.
I de
On Tue, 2016-07-12 at 15:00 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Dell XPS 13 9350 apparently doesn't like it when we use the panel
> type
> from OpRegion. The OpRegion panel type (0) tells us to use use low
> vswing for eDP, whereas the VBT panel type (2) tells us
On Wed, Jul 13, 2016 at 02:40:49PM +0200, Daniel Vetter wrote:
> On Wed, Jun 29, 2016 at 12:38:51PM +0100, Chris Wilson wrote:
> > Several years ago we made the plan of only having one canonical source
> > for i915_pciids.h, the kernel and everyone importing their definitions
> > from that. For con
On Wed, Jul 13, 2016 at 04:32:03PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec tells us to keep bashing the PCU for up to 3ms when trying to
> inform it about an upcoming change in the cdclk frequency. Currently
> we only keep at it for 15*10usec (+ whatever delays
== Series Details ==
Series: drm/i915/guc: Protect against HAS_GUC_* returning true values other
than one (rev4)
URL : https://patchwork.freedesktop.org/series/9473/
State : warning
== Summary ==
Series 9473v4 drm/i915/guc: Protect against HAS_GUC_* returning true values
other than one
http:
On Wed, Jul 13, 2016 at 10:33:00PM +0900, James Bottomley wrote:
> On Tue, 2016-07-12 at 15:00 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Dell XPS 13 9350 apparently doesn't like it when we use the panel
> > type
> > from OpRegion. The OpRegion panel type (0) tell
Did try when you submitted the patch...but can't seem to replicate with
latest nightly on other SKLs, and currently do not have access on
the machine that caused it.
On Tue, Jul 12, 2016 at 02:16:50PM +0100, Chris Wilson wrote:
> On Tue, Jul 12, 2016 at 04:10:22PM +0300, Mika Kuoppala wrote:
> > C
On Tue, Jul 12, 2016 at 05:47:02PM +0100, Chris Wilson wrote:
> On Tue, Jul 12, 2016 at 07:24:47PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Prior to gen6 we didn't have per-ring IMR registers, which means that
> > since commit 61ff75ac20ff ("drm/i915: Simplify e
== Series Details ==
Series: drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
SKL
URL : https://patchwork.freedesktop.org/series/9815/
State : failure
== Summary ==
Series 9815v1 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change
request on SKL
http://patchwo
On Wed, 13 Jul 2016, Daniel Vetter wrote:
On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote:
On Thu, 23 Jun 2016, Dave Gordon wrote:
On 22/06/16 09:31, Daniel Vetter wrote:
No, the *correct* fix is to unify all the firmware loaders we have.
There should just be ONE piece of code th
From: Tvrtko Ursulin
Created two common helpers for engine setup and engine init phases
respectively to help with code sharing.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 47 +
drivers/gpu/drm/i915/intel_lrc.c| 17 +++
From: Tvrtko Ursulin
Engine contains dev_priv so need to pass it in.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuff
From: Tvrtko Ursulin
Use more of the shared engine setup data for legacy engine
initialization. This time to simplify the irq initialization
code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(
From: Tvrtko Ursulin
Move the execlist engine setup to vfuncs so that the engine
init loop is clearly split into the mode agnostic and
specific steps.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c | 103 ---
1
From: Dave Gordon
intel_lrc.c has a table of "logical rings" (meaning engines), while
intel_ringbuffer.c has separately open-coded initialisation for each
engine. We can deduplicate this somewhat by using the same first-stage
engine-setup function for both modes.
So here we expose the function t
From: Tvrtko Ursulin
With the unified common engine setup done, and the execlist engine
initialization loop clearly split into two phases, we can eliminate
the separate legacy engine initialization code.
v2: Fix cleanup path for legacy.
v3: Rename constructors. (Chris Wilson)
Signed-off-by: Tvr
From: Tvrtko Ursulin
Common code deserves to be put in a separate file from legacy and
execlists implementation for clarity and ease of maintenance.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 162
On 17/06/16 21:42, Matt Roper wrote:
intel_state->active_crtcs is usually only initialized when doing a
modeset. During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.
v2:
- Don't clob
On Tue, Jul 12, 2016 at 03:59:28PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec says:
> "For DDIA with x4 capability (DDI_BUF_CTL DDIA Lane Capability Control =
> DDIA x4), the I_boost value has to be programmed in both
> tx_blnclegsctl_0 and tx_blnclegsctl_4."
>
On Tue, Jul 12, 2016 at 03:59:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy
> that.
>
> Cc: David Weinehall
> Signed-off-by: Ville Syrjälä
Reviewed-by: David Weinehall
> ---
> drivers/gpu/
On Tue, Jul 12, 2016 at 03:59:29PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Give a proper name for the SKL DDI_BUF_TRANS iboost bit.
>
> Cc: David Weinehall
> Signed-off-by: Ville Syrjälä
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1
On 07/07/16 09:41, Chris Wilson wrote:
In the future, we will want to add annotations to the i915_gem_active
struct. The API is thus expanded to hide direct access to the contents
of i915_gem_active and mediated instead through a number of helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu
== Series Details ==
Series: series starting with [1/7] drm/i915: unify first-stage engine struct
setup
URL : https://patchwork.freedesktop.org/series/9821/
State : success
== Summary ==
Series 9821v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9821/revisions/1
On Wed, Jul 13, 2016 at 04:40:03PM +0100, Tvrtko Ursulin wrote:
>
> On 07/07/16 09:41, Chris Wilson wrote:
> >In the future, we will want to add annotations to the i915_gem_active
> >struct. The API is thus expanded to hide direct access to the contents
> >of i915_gem_active and mediated instead t
On Wed, Jul 13, 2016 at 04:03:35PM +0100, Tvrtko Ursulin wrote:
> From: Dave Gordon
>
> intel_lrc.c has a table of "logical rings" (meaning engines), while
> intel_ringbuffer.c has separately open-coded initialisation for each
> engine. We can deduplicate this somewhat by using the same first-sta
On Wed, Jul 13, 2016 at 04:03:40PM +0100, Tvrtko Ursulin wrote:
> + /*
> + * Catch failures to update intel_engines table when the new engines
> + * are added to the driver by a warning and disabling the forgotten
> + * engines.
> + */
> + if (WARN_ON(mask != INTEL_INFO(
Since the suspend_work can arm itself if the console_lock() is currently
held elsewhere, simply calling flush_work() doesn't guarantee that the
work is idle upon return. To do so requires using cancel_work_sync().
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Mika Kuoppala
---
drivers/gpu/
If the fbdev probing fails, and in our error path we fail to clear the
dev_priv->fbdev, then we can try and use a dangling fbdev pointer, and
in particular a NULL fb. This could also happen in pathological cases
where we try to operate on the fbdev prior to it being probed.
Reported-by: Maarten La
On Tue, Jul 12, 2016 at 11:21:39AM -0700, Matt Roper wrote:
> On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if
On Wed, Jul 13, 2016 at 11:08:46AM -0700, Matt Roper wrote:
> On Tue, Jul 12, 2016 at 11:21:39AM -0700, Matt Roper wrote:
> > On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > > Since the watermark calculations for Skylake are still broken, we're apt
> > > to hitting underruns very easily
On Wed, Jul 13, 2016 at 09:12:09PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 13, 2016 at 11:08:46AM -0700, Matt Roper wrote:
> > On Tue, Jul 12, 2016 at 11:21:39AM -0700, Matt Roper wrote:
> > > On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > > > Since the watermark calculations for Skyl
On Wed, Jul 13, 2016 at 11:17:52AM -0700, Matt Roper wrote:
> On Wed, Jul 13, 2016 at 09:12:09PM +0300, Ville Syrjälä wrote:
> > We have wait_for()/_wait_for() for polling stuff.
>
> Those just block until a condition becomes true, right? In this case my
> understanding from the bspec is that we
On Wed, Jul 13, 2016 at 04:32:03PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec tells us to keep bashing the PCU for up to 3ms when trying to
> inform it about an upcoming change in the cdclk frequency. Currently
> we only keep at it for 15*10usec (+ whatever delays
On Tue, Jul 12, 2016 at 01:46:21PM +0100, Chris Wilson wrote:
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer an
2016-07-12 Chris Wilson :
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer and queue hardware operations like fl
On Wed, Jul 13, 2016 at 05:29:21PM -0300, Gustavo Padovan wrote:
> 2016-07-12 Chris Wilson :
>
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM buffers (on the dma-buf), the use
2016-07-12 19:21 GMT+01:00 Matt Roper :
> On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this was fixed, it'
On 07/13/2016 06:04 PM, Deak, Imre wrote:
Hi Yakui,
thanks for taking a look at these, see my comment below.
On ke, 2016-07-13 at 10:22 +0800, Zhao Yakui wrote:
On 07/01/2016 09:40 PM, Deak, Imre wrote:
The purpose for each MOCS entry isn't well defined atm. Defining these
is important to rem
Ops, I had forgot to reply to this one although I have reviewed!
Feel free to use
Reviewed-by: Rodrigo Vivi
On Tuesday, July 5, 2016, Shashank Sharma wrote:
> This patch adds lspcon support in dp_dual_mode helper.
> lspcon is essentially a dp->hdmi dongle with dual personality.
>
> LS mode: It
== Series Details ==
Series: series starting with [1/2] drm/i915/fbdev: Drain the suspend worker on
retiring
URL : https://patchwork.freedesktop.org/series/9826/
State : success
== Summary ==
Series 9826v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9826/revisi
83 matches
Mail list logo
