On 06/16/2015 03:41 PM, Abdiel Janulgue wrote:
> This will let userspace know whether Resource Streamer is supported
> in the kernel.
>
> v2: Update I915_PARAM_HAS_RESOURCE_STREAMER so it's after
> I915_PARAM_HAS_GPU_RESET.
> v3: Only advertise RS support for hardware that supports it.
Ping
On 6/23/2015 4:42 PM, David Weinehall wrote:
On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
@@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp,
uint32_t *DP)
} else if (HAS_DDI(de
Hi. Feel free to Cc me on patches of this nature. I am far behind on mesa-dev,
and no longer read intel-gfx. I'm probably one of the sensible people to look at
this...
On Tue, Jun 23, 2015 at 01:21:27PM +0100, Michel Thierry wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must a
On 06/23/2015 04:33 AM, Dave Gordon wrote:
On 17/06/15 13:41, Daniel Vetter wrote:
> On Wed, Jun 17, 2015 at 02:22:19PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 17, 2015 at 09:20:44AM +0100, Dave Gordon wrote:
>>> On 16/06/15 10:24, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:30PM
On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson wrote:
> On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 22, 2015 at 11:47:02AM -0700, Anuj Phogat wrote:
>> > and use it to initialize the align variable in drm_intel_bo.
>> >
>> > In case of YF/YS tiled buffers libdrm ne
On Mon, Jun 22, 2015 at 12:49 PM, Daniel Vetter wrote:
> On Mon, Jun 22, 2015 at 10:21:46AM -0700, Ben Widawsky wrote:
>> On Fri, Jun 19, 2015 at 03:52:01PM -0700, Anuj Phogat wrote:
>> > +Ben
>> >
>> > On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
>> > > Signed-off-by: Anuj Phogat
>> > >
The registers and process differ from other platforms. If the hardware
was programmed incorrectly, this will return invalid cdclk values, which
should then cause reprogramming of the hardware.
v2(Matt): Return 19.2 MHz when DE PLL is disabled (Ville)
v3: Make less assumptions about the hardware st
On Tue, Jun 23, 2015 at 07:16:15PM +0100, Damien Lespiau wrote:
> On Tue, Jun 23, 2015 at 08:40:27PM +0300, Imre Deak wrote:
> > This typo lead to the crtc scaler getting enabled incorrectly and an
> > evantual state checker mismatch about the scaler_id.
> >
> > Signed-off-by: Imre Deak
>
> Revi
On Tue, Jun 23, 2015 at 04:14:19PM +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 03:46:57PM +0100, Arun Siluvery wrote:
> > In Indirect context w/a batch buffer,
> > WaClearSlmSpaceAtContextSwitch
> >
> > This WA performs writes to scratch page so it must be valid, this check
> > is perform
On Tue, Jun 23, 2015 at 05:26:40PM -0300, Paulo Zanoni wrote:
> 2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> > I was momentarily confused until I've double-checked that these
> > functions really only compute state and don't update the hardware
> > state. They once did that, but since Ander's rework
On Thu, Jun 18, 2015 at 10:30:36AM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 11:23:17AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 18, 2015 at 10:00:51AM +0100, Chris Wilson wrote:
> > > On Thu, Jun 18, 2015 at 10:30:23AM +0200, Daniel Vetter wrote:
> > > > With the new DRRS code it kin
On Tue, Jun 23, 2015 at 05:21:16PM +0100, Siluvery, Arun wrote:
> On 23/06/2015 17:01, Chris Wilson wrote:
> >On Tue, Jun 23, 2015 at 06:58:42PM +0300, Imre Deak wrote:
> >>On ti, 2015-06-23 at 16:44 +0100, Chris Wilson wrote:
> >>>On Tue, Jun 23, 2015 at 06:18:21PM +0300, Imre Deak wrote:
> On
On Tue, Jun 23, 2015 at 12:08:33PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to avoid a situation where QA/PRTS stops reporting regressions
> because there are way too many subtests failing. So after this commit
> we will just SKIP all the expected failures, and we'll start alwa
On Tue, Jun 23, 2015 at 04:57:26PM -0300, Paulo Zanoni wrote:
> 2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> > The current code tracks business across all pipes, but we're only
> > really interested in the one pipe DRRS is enabled on. Fairly tiny
>
> s/DRRS/PSR/
>
> > optimization, but something I
On Tue, Jun 23, 2015 at 03:59:24PM -0300, Paulo Zanoni wrote:
> 2015-06-18 6:23 GMT-03:00 Daniel Vetter :
> > The current/old frontbuffer might still have gpu frontbuffer rendering
> > pending. But once flipped it won't have the corresponding frontbuffer
> > bits any more and hence the request reti
Just so I have a user for this macro.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c49fe2afa223..6db920c913ee 100644
---
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we can'
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug.
Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 6 --
1 file changed, 4 insertions(+), 2 de
Remaining manual work in the drm core&helpers. Nothing special here,
no surprises.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 26 ++
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_m
Hi all,
Dave&I have been discussing connector hotplug and unplugging around DP MST and
if there's one thing that's clear it's that we don't even really know where all
the problems are. Hence first step is to figure that out. One of the bigger
items is walking the encoder/connector lists without ap
Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by a
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/shmobile/shmo
Because of DP MST encoders/connectors can now be hotplugged and we
must hold the right lock when walking the encoder/connector lists.
Enforce this by checking the locking in our shiny new list walking
macros.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 12 ++--
1 file chang
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
fbd
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a locking
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> The current code tracks business across all pipes, but we're only
> really interested in the one pipe DRRS is enabled on. Fairly tiny
> optimization, but something I noticed while reading the code. But it
> might matter a bit when e.g. showing a video or
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> I was momentarily confused until I've double-checked that these
> functions really only compute state and don't update the hardware
> state. They once did that, but since Ander's rework of the dpll
> computation flow that's no longer the case.
>
> Rename
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> Must have missed the transition.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_frontbuffer.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/in
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> The frontbuffer code gives us accurate information about activity,
> let's use it. Again this should avoid unecessary updates when multiple
> screens are on.
>
> Also realing function paramaters, I couldn't resist that bit of OCD.
Can't test this since -
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> The current code tracks business across all pipes, but we're only
> really interested in the one pipe DRRS is enabled on. Fairly tiny
s/DRRS/PSR/
> optimization, but something I noticed while reading the code. But it
> might matter a bit when e.g. showi
On Tue, Jun 23, 2015 at 04:43:24PM +0100, John Harrison wrote:
> On 23/06/2015 14:24, Daniel Vetter wrote:
> >On Tue, Jun 23, 2015 at 12:38:01PM +0100, John Harrison wrote:
> >>On 22/06/2015 21:12, Daniel Vetter wrote:
> >>>On Fri, Jun 19, 2015 at 05:34:12PM +0100, john.c.harri...@intel.com wrote:
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> Useful to figure out whether stuck bits are due to the frontbuffer
> tracking code as opposed to individual consumers (who have their own
> bitmask tracking).
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i91
2015-06-18 5:30 GMT-03:00 Daniel Vetter :
> Paulo noticed that the fbc frontbuffer tracking flush callback
> occasionally gets a call without any bit set. This can happen when we
> have to filter flush calls due to e.g. gpu rendering. Filter these
> out.
>
> Reported-by: Paulo Zanoni
> Cc: Paulo Z
2015-06-18 6:23 GMT-03:00 Daniel Vetter :
> The current/old frontbuffer might still have gpu frontbuffer rendering
> pending. But once flipped it won't have the corresponding frontbuffer
> bits any more and hence the request retire function won't ever clear
> the corresponding busy bits. The async
On Tue, Jun 23, 2015 at 11:40 AM Runyan, Arthur J
wrote:
> >From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
> >>On Mon, Jun 22, 2015 at 3:31 PM Runyan, Arthur J <
> arthur.j.run...@intel.com> wrote:
> >>-- Daniel
> I guess I don't really understand your description, but it does sound
> >>
>From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
>>On Mon, Jun 22, 2015 at 3:31 PM Runyan, Arthur J
>>wrote:
>>-- Daniel
I guess I don't really understand your description, but it does sound
strange ... runtime pm enabling from my patch is only about D3, power
well changes are
Hi Arun,
First bad commit (maybe != root cause):
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 5e60d790714bbda0402ddd715aee5e61b48682f4
commit: 4d78c8dcf9f856587fb7bf664021d9fb699012d9 [260/261] drm/i915: Fix
warnings reported by 0-day
reproduce: make htmldocs
Al
On Tue, Jun 23, 2015 at 08:40:27PM +0300, Imre Deak wrote:
> This typo lead to the crtc scaler getting enabled incorrectly and an
> evantual state checker mismatch about the scaler_id.
>
> Signed-off-by: Imre Deak
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_disp
On 17/06/15 16:01, Dave Gordon wrote:
> On 15/06/15 21:20, Chris Wilson wrote:
>> On Mon, Jun 15, 2015 at 07:36:22PM +0100, Dave Gordon wrote:
>>> From: Alex Dai
>>>
>>> intel_guc_api.h contains the subset of the GuC interface that we
>>> will need for submission of commands through the GuC. These
From: Paulo Zanoni
We want to avoid a situation where QA/PRTS stops reporting regressions
because there are way too many subtests failing. So after this commit
we will just SKIP all the expected failures, and we'll start always
failing a subtest called "no-expected-failures".
With this approach
From: Paulo Zanoni
This test exercies the dev_priv->fb_tracking.busy_bits bug I recently
found and Daniel fixed.
Cc: Daniel Vetter
Signed-off-by: Paulo Zanoni
---
tests/kms_frontbuffer_tracking.c | 113 +++
1 file changed, 113 insertions(+)
diff --git a/te
This typo lead to the crtc scaler getting enabled incorrectly and an
evantual state checker mismatch about the scaler_id.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/
On 22/06/15 13:37, Chris Wilson wrote:
> On Mon, Jun 22, 2015 at 12:59:00PM +0100, Dave Gordon wrote:
>> On 19/06/15 09:44, Chris Wilson wrote:
>>> On Thu, Jun 18, 2015 at 07:07:46PM +0100, Dave Gordon wrote:
On 18/06/15 13:10, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 12:49:55PM +0100
On 23/06/2015 17:01, Chris Wilson wrote:
On Tue, Jun 23, 2015 at 06:58:42PM +0300, Imre Deak wrote:
On ti, 2015-06-23 at 16:44 +0100, Chris Wilson wrote:
On Tue, Jun 23, 2015 at 06:18:21PM +0300, Imre Deak wrote:
On ti, 2015-06-23 at 16:13 +0100, Siluvery, Arun wrote:
On 23/06/2015 15:36, Imr
On Tue, Jun 23, 2015 at 04:58:29PM +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 04:45:52PM +0100, Derek Morton wrote:
> > On android platforms with 1Gb RAM gem_fence_thrash was failing
> > with an out of memory error.
> > This patch causes gem_close() to be called when a handle is
> > no lo
On Tue, Jun 23, 2015 at 06:58:42PM +0300, Imre Deak wrote:
> On ti, 2015-06-23 at 16:44 +0100, Chris Wilson wrote:
> > On Tue, Jun 23, 2015 at 06:18:21PM +0300, Imre Deak wrote:
> > > On ti, 2015-06-23 at 16:13 +0100, Siluvery, Arun wrote:
> > > > On 23/06/2015 15:36, Imre Deak wrote:
> > > > > On
On Tue, Jun 23, 2015 at 04:45:52PM +0100, Derek Morton wrote:
> On android platforms with 1Gb RAM gem_fence_thrash was failing
> with an out of memory error.
> This patch causes gem_close() to be called when a handle is
> no longer required rather than relying on the cleanup when
> the fd is closed
On ti, 2015-06-23 at 16:44 +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 06:18:21PM +0300, Imre Deak wrote:
> > On ti, 2015-06-23 at 16:13 +0100, Siluvery, Arun wrote:
> > > On 23/06/2015 15:36, Imre Deak wrote:
> > > > On ti, 2015-06-23 at 15:31 +0100, Chris Wilson wrote:
> > > >> On Tue, J
On android platforms with 1Gb RAM gem_fence_thrash was failing
with an out of memory error.
This patch causes gem_close() to be called when a handle is
no longer required rather than relying on the cleanup when
the fd is closed. This greatly improves the memory footprint
of the test allowing it to
On Tue, Jun 23, 2015 at 06:18:21PM +0300, Imre Deak wrote:
> On ti, 2015-06-23 at 16:13 +0100, Siluvery, Arun wrote:
> > On 23/06/2015 15:36, Imre Deak wrote:
> > > On ti, 2015-06-23 at 15:31 +0100, Chris Wilson wrote:
> > >> On Tue, Jun 23, 2015 at 05:26:13PM +0300, Imre Deak wrote:
> > >>> On the
On 23/06/2015 14:24, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 12:38:01PM +0100, John Harrison wrote:
On 22/06/2015 21:12, Daniel Vetter wrote:
On Fri, Jun 19, 2015 at 05:34:12PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail. T
On Tue, Jun 23, 2015 at 03:15:40PM +, Morton, Derek J wrote:
> >
> >
> >-Original Message-
> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> >Vetter
> >Sent: Monday, June 15, 2015 3:39 PM
> >To: Morton, Derek J
> >Cc: intel-gfx@lists.freedesktop.org; Wood, Th
On Tue, Jun 23, 2015 at 5:20 PM, Daniel Vetter wrote:
>> I pushed my branch,
>> 20150608_TDR_upstream_adaptation_single-thread_hangchecking_RFC_delivery_sendmail_1,
>> to drm-private :
>>
>> https://git-amr-2.devtools.intel.com/gerrit/gitweb?p=otc_gen_graphics-drm-private.git;a=shortlog;h=refs/he
On Tue, Jun 23, 2015 at 04:27:45PM +0100, John Harrison wrote:
> On 23/06/2015 14:25, Daniel Vetter wrote:
> >On Tue, Jun 23, 2015 at 11:37:53AM +0100, John Harrison wrote:
> >>On 23/06/2015 11:24, Chris Wilson wrote:
> >>>On Fri, May 29, 2015 at 05:44:07PM +0100, john.c.harri...@intel.com wrote:
>
>
>
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Tuesday, June 23, 2015 4:08 PM
>To: Morton, Derek J
>Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas
>Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_fence_thrash.c: Reduce memory
>usage
>
>On Tue, Jun
On 23/06/2015 14:25, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 11:37:53AM +0100, John Harrison wrote:
On 23/06/2015 11:24, Chris Wilson wrote:
On Fri, May 29, 2015 at 05:44:07PM +0100, john.c.harri...@intel.com wrote:
-int intel_ring_begin(struct intel_engine_cs *ring,
+int intel_ring_begin
On Tue, Jun 23, 2015 at 04:12:33PM +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 03:50:42PM +0100, Arun Siluvery wrote:
> > Patch1 - Fix warnings in kerneldoc reported by 0-day
> > Patch2 - Tvrtko noticed a WARNING that WA batch is not initialized for Gen9
> > during boot (Gen9 changes not y
>
>
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 15, 2015 3:39 PM
>To: Morton, Derek J
>Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas
>Subject: Re: [Intel-gfx] [PATCH i-g-t v5] libs/igt_core.c: Fix compile
>warn
On Tue, Jun 23, 2015 at 07:29:58AM -0700, Matt Roper wrote:
> On Tue, Jun 23, 2015 at 09:34:50AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 22, 2015 at 06:30:33PM -0700, Matt Roper wrote:
> > > We never removed the sprite watermark updates from our low-level
> > > foo_update_plane() functions; sin
On 23/06/2015 15:36, Imre Deak wrote:
On ti, 2015-06-23 at 15:31 +0100, Chris Wilson wrote:
On Tue, Jun 23, 2015 at 05:26:13PM +0300, Imre Deak wrote:
On the GEN!=8 error path we call kmap_atomic() which returns in atomic
context and then lrc_destroy_wa_ctx_obj() which can be called only in
pro
On ti, 2015-06-23 at 16:13 +0100, Siluvery, Arun wrote:
> On 23/06/2015 15:36, Imre Deak wrote:
> > On ti, 2015-06-23 at 15:31 +0100, Chris Wilson wrote:
> >> On Tue, Jun 23, 2015 at 05:26:13PM +0300, Imre Deak wrote:
> >>> On the GEN!=8 error path we call kmap_atomic() which returns in atomic
> >>
On Tue, Jun 23, 2015 at 03:06:49PM +0100, Tomas Elf wrote:
> On 23/06/2015 12:38, Daniel Vetter wrote:
> >On Tue, Jun 23, 2015 at 11:47:16AM +0100, Tomas Elf wrote:
> >>On 23/06/2015 11:05, Daniel Vetter wrote:
> >>>Your patches don't apply cleanly any more and I can't find a suitable
> >>>baseline
On Tue, Jun 23, 2015 at 03:46:57PM +0100, Arun Siluvery wrote:
> In Indirect context w/a batch buffer,
> WaClearSlmSpaceAtContextSwitch
>
> This WA performs writes to scratch page so it must be valid, this check
> is performed before initializing the batch with this WA.
>
> v2: s/PIPE_CONTROL_FLU
On Tue, Jun 23, 2015 at 03:50:42PM +0100, Arun Siluvery wrote:
> Patch1 - Fix warnings in kerneldoc reported by 0-day
> Patch2 - Tvrtko noticed a WARNING that WA batch is not initialized for Gen9
> during boot (Gen9 changes not yet added). Current code destroys the wa ctx
> page and he observed it
On Tue, Jun 23, 2015 at 04:01:53PM +0100, Derek Morton wrote:
> On android platforms with 1Gb RAM gem_fence_thrash was failing
> with an out of memory error.
> This patch causes gem_close() to be called when a thread is
> finished with its handles rather than relying on the cleanup
> when the fd is
On android platforms with 1Gb RAM gem_fence_thrash was failing
with an out of memory error.
This patch causes gem_close() to be called when a thread is
finished with its handles rather than relying on the cleanup
when the fd is closed. This greatly improves the memory footprint
of the test allowing
Kernel 0-day framework reported warnings with WA batch patches, this patch
fixes those warnings and an additional warning reported in intel_lrc.c file.
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers
To initialize WA batch, at the moment we first allocate batch and then check
whether we have any WA to be initialized for the given Gen; if we don't have
any WA then we WARN the user, destroy the batch and return but this is causing
another WARN in cleanup code complaining about sleeping in atomic
Patch1 - Fix warnings in kerneldoc reported by 0-day
Patch2 - Tvrtko noticed a WARNING that WA batch is not initialized for Gen9
during boot (Gen9 changes not yet added). Current code destroys the wa ctx
page and he observed it triggered another warning complaining about sleeping
in atomic context
On 22/06/2015 17:59, Siluvery, Arun wrote:
On 22/06/2015 17:21, Ville Syrjälä wrote:
On Fri, Jun 19, 2015 at 06:37:15PM +0100, Arun Siluvery wrote:
In Per context w/a batch buffer,
WaRsRestoreWithPerCtxtBb
This WA performs writes to scratch page so it must be valid, this check
is performed bef
In Indirect context w/a batch buffer,
WaClearSlmSpaceAtContextSwitch
This WA performs writes to scratch page so it must be valid, this check
is performed before initializing the batch with this WA.
v2: s/PIPE_CONTROL_FLUSH_RO_CACHES/PIPE_CONTROL_FLUSH_L3 (Ville)
v3: GTT bit in scratch address sh
On ti, 2015-06-23 at 15:31 +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 05:26:13PM +0300, Imre Deak wrote:
> > On the GEN!=8 error path we call kmap_atomic() which returns in atomic
> > context and then lrc_destroy_wa_ctx_obj() which can be called only in
> > process context. Fix this by pr
On Tue, Jun 23, 2015 at 05:26:13PM +0300, Imre Deak wrote:
> On the GEN!=8 error path we call kmap_atomic() which returns in atomic
> context and then lrc_destroy_wa_ctx_obj() which can be called only in
> process context. Fix this by preserving the correct cleanup order on
> this error path.
>
>
On Tue, Jun 23, 2015 at 09:34:50AM +0200, Daniel Vetter wrote:
> On Mon, Jun 22, 2015 at 06:30:33PM -0700, Matt Roper wrote:
> > We never removed the sprite watermark updates from our low-level
> > foo_update_plane() functions; since our hardware updates happen under
> > vblank evasion, we're not s
On the GEN!=8 error path we call kmap_atomic() which returns in atomic
context and then lrc_destroy_wa_ctx_obj() which can be called only in
process context. Fix this by preserving the correct cleanup order on
this error path.
Also convert the WARN to DRM_ERROR the stack trace isn't really useful.
On 23/06/2015 12:38, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 11:47:16AM +0100, Tomas Elf wrote:
On 23/06/2015 11:05, Daniel Vetter wrote:
Your patches don't apply cleanly any more and I can't find a suitable
baseline where they would. But I'd like to see it all in context to check
a few th
From: Tvrtko Ursulin
This way data is available as soon as the view is passed into the call chain.
v2: Store size in bytes instead of pages under the appropriate name. (Chris
Wilson)
v3: Use uint64_t instead of size_t. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Chri
On Tue, Jun 23, 2015 at 11:37:53AM +0100, John Harrison wrote:
> On 23/06/2015 11:24, Chris Wilson wrote:
> >On Fri, May 29, 2015 at 05:44:07PM +0100, john.c.harri...@intel.com wrote:
> >>-int intel_ring_begin(struct intel_engine_cs *ring,
> >>+int intel_ring_begin(struct drm_i915_gem_request *req,
On Tue, Jun 23, 2015 at 01:21:05PM +0100, Michel Thierry wrote:
> There are some allocations that must be only referenced by 32-bit
> offsets. To limit the chances of having the first 4GB already full,
> objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
> DRM_MM_CREATE_TOP flags
>
> I
On Tue, Jun 23, 2015 at 12:38:01PM +0100, John Harrison wrote:
> On 22/06/2015 21:12, Daniel Vetter wrote:
> >On Fri, Jun 19, 2015 at 05:34:12PM +0100, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>It is a bad idea for i915_add_request() to fail. The work will already have
> >
On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote:
> I've done some extensive history digging across libdrm, mesa and
> xf86-video-{intel,nouveau,ati}. The only potential user of this with
> kms drivers I could find was ttmtest, which once used drmGetLock
> still. But that mistake was quickly
On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote:
> From: Peter Antoine
>
> The context functions are not used by the i915 driver and should not
> be used by modeset drivers. These driver functions contain several bugs
> and security holes. This change makes these functions optional can be
On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote:
> It can't fail really.
>
> Also remove the redundant kms check Peter added.
>
> Cc: Peter Antoine
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_context.c | 5 ++---
> drivers/gpu/drm/drm_drv.c | 10 +-
> drivers
On Tue, Jun 23, 2015 at 01:21:29PM +0100, Michel Thierry wrote:
> +static void reusebo_and_compare_offsets(uint32_t fd,
> + uint64_t buf_size)
> +{
> + uint32_t bo;
> + uint64_t offset, offset2;
> +
> + bo = gem_create(fd, buf_size);
> + /* suppor
On Mon, Jun 22, 2015 at 4:46 PM, Varka Bhadram wrote:
> Hi Shobhit Kumar,
>
> On 06/22/2015 04:24 PM, Shobhit Kumar wrote:
>
>> The Crystalcove PMIC provides three PWM signals and this driver exports
>> one of them on the BYT platform which is used to control backlight for
>> DSI panel. This is pl
On Mon, 2015-06-22 at 17:43 +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2015 at 11:07:29PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
> > Corrected the platform checks in i915_ring_freq_table debugfs function
> > so as to allow the read of ring frequency table for BDW and disal
On ti, 2015-06-23 at 13:42 +0300, Mikko Rapeli wrote:
> Hi Imre,
>
> On Mon, Jun 22, 2015 at 04:43:50PM +0300, Imre Deak wrote:
> >
> > To summarize, since we extended the range of platforms to apply the
> > workaround in
> > commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
> > Author: Imre Deak
>
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Intruction State Heap (ISH) must be in a
32-bit range, because the General State
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Intruction State Heap (ISH) must be in a
32-bit range, because the General State
Test EXEC_OBJECT_SUPPORTS_48BADDRESS flag to use +32-bit segment.
Driver will try to use lower PDPs of each PPGTT for the objects
requiring Wa32bitGeneralStateOffset or Wa32bitInstructionBaseOffset.
v2: Add flink cases, (suggested by Daniel Vetter).
v3: 48-bit support flab moved to exec_object.
S
Changed size from u32 to u64 to support +4GB.
48-bit PPGTT test cases may need extra memory available.
Signed-off-by: Michel Thierry
---
lib/igt_aux.h | 2 +-
lib/intel_os.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index b2dc267..9
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used with flat/heapless (0x-0xf000)
Gen
On Tue, Jun 23, 2015 at 02:04:04PM +0200, Daniel Vetter wrote:
> The module pciid list got lost, but somehow most distros seem to
> force-load drm drivers early and no one noticed for a while.
>
> Bug introduced in
>
> commit fd930478fb797e4cbaa799d9ddd970e9a1fa1b4a
> Author: Chris Wilson
> Date
On Tue, Jun 23, 2015 at 02:12:41PM +0300, David Weinehall wrote:
> On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
> > > @@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp
> > > *intel_dp, uint32_t *D
On Tue, Jun 23, 2015 at 11:46:29AM +0100, Tvrtko Ursulin wrote:
>
> On 06/22/2015 03:17 PM, Daniel Vetter wrote:
> >On Mon, Jun 22, 2015 at 12:11:47PM +0100, Damien Lespiau wrote:
> >>On Fri, Jun 19, 2015 at 08:27:27PM +0100, Chris Wilson wrote:
> >>>Since we only support modesetting by default (d
The module pciid list got lost, but somehow most distros seem to
force-load drm drivers early and no one noticed for a while.
Bug introduced in
commit fd930478fb797e4cbaa799d9ddd970e9a1fa1b4a
Author: Chris Wilson
Date: Fri Jun 19 20:27:27 2015 +0100
drm/i915: Remove KMS Kconfig option
Re
On 06/23/2015 11:29 AM, Chris Wilson wrote:
On Tue, Jun 23, 2015 at 11:04:42AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently object size is returned for the rotated VMA size which can be
bigger than the rotated view itself. Since the binding code pads all
excess size with scratc
From: Tvrtko Ursulin
This way data is available as soon as the view is passed into the call chain.
v2: Store size in bytes instead of pages under the appropriate name. (Chris
Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
This will be needed in the following
1 - 100 of 138 matches
Mail list logo
