On 08/17/2016 07:02 PM, Christian König wrote:
> Am 17.08.2016 um 18:35 schrieb Mario Kleiner:
>> On 08/17/2016 06:27 PM, Christian König wrote:
AMD uses copy swaps because radeon/amdgpu kms can't switch the
scanout mode from tiled to linear on the fly during flips.
>>> Well I'm not an
On 08/17/2016 07:43 PM, Alex Deucher wrote:
> On Wed, Aug 17, 2016 at 12:35 PM, Mario Kleiner
> wrote:
>> On 08/17/2016 06:27 PM, Christian König wrote:
AMD uses copy swaps because radeon/amdgpu kms can't switch the
scanout mode from tiled to linear on the fly during flips.
>>>
>>>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/17124607/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/056c0874/attachment.html>
ceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/354402b0/attachment.html>
Hi,
On 2016å¹´08æ18æ¥ 02:14, Sean Paul wrote:
> On Tue, Aug 16, 2016 at 3:36 PM, Lin Huang wrote:
>> when in ddr frequency scaling process, vop can not do
>> enable or disable operation, since dcf will base on vop vblank
>> time to do frequency scaling and need to get vop irq if there
>> have
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/357a9a5a/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160818/dcf7142d/attachment.html>
On 18/08/16 01:12 AM, Mario Kleiner wrote:
>
> Intel as display gpu + nouveau for render offload worked nicely
> on intel-ddx with page flipping, proper timing, dmabuf fence sync
> and all.
How about with AMD instead of nouveau in this case?
> Turns out that prime + page flipping currently does
On 18/08/16 08:51 AM, Mario Kleiner wrote:
>
> That's what the ati-ddx/amdgpu-ddx does at the moment, as it detects the
> mismatch in tiling flags and uses the DRI3/Present copy path instead of
> the pageflip path. The problem is that the servers Present
> implementation doesn't request a vsync'ed
Hi Linus,
Pretty quiet so far, a few amdgpu/radeon fixup for pcie pm changes,
and a couple of amdgpu fixes, along with some build fixes, and printk fix.
Dave.
The following changes since commit 4b9eaf33d83d91430b7ca45d0ebf8241da489c92:
Merge branch 'akpm' (patches from Andrew) (2016-08-11 16
https://bugzilla.kernel.org/show_bug.cgi?id=153121
Kontantin Ivanov changed:
What|Removed |Added
Severity|normal |low
--- Comment #28 from Kontantin Iv
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #29 from Michel Dänzer ---
(In reply to Kontantin Ivanov from comment #28)
> DRI_PRIME=1 glxinfo | grep -i opengl | egrep -i '(version|renderer)'
>
> OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile
[...]
> DRI_PRIME=1 g
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #30 from Kontantin Ivanov ---
Created attachment 229231
--> https://bugzilla.kernel.org/attachment.cgi?id=229231&action=edit
4.8.0-040800rc2 dmesg
dmesg for 4.8.0 rc2
--
You are receiving this mail because:
You are watching the a
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #31 from Kontantin Ivanov ---
Created attachment 229241
--> https://bugzilla.kernel.org/attachment.cgi?id=229241&action=edit
4.8.0-040800rc2 Xorg.0.log
Xorg log for 4.8.0 rc2
--
You are receiving this mail because:
You are watchi
The cec_get_edid_spa_location() function did not verify that the IEEE
identifier in the Vendor Specific Data Block matched the HDMI-LLC
identifier. This could result in the wrong VSDB block being returned.
For example, for HDMI 2.0 EDIDs there is also a HDMI Forum VSDB.
So check the IEEE identifi
Hey,
Op 17-08-16 om 21:55 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however,
> Afaiu the prime importing display gpu generates its own gem buffer
> handle (prime_fd_to_handle) from that dmabuf, importing scather-gather
> tables to access the dmabuf in system ram. As far as page flipping is
> concerned, so far those gem buffers / radeon_bo's aren't treated any
> differen
Am 18.08.2016 um 04:32 schrieb Michel Dänzer:
> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>> There is this other approach from NVidia's Alex Goins for their
>> proprietary driver, whose patches landed in the X-Server 1.19 master
>> branch a couple of weeks ago. I haven't read his patches in detai
On 18/08/16 04:41 PM, Christian König wrote:
>> Afaiu the prime importing display gpu generates its own gem buffer
>> handle (prime_fd_to_handle) from that dmabuf, importing scather-gather
>> tables to access the dmabuf in system ram. As far as page flipping is
>> concerned, so far those gem buffe
Acked-by: Vincent Abriou
On 08/16/2016 09:06 AM, Shawn Guo wrote:
> Since commit 4984979b9b90 ("drm/irq: simplify irq checks in
> drm_wait_vblank"), the drm driver feature flag DRIVER_HAVE_IRQ is only
> required for drivers that have an IRQ handler managed by the DRM core.
> Some drivers, armada,
Am 18.08.2016 um 09:52 schrieb Michel Dänzer:
> On 18/08/16 04:41 PM, Christian König wrote:
>>> Afaiu the prime importing display gpu generates its own gem buffer
>>> handle (prime_fd_to_handle) from that dmabuf, importing scather-gather
>>> tables to access the dmabuf in system ram. As far as p
On 18/08/16 05:20 PM, Christian König wrote:
> Am 18.08.2016 um 09:52 schrieb Michel Dänzer:
>> On 18/08/16 04:41 PM, Christian König wrote:
Afaiu the prime importing display gpu generates its own gem buffer
handle (prime_fd_to_handle) from that dmabuf, importing scather-gather
ta
Op 16-08-16 om 01:05 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> If userspace is running an synchronously atomic commit and interrupts the
> atomic operation during fence_wait() it will hang until the timer expires,
> so here we change the wait to be interruptible so it stop immediately w
On Wed, Aug 17, 2016 at 08:31:20PM +0100, Al Viro wrote:
> On Wed, Aug 17, 2016 at 03:24:38PM -0400, Rob Clark wrote:
>
> > hmm, looks like, at least on arm (not sure about arm64),
> >
> > #define __copy_from_user_inatomic __copy_from_user
> >
> > ie. copy_from_user() minus the access_ok() and m
On Wed, Aug 17, 2016 at 05:29:31PM -0400, Rob Clark wrote:
> On Wed, Aug 17, 2016 at 3:15 PM, Al Viro wrote:
> > On Wed, Aug 17, 2016 at 02:49:32PM -0400, Rob Clark wrote:
> >> If there is a copy_from_user() variant that will return an error
> >> instead of blocking, I think that is really what I
On 2016å¹´08æ13æ¥ 01:00, Sean Paul wrote:
> Since we can have multiple vops, use DRM_DEV_ERROR to
> make logs easier to process.
>
> Signed-off-by: Sean Paul
looks good for me
Acked-by: Mark Yao
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 ++--
> 1 file ch
Hi Sean
Thanks for send v3 patch for rk3399 vop support.
But sorry for that, I had changed my mind, those patches are deprecated,
I have new rk3399 patch on my downstream kernel, I will upstream soon.
Thanks.
On 2016å¹´08æ18æ¥ 01:20, Sean Paul wrote:
> From: Mark Yao
>
> No functional chang
On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
> Hi Sean
>
> Thanks for send v3 patch for rk3399 vop support.
>
> But sorry for that, I had changed my mind, those patches are deprecated,
> I have new rk3399 patch on my downstream kernel, I will upstream soon.
Wut? Imo merge Sean's pat
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/ba1edcc1/attachment.html>
el release.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/5dc00601/attachment-0001.html>
On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote:
> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
>> >Hi Sean
>> >
>> >Thanks for send v3 patch for rk3399 vop support.
>> >
>> >But sorry for that, I had changed my mind, those patches are deprecated,
>> >I have new rk3399 patch on my down
On 4 August 2016 at 17:09, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
>> On 4 August 2016 at 14:15, Sharma, Shashank
>> wrote:
>> > On 8/4/2016 5:04 PM, Emil Velikov wrote:
>> >>
>> >> On 4 August 2016 at 11:16, Sharma, Shashank
>> >> wrote:
>> >>>
>> >
On Thu, Aug 18, 2016 at 4:36 AM, Daniel Vetter wrote:
> On Wed, Aug 17, 2016 at 05:29:31PM -0400, Rob Clark wrote:
>> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
>> index 6cd4af4..4502e4b 100644
>> --- a/drivers/gpu/drm/msm/msm_gem.c
>> +++ b/drivers/gpu/drm/msm/msm_
Hi Daniel,
On 17 August 2016 at 21:56, Daniel Vetter wrote:
> --- /dev/null
> +++ b/include/drm/drm_property.h
> +#ifndef __DRM_PROPERTY_H__
> +#define __DRM_PROPERTY_H__
> +
> +#include
> +#include
> +#include
> +
Add the following fwd declaration since we use a pointer to the said
struct ?
On Thu 2016-08-11 13:45:53, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This interface is hidden from kernel headers and it is intended for use
> only for testing. So testers would have to add the ioctl information
> internally. This is to prevent misuse of this feature.
>
> v2: take in E
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/68b32006/attachment.html>
On Thu, Aug 18, 2016 at 06:55:12AM -0400, Rob Clark wrote:
> On Thu, Aug 18, 2016 at 4:36 AM, Daniel Vetter wrote:
> > On Wed, Aug 17, 2016 at 05:29:31PM -0400, Rob Clark wrote:
> >> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> >> index 6cd4af4..4502e4b 100644
> >>
On Thu, Aug 18, 2016 at 12:11:35PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On 17 August 2016 at 21:56, Daniel Vetter wrote:
> > --- /dev/null
> > +++ b/include/drm/drm_property.h
>
> > +#ifndef __DRM_PROPERTY_H__
> > +#define __DRM_PROPERTY_H__
> > +
> > +#include
> > +#include
> > +#inclu
On Thu, Aug 18, 2016 at 9:08 AM, Daniel Vetter wrote:
> On Thu, Aug 18, 2016 at 06:55:12AM -0400, Rob Clark wrote:
>> On Thu, Aug 18, 2016 at 4:36 AM, Daniel Vetter wrote:
>> > On Wed, Aug 17, 2016 at 05:29:31PM -0400, Rob Clark wrote:
>> >> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gp
Serious Sam 3 with
it, but let just say that is separate issue for now.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 17-08-16 om 21:55 schreef Lyude:
> >
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit 396f5d62d1a5fd99421855a08ffdef8edb43c76e upstream.
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:0
do not expect it to materialize this year.)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/d6736f7e/attachment.html>
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit 396f5d62d1a5fd99421855a08ffdef8edb43c76e upstream.
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:0
ression testing contribution from me.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/e3b172d9/attachment.html>
On Tue, Aug 16, 2016 at 11:26:43PM +0300, Vladimir Zapolskiy wrote:
> This change is needed to properly lock I2C bus driver, which serves
> DDC.
>
> The change fixes an overflow over zero of I2C bus driver user counter:
>
> root at imx6q:~# lsmod
> Not tainted
> dw_hdmi_ahb_audio 4082 0 - L
Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedes
Hi,
On 09-08-2016 15:55, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
> supported for HDMI 2.0 4k modes.
>
> Adding aspect ratio support in DRM layer:
>
> Best,
> Rares
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/d96d05fe/attachment-0001.html>
On Thu, Aug 18, 2016 at 03:34:12PM +0100, Jose Abreu wrote:
> Colorspace and scan information values were being written in wrong
> offsets. This patch corrects this and writes the values at the
> offsets specified in the databook.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: David A
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/cf75ea45/attachment-0001.obj>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/94f36a74/attachment.html>
On Thu, Aug 18, 2016 at 1:53 AM, Mark yao wrote:
> On 2016å¹´08æ13æ¥ 01:00, Sean Paul wrote:
>>
>> Since we can have multiple vops, use DRM_DEV_ERROR to
>> make logs easier to process.
>>
>> Signed-off-by: Sean Paul
>
>
> looks good for me
>
> Acked-by: Mark Yao
>
Applied to drm-misc
>> ---
On Tue, Aug 16, 2016 at 9:56 AM, Eric Engestrom
wrote:
> On Tue, Aug 16, 2016 at 09:18:34AM -0700, Sean Paul wrote:
>> On Tue, Aug 16, 2016 at 5:28 AM, Eric Engestrom
>> wrote:
>> > On Mon, Aug 15, 2016 at 04:18:04PM -0700, Sean Paul wrote:
>> >> This patch consolidates all the various log functi
On Mon, Aug 15, 2016 at 10:31 AM, wrote:
> From: Clint Taylor
>
> In the CEA-861 specification VIC 64 specifies a vsync pulse of 5 and
> a backporch of 36. Adjust vsync pulse width to match specification.
>
> Cc: Ville Syrjälä
> Signed-off-by: Clint Taylor
Seems to line up with the spec.
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
The drivers have to modify the atomic plane state during the prepare_fb
callback so they track allocations, reservations and dependencies for
this atomic operation involving this fb. In particular, how else do we
set the plane->fence from the framebuffer!
Signed-off-by: Chris Wilson
Cc: Daniel Ve
Now that we subclass our request from struct fence, we start using the
common primitives more freely and so avoid hand-rolling routines already
provided for by the helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 3 --
drivers/gpu/drm/i915/intel_display.c
On Tue, Aug 16, 2016 at 12:24:28PM +0300, Jyri Sarha wrote:
> Add "blue-and-red-wiring"-device tree property and update devicetree
> binding document. The red and blue components are reversed between 24
> and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the
> red and blue wires has
On Thu, Aug 18, 2016 at 4:23 AM, Michel Dänzer wrote:
> Maybe the rasterization as two triangles results in bad PCIe bandwidth
> utilization. Using the asynchronous DMA engine for these transfers would
> probably be ideal, but having the 3D engine rasterize a single rectangle
> (either using the
From: Markus Elfring
Date: Thu, 18 Aug 2016 21:38:37 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use memdup_user() rather than duplicating its implementation
Less function calls after error detection
drivers/gpu/drm/savage/sa
From: Markus Elfring
Date: Thu, 18 Aug 2016 18:12:03 +0200
Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/savage/savage_state.c | 12 +++--
From: Markus Elfring
Date: Thu, 18 Aug 2016 21:28:58 +0200
The kfree() function was called in a few cases by the
savage_bci_cmdbuf() function during error handling
even if a passed variable contained a null pointer.
Adjust jump targets according to the Linux coding style convention.
Signed-off-
On Thu, Aug 18, 2016 at 4:58 AM, Dave Airlie wrote:
>
> Hi Linus,
>
> Pretty quiet so far, a few amdgpu/radeon fixup for pcie pm changes,
> and a couple of amdgpu fixes, along with some build fixes, and printk fix.
It's missing the intel fixes pile from earlier this week, already
pinged Dave over
nux 4.8-rc2. See attached screenshot.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/f1bd7855/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/15fb49de/attachment-0001.html>
From: Markus Elfring
Date: Thu, 18 Aug 2016 22:35:14 +0200
Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 13
On Thu, Aug 18, 2016 at 07:00:16PM +0100, Chris Wilson wrote:
> The drivers have to modify the atomic plane state during the prepare_fb
> callback so they track allocations, reservations and dependencies for
> this atomic operation involving this fb. In particular, how else do we
> set the plane->f
From: Mark Yao
This patch documents the compatible strings for the big and little vop
in rockchip's drm driver.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Reviewed-by: Tomasz Figa
Signed-off-by: Mark Yao
[seanpaul removed superfluous description per t
From: Mark Yao
Reorder the compatible vop devices to be sorted by chip number
in ascending order.
Reviewed-by: Tomasz Figa
Signed-off-by: Mark Yao
[seanpaul added commit description per tfiga's review]
Signed-off-by: Sean Paul
---
Resending to add devicetree list
Changes in v3:
- Up
ok for Haswell.
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/b83a8aaa/attachment-0001.html>
_states
states: 3
0 boot
1 performance
2 battery
# cat pp_sclk_od
0
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160818/7bb321a5/attachment.html>
ives/dri-devel/attachments/20160818/ecc16e4d/attachment.html>
I've updated the stream->ops->read() interface to avoid the struct
i915_perf_read_state so it's hopefully a bit clearer to see the state being
passed around:
int (*read)(struct i915_perf_stream *stream,
char __user *buf,
size_t count,
size_t *off
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files chang
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gpu
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_dr
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Robert Br
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-pe
In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 163 +++
Instead of using vblank to trigger psr enable/disable, use the flush
timer built for fb_dirty all of the time. This allows us to mitiage
the various edge cases, e.g. cursor. non-event updates, etc..
Sean Paul (3):
drm/rockchip: Remove unnecessary vblank get/put from vop driver
drm/rockchip: Do
vblank references are handled in the top-level atomic complete
function, so no need to grab them again in the vop driver.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm
Instead of keying off vblank for psr, just flush every time
we get an atomic update. This ensures that cursor updates
will properly disable psr (without turning vblank on/off),
and unifies the paths between fb_dirty and atomic psr
enable/disable.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rock
3 seconds is a bit too conservative, drop this to 100ms for
better power savings.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/r
90 matches
Mail list logo
