[PATCH 02/18] drm/irq: simplify irq checks in drm_wait_vblank

s.freedesktop.org/archives/dri-devel/attachments/20140414/936a27e1/attachment.sig>

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

Hi Tomasz, Always thanks for your opinions. > -Original Message- > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc- > owner at vger.kernel.org] On Behalf Of Tomasz Figa > Sent: Monday, April 14, 2014 8:32 PM > To: Inki Dae; 'Andrzej Hajda' > Cc: 'Kyungmin

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

On Mon, Apr 14, 2014 at 05:21:32PM +0200, Philipp Zabel wrote: > Wait for the DC Frame Complete or DP Sync Flow End interrupts > before disabling DC channels. > > Signed-off-by: Philipp Zabel > --- > drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 > +++-- > 1 file

[PATCH 0/7] Reorder i.MX IPU display enable/disable sequence

On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote: > Repeatedly enabling and disabling the display currently can lead to a state > in which the IPU doesn't produce a valid signal anymore because we disable > IPU submodules before they can finish their interaction. I'm afraid to say

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #9 from Pali Roh?r --- I looked into radeon_atpx_handler.c code and I found reason why radeon kernel driver does not detect ATPX... First here is lspci output: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core

[PATCH] drm/radeon: fix VCE fence command

> -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; linux-kernel at vger.kernel.org; > Christoph > Jaeger >

DRM security flaws and security levels.

ses, but I don't see how we should securely handle the authorisation for an application to disable the PPGTT without some serious work... As you can see, there is some work to be done before exposing the security/performance trade-off knob. I am not convinced it is necessary but I would d

[PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

On Mon, Apr 14, 2014 at 12:24:45PM +0200, Lucas Stach wrote: > Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux: > > Now *you* please go back and read what you said about kms/userspace being > > able to poll the connector, thereby causing an EDID read attempt while > > HPD

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #8 from Pali Roh?r --- Created attachment 132291 --> https://bugzilla.kernel.org/attachment.cgi?id=132291=edit dmesg plymouth log Similar/same problem happends if I start plymouth splash screen (which using intel fb) and then I

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #7 from Pali Roh?r --- Created attachment 132281 --> https://bugzilla.kernel.org/attachment.cgi?id=132281=edit pstore log Ok, now kernel does not crash after loading radeon module again. I modprobed & rmmoded it more times, there

[PATCH] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

Hi Tomasz, On 04/14/2014 07:07 PM, Tomasz Stanislawski wrote: > 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

[PATCH 0/7] Reorder i.MX IPU display enable/disable sequence

On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote: > Repeatedly enabling and disabling the display currently can lead to a state > in which the IPU doesn't produce a valid signal anymore because we disable > IPU submodules before they can finish their interaction. Well done at finding

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 Alex Deucher changed: What|Removed |Added Attachment #132231|0 |1 is obsolete|

[Bug 42960] Display does not work when resuming from suspend

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/20140414/cbf7ce3f/attachment.html>

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

> -Original Message- > From: Andrzej Hajda [mailto:a.hajda at samsung.com] > Sent: Monday, April 14, 2014 5:55 PM > To: Inki Dae > Cc: dri-devel at lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; > Kyungmin Park; Marek Szyprowski > Subject: Re: [PATCH RFC 0/2] drm/exynos:

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #5 from Pali Roh?r --- Created attachment 132251 --> https://bugzilla.kernel.org/attachment.cgi?id=132251=edit pstore log Now I found pstore and its efi backend... I modprobed efi-pstore before rmmoding radeon and dmesg logs were

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

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: On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #4 from Pali Roh?r --- No does not help, kernel still crashing. But now I cannot provide syslog output, because userspace rsyslog daemon does not read log from kernel and write data to disk.. Plus output on framebuffer screen is very

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

On 04/14/2014 05:00 PM, Tomasz Stanislawski wrote: > 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(+),

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #8 from Pali Roh?r --- (In reply to Alex Deucher from comment #7) > (In reply to Pali Roh?r from comment #6) > > Btw, I looked into DSDT/SSDT acpi tables and there is ATPX method (in SSDT7, > > scope \_SB.PCI0.GFX0). > > Did you

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #7 from Alex Deucher --- (In reply to Pali Roh?r from comment #5) > So I cannot turn off dGPU when it is not used? > Correct. The driver requires that method to power on/off the dGPU. > Also I think that kernel should not crash

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #6 from Pali Roh?r --- Btw, I looked into DSDT/SSDT acpi tables and there is ATPX method (in SSDT7, scope \_SB.PCI0.GFX0). -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 7/7] 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 6/7] 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 5/7] 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 4/7] 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 --- drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++-- 1 file changed, 50 insertions(+), 21 deletions(-) diff --git

[PATCH 3/7] imx-drm: ipu-dmfc: Wait for FIFOs to run empty before disabling

Disabling the DMFC module while there is still data in the FIFOs could cause the "new frame before end of frame" error state when the DMFC is enabled again. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++-- 1 file changed, 23

[PATCH 2/7] imx-drm: ipu-common: Add helpers to check for a busy IDMAC channel and to busywait for an interrupt

Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/ipu-common.c | 22 ++ drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 3 +++ 2 files changed, 25 insertions(+) diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c

[PATCH 1/7] imx-drm: ipu-common: add ipu_map_irq to request non-IDMAC interrupts

This allows to request the DC related interrupts. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 + drivers/staging/imx-drm/ipu-v3/ipu-common.c | 19 +-- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git

[PATCH 0/7] Reorder i.MX IPU display enable/disable sequence

Repeatedly enabling and disabling the display currently can lead to a state in which the IPU doesn't produce a valid signal anymore because we disable IPU submodules before they can finish their interaction. This series reorders the enable/disable sequence so that we first wait for the DC/DP to

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #5 from Pali Roh?r --- So I cannot turn off dGPU when it is not used? Also I think that kernel should not crash when booting with (maybe incorrect?) param runpm. -- You are receiving this mail because: You are watching the assignee

[PATCH 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

[PATCH 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 |3 +++ drivers/gpu/drm/exynos/exynos_mixer.c |3 +++ 2 files changed, 6 insertions(+) diff --git

[PATCH 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 ---

[PATCH 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

[PATCH 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 Tomasz Stanislawski (4): drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: mixer: fix using usleep() in atomic context drm:

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #4 from Alex Deucher --- Your system does not appear to have the ATPX acpi methods that are required for runtime pm to work properly (required to power off the dGPU). You should see something like: ATPX version X, functions

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #3 from Alex Deucher --- Created attachment 132231 --> https://bugzilla.kernel.org/attachment.cgi?id=132231=edit possible fix Does this help in the second case? -- You are receiving this mail because: You are watching the

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

On Monday 14 April 2014 04:00 PM, Tomi Valkeinen wrote: > On 14/04/14 13:18, Archit Taneja wrote: >> On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote: >>> On 11/04/14 10:23, Archit Taneja wrote: The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #2 from Pali Roh?r --- Created attachment 132221 --> https://bugzilla.kernel.org/attachment.cgi?id=132221=edit syslog output after modprobe radeon Yes, your patch fixing original problem. Maybe this is candidate for stable

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

On 14.04.2014 15:55, Inki Dae wrote: > Hi Tomasz, > > Always thanks for your opinions. > >> -Original Message- >> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc- >> owner at vger.kernel.org] On Behalf Of Tomasz Figa >> Sent: Monday, April 14, 2014 8:32 PM >> To:

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote: > On 11/04/14 10:23, Archit Taneja wrote: >> The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are >> greater than what is specified in the driver through dev->mode_config. >> >> Create helpers for DISPC which return

[PATCH] drm: fix memory leak in msm_gem when no iommu is present

fyi, I have this patch applied locally (well, actually the previous one with slightly amended subject line).. was just waiting a bit to see if any other fixes turned up before sending a fixes pull. Thanks! BR, -R On Mon, Apr 14, 2014 at 2:40 PM, Micah Richert wrote: > Signed-off-by: Micah

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

t -- 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/20140414/e1ff7448/attachment.sig>

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 Pali Roh?r changed: What|Removed |Added Attachment #132211|application/octet-stream|text/plain mime type|

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #3 from Pali Roh?r --- Created attachment 132211 --> https://bugzilla.kernel.org/attachment.cgi?id=132211=edit dmesg output I'm using version 3.14 (as specified in bugzilla). Dmesg output from kernel without any radeon params is

[PATCH 9/9] drm/exynos: modify goto labels to meaningful names

Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 +++ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index cdd74e2..1d1c604 100644 ---

[PATCH 8/9] drm/exynos: fix comment to exynos_drm_device_subdrv_prove call

subdrv_probe callback of virtual display driver will be called by exynos_drm_device_subdrv_probe() to create crtc and encoder/connector for virtual display driver. So it fixes comments to exynos_drm_device_subdrv probe call. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[PATCH v2 7/9] drm/exynos: separate dpi from fimd

From: Andrzej Hajda The patch separates dpi related routines from fimd. Changelog v2: - Rename ctx->dpi to ctx->display Signed-off-by: Andrzej Hajda Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 40 +--

[PATCH 6/9] exynos/drm: add DT bindings

This patch adds bindings for Exynos drm display subsystem. The bindings describes ports containing a list of phandles pointing to display controller, image enhancer, and display interfaces nodes. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[PATCH 5/9] ARM: dts: exynos4412-trats2: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4412-trats2.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index 53c717b..115b9ed 100644 ---

[PATCH 4/9] ARM: dts: exynos4210-trats: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4210-trats.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts index 02c6768..a41c109 100644 ---

[PATCH 3/9] ARM: dts: exynos4210-universal: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4210-universal_c210.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts index 0a80a72..5351ac4 100644

[PATCH 2/9] drm/exynos: dpi: fix hotplug fail issue

When connector is created, if connector->polled is DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event function isn't called at drm_helper_hpd_irq_event because the function will be called only in case of DRM_CONNECTOR_POLL_HPD. So this patch sets always DRM_CONNECTOR_POLL_HPD flag to

[PATCH v5 1/9] drm/exynos: add super device support

This patch adds super device support to bind sub drivers using device tree. For this, you should add a super device node to each machine dt files like belows, In case of using MIPI-DSI, display-subsystem { compatible = "samsung,exynos-display-subsystem";

[PATCH v3 0/9] drm/exynos: more cleanup with super device support

This patch series cleans up exynos drm framework and kms sub drivers using the component framework[1] [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html Previous patches, RFC: http://comments.gmane.org/gmane.comp.video.dri.devel/101200 v1:

DRM security flaws and security levels.

On 04/14/2014 02:41 PM, One Thousand Gnomes wrote: >> throw out all GPU memory on master drop and block ioctls requiring >> authentication until master becomes active again. > If you have a per driver method then the driver can implement whatever is > optimal (possibly including throwing it all

[PATCH V2] gpu: host1x: handle the correct # of syncpt regs

On 04/04/2014 04:31 PM, Stephen Warren wrote: > From: Stephen Warren > > BIT_WORD() truncates rather than rounds, so the loops in > syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <= > rather than < in an attempt to process the correct number of registers > when rounding of

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

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/20140414/9779f7f7/attachment.html>

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

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

https://bugzilla.kernel.org/show_bug.cgi?id=73901 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2

DRM security flaws and security levels.

> throw out all GPU memory on master drop and block ioctls requiring > authentication until master becomes active again. If you have a per driver method then the driver can implement whatever is optimal (possibly including throwing it all out). > -1: The driver allows an authenticated client to

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

Hi Inki, On 14.04.2014 13:04, Inki Dae wrote: > > >> -Original Message- >> From: Andrzej Hajda [mailto:a.hajda at samsung.com] >> Sent: Monday, April 14, 2014 5:55 PM >> To: Inki Dae >> Cc: dri-devel at lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; >> Kyungmin Park; Marek

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

egions of the same buffer. In that case shouldn't the limit be 0 (if that's allowed) or some surely high enough value, say, 32767. Why calculate it at all based on the dispc's maximum, if it has no relevance? 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/20140414/b701c17d/attachment.sig>

[3.14 regression] kernel oops with dpm enabled on TURKS

Greetings, I'm facing a dpm regression in 3.14 on my radeon TURKS (pci id 1002:6840). Upon loading the radeon module with dpm enabled, the screen goes black and the computer locks up. The problem first appeared at 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 drm/radeon/pm: move pm handling into

[PATCH 4/4] drm/omap: remove warn from debugfs

Patch dfe96ddcfa22b44100814b9435770f6ff1309d37 (omapdrm: simplify locking in the fb debugfs file) removed taking locks when using omapdrm's debugfs to dump fb objects. However, in omap_gem_describe we give a WARN is the lock has not been taken, so that WARN is now seen every time omapdrm debugfs

[PATCH 3/4] drm/omap: remove extra plane->destroy from crtc destroy

All the planes, including primary planes, are now destroyed by the drm framework. Thus we no longer need the explicit call to plane->destroy from the crtc's destroy function. This patch removes the call, thus fixing the crash caused by double freeing the plane. remove

[PATCH 2/4] drm/omap: print warning when rotating non-TILER fb

Print a warning when the user tries to rotate a non-TILER framebuffer. Also set the rotation to 0, to avoid constant flood of the warnings in case of page flipping. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH 1/4] drm/omap: fix missing unref to fb's buf object

omap_fbdev_create() takes a reference to the fb's gem object with omap_gem_get_paddr(). However, it never releases it with omap_gem_put_paddr(). This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free(). Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +++

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

t;part" defined, then?), then there should be no limits as the only limit is the size of the memory. 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/20140414/c154062f/attachment-0001.sig>

[PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux: > On Mon, Apr 14, 2014 at 11:38:43AM +0200, Lucas Stach wrote: > > Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux: > > > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote: > > > > Am

[PATCH] 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

Possible fb ref count issue with drm_plane_force_disable()

register() drops the "idr reference" taken in > drm_framebuffer_init(). What's "idr"? Tomi -- next part -- A non-text attachment was scrubbed... Name: m.log Type: text/x-log Size: 23295 bytes Desc: not available URL: <http://lists.freedesktop

[PATCH] drm: fix memory leak in msm_gem when no iommu is present

Signed-off-by: Micah Richert --- drivers/gpu/drm/msm/msm_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index e8458bc..c818a06 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++

[PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux: > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote: > > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM > > Linux: > > > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote: > > > > Make

[PATCH 3/3] drm: bochs: drop unused struct fields

Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/bochs/bochs.h | 2 -- drivers/gpu/drm/bochs/bochs_fbdev.c | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index 4608205..7eb52dd 100644 --- a/drivers/gpu/drm/bochs/bochs.h

[PATCH 2/3] drm: bochs: add power management support

bochs kms driver lacks power management support, thus the vga display doesn't work any more after S3 resume. Fix this by adding suspend and resume functions. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/bochs/bochs.h | 1 + drivers/gpu/drm/bochs/bochs_drv.c | 44

[PATCH 1/3] drm: cirrus: add power management support

cirrus kms driver lacks power management support, thus the vga display doesn't work any more after S3 resume. Fix this by adding suspend and resume functions. Also make the mode_set function unblank the screen. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/cirrus/cirrus_drv.c | 42

[PATCH RESEND 0/3] three qemu patches (bochs/cirrus drivers)

Hi, Resending three patches for qemu emulated hardware. One little cleanup, and two adding power management callbacks to bochs and cirrus drivers, so you have working video after resuming your virtual machine from S3. I've already sent them months ago, nobody raised any concerns and I've

[PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

On Mon, Apr 14, 2014 at 11:38:43AM +0200, Lucas Stach wrote: > Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux: > > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote: > > > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM > > > Linux: > > > > On

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

On 04/12/2014 04:18 PM, Inki Dae wrote: > Hi Andrzej, > > Thanks for your contributions. > > 2014-04-11 23:11 GMT+09:00 Andrzej Hajda : >> Hi Inki, >> >> This patchset refactors drm device initialization. Details are described >> in respective patches. It is an alternative to DT supernode concept.

[ 3.14.0-12041-g75ff24f ] regression: drm warning

2014-04-09 12:08 GMT+02:00 J?rg Otte : > Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following > on the console (driver is i915): > > [drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun > [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun >

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

https://bugzilla.kernel.org/show_bug.cgi?id=50091 --- Comment #34 from Dzianis Kahanovich --- OOPS! Crushed now. No fix ;( -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote: > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM > Linux: > > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote: > > > Make sure that we probe for a display on detect regardless > > > of previous hotplug

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

op 11-04-14 21:35, Thomas Hellstrom schreef: > On 04/11/2014 08:09 PM, Maarten Lankhorst wrote: >> op 11-04-14 12:11, Thomas Hellstrom schreef: >>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote: op 11-04-14 10:38, Thomas Hellstrom schreef: > Hi, Maarten. > > Here I believe we

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

bed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140414/a3428db8/attachment.sig>

DRM security flaws and security levels.

On Mon, Apr 14, 2014 at 8:56 AM, Thomas Hellstrom wrote: > On 04/14/2014 02:41 PM, One Thousand Gnomes wrote: >>> throw out all GPU memory on master drop and block ioctls requiring >>> authentication until master becomes active again. >> If you have a per driver method then the driver can

[Bug 66963] Rv6xx dpm problems

e testing. And number of hangs just correlates with frequency of video playing. -- 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

[Bug 66963] Rv6xx dpm problems

dri-devel/attachments/20140414/6aa89895/attachment.html>

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

On Fri, Apr 11, 2014 at 3:23 AM, Archit Taneja wrote: > The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are > greater than what is specified in the driver through dev->mode_config. > > Create helpers for DISPC which return the max manager width and height > supported >

[PATCH 2/6] shm: add sealing API

Hi On Sat, Apr 12, 2014 at 12:07 AM, Andy Lutomirski wrote: > I bet this is missing from lots of places. For example, I can't find > any write_access stuff in the rdma code. > > I suspect that the VM_DENYWRITE code is just generally racy. So what does S_IMMUTABLE do to prevent such races? I

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

ves/dri-devel/attachments/20140414/e9df2ec0/attachment.html>

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

https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #33 from Chris Rankin --- Created attachment 97325 --> https://bugs.freedesktop.org/attachment.cgi?id=97325=edit Xorg.0.log showing errors when exiting WoW One of the other errors that I've come to associate (rightly or wrongly)