Hey Daniel,
This patch looks good to me.
On 2016-12-13 01:15 PM, Daniel Stone wrote:
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 pi
On 12/13/2016 07:22 PM, Maarten Lankhorst wrote:
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 c
>-Original Message-
>From: Hiler, Arkadiusz
>Sent: Tuesday, December 13, 2016 1:41 AM
>To: Chris Wilson ; Srivatsa, Anusha
>; intel-gfx@lists.freedesktop.org; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to
>getparams
>
>On Thu, Dec 08, 2016 at
Hi Maarten,
On Tuesday 13 Dec 2016 15:13:54 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:
> >> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> >>> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarte
On Wed, Dec 14, 2016 at 12:08:09AM +0100, Daniel Vetter wrote:
> If we're unlucky then the registration from a hotplugged connector
> might race with the final registration step on driver load. And since
> MST topology discover is asynchronous that's even somewhat likely.
>
> v2: Also update the k
== Series Details ==
Series: series starting with [1/2] drm/i915: Don't assume 60Hz when accounting
for DSI pixel overlap
URL : https://patchwork.freedesktop.org/series/16760/
State : success
== Summary ==
Series 16760v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.
v2: Also update the kerneldoc for @registered!
Cc: Chris Wilson
Reported-by: Chris Wilson
S
One case where I nuked a now unecessary locking, otherwise all just
boring stuff.
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/
Nothing special, just rote conversion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hotplug.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 3d546
Only static connectors should be left at this point, and we should be
able to clean them out by simply dropping that last reference still
around from drm_connector_init.
If that leaves anything behind then we have a driver bug.
Doing the final cleanup this way also allows us to use
drm_connector_
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Signed-o
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protectio
- Modeset state needs mode_config->connection mutex, that covers
figuring out the encoder, and reading properties (since in the
atomic case those need to look at connector->state).
- Don't hold any locks for stuff that's invariant (i.e. possible
connectors).
- Same for connector lookup and
Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.
I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Signed-off-by: Daniel Vetter
---
drive
While at it also try to reduce the locking a bit to what's really just
needed instead of everything that we could possibly lock.
Added a new for_each_intel_connector_iter which includes the cast to
intel_connector.
Otherwise just plain transformation with nothing special going on.
Signed-off-by:
The list walk will shortcircuit anyway.
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6 ++
drivers/gpu/drm/radeon/radeon_irq_kms.c | 12
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing
This is not driver interface stuff.
Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state")
Cc: Rob Clark
Cc: Sean Paul
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 6 ++
drivers/gpu/drm/drm_debugfs.c
This is single-threaded setup code, no need for locks. And anyway,
all properties need to be set up before the driver is registered
anyway, they can't be hot-added.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu
Hi all,
I finally clued up about connector_list locking and here is a fix for that
little issue that's not totally horribly nightmare fuel. As usual I ended up
reading too much other code, so there's a few random bits in here too. Some of
the earlier randomness I submitted already and it's in drm-
== Series Details ==
Series: drm/i915: disable PSR by default on HSW/BDW
URL : https://patchwork.freedesktop.org/series/16759/
State : failure
== Summary ==
Series 16759v1 drm/i915: disable PSR by default on HSW/BDW
https://patchwork.freedesktop.org/api/1.0/series/16759/revisions/1/mbox/
Test
On Tue, Dec 13, 2016 at 09:40:51PM +0200, Ville Syrjälä wrote:
> 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
On Tue, Dec 13, 2016 at 10:23:05PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 13, 2016 at 08:54:14PM +0100, Daniel Vetter wrote:
> > 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.
> >
>
On Tue, Dec 13, 2016 at 05:23:54PM +0200, Joonas Lahtinen wrote:
> 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.
>
Hi Chris,
Thank you for the patch.
On Thursday 08 Dec 2016 08:18:40 Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> mo
On Tue, Dec 13, 2016 at 08:32:19PM +, 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 Tue, Dec 13, 2016 at 08:32:20PM +, 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
On Tue, Dec 13, 2016 at 08:32:22PM +, Matthew Auld wrote:
> Convert some of the obvious hand-rolled ranged overflow sanity checks to
> our shiny new range_overflows macro.
>
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
Reviewed-by: Chr
On Tue, Dec 13, 2016 at 08:32:21PM +, Matthew Auld wrote:
> In a number places we hand-roll the overflow sanity check for ranges, so
> roll that into single macro, conceived by Chris, along with its typed
> variant.
>
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Suggested-by: Chris Wilson
> S
Acked-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
On Tue, 2016-12-13 at 18:57 -0200, Paulo Zanoni wrote:
> We've been ignoring the poor bugzilla reporters that say PSR causes
> system lockups and all other sorts of problems. The earliest bug
> report is from April, so I think we can use the "r
== Series Details ==
Series: series starting with [1/4] drm/i915: introduce GEM_WARN_ON
URL : https://patchwork.freedesktop.org/series/16758/
State : success
== Summary ==
Series 16758v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16758/revisions/1/mbox/
fi-b
From: Ville Syrjälä
Dump out the computed pclk and burst_mode_ratio for DSI. These are
pretty important in figuring out timing related stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrjälä
Compute the increase in the DSI clock due to pixel overlap mode in
a way that's refresh rate agnostic. So far the computation assumed
a 60Hz refresh rate. And let's switch to round to closest here as
well since we would like to be as close to the target as possible.
Also toss
We've been ignoring the poor bugzilla reporters that say PSR causes
system lockups and all other sorts of problems. The earliest bug
report is from April, so I think we can use the "revert the offending
commit if no fixes are presented within 8 months" rule here.
Fixes: 9b58e352b463 ("drm/i915: En
On Tue, Dec 13, 2016 at 09:39:06PM +0200, Laurent Pinchart wrote:
> 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 ou
== Series Details ==
Series: series starting with [1/2] drm/i915: skip the first 4k of stolen memory
on everything >= gen8
URL : https://patchwork.freedesktop.org/series/16757/
State : failure
== Summary ==
Series 16757v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
On Tue, Dec 13, 2016 at 05:57:26PM -0200, Paulo Zanoni wrote:
> Reserve the first page of stolen memory right after initializing the
> mm allocator. This means that we won't inherit the FB in case the BIOS
> decides to put it at the start of stolen. IMHO, avoiding constant
> screen flickering is mo
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
Convert some of the obvious hand-rolled ranged overflow sanity checks to
our shiny new range_overflows macro.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
drivers/gpu/drm/i915/i915_vma.c | 6 ++
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
In a number places we hand-roll the overflow sanity check for ranges, so
roll that into single macro, conceived by Chris, along with its typed
variant.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 12
On Tue, Dec 13, 2016 at 08:54:14PM +0100, Daniel Vetter wrote:
> 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ä
> R
== Series Details ==
Series: drm/i915: tune down the fast link training vs boot fail
URL : https://patchwork.freedesktop.org/series/16756/
State : success
== Summary ==
Series 16756v1 drm/i915: tune down the fast link training vs boot fail
https://patchwork.freedesktop.org/api/1.0/series/16756
Em Ter, 2016-12-13 às 17:57 -0200, Paulo Zanoni escreveu:
> BSpec got updated and this workaround is now listed as standard
> required programming for all subsequent projects.
>
Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 5 ++---
>
Reserve the first page of stolen memory right after initializing the
mm allocator. This means that we won't inherit the FB in case the BIOS
decides to put it at the start of stolen. IMHO, avoiding constant
screen flickering is more important than BIOS framebuffer inheritance.
TODO: the goal is to
BSpec got updated and this workaround is now listed as standard
required programming for all subsequent projects.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
On Tue, Dec 13, 2016 at 11:54 AM, Daniel Vetter wrote:
>
> Feel free to apply directly in case it annoys too much and you don't
> want to wait for your presents ;-)
I'll wait for the proper unboxing of presents. Once I've rattled them
and know what to expect, I can be very patient.
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
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
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 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
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
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%
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:
== 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/
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
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
== 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
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: 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
== 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
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
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 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
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
== 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/
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
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
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)
>> >
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/
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
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
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
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
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
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:
> 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 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 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: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, 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
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, 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
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, 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:
> 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 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 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 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
>
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:
> 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
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 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 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 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 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
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 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
>
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
1 - 100 of 147 matches
Mail list logo
