Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On Thu, Nov 12, 2015 at 07:50:09PM +0200, Imre Deak wrote: > On to, 2015-11-12 at 17:04 +, Chris Wilson wrote: > > As it stands since we don't actually cancel the hangcheck when we > drop > > the rpm wakelock in intel_mark_idle() it can very well come to pass > > that > > we execute this

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

On Thu, 2015-11-12 at 13:50 +, R, Durgadoss wrote: > Hi Rodrigo, > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > Behalf Of Rodrigo Vivi > > Sent: Thursday, November 12, 2015 1:07 AM > > To: intel-gfx@lists.freedesktop.org > > Cc:

[Intel-gfx] [PATCH v2 8/8] 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 v2 5/8] 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 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 21 + 1

[Intel-gfx] [PATCH v2 0/8] drm: Give crtcs and planes actual names (v2)

From: Ville Syrjälä OK, so another attempt. This time the error handling and cleanup should be more solid. Previus attempt was at http://lists.freedesktop.org/archives/dri-devel/2015-November/094331.html I pushed v2 to: git://github.com/vsyrjala/linux.git

[Intel-gfx] [PATCH 3/8] 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 v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On Thu, 2015-11-12 at 20:41 +, Chris Wilson wrote: > On Thu, Nov 12, 2015 at 07:50:09PM +0200, Imre Deak wrote: > > On to, 2015-11-12 at 17:04 +, Chris Wilson wrote: > > > As it stands since we don't actually cancel the hangcheck when we > > drop > > > the rpm wakelock in intel_mark_idle()

[Intel-gfx] [PATCH 7/8] 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 1/8] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56 +++-- drivers/gpu/drm/drm_crtc.c

[Intel-gfx] [PATCH 6/8] 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. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 2/8] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä 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 | 3 +++ include/drm/drm_crtc.h

[Intel-gfx] [PATCH 4/8] 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

Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again

Hi, I have seen you were working on brightness. Right, but this is useful only if many worlwide users would be able to activate it. I have never been able to make it working on my intel systemes (core i5 - 4300u , core i3 ...) Very difficult to check where the problem is coming from, altough

Re: [Intel-gfx] [PATCH i-g-t] igt/pm_rps: current freq < user specified min is no longer a fail

On ke, 2015-11-11 at 13:37 -0800, Bob Paauwe wrote: > Since commit > > commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581 > Author: Chris Wilson > Date: Wed Mar 18 09:48:21 2015 + > > drm/i915: Relax RPS contraints to allows setting minfreq on > idle >

Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again

On 12/11/2015 09:28, Shih-Yuan Lee (FourDollars) wrote: I think the first step is to identify which backlight interface is able to actually change the brightness. Usually there are two backlight interfaces under /sys/class/backlight/, i.e. /sys/class/backlight/acpi_video0 and

Re: [Intel-gfx] [PATCH] drm/i915/skl: Implement DP Aux Mutex framework

"aux mutex framework" in the title sounds a bit grandiose, to be honest. "add support for DP AUX hardware mutex" is what I would have used. Further comments inline. On Thu, 12 Nov 2015, Wayne Boyer wrote: > From: "Boyer, Wayne" > > Beginning with

Re: [Intel-gfx] [PATCH 0/5] Sink CRC stabilization

On Wed, 11 Nov 2015, Rodrigo Vivi wrote: > Let's start spliting that big series that enables PSR with this sink crc > stabilization. > > Also I'm adding Wayne's mutex that stabilizes sink CRC on Skylake. > > All patches already reviewed and ready to merge. Disagreed on

Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again

You may need to put "drm.debug=0xe" into the kernel parameter and reboot the system to collect some system log. Did you check the brightness value after you change it? On Thu, Nov 12, 2015 at 4:40 PM, Stéphane ANCELOT wrote: > On 12/11/2015 09:28, Shih-Yuan Lee (FourDollars)

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Clean up AUX power domain handling

On Wed, Nov 11, 2015 at 08:37:36PM +0200, Ville Syrjälä wrote: > On Wed, Nov 11, 2015 at 08:22:03PM +0200, Imre Deak wrote: > > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > > From: Ville Syrjälä > > > > > > Introduce

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

Hey, Gabriel Feceoru schreef op wo 11-11-2015 om 20:27 [+0200]: > > On 11.11.2015 16:21, Jani Nikula wrote: > > On Wed, 11 Nov 2015, Ander Conselvan De Oliveira > > wrote: > >> On Tue, 2015-11-10 at 14:53 +0200, Jani Nikula wrote: > >>> Ander, Maarten, where are we with

Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again

I think the first step is to identify which backlight interface is able to actually change the brightness. Usually there are two backlight interfaces under /sys/class/backlight/, i.e. /sys/class/backlight/acpi_video0 and /sys/class/backlight/intel_backlight. However you may see other different

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Replace the aux ddc name switch statement with kasprintf()

On Wed, 11 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use kasprintf() to generate the "DPDDC-" name for the aux helper. > > To deal with errors properly make intel_dp_aux_init() return something, > and adjust the caller to match. It

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Reordered AUX patches from type safety series

On Wed, 11 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Chris requested that I try to reorder the DP AUX patches in the last > register type safety series [1] to form a better story. Here is the > result. The final code is exactly the

Re: [Intel-gfx] [PATCH v3 3/7] drm/i915: use assert_rpm_wakelock_held instead of opencoding it

On Thu, Nov 12, 2015 at 06:40:17PM +0200, Imre Deak wrote: > Signed-off-by: Imre Deak > Reviewed-by: Chris Wilson (v1) Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH v3 5/7] drm/i915: sanitize the asserts in the RPM get/put helpers

On Thu, Nov 12, 2015 at 06:40:19PM +0200, Imre Deak wrote: > There is no point in checking the refcount just after increasing it so > remove the assert from the get helper. Otoh, we should check the > refcount before decreasing it, so add it to the put helper. > > Signed-off-by: Imre Deak

[Intel-gfx] [PATCH 1/4] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state

The intel_dump_pipe_config() always dumps the currently active plane state for each plane on a CRTC. If we're calling this function to dump CRTC state that is in-flight (not yet active), then this mismatch can be misleading and confusing. Let's pay attention to whether the state we're dumping is

[Intel-gfx] [PATCH] drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink.

Commit (89251b17) intended to remove this line and let only one DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated at the code. Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It was like that since I introduced this call but probably the idea was to be informative

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On Thu, Nov 12, 2015 at 10:49:29PM +0200, Imre Deak wrote: > On Thu, 2015-11-12 at 20:41 +, Chris Wilson wrote: > > On Thu, Nov 12, 2015 at 07:50:09PM +0200, Imre Deak wrote: > > > On to, 2015-11-12 at 17:04 +, Chris Wilson wrote: > > > > As it stands since we don't actually cancel the

Re: [Intel-gfx] [PATCH v3 2/7] drm/i915: add assert_rpm_wakelock_held helper

On Thu, Nov 12, 2015 at 06:40:16PM +0200, Imre Deak wrote: > As a preparation for follow-up patches add a new helper that checks > whether we hold an RPM reference, since this is what we want most of > the cases. Atm this helper will only check for the HW suspended state, a > follow-up patch will

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On Thu, Nov 12, 2015 at 06:40:18PM +0200, Imre Deak wrote: > Atm, we assert that the device is not suspended until the point when the > HW is truly put to a suspended state. This is fine, but we can catch > more problems if we check the RPM refcount. After that one drops to zero > we shouldn't

[Intel-gfx] [PATCH 2/4] drm/i915: Clarify plane state during CRTC state dumps

During state dumping, list planes that have an FB but are invisible (e.g., because they're offscreen or clipped by other planes) as "not visible" rather than "enabled." While we're at it, throw the bpp value into the debugging output. Signed-off-by: Matt Roper ---

[Intel-gfx] [PATCH 4/4] drm/i915: Setup clipped src/dest coordinates during FB reconstruction

Plane state objects contain two copies of src/dest coordinates: the original (requested by userspace) coordinates in the base drm_plane_state object, and a second, clipped copy (i.e., what we actually want to program to the hardware) in intel_plane_state. We've only been setting up the former

[Intel-gfx] [PATCH 3/4] drm/i915: Dump pipe config after initial FB is reconstructed

We dump during HW state readout, but that's too early to reflect how the primary plane is actually configured. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [Intel-gfx] [PATCH v3 1/7] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers

On Thu, Nov 12, 2015 at 06:40:15PM +0200, Imre Deak wrote: > We don't really need to check this flag in the get/put/assert helpers, > as on platforms without RPM support we won't ever enable RPM. That means > pm.suspend will be always false and the assert will be always true. > > Do this to

Re: [Intel-gfx] [PATCH 06/31] drm/i915: Fix IPS disable sequence.

Hi, On 11 November 2015 at 23:31, Vivi, Rodrigo wrote: > On Tue, 2015-11-10 at 16:34 +, Daniel Stone wrote: >> On 5 November 2015 at 18:49, Rodrigo Vivi >> wrote: >> > +void intel_ips_disable_if_alone(struct intel_crtc *crtc) >> > +{ >> > +

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/gen9: Turn DC handling into a power well

On Wed, Nov 11, 2015 at 08:57:19PM +0200, Imre Deak wrote: > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > Handle DC off as a power well where enabling the power well will > > prevent > > the DMC to enter selected DC states (required around modesets and Aux > > A). Disabling the

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/gen9: Turn DC handling into a power well

On Wed, Nov 11, 2015 at 09:23:32PM +0200, Imre Deak wrote: > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > Handle DC off as a power well where enabling the power well will > > prevent > > the DMC to enter selected DC states (required around modesets and Aux > > A). Disabling the

Re: [Intel-gfx] [PATCH i-g-t 2/3 v3] Unify handling of slow/combinatorial tests

On Fri, Oct 30, 2015 at 01:52:48PM +, Chris Wilson wrote: > On Fri, Oct 30, 2015 at 03:18:30PM +0200, David Weinehall wrote: > > @@ -931,16 +930,20 @@ run_basic_modes(const struct access_mode *mode, > > struct buffers buffers; > > > > for (h = hangs; h->suffix; h++) { > > -

[Intel-gfx] [PATCH] drm/i915: Remove redundant check in i915_gem_obj_to_vma

From: Tvrtko Ursulin No need to verify VMA belongs to GGTT since: 1. The function must return a normal VMA belonging to passed in VM. 2. There can only be one normal VMA for any VM. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v3 03/13] drm/i915/gen9: move assert_csr_loaded into intel_rpm.c

On ke, 2015-10-28 at 23:58 +0200, Imre Deak wrote: > From: Daniel Vetter > > Avoids non-static functions since all the callers are in intel_rpm.c. > > Cc: Damien Lespiau > Cc: Imre Deak > Cc: Sunil Kamath

Re: [Intel-gfx] [PATCH v2 11/12] drm/i915/gen9: Add boot parameter for disabling DC6

On Wed, Nov 11, 2015 at 09:04:09PM +0200, Imre Deak wrote: > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > v2: Use _unsafe (Jani) > > > > Signed-off-by: Patrik Jakobsson > > --- > > drivers/gpu/drm/i915/i915_drv.h | 1 + > >

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Clean up AUX power domain handling

On Thu, Nov 12, 2015 at 10:02:36AM +0100, Patrik Jakobsson wrote: > On Wed, Nov 11, 2015 at 08:37:36PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 11, 2015 at 08:22:03PM +0200, Imre Deak wrote: > > > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > > > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant check in i915_gem_obj_to_vma

On Thu, Nov 12, 2015 at 11:59:55AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > No need to verify VMA belongs to GGTT since: > > 1. The function must return a normal VMA belonging to passed in VM. > 2. There can only be one normal VMA for any VM. > >

Re: [Intel-gfx] [PATCH v7 0/3] fbdev fixes (reviewed)

On Thu, 12 Nov 2015, Lukas Wunner wrote: > I use msmtp instead of git send-email, which preserves the Date-header. Any particular reason not to use git send-email? You can configure it to use a sendmail-like program instead of a server, and actually that's the default. If you

[Intel-gfx] [PATCH v7] drm/i915: A better backlight class brightness range.

Expose the whole valid PWM brightness range to the backlight class and respect the VBT minimum backlight brightness. Signed-off-by: Shih-Yuan Lee (FourDollars) --- drivers/gpu/drm/i915/intel_panel.c | 31 ++- 1 file changed, 14 insertions(+), 17

[Intel-gfx] [PATCH v7] drm/i915: A better backlight class brightness range.

Since v3.17-rc1, it contains commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness The backlight class 0 brightness means the PWM min and it does not

Re: [Intel-gfx] [RFC PATCH] drm/i915: Consider SPLL as another shared pll.

On Wed, 21 Oct 2015, Daniel Vetter wrote: > On Wed, Sep 16, 2015 at 09:23:59AM +0200, Maarten Lankhorst wrote: >> When diagnosing a unrelated bug for someone on irc, it would seem the >> hardware can >> be brought up by the BIOS with the embedded displayport using the SPLL for

Re: [Intel-gfx] [PATCH 09/12] drm/i915: Explain usage of power well IDs vs bit groups

On Wed, Nov 11, 2015 at 09:13:27PM +0200, Imre Deak wrote: > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > Signed-off-by: Patrik Jakobsson > > --- > > drivers/gpu/drm/i915/i915_reg.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/gen9: Turn DC handling into a power well

On to, 2015-11-12 at 13:24 +0100, Patrik Jakobsson wrote: > On Wed, Nov 11, 2015 at 08:57:19PM +0200, Imre Deak wrote: > > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > > Handle DC off as a power well where enabling the power well will > > > prevent > > > the DMC to enter selected

Re: [Intel-gfx] [PATCH] drm/i915: Do a better job at disabling primary plane in the noatomic case.

Op 12-11-15 om 14:37 schreef Ander Conselvan De Oliveira: > On Wed, 2015-11-11 at 15:36 +0100, Maarten Lankhorst wrote: >> When disable_noatomic is called plane_mask is not reliable yet, >> and plane_state->visible = true even after disabling the primary plane. > So the stale value of

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant check in i915_gem_obj_to_vma

On Thu, 12 Nov 2015, Chris Wilson wrote: > On Thu, Nov 12, 2015 at 11:59:55AM +, Tvrtko Ursulin wrote: >> From: Tvrtko Ursulin >> >> No need to verify VMA belongs to GGTT since: >> >> 1. The function must return a normal VMA belonging to

Re: [Intel-gfx] [PATCH 3/3] drm/i915: refactor stepping info retrieval

On Wed, 21 Oct 2015, Jani Nikula wrote: > On Wed, 21 Oct 2015, Daniel Vetter wrote: >> On Tue, Oct 20, 2015 at 03:38:33PM +0300, Jani Nikula wrote: >>> Have only one if ladder for platforms and only one range check for >>> size. Makes it easier to handle

Re: [Intel-gfx] [PATCH 01/10] drm/i915: fix the power well ID for always on wells

On Wed, Nov 04, 2015 at 07:24:10PM +0200, Imre Deak wrote: > lookup_power_well() expects uniq power well IDs, but atm we have > uninitialized IDs which would clash with those power wells with a 0 > ID. This wasn't a problem so far since nothing looked up such a power > well, but an upcoming patch

Re: [Intel-gfx] [PATCH 01/10] drm/i915: fix the power well ID for always on wells

On Wed, Nov 04, 2015 at 07:24:10PM +0200, Imre Deak wrote: > lookup_power_well() expects uniq power well IDs, but atm we have > uninitialized IDs which would clash with those power wells with a 0 > ID. This wasn't a problem so far since nothing looked up such a power > well, but an upcoming patch

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Rodrigo Vivi >Sent: Thursday, November 12, 2015 1:07 AM >To: intel-gfx@lists.freedesktop.org >Cc: Vivi, Rodrigo >Subject: [Intel-gfx] [PATCH 0/4] PSR Critical fixes > >Let's split critical

Re: [Intel-gfx] [V2 PATCH 1/2] dp/mst: add SDP stream support

Hi Jani, Do you have time to have a review? Thanks. Regards, Libin > -Original Message- > From: libin.y...@linux.intel.com [mailto:libin.y...@linux.intel.com] > Sent: Wednesday, November 11, 2015 1:33 PM > To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, >

Re: [Intel-gfx] [PATCH v3 03/13] drm/i915/gen9: move assert_csr_loaded into intel_rpm.c

On Thu, 12 Nov 2015, Imre Deak wrote: > On ke, 2015-10-28 at 23:58 +0200, Imre Deak wrote: >> From: Daniel Vetter >> >> Avoids non-static functions since all the callers are in intel_rpm.c. >> >> Cc: Damien Lespiau >> Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Do a better job at disabling primary plane in the noatomic case.

On Wed, 2015-11-11 at 15:36 +0100, Maarten Lankhorst wrote: > When disable_noatomic is called plane_mask is not reliable yet, > and plane_state->visible = true even after disabling the primary plane. So the stale value of plane_state->visible causes a subsequent modeset to enable the primary

Re: [Intel-gfx] [PATCH 02/10] drm/i915: fix lookup_power_well for power wells without any domain

On Wed, Nov 04, 2015 at 07:24:11PM +0200, Imre Deak wrote: > The current lookup code wouldn't find a power well if it's not in any > power domain. There wasn't any power wells before but an upcoming patch > will detach the power domains from power well#1 and the MISC IO power > wells, so fix

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

Hi Rodrigo, >-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Rodrigo Vivi >Sent: Thursday, November 12, 2015 1:07 AM >To: intel-gfx@lists.freedesktop.org >Cc: Vivi, Rodrigo >Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR

Re: [Intel-gfx] [PATCH 01/10] drm/i915: fix the power well ID for always on wells

On to, 2015-11-12 at 15:39 +0200, Ville Syrjälä wrote: > On Wed, Nov 04, 2015 at 07:24:10PM +0200, Imre Deak wrote: > > lookup_power_well() expects uniq power well IDs, but atm we have > > uninitialized IDs which would clash with those power wells with a 0 > > ID. This wasn't a problem so far

Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again

On Thu, 12 Nov 2015, Stéphane ANCELOT wrote: > Hi, > I have seen you were working on brightness. Right, but this is useful > only if many worlwide users would be able to activate it. > I have never been able to make it working on my intel systemes (core i5 > - 4300u , core i3

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences

On Wed, Nov 04, 2015 at 07:24:12PM +0200, Imre Deak wrote: > From: Damien Lespiau > > Before this patch, we used the intel_display_power_{get,put} functions > to make sure the PW1 and Misc I/O power wells were enabled all the > time while LCPLL was enabled. We called a

Re: [Intel-gfx] [PATCH v7 0/3] fbdev fixes (reviewed)

Hi Jani, On Mon, Nov 09, 2015 at 04:23:34PM +0200, Jani Nikula wrote: > On Sat, 07 Nov 2015, Lukas Wunner wrote: > > three patches with fbdev deadlock & failure path fixes, > > each with Reviewed-by tag by Ville or Daniel, the third one > > with amended commit message as

Re: [Intel-gfx] [PATCH v3 03/13] drm/i915/gen9: move assert_csr_loaded into intel_rpm.c

On to, 2015-11-12 at 16:48 +0200, Jani Nikula wrote: > On Thu, 12 Nov 2015, Imre Deak wrote: > > On ke, 2015-10-28 at 23:58 +0200, Imre Deak wrote: > > > From: Daniel Vetter > > > > > > Avoids non-static functions since all the callers are in > > >

[Intel-gfx] [PATCH v4 04/13] drm/i915/gen9: Remove csr.state, csr_lock and related code.

From: Daniel Vetter This removes two anti-patterns: - Locking shouldn't be used to synchronize with async work (of any form, whether callbacks, workers or other threads). This is what the mutex_lock/unlock seems to have been for in intel_csr_load_program. Instead

Re: [Intel-gfx] [PATCH v3 00/13] drm/i915: Redesign dmc firmware loading.

On Wed, 28 Oct 2015, Imre Deak wrote: > This is a rebased version of [1], addressing the review comments. It > depends on Mika's FW version blacklisting/capture patchset [2]. Entire series pushed to drm-intel-next-queued, thanks for everyone involved. BR, Jani. -- Jani

[Intel-gfx] [PATCH v4 09/13] drm/i915/gen9: extract parse_csr_fw

From: Daniel Vetter The loader function will get a bit more complicated soon, extract the parsing code to make the control flow clearer. While doing that just use dev_priv->csr.dmc_payload as the indicator for whether it all suceeded or not. v2-v3: - unchanged v4: -

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On to, 2015-11-12 at 17:04 +, Chris Wilson wrote: > On Thu, Nov 12, 2015 at 06:40:18PM +0200, Imre Deak wrote: > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index 825114a..ee3ef69 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Give meaningful names to all the planes

On Thu, Nov 12, 2015 at 05:38:48PM +, Emil Velikov wrote: > Hi Ville, > > On 12 November 2015 at 16:52, wrote: > > From: Ville Syrjälä > > > > Let's name our planes in a way that makes sense wrt. the spec: > > - skl+ -> "plane

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton doesn't use gen9 scaling for rps frequencies.

On Thu, 12 Nov 2015 10:35:00 +0200 Imre Deak wrote: > On Wed, 2015-11-11 at 13:36 -0800, Bob Paauwe wrote: > > On Tue, 10 Nov 2015 11:04:22 +0200 > > Mika Kuoppala wrote: > > > > > Bob Paauwe writes: > > > > > > >

Re: [Intel-gfx] [PATCH i-g-t] igt/pm_rps: current freq < user specified min is no longer a fail

On Thu, 12 Nov 2015 11:18:11 +0200 Imre Deak wrote: > On ke, 2015-11-11 at 13:37 -0800, Bob Paauwe wrote: > > Since commit > > > > commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581 > > Author: Chris Wilson > > Date: Wed Mar 18 09:48:21 2015

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

On Thu, Nov 12, 2015 at 06:40:18PM +0200, Imre Deak wrote: > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 825114a..ee3ef69 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2962,6 +2962,9 @@ static void

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL i_boost level

On Wed, Nov 11, 2015 at 03:15:54PM +0200, Ander Conselvan de Oliveira wrote: > The i_boost level in the DDI translation tables are stored per level. > However, skl_ddi_set_iboos() would choose an entry of that table based > on the port argument. > > Cc: Jim Bride >

[Intel-gfx] [PATCH 4/6] 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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Give meaningful names to all the planes

Hi Ville, On 12 November 2015 at 16:52, wrote: > 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",

[Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

Atm, we assert that the device is not suspended until the point when the HW is truly put to a suspended state. This is fine, but we can catch more problems if we check the RPM refcount. After that one drops to zero we shouldn't access the HW any more, although the actual suspend may be delayed.

[Intel-gfx] [PATCH v3 5/7] drm/i915: sanitize the asserts in the RPM get/put helpers

There is no point in checking the refcount just after increasing it so remove the assert from the get helper. Otoh, we should check the refcount before decreasing it, so add it to the put helper. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- 1

[Intel-gfx] [PATCH v3 2/7] drm/i915: add assert_rpm_wakelock_held helper

As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception

[Intel-gfx] [PATCH v3 7/7] drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters

The device should be on for the whole duration of the update, so check for this. v2: - use the existing dev_priv directly everywhere (Ville) v3: - check also that we are in an RPM atomic section (Chris) - add the assert to i915_ggtt_insert_entries/clear_range too (Chris) Signed-off-by: Imre Deak

[Intel-gfx] [PATCH v3 0/7] drm/i915: improve the RPM device suspended assert

This is v3 of [1]. I addressed the review comments from Ville and Chris and added an RPM atomic section check as well requested by Chris. I was also considering using lockdep for more coverage, but decided to leave that out for now, we can also add that later if needed. The patchset depends on

[Intel-gfx] [PATCH v3 3/7] drm/i915: use assert_rpm_wakelock_held instead of opencoding it

Signed-off-by: Imre Deak Reviewed-by: Chris Wilson (v1) --- drivers/gpu/drm/i915/intel_runtime_pm.c | 10 -- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git

[Intel-gfx] [PATCH v3 1/7] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers

We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms

[Intel-gfx] [PATCH 0/6] drm: Give crtcs and planes actual names

From: Ville Syrjälä I got sick and tired of staring at the line noise produced by drm.debug=0x1e, so I decided to give the crtcs and planes human readable names. Each driver can give whatever names it wants, and for i915 I gave something that makes some sense

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

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56 +++-- drivers/gpu/drm/drm_crtc.c

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

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

[Intel-gfx] [PATCH 2/6] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä 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 | 3 +++ include/drm/drm_crtc.h

[Intel-gfx] [PATCH 6/6] 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. Signed-off-by:

[Intel-gfx] [PATCH v3 6/7] drm/i915: add support for checking RPM atomic sections

In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic

Re: [Intel-gfx] [PATCH 0/5] Sink CRC stabilization

On Thu, 2015-11-12 at 12:17 +0200, Jani Nikula wrote: > On Wed, 11 Nov 2015, Rodrigo Vivi wrote: > > Let's start spliting that big series that enables PSR with this > > sink crc > > stabilization. > > > > Also I'm adding Wayne's mutex that stabilizes sink CRC on Skylake.

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

On 12.11.2015 10:28, Lankhorst, Maarten wrote: Hey, Gabriel Feceoru schreef op wo 11-11-2015 om 20:27 [+0200]: On 11.11.2015 16:21, Jani Nikula wrote: On Wed, 11 Nov 2015, Ander Conselvan De Oliveira wrote: On Tue, 2015-11-10 at 14:53 +0200, Jani Nikula wrote:

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Give meaningful names to all the planes

On Thu, Nov 12, 2015 at 07:49:19PM +0200, Ville Syrjälä wrote: > On Thu, Nov 12, 2015 at 05:38:48PM +, Emil Velikov wrote: > > Hi Ville, > > > > On 12 November 2015 at 16:52, wrote: > > > From: Ville Syrjälä > > > > > > Let's

Re: [Intel-gfx] [PATCH 0/5] Sink CRC stabilization

On Thu, Nov 12, 2015 at 10:56 AM Vivi, Rodrigo wrote: > On Thu, 2015-11-12 at 12:17 +0200, Jani Nikula wrote: > > On Wed, 11 Nov 2015, Rodrigo Vivi wrote: > > > Let's start spliting that big series that enables PSR with this > > > sink crc > > >

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters

On Thu, Nov 12, 2015 at 06:40:21PM +0200, Imre Deak wrote: > The device should be on for the whole duration of the update, so check > for this. > > v2: > - use the existing dev_priv directly everywhere (Ville) > v3: > - check also that we are in an RPM atomic section (Chris) > - add the assert to

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Sanitize watermarks after hardware state readout (v2)

On Thu, Nov 05, 2015 at 02:55:20PM +0200, Jani Nikula wrote: > On Thu, 05 Nov 2015, Matt Roper wrote: > > On Wed, Nov 04, 2015 at 04:12:33PM +0200, Jani Nikula wrote: > >> On Tue, 03 Nov 2015, Matt Roper wrote: > >> > Although we can do a