On Sunday, 2016-11-06 08:03:47 -0500, Rob Clark wrote:
> On Sun, Nov 6, 2016 at 4:47 AM, Christian König
> wrote:
> > Am 05.11.2016 um 17:49 schrieb Rob Clark:
> >>
> >> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom
> >> wrote:
> >>>
> >>> On Saturday, 2016-11-05 13:11:36 +0100, Christian Kö
Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
drm: make drm_get_format_name thread-safe
Signed-off-by: Eric Engestrom
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Christian König
Suggested-by: Vi
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
>
> Signen-off-by: Christian König
> Reviewed-by: Chunming Zhou
> ---
> drivers/dma-buf/fence.c | 8 +---
> 1 file
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.
>
> When we don't call the wait function software signaling might never be
> activated. This can cause infinite polling loops with unreliable interrupt
> drive
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> reservation_object_wait_timeout_rcu() should enable signaling even with a zero
> timeout, but ttm_bo_wait() can also be called from atomic context and then it
> is not a good idea to do this.
>
> Signed-off-by: Christian
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>
> Otherwise signaling might never be activated on the fences. This can
> result in infinite waiting with hardware which has unreliable interrupts.
>
> v2: s
Hi Alex,
2016-11-04 Alex Deucher :
> From: Junwei Zhang
>
> v2: agd: rebase and squash in all the previous optimizations and
> changes so everything compiles.
> v3: squash in Slava's 32bit build fix
> v4: rebase on drm-next (fence -> dma_fence),
> squash in Monk's ioctl update patch
>
> Si
Hi Christophe,
2016-11-04 Christophe JAILLET :
> If 'sun4i_layers_init()' returns an error, propagate it instead of
> returning -EINVAL unconditionally.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Revi
Hi David, Daniel,
On Mon, Oct 31, 2016 at 05:17:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The series adds the initial ZTE VOU display controller DRM/KMS driver.
> There are still some features to be added, like overlay plane, scaling,
> and more output devices support. But it's already
2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Use core helpers to generate infoframes and generate vendor frame if
> necessary.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 141
> ++-
> drivers/gpu/drm/exynos
> create mode 100644 drivers/gpu/drm/zte/zx_hdmi_regs.h
> > create mode 100644 drivers/gpu/drm/zte/zx_plane.c
> > create mode 100644 drivers/gpu/drm/zte/zx_plane.h
> > create mode 100644 drivers/gpu/drm/zte/zx_plane_regs.h
> > create mode 100644 drivers/gpu/drm/zte/zx_vou.c
> > create mode 100644 drivers/gpu/drm/zte/zx_vou.h
> > create mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h
> >
> > --
> > 1.9.1
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/113f38c4/attachment-0001.html>
External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
so attach fences on exported buffers as exclusive
ones, if the buffers get imported by an external
client.
See discussion in thread:
https://lists.freedesktop.org/archives/dri-devel/2016-October/12237
Hi Dave,
Please consider to pull the following initial ZTE zxdrm driver support
for 4.10. The pull request is based on v4.9-rc1. If you need it to
be on other base, just let me know, and I will update it. Thanks.
Shawn
The following changes since commit 1001354ca34179f3db924eb66672442a173147
On 07/11/16 11:47 AM, Mario Kleiner wrote:
> External clients which import our bo's wait only
> for exclusive dmabuf-fences, not on shared ones,
> so attach fences on exported buffers as exclusive
> ones, if the buffers get imported by an external
> client.
>
> See discussion in thread:
> https://
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/b38effdc/attachment-0001.html>
tachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/6760d10c/attachment.html>
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/4df2ab39/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161107/ede0fa9d/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/64f587de/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/7dbc6ee0/attachment.html>
|--- |FIXED
--
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/20161107/8a51f79b/attachment.html>
|RESOLVED
--
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/20161107/7f1bac67/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/71fc9968/attachment.html>
On 4 November 2016 at 20:41, Christophe Fergeau wrote:
> On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
>> > Or maybe other parts of the
>> > kernel/userspace rely on this rounding down.
>>
>> This is where I suspect we could run in trouble. Odd resolutions simply
>> don't happen
On 07/11/16 03:56 AM, Sandeep wrote:
> Hello,
>
> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
> upstream kernel (or is this upto individual distros?)
>
> Is there any work left to be done/bugs to be fixed before it can be
> enabled by default?
There are still some fu
On 07/11/16 04:24 PM, Michel Dänzer wrote:
> On 07/11/16 03:56 AM, Sandeep wrote:
>> Hello,
>>
>> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
>> upstream kernel (or is this upto individual distros?)
>>
>> Is there any work left to be done/bugs to be fixed before it can
If I was not very clear for the first time, every time we send a patch
to drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not
only Android).
So even these aspect ratio patches were tested with full gnome-desktop,
and it worked well.
Regards
Shashank
On 11/3/2016 9:49 PM, Sharma
Am 07.11.2016 um 04:29 schrieb Michel Dänzer:
> On 07/11/16 11:47 AM, Mario Kleiner wrote:
>> External clients which import our bo's wait only
>> for exclusive dmabuf-fences, not on shared ones,
>> so attach fences on exported buffers as exclusive
>> ones, if the buffers get imported by an externa
Hey,
Same series as v2 except that I removed the use of camel case in patch 6/7.
Now it's only using an anonymous enum + int.
Christophe
qdev->gem.objects was initialized directly in qxl_device_init() rather
than going through qxl_gem_init(), and qxl_gem_fini() was never called.
Signed-off-by: Christophe Fergeau
---
drivers/gpu/drm/qxl/qxl_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
They are not used outside of their respective source file
Signed-off-by: Christophe Fergeau
---
drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/
The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
the resolutions we are going to present to user-space are going to be
rounded down to a multiple of 8. In the QXL arbitrary resolution case,
this is not useful.
This commit forces the actual width/height that was requested by t
It's always returning 0, and it's always ignored.
---
drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
drivers/gpu/drm/qxl/qxl_gem.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 5a4720a..feac7e6 100644
--- a/driver
qxl_crtc_set_from_monitors_config() is defined in qxl_drv.h but never
implemented.
Signed-off-by: Christophe Fergeau
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index a3c1131..5a4720a 100644
When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt,
we currently always notify userspace that there was some hotplug event.
However, gnome-shell/mutter is reacting to this event by attempting a
resolution change, which it does by issueing drmModeRmFB, drmModeAddFB,
and t
The message has to be terminated by a newline as it's not going to get
added automatically.
Signed-off-by: Christophe Fergeau
---
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 28c
Am 07.11.2016 um 02:10 schrieb Gustavo Padovan:
> Hi Alex,
>
> 2016-11-04 Alex Deucher :
>
>> From: Junwei Zhang
>>
>> v2: agd: rebase and squash in all the previous optimizations and
>> changes so everything compiles.
>> v3: squash in Slava's 32bit build fix
>> v4: rebase on drm-next (fence -> dm
On 07.11.2016 02:45, Inki Dae wrote:
>
> 2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> Use core helpers to generate infoframes and generate vendor frame if
>> necessary.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 141
>> ++--
2016ë
11ì 07ì¼ 17:05ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 07.11.2016 02:45, Inki Dae wrote:
>>
>> 2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> Use core helpers to generate infoframes and generate vendor frame if
>>> necessary.
>>>
>>> Signed-off-by: Andrzej Hajda
>>>
Hi,
> I think we should try it an see,
Ok, lets try. I'll go pick them up and prepare a pull with this and
some virtio-gpu bits,
Gerd
>
> It's always returning 0, and it's always ignored.
Missing the Signed-off-by.
Acked-by: Frediano Ziglio
You should add the Acked-by message when posting new
versions of the patch series.
Frediano
> ---
> drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
> drivers/gpu/drm/qxl/qxl_gem.c | 3 +--
> 2
>
> When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
> interrupt,
> we currently always notify userspace that there was some hotplug event.
>
> However, gnome-shell/mutter is reacting to this event by attempting a
> resolution change, which it does by issueing drmModeRmFB, drmM
On Mo, 2016-11-07 at 09:00 +0100, Christophe Fergeau wrote:
> Hey,
>
> Same series as v2 except that I removed the use of camel case in patch 6/7.
> Now it's only using an anonymous enum + int.
Can you please not drop the "PATCH" from $subject?
thanks,
Gerd
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/8255cfc1/attachment.sig>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/bb596270/attachment.html>
From: Gustavo Padovan
This new function should be used by drivers when setting a implicit
fence for the plane. It abstracts the fact that the user might have
chosen explicit fencing instead.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 30 ++
From: Gustavo Padovan
drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.
Cc: Philipp Zabel
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/imx/imx-drm-core.c | 6 --
1 file change
-test
everything.
--
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/20161107/05757a04/attachment.html>
From: Gustavo Padovan
drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_atomic.c | 3 ++-
1 file changed, 2 inse
From: Gustavo Padovan
Some of the members of struct drm_plane had extra comments so for these
add inline kernel comment to consolidate all documentation in one place.
Signed-off-by: Gustavo Padovan
---
include/drm/drm_plane.h | 61 +++--
1 file chang
On 11/05/2016 09:55 PM, Rob Clark wrote:
> Add basic state duplication/apply mechanism. Following commits will
> move actual global hw state into this.
>
> The state_lock allows multiple concurrent updates to proceed as long as
> they don't both try to alter global state. The ww_mutex mechanism
Hi,
Minor comments below. LGTM otherwise.
On 11/05/2016 09:56 PM, Rob Clark wrote:
> (re)assign the hw pipes to planes based on required caps, and to handle
> situations where we could not modify an in-use plane (ie. SMP block
> reallocation).
>
> This means all planes advertise the superset of f
On 11/05/2016 09:55 PM, Rob Clark wrote:
> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
> pipes are statically assigned to planes, but next step is to assign the
> hw pipes during plane->atomic_check() based on requested caps (scaling,
> YUV, etc). And then hw pipe re
esa fix this bug.
--
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/20161107/394da367/attachment.html>
On Mon, Nov 7, 2016 at 5:29 AM, Archit Taneja wrote:
>
>
> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>
>> Add basic state duplication/apply mechanism. Following commits will
>> move actual global hw state into this.
>>
>> The state_lock allows multiple concurrent updates to proceed as long as
>>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/e494912e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=107381
madbiologist changed:
What|Removed |Added
CC||madbiologist2016 at outlook.co
hanged, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/544f81c6/attachment.sig>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/fd9b4f90/attachment.sig>
e.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/49843cca/attachment.sig>
5 deletions(-)
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/31d3aa77/attachment.sig>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/86771c04/attachment.html>
d previously been enabled?
And even if we go this extra mile there's a possibility that the GPIO
was just left dangling by earlier software (or hardware) and leaving it
on would actually be worse than turning the panel off.
Thierry
-- next part --
A non-text attac
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/08980b9d/attachment.html>
ot;download raw diff" and have to search/sort out the
> paths by hand.
Hello Andy,
how did you solved this?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.
Am Montag, den 07.11.2016, 14:17 +0100 schrieb Thierry Reding:
> On Mon, Nov 07, 2016 at 06:12:43PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Nov 6, 2016 at 7:09 PM, Icenowy Zheng wrote:
> > > The enable gpio of simple-panel may be used by a simplefb or other
> > > driver on the panel's display befor
Am Montag, den 07.11.2016, 19:03 +0900 schrieb Gustavo Padovan:
> From: Gustavo Padovan
>
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
>
> Cc: Philipp Zabel
> Signed-off-by: Gustavo Padovan
> Reviewed-by:
On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja wrote:
>
>
> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>
>> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
>> pipes are statically assigned to planes, but next step is to assign the
>> hw pipes during plane->atomic_check() bas
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/f304fbce/attachment-0001.html>
Use core helpers to generate infoframes and generate vendor frame if necessary.
Signed-off-by: Andrzej Hajda
---
- changed 'ret >= 0' checks to '!ret'
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 141 ++-
drivers/gpu/drm/exynos/regs-hdmi.h | 2 +
2 files changed
osing the whole thing if I tried like that :-)
--
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/20161107/cf827281/attachment.html>
On 7 November 2016 at 07:43, Sharma, Shashank
wrote:
> If I was not very clear for the first time, every time we send a patch to
> drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not only
> Android).
>
> So even these aspect ratio patches were tested with full gnome-desktop, and
>
On 11/7/2016 8:18 PM, Rob Clark wrote:
> On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja
> wrote:
>>
>>
>> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>>
>>> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
>>> pipes are statically assigned to planes, but next step is to ass
On Mon, Nov 7, 2016 at 5:03 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
>
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
Regards
Shashank
On 11/7/2016 8:56 PM, Emil Velikov wrote:
> On 7 November 2016 at 07:43, Sharma, Shashank
> wrote:
>> If I was not very clear for the first time, every time we send a patch to
>> drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not only
>> Android).
>>
>> So even
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Michel Dänzer
>Sent: Monday, November 07, 2016 2:24 AM
>To: Sandeep
>Cc: dri-devel at lists.freedesktop.org
>Subject: Re: Enable AMDGPU for CIK by default
>
>On 07/11/16 03:56 AM, Sandee
~
ac_nir_to_llvm.c: In function 'si_llvm_init_export_args':
ac_nir_to_llvm.c:4059:13: error: 'LLVMReadNoneAttribute' undeclared (first use
in this function)
LLVMReadNoneAttribute);
^
ac_nir_to_llvm.c: In function 'e
On 7 November 2016 at 15:48, Sharma, Shashank
wrote:
> Regards
>
> Shashank
>
>
> On 11/7/2016 8:56 PM, Emil Velikov wrote:
>>
>> On 7 November 2016 at 07:43, Sharma, Shashank
>> wrote:
>>>
>>> If I was not very clear for the first time, every time we send a patch to
>>> drm-intel/dri-devel, we
On Fri, Nov 4, 2016 at 6:03 PM, Sumit Semwal wrote:
> Hi Alex,
>
> Thanks for the patches.
>
> On 4 November 2016 at 14:16, Alex Deucher wrote:
>> From: "monk.liu"
>>
>> Return the index of the first signaled fence. This information
>> is useful in some APIs like Vulkan.
>>
>> v2: rebase on drm
On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan wrote:
> Hi Christian,
>
> 2016-10-20 Christian König :
>
>> From: Christian König
>>
>> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>>
>> Otherwise signaling might never be activated on the fences. This can
>> result in infinite
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/b8cc6823/attachment.sig>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/643085ed/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/9ebb0be4/attachment.html>
> -Original Message-
> From: Pavel Machek [mailto:pavel at ucw.cz]
> Sent: Monday, November 07, 2016 1:40 PM
> To: Deucher, Alexander; Koenig, Christian; dri-devel at lists.freedesktop.org;
> kernel list
> Subject: v4.9-rc3: radeon oops on shutdown
>
> Hi!
>
> On old thinkpad T40p... with
On Fri, 04 Nov 2016, Dhinakaran Pandiyan
wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix this by increasing the array
> size to 7 and initialize
On 11/07/2016 08:55 AM, Christian König wrote:
> Am 07.11.2016 um 04:29 schrieb Michel Dänzer:
>> On 07/11/16 11:47 AM, Mario Kleiner wrote:
>>> External clients which import our bo's wait only
>>> for exclusive dmabuf-fences, not on shared ones,
>>> so attach fences on exported buffers as exclus
hes (as Russell suggested)?
I'll reply to his mail.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/f6460e69/attachment-0001.sig>
Rebased and updated with more feedback from Sourab and Matt.
In particular the patch that added the oa_min_timer_exponent sysctl parameter
has now been replaced with one adding an oa_max_sample_rate parameter in Hz.
This way userspace policy won't need to be tailored to different systems when
gen
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
Reviewed-by: Matthew Auld
Reviewed-by: Sourab Gupta
---
drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
drivers/
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
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
Reviewed-by: Matthew Auld
Review
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.
v2:
Make sure to initialize ->specific_ctx_id when opening, withou
The maximum OA sampling frequency is now configurable via a
dev.i915.oa_max_sample_rate sysctl parameter.
Following the precedent set by perf's similar
kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 61 ++
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
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_p
/free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/310f8f7b/attachment.sig>
1 - 100 of 124 matches
Mail list logo
