On Thu, 10 Jan 2019 15:10:28 +
Peter Rosin wrote:
> Hi!
>
> I found an unfortunate issue while recoding plane handling to use
> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
> which is not correct. I simply fixed it (patch 1/4), but maybe that
> will cause regressions
https://bugs.freedesktop.org/show_bug.cgi?id=108260
Martin Jørgensen changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
Am Sonntag, 27. Januar 2019, 04:41:26 CET schrieb Stephen Rothwell:
> Hi all,
>
> In commit
>
> 053ff09f1a8f ("drm/rockchip: rgb: update SPDX license identifier")
>
> Fixes tag
>
> Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface")
looks like I accidentially lost the
Hey
On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> David Herrmann removed the last bits of drm_bus in:
> c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
>
> Remove the todo item.
>
> Signed-off-by: Sam Ravnborg
> Cc: David Herrmann
> Cc: David Airlie
> Cc: Daniel V
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #32 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
7990e4b7b3b63e417a8a8cb8b33bc732b7e9e32f
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=99923
Gregor Münch changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
gpiod_get_value() gives out a warning if access to the underlying gpiochip
requires sleeping, which is common for I2C based chips:
WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500
gpiod_get_value+0xd0/0x100
Modules linked in:
CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted
4.14.0-
On Sat, Jan 26, 2019 at 1:22 AM Sam Ravnborg wrote:
>
> Hi Jagan.
>
> Looks good, only very few nits left.
>
> On Sat, Jan 26, 2019 at 12:52:33AM +0530, Jagan Teki wrote:
> > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> >
> > Add panel driver for it.
> >
> > Tested-by: Bhusha
Am Donnerstag, 24. Januar 2019, 17:58:26 CET schrieb Daniel Vetter:
> This will set an fb name for the first time!
>
> Signed-off-by: Daniel Vetter
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
After looking up the r
https://bugs.freedesktop.org/show_bug.cgi?id=109466
Bug ID: 109466
Summary: Frozen display with Radeon RX 580 and Open Source
Drivers under GNU/Linux Debian Sid
Product: Mesa
Version: 18.3
Hardware: x86-64 (AMD64)
Am Samstag, 26. Januar 2019, 01:24:37 CET schrieb Heiko Stuebner:
> Before assigning window data, we should check if the yuv2yuv vop-data
> is set at all, because it looks like it can otherwise reference something
> wrong, as I saw on my rk3188 today which ended up in a null pointer
> dereference i
https://bugs.freedesktop.org/show_bug.cgi?id=105072
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Also looks for me. Thanks Thomas.
Reviewed-by: Huang Rui
> -Original Message-
> From: Koenig, Christian
> Sent: Friday, January 25, 2019 7:29 PM
> To: Thomas Zimmermann ; Huang, Ray
> ; Zhang, Jerry ;
> airl...@redhat.com; bske...@redhat.com; linux-graphics-
> maintai...@vmware.com; thel
https://bugs.freedesktop.org/show_bug.cgi?id=109229
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|NEW
Component|Drivers/Gallium
> Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
> static int drm_fbdev_client_restore(struct drm_client_dev *client)
> {
> - struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
> -
> - drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> +
https://bugs.freedesktop.org/show_bug.cgi?id=104520
--- Comment #24 from Yoshinori Gento ---
I met the similar problem twice.
Environment is following.
CPU: SkyLake(core i5 6500TE)
Distribution: debian(customised)
Kernel: 4.14.40
Mesa: 17.3.9
libdrm: 2.4.89
[197410.815921] [drm] GPU HANG:
16 matches
Mail list logo