Re: [Intel-gfx] [PATCH 3/3] drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state.

Op 07-12-15 om 11:02 schreef Thierry Reding: > On Tue, Nov 24, 2015 at 02:35:34PM +0100, Maarten Lankhorst wrote: >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/tegra/dsi.c | 9 +++-- >> 1 file changed, 3 insertions(+), 6 deletions(-) >> >>

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Disable coarse power gating up until F0

Reviewed-by: Sagar Arun Kamble On 12/7/2015 9:59 PM, Mika Kuoppala wrote: There is conflicting info between E0 and F0 steppings for this workarounds. Trust more authoritative source and be conservative and extend also for F0. This prevents numerous (>50) gpu hangs

Re: [Intel-gfx] [PATCH 1/5] [RFC] drm: Documentation style guide

Hello Daniel, Just some typo comments below. On 09:49 AM - Dec 08 2015, Daniel Vetter wrote: > Every time I type or review docs this seems a bit different. Try to > document the common style so we can try to unify at least new docs. > > Signed-off-by: Daniel Vetter >

Re: [Intel-gfx] [PATCH] drm/i915: Restore waitboost credit to the synchronous waiter

Hi, On 12/07/2015 07:38 PM, Jesse Barnes wrote: [...] Still wishing we had a good way to benchmark these types of changes across a range of workloads. Eero, have you guys looked at turbo stuff at all yet? Except for this, not really: https://jira01.devtools.intel.com/browse/LCK-2271

Re: [Intel-gfx] [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe

On Mon, Dec 07, 2015 at 03:33:00PM +, Daniel Stone wrote: > Hi, > > On 4 December 2015 at 08:46, Daniel Vetter wrote: > > + /* > > +* Reject event generation for when a CRTC is off and stays off. It > > +* wouldn't be hard to implement this, but

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

On 8 December 2015 at 08:49, Daniel Vetter wrote: > In my quest to remove all the drm_encoder_helper_funcs->save/restore > hooks I somehow missed that this driver has a dummy set too - I > thought all the i2c drivers only set up the slave_encoder save/restore > hooks,

Re: [Intel-gfx] [PATCH] Revert "drm/i915: skip modeset if compatible for everyone."

Op 19-11-15 om 10:05 schreef Jani Nikula: > On Thu, 19 Nov 2015, Jani Nikula wrote: >> This reverts >> >> commit 6764e9f8724f1231b4deac53b9a82286ac0830e7 >> Author: Maarten Lankhorst >> Date: Thu Aug 27 15:44:06 2015 +0200 >> >>

[Intel-gfx] [PATCH i-g-t] lib/pm_workarounds: Lib for PM workarounds

Move workarounds for power management related issues in external components into a separate library, and modify the users of such workarounds accordingly. This currently involves HD audio and SATA link power management. For SATA link PM there's also code to save the previous settings, to allow

Re: [Intel-gfx] [PATCH V4 2/2] drm/i915: start adding dp mst audio

Hi all, Any comments on the patches? Best Regards, Libin On 12/02/2015 02:09 PM, libin.y...@linux.intel.com wrote: From: Libin Yang This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable

[Intel-gfx] [maintainer-tools PATCH] drm-intel: embed wavedrom engine and skin into the web page

The wavedrom timeline will be missing from html pages served over https due to "mixed active content" blocking [1], because the wavedrom engine and skin are only available over http. Embed the engine and skin into the resulting html to avoid the problem. The rst :url: will fetch and include the

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote: > > On 25/08/15 16:45, Daniel Vetter wrote: > > When the usual fbcon legacy options are enabled we have > > ->register_framebuffer > > ->fb notifier chain calls into fbcon > > ->fbcon sets up console on new fbi > >

Re: [Intel-gfx] [PATCH 8/9] drm/atomic: Remove drm_atomic_connectors_for_crtc.

Op 07-12-15 om 11:34 schreef Thierry Reding: > On Tue, Nov 24, 2015 at 10:34:35AM +0100, Maarten Lankhorst wrote: > [...] >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c >> index cee31d43cd1c..fb79c54b2aed 100644 >> ---

Re: [Intel-gfx] i915 Skylake crash on 4.4-rc3

Hi, On 07/12/15 19:25, Andy Lutomirski wrote: [53834.386369] traps: gnome-session-b[2308] general protection ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in libc-2.22.so[7f10efba1000+1b7000] [53834.687584] [ cut here ] [53834.687607] WARNING: CPU: 0 PID: 23730 at

[Intel-gfx] [PATCH 3/5] drm: Move more framebuffer doc from docbook to kerneldoc

I missed a few paragraphs in the docbook that need to be pulled into the fbdev vfunc docs. Cc: Thierry Reding Signed-off-by: Daniel Vetter --- Documentation/DocBook/gpu.tmpl | 72 +- include/drm/drm_crtc.h

[Intel-gfx] [PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

We want this for consistency with existing page_flip semantics. Since this spurred quite a discussion on IRC also document why we reject even generation when the pipe is off: It's not that it's hard to implement, but userspace has a track recording proofing that it's way too easy to accidentally

[Intel-gfx] [PATCH 1/5] [RFC] drm: Documentation style guide

Every time I type or review docs this seems a bit different. Try to document the common style so we can try to unify at least new docs. Signed-off-by: Daniel Vetter --- Documentation/DocBook/gpu.tmpl | 37 + 1 file changed, 37

[Intel-gfx] [PATCH 2/5] drm/atomic-helper: Drop unneeded argument from check_pending_encoder

Just a remnant from an old iteration of this patch that I've forgotten to remove: We only need the encoder to figure out whether it has been reassigned in this update already or not to figure out whether there's a conflict or not. Reported-by: Thierry Reding Cc: Thierry

[Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

In my quest to remove all the drm_encoder_helper_funcs->save/restore hooks I somehow missed that this driver has a dummy set too - I thought all the i2c drivers only set up the slave_encoder save/restore hooks, which I've left. Remove them. Reported-by: Stephen Rothwell

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix uninitialized variables in intel_check_sprite_plane

On Mon, 07 Dec 2015, Nabendu Maiti wrote: > On 11/26/2015 11:33 PM, Nabendu Maiti wrote: >> >> >> On 11/18/2015 10:56 PM, Ville Syrjälä wrote: >>> On Wed, Nov 18, 2015 at 10:33:55PM +0530, Maiti, Nabendu Bikash wrote: On 11/18/2015 7:00 PM, Ville Syrjälä

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote: > On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote: > > On 8 December 2015 at 08:49, Daniel Vetter wrote: > > > In my quest to remove all the drm_encoder_helper_funcs->save/restore > > > hooks I

Re: [Intel-gfx] i915 Skylake crash on 4.4-rc3

On Tue, 08 Dec 2015, Daniel Vetter wrote: > On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote: >> >> Hi, >> >> On 07/12/15 19:25, Andy Lutomirski wrote: >> >[53834.386369] traps: gnome-session-b[2308] general protection >> >ip:7f10efc1fc2b sp:7ffdfde31880 error:0

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

On Tue, Dec 08, 2015 at 01:44:10PM +0200, Jani Nikula wrote: > On Mon, 07 Dec 2015, Wayne Boyer wrote: > > The cherryview device shares many characteristics with the valleyview > > device. When support was added to the driver for cherryview, the > > corresponding device

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

On 08/12/15 11:57, Michel Thierry wrote: From: Vinay Belgaumkar These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Only set gem object L3 cache level for IVB devices

On Mon, Dec 07, 2015 at 10:26:15PM +, Boyer, Wayne wrote: > On 12/7/15, 11:56 AM, "Deak, Imre" wrote: > > > >On Mon, 2015-12-07 at 21:28 +0200, Ville Syrjälä wrote: > >> On Mon, Dec 07, 2015 at 10:51:09AM -0800, Wayne Boyer wrote: > >> > Do some further clean up based

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Remove BUG_ON call in vlv_enable_pll

On Mon, Dec 07, 2015 at 03:02:42PM -0800, Wayne Boyer wrote: > Do some further clean up based on the initial review of > drm/i915: Separate cherryview from valleyview. > > In this case remove the BUG_ON call in vlv_enable_pll(). > > v2: Also remove the BUG_ON call in chv_enable_pll(). (Ville) >

[Intel-gfx] [PATCH 0/1] drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e}

Way back at the beginning of October, Chris Wilson suggested that cleaning up these macros by removing the redundant 'temp' might be worthwhile. So here's the patch. There's one more thing that might be cleaned up here (but for which I don't have a patch yet), which is that gen8_for_each_pdpe()

[Intel-gfx] [PATCH 1/1] drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e} macros

All of these iterator macros require a 'temp' argument, used merely to hold internal partial results. We can instead declare the temporary variable inside the macro, so the caller need not provide it. Some of the old code contained nested iterators that actually reused the same 'temp' variable

Re: [Intel-gfx] [PATCH 1/5] [RFC] drm: Documentation style guide

On Tue, Dec 08, 2015 at 10:59:05AM +0100, Pierre Moreau wrote: > On 09:49 AM - Dec 08 2015, Daniel Vetter wrote: > > + > > + Functions which have a non-void return value should > > have a > > + section called "Returns" explaining the expected return values in > > + different

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

On Mon 07-12-15 11:48:31, Johannes Weiner wrote: > On Mon, Dec 07, 2015 at 02:48:12PM +0100, Michal Hocko wrote: > > On Fri 04-12-15 15:58:53, Chris Wilson wrote: > > > Some modules, like i915.ko, use swappable objects and may try to swap > > > them out under memory pressure (via the shrinker).

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

On Fri 04-12-15 15:58:53, Chris Wilson wrote: > Some modules, like i915.ko, use swappable objects and may try to swap > them out under memory pressure (via the shrinker). Before doing so, they > want to check using get_nr_swap_pages() to see if any swap space is > available as otherwise they will

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

On Mon, 07 Dec 2015, Wayne Boyer wrote: > The cherryview device shares many characteristics with the valleyview > device. When support was added to the driver for cherryview, the > corresponding device info structure included .is_valleyview = 1. > This is not correct and

Re: [Intel-gfx] [PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

Hi, On 8 December 2015 at 08:49, Daniel Vetter wrote: > We want this for consistency with existing page_flip semantics. > > Since this spurred quite a discussion on IRC also document why we > reject even generation when the pipe is off: It's not that it's hard > to

Re: [Intel-gfx] i915 Skylake crash on 4.4-rc3

On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote: > > Hi, > > On 07/12/15 19:25, Andy Lutomirski wrote: > >[53834.386369] traps: gnome-session-b[2308] general protection > >ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in > >libc-2.22.so[7f10efba1000+1b7000] > >[53834.687584]

Re: [Intel-gfx] [PATCH v7] drm/i915: Slaughter the thundering i915_wait_request herd

On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote: > > Hi, > > On 03/12/15 16:22, Chris Wilson wrote: > >One particularly stressful scenario consists of many independent tasks > >all competing for GPU time and waiting upon the results (e.g. realtime > >transcoding of many, many

Re: [Intel-gfx] [PATCH i-g-t 1/2] kms_psr_sink_crc: Introduce PSR BAT test.

On Mon, Dec 07, 2015 at 02:06:49AM -0800, Rodrigo Vivi wrote: > This simple test checks if PSR is enabled when it should. > Minimal and fastest check possible. > > To make it faster for BAT we first check if it is enabled and return > Success. We just do the dpms_on in case psr is not enabled. So

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_psr_sink_crc: Add basic check for PSR active.

On Mon, Dec 07, 2015 at 02:06:50AM -0800, Rodrigo Vivi wrote: > It takes from 2 to 5 seconds to run. > > Cc: Daniel Vetter > Signed-off-by: Rodrigo Vivi > --- > tests/kms_psr_sink_crc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

On Mon 07-12-15 14:13:46, Johannes Weiner wrote: > On Mon, Dec 07, 2015 at 06:10:00PM +, Dave Gordon wrote: > > Exporting random uncontrolled variables from the kernel to loaded modules is > > not really considered best practice. It would be preferable to provide an > > accessor function -

[Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

From: Vinay Belgaumkar These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the

Re: [Intel-gfx] [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks

Reviewed-by: Thomas Hellstrom On 12/04/2015 09:45 AM, Daniel Vetter wrote: > These hooks will be gone soon. > > Cc: Thomas Hellstrom > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16

[Intel-gfx] [PATCH i-g-t] gem_flink_race/prime_self_import: Improve test reliability

gem_flink_race and prime_self_import have subtests which read the number of open gem objects from debugfs to determine if objects have leaked during the test. However the test can fail sporadically if the number of gem objects changes due to other process activity. This patch introduces a change

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote: > On 8 December 2015 at 08:49, Daniel Vetter wrote: > > In my quest to remove all the drm_encoder_helper_funcs->save/restore > > hooks I somehow missed that this driver has a dummy set too - I > > thought all

Re: [Intel-gfx] [PATCH i-g-t] RFC: split PM workarounds into separate lib

Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu: > Since the defaults for some external power management related > settings > prevents us from testing our power management functionality properly, > we have to work around it. Currently this is done from the individual > test cases, but

Re: [Intel-gfx] [PATCH i-g-t] RFC: split PM workarounds into separate lib

On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote: > Since the defaults for some external power management related settings > prevents us from testing our power management functionality properly, > we have to work around it. Currently this is done from the individual > test cases,

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Disable FDI after the CRT port on LPT-H

On Mon, Dec 07, 2015 at 08:57:59PM +0200, Ville Syrjälä wrote: > On Mon, Dec 07, 2015 at 03:51:06PM -0200, Paulo Zanoni wrote: > > 2015-12-04 18:20 GMT-02:00 : > > > From: Ville Syrjälä > > > > > > Bspec modeset sequence tells us to

Re: [Intel-gfx] [PATCH v7] drm/i915: Slaughter the thundering i915_wait_request herd

On 08/12/15 14:33, Chris Wilson wrote: On Tue, Dec 08, 2015 at 02:03:39PM +, Tvrtko Ursulin wrote: On 08/12/15 10:44, Chris Wilson wrote: On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote: Equally, why wouldn't we wake up all waiters for which the requests have been

[Intel-gfx] [PATCH] drm/i915: Disable FDI after the CRT port on LPT-H

From: Ville Syrjälä Bspec modeset sequence tells us to disable the PCH transcoder and FDI after the CRT port on LPT-H, so let's do that. And the CRT port should be disabled after the pipe, as we do on other PCH platforms too since commit 1ea56e269e13 ("drm/i915:

Re: [Intel-gfx] [PATCH 00/10] HSW/BDW PCH modeset fixes and stuff

On Tue, Dec 01, 2015 at 03:08:31PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I was trying to get to the bottom of the FDI fails on Brix Pro, and > thus eneded up going through the entire PCH modeset stuff for HSW. > While I did find a

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_psr_sink_crc: Add basic check for PSR active.

On Tue, Dec 8, 2015 at 2:45 AM, Daniel Vetter wrote: > On Mon, Dec 07, 2015 at 02:06:50AM -0800, Rodrigo Vivi wrote: >> It takes from 2 to 5 seconds to run. >> >> Cc: Daniel Vetter >> Signed-off-by: Rodrigo Vivi >> --- >>

Re: [Intel-gfx] [PATCH v7] drm/i915: Slaughter the thundering i915_wait_request herd

On Tue, Dec 08, 2015 at 02:03:39PM +, Tvrtko Ursulin wrote: > On 08/12/15 10:44, Chris Wilson wrote: > >On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote: > >>Equally, why wouldn't we wake up all waiters for which the requests > >>have been completed? > > > >Because we no longer

[Intel-gfx] [PATCH 1/1] drm/i915: intel_ring_initialized() must be simple and inline

Based on Chris Wilson's patch from 6 months ago, rebased and adapted. The current implementation of intel_ring_initialized() is too heavyweight; it's a non-inlined function that chases several levels of pointers. This wouldn't matter too much if it were rarely called, but it's used inside the

Re: [Intel-gfx] [PATCH v7] drm/i915: Slaughter the thundering i915_wait_request herd

On 08/12/15 10:44, Chris Wilson wrote: On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote: Hi, On 03/12/15 16:22, Chris Wilson wrote: One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime

[Intel-gfx] [PATCH] drm/i915: Widen return value for reservation_object_wait_timeout_rcu to long.

This fixes a spurious warning from an integer overflow on 64-bits systems. The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1. Explicitly handling this by casting to lret fixes it. Signed-off-by: Maarten Lankhorst Reported-and-tested-by:

[Intel-gfx] [PATCH 0/1] drm/i915: intel_ring_initialized() must be simple and inline

Based on Chris Wilson's patch from 6 months ago, rebased and adapted. The idea is to use ring->dev as an indicator showing which engines have been initialised and are therefore to be included in iterations that use for_each_ring(). This allows us to avoid multiple memory references and a

Re: [Intel-gfx] [PATCH 1/5] [RFC] drm: Documentation style guide

Hello, On Tuesday 08 December 2015 10:59:05 Pierre Moreau wrote: > On 09:49 AM - Dec 08 2015, Daniel Vetter wrote: > > Every time I type or review docs this seems a bit different. Try to > > document the common style so we can try to unify at least new docs. > > > > Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter wrote: > We want this for consistency with existing page_flip semantics. > > Since this spurred quite a discussion on IRC also document why we > reject even generation when the pipe is off: It's not that it's hard event

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Remove double wait_for_vblank on broadwell.

On Wed, Nov 25, 2015 at 11:44:48AM +0200, Ander Conselvan De Oliveira wrote: > On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > > wait_vblank is already set in intel_plane_atomic_calc_changes > > for broadwell, waiting for a double vblank is overkill. > > > > Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Disable coarse power gating up until F0

Both patches pushed to drm-intel-next-queued, and then backported to drm-intel-fixes with cc: stable. Thanks for the patches and review. BR, Jani. On Tue, 08 Dec 2015, "Kamble, Sagar A" wrote: > Reviewed-by: Sagar Arun Kamble > > On

[Intel-gfx] [PATCH] drm/i915: Disable FDI RX before DDI_BUF_CTL

From: Ville Syrjälä Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists FDI RX disable both as step 13 and step 18 in the sequence. But I dug up an old BUN mail from Art that moved the FDI RX disable to happen before DDI_BUF_CTL disable. That BUN

[Intel-gfx] [PATCH v3 12/14] 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

[Intel-gfx] [PATCH 13/14] drm/i915: Give encoders useful names

From: Ville Syrjälä Rather than let the core generate usless encoder names, let's pass in something that actually identifies the piece of hardware we're dealing with. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 08/14] 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

[Intel-gfx] [PATCH 11/14] 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.

[Intel-gfx] [PATCH v4 09/14] 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) v4: Pass the printf style format string to

[Intel-gfx] [PATCH 07/14] 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(-)

Re: [Intel-gfx] [PATCH 2/3] drm/i915: mark GEM objects as dirty when updated by the CPU

On Tue, Dec 08, 2015 at 04:51:17PM +, Dave Gordon wrote: > In various places, one or more pages of a GEM object are mapped into CPU > address space and updated. In each such case, either the page or the the > object should be marked dirty, to ensure that the modifications are not > discarded

[Intel-gfx] [PATCH v3 06/14] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä Show a sensible name for the plane in debug mesages. The driver may supply its own name, otherwise the core genrates the name ("plane-0", "plane-1" etc.). v2: kstrdup() the name passed by the caller (Jani) v3: Generate a default name if the

[Intel-gfx] [PATCH v2 02/14] drm: Pass 'name' to drm_universal_plane_init()

From: Ville Syrjälä Done with coccinelle for the most part. It choked on msm/mdp/mdp5/mdp5_plane.c like so: "BAD:! enum drm_plane_type type;" No idea how to deal with that, so I just fixed that up by hand. Also it thinks '...' is part of the semantic patch,

[Intel-gfx] [PATCH 03/14] drm: Pass 'name' to drm_encoder_init()

From: Ville Syrjälä Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. @@ identifier dev, encoder, funcs; @@ int

[Intel-gfx] [PATCH v2 01/14] drm: Pass 'name' to drm_crtc_init_with_planes()

From: Ville Syrjälä Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. I didn't convert drm_crtc_init() since passing the

[Intel-gfx] [PATCH v3 05/14] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä Show a sensible name for the crtc in debug mesages. The driver may supply its own name, otherwise the core genrates the name ("crtc-0", "crtc-1" etc.). v2: kstrdup() the name passed by the caller (Jani) v3: Generate a default name if the driver

[Intel-gfx] [PATCH v4 00/14] drm: Give crtcs and planes actual names (v4)

From: Ville Syrjälä I've done some more modeset log staring recently and again got fed up with the noise. So here's another attempt at making the logs make some sense. This time I pass a printf style format string to the init functions, so that callers don't have

[Intel-gfx] [PATCH 04/14] drm: Use driver specified encoder name

From: Ville Syrjälä Use the encoder name passed by the driver if non-NULL, otherwise fall back to the old style name. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_crtc.c | 14 +++--- 1 file changed, 11

[Intel-gfx] [PATCH 14/14] drm/i915: Add debug prints for encoder modeset hooks

From: Ville Syrjälä To get a better idea where exactly some error occurred during modeset, put in some debug prints to tell us when the variuous encoder hooks are getting called. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 0/3] drm/i915: mark GEM objects as dirtied by CPU

This patchset covers three variations on GEM objects being dirtied by means of CPU writes. The first is simple: an object has been entirely filled with data via CPU writes, and the whole object is therefore dirty (i.e. backing store is out-of-date w.r.t. current contents). For these cases,

[Intel-gfx] [PATCH 3/3] drm/i915: mark GEM objects as dirty when written by the CPU

This patch covers a couple more places where a GEM object is (or may be) modified by means of CPU writes, and should therefore be marked dirty to ensure that the changes are not lost in the evenof of the object is evicted under memory pressure. It may be possible to optimise these paths later, by

[Intel-gfx] [PATCH 2/3] drm/i915: mark GEM objects as dirty when updated by the CPU

In various places, one or more pages of a GEM object are mapped into CPU address space and updated. In each such case, either the page or the the object should be marked dirty, to ensure that the modifications are not discarded if the object is evicted under memory pressure. Ideally, we would

[Intel-gfx] [PATCH i-g-t 1/2] kms_psr_sink_crc: Reduce our time out for PSR active.

Using same timeout value as kms_fronbuffer_tracking and for same reasons exposed at 'commit 83582f9b ("kms_frontbuffer_tracking: Increase the time we wait for PSR.")' Signed-off-by: Rodrigo Vivi --- tests/kms_psr_sink_crc.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH i-g-t 2/2] kms_psr_sink_crc: Add BAT test for PSR active.

It takes from 2 to 5 seconds to run. Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- tests/kms_psr_sink_crc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c index 8cd11a7..5fad9b5

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

On Tue, Dec 8, 2015 at 2:15 AM, Russell King - ARM Linux wrote: > On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote: >> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote: >> > On 8 December 2015 at 08:49, Daniel Vetter wrote:

[Intel-gfx] [PATCH 1/3] drm/i915: mark GEM objects as dirty when filled by the CPU

In various places, a GEM object is filled with data by means of CPU writes. In such cases, the object should be marked dirty, to ensure that the data is not discarded if the object is evicted under memory pressure. This incorporates and supercedes Alex Dai's earlier patch [PATCH v1] drm/i915/guc:

Re: [Intel-gfx] [PATCH 1/3] drm/i915: mark GEM objects as dirty when filled by the CPU

On Tue, Dec 08, 2015 at 04:51:16PM +, Dave Gordon wrote: > In various places, a GEM object is filled with data by means of CPU > writes. In such cases, the object should be marked dirty, to ensure that > the data is not discarded if the object is evicted under memory > pressure. > > This

Re: [Intel-gfx] [PATCH 3/3] drm/i915: mark GEM objects as dirty when written by the CPU

On Tue, Dec 08, 2015 at 04:51:18PM +, Dave Gordon wrote: > This patch covers a couple more places where a GEM object is (or may be) > modified by means of CPU writes, and should therefore be marked dirty to > ensure that the changes are not lost in the evenof of the object is > evicted under

[Intel-gfx] [PATCH 01/15] drm/i915: Pass the correct encoder to intel_ddi_clk_select() with MST

From: Ville Syrjälä We're supposed to pass the primary DP encoder to intel_ddi_clk_select(), not the fake MST encoder. Do so. There's no real bug here though, since intel_ddi_clk_select() only checks if the encoder type is EDP (which it isn't for either the

[Intel-gfx] [PATCH 09/15] drm/i915: Kill intel_prepare_ddi()

From: Ville Syrjälä Move the ddi buffer translation programming to occur from the encoder .pre_enable() hook, for just the ddi port we are enabling. Previously we used to reprogram the translations for all ddi ports during init and during power well enabling.

[Intel-gfx] [PATCH 07/15] drm/i915: Add BUILD_BUG_ON()s for DDI translation table sizes

From: Ville Syrjälä The DDI translation tables are supposed to be of certain size, so let's add some compile time asserts to enforce that.. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 15 +++ 1

[Intel-gfx] [PATCH 06/15] drm/i915: Pass around dev_priv for ddi buffer programming

From: Ville Syrjälä Make the ddi buffer programming code a bit more neat by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 79 +++- 1

[Intel-gfx] [PATCH 04/15] drm/i915: Remove pointless 'ddi_translations' local variable

From: Ville Syrjälä skl_get_buf_trans_*() don't need the 'ddi_translations' local variable since all they with is assign and return. Just return the right thing directly and get rid of the local variable. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 05/15] drm/i915: Eliminate duplicated skl_get_buf_trans_dp()

From: Ville Syrjälä skl_get_buf_trans_edp() effectively contains another copy of skl_get_buf_trans_dp(). Remove the duplication and just call skl_get_buf_trans_dp() from skl_get_buf_trans_edp(). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 03/15] drm/i915: Store max lane count in intel_digital_port

From: Ville Syrjälä Rather than having open coded checks for the DDI A/E configuration, just store the max supported lane count in intel_digital_port. We had an open coded check for DDI A, but not for DDI E. So we may have been vilating the DDI E max lane count.

[Intel-gfx] [PATCH 02/15] drm/i915: Check max number of lanes when registering DDI ports

From: Ville Syrjälä DDI A and E share some of the lanes, so check that we have enough lanes for the purpose we need before registering the encoders. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 36

[Intel-gfx] [PATCH 10/15] drm/i915: Split the problematic dual-role DDI encoder into two encoders

From: Ville Syrjälä Eliminate the troublesome role switching DDI encoder, and just register a separate encoder for each role (DP and HDMI). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 232

[Intel-gfx] [PATCH 14/15] drm/i915: Get the iboost setting based on the port type

From: Ville Syrjälä Program the 'iboost_bit' based on what the VBT says it should be for the specific port type, rather than assume it's alwasy the same for DP and HDMI. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 12/15] drm/i915: Split DP/eDP/FDI and HDMI/DVI DDI buffer programming apart

From: Ville Syrjälä DDI buffer prorgramming works quite differently depending on the mode of the DDI port (DP/eDP/FDI vs. HDMI/DVI). Let's split the function that does the programming into two matching variants as well. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 13/15] drm/i915: Add a sanity check for 'hdmi_default_entry'

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index

[Intel-gfx] [PATCH 15/15] drm/i915: Simplify intel_ddi_get_encoder_port()

From: Ville Syrjälä We no longer have any need to look up the intel_digital_port based on the passed in intel_encoder, but we still want to look up the port. Let's just move that logic into intel_ddi_get_encoder_port() and drop the dig_port stuff. Signed-off-by:

[Intel-gfx] [PATCH 08/15] drm/i915: Reject >9 ddi translation entried if port != A/E on SKL

From: Ville Syrjälä Only DDI A and E support 10 translation entries in DP mode. For the other ports the tenth entry is reserved for HDMI.. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 9 + 1 file

[Intel-gfx] [PATCH 11/15] drm/i915: Explicitly use ddi bug trans entry 9 for hdmi

From: Ville Syrjälä When the DDI port is in HDMI/DVI mode, it automagically uses the buffer translations values from entry 9. Let's make that explicit in the code. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c |

Re: [Intel-gfx] [PATCH 1/3] drm/i915: mark GEM objects as dirty when filled by the CPU

On 08/12/15 17:00, Chris Wilson wrote: On Tue, Dec 08, 2015 at 04:51:16PM +, Dave Gordon wrote: In various places, a GEM object is filled with data by means of CPU writes. In such cases, the object should be marked dirty, to ensure that the data is not discarded if the object is evicted

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Only set gem object L3 cache level for IVB devices

On Tue, Dec 08, 2015 at 09:38:52AM -0800, Wayne Boyer wrote: > Do some further clean up based on the initial review of > drm/i915: Separate cherryview from valleyview. > > In this case, in i915_gem_alloc_context_obj() only call > i915_gem_object_set_cache_level() for Ivy Bridge devices > since

Re: [Intel-gfx] [PATCH 3/3] drm/i915: mark GEM objects as dirty when written by the CPU

On 08/12/15 17:03, Chris Wilson wrote: On Tue, Dec 08, 2015 at 04:51:18PM +, Dave Gordon wrote: This patch covers a couple more places where a GEM object is (or may be) modified by means of CPU writes, and should therefore be marked dirty to ensure that the changes are not lost in the

  1   2   >