15-rc1: radeon modesetting fails

> -Original Message- > From: Kertesz Laszlo [mailto:laszlo.kertesz at gmail.com] > Sent: Tuesday, April 15, 2014 5:50 PM > To: Borislav Petkov > Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI > developers; lkml > Subject: Re: 15-rc1: radeon modesetting fails >

15-rc1: radeon modesetting fails

Borislav Petkov wrote: > On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote: >> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, >> drm, mesa built from git today. I see nothing and receive no message >> on the monitors (i have 2 identical ones, one on the DVI

15-rc1: radeon modesetting fails

Alex Deucher wrote: > On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov wrote: >> Hi Christian, >> >> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote: >>> Hi Borislav, >>> >>> that's a known issue and should be fixed in the next rc, see this >>> bugreport:

15-rc1: radeon modesetting fails

On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote: > Honestly didnt try that but i assume yes, since the screens go black > when it should change resolution. Pls try it and let us know whether you see the machine booting further, albeit without modesetting. Thanks. --

[Bug 66963] Rv6xx dpm problems

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/b814cae0/attachment.html>

15-rc1: radeon modesetting fails

On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote: > Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, > drm, mesa built from git today. I see nothing and receive no message > on the monitors (i have 2 identical ones, one on the DVI andother on > HDMI), but the

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

On 15 April 2014 18:41, Tomasz Stanislawski wrote: > On 04/15/2014 11:42 AM, Rahul Sharma wrote: >> Hi Tomasz, >> >> On 15 April 2014 14:57, Tomasz Stanislawski >> wrote: >>> Adds support for limitation of maximal pixel clock of HDMI >>> signal. This feature is needed on boards that contains

[Bug 66963] Rv6xx dpm problems

ecause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/7151be50/attachment.html>

[Bug 66963] Rv6xx dpm problems

ist? I thought it is X-related. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/d066eaf4/attachment.html>

[Bug 66963] Rv6xx dpm problems

as scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/03745b3f/attachment-0001.html>

[Bug 66963] Rv6xx dpm problems

- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/1019fd6c/attachment.html>

[Bug 66963] Rv6xx dpm problems

An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/106643e1/attachment.html>

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

2014-04-15 16:00 GMT+09:00 Ben Skeggs : > - Original Message - >> From: "Daeseok Youn" >> To: airlied at linux.ie >> Cc: bskeggs at redhat.com, dri-devel at lists.freedesktop.org, linux-kernel >> at vger.kernel.org >> Sent: Tuesday, 15 April, 2014 11:56:49 AM >> Subject: [PATCH]

[Bug 66963] Rv6xx dpm problems

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/0452c18f/attachment.html>

[Bug 66963] Rv6xx dpm problems

org/archives/dri-devel/attachments/20140415/27a1f36c/attachment.html>

[Bug 76484] [radeonsi] Strike Suit Zero fail to start

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/1ad29d2a/attachment.html>

Possible fb ref count issue with drm_plane_force_disable()

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/043584e0/attachment-0001.sig>

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

On 04/15/2014 03:42 PM, Rahul Sharma wrote: > On 15 April 2014 18:41, Tomasz Stanislawski > wrote: >> On 04/15/2014 11:42 AM, Rahul Sharma wrote: >>> Hi Tomasz, >>> >>> On 15 April 2014 14:57, Tomasz Stanislawski >>> wrote: Adds support for limitation of maximal pixel clock of HDMI

15-rc1: radeon modesetting fails

On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian K?nig wrote: > >Does reverting: > >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179 > >fix the issue? We may need to tweak the pll parameters for older asics. > > Yeah, indeed

[PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit

> -Original Message- > From: Tomasz Figa [mailto:tomasz.figa at gmail.com] > Sent: Monday, April 14, 2014 11:05 PM > To: Inki Dae; 'Andrzej Hajda' > Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell King'; > dri-devel at lists.freedesktop.org; 'Marek Szyprowski' >

[Bug 66963] Rv6xx dpm problems

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/eb33e624/attachment.html>

[PATCH] drm/exynos: balance framebuffer refcount

exynos_drm_crtc_mode_set assigns primary framebuffer to plane without taking reference. Then during framebuffer removal it is dereferenced twice, causing oops. The patch fixes it. Signed-off-by: Andrzej Hajda --- Hi, This patch fixes framebuffer refcount balancing. The issue appeared after

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

Hi Tomasz, On 15 April 2014 14:57, Tomasz Stanislawski wrote: > Adds support for limitation of maximal pixel clock of HDMI > signal. This feature is needed on boards that contains > lines or bridges with frequency limitations. > > Signed-off-by: Tomasz Stanislawski > --- >

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

On 04/15/2014 11:42 AM, Rahul Sharma wrote: > Hi Tomasz, > > On 15 April 2014 14:57, Tomasz Stanislawski > wrote: >> Adds support for limitation of maximal pixel clock of HDMI >> signal. This feature is needed on boards that contains >> lines or bridges with frequency limitations. >> >>

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

On Mon, Apr 14, 2014 at 5:35 PM, Ben Skeggs wrote: > On Fri, Apr 11, 2014 at 5:34 PM, Alexandre Courbot > wrote: >> On 04/11/2014 04:31 PM, Ben Skeggs wrote: >>> >>> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot >>> wrote: On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:

15-rc1: radeon modesetting fails

> Does reverting: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179 > fix the issue? We may need to tweak the pll parameters for older asics. Yeah, indeed the most likely cause. Please provide dmesg outputs created with

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

On 15 April 2014 14:48, Sylwester Nawrocki wrote: > On 15/04/14 10:41, Sachin Kamat wrote: >> On 15 April 2014 11:17, YoungJun Cho wrote: >>> This patch adds sysreg device node, and sysreg property to fimd device node >>> which is required to use I80 interface. >>> >>> Signed-off-by: YoungJun

Possible fb ref count issue with drm_plane_force_disable()

ce =). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/e1cde621/attachment-0001.sig>

[RFC PATCH 14/14] ARM: dts: exynos5420: add dsi node

This patch adds common part of dsi node. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi

[RFC PATCH 13/14] ARM: dts: exynos5420: add mipi-phy node

This patch adds mipi-phy node for MIPI-DSI device. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

This patch adds sysreg device node, and sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos5.dtsi |6 ++ 1 file changed, 6 insertions(+) diff --git

[RFC PATCH 11/14] ARM: dts: exynos4: add system register node

This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi

[RFC PATCH 10/14] drm/panel: add S6E3FA0 driver

This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile|1 +

[RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings

This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings, delays and physical size. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 52

[RFC PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

The offset of register DSIM_PLLTMR_REG in Exynos5420 is different from the one in Exynos4 SoC. In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead. So this patch adds driver data to distinguish it.

[RFC PATCH 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible

This patch adds exynos5420 SoC support. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[RFC PATCH 06/14] drm/exynos: support MIPI DSI command mode

This patch adds I80 interface for FIMD to support command mode panel. For this, the below features are added: - Set display interface mode relevant registers properly according to the interface type from DT - Add TE interrupt handler . FIMD driver should know TE signal from lcd panel to avoid

[RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

In case of using CPU interface panel, the relevant registers should be set. So this patch adds relevant dt bindings. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt |9 + 1 file changed, 9

[RFC PATCH 04/14] ARM: dts: add exynos5 compatible to sysreg

This patch adds sysreg support for exynos5 SoCs. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file changed, 1 insertion(+) diff --git

[RFC PATCH 03/14] drm/exynos: use wait_event_timeout() for safety usage

There could be the case that the page flip operation isn't finished correctly with some abnormal condition such as panel reset. So this patch replaces wait_event() with wait_event_timeout() to avoid waiting for page flip completion infinitely. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae

[RFC PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

Some phy control registers are not kept after software reset. So this patch makes the clocks containing phy control to be set after software reset. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +- 1 file

[RFC PATCH 01/14] drm/exynos: dsi: move the Eot packets configuration point

This configuration could be used in MIPI DSI command mode also. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[RFC PATCH 00/14] drm/exynos: support MIPI DSI command mode display

This patch series includes the following: - FIMD I80 interface - DSI command mode interface for Exynos5420 - S6E3FA0 command mode type panel driver - Some bugs modification The patch series is based on exynos-drm-next branch. Thank you. Best regards YJ YoungJun Cho (14): drm/exynos: dsi: move

[Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

-- Forwarded message -- From: Date: 15 April 2014 14:32 Subject: [Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected" To: dri-devel at lists.freedesktop.org

[Bug 66963] Rv6xx dpm problems

gnee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/4425fdd0/attachment.html>

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

On 15 April 2014 11:17, YoungJun Cho wrote: > This patch adds sysreg device node, and sysreg property to fimd device node > which is required to use I80 interface. > > Signed-off-by: YoungJun Cho > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > arch/arm/boot/dts/exynos5.dtsi |

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

On Tue, Apr 15, 2014 at 12:22 PM, Ville Syrj?l? wrote: > Although I'm not sure EINVAL is the best choice here. Maybe ENOSYS? We return -EINVAL everywhere else where we don't support a giving config, e.g. lack of dpll, unsupported plane scaling, pixel format mismatch of the primary plane (since

15-rc1: radeon modesetting fails

Hi Christian, On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote: > Hi Borislav, > > that's a known issue and should be fixed in the next rc, see this > bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009 > > You might also want to try my branch with 3.15 fixes which

[RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings

On 15 April 2014 11:17, YoungJun Cho wrote: > This patch adds DT bindings for s6e3fa0 panel. > The bindings describes panel resources, display timings, delays > and physical size. > > Signed-off-by: YoungJun Cho > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- >

Possible fb ref count issue with drm_plane_force_disable()

s scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/8d4e301b/attachment-0001.sig>

[RFC PATCH 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible

On 15 April 2014 11:17, YoungJun Cho wrote: > This patch adds exynos5420 SoC support. This patch just updates binding documentation :) > Signed-off-by: YoungJun Cho > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > .../devicetree/bindings/video/exynos_dsim.txt |4

[RFC PATCH 14/14] ARM: dts: exynos5420: add dsi node

Hi YoungJun, On 15 April 2014 11:17, YoungJun Cho wrote: > This patch adds common part of dsi node. > > Signed-off-by: YoungJun Cho > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > arch/arm/boot/dts/exynos5420.dtsi | 14 ++ > 1 file changed, 14 insertions(+) > >

[RFC PATCH 04/14] ARM: dts: add exynos5 compatible to sysreg

Hi YoungJun, On 15 April 2014 11:17, YoungJun Cho wrote: > This patch adds sysreg support for exynos5 SoCs. The patch title and commit description seem a bit off here. This patch does not add support per se. It only updates the binding documentaion. -- With warm regards, Sachin

[Bug 73901] Kernel crash after modprobe radeon runpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #14 from Alex Deucher --- (In reply to Pali Roh?r from comment #13) > (In reply to Alex Deucher from comment #11) > > Created attachment 132311 [details] > > avoid a possible crash when runpm is forced on non-ATPX systems > > > > Fix

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote: > After thinking about this topic a bit more I've reached the conclusion > that implementing this doesn't make sense: > > - The locking is all wrong: set_config(NULL) will also unlink encoders > and connectors, but those links are

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

line in grub. If that helps, the patches I mentioned may help. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/fadbf

[Bug 66963] Rv6xx dpm problems

ubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/86c192b7/attachment.html>

[Bug 66963] Rv6xx dpm problems

and then it's golden. Not a big issue though would love to see that fixed finally, -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140

[PATCH 4/4] drm/radeon: don't allow runpm=1 on systems with out ATPX

vgaswitcheroo and the ATPX ACPI methods are required to power down the dGPU. bug: https://bugzilla.kernel.org/show_bug.cgi?id=73901 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_kms.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-)

[PATCH 3/4] drm/radeon: fix ATPX detection on non-VGA GPUs

Some newer PX laptops have the pci device class set to DISPLAY_OTHER rather than DISPLAY_VGA. This properly detects ATPX on those laptops. Based on a patch from: Pali Roh?r Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org Cc: airlied at gmail.com ---

[PATCH 2/4] drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)

Avoids a crash in certain cases when thermal irqs are generated before the display structures have been initialized. v2: fix the vblank and vrefresh helpers as well bug: https://bugzilla.kernel.org/show_bug.cgi?id=73931 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org ---

[PATCH 1/4] drm/radeon: properly unregister hwmon interface (v2)

Need to properly unregister the hwmon device on driver unload. v2: minor clean up bug: https://bugzilla.kernel.org/show_bug.cgi?id=73931 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_pm.c | 21 +++-- 1 file changed, 15

[PATCH 0/6] drm/omap: Misc fixes

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140415/2e6edd55/attachment-0001.sig>

Possible fb ref count issue with drm_plane_force_disable()

On 04/15/2014 12:10 PM, Rob Clark wrote: > On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen > wrote: >> On 14/04/14 11:43, Tomi Valkeinen wrote: >>> On 11/04/14 14:50, Ville Syrj?l? wrote: >>> > So the explicit unref done by drm_plane_force_disable() seems a bit out > of place. I can't

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #22 from Ilya Tumaykin --- Reproducible with 3.14.0 kernel. -- You are receiving this mail because: You are watching the assignee of the bug.

Possible fb ref count issue with drm_plane_force_disable()

unreference All the other unrefs I can explain, except the drm_plane_force_disable() one. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/1db17cda/attachment-0001.sig>

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

Am Dienstag, den 15.04.2014, 11:27 +0200 schrieb Tomasz Stanislawski: > Adds support for limitation of maximal pixel clock of HDMI > signal. This feature is needed on boards that contains > lines or bridges with frequency limitations. > > Signed-off-by: Tomasz Stanislawski > --- >

15-rc1: radeon modesetting fails

Hi Borislav, that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009 You might also want to try my branch with 3.15 fixes which includes the necessary patch for this:

[PATCH] drm/radeon: memory leak on bo reservation failure. v2

From: Quentin Casasnovas On bo reservation failure, we end up leaking fpriv. v2 (chk): rebased and added missing free on vm failure as well Fixes: 5e386b574cf7e1 ("drm/radeon: fix missing bo reservation") Cc: stable at vger.kernel.org Cc: Christian K?nig Cc:

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

Adds support for limitation of maximal pixel clock of HDMI signal. This feature is needed on boards that contains lines or bridges with frequency limitations. Signed-off-by: Tomasz Stanislawski --- .../devicetree/bindings/video/exynos_hdmi.txt |4

[PATCHv2 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

This patch add proper compatibles for Mixer and HDMI chip available on exynos4210 SoCs. Signed-off-by: Tomasz Stanislawski --- drivers/gpu/drm/exynos/exynos_hdmi.c |7 +++ drivers/gpu/drm/exynos/exynos_mixer.c |3 +++ 2 files changed, 10 insertions(+) diff --git

[PATCHv2 2/4] drm: exynos: mixer: fix using usleep() in atomic context

This patch fixes calling usleep_range() after taking reg_slock using spin_lock_irqsave(). The mdelay() is used instead. Waiting in atomic context is not the best idea in general. Hopefully, waiting occurs only when Video Processor fails to reset correctly. Signed-off-by: Tomasz Stanislawski ---

[PATCHv2 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

This patch eliminates redundant checks while retrieving HPD gpio from DT during HDMI's probe(). Signed-off-by: Tomasz Stanislawski --- drivers/gpu/drm/exynos/exynos_hdmi.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c

[PATCHv2 0/4] drm: exynos: update/fixes to HDMI driver

Hi everyone, This patchset adds 4 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Changelog: v2: * fix check with gpio_is_valid() * use U32_MAX instead of ULONG_MAX to be 64-bit-friendly * use hdmi_driver_data as hdmi's compatile

linux-next: manual merge of the drm-intel tree with the tree

+ ret = DEFAULT_CONTEXT_ID; ctx->file_priv = file_priv; ctx->id = ret; -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/8a812e23/attachment.sig>

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

On 15/04/14 10:41, Sachin Kamat wrote: > On 15 April 2014 11:17, YoungJun Cho wrote: >> This patch adds sysreg device node, and sysreg property to fimd device node >> which is required to use I80 interface. >> >> Signed-off-by: YoungJun Cho >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin

[PATCH] drm/radeon: fix VCE fence command

Am 15.04.2014 00:13, schrieb Deucher, Alexander: >> -Original Message- >> From: Christoph Jaeger [mailto:christophjaeger at linux.com] >> Sent: Monday, April 14, 2014 6:10 PM >> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie >> Cc: dri-devel at lists.freedesktop.org;

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

It need to be checking NULL before dereferencing. Signed-off-by: Daeseok Youn --- drivers/gpu/drm/nouveau/core/subdev/clock/base.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are protected with the mode_config mutex. In the ->disable_plane callback we

[PATCH 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

Hi Tomasz, On 04/15/2014 12:00 AM, Tomasz Stanislawski wrote: > This patch add proper compatibles for Mixer and HDMI chip > available on exynos4210 SoCs. > > Signed-off-by: Tomasz Stanislawski > --- > drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++ > drivers/gpu/drm/exynos/exynos_mixer.c |

[PATCH] drm/radeon: memory leak on bo reservation failure. v2

On Tue, Apr 15, 2014 at 5:28 AM, Christian K?nig wrote: > From: Quentin Casasnovas > > On bo reservation failure, we end up leaking fpriv. > > v2 (chk): rebased and added missing free on vm failure as well > > Fixes: 5e386b574cf7e1 ("drm/radeon: fix missing bo reservation") > Cc: stable at

[Bug 74121] [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

https://bugzilla.kernel.org/show_bug.cgi?id=74121 --- Comment #1 from Rahul Sharma --- -- Forwarded message -- From: Date: 15 April 2014 14:32 Subject: [Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument

15-rc1: radeon modesetting fails

On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov wrote: > Hi Christian, > > On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote: >> Hi Borislav, >> >> that's a known issue and should be fixed in the next rc, see this >> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009 >>

[Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

https://bugzilla.kernel.org/show_bug.cgi?id=74121 Bug ID: 74121 Summary: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected" Product: Drivers Version: 2.5 Kernel Version: 3.15-rc1

15-rc1: radeon modesetting fails

Hi guys, so I'm booting 15-rc1 + tip/master and around the time modesetting gets initialized, the screen blanks and on it appears a message from the monitors: "The current input timing is not supported by the monitor display. Please change your input timing to 1920x1200 at 60Hz or any other

Possible fb ref count issue with drm_plane_force_disable()

On Tue, Apr 15, 2014 at 6:44 AM, Tomi Valkeinen wrote: > On 15/04/14 13:29, Andrzej Hajda wrote: > >> I have experienced similar problem with exynos_drm. I have found that >> in exynos_drm_crtc_mode_set there is line: >> >> plane->fb = crtc->primary->fb; >> >> without

[Bug 73901] Kernel crash after modprobe radeon runpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #13 from Pali Roh?r --- (In reply to Alex Deucher from comment #11) > Created attachment 132311 [details] > avoid a possible crash when runpm is forced on non-ATPX systems > > Fix runpm=1 handling on non-PX systems. It is not

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

those before as well but much less frequently, maybe due to lower GL usage). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments

[Bug 73901] Kernel crash after modprobe radeon runpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #12 from Pali Roh?r --- (In reply to Alex Deucher from comment #10) > Created attachment 132301 [details] > fix ATPX detection on non-VGA dGPUs > > Thanks for sorting this out. This patch is same as mine, already tested and is

[Bug 71891] 3.13 fails to boot with the radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #16 from sdh --- ping. I guess the above response got lost in the huge amount of mails you must be receiving :) -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote: > After thinking about this topic a bit more I've reached the conclusion > that implementing this doesn't make sense: > > - The locking is all wrong: set_config(NULL) will also unlink encoders > and connectors, but those links are

Possible fb ref count issue with drm_plane_force_disable()

On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen wrote: > On 14/04/14 11:43, Tomi Valkeinen wrote: >> On 11/04/14 14:50, Ville Syrj?l? wrote: >> So the explicit unref done by drm_plane_force_disable() seems a bit out of place. I can't figure out which drm_framebuffer_reference() would

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/39928a55/attachment.html>

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

- Original Message - > From: "Daeseok Youn" > To: airlied at linux.ie > Cc: bskeggs at redhat.com, dri-devel at lists.freedesktop.org, linux-kernel > at vger.kernel.org > Sent: Tuesday, 15 April, 2014 11:56:49 AM > Subject: [PATCH] drm/nouveau/clk: fix possible NULL pointer dereference >

[PATCH] drm/radeon: fix VCE fence command

Due to a type mismatch that causes an implicit type conversion, the upper 32 bits of the GPU address have been zeroed out when adding to the command buffer. Picked up by Coverity - CID 1198624. Signed-off-by: Christoph Jaeger --- drivers/gpu/drm/radeon/radeon_vce.c | 2 +- 1 file changed, 1

[PATCH v2 8/8] imx-drm: ipu-dc: Disable DC module when not in use

Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 ++ drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 14 -- drivers/staging/imx-drm/ipuv3-crtc.c| 8 ++-- 3 files changed, 20 insertions(+), 4 deletions(-) diff --git

[PATCH v2 7/8] imx-drm: ipuv3-crtc: Change display enable/disable order

Now that ipu_dc_disable_channel correctly waits for the channel to finish, we can reorder the enable/disable order to first stop the DC and DI and only then disable the IDMAC. Enabling is done the other way around: IDMAC first, then DC, then DI. This avoids an issue where sometimes the channel

[PATCH v2 6/8] imx-drm: imx-dp: When disabling the DP foreground channel, wait until the DP background channel is finished before disabling the IDMAC channel

Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c index 6980fa1..d90f82a 100644 --- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c +++

[PATCH v2 5/8] imx-drm: ipu-dp: Split disabling the DP foreground channel from disabling the DP module

The former has to be done before disabling the DMFC, the latter has to be done afterwards. Otherwise the DMFC FIFOs never get cleared properly. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 + drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68

[PATCH v2 4/8] imx-drm: ipu-dc: Wait for DC_FC_1 / DP_SF_END interrupt

Wait for the DC Frame Complete or DP Sync Flow End interrupts before disabling DC channels. Signed-off-by: Philipp Zabel --- Changes since v1: - Moved disable_irq() out of dc_irq_handler() --- drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++-- 1 file changed, 50

  1   2   >