[PATCH 6/6] platform: recognize GM20B

Allow the platform driver to recognize GM20B. Signed-off-by: Alexandre Courbot --- drm/nouveau/nouveau_platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index dcfbbfa..7a39d44 100644 --- a/drm/nouveau/nouveau_platform.c

[PATCH 5/6] device: recognize GM20B

Recognize GM20B and assign the right engines and subdevs. Signed-off-by: Alexandre Courbot --- drm/nouveau/nvkm/engine/device/gm100.c | 20 1 file changed, 20 insertions(+) diff --git a/drm/nouveau/nvkm/engine/device/gm100.c b/drm/nouveau/nvkm/engine/device/gm100.c index 7

[PATCH 4/6] gr: add GM20B support

Add support for GM20B's graphics engine, based on GK20A. Note that this code alone will not allow the engine to initialize on released devices which require PMU-assisted secure boot. Signed-off-by: Alexandre Courbot --- drm/nouveau/include/nvkm/engine/gr.h | 1 + drm/nouveau/nvkm/engine/gr/Kb

[PATCH 3/6] fifo: add GM20B fifo

GM20B has a 512-channels FIFO similar to GK104. Signed-off-by: Alexandre Courbot --- drm/nouveau/include/nvkm/engine/fifo.h | 1 + drm/nouveau/nvkm/engine/fifo/Kbuild| 1 + drm/nouveau/nvkm/engine/fifo/gk104.h | 4 drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +- drm/nouveau/nvkm/en

[PATCH 2/6] gr/gk20a: use same initialization sequence as nvgpu

GK20A's initialization was based on GK104, but differences exist in the way the initial context is built and the initialization process itself. This patch follows the same initialization sequence as nvgpu performs to avoid bad surprises. Since the register bundles initialization also differ consid

[PATCH 1/6] gr: support for NVIDIA-provided firmwares

NVIDIA will officially start providing signed firmwares through linux-firmware. Change the GR firmware lookup function to look them up in addition to the extracted firmwares. Signed-off-by: Alexandre Courbot --- drm/nouveau/nvkm/engine/gr/gf100.c | 66 +- 1 fi

[PATCH 0/6] Improve GK20A and introduce GM20B support

Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

On Fri, May 1, 2015 at 2:42 AM, Paul Bolle wrote: > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote: >> --- a/drivers/pwm/Kconfig >> +++ b/drivers/pwm/Kconfig > >> +config PWM_CRC >> + bool "Intel Crystalcove (CRC) PWM support" >> + depends on X86 && INTEL_SOC_PMIC >> + help >>

[pull] radeon drm-fixes-4.1

Hi Dave, just your MST fix and another one from Michel which is CC stable as well. Branch is based on drm-fixes, not sure if you still take stuff for 4.1 or if that will go into 4.2. I won't mind either way. Regards, Christian. The following changes since commit 25161084b1c1b0c29948f6f77266a35

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

Hi Shobhit, On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote: > On Fri, May 1, 2015 at 2:42 AM, Paul Bolle wrote: > > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote: > >> --- a/drivers/pwm/Kconfig > >> +++ b/drivers/pwm/Kconfig > > > >> +config PWM_CRC > >> + bool "Intel Crystal

[PATCH] drm/msm/dp: use flags argument of devm_gpiod_get to set direction

Hello Emil, On Thu, Jun 18, 2015 at 03:51:26PM +0100, Emil Velikov wrote: > > I had planned to send a second pull request for 4.2 with some > > additional hdcp patches that depend on scm changes coming in via > > arm-soc tree for 4.2.. if that is ok, I can include this patch with > > that second p

[Bug 90873] Kernel hang, TearFree On, Mate desktop environment

|--- |FIXED --- Comment #7 from Tom --- Resolved in kernel 4.1-rc8 -- 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/20150

[Bug 90873] Kernel hang, TearFree On, Mate desktop environment

ed this issue, thanks. -- 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/20150618/e82ce6be/attachment.html>

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

On 18 June 2015 at 17:39, Christian König wrote: > On 18.06.2015 06:29, Dave Airlie wrote: >> >> From: Dave Airlie >> >> If you do radeon.mst=1 on a gpu without mst hw, and then >> plug some mst hw it will oops instead of falling back. >> >> So check we have DCE5 at least before proceeding. >> >

[PATCH 2/2] drm/radeon: SDMA fix hibernation (CI GPU family).

From: Jérôme Glisse In order for hibernation to reliably work we need to properly turn off the SDMA block, sadly after numerous attemps i haven't not found proper sequence for clean and full shutdown. So simply reset both SDMA block, this makes hibernation works reliably on sea island GPU famil

[PATCH 1/2] drm/radeon: compute ring fix hibernation (CI GPU family).

From: Jérôme Glisse In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which corresp

[Intel-gfx] [PATCH] drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()

On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote: > On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote: > > On 10/06/15 15:58, Chris Wilson wrote: > > > As the clflush operates on cache lines, and we can flush any byte > > > address, in order to flush all bytes given in the range we is

[PATCH 5/5] drm/omap: fix omap_gem_put_paddr() error handling

Hi Tomi, Thank you for the patch. On Thursday 18 June 2015 13:10:39 Tomi Valkeinen wrote: > If tiler_unpin() call in omap_gem_put_paddr() fails, > omap_gem_put_paddr() will immediately stop processing and return an > error. > > This patch remoes that error checking, and also removes > omap_gem_p

[PATCH 4/5] drm/omap: fix omap_framebuffer_unpin() error handling

Hi Tomi, Thank you for the patch. On Thursday 18 June 2015 13:10:38 Tomi Valkeinen wrote: > omap_framebuffer_unpin() check the return value of omap_gem_put_paddr() > and return immediately if omap_gem_put_paddr() fails. > > This patch removes the check for the return value, and also removes the

[PATCH 2/2] drm/exynos: use KMS version of DRM vblanks functions

From: Gustavo Padovan Get rid of legacy DRM vblank function that are less clear to use. The new only basically requires only the crtc as paramenters. It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a consequence. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exyn

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

From: Gustavo Padovan When mode's vrefresh is zero we should ask DRM core to calculate vrefresh for us so we can get the correct value instead of relying on fixed value defined in a macro. But if vrefresh is still zero we should fail the update. Suggested-by: Daniel Stone Signed-off-by: Gustavo

[PATCH 2/5] drm/omap: check that plane is inside crtc

Hi Tomi, Thank you for the patch. On Thursday 18 June 2015 13:10:36 Tomi Valkeinen wrote: > DRM allows planes to be partially off-screen, but DSS hardware does not. > This patch adds the necessary check to reject plane configs if the plane > is not fully inside the crtc. > > Signed-off-by: Tomi

[Intel-gfx] [PATCH] drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()

On Thu, Jun 18, 2015 at 06:31:18PM +0300, Imre Deak wrote: > On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote: > > On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote: > > > On 10/06/15 15:58, Chris Wilson wrote: > > > > As the clflush operates on cache lines, and we can flush any byte

[PATCH] nvidia/noveau: Fix color mask

sion s; @@ - ~c >> s + (unsigned int)~c >> s @sh expression@ identifier val; expression shift; @@ val >> shift @@ expression e; identifier sh.val; @@ - #define val ~e + #define val e -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150618/aa8c5de0/attachment.sig>

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

Hi Tomi, Thank you for the patch. On Thursday 18 June 2015 13:10:35 Tomi Valkeinen wrote: > On a platform with no TILER (e.g. omap3, am43xx), when the user wants to > allocate buffer with flag OMAP_BO_SCANOUT, the buffer needs to be > allocated with dma_alloc_writecombine. For some reason the dri

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

On Thu, Jun 18, 2015 at 04:55:45PM +0100, Russell King - ARM Linux wrote: > On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote: > > Perhaps you can try > > Something like that needs to be done, but let's get rid of the mdvi > thing in struct

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote: > Russell, > > On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux > wrote: > >> OK, so clearly my patch won't work against mainline. I guess it's a > >> good thing that I pointed out that it was only tested locally (would > >>

[PATCH v2 04/10] drm: Add Gamma correction structure

On 14 June 2015 at 10:02, Sharma, Shashank wrote: > Hi, Emil Velikov > > The reason behind a zero sized array is that we want to use the same variable > for various color correction possible across various driver . > Due to current blob implementation, it doesn’t look very efficient to have >

[PATCH 6/6] drm/rockchip: vop: default enable win2/3 area0 bit

Win2/3 support 4 area display, but now havn't found a suitable way to use it, and it enable by win gate and area gate, so default enable area0 gate, so that its behaviour just like a win. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c |6 ++ 1 file changed, 6 ins

[PATCH 5/6] drm/rockchip: vop: switch cursor plane to window 3

Window 1 support scale and yuv format, it's waste use it for a cursor, use window 3 is enough. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/driv

[PATCH] drm/msm/dp: use flags argument of devm_gpiod_get to set direction

On 16 June 2015 at 02:00, Rob Clark wrote: > On Mon, Jun 15, 2015 at 5:00 PM, Uwe Kleine-König > wrote: >> On Tue, Jun 09, 2015 at 11:38:45AM +0200, Uwe Kleine-König wrote: >>> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) >>> which appeared in v3.17-rc1, the gpiod_get

[PATCH 4/6] drm/rockchip: vop: support plane scale

Win_full support 1/8 to 8 scale down/up engine, support all format scale. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 390 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 96 +++ 2 files changed, 483 insertions(+), 3 deletions(-) di

[PATCH 3/6] drm/rockchip: vop: fix yuv plane support

vop support yuv with NV12, NV16 and NV24, only 2 plane yuv. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 ++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/roc

[PATCH 2/6] drm/rockchip: vop: optimize virtual stride calculate

vir_stride need number words of the virtual width, and fb->pitches save bytes_per_pixel, so just div 4 switch to stride. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchi

[PATCH 1/6] drm/rockchip: import dma_buf to gem

We want to display a buffer allocated by other driver, need import the buffer to gem. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 45 +-- drivers/gpu/drm/rockchip/rockchip_drm_gem.h |

[PATCH 0/6] drm/rockchip: support yuv overlay and plane scale

This series patches are used for yuv image overlay display. Rockchip vop support NV11, NV16, NV24 yuv format, and can scale the image scale 1/8 to 8. Mark Yao (6): drm/rockchip: import dma_buf to gem drm/rockchip: vop: optimize virtual stride calculate drm/rockchip: vop: fix yuv plane suppo

[PATCH 9/9] [media] mm: Move get_vaddr_frames() behind a config option

On Wed 10-06-15 09:37:20, Josh Triplett wrote: > On Wed, Jun 10, 2015 at 06:20:52AM -0300, Mauro Carvalho Chehab wrote: > > From: Jan Kara > > > > get_vaddr_frames() is used by relatively rare drivers so hide it and the > > related functions behind a config option that is selected only by > > dri

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

On 18.06.2015 10:31, Dave Airlie wrote: > On 18 June 2015 at 17:39, Christian König wrote: >> On 18.06.2015 06:29, Dave Airlie wrote: >>> From: Dave Airlie >>> >>> If you do radeon.mst=1 on a gpu without mst hw, and then >>> plug some mst hw it will oops instead of falling back. >>> >>> So check

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

From: Dave Airlie If you do radeon.mst=1 on a gpu without mst hw, and then plug some mst hw it will oops instead of falling back. So check we have DCE5 at least before proceeding. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 + 1 file changed, 5 insertions(+)

[PATCH] GPU: ipu: fix lockup caused by pending chained interrupts

Even with the oops fixed by a previous patch, the system still fails to kexec, due to a stuck chained interrupt locking the system. We must disable the child interrupts prior to setting up the irq chip to ensure we don't get stuck here. Signed-off-by: Russell King --- Maybe this is all that's re

[PATCH v2 00/32] acpi-video: Rewrite backlight interface selection logic

On Wed, Jun 17, 2015 at 11:36:13AM +0200, Rafael J. Wysocki wrote: > On Wed, Jun 17, 2015 at 5:39 AM, Darren Hart wrote: > > On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote: > >> On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote: > >> > Hi All, > >> > > >> > Here is v2 of my

[PATCH v10 00/17] drm/exynos: atomic modesetting support

On 2015년 06월 17일 23:33, Gustavo Padovan wrote: > Hi Inki, > > 2015-06-17 Inki Dae : > >> Hi Gustavo, >> >> On 2015년 06월 17일 05:35, Gustavo Padovan wrote: >>> HI Inki, >>> >>> 2015-06-15 Inki Dae : >>> Hi Gustavo, On 2015년 06월 02일 00:04, Gustavo Padovan wrote:

[PATCH 5/5] drm/omap: fix omap_gem_put_paddr() error handling

If tiler_unpin() call in omap_gem_put_paddr() fails, omap_gem_put_paddr() will immediately stop processing and return an error. This patch remoes that error checking, and also removes omap_gem_put_paddr()'s return value, because: * The caller of omap_gem_put_paddr() can do nothing if an error

[PATCH 4/5] drm/omap: fix omap_framebuffer_unpin() error handling

omap_framebuffer_unpin() check the return value of omap_gem_put_paddr() and return immediately if omap_gem_put_paddr() fails. This patch removes the check for the return value, and also removes the return value of omap_framebuffer_unpin(), because: * Nothing checks the return value of omap_frame

[PATCH 3/5] drm/omap: increase DMM transaction timeout

The DMM driver uses a timeout of 1 ms to wait for DMM transaction to finish. While DMM should always finish the operation within that time, the timeout is rather strict. Small misbehavior of the system (e.g. an irq taking too long) could trigger the timeout. As the DMM is a critical piece of code

[PATCH 2/5] drm/omap: check that plane is inside crtc

DRM allows planes to be partially off-screen, but DSS hardware does not. This patch adds the necessary check to reject plane configs if the plane is not fully inside the crtc. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++ 1 file changed,

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

On a platform with no TILER (e.g. omap3, am43xx), when the user wants to allocate buffer with flag OMAP_BO_SCANOUT, the buffer needs to be allocated with dma_alloc_writecombine. For some reason the driver does not return an error if that alloc fails, instead it continues without backing memory. Thi

[PATCH 0/5] drm/omap: various small fixes

Hi, Here are a few small fixes for omapdrm. These are based on the recent omapdrm atomic modesetting series, which is now in drm-next. Tomi Tomi Valkeinen (5): drm/omap: return error if dma_alloc_writecombine fails drm/omap: check that plane is inside crtc drm/omap: increase DMM transacti

[PATCH 3/3] drm/exynos: pass the correct pipe number

From: Gustavo Padovan Instead of giving -1 to as arg to drm_send_vblank_event() pass the correct pipe number to it. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm

[PATCH 2/3] drm/exynos: vidi: always handle vblank on planes updates

From: Gustavo Padovan We need to call drm_handle_vblank() after each successful plane update to update vblank counter and send the necessary events. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a

[PATCH 1/3] drm/exynos: add atomic asynchronous commit

From: Gustavo Padovan The atomic modesetting interfaces supports async commits that should be implemented by the drivers. If drm core requests an async commit exynos_atomic_commit() will schedule a work task to run the update later. It also waits to an update to finishes to schedule a new one. S

[PATCH 0/3] drm/exynos: improve vidi refresh rate + async commit

From: Gustavo Padovan Hi, The first patch in this series add support to async page flips, but it doesn't improve the refresh rate when using vidi+fimd. The second patch fixes an issue on vidi that solves the refresh rate issue when only vidi is used. For the case where vidi + fimd is used it im

[Nouveau] [PATCH 1/6] gr: support for NVIDIA-provided firmwares

Why did you change request_firmware to request_firmware_direct? On Thu, Jun 18, 2015 at 10:47 AM, Alexandre Courbot wrote: > NVIDIA will officially start providing signed firmwares through > linux-firmware. Change the GR firmware lookup function to look them up > in addition to the extracted firm

[PATCH 1/6] drm/rockchip: import dma_buf to gem

On Thu, Jun 18, 2015 at 03:49:25PM +0800, Mark Yao wrote: > We want to display a buffer allocated by other driver, need import > the buffer to gem. > > Signed-off-by: Mark Yao > --- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 45 > ++

[PATCH] drm/atomic: Extract needs_modeset function

We use the same check already in the atomic core, so might as well make this official. And it's also reused in e.g. i915. Motivated by Maarten's idea to extract a connector_changed state out of mode_changed. Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c

[PATCH 2/2] drm/msm/dsi: Add support for msm8x94

DSI controller on msm8x94 is version 1.3, which requires different power supplies and works with 20nm DSI PHY. This change is to add the basic support for this version. Signed-off-by: Hai Li --- Documentation/devicetree/bindings/drm/msm/dsi.txt | 7 ++ drivers/gpu/drm/msm/dsi/dsi.h

[PATCH 1/2] drm/msm/dsi: Update generated headers with 20nm PHY support

Signed-off-by: Hai Li --- drivers/gpu/drm/msm/dsi/dsi.xml.h | 192 +++--- 1 file changed, 181 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h b/drivers/gpu/drm/msm/dsi/dsi.xml.h index 9791ea0..9bb63a9 100644 --- a/drivers/gpu/drm/msm

[PATCH 0/2] drm/msm/dsi: msm8x94 configuration and support

Hai Li (2): drm/msm/dsi: Update generated headers with 20nm PHY support drm/msm/dsi: Add support for msm8x94 Documentation/devicetree/bindings/drm/msm/dsi.txt | 7 + drivers/gpu/drm/msm/dsi/dsi.h | 1 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 192 +

[PATCH] rnndb/dsi: Add register descriptions for 20nm PHY

This change introduces new domains of PHY and PHY_REGULATOR for 20nm DSI PHY registers. Signed-off-by: Hai Li --- rnndb/dsi/dsi.xml | 91 +++ 1 file changed, 91 insertions(+) diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml index d19bea9..0f

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

On Wed, Jun 17, 2015 at 07:52:14PM -0700, Doug Anderson wrote: > Russell, > > On Wed, Jun 17, 2015 at 4:30 PM, Russell King - ARM Linux > wrote: > > On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote: > >> If you plug in a DVI monitor to your HDMI port, you need to filter out > >> cloc

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

On 18.06.2015 06:29, Dave Airlie wrote: > From: Dave Airlie > > If you do radeon.mst=1 on a gpu without mst hw, and then > plug some mst hw it will oops instead of falling back. > > So check we have DCE5 at least before proceeding. > > Signed-off-by: Dave Airlie Reviewed-by: Christian König B

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

Russell, On Thu, Jun 18, 2015 at 9:09 AM, Russell King - ARM Linux wrote: > So, what I'd like to see is a patch series which starts with the change > below, and builds on that, with explainations why each change is needed. > This is important, as this is shared IP, and we need to make sure that >

inverted brightness for HP notebook

On Wed, 17 Jun 2015, Max Manheimer wrote: > Hi, > > Jani Nikula linux.intel.com> writes: > >> On Thu, 13 Nov 2014, olivier.fambon free.fr wrote: > >>> $ lspci | grep VGA >>> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev >>> 0e) > >>> $ sudo lspci -v -s 00:02 >>> 00:0

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

Russell, On Thu, Jun 18, 2015 at 8:55 AM, Russell King - ARM Linux wrote: >> Perhaps you can try > > Something like that needs to be done, but let's get rid of the mdvi > thing in struct hdmi_vmode - it doesn't belong there, it isn't part > of the cur

[PULL] drm-intel-next-fixes

Hi Dave, i915 fixes for drm-next/v4.2. BR, Jani. The following changes since commit bf546f8158e2df2656494a475e6235634121c87c: drm/i915/skl: Fix DMC API version in firmware file name (2015-06-05 12:08:01 +0300) are available in the git repository at: git://anongit.freedesktop.org/drm-int

[PULL] drm-intel-fixes

Hi Dave, final i915 fixes for v4.1. BR, Jani. The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27: Linux 4.1-rc8 (2015-06-14 15:51:10 -1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-06-18 for you to

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

Russell, On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux wrote: >> OK, so clearly my patch won't work against mainline. I guess it's a >> good thing that I pointed out that it was only tested locally (would >> have been better to test against mainline, but I don't think that's so >> ea

[PATCH] Fixes: 9697dffb098d ("drm: Turn off Legacy Context Functions")

On Wed, Jun 17, 2015 at 02:03:47PM -0600, Eddie Kovsky wrote: > Commit 9697dffb098d ("drm: Turn off Legacy Context Functions") > added checks for legacy features to several functions in the > drm driver. It is now possible for the void functions changed by > this commit to return an int error cod

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

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

[RFC PATCH] Trim 1204 bytes from gm204_grctx_generate_405b60 stack frame

This function keeps causing the kernel build to whine at me about its 1200 byte stack frame. (TPC_MAC = 8 * GPC_MAX = 8 * 32 = 256) The following generates the same nv_wr32() operations in the same order as the original, but without the 256-word dist[] array. (I'm not sure if 4-bit fields inside

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote: > If you plug in a DVI monitor to your HDMI port, you need to filter out > clocks > 165MHz. That's because 165MHz is the maximum clock rate that > we can run single-link DVI at. > > If you want to run high resolutions to DVI, you'd ne