Unify function structure as any other *_hz_to_pwm() functions are
structured.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_panel.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 414
Let's switch to use private dev_priv instead of dev when detecting
intel panels.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c| 3 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 4 ++--
drivers/gpu/drm/i915/intel_panel.c | 4 +---
4 files
Let's switch to use dev_priv instead of dev when calling
intel_find_panel_downclock() function.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c| 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_panel.c | 6 +++---
3 files changed, 5 insertions(+), 5
Proposal for cleanup. Let's favor dev_priv instead of dev in intel_panel.c
functions. Cleanup for HZ to PWM functions to unify the look and feel of
these functions.
Mika Kahola (3):
drm/i915: Intel panel detection cleanup
drm/i915: Intel panel downclock cleanup
drm/i915: Hz to PWM for i965
On Mon, Dec 12, 2016 at 01:23:46PM +, Emil Velikov wrote:
> On 10 December 2016 at 21:52, Daniel Vetter wrote:
> > No one looks at the major/minor versions except the unique/busid
> > stuff. If we protect that with the master_mutex (since it also affects
> > the unique of each master, oh well)
On Mon, Dec 12, 2016 at 09:50:29AM +, Chris Wilson wrote:
> On Sat, Dec 10, 2016 at 10:52:54PM +0100, Daniel Vetter wrote:
> > With the last round of changes all ioctls called by modern drivers now
> > have their own locking. Everything else is only allowed for legacy
> > drivers and hence the
On Mon, Dec 12, 2016 at 09:39:55AM +, Chris Wilson wrote:
> On Sat, Dec 10, 2016 at 10:52:52PM +0100, Daniel Vetter wrote:
> > No one looks at the major/minor versions except the unique/busid
> > stuff. If we protect that with the master_mutex (since it also affects
> > the unique of each maste
On Tue, Dec 13, 2016 at 07:42:54AM +, Saarinen, Jani wrote:
> > == Series Details ==
> >
> > Series: drm/i915: VLV/CHV two-stage watermarks
> > URL : https://patchwork.freedesktop.org/series/16712/
> > State : warning
> >
> > == Summary ==
> >
> > Series 16712v1 drm/i915: VLV/CHV two-stage
== Series Details ==
Series: Various cleanups on intel_panel.c
URL : https://patchwork.freedesktop.org/series/16731/
State : failure
== Summary ==
Series 16731v1 Various cleanups on intel_panel.c
https://patchwork.freedesktop.org/api/1.0/series/16731/revisions/1/mbox/
Test drv_module_reload:
On Tue, 13 Dec 2016, Mika Kahola wrote:
> Proposal for cleanup. Let's favor dev_priv instead of dev in intel_panel.c
> functions. Cleanup for HZ to PWM functions to unify the look and feel of
> these functions.
>
> Mika Kahola (3):
> drm/i915: Intel panel detection cleanup
> drm/i915: Intel pa
On Fri, Dec 09, 2016 at 01:04:12PM -0500, Sean Paul wrote:
> On Fri, Dec 9, 2016 at 9:19 AM, Daniel Vetter wrote:
> > It's deprecated and only should be used by drivers which still use
> > drm_platform_init, not by anyone else.
> >
> > And indeed it's entirely unused and can be nuked.
> >
> > This
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the new hol
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> If we remember that node_list is a circular list containing the fake
> head_node, we can use a simple list_next_entry() and skip the NULL check
> for the allocated check against the head_node.
>
> Signed-off-by: Chris Wilson
I'm not sure if
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
> for walking the list of nodes safe against removal.
>
> Signed-off-by: Chris Wilson
> +#define __drm_mm_nodes(mm) (&(mm)->head_node.node_list)
Not static inline f
On Thu, Dec 08, 2016 at 11:55:34PM +, Chris Wilson wrote:
> On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> > From: Peter Antoine
> >
> > This patch will allow for getparams to return the status of the HuC.
> > As the HuC has to be validated by the GuC this patch uses the validate
On 13/12/16 05:35 PM, Daniel Vetter wrote:
> On Mon, Dec 12, 2016 at 01:23:46PM +, Emil Velikov wrote:
>> On 10 December 2016 at 21:52, Daniel Vetter wrote:
>>> No one looks at the major/minor versions except the unique/busid
>>> stuff. If we protect that with the master_mutex (since it also a
On Tue, Dec 13, 2016 at 10:42 AM, Michel Dänzer wrote:
>> Hm, I thought the grand plan is to use -modesetting almost everywhere and
>> forget about all the others?
>
> Maybe if you mean s/grand plan/pipe dream/ ...
I said "almost everywhere", not "everywhere". I'm fully aware that
there's tons of
On Mon, 2016-12-12 at 22:56 +0100, Hans de Goede wrote:
> On my cherrytrail tablet with axp288 pmic, just doing a bunch of
> repeated
> reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet
> in
> 1 - 3 runs guaranteed.
>
> This seems to be causes by the cpu trying to enter C6 or
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> First we introduce a smattering of infrastructure for writing selftests.
> The idea is that we have a test module that exercises a particular
> portion of the exported API, and that module provides a set of tests
> that can either be run as an
Currently in dual display connected boot scenarios, minimum of the resolutions
is taken for fb width and height as reference. Based on this resolution, other
modes are pruned.
Example Scenario: If DSI mode is 2560x1440 and HDMI is 1920x1080, during the
probing
the fb width and height is set to ma
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Simple first test to just exercise initialisation of struct drm_mm.
>
> Signed-off-by: Chris Wilson
> + drm_mm_for_each_hole(hole, &mm, start, end) {
> + if (start != 0 || end != 4096) {
> + pr_err("emp
On Tue, Dec 13, 2016 at 11:58:54AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
> > @@ -0,0 +1,47 @@
> > +/*
> > + * Test cases for the drm_mm range manager
> > + */
> > +
> > +#define pr_fmt(fmt) "drm_mm: "
On Mon, Dec 12, 2016 at 01:29:48PM +0100, Tomeu Vizoso wrote:
> In preparation to using a generic API in the DRM core for continuous CRC
> generation, move the related code out of i915_debugfs.c into a new file.
>
> Eventually, only the Intel-specific code will remain in this new file.
>
> v2: Re
On Tue, 13 Dec 2016, Vidya Srinivas wrote:
> Currently in dual display connected boot scenarios, minimum of the resolutions
> is taken for fb width and height as reference. Based on this resolution, other
> modes are pruned.
>
> Example Scenario: If DSI mode is 2560x1440 and HDMI is 1920x1080, dur
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> For testing, we want a reproducible PRNG, a plain linear congruent
> generator is suitable for our very limited selftests.
>
> Signed-off-by: Chris Wilson
> +++ b/drivers/gpu/drm/lib/drm_rand.c
> @@ -0,0 +1,51 @@
> +#include
> +#include
== Series Details ==
Series: drm: Fix for invalid pruning of modes in dual display cases
URL : https://patchwork.freedesktop.org/series/16735/
State : success
== Summary ==
Series 16735v1 drm: Fix for invalid pruning of modes in dual display cases
https://patchwork.freedesktop.org/api/1.0/seri
On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote:
> Currently in dual display connected boot scenarios, minimum of the resolutions
> is taken for fb width and height as reference. Based on this resolution, other
> modes are pruned.
>
> Example Scenario: If DSI mode is 2560x1440 and H
c9c4b6f6c283 ("drm/i915: fix swizzle detection for gen3") added a
complicated check for I915G/I945G. Pineview and other gen3 devices match
IS_MOBILE() anyway. Simplify.
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
1 file changed, 1 insertio
On Mon, Dec 12, 2016 at 11:58:24AM +, Tvrtko Ursulin wrote:
>
> On 09/12/2016 15:05, Chris Wilson wrote:
> >Some object retain an extra pin whilst they are active (e.g. contexts).
> >This excludes them from being considered for eviction unless we idle the
> >GPU. If before we look at the activ
On Thu, 08 Dec 2016, Madhav Chauhan wrote:
> From: Deepak M
>
> Signed-off-by: Deepak M
> Signed-off-by: Madhav Chauhan
> ---
> drivers/gpu/drm/i915/i915_reg.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_
== Series Details ==
Series: drm/i915: simplify check for I915G/I945G in bit 6 swizzling detection
URL : https://patchwork.freedesktop.org/series/16738/
State : failure
== Summary ==
Series 16738v1 drm/i915: simplify check for I915G/I945G in bit 6 swizzling
detection
https://patchwork.freedes
Hi,
On 13-12-16 10:56, Andy Shevchenko wrote:
On Mon, 2016-12-12 at 22:56 +0100, Hans de Goede wrote:
On my cherrytrail tablet with axp288 pmic, just doing a bunch of
repeated
reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet
in
1 - 3 runs guaranteed.
This seems to be caus
From: Tvrtko Ursulin
A few details to hopefully make a very hot function a tiny bit
more efficient:
1. Cast VM pointers before substraction to save the compiler
doing a smart one which includes multiplication.
2. Use smaller type for comparison since we only care about
the sign.
3.
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> To test whether there are any nodes allocated within the range manager,
> we merely have to ask whether the node_list is empty.
>
> Signed-off-by: Chris Wilson
For documentation purposes add "Since commit ..." to the commit
message?
Review
On Tue, 2016-12-13 at 13:21 +0100, Hans de Goede wrote:
> Hi,
>
> On 13-12-16 10:56, Andy Shevchenko wrote:
> > On Mon, 2016-12-12 at 22:56 +0100, Hans de Goede wrote:
> > > On my cherrytrail tablet with axp288 pmic, just doing a bunch of
> > > repeated
> > > reads from the pmic, e.g. "i2cdump -y
Thanks Jonathan!
On 12 December 2016 at 01:14, Jonathan Corbet wrote:
> On Sun, 11 Dec 2016 18:35:42 +0100
> Daniel Vetter wrote:
>
>> > Here's a thought, though: how about if we slip in a little version of
>> > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the
>> > rest o
On Tue, Dec 13, 2016 at 12:22:18PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A few details to hopefully make a very hot function a tiny bit
> more efficient:
>
> 1. Cast VM pointers before substraction to save the compiler
> doing a smart one which includes multiplication.
In
== Series Details ==
Series: drm/i915: Optimise VMA lookup slightly
URL : https://patchwork.freedesktop.org/series/16740/
State : success
== Summary ==
Series 16740v1 drm/i915: Optimise VMA lookup slightly
https://patchwork.freedesktop.org/api/1.0/series/16740/revisions/1/mbox/
Test gem_ringf
Hi,
On 12/12/2016 4:04 PM, Maarten Lankhorst wrote:
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall ba
On Mon, Dec 12, 2016 at 11:06:19PM +0200, Imre Deak wrote:
> On Mon, 2016-12-12 at 16:21 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > VLV apparently gets upset if the PPS for a pipe currently driving an
> > external DP port gets used for VDD stuff on another eDP por
On 13/12/2016 12:41, Chris Wilson wrote:
On Tue, Dec 13, 2016 at 12:22:18PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A few details to hopefully make a very hot function a tiny bit
more efficient:
1. Cast VM pointers before substraction to save the compiler
doing a smart one whi
On Tue, Dec 13, 2016 at 01:30:19PM +, Tvrtko Ursulin wrote:
>
> On 13/12/2016 12:41, Chris Wilson wrote:
> >On Tue, Dec 13, 2016 at 12:22:18PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>A few details to hopefully make a very hot function a tiny bit
> >>more efficient:
> >>
On 12/13/2016 11:56 AM, Andy Shevchenko wrote:
On Mon, 2016-12-12 at 22:56 +0100, Hans de Goede wrote:
On my cherrytrail tablet with axp288 pmic, just doing a bunch of
repeated
reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet
in
1 - 3 runs guaranteed.
This seems to be caus
On 12/12/2016 11:56 PM, Hans de Goede wrote:
The cherrytrail punit has the pmic i2c bus access semaphore at a
different register address.
Signed-off-by: Hans de Goede
Reviewed-by: Takashi Iwai
Tested-by: Takashi Iwai
Reviewed-by: Andy Shevchenko
---
Changes in v2:
-Adjust for accessor_flags
Op 13-12-16 om 14:01 schreef Archit Taneja:
> Hi,
>
> On 12/12/2016 4:04 PM, Maarten Lankhorst wrote:
>> Do something similar to vc4, only allow updating the cursor state
>> in-place through a fastpath when the watermarks are unaffected. This
>> will allow cursor movement to be smooth, but changing
On Mon, 05 Dec 2016, Mika Kahola wrote:
> From: Jani Nikula
>
> Request the GPIO by index through the consumer API. For now, use a quick
> hack to store the already requested ones, simply because I have no idea
> whether this actually works or not, and I have no way to test it.
>
> v2: switch *NU
Op 09-12-16 om 09:25 schreef Daniel Vetter:
> On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
>>> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
Atomic drivers may set properties lik
On Thu, 08 Dec 2016, Manasi Navare wrote:
> Daniel, can we merge this patch?
Pushed this one to dinq, thanks for the patch.
BR,
Jani.
> It has no dependency on other link train patches,
> it is just a clean up for the existing driver code that
> uses max link rate and lane count values.
> Othe
On Fri, 09 Dec 2016, Jani Nikula wrote:
> On Fri, 09 Dec 2016, Manasi Navare wrote:
>> If link training fails, then we need to fallback to lower
>> link rate first and if link training fails at RBR, then
>> fallback to lower lane count.
>> This function finds the next lower link rate/lane count
>
From: Tvrtko Ursulin
Cast VM pointers before substraction to save the compiler
doing a smart one which includes multiplication.
v2: Only keep the first optimisation and prettify it. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.h | 12 +++
On 13/12/2016 13:41, Chris Wilson wrote:
On Tue, Dec 13, 2016 at 01:30:19PM +, Tvrtko Ursulin wrote:
On 13/12/2016 12:41, Chris Wilson wrote:
On Tue, Dec 13, 2016 at 12:22:18PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A few details to hopefully make a very hot function a tiny
On Tue, Dec 13, 2016 at 02:37:27PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Cast VM pointers before substraction to save the compiler
> doing a smart one which includes multiplication.
>
> v2: Only keep the first optimisation and prettify it. (Chris Wilson)
>
> Signed-off-by: Tvr
On Tue, 13 Dec 2016, Chris Wilson wrote:
> On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote:
>> Currently in dual display connected boot scenarios, minimum of the
>> resolutions
>> is taken for fb width and height as reference. Based on this resolution,
>> other
>> modes are pruned
On Sat, 10 Dec 2016, Manasi Navare wrote:
> This patch does not change anything functionally, just cleans up
> the DP compliance related variables and stores them all together
> in a separate struct intel_dp_compliance. There is another struct
> intel_dp_compliance_data to store all the test data.
On ti, 2016-12-13 at 10:21 +, Chris Wilson wrote:
> On Tue, Dec 13, 2016 at 11:58:54AM +0200, Joonas Lahtinen wrote:
> >
> > This could be build time, depending on the intended use.
>
> I was thinking module param for the seed, just in case we want different
> patterns.
As discussed in IRC, g
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
> validation checking using BUG_ON. Ideally these paths should all be
> exercised by CI selftests (with the asserts enabled).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joon
Hey Chris
On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson wrote:
> For testing, we want a reproducible PRNG, a plain linear congruent
> generator is suitable for our very limited selftests.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/Kconfig| 5 +
> drivers/gpu/drm/Makef
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The scan state occupies a large proportion of the struct drm_mm and is
> rarely used and only contains temporary state. That makes it suitable to
> moving to its struct and onto the stack of the callers.
>
> Signed-off-by: Chris Wilson
>
On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann wrote:
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
> wrote:
> for (i = 0; i < count; ++i)
> swap(order[i], order[drm_lcg_random(state) % count]);
>
> Much simpler and I cannot see why it wouldn't work.
Hint: swap() does multiple evalu
On 13 December 2016 at 09:46, Daniel Vetter wrote:
> On Tue, Dec 13, 2016 at 10:42 AM, Michel Dänzer wrote:
>>> Hm, I thought the grand plan is to use -modesetting almost everywhere and
>>> forget about all the others?
>>
>> Maybe if you mean s/grand plan/pipe dream/ ...
>
> I said "almost everyw
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Acknowledging that we were building up the hole was more useful to me
> when reading the code, than knowing the relationship between this node
> and the previous node.
>
I don't really agree. I see that we have nodes and there are holes that
On Tue, Dec 13, 2016 at 04:16:41PM +0100, David Herrmann wrote:
> Hey Chris
>
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
> wrote:
> > For testing, we want a reproducible PRNG, a plain linear congruent
> > generator is suitable for our very limited selftests.
> >
> > Signed-off-by: Chris Wi
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Doing the check is trivial (low cost in comparison to overall eviction)
> and helps simplify the code.
>
> Signed-off-by: Chris Wilson
I now see that the other function gets eliminated, so no biggie.
Reviewed-by: Joonas Lahtinen
Regards,
On Tue, 13 Dec 2016, Jani Nikula wrote:
> On Tue, 13 Dec 2016, Mika Kahola wrote:
>> Proposal for cleanup. Let's favor dev_priv instead of dev in intel_panel.c
>> functions. Cleanup for HZ to PWM functions to unify the look and feel of
>> these functions.
>>
>> Mika Kahola (3):
>> drm/i915: Int
For limiting the max frequency of gpu, the max freq tunable
is not enough to hard limit the max gap. We now have also per
client boost max freq. When this tunable was introduced,
it was mistakenly made read only. Allow user to gain control by
setting it writable.
Fixes: 29ecd78d3b79 ("drm/i915: De
On Tue, 13 Dec 2016, Mika Kuoppala wrote:
> For limiting the max frequency of gpu, the max freq tunable
> is not enough to hard limit the max gap. We now have also per
> client boost max freq. When this tunable was introduced,
> it was mistakenly made read only. Allow user to gain control by
> set
On Tue, Dec 13, 2016 at 04:18:35PM +0100, David Herrmann wrote:
> On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann wrote:
> > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
> > wrote:
> > for (i = 0; i < count; ++i)
> > swap(order[i], order[drm_lcg_random(state) % count]);
> >
> > Much si
On Tue, Dec 13, 2016 at 05:37:42PM +0200, Jani Nikula wrote:
> On Tue, 13 Dec 2016, Mika Kuoppala wrote:
> > For limiting the max frequency of gpu, the max freq tunable
> > is not enough to hard limit the max gap. We now have also per
> > client boost max freq. When this tunable was introduced,
>
On Tue, Dec 13, 2016 at 04:52:01PM +0200, Jani Nikula wrote:
> On Tue, 13 Dec 2016, Chris Wilson wrote:
> > On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote:
> >> Currently in dual display connected boot scenarios, minimum of the
> >> resolutions
> >> is taken for fb width and heigh
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Compute the minimal required hole during scan and only evict those nodes
> that overlap. This enables us to reduce the number of nodes we need to
> evict to the bare minimum.
>
> Signed-off-by: Chris Wilson
Definitely for the better.
Revie
On Tue, Dec 13, 2016 at 05:32:07PM +0200, Mika Kuoppala wrote:
> For limiting the max frequency of gpu, the max freq tunable
> is not enough to hard limit the max gap. We now have also per
> client boost max freq. When this tunable was introduced,
> it was mistakenly made read only. Allow user to g
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> For power-of-two alignments, we can avoid the 64bit divide and do a
> simple bitwise add instead.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_mm.c | 9 -
> include/drm/drm_mm.h | 1 +
> 2 files changed, 9 inserti
In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, with the
simple goal of expressing warnings which are truly insane, and so are
only really useful for CI where we have some abusive tests.
v2:
- use BUILD_BUG_ON_INVALID for !DEBUG_GEM
- clarify commit message
Cc: Joonas Lahtinen
If we move the sanity checking from gen8_alloc_va_range_3lvl and
gen6_alloc_va_range into i915_vma_bind, we will increase our coverage to
now both callbacks. We also convert each WARN_ON over to a GEM_WARN_ON.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Suggested-by: Chris Wilson
Signed-off-by: Matthe
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Using mm->color_adjust makes the eviction scanner much tricker since we
> don't know the actual neighbours of the target hole until after it is
> created (after scanning is complete). To work out whether we need to
> evict the neighbours becau
The function name gen8_setup_page_directory_pointer is misleading, and
only serves to confuse the reader, it's not setting up a pdp, but
rather encoding a specific pml4e with a given pdp.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gp
Now that it's obvious what the helpers do, we can simplify the code
somewhat by using them when clearing the pdpe/pml4e with the relevant
scratch entry.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++--
1 file change
The function name gen8_setup_page_directory is misleading, and only
serves to confuse the reader, it's not setting up a pd, but rather
encoding a specific pdpe with a given pd.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/
Hey Chris
On Tue, Dec 13, 2016 at 4:40 PM, Chris Wilson wrote:
> On Tue, Dec 13, 2016 at 04:18:35PM +0100, David Herrmann wrote:
>> On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann
>> wrote:
>> > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
>> > wrote:
>> > for (i = 0; i < count; ++i)
>> >
On ti, 2016-12-13 at 16:00 +, Matthew Auld wrote:
> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, with the
> simple goal of expressing warnings which are truly insane, and so are
> only really useful for CI where we have some abusive tests.
>
> v2:
> - use BUILD_BUG_ON_INVA
On Tue, Dec 13, 2016 at 04:00:59PM +, Matthew Auld wrote:
> If we move the sanity checking from gen8_alloc_va_range_3lvl and
> gen6_alloc_va_range into i915_vma_bind, we will increase our coverage to
> now both callbacks. We also convert each WARN_ON over to a GEM_WARN_ON.
>
> Cc: Joonas Lahti
== Series Details ==
Series: drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV
URL : https://patchwork.freedesktop.org/series/16698/
State : success
== Summary ==
Series 16698v1 drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV
https://patchwork.freedesktop.org/api/
Pushed, thanks
On Tue, 2016-12-13 at 07:20 +0200, Abdiel Janulgue wrote:
>
> On 12.12.2016 22:50, Lyude wrote:
> > Many GPUs have more then 3 pipes available, so hard limiting this
> > to
> > I915_MAX_PIPES prevents us from using anything that relies on
> > igt_display_init() on non-intel systems
On 13 December 2016 at 16:25, Joonas Lahtinen
wrote:
> On ti, 2016-12-13 at 16:00 +, Matthew Auld wrote:
>> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, with the
>> simple goal of expressing warnings which are truly insane, and so are
>> only really useful for CI where we ha
On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
> Op 09-12-16 om 09:25 schreef Daniel Vetter:
> > On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
> >> Hi Daniel,
> >>
> >> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> >>> On Thu, Dec 08, 2016 at 02:45:
On 07/12/2016 13:58, Chris Wilson wrote:
The phys object is a rarely used device (only very old machines require
a chunk of physically contiguous pages for a few hardware interactions).
As such, it is not exercised by CI and to combat that we want to add a
test that exercises the phys object on
== Series Details ==
Series: drm/i915: Optimise VMA lookup slightly (rev2)
URL : https://patchwork.freedesktop.org/series/16740/
State : warning
== Summary ==
Series 16740v2 drm/i915: Optimise VMA lookup slightly
https://patchwork.freedesktop.org/api/1.0/series/16740/revisions/2/mbox/
Test dr
== Series Details ==
Series: drm/i915: Fix setting of boost freq tunable
URL : https://patchwork.freedesktop.org/series/16748/
State : failure
== Summary ==
Series 16748v1 drm/i915: Fix setting of boost freq tunable
https://patchwork.freedesktop.org/api/1.0/series/16748/revisions/1/mbox/
Test
On Tue, Dec 13, 2016 at 04:05:12PM +, Matthew Auld wrote:
> Now that it's obvious what the helpers do, we can simplify the code
> somewhat by using them when clearing the pdpe/pml4e with the relevant
> scratch entry.
>
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Michał Winiarski
== Series Details ==
Series: series starting with [1/2] drm/i915: introduce GEM_WARN_ON
URL : https://patchwork.freedesktop.org/series/16750/
State : success
== Summary ==
Series 16750v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16750/revisions/1/mbox/
Test
Our heuristic for finding planes was previously matching the type, and
ensuring that the plane was valid for that CRTC. However, VC4 now has
primary/cursor planes which can wander multiple CRTCs, so we could pick
a PRIMARY plane which was not the kernel's idea of crtc->primary,
causing plane_primar
This isn't new, but I thought I'd report it since it doesn't seem to
get fixed on its own..
[drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_dp.c:4018
intel_dp_check_link_status+0x1db
== Series Details ==
Series: series starting with [1/3] drm/i915:
s/gen8_setup_page_directory/gen8_setup_pdpe/
URL : https://patchwork.freedesktop.org/series/16751/
State : success
== Summary ==
Series 16751v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16751/
On Tue, Dec 13, 2016 at 11:00:50AM -0800, Linus Torvalds wrote:
> This isn't new, but I thought I'd report it since it doesn't seem to
> get fixed on its own..
>
> [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0
> [ cut here ]
> WARNING: CPU: 1 PID:
Em Ter, 2016-12-13 às 21:17 +0200, Ville Syrjälä escreveu:
> On Tue, Dec 13, 2016 at 11:00:50AM -0800, Linus Torvalds wrote:
> >
> > This isn't new, but I thought I'd report it since it doesn't seem
> > to
> > get fixed on its own..
For me this is new. Ever since September, my SKL SDP booted 100%
Hi Linus,
Below is the gvt pull request from Zhenyu, now that the vfio stuff has
landed. I figured no point in passing this all through the various
trees especially since Dave is kinda in vacation mode anyway. But I
did a local test pull and looked all reasonable to me. Diffstat and
summary is wro
On Tue, Dec 13, 2016 at 05:29:54PM -0200, Paulo Zanoni wrote:
> Em Ter, 2016-12-13 às 21:17 +0200, Ville Syrjälä escreveu:
> > On Tue, Dec 13, 2016 at 11:00:50AM -0800, Linus Torvalds wrote:
> > >
> > > This isn't new, but I thought I'd report it since it doesn't seem
> > > to
> > > get fixed on i
Hello,
On Tuesday 13 Dec 2016 16:16:41 David Herrmann wrote:
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson wrote:
> > For testing, we want a reproducible PRNG, a plain linear congruent
> > generator is suitable for our very limited selftests.
> >
> > Signed-off-by: Chris Wilson
This doesn't
On Tue, Dec 13, 2016 at 09:17:50PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 13, 2016 at 11:00:50AM -0800, Linus Torvalds wrote:
> > This isn't new, but I thought I'd report it since it doesn't seem to
> > get fixed on its own..
> >
> > [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on m
It's been unfixed since a while and no one is immediately working on
this. And we have the FIXME already. And now also a task in the DP
team's backlog.
Cc: Linus Torvalds
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
References:
https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.h
1 - 100 of 147 matches
Mail list logo
