[PATCH] drm/cma: Use the %zu specifier for printing size_t

From: Fabio Estevam Building for arm64 causes the following warnings: drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create': drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format '%d' expects argument of type 'int', but argument 3 has type

[PATCH] drm/mm: Support 4 GiB and larger ranges

On Tue, Jan 27, 2015 at 09:31:26AM +0100, Thomas Hellstrom wrote: > On 01/27/2015 09:15 AM, Thierry Reding wrote: > > Are you referring to the 4 GiB - 1 comment? The point I was trying to > > make is not that the granularity of the IOVA space needs to be 1 byte > > but rather that using an

[PATCH 2/2] drm/exynos: remove to use unnecessary MODULE_xxx macro

The exynos_drm_dmabuf.c file doesn't include any module feature and it isn't built to module. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_DMABUF config

The exynos drm driver has DRIVER_PRIME capability, then it's reasonable to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will prevent that user selects the option unnecessarily. Signed-off-by: Joonyoung Shim --- This patch can be conflicted below link patch of Marek to remove

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

20 seconds of playing the video, but slightly later than with plain 3.19.0-rc6. -- 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 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

[PATCH 2/2] drm: bridge/sti_dvo: Adapt to bridge API change

Compare to Dave's patch this one doesn't take care of driver unbind but that is a general issue I have to address in STI driver. I would like to fix all unbind issues (hdmi, dvo, hda) in the same way but it isn't link to this topic. so you could my ack on this patch, up to me to fix unbind

[PATCH] drm: bridge/dw_hdmi: Fix return error path

Hi Fabio, Am Dienstag, den 27.01.2015, 10:54 -0200 schrieb Fabio Estevam: > If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that > will disable the clocks that were previously enabled. > > Signed-off-by: Fabio Estevam > --- > drivers/gpu/drm/bridge/dw_hdmi.c | 2 +- >

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in their I2C over AUX implementation. They work fine with Windows, but fail with Linux. It turns out that they cannot keep an I2C transaction open unless the previous read was 16 bytes; shorter reads can only be followed by a

[PATCH] drm/dp: Use large transactions for I2C over AUX

On Mon, Jan 26, 2015 at 04:39:29PM +, Simon Farnsworth wrote: > On Monday 26 January 2015 18:11:01 Ville Syrjälä wrote: > > On Mon, Jan 26, 2015 at 03:47:13PM +, Simon Farnsworth wrote: > > > On Monday 26 January 2015 17:33:35 Ville Syrjälä wrote: > > > > On Mon, Jan 26, 2015 at

[RFC v3 4/4] drm/i915: Enable DSI panel enable/disable based on PMIC

This allows for proper PPS during enable/disable of BYT-T platforms where these signals are routed through PMIC. Needs DRM_PANEL to be selected by default as well v2: Adapt to panel find function name change in drm_panel Signed-off-by: Shobhit Kumar --- drivers/gpu/drm/i915/Kconfig

[RFC v3 3/4] drm/i915: Add new panel driver based on crystal cove pmic

This driver provides support for the "crystal_cove_panel" cell device. On BYT-T pmic has to be used to enable/disable panel. v2: Addressed Jani's comments - Moved inside i915 - Correct licensing - Remove unused stuff - Do not initialize prepare/unprepare as they are not needed as

[RFC v3 2/4] mfd: Add a new cell device for panel controlled by crystal cove pmic

On BYT-T configuration, panel enable/disable signals are routed through PMIC. Add a cell device for the same. Signed-off-by: Shobhit Kumar --- drivers/mfd/intel_soc_pmic_crc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/intel_soc_pmic_crc.c

[RFC v3 1/4] drm: Add support to find drm_panel by name

For scenarios where OF is not available, we can use panel identification by name. Signed-off-by: Shobhit Kumar --- drivers/gpu/drm/drm_panel.c | 18 ++ include/drm/drm_panel.h | 3 +++ 2 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/drm_panel.c

[RFC v3 0/4] Crystal Cove PMIC based Panel and Backlight Control

Hi All Please find modifed set of patches using regmap interface to accedd the PMIC registers. These patches implement a drm_panel as a platform driver for the mfd_cell device declared in intel_soc_pmic_core.c. DRM is extended to provide a find panel by name in absence of OF. Backlight

[Bug 88408] Black screen in Nuclear Dawn

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

[Bug 88408] Black screen in Nuclear Dawn

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

[PATCH 2/6] drm/exynos: track vblank events on a per crtc basis

On Tue, Jan 27, 2015 at 12:59:15PM +, Daniel Stone wrote: > Hi, > > On 23 January 2015 at 12:42, Gustavo Padovan wrote: > > void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe) > > { > > struct exynos_drm_private *dev_priv = dev->dev_private; > > - struct

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

Add some helpers to share the constraints of devices while attaching to the dmabuf buffer. At each attach, the constraints are calculated based on the following: - max_segment_size, max_segment_count, segment_boundary_mask from device_dma_parameters. In case the attaching device's constraints

[RFCv3 1/2] device: add dma_params->max_segment_count

From: Rob Clark For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to

[PATCH 2/6] drm/exynos: track vblank events on a per crtc basis

Hi, On 23 January 2015 at 12:42, Gustavo Padovan wrote: > void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe) > { > struct exynos_drm_private *dev_priv = dev->dev_private; > - struct drm_pending_vblank_event *e, *t; > struct drm_crtc *drm_crtc =

[RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

Hi Russell! On 21 January 2015 at 23:01, Russell King - ARM Linux wrote: > On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote: >> +static int calc_constraints(struct device *dev, >> + struct dma_buf_constraints *calc_cons) >> +{ >> + struct

LLVM / Clang git for libclc: optimized build or debug?

On 27.01.2015 04:20, Dieter Nützel wrote: > make[1]: Leaving directory '/opt/llvm/bindings' > llvm[0]: * Completed Debug+Asserts Build > llvm[0]: * Note: Debug build can be 10 times slower than an > llvm[0]: * optimized build. Use make ENABLE_OPTIMIZED=1 to > llvm[0]: * make an

[PULL] topic/atomic-core

Hi Dave, Mostly just small fixes and polish all over, plus the dpms-on-atomic stuff. Cheers, Daniel The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470: Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 10:44:41 +1000) are available in the git

[PATCH] drm/msm/mdp5: only flush on a CRTC ->atomic_flush()

MDP5 hardware has some limitation and requires to avoid flushing registers more than once between two Vblanks. This change removes all FLUSH operations (except for HW cursor) beside the one coming from a CRTC's ->atomic_flush(). This avoid this type of behavior (eg: CRTC + 1 plane overlay):

[Bug 86043] Optimus issue with libdrm 2.4.58

achment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150127/ceacf669/attachment.html>

[PATCH 2/2] drm/exynos: remove to use unnecessary MODULE_xxx macro

2015-01-27 Joonyoung Shim : > The exynos_drm_dmabuf.c file doesn't include any module feature and it > isn't built to module. > > Signed-off-by: Joonyoung Shim > --- > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 > 1 file changed, 4 deletions(-) Reviewed-by: Gustavo Padovan

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_DMABUF config

2015-01-27 Joonyoung Shim : > The exynos drm driver has DRIVER_PRIME capability, then it's reasonable > to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will > prevent that user selects the option unnecessarily. > > Signed-off-by: Joonyoung Shim > --- > This patch can be

[PATCH] drm: bridge/dw_hdmi: Fix return error path

If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that will disable the clocks that were previously enabled. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/bridge/dw_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3] drm/panel: add s6e3ha2 AMOLED panel driver

From: Donghwa Lee This patch adds MIPI-DSI based S6E3HA2 panel driver. This panel has 1440x2560 resolution in 5.7-inch physical panel. Signed-off-by: Donghwa Lee Signed-off-by: Hyungwon Hwang Cc: Inki Dae Cc: Sangbae Lee --- Changes for v2: - Fix errata in

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

tachments/20150127/2eab80f1/attachment.html>

[Intel-gfx] [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment

On Tue, Jan 27, 2015 at 09:56:49AM +0200, Jani Nikula wrote: > On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > > with the code and the rest of the comment for this routine. This patch > > fixes this typo in comment. > > >

[Bug 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau

|--- |FIXED -- 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/20150127/c178287a/attachment.html>

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

Hi Dave, The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470: Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 10:44:41 +1000) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-3.20-rc1 for

[PATCH 2/2] drm: bridge/sti_dvo: Adapt to bridge API change

Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of drm flow") introduced some drm/bridge API modifications. Make the necessary changes so that we can avoid the build breakage: drivers/gpu/drm/sti/sti_dvo.c: In function 'sti_dvo_brigde_destroy':

[PATCH 1/2] drm: bridge/dw_hdmi: Adapt to bridge API change

Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of drm flow") introduced some drm/bridge API modifications. Make the necessary changes so that we can avoid the build breakage: drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_bridge_destroy':

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

dri-devel/attachments/20150127/a98fc5e6/attachment.html>

[PATCH 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

Dear Emil, On Mon, 26 Jan 2015 19:05:51 + Emil Velikov wrote: > On 26 January 2015 at 01:42, Hyungwon Hwang > wrote: > > Dear Tobias, > > > > Thanks for fixing it. > > > > Signed-off-by: Hyungwon Hwang > > > Hi Hyungwon Hwang > > I'm a bit confused about the use of s-o-b here. I've

[git pull] drm fixes

On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie wrote: > > are available in the git repository at: > > git://people.freedesktop.org/~airlied/linux drm-fixes No they aren't, actually, because you've screwed up your repository. It looks like you were using an alternates that has gone away:

[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints

Hi Kukjin, On Fri, Jan 23, 2015 at 12:31 PM, Kukjin Kim wrote: > Ajay Kumar wrote: >> >> Define videoports and use endpoints to describe the connection between >> the encoder, bridge and the panel, instead of using phandles. >> >> Signed-off-by: Ajay Kumar >> Acked-by: Inki Dae >> Tested-by:

[PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment

On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > with the code and the rest of the comment for this routine. This patch > fixes this typo in comment. > > Signed-off-by: Kumar Amit Mehta Reviewed-by: Jani Nikula > --- >

[PATCH] [rfc] drm/sti: fixup for bridge interface

From: Dave Airlie So sti doesn't build because the bridge interfaces changes didn't catch up to its new DVO driver. Now I might just carry this patch, but I might just push the bridge pull into a side-pull until someone resolves it. So this might not be the right solution

[PATCH] drm/mm: Support 4 GiB and larger ranges

On 01/27/2015 09:15 AM, Thierry Reding wrote: > On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote: >> On 01/26/2015 11:51 PM, Dave Airlie wrote: >>> On 23 January 2015 at 18:05, Thierry Reding wrote: From: Thierry Reding The current implementation is limited by the

[PATCH] drm/mm: Support 4 GiB and larger ranges

On Tue, Jan 27, 2015 at 08:51:12AM +1000, Dave Airlie wrote: > On 23 January 2015 at 18:05, Thierry Reding > wrote: > > From: Thierry Reding > > > > The current implementation is limited by the number of addresses that > > fit into an unsigned long. This causes problems on 32-bit Tegra where >

[PATCH] drm/bridge: dw_hdmi: adapt to updated bridge API

On 26 January 2015 at 23:12, Heiko Stübner wrote: > Commits 8eb17f05bc18 ("drm/bridge: do not pass drm_bridge_funcs to > drm_bridge_init") and fbc4572e9c48 ("drm/bridge: make bridge registration > independent of drm flow") changed the bridge API without taking into account > the also newly

[PATCH] drm/mm: Support 4 GiB and larger ranges

her that using an unsigned long for a size on a 32-bit machine will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB for Tegra. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150127/e6f76b7d/attachment.sig>

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

https://bugzilla.kernel.org/show_bug.cgi?id=91861 Christian König changed: What|Removed |Added CC||deathsimple at vodafone.de ---

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

On 23 January 2015 at 23:56, Thierry Reding wrote: > Hi Dave, > > The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470: > > Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 > 10:44:41 +1000) > > are available in the git repository at: > >

[PATCH] drm/mm: Support 4 GiB and larger ranges

On 23 January 2015 at 18:05, Thierry Reding wrote: > From: Thierry Reding > > The current implementation is limited by the number of addresses that > fit into an unsigned long. This causes problems on 32-bit Tegra where > unsigned long is 32-bit but drm_mm is used to manage an IOVA space of > 4

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

https://bugzilla.kernel.org/show_bug.cgi?id=91861 --- Comment #4 from Mike S. --- I haven't yet tested the patch to cap ref_div to 7, but here are the values reported with drm.debug=0xE, in case they are useful: 1. Kernel 3.14 (working): 14851, fb: 145.2 ref: 2, post: 7 2. Kernel 3.18 (not

[PATCH] drm/mm: Support 4 GiB and larger ranges

On 01/26/2015 11:51 PM, Dave Airlie wrote: > On 23 January 2015 at 18:05, Thierry Reding > wrote: >> From: Thierry Reding >> >> The current implementation is limited by the number of addresses that >> fit into an unsigned long. This causes problems on 32-bit Tegra where >> unsigned long is

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

ubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150127/d0712502/attachment.html>

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

e (drm)? -- 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/20150127/732639fd/attachment.html>

[Bug 78951] gl_PrimitiveID is zero if no geometry shader is present

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

[PATCH 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

On 27 January 2015 at 01:05, Hyungwon Hwang wrote: > Dear Emil, > > On Mon, 26 Jan 2015 19:05:51 + > Emil Velikov wrote: > >> On 26 January 2015 at 01:42, Hyungwon Hwang >> wrote: >> > Dear Tobias, >> > >> > Thanks for fixing it. >> > >> > Signed-off-by: Hyungwon Hwang >> > >> Hi Hyungwon

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

gpu locked up after a few seconds of playing the same video. -- 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/20150127/ba9a38c3/atta

[git pull] drm fixes

Hi Linus, This feels larger than I'd like but its for three reasons. a) amdkfd finalising the API more, this is a new feature introduced last merge window, and I'd prefer to make the tweaks to the API before it first gets into a stable release. b) radeon regression required splitting an