[GIT PULL v2] exynos-drm-next

Hi Dave, This pull request includes MIPI-DSI driver, two panel drivers, and relevant dt bindings. And I has excepted one patch series, super device support from exynos-drm-next because the patch series hadn't been reviewed by right maintainers and mailing list. The patch series is

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

On Fri, Apr 04, 2014 at 01:52:05PM -0400, Alex Deucher wrote: > 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. > >

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

On Fri, Apr 04, 2014 at 01:52:04PM -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 dp i2c > over aux algo currently does. > > This fixes EDID

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/8c10a2d5/attachment.html>

[Bug 77069] New: Use semantic naming for microcode files

spaces. -- 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/20140404/288407dd/attachment.html>

[PATCH] drm/dp_helper: don't return EPROTO for defers (v2)

From: Dave Airlie If we get a msg.reply of REPLY_DEFER, we also get an err of 0 so we fail reads with 0 < size and return -EPROTO instead of trying again. v2: same fix in i2c code. Found writing MST support. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_dp_helper.c

[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed

next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/6aeb52c8/attachment.html>

[PATCH] radeon: sync with radeon_drm.h from kernel headers

From: Marek Ol??k Signed-off-by: Marek Ol??k --- I will make a new release and clean up Mesa definitions after this is committed. include/drm/radeon_drm.h | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git

[PATCH 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

On Fri, Apr 04, 2014 at 10:40:57AM -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 dp i2c > over aux algo currently does. > > This fixes EDID

[Bug 76190] [r600g-evergreen] GPU lockup in Stunt Rally (bisected)

vel/attachments/20140404/af824317/attachment.html>

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

tachments/20140404/d7706cb9/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/3ec039cc/attachment-0001.html>

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

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/d42ea384/attachment.html>

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

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/ae8df866/attachment.html>

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

back. This is my first post on this site, I hope I don't mess it ;) -- 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 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

On Fri, Apr 04, 2014 at 10:40:57AM -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 dp i2c > over aux algo currently does. > > This fixes EDID

[GIT PULL] exynos-drm-next

2014-04-04 17:05 GMT+09:00, Tomasz Figa : > On 04.04.2014 09:48, Inki Dae wrote: >> >> >>> -Original Message- >>> From: Tomasz Figa [mailto:t.figa at samsung.com] >>> Sent: Friday, April 04, 2014 4:29 PM >>> To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri- >>> devel at

[PATCH 2/2] drm/exynos/fbdev: don't set mode_config.fb_base

AFAICT, the fb_base of a drm_device's mode_config is never used. It isn't accessed by core drm, it isn't used by fbmem, and it isn't exposed to user space. Furthermore, it is probably supposed to be a physical address, not the dma address mapped to the display controller, so this is just wrong.

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

Kernel access to the eyxnos fbdev framebuffer is via its gem object's kernel mapping (kvaddr, stored in info->screen_base). User space access is provided by mmap(), read() and write() of /dev/fb/fb0. These functions also only use screen_base/screen_size(). Therefore, it is not necessary to set

[PULL] drm-intel-fixes

Hi Dave, Merge window -fixes pull request as usual. Well, I did sneak in Jani's drm_i915_private_t typedef removal, need to have fun with a big sed job too ;-) Otherwise: - hdmi interlaced fixes (Jesse) - pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but not cc: stable

[RFC 3/3] drm/ttm: Enable the priority queue for VRAM

Signed-off-by: Lauri Kasanen --- drivers/gpu/drm/ttm/ttm_bo.c | 68 +++- 1 file changed, 54 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 621151c..80e5856 100644 ---

[PATCH 4/4] Revert "drm/exynos: add mout_hdmi clock in hdmi driver to change parent"

This reverts commit 59956d35a8618235ea715280b49447bb36f2c975. Signed-off-by: Tomasz Stanislawski --- drivers/gpu/drm/exynos/exynos_hdmi.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c

[PATCH 3/4] clk: exynos4: enable clk_set_parent() propagation for sclk_hdmi and sclk_mixer clocks

This patch enables clk_set_parent() propagation for clocks used by s5p-tv and exynos-drm drivers. Signed-off-by: Tomasz Stanislawski --- drivers/clk/samsung/clk-exynos4.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos4.c

[PATCH 2/4] clk: exynos4: export sclk_hdmiphy clock

Export sclk_hdmiphy clock to be usable from DT. Signed-off-by: Tomasz Stanislawski --- drivers/clk/samsung/clk-exynos4.c |2 +- include/dt-bindings/clock/exynos4.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/samsung/clk-exynos4.c

[PATCH 1/4] clk: propagate parent change up one level

This patch adds support for propagation of setup of clock's parent one level up. This feature is helpful when a driver changes topology of its clocks using clk_set_parent(). The problem occurs when on one platform/SoC driver's clock is located at MUX output but on the other platform/SoC there is

[RFC 2/3] drm/ttm: Add the priority queue to appropriate structs

Signed-off-by: Lauri Kasanen --- drivers/gpu/drm/ast/ast_ttm.c | 1 + drivers/gpu/drm/bochs/bochs_mm.c | 1 + drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 + drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 + drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/gpu/drm/qxl/qxl_ttm.c

[PATCH 0/4] Update to Exynos clocks

This patchset adds some updates to clocks for Exynos4 platform and to the clock core. The patches are rebased on linux/next. An interesting part might be 'propagation of clk_set_parent()'. This feature simplifies configuration of complex topologyof clocks by drivers. Such a situation happens

[RFC 1/3] drm/ttm: Add a priority queue

Signed-off-by: Lauri Kasanen --- drivers/gpu/drm/ttm/Makefile | 2 +- drivers/gpu/drm/ttm/ttm_priority.c | 152 + include/drm/ttm/ttm_priority.h | 90 ++ 3 files changed, 243 insertions(+), 1 deletion(-) create mode 100644

[RFC 0/3] TTM priority queue logic

Hi list, Thomas, I'd like to know if this is going in the right direction. I've implemented a priority queue on top of the kernel rb tree and linked list. It's been tested well in userspace. I hardcoded radeon to input the buffer size as the score. Nothing blew up, games ran fine, and even got

PCI Radeon RV100 detection hang on sparc64

From: Meelis Roos Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST) >> > > That looks quite strange. I guess the kernel should map the ROM at the >> > > address OpenBoot/OF assigned to it. ( 1002 ). >> > >> > The address you see is a raw physical I/O address, which is a

[GIT PULL] exynos-drm-next

> -Original Message- > From: Tomasz Figa [mailto:t.figa at samsung.com] > Sent: Friday, April 04, 2014 4:29 PM > To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri- > devel at lists.freedesktop.org; 'Marek Szyprowski'; > devicetree at vger.kernel.org; Grant Likely; Rob Herring >

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

[RFC 0/3] TTM priority queue logic

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. > > I've implemented a priority queue on top of the kernel rb tree and > linked list. It's been tested well in userspace. > > I hardcoded radeon to input the buffer size as

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

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 the conversion of count of bits to

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

elps? -- 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/20140404/00dd04f8/attachment.html>

[PATCH v4 14/34] drm/exynos: hdmi: remove the i2c drivers and use devtree

Hi Inki, Sorry for a very late reply. On 02/19/2014 12:14 PM, Inki Dae wrote: > Hi Tomasz, > > > 2014-02-14 23:13 GMT+09:00 Tomasz Stanislawski : >> Hi Daniel, >> I think that it would be better to change the semantic of phy and ddc >> bindings. >> >> Rather than pointing to I2C client it

[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

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. Signed-off-by: Alex Deucher Cc: Ville Syrj?l? Cc: Jani Nikula Cc: Thierry

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

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

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 deletions(-) diff --git

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

V3 just drops a left over debug statement. Alex Deucher (4): drm/radeon/dp: handle zero sized i2c over aux transactions drm/dp/i2c: send bare addresses to properly reset i2c connections (v3) drm/dp/i2c: Update comments about common i2c over dp assumptions drm/radeon/dp: switch to the

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

Hi Inki, On 01.04.2014 14:37, Inki Dae wrote: > 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 { >

[Bug 77002] problems with kernel 3.14

got to upload this the first time. Getting a lot of I/O errors in AlSA Sink. -- 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/20

[Bug 77002] problems with kernel 3.14

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

[Bug 77002] problems with kernel 3.14

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

[Bug 76659] Display does not return from DPMS off using ATI drivers

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/20140404/95e8486c/attachment.html>

[Bug 77002] problems with kernel 3.14

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/dd35e68a/attachment-0001.html>

[Bug 77002] problems with kernel 3.14

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/6e1704d7/attachment.html>

[GIT PULL] exynos-drm-next

Hi Tomasz, > -Original Message- > From: Tomasz Figa [mailto:tomasz.figa at gmail.com] > Sent: Friday, April 04, 2014 2:00 PM > To: inki.dae at samsung.com; airlied at linux.ie; dri- > devel at lists.freedesktop.org > Subject: Re: [GIT PULL] exynos-drm-next > > Hi Inki, > > On 03.04.2014

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

this weekend I will try to collect all of the data. +/- patches. -- 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/20140404/f1d4d

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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/20140404/0f403fb2/attachment.html>

[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

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. Signed-off-by: Alex Deucher Cc: Ville Syrj?l? Cc: Jani Nikula Cc: Thierry

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

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

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 deletions(-) diff --git

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

I think this set should address the remaining concerns raised by Ville. Alex Deucher (4): drm/radeon/dp: handle zero sized i2c over aux transactions drm/dp/i2c: send bare addresses to properly reset i2c connections (v2) drm/dp/i2c: Update comments about common i2c over dp assumptions

[PATCH] drm/dp_helper: don't return EPROTO for defers (v2)

On Fri, 04 Apr 2014, Dave Airlie wrote: > From: Dave Airlie > > If we get a msg.reply of REPLY_DEFER, we also get an err of 0 > so we fail reads with 0 < size and return -EPROTO instead of trying > again. > > v2: same fix in i2c code. > > Found writing MST support. > Reviewed-by: Jani Nikula

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

<http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/c85e88be/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

s the entire amount of vram. -- 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/20140404/6efbc992/attachment.html>

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

nts/20140404/3cb7f35c/attachment.html>

Synchronization between a crtc mode_set and page_flip?

On Friday 04 April 2014 02:54 AM, Daniel Vetter wrote: > On Thu, Apr 03, 2014 at 02:28:32PM +0530, Archit Taneja wrote: >> On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote: >>> On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja wrote: Hi, I was trying to figure out how we are

[RESEND][GIT PULL] exynos-drm-next

Hi Dave, I am re-sending git-pull request with fixing module build errors. For this, I reverted one patch, and added two patches below, - Revert 'drm/exynos: register platform driver at each kms sub drivers' . Exynos drm should be built as single module, so platform_driver_register of

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

re the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/e7a3ea18/attachment-0001.html>

[Bug 76998] hang on CEDAR right after log on

RL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/b0017711/attachment.html>

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

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/618073f5/attachment.html>

[Bug 76998] hang on CEDAR right after log on

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/51cec1fa/attachment.html>

[Bug 76998] hang on CEDAR right after log on

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/d7a3eeb2/attachment.html>

[PATCH] drm/dp_helper: don't return EPROTO for defers

From: Dave Airlie If we get a msg.reply of REPLY_DEFER, we also get an err of 0 so we fail reads with 0 < size and return -EPROTO instead of trying again. Found writing MST support. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2

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

64 bits wide in the future. Although they'd probably still be accessible as 32 bit values even then. 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/20140404/7de20712/attachment.sig>

[PATCH 3/3] 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 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

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. Signed-off-by:

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

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 deletions(-) diff --git

[PATCH 0/3] Reset i2c connection between xfers

When switching to the new common i2c over aux code, I ran into problems fetching the EDID on certain DP monitors. I tracked this down to the lack of bare address packets being sent between i2c transfers. This patch set adds that functionality which brings it back inline with the old drm dpm i2c

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

lem? Thank you, Benjamin. -- 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/20140404/37d2109c/attachment.html>

[PATCH] modetest: consider supported formats before selecting a DRM plane

On Fri, Mar 28, 2014 at 6:15 AM, Fabien DESSENNE wrote: > This fixes an issue where the DRM planes do not support the same pixel > formats. > The current implementation selects a DRM plane without checking whether > the pixel format is supported or not. As a consequence modetest may try > to set

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

On Fri, Apr 4, 2014 at 2:09 AM, Jani Nikula wrote: > On Sat, 22 Mar 2014, Alex Deucher wrote: >> This adds a flags field and a new flag, BARE_ADDRESS, >> which drivers can use for special handling when they >> want to set just the aux address. This is needed >> to properly reset the connection

[GIT PULL] exynos-drm-next

On 04.04.2014 09:48, Inki Dae wrote: > > >> -Original Message- >> From: Tomasz Figa [mailto:t.figa at samsung.com] >> Sent: Friday, April 04, 2014 4:29 PM >> To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri- >> devel at lists.freedesktop.org; 'Marek Szyprowski'; >> devicetree at

[GIT PULL] exynos-drm-next

On 04.04.2014 07:34, Inki Dae wrote: > Hi Tomasz, > >> -Original Message- >> From: Tomasz Figa [mailto:tomasz.figa at gmail.com] >> Sent: Friday, April 04, 2014 2:00 PM >> To: inki.dae at samsung.com; airlied at linux.ie; dri- >> devel at lists.freedesktop.org >> Subject: Re: [GIT PULL]

[GIT PULL] drm/tegra: Changes for v3.15-rc1

vel/attachments/20140404/e4c7709f/attachment.sig>

[GIT PULL] drm/panel: Changes for v3.15-rc1

00644 Documentation/devicetree/bindings/panel/lg,lp129qe.txt -- 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/

[PATCH] modetest: consider supported formats before selecting a DRM plane

Can anyone review this patch ? Thanks for your time. Fabien > -Original Message- > From: Fabien DESSENNE [mailto:fabien.dessenne at st.com] > Sent: vendredi 28 mars 2014 11:16 > To: dri-devel at lists.freedesktop.org > Cc: Benjamin Gaignard; Vincent Abriou; Fabien DESSENNE > Subject:

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

On Sat, 22 Mar 2014, Alex Deucher wrote: > This adds a flags field and a new flag, BARE_ADDRESS, > which drivers can use for special handling when they > want to set just the aux address. This is needed > to properly reset the connection between i2c transactions. Sorry it took me so long to get

[PATCH] drm/dp_helper: don't return EPROTO for defers

On Fri, 04 Apr 2014, Jani Nikula wrote: > On Fri, 04 Apr 2014, Dave Airlie wrote: >> From: Dave Airlie >> >> If we get a msg.reply of REPLY_DEFER, we also get an err of 0 >> so we fail reads with 0 < size and return -EPROTO instead of trying >> again. >> >> Found writing MST support. >> > >

[PATCH] drm/dp_helper: don't return EPROTO for defers

On Fri, 04 Apr 2014, Dave Airlie wrote: > From: Dave Airlie > > If we get a msg.reply of REPLY_DEFER, we also get an err of 0 > so we fail reads with 0 < size and return -EPROTO instead of trying > again. > > Found writing MST support. > Reviewed-by: Jani Nikula > Signed-off-by: Dave Airlie

[PATCH] drm/dp_helper: don't return EPROTO for defers

well. I agree. drm_dp_i2c_do_msg() should have the same change. With that: Reviewed-by: Thierry Reding -- 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/20140404/97e6f1e6/attachment.sig>

[PULL] vmwgfx-next

Dave, The second vmwgfx pull request for the 3.15 merge window. Contains a fbdev fix by Christopher Friedt, one fix for a locking order violation introduced in 3.14 (hit when using queries) and finally a removal of the DRM_AUTH requirement around some vmwgfx IOCTLS where the caller is already

[PULL] ttm-next

Dave, Currently only a single patch fixing up mixed use of the ttm_bo_reserve and ww_mutex APIs. /Thomas The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a: Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux into drm-next (2014-04-02

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

. Thanks, Christian. -- 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/20140404/541a2678/attachment.html>

[PATCH] drm: gem-cma: Fix warnings due to improper printk formats

On Thu, Apr 3, 2014 at 10:21 AM, Laurent Pinchart wrote: > Hi Dave, > > Could you please take this patch in your tree ? > > What's the expected process when sending patches to the mailing list by the > way ? Do you track them somehow, or always expect pull requests ? I generally pick up things

Synchronization between a crtc mode_set and page_flip?

On Fri, Apr 4, 2014 at 3:21 AM, Archit Taneja wrote: > On Friday 04 April 2014 02:54 AM, Daniel Vetter wrote: >> >> On Thu, Apr 03, 2014 at 02:28:32PM +0530, Archit Taneja wrote: >>> >>> On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote: On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja

[PATCH 2/5] drm/exynos: use regmap interface to set hdmiphy control bit in pmu

Thanks Inki, On 3 April 2014 21:23, Inki Dae wrote: > Hi Rahul, > > Thanks for contributions. > > 2014-04-03 2:13 GMT+09:00 Rahul Sharma : >> From: Rahul Sharma >> >> Hdmiphy control bit needs to be set before setting the resolution >> to hdmi hardware. This was handled using dummy hdmiphy

[GIT PULL] exynos-drm-next

Hi Inki, On 03.04.2014 19:34, inki.dae at samsung.com wrote: > Hi Dave, > Sorry for late. > This pull request includes MIPI-DSI driver, two panel drivers, > super device support, and relevant dt bindings. > > Summaries: > - Add MIPI-DSI Driver, and dt bindigs > - Add S6E8AA0 MIPI-DSI

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

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

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

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

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

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140404/6f463fbc/attachment.html>

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

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

[GIT PULL] exynos-drm-next

Hi Dave, Sorry for late. This pull request includes MIPI-DSI driver, two panel drivers, super device support, and relevant dt bindings. Summaries: - Add MIPI-DSI Driver, and dt bindigs - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings - Add LD9040 parallel panel driver . this

[PATCH] drm/exynos: separate dpi from fimd

2014-04-04 1:35 GMT+09:00 Inki Dae : > 2014-04-03 23:26 GMT+09:00 Andrzej Hajda : >> The patch separates dpi related routines from fimd. >> >> Signed-off-by: Andrzej Hajda >> --- >> Hi Inki, >> >> This is my attempt to separate DPI from FIMD, >> it requires putting real probe back into

[PATCH] drm/exynos: separate dpi from fimd

2014-04-03 23:26 GMT+09:00 Andrzej Hajda : > The patch separates dpi related routines from fimd. > > Signed-off-by: Andrzej Hajda > --- > Hi Inki, > > This is my attempt to separate DPI from FIMD, > it requires putting real probe back into fimd_probe, but I > guess it should not be a problem, as

[PATCH] drm/exynos: separate dpi from fimd

Hi Andrzej, 2014-04-03 23:26 GMT+09:00 Andrzej Hajda : > The patch separates dpi related routines from fimd. > > Signed-off-by: Andrzej Hajda > --- > Hi Inki, > > This is my attempt to separate DPI from FIMD, Ah, I understood now. Right, if we can separate DPI from FIMD, we can also move some

  1   2   >