[PATCH v2 7/7] drm: Renesas SH Mobile DRM driver

The SH Mobile LCD controller (LCDC) DRM driver supports the main graphics plane in RGB and YUV formats, as well as the overlay planes (in alpha-blending mode only). Only flat panel outputs using the parallel interface are supported. Support for SYS panels, HDMI and DSI is currently not

[Bug 16249] HDMI doesn't work on Radeon RS690M

https://bugzilla.kernel.org/show_bug.cgi?id=16249 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.

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

[PATCH 1/2] drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)

From: Jerome Glisse No need to retrain the link for passive adapters. v2: agd5f - no passive DP to VGA adapters, update comments - assign radeon_connector_atom_dig after we are sure we have a digital connector as analog connectors have different private data. - get new

[PATCH 2/2] drm/radeon: on hotplug force link training to happen (v2)

From: Jerome Glisse To have DP behave like VGA/DVI we need to retrain the link on hotplug. For this to happen we need to force link training to happen by setting connector dpms to off before asking it turning it on again. v2: agd5f - drop the dp_get_link_status() change in

[PATCH 0/7] modetest cleanup and enhancements

On Fri, Jul 20, 2012 at 7:50 AM, Laurent Pinchart wrote: > Hi everybody, > > I've enhanced the modetest utility to test various features of the SH Mobile > LCDC DRM driver. Here are the corresponding patches. They mostly touch buffer > allocation cleanup (1/7), adding test patterns for different

[patch] drm/radeon: check for allocation failure in radeon_ring_backup()

On 20.07.2012 13:17, Dan Carpenter wrote: > Static checkers complain if this we don't check for allocation failure. > Also we can use the new kmalloc_array() function here as a cleanup. > > Signed-off-by: Dan Carpenter What's the benefit of using kmalloc_array instead of just kmalloc? Anyway

[Bug 52266] No DVI output on "ATI Radeon XPRESS 200 5A41 (PCIE)" (ChipID = 0x5a41)

https://bugs.freedesktop.org/show_bug.cgi?id=52266 --- Comment #8 from Alex Deucher 2012-07-20 13:53:02 PDT --- Created attachment 64449 --> https://bugs.freedesktop.org/attachment.cgi?id=64449 possible fix How about this one? If it doesn't work, try commenting out the first *ddc_i2c line

[PATCH] drm/radeon: fix handling for ddc type 5 on combios

From: Alex Deucher When ddc type is 5, need to look up the i2c channel in the i2c table. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_combios.c | 57 +++--- 1 files changed, 36 insertions(+), 21 deletions(-) diff --git

exynos drm hdmi audio: how to recieve audio parameters (sf, bps, channel count)

On 07/20/2012 01:44 PM, RAHUL SHARMA wrote: > > On Fri, Jul 20, 2012 at 11:40 AM, RAHUL SHARMA > wrote: >> >> >> --- Original Message --- >> Sender : Lars-Peter Clausen >> Date : Jul 19, 2012 19:12 (GMT+05:30) >> Title : Re: exynos drm hdmi audio: how to recieve audio parameters (sf,

-next merged with Linus tree

ave. Attached patch fix something that have been lost. Cheers, Jerome -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-don-t-unreference-a-possibly-invalid-poin.patch Type: application/octet-stream Size: 955 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120720/82ec827f/attachment.obj>

gma500 opregion/power init order backtrace

On Tue, 17 Jul 2012 22:12:42 +0100, Alan Cox wrote : > > I'm wondering if the gma_power_init call can be moved up before > > chip_setup is called. Seems so, but I thought I would ping you to see > > if you've seen this already. > > Fixed in the patches that went to Linus. Thanks for this ! I

-next merged with Linus tree

On 20.07.2012 16:12, Jerome Glisse wrote: > On Fri, Jul 20, 2012 at 4:47 AM, Christian K?nig > wrote: >> On 20.07.2012 07:34, Dave Airlie wrote: >>> Hi, >>> >>> I've just merged Linus tree into drm-next and fixes up the conflicts, >>> some in i915, one in radeon. >>> >>> Can you guys check that

[PATCH] modeset: Split buffer allocation to a separate file

As the modeset test application is often referred to as an example of the KMS API usage, move test pattern generation and buffer allocation to a separate file to keep it simple and clear. Signed-off-by: Laurent Pinchart --- tests/modetest/Makefile.am |2 +- tests/modetest/buffers.c | 1021

[Bug 52313] New: r600g: Linux 3.3.x broken since 30257c32

https://bugs.freedesktop.org/show_bug.cgi?id=52313 Bug #: 52313 Summary: r600g: Linux 3.3.x broken since 30257c32 Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All)

-next merged with Linus tree

On Fri, Jul 20, 2012 at 10:32 AM, Christian K?nig wrote: > On 20.07.2012 16:12, Jerome Glisse wrote: >> >> On Fri, Jul 20, 2012 at 4:47 AM, Christian K?nig >> wrote: >>> >>> On 20.07.2012 07:34, Dave Airlie wrote: Hi, I've just merged Linus tree into drm-next and fixes up the

[PATCH] drm/radeon: make a few SI functions static

Dave, Can you pick this up for drm-next as well? Alex On Sat, Jun 30, 2012 at 5:37 AM, Michel D?nzer wrote: > On Fre, 2012-06-29 at 19:34 -0400, alexdeucher at gmail.com wrote: >> From: Alex Deucher >> >> Not used outside of si.c >> >> Signed-off-by: Alex Deucher > > Reviewed-by: Michel

gma500 opregion/power init order backtrace

On Fri, 20 Jul 2012 16:32:47 +0200, Anisse Astier wrote : > On Tue, 17 Jul 2012 22:12:42 +0100, Alan Cox wrote : > > > > I'm wondering if the gma_power_init call can be moved up before > > > chip_setup is called. Seems so, but I thought I would ping you to see > > > if you've seen this

[Bug 52313] r600g: Linux 3.3.x broken since 30257c32

https://bugs.freedesktop.org/show_bug.cgi?id=52313 --- Comment #1 from Jerome Glisse 2012-07-20 15:23:18 UTC --- Fixed in mesa master -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the

[PATCH] modeset: Split buffer allocation to a separate file

thanks! I've pushed to a branch on my github tree, in case you want to double check that I'm not missing anything: git://github.com/robclark/libdrm.git modetest branch will do some sanity testing a bit later, and if that looks ok and no one objects, I can push to fd.o BR, -R On Fri, Jul

[patch] drm/radeon: check for allocation failure in radeon_ring_backup()

On Fri, Jul 20, 2012 at 03:45:28PM +0200, Christian K?nig wrote: > On 20.07.2012 13:17, Dan Carpenter wrote: > >Static checkers complain if this we don't check for allocation failure. > >Also we can use the new kmalloc_array() function here as a cleanup. > > > >Signed-off-by: Dan Carpenter >

[PATCH 2/2] dma-buf: add helpers for attacher dma-parms

Fyi, Daniel Vetter had suggested on IRC that it would be cleaner to have a single helper fxn that most-restrictive union of all attached device's dma_parms. Really this should include dma_mask and coherent_dma_mask, I think. But that touches a lot of other places in the code. If no one objects

[Bug 52266] No DVI output on "ATI Radeon XPRESS 200 5A41 (PCIE)" (ChipID = 0x5a41)

https://bugs.freedesktop.org/show_bug.cgi?id=52266 --- Comment #9 from Przemek Tomczyk 2012-07-20 17:14:13 UTC --- neither of those worked. kern.log output is now the same as in first attachement: [drm:radeon_add_legacy_connector] *ERROR* DVI: Failed to assign ddc bus! Check dmesg for i2c

[PATCH] modeset: Split buffer allocation to a separate file

Hi Rob, On Friday 20 July 2012 10:34:46 Rob Clark wrote: > thanks! I've pushed to a branch on my github tree, in case you want > to double check that I'm not missing anything: > > git://github.com/robclark/libdrm.git modetest branch > > will do some sanity testing a bit later, and if that

[PATCH] drm, ast_fb: Fix a small leak in astfb_create()

We have this code: ... sysram = vmalloc(size); if (!sysram) return -ENOMEM; info = framebuffer_alloc(0, device); if (!info) { ret = -ENOMEM; goto out; } ... We'll leak the memory allocated to 'sysram' if the

[PATCH] drm, cirrus_fbdev: Fix leak in cirrusfb_create()

We have this code: ... sysram = vmalloc(size); if (!sysram) return -ENOMEM; info = framebuffer_alloc(0, device); if (info == NULL) return -ENOMEM; ... If the vmalloc() call succeeds but the framebuffer_alloc() call subsequently

[PATCH] drm/radeon/dce4+: set a more reasonable cursor watermark

From: Alex Deucher Set a more reasonable default cursor watermark. The recommended default value is 4. This should reduce urgency requests to the MC form the display hw. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_cursor.c |6 -- 1 files

your distracted maintainer and -next

On Fri, 20 Jul 2012, Dave Airlie wrote: > I've merged most things I've found on the list, please take a look and > see what I missed, I have two that I sent a while ago that I think got missed. First is a totally trivial and obvious:

<    1   2