https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #3 from Stas Sergeev ---
Essentially, when driver initializes, it puts 0
to /sys/class/hwmon/hwmon0/pwm1. And unless you
set up fancontrol (which is a major pita), this
0 remain there, no matter how you load you GPU.
It should put som
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #2 from Stas Sergeev ---
Even besides the fact that GPU was so hot I
couldn't even touch it?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #1 from Vedran MiletiÄ ---
You should produce some GPU load before the fan activates.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119211
Bug ID: 119211
Summary: amdgpu disables fan by default
Product: Drivers
Version: 2.5
Kernel Version: 4.5.5
Hardware: All
OS: Linux
Tree: Fedora
St
Thanks Oded. Sending v3 right away :)
On Sun, May 29, 2016 at 8:31 PM, Oded Gabbay wrote:
> On Thu, May 26, 2016 at 10:37 PM, Bhaktipriya Shridhar
> wrote:
>> alloc_workqueue replaces deprecated create_workqueue().
>>
>> create_workqueue has been replaced with alloc_workqueue with max_active
>>
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/3ea313f6/attachment.html>
alloc_workqueue replaces deprecated create_workqueue().
create_workqueue has been replaced with alloc_workqueue with max_active
as 0 since there is no need for throttling the number of active work items.
WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be
used in memory reclaim
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/20160529/6e116a2b/attachment.html>
t;https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/9758336b/attachment.html>
Now that the core helpers support nonblocking atomic commits there's
no need to invent that wheel separately (instead of fixing the bug in
the atomic implementation of virtio, as it should have been done!).
Cc: Gerd Hoffmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_displa
This is now handled by the core, drivers can totally ignore lifetime
issues of drm events.
Cc: Tomeu Vizoso
Cc: Mark yao
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22 --
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 -
drivers/gpu/drm
So totally untested ...
v2: Fixes from Tomeu.
v3: Send out vblank events correctly when shutting down a crtc for
good. This is part of the atomic interface contract.
v4: Properly protect vop->event.
Cc: Tomeu Vizoso
Cc: Mark yao
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rock
Right now still all blocking, no worker anywhere to be seen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 66a2
This is part of what atomic must implement. And it's also required
to be able to use the helper nonblocking support.
v2: Always send out the drm event, remove the planes_changed check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm/i915
Design ideas:
- split up the actual commit into different phases, and have
completions for each of them. This will be useful for the future
when we want to interleave phases much more aggressively, for e.g.
queue depth > 1. For not it's just a minimal optimization compared
to current commo
Just a bit of drive-by ocd.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d9504dfcd1cc..465a1212f4f0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic
atomic_flush seems to be the right place, right after we commit the
plane updates. Again use the fullproof version, since the pipe might
be off.
Cc: Boris Brezillon
Cc: Maxime Ripard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12
1 file changed, 12 inser
atomic_flush seems to be the right place, but I'm not entirely sure
whether this will catch them all. It could be that when disabling the
crtc we'll miss the vblank.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away
No idea how exactly fsl-du commits hw state changes, but here in flush
is probably the safest place.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away.
Cc: Stefan Agner
Signed-off-by: Daniel Vetter
---
drivers/g
Again, just doing them as blocking commits isn't cool.
>From a cursory check hdlcd does seem to at least try to handle
drm_pending_vblank_event, so hopefully this works.
Cc: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 +---
1 file changed, 1 insertion(+
Committing with block it is not.
Thanks to the fixed up vblank event handling we can just use the
helper support for nonblocking commits now.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps-arc at lists.infradead.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_drv.c | 8
The drm core has a nice ready-made helper for exactly the simple case
where it should fire on the next vblank.
Note that arming the vblank event in _begin is probably too early, and
might easily result in the vblank firing too early, before the new set
of planes are actually disabled. But that's k
This is just used for cleanup in preclose, and with the reworked event
handling code this is now done properly by the core.
Nuke it!
But it also shows that arc totally fails at sending out drm events for
flips. Next patch will hack that up.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps
- dev is redundant, we have state->atomic
- add stall parameter, which must be set when swapping needs to stall
for preceeding commits to stop looking at ->state pointers. Currently
all drivers need this to be, just prep work for a glorious future.
Signed-off-by: Daniel Vetter
---
drivers/gp
From: Gustavo Padovan
Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another drive
It's silly to have 2 mallocs when we could tie these two together.
Also, Gustavo adds another one in his per-crtc out-fence patches. And
I want to add more stuff here for nonblocking commit helpers.
In the future we can use this to store a pointer to the preceeding
state, making an atomic update
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-plane state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more per-
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-connector state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more
We want to hide drm_atomic_state internals better.
Cc: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
... and use it in msm&vc4. Again just want to encapsulate
drm_atomic_state internals a bit.
The const threading is a bit awkward in vc4 since C sucks, but I still
think it's worth to enforce this. Eventually I want to make all the
obj->state pointers const too, but that's a lot more work ...
Cc:
We want to hide drm_atomic_stat internals a bit better.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index cb37751bc99f.
We want to hide drm_atomic_state internals better.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 20
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/dri
We want to hide drm_atomic_state internals
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 20 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 12 +++---
drivers/gpu/drm/msm/msm_atomic.c | 35 ++
We want to encapsulate the drm_atomic_state internals.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 50ff90aea721..3e6d9f
This avois leaking drm_atomic_state internals into the helpers. The
only place where this still happens after this patch is
drm_atomic_helper_swap_state().
It's unavoidable there, and maybe a good indicator we should actually
move that function into drm_atomic.c.
Signed-off-by: Daniel Vetter
---
Hi all,
So I finally unlazied and implemented generic nonblocking atomic commit support
in the atomic helpers. Still an early draft, but stopped being a fireworks show
on i915 at least. Rockchip still oopses somewhere, virtio conversion is entirely
untested. Same for arc/hdlcd/fsl-du/sun4i. All th
On Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez wrote:
> To get KFD support in radeon we need the following
> initialization to happen in this order, their
> respective driver file that has its init routine
> listed next to it:
>
> 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
> 1. AMD IOMMUv2:
https://bugzilla.kernel.org/show_bug.cgi?id=119181
--- Comment #1 from Hristo Venev ---
The hang does not occur when the power state is set to low. There are also no
rendering glitches (otherwise some frames seem to have random triangles on
them).
--
You are receiving this mail because:
You are
On Thu, May 26, 2016 at 10:37 PM, Bhaktipriya Shridhar
wrote:
> alloc_workqueue replaces deprecated create_workqueue().
>
> create_workqueue has been replaced with alloc_workqueue with max_active
> as 0 since there is no need for throttling the number of active work items.
>
> WQ_MEM_RECLAIM has n
https://bugzilla.kernel.org/show_bug.cgi?id=119181
Bug ID: 119181
Summary: Hang in amdgpu_vm_bo_update_mapping with powerplay
enabled
Product: Drivers
Version: 2.5
Kernel Version: 4.5.4
Hardware: All
OS:
Hi Peter,
On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote:
> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
> > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
> > We therefore l
On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez wrote:
> To get KFD support in radeon we need the following
> initialization to happen in this order, their
> respective driver file that has its init routine
> listed next to it:
>
> 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
> 1. AMD IOMMUv2:
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f466673..a8a62e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3957,6 +3957,13 @@ T: git git://github.com/patjak/drm-gma500
S:
Add support for fbdev.
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 20 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 17 ++
drivers/gpu/drm/hisilicon/hibmc/hi
Add connector funcs and helper funcs for VDAC.
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 21 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 3 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 89
Add encoder funcs and helpers for VDAC.
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
drivers/gpu/drm/hisilico
Add crtc funcs and helper funcs for DE.
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 307
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h | 29 +++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +
d
Add plane funcs and helper funcs for DE.
Signed-off-by: Rongrong Zou
Signed-off-by: Jianhua Li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 170
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 41
Add DRM master driver for Hisilicon Hibmc SoC which used for
Out-of-band management. Blow is the general hardware connection,
both the Hibmc and the host CPU are on the same mother board.
+--+ +--+
| | PCIe | Hibmc |
|host CPU( |<->| display |
|arm64,x86)|
This patch set adds a new drm driver for Hisilicon Hibmc. Hibmc is a
base board management controller, usually it is used on server for
Out-of-band management purpose. In this patch set, we just support basic
function for Hibmc display subsystem. Hibmc display subsystem is connected
to host CPU by
Den 12.05.2016 20:25, skrev Noralf Trønnes:
> Provides helper functions for drivers that have a simple display
> pipeline. Plane, crtc and encoder are collapsed into one entity.
>
> Cc: jsarha at ti.com
> Signed-off-by: Noralf Trønnes
> ---
[...]
> diff --git a/drivers/gpu/drm/drm_simple_kms_
On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>>
>
> I just upgraded to 11.2. I'm getting errors like this in the log:
>
> [ 5383.723240] nouveau :09:
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/da6b935c/attachment.html>
On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote:
> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
>>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>>>
>>
>> I just upgraded to 11.2. I'm getting err
/archives/dri-devel/attachments/20160529/fb62b862/attachment.html>
On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>
I just upgraded to 11.2. I'm getting errors like this in the log:
[ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000
engine 07 [PBDMA0] client 06 [
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/ecfc2378/attachment.html>
|Unigine Heaven 4.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/20160529/39c9d116/attachment.html>
Could you try to apply the following patch [1], hopefully this fixes
the issue for you.
[1] https://patchwork.freedesktop.org/patch/89111/
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/20160529/14a3d356/attachment.html>
ing the issue more severe. The
frequency of "black triangles on screen" in Tomb Raider is higher.
--
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/archi
This print can really spam the kernel log in case we are truncating
mem_banks, so just print this info once. It should also not be classified
as warning.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160529/2b719567/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/c9904553/attachment-0001.html>
64 matches
Mail list logo
