Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote: > On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula > wrote: > >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" >> wrote: >> > On Mon, Nov 9, 2015 at 6:17 PM, Jani

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On Mon, Nov 09, 2015 at 03:36:10PM +0200, Imre Deak wrote: > On ma, 2015-11-09 at 13:25 +, Chris Wilson wrote: > > On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote: > > > Looked through it, it seems only i915_gem_set_tiling() could > > > release > > > the PTE's without waking up the

Re: [Intel-gfx] [PATCH v2 06/14] drm/i915: Update watermark related members in the crtc_state, v2.

On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote: > This removes another couple of hacks from intel_crtc->atomic, and > creates proper atomic state for it. Perhaps you could be more verbose about the hacks being removed. > Changes since v1: > - Rebase on top of wm changes. > >

Re: [Intel-gfx] [PATCH v2 07/14] drm/i915: Kill off intel_crtc->atomic.wait_vblank.

On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote: > By handling this after the atomic helper waits for vblanks there will > be one less wait for vblank in the atomic path. I found this a bit confusing. Sounds like you are referring to calling intel_post_enable_update() after the call to

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

On Sat, 07 Nov 2015, Lukas Wunner wrote: > Hi Jani, > > 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 requested by Daniel in > <20151030182818.GR16848@phenom.ffwll.local>. > >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

Hi Ankitprasad, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.3 next-20151109] url: https://github.com/0day-ci/linux/commits/ankitprasad-r-sharma-intel-com/Support-for-mapping-an-object-page-by-page/20151109-191910 base: git://anongit.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, Nov 9, 2015 at 8:58 PM, Jani Nikula wrote: > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" > wrote: > > On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula > > > wrote: > > > >> On Mon, 09 Nov 2015, "Shih-Yuan

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote: > Looked through it, it seems only i915_gem_set_tiling() could release > the PTE's without waking up the hardware (if no need to unbind the > object). Otherwise it's true that all callers hold (or should hold) > already an RPM ref. To fix

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On pe, 2015-11-06 at 08:54 +, Chris Wilson wrote: > On Fri, Nov 06, 2015 at 12:57:35AM +0200, Imre Deak wrote: > > On Thu, 2015-11-05 at 11:56 +, Chris Wilson wrote: > > > On Thu, Nov 05, 2015 at 01:28:32PM +0200, Imre Deak wrote: > > > > On ke, 2015-11-04 at 20:57 +, Chris Wilson

Re: [Intel-gfx] [PATCH i-g-t 4/8] kms_frontbuffer_tracking: Allow to skip suspend_resume sub test case.

2015-11-05 18:40 GMT-02:00 Ville Syrjälä : > On Thu, Nov 05, 2015 at 06:34:07PM -0200, Paulo Zanoni wrote: >> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi : >> > There are few platforms with other suspend resume bugs that breaks >> > the full

Re: [Intel-gfx] [PATCH i-g-t 8/8] tests/kms_fbc_crc: ensure context is initialized correctly

On 4 November 2015 at 19:36, Zanoni, Paulo R wrote: > Em Seg, 2015-11-02 às 11:48 +, Thomas Wood escreveu: >> Initialization was included in commit a976d7e (tests/kms_fbc_crc: >> refactor context >> handling code), but won't be executed since it is declared before

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On ma, 2015-11-09 at 13:25 +, Chris Wilson wrote: > On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote: > > Looked through it, it seems only i915_gem_set_tiling() could > > release > > the PTE's without waking up the hardware (if no need to unbind the > > object). Otherwise it's true

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote: > The device should be on when updating the GGTT PTEs, so add an assert to > all relevant places. > > v2: > - use the existing dev_priv directly everywhere (Ville) > > Signed-off-by: Imre Deak For completeness, add

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

On Mon, 2015-11-09 at 23:24 +0200, Imre Deak wrote: > On Mon, 2015-11-09 at 21:11 +, Chris Wilson wrote: > > On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote: > > > The device should be on when updating the GGTT PTEs, so add an assert to > > > all relevant places. > > > > > > v2: > >

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

On Mon, 2015-11-09 at 21:11 +, Chris Wilson wrote: > On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote: > > The device should be on when updating the GGTT PTEs, so add an assert to > > all relevant places. > > > > v2: > > - use the existing dev_priv directly everywhere (Ville) > > >

Re: [Intel-gfx] [PATCH 2/4] drm/i915: use assert_device_not_suspended instead of opencoding it

On Mon, Nov 09, 2015 at 08:20:09PM +0200, Imre Deak wrote: > Signed-off-by: Imre Deak Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

Should I improve this patch or you have rejected this patch? Regards, $4 On Mon, Nov 09, 2015 at 06:57:22PM +0200, Jani Nikula wrote: > On Mon, 09 Nov 2015, Paulo Zanoni wrote: > > 2015-11-09 8:17 GMT-02:00 Jani Nikula : > >> On Mon, 09 Nov 2015,

[Intel-gfx] [PATCH i-g-t] lib: add a environment variable to control output

Disable output of terminal control characters and progress meters when IGT_PLAIN_OUTPUT is set in the environment. Cc: Derek Morton Signed-off-by: Thomas Wood --- lib/igt_aux.c | 2 +- lib/igt_core.c | 23 ++-

[Intel-gfx] [PATCH] drm/i915: Add Backlight Control using DPCD for eDP connectors (v2)

This patch adds support for eDP backlight control using DPCD registers to backlight hooks in intel_panel. It checks for backlight control over AUX channel capability and sets up function pointers to get and set the backlight brightness level if supported. v2: Moved backlight functions from

Re: [Intel-gfx] [PATCH] drm/i915: Print a debug message when exceeding dotclock limit on pre-gen4

On Wed, Nov 04, 2015 at 05:41:16PM +0200, Ander Conselvan De Oliveira wrote: > Reviewed-by: Ander Conselvan de Oliveira Pushed to dinq. Thanks for the review. > On Fri, 2015-10-30 at 23:39 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 06/14] drm/i915: Update watermark related members in the crtc_state, v2.

On Mon, Nov 09, 2015 at 05:10:40PM +0100, Maarten Lankhorst wrote: > Op 09-11-15 om 15:48 schreef Ander Conselvan De Oliveira: > > On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote: > >> This removes another couple of hacks from intel_crtc->atomic, and > >> creates proper atomic state for

Re: [Intel-gfx] [PATCH 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

On ma, 2015-11-09 at 20:37 +0200, Ville Syrjälä wrote: > On Mon, Nov 09, 2015 at 08:20:11PM +0200, Imre Deak wrote: > > The device should be on when updating the GGTT PTEs, so add an > > assert to > > all relevant places. > > > > Signed-off-by: Imre Deak > > --- > >

Re: [Intel-gfx] [PATCH 1/7] drm/i915/skl: Store and print the DMC firmware version we load

On Wed, Nov 04, 2015 at 05:18:28PM +, Daniel Stone wrote: > Hi, > > On 27 October 2015 at 12:46, Mika Kuoppala > wrote: > > From: Damien Lespiau > > > > That can be handy later on to tell which DMC firmware version the user > > has,

[Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_tiling IOCTL

After fixing the same issue in the set_caching IOCTL and Chris' request to check out the possibilities for an improved RPM ref handling I noticed that we have the same issue in the set_tiling IOCTL. Fix this up.I didn't see any bug reports about this one, but the GTT unbind operation on this path

Re: [Intel-gfx] [PATCH] drm/i915: Avoid pointer arithmetic in calculating plane surface offset

On Fri, Oct 30, 2015 at 11:40:46AM +, Tvrtko Ursulin wrote: > > On 30/10/15 11:26, Mika Kuoppala wrote: > > VMA offsets are 64 bits. Plane surface offsets are in ggtt and > > the hardware register to set this is thus 32 bits. Be explicit > > about these and convert carefully to from vma to

Re: [Intel-gfx] [PATCH 1/4] drm/i915: export assert_device_not_suspended

On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote: > We should use the same assert in more places, so export it. Move it to > intel_runtime_pm.c at the same time, since that's a more logical place > for it. > > Signed-off-by: Imre Deak > --- >

[Intel-gfx] [PATCH 1/4] drm/i915: export assert_device_not_suspended

We should use the same assert in more places, so export it. Move it to intel_runtime_pm.c at the same time, since that's a more logical place for it. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 6

[Intel-gfx] [PATCH 3/4] drm/i915: make assert_device_not_suspended more precise

Atm, we assert that the device is not suspended after 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 2/4] drm/i915: use assert_device_not_suspended instead of opencoding it

Signed-off-by: Imre Deak --- 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 a/drivers/gpu/drm/i915/intel_runtime_pm.c

[Intel-gfx] [PATCH 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

The device should be on when updating the GGTT PTEs, so add an assert to all relevant places. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

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

Motivated by the discussions with Chris about imrpoving our RPM ref get/put logic and seeing that we are still missing RPM refs from places I improved a bit the assert that checks if the device is powered on while we are accessing the HW. This produced at least one additional assert on the atomic

Re: [Intel-gfx] [PATCH 1/4] drm/i915: export assert_device_not_suspended

On ma, 2015-11-09 at 20:30 +0200, Ville Syrjälä wrote: > On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote: > > We should use the same assert in more places, so export it. Move it > > to > > intel_runtime_pm.c at the same time, since that's a more logical > > place > > for it. > > > >

[Intel-gfx] [PATCH 1/2] drm/dp: Add definition for Display Control DPCD Registers capability size

cc: Jani Nikula Signed-off-by: Yetunde Adebisi --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1252108..92d9a52 100644 ---

Re: [Intel-gfx] [PATCH 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

On Mon, Nov 09, 2015 at 08:20:11PM +0200, Imre Deak wrote: > The device should be on when updating the GGTT PTEs, so add an assert to > all relevant places. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 8 > 1 file changed, 8

Re: [Intel-gfx] [PATCH v2 06/14] drm/i915: Update watermark related members in the crtc_state, v2.

Op 09-11-15 om 15:48 schreef Ander Conselvan De Oliveira: > On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote: >> This removes another couple of hacks from intel_crtc->atomic, and >> creates proper atomic state for it. > Perhaps you could be more verbose about the hacks being removed.

[Intel-gfx] [PATCH 01/12] drm/i915: Don't trust CSR program memory contents

Replaces "drm/i915: Force loading of csr program at boot" in the old series. Previously we called blindly into intel_csr_load_program() and depended on a check of whether the CSR program memory was cleared or not. This check is not reliable and no longer needed since we fixed the call-sites of

[Intel-gfx] [PATCH] drm/i915: Change context lifecycle

Use the first retired request on a new context to unpin the old context. This ensures that the hw context remains bound until it has been saved. Now that the context is pinned until later in the request/context lifecycle, it no longer needs to be pinned from context_queue to retire_requests. The

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

2015-11-09 8:17 GMT-02:00 Jani Nikula : > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" > wrote: >> The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however >> the sysfs brightness level always starts from 0 so it is better

Re: [Intel-gfx] [PATCH v2 08/14] drm/i915: Remove intel_crtc->atomic.disable_ips.

On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote: > This is already handled in pre_disable_primary, disabling it twice is useless. The atomic.disable_ips field was added in commit 066cf55b9ce35f1f90dde9fcec01431a9243a949 Author: Rodrigo Vivi Date: Fri Jun 26

[Intel-gfx] [PATCH 04/12] drm/i915: Introduce a gmbus power domain

From: Ville Syrjälä Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the

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

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 power well will allow DC states again. For now the highest DC state is DC6 for Skylake and DC5 for Broxton but will be configurable for

[Intel-gfx] [PATCH 05/12] drm/i915: Remove DDI power domain exclusion SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS

From: Ville Syrjälä All the DDI power domains are already excluded from SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS on account of excluding SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS and SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, no need to spell them out again. Signed-off-by:

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

Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e6d88f5..31b3a84 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++

[Intel-gfx] [PATCH 07/12] drm/i915: Add a modeset power domain

We need a power domain for disabling DC5/DC6 around modesets to prevent confusing the DMC. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ drivers/gpu/drm/i915/i915_drv.h | 1 + 2 files changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH 06/12] drm/i915: Remove distinction between DDI 2 vs 4 lanes

We never make use of the distinction between 2 vs 4 lanes so combine them into a per port domain instead. This saves us a few bits in the power domain mask. Change suggested by Ville. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_debugfs.c |

[Intel-gfx] [PATCH v2 00/12] Skylake DMC/DC-state fixes and redesign

This v2 of the series is rebased on top of a new series from Imre [1] and contains a few new patches and reordering. These patches should sit on top of the DMC redesign patches from Animesh/Imre [2] which in turn depends on Mika's FW debug patches [3]. First couple of patches are from Ville and

[Intel-gfx] [PATCH 08/12] drm/i915: Do not warn on PG2 enabled in gen9_disable_dc5()

PG2 enabled is not a requirement for disabling DC5. It's just one of the reasons why the DMC wouldn't enter DC5. During modeset we don't care about PG2 from a DC perspective, only the fact that DC5/DC6 is not allowed. Signed-off-by: Patrik Jakobsson Reviewed-by:

[Intel-gfx] [PATCH 02/12] drm/i915/gen9: Always set mask memory up when enabling DC5 or DC6

Move call to gen9_set_dc_state_debugmask_memory_up() into gen9_set_dc_state() to prevent us missing it somewhere. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/intel_runtime_pm.c | 35 - 1 file changed, 17

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

From: Ville Syrjälä Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not

[Intel-gfx] [PATCH 12/12] drm/i915/skl: Remove unused suspend and resume callbacks

Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_drv.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0c7f435..77d183d 100644 ---

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

v2: Use _unsafe (Jani) Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_params.c | 6 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++-- 3 files changed, 9 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, 09 Nov 2015, Paulo Zanoni wrote: > 2015-11-09 8:17 GMT-02:00 Jani Nikula : >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" >> wrote: >>> The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, Nov 09, 2015 at 10:02:24PM +0800, Shih-Yuan Lee (FourDollars) wrote: > On Mon, Nov 9, 2015 at 8:58 PM, Jani Nikula > wrote: > > > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" > > wrote: > > > On Mon, Nov 9, 2015 at 6:51 PM, Jani

Re: [Intel-gfx] [PATCH i-g-t] lib: add a environment variable to control output

On Mon, Nov 09, 2015 at 05:17:13PM +, Thomas Wood wrote: > Disable output of terminal control characters and progress meters when > IGT_PLAIN_OUTPUT is set in the environment. > > Cc: Derek Morton > Signed-off-by: Thomas Wood > --- >

Re: [Intel-gfx] [PATCH 1/4] drm/i915: export assert_device_not_suspended

On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote: > We should use the same assert in more places, so export it. Move it to > intel_runtime_pm.c at the same time, since that's a more logical place > for it. > > Signed-off-by: Imre Deak > --- >

[Intel-gfx] [PATCH v2 4/4] drm/i915: add assert_device_not_suspended to GGTT PTE updaters

The device should be on when updating the GGTT PTEs, so add an assert to all relevant places. v2: - use the existing dev_priv directly everywhere (Ville) Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 1 file changed, 8 insertions(+) diff

[Intel-gfx] [PATCH v2 3/4] drm/i915: make assert_device_not_suspended more precise

Atm, we assert that the device is not suspended after 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.

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_tiling IOCTL

On Mon, Nov 09, 2015 at 08:16:26PM +0200, Imre Deak wrote: > After fixing the same issue in the set_caching IOCTL and Chris' request > to check out the possibilities for an improved RPM ref handling I > noticed that we have the same issue in the set_tiling IOCTL. Fix this > up.I didn't see any bug

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

ankitprasad.r.sha...@intel.com writes: > From: Ankitprasad Sharma > > In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, > we try a nonblocking pin for the whole object (since that is fastest if > reused), then failing that we try to grab one

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c

On Sun, Nov 08, 2015 at 05:44:37PM +0100, Lukas Wunner wrote: > Hi Ville, > > On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Reading the driver load/unload code leaves one confused as there's > > an

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Mon, Nov 09, 2015 at 10:45:14AM +0200, Jani Nikula wrote: > On Sun, 08 Nov 2015, Damien Lespiau wrote: > > There are two new patchwork projects then: > > > > http://patchwork.freedesktop.org/project/intel-gpu-tools/ > >

[Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

From: Ankitprasad Sharma In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, we try a nonblocking pin for the whole object (since that is fastest if reused), then failing that we try to grab one page in the mappable aperture. It also allows us

[Intel-gfx] [PATCH v3 0/3] Support for mapping an object page by page

From: Ankitprasad Sharma It is possible that when we want to map an object to the aperture, either we run out of aperture space or the size of the object is larger than the mappable aperture. In such cases we might not be able to map the whole object to the

[Intel-gfx] [PATCH 1/3] drm/i915: Add support for mapping an object page by page

From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated over to access the whole object by using space as meagre as page

[Intel-gfx] [PATCH 2/3] drm/i915: Introduce i915_gem_object_get_dma_address()

From: Chris Wilson This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with any page within the object. Signed-off-by: Chris Wilson

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Mon, 09 Nov 2015, Damien Lespiau wrote: > That would work for us, but not in the general case (for other > projects). I was thinking of using some kind of other heuristic, eg. > (subject, commit message, files touched) with a levenshtein distance on > text to allow

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Mon, Nov 09, 2015 at 01:21:33PM +0200, Jani Nikula wrote: > On Mon, 09 Nov 2015, Damien Lespiau wrote: > > That would work for us, but not in the general case (for other > > projects). I was thinking of using some kind of other heuristic, eg. > > (subject, commit

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

Signed-off-by: Bob Paauwe Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768 --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index

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

Beginning with SKL the DP Aux channel communication can be protected using a built in H/W mutex. This patch provides an initial implementation for using that mutex. The use is currently limited to protecting the sink crc request based on feedback from the H/W designers indicating that using the

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: make assert_device_not_suspended more precise

On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote: > Atm, we assert that the device is not suspended after 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

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula wrote: > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" > wrote: > > The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however > > the sysfs brightness level always starts from 0 so

Re: [Intel-gfx] [PATCH 24/31] drm/i915: PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT.

On Thu, 05 Nov 2015, Rodrigo Vivi wrote: > Since the beginning there is a confusion on the meaning of this bit. > > A previous patch had identified this already and fixed it partially: > 'commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic") > >

Re: [Intel-gfx] [PATCH 25/31] drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT.

On Thu, 05 Nov 2015, Rodrigo Vivi wrote: > On the commit 3301d4092106 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT > logic")' > we already had identified that DP_PSR_NO_TRAIN_ON_EXIT > doesn't mean we shouldn't send TPS patterns, however we start sending the > minimal TP1

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote: > On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula > wrote: > >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" >> wrote: >> > The PWM brightness level of Dell XPS 13

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote: > The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however > the sysfs brightness level always starts from 0 so it is better to use > 927 as the sysfs maximum brightness level and it becomes easier to

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a fw content lost issue after it is evicted

On Fri, Nov 06, 2015 at 03:18:37PM -0800, Yu Dai wrote: > > > On 11/06/2015 02:07 PM, Chris Wilson wrote: > >On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote: > >> From: Alex Dai > >> > >> We keep a copy of GuC fw in a GEM obj. However its content is lost > >>

Re: [Intel-gfx] [PATCH] drm: Add aux plane verification in addFB2

On 11/5/2015 10:50 PM, Vandana Kannan wrote: From: Daniel Vetter For render compression, userspace passes aux stride and offset values as an additional entry in the fb structure. This should not be treated as garbage and discarded as data belonging to no plane. This

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Sun, 08 Nov 2015, Damien Lespiau wrote: > There are two new patchwork projects then: > > http://patchwork.freedesktop.org/project/intel-gpu-tools/ > http://patchwork.freedesktop.org/project/libdrm-intel/ > > I've also run the sorting on all the existing patches so

Re: [Intel-gfx] [PATCH] drm/i915: quirk backlight present on Macbook 4, 1

Reviewed-by: Ander Conselvan de Oliveira On Thu, 2015-11-05 at 11:49 +0200, Jani Nikula wrote: > Unsurprisingly macbooks have backlights, just the VBT doesn't seem to > know it in this case. > > Reported-and-tested-by: Daniel Nicoletti > Bugzilla:

Re: [Intel-gfx] Hardlock problems when switching monitor channels and questions (Skylake)

On Sun, 2015-11-01 at 12:48 +0100, Maarten Maathuis wrote: > Hi everyone. > > I've been some hardlock problems when switching from the HDMI connection of my > monitor (connected to another PC) and the displayport (connected to the > problematic PC), several times a week at least. > > In an

Re: [Intel-gfx] [PATCH 07/31] drm/i915: IPS Sysfs interface.

Hi Rodrigo, On 5 November 2015 at 18:49, Rodrigo Vivi wrote: > diff --git a/drivers/gpu/drm/i915/intel_ips.c > b/drivers/gpu/drm/i915/intel_ips.c > index b867aba..6bc5c55 100644 > --- a/drivers/gpu/drm/i915/intel_ips.c > +++ b/drivers/gpu/drm/i915/intel_ips.c > @@

Re: [Intel-gfx] [PATCH 00/31] IPS/DRRS/PSR rework with PSR enabled by default

Hi Rodrigo, On 5 November 2015 at 18:49, Rodrigo Vivi wrote: > So I'm confident we can enable PSR back by default now. > > All comments, ideas, suggestions and even bikesheddings are pretty welcome. You did ask for it ... I've been looking at pulling this on top of

Re: [Intel-gfx] [PATCH] drm/i915: A better maximum brightness for users.

On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula wrote: > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" > wrote: > > On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula > > > wrote: > > > >> On Mon, 09 Nov 2015, "Shih-Yuan

[Intel-gfx] HDMI hotplug fails when using VT or boot on text mode

When using i915 O.S. Ubuntu 15.10 Pltaform: Bay Trail I Issue: When the O.S. is on Virtual Terminal or Text Mode it doesn't detect when connecting HDMI display, the issue is not present on graphic mode. Is this expected behavior? Best Regards, Adolfo.