[Intel-gfx] [PATCH] drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.

This patch is to correct one thing in this commit: commit 25a56705332add0363e47b3a0eca001d6fbd5bec Author: Dongwon Kim Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit For BXT, description of polarities of

[Intel-gfx] [PATCH V2 3/3] DRRS status on sysfs interface

This interface allows viewing the status of the DRRS. Exposing this feature on sysfs interface would allow tools such as powertop to provide status of the Graphics subsystem and aid debugging RPM Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH V2 2/3] FBC status on sysfs interface

This interface allows viewing the status of the FBC. Exposing this feature on sysfs interface would allow tools such as powertop to provide status of the Graphics subsystem and aid debugging RPM Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH V2 1/3] PSR status on sysfs interface

This interface allows viewing the status of the PSR. Exposing this feature on sysfs interface would allow tools such as powertop to provide status of the Graphics subsystem and aid debugging RPM. Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH V2 0/3] RPM Graphics Features

Summary: Permits the user to identify during runtime the values set for PSR, FBC, and DRRS. The values are displayed under /sys/class/drm/card0/power/ By enabling these features I'm looking to empower our customers, such as, power team, chrome OS, and platform integration teams to debug

[Intel-gfx] [PATCH v5 11/24] backlight: lp855x: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 19/24] pwm: move the enabled/disabled info into pwm_state

Prepare the transition to PWM atomic update by moving the enabled/disabled state into the pwm_state struct. This way we can easily update the whole PWM state by copying the new state in the ->state field. Signed-off-by: Boris Brezillon --- drivers/pwm/core.c

[Intel-gfx] [PATCH v5 23/24] pwm: switch to the atomic API

Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls by pwm_get/apply_state(). Signed-off-by: Boris Brezillon --- drivers/pwm/core.c | 5 - drivers/pwm/sysfs.c | 61 +++-- 2 files

[Intel-gfx] [PATCH v5 18/24] pwm: introduce the pwm_state concept

The PWM state, represented by its period, duty_cycle and polarity, is currently directly stored in the PWM device. Declare a pwm_state structure embedding those field so that we can later use this struct to atomically update all the PWM parameters at once. All pwm_get_xxx() helpers are now

[Intel-gfx] [PATCH v5 14/24] input: misc: pwm-beeper: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 15/24] drm: i915: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 22/24] pwm: update documentation

Update the PWM subsystem documentation to reflect the atomic PWM changes. Signed-off-by: Boris Brezillon --- Documentation/pwm.txt | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/pwm.txt

[Intel-gfx] [PATCH v5 24/24] pwm: add information about polarity, duty cycle and period to debugfs

From: Heiko Stübner The pwm-states make it possible to also output the polarity, duty cycle and period information in the debugfs pwm summary-outout. This makes it easier to gather overview information about pwms without needing to walk through the sysfs attributes of every pwm.

[Intel-gfx] [PATCH v5 21/24] pwm: add the core infrastructure to allow atomic update

Add an ->apply() method to the pwm_ops struct to allow PWM drivers to implement atomic update. This method will be preferred over the ->enable(), ->disable() and ->config() methods if available. Add the pwm_apply_state() function to the PWM user API. Note that the pwm_apply_state() does not

[Intel-gfx] [PATCH v5 06/24] leds: pwm: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 16/24] ARM: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 17/24] pwm: keep PWM state in sync with hardware state

Before the introduction of pwm_args, the core was resetting the PWM period and polarity states to the reference values (those provided through the DT, a PWM lookup table or hardcoded in the driver). Now that all PWM users are correctly using pwm_args to configure their PWM device, we can safely

[Intel-gfx] [PATCH v5 10/24] backlight: lp8788: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 09/24] backlight: pwm_bl: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 12/24] backlight: lm3630a: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 13/24] input: misc: max8997: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[Intel-gfx] [PATCH v5 20/24] pwm: add the PWM initial state retrieval infra

Add a ->get_state() function to the pwm_ops struct to let PWM drivers initialize the PWM state attached to a PWM device. Signed-off-by: Boris Brezillon --- drivers/pwm/core.c | 3 +++ include/linux/pwm.h | 28 2 files changed,

[Intel-gfx] [PATCH v5 08/24] fbdev: ssd1307fb: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 07/24] regulator: pwm: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 05/24] input: misc: max77693: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 03/24] clk: pwm: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 04/24] hwmon: pwm-fan: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[Intel-gfx] [PATCH v5 01/24] pwm: introduce the pwm_args concept

Currently the PWM core mixes the current PWM state with the per-platform reference config (specified through the PWM lookup table, DT definition or directly hardcoded in PWM drivers). Create a pwm_args struct to store this reference config, so that PWM users can differentiate the current config

[Intel-gfx] [PATCH v5 00/24] pwm: add support for atomic update

Hello, This series adds support for atomic PWM update, or IOW, the capability to update all the parameters of a PWM device (enabled/disabled, period, duty and polarity) in one go. It also adds support for initial PWM state retrieval (or hardware readout), which should allow smooth handover

[Intel-gfx] [PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate

Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx field. Doing that will ease adaptation of the PWM framework to support atomic update. Signed-off-by: Boris Brezillon --- Patch generated with the following coccinelle script: --->8---

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

On Tue, Mar 29, 2016 at 04:46:30PM -0400, Lyude wrote: > On Valleyview, VGA hotplugging is controlled through a seperate register > than everything else, VLV_ADPA, which must be explicitly set. > > While VGA hotplugging worked(ish) before, it looks like that was mainly > because we'd

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915:bxt: Enable Pooled EU support

== Series Details == Series: drm/i915:bxt: Enable Pooled EU support URL : https://patchwork.freedesktop.org/series/5725/ State : failure == Summary == Series 5725v1 drm/i915:bxt: Enable Pooled EU support http://patchwork.freedesktop.org/api/1.0/series/5725/revisions/1/mbox/ Test

[Intel-gfx] [PATCH 04/14] drm/i915: use drm_crtc_send_vblank_event()

From: Gustavo Padovan Replace the legacy drm_send_vblank_event() with the new helper function. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Show pin mapped status in describe_obj

== Series Details == Series: series starting with [1/2] drm/i915: Show pin mapped status in describe_obj URL : https://patchwork.freedesktop.org/series/5716/ State : failure == Summary == Series 5716v1 Series without cover letter

[Intel-gfx] [PATCH 3/3] drm/i915/guc: drop cached copy of 'wq_head'

From: Alex Dai Now that we keep the GuC client structure (and therefore the process descriptor embedded therein) permanently mapped, we don't really need to keep a local copy of the GuC's work-queue-head. So we can simplify the code a little by not doing this. Signed-off-by:

[Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC objects mapped in kernel

With the new i915_gem_obj_pin_map() interface, it makes sense to keep GuC objects (which are always pinned in memory and in the GGTT anyway) mapped into kernel address space, rather than mapping and unmapping them on each access. This preliminary patch sets up the pin-and-map for all GuC-specific

[Intel-gfx] [PATCH 2/3] drm/i915/guc: stop using kmap_atomic() during request submission

From: Alex Dai Now that we keep GuC shared objects mapped into kernel space for their entire lifetime, we can simplify the code for accessing the doorbells and work queue, which were previously calling kmap_atomic() on *each* request submission. This patch fixes the BUG shown

[Intel-gfx] [PATCH v4 3/3] drm/i915/dp/mst: Add source port info to debugfs output

Modify the debugfs output for i915_dp_mst_info to list the source port for the DP MST topology in question. v2: rebase v3: rebase v4: rebase cc: Jani Nikula Reviewed-by: Jani Nikula Signed-off-by: Jim Bride ---

[Intel-gfx] [PATCH v4 1/3] drm/edid: Add drm_edid_get_monitor_name()

In order to include monitor name information in debugfs output we needed to add a function that would extract the monitor name from the EDID, and that function needed to reside in the file where the rest of the EDID helper functions are implemented. v2: Refactor to have

[Intel-gfx] [PATCH v4 2/3] drm/dp/mst: Enhance DP MST debugfs output

Add some additional information (input vs. output port, sink associated with VC, peer device type, max number of VCs supported) and ensure that any embedded '\0' characters in a branch device's devid string are not written to debugfs. v2: Rebase + change drm_edid_get_monitor_name() call to

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On 04/14/2016 02:48 AM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 10:06:57PM +, Vivi, Rodrigo wrote: On Wed, 2016-04-13 at 22:46 +0200, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo < rodrigo.v...@intel.com> wrote: On Wed, 2016-04-13 at 16:50 +0200, Daniel

Re: [Intel-gfx] [PATCH v5 3/4] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

On Wed, Apr 13, 2016 at 10:58:32AM -0400, Lyude wrote: > This is part of a patch series to migrate all of the workarounds for > commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's > DP helper. > > Some sinks will just return garbage for the first aux tranaction they >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Use readl/writel for ring buffer access

== Series Details == Series: series starting with [1/3] drm/i915: Use readl/writel for ring buffer access URL : https://patchwork.freedesktop.org/series/5714/ State : failure == Summary == Series 5714v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix eDP low vswing for Broadwell (rev3)

On Wed, Apr 13, 2016 at 05:07:04PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix eDP low vswing for Broadwell (rev3) > URL : https://patchwork.freedesktop.org/series/4499/ > State : failure > > == Summary == > > CC drivers/usb/host/xhci-trace.o > CC

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

On Thu, Apr 14, 2016 at 05:29:31PM +0300, Ville Syrjälä wrote: > On Mon, Apr 11, 2016 at 10:06:28AM +0100, Chris Wilson wrote: > > On Mon, Apr 11, 2016 at 11:34:54AM +0300, Ville Syrjälä wrote: > > > On Sat, Apr 09, 2016 at 11:14:44AM +0100, Chris Wilson wrote: > > > > In order for the

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On Thu, Apr 14, 2016 at 04:07:58PM +0100, Dave Gordon wrote: > On 14/04/16 12:58, Tvrtko Ursulin wrote: > > > >On 14/04/16 12:30, Chris Wilson wrote: > >>On Thu, Apr 14, 2016 at 12:24:20PM +0100, Tvrtko Ursulin wrote: > >>> > >>>On 14/04/16 12:16, Chris Wilson wrote: > On Thu, Apr 14, 2016 at

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: introduce and use i915_gem_object_map_range()

== Series Details == Series: series starting with [1/2] drm/i915: introduce and use i915_gem_object_map_range() URL : https://patchwork.freedesktop.org/series/5691/ State : failure == Summary == Series 5691v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915:bxt: Enable Pooled EU support

From: Tim Gore This is a re-send of patch 3/3 from Arun Siluvery's patch series "Add Pooled EU support to BXT", originally submitted 20 July 2015. Patches 1 and 2 are already merged in preparation. This final patch actually enables the feature. The rest of this commit message

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On 14/04/16 12:58, Tvrtko Ursulin wrote: On 14/04/16 12:30, Chris Wilson wrote: On Thu, Apr 14, 2016 at 12:24:20PM +0100, Tvrtko Ursulin wrote: On 14/04/16 12:16, Chris Wilson wrote: On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH] drm/i915: Provide a modparam to disable firmware loading

On Thu, Apr 14, 2016 at 11:27:25AM +0300, Jani Nikula wrote: > On Wed, 13 Apr 2016, Ben Widawsky wrote: > > +module_param_named_unsafe(disable_firmware_loading, > > i915.disable_firmware_loading, uint, 0400); > > +MODULE_PARM_DESC(disable_firmware_loading, > > + "Bypass

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable FBC on SKL (rev4)

== Series Details == Series: Enable FBC on SKL (rev4) URL : https://patchwork.freedesktop.org/series/4722/ State : success == Summary == Series 4722v4 Enable FBC on SKL http://patchwork.freedesktop.org/api/1.0/series/4722/revisions/4/mbox/ Test gem_busy: Subgroup basic-blt:

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update eDRAM calculation

On Thu, Apr 14, 2016 at 07:48:13AM -0700, Ben Widawsky wrote: > On Thu, Apr 14, 2016 at 11:14:48AM +0300, Jani Nikula wrote: > > On Thu, 14 Apr 2016, Jani Nikula wrote: > > > On Wed, 13 Apr 2016, Ben Widawsky wrote: > > >> The two behavioral

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update eDRAM calculation

On Thu, Apr 14, 2016 at 11:14:48AM +0300, Jani Nikula wrote: > On Thu, 14 Apr 2016, Jani Nikula wrote: > > On Wed, 13 Apr 2016, Ben Widawsky wrote: > >> The two behavioral changes here are the correct detection of the eDRAM > >> size on > >> gen9

Re: [Intel-gfx] [PATCH] mm/vmalloc: Keep a separate lazy-free list

On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson wrote: > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: >> Hi, Chris. >> >> Is it made on purpose not to drop VM_LAZY_FREE flag in >> __purge_vmap_area_lazy()? With your patch va->flags >> will have two bits

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

On Thu, Apr 14, 2016 at 05:29:31PM +0300, Ville Syrjälä wrote: > On Mon, Apr 11, 2016 at 10:06:28AM +0100, Chris Wilson wrote: > > On Mon, Apr 11, 2016 at 11:34:54AM +0300, Ville Syrjälä wrote: > > > On Sat, Apr 09, 2016 at 11:14:44AM +0100, Chris Wilson wrote: > > > > In order for the

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

On Mon, Apr 11, 2016 at 10:06:28AM +0100, Chris Wilson wrote: > On Mon, Apr 11, 2016 at 11:34:54AM +0300, Ville Syrjälä wrote: > > On Sat, Apr 09, 2016 at 11:14:44AM +0100, Chris Wilson wrote: > > > In order for the MI_SEMAPHORE_SIGNAL command to wait until after the > > > pipecontrol writing the

Re: [Intel-gfx] [PATCH] mm/vmalloc: Keep a separate lazy-free list

On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: > Hi, Chris. > > Is it made on purpose not to drop VM_LAZY_FREE flag in > __purge_vmap_area_lazy()? With your patch va->flags > will have two bits set: VM_LAZY_FREE | VM_LAZY_FREEING. > Seems it is not that bad, because all other

Re: [Intel-gfx] [PATCH 08/10] drm: Forbid legacy MAP functions for DRIVER_MODESET

On 14 April 2016 at 11:06, Daniel Vetter wrote: > On Wed, Mar 30, 2016 at 11:39:01AM +0100, Emil Velikov wrote: >> On 30 March 2016 at 10:45, Daniel Vetter wrote: >> > Like in >> > >> > commit 0e975980d435d58df2d430d688b8c18778b42218 >> > Author: Peter

Re: [Intel-gfx] [PATCH] mm/vmalloc: Keep a separate lazy-free list

Hi, Chris. Is it made on purpose not to drop VM_LAZY_FREE flag in __purge_vmap_area_lazy()? With your patch va->flags will have two bits set: VM_LAZY_FREE | VM_LAZY_FREEING. Seems it is not that bad, because all other code paths do not care, but still the change is not clear. Also, did you

[Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev3)

== Series Details == Series: Unduplicate CHV phy code (rev3) URL : https://patchwork.freedesktop.org/series/5463/ State : failure == Summary == Series 5463v3 Unduplicate CHV phy code http://patchwork.freedesktop.org/api/1.0/series/5463/revisions/3/mbox/ Test drv_module_reload_basic:

Re: [Intel-gfx] [i-g-t PATCH v1 00/14] Get a few more tests to run on !i915

Hi, On 5 March 2016 at 12:34, Daniel Vetter wrote: > On Wed, Mar 02, 2016 at 03:00:07PM +0100, Tomeu Vizoso wrote: >> have restarted work on getting tests in IGT to run on drivers other than >> i915. >> >> These changes make the modified tests pass in a Radxa Rock2 board by >>

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

ville.syrj...@linux.intel.com writes: > [ text/plain ] > From: Ville Syrjälä > > On VLV/CHV the master interrupt enable bit only affects GT/PM > interrupts. Display interrupts are not affected by the master > irq control. > > Also it seems that the CPU interrupt

Re: [Intel-gfx] [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV

On Thu, Apr 14, 2016 at 11:37:49AM +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 09:09:30PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On CHV GTFIFODBG has some read-only bits to indicate the number > > of free FIFO entries.

Re: [Intel-gfx] [PATCH] drm/i915: Use fw_domains_put_with_fifo() on HSW

On Thu, Apr 14, 2016 at 02:51:02PM +0300, Mika Kuoppala wrote: > ville.syrj...@linux.intel.com writes: > > > [ text/plain ] > > From: Ville Syrjälä > > > > HSW still has the wake FIFO, so let's check it. > > > > Cc: Mika Kuoppala > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Show pin mapped counts and sizes in debugfs

On Thu, Apr 14, 2016 at 12:57:02PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Show a total and purgeable number of pin mapped objects > and their total and purgeable size. > > Example output (new stat prefixed with a star): > > # cat i915_gem_objects >

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Thu, Apr 14, 2016 at 10:36:00AM +0100, Chris Wilson wrote: > On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On VLV/CHV the master interrupt enable bit only affects GT/PM > > interrupts. Display

Re: [Intel-gfx] [PATCH] drm/i915: Use fw_domains_put_with_fifo() on HSW

On Thu, Apr 14, 2016 at 02:51:02PM +0300, Mika Kuoppala wrote: > ville.syrj...@linux.intel.com writes: > > > [ text/plain ] > > From: Ville Syrjälä > > > > HSW still has the wake FIFO, so let's check it. > > > > Cc: Mika Kuoppala > >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On 14/04/16 12:30, Chris Wilson wrote: On Thu, Apr 14, 2016 at 12:24:20PM +0100, Tvrtko Ursulin wrote: On 14/04/16 12:16, Chris Wilson wrote: On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin We know ringbuffers are memory and

[Intel-gfx] [PATCH 2/2] drm/i915: Show pin mapped counts and sizes in debugfs

From: Tvrtko Ursulin Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168]

[Intel-gfx] [PATCH 1/2] drm/i915: Show pin mapped status in describe_obj

From: Tvrtko Ursulin Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Provide a modparam to disable firmware loading

== Series Details == Series: drm/i915: Provide a modparam to disable firmware loading URL : https://patchwork.freedesktop.org/series/5675/ State : warning == Summary == Series 5675v1 drm/i915: Provide a modparam to disable firmware loading

Re: [Intel-gfx] [PATCH] drm/i915: Use fw_domains_put_with_fifo() on HSW

ville.syrj...@linux.intel.com writes: > [ text/plain ] > From: Ville Syrjälä > > HSW still has the wake FIFO, so let's check it. > > Cc: Mika Kuoppala > Cc: Deepak S > Fixes: 05a2fb157e44 ("drm/i915:

Re: [Intel-gfx] [PATCH] drm/i915: Use fw_domains_put_with_fifo() on HSW

On Thu, Apr 14, 2016 at 02:39:02PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > HSW still has the wake FIFO, so let's check it. > > Cc: Mika Kuoppala > Cc: Deepak S > Fixes:

[Intel-gfx] [PATCH] drm/i915: Use fw_domains_put_with_fifo() on HSW

From: Ville Syrjälä HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala Cc: Deepak S Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On Thu, Apr 14, 2016 at 12:24:20PM +0100, Tvrtko Ursulin wrote: > > On 14/04/16 12:16, Chris Wilson wrote: > >On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>We know ringbuffers are memory and not ports so if we use

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On 14/04/16 12:16, Chris Wilson wrote: On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin We know ringbuffers are memory and not ports so if we use readl and writel instead of ioread32 and iowrite32 (which dispatch to the very same

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use writel instead of iowrite32 when doing GTT relocations

On Thu, Apr 14, 2016 at 11:59:30AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We know that our aperture is memory and not ports so we can use > the correct accessors straight away and avoid function calls. There are much more complete patches to fix a host

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We know ringbuffers are memory and not ports so if we use readl > and writel instead of ioread32 and iowrite32 (which dispatch to > the very same functions after checking the

Re: [Intel-gfx] [PATCH v5 01/46] pwm: rcar: make use of pwm_is_enabled()

Hi Thierry On Tue, 12 Apr 2016 13:01:52 +0200 Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:24PM +0200, Boris Brezillon wrote: > > Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a > > new function to test whether a PWM device is enabled

Re: [Intel-gfx] [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV

On Thu, Apr 14, 2016 at 11:37:49AM +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 09:09:30PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On CHV GTFIFODBG has some read-only bits to indicate the number > > of free FIFO entries.

[Intel-gfx] [PATCH 1/3] drm/i915: Use readl/writel for ring buffer access

From: Tvrtko Ursulin We know ringbuffers are memory and not ports so if we use readl and writel instead of ioread32 and iowrite32 (which dispatch to the very same functions after checking the address range) we avoid generating functions calls and branching on every

[Intel-gfx] [PATCH 3/3] drm/i915: Use writel instead of iowrite32 when programming page table entries

From: Tvrtko Ursulin We know that the underlying area is memory and not ports so we can use the correct accessor straight away to save on function calls. Especially since the gen8_set_pte already mixes writeq and iowrite32 depending on the kernel config.

[Intel-gfx] [PATCH 2/3] drm/i915: Use writel instead of iowrite32 when doing GTT relocations

From: Tvrtko Ursulin We know that our aperture is memory and not ports so we can use the correct accessors straight away and avoid function calls. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++--- 1

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/4] drm/dp_helper: Always wait before retrying native aux transactions

== Series Details == Series: series starting with [v5,1/4] drm/dp_helper: Always wait before retrying native aux transactions URL : https://patchwork.freedesktop.org/series/5667/ State : failure == Summary == Series 5667v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr (rev2) URL : https://patchwork.freedesktop.org/series/5649/ State : success == Summary == Series 5649v2 Series without cover letter

Re: [Intel-gfx] [for-CI-v2] drm/i915/mocs: Program MOCS for all engines on init

On Wed, Apr 13, 2016 at 03:03:25PM +0100, Chris Wilson wrote: > From: Peter Antoine > > Allow for the MOCS to be programmed for all engines. > Currently we program the MOCS when the first render batch > goes through. This works on most platforms but fails on > platforms

Re: [Intel-gfx] [PATCH 08/10] drm: Forbid legacy MAP functions for DRIVER_MODESET

On Wed, Mar 30, 2016 at 11:39:01AM +0100, Emil Velikov wrote: > On 30 March 2016 at 10:45, Daniel Vetter wrote: > > Like in > > > > commit 0e975980d435d58df2d430d688b8c18778b42218 > > Author: Peter Antoine > > Date: Tue Jun 23 08:18:49 2015

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, Apr 13, 2016 at 10:06:57PM +, Vivi, Rodrigo wrote: > On Wed, 2016-04-13 at 22:46 +0200, Daniel Vetter wrote: > > On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo < > > rodrigo.v...@intel.com> wrote: > > > On Wed, 2016-04-13 at 16:50 +0200, Daniel Vetter wrote: > > > > On Wed, Apr 13,

Re: [Intel-gfx] [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV

On Wed, Apr 13, 2016 at 09:09:30PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On CHV GTFIFODBG has some read-only bits to indicate the number > of free FIFO entries. Ignore these when checking to see if any > of the sticky error bits are

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On VLV/CHV the master interrupt enable bit only affects GT/PM > interrupts. Display interrupts are not affected by the master > irq control. > > Also it seems

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rest of my DSI and DPLL stuff

On Thu, Apr 14, 2016 at 11:54:53AM +0300, Tomi Sarvela wrote: > On Thursday 14 April 2016 11:46:12 Ville Syrjälä wrote: > > On Thu, Apr 14, 2016 at 10:24:23AM +0300, Tomi Sarvela wrote: > > > On Wednesday 13 April 2016 19:29:25 Ville Syrjälä wrote: > > > [ILK-hp8440p problems] > > > > > > > ... >

[Intel-gfx] ✓ Fi.CI.BAT: success for ci-run of edram size patches

== Series Details == Series: ci-run of edram size patches URL : https://patchwork.freedesktop.org/series/5663/ State : success == Summary == Series 5663v1 ci-run of edram size patches http://patchwork.freedesktop.org/api/1.0/series/5663/revisions/1/mbox/ Test drv_hangman: Subgroup

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rest of my DSI and DPLL stuff

On Thursday 14 April 2016 11:46:12 Ville Syrjälä wrote: > On Thu, Apr 14, 2016 at 10:24:23AM +0300, Tomi Sarvela wrote: > > On Wednesday 13 April 2016 19:29:25 Ville Syrjälä wrote: > > [ILK-hp8440p problems] > > > > > ... > > > > > > [ 265.316531] drm/i915: Resetting chip after gpu hang > > > [

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Thu, Apr 14, 2016 at 09:32:30AM +0100, Chris Wilson wrote: > On Thu, Apr 14, 2016 at 11:22:48AM +0300, Ville Syrjälä wrote: > > On Wed, Apr 13, 2016 at 09:53:38PM +0100, Chris Wilson wrote: > > > On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com > > > wrote: > > > > +

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rest of my DSI and DPLL stuff

On Thu, Apr 14, 2016 at 10:24:23AM +0300, Tomi Sarvela wrote: > On Wednesday 13 April 2016 19:29:25 Ville Syrjälä wrote: > [ILK-hp8440p problems] > > ... > > > > [ 265.316531] drm/i915: Resetting chip after gpu hang > > [ 265.316585] [drm:i915_reset [i915]] *ERROR* Failed to reset chip: -110 >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI-ping,01/15] drm/i915: Force clean compilation with -Werror (rev3)

== Series Details == Series: series starting with [CI-ping,01/15] drm/i915: Force clean compilation with -Werror (rev3) URL : https://patchwork.freedesktop.org/series/5612/ State : failure == Summary == Series 5612v3 Series without cover letter

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Thu, Apr 14, 2016 at 11:22:48AM +0300, Ville Syrjälä wrote: > On Wed, Apr 13, 2016 at 09:53:38PM +0100, Chris Wilson wrote: > > On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > + /* > > > + * Theory on interrupt generation, based on

Re: [Intel-gfx] [PATCH] drm/i915: Provide a modparam to disable firmware loading

On Wed, 13 Apr 2016, Ben Widawsky wrote: > +module_param_named_unsafe(disable_firmware_loading, > i915.disable_firmware_loading, uint, 0400); > +MODULE_PARM_DESC(disable_firmware_loading, > + "Bypass loading of firmware based on mask. This overrides all other > firmware

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Wed, Apr 13, 2016 at 09:53:38PM +0100, Chris Wilson wrote: > On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On VLV/CHV the master interrupt enable bit only affects GT/PM > > interrupts. Display

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update eDRAM calculation

On Thu, 14 Apr 2016, Jani Nikula wrote: > On Wed, 13 Apr 2016, Ben Widawsky wrote: >> The two behavioral changes here are the correct detection of the eDRAM size >> on >> gen9 (SKL + KBL), and unconditional printing of the eLLC size. >> >> Cc:

  1   2   >