[PATCH] drm/tegra: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO

quot; would probably be more accurate. There is no error here. Thierry -- 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/20140416/3701191c/attachment.sig>

[PATCH 7/7] drm/bridge: ptn3460: add drm_panel controls

attach ptn3460 connector to drm_panel and support drm_panel routines, if a valid drm_panel object is passed to ptn3460_init. Signed-off-by: Ajay Kumar --- drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ptn3460.c| 17 -

[PATCH 6/7] drm/bridge: ptn3460: enable polling based detection

From: Rahul Sharma Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while registering drm_connector for ptn3460. Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar --- drivers/gpu/drm/bridge/ptn3460.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 5/7] drm/exynos: dp: modify driver to support drm_panel

This patch attaches the dp connector to exynos_dp_panel, and adds calls to drm_panel functions to control panel power sequence. Signed-off-by: Ajay Kumar --- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_dp_core.c | 19 +++

[PATCH 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver

Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ---

[PATCH 3/7] drm/panel: Add driver for exynos_dp based panels

This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. Most of the eDP/LVDS panels need this sequence for powerup: -- LCD unit powerup/LCD_EN -- video data on -- LED unit

[PATCH 2/7] drm/panel: add pre_enable routine to drm panel

Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only one callback, i.e "panel_enable" is supported. This

[PATCH 1/7] drm/exynos: dp: support hotplug detection via GPIO

From: Andrew Bresticker Certain bridge chips use a GPIO to indicate the cable status instead of the I_DP_HPD pin. This adds an optional device-tree property, "samsung,hpd-gpio", to the exynos-dp controller which indicates that the specified GPIO should be used for hotplug

[PATCH 0/7] drm: exynos: few patches to enhance bridge chip support

This series is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git This set of drm patches are needed to support bridge chips and eDP/LVDS panels with exynos_dp. For testing, I have used exynos5250-snow board along with

[PATCH] drm/ast: fix value check in cbr_scan2

this is a typo vs the ums driver, fix to check correct value. Found initially by Coverity. Reported-by: Daniel Vetter Signed-off-by: Dave Airlie --- drivers/gpu/drm/ast/ast_post.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_post.c

15-rc1: radeon modesetting fails

On Wed, Apr 16, 2014 at 12:07:20PM +0200, Christian K?nig wrote: > Hi Borislav, > > thanks for the logs, those were indeed quite helpful. > > Attached are two patches, the first one tries to solve the problem by > increasing the accuracy of the parameters if we don't match exactly and the >

[PATCH 01/18] drm/omap: fix up pdev_remove

On Wed, Apr 16, 2014 at 10:27 AM, Tomi Valkeinen wrote: > On 16/04/14 11:15, Daniel Vetter wrote: > >> I don't mind how this is getting fixed, I just don't like when regression >> caused by my patches are left lingering too long ;-) >> >> Have you merged your patch for 3.14-rc already so that I

[PATCHv3 5/5] 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

[PATCHv3 4/5] 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

[PATCHv3 3/5] 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 ---

[PATCHv3 2/5] 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 |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c

[PATCHv3 1/5] drm: exynos: hdmi: remove usage of struct s5p_hdmi_platform_data

This patch continues shift of DRM EXYNOS to DT-only configuration. The usage of the old structure for HDMI's platform data is removed. Signed-off-by: Tomasz Stanislawski --- drivers/gpu/drm/exynos/exynos_hdmi.c | 30 -- 1 file changed, 8 insertions(+), 22

[PATCHv3 0/5] drm: exynos: update/fixes to HDMI driver

Hi everyone, This patchset adds 5 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Changelog: v3: * remove usage of s5p_hdmi_platform_data * return MODE_CLOCK_HIGH instead of MODE_CLOCK_BAD v2: * fix check with gpio_is_valid() * use

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

Some drivers need to be able to have a perfect race-free fbcon setup. Current drivers only enable hotplug processing after the call to drm_fb_helper_initial_config which leaves a tiny but important race. This race is especially noticable on embedded platforms where the driver itself enables the

[Bug 77533] commit: acf55e73252e46fa51378ef4b23c94a89902ae1c breaks radeonsi on linux

|| -- 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/20140416/07163351/attachment.html>

[Bug 77533] New: commit: acf55e73252e46fa51378ef4b23c94a89902ae1c breaks radeonsi on linux

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

[PATCH 1/2] drm/radeon/si: make sure mc ucode is loaded before checking the size

Added both patches to my 3.15 queue. Thanks, Christian. Am 16.04.2014 15:42, schrieb Alex Deucher: > Avoid a possible segfault. > > Noticed-by: Dan Carpenter > Signed-off-by: Alex Deucher > Cc: stable at vger.kernel.org > --- > drivers/gpu/drm/radeon/si.c | 4 +++- > 1 file changed, 3

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)

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/20140416/41e27c90/attachment-0001.html>

[PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

On Wed, Mar 26, 2014 at 1:27 PM, Ben Skeggs wrote: > On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding > wrote: >> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote: >>> GK20A does not embed a dedicated COPY engine and thus cannot allocate >>> the copy channel that

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

This patch adds common part of dsi node. Changelog v2: - Uses clock macros instead of numbers (commented by Sachin Kamat) Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi | 15 +++ 1 file changed, 15

[RFC PATCH v2 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. Changelog v2: - Adds unit address (commented by Sachin Kamat) Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[RFC PATCH v2 07/14] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings

This patch adds relevant to exynos5420 compatible for exynos5420 SoC support. Changelog v2: - Changes title, description and fixes typo (commented by Sachin Kamat) Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

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

This patch adds relevant to exynos5 compatible for exynos5 SoCs. Changelog v2: - Changes title and description (commented by Sachin Kamat) Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file

[Bug 77512] the start of upstream kernel is blocked at DRM/Radeon initialization

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/7becd308/attachment.html>

[PATCH 6/6] drm/omap: protect omap_crtc's event with event_lock spinlock

Hi, On Monday 14 April 2014 06:06 PM, Tomi Valkeinen wrote: > On 11/04/14 10:23, Archit Taneja wrote: >> The vblank_cb callback and the page_flip ioctl can occur together in >> different >> CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when >> sending the vblank event

15-rc1: radeon modesetting fails

. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-improve-PLL-params-if-we-don-t-match-exac.patch Type: text/x-diff Size: 2003 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/65c72326/attac

[GIT PULL] omapdrm fixes for 3.15

ame: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/6dc12e7d/attachment-0001.sig>

15-rc1: radeon modesetting fails

Borislav Petkov wrote: > On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote: >> Turning off modesetting basically disables the driver. > > Well, in my case, I was using the radeon.modeset=0 variant to rule out > issues in x.org. And in my case x.org did start still, albeit with a >

[PATCH 01/18] drm/omap: fix up pdev_remove

archives/dri-devel/attachments/20140416/9c995462/attachment-0001.sig>

15-rc1: radeon modesetting fails

Am 16.04.2014 10:32, schrieb Kertesz Laszlo: > Borislav Petkov wrote: >> On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote: >>> Turning off modesetting basically disables the driver. >> >> Well, in my case, I was using the radeon.modeset=0 variant to rule out >> issues in x.org.

[PATCH 01/18] drm/omap: fix up pdev_remove

On Mon, Apr 14, 2014 at 09:26:14AM +0300, Tomi Valkeinen wrote: > Hi, > > On 12/04/14 00:35, Daniel Vetter wrote: > > Dave accidentally merged the wrong version of the patch in > > > > commit fd3c02531461924853db65f2664db361b53a70d3 > > Author: Daniel Vetter > > Date: Wed Dec 11 11:34:26 2013

[PATCH 2/2] drm/radeon/ci: make sure mc ucode is loaded before checking the size

Avoid a possible segfault. Noticed-by: Dan Carpenter Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/cik.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index

[PATCH 1/2] drm/radeon/si: make sure mc ucode is loaded before checking the size

Avoid a possible segfault. Noticed-by: Dan Carpenter Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/si.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 86f8c9c..ac708e0

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

;) -- 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/20140416/8acc769b/attachment.html>

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)

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/20140416/679db5e8/attachment.html>

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

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140416/4498ca62/attachment.html>

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

On 15 April 2014 19:59, Tomasz Stanislawski wrote: > 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: >

[Bug 77512] New: the start of upstream kernel is blocked at DRM/Radeon initialization

--- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/01132ffc/attachment.html>

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

-- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/70cef762/attachment-0001.html>

[Bug 75128] Artifacts

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/407d666b/attachment.html>

[Bug 75128] Artifacts

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/9101f59b/attachment.html>

[Bug 75128] Artifacts

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/0ff457b4/attachment.html>

[Bug 75128] Artifacts

ere problem. -- 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/20140416/6d5a3e24/attachment.html>

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/60c483ba/attachment.html>

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/d58980ab/attachment.html>

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/86a062c4/attachment-0001.html>

15-rc1: radeon modesetting fails

Borislav Petkov wrote: > 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

15-rc1: radeon modesetting fails

On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote: > Turning off modesetting basically disables the driver. Well, in my case, I was using the radeon.modeset=0 variant to rule out issues in x.org. And in my case x.org did start still, albeit with a jacked-up resolution. But in

Possible fb ref count issue with drm_plane_force_disable()

On Tue, Apr 15, 2014 at 3:30 PM, Tomi Valkeinen wrote: > > It looks to me like drm_mode_setplane() doesn't really presume that the > update_plane would set plane->fb or plane->crtc, as it does that itself > (and only if update_plane has succeeded). Yeah that's a bit of historical hilarity.

Possible fb ref count issue with drm_plane_force_disable()

On Tue, Apr 15, 2014 at 12:10 PM, Rob Clark wrote: > so, what triggers this is that previously drm_framebuffer_remove() did > not process private planes. But now the fb shows up attached to a > plane as well, the crtc's primary plane. That shouldn're really matter - if we have the fb assigned

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

https://bugs.freedesktop.org/show_bug.cgi?id=75649 Alex Deucher changed: What|Removed |Added Product|Mesa|DRI Version|10.0

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

https://bugs.freedesktop.org/show_bug.cgi?id=75649 --- Comment #1 from tderensis at gmail.com --- Problem persists even when using 3.14 kernel and mesa 10.1 in Arch. What other information would be useful to assist in debugging this issue? -- You are receiving this mail because: You are the