Hi,
On Sat, Nov 10, 2018 at 01:16:54PM +0200, Laurent Pinchart wrote:
> The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
> attempt to manage the runtime PM state of the connected DISPC, based on
> the rationale that the DISPC providing data to the encoders requires
>
Hi,
On Sat, Nov 10, 2018 at 01:16:53PM +0200, Laurent Pinchart wrote:
> The probe function performs hardware access to read the number of
> supported data lanes from a configuration register and thus requires the
> device to be active. Ensure this by surrounding the access with
>
Hi,
On Sat, Nov 10, 2018 at 01:16:52PM +0200, Laurent Pinchart wrote:
> The bind function performs hardware access (in hdmi4_cec_init()) and
> thus requires the device to be active. Ensure this by surrounding the
> bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.
>
> Fixes:
Hi,
On Sat, Nov 10, 2018 at 01:16:51PM +0200, Laurent Pinchart wrote:
> The DSS DT node contains children that describe the DSS components
> (DISPC and internal encoders). Each of those components is handled by a
> platform driver, and thus needs to be backed by a platform device.
>
> The
The pull request you sent on Sun, 11 Nov 2018 04:43:57 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-11-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/20ef6d06ef9a31a33516637a80521b9fc7f1f849
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 9 Nov 2018 at 19:13, Eric Engestrom wrote:
> Error message was invalid too, negative values aren't the number of
> devices, they're errno error codes.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Daniel Stone
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=96868
--- Comment #35 from bmil...@gmail.com ---
Forgot to said on last comment, maybe your high state is 1, not 2 (depends on
gpu)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=96868
--- Comment #34 from bmil...@gmail.com ---
(In reply to Mike Bendel from comment #33)
> I'm also experiencing the same issues, but on much lower refresh rates. I
> have a 3840x1600 monitor (LG 38UC99) and when running at 75Hz, display
>
Hi Linus,
Nothing too urgent in here, in case you want to leave until post
holidays. I'm in Vancouver for the next week, but should get most
stuff line up, though rc3 fixes might be late if I'm flying and
sleeping.
amdgpu has some display fixes, KFD ioctl fixes and a Vega20 bios
interaction fix.
Quoting Christian König (2018-10-19 10:27:11)
> From: Christian König
>
> Still contains some bugs.
>
> This reverts commit 48197bc564c7a1888c86024a1ba4f956e0ec2300.
>
> Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108490
> Signed-off-by: Christian König
The code for the old style of
This patchset adds a GEM object function table and makes use of it in
the CMA helper.
This was originally part of a shmem helper series[1] that didn't make
it. Daniel and Christian showed interest in the vtable part so I have
hooked it up to some refactoring in tinydrm in order to have a user.
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the
This adds functionality to the CMA helper which ensures that the kernel
virtual address is set on the CMA GEM object also for imported buffers.
The drivers have been audited to ensure that none set ->vaddr on imported
buffers, making the conditional dma_buf_vunmap() call in
Add a generic PRIME GEM mmap function.
v2: Fix link in docs (Daniel Vetter)
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 37 +
include/drm/drm_prime.h | 1 +
2 files changed, 38
The CMA helper now has the functionality to ensure a virtual address on
imported buffer so use that.
While touching all tinydrm drivers, remove the unnecessary inclusion of
drm_fb_helper.h in some drivers.
Cc: David Lechner
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
---
The majority of drivers use drm_gem_prime_export() and
drm_gem_prime_import() for these callbacks so let's make them the
default.
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 7 +++
drivers/gpu/drm/drm_prime.c | 10 --
https://bugs.freedesktop.org/show_bug.cgi?id=105664
--- Comment #4 from Yassine Oudjana ---
Comment on attachment 142424
--> https://bugs.freedesktop.org/attachment.cgi?id=142424
dmesg output
Note: I have not modified the kernel dmesg was ran under. Core clock is still
750MHz.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=105664
--- Comment #3 from Yassine Oudjana ---
Created attachment 142424
--> https://bugs.freedesktop.org/attachment.cgi?id=142424=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108704
Bug ID: 108704
Summary: 4.19 amdgpu Tonga powerplay regressions
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: All
Status: NEW
Severity:
The bind function performs hardware access (in hdmi4_cec_init()) and
thus requires the device to be active. Ensure this by surrounding the
bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.
Fixes: 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by:
Hello,
This series fixes crashes in the omapdss driver at both load and unload
time, due to runtime PM problems related to probe deferral. The bugs got
introduced in v4.20-rc, this should thus be considered as v4.20 fixes.
At the core of the problem comes commit 27d624527d99 ("drm/omap: dss:
The DSS DT node contains children that describe the DSS components
(DISPC and internal encoders). Each of those components is handled by a
platform driver, and thus needs to be backed by a platform device.
The corresponding platform devices are created in mach-omap2 code by a
call to
The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
attempt to manage the runtime PM state of the connected DISPC, based on
the rationale that the DISPC providing data to the encoders requires
ensuring that the display is active whenever the encoders are active.
While the DISPC
The probe function performs hardware access to read the number of
supported data lanes from a configuration register and thus requires the
device to be active. Ensure this by surrounding the access with
dsi_runtime_get() and dsi_runtime_put() calls.
Fixes: edb715dffdee ("drm/omap: dss: dsi: Move
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #35 from fin4...@hotmail.com ---
To prevent random kernel lock ups with Ryzen, enable RCU_NOCB_CPU in the kernel
configuration and boot the kernel with the rcu_nocbs=0-X command line
parameter. X is the cpu thread count -1. To fix
25 matches
Mail list logo
