[PATCH] drm/mm: Don't WARN if drm_mm_reserve_node

On Mon, 7 Apr 2014 23:25:20 +0200 Daniel Vetter wrote: > Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC > return value to detect overlapping framebuffers (which the bios uses > always when lighting up more than one screen). All this fanciness > happens in

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

On Mon, Apr 7, 2014 at 7:23 PM, Rob Clark wrote: > On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding > wrote: >> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote: >>> On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote: >>> > Add cursor plane as a parameter to drm_crtc_init()

[Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher wrote: > On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote: >> To support bare address requests used by the drm dp helpers. >> >> Signed-off-by: Jani Nikula >> >> --- >> >> Hi Alex, similar to Thierry's patch for i915. >> > > Looks good to me. > >

[PATCH 01/13] drm/mgag200: Remove unnecessary NULL check in bo_unref

On Mon, Apr 7, 2014 at 5:19 PM, Ian Romanick wrote: > On 04/05/2014 02:44 AM, Daniel Vetter wrote: >> ttm_bo_unref unconditionally calls kref_put on it's argument, so the >> thing can't be NULL without already causing Oopses. > > Doesn't this mean the NULL check is in the wrong place (rather than

[PATCH 08/13] drm/ast: Remove dead code from cbr_scan2

On Mon, Apr 7, 2014 at 5:28 PM, Ian Romanick wrote: > On 04/05/2014 02:44 AM, Daniel Vetter wrote: >> The outer if already checks for data != 0, so it can't really be >> 0. Hence remove it. >> >> Now I don't have specs or anything for this beast, so I have no >> idea whether this was actually

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

EAD 4ccff1499c956b51f18710c7308cbce883f64cd9. -- 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/20140407/d5d56cf5/attachment.html>

[PATCH] imx-drm: imx-drm-core: Fix imx_drm_encoder_get_mux_id

On Mon, Apr 07, 2014 at 10:22:36AM +0200, Philipp Zabel wrote: > The decoder mux id is equal to the port id of the encoder's input port > that is connected to the given crtc, not to the endpoint id (which is > arbitrary and usually zero). > > Signed-off-by: Philipp Zabel It fixes a color

[PATCH v5 00/11] imx-drm dt bindings

On Mon, Apr 07, 2014 at 12:05:35PM +0200, Philipp Zabel wrote: > > Did you get any chance to reproduce this dual display issue? Now it > > shows on mainline kernel. > > I have not yet reproduced, but I've sent a patch today ("imx-drm: > imx-drm-core: Fix imx_drm_encoder_get_mux_id") that might

[PATCH v5 00/11] imx-drm dt bindings

On Mon, Apr 07, 2014 at 10:09:27AM +0100, Russell King - ARM Linux wrote: > So no EDID. Did you update the "ddc" property to "ddc-i2c-bus" ? Ah, right. This is exactly the cause. Thanks, Russell. Shawn

[Bug 66963] Rv6xx dpm problems

there is unsaved work on the screen. -- 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/20140407/68ec22d5/attachment.html>

[Bug 66963] Rv6xx dpm problems

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/2a430f4b/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

u 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/20140407/e996c122/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

he bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/8bd2a89f/attachment-0001.html>

[Bug 77002] hdmi audio problems with 3.14

ubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/b912535e/attachment-0001.html>

[Bug 77002] hdmi audio problems with 3.14

the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/459f1d1b/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

[Bug 77002] hdmi audio problems with 3.14

ving 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/20140407/9d1b7980/attachment.html>

[Bug 71461] monitor doesn't get detected after boot or disconnection

https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #18 from Alex Deucher --- (In reply to Tom Yan from comment #16) > I tried to remove the DisplayPort-specific code in > radeon_connector_hotplug() of radeon_connector.c and everything seems to > work like a charm. What is the code

[Bug 77002] hdmi audio problems with 3.14

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140407/6377f175/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

s 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/20140407/2bc40304/attachment.html>

[PATCH 07/13] drm/via: Remove unecessary NULL check

On Mon, Apr 7, 2014 at 5:51 PM, David Herrmann wrote: > On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter > wrote: >> The context_dtor callback is only called once we've successfully loaded >> the driver, which means dev->dev_private is set up. The check is hence >> pointless. >> >> Also

[Bug 71461] monitor doesn't get detected after boot or disconnection

https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #17 from Tom Yan --- One thing to add, unplugging it physically in X still makes it blank. It happens no matter the code is removed or not. Also, HDMI doesn't work all time yet, seems that if the TV is powered off and it goes into

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

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #16 from Tom Yan --- I tried to remove the DisplayPort-specific code in radeon_connector_hotplug() of radeon_connector.c and everything seems to work like a charm. What is the code supposed to do actually? Though, btw, it seems that

[PATCH] drm/omap: fix plane rotation

On Mon, Apr 7, 2014 at 5:41 PM, Grazvydas Ignotas wrote: > Gra?vydas > > > On Mon, Apr 7, 2014 at 8:17 PM, Rob Clark wrote: >> On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas >> wrote: >>> On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote: On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas

[Bug 70706] Regression in fbconfig

s.freedesktop.org/archives/dri-devel/attachments/20140407/ccb8f37f/attachment.html>

[PATCH 00/13] coverity

Hi On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter wrote: > Hi all, > > Rainy w/e here and I got a bit bored, so looked at coverity again. I've closed > all outstanding issues in drivers/gpu now either as false positives or fixed > in > this series expect for vmwgfx/ttm stuff (not enough clue)

[PATCH 07/13] drm/via: Remove unecessary NULL check

Hi On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter wrote: > The context_dtor callback is only called once we've successfully loaded > the driver, which means dev->dev_private is set up. The check is hence > pointless. > > Also dev->dev_private is deref already above, so compilers are free > to

[PATCH v2 1/7] drm/exynos: add super device support

On 07.04.2014 17:16, Inki Dae wrote: > Hi Andrzej, > > 2014-04-07 23:18 GMT+09:00 Andrzej Hajda : >> Hi Inki and Tomasz, >> >> On 04/06/2014 05:15 AM, Inki Dae wrote: >> >> (...) >>> The code creating the list of components to wait for >>> (exynos_drm_add_components()) doesn't seem to consider

[RFC 0/3] TTM priority queue logic

On Mon, 07 Apr 2014 14:25:28 +0200 Thomas Hellstrom wrote: > Hi, Lauri. > > On 04/04/2014 03:52 PM, Lauri Kasanen wrote: > > Hi list, Thomas, > > > > I'd like to know if this is going in the right direction. > > This looks fine with me. > > However, if possible I'd like the drivers to enable

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

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/39973576/attachment-0001.html>

[PATCH 2/3] drm/edid: Check for user aspect ratio input

In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. Signed-off-by: Vandana Kannan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file

[PATCH 1/3] drm/crtc: Add property for aspect ratio

Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. Signed-off-by: Vandana Kannan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_crtc.c | 31 +++

[RFC 0/3] TTM priority queue logic

On 04/07/2014 04:39 PM, Lauri Kasanen wrote: > On Mon, 07 Apr 2014 14:25:28 +0200 > Thomas Hellstrom wrote: > >> Hi, Lauri. >> >> On 04/04/2014 03:52 PM, Lauri Kasanen wrote: >>> Hi list, Thomas, >>> >>> I'd like to know if this is going in the right direction. >> This looks fine with me. >> >>

[PATCH v2 1/7] drm/exynos: add super device support

Hi Andrzej, On 07.04.2014 16:18, Andrzej Hajda wrote: > Hi Inki and Tomasz, > > On 04/06/2014 05:15 AM, Inki Dae wrote: > > (...) >> The code creating the list of components to wait for >> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are >> actually enabled in kernel

[Bug 77142] Garbled text in Gtk2 applications

|| -- 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/20140407/523bd4d7/attachment.html>

[PATCH v2 1/7] drm/exynos: add super device support

Hi Inki and Tomasz, On 04/06/2014 05:15 AM, Inki Dae wrote: (...) > The code creating the list of components to wait for > (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are > actually enabled in kernel config. > > Are you sure? > > exynos_drm_add_components() will try

[Bug 77142] New: Garbled text in Gtk2 applications

re, but scrolling in Firefox (and possible other applications) is much slower/less smooth. -- 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/

[PATCH] drm/radeon: fix audio pin counts for DCE6+

There is actually quite a bit of variance based on the asic. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/dce6_afmt.c | 14 ++ drivers/gpu/drm/radeon/radeon.h| 5 - 2 files changed, 14 insertions(+), 5 deletions(-) diff --git

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

On Mon, Apr 7, 2014 at 4:03 PM, Daniel Vetter wrote: > On Mon, Apr 7, 2014 at 7:23 PM, Rob Clark wrote: >> On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding >> wrote: >>> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote: On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)

mind if we do that in a follow > up patch so we can keep it separate from the addition of the bare > address packets? No, looking at the code again, I don't see how we can do much better without sacrificing much of the clarity of the code. But perhaps this could be documented somewhere else than the I2C helpers. Perhaps the struct drm_dp_aux comment should be updated, which would cause the DRM docbook to automatically pick up that change as well. 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/20140407/aa052f13/attachment-0001.sig>

[Bug 77009] 24P playback video signal loss with latest DRI patches

h higher than 100. LMK if you need more. TIA. -- 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/20140407/6642275c/attachment-0001.html>

[Bug 77002] hdmi audio problems with 3.14

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/15687069/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

[PATCH 2/3] drm/edid: Check for user aspect ratio input

In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. Signed-off-by: Vandana Kannan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file

[PATCH 1/3] drm/crtc: Add property for aspect ratio

Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. Signed-off-by: Vandana Kannan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_crtc.c | 31 +++

[Bug 77002] hdmi audio problems with 3.14

hives/dri-devel/attachments/20140407/256734dd/attachment.html>

[PATCH 1/3] drm/crtc: Add property for aspect ratio

On Apr-07-2014 3:33 PM, Kannan, Vandana wrote: > Added a property to enable user space to set aspect ratio. > This patch contains declaration of the property and code to create the > property. > > Signed-off-by: Vandana Kannan > Cc: dri-devel at lists.freedesktop.org > --- This patch series is

[PATCH v12][ 12/12] ARM: imx_v6_v7_defconfig: Add more drm drivers.

The DRM_PANEL_SIMPLE is needed by the eukrea mbimxsd51's displays. Signed-off-by: Denis Carikli --- ChangeLog v10->v11: - New patch, splitting it would be overkill. --- arch/arm/configs/imx_v6_v7_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v12][ 11/12] ARM: dts: mbimx51sd: Add CMO-QVGA backlight support.

Signed-off-by: Denis Carikli --- ChangeLog v9->v11: - Now uses the drm-panel instead of the display-timings. ChangeLog v8->v9: - Removed the Cc. They are now set in git-send-email directly. - The backlight is now on at boot. ChangeLog v6->v7: - Shrinked even more the Cc list. ChangeLog v5->v6:

[PATCH v12][ 10/12] ARM: dts: mbimx51sd: Add display support.

The CMO-QVGA, DVI-SVGA and DVI-VGA are added. Signed-off-by: Denis Carikli --- ChangeLog v10->v11: - Now uses the drm-panel instead of the display-timings. This is to get regulator support, which is lacking in the imx-drm driver when using the display-timings. ChangeLog v9->v10: - Rebased -

[PATCH v12][ 09/12] drm/panel: Add Eukrea mbimxsd51 displays.

Signed-off-by: Denis Carikli --- ChangeLog v11->v12: - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names ChangeLog v10->v11: - New patch. --- .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt |7 ++ .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt |7 ++

[PATCH v12][ 08/12] imx-drm: Use drm_display_mode timings flags.

The previous hardware behaviour was kept if the flags are not set. Signed-off-by: Denis Carikli --- ChangeLog v11->v12: - Rebased: It now uses the following new flags defines names: CLK_POL, ENABLE_POL - The inversions in ipuv3-crtc.c are now fixed. - ipuv3-crtc.c was still using

[PATCH v12][ 07/12] drm: drm_display_mode: add signal polarity flags

We need a way to pass signal polarity informations between DRM panels, and the display drivers. To do that, a pol_flags field was added to drm_display_mode. Signed-off-by: Denis Carikli --- ChangeLog v11->v12: - Rebased: This patch now applies against drm_modes.h - Rebased: It now uses the

[PATCH v12][ 06/12] ARM: dts: imx5*, imx6*: correct display-timings nodes.

The imx-drm driver can't use the de-active and pixelclk-active display-timings properties yet. Instead the data-enable and the pixel data clock polarity are hardcoded in the imx-drm driver. So theses properties are now set to keep the same behaviour when imx-drm will start using them.

[PATCH v12][ 05/12] imx-drm: use defines for clock polarity settings

Signed-off-by: Denis Carikli --- ChangeLog 11->v12: - Improved the define names to match the hardware: ENABLE_POL is not a clock signal but instead an enable signal. ChangeLog v9->v10: - New patch which was splitted out from: "staging: imx-drm: Use de-active and pixelclk-active

[PATCH v12][ 04/12] imx-drm: Match ipu_di_signal_cfg's clk_pol with its description.

According to the datasheet, setting the di0_polarity_disp_clk field in the GENERAL di register sets the output clock polarity to active high. Signed-off-by: Denis Carikli --- ChangeLog v9->v10: - New patch that is now needed by the "staging: imx-drm: Use de-active and pixelclk-active" patch.

[PATCH v12][ 03/12] imx-drm: Correct BGR666 and the board's dts that use them.

The current BGR666 is not consistent with the other color mapings like BGR24. BGR666 should be in the same byte order than BGR24. Signed-off-by: Denis Carikli Acked-by: Philipp Zabel --- ChangeLog v9->v10: - Rebased. - Added Philipp Zabel's Ack. - Included Lothar Wa?mann's suggestion about

[PATCH v12][ 02/12] imx-drm: Add RGB666 support for parallel display.

Signed-off-by: Denis Carikli Acked-by: Philipp Zabel --- ChangeLog v8->v9: - Rebased. - Added Philipp Zabel's ack. - Shortened the patch title. ChangeLog v8->v9: - Removed the Cc. They are now set in git-send-email directly. - Rebased. ChangeLog v7->v8: - Shrinked even more the Cc list.

[PATCH v12][ 01/12] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

That new macro is needed by the imx_drm staging driver for supporting the QVGA display of the eukrea-cpuimx51 board. Signed-off-by: Denis Carikli Acked-by: Mauro Carvalho Chehab Acked-by: Laurent Pinchart Acked-by: Philipp Zabel --- ChangeLog v9->v10: - Rebased on top of: "211e7f2 [media]

[PATCH v5 00/11] imx-drm dt bindings

Am Montag, den 07.04.2014, 12:05 +0200 schrieb Philipp Zabel: > Hi Shawn, > > Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo: > > On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote: > > > I just came across a couple problems when testing the series on > > > my imx6dl-sabresd

[RFC 0/3] TTM priority queue logic

Hi, Lauri. On 04/04/2014 03:52 PM, Lauri Kasanen wrote: > Hi list, Thomas, > > I'd like to know if this is going in the right direction. This looks fine with me. However, if possible I'd like the drivers to enable both alloc_threshold and priority queue on a per-memory-type basis. That would

[PATCH] drm/omap: fix plane rotation

On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote: > On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas > wrote: >> Plane rotation with omapdrm is currently broken. >> It seems omap_plane_mode_set() expects width and height in screen >> coordinates, so pass it like that. >> >> Cc: Rob Clark >>

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding wrote: > On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote: >> On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote: >> > Add cursor plane as a parameter to drm_crtc_init() and update all >> > existing DRM drivers to use a

[PATCH] drm/omap: fix plane rotation

On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas wrote: > On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote: >> On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas >> wrote: >>> Plane rotation with omapdrm is currently broken. >>> It seems omap_plane_mode_set() expects width and height in screen

[PATCH 01/13] drm/mgag200: Remove unnecessary NULL check in bo_unref

On 04/07/2014 12:56 PM, Daniel Vetter wrote: > On Mon, Apr 7, 2014 at 5:19 PM, Ian Romanick wrote: >> On 04/05/2014 02:44 AM, Daniel Vetter wrote: >>> ttm_bo_unref unconditionally calls kref_put on it's argument, so the >>> thing can't be NULL without already causing Oopses. >> >> Doesn't this

[PATCH] DRM: Armada: Use devm_ioremap_resource()

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/20140407/ae3b2dc3/attachment.sig>

[PATCH] drm/i915: support address only i2c-over-aux transactions

To support bare address requests used by the drm dp helpers. Signed-off-by: Jani Nikula --- Hi Alex, similar to Thierry's patch for i915. BR, Jani. --- drivers/gpu/drm/i915/intel_dp.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH v5 00/11] imx-drm dt bindings

On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote: > I just came across a couple problems when testing the series on > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it > using Russell's branch below, which I believe has all the pieces put > together. > >

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

ent was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/a9808a95/attachment.sig>

[PATCH v5 00/11] imx-drm dt bindings

Hi Shawn, Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo: > On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote: > > I just came across a couple problems when testing the series on > > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it > > using Russell's

[PATCH] DRM: armada: fix corruption while loading cursors

Loading cursors to the LCD controller's SRAM can be corrupted when the configured pixel clock is relatively slow. This seems to be caused when we write back-to-back to the SRAM registers. There doesn't appear to be any status register we can read to check when an access has completed. Inserting

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

On 07.04.2014 11:41, Thierry Reding wrote: > On Mon, Apr 07, 2014 at 11:34:22AM +0300, Terje Bergstr?m wrote: >> On 07.04.2014 11:18, Thierry Reding wrote: >>> If I understand correctly there's no immediate need for this to go to >>> stable kernels, nor for it to be queued for 3.15, right? That is

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

On 07.04.2014 11:18, Thierry Reding wrote: > If I understand correctly there's no immediate need for this to go to > stable kernels, nor for it to be queued for 3.15, right? That is the > potential extra write isn't causing any harm on actual hardware, is it? > > In that case I'll queue this up

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

On 05.04.2014 01:31, Stephen Warren wrote: > From: Stephen Warren > > diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c > index db9017adfe2b..498b37e39058 100644 > --- a/drivers/gpu/host1x/hw/intr_hw.c > +++ b/drivers/gpu/host1x/hw/intr_hw.c > @@ -47,7 +47,7 @@

Required backwards support level?

On Son, 2014-04-06 at 15:26 +0300, Lauri Kasanen wrote: > Hi, > > Obviously old userspace + new kernel combo needs to be supported. But > I'm not so sure about a mixed case, does old userspace + new userspace > need to be supported to run at the same time? > > For example, a new 64-bit

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions

On Fri, 04 Apr 2014, Alex Deucher wrote: > Needed for proper i2c over aux handling for certain > monitors and configurations (e.g., dp bridges or > adapters). > > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/radeon/atombios_dp.c | 15 +++ > 1 file changed, 11 insertions(+), 4

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)

hierry -- 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/20140407/eb0a812c/attachment.sig>

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

reedesktop.org/archives/dri-devel/attachments/20140407/77c9b71b/attachment.sig>

[PATCH] drm/tegra: dp: Support address-only I2C-over-AUX transactions

From: Thierry Reding Certain types of I2C-over-AUX transactions require that only the address is transferred. Detect this by looking at the AUX message's size and set the address-only bit appropriately. Signed-off-by: Thierry Reding --- Hi Alex, This patch is required to

[PATCH] drm/i915: support address only i2c-over-aux transactions

On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote: > To support bare address requests used by the drm dp helpers. > > Signed-off-by: Jani Nikula > > --- > > Hi Alex, similar to Thierry's patch for i915. > Looks good to me. Reviewed-by: Alex Deucher Do you want me to add this to the patch

[PATCH 4/4] drm/radeon/dp: switch to the common i2c over aux code

Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 117 + drivers/gpu/drm/radeon/radeon_connectors.c | 44 ++- drivers/gpu/drm/radeon/radeon_display.c| 11 ++-

[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions (v2)

If you are using the common dp over i2c functionality, it is asumed that the aux transfer function does not modify the any of the msg structure other than the reply field. Doing so breaks the logic in the common code. v2: update struct drm_dp_aux comments about assumptions Signed-off-by: Alex

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)

We need bare address packets at the start and end of each i2c over aux transaction to properly reset the connection between transactions. This mirrors what the existing dp i2c over aux algo currently does. This fixes EDID fetches on certain monitors especially with dp bridges. v2: update as per

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions (v2)

Needed for proper i2c over aux handling for certain monitors and configurations (e.g., dp bridges or adapters). v2: add comments clarifying tx_size setting. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 23 ++- 1 file changed, 18 insertions(+), 5

[PATCH 0/4] Reset i2c connection between xfers (v4)

Updated with Thierry's comments. Alex Deucher (4): drm/radeon/dp: handle zero sized i2c over aux transactions (v2) drm/dp/i2c: send bare addresses to properly reset i2c connections (v4) drm/dp/i2c: Update comments about common i2c over dp assumptions (v2) drm/radeon/dp: switch to the

Required backwards support level?

On Sun, 6 Apr 2014 19:58:48 +0200 Daniel Vetter wrote: > On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote: > > This is related to my memory management work. As the VRAM queue is > > global, it cannot be determined on a per-app basis. If at least one > > client is running old userspace, the

[PATCH] imx-drm: imx-drm-core: Fix imx_drm_encoder_get_mux_id

The decoder mux id is equal to the port id of the encoder's input port that is connected to the given crtc, not to the endpoint id (which is arbitrary and usually zero). Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/imx-drm-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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

arm on actual hardware, is it? In that case I'll queue this up for 3.16. 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/20140407/c6c11806/attachment-0001.sig>

[PATCH v5 00/11] imx-drm dt bindings

On Mon, Apr 07, 2014 at 12:23:37PM +0800, Shawn Guo wrote: > And I see another HDMI regression with my testing on mainline kernel. I > can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only > probes 1024x768 with the mainline today. Works for me here. > [20.606] (II)

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)

hese assumptions, I don't see a reason for these assumptions in the first place. I'd prefer if we simply provided the complete message rather than rely on drivers not to touch anything but the reply field. Thierry -- next part -- A non-text attachment was scrubbed...

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)

On Mon, Apr 7, 2014 at 3:49 AM, Thierry Reding wrote: > On Fri, Apr 04, 2014 at 03:58:37PM -0400, Alex Deucher wrote: >> We need bare address packets at the start and end of >> each i2c over aux transaction to properly reset the connection >> between transactions. This mirrors what the existing

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

On 04/07/2014 02:18 AM, Thierry Reding wrote: > On Fri, Apr 04, 2014 at 04:31:05PM -0600, 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

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions

On Mon, Apr 7, 2014 at 9:24 AM, Alex Deucher wrote: > On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula > wrote: >> On Fri, 04 Apr 2014, Alex Deucher wrote: >>> Needed for proper i2c over aux handling for certain >>> monitors and configurations (e.g., dp bridges or >>> adapters). >>> >>>

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions

On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula wrote: > On Fri, 04 Apr 2014, Alex Deucher wrote: >> Needed for proper i2c over aux handling for certain >> monitors and configurations (e.g., dp bridges or >> adapters). >> >> Signed-off-by: Alex Deucher >> --- >>

[PATCH 12/13] drm/i2c/tda998x: Fix signed overflow issue

On 04/05/2014 02:45 AM, Daniel Vetter wrote: > This is C standard hair-splitting, but afaict > - sum will be promoted to signed int in computation since > uint8_t fits > - signed overflow is undefined. > > No we need to add up an awful lot of bytes to actually make it ^^ Now > overflow. But

[PATCH 11/13] drm/bochs: Remove unecessary NULL check in gem_free

On 04/05/2014 02:45 AM, Daniel Vetter wrote: > The ->gem_free_object never gets called with a NULL pointer, the check > is redundant. Also checking after the upcast allows compilers to elide > it anyway. > > Noticed while chasing coverity reports, somehow this one here was not > flagged. > >

[PATCH 08/13] drm/ast: Remove dead code from cbr_scan2

On 04/05/2014 02:44 AM, Daniel Vetter wrote: > The outer if already checks for data != 0, so it can't really be > 0. Hence remove it. > > Now I don't have specs or anything for this beast, so I have no > idea whether this was actually intended or whether the logic > should be different. At least

[PATCH 06/13] drm/mgag200: Remove unecessary NULL check in gem_free

On 04/05/2014 02:44 AM, Daniel Vetter wrote: > The ->gem_free_object never gets called with a NULL pointer, the check > is redundant. Also checking after the upcast allows compilers to elide > it anyway. > > Spotted by coverity. > > Signed-off-by: Daniel Vetter Same as MGA change.

[PATCH 04/13] drm/cirrus: Remove unecessary NULL check in gem_free

On 04/05/2014 02:44 AM, Daniel Vetter wrote: > The ->gem_free_object never gets called with a NULL pointer, the check > is redundant. Also checking after the upcast allows compilers to elide > it anyway. > > Spotted by coverity. > > Signed-off-by: Daniel Vetter Same as MGA change.

  1   2   >