[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 SWF1

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 stuff to use its own macros. > > Cc

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 way we can simply loop through the

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

Looks good to me. Reviewed-by: Sonika Jindal mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Shubhangi Shrivastava Sent: Wednesday, October 28, 2015 3:31 PM To: intel-gfx@lists.freedesktop.org Cc: Shrivastava, Shubhangi Subject: [Intel-gfx] [PATCH] drm/i915: Cleanup test data during l

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

Looks good to me. Reviewed-by: Sonika Jindal mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Shubhangi Shrivastava Sent: Wednesday, October 14, 2015 2:57 PM To: intel-gfx@lists.freedesktop.org Cc: Shrivastava, Shubhangi Subject: [Intel-gfx] [PATCH 2/2] drm/i915: force link training wh

[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) Cc:

[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 S

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 how i915 would have chosen to

[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: - Add

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 > Signed-off-by: Damien Lespiau > Signed-off-by: Rodrigo Vivi > --- >

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 > this structure (we wind u

[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 96fd0f5..8017a3b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/dr

[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 Cc: Kevin Tian Cc: Yu Zhang Cc: Zhi Wang Cc: Zhiyua

[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 files changed, 36 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/i9

[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 index 5012bbe..221c478 100644 --- a/drivers/gpu/drm/i915/intel_lr

[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 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gp

[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ä --- drivers/gpu/drm/i915/i915_reg.h | 8 drivers/gpu/drm/i915/intel_lrc.c

[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ä --- drivers/gpu/drm/i915/intel

[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ä --- drivers/gpu/drm/i915/intel_uncore.c | 4

[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 change the register offsets to u32

[Intel-gfx] [PATCH 11/29] drm/i915: Store DVO SRCDIM register offset under intel_dvo_device

From: Ville Syrjälä Store the DVO SRCDIM register offset alongside the DVO control register offset in intel_dvo_device. This gets rid of the switch statement whose case values are the DVO control register offsets. Such a construct would cause problems for register type safety. Signed-off-by: Vil

[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 a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 27/29] drm/i915: Add save/restore of SWF for ILK+

From: Ville Syrjälä No idea if we might want these. Perhaps there is a "keep your paws off my GPU" bit in there somewhere to avoid BIOS crap? Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 13 ++--- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i91

[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 Cc: Kevin Tian Cc: Yu Zhang Cc: Zhi Wang Cc: Zhiyuan Lv Sign

[Intel-gfx] [PATCH v2 19/29] drm/i915: Add functions to emit register offsets to the ring

From: Ville Syrjälä When register type safety happens, we can't just try to emit the register itself to the ring. Instead we'll need to extract the offset from it first. Add some convenience functions that will do that. v2: Convert MOCS setup too Signed-off-by: Ville Syrjälä --- drivers/gpu/d

[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ä --- drivers/gpu/drm/i915/intel_di

[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 it will take into account all t

[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(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/

[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 register offsets (like we do for all ot

[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ä --- drivers/gpu/drm/i915/i915_cmd_parser.c | 29 +--

[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ä --- drivers/gpu/drm/i915/intel_dp.c

[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 changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/d

[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 straightforward and simply add a few functions

[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: git://github.com/vsyrjala/linux.git type_safe_reg_acce

[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 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drive

[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 files changed, 19 insertions(+), 23 deletions(-) diff --git a/dri

[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 b/drivers/gpu/drm/i915/intel_dp.c index a26995a..62fb95c 100644 --- a

[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 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h

[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 whitespace change (Jani) Reviewed-by: Ja

[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 registers locally in quirks.c. This w

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 ra

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 debug patches [2]. >> >> First two patches are from Ville

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 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 > > >   

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 impl

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 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 this wouldn't get merged

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 now >> it's a 64 bit mask. > >

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 RPM problem that preve

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: ‘cont

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 Aux >> A). Disabling the power w

[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 +++- 1 file changed,

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 D

[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 b/drivers/gpu/drm/i915/intel_fbc.c index 19a3e93..55bef12

[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 --- drivers/gpu/drm/i915/intel_fbc.c | 22 +++

[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 --- drivers/

[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 Aut

[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. Sig

[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 insertion(+), 1 deletion(-) dif

[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 combinat

[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() won

[Intel-gfx] [PATCH 07/13] drm/i915: don't disable_fbc() if FBC is already disabled

If FBC is disabled we will still call intel_fbc_invalidate(), and as a result we may call intel_fbc_deactivate(), which will try to touch registers. I'm pretty sure I saw this happen on a runtime suspended device, and I'm almost sure I was running igt/pm_rpm. It produced the "you touched registers

[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 I

[Intel-gfx] [PATCH 01/13] drm/i915: rename intel_fbc_nuke to intel_fbc_recompress

Although the term "nuke" is part of the FBC spec, it's not very intuitive, so let's rename it to make it easier for people that are not familiar with the spec. Requested-by: Chris Wilson Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 7 --- 1 file changed, 4 insertions(+

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

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 implemented it for fun years back). Imo just remove al

[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 -- 1 file changed, 2 deletio

[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 b/drivers/gpu/drm/i915/intel_f

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

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 Aux > A). Disabling the power well will allow DC states again. For now the > highest DC st

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. > > Signed-

[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 d

[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 Dea

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 po

[Intel-gfx] [PATCH 10/10] drm/i915/skl: remove redundant DDI/IRQ reinitialization during PW1 enabling

We don't need to reinit DDI and IRQs during PW1 enabling any more, since we don't toggle PW1 on-demand any more. We enable PW1 only as part of the display core init sequence and after this we initialize both DDI and IRQs later in the init sequence. So remove these init steps from the power well cod

[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 enabled, then we would call put/

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

lookup_power_well() expects uniq power well IDs, but atm we have uninitialized IDs which would clash with those power wells with a 0 ID. This wasn't a problem so far since nothing looked up such a power well, but an upcoming patch will (Misc IO for SKL), so fix this up on platforms where this matte

[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 alrea

[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 b/drivers/gpu/drm/i915/i915_reg.h index c10

[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 04/10] drm/i915: rename intel_power_domains_resume to *_sync_hw

Give a more proper name to this function. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 16691a3..63ad315 100644

[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 --- drivers/gpu/drm/i9

[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 ver

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 DRM_INFO (Marc Herbert) For the series (all 7): Tested-by:

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 otherwise > might be forgotten. The

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 commit message, patches

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 back from DPMS. >> That being said, this is also on top

[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 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(), and read it just once at the st

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] 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 we don't hold it across

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 avoid further head scratching. > > While at it refact

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] [PAT

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: 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: Improv

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 pre

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? P

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 firmware's watermark program

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 > >Subjec

[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. Subsequ

[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 possibl

  1   2   >