Query all domains and their signals and provide it this information
via struct etna_perfmon and the corresponding api functions.
v2:
- code style changes
- etna_perfmon_create(..): add missing clean up in error case
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
etnaviv/Makefi
Add some basic functions to query performance monitor domains and
signals. Also add support to submit performance monitor requests (pmrs).
There is only one small change in v3 compared to v2. We mark perfmon
bos as RW now.
Christian Gmeiner (3):
etnaviv: sync uapi header
etnaviv: add permon s
Import the etnaviv header changes from kernel commit 05916bed1 (drm-next)
The drm_etnaviv_gem_submit structure was extended to include performance
monitor requests. Also two new ioctls got added to be able to readout
performance monitor domains and their signals.
Signed-off-by: Christian Gmeiner
Add etna_cmd_stream_perf(..) to submit perform requests.
Userspace can submit pmrs via submit ioctl to sample perfmon
signals.
v3:
- mark perfmon bos as RW
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv-symbol-check | 1 +
etnaviv/etnaviv_cmd_stream.c | 20
etnaviv/
Hi Lucas,
thanks for review.
2017-12-14 12:48 GMT+01:00 Lucas Stach :
> Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
>> Add etna_cmd_stream_perf(..) to submit perform requests.
>> Userspace can submit pmrs via submit ioctl to sample perfmon
>> signals.
>>
>> Signed-off-by:
Roger and Chrisitian,
Correct me if I'm wrong, but It seems to me like a lot of the recent
changes to ttm_bo.c are to allow recursive reservation object locking in
the case of shared reservation objects, but only in certain functions
and with special arguments so it doesn't look like recursive
Hi.
On 12/14/2017 09:10 AM, Roger He wrote:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.
https://bugs.freedesktop.org/show_bug.cgi?id=104274
--- Comment #1 from Sverd Johnsen ---
with 4.15rc (linus tree from today)
[ 78.807441] [drm] amdgpu: finishing device.
[ 78.887439] amdgpu: [powerplay]
[ 78.887454] amdgpu: [powerplay]
[ 78.968349] BUG: unable to handle kernel NULL po
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #1 from Kai-Heng Feng ---
Created attachment 136186
--> https://bugs.freedesktop.org/attachment.cgi?id=136186&action=edit
lspci
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #2 from Kai-Heng Feng ---
Created attachment 136187
--> https://bugs.freedesktop.org/attachment.cgi?id=136187&action=edit
dmesg with drm.debug=0x0e
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104275
Bug ID: 104275
Summary: Stoney Ridge laptop display goes blank after HDMI gets
plugged/unplugged in extended mode.
Product: DRI
Version: unspecified
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=104274
Bug ID: 104274
Summary: Unable to cleanly unload kernel module: BUG: unable to
handle kernel NULL pointer dereference at
0258 (mutex_lock)
Product: DRI
On Thu, 2017-12-14 at 21:30 +0100, Daniel Vetter wrote:
> DK put some nice docs into the commit introducing driver private
> state, but in the git history alone it'll be lost.
>
> Also, since Ville remove the void* usage it's a good opportunity to
> give the driver private stuff some tlc on the d
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> We don't want people to accidentally stumble over there.
>
> Also rename the plane helpers to legacy plane helpers. After Ville's
> patch to make the clipping helper atomic and move it to
> drm_atomic_helper.c there's nothing left in there th
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> Complete a few missing bits, fix up the existing xcross-references and
> add a bunch more.
>
> Cc: Dave Airlie via lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 45
> +
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> It thinks we want to document the __printf(2,0) annotion. Not sure we
> want to teach it about all possible gcc-only flags, hence why I opted
> for the cheap trick of just moving it ahead of the kerneldoc.
>
> This is only a problem for stati
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> Also some breadcrumbs for how exactly to find this. Probably should
> pass drm_connector * or at least drm_display_info * to that function
> instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
> drm_connector_state (and the hd
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> DK put some nice docs into the commit introducing driver private
> state, but in the git history alone it'll be lost.
>
> Also, since Ville remove the void* usage it's a good opportunity to
> give the driver private stuff some tlc on the doc
https://bugs.freedesktop.org/show_bug.cgi?id=104142
--- Comment #4 from Mike Lothian ---
Tried again and it looks a little more promising:
0a214e2fb6b0a56519b6d5efab4b21475c233ee0 is the first bad commit
commit 0a214e2fb6b0a56519b6d5efab4b21475c233ee0
Author: Andrey Grodzovsky
Date: Thu Jul 1
https://bugzilla.kernel.org/show_bug.cgi?id=197851
--- Comment #4 from Tyler McLean (sonarsoundapplicati...@gmail.com) ---
(In reply to Harry Wentland from comment #3)
> Do you get different behavior if you enable the new DC display driver by
> passing amdgpu.dc=1 to the kernel?
Enabling that on
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #14 from Andrew ---
Charly,
Does X work all the time or only after reboot?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@l
https://bugs.freedesktop.org/show_bug.cgi?id=101483
FFAB changed:
What|Removed |Added
Priority|high|medium
Severity|critical
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #79 from Charly ---
Hi
It looks fine for me also !! On my carrizo A10-8700p rev c5 (probook 455 g3),
when booting archlinux with kernel 4.15-rc3, journalctl raises an error
reported in bug 104206
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #18 from James Lovinsky ---
Sorry, my mistake. Will refer to #95530, thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=104206
Charly changed:
What|Removed |Added
Attachment #136179|0 |1
is obsolete|
DK put some nice docs into the commit introducing driver private
state, but in the git history alone it'll be lost.
Also, since Ville remove the void* usage it's a good opportunity to
give the driver private stuff some tlc on the doc front.
Finally try to explain why the "let's just subclass drm_
Complete a few missing bits, fix up the existing xcross-references and
add a bunch more.
Cc: Dave Airlie via lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 45 +++
include/drm/drm_syncobj.h | 32
Also some breadcrumbs for how exactly to find this. Probably should
pass drm_connector * or at least drm_display_info * to that function
instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
drm_connector_state (and the hdmi stuff moved into that), so this is a
bit more work.
Cc: Vil
It thinks we want to document the __printf(2,0) annotion. Not sure we
want to teach it about all possible gcc-only flags, hence why I opted
for the cheap trick of just moving it ahead of the kerneldoc.
This is only a problem for static inline functions, since for
non-inline function the kerneldoc
We don't want people to accidentally stumble over there.
Also rename the plane helpers to legacy plane helpers. After Ville's
patch to make the clipping helper atomic and move it to
drm_atomic_helper.c there's nothing left in there that should be
useful for modern drivers.
v2: Laurent had a few q
Hi all,
Originally I wanted to include the atomic helper split-up here, but once
more I failed to get that done. So just a few patches to clean up
accumlated kernel-doc warnings, plus some real docs for the new best
practices for handling driver private objects. That was motivated by a
recent disc
On Thu, Dec 14, 2017 at 08:10:08PM +0100, Noralf Trønnes wrote:
> Make it possible to opt out of fbdev emulation.
> DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so
> this doesn't change the default behaviour.
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
For all t
On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
> Add helper for initializing fbdev deferred I/O.
>
> The cleanup could have happened in drm_fb_helper_fini(), but that would
> have required me to set fb_info->fbdefio to NULL in a couple of drivers
> before they call _fini() to avoi
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #17 from Gert Wollny ---
@James Lovinsky: since you are running the game on Intel graphics hardware you
probably saw #95530, this bug refers to AMD hardware (r600).
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #12 from Charly ---
hi team
By installing kerenl 4.15-rc3 the blamk screen related on bug 95306 seems to be
fixed, and I'm very happy for that !
the message :
[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank
On Thu, Dec 14, 2017 at 08:10:03PM +0100, Noralf Trønnes wrote:
> Add helpers to setup and teardown fbdev emulation.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 106
>
> include/drm/drm_fb_helper.h | 25 ++
>
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #11 from Charly ---
Created attachment 136181
--> https://bugs.freedesktop.org/attachment.cgi?id=136181&action=edit
kernel parameters set for 4.15-rc3
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #10 from Charly ---
Created attachment 136180
--> https://bugs.freedesktop.org/attachment.cgi?id=136180&action=edit
lspci -vv {Probook 455 G3 carrizo a10-8700p rev c5)
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #9 from Charly ---
Created attachment 136179
--> https://bugs.freedesktop.org/attachment.cgi?id=136179&action=edit
journalctl from a boot with a cold laptop archlinux
--
You are receiving this mail because:
You are the assignee f
On Thu, Dec 14, 2017 at 08:10:02PM +0100, Noralf Trønnes wrote:
> Set dev->fb_helper even when fbdev emulation is compiled out,
> so drivers can use it to free the structure.
> Clear it for consistency.
>
> Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
> Signed-off-by: Noralf Trøn
On Thu, Dec 14, 2017 at 04:15:27PM +0100, Christian König wrote:
> Am 14.12.2017 um 15:41 schrieb Daniel Vetter:
> > On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote:
> > > On Thu, Dec 14, 2017 at 8:37 AM, Christian König
> > > wrote:
> > > > AMD is the major user of TTM, so it also ma
Den 14.12.2017 17.25, skrev David Lechner:
On 12/11/2017 06:45 AM, Noralf Trønnes wrote:
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
I'm s
On Thu, Dec 14, 2017 at 6:50 AM, Daniel Vetter wrote:
>
> Imo that's enough that I figured better not delay until Dave is back.
> Linus, can you pls apply?
Pulled.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
Hi Dave, I'm back, resuming with fixes for v4.15.
BR,
Jani.
The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017
Add helpers to setup and teardown fbdev emulation.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 106
include/drm/drm_fb_helper.h | 25 ++
2 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
Add entry for conversion of drivers to new helpers.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index f421a54527d2..1e593370f64f 100644
--- a/Documenta
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo whic
Promote new helpers for dealing with fbdev emulation.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 823fc8f50d8
Use the new setup/teardown helpers as well as drm_fb_helper_defio_init().
Wrap fb_deferred_io_mmap() in ifdef so we can make fbdev optional.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
I had to touch drm_fbdev_cma_fini() here, but that will be rebased away
when I this patch is unbloc
Set dev->fb_helper even when fbdev emulation is compiled out,
so drivers can use it to free the structure.
Clear it for consistency.
Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
Signed-off-by: Noralf Trønnes
---
include/drm/drm_fb_helper.h | 7 +++
1 file changed, 7 inserti
Make it possible to opt out of fbdev emulation.
DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so
this doesn't change the default behaviour.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Hi,
This is a new attempt at simplifying fbdev setup/teardown in drivers.
Hopefully this one is better than my previous attempt. The previous
version allocated the drm_fb_helper struct as well, this time I leave it
to the driver.
I've included an fbdev deferred I/O setup helper as well since it's
Hi Dave,
Nothing too major here. A couple more ttm fixes for huge page and a kiq
fix for amdgpu.
The following changes since commit 90eeb3aa34831ff3d031589c0c24892eb8a07e51:
Merge tag 'drm-misc-fixes-2017-12-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2017-12-08 08:17:5
On 12/14/2017 06:48 PM, Emil Velikov wrote:
On 14 December 2017 at 13:37, Christian König
wrote:
AMD is the major user of TTM, so it also makes sense that we maintain
it.
Signed-off-by: Christian König
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS
On Thu, Dec 14, 2017 at 04:10:15PM +0100, Marek Szyprowski wrote:
> Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
> dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
> broken and never really functional. It will be replaced by a completely
> rewritten AP
On 14 December 2017 at 13:37, Christian König
wrote:
> AMD is the major user of TTM, so it also makes sense that we maintain
> it.
>
> Signed-off-by: Christian König
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 069ba63190b
Hi Dave,
More of the same. A lot of improvements from Noralf on this one. Nothing
really big here.
Regards,
Gustavo
drm-misc-next-2017-12-14:
drm-misc-next for 4.16:
Cross-subsystem Changes:
- Documentation for amlogic dt dt-bindings
Core Changes:
- Update edid-derived drm_display_info fi
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #16 from James Lovinsky ---
I'm using Stellaris v1.9 through the Steam client on Linux Mint 18.3 with the
MATE desktop.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=101483
FFAB changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #15 from james...@gmail.com ---
I have a thinkpad x220 (Intel HD 3000 integrated graphics). I can confirm that
this bug is fixed for me with MESA 17.2.4
/--/
ser
Hi,
On 14 December 2017 at 15:10, Marek Szyprowski wrote:
> Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
> dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
> broken and never really functional. It will be replaced by a completely
> rewritten API.
I
https://bugs.freedesktop.org/show_bug.cgi?id=104266
Bug ID: 104266
Summary: [polaris10][arm] blurred screen on AMD Radeon Pro WX
7100
Product: Mesa
Version: 17.2
Hardware: ARM
OS: All
Status: NEW
On 12/11/2017 06:45 AM, Noralf Trønnes wrote:
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
I'm starting to wonder if there is some sort of ra
Hi
I am trying to use amdgpupro opencl on top of amdgpu and everything
seems to run fine except this OOPS that I get once per execution:
[ 120.180229] BUG: sleeping function called from invalid context at
/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/work-shared/qt5122/kernel-source/mm/slab
On 12/14/2017 12:55 AM, Randy Dunlap wrote:
> On 12/13/2017 11:47 AM, Max Staudt wrote:
>> This is the initial prototype for a lean Linux kernel bootsplash.
>>
>> As it is now, it will show a black screen rather than a logo, and
>> only if manually enabled via the kernel cmdline:
>>
>> bootsplash
On 12/13/2017 10:35 PM, Daniel Vetter wrote:
> Using drm directly would allow you to flush the contents without the fake
> (and tbh, really expensive on most drivers) copy op. If you insist on
> using fbdev for this stuff, then at least add a new hook to flush cpu
> rendering.
My reasoning is as f
https://bugzilla.kernel.org/show_bug.cgi?id=197851
Harry Wentland (harry.wentl...@amd.com) changed:
What|Removed |Added
CC||harry.wentl...@a
Am 14.12.2017 um 15:41 schrieb Daniel Vetter:
On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote:
On Thu, Dec 14, 2017 at 8:37 AM, Christian König
wrote:
AMD is the major user of TTM, so it also makes sense that we maintain
it.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
broken and never really functional. It will be replaced by a completely
rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following
reaso
https://bugs.freedesktop.org/show_bug.cgi?id=104142
--- Comment #3 from Mike Lothian ---
I bisected this back to:
d21becbe0225de0e2582d17d4fbc73fbd103b1f7 is the first bad commit
commit d21becbe0225de0e2582d17d4fbc73fbd103b1f7
Author: Tony Cheng
Date: Wed Jul 12 11:54:10 2017 -0400
drm/a
Hi Linus&Dave,
drm-misc-fixes-2017-12-14:
drm-misc-fixes for 4.15-rc4
2 fixes for new core features, a corner case fix for the connnector_iter
fix from last week (that one is cc: stable) and 1 vc4 fix.
Imo that's enough that I figured better not delay until Dave is back.
Linus, can you pls appl
On 2017-12-13 02:24 PM, Leo Li wrote:
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memor
On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote:
> On Thu, Dec 14, 2017 at 8:37 AM, Christian König
> wrote:
> > AMD is the major user of TTM, so it also makes sense that we maintain
> > it.
> >
> > Signed-off-by: Christian König
>
> Acked-by: Alex Deucher
>
> > ---
> > MAINTAINE
On 12/14/2017 02:17 PM, Christian König wrote:
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a
nice cleanup there are two things below I think needs fixing.
On 11
On Thu, Dec 14, 2017 at 8:37 AM, Christian König
wrote:
> AMD is the major user of TTM, so it also makes sense that we maintain
> it.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MA
AMD is the major user of TTM, so it also makes sense that we maintain
it.
Signed-off-by: Christian König
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 069ba63190b2..72e8f8f750ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4805,6 +4
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a nice
cleanup there are two things below I think needs fixing.
On 11/15/2017 01:31 PM, Christian König wrote:
There
This is to allow clients running within VMs to be able to communicate
with a compositor in the host. Clients will use the communication
protocol that the compositor supports, and virtio-gpu will assist with
making buffers available in both sides, and copying content as needed.
It is expected that
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Add etna_cmd_stream_perf(..) to submit perform requests.
> Userspace can submit pmrs via submit ioctl to sample perfmon
> signals.
>
> Signed-off-by: Christian Gmeiner
> ---
> etnaviv/etnaviv-symbol-check | 1 +
> etnaviv/etn
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Query all domains and their signals and provide it this information
> via struct etna_perfmon and the corresponding api functions.
>
> v2:
> - code style changes
> - etna_perfmon_create(..): add missing clean up in error case
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #35 from Michel Dänzer ---
(In reply to FFAB from comment #32)
> I'll set this bug as r e s o l v e d when the solution is in released
> ubuntu versions available
This is an upstream bug tracker, not an Ubuntu one. If the problem
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Import the etnaviv header changes from kernel commit 05916bed1 (drm-
> next)
>
> The drm_etnaviv_gem_submit structure was extended to include
> performance
> monitor requests. Also two new ioctls got added to be able to readout
On Wed, 13 Dec 2017, Lucas De Marchi wrote:
> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
> allow the memory region to be stolen, otherwise we could have RAM being
> arbitrarily overwritten if for example we keep using the UEFI framebuffer,
> depending on how BIOS has s
Hi,
On Wed, Dec 13, 2017 at 05:23:04PM +0100, Thomas van Kleef wrote:
> I wondered if the following is still valid?
> In file sun4i_layer.c, func sun4i_layers_init
>
> --
> /*
> * The hardware is a bit unusual here.
> *
> * Even though it suppor
On Thu, Dec 14, 2017 at 11:30:21AM +0800, Chen-Yu Tsai wrote:
> >> > + /* Map output pins to channel 0 */
> >> > + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> >> > + SUN4I_TCON_GCTL_IOMAP_MASK,
> >> > + SUN4I_TCON_GCTL_IOMAP_TC
Hi Thomas:
Really sorry for that and will keep that in mind.
If necessary, next time I will send cover letter to provide more background and
details.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Thursday, December 14, 201
Am 14.12.2017 um 09:55 schrieb Thomas Hellstrom:
Hi, Christian,
On 12/14/2017 09:40 AM, Christian König wrote:
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need
to improve the commit messages. But this one somehow slipped through
because I discussed this change
On Wed, Dec 13, 2017 at 9:56 PM, Sinclair Yeh wrote:
> This looks okay to me. Although we should change eaction->tv_* type
> to 64-bit as well.
I thought about it but it would add significant complication without real gain,
as the eaction->tv_* pointers point into uapi structures (drm_vmw_event
Hi, Christian,
On 12/14/2017 09:40 AM, Christian König wrote:
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need
to improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the
Hi Laurent,
On Thu, Dec 14, 2017 at 9:17 AM, Laurent Pinchart
wrote:
> On Thursday, 14 December 2017 04:10:27 EET Kuninori Morimoto wrote:
>> >> + if ((fvco < 2000) ||
>> >> + (fvco > 409600ll))
>> >
>> > No need for the inner parentheses, and you can wri
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need to
improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the change completely logical for me, but without this context
eve
On Thu, Dec 14, 2017 at 07:01:57AM +, Priit Laes wrote:
> On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > Here is an attempt at supporting the LVDS output in our DRM driver. This
> > has been tested on the A83T (with DE2), but since everything is basically
> > in
Hi Thomas,
On Wed, Dec 13, 2017 at 05:16:22PM +0100, Thomas van Kleef wrote:
> Hi,
>
> On 13-12-17 16:33, Maxime Ripard wrote:
> > Hi,
> >
> > This is a first serie to enable the display engine frontend.
> >
> > This hardware block is found in the first generation Display Engine from
> > Allwin
Hello Sinclair Yeh,
This is a semi-automatic email about new static checker warnings.
The patch 060e2ad57041: "drm/vmwgfx: Add and connect plane helper
functions" from Mar 23, 2017, leads to the following Smatch complaint:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:466 vmw_du_primary_plane_atomic_
On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> Hi,
>
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modif
On Wed, Dec 13, 2017 at 03:41:49PM +, Daniel Stone wrote:
> Hi Russell,
>
> On 8 December 2017 at 12:31, Russell King wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion. This is mutually
> > exclusive with the CS
Hi Laurent
Thank you for your feedback
> > +* NOTES
> > +* N = (n + 1), M = (m + 1), P = 2
> > +* 2000 < fvco < 4096Mhz
>
> Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz -
> 4GHz would be a surprisingly large range.
It is 2kHz. This is came fr
Hi Noralf,
On Tue, 2017-12-12 at 22:58 +0100, Noralf Trønnes wrote:
> Den 04.12.2017 12.32, skrev Alexey Brodkin:
> > Hello,
> >
> > I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only
> > video output and I want to get Xserver working on top of that.
> >
> > I'm not very fa
The driver may sleep under a spinlock.
The function call path is:
drm_vma_offset_manager_destroy (acquire the spinlock)
drm_mm_takedown
show_leaks
kmalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool(DSAC) an
On 13-12-17 16:33, Maxime Ripard wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not
1 - 100 of 108 matches
Mail list logo
