[git pull] drm fixes

Hi Linus, One urgent fix for an oops under console lock in some drivers, one uapi fix, and one revert to fix rockchip regression. I've got the sti driver pull request that I'll send out in a minute, don't think it'll have any issues. Dave. The following changes since commit

[git pull] drm next (sti driver only)

Hi Linus, The sti driver had a requirement on some patches in Greg's tree, they are in, so I see no problems just merging this one now. But if it's too late I don't mind either. Dave. The following changes since commit a18e2fa5e670a1b84e66522b221c42875b02028a: Merge tag 'arm64-fixes' of

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

On 10.11.2015 22:23, Marek Szyprowski wrote: > This patch adds device node for Rotator device to Exynos 4210 and 4x12 > device tree files. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos4.dtsi| 10 +- > arch/arm/boot/dts/exynos4210.dtsi | 8 >

[PATCH 02/25] ARM: dts: exynos542x: add rotator node

On 10.11.2015 22:23, Marek Szyprowski wrote: > This patch adds device node for Rotator device to Exynos 542x device > tree file. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos5420.dtsi | 19 +++ > 1 file changed, 19 insertions(+) > Looks good, thanks!

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

On 10.11.2015 22:23, Marek Szyprowski wrote: > This patch adds device node for Rotator device to Exynos 4210 and 4x12 > device tree files. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos4.dtsi| 10 +- > arch/arm/boot/dts/exynos4210.dtsi | 8 >

[Bug 76490] Hang during boot when DPM is on (R9 270X)

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/43ed911b/attachment.html>

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

Hello, On 2015-11-13 03:23, Krzysztof Kozlowski wrote: > On 10.11.2015 22:23, Marek Szyprowski wrote: >> This patch adds device node for Rotator device to Exynos 4210 and 4x12 >> device tree files. >> >> Signed-off-by: Marek Szyprowski >> --- >> arch/arm/boot/dts/exynos4.dtsi| 10

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

Hello, On 2015-11-13 03:29, Krzysztof Kozlowski wrote: > On 10.11.2015 22:23, Marek Szyprowski wrote: >> This patch adds device node for Rotator device to Exynos 4210 and 4x12 >> device tree files. >> >> Signed-off-by: Marek Szyprowski >> --- >> arch/arm/boot/dts/exynos4.dtsi| 10

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

On 13.11.2015 17:31, Marek Szyprowski wrote: > Hello, > > On 2015-11-13 03:23, Krzysztof Kozlowski wrote: >> On 10.11.2015 22:23, Marek Szyprowski wrote: >>> This patch adds device node for Rotator device to Exynos 4210 and 4x12 >>> device tree files. >>> >>> Signed-off-by: Marek Szyprowski >>>

[PATCH 01/25] ARM: dts: exynos4: add rotator nodes

On 13.11.2015 17:32, Marek Szyprowski wrote: > Hello, > > On 2015-11-13 03:29, Krzysztof Kozlowski wrote: >> On 10.11.2015 22:23, Marek Szyprowski wrote: >>> This patch adds device node for Rotator device to Exynos 4210 and 4x12 >>> device tree files. >>> >>> Signed-off-by: Marek Szyprowski >>>

__i915_spin_request() sucks

On Thu, Nov 12, 2015 at 03:52:02PM -0700, Jens Axboe wrote: > On 11/12/2015 03:19 PM, Chris Wilson wrote: > >>>So today, I figured I'd try just killing that spin. If it fails, we'll > >>>punt to normal completions, so easy change. And wow, MASSIVE difference. > >>>I can now scroll in chrome and

[PATCH 06/25] drm/exynos: fix to calculate offset of each plane for ipp fimc

Hello, On 2015-11-12 16:20, Tobias Jakobi wrote: > Hello, > > Marek Szyprowski wrote: >> From: Seung-Woo Kim >> >> NV12 and YUV420 formats are need to calculate offset of each plane >> for ipp fimc in a gem buffer. Without proper offset, only Y plane >> can be processed, so result shows green

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

On Thu, Nov 12, 2015 at 05:49:28PM -0800, Alex Goins wrote: > If a buffer is backed by dmabuf, wait on its reservation object's fences > before flipping. > > Signed-off-by: Alex Goins > --- > drivers/gpu/drm/i915/intel_display.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff

[PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

On Thu, Nov 12, 2015 at 09:30:31PM -0600, Rob Herring wrote: > On Thu, Nov 12, 2015 at 4:42 AM, Liviu Dudau wrote: > > On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote: > >> On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote: > >> > Cc: Rob Herring > >>

[Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

On Thu, 12 Nov 2015, ville.syrjala at linux.intel.com wrote: > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 24c5434..ea00a69 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -677,6 +677,9 @@ int drm_crtc_init_with_planes(struct

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

Hi, On 13 November 2015 at 10:08, Chris Wilson wrote: > On Thu, Nov 12, 2015 at 05:49:28PM -0800, Alex Goins wrote: >> static const uint32_t i8xx_primary_formats[] = { >> @@ -11170,10 +11172,19 @@ static void ilk_do_mmio_flip(struct intel_crtc >> *intel_crtc) >> static void

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

On Fri, Nov 13, 2015 at 10:38:07AM +, Daniel Stone wrote: > Hi, > > On 13 November 2015 at 10:08, Chris Wilson > wrote: > > On Thu, Nov 12, 2015 at 05:49:28PM -0800, Alex Goins wrote: > >> static const uint32_t i8xx_primary_formats[] = { > >> @@ -11170,10 +11172,19 @@ static void

[Bug 92936] Tonga powerplay isssues

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/08d0d574/attachment.html>

[Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

On Fri, Nov 13, 2015 at 12:18:24PM +0200, Jani Nikula wrote: > On Thu, 12 Nov 2015, ville.syrjala at linux.intel.com wrote: > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index 24c5434..ea00a69 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++

[Bug 91729] Graphic Distortions on Knights of the Old Republic with wine

dri-devel/attachments/20151113/bd55731d/attachment.html>

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/0338aa75/attachment.sig>

[PATCH 11/25] drm/exynos: introduce exynos_drm_plane_state structure

Hi Marek, 2015-11-10 Marek Szyprowski : > This patch introduces exynos_drm_plane_state structure, which subclasses > drm_plane_state and holds precalculated data suitable for configuring > Exynos hardware. > > Signed-off-by: Marek Szyprowski > --- >

[PATCH 12/25] drm/exynos: mixer: use crtc->state->adjusted_mode instead of crtc->mode

Hi Marek, 2015-11-10 Marek Szyprowski : > This patch replaces usage of crtc->mode with crtc->state->adjusted_mode > like it is already done in common plane code. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2

[PATCH 13/25] drm/exynos: mixer: enable video overlay plane only when VP is available

Hi Marek, 2015-11-10 Marek Szyprowski : > Video overlay plane should be registered only when suitable hardware > sub-block (Video Processor) is available. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++ > 1 file changed, 3 insertions(+) Good catch.

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: > On 13/11/15 12:29, H. Nikolaus Schaller wrote: > > Include VENC in the set of drivers where it is assimed that the cable > > is always connected. Like DPI, DSI, DBI and SDI do. > > > > Otherwise, the VENC will return cable status

[PATCHv5 0/3] Add initial support for slimport anx78xx

Hi all, This is the fifth version of patch set. Any comments are welcome. See the changelog below for details. The following series add initial support for the Slimport ANX7814 transmitter, a ultra-low power Full-HD (1080p60) transmitter designed for portable device. The driver was originally

[PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

Analogix Semiconductor develops analog and mixed-signal devices for digital media and communications interconnect applications. Signed-off-by: Enric Balletbo i Serra Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff

[PATCHv5 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter designed for portable devices. You can add support to your board with current binding. Example: anx7814: anx7814 at 38 { compatible = "analogix,anx7814"; reg = <0x38>;

[PATCHv5 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

At the moment it only supports ANX7814. The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter designed for portable devices. This driver adds initial support and supports HDMI to DP pass-through mode. Signed-off-by: Enric Balletbo i Serra --- drivers/gpu/drm/bridge/Kconfig

[PATCH 14/25] drm/exynos: introduce exynos_drm_plane_config structure

Hi Marek, 2015-11-10 Marek Szyprowski : > This patch adds common structure for keeping plane configuration and > capabilities data. This patch is inspired by similar code developed by > Tobias Jakobi. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c |

[PATCH 15/25] drm/exynos: add generic check for plane state

Hi Marek, 2015-11-10 Marek Szyprowski : > This patch adds generic check for plane state: pixel format and display > area dimensions, so drivers can always assume that they get valid plane > state to set. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_drv.h |

[PATCH 16/25] drm/exynos: mixer: use ratio precalculated in exynos_state

Hi Marek, 2015-11-10 Marek Szyprowski : > Common plane code already calculates and checks for supported scalling > modes, so additional code in mixer driver can be now removed. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 33

[PATCH 1/2] virtio-gpu: use no-merge for fill-modes

Avoid the sticky preferred mode bit by using the no-merge version of the function (this allows gnome-shell to resize to lower resolutions than the default resolution) Signed-off-by: Marc-André Lureau --- drivers/gpu/drm/virtio/virtgpu_display.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/2] virtio-gpu: update cursor after scanout

It seems appropriate for paravirtual hardware to reset cursor when the resolution changes, that way the cursor is removed if the machine is forcefully rebooted for ex. That's what the QXL/Spice server does. In order for virtio-gpu to work will with the Spice server, set the cursor again after

[PATCH v2 2/4] ARM: dts: exynos4: fix power domain for sysmmu-rotator device

Rotator device and it's SYSMMU belongs to different power domains on various Exynos4 SoC revisions: LCD0 for 4210 and TOP for 4x12. This patch fixes this by moving power-domains property to exynos4210.dtsi. TOP power domain is always enabled and it is not represented in DTS. Signed-off-by: Marek

[PATCH v2 1/4] ARM: dts: exynos4: add rotator nodes

This patch adds device node for Rotator device to Exynos 4210 and 4x12 device tree files. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4.dtsi| 9 + arch/arm/boot/dts/exynos4210.dtsi | 4 arch/arm/boot/dts/exynos4x12.dtsi | 4 3 files changed, 17

[PATCH v2 3/4] ARM: dts: exynos5250: add rotator node

This patch adds device node for Rotator device to Exynos 5250 device tree file. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos5250.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index

[PATCH v2 4/4] ARM: dts: exynos542x: add rotator node

This patch adds device node for Rotator device and it's SYSMMU to Exynos 542x device tree file. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos5420.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi

[PATCH] drm/atomic: only run atomic_check() if crtc is active

From: Gustavo Padovan Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace direct cross-driver call with drm mode) and while this regression was caused by a change in the exynos driver it makes sense to add the check on atomic core to benefit other

[PATCH] drm/atomic: only run atomic_check() if crtc is active

On Fri, Nov 13, 2015 at 11:45:58AM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace > direct cross-driver call with drm mode) and while this regression was > caused by a change in the exynos driver it makes sense to add the

[PATCHv5 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

On Fri, Nov 13, 2015 at 01:01:03PM +0100, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > You can add support to your board with current binding. > > Example: > > anx7814: anx7814 at 38 { >

[PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

On Fri, Nov 13, 2015 at 01:01:02PM +0100, Enric Balletbo i Serra wrote: > Analogix Semiconductor develops analog and mixed-signal devices for digital > media and communications interconnect applications. > > Signed-off-by: Enric Balletbo i Serra > Acked-by: Rob Herring > --- >

[PATCH v2 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

On Mon, Oct 26, 2015 at 12:59:56PM +0100, Andrzej Hajda wrote: > DECON-TV(Display and Enhancement Controller for TV) is a variation > of DECON IP. Its main purpose is to produce video stream for HDMI IP. > > Signed-off-by: Andrzej Hajda Acked-by: Rob Herring > --- > Hi Krzysztof, > > I have

[PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

Hi Rob, 2015-11-13 15:38 GMT+01:00 Rob Herring : > On Fri, Nov 13, 2015 at 01:01:02PM +0100, Enric Balletbo i Serra wrote: >> Analogix Semiconductor develops analog and mixed-signal devices for digital >> media and communications interconnect applications. >> >> Signed-off-by: Enric Balletbo i

[PATCH RFC v2 2/2] drm/atomic: Disable planes on blanked CRTC and enable on unblank

Disable planes if they are on to be blanked CRTC and enable them when the CRTC is turned back on by DMPS. This is desirable on HW that loses its context on blanking. When planes are enabled and disabled with the associated CRTCs, there is no need to restore the plane context in runtime_resume

[PATCH RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank

Since first RFC version: - Added "drm/atomic: Track drm_plane's active state"-patch We would need something like this to get rid off OMAPDSS somewhat messy runtime_resume code. How does this look, could this generic solution be refined to be acceptable for mainline, or should we start looking a

[PATCH RFC v2 1/2] drm/atomic: Track drm_plane's active state

Track drm_plane's active state with a new boolean in struct drm_plane_state. The patch replaces drm_atomic_plane_disabling() with drm_atomic_helper_update_plane_state(). In addition to all the same things the drm_atomic_plane_disabling() used to do the new function updates the active-flag and

[Bug 92936] Tonga powerplay isssues

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/20151113/4f397a55/attachment-0001.html>

[PATCH v3 0/9] drm: Give crtcs and planes actual names (v3)

From: Ville Syrjälä Another attempt to give crtcs and planes human friendly names. This time I pulled out coccinelle and added a 'name' parameter to all the crtc and plane init functions. Third time's the charm, eh? Previous series at:

[PATCH v2 2/9] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä v2: kstrdup() the name passed by the caller (Jani) Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56 +++--

[PATCH v2 3/9] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä v2: kstrdup() the name passed by the caller (Jani) Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 12 ++-- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- drivers/gpu/drm/drm_crtc.c | 11 ++-

[PATCH 4/9] drm/i915: Use crtc->name in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 55 drivers/gpu/drm/i915/intel_fbdev.c | 5 ++-- 2 files changed, 33 insertions(+), 27 deletions(-) diff --git

[PATCH 5/9] drm/i915: Use plane->name in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 38 +--- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[PATCH v3 6/9] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

From: Ville Syrjälä v2: Fix intel_crtc leak on failure to allocate the name Use a local 'name' variable to make things easier v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani) Signed-off-by: Ville Syrjälä ---

[PATCH v2 7/9] drm/i915: Fix plane init failure paths

From: Ville Syrjälä Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. v2: Rebased due to drm_universal_plane_init() 'name' parameter

[PATCH 8/9] drm/i915: Don't leak primary/cursor planes on crtc init failure

From: Ville Syrjälä Call intel_plane_destroy() instead of drm_plane_cleanup() so that we also free the plane struct itself when bailing out of the crtc init. And make intel_plane_destroy() NULL tolerant to avoid having to check for it in the caller.

[PATCH v3 9/9] drm/i915: Give meaningful names to all the planes

From: Ville Syrjälä Let's name our planes in a way that makes sense wrt. the spec: - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. - g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc. - pre-g4x -> "plane A", "cursor B" etc. v2: Rebase on

[PATCH 1/9] drm: Pass 'name' to crtc and plane init functions

From: Ville Syrjälä Allow the driver to pass a crtc and plane names to the crtc and plane init functions. Will be used later to populate the crtc and plane name that gets printed in debug messages. Done with coccinelle for the most part. It choked on

[PATCH] drm/atomic: only run atomic_check() if crtc is active

Hi Ville, 2015-11-13 Ville Syrjälä : > On Fri, Nov 13, 2015 at 11:45:58AM -0200, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace > > direct cross-driver call with drm mode) and while this regression was > > caused by a

[Bug 92229] SOMA have serious graphical errors

Profile) Mesa 11.1.0-devel (git-006fcc0 2015-10-17 trusty-oibaf-ppa) -- 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/20151113/8a149

[PATCH] drm/amdgpu: update Fiji's tiling mode table

From: Flora Cui Change-Id: I925c15015390113f7e27746ec5751eaa6a92c2a7 Signed-off-by: Flora Cui Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 292 +- 1 file changed, 291 insertions(+), 1 deletion(-) diff --git

[Bug 92229] SOMA have serious graphical errors

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/85aaf0af/attachment.html>

[PATCH 0/9] uapi: drm: fixes for userspace compilation

On Thu, 12 Nov 2015 19:34:18 + Emil Velikov wrote: > Hi Gabriel, > > Interestingly enough we had a person (gaby) asking about this over at > #dri-devel, and I forwarded him to the work of Mikko Rapeli. You don't > happen to be that person do you ? Yes, that's me. > On 12 November 2015 at

[PATCH 0/9] uapi: drm: fixes for userspace compilation

On Fri, 13 Nov 2015 20:24:30 +0100 Gabriel Laskar wrote: > On Thu, 12 Nov 2015 19:34:18 + > Emil Velikov wrote: > > > That aside I'm a strong supporter of this type of work and I'm curious > > why Dave hasn't picked up the existing series ? Last time I've asked > > he did not have any

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

Sorry; needless to say I'm not super familiar with the Intel driver. ilk_do_mmio_flip() uses crtc->primary->fb to fetch the gem object: struct intel_framebuffer *intel_fb = to_intel_framebuffer(intel_crtc->base.primary->fb); struct drm_i915_gem_object *obj =

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

Okay, implemented these suggestions. Will send out v4 patch set once the crtc->primary->fb thing is cleared up. -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, November 13, 2015 2:08 AM To: Alexander Goins Cc: dri-devel at lists.freedesktop.org;

[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/2eb54117/attachment.html>

[Bug 92936] Tonga powerplay isssues

ce highest pcie dpm state failed! -- 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/20151113/a80bed02/attachment.html>

[PATCH 0/9] uapi: drm: fixes for userspace compilation

On 13 November 2015 at 19:31, Gabriel Laskar wrote: > On Fri, 13 Nov 2015 20:24:30 +0100 > Gabriel Laskar wrote: > >> On Thu, 12 Nov 2015 19:34:18 + >> Emil Velikov wrote: >> >> > That aside I'm a strong supporter of this type of work and I'm curious >> > why Dave hasn't picked up the

[PATCH 0/9] uapi: drm: fixes for userspace compilation

On Fri, 13 Nov 2015 20:38:51 + Emil Velikov wrote: > On 13 November 2015 at 19:31, Gabriel Laskar wrote: > > On Fri, 13 Nov 2015 20:24:30 +0100 > > Gabriel Laskar wrote: > > > > Sorry for the noise, I had just saw the first version. > > > Heh I was wondering what's happening. I guess I

atomic explicit fencing vs android

Ok, this has been something on my TODO list to write up for a little while now.. but better late than never ;-) At LPC Daniel Vetter and myself were talking to Greg Hackmann and came to realize a bit of an impedance mismatch between how android display stack expects to use fences, and what Daniel

[PATCH 0/9] uapi: drm: fixes for userspace compilation

On 13 November 2015 at 21:36, Gabriel Laskar wrote: > On Fri, 13 Nov 2015 20:38:51 + > Emil Velikov wrote: > >> On 13 November 2015 at 19:31, Gabriel Laskar wrote: >> > On Fri, 13 Nov 2015 20:24:30 +0100 >> > Gabriel Laskar wrote: >> > >> > Sorry for the noise, I had just saw the first

__i915_spin_request() sucks

On Fri, Nov 13, 2015 at 09:22:52AM -0700, Jens Axboe wrote: > On 11/13/2015 09:13 AM, Mike Galbraith wrote: > >On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote: > >>Previous patch was obvious pre-coffee crap, this should work for using > >>ktime to spin max 1usec. > > > >1us seems a tad low. I

[Bug 92229] SOMA have serious graphical errors

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

atomic explicit fencing vs android

s before signalling it, you're stuck with a deadlocked display pipeline waiting on a fence that can never fire. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/a8156a73/attachment.html>

[PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

ct, so the common document in bridge is not very good, I should be in display/connector/, but I don't know what else could I collect for that common document, would like to share more on this point - Yakir > >> I thought if we put this a property to generic property, then we must need >> to define it in normal device node, not sure whether it is right :) > Sorry, I don't follow. > > Rob > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/b48d5dd2/attachment-0001.html>

[PATCH 05/19] clk: sunxi: add DRAM gates

On Mon, Nov 9, 2015 at 12:18 PM, Chen-Yu Tsai wrote: > On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard > wrote: >> The Allwinner SoCs have a gate controller to gate the access to the DRAM >> clock to the some devices that need to access the DRAM directly (mostly >> display / image related IPs).

[PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

Otherwise check_timings fails and we get a "has no modes" message from xrandr. This fix makes the venc assume PAL and NTSC timings that match the timings synthetized by copy_timings_drm_to_omap() from omapdrm mode settings so that check_timings() succeeds. Tested on: BeagleBoard XM, GTA04 and

[PATCH 0/2] Fix omap VENC (PAL/NTSC TV out) operation with omapdrm driver

This patch set fixes some issues with the OMAP VENC when used with the omapdrm driver. Tested on: BeagleBoard XM, GTA04 and OpenPandora H. Nikolaus Schaller (2): video:omap2:dss: fix timings for VENC to match what omapdrm expects video:omapdrm: make omapdrm assume the tv-out cable is always

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Include VENC in the set of drivers where it is assimed that the cable is always connected. Like DPI, DSI, DBI and SDI do. Otherwise, the VENC will return cable status "unknown" and is not enabled by the X-server. So there is no video output signal. Tested on: BeagleBoard XM, GTA04 and

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Hi Laurent and Tomi, Am 13.11.2015 um 13:01 schrieb Laurent Pinchart : > On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: >> On 13/11/15 12:29, H. Nikolaus Schaller wrote: >>> Include VENC in the set of drivers where it is assimed that the cable >>> is always connected. Like DPI, DSI,

__i915_spin_request() sucks

On 11/13/2015 02:15 AM, Chris Wilson wrote: > On Thu, Nov 12, 2015 at 03:52:02PM -0700, Jens Axboe wrote: >> On 11/12/2015 03:19 PM, Chris Wilson wrote: > So today, I figured I'd try just killing that spin. If it fails, we'll > punt to normal completions, so easy change. And wow, MASSIVE

__i915_spin_request() sucks

Previous patch was obvious pre-coffee crap, this should work for using ktime to spin max 1usec. diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 5cf4a1998273..21192e55c33c 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@

__i915_spin_request() sucks

On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote: > Previous patch was obvious pre-coffee crap, this should work for using > ktime to spin max 1usec. 1us seems a tad low. I doubt the little wooden gears and pulleys of my core2 Toshiba Satellite lappy can get one loop ground out in a usec :)

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Here the test results: Am 13.11.2015 um 13:01 schrieb Laurent Pinchart : > On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: >> On 13/11/15 12:29, H. Nikolaus Schaller wrote: >>> Include VENC in the set of drivers where it is assimed that the cable >>> is always connected. Like DPI, DSI,

[RFC] Docs: drm: Move KMS properties table out to source files

On Mon, 2015-09-28 at 11:33 -0600, Jonathan Corbet wrote: > On Mon, 28 Sep 2015 10:36:59 +0100 > Graham Whaley wrote: > > > I've still not thought of a way of tweaking the kernel-doc and > > pandoc > > processing to work around this either, as they are done as > > different > > passes/phases

__i915_spin_request() sucks

On 11/13/2015 03:12 PM, Chris Wilson wrote: > On Fri, Nov 13, 2015 at 09:22:52AM -0700, Jens Axboe wrote: >> On 11/13/2015 09:13 AM, Mike Galbraith wrote: >>> On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote: Previous patch was obvious pre-coffee crap, this should work for using ktime

__i915_spin_request() sucks

On 11/13/2015 09:13 AM, Mike Galbraith wrote: > On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote: >> Previous patch was obvious pre-coffee crap, this should work for using >> ktime to spin max 1usec. > > 1us seems a tad low. I doubt the little wooden gears and pulleys of my > core2 Toshiba