On Thu, 2016-06-02 at 11:30 +0530, Martin Peres wrote:
> On 02/06/16 08:18, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > This patch introduces a framework to enable OA counter reports associated
> > with Render command stream. We can then associate the reports captured
> > through
On 02/06/16 08:18, sourab.gu...@intel.com wrote:
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further
From: Sourab Gupta
Add a compile time option for detecting the overflow condition of command
stream buffer, and not overwriting the old entries in such a case.
Also, set a status flag to forward the overflow condition to userspace if
overflow is detected.
Signed-off-by: Sourab Gupta
---
driver
From: Sourab Gupta
This series adds framework for collection of gpu performance metrics
associated with the command stream of a particular engine. These metrics
include OA reports, timestamps, mmio metrics, etc. These metrics are
are collected around batchbuffer boundaries.
This work utilizes th
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
For e.g. for internally triggerred reports (non MI_RPC reports), the RPT_ID
field has bitfields for specifying the origin such as timer, or render ctx
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to cap
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An ab
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps accordi
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening the stream.
From: Sourab Gupta
For the drivers to be able to use the cross timestamp framework,
they need the information of current clocksource being used by the
kernel timekeeping. This is needed since the callback given by driver
into the get_device_system_crosststamp(), in order to synchronously read
the
From: Sourab Gupta
Exporting clocks_calc_mult_shift is helpful for drivers to calculate
the mult/shift values for their clocks, given their frequency.
This is particularly useful when such drivers may want to associate
timecounter/cyclecounter abstraction for their clock sources, in order
to use
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other metadata informatio
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what the ordering be
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports itself.
From: Sourab Gupta
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx unique id by userspace.
This can be used by userspace to map the i915 perf samples with their
particular ctx's, since those would be having ctx unique id's.
Otherwise the userspace has no way
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be collec
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA re
Gen9 has two scalers on pipes A & B, but only a single scaler on pipe C.
We should bail out of the test early on pipe C so that we don't ask the
kernel to use more scalers than we really have.
Note that this test may still fail (on any pipe) if we're already using
one of the scalers as a panel fit
This is now handled by the core, drivers can totally ignore lifetime
issues of drm events.
Cc: Tomeu Vizoso
Cc: Mark yao
Tested-by: Tomeu Vizoso
Reviewed-by: Tomeu Vizoso
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22 --
drivers/gpu/drm
Atomic drivers are supposed to do hw/sw state reset with the
drm_mode_config_reset() call right above it.
Cc: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/s
Simply split intel_atomic_commit in half and place the new
nonblocking commit helpers at the right spots.
NOTE: There's still trouble with obj->frontbuffer bits getting mangled
when pipelining atomic commits.
v2:
- Remove the check for nonblocking which returned -EINVAL.
- Do wait for requests in
With the various bits fixed rockchip now has an atomic compliant
handling/signalling of crtc_state->event, which means we can just
switch over to the new nonblocking helpers and remove some code.
v2: Fixes from Tomeu.
v3: Send out vblank events correctly when shutting down a crtc for
good. This i
Right now still all blocking, no worker anywhere to be seen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0618
It's not permissible to look at plane->state from interrupt context,
since doing that would need the irq handler to acquire the
plane->mutex lock.
The other problem is that if we pipeline updates using the new
nonblocking atomic helpers new state gets commit before the irq
handler fires, resulting
With atomic helpers there's no need to track the enabled state of a pipe
any more, because atomic helpers track this accurately already.
Just disable the early returns, since the debug checks might be useful.
v2: Don't call drm_helper_disable_unused_functions, it blows up
without this check. At l
Drivers transitioning to atomic might not yet want to enable full
DRIVER_ATOMIC support when it's not entirely working. But using atomic
internally makes a lot more sense earlier.
Instead of spreading such flags to more places I figured it's simpler
to just check for mode_config->funcs->atomic_com
Just a bit of drive-by ocd.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d9504dfcd1cc..465a1212f4f0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic
Now that the core helpers support nonblocking atomic commits there's
no need to invent that wheel separately (instead of fixing the bug in
the atomic implementation of virtio, as it should have been done!).
Cc: Gerd Hoffmann
Tested-by: Gerd Hoffmann
Reviewed-by: Gerd Hoffmann
Signed-off-by: Dan
Currently it's part of prepare_fb, still in the first phase of
atomic_commit which might fail. Which means that we need to have some
heuristics in cleanup_fb to figure out whether things failed, or
whether we just clean up the old fbs.
That's fragile, and worse, once we start pipelining commits ge
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, b
Committing with block it is not.
Thanks to the fixed up vblank event handling we can just use the
helper support for nonblocking commits now.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_drv.c | 8 +--
atomic_flush seems to be the right place, but I'm not entirely sure
whether this will catch them all. It could be that when disabling the
crtc we'll miss the vblank.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away
Rockchip just blew up here on testing, because I removed some "is this
crtc already disabled/enabled" state tracking from callbacks (not needed
with atomic). Turns out that was needed to work around rockchip still
calling legacy helper code.
Since me explaining on irc/mailing-list plus kerneldoc i
The drm core has a nice ready-made helper for exactly the simple case
where it should fire on the next vblank.
Note that arming the vblank event in _begin is probably too early, and
might easily result in the vblank firing too early, before the new set
of planes are actually disabled. But that's k
This is just used for cleanup in preclose, and with the reworked event
handling code this is now done properly by the core.
Nuke it!
But it also shows that arc totally fails at sending out drm events for
flips. Next patch will hack that up.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps
Those are all no longer needed for a pure atomic driver.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/dr
Note that I didn't start garbage collecting all the legacy flip code
yet, to make it easier to revert this. But there will be _lots_ of
code that can be removed once this is tested on all platforms.
FIXME: obj->frontbuffer_bits gets out of whack when pipelining
commits too hard.
Signed-off-by: Da
atomic_flush seems to be the right place, right after we commit the
plane updates. Again use the fullproof version, since the pipe might
be off.
Cc: Boris Brezillon
Cc: Maxime Ripard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12
1 file changed, 12 inser
No idea how exactly fsl-du commits hw state changes, but here in flush
is probably the safest place.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away.
Cc: Stefan Agner
Signed-off-by: Daniel Vetter
---
drivers/g
event_list just reimplemented what drm_crtc_arm_vblank_event does. And
we also need to send out drm events when shutting down a pipe.
With this it's possible to use the new nonblocking commit support in
the helpers.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Da
From: Gustavo Padovan
Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another drive
Design ideas:
- split up the actual commit into different phases, and have
completions for each of them. This will be useful for the future
when we want to interleave phases much more aggressively, for e.g.
queue depth > 1. For not it's just a minimal optimization compared
to current commo
With the fixed up drm event handling for crtc_state->event we can just
use the helper support for nonblocking commits.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 +---
1 file changed, 1 insertion(+), 7
This is part of what atomic must implement. And it's also required
to be able to use the helper nonblocking support.
v2: Always send out the drm event, remove the planes_changed check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm/i915
We want to hide drm_atomic_stat internals a bit better.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index cb37751bc99f.
We want to encapsulate the drm_atomic_state internals.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 50ff90aea721..3e6d9f
This avois leaking drm_atomic_state internals into the helpers. The
only place where this still happens after this patch is
drm_atomic_helper_swap_state().
It's unavoidable there, and maybe a good indicator we should actually
move that function into drm_atomic.c.
Signed-off-by: Daniel Vetter
---
We want to hide drm_atomic_state internals
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 20 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 12 +++---
drivers/gpu/drm/msm/msm_atomic.c | 35 ++
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-plane state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more per-
We want to hide drm_atomic_state internals better.
Cc: Inki Dae
Acked-by: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exy
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-connector state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more
It's silly to have 2 mallocs when we could tie these two together.
Also, Gustavo adds another one in his per-crtc out-fence patches. And
I want to add more stuff here for nonblocking commit helpers.
In the future we can use this to store a pointer to the preceeding
state, making an atomic update
We want to hide drm_atomic_state internals better.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 20
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/dri
- dev is redundant, we have state->atomic
- add stall parameter, which must be set when swapping needs to stall
for preceeding commits to stop looking at ->state pointers. Currently
all drivers need this to be, just prep work for a glorious future.
Signed-off-by: Daniel Vetter
---
drivers/gp
We want to hide drm_atomic_stat internals a bit better.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/
... and use it in msm&vc4. Again just want to encapsulate
drm_atomic_state internals a bit.
The const threading is a bit awkward in vc4 since C sucks, but I still
think it's worth to enforce this. Eventually I want to make all the
obj->state pointers const too, but that's a lot more work ...
Cc:
Hi all,
Now without the RFC tag, but with polish:
- kerneldoc for everything!
- tested on virtio, hdlcd, rockchip and i915.
The big upshot is still that the helpers are really picky about drivers sending
out drm events correctly, and that is the area where most of the debug work was
needed in tes
Ping, any update on this?
On Wed, 2016-05-18 at 17:35 -0400, Lyude wrote:
> From: Lyude Paul
>
> DRM does not always update the status of each connector during a
> hotplug event, and it's generally expected that userspace is supposed
> to
> handle that by reprobing. This happens in a couple situ
On Wed, Jun 01, 2016 at 06:18:59PM +0200, Maxime Ripard wrote:
> Hi Daniel,
>
> On Sun, May 29, 2016 at 08:35:16PM +0200, Daniel Vetter wrote:
> > atomic_flush seems to be the right place, right after we commit the
> > plane updates. Again use the fullproof version, since the pipe might
> > be off
On Wed, Jun 01, 2016 at 06:08:43PM +0100, Chris Wilson wrote:
> My old 845g complains that the child_device_size inside its VBT,
> version 110, is incorrect. Let's fiddle with the version matching such
> that it works with this VBT (i.e. treat BIOS v110 as having the same size
> as v108).
>
> Fixe
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The ultimate aim is to use the same
sequence number as for the request itself (or rather, to remove the
My old 845g complains that the child_device_size inside its VBT,
version 110, is incorrect. Let's fiddle with the version matching such
that it works with this VBT (i.e. treat BIOS v110 as having the same size
as v108).
Fixes [drm:intel_bios_init] *ERROR* Unexpected child device config
size 27 (ex
From: John Harrison
The notify function can be called many times without the seqno
changing. Some are to prevent races due to the requirement of not
enabling interrupts until requested. However, when interrupts are
enabled the IRQ handler can be called multiple times without the
ring's seqno valu
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is
signaled as complete. Also moved the notify event from the IRQ handler
code to inside the notify function itself.
v3: Added the current ring seqno to the notify trace point.
v5: Line wrapping to keep the
From: John Harrison
The change to the implementation of i915_gem_request_completed() means
that the lazy coherency flag is no longer used. This can now be
removed to simplify the interface.
v6: Updated to newer nightly and resolved conflicts.
v7: Updated to newer nightly (lots of ring -> engine
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
On Wed, Jun 01, 2016 at 05:01:13PM +0100, Damien Lespiau wrote:
> We exit early if has_aliasing_ppgtt is 0, so towards the end of the
> function has_aliasing_ppgtt can only be 1.
>
> Also:
>
> if (foo)
> return 1;
> else
> return 0;
>
> when foo is already
Hi Daniel,
On Sun, May 29, 2016 at 08:35:16PM +0200, Daniel Vetter wrote:
> atomic_flush seems to be the right place, right after we commit the
> plane updates. Again use the fullproof version, since the pipe might
> be off.
This looks fine.
How can that be tested? modetest requires async vblank
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
We exit early if has_aliasing_ppgtt is 0, so towards the end of the
function has_aliasing_ppgtt can only be 1.
Also:
if (foo)
return 1;
else
return 0;
when foo is already a bool is really just:
return foo;
Signed-off-by: Damien Lespiau
-
s/tho/though/
s/regarless/regardless/
Seems reasonable so:
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, May 27, 2016 at 05:27:02PM +0300, Mika Kuoppala wrote:
> Set bit 8 in 0x43224 to prevent screen corruption and system
> hangs on high memory bandwidth conditions. The same wa also suggest
> setting bit 31 on ARB_CTL. According to another workaround we gain
> better idle power savings when F
On Fri, May 27, 2016 at 05:27:03PM +0300, Mika Kuoppala wrote:
> Bspec states that we need to set nuke on modify all to prevent
> screen corruption with fbc on skl and kbl.
>
> v2: proper workaround name
>
> References: HSD#2227109, HSDES#1404569388
> Signed-off-by: Mika Kuoppala
Reviewed-by: V
Hi Joonas,
On Wed, Jun 01, 2016 at 03:49:59PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-05-31 at 22:01 +0800, Zhiyuan Lv wrote:
> > Hi Joonas,
> >
> > On Fri, May 27, 2016 at 02:32:25PM +0300, Joonas Lahtinen wrote:
> > >
> > > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > > >
> >
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jun 01, 2016 at 11:38:03AM +0100, Chris Wilson wrote:
> On Wed, Jun 01, 2016 at 11:57:09AM +0200, Daniel Vetter wrote:
> > On Mon, May 30, 2016 at 09:38:20AM +0100, Chris Wilson wrote:
> > > If a driver wants to more precisely control its initialisation and in
> > > particular, defer regist
On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> > >> On Tue, May 24, 2016 at 06:03:27PM +0
On Wed, Jun 01, 2016 at 07:55:18PM +0530, Mahesh Kumar wrote:
> Reviewed-by: Kumar Mahesh
Merged to dinq; thanks for the review (and thanks for doing the initial
work this series was based on).
Matt
>
> On Tuesday 31 May 2016 10:28 PM, Matt Roper wrote:
> >From: "Kumar, Mahesh"
> >
> >don't
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jun 01, 2016 at 07:54:42AM +0100, Chris Wilson wrote:
> On Tue, May 31, 2016 at 04:18:34PM -0700, Matt Roper wrote:
> > On Tue, May 31, 2016 at 09:51:53AM +0100, Chris Wilson wrote:
> > > On Tue, May 31, 2016 at 01:58:27PM +0530, Sagar Arun Kamble wrote:
> > > > On Loading, GuC sets PM inte
Reviewed-by: Kumar Mahesh
On Tuesday 31 May 2016 10:28 PM, Matt Roper wrote:
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
v2: optimizations as per Matt's comments.
v3 (by Matt):
- Fix boolean logic for !fb test in skl_ddb_min_alloc()
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, May 30, 2016 at 06:10:20PM +0300, Mika Kuoppala wrote:
> According to bspec this prevents screen corruption when fbc is
> used.
>
> v2: This workaround has a name, use it (Ville)
> v3: remove bogus gen check on ilk/vlv wm path (Ville)
>
> References: HSD#213, HSD#2137270, BSID#562
> C
On ti, 2016-05-31 at 22:01 +0800, Zhiyuan Lv wrote:
> Hi Joonas,
>
> On Fri, May 27, 2016 at 02:32:25PM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > >
> > > For me I think maybe i915 could save the snapshot for GVT, then GVT-g
> > > patch the sn
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
> having a spinlock inside the per-cpu struct. The only place where we
> actually may touch another CPU's data is when performing a cache flush
> after running out of memory.
On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> >> > When a drm_crtc structure is destroyed
On 1 June 2016 at 13:11, Emil Velikov wrote:
> [+Daniel Vetter]
>
> Hi Ankitprasad,
>
> On 31 May 2016 at 07:19, wrote:
>
>> Signed-off-by: Chris Wilson
>> Signed-off-by: Rodrigo Vivi
> Seems like you've picked the patch from the mailing list, which does
> s/@/ at /. You might want to revert t
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> Between acquiring the this_cpu_ptr() and using it, ideally we don't want
> to be preempted and work on another CPU's private data. this_cpu_ptr()
> checks whether or not preemption is disable, and get_cpu_ptr() provides
> a convenient wrapper
[+Daniel Vetter]
Hi Ankitprasad,
On 31 May 2016 at 07:19, wrote:
> Signed-off-by: Chris Wilson
> Signed-off-by: Rodrigo Vivi
Seems like you've picked the patch from the mailing list, which does
s/@/ at /. You might want to revert that and normalise the emails.
> --- a/include/uapi/drm/i915_
By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
having a spinlock inside the per-cpu struct. The only place where we
actually may touch another CPU's data is when performing a cache flush
after running out of memory. Here, we can instead schedule a task to run
on the other CPU t
Between acquiring the this_cpu_ptr() and using it, ideally we don't want
to be preempted and work on another CPU's private data. this_cpu_ptr()
checks whether or not preemption is disable, and get_cpu_ptr() provides
a convenient wrapper for operating on the cpu ptr inside a preemption
disabled crit
== Series Details ==
Series: iommu: Disable preemption around use of this_cpu_ptr() (rev2)
URL : https://patchwork.freedesktop.org/series/8052/
State : success
== Summary ==
Series 8052v2 iommu: Disable preemption around use of this_cpu_ptr()
http://patchwork.freedesktop.org/api/1.0/series/805
On Wed, Jun 01, 2016 at 11:57:09AM +0200, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 09:38:20AM +0100, Chris Wilson wrote:
> > If a driver wants to more precisely control its initialisation and in
> > particular, defer registering its interfaces with userspace until after
> > everything is setu
On 31/05/16 07:19, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
frag
On Wed, Jun 01, 2016 at 12:01:44PM +0200, Daniel Vetter wrote:
> With the one bug in the error handling fixed, and the kerneldoc augmented:
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f0553ccd4f71..4f3d3bba08f7 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/d
Between acquiring the this_cpu_ptr() and using it, ideally we don't want
to be preempted and work on another CPU's private data. If we disable
preemption around this_cpu_ptr, we do not need the CPU local spinlock -
so long as take care that no other CPU is running that code as do perform
the cross-
1 - 100 of 127 matches
Mail list logo
