[PATCH] Reenabling SS on Cayman

It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that Cayman is stable since VDDCI fix. Spread spectrum was not the culprit. Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/rv770_dpm.c | 6 -- 1 file changed, 6 deletions(-) diff --git

Reenable Spread Spectrum on Cayman

Since vddci was the real culprit behind Cayman's dpm problem and now that it is fixed, I've been playing around with kernel 3.16-RC4 and spread spectrum reenabled. So far, no problem and I think it's safe to reenable it for good. Alex, if you share my impression, could you push the following

[PATCH v3 4/4] ARM: tegra: roth: add display DT node

Tegra DSI support has been fixed to support continuous clock behavior that the panel used on SHIELD requires, so finally add its device tree node since it is functional. Signed-off-by: Alexandre Courbot --- arch/arm/boot/dts/tegra114-roth.dts | 22 +++--- 1 file changed, 19

[PATCH v3 3/4] drm/tegra: dsi - Handle non-continuous clock flag

Handle the MIPI_DSI_CLOCK_NONCONTINUOUS flag and only set TX-only clock behavior when this flag is present to allow panels requiring continuous clock mode to operate with this driver. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/tegra/dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH v3 2/4] drm/panel: Set non-continuous clock flag on supporting panels

The LG LD070WX3-SL01 and Panasonic VVX10F004B00 are DSI support non-continuous clock mode. Set the MIPI_DSI_CLOCK_NON_CONTINUOUS to their definition so host drivers become aware of this capability. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/panel/panel-simple.c | 5 +++-- 1 file

[PATCH v3 1/4] drm/dsi: Flag for non-continuous clock behavior

As per section 5.6.1 of the DSI specification, all DSI transmitters must support continuous clock behavior on the clock lane, while non-continuous mode support is only optional. Add a flag that allows devices to indicate that they support non-continuous clock mode so host drivers can adapt their

[PATCH v3 0/4] drm/dsi/tegra: continuous clock support

This small series adds a flag that allows to specify that a DSI device supports non-continuous clock mode, and uses it in the Tegra DSI driver to only enable this mode on panels that support it. Until now, the Tegra DSI driver unconditionally enabled non-continuous mode, which prevented

[Bug 81066] New: [r600g] Second Life causes GPU to lock up sometimes with DRI_PRIME

Offload crtcs: 2 outputs: 4 associated providers: 2 name:radeon -- 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/

[PATCH v2 0/9] Updated fence patch series

On 8 July 2014 20:09, Greg KH wrote: > On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: >> On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: >> > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: >> > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH >> > > wrote: >> >

[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game

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

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Tue, 8 Jul 2014 11:41:32 -0400 Rob Clark wrote: > On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON > wrote: > > On Tue, 8 Jul 2014 08:49:41 -0400 > > Rob Clark wrote: > > > >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON > >> wrote: > >> > Hello Rob, > >> > > >> > On Mon, 7 Jul 2014

[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140708/649a80c5/attachment.html>

[Bug 78661] GPU sometimes locks up after boot and/or resume

https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #10 from Nikolaus Waxweiler --- Alright, both patches active. Will test and report back. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game

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

[PATCH] drm/radeon: fix typo in ci_stop_dpm()

Need to use the RREG32_SMC() accessor since the register is an smc indirect index. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/ci_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c

[PATCH v4 6/6] drm/nouveau: allocate GPFIFOs and fences coherently

Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to allow them to be safely accessed by the kernel without being synced on non-coherent architectures. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nv84_fence.c | 4

[PATCH v4 5/6] drm/nouveau: implement explicitly coherent BOs

Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which means that we want the allocated BO to be perfectly coherent between the CPU and GPU. This is useful on non-coherent architectures for which we do not want to manually sync some rarely-accessed buffers: typically, fences and

[PATCH v4 4/6] drm/nouveau: synchronize BOs when required

On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly when BO control changes between CPU and GPU. This patch adds buffer synchronization functions which invokes the correct API (PCI or DMA) to ensure synchronization is effective.

[PATCH v4 3/6] drm/nouveau: introduce nv_device_is_cpu_coherent()

Add a function allowing us to know whether a device is CPU-coherent, i.e. accesses performed by the CPU on GPU-mapped buffers will be immediately visible on the GPU side and vice-versa. For now, a device is considered to be coherent if it uses the PCI bus on a non-ARM architecture.

[PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices

page_to_phys() is not the correct way to obtain the DMA address of a buffer on a non-PCI system. Use the DMA API functions for this, which are portable and will allow us to use other DMA API functions for buffer synchronization. Signed-off-by: Alexandre Courbot ---

[PATCH v4 1/6] drm/ttm: expose CPU address of DMA-allocated pages

Pages allocated using the DMA API have a coherent memory mapping. Make this mapping visible to drivers so they can decide to use it instead of creating their own redundant one. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 ++ drivers/gpu/drm/ttm/ttm_tt.c

[PATCH v4 0/6] drm: nouveau: memory coherency on ARM

Another revision of this patchset critical for GK20A to operate. Previous attempts were exclusively using either TTM's regular page allocator or the DMA API one. Both have their advantages and drawbacks: the page allocator is fast but requires explicit synchronization on non-coherent

[PATCH 2/2] drm/udl: Implement page_flip ioctl

On 8 July 2014 17:15, David Herrmann wrote: > Hi > > On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin > wrote: >> This is a very crude page_flip implementation for UDL. There are ways >> to make it better (make it asynchronous, make it do actual vsynced >> flips...) but that's for another

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Tue, Jul 08, 2014 at 07:08:20PM +0200, Boris BREZILLON wrote: > On Tue, 8 Jul 2014 11:41:32 -0400 > Rob Clark wrote: > > > On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON > > wrote: > > > On Tue, 8 Jul 2014 08:49:41 -0400 > > > Rob Clark wrote: > > > > > >> On Tue, Jul 8, 2014 at 3:23 AM,

[PATCH 1/2] drm/nouveau/bar: add noncached ioremap property

Ping Ben, how do these two patches look like? On Fri, Jun 27, 2014 at 7:28 PM, Alexandre Courbot wrote: > Some BARs (like GK20A's) do not support being ioremapped write-combined. > Add a boolean property to the BAR structure and handle that case in the > Nouveau BO implementation. > >

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Tue, 8 Jul 2014 08:49:41 -0400 Rob Clark wrote: > On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON > wrote: > > Hello Rob, > > > > On Mon, 7 Jul 2014 23:45:54 -0400 > > Rob Clark wrote: > > > >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON > >> wrote: > >> > The Atmel HLCDC (HLCD

[PATCH] drm: reduce default drm vblank off delay to 50ms

On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote: > On Wed, 2 Jul 2014 13:35:19 -0700 > St?phane Marchesin wrote: > > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote: > > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes > > virtuousgeek.org> wrote: > > >> People keep whining

[PATCH v2 0/9] Updated fence patch series

On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH > > wrote: > > >> Android can expose fences to userspace. It's possible to make the new > > >> fence > > >> mechanism expose the

[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()

On Tue, Jul 08, 2014 at 01:40:44PM +0200, Thomas Hellstrom wrote: > On 07/08/2014 01:24 PM, Daniel Vetter wrote: > > On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote: > >> removed drm_open_hash from drm_ht_remove_item() as the parameter is > >> not used within the function. > >> > >>

[PATCH] drm/plane-helper: Use proper plane init function

On Mon, Jun 30, 2014 at 03:37:51PM -0700, Matt Roper wrote: > drm_plane_init() (the legacy plane initialization function) takes a bool > as its final parameter; originally this indicated whether a plane was > 'private' to the driver (before the DRM core understood non-overlay > planes), now it

[PATCH] exynos: Put a stop to the userptr heresy.

On Wed, Jul 02, 2014 at 11:25:19AM -0400, Jerome Glisse wrote: > Anyway as this is upstream i guess you can keep it. This is just an horrible > API that allow to circumvant any limit set by memcg for page locking and all. > But anyway GPU driver never played in the same ballpark as other driver.

[PATCH] i915: purify user ptr ioctl through the fire of truth.

On Mon, Jun 30, 2014 at 02:23:32PM -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Heresy should not be tolerated, any ioctl that rely on pure luck > should die. Violating memory pining kernel policy and all the > reasonable expection kernel have about user of mmu_notifier api > is

[RFC] drm/exynos: abort commit when framebuffer is removed from plane

Hi Inki, What do you think about the following fix? I need your inputs for this. Regards, Rahul Sharma On 19 June 2014 20:43, Rahul Sharma wrote: > This situation arises when userspace remove the frambuffer object > and call setmode ioctl. > > drm_mode_rmfb --> drm_plane_force_disable -->

[Bug 78661] GPU sometimes locks up after boot and/or resume

https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #9 from Alex Deucher --- This might be related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=76998 Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=102392 -- You are receiving this mail because:

mixer_check_mode drops Exynos5 display modes

Hi Sean, While looking at the following commit I noticed something: commit f041b257a8997c8472a1013e9f252c3e2a1d879e Author: Sean Paul Date: Thu Jan 30 16:19:15 2014 -0500 drm/exynos: Remove exynos_drm_hdmi shim This commit changes how mixer_check_mode() is used. It used to just exclude

[Bug 78661] GPU sometimes locks up after boot and/or resume

https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #8 from Nikolaus Waxweiler --- Speaking of hangs, every once in a while I get lockups on boot where the screen stays corrupted or black and even the reset button doesn't help and I have to long-press the power button. Theres no log

[PATCH v2 0/9] Updated fence patch series

On Wed, Jul 02, 2014 at 11:12:32AM +0200, Maarten Lankhorst wrote: > op 02-07-14 07:37, Greg KH schreef: > > On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote: > >> So after some more hacking I've moved dma-buf to its own subdirectory, > >> drivers/dma-buf and applied the fence

[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()

On 07/08/2014 01:24 PM, Daniel Vetter wrote: > On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote: >> removed drm_open_hash from drm_ht_remove_item() as the parameter is >> not used within the function. >> >> Signed-off-by: Masaru Nomura >> --- >> Please review this patch carefully.

[PATCH] drm: Fix function names in kerneldoc

On Thu, Jun 26, 2014 at 09:37:20PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The drm_property_create_enum(), drm_property_create_bitmask() and > drm_property_create_range() contain the wrong name in the kerneldoc > comment. This is probably simply a copy/paste mistake. > >

[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()

On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote: > removed drm_open_hash from drm_ht_remove_item() as the parameter is > not used within the function. > > Signed-off-by: Masaru Nomura > --- > Please review this patch carefully. The reason the parameter is passed > might be some

[PATCH 06/22] i810: Use pci_zalloc_consistent

On Mon, Jun 23, 2014 at 06:41:34AM -0700, Joe Perches wrote: > Remove the now unnecessary memset too. > > Signed-off-by: Joe Perches Since I seem to be the last idiot to have touched i810.ko: Acked-by: Daniel Vetter > --- > drivers/gpu/drm/i810/i810_dma.c | 5 ++--- > 1 file changed, 2

[Bug 81045] New: [r600] Unreal Engine 4 demo crashed kernel

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

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

On Sat, Jun 28, 2014 at 06:51:15AM -0400, Rob Clark wrote: > On Fri, Jun 27, 2014 at 6:08 PM, Darren Etheridge > wrote: > > Guido, > > > > > > On 06/17/2014 09:17 AM, Guido Mart?nez wrote: > >> > >> The tilcdc driver could be compiled as a module, but was severely broken > >> and could not be

[RFCv2] drm/msm: DT support for 8960/8064

Now that we (almost) have enough dependencies in place (MMCC, RPM, etc), add necessary DT support so that we can use drm/msm on upstream kernel. Signed-off-by: Rob Clark --- I thought I sent this already, but looks like I've forgot. I've updated the names for the GPIO properties (and, via

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON wrote: > On Tue, 8 Jul 2014 08:49:41 -0400 > Rob Clark wrote: > >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON >> wrote: >> > Hello Rob, >> > >> > On Mon, 7 Jul 2014 23:45:54 -0400 >> > Rob Clark wrote: >> > >> >> On Mon, Jul 7, 2014 at

[PATCH v3] ASoC: tda998x: add a codec to the HDMI transmitter

This patch adds a CODEC function to the NXP TDA998x HDMI transmitter. The CODEC handles both I2S and S/PDIF input and does dynamic input switch in the TDA998x I2C driver on start/stop audio streaming. Signed-off-by: Jean-Francois Moine --- v3: fix bad rate (Andrew Jackson) v2: check double

[alsa-devel] [PATCH v2] ASoC: tda998x: add a codec to the HDMI transmitter

On Tue, 08 Jul 2014 10:17:58 +0100 Andrew Jackson wrote: > > + static const u32 hdmi_rates[] = { > > + 32000, 44100, 48000, 88200, 9600, 176400, 192000 > > + }; > > + > > Shouldn't this be 96000, not 9600? Assuming that the table is ordered in > terms of increasing

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

On 3 July 2014 06:38, Ezequiel Garc?a wrote: > On 02 Jul 02:08 PM, Dave Airlie wrote: >> On 2 July 2014 12:31, Darren Etheridge wrote: >> > On 07/01/2014 06:39 PM, Guido Mart?nez wrote: >> >> >> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: >> >>> >> >>> [snip] >> >>> >>

[PATCH v2 0/9] Updated fence patch series

On Tue, Jul 08, 2014 at 08:22:11PM +0530, Sumit Semwal wrote: > On 8 July 2014 20:09, Greg KH wrote: > > On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: > >> On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > >> > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter

[v3 10/13] drm/i915: Add 180 degree primary plane rotation support

From: Sonika Jindal Primary planes support 180 degree rotation. Expose the feature through rotation drm property. v2: Calculating linear/tiled offsets based on pipe source width and height. Added 180 degree rotation support in ironlake_update_plane. v3: Checking if

[v3 09/13] drm/i915: Add rotation property for sprites

From: Ville Syrj?l? Sprite planes support 180 degree rotation. The lower layers are now in place, so hook in the standard rotation property to expose the feature to the users. v2: Moving rotation_property to drm_plane Cc: dri-devel at lists.freedesktop.org

[v3 08/13] drm/i915: Make intel_plane_restore() return an error

From: Ville Syrj?l? Propagate the error from intel_update_plane() up through intel_plane_restore() to the caller. This will be used for rollback purposes when setting properties fails. Cc: dri-devel at lists.freedesktop.org Signed-off-by: Ville Syrj?l?

[v3 07/13] drm/i915: Add 180 degree sprite rotation support

From: Ville Syrj?l? The sprite planes (in fact all display planes starting from gen4) support 180 degree rotation. Add the relevant low level bits to the sprite code to make use of that feature. The upper layers are not yet plugged in. v2: HSW handles the rotated

[v3 06/13] drm: Add drm_rotation_simplify()

From: Ville Syrj?l? drm_rotation_simplify() can be used to eliminate unsupported rotation flags. It will check if any unsupported flags are present, and if so it will modify the rotation to an alternate form by adding 180 degrees to rotation angle, and flipping the

[v3 05/13] drm: Add drm_rect rotation functions

From: Ville Syrj?l? Add some helper functions to move drm_rects between different rotated coordinate spaces. One function does the forward transform and another does the inverse. Cc: dri-devel at lists.freedesktop.org Signed-off-by: Ville Syrj?l? Reviewed-by:

[v3 04/13] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()

From: Ville Syrj?l? Use the new drm_mode_create_rotation_property() in omapdrm. Cc: dri-devel at lists.freedesktop.org Signed-off-by: Ville Syrj?l? Reviewed-by: Rob Clark Reviewed-by: Imre Deak Reviewed-by: Sagar Kamble ---

[v3 02/13] drm: Add support_bits parameter to drm_property_create_bitmask()

From: Ville Syrj?l? Make drm_property_create_bitmask() a bit more generic by allowing the caller to specify which bits are in fact supported. This allows multiple callers to use the same enum list, but still create different versions of the same property with

[alsa-devel] [PATCH v2] ASoC: tda998x: add a codec to the HDMI transmitter

On 07/04/14 08:17, Jean-Francois Moine wrote: > This patch adds a CODEC function to the NXP TDA998x HDMI transmitter. > > The CODEC handles both I2S and S/PDIF input and does dynamic input > switch in the TDA998x I2C driver on start/stop audio streaming. > > Signed-off-by: Jean-Francois Moine >

[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

On Mon, Jul 07, 2014 at 10:53:16PM -0400, Ed Tomlinson wrote: > Hi Daniel, > > The patch below also works. You can use my Tested By for it. Thanks a lot for testing, patch submitted and should get forwarded asap. > > Thanks > Ed Tomlinson > > PS. I _really_ need to get a serial console

[PATCH v5 14/14] ARM: dts: exynos5420: add dsi node

This patch adds common part of dsi node. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi

[PATCH v5 13/14] ARM: dts: exynos5420: add mipi-phy node

This patch adds mipi-phy node for MIPI DSI device. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi

[PATCH v5 12/14] ARM: dts: exynos5: add system register property

This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5.dtsi

[PATCH v5 11/14] ARM: dts: exynos4: add system register property

This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi

[PATCH v5 10/14] drm/panel: add S6E3FA0 driver

This patch adds MIPI DSI command mode based S6E3FA0 AMOLED LCD Panel driver. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/panel/Kconfig | 7 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 569

[PATCH v5 09/14] ARM: dts: s6e3fa0: add DT bindings

This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources and display timings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++ 1 file changed, 46

[PATCH v5 08/14] drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs

The offset of register DSIM_PLLTMR_REG in Exynos5410 / 5420 / 5440 SoCs is different from the one in Exynos4 SoCs. In case of Exynos5410 / 5420 / 5440 SoCs, there is no frequency band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead. So this patch adds driver

[PATCH v5 07/14] ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings

This patch adds relevant to exynos5410 compatible for exynos5410 / 5420 / 5440 SoCs support. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- Documentation/devicetree/bindings/video/exynos_dsim.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v5 06/14] drm/exynos: fimd: support LCD I80 interface

To support MIPI command mode based I80 interface panel, FIMD should do followings: - Sets LCD I80 interface timings configuration. - Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration. - Sets LCD block configuration for I80 interface. - Sets ideal(pixel) clock is 2 times faster

[PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface

To support LCD I80 interface, the DSI host calls this function to notify the panel tearing effect synchronization signal to the CRTC device manager to trigger to transfer video image. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park ---

[PATCH v5 04/14] drm/exynos: add TE handler to support LCD I80 interface

To support LCD I80 interface, the panel should generate Tearing Effect synchronization signal between MCU and FB to display video images. And the display controller should trigger to transfer video image at this signal. So the panel receives the TE IRQ, then calls these handler chains to notify it

[PATCH v5 03/14] ARM: dts: samsung-fimd: add LCD I80 interface specific properties

In case of using MIPI DSI based I80 interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt | 28 ++ 1 file

[PATCH v5 02/14] drm/exynos: use wait_event_timeout() for safety usage

There could be the case that the page flip operation isn't finished correctly with some abnormal condition such as panel reset. So this patch replaces wait_event() with wait_event_timeout() to avoid waiting for page flip completion infinitely. And clears exynos_crtc->pending_flip in

[PATCH v5 01/14] drm/exynos: dsi: move the EoT packets configuration point

This configuration could be used in MIPI DSI command mode also. And adds user manual description for display configuration. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +++-- 1 file

[PATCH v5 00/14] drm/exynos: support LCD I80 interface display

Hi, This series adds LCD I80 interface display support for Exynos DRM driver. The FIMD(display controller) specification describes it as "LCD I80 interface" and the DSI specification describes it as "Command mode interface". This is based on exynos-drm-next branch. The previous patches, RFC:

[PATCH] drm: reduce default drm vblank off delay to 50ms

On Tue, 8 Jul 2014 15:56:04 +0200 Daniel Vetter wrote: > On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote: > > On Wed, 2 Jul 2014 13:35:19 -0700 > > St?phane Marchesin wrote: > > > > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter > > > wrote: > > > > On Tue, Oct 30, 2012 at

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

Hello Rob, On Mon, 7 Jul 2014 23:45:54 -0400 Rob Clark wrote: > On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON > wrote: > > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. > > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display > > controller device.

[PATCH 2/2] drm/udl: Implement page_flip ioctl

Hi On Tue, Jul 8, 2014 at 9:17 AM, Dave Airlie wrote: > On 8 July 2014 17:15, David Herrmann wrote: >> Hi >> >> On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin >> wrote: >>> This is a very crude page_flip implementation for UDL. There are ways >>> to make it better (make it asynchronous,

[PATCH 2/2] drm/udl: Implement page_flip ioctl

Hi On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin wrote: > This is a very crude page_flip implementation for UDL. There are ways > to make it better (make it asynchronous, make it do actual vsynced > flips...) but that's for another patch. > > Signed-off-by: St?phane Marchesin > --- >

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON wrote: > Hello Rob, > > On Mon, 7 Jul 2014 23:45:54 -0400 > Rob Clark wrote: > >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON >> wrote: >> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. >> > at91sam9n12, at91sam9x5

[PATCH 2/2] drm/udl: Implement page_flip ioctl

On Wed, Jul 02, 2014 at 03:13:43PM -0700, St?phane Marchesin wrote: > This is a very crude page_flip implementation for UDL. There are ways > to make it better (make it asynchronous, make it do actual vsynced > flips...) but that's for another patch. > > Signed-off-by: St?phane Marchesin > --- >

[PATCH v2 0/9] Updated fence patch series

On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: > On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: > > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH > > > wrote: > > > >> Android can expose fences to userspace.

linux-next: Tree for Jun 19 (drm/i915)

On Monday, July 07, 2014 11:49:22 PM Rafael J. Wysocki wrote: > On Monday, July 07, 2014 10:06:59 PM Daniel Vetter wrote: > > On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote: > > > On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote: > > > > On Wed, Jun 25, 2014 at

[Bug 80868] Support screen scaling modes for external monitors

c_timestamping_constants] *ERROR* crtc 14: Can't calculate constants, dotclock = 0! The last line seems important. -- 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/20140708/7f143ca6/attachment.html>

[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled

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

[PATCH] drm: Remove command line guard for render nodes (v2)

Hi On Tue, Jul 8, 2014 at 12:28 AM, Alex Deucher wrote: > On Mon, Jul 7, 2014 at 6:20 PM, David Herrmann > wrote: >> Hi >> >> On Tue, Jul 8, 2014 at 12:10 AM, Alex Deucher >> wrote: >>> Render nodes are ready to leave the experimental state so >>> drop the kernel command line parameter which

[PATCH] drm: Remove command line guard for render nodes (v2)

Hi On Tue, Jul 8, 2014 at 12:10 AM, Alex Deucher wrote: > Render nodes are ready to leave the experimental state so > drop the kernel command line parameter which was hiding them > by default. I swore we had already enabled these by default, > that appears to not be the case. > > v2: remove

[PATCH] drm: Remove command line guard for render nodes

Hi On Mon, Jul 7, 2014 at 11:25 PM, Alex Deucher wrote: > Render nodes are ready to leave the experimental state so > drop the kernel command line parameter which was hiding them > by default. I swore we had already enabled these by default, > that appears to not be the case. > > Signed-off-by:

[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled

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

linux-next: Tree for Jun 19 (drm/i915)

On Monday, July 07, 2014 10:06:59 PM Daniel Vetter wrote: > On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote: > > On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote: > > > On Wed, Jun 25, 2014 at 01:01:36AM +0200, Rafael J. Wysocki wrote: > > > > On Tuesday, June 24, 2014

[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support

On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON wrote: > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display > controller device. > > This display controller supports at least one primary plane and might >

[Bug 80868] Support screen scaling modes for external monitors

https://bugs.freedesktop.org/show_bug.cgi?id=80868 --- Comment #8 from Kamil P?ral --- Yes, you seem to be right. I put the patch into the spec file, but it probably didn't apply. I'm trying to find out why. -- You are receiving this mail because: You are the assignee for the bug.