[Intel-gfx] [PATCH 5/6] drm/i915/gen9: WA ST Unit Power Optimization Disable

From: Robert Beckett WaDisableSTUnitPowerOptimization:skl,bxt Signed-off-by: Robert Beckett Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 3 +++

[Intel-gfx] [PATCH 2/6] drm/i915/bxt: Add WaSetClckGatingDisableMedia

Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 84ed9ab..2c719b0 100644 ---

[Intel-gfx] [PATCH 4/6] drm/i915/bxt: Update WaSetHDCunitClckGatingDisable

As per spec this is applicable to 3x6 SKUs only, add condition to check the same. Cc: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_pm.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff

[Intel-gfx] [PATCH 6/6] drm/i915/gen9: Add WaDisableMinuteIaClockGating

From: Nick Hoath Signed-off-by: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Intel-gfx] [PATCH 3/6] drm/i915/gen9: Update WaDisableSDEUnitClockGating

Apply in common gen9_init_clock_gating() fn and add revid check for bxt. Cc: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_pm.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff

[Intel-gfx] [PATCH 1/6] drm/i915/gen9: Add WaDisableSamplerPowerBypassForSOPingPong

Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index d2e0b3b..0e1ed0b 100644 ---

[Intel-gfx] [PATCH] drm/i915: Limit the number of loops for reading a split 64bit register

In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit reads. Due to the nature of the registers we try to read in this manner, they may increment between the two instruction (e.g. a timestamp counter). To keep the result accurate, we repeat the read if we detect an overflow (i.e.

Re: [Intel-gfx] [PATCH] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, Sep 08, 2015 at 08:24:19AM +0100, Chris Wilson wrote: > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit > reads. Due to the nature of the registers we try to read in this manner, > they may increment between the two instruction (e.g. a timestamp > counter). To keep

Re: [Intel-gfx] [PATCH] drm/i915: Fix a bug in GuC status check

On 02/09/15 23:52, yu@intel.com wrote: From: Alex Dai Bit 16 of GuC status indicates resuming from RC6. The LAPIC_DONE status is a reliable readiness flag only when resuming from RC6. This fix a racing issue that allocation of doorbell fails whilst GuC init is not

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f ("drm/i915: Only enable cursor if it can be enabled.")

Op 08-09-15 om 09:31 schreef Bjørn Mork: > Just for the record: I still get these quite often on resuming from > suspend-to-ram. But I can't reliably provoke them for some reason, so > the exact trigger mechanism is unknown. Related to timing issues caused > by other devices, maybe? Or some odd

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f ("drm/i915: Only enable cursor if it can be enabled.")

Just for the record: I still get these quite often on resuming from suspend-to-ram. But I can't reliably provoke them for some reason, so the exact trigger mechanism is unknown. Related to timing issues caused by other devices, maybe? Or some odd Lenovo firmware thingy? Does of course not

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f ("drm/i915: Only enable cursor if it can be enabled.")

Maarten Lankhorst writes: > Op 08-09-15 om 09:31 schreef Bjørn Mork: >> Just for the record: I still get these quite often on resuming from >> suspend-to-ram. But I can't reliably provoke them for some reason, so >> the exact trigger mechanism is unknown.

Re: [Intel-gfx] [PATCH] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, Sep 08, 2015 at 08:51:50AM +0100, Chris Wilson wrote: > On Tue, Sep 08, 2015 at 08:24:19AM +0100, Chris Wilson wrote: > > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit > > reads. Due to the nature of the registers we try to read in this manner, > > they may

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

On Tue, Sep 08, 2015 at 06:48:34AM +0200, Maarten Lankhorst wrote: > Op 08-09-15 om 01:42 schreef Stephen Rothwell: > > Hi all, > > > > On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell > > wrote: > >> After merging the drm-misc tree, today's linux-next build (arm > >>

[Intel-gfx] [PATCH i-g-t] tests/gem_pwrite_snooped: disable const cast warning

Disable -Wcast-qual temporarily to allow memchr_inv to return non-const data (similar to memchr), without causing a compiler warning. Cc: Ville Syrjälä Signed-off-by: Thomas Wood --- tests/gem_pwrite_snooped.c | 3 +++ 1 file changed, 3

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, September 2, 2015 16:03 > To: Daniluk, Lukasz > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice > and > EU count for BDW > > On

Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen9: Add WaDisableMinuteIaClockGating

This is applicable to SKL GT3 and GT4. Can you add that check as well? -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Arun Siluvery Sent: Tuesday, September 8, 2015 3:02 PM To: intel-gfx@lists.freedesktop.org Cc: Kuoppala, Mika

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Add option to update planes only on active crtc

Hi Daniel, Thank you for the patch. On Tuesday 08 September 2015 12:02:07 Daniel Vetter wrote: > With drivers supporting runtime pm it's generally not a good idea to > touch the hardware when it's off. Add an option to the commit_planes > helper to support this case. > > Note that the helpers

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Add option to update planes only on active crtc

On Tue, Sep 08, 2015 at 01:10:58PM +0200, Thierry Reding wrote: > On Tue, Sep 08, 2015 at 12:02:07PM +0200, Daniel Vetter wrote: > > With drivers supporting runtime pm it's generally not a good idea to > > touch the hardware when it's off. Add an option to the commit_planes > > helper to support

Re: [Intel-gfx] [PATCH] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, 08 Sep 2015, Chris Wilson wrote: > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit > reads. Due to the nature of the registers we try to read in this manner, > they may increment between the two instruction (e.g. a timestamp > counter). To

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

On 9/8/2015 10:12 AM, Jindal, Sonika wrote: On 9/7/2015 9:56 PM, Daniel Vetter wrote: On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote: If the same port is enumerated as hdmi as well as DP, this will call hot_plug hook for DP as well which is not required here. This splitting

[Intel-gfx] [PATCH 8/8] drm/i915: Extract intel_dev_info.[ch]

Put all device information related stuff in separate files to that it is easy to pull them for the link training tests in i-g-t. --- drivers/gpu/drm/i915/i915_drv.c | 395 +- drivers/gpu/drm/i915/i915_drv.h | 286 +-

Re: [Intel-gfx] Temporary freezes

On Tue, 08 Sep 2015, Daniel Kasak wrote: > Hi all. I've got an Intel(R) Iris(TM) Pro Graphics 5200 ( in a Macbook ), > and I'm running a 4.1.5-rt5 kernel, libdrm-2.4.64 and mesa-11.0.0_rc1. I > use Enlightenment ( from git ), and on this particular system only, I get a >

[Intel-gfx] [PATCH] drm/atomic-helper: Add option to update planes only on active crtc

With drivers supporting runtime pm it's generally not a good idea to touch the hardware when it's off. Add an option to the commit_planes helper to support this case. Note that the helpers already add all planes on a crtc when a modeset happens, hence plane updates will not be lost if drivers set

Re: [Intel-gfx] [PATCH 0/3] remove crtc<->pipe mapping code

On 4 September 2015 at 19:22, Micah Fedke wrote: > This patchset removes the code that looks up a pipe number from a crtc ID. > The > pipe number is equivalent to the index of the crtc in the array of crtcs > returned by the kernel for a drmModeGetResources() call.

Re: [Intel-gfx] [PATCH 3/3] overlay: remove crtc<->pipe mapping code from kms-overlay

On 4 September 2015 at 19:22, Micah Fedke wrote: > the crtc id is now always equivalent to its index in the array of crtcs > returned by the kernel > > --- > overlay/Makefile.am | 4 ++-- > overlay/kms/kms-overlay.c | 7 ++- > 2 files changed, 4

[Intel-gfx] [PATCH 11/11] drm: Remove dummy agp ioctl wrappers

They're only used in the drm ioctl table, and there they're excluded when AGP support is disabled. So this is just dead code ripe for removal. Signed-off-by: Daniel Vetter --- include/drm/drm_agpsupport.h | 48 1 file

[Intel-gfx] [PATCH 10/11] drm/: Drop DRM_UNLOCKED from modeset drivers

Just one special case (since i915 lost its ums code, yay): - radeon: Has slots for the old ums ioctls which don't have DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it everywhere. Every other kms driver just has DRM_UNLOCKED for all their ioctls, as they should. v2: admgpu

Re: [Intel-gfx] [PATCH 00/18] Color Management for DRM

On Thu, 2015-08-06 at 22:08 +0530, Shashank Sharma wrote: > This patch set adds Color Manager implementation in DRM layer. Color > Manager is > an extension in DRM framework to support color > correction/enhancement. Various > Hardware platforms can support several color correction capabilities. >

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Add option to update planes only on active crtc

On Tue, Sep 08, 2015 at 12:02:07PM +0200, Daniel Vetter wrote: > With drivers supporting runtime pm it's generally not a good idea to > touch the hardware when it's off. Add an option to the commit_planes > helper to support this case. > > Note that the helpers already add all planes on a crtc

Re: [Intel-gfx] [PATCH 00/18] Color Management for DRM

Hey Rob, My comments inline. Regards Shashank On 9/8/2015 4:19 PM, Rob Bradford wrote: On Thu, 2015-08-06 at 22:08 +0530, Shashank Sharma wrote: This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color

[Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

The Bspec is very clear that Live status must be checked about before trying to read EDID over DDC channel. This patch makes sure that HDMI EDID is read only when live status us up. The live status doesn't seem to perform very consistent across various platforms when tested with different

[Intel-gfx] [PATCH 01/11] drm: Remove __OS_HAS_AGP

We already express the drm/agp depencies correctly in Kconfig, so we can rip this remnant from the shared drm core days. Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed if ttm would provide dummy functions. I'm not going to volunteer for that though. v2: Use

[Intel-gfx] [PATCH 06/11] drm: Define a drm_invalid_op ioctl implementation

And use it in radeon to replace all the ioctls no longer valid in kms mode. I plan to also use this later on when nuking the ums support for i915. Note that setting the function pointer in the ioctl table to NULL would amount to the same, but that results in some debug output from the drm_ioctl()

[Intel-gfx] [PATCH 03/11] drm/i915: Mark debug mod options as _unsafe

We don't want random people to touch these. Especially true since we've just screwed up SKL by holding it way too long under the preliminary flag because of some ABI issues. And now there's howtos all over the internets about how to set this. Same pretty much for anything else. Cc: Jani Nikula

[Intel-gfx] [PATCH 05/11] drm/i915: Mark getparam ioctl as DRM_UNLOCKED

With kms all the data getparam looks at is actually invariant, and certainly not protected by the global kms mutex. With ums all the setup code is already racy as hell, so this won't make things any worse. I've done this change so that all ioctl still used by kms drivers are marked as

[Intel-gfx] [PATCH 04/11] drm/i915: Remove setparam ioctl

This was only used for the ums+gem combo, so ripe for removal now that we only have kms code left. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c | 31 +-- 1 file changed, 1 insertion(+), 30 deletions(-) diff --git

[Intel-gfx] [PATCH 09/11] drm/vmwgfx: Stop checking for DRM_UNLOCKED

drm core enforces now for DRIVER_MODESET that all ioctls are unlocked. And all the old nasty ones from drm core aren't allowed for modern drivers any more. Hence this is no longer needed. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8

[Intel-gfx] [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls

With the prep patches for i915 all kms drivers either have DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns with an invariant return value when in modeset mode. But that's only the case for i915 and radeon. The drm core ioctls are unfortunately too much a mess still to dare

[Intel-gfx] [PATCH 07/11] drm/drm_ioctl.c: kerneldoc

As usual pull it into the drm docbook template, too. And again as usual I've decided to only document stuff exported to drivers, so all the old leftover markup from the shared drm repo days lost the magic ** signature. Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 02/11] drm/i915: Kill cross-module option depencies

Makes it really hard to reason about these since there are dependency loops. Also if you touch them and don't know what you're doing you get to keep all the pieces. v2: Move marking debug module options as _unsafe into a separate patch, as requested by Jani. Cc: Jani Nikula

[Intel-gfx] [PATCH 00/11] Mixed bag of ioctl and agp cleanups

Hi all, Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODESET (i.e. modern drivers) since all of them have their own locking. Besides that a few random things that kind where in the same area/files. Of course kerneldoc is updated too. Feedback highly welcome. Cheers, Daniel Daniel

[Intel-gfx] [PATCH] drm/i915: Remove one very outdated comment

From: Tvrtko Ursulin Comment disagrees with the code which has changed a lot since it was documented. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 deletions(-) diff --git

[Intel-gfx] [PATCH 1/8] drm/i915: Rename DP link training functions

The link training functions had confusing names. The start function actually does the clock recovery phase of the link training, and the complete function does the channel equalization. So call them that instead. Also, every call to intel_dp_start_link_train() was followed by a call to

[Intel-gfx] [PATCH i-g-t] Add a link training test

This adds a test that compiles the link training code from i915 into a separate executable and uses it to train a fake sink device. The test also uses device information from i915 to exercise the different code paths for different hardwdare generations. In order to get the code to compile a lot

[Intel-gfx] [PATCH 7/8] drm/i915: Move max voltage and pre emphasis to intel_dp_link_training.c

So link training tests can use real hardware limits. --- drivers/gpu/drm/i915/intel_dp.c | 99 --- drivers/gpu/drm/i915/intel_dp_link_training.c | 92 + drivers/gpu/drm/i915/intel_drv.h | 11 +-- 3 files changed, 99

[Intel-gfx] [PATCH 6/8] drm/i915: Move generic link training code to a separate file

No functional changes, just moving code around. --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/intel_dp.c | 328 + drivers/gpu/drm/i915/intel_dp_link_training.c | 336 ++

[Intel-gfx] [PATCH 2/8] drm/i915: Don't pass *DP around to link training functions

It just makes the code more confusing, so just reference intel_dp_>DP directly. The old behavior is preserved by saving the previous value of DP in the stack and restoring the old value in case of failure. -- I'm not sure the old behavior is correct, but to err in the side of caution I tried not

[Intel-gfx] [PATCH 4/8] drm/i915: Split write of pattern to DP reg from intel_dp_set_link_train

Split the register write with the new link training pattern out of intel_dp_set_link_train(), so that the i915 specific code is in a separate function. --- drivers/gpu/drm/i915/intel_dp.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 3/8] drm/i915: Split intel_dp_update_link_train()

Separate the bit that writes to DP register in its own function and move the update of the train_set based on the adjust request to the sink out. The objective is to split the generic link training logic from the i915 specific part. --- drivers/gpu/drm/i915/intel_dp.c | 21 ++---

[Intel-gfx] [PATCH 5/8] drm/i915: Don't call intel_dp_set_signal_levels() on link train reset

Instead of calling intel_dp_set_signal_levels(), which writes the desired signal levels mask to a variable, just call the new function intel_dp_update_signal_levels(). The effect should be the same, except for an extra register write, but this creates a better split between the generic link

[Intel-gfx] [PATCH 0/8] [RFC] Link training test

Hi, There's been some discussion on improving our link training code, with one of the ideas being a complete rewrite of the state machine. However, a concern was raised over the risk of regressions. The code we have has seen a lot of real world testing, and it would take a long time for any new

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add HDMI aspect ration property for SDVO

On Tue, Sep 08, 2015 at 01:40:50PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Handle the HDMI aspect ratio propert the same way in the SDVO code > as we handle it in the HDMI code. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_bad_reloc: use correct page table size

On 9/3/2015 5:13 PM, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio 2 subparts of gem_bad_reloc check that the reloc address is below the global gtt boundary. However, when executing from ppgtt the reloc address can be greater than that and

Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen9: Add WaDisableMinuteIaClockGating

Ignore the comment. I thought about CPG. Sorry. -Original Message- From: Kamble, Sagar A Sent: Tuesday, September 8, 2015 3:44 PM To: 'Arun Siluvery' ; intel-gfx@lists.freedesktop.org Cc: Kuoppala, Mika Subject: RE: [Intel-gfx]

[Intel-gfx] [PATCH 6/7] drm/i915: Constify adjusted_mode

From: Ville Syrjälä Make adjusted_mode const whereever we don't have to modify it. This only covers cases when we have a local adjusted_mode variable, and doesn't make any difference for cases where we just dereference pipe_config->adjusted_mode. Signed-off-by:

[Intel-gfx] [PATCH 2/7] drm/i915: Always call the adjusted mode 'adjusted_mode'

From: Ville Syrjälä Always name any variable pointing at the adjusted mode as 'adjustead_mode'. This will make it much easier to identify when we should use the crtc_ timings and when we shoudln't. Conversion was performed with coccinelle: @@ expression E;

[Intel-gfx] [PATCH 4/7] drm/i915: Always use crtc_ timings when dealing with adjustead_mode

From: Ville Syrjälä The adjustead_mode crtc_ timings are what we will program into the hardware, so it's those timings we should be looking practically everywhere. The normal and crtc_ timings should differ only when stere doubling is used. In that case the normal

[Intel-gfx] [PATCH 1/7] drm/i915: Use intel_panel for DVO fixed mode handling

From: Ville Syrjälä Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel stuff. Now all connectors that have a fixed mode use intel_panel. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dvo.c | 49

[Intel-gfx] [PATCH 5/7] drm/i915: Move HDMI aspect ratio setup to .compute_config()

From: Ville Syrjälä We shouldn't frob adjusted_mode after .compute_config(), so move the infoframe aspect ratio setup to .compute_config() from intel_hdmi_set_avi_infoframe(). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 3/7] drm/i915: s/mode/adjusted_mode/ in functions that really get passed the adjusted_mode

From: Ville Syrjälä Rename the function argument to 'adjusted_mode' whenever the function only ever gets passed the adjusted_mode. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +-

[Intel-gfx] [PATCH 7/7] drm/i915: Add HDMI aspect ratio property for SDVO

From: Ville Syrjälä Handle the HDMI aspect ratio property the same way in the SDVO code as we handle it in the HDMI code. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c

[Intel-gfx] [PATCH 0/7] drm/i915: Always use crtc_ timings with adjusted_mode

From: Ville Syrjälä Maarten pointed out that we still look at the non-crtc_ timings from adjusted_mode in many places. While that is only strictly required with HDMI due to stereo doubling I think it's better to be consistent about it and always use the crtc_

[Intel-gfx] [PATCH 7/7] drm/i915: Add HDMI aspect ration property for SDVO

From: Ville Syrjälä Handle the HDMI aspect ratio propert the same way in the SDVO code as we handle it in the HDMI code. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

> -Original Message- > From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com] > Sent: Wednesday, September 2, 2015 17:08 > To: Daniluk, Lukasz; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice > and > EU count for BDW > >

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

On Tue, Sep 08, 2015 at 09:05:12PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If one disables DDR DVFS in the BIOS, Punit will apparently ignores > all DDR DVFS request. Currently we assume that DDR DVFS is always > operational, which

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, Sep 08, 2015 at 02:17:13PM +0100, Chris Wilson wrote: > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit > reads. Due to the nature of the registers we try to read in this manner, > they may increment between the two instruction (e.g. a timestamp > counter). To keep

Re: [Intel-gfx] [PATCH 10/11] drm/: Drop DRM_UNLOCKED from modeset drivers

Hi Daniel, 2015-09-08 Daniel Vetter : > Just one special case (since i915 lost its ums code, yay): > - radeon: Has slots for the old ums ioctls which don't have > DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it > everywhere. > > Every other kms

Re: [Intel-gfx] [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls

Hi Daniel, 2015-09-08 Daniel Vetter : > With the prep patches for i915 all kms drivers either have > DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns > with an invariant return value when in modeset mode. But that's only > the case for i915 and

Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

On 09/07/2015 09:35 AM, Daniel Vetter wrote: > On Sat, Sep 05, 2015 at 01:12:50AM +0530, Vandana Kannan wrote: >> This patch includes enabling render decompression after checking all the >> requirements (format, tiling, rotation etc.). Along with this, the WAs >> mentioned in BSpec Workaround page

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

On 09/08/2015 11:05 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä If one disables DDR DVFS in the BIOS, Punit will apparently ignores all DDR DVFS request. Currently we assume that DDR DVFS is always operational, which leads to errors in dmesg when

Re: [Intel-gfx] About GVT-g Interrupt in i915 Host

On Tue, Sep 08, 2015 at 04:03:02PM +, Wang, Zhi A wrote: > BACKGROUND > > Under Intel GVT-g environment, HW interrupts are shared among different VMs. > > Because of the sharing, to enable or disable a HW interrupt becomes a bit > complicated. Considered that a virtual machine may request to

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Move max voltage and pre emphasis to intel_dp_link_training.c

On Tue, Sep 08, 2015 at 03:27:58PM +0300, Ander Conselvan de Oliveira wrote: > So link training tests can use real hardware limits. These need to be kept in sync with the _signal_levels() functions, so moving them to a separate file is a bit questionable. I suggest that we should attempt to

Re: [Intel-gfx] [PATCH] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, Sep 08, 2015 at 03:36:32PM +0300, Jani Nikula wrote: > On Tue, 08 Sep 2015, Chris Wilson wrote: > > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit > > reads. Due to the nature of the registers we try to read in this manner, > > they may

[Intel-gfx] [PATCH v2] drm/i915: Limit the number of loops for reading a split 64bit register

In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit reads. Due to the nature of the registers we try to read in this manner, they may increment between the two instruction (e.g. a timestamp counter). To keep the result accurate, we repeat the read if we detect an overflow (i.e.

[Intel-gfx] [PATCH] drm/atomic-helper: Pimp docs with recommendations for rpm drivers

Requested by Laurent. Note that this uses the new markdown support which will only land in kernel 4.4 (for the code snippet). v2: A few spelling fixes I spotted myself. v3: Big reword for commit_planes() kerneldoc based on a text from Laurent. Cc: Laurent Pinchart

Re: [Intel-gfx] [PATCH i-g-t] Add a link training test

On Tue, 2015-09-08 at 16:11 +0300, Ville Syrjälä wrote: > On Tue, Sep 08, 2015 at 03:28:00PM +0300, Ander Conselvan de Oliveira wrote: > > This adds a test that compiles the link training code from i915 into a > > separate executable and uses it to train a fake sink device. The test > > also uses

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Add NV12 to primary plane programming.

> > > > + if (fb->pixel_format == DRM_FORMAT_NV12) { > > > > + int height_in_mem = > > > > (fb->offsets[1]/fb->pitches[0]); > > > > + /* > > > > +* If UV starts from middle of a page, then UV > > > > start > > >

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

> > > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv, > > > > + int pipe, int enable) > > > > +{ > > > > + if (pipe == PIPE_A || pipe == PIPE_B) { > > > > + if (enable) > > > > + I915_WRITE(CLKGATE_DIS_PSL(pipe), > > > > +

Re: [Intel-gfx] [PATCH v4 5/5] drm: Add decoding of DRM and KMS ioctls

On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote: > First batch of drm / kms ioctls. Several comments in addition to issues similar to 4/5 patch. > +static int drm_mode_rm_fb(struct tcb *tcp, const unsigned int code, long arg) > +{ > + unsigned int handle; > + > + > + if

[Intel-gfx] About GVT-g Interrupt in i915 Host

BACKGROUND Under Intel GVT-g environment, HW interrupts are shared among different VMs. Because of the sharing, to enable or disable a HW interrupt becomes a bit complicated. Considered that a virtual machine may request to disable a interrupt which may be using by other virtual machines. The

[Intel-gfx] [PATCH 1/2] drm/i915: Don't bypass LRC on CHV

From: Ville Syrjälä The docs are unclear as usual, so it's not clear whether LRC should be bypassed, performed normally or GRC code should be used as the LRC code. Some old docs stated that LRC bypass ought to be used, more recent ones no longer say that. Some docs

[Intel-gfx] [PATCH 2/2] drm/i915: Skip CHV PHY asserts until PHY has been fully reset

From: Ville Syrjälä The BIOS can leave the CHV display PHY in some odd state where some of the LDOs/lanes won't power down fully when unused. This will trigger a host of asserts that were added in: 30142273a3e83936fd7b45aa5339311a9295ca51 drm/i915: Add CHV PHY LDO

[Intel-gfx] Skylake Linux 4.2 FIFO underruns

Hi, Using Linux 4.2 on a new Skylake laptop, I frequently see the internal display go momentarily black, with a coinciding message in the logs: [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun Testing linus master, the problem is gone. Does anyone know what commit

Re: [Intel-gfx] 4.1->4.2 regression : intel_display.c:12324check_crtc_state warning

Toralf Förster gmx.de> writes: > > On 09/02/2015 10:31 PM, Konduru, Chandra wrote: > > It is due to ips_enabled mismatch in crtc_state. > > I can't think how below patch is triggering mismatch in ips_enabled. > > tested it 2 times in a row, the bad commits fails, the commit before works fine.

Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component

Hi Daniel, As Takashi has already accepted the first 3 patches for sync_audio_rate() and the patches are not merged into -nightly branch. If I make a kerneldoc patch based on currently -nightly branch, there will be conflict when you are merging Takashi's branch. What do you think if I make the

[Intel-gfx] [PATCH 1/1] drm/i915/gtt: Mark newly created ppgtt dirty

We mark ppgtt dirty when vm area grows. As one needs to allocate atleast one batchbuffer object before running anything in vm space, this was considered adequate. However in init, we run batch which doesn't need to allocate anything. This is the render state initialization batch, part of context

Re: [Intel-gfx] [PATCH 1/1] drm/i915/gtt: Mark newly created ppgtt dirty

On 9/8/2015 5:20 PM, Mika Kuoppala wrote: We mark ppgtt dirty when vm area grows. As one needs to allocate atleast one batchbuffer object before running anything in vm space, this was considered adequate. However in init, we run batch which doesn't need to allocate anything. This is the render

Re: [Intel-gfx] Water mark update need to wait for next VSYNC?

What's the difference if double-buffered with armed attribute? William -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Sunday, September 06, 2015 7:50 PM To: Wang, Zhi A Cc: Xie, William; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Water

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

On 08/09/2015 13:53, Daniluk, Lukasz wrote: -Original Message- From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com] Sent: Wednesday, September 2, 2015 17:08 To: Daniluk, Lukasz; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice,

Re: [Intel-gfx] [PATCH 00/11] Mixed bag of ioctl and agp cleanups

Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König . That should be everything touching radeon/amdgpu if I missed something leave me a note. Regards, Christian. On 08.09.2015 13:56, Daniel Vetter wrote: Hi all, Big thing for sure is deprecating

Re: [Intel-gfx] [PATCH i-g-t] Add a link training test

On Tue, Sep 08, 2015 at 03:28:00PM +0300, Ander Conselvan de Oliveira wrote: > This adds a test that compiles the link training code from i915 into a > separate executable and uses it to train a fake sink device. The test > also uses device information from i915 to exercise the different code >

[Intel-gfx] [PATCH i-g-t 2/2] null_state_gen: add const to intel_batch_state_copy data

The data is not modified by the function and is often declared const. Signed-off-by: Thomas Wood --- tools/null_state_gen/intel_batchbuffer.c | 6 +++--- tools/null_state_gen/intel_batchbuffer.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH i-g-t 1/2] tools/aubdump: remove void pointer arithmetic

A gcc extension allows void pointer arithmetic by treating the size of void as 1, but this generates a warning when -Wpointer-arith is used. Signed-off-by: Thomas Wood --- tools/aubdump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

From: Ville Syrjälä If one disables DDR DVFS in the BIOS, Punit will apparently ignores all DDR DVFS request. Currently we assume that DDR DVFS is always operational, which leads to errors in dmesg when the DDR DVFS requests time out. Fix the problem by gently

Re: [Intel-gfx] [PATCH 5/6] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests

On Thu, Aug 27, 2015 at 05:23:30PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > When an i2c WRITE gets an i2c defer or short i2c ack reply, we are > supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE > when we continue