On Wed, Dec 16, 2015 at 01:40:53PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> GuC supports different scheduling policies for its four internal
> queues. Currently these have been set to the same default values
> as KMD_NORMAL queue.
>
> Particularly POLICY_MAX_NUM_WI is set to 15 to mat
On Mon, 2015-12-14 at 12:50 +0200, Jani Nikula wrote:
> The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
> mailbox may specify an alternate location for VBT instead of mailbox #4.
> Use the alternate location if available and valid, falling back to
> mailbox #4 otherwise.
>
Tes
On Thu, Dec 17, 2015 at 10:59:13AM +0530, Praveen Paneri wrote:
> When the system is running low on memory, gem shrinker is invoked.
> In this process objects will be unbinded from GTT.
> For tiled objects, access to fence registers could be required while
> unbinding them. That requires a resume o
On Wed, Dec 16, 2015 at 01:40:52PM -0800, yu@intel.com wrote:
> + page = i915_gem_object_get_page(obj, 0);
> + ads = kmap_atomic(page);
> + if (!ads) {
kmap_atomic() cannot fail.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
Reviewed-by: Sagar Arun Kamble
On 12/16/2015 10:48 PM, Mika Kuoppala wrote:
commit 344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
failed to take into account that the same workaround is used in guc
when forcewake is sampled.
Wrap the condition check inside a macro and u
When the system is running low on memory, gem shrinker is invoked.
In this process objects will be unbinded from GTT.
For tiled objects, access to fence registers could be required while
unbinding them. That requires a resume of gfx device, if suspended,
in the shrinker path. This intermediate resu
On 12/16/2015 7:16 PM, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 04:18:05PM +0530, Sonika Jindal wrote:
Call the encoders, call the hot_plug if it is registered.
This is required for connected boot and resume cases to generate
fake hpd resulting in reading of edid.
Removing the initial sdvo
Original value of 32 blocks is not sufficient when using cursor size of
256x256 causing FIFO underruns when the reworked wm
caluclations in
commit 024c9045221fe45482863c47c4b4c47d37f97cbf
Author: Matt Roper
Date: Thu Sep 24 15:53:11 2015 -0700
drm/i915/skl: Eliminate usage of pipe_wm_param
It is unclear if this is even required on BXT.
Cc: Imre Deak
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 519cea32..0d
From: Alex Dai
The device struct_mutex needs to be held before releasing any GEM
objects allocated by GuC.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/
From: Rafael J. Wysocki
Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 'true' if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time ('false' will be returned
otherwise).
This is
Sure. In next patch set will get rid of jiffies altogether and will use
getboottime() instead of do_gettimeofday() for panel_power_cycle_delay.
Does this make sense?
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, December 16, 2015 2:56 AM
On Wed, 2015-12-16 at 12:18 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 08:10:37PM +0200, Imre Deak wrote:
> > In some cases we want to check whether we hold an RPM wakelock
> > reference
> > for the whole duration of a sequence. To achieve this add a new RPM
> > atomic sequence
> > count
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored duri
From: Dave Gordon
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
For: VIZ-2021
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915
From: Alex Dai
GuC needs to know which registers and how they will be saved and
restored during event such as engine reset or power state changes.
For now only the base address of reg state is initialized. The
detail register table probably will be setup in future GuC TDR or
Preemption patch seri
From: Alex Dai
Set ADS enabling flag during GuC init.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 4740949..625272f4 100644
From: Alex Dai
GuC supports different scheduling policies for its four internal
queues. Currently these have been set to the same default values
as KMD_NORMAL queue.
Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
maximum submit queue numbers to avoid an out-of-space problem.
T
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is a chunk of
memory created by driver to share with GuC. This series creates the GuC ADS
object and setup some basic settings for it.
Alex Dai (4):
drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation
On Wed, Dec 16, 2015 at 10:02:29PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 03:19:39PM +, Chris Wilson wrote:
> > +static void gen8_ggtt_insert_entries__BKL(struct i915_address_space *vm,
> > + struct sg_table *st,
> > +
On Wed, Nov 18, 2015 at 03:19:39PM +, Chris Wilson wrote:
> There was a silent conflict between
>
> commit 0a878716265e9af9f697264dc2e858fcc060d833
> Author: Daniel Vetter
> Date: Thu Oct 15 14:23:01 2015 +0200
>
> drm/i915: restore ggtt double-bind avoidance
>
> and
>
> commit 5bab6
From: Alex Dai
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to ri
On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
> On 16/12/15 18:57, Chris Wilson wrote:
> >On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
> >>Some of the LRC-specific context-destruction code has to special-case
> >>the global default context, because the HWSP is part of
On 16/12/15 18:57, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
Some of the LRC-specific context-destruction code has to special-case
the global default context, because the HWSP is part of that context. At
present it deduces it indirectly by checking for the
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
> Some of the LRC-specific context-destruction code has to special-case
> the global default context, because the HWSP is part of that context. At
> present it deduces it indirectly by checking for the backpointer from
> the engine to the
A collection of small patches to fix some incorrect failure paths and
generally tidy up the corresponding teardown code, mostly relating to
contexts, and in particular the global default context that's created
at startup.
These should make subsequent reorganisation of other startup/teardown
code e
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypasted from legacy ringbuffer version at creation.
Si
We set up engines in forwards order, so some things (notably the
default context) are "owned" by engine 0 (the render engine, aka "RCS").
For symmetry and to make sure such shared objects don't disappear too
early, we should generally run teardown loops in the reverse order,
so that engine 0 is pro
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.
2. Fix the error path in intel_init_ring_buffer(), which already
called intel_destroy_ringbuffer_obj(),
Some of the LRC-specific context-destruction code has to special-case
the global default context, because the HWSP is part of that context. At
present it deduces it indirectly by checking for the backpointer from
the engine to the context, but that's an unsafe assumption if the setup
and teardown c
On ke, 2015-12-16 at 19:26 +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 03:53:32PM +0200, Imre Deak wrote:
> > Currently we get a permanent RPM reference if the platform doesn't
> > support RPM, but this is implicit via the dependency of the power
> > well
> > functionality on RPM the RPM
On ke, 2015-12-16 at 19:31 +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 03:21:00PM +0200, Imre Deak wrote:
> > On ke, 2015-12-16 at 12:12 +0100, Daniel Vetter wrote:
> > > On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre
Chris Wilson noted that the change introduced by i-g-t:
commit 5c07135b7bd2 ("tools/null_state/gen9: Send all components in VF state")
had not found it's way into the kernel side.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_renderstate_gen9.c | 4 ++--
1 file ch
On Wed, Dec 16, 2015 at 03:53:32PM +0200, Imre Deak wrote:
> Currently we get a permanent RPM reference if the platform doesn't
> support RPM, but this is implicit via the dependency of the power well
> functionality on RPM the RPM support, see
> sanitize_disable_power_well_option(). Make things mo
On Wed, Dec 16, 2015 at 05:16:19PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 14/12/15 11:36, Chris Wilson wrote:
> >With the introduction of requests, we amplified the number of atomic
> >refcounted objects we use and update every execbuffer; from none to
> >several references, and a set of ref
On Wed, Dec 16, 2015 at 03:21:00PM +0200, Imre Deak wrote:
> On ke, 2015-12-16 at 12:12 +0100, Daniel Vetter wrote:
> > On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > > > All platforms with power well support have
On 16/12/15 10:09, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 10:00:44AM +, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 09:54:47AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 10:18:35PM +, Chris Wilson wrote:
igt likes to inject GPU hangs into its command streams. However, as
On Wed, Dec 16, 2015 at 04:28:36PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 02:51:20PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> > > On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in
Do what the comment says and don't enable coarse power gating
is rc6 is disabled. With this the check then becomes identical
with the guc side check for forcewake sampling with same
workaround.
Cc: Dave Gordon
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file chan
commit 344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
failed to take into account that the same workaround is used in guc
when forcewake is sampled.
Wrap the condition check inside a macro and use it in both places
to fix the guc side scope.
Cc: Dave Gordon
Cc: Sagar Arun
Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.
Cc: Laurent Pinchart
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gp
On Wed, Dec 16, 2015 at 05:15:18PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 06:13:44PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 06:10:00PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > I broke AVI/HDMI/SPD infoframes on HSW+ wit
On Wed, Dec 16, 2015 at 06:13:44PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 06:10:00PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
> > safety changes. We were supposed to check that the inf
On Wed, Dec 16, 2015 at 06:10:00PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
> safety changes. We were supposed to check that the infoframe data
> register is valid before writing the infoframe data, but th
From: Ville Syrjälä
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
safety changes. We were supposed to check that the infoframe data
register is valid before writing the infoframe data, but the check
ended up inverted, and so in practice we never wrote or enabled
these infoframes.
On Wed, 16 Dec 2015, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 03:04:19PM +0200, Jani Nikula wrote:
>> Specify the maximum number of letters to print from the potentially
>> unterminated buffer, not the minimum. While at it, use sizeof instead of
>> a magic number.
>>
>> Signed-off-by: Jani N
I gave a try to this patch on Braswell.
A couple of comments below.
On 03/12/15 11:36, Shashank Sharma wrote:
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach d
On Wed, Dec 16, 2015 at 02:51:20PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Gen2 doesn't have a hardware frame counter,
On Wed, Dec 16, 2015 at 03:04:21PM +0200, Jani Nikula wrote:
> Slightly cleaner with early exit.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx
On Wed, Dec 16, 2015 at 03:04:20PM +0200, Jani Nikula wrote:
> dev_priv is the new black. Or something.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
In
On Wed, Dec 16, 2015 at 03:04:19PM +0200, Jani Nikula wrote:
> Specify the maximum number of letters to print from the potentially
> unterminated buffer, not the minimum. While at it, use sizeof instead of
> a magic number.
>
> Signed-off-by: Jani Nikula
Wow that's a widely underused feature, on
On Wed, Dec 16, 2015 at 03:04:18PM +0200, Jani Nikula wrote:
> The intel_bios.h header doesn't even need it, but other headers included
> from i915_drv.h do. Let's untangle the mess a bit.
>
> Signed-off-by: Jani Nikula
Since we dereference struct drm_device inside i915_drv.h, we need this,
and
On Wed, Dec 16, 2015 at 01:51:46PM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 03:12:57PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> > > On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > > > On Sat, Dec 12, 2015 at 08:02
On Wed, Dec 16, 2015 at 02:49:51PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 03:04:47PM +0200, Mika Kahola wrote:
> > On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> > > On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > > > Disable DP fast link training if DP li
Currently we get a permanent RPM reference if the platform doesn't
support RPM, but this is implicit via the dependency of the power well
functionality on RPM the RPM support, see
sanitize_disable_power_well_option(). Make things more explicit by
taking an RPM reference only for the purpose of keep
On Wed, Dec 16, 2015 at 03:12:57PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> > On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > > On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> > > > Wean drv_hangman off the atro
On Wed, Dec 16, 2015 at 03:04:47PM +0200, Mika Kahola wrote:
> On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > > Disable DP fast link training if DP link configuration
> > > changes. If one of the DP link parameters i.e. l
On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> So there's 3 competing proposals for what wait_ioctl should do wrt
> -EIO:
>
> - return -EIO when the gpu is wedged. Not terribly useful for
> userspace since it might race with a hang and then there's no
> guarantee that a subse
Currently we get a permanent RPM reference if the platform doesn't
support RPM, but this is implicit via the dependency of the power well
functionality on RPM the RPM support, see
sanitize_disable_power_well_option(). Make things more explicit by
taking an RPM reference only for the purpose of keep
On Wed, Dec 16, 2015 at 04:18:05PM +0530, Sonika Jindal wrote:
> Call the encoders, call the hot_plug if it is registered.
> This is required for connected boot and resume cases to generate
> fake hpd resulting in reading of edid.
> Removing the initial sdvo hot_plug call too so that it will be cal
On ke, 2015-12-16 at 15:39 +0200, Joonas Lahtinen wrote:
> On ke, 2015-12-16 at 13:02 +, Chris Wilson wrote:
> > On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> > > On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > > > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wro
On ke, 2015-12-16 at 13:02 +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> > On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > > > +static inline void
> > > > +assert_rpm_device_not_su
On ke, 2015-12-16 at 12:12 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > > All platforms with power well support have runtime PM support, so
> > > simplify things by explicitly disablin
On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> > > Wean drv_hangman off the atrocious stop_rings and use a real GPU hang
> > > instead.
> > >
> > > Si
Slightly cleaner with early exit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 25edfc062f
The intel_bios.h header doesn't even need it, but other headers included
from i915_drv.h do. Let's untangle the mess a bit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --gi
Specify the maximum number of letters to print from the potentially
unterminated buffer, not the minimum. While at it, use sizeof instead of
a magic number.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
dev_priv is the new black. Or something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 22 +-
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gp
On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > Disable DP fast link training if DP link configuration
> > changes. If one of the DP link parameters i.e. link
> > bandwidth, lane count, rate selection, port clock or bpp
> >
On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > > +static inline void
> > > +assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> > > +{
> > > + WARN
On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > As a preparation for follow-up patches add a new helper that checks
> > whether we hold an RPM reference, since this is what we want most
> > of
> > the cases. Atm this helper will
On Wed, Dec 16, 2015 at 11:06:20AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 10:52:06AM +0100, Daniel Vetter wrote:
> > On Fri, Dec 11, 2015 at 11:33:05AM +, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> >
On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Gen2 doesn't have a hardware frame counter, so let's use the sw
> > counter value instead.
> >
> > Testcase: igt/kms_pip
On ke, 2015-12-16 at 11:07 +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 01:00:38PM +0200, Joonas Lahtinen wrote:
> > On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > > v2-v3:
> > > - unchanged
> > > v4:
> > > - keep the corresponding check in the get helper (Chris)
> >
> > This is pu
On Tue, 2015-12-15 at 10:26 +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 12:22:40PM +0200, Mika Kahola wrote:
> > On Tue, 2015-11-24 at 11:29 +0100, Maarten Lankhorst wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 3c4
On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> Disable DP fast link training if DP link configuration
> changes. If one of the DP link parameters i.e. link
> bandwidth, lane count, rate selection, port clock or bpp
> changes the link training does no longer apply the
> previously co
On Wed, 16 Dec 2015, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 12:48:16PM +0200, Jani Nikula wrote:
>> Use the for_each_intel_* macros for iterating intel_encoder,
>> intel_connector, and intel_crtc. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>
> Trusting that gcc will scream a
On Tue, Dec 15, 2015 at 05:50:36PM +, Dave Gordon wrote:
> On 15/12/15 14:54, Chris Wilson wrote:
> >On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote:
> >>On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
> >>>From: Ankitprasad Sharma
> >>>
> >>>Using stolen backed objects as
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link trainin
On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> As a preparation for follow-up patches add a new helper that checks
> whether we hold an RPM reference, since this is what we want most of
> the cases. Atm this helper will only check for the HW suspended state, a
> follow-up patch will d
This is used when reading Display Control capability Registers on the sink
device.
cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..92d9a52
These patches add support for Backlight Control using DPCD registers
on eDP displays.
Yetunde Adebisi (2):
drm/dp: Add definition for Display Control DPCD Registers capability
size
drm/i915: Add Backlight Control using DPCD for eDP connectors (v4)
drivers/gpu/drm/i915/Makefile
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_
On Wed, Dec 16, 2015 at 12:48:16PM +0200, Jani Nikula wrote:
> Use the for_each_intel_* macros for iterating intel_encoder,
> intel_connector, and intel_crtc. No functional changes.
>
> Signed-off-by: Jani Nikula
Trusting that gcc will scream at you if you fumbled types:
Reviewed-by: Daniel Vet
On Tue, Dec 15, 2015 at 08:10:37PM +0200, Imre Deak wrote:
> In some cases we want to check whether we hold an RPM wakelock reference
> for the whole duration of a sequence. To achieve this add a new RPM atomic
> sequence
> counter that we increment any time the wakelock refcount drops to zero.
>
On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > All platforms with power well support have runtime PM support, so
> > simplify things by explicitly disabling power well support on platforms
> > without runtime PM suppor
On Wed, Dec 16, 2015 at 11:46:50AM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 12:30:54PM +, Chris Wilson wrote:
> > On Tue, Dec 15, 2015 at 02:01:24PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 15, 2015 at 11:1
On Wed, Dec 16, 2015 at 12:58:33PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 11:23:54AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The crc code assumes that the printed frame
On Wed, Dec 16, 2015 at 01:00:38PM +0200, Joonas Lahtinen wrote:
> On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > v2-v3:
> > - unchanged
> > v4:
> > - keep the corresponding check in the get helper (Chris)
>
> This is put helper you patched, so I think the above message is
> incorrect.
It
On Wed, Dec 16, 2015 at 11:23:54AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The crc code assumes that the printed frame counter value takes
> > exactly 8 characters. The counter is a 32bit value, s
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> In some cases we want to check whether we hold an RPM wakelock
> reference
> for the whole duration of a sequence. To achieve this add a new RPM
> atomic sequence
> counter that we increment any time the wakelock refcount drops to
> zero.
> Check
On Wed, Dec 16, 2015 at 10:52:06AM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 11:33:05AM +, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d7bbd015de35..875bdf814d73 100644
> > --- a/drivers/gpu/drm/i915
On ke, 2015-12-16 at 11:42 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 01:36:07PM +0200, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> > > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> > > > When we drop caches, this debugfs entry does hardware access
> > > > la
On Tue, Dec 15, 2015 at 05:33:38PM +0200, Jani Nikula wrote:
> We've been accumulating code across the driver that depends on the VBT
> specific structures and defines. The VBT is an uncontrollable
> beast. Encourage encapsulation of the VBT data by hiding the structures
> and defines in a private
On ke, 2015-12-16 at 12:54 +0200, Joonas Lahtinen wrote:
> On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > We can make the RPM dependency on RC6 explciit in the code by
Typo, s/explciit/explicit/
> > taking
> > an
> > actual RPM reference, instead of avoiding to drop the initial one.
> >
From: Shashank Sharma
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every d
Call the encoders, call the hot_plug if it is registered.
This is required for connected boot and resume cases to generate
fake hpd resulting in reading of edid.
Removing the initial sdvo hot_plug call too so that it will be called
just once from this loop.
v2: Schedule a work function to call hot
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> v2-v3:
> - unchanged
> v4:
> - keep the corresponding check in the get helper (Chris)
This is put helper you patched, so I think the above message is
incorrect.
Regards, Joonas
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel
1 - 100 of 145 matches
Mail list logo
