[Intel-gfx] [PATCH 22/29] drm/i915: Give names to more ring registers

From: Ville Syrjälä The logical render context population has a bunch of raw ring register offsets. Use the names we have for them, and in cases where we we don't, give them names. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 23/29] drm/i915: Wrap context LRI init in a macro

From: Ville Syrjälä We set up a load of LRIs in the logical ring context. Wrap that stuff in a macro to avoid typos with position of each reg/value pair in the context. This also makes it easier to make the register defines type safe. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 26/29] drm/i915: Add 'offset' to uncore funcs

From: Ville Syrjälä Add 'uint32_t offset' to the uncore register access functions. For now it's the same as 'reg', but once type safety gets added 'reg' will be the type safe register variable and 'offset' the raw offset. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 17/29] drm/i915: Make the high dword offset more explicit in i915_reg_read_ioctl

From: Ville Syrjälä Store the upper dword of the register offset in the whitelist as well. This would allow it to read register where the two halves aren't sitting right next to each other, and it'll make it easier to make register access type safe. While at it

[Intel-gfx] [PATCH 24/29] drm/i915: Turn vgpu pdps into an array

From: Ville Syrjälä We'll want to avoid performing arithmetic with register offsets, so instead calculating the vgpu PDP as pdp0_lo+offset, make the PDPs into an array. This way we can simply loop through them. Cc: Eddie Dong Cc: Jike Song

[Intel-gfx] [PATCH 15/29] drm/i915: Parametrize MOCS registers

From: Ville Syrjälä Cc: Francisco Jerez Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 12 ++-- drivers/gpu/drm/i915/intel_mocs.c | 41 --- 2

[Intel-gfx] [PATCH 21/29] drm/i915: Wrap ASSIGN_CTX_{PDP, PM4L} in do {} while(0)

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

[Intel-gfx] [PATCH 20/29] drm/i915: Add wa_ctx_emit_reg()

From: Ville Syrjälä Add a helper for emitting register offsets (for LRI/SRM) into the w/a batch buffer. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_lrc.c | 10 ++ 1 file changed, 6 insertions(+), 4

[Intel-gfx] [PATCH 16/29] drm/i915: s/0x50/RING_PSMI_CTL/

From: Ville Syrjälä Use the RING_PSMI_CTL define insted of hand rolling the register offset. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 28/29] drm/i915: Add missing ')' to SKL_PS_ECC_STAT define

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

On 11/04/2015 12:26 PM, Zanoni, Paulo R wrote: > Em Qua, 2015-11-04 às 14:19 -0600, Jason Wessel escreveu: >> On 11/04/2015 02:13 PM, Jesse Barnes wrote: >>> On 11/04/2015 11:10 AM, Paulo Zanoni wrote: From our maintainer Daniel Vetter a few days ago: "Oh dear this is dead code. kdbg

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix eDP panel fitting (v2)

On Wed, 4 Nov 2015 09:05:27 -0800 Matt Roper wrote: > BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths > store panel fitter information in pipe_config->pch_pfit. However since > HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in

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

On Wed, Nov 04, 2015 at 09:25:32PM +0200, Imre Deak wrote: > After Damien's D3 fix I started to get runtime suspend residency for the > first time and that revealed a breakage on the set_caching IOCTL path > that accesses the HW but doesn't take an RPM ref. Fix this up. Why here (and in so many

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

Em Qua, 2015-11-04 às 14:19 -0600, Jason Wessel escreveu: > On 11/04/2015 02:13 PM, Jesse Barnes wrote: > > On 11/04/2015 11:10 AM, Paulo Zanoni wrote: > > >  From our maintainer Daniel Vetter a few days ago: > > >    "Oh dear this is dead code. kdbg uses the fbcon, which always > > > uses > > >   

[Intel-gfx] [PATCH v3 04/29] drm/i915: Parametrize AUX registers

From: Ville Syrjälä v2: Keep some MISSING_CASE() stuff (Jani) s/-1/-PIPE_B/ in the register macro Fix typo in patch subject v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani) Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH v2 05/29] drm/i915: Add dev_priv->psr_mmio_base

From: Ville Syrjälä Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset under dev_priv, like we for DSI and GPIO for example. TODO: could probably move a bunch of this kind of stuff into the device info instead... v2: Drop the spurious

[Intel-gfx] [PATCH 02/29] drm/i915: Remove the magic AUX_CTL is at DP + foo tricks

From: Ville Syrjälä Currently we determine the location of the AUX registers in a confusing way. First we assume the PCH registers are used always, but then we override it for everything but HSW/BDW to use DP+0x10. Very confusing. Let's just make it

[Intel-gfx] [PATCH 08/29] drm/i915: s/PCH_DP_/PORT_/ in intel_trans_dp_port_sel() and move it next to its only user

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/intel_display.c | 22 +++--- drivers/gpu/drm/i915/intel_dp.c | 19 --- 3

[Intel-gfx] [PATCH 03/29] drm/i915: Replace the aux ddc name switch statement with a table

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

[Intel-gfx] [PATCH v2 07/29] drm/i915: Model PSR AUX register selection more like the normal AUX code

From: Ville Syrjälä v2: Split up the ctl vs. data reg handling like in the normal AUX code Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_psr.c | 27 +-- 1 file changed, 21 insertions(+), 6

[Intel-gfx] [PATCH 01/29] pci: Decouple quirks.c from i915_reg.h

From: Ville Syrjälä i915 register defines are going to become type safe, so going forward the register defines can't be used as straight numbers. Since quirks.c needs just a few extra register defines from i915_reg.h, decouple the two by defining the required

Re: [Intel-gfx] [PATCH 0/8] Skylake DMC/DC-state fixes and redesign

On Wed, Nov 4, 2015 at 6:17 PM, Daniel Stone wrote: > Hi, > > On 3 November 2015 at 12:31, Patrik Jakobsson > wrote: >> These patches should sit on top of the DMC redesign patches from >> Animesh/Imre [1] which in turn depends on Mika's FW

[Intel-gfx] [PATCH 25/29] drm/i915: Pull the vgpu uncore funcs apart from the rest of gen6+

From: Ville Syrjälä I need to add a new variable into GEN6_{READ,WRITE}_HEADER, but the vgpu won't need it, so let's avoid an unused variable warning by splitting the vgpu stuff to use its own macros. Cc: Eddie Dong Cc: Jike Song

[Intel-gfx] [PATCH 10/29] drm/i915: s/is_sdvob/enum port/

From: Ville Syrjälä Replace the is_sdvob bool and some sdvo_reg checks with enum port. This makes the SDVO code look more modern, and gets rid of explicit register offset checks in the code which will hamper register type checking. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 18/29] drm/i915: Make the cmd parser 64bit regs explicit

From: Ville Syrjälä Add defines for the upper halves of the registers used by the cmd parser. Getting rid of the arithmetic with the register offset will help in making registers type safe. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 13/29] drm/i915: Prefix raw register defines with underscore

From: Ville Syrjälä Most of our register defines follow the convention that if there's a need for the raw register offset, that one has an underscore sa a prefix. The define (possibly parametrized) without the underscore is the one people should normally use, since

[Intel-gfx] [PATCH v2 00/29] drm/i915: Type safe register read/write (v2) and more prep work

From: Ville Syrjälä Another round of stuff for the type safe register access. Some of these were already posted during the first round, but a lot of it is new (LRI stuff, cmd parser, lrc setup etc., vgpu, etc.) Available as a git branch too:

[Intel-gfx] [PATCH v3 06/29] drm/i915: Store aux data reg offsets in intel_dp->aux_ch_data_reg[]

From: Ville Syrjälä Rather than computing on demand, store also the aux data reg offsets under intel_dp. v2: Duplicate some code to make things less magic (Jani) v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg() Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 09/29] drm/i915: Replace aux_ch_ctl_reg check with port check

From: Ville Syrjälä Instead of checking what aux_ch_ctl_reg is, we can simply check the port when determining the right timeout value to program. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 3 +-- 1 file

[Intel-gfx] [PATCH 14/29] drm/i915: Parametrize L3 error registers

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 6 ++ 3 files changed, 6 insertions(+), 9 deletions(-)

[Intel-gfx] [PATCH 12/29] drm/i915: Streamline gpio_mmio_base deduction

From: Ville Syrjälä If we ignore the BXT situation, we can observe that the only variables affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT situation we can fit into the same pattern if we change gmbus_pins_bxt[] to house the GMCH GPIO

Re: [Intel-gfx] [PATCH 2/2] drm/i915/kbl: Kabylake uses the same GMS values as Skylake

Hi Jani, could you please consider to merge this already reviewed patch. Thanks, Rodrigo. On Thu, Oct 29, 2015 at 10:22 AM Rodrigo Vivi wrote: > From: Deepak S > > Reviewed-by: Damien Lespiau > Signed-off-by: Deepak S

[Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a new subtest to exhaustively test for fence leaks (v3)

In this subtest, as a first step, MAX_FENCES+1 number of framebuffers are created backed up by objects that have multiple GGTT views (normal and rotated). Next, we have the i915 driver instantiate a normal view followed by a rotated view. We continue doing the above MAX_FENCES + 1 times. v2: -

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

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 good job of reading out hardware state, the > > graphics firmware may have programmed the watermarks in a creative way > > that doesn't match

[Intel-gfx] [PATCH] igt/igt_kms: Introduce get_first_connected_output (v2)

In some cases, we just need one valid (connected) output to perform a test. This macro can help in these situations by not having to put the test code inside a for loop that iterates over all the outputs. v2: Added a brief documentation for this macro. Suggested-by: Matt Roper Cc: Thomas Wood

[Intel-gfx] [PATCH] gbm: Add a flag to enable creation of rotated scanout buffers (v2)

For certain platforms that support rotated scanout buffers, currently, there is no way to create them with the GBM DRI interface. This flag will instruct the DRI driver to create the buffer by setting additional requirements such as tiling mode. v2: Reserve a bit per angle. (Ville and Michel)

Re: [Intel-gfx] [PATCH 2/2] drm/i915: force link training when requested by Sink

Looks good to me. Reviewed-by: Sonika Jindal

Re: [Intel-gfx] [PATCH] drm/i915: Cleanup test data during long/short hotplug

Looks good to me. Reviewed-by: Sonika Jindal

[Intel-gfx] [v2] drm/i915/skl: While sanitizing cdclock check the SWF18 as well

SWF18 is set if the display has been intialized by the pre-os. It also gives what configuration is enabled on which pipe. In skl_sanitize_cdclk, the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS enables DPLL for integrated audio codec related programming. So fisrt check if

Re: [Intel-gfx] [PATCH 24/29] drm/i915: Turn vgpu pdps into an array

On Wed, Nov 04, 2015 at 11:20:12PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We'll want to avoid performing arithmetic with register offsets, so > instead calculating the vgpu PDP as pdp0_lo+offset, make the PDPs > into an array. This

Re: [Intel-gfx] [PATCH 25/29] drm/i915: Pull the vgpu uncore funcs apart from the rest of gen6+

On Wed, Nov 04, 2015 at 11:20:13PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I need to add a new variable into GEN6_{READ,WRITE}_HEADER, but the vgpu > won't need it, so let's avoid an unused variable warning by splitting > the vgpu

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Add a modeset power domain

On Wed, Nov 4, 2015 at 6:29 PM, Ville Syrjälä wrote: > On Tue, Nov 03, 2015 at 01:31:10PM +0100, Patrik Jakobsson wrote: >> We need DC5/DC6 to be disabled around modesets to prevent confusing the >> DMC. Also, we've run out of bits in the 32 bit power domain mask so

Re: [Intel-gfx] [PATCH i-g-t 2/8] lib: highlight subtest results on terminals

2015-11-02 9:48 GMT-02:00 Thomas Wood : > Make subtest results easier to identify by making them bold when the output > is a terminal. Cool! A long time ago I suggested using different colors when writing SUCCESS/FAIL/SKIP/CRASH (green, red, yellow, orange) and I was told

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

On Wed, Nov 04, 2015 at 07:36:04PM +, 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 the > > first

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

On 11/04/2015 11:10 AM, Paulo Zanoni wrote: > From our maintainer Daniel Vetter a few days ago: > "Oh dear this is dead code. kdbg uses the fbcon, which always uses > untiled, which means fbc will never be enabled. Also we have 0 users > and 0 test coverage for kdbg on top of i915 (Jesse

[Intel-gfx] [PATCH 13/13] drm/i915: remove newline from a no_fbc_reason message

Newlines are not needed and they're not used by the other messages. I added the newline by mistake. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c

[Intel-gfx] [PATCH 06/13] drm/i915: fix the __intel_fbc_update() comments

Don't try to list in comments the cases where we should enable or disable FBC: it varies a lot with the hardware generations and the code should be the documentation. Also notice that there's already a huge gap between the comments and what's in the code. Signed-off-by: Paulo Zanoni

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

After Damien's D3 fix I started to get runtime suspend residency for the first time and that revealed a breakage on the set_caching IOCTL path that accesses the HW but doesn't take an RPM ref. Fix this up. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_gem.c | 8

Re: [Intel-gfx] [PATCH 6/8] drm/i915/skl: Turn DC handling into a power well

On Wed, Nov 4, 2015 at 6:53 PM, Ville Syrjälä wrote: > On Tue, Nov 03, 2015 at 01:31:12PM +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

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

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 the > first > label within a switch statement. > > kms_fbc_crc.c:178:2: warning:

[Intel-gfx] [PATCH 09/13] drm/i915: remove too-frequent FBC debug message

If we run igt/kms_frontbuffer_tracking, this message will appear thousands of times, eating a significant part of our dmesg buffer. It's part of the expected FBC behavior, so let's just silence it. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 2 --

[Intel-gfx] [PATCH 05/13] drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()

This change was part of the commit that makes intel_fbc_update() receive an intel_crtc as argument instead of dev_priv, but since it was polluting the diff with too many chunks I decided to move it to its own commit. It seems that our developers are favoring having this instead of the old

[Intel-gfx] [PATCH 08/13] drm/i915: refactor FBC deactivation at init

Make sure we deactivate FBC at intel_fbc_init(), so we can remove the call from intel_display.c. Currently we only have the "enabled" software state, but later we'll have both "enabled" and "active", and we'll add assertions to them, so just calling intel_fbc_disable() from intel_modeset_init()

[Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

Hi So Ville pointed a problem on patch 02/26 of the previous series, and the nice fix for that would make me rebase most of the subsequent patches. In order to avoid blocking the other patches on the review of patch 02 and in order to avoid having to rebase everything again and again during this

[Intel-gfx] [PATCH 03/13] drm/i915: remove unnecessary check for crtc->primary->fb

We already check if the CRTC is visible, and it shouldn't be possible to have a visible CRTC without an FB. This was noticed by both Chris and Ville on different ocasions. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 11/13] drm/i915: clarify that checking the FB stride for CFB is intentional

Daniel was looking at this code and asked about whether fb->pitches[0] is correct, then he suggested we should a comment to make sure it is actually intentional. For more information on the CFB size calculation, please see the commit message of: commit c4ffd40908c30a33291227920e921f6b45b9e8f7

[Intel-gfx] [PATCH 02/13] drm/i915: extract fbc_on_pipe_a_only()

Make the code easier to read. Suggested-by: Chris Wilson Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c

[Intel-gfx] [PATCH 04/13] drm/i915: extract crtc_is_valid() on the FBC code

We're going to kill intel_fbc_find_crtc(), that's why a big part of the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). v2: - Rebase due to pipe_a_only change. - Split the multiline conditional (Chris). Signed-off-by: Paulo Zanoni ---

[Intel-gfx] [PATCH 10/13] drm/i915: fix the CFB size check

In function find_compression_threshold() we try to over-allocate CFB space in order to reudce reallocations and fragmentation, and we're not considering that at the CFB size check. Consider it. There is also a longer-term plan to kill dev_priv->fbc.uncompressed_size, but this will come later.

Re: [Intel-gfx] [PATCH 6/8] drm/i915/skl: Turn DC handling into a power well

On ti, 2015-11-03 at 13:31 +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 power well will allow DC states again. For now the > highest DC state is

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

2015-11-04 17:25 GMT-02:00 Imre Deak : > After Damien's D3 fix I started to get runtime suspend residency for the > first time and that revealed a breakage on the set_caching IOCTL path > that accesses the HW but doesn't take an RPM ref. Fix this up. Oh, well, that's the the

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

On 04/11/15 14:24, Chris Wilson wrote: On Wed, Nov 04, 2015 at 02:10:36PM +, Morton, Derek J wrote: -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] No, just android appears to be broken. I was actually complaining about the use of 'S'. What would you

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

On 04/11/15 14:46, Morton, Derek J wrote: -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Wednesday, November 4, 2015 2:34 PM To: Chris Wilson; Morton, Derek J; intel-gfx@lists.freedesktop.org; Wood, Thomas; Gore, Tim Subject: Re: [Intel-gfx]

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

On Wed, Nov 04, 2015 at 02:10:36PM +, Morton, Derek J wrote: > > > > > >-Original Message- > >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > >No, just android appears to be broken. I was actually complaining about the > >use of 'S'. > > What would you prefer to be printed?

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

> > >-Original Message- >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] >Sent: Wednesday, November 4, 2015 2:34 PM >To: Chris Wilson; Morton, Derek J; intel-gfx@lists.freedesktop.org; Wood, >Thomas; Gore, Tim >Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop:

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

On Wed, Nov 04, 2015 at 01:20:33PM +, Gong, Zhipeng wrote: > > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Wednesday, November 04, 2015 5:54 PM > > On Wed, Nov 04, 2015 at 06:19:33AM +, Gong, Zhipeng wrote: > > > > From: Chris Wilson

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

> > >-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Wednesday, November 4, 2015 1:55 PM >To: Morton, Derek J >Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Gore, Tim >Subject: Re: [PATCH i-g-t] tests/gem_exec_nop: Improved test run time > >On Wed, Nov

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

On Tue, 03 Nov 2015, Matt Roper wrote: > Although we can do a good job of reading out hardware state, the > graphics firmware may have programmed the watermarks in a creative way > that doesn't match how i915 would have chosen to program them. We > shouldn't trust the

[Intel-gfx] [PATCH] drm/i915: Unpin framebuffers when crtc is deconfigured.

When setcrtc is called and steals the last connector away from a crtc it's turned off because it can't stay configured without connectors. The framebuffer is still preserved however, and that causes troubles in the IGT stress test kms_flip.flips-vs-fences which tries to use as many pins as

[Intel-gfx] [PATCH] drm: Remove unused fbdev_list members

I noticed that intel_fbdev->our_mode is unused. Introduced by 79e539453b34 ("DRM: i915: add mode setting support"). Then I noticed that intel_fbdev->fbdev_list is unused as well. Introduced by 386516744ba4 ("drm/fb: fix fbdev object model + cleanup properly.") in i915, nouveau and radeon.

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

> > >-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Tuesday, November 3, 2015 4:40 PM >To: Morton, Derek J >Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Gore, Tim >Subject: Re: [PATCH i-g-t] tests/gem_exec_nop: Improved test run time > >On Tue, Nov

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_nop: Improved test run time

On Wed, Nov 04, 2015 at 01:40:45PM +, Morton, Derek J wrote: > > > > > >-Original Message- > >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > >Sent: Tuesday, November 3, 2015 4:40 PM > >To: Morton, Derek J > >Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Gore, Tim >

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

Reviewed-by: Ander Conselvan de Oliveira On Fri, 2015-10-30 at 23:39 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently there's no trace in dmesg when the gen2/3 dotclock checks > reject the modeset. Add some to

Re: [Intel-gfx] [PATCH] drm/i915: Fix locking around GuC firmware load

On 11/03/2015 07:22 PM, Dave Airlie wrote: On 4 November 2015 at 07:42, Daniel Stone wrote: > The GuC firmware load requires struct_mutex to create a GEM object, > but this collides badly with request_firmware. Move struct_mutex > locking down into the loader itself, so

[Intel-gfx] [PATCH] drm/i915/bxt: Fix eDP panel fitting (v2)

BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths store panel fitter information in pipe_config->pch_pfit. However since HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in this structure (we wind up filling in pipe_config->gmch_pfit instead, which is ignored

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix eDP panel fitting

On Tue, Nov 03, 2015 at 06:29:41PM -0800, Matt Roper wrote: > BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths > store panel fitter information in pipe_config->pch_pfit. However since > HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in > this structure (we

Re: [Intel-gfx] [PATCH 32/43] drm/i915: Clean up LVDS register handling

On Sun, Nov 01, 2015 at 04:33:57PM +0100, Lukas Wunner wrote: > Hi Ville, > > On Fri, Sep 18, 2015 at 08:03:45PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Keep single 'lvds_reg' and 'lvds' variable around in > > intel_lvds_init(),

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

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, by just looking at the dmesg. > > v2: use DRM_DEBUG_DRIVER (Chris) > v3: use

[Intel-gfx] [PATCH 06/10] drm/i915/skl: don't toggle PW1 and MISC power wells on-demand

With the DMC firmware installed we don't need to handle HW resources that are handled automatically by the firmware. Besides beeing redundant this can also interfere with the firmware, possibly getting it into a broken/blocked state. The on-demand handling of PW1 was already half-way removed, MISC

[Intel-gfx] [PATCH 07/10] drm/i915/gen9: simplify DC toggling code

Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_runtime_pm.c | 66 ++--- 2 files changed, 29 insertions(+), 38 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h

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

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 get() at intel_ddi_pll_init() when we discovered that LCPLL was

[Intel-gfx] [PATCH 08/10] drm/i915/skl: disable DC states before display core init/uninit

We need to disable the DC states during display core init to sanitize the HW state we inherit from the BIOS. We need to disable it during display core uninit too, since the power well framework will leave it enabled (since we get to the display core uninit step with all power domains disabled

[Intel-gfx] [PATCH 05/10] drm/i915/skl: init/uninit display core as part of the HW power domain state

We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and

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

Hi, On 28 October 2015 at 21:58, 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]. > > I have added my Reviewed-by to those patches that I only rebased or > updated the

[Intel-gfx] [PATCH 09/10] drm/i915/skl: make sure LCPLL is disabled when uniniting CDCLK

Suppressing LCPLL disabling was added to avoid interfering with the DMC firmware. It is not needed any more since we uninit CDCLK now with the DMC deactivated (DC states disabled). We also must disable it during system suspend as part of the Bspec "Display uninit sequence". Signed-off-by: Imre

Re: [Intel-gfx] skylake + drm-next - warn city

Hi, On 3 November 2015 at 22:08, Patrik Jakobsson wrote: > On Tue, Nov 3, 2015 at 10:47 PM, Daniel Stone wrote: >> I tested this on top of the three series (Mika's, Imre's, and yours), >> but hit some power domain warnings and I never come

Re: [Intel-gfx] [PATCH 0/8] Skylake DMC/DC-state fixes and redesign

Hi, On 3 November 2015 at 12:31, Patrik Jakobsson wrote: > These patches should sit on top of the DMC redesign patches from > Animesh/Imre [1] which in turn depends on Mika's FW debug patches [2]. > > First two patches are from Ville and is included since they

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

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 things up accordingly. Signed-off-by: Imre Deak

[Intel-gfx] [PATCH 00/10] drm/i915/skl: fix display core init/uninit sequence

Atm we toggle HW resources handled automatically by the DMC firmware. This is redundant and also interferes with the firmware's functionality. This patchset fixes this and also an old existing issue leaving RPM disabled all the time (see Damien's patch). The patchset depends on Mika's firmware

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Add a modeset power domain

On Tue, Nov 03, 2015 at 01:31:10PM +0100, Patrik Jakobsson wrote: > We need DC5/DC6 to be disabled around modesets to prevent confusing the > DMC. Also, we've run out of bits in the 32 bit power domain mask so now > it's a 64 bit mask. We could get back 4 bits by squashing each 2 and 4 lane DDI

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

On Tue, Nov 03, 2015 at 01:31:11PM +0100, Patrik Jakobsson wrote: > PG2 enabled is not a requirement for disabling DC5. It's just one > of the reasons why we 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. > >

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915/gen9: csr_init after runtime pm enable

On Thursday 29 October 2015 07:25 PM, Imre Deak wrote: On to, 2015-10-29 at 15:48 +0530, Sunil Kamath wrote: On Thursday 29 October 2015 03:28 AM, Imre Deak wrote: From: Animesh Manna Skl is fully dependent on dmc for going to low power state (dc5/dc6). This requires

[Intel-gfx] [PATCH] drm/i915: Request for resets under forcewake

We have a timed release of a forcewake when using I915_READ/WRITE macros. wait_for() macro will go to quite long sleep if the first read doesn't satisfy the condition for successful exit. With these two interacting, it is possible that we lose the forcewake during the wait_for() and the subsequent

[Intel-gfx] [PATCH] drm/i915: Add some more bits to CURSOR_POS_MASK

The old value of 0x7FF will wrap the position at 2048 giving wrong coordinate values on panels larger than 2048 pixels in any direction. Used in i915_debugfs atm. Looking at all hw specs available at 01.org shows that X position is bit 0:11, and even 0:12 on some hw where remaining bits up to bit

Re: [Intel-gfx] [PATCH] drm/i915: Request for resets under forcewake

On Wed, Nov 04, 2015 at 11:33:04AM +0200, Mika Kuoppala wrote: > We have a timed release of a forcewake when using > I915_READ/WRITE macros. wait_for() macro will go to quite > long sleep if the first read doesn't satisfy the condition for > successful exit. With these two interacting, it is

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

On Wed, Nov 04, 2015 at 06:19:33AM +, Gong, Zhipeng wrote: > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > On Tue, Nov 03, 2015 at 01:31:22PM +, Gong, Zhipeng wrote: > > > > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > > > > > > > Do you also have a relative

Re: [Intel-gfx] [PATCH] drm/i915: Add some more bits to CURSOR_POS_MASK

On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote: > The old value of 0x7FF will wrap the position at 2048 giving wrong > coordinate values on panels larger than 2048 pixels in any direction. > Used in i915_debugfs atm. Looking at all hw specs available at 01.org > shows that X

[Intel-gfx] [PATCH v3 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using

Re: [Intel-gfx] [PATCH] drm/i915: Request for resets under forcewake

Chris Wilson writes: > On Wed, Nov 04, 2015 at 11:33:04AM +0200, Mika Kuoppala wrote: >> We have a timed release of a forcewake when using >> I915_READ/WRITE macros. wait_for() macro will go to quite >> long sleep if the first read doesn't satisfy the condition for >>

[Intel-gfx] [PATCH] OCL20: Add svm support.

Enable CL_DEVICE_SVM_COARSE_GRAIN_BUFFER svm support, use userptr and softpin to implement it. Use userptr to share the page between cpu and gpu, and softpin to unify the cpu and gpu's address. Now it works on i386 system. x86_64 depends on backend support. This patch base on DRM library and DRM

  1   2   >