[RFC 0/2] drm/bridge: panel and chaining

create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c > > create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h > > > > -- > > 1.9.0 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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/20140430/02f48422/attachment.html>

[RFC 2/2] drm/bridge/ptn3460: add panel support

Rob, > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/bridge/ptn3460.c | 39 > +-- > include/drm/bridge/ptn3460.h | 6 -- > 2 files changed, 37 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ptn3460.c >

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

; case, but this could also include MIPI DSI lane configuration or any > > other kind of physical interface parameters) are distinct from the video > > modes. > > We already have the lanes field in struct mipi_dsi_device. Seems I've missed the addition of mipi_dsi_device to DRM. > I think in general I'd prefer to not spread these parameters around too > wildly. If this is a general requirement for DBI devices, perhaps what we > need is struct mipi_dbi_device? That could be done, but I'm not sure we should expose the nature of the panel device (i.e. "I'm a mipi_dsi_device") to the display controller. I would be worried about using container_of() on panel->dev to get a mipi_dsi_device pointer, as we would then need a strict guarantee that the panel->dev pointer is embedded directly in a mipi_dsi_device. This might be doable for DSI, but other kind of panels might be connected to different control busses (I'm thinking about I2C and SPI in particular) and still need to expose video interface parameters to the display controller driver. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/def4ed3f/attachment.sig>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

efix=/path/to/llvm to mesa's configure script. -- 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/20140430/5f80cc96/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/1f0cdb26/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

to force my system to use the modified stuf without breaking things. -- 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/20140430/b408c

[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume

From: Rahul Sharma While testing S2R on exynos board, system is hanging and rebooting due to nested mutex_lock calls in exynos drm resume callback. Changing the order of the calls is fixing the issue. Signed-off-by: Rahul Sharma --- Based on exynos-drm-next branch in

[PATCH 2/2] radeon: add Mullins pci ids

From: Samuel Li Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- radeon/r600_pci_ids.h | 17 + 1 file changed, 17 insertions(+) diff --git a/radeon/r600_pci_ids.h b/radeon/r600_pci_ids.h index 37fb61c..de25f16 100644 --- a/radeon/r600_pci_ids.h +++

[PATCH 1/2] radeon: add Mullins chip family

From: Samuel Li Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- radeon/radeon_surface.c | 1 + 1 file changed, 1 insertion(+) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 15127d4..109bd6b 100644 --- a/radeon/radeon_surface.c +++

[PATCH 0/2] libdrm_radeon support for Mullins

This adds support for the new Mullins and Beema APUs. Samuel Li (2): radeon: add Mullins chip family radeon: add Mullins pci ids radeon/r600_pci_ids.h | 17 + radeon/radeon_surface.c | 1 + 2 files changed, 18 insertions(+) -- 1.8.3.1

[PATCH 8/8] drm/radeon: add pci ids for Mullins

From: Samuel Li Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- include/drm/drm_pciids.h | 16 1 file changed, 16 insertions(+) diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h index 49376ae..6dfd64b 100644 ---

[PATCH 7/8] drm/radeon: add Mullins VCE support

From: Leo Liu VCE 2.0 just like the other CIK parts. Signed-off-by: Leo Liu Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_vce.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_vce.c b/drivers/gpu/drm/radeon/radeon_vce.c

[PATCH 6/8] drm/radeon: modesetting updates for Mullins.

From: Samuel Li Uses the same code as Kabini. Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c

[PATCH 5/8] drm/radeon: dpm updates for KV/KB

- Use vddc/sclk dep table for voltage if available - Fix UVD DPM setup - Patch voltage tables properly for non-UVD blocks - Fix DPM + UVD/VCE on Mullins Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/kv_dpm.c | 117 +--- 1 file changed, 97

[PATCH 4/8] drm/radeon: add Mullins dpm support.

From: Samuel Li Generic dpm support similar to Kabini. Mullins specific features will be worked on later. Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/kv_dpm.c| 20 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 1 + 2

[PATCH 3/8] drm/radeon: add Mullins UVD support.

From: Samuel Li Has same version of UVD as other CIK parts. Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_uvd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c

[PATCH 2/8] drm/radeon: update cik init for Mullins.

From: Samuel Li Also add golden registers, update firmware loading functions. Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/cik.c | 71 +++ drivers/gpu/drm/radeon/radeon_ucode.h | 1 + 2 files

[PATCH 1/8] drm/radeon: add Mullins chip family

From: Samuel Li Mullins is a new CI-based APU. Signed-off-by: Samuel Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_asic.c | 1 + drivers/gpu/drm/radeon/radeon_device.c | 1 + drivers/gpu/drm/radeon/radeon_family.h | 1 + 3 files changed, 3

[PATCH 0/8] Add support for Mullins and Beema

This patch set adds support for the new Mullins and Beema APUs. Alex Deucher (1): drm/radeon: dpm updates for KV/KB Leo Liu (1): drm/radeon: add Mullins VCE support Samuel Li (6): drm/radeon: add Mullins chip family drm/radeon: update cik init for Mullins. drm/radeon: add Mullins UVD

[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume

From: Rahul Sharma While testing S2R on exynos board, system is hanging and rebooting due to nested mutex_lock calls in exynos drm resume callback. Changing the order of the calls is fixing the issue. Change-Id: I3f3ada8a413a414dca0bbac53cfc5fe3138af4d6 Signed-off-by:

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

[RFC 0/3] DRM driver for the ATMEL High end LCD controller

Hi Tim, On 04/24/2014 02:46 PM, Tim Niemeyer wrote: > > Hi Boris > > Am Donnerstag, den 24.04.2014, 14:14 +0200 schrieb Boris BREZILLON: >> Hi Tim, >> >> On 23/04/2014 17:36, Tim Niemeyer wrote: >>> Hi Jean-Jacques, >>> >>> Am Freitag, den 18.04.2014, 11:45 +0200 schrieb Jean-Jacques Hiblot:

[RFC PATCH 4/4] drm/panel/ld9040: do not power off panel on removal

Panel is powered off already by connector during drm_panel_remove call. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/panel/panel-ld9040.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-ld9040.c b/drivers/gpu/drm/panel/panel-ld9040.c index 1f1f837..1def4b0

[RFC PATCH 3/4] drm/exynos/dpi: add interface tracker support

exynos_dpi uses connector polling for tracking panel presence, this solution introduces unnecessary 10s delay before panel activation. Moreover it is unsafe, module unloading or driver unbinding can cause system crash. interface_tracker support solves both problems. Signed-off-by: Andrzej Hajda

[RFC PATCH 2/4] drm/panel: add interface tracker support

drm_panel framework allows only query for presence of given panel. It also does not protect panel module from unloading and does not provide solution for driver unbinding. interface_tracker should solve both issues. Signed-off-by: Andrzej Hajda --- --- drivers/gpu/drm/drm_panel.c | 5

[RFC PATCH 1/4] drivers/base: add interface tracker framework

interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of

[PATCH] drm/radeon/dp: check for errors in dpcd reads

Am 30.04.2014 15:27, schrieb Alex Deucher: > Check to make sure the transaction succeeded before > using the register value. Fixes occasional link training > problems. > > Noticed-by: Sergei Antonov > Signed-off-by: Alex Deucher Applied to my 3.15 queue. Christian. > --- >

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

> -Original Message- > From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel > Kurtz > Sent: Wednesday, April 30, 2014 3:21 PM > To: Inki Dae > Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K > Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

> -Original Message- > From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel > Kurtz > Sent: Wednesday, April 30, 2014 3:21 PM > To: Inki Dae > Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K > Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel

[RFC 0/2] drm/bridge: panel and chaining

Hi Rob, > -Original Message- > From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf > Of Rob Clark > Sent: Wednesday, April 30, 2014 4:58 AM > To: dri-devel at lists.freedesktop.org > Cc: Ajay Kumar > Subject: [RFC 0/2] drm/bridge: panel and chaining > > So I

[RFC 0/2] drm/bridge: panel and chaining

On Wed, Apr 30, 2014 at 1:46 PM, Sean Paul wrote: > On Wed, Apr 30, 2014 at 11:38 AM, Rob Clark wrote: >> On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar wrote: >>> >>> On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA >>> wrote: --- Original

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

Hi Daniel, Please use only text format. :) >From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel >Kurtz >Sent: Wednesday, April 30, 2014 1:57 PM >To: Inki Dae >Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K >Subject: Re: [PATCH v2] drm/exynos: fimd: clear

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140430/0dd3d1cd/attachment.html>

[Bug 73931] rmmod radeon and kernel crash

https://bugzilla.kernel.org/show_bug.cgi?id=73931 --- Comment #10 from Pali Roh?r --- @Alex Deucher: ping -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

On Wed, Apr 30, 2014 at 1:44 PM, Inki Dae wrote: > Hi Daniel, > > Please use only text format. :) > > >>From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of >>Daniel Kurtz >>Sent: Wednesday, April 30, 2014 1:57 PM >>To: Inki Dae >>Cc: David Airlie; dri-devel; Akshu Agrawal;

[Bug 75361] freeze in Mass Effect 3 (wine)

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

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

Sure (5250, 5420). I will wait for the same to update DT patches, if any. Regards, Rahul Sharma. On 30 April 2014 14:02, Tomasz Stanislawski wrote: > Hi Rahul, > I will prepare we v3 version. > Do you want me to add your patches for exynos5?50 to the patchset? > Regards, > Tomasz Stanislawski >

[RFC 0/2] drm/bridge: panel and chaining

On Wed, Apr 30, 2014 at 11:38 AM, Rob Clark wrote: > On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar wrote: >> >> On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA >> wrote: >>> >>> >>> >>> >>> >>> --- Original Message --- >>> >>> Sender : Sean Paul >>> >>> Date : Apr 30,

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

HZ/20)) > - DRM_DEBUG_KMS("vblank wait timed out.\n"); > -} > - > static void fimd_win_mode_set(struct exynos_drm_manager *mgr, > struct exynos_drm_overlay *overlay) > { > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/c1d69d45/attachment.html>

[Bug 75361] freeze in Mass Effect 3 (wine)

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

[Bug 75361] freeze in Mass Effect 3 (wine)

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/913b76b1/attachment.html>

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

if return 0; } -- 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/20140430/510b4a1f/attachment.sig>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

Hi Tomasz, I have tested your patches for exynos5250 and 5420. Works fine. Are you planning to post v3? If you want I can share hand with you for v3. Regards, Rahul Sharma On 9 April 2014 17:17, Andreas Oberritter wrote: > Hello Andrzej, > > On 09.04.2014 10:37, Andrzej Hajda wrote: >>>

[RFC 0/2] drm/bridge: panel and chaining

On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar wrote: > > On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA > wrote: >> >> >> >> >> >> --- Original Message --- >> >> Sender : Sean Paul >> >> Date : Apr 30, 2014 02:34 (GMT+05:30) >> >> Title : Re: [RFC 0/2] drm/bridge:

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

Hi Rahul, I will prepare we v3 version. Do you want me to add your patches for exynos5?50 to the patchset? Regards, Tomasz Stanislawski On 04/30/2014 08:37 AM, Rahul Sharma wrote: > Hi Tomasz, > > I have tested your patches for exynos5250 and 5420. Works fine. Are > you planning to post v3? If

[PATCH 2/4] drm/plane-helper: Add drm_primary_helper_check_update() (v2)

Pull the parameter checking from drm_primary_helper_update() out into its own function; drivers that provide their own setplane() implementations rather than using the helper may still want to share this parameter checking logic. A few of the checks here were also updated based on suggestions by

[PATCH 1/4] drm: Check CRTC compatibility in setplane

The DRM core setplane code should check that the plane is usable on the specified CRTC before calling into the driver. Prior to this patch, a plane's possible_crtcs field was purely informational for userspace and was never actually verified at the kernel level (aside from the primary plane

[RFC v3 PATCH v2 10/16] drm/exynos: dsi: add driver data to support Exynos5420

Hi Sachin, Thank you for comment. I'll fix. Thank you. Best regards YJ On 04/30/2014 12:26 AM, Sachin Kamat wrote: > On 27 April 2014 07:20, YoungJun Cho wrote: >> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different >> from the one in Exynos4 SoC. >> >> In case of Exynos5420

[RFC v3 PATCH 08/16] drm/exynos: fimd: support I80 interface

Hi Sachin, Thank you for comment. I'll fix. Thank you. Best regards YJ On 04/30/2014 12:35 AM, Sachin Kamat wrote: > Hi YoungJun, > > On 27 April 2014 07:20, YoungJun Cho wrote: >> To support MIPI DSI command mode interface, FIMD should do followings: >> - Sets LCD block configuration for I80

[PATCH] drm/radeon/dp: check for errors in dpcd reads

Check to make sure the transaction succeeded before using the register value. Fixes occasional link training problems. Noticed-by: Sergei Antonov Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 44 1 file changed, 25 insertions(+),

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: > Generic framework for tracking internal interfaces > == > > Summary > --- > > interface_tracker is a generic framework which allows to track appearance > and disappearance of

[git pull] drm fixes

Hi Linus, smattering of fixes, i915, exynos, tegra, msm, vmwgfx, bit of framebuffer reference counting fallout fixes, i915 GM45 regression fix, DVI regression fix, vmware info leak between processes fix. Inki, I've cherry-picked and signed off some of the stuff from the exynos fixes pull

[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)

https://bugs.freedesktop.org/show_bug.cgi?id=75211 --- Comment #11 from Christoph Haag --- Created attachment 98201 --> https://bugs.freedesktop.org/attachment.cgi?id=98201=edit dmesg with GPU lockup Yea, this is maybe going off topic, but I'm a bit tired, so here's the dmesg with gpu lockup.

[Bug 73511] clinfo mises Max clock frequency on r600

https://bugs.freedesktop.org/show_bug.cgi?id=73511 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---