On Tue, May 21, 2019 at 11:06 PM Tetsuo Handa
wrote:
>
> On 2019/05/21 23:44, Daniel Vetter wrote:
> OOM notifiers should not depend on any locks or sleepable conditionals.
> If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
> it will deadlock. Thus, despite bloc
Quoting Michal Hocko (2019-05-22 07:34:42)
> On Wed 22-05-19 06:06:31, Tetsuo Handa wrote:
> [...]
> > Since OOM notifier will be called after shrinkers are attempted,
> > can i915 move from OOM notifier to shrinker?
>
> That would be indeed preferable. OOM notifier is an API from hell.
We were^W
On Thu, May 16, 2019 at 08:26:36AM +0200, Daniel Vetter wrote:
> On Wed, May 15, 2019 at 11:25 AM Christian König
> wrote:
> >
> > Am 15.05.19 um 10:58 schrieb Daniel Vetter:
> > > On Tue, May 14, 2019 at 04:05:14PM +0200, Christian König wrote:
> > >> To allow a smooth transition from pinning buf
On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #44 from Ondrej Lang ---
Created attachment 144316
--> https://bugs.freedesktop.org/attachment.cgi?id=144316&action=edit
Kernel log 5.1.3 showing amdgpu drm crash
Experiencing the same problem. On boot with any kernel > 4.20, the
Am 22.05.19 um 10:19 schrieb Daniel Vetter:
On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote:
[SNAP]
Just this functional comment, since I think api detail polishing is
premature if we're not yet aware of how this works.
+ /* When the importer is dynamic but the exporter is
Am Donnerstag, 16. Mai 2019, 19:25:08 CEST schrieb Matthias Kaehlcke:
> The GPU can be used as a thermal cooling device, add an optional
> '#cooling-cells' property.
>
> Signed-off-by: Matthias Kaehlcke
applied to drm-misc-next for 5.3
Am Donnerstag, 16. Mai 2019, 19:25:09 CEST schrieb Matthias Kaehlcke:
> The Mali GPU of the rk3288 can be used as cooling device, add
> a #cooling-cells entry for it.
>
> Signed-off-by: Matthias Kaehlcke
> Reviewed-by: Douglas Anderson
applied patches 2+3 for 5.3
Thanks
Heiko
___
Feature is controlled by DRM_CAP_SYNCOBJ_TIMELINE drm capability.
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
tests/amdgpu/syncobj_tests.c | 8
1 file changed, 8 insertions(+)
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
index a0c627d7..86
a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
b) Generated using make headers_install.
c) Generated from origin/drm-misc-next commit
982c0500fd1a8012c31d3c9dd8de285129904656"
Signed-off-by: Chunming Zhou
Suggested-by: Michel Dänzer
---
include/drm/drm.h | 2 ++
1 file changed, 2 insertions(
The devcoredump needs to operate on a stable state of the MMU while
it is writing the MMU state to the coredump. The missing lock
allowed both the userspace submit, as well as the GPU job finish
paths to mutate the MMU state while a coredump is under way.
Fixes: a8c21a5451d8 (drm/etnaviv: add init
Hi Lucas,
Seems I'm not getting a reply, so I'm hijacking one of your more
recent patches in the hope of attracting your attention.
A while back I sent a fix for a regression that recently occurred
with etnaviv, where the kernel spat out a warning when importing
buffers into etnaviv. You apparen
Hi Daniel,
On 5/21/19 4:23 PM, Daniel Vetter wrote:
> This is unused code since
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> when fbcon was made a compile-time s
Hi Russell,
Am Samstag, den 18.05.2019, 22:37 +0100 schrieb Russell King - ARM
Linux admin:
> On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> > Hi Russell,
> >
> > On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
> > wrote:
> > >
> > > Ping.
> >
> > This patch is
On Wed, May 22, 2019 at 12:04:27PM +0200, Lucas Stach wrote:
> Hi Russell,
>
> Am Samstag, den 18.05.2019, 22:37 +0100 schrieb Russell King - ARM
> Linux admin:
> > On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> > > Hi Russell,
> > >
> > > On Sat, May 18, 2019 at 2:51 PM Russell
Reorder code a bit and then remove no longer needed function
prototypes.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/pvr2fb.c | 141 ++-
1 file changed, 61 insertions(+), 80 deletions(-)
Index: b/drivers/video/fbdev/pvr2fb.c
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it mark pvr2fb_interrupt() and pvr2fb_common_init()
with __maybe_unused tag (to silence build warnings when
!SH_DREAMCAST), also convert mmio_base in struct pvr2fb_par to
'void __iomem *' from 'unsigned long' (
On 4/10/19 1:24 AM, Eric Anholt wrote:
> Hoegeun Kwon writes:
>
>> On 4/2/19 2:48 AM, Eric Anholt wrote:
>>> Hoegeun Kwon writes:
>>>
There is a problem when often dpms goes from off to on. pm idle is not
in sync and the problem occurs. Modify pm_runtime_put from
asynchronous to sy
cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
instead of "git rm" on them so they are still in present the tree.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 250 ---
On Wed, May 22, 2019 at 12:04 PM Bartlomiej Zolnierkiewicz
wrote:
>
>
> Hi Daniel,
>
> On 5/21/19 4:23 PM, Daniel Vetter wrote:
> > This is unused code since
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbc
Am 22.05.19 um 11:07 schrieb Chunming Zhou:
> a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
> b) Generated using make headers_install.
> c) Generated from origin/drm-misc-next commit
> 982c0500fd1a8012c31d3c9dd8de285129904656"
>
> Signed-off-by: Chunming Zhou
> Suggested-by: Michel Dänzer
On Tue, May 21, 2019 at 02:40:22PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> > Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> > to the memory manager. Now, unused BOs are only evicted when the space
> > is required.
On Wed, May 22, 2019 at 10:49 AM Christian König
wrote:
>
> Am 22.05.19 um 10:19 schrieb Daniel Vetter:
> > On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote:
> > [SNAP]
> > Just this functional comment, since I think api detail polishing is
> > premature if we're not yet aware of ho
On Wed, May 15, 2019 at 4:38 PM Christian König
wrote:
>
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
> held.
On Wed, May 22, 2019 at 1:27 PM Daniel Vetter wrote:
>
> On Wed, May 22, 2019 at 10:49 AM Christian König
> wrote:
> >
> > Am 22.05.19 um 10:19 schrieb Daniel Vetter:
> > > On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote:
> > > [SNAP]
> > > Just this functional comment, since I th
On Wed, May 22, 2019 at 12:24 PM Hoegeun Kwon
wrote:
> On 4/10/19 1:24 AM, Eric Anholt wrote:
>
> Hoegeun Kwon writes:
>
>
> On 4/2/19 2:48 AM, Eric Anholt wrote:
>
> Hoegeun Kwon writes:
>
>
> There is a problem when often dpms goes from off to on. pm idle is not
> in sync and the problem oc
Dave, Daniel
A set of misc fixes for various issues that have surfaced recently.
All Cc'd stable except the dma iterator fix which shouldn't really cause
any real issues on older kernels.
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:
https://bugs.freedesktop.org/show_bug.cgi?id=106302
--- Comment #1 from Pierre-Eric Pelloux-Prayer ---
I can reproduce but I don't think it's a bug in Mesa: your createTexture()
function doesn't use any synchronization mechanisms so you can't expect the
other thread/context to pick up the changes
Hi Paul and Maxime,
On Fri, Mar 15, 2019 at 7:03 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output which
> > can have an option to connect DSI interface by means of bridge
> > convertor.
> >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #2 from alvarex ---
now the bug has hit 19.0.5. There is a fix for steam if you uncheck "Enable Gpu
accelarated rendering in web views"
--
You are receiving this mail because:
You are the assignee for the bug.__
On 21/05/2019 19:23, Chris Wilson wrote:
> Quoting Rob Herring (2019-05-21 16:24:27)
>> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
>>>
>>
>> You forgot to update the subject. I can fixup when applying, but I'd
>> like an ack from Chris on patch 1.
Sorry about that - I'll try to be more c
In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
is dereferenced in the following codes. However, memory allocation
functions such as kstrdup() may fail and returns NULL. Dereferencing
this null pointer may cause the kernel go wrong. Thus we should check
this kstrdup() ope
https://bugs.freedesktop.org/show_bug.cgi?id=110721
alvarex changed:
What|Removed |Added
Version|unspecified |19.0
--
You are receiving this mail because:
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9 +--
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gp
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/am
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61 d
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
Signed-off-by: Christian König
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgp
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
Hello Christian König,
The patch 5918045c4ed4: "drm/scheduler: rework job destruction" from
Apr 18, 2019, leads to the following static checker warning:
drivers/gpu/drm/scheduler/sched_main.c:297 drm_sched_job_timedout()
error: potential NULL dereference 'job'.
drivers/gpu/drm/sc
Thanks for letting know, I will send a fix soon.
Andrey
On 5/22/19 9:07 AM, Dan Carpenter wrote:
> [CAUTION: External Email]
>
> Hello Christian König,
>
> The patch 5918045c4ed4: "drm/scheduler: rework job destruction" from
> Apr 18, 2019, leads to the following static checker warning:
>
>
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 90d7a82..ec7faca 100644
--- a/drivers/gpu/drm/sc
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #3 from Eric Engestrom ---
(In reply to alvarex from comment #2)
> now the bug has hit 19.0.5.
Are you saying the bug was not present in 19.0.4, but is now present in 19.0.5?
If so, that's only 22 new commits, 10 if you exclude obv
Am 22.05.19 um 15:57 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #4 from alvarex ---
yes the bug was not present on 19.0.4.
I'll give it a shot, I don't compile mesa from git in a standard way, I compile
it on opensuse build service.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=110729
Eric Engestrom changed:
What|Removed |Added
Product|Mesa|DRI
Version|19.1
This add the H6 mali compatible in the dt-bindings to later support
specific implementation.
Signed-off-by: Clément Péron
Reviewed-by: Rob Herring
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentati
Hello Sam,
On 5/8/19 11:06 AM, Daniel Vetter wrote:
> On Wed, May 08, 2019 at 10:33:03AM +0200, Daniel Vetter wrote:
>> On Tue, May 07, 2019 at 06:19:50PM +0200, Sam Ravnborg wrote:
>>> Hi Fabio
>>>
>>> On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote:
[Adding Sam, who is helping
Hello,
I have recently observed a memory leak issue with lima using
drm-misc-next, which I initially reported here:
https://gitlab.freedesktop.org/lima/linux/issues/24
It is an easily reproduceable memory leak which I was able to bisect to commit:
5918045c4ed4 drm/scheduler: rework job destructio
fix eror to error
Signed-off-by: Weitao Hou
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index f7043
If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs. This is because the caller of init expects error
pointers, but init returns NULL on error. Fix this by returning the
expected values on error.
Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg modu
On Fri, May 17, 2019 at 10:43 PM Grodzovsky, Andrey
wrote:
> On 5/17/19 3:35 PM, Erico Nunes wrote:
> > Lima currently defaults to an "infinite" timeout. Setting a 500ms
> > default timeout like most other drm_sched users do fixed the leak for
> > me.
>
> I am not very clear about the problem - so
The '#address-cells' and '#size-cells' properties were not defined in
the lm3630a bindings and would cause the following error when
attempting to validate the examples against the schema:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
'#address-cells', '#size-c
These barriers only apply to the read-modify-write operations; in
particular, they do not apply to the atomic_set() primitive.
Replace the barriers with smp_mb()s.
Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5XX targets")
Cc: sta...@vger.kernel.org
Reported-by: "Paul E. McKenney"
R
Use struct_size() helper to keep code simple.
Signed-off-by: xiaolinkui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 22bd21e..4717a64 1006
Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock.
Add an optional bus_clock at the init of the panfrost driver.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_device.c | 22 ++
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files cha
From: Icenowy Zheng
Some SoCs adds a bus clock gate to the Mali Midgard GPU.
Add the binding for the bus clock.
Signed-off-by: Icenowy Zheng
Signed-off-by: Clément Péron
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++
1 file changed, 6 ins
Panfrost has a re-implementation of drm_gem_dumb_map_offset() with an
extra bug regarding the handling of imported buffers. However we don't
really want Panfrost calling _dumb functions because it's not a KMS
driver.
This series renames drm_gem_dumb_map_offset() to drop the '_dumb' and
updates Pan
On 5/20/19 3:06 PM, Fabio Estevam wrote:
> There is a DRM version of the mxsfb driver for quite some time
> at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
> the fbdev version any longer.
>
> Remove the fbdev mxsfb driver in favour of the DRM version.
>
> Signed-off-by: Fabio E
Hi,
The Allwinner H6 has a Mali-T720 MP2 which should be supported by
the new panfrost driver. This series fix two issues and introduce the
dt-bindings but a simple benchmark show that it's still NOT WORKING.
I'm pushing it in case someone want to continue the work.
This has been tested with Mes
Convert to use hmm_range_fault().
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 93ed43c..8d56bd6 100644
--- a/drive
panfrost_ioctl_mmap_bo() contains a reimplementation of
drm_gem_map_offset() but with a bug - it allows mapping imported objects
(without going through the exporter). Fix this by switching to use the
newly renamed drm_gem_map_offset() function instead which has the bonus
of simplifying the code.
C
Hello!
Registration & Call for Proposals are now open for XDC 2019, which will
take place at the Concordia University Conference Centre in Montréal,
Canada on October 2-4, 2019.
Thanks to LWN.net, this year we have a brand new website using the
Indico platform, a fully open source event managemen
syzbot has bisected this bug to:
commit c0d9271ecbd891cdeb0fad1edcdd99ee717a655f
Author: Yong Zhao
Date: Fri Feb 1 23:36:21 2019 +
drm/amdgpu: Delete user queue doorbell variables
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1433ece4a0
start commit: f49aa1de Mer
On Mon, May 6, 2019 at 2:59 AM Tomi Valkeinen wrote:
>
> Hi Laurent, Andrey,
>
> On 03/05/2019 20:11, Laurent Pinchart wrote:
> >> I agree that if the panel Andrey mentioned is still used, we need to
> >> handle it somehow. But I think explicitly handling such a case is better
> >> than guessing.
On Wed, 22 May 2019, Gen Zhang wrote:
> In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
> is dereferenced in the following codes. However, memory allocation
> functions such as kstrdup() may fail and returns NULL. Dereferencing
> this null pointer may cause the kernel go
https://bugs.freedesktop.org/show_bug.cgi?id=110575
--- Comment #3 from tempel.jul...@gmail.com ---
Can you try R600_DEBUG=nohyperz? I have this kind of glitches in almost every
game with OpenGL/Gallium Nine on Polaris and this variable seems to help at
least in Skyrim with Gallium Nine (haven't t
From: Emil Velikov
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 --
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
3 files changed, 1 insertion(+), 8 deletions(-)
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1b9b6f5e48e1..672e0f8ad11
https://bugs.freedesktop.org/show_bug.cgi?id=107612
--- Comment #7 from bibitocarlos ---
Yeah, it's fixed.
thanks
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote:
> cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
> ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
> instead of "git rm" on them so they are still in present the tree.
>
> Signed-off-by: Gerd Hof
https://bugs.freedesktop.org/show_bug.cgi?id=110575
--- Comment #4 from Danylo ---
I'll try it later when will come home, thanks. It also happens in Minecraft but
much rarer (so I wasn't patient enough to bisect with it).
--
You are receiving this mail because:
You are the assignee for the bug.
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/tegra/drm.c | 28 ++--
1 file changed, 14 insertions(+), 14 dele
From: Emil Velikov
Should minimise the copy/paste mistakes, fixed with previous patches.
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Daniel, not 100% sold on the idea. That plus listing you as a contact
point ;-)
What do you thing?
Emil
---
Documentation/gpu/todo.rst | 19 +
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 18 +-
1 file ch
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: intel-...@lists.freedesktop.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #5 from alvarex ---
I need help, I build up mesa and set the git bisect good and bad commits, but
steam does not start because it needs 32bits libs and I can't seem to build
them. What option should I pass to meson or ninja to compil
On Wed, May 22, 2019 at 04:47:02PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Should minimise the copy/paste mistakes, fixed with previous patches.
>
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> Daniel, not 100% sold on the idea. That plus listing you as a contact
> point
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
>
> On Tue, 16 Apr 2019, Christian König wrote:
>
> > To allow a smooth transition from pinning buffer objects to dynamic
> > invalidation we first start to cache the sg_table for an attachment
> > unless the driver explicitly says to n
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #6 from Ropid ---
@alvarex:
Try starting chromium with this command line here, it makes it show corruption
everywhere for me here:
chromium --ignore-gpu-blacklist --enable-gpu-rasterization
--enable-native-gpu-memory-buffers --enab
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #7 from alvarex ---
(In reply to Ropid from comment #6)
> @alvarex:
>
> Try starting chromium with this command line here, it makes it show
> corruption everywhere for me here:
>
> chromium --ignore-gpu-blacklist --enable-gpu-raste
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #8 from Ropid ---
$ chromium --version
Chromium 74.0.3729.157 Arch Linux
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
When the driver probes, the PWM pin is automatically configured to its
default state, which should be the "pwm" function. However, at this
point we don't know the actual level of the pin, which may be active or
inactive. As a result, if the driver probes without enabling the
backlight, the PWM pin
From: Emil Velikov
Core DRM is safe when the callback is NULL.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/driv
From: Emil Velikov
Currently vmw_execbuf_ioctl() open-codes the permission checking, size
extending and copying that is already done in core drm.
Kill all the duplication, adding a few comments for clarity.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Veli
From: Emil Velikov
According to the docs - prevents firstopen/lastclose races. Yet never
used in practise.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
2
From: Emil Velikov
As of earlier commit the function is used only within drm core.
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_ioctl.c | 3 +--
include/drm/drm_ioctl.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.
From: Emil Velikov
Drop the custom ioctl io encoding check - core drm does it for us.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #9 from Pierre-Eric Pelloux-Prayer ---
> (In reply to Ropid from comment #6)
> @alvarex:
>
> Try starting chromium with this command line here, it makes it show
> corruption everywhere for me here:
>
> chromium --ignore-gpu-blackli
https://bugs.freedesktop.org/show_bug.cgi?id=110731
Andre Klapper changed:
What|Removed |Added
Product|DRI |Spam
Resolution|---
Am 22.05.19 um 18:17 schrieb Sumit Semwal:
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
On Tue, 16 Apr 2019, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment
unless t
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #10 from alvarex ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> > (In reply to Ropid from comment #6)
> > @alvarex:
> >
> > Try starting chromium with this command line here, it makes it show
> > corruption everywher
From: Sean Paul
a6xx_gmu_stop() already calls this function via shutdown or force_stop,
so it's not necessary to call it twice. This also knocks the irq depth
count out of sync, so nice to avoid.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 -
1 file changed, 1 deleti
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn
From: Sean Paul
The gmu driver is initalized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
I
From: Sean Paul
pdcptr and seqptr aren't necessarily valid, check them before trying to
unmap them.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/
1 - 100 of 144 matches
Mail list logo
