Re: [Intel-gfx] [PATCH 01/29] pci: Decouple quirks.c from i915_reg.h
Hi Ville, On Wed, Nov 04, 2015 at 11:19:49PM +0200, ville.syrj...@linux.intel.com wrote: > 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 was > already done for a few other igpu related registers. > > Cc: Bjorn Helgaas > Cc: linux-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Ville Syrjälä I haven't seen the rest of this series, but this patch is OK by me, and I assume you'll merge this along with the whole series. Please adjust the subject line to be: PCI: Decouple quirks.c from i915_reg.h Acked-by: Bjorn Helgaas > --- > drivers/pci/quirks.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index b03373f..78a70fb 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3404,7 +3404,9 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev > *dev, int probe) > return 0; > } > > -#include "../gpu/drm/i915/i915_reg.h" > +#define SOUTH_CHICKEN2 0xc2004 > +#define PCH_PP_STATUS0xc7200 > +#define PCH_PP_CONTROL 0xc7204 > #define MSG_CTL 0x45010 > #define NSDE_PWR_STATE 0xd0100 > #define IGD_OPERATION_TIMEOUT1 /* set timeout 10 seconds */ > -- > 2.4.10 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [iGVT-g] XenGT for PV guest
Hi all, I am trying to enable XenGT for Android on board vtc1010 in PV mode. Used: - Intel® Atom™ processor E3827 - Xen 4.3.1 on branch "byt_experiment". - dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version - domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs) kernel version vgt was successfully started in dom0. vgt does not start in domU. After registration of pci dev in i915_init() there is no call of i915_pci_driver.probe(). Inte HD Graphics is on pci bus, but it is not passthrough to domU. When tried to passtrough it to domU than dom0 crashes in drm_framebuffer_remove(). More than that it is not my case because of intel hd graphics need to be working in dom0 and domU. So could U give advice how to probe i915 driver in domU? With best, Oleksii -- Oleksii Kurochko | Embedded Dev GlobalLogic www.globallogic.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix potential dangling else problems in for_each_ macros
On Tue, Nov 24, 2015 at 09:21:56PM +0200, Jani Nikula wrote:
> We have serious dangling else bugs waiting to happen in our for_each_
> style macros with ifs. Consider, for example,
>
> #define for_each_power_domain(domain, mask) \
> for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> if ((1 << (domain)) & (mask))
>
> If this is used in context:
>
> if (condition)
> for_each_power_domain(domain, mask);
> else
> foo();
>
> foo() will be called for each domain *not* in mask, if condition holds,
> and not at all if condition doesn't hold.
>
> Fix this by reversing the conditions in the macros, and adding an else
> branch for the "for each" block, so that other if/else blocks can't
> interfere. Provide a "for_each_if" helper macro to make it easier to get
> this right.
>
> v2: move for_each_if to drmP.h in a separate patch.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
Both applied to drm-misc, thanks for respinning with drm headers included.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 12 ++--
> drivers/gpu/drm/i915/intel_display.c| 2 +-
> drivers/gpu/drm/i915/intel_dsi.h| 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
> 4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3d8741eff7d3..11ae5a5a0a2e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,7 +286,7 @@ struct i915_hotplug {
> list_for_each_entry(intel_plane,\
> &(dev)->mode_config.plane_list, \
> base.head) \
> - if ((intel_plane)->pipe == (intel_crtc)->pipe)
> + for_each_if ((intel_plane)->pipe == (intel_crtc)->pipe)
>
> #define for_each_intel_crtc(dev, intel_crtc) \
> list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
> @@ -303,15 +303,15 @@ struct i915_hotplug {
>
> #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) \
> list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list,
> base.head) \
> - if ((intel_encoder)->base.crtc == (__crtc))
> + for_each_if ((intel_encoder)->base.crtc == (__crtc))
>
> #define for_each_connector_on_encoder(dev, __encoder, intel_connector) \
> list_for_each_entry((intel_connector),
> &(dev)->mode_config.connector_list, base.head) \
> - if ((intel_connector)->base.encoder == (__encoder))
> + for_each_if ((intel_connector)->base.encoder == (__encoder))
>
> #define for_each_power_domain(domain, mask) \
> for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> - if ((1 << (domain)) & (mask))
> + for_each_if ((1 << (domain)) & (mask))
>
> struct drm_i915_private;
> struct i915_mm_struct;
> @@ -730,7 +730,7 @@ struct intel_uncore {
> for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
>(i__) < FW_DOMAIN_ID_COUNT; \
>(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
> - if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1 << (i__)))
> + for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1
> << (i__)))
>
> #define for_each_fw_domain(domain__, dev_priv__, i__) \
> for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
> @@ -1969,7 +1969,7 @@ static inline struct drm_i915_private
> *guc_to_i915(struct intel_guc *guc)
> /* Iterate over initialised rings */
> #define for_each_ring(ring__, dev_priv__, i__) \
> for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
> - if (((ring__) = &(dev_priv__)->ring[(i__)]),
> intel_ring_initialized((ring__)))
> + for_each_if ring__) = &(dev_priv__)->ring[(i__)]),
> intel_ring_initialized((ring__
>
> enum hdmi_force_audio {
> HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 75f03e5bee51..4b21d5e137dc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12417,7 +12417,7 @@ static bool intel_fuzzy_clock_check(int clock1, int
> clock2)
> list_for_each_entry((intel_crtc), \
> &(dev)->mode_config.crtc_list, \
> base.head) \
> - if (mask & (1 <<(intel_crtc)->pipe))
> + for_each_if (mask & (1 <<(intel_crtc)->pipe))
>
> static bool
> intel_compare_m_n(unsigned int m, unsigned int n,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index e6cb25239941..02551ff228c2 100644
> --- a/drivers/gpu/drm/
[Intel-gfx] [i-g-t PATCH] scripts: remove display_debug.sh as obsolete
The script uses the obsoleted and removed intel_reg_read tool. Rather than mechanically fix this to use intel_reg, observe that the hardcoded register offsets are platform specific. A quick glance suggests they are for PCH split platforms with FDI, and as such useful only on a minority of platforms. Remove the script as obsolete. If the need for such a script arises, it should be based around using 'intel_reg dump' with display-only register spec files. Signed-off-by: Jani Nikula --- scripts/display_debug.sh | 172 --- 1 file changed, 172 deletions(-) delete mode 100755 scripts/display_debug.sh diff --git a/scripts/display_debug.sh b/scripts/display_debug.sh deleted file mode 100755 index f854f90b846c.. --- a/scripts/display_debug.sh +++ /dev/null @@ -1,172 +0,0 @@ -#!/bin/bash - -# FBC_CFB_BASE 0x43200 -../tools/intel_reg_read 0x43200 -# FBC_CTL 0x43208 -../tools/intel_reg_read 0x43208 -# ERR_INT 0x44040 -../tools/intel_reg_read 0x44040 -# DE_RRMR 0x44050 -../tools/intel_reg_read 0x44050 -# ARB_CTL 0x45000 -../tools/intel_reg_read 0x45000 -# ARB_CTL2 0x45004 -../tools/intel_reg_read 0x45004 -# MSG_CTL 0x45010 -../tools/intel_reg_read 0x45010 -# Watermarks -../tools/intel_reg_read 0x45100 -../tools/intel_reg_read 0x45104 -../tools/intel_reg_read 0x45200 -../tools/intel_reg_read 0x45108 -../tools/intel_reg_read 0x4510C -../tools/intel_reg_read 0x45110 -../tools/intel_reg_read 0x45120 -../tools/intel_reg_read 0x45124 -../tools/intel_reg_read 0x45128 -# Pipe A timing 0x6-0x6004C -../tools/intel_reg_read 0x6 -c 0x13; -# Pipe B timing 0x61000-0x6104C -../tools/intel_reg_read 0x61000 -c 0x13; -# Pipe C timing 0x62000-0x6204C -../tools/intel_reg_read 0x62000 -c 0x13; -# FDI A 0x60100 -# FDI B 0x61100 -# FDI C 0x62100 -# EDP 0x64000 -../tools/intel_reg_read 0x60100 -../tools/intel_reg_read 0x61100 -../tools/intel_reg_read 0x62100 -../tools/intel_reg_read 0x64000 -# Panel fitter A window size 0x68074 -# Panel fitter A control 0x68080 -../tools/intel_reg_read 0x68074 -../tools/intel_reg_read 0x68080 -# Panel fitter B window size 0x68874 -# Panel fitter B control 0x68880 -../tools/intel_reg_read 0x68874 -../tools/intel_reg_read 0x68880 -# Panel fitter C window size 0x69074 -# Panel fitter C control 0x69080 -../tools/intel_reg_read 0x69074 -../tools/intel_reg_read 0x69080 -# Pipe A config 0x70008 -# Pipe B config 0x71008 -# Pipe C config 0x72008 -../tools/intel_reg_read 0x70008 -../tools/intel_reg_read 0x71008 -../tools/intel_reg_read 0x72008 -# Cursor A control 0x70080 -# Cursor B control 0x71080 -# Cursor C control 0x72080 -../tools/intel_reg_read 0x70080 -../tools/intel_reg_read 0x71080 -../tools/intel_reg_read 0x72080 -# Primary A control 0x70180 -# Primary B control 0x71180 -# Primary C control 0x72180 -../tools/intel_reg_read 0x70180 -../tools/intel_reg_read 0x71180 -../tools/intel_reg_read 0x72180 -# Sprite A control 0x70280 -# Sprite B control 0x71280 -# Sprite C control 0x72280 -../tools/intel_reg_read 0x70280 -../tools/intel_reg_read 0x71280 -../tools/intel_reg_read 0x72280 -# Sprite A size 0x70290 -# Sprite B size 0x71290 -# Sprite C size 0x72290 -../tools/intel_reg_read 0x70290 -../tools/intel_reg_read 0x71290 -../tools/intel_reg_read 0x72290 -# Sprite A scaling 0x70304 -# Sprite B scaling 0x71304 -# Sprite C scaling 0x72304 -../tools/intel_reg_read 0x70304 -../tools/intel_reg_read 0x71304 -../tools/intel_reg_read 0x72304 -# PCH DE Interrupt enable 0xC400C -../tools/intel_reg_read 0xC400C -# PCH DE Interrupt IIR 0xC4008 -../tools/intel_reg_read 0xC4008 -# PCH DE hotplug 0xC4030 -../tools/intel_reg_read 0xC4030 -# SERR_INT 0xC4040 -../tools/intel_reg_read 0xC4040 -# PCH DPLL A CTL 0xC6014 -# PCH DPLL A Divisor 0 0xC6040 -# PCH DPLL A Divisor 1 0xC6044 -../tools/intel_reg_read 0xC6014 -../tools/intel_reg_read 0xC6040 -../tools/intel_reg_read 0xC6044 -# PCH DPLL B CTL 0xC6018 -# PCH DPLL B Divisor 0 0xC6048 -# PCH DPLL B Divisor 1 0xC604C -../tools/intel_reg_read 0xC6018 -../tools/intel_reg_read 0xC6048 -../tools/intel_reg_read 0xC604C -# PCH DPLL DREF CTL 0xC6200 -../tools/intel_reg_read 0xC6200 -# PCH DPLL SEL 0xC7000 -../tools/intel_reg_read 0xC7000 -# PCH Panel Status 0xC7200 -../tools/intel_reg_read 0xC7200 -# PCH Panel Control 0xC7204 -../tools/intel_reg_read 0xC7204 -# Transcoder A timing 0xE-0xE004F -# Transcoder B timing 0xE1000-0xE104F -# Transcoder C timing 0xE2000-0xE204F -../tools/intel_reg_read 0xE -c 0x14; -../tools/intel_reg_read 0xE1000 -c 0x14; -../tools/intel_reg_read 0xE2000 -c 0x14; -# Transcoder A DP CTL 0xE0300 -# Transcoder B DP CTL 0xE1300 -# Transcoder C DP CTL 0xE2300 -../tools/intel_reg_read 0xE0300 -../tools/intel_reg_read 0xE1300 -../tools/intel_reg_read 0xE2300 -# CRT DAC CTL 0xE1100 -../tools/intel_reg_read 0xE1100 -# HDMI/DVI B CTL 0xE1140 -# HDMI/DVI C CTL 0xE1150 -# HDMI/DVI D CTL 0xE1160 -../tools/intel_reg_read 0xE1140 -../tools/intel_reg_read 0xE1150 -../tools/intel_reg_read 0xE1160 -# LVDS 0xE1
Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
On Tue, Nov 24, 2015 at 11:01:25PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 07:06:21PM +0100, Daniel Vetter wrote: > > Just setting obj->dirty only works if you also have the pages. > > Exactly. The CPU access has historically always been page-by-page. The > style here more or less to emulate the CPU mmap. > > > But it's also not awesome that set_to_gtt_domain does this for callers. > > Hmm, do you have an example where we want set-to-gtt(write), but not > actually write through the backing storage? Internal use of set-to-gtt > has never been ideal (e.g. context) but we haven't yet come up with a > better semantic. Just the inconsistency that Dave pointed out is a bit worrisome. At most we can fix this with docs (which atm we have), which gives us a rather low score on API design (still a positive one still it's possible to get right). I agree that I don't have better semantics either. > > For lack of clear solutions I'd go with sprinkling obj->dirty or > > page_set_dirty over callers. Aside: relocate_entry_cpu probably gets away > > because of the unconditional obj->dirty we do later on, and that we redo > > all relocs if a fault happens. Still would be good to fix it, just for > > safety. > > [copy_batch() isn't a bug as the contents are invalidated after use > anyway] Just for consistency adding the obj->dirty after get_pages won't hurt though. > relocate_entry_cpu() is a bug we never caught. Indeed we've papered over > it to mask some over userspace issues, but just adding the set_page_dirty() > as required isn't going to be a big hardship. Yeah. > We have tons of swapthrash tests to check persistency of GPU buffers, > but we never tried to thrash the batches themselves out to swap and then > reuse them. > > I guess that it is because userspace doesn't reuse batches that we never > had report of the issue. Hibernating would be a good exercise of such. Hm it's not just batches but any object with relocs. Could this explain the oddball libva/uxa hang? Stuff like "after playing $game for hours my desktop looked funny", but not for tiling issues. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] PSR general improvements and stabilization.
On Tue, Nov 24, 2015 at 08:53:43PM +, Vivi, Rodrigo wrote: > On Tue, 2015-11-24 at 17:12 +, Daniel Stone wrote: > > Hi Rodrigo, > > > > On 11 November 2015 at 21:19, Rodrigo Vivi > > wrote: > > > Proceeding with the big series split here goes the general PSR > > > improvements and stabilization work. > > > > > > There is no critical fix on this series although I believe it is > > > good to have all of them before we can enable PSR back by default. > > > > For the series: > > Tested-by: Daniel Stone # SKL > > Thank you very much for this and the aux one. > > > > > I haven't managed to get to BDW yet since that relies on IPS bits. > > Oh, Daniel or Jani reverted the fastboot so PSR is just working well on > BDW regardless that initialization rework. > > I'm still going to do the encoder fixup that Daniel suggest and accept > your suggestions on the IPS one, but they shouldn't be blocking any of > the PSR work anymore. Yeah, my plan is to re-enable fastboot just in -nightly for better test coverage. Similar to how we enable psr/fbc and all that stuff in testcases, for better coverage. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH] tools: fix intel_gpu_abrt to use intel_reg
intel_reg_dumper is gone, replaced by 'intel_reg dump'. Signed-off-by: Jani Nikula --- tools/intel_gpu_abrt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt index a38137d795f4..bde6fb0d2493 100755 --- a/tools/intel_gpu_abrt +++ b/tools/intel_gpu_abrt @@ -55,7 +55,7 @@ get /etc/X11/xorg.conf.d/ X dmesg > $tardir/dmesg lspci -nn > $tardir/lspci -$igtdir/intel_reg_dumper > $tardir/intel_reg_dumper.txt +$igtdir/intel_reg dump > $tardir/intel_reg_dump.txt $igtdir/intel_bios_dumper $tardir/intel_bios_dump $igtdir/intel_stepping > $tardir/intel_stepping -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock
On Tue, Nov 24, 2015 at 02:34:46PM -0800, Yu Dai wrote: > > > On 11/24/2015 11:13 AM, Daniel Vetter wrote: > >On Tue, Nov 24, 2015 at 10:36:54AM -0800, Yu Dai wrote: > >> > >> > >> On 11/24/2015 10:08 AM, Daniel Vetter wrote: > >> >On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote: > >> >> On ti, 2015-11-24 at 09:00 -0800, Yu Dai wrote: > >> >> > > >> >> > On 11/24/2015 05:26 AM, Imre Deak wrote: > >> >> > > On ti, 2015-11-24 at 14:04 +0100, Daniel Vetter wrote: > >> >> > > > On Mon, Nov 23, 2015 at 03:02:58PM -0800, yu@intel.com wrote: > >> >> > > > > From: Alex Dai > >> >> > > > > > >> >> > > > > When GuC Work Queue is full, driver will wait GuC for avaliable > >> >> > > > > space by delaying 1ms. The wait needs to be out of spinlockirq > >> >> > > > > / > >> >> > > > > unlock. Otherwise, lockup happens because jiffies won't be > >> >> > > > > updated > >> >> > > > > dur to irq is disabled. > >> >> > > > > > >> >> > > > > Issue is found in igt/gem_close_race. > >> >> > > > > > >> >> > > > > Signed-off-by: Alex Dai > >> >> > > > > --- > >> >> > > > > drivers/gpu/drm/i915/i915_guc_submission.c | 27 > >> >> > > > > +- > >> >> > > > > - > >> >> > > > > 1 file changed, 17 insertions(+), 10 deletions(-) > >> >> > > > > > >> >> > > > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > >> >> > > > > b/drivers/gpu/drm/i915/i915_guc_submission.c > >> >> > > > > index 0a6b007..1418397 100644 > >> >> > > > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > >> >> > > > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > >> >> > > > > @@ -201,10 +201,13 @@ static int guc_ring_doorbell(struct > >> >> > > > > i915_guc_client *gc) > >> >> > > > > union guc_doorbell_qw *db; > >> >> > > > > void *base; > >> >> > > > > int attempt = 2, ret = -EAGAIN; > >> >> > > > > + unsigned long flags; > >> >> > > > > > >> >> > > > > base = kmap_atomic(i915_gem_object_get_page(gc- > >> >> > > > > > client_obj, 0)); > >> >> > > > > >> >> > > > We don't need kmap_atomic anymore here now, since it's outside of > >> >> > > > the > >> >> > > > spinlock. > >> >> > > > > >> >> > > > > desc = base + gc->proc_desc_offset; > >> >> > > > > > >> >> > > > > + spin_lock_irqsave(&gc->wq_lock, flags); > >> >> > > > > >> >> > > > Please don't use the super-generic _irqsave. It's expensive and > >> >> > > > results in > >> >> > > > fragile code when someone accidentally reuses something in an > >> >> > > > interrupt > >> >> > > > handler that was never meant to run in that context. > >> >> > > > > >> >> > > > Instead please use the most specific funtion: > >> >> > > > - spin_lock if you know you are in irq context. > >> >> > > > - sipn_lock_irq if you know you are not. > >> >> > > > >> >> > > Right, and simply spin_lock() if the lock is not taken in IRQ > >> >> > > context > >> >> > > ever. > >> >> > > >> >> > This is not in IRQ context. So I will use spin_lock_irq instead. > >> >> > >> >> You can just use spin_lock(). spin_lock_irq() makes only sense if you > >> >> take the lock in IRQ context too, which is not the case. > >> > > >> >Imo just drop both spinlocks, adding locks for debugfs is overkill imo. > >> > > >> How about using mutex_lock_interruptible(&dev->struct_mutex) instead in > >> debugfs, which is to replace host2guc lock. > > > >Yes. > > > >> spinlock during ring the door bell is still needed. > > > >Where/why is that needed? At least on a quick look I didn't notice > >anything. > > > > Currently there is only one guc client to do the commands submission. It > appears we don't need the lock. When there are more clients and all write to > the scratch registers or ring the door bell, we don't want them interact > with each other. Also, if we implement guc to host interrupt (says to handle > the log buffer full event), we do need to protect the guc client content. > Well, none presents today. I can clean up these and test out. Yeah I think it's better to add locking when we need it, since very likely something will have changed in the codebase by then. Otherwise there's only complication and confusion. So please remove the spinlocks and use the usual interruptible mutex locking for debugfs for now. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH] tests: fix ddx_intel_after_fbdev to use intel_reg
intel_reg_dumper is gone, replaced by 'intel_reg dump'. Signed-off-by: Jani Nikula --- tests/ddx_intel_after_fbdev | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev index bcd2c29d8e9e..f068209d7a45 100755 --- a/tests/ddx_intel_after_fbdev +++ b/tests/ddx_intel_after_fbdev @@ -40,8 +40,8 @@ cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.1.before.fbdev # run fbdev xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.fbdev & sleep 5 -if [ -f `which intel_reg_dumper` ]; then -`which intel_reg_dumper` > $TMPDIR/intel_reg_dumped.1.fbdev +if [ -f `which intel_reg` ]; then +`which intel_reg` dump > $TMPDIR/intel_reg_dump.1.fbdev fi killall X @@ -54,8 +54,8 @@ sleep 5 # run intel xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.intel & sleep 5 -if [ -f `which intel_reg_dumper` ]; then -`which intel_reg_dumper` > $TMPDIR/intel_reg_dumped.2.intel +if [ -f `which intel_reg` ]; then +`which intel_reg` dump > $TMPDIR/intel_reg_dump.2.intel fi killall X -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote: > Hm it's not just batches but any object with relocs. Could this explain > the oddball libva/uxa hang? Stuff like "after playing $game for hours my > desktop looked funny", but not for tiling issues. Possible, but with libva having its own issues with not marking GPU writes, only time will tell. I say batches because in modern code, only the batch has the reloc. In UXA and mesa, even the auxiliary buffers with the relocs are reallocated with each batch. There's only one swap related corruption issue on gen4, for which we also know the machine had bad swizzle detection, and there is another swap related bug on gen2, but neither are actually susceptible to this bug. I don't have any strong candidates for an eureka moment. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros
On Wed, 25 Nov 2015, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote: >> On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote: >> > /* Iterate over initialised rings */ >> > #define for_each_ring(ring__, dev_priv__, i__) \ >> >for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \ >> > - if (((ring__) = &(dev_priv__)->ring[(i__)]), >> > intel_ring_initialized((ring__))) >> > + for_each_if ring__) = &(dev_priv__)->ring[(i__)]), >> > intel_ring_initialized((ring__ >> >> Idly wondering if we would be happy with >> >> for_each_ring(ring__, dev_priv__) >> for ((ring__) = &(dev_priv__)->ring[0]; >> (ring__) <= &(dev_priv__)->ring[I915_NUM_RINGS]; >> (ring__)++) >> for_each_if(intel_ring_initialized(ring__)) >> >> ? >> >> The downside is that we have used i__ in several places rather than >> ring->id. > > Fwiw, 13 files changed, 113 insertions(+), 140 deletions(-) Seems good, looks like you have the patch so I won't bother. v2 of my patch was merged to drm-misc now, so that complicates a bit. Perhaps the i__ to ring->id change could be a prep step. *shrug*. BR, Jani. > > Seems a reasonable shrinkage. > -Chris -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request
On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote: > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote: > > > Instead of querying the reset counter before every access to the ring, > > > query it the first time we touch the ring, and do a final compare when > > > submitting the request. For correctness, we need to then sanitize how > > > the reset_counter is incremented to prevent broken submission and > > > waiting across resets, in the process fixing the persistent -EIO we > > > still see today on failed waits. > > > > tbh that explanation went straight over my head. Questions: > > - Where do we wait again over a reset? With all the wakeups we should > > catch them properly. I guess this needs the detailed scenario to help me > > out, since I have dim memories that there is something wrong ;-) > > TDR. In the future (and in past speculative patches) we have proposed > keeping requests over a reset and requeuing them. That is a complication > to the simplification of bailing out from the wait. What I have in mind, > is the recovery code has to fix up the request list somehow, though that > will be fun. But even with requeueing the waiters need to bail out and restart the ioctl. So I don't see why requeueing of requests matter. And my question was about what exactly is broken when waiting over a reset? As long as we detect the reset and restart the ioctl we should pick up any kinds of state fixups the reset work has done and recover perfectly. Irrespective of whether the reset work has requeued some of the requests or not. > > - What precisely is the effect for waiters? I only see moving the > > atomic_inc under the dev->struct_mutex, which shouldn't do a hole lot > > for anyone. Plus not returning -EAGAIN when reset_in_progress, which > > looks like it might result in missed wakeups and deadlocks with the > > reset work. > > At the moment, I can trivially wedge the machine. This patch fixes that. > The patch also ensures that we cannot raise unhandled errors from > wait-request (EIO/EAGAIN handling has to be explicitly added to the > caller). Hm, how/where do we wedge the machine, and how does the fix work? > The wait-request interface still has the wait-seqno legacy of having to > acquire the reset_counter under the mutex before calling. That is quite > hairy and causes a major complication later where we want to amalgamate > waiters. Yeah, that's a sensible change. But since I don't yet understand where exactly the current logic results in a wedge gpu I can't convince myself that the new one is ok. > Re EAGAIN. No, it cannot result in missed wakeups since that is internal > to the wait_request function, nor can it result in new deadlocks with the > reset worker. Yeah I think today with just struct_mutex it's impossible. But if we have more locks the waiting thread could continue to grab more locks instead of bailing out straight. And then the reset handler would be somewhat screwed since it isn't guaranteed to make forward progress. > > I /thought/ that the -EIO is from check_wedge in intel_ring_begin, but > > that part seems essentially unchanged. > > For two reasons, we need to to protect the access to the ring, and you > argued that (reporting of EIO from previous wedged GPUs) it was part of > the ABI. The other ABI that I think is important, is the reporting of > EIO if the user explicits waits on a request and it is incomplete (i.e. > wait_ioctl). Well then I don't get where the -EIO is from. That leaves a truly wedge gpu as the cause, and for that case I don't get how it can happen by accident with the current code. > > Aside from all that, shuffling the atomic_inc (if I can convince myself > > that it's safe) to avoid the reload_in_reset hack looks like a good > > improvement. > > That's what I said at the time :-p > > > More confused comments below. > > A large proportion of the actual patch is spent trying to make using the > atomic reset_counter safer (wrt to it changing values between multiple > tests and subsequent action). > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > > > b/drivers/gpu/drm/i915/i915_debugfs.c > > > index d83f35c8df34..107711ec956f 100644 > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > > @@ -4415,7 +4415,7 @@ i915_wedged_get(void *data, u64 *val) > > > struct drm_device *dev = data; > > > struct drm_i915_private *dev_priv = dev->dev_private; > > > > > > - *val = atomic_read(&dev_priv->gpu_error.reset_counter); > > > + *val = i915_terminally_wedged(&dev_priv->gpu_error); > > > > Don't we have a few tests left that look at this still? > > One. I strongly believe that the debug interface should not be reporting > the reset_counter but the wedged status (as that is what it is called). And that one only writes, so we're perfectly fine I think. > > > diff --git a/drivers/gpu/drm/i915/i9
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > If the system has no available swap pages, we cannot make forward
> > > progress in the shrinker by releasing active pages, only by releasing
> > > purgeable pages which are immediately reaped. Take total_swap_pages into
> > > account when counting up available objects to be shrunk and subsequently
> > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > > the system and then immediately back again (as they will more than
> > > likely be reused shortly after).
> > >
> > > Based on a patch by Akash Goel.
> > >
> > > Reported-by: Akash Goel
> > > Signed-off-by: Chris Wilson
> > > Cc: Akash Goel
> > > Cc: sourab.gu...@intel.com
> >
> > Cc: linux...@kvack.org should be done on this one, just in case they have
> > ideas for proper interfaces for this. Which might be, given that Jerome
> > Glisse is working on swaput-to-vram and other fun stuff like that.
> >
> > Also, how does stuff like zswap (or whatever "compress my swap in memory"
> > is called again) factor in here? Iirc Android very much does use that.
>
> It doesn't. We would need
>
> #include
>
> static bool swap_available(void)
> {
> return total_swap_pages || frontswap_enabled;
> }
>
> But if that then returns true for Android it seems the primary usecase
> is invalidated.
Well swapping to frontswap should be ok. Trashing not so much, and if we
do that I suspect there's something really loopsided with memory usage
balancing going on ... Does the android workload have your "only shrink
inactive" patch already?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
> > > >
> > > > When the object is moved out of CPU read domain, the cachelines
> > > > are not invalidated immediately. The invalidation is deferred till
> > > > next time the object is brought back into CPU read domain.
> > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > where the cachelines were flushed previously, when the object moved out
> > > > of CPU write domain. This is avoidable and would lead to some
> > > > optimization.
> > > > Though this is not a hypothetical case, but is unlikely to occur often.
> > > > The aim is to detect changes to the backing storage whilst the
> > > > data is potentially in the CPU cache, and only clflush in those case.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > Signed-off-by: Akash Goel
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index df9316f..fedb71d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > unsigned long gt_ro:1;
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > > + unsigned int cache_clean:1;
> > >
> > > So now we have cache_dirty and cache_clean which seems redundant,
> > > except somehow cache_dirty != !cache_clean?
>
> Exactly, not entirely redundant. I did think something along MESI lines
> would be useful, but that didn't capture the different meanings we
> employ.
>
> cache_dirty tracks whether we have been eliding the clflush.
>
> cache_clean tracks whether we know the cache has been completely
> clflushed.
>
> (cache_clean implies !cache_dirty, but
> !cache_clean does not imply cache_dirty)
>
> > We also have read_domains & DOMAIN_CPU. Which is which?
>
> DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> clflush elision above).
>
> DOMAIN_CPU implies !cache_clean
>
> and even
>
> cache_clean implies !DOMAIN_CPU
>
> but
>
> !DOMAIN_CPU does not imply cache_clean
All the above should be in the kerneldoc (per-struct-member comments
please) of drm_i915_gem_object. Akash, can you please amend your patch?
And please make sure we do include that kerneldoc somewhere ... might need
an upfront patch to do that, for just drm_i915_gem_object.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Calculate watermark related members in the crtc_state, v3.
On Tue, 2015-11-24 at 15:55 +0100, Maarten Lankhorst wrote:
> Op 24-11-15 om 15:03 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > > This removes pre/post_wm_update from intel_crtc->atomic, and
> > > creates atomic state for it in intel_crtc.
> > >
> > > Changes since v1:
> > > - Rebase on top of wm changes.
> > > Changes since v2:
> > > - Split disable_cxsr into a separate patch.
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/i915/intel_atomic.c | 1 +
> > > drivers/gpu/drm/i915/intel_display.c | 31 +--
> > > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > > 3 files changed, 15 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index 9f0638a37b6d..4625f8a9ba12 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -96,6 +96,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > > crtc_state->update_pipe = false;
> > > crtc_state->disable_lp_wm = false;
> > > crtc_state->disable_cxsr = false;
> > > + crtc_state->wm_changed = false;
> > >
> > > return &crtc_state->base;
> > > }
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5ee64e67ad8a..db4995406277 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4741,6 +4741,8 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
> > > static void intel_post_plane_update(struct intel_crtc *crtc)
> > > {
> > > struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
> > > + struct intel_crtc_state *pipe_config =
> > > + to_intel_crtc_state(crtc->base.state);
> > > struct drm_device *dev = crtc->base.dev;
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > >
> > > @@ -4751,7 +4753,7 @@ static void intel_post_plane_update(struct
> > > intel_crtc
> > > *crtc)
> > >
> > > crtc->wm.cxsr_allowed = true;
> > >
> > > - if (crtc->atomic.update_wm_post)
> > > + if (pipe_config->wm_changed)
> > > intel_update_watermarks(&crtc->base);
> > This adds an extra call to intel_update_watermarks() for the case where
> > previously update_wm_pre would be set. This won't cause extra register
> > writes
> > because of the dirty check, but I think it deserves a note in the commit
> > message.
> I think intel_update_watermarks needs to be fixed to take a crtc_state and
> whether pre/post commit is used.
>
> It looks to me like doing anything else could bug if watermarks are changed
> with 1 plane becoming visible and the other invisible..
> > >
> > > if (atomic->update_fbc)
> > > @@ -4784,6 +4786,9 @@ static void intel_pre_plane_update(struct intel_crtc
> > > *crtc)
> > > crtc->wm.cxsr_allowed = false;
> > > intel_set_memory_cxsr(dev_priv, false);
> > > }
> > > +
> > > + if (!needs_modeset(&pipe_config->base) && pipe_config
> > > ->wm_changed)
> > > + intel_update_watermarks(&crtc->base);
> > > }
> > >
> > > static void intel_crtc_disable_planes(struct drm_crtc *crtc, unsigned
> > > plane_mask)
> > > @@ -11706,25 +11711,18 @@ int intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > >plane->base.id, was_visible, visible,
> > >turn_off, turn_on, mode_changed);
> > >
> > > - if (turn_on) {
> > > - intel_crtc->atomic.update_wm_pre = true;
> > > - /* must disable cxsr around plane enable/disable */
> > > - if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> > > - pipe_config->disable_cxsr = true;
> > > - /* to potentially re-enable cxsr */
> > > - intel_crtc->atomic.wait_vblank = true;
> > > - intel_crtc->atomic.update_wm_post = true;
> > > - }
> > > - } else if (turn_off) {
> > > - intel_crtc->atomic.update_wm_post = true;
> > > + if (turn_on || turn_off) {
> > > + pipe_config->wm_changed = true;
> > > +
> > > /* must disable cxsr around plane enable/disable */
> > > if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> > > if (is_crtc_enabled)
> > > intel_crtc->atomic.wait_vblank = true;
> > > pipe_config->disable_cxsr = true;
> > > }
> > > - } else if (intel_wm_need_update(plane, plane_state)) {
> > > - intel_crtc->atomic.update_wm_pre = true;
> > > + } else if ((was_visible || visible) &&
> > So this avoids watermark changes when the plane is not visible before or
> > after
> > the update. Wouldn't it be better to fix intel_wm_need_update() instead if
> > returns true in that case?
>
> If visible is changed wm_changed = true is always set. It would go through the
> (turn_on || turn_off) case.
>
> I guess checking was_visible || visible is ove
Re: [Intel-gfx] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote: > > On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote: > > > /* Iterate over initialised rings */ > > > #define for_each_ring(ring__, dev_priv__, i__) \ > > > for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \ > > > - if (((ring__) = &(dev_priv__)->ring[(i__)]), > > > intel_ring_initialized((ring__))) > > > + for_each_if ring__) = &(dev_priv__)->ring[(i__)]), > > > intel_ring_initialized((ring__ > > > > Idly wondering if we would be happy with > > > > for_each_ring(ring__, dev_priv__) > > for ((ring__) = &(dev_priv__)->ring[0]; > > (ring__) <= &(dev_priv__)->ring[I915_NUM_RINGS]; > > (ring__)++) > > for_each_if(intel_ring_initialized(ring__)) > > > > ? > > > > The downside is that we have used i__ in several places rather than > > ring->id. > > Fwiw, 13 files changed, 113 insertions(+), 140 deletions(-) > > Seems a reasonable shrinkage. Maybe for_each_engine even, and phase out for_each_ring completely? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On 11/25/2015 2:51 PM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
From: Akash Goel
When the object is moved out of CPU read domain, the cachelines
are not invalidated immediately. The invalidation is deferred till
next time the object is brought back into CPU read domain.
But the invalidation is done unconditionally, i.e. even for the case
where the cachelines were flushed previously, when the object moved out
of CPU write domain. This is avoidable and would lead to some optimization.
Though this is not a hypothetical case, but is unlikely to occur often.
The aim is to detect changes to the backing storage whilst the
data is potentially in the CPU cache, and only clflush in those case.
Signed-off-by: Chris Wilson
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df9316f..fedb71d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_dirty:1;
+ unsigned int cache_clean:1;
So now we have cache_dirty and cache_clean which seems redundant,
except somehow cache_dirty != !cache_clean?
Exactly, not entirely redundant. I did think something along MESI lines
would be useful, but that didn't capture the different meanings we
employ.
cache_dirty tracks whether we have been eliding the clflush.
cache_clean tracks whether we know the cache has been completely
clflushed.
(cache_clean implies !cache_dirty, but
!cache_clean does not imply cache_dirty)
We also have read_domains & DOMAIN_CPU. Which is which?
DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
clflush elision above).
DOMAIN_CPU implies !cache_clean
and even
cache_clean implies !DOMAIN_CPU
but
!DOMAIN_CPU does not imply cache_clean
All the above should be in the kerneldoc (per-struct-member comments
please) of drm_i915_gem_object. Akash, can you please amend your patch?
And please make sure we do include that kerneldoc somewhere ... might need
an upfront patch to do that, for just drm_i915_gem_object.
I floated the amended patch, earlier today,
http://lists.freedesktop.org/archives/intel-gfx/2015-November/081194.html.
Please kindly check that.
Best regards
Akash
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915/skl: Update watermarks before the crtc is disabled.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > On skylake some of the registers are only writable when the correct > power wells are enabled. Because of this watermarks have to be updated > before the crtc turns off, or you get unclaimed register read and write > warnings. > > This patch needs to be modified slightly to apply to -fixes. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181 > Signed-off-by: Maarten Lankhorst > Cc: sta...@vger.kernel.org > Cc: Matt Roper Reviewed-by: Ander Conselvan de Oliveira > --- > drivers/gpu/drm/i915/intel_display.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index db4995406277..5345ffcce51e 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4753,7 +4753,7 @@ static void intel_post_plane_update(struct intel_crtc > *crtc) > > crtc->wm.cxsr_allowed = true; > > - if (pipe_config->wm_changed) > + if (pipe_config->wm_changed && pipe_config->base.active) > intel_update_watermarks(&crtc->base); > > if (atomic->update_fbc) > @@ -13362,6 +13362,9 @@ static int intel_atomic_commit(struct drm_device *dev, > dev_priv->display.crtc_disable(crtc); > intel_crtc->active = false; > intel_disable_shared_dpll(intel_crtc); > + > + if (!crtc->state->active) > + intel_update_watermarks(crtc); > } > } > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Ditch drm_can_sleep check in wait_for
It's causing endless amounts of trouble by hiding pretty serious bugs
where we wait for a few msecs, but accidentally while holding a
spinlock (sometimes even an irqsafe one).
And the only reason for this was to make the mode for the panic
handler work somewhat. But that _really_ needs to be done at a higher
level, since all our sideband mutexes and other stuff isn't covered
with this either.
And the final straw: At least with the current drm infrastructure
we've given up on special panic handlers a while ago:
commit 6066677cfd9d73734ab678b9d14013c860f0f732
Author: Dave Airlie
Date: Thu Jul 9 13:15:34 2015 +1000
drm/fb: drop panic handling
So let's just rip this out.
Cc: Mika Kuoppala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5c147fa9e9..18d257898a78 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -54,7 +54,7 @@
ret__ = -ETIMEDOUT; \
break; \
} \
- if ((W) && drm_can_sleep()) { \
+ if (W) {\
usleep_range((W)*1000, (W)*2000); \
} else {\
cpu_relax();\
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Remove double wait_for_vblank on broadwell.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > wait_vblank is already set in intel_plane_atomic_calc_changes > for broadwell, waiting for a double vblank is overkill. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Ander Conselvan de Oliveira > --- > drivers/gpu/drm/i915/intel_display.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 5345ffcce51e..60f17bc5f0ce 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4657,14 +4657,6 @@ intel_post_enable_primary(struct drm_crtc *crtc) > int pipe = intel_crtc->pipe; > > /* > - * BDW signals flip done immediately if the plane > - * is disabled, even if the plane enable is already > - * armed to occur at the next vblank :( > - */ > - if (IS_BROADWELL(dev)) > - intel_wait_for_vblank(dev, pipe); > - > - /* >* FIXME IPS should be fine as long as one plane is >* enabled, but in practice it seems to have problems >* when going from primary only to sprite only and vice ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
Recently I always see the following error message during S4 or S3 resume with
drm-intel-nightly.
[ 97.778063] PM: Syncing filesystems ... done.
[ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
[ 97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
[ 97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
[ 97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
[ 97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
[ 97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
[ 97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
[ 97.806363] PM: Basic memory bitmaps created
[ 97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
[ 98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
[ 98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 98.151998] Suspending console(s) (use no_console_suspend to debug)
[ 98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status:
Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[ 99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
cmd=0x206f2e08
[ 99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force
128
[ 101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, switching
to polling mode: last cmd=0x206f2f00
[ 102.195492] snd_hda_intel :00:1f.3: No response from codec, disabling
MSI: last cmd=0x206f2f00
[ 103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, switching
to single_cmd mode: last cmd=0x206f2f00
[ 103.201396] azx_single_wait_for_response: 42 callbacks suppressed
The bisect result points to this commit.
I checked this patch and had one question: if i915 driver wake up ahead of
snd_hda_intel driver during resume, i915 driver will call audio driver's
hdmi_present_sense() function through this patch, but the audio interrupt is
disabled at this moment, how could hdmi_present_sense() get the response from
codec ?
thanks
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> David Henningsson
> Sent: Saturday, August 29, 2015 1:03 AM
> To: ti...@suse.de; alsa-de...@alsa-project.org;
> intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Yang, Libin;
> Vetter,
> Daniel
> Cc: David Henningsson
> Subject: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD
> notify
> events
>
> Whenever there is an event from the i915 driver, wake the codec
> and recheck plug/unplug + ELD status.
>
> This fixes the issue with lost unsol events in power save mode,
> the codec and controller can now sleep in D3 and still know when
> the HDMI monitor has been connected.
>
> Right now, this might mean we get two callbacks from the same event,
> one from the unsol event and one from the i915 driver, but this is
> not harmful and can be optimised away in a later patch.
>
> Reviewed-by: Takashi Iwai
> Signed-off-by: David Henningsson
> ---
> sound/pci/hda/patch_hdmi.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index a97db5f..acbfbe0 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -37,6 +37,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "hda_codec.h"
> #include "hda_local.h"
> #include "hda_jack.h"
> @@ -144,6 +146,9 @@ struct hdmi_spec {
>*/
> struct hda_multi_out multiout;
> struct hda_pcm_stream pcm_playback;
> +
> + /* i915/powerwell (Haswell+/Valleyview+) specific */
> + struct i915_audio_component_audio_ops i915_audio_ops;
> };
>
>
> @@ -2191,6 +2196,9 @@ static void generic_hdmi_free(struct hda_codec
> *codec)
> struct hdmi_spec *spec = codec->spec;
> int pin_idx;
>
> + if (is_haswell_plus(codec) || is_valleyview_plus(codec))
> + snd_hdac_i915_register_notifier(NULL);
> +
> for (pin_idx = 0; pin_idx < spec->n
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > > If the system has no available swap pages, we cannot make forward
> > > > progress in the shrinker by releasing active pages, only by releasing
> > > > purgeable pages which are immediately reaped. Take total_swap_pages into
> > > > account when counting up available objects to be shrunk and subsequently
> > > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > > > the system and then immediately back again (as they will more than
> > > > likely be reused shortly after).
> > > >
> > > > Based on a patch by Akash Goel.
> > > >
> > > > Reported-by: Akash Goel
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Akash Goel
> > > > Cc: sourab.gu...@intel.com
> > >
> > > Cc: linux...@kvack.org should be done on this one, just in case they have
> > > ideas for proper interfaces for this. Which might be, given that Jerome
> > > Glisse is working on swaput-to-vram and other fun stuff like that.
> > >
> > > Also, how does stuff like zswap (or whatever "compress my swap in memory"
> > > is called again) factor in here? Iirc Android very much does use that.
> >
> > It doesn't. We would need
> >
> > #include
> >
> > static bool swap_available(void)
> > {
> > return total_swap_pages || frontswap_enabled;
> > }
> >
> > But if that then returns true for Android it seems the primary usecase
> > is invalidated.
>
> Well swapping to frontswap should be ok. Trashing not so much, and if we
> do that I suspect there's something really loopsided with memory usage
> balancing going on ... Does the android workload have your "only shrink
> inactive" patch already?
I'll let Akash or Sourab comment, but the background to the patch was
that they observed that under memory pressure a framebuffer was being
unbound (obviously not pinned as a current scanout) and then rebound
(clflushing both ways ofc). My gut says that the priority lists in the
kernel and userspace are akilter if we either fail to purge the LRU
object in the kernel or if userspace then doesn't try to reuse the MRU
backbuffer. One thing I did notice when also dealing with memory
pressure flushing backbuffers was (a) they were unaligned and so needed
rebinding before pinning
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c
and (b) we didn't bump the scanout on the inactive list
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=3a23ff3e5e201a52068d6e9d65f4ffb95077c21e
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
On Wed, Nov 25, 2015 at 09:02:20AM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote: > > Hm it's not just batches but any object with relocs. Could this explain > > the oddball libva/uxa hang? Stuff like "after playing $game for hours my > > desktop looked funny", but not for tiling issues. > > Possible, but with libva having its own issues with not marking GPU > writes, only time will tell. I say batches because in modern code, only > the batch has the reloc. In UXA and mesa, even the auxiliary buffers with > the relocs are reallocated with each batch. Ah, I didn't realize/forgot that UXA doesn't reuse the indirect state. > There's only one swap related corruption issue on gen4, for which we > also know the machine had bad swizzle detection, and there is another > swap related bug on gen2, but neither are actually susceptible to this > bug. I don't have any strong candidates for an eureka moment. Was just a thought really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote:
>
>
> On 11/25/2015 2:51 PM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> >>On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> >>>On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> >From: Akash Goel
> >
> >When the object is moved out of CPU read domain, the cachelines
> >are not invalidated immediately. The invalidation is deferred till
> >next time the object is brought back into CPU read domain.
> >But the invalidation is done unconditionally, i.e. even for the case
> >where the cachelines were flushed previously, when the object moved out
> >of CPU write domain. This is avoidable and would lead to some
> >optimization.
> >Though this is not a hypothetical case, but is unlikely to occur often.
> >The aim is to detect changes to the backing storage whilst the
> >data is potentially in the CPU cache, and only clflush in those case.
> >
> >Signed-off-by: Chris Wilson
> >Signed-off-by: Akash Goel
> >---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 9 -
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index df9316f..fedb71d 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > unsigned long gt_ro:1;
> > unsigned int cache_level:3;
> > unsigned int cache_dirty:1;
> >+unsigned int cache_clean:1;
>
> So now we have cache_dirty and cache_clean which seems redundant,
> except somehow cache_dirty != !cache_clean?
> >>
> >>Exactly, not entirely redundant. I did think something along MESI lines
> >>would be useful, but that didn't capture the different meanings we
> >>employ.
> >>
> >>cache_dirty tracks whether we have been eliding the clflush.
> >>
> >>cache_clean tracks whether we know the cache has been completely
> >>clflushed.
> >>
> >>(cache_clean implies !cache_dirty, but
> >>!cache_clean does not imply cache_dirty)
> >>
> >>>We also have read_domains & DOMAIN_CPU. Which is which?
> >>
> >>DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> >>clflush elision above).
> >>
> >>DOMAIN_CPU implies !cache_clean
> >>
> >>and even
> >>
> >>cache_clean implies !DOMAIN_CPU
> >>
> >>but
> >>
> >>!DOMAIN_CPU does not imply cache_clean
> >
> >All the above should be in the kerneldoc (per-struct-member comments
> >please) of drm_i915_gem_object. Akash, can you please amend your patch?
> >And please make sure we do include that kerneldoc somewhere ... might need
> >an upfront patch to do that, for just drm_i915_gem_object.
>
> I floated the amended patch, earlier today,
> http://lists.freedesktop.org/archives/intel-gfx/2015-November/081194.html.
> Please kindly check that.
Already done and replied here because I think this should be lifted to
kerneldoc for the structure itself. That's why I replied here ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_dp_detect redesign
On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote: > Hi Ander&Sivakumar, > > Dave&I had a short discussion about reprobing DP (and MST) state on > resume. I think this is something we've missed in our dp hpd handling > rework thus far. And at least for SST we need to take it into account > since it would be a regression. > > Currently it's done through ->detect callback from > drm_helper_hpd_irq_event called from i915_drm_resume. Also irc logs > below. Oh and there's an issue for the hdmi hpd changes that have been merged and reverted too: Those will run into the same problem. Plus in addition doing nothing in ->detect will break storm handling (since that falls back to the probe helper poll work). -Daniel > > Thanks, Daniel > > danvet: so probing on resume, it seems a bit inconsistent, > is the kernel driver meant to be doing it? > I think since we stopped vt switching we've stopped doing > it, which is making mst docking kinda suck > mst was after stopping vt-switching I thought > but yeah we should reprobe > and we do (at least occasionally if it's not broken again) > well people are just noticing it more with mst > but not for mst iirc > mst just restores and hopes I think > but when you suspend in the dock, and move the laptop, and > resume things don't work unless you xrandr > and vice-versa > I looked into it for 5 minutes when tedtso complained an ran ;-) > well reproving should bring up/tear down any mst > hm, xrandr shouldn't be enough to fix it, we need a real hpd > to redo the mst stuff I thought ... > so I don't think mst is special here > we reprobe through probe helpers > janesma, Pali, bleh sorry.. yeah, looks like it needs a > stdbool.h.. not sure why I didn't hit that compile error.. sorry about > that.. > all mst stuff is done directly from hpd since it needs to > know long vs. short > so it misses out > if we probe a DP port and the device is gone, MST will get torn down > danvet: not so > unless someone else has been hacking the driver > * xxmitsu (~m...@5-15-26-95.residential.rdsnet.ro) has joined #dri-devel > oh, the completely gone case > * danvet looks > oh maybe we don't handle that properly > oh you might be right, I wonder where we should hook that in > drm_helper_hpd_irq_event in i915_drm_resume should get this > right for non-mst > well non-DP maybe, anderco and rtshiva are reworking this > but it's not merged yet > I'm guessing detect should not if a port was in mst > and is now disconnected > ok, skeleton is there but not all > intel_dp_detect > drm_dp_mst_topology_mgr_resume should probably check the > entire hierarchy, not just a simple dpcd write > and if anything changes, we need to generate the uevent somewhere > so might be better to re-run the entire dp_detect pile > tricky part is that we need to lie about long vs. short > it should be treated like a long hpd if anything changed, > short otherwise > well we have mgr->cbs->hotplug in the mst manager already > so should reuse that hook > airlied, I guess just fix up drm_dp_mst_topology_mgr_resume > to do rescan the entire hierarchy > calling ->hotplug if anything changed > and only returning true if the sink isn't mst any more > along the lines of what intel_dp_probe_mst does > it's not going to be all that simple ;-) > at least if you care about stuff like laptopt connected to > dock -> screen > s/r > doesn't sounds like fun, I'll stick on my list of things to > be scared off > then laptop only connected to dock > airlied, done the same > well the use case is laptop in dock, suspend, resume with > laptop plugged into a monitor > but the fun part is that anderco/rtshiva want to rework this > and if they do they'll also break sst dp ;-) > so I think I have some victims > airlied, yeah that's step one > I'd prefer to get the fixes in before redesigning the tower > but that already has all the complexity on the driver side > only thing missing is the code in the mst helper to rescan > the entire tree and call ->hot_plug if needed > problem is that current dp hpd handling is a mess already > it's hard to fix anything in there atm > so fixing this properly is needed anyway > it's just that I've forgotten about the resume case for plain > DP myself ;-) > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Wed, 25 Nov 2015 10:56:51 +0100, Zhang, Xiong Y wrote: > > Recently I always see the following error message during S4 or S3 resume with > drm-intel-nightly. > [ 97.778063] PM: Syncing filesystems ... done. > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done. > [ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff] > [ 97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff] > [ 97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f] > [ 97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff] > [ 97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff] > [ 97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff] > [ 97.804387] PM: Marking nosave pages: [mem 0x8800-0x] > [ 97.806363] PM: Basic memory bitmaps created > [ 97.806409] PM: Preallocating image memory... done (allocated 321557 pages) > [ 98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s) > [ 98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) > done. > [ 98.151998] Suspending console(s) (use no_console_suspend to debug) > [ 98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI > status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1 > [ 99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > [ 99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force > 128 > [ 101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, > switching to polling mode: last cmd=0x206f2f00 > [ 102.195492] snd_hda_intel :00:1f.3: No response from codec, disabling > MSI: last cmd=0x206f2f00 > [ 103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, > switching to single_cmd mode: last cmd=0x206f2f00 > [ 103.201396] azx_single_wait_for_response: 42 callbacks suppressed > > The bisect result points to this commit. > I checked this patch and had one question: if i915 driver wake up ahead of > snd_hda_intel driver during resume, i915 driver will call audio driver's > hdmi_present_sense() function through this patch, but the audio interrupt is > disabled at this moment, how could hdmi_present_sense() get the response from > codec ? Yeah, a bad thing happens there. The fix should be simple like below, though. Basically the pins are checked in the resume callback in anyway, so there is no need to handle the notification during PM. Could you check whether it works? thanks, Takashi --- diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index bdb6f226d006..b468fe0e6195 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) struct hda_codec *codec = audio_ptr; int pin_nid = port + 0x04; - check_presence_and_report(codec, pin_nid); + /* don't call notifier during PM; will be checked in resume callback */ + if (!atomic_read(&codec->core.in_pm)) + check_presence_and_report(codec, pin_nid); } static int patch_generic_hdmi(struct hda_codec *codec) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired
On 24/11/15 17:47, Daniel Vetter wrote:
On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current code moves _any_ VMA to the inactive list only when
_all_ rendering on an object (so from any context or VM) has
been completed.
This creates an un-natural situation where the context (and
VM) destructors can run with VMAs still on the respective
active list.
Change here is to move VMAs to the inactive list as the
requests are getting retired.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cd7e102720f4..47a743246d2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2413,17 +2413,32 @@ static void
i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
{
struct i915_vma *vma;
+ struct i915_address_space *vm;
RQ_BUG_ON(obj->last_read_req[ring] == NULL);
RQ_BUG_ON(!(obj->active & (1 << ring)));
list_del_init(&obj->ring_list[ring]);
- i915_gem_request_assign(&obj->last_read_req[ring], NULL);
if (obj->last_write_req && obj->last_write_req->ring->id == ring)
i915_gem_object_retire__write(obj);
obj->active &= ~(1 << ring);
+
+ if (obj->last_read_req[ring]->ctx->ppgtt)
+ vm = &obj->last_read_req[ring]->ctx->ppgtt->base;
+ else
+ vm = &obj->last_read_req[ring]->i915->gtt.base;
+
+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ if (vma->vm == vm &&
+ vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
+ !list_empty(&vma->mm_list))
+ list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
+ }
This is only a partial solution since with schedulers and semaphores and a
few depencies on a given object, but in different vm you can still end up
with an object that is idle in a vm, but slipped through here.
Could you describe the exact scenario you had in mind? I won't pretend
it this is simple code and I have it all figured out.
Also, checking for the view type is some strange layering. Why that?
!ppgtt to skip potential other views I thought, no?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Rename request->ringbuf to request->ring
On 24/11/15 15:25, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 03:08:09PM +, Tvrtko Ursulin wrote:
On 20/11/15 12:43, Chris Wilson wrote:
Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 28 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.c | 149 ++---
drivers/gpu/drm/i915/intel_mocs.c | 32 +++
drivers/gpu/drm/i915/intel_overlay.c | 42
drivers/gpu/drm/i915/intel_ringbuffer.c| 86 -
10 files changed, 178 insertions(+), 183 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ce8b3fcb3a0..b7eaa2deb437 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2185,7 +2185,7 @@ struct drm_i915_gem_request {
* context.
*/
struct intel_context *ctx;
- struct intel_ringbuffer *ringbuf;
+ struct intel_ringbuffer *ring;
What was the problem with ringbuf? Struct is still called ringbuf
and the files as well after the patch series.
It introduced a major naming clash with existing code. I am trying to
remove the needlessly duplicated interfaces, and restore the historic
naming conventions.
Ok my point was that I am not sure if it is worth renaming things a)
partially, and b) that ring is a good name for intel_ringbuffer. Ringbuf
sounds at least just as good, in fact better to me. So this renaming
feels like unnecessary churn. And the fact you don't even do all of them
in the patch series just reinforces that.
But as Daniel already approved this it doesn't really matter apart for
"for the record".
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
> On Wed, 25 Nov 2015 10:56:51 +0100, > Zhang, Xiong Y wrote: > > > > Recently I always see the following error message during S4 or S3 resume > with drm-intel-nightly. > > [ 97.778063] PM: Syncing filesystems ... done. > > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) > done. > > [ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff] > > [ 97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff] > > [ 97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f] > > [ 97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff] > > [ 97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff] > > [ 97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff] > > [ 97.804387] PM: Marking nosave pages: [mem 0x8800-0x] > > [ 97.806363] PM: Basic memory bitmaps created > > [ 97.806409] PM: Preallocating image memory... done (allocated 321557 > pages) > > [ 98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 > MB/s) > > [ 98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 > > seconds) > done. > > [ 98.151998] Suspending console(s) (use no_console_suspend to debug) > > [ 98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1 > > [ 99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > cmd=0x206f2e08 > > [ 99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, > force 128 > > [ 101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, > switching to polling mode: last cmd=0x206f2f00 > > [ 102.195492] snd_hda_intel :00:1f.3: No response from codec, > disabling MSI: last cmd=0x206f2f00 > > [ 103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, > switching to single_cmd mode: last cmd=0x206f2f00 > > [ 103.201396] azx_single_wait_for_response: 42 callbacks suppressed > > > > The bisect result points to this commit. > > I checked this patch and had one question: if i915 driver wake up ahead of > snd_hda_intel driver during resume, i915 driver will call audio driver's > hdmi_present_sense() function through this patch, but the audio interrupt is > disabled at this moment, how could hdmi_present_sense() get the response > from codec ? > > Yeah, a bad thing happens there. The fix should be simple like below, > though. Basically the pins are checked in the resume callback in > anyway, so there is no need to handle the notification during PM. > > Could you check whether it works? > > > thanks, > > Takashi Strange, your patch couldn't get away the error message. thanks > > --- > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > index bdb6f226d006..b468fe0e6195 100644 > --- a/sound/pci/hda/patch_hdmi.c > +++ b/sound/pci/hda/patch_hdmi.c > @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int > port) > struct hda_codec *codec = audio_ptr; > int pin_nid = port + 0x04; > > - check_presence_and_report(codec, pin_nid); > + /* don't call notifier during PM; will be checked in resume callback */ > + if (!atomic_read(&codec->core.in_pm)) > + check_presence_and_report(codec, pin_nid); > } > > static int patch_generic_hdmi(struct hda_codec *codec) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
> > > >
> > > > When the object is moved out of CPU read domain, the cachelines
> > > > are not invalidated immediately. The invalidation is deferred till
> > > > next time the object is brought back into CPU read domain.
> > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > where the cachelines were flushed previously, when the object moved out
> > > > of CPU write domain. This is avoidable and would lead to some
> > > > optimization.
> > > > Though this is not a hypothetical case, but is unlikely to occur often.
> > > > The aim is to detect changes to the backing storage whilst the
> > > > data is potentially in the CPU cache, and only clflush in those case.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > Signed-off-by: Akash Goel
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index df9316f..fedb71d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > unsigned long gt_ro:1;
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > > + unsigned int cache_clean:1;
> > >
> > > So now we have cache_dirty and cache_clean which seems redundant,
> > > except somehow cache_dirty != !cache_clean?
>
> Exactly, not entirely redundant. I did think something along MESI lines
> would be useful, but that didn't capture the different meanings we
> employ.
>
> cache_dirty tracks whether we have been eliding the clflush.
>
> cache_clean tracks whether we know the cache has been completely
> clflushed.
Can we know that with speculative prefetching and whatnot?
>
> (cache_clean implies !cache_dirty, but
> !cache_clean does not imply cache_dirty)
>
> > We also have read_domains & DOMAIN_CPU. Which is which?
>
> DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> clflush elision above).
>
> DOMAIN_CPU implies !cache_clean
>
> and even
>
> cache_clean implies !DOMAIN_CPU
>
> but
>
> !DOMAIN_CPU does not imply cache_clean
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Wed, 25 Nov 2015 11:57:13 +0100, Zhang, Xiong Y wrote: > > > On Wed, 25 Nov 2015 10:56:51 +0100, > > Zhang, Xiong Y wrote: > > > > > > Recently I always see the following error message during S4 or S3 resume > > with drm-intel-nightly. > > > [ 97.778063] PM: Syncing filesystems ... done. > > > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) > > done. > > > [ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff] > > > [ 97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff] > > > [ 97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f] > > > [ 97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff] > > > [ 97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff] > > > [ 97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff] > > > [ 97.804387] PM: Marking nosave pages: [mem 0x8800-0x] > > > [ 97.806363] PM: Basic memory bitmaps created > > > [ 97.806409] PM: Preallocating image memory... done (allocated 321557 > > pages) > > > [ 98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 > > MB/s) > > > [ 98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 > > > seconds) > > done. > > > [ 98.151998] Suspending console(s) (use no_console_suspend to debug) > > > [ 98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: > > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1 > > > [ 99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last > > cmd=0x206f2e08 > > > [ 99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, > > force 128 > > > [ 101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, > > switching to polling mode: last cmd=0x206f2f00 > > > [ 102.195492] snd_hda_intel :00:1f.3: No response from codec, > > disabling MSI: last cmd=0x206f2f00 > > > [ 103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, > > switching to single_cmd mode: last cmd=0x206f2f00 > > > [ 103.201396] azx_single_wait_for_response: 42 callbacks suppressed > > > > > > The bisect result points to this commit. > > > I checked this patch and had one question: if i915 driver wake up ahead of > > snd_hda_intel driver during resume, i915 driver will call audio driver's > > hdmi_present_sense() function through this patch, but the audio interrupt is > > disabled at this moment, how could hdmi_present_sense() get the response > > from codec ? > > > > Yeah, a bad thing happens there. The fix should be simple like below, > > though. Basically the pins are checked in the resume callback in > > anyway, so there is no need to handle the notification during PM. > > > > Could you check whether it works? > > > > > > thanks, > > > > Takashi > > Strange, your patch couldn't get away the error message. OK, then it's not about the race *during* the hd-audio driver resuming or such. I guess it's the other way round: the i915 driver notifies it unnecessarily while it's getting off. The audio part of HDMI controller relies on the i915 power state, so it's screwed up. Check with drm.debug option to see in which code path it's triggered. If it's a call in i915 suspend, the call should be removed not to wake up the audio part unnecessarily. BTW, I have a patchset to avoid the audio h/w wakeup by a new component ops to get ELD and connection states. It was posted to alsa-devel shortly ago just as a reference, but this should work well in such a case, too. The test patches are found in test/hdmi-jack branch of my sound git tree. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable FLT if DP config changes
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link training is started with zero values.
The patch is fix for reported screen flickering issue in
https://bugs.freedesktop.org/show_bug.cgi?id=91393
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
drivers/gpu/drm/i915/intel_dp_link_training.c | 27 +++
drivers/gpu/drm/i915/intel_drv.h | 6 +-
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2805f0d..3694e3f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1621,6 +1621,12 @@ found:
intel_dp_compute_rate(intel_dp, pipe_config->port_clock,
&link_bw, &rate_select);
+ intel_dp->link_bw = link_bw;
+ intel_dp->rate_select = rate_select;
+ intel_dp->lane_count = lane_count;
+ intel_dp->port_clock = pipe_config->port_clock;
+ intel_dp->bpp = bpp;
+
DRM_DEBUG_KMS("DP link bw %02x rate select %02x lane count %d clock %d
bpp %d\n",
link_bw, rate_select, pipe_config->lane_count,
pipe_config->port_clock, bpp);
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 793..36a5294 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -82,9 +82,31 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
}
static bool
+intel_dp_check_conf(struct intel_dp *intel_dp)
+{
+ if (intel_dp->link_bw != intel_dp->old_link_bw)
+ return false;
+ else if (intel_dp->lane_count != intel_dp->old_lane_count)
+ return false;
+ else if (intel_dp->rate_select != intel_dp->old_rate_select)
+ return false;
+ else if (intel_dp->port_clock != intel_dp->old_port_clock)
+ return false;
+ else if (intel_dp->bpp != intel_dp->old_bpp)
+ return false;
+ else
+ return true;
+}
+
+static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
+ intel_dp->train_set_valid &= intel_dp_check_conf(intel_dp);
+
+ DRM_DEBUG_KMS("flt enabled: %s\n",
+ intel_dp->train_set_valid ? "true" : "false");
+
if (!intel_dp->train_set_valid)
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
@@ -305,6 +327,11 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp)
if (channel_eq) {
intel_dp->train_set_valid = true;
+ intel_dp->old_link_bw = intel_dp->link_bw;
+ intel_dp->old_rate_select = intel_dp->rate_select;
+ intel_dp->old_lane_count = intel_dp->lane_count;
+ intel_dp->old_port_clock = intel_dp->port_clock;
+ intel_dp->old_bpp = intel_dp->bpp;
DRM_DEBUG_KMS("Channel EQ done. DP Training successful\n");
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fae824..8db9288 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -742,7 +742,11 @@ struct intel_dp {
i915_reg_t aux_ch_data_reg[5];
uint32_t DP;
int link_rate;
- uint8_t lane_count;
+ uint8_t lane_count, old_lane_count;
+ uint8_t link_bw, old_link_bw;
+ uint8_t rate_select, old_rate_select;
+ int port_clock, old_port_clock;
+ int bpp, old_bpp;
bool has_audio;
enum hdmi_force_audio force_audio;
bool limited_color_range;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_dp_detect redesign
On 11/25/2015 3:34 PM, Daniel Vetter wrote: On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote: Hi Ander&Sivakumar, Dave&I had a short discussion about reprobing DP (and MST) state on resume. I think this is something we've missed in our dp hpd handling rework thus far. And at least for SST we need to take it into account since it would be a regression. Currently it's done through ->detect callback from drm_helper_hpd_irq_event called from i915_drm_resume. Also irc logs below. Oh and there's an issue for the hdmi hpd changes that have been merged and reverted too: Those will run into the same problem. Plus in addition doing nothing in ->detect will break storm handling (since that falls back to the probe helper poll work). -Daniel Storm handling is done in i915_hotplug_work_func before detection is called so it should work on top of changes planned. our change is inside intel_dp_detect so any flow before this is called should remain intact. the expected flow post the changes will be digport_work_func -> intel_dp_hpd_pulse if (long pulse) handle long pulse () return IRQ_NONE i915_hotplug_work_func -> detect however good to explicitly check for this, following needs to be tested before sending in next patch/merge 1) MST displays verification (Ander's reported on first set of patches) 2) check behavior on sleep - resume (dave&danvet) 3) storm handling needs to be handled as well. (i assume this should be fine, but good to check explicitly) (danvet) regards, Sivakumar Thanks, Daniel danvet: so probing on resume, it seems a bit inconsistent, is the kernel driver meant to be doing it? I think since we stopped vt switching we've stopped doing it, which is making mst docking kinda suck mst was after stopping vt-switching I thought but yeah we should reprobe and we do (at least occasionally if it's not broken again) well people are just noticing it more with mst but not for mst iirc mst just restores and hopes I think but when you suspend in the dock, and move the laptop, and resume things don't work unless you xrandr and vice-versa I looked into it for 5 minutes when tedtso complained an ran ;-) well reproving should bring up/tear down any mst hm, xrandr shouldn't be enough to fix it, we need a real hpd to redo the mst stuff I thought ... so I don't think mst is special here we reprobe through probe helpers janesma, Pali, bleh sorry.. yeah, looks like it needs a stdbool.h.. not sure why I didn't hit that compile error.. sorry about that.. all mst stuff is done directly from hpd since it needs to know long vs. short so it misses out if we probe a DP port and the device is gone, MST will get torn down danvet: not so unless someone else has been hacking the driver * xxmitsu (~m...@5-15-26-95.residential.rdsnet.ro) has joined #dri-devel oh, the completely gone case * danvet looks oh maybe we don't handle that properly oh you might be right, I wonder where we should hook that in drm_helper_hpd_irq_event in i915_drm_resume should get this right for non-mst well non-DP maybe, anderco and rtshiva are reworking this but it's not merged yet I'm guessing detect should not if a port was in mst and is now disconnected ok, skeleton is there but not all intel_dp_detect drm_dp_mst_topology_mgr_resume should probably check the entire hierarchy, not just a simple dpcd write and if anything changes, we need to generate the uevent somewhere so might be better to re-run the entire dp_detect pile tricky part is that we need to lie about long vs. short it should be treated like a long hpd if anything changed, short otherwise well we have mgr->cbs->hotplug in the mst manager already so should reuse that hook airlied, I guess just fix up drm_dp_mst_topology_mgr_resume to do rescan the entire hierarchy calling ->hotplug if anything changed and only returning true if the sink isn't mst any more along the lines of what intel_dp_probe_mst does it's not going to be all that simple ;-) at least if you care about stuff like laptopt connected to dock -> screen s/r doesn't sounds like fun, I'll stick on my list of things to be scared off then laptop only connected to dock airlied, done the same well the use case is laptop in dock, suspend, resume with laptop plugged into a monitor but the fun part is that anderco/rtshiva want to rework this and if they do they'll also break sst dp ;-) so I think I have some victims airlied, yeah that's step one I'd prefer to get the fixes in before redesigning the tower but that already has all the complexity on the driver side only thing missing is the code in the mst helper to rescan the entire tree and call ->hot_plug if needed problem is that current dp hpd handling is a mess already it's hard to fix anything in there atm so fixing this properly is needed anyway it's just that I've forgotten about the resume case for plain DP myself ;-) -- Daniel Vetter Software Engineer, Intel Corporation +
[Intel-gfx] [PATCH i-g-t] scripts: Add feature list file for piglit 'summary feature'
This is a placeholder for the feature list file. Its content is just
an example.
This needs to be filled in by feature owners with the feature name
and the corresponding tests regex.
Please refer to this piglit commit for more info on this feature.
commit f16d011db75b08ceae241e7370599146691340ab
Author: Feceoru, Gabriel
Date: Tue Nov 3 17:50:41 2015 +0200
framework: Add support for feature readiness.
Signed-off-by: Gabriel Feceoru
---
scripts/feat_profile.json | 12
1 file changed, 12 insertions(+)
create mode 100644 scripts/feat_profile.json
diff --git a/scripts/feat_profile.json b/scripts/feat_profile.json
new file mode 100644
index 000..f3a21a3
--- /dev/null
+++ b/scripts/feat_profile.json
@@ -0,0 +1,12 @@
+{
+"glsl" : {
+"include_tests" : "glsl",
+"exclude_tests" : "",
+"target_rate" : 90
+},
+"arb" : {
+"include_tests" : "ARB_shader|deqp.arb shader",
+"exclude_tests" : "",
+"target_rate" : 10
+}
+}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request
On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote:
> > > > Instead of querying the reset counter before every access to the ring,
> > > > query it the first time we touch the ring, and do a final compare when
> > > > submitting the request. For correctness, we need to then sanitize how
> > > > the reset_counter is incremented to prevent broken submission and
> > > > waiting across resets, in the process fixing the persistent -EIO we
> > > > still see today on failed waits.
> > >
> > > tbh that explanation went straight over my head. Questions:
> > > - Where do we wait again over a reset? With all the wakeups we should
> > > catch them properly. I guess this needs the detailed scenario to help me
> > > out, since I have dim memories that there is something wrong ;-)
> >
> > TDR. In the future (and in past speculative patches) we have proposed
> > keeping requests over a reset and requeuing them. That is a complication
> > to the simplification of bailing out from the wait. What I have in mind,
> > is the recovery code has to fix up the request list somehow, though that
> > will be fun.
>
> But even with requeueing the waiters need to bail out and restart the
> ioctl. So I don't see why requeueing of requests matter.
But why should the waiter even wake up? It is not holding any locks, all
it is just waiting for the request to complete. It is only those holding
a lock required to reset that we need to kick.
> And my question was about what exactly is broken when waiting over a
> reset? As long as we detect the reset and restart the ioctl we should pick
> up any kinds of state fixups the reset work has done and recover
> perfectly. Irrespective of whether the reset work has requeued some of the
> requests or not.
But... The reset handler clears the requests, we cannot wait over a
reset. So waiting over a reset today is clearly a bug in the kernel.
Only in the future do we contemplate situations where a request may
survive a reset.
> > > - What precisely is the effect for waiters? I only see moving the
> > > atomic_inc under the dev->struct_mutex, which shouldn't do a hole lot
> > > for anyone. Plus not returning -EAGAIN when reset_in_progress, which
> > > looks like it might result in missed wakeups and deadlocks with the
> > > reset work.
> >
> > At the moment, I can trivially wedge the machine. This patch fixes that.
> > The patch also ensures that we cannot raise unhandled errors from
> > wait-request (EIO/EAGAIN handling has to be explicitly added to the
> > caller).
>
> Hm, how/where do we wedge the machine, and how does the fix work?
Being able to reset a previously wedged machine.
> > The wait-request interface still has the wait-seqno legacy of having to
> > acquire the reset_counter under the mutex before calling. That is quite
> > hairy and causes a major complication later where we want to amalgamate
> > waiters.
>
> Yeah, that's a sensible change. But since I don't yet understand where
> exactly the current logic results in a wedge gpu I can't convince myself
> that the new one is ok.
>
> > Re EAGAIN. No, it cannot result in missed wakeups since that is internal
> > to the wait_request function, nor can it result in new deadlocks with the
> > reset worker.
>
> Yeah I think today with just struct_mutex it's impossible. But if we have
> more locks the waiting thread could continue to grab more locks instead of
> bailing out straight. And then the reset handler would be somewhat screwed
> since it isn't guaranteed to make forward progress.
So basically if you add a deadlock/livelock, it may deadlock/livelock.
> > > I /thought/ that the -EIO is from check_wedge in intel_ring_begin, but
> > > that part seems essentially unchanged.
> >
> > For two reasons, we need to to protect the access to the ring, and you
> > argued that (reporting of EIO from previous wedged GPUs) it was part of
> > the ABI. The other ABI that I think is important, is the reporting of
> > EIO if the user explicits waits on a request and it is incomplete (i.e.
> > wait_ioctl).
>
> Well then I don't get where the -EIO is from. That leaves a truly wedge
> gpu as the cause, and for that case I don't get how it can happen by
> accident with the current code.
We fail a reset, or to recover. Happens often enough.
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index ffd99d27fac7..5838882e10a1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -841,23 +841,31 @@ int i915_resume_legacy(struct drm_device *dev)
> > > > int i915_reset(struct drm_device *dev)
> > > > {
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + struct i915_gpu_error *error = &dev
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
>
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
>
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own commit.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_display.c | 88 ++-
> -
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 3 files changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> crtc_state->disable_lp_wm = false;
> crtc_state->disable_cxsr = false;
> crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>
> return &crtc_state->base;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 60f17bc5f0ce..299edbf6f99e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4738,9 +4738,6 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
> intel_frontbuffer_flip(dev, atomic->fb_bits);
>
> crtc->wm.cxsr_allowed = true;
> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
> if (atomic->post_enable_primary)
> intel_post_enable_primary(&crtc->base);
>
> + if (needs_modeset(&pipe_config->base))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> +
> memset(atomic, 0, sizeof(*atomic));
> }
>
> @@ -11693,6 +11693,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (!was_visible && !visible)
> return 0;
>
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
> turn_off = was_visible && (!visible || mode_changed);
> turn_on = visible && (!was_visible || mode_changed);
>
> @@ -11708,8 +11711,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>
> /* must disable cxsr around plane enable/disable */
> if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank = true;
> pipe_config->disable_cxsr = true;
> }
> } else if ((was_visible || visible) &&
> @@ -11757,14 +11758,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> plane_state->rotation != BIT(DRM_ROTATE_0))
> intel_crtc->atomic.disable_fbc = true;
>
> - /*
> - * BDW signals flip done immediately if the plane
> - * is disabled, even if the plane enable is already
> - * armed to occur at the next vblank :(
> - */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
> intel_crtc->atomic.update_fbc |= visible || mode_changed;
> break;
> case DRM_PLANE_TYPE_CURSOR:
> @@ -11779,12 +11772,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (IS_IVYBRIDGE(dev) &&
> needs_scaling(to_intel_plane_state(plane_state)) &&
> !needs_scaling(old_plane_state)) {
> - to_intel_crtc_state(crtc_state)->disable_lp_wm =
> true;
> - } else if (turn_off && !mode_changed) {
> - intel_crtc->atomic.wait_vblank = true;
> + pipe_config->disable_lp_wm = true;
> + } else if (turn_off && !mode_changed)
> intel_crtc->atomic.update_sprite_watermarks |=
> 1 << i;
> - }
>
> break;
> }
> @@ -13299,6 +13290,48 @@ static int intel_atomic_prepare_commit(struct
> drm_device *dev,
> return ret;
> }
>
> +static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
> + struct drm_i915_private *dev_priv,
> +
Re: [Intel-gfx] [MIPI CABC 2/2] drm/i915: CABC support for backlight control
On Mon, 16 Nov 2015, Deepak M wrote:
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
> their implementation. The CABC implementaion here assumes that the
> panels use standard SW register for control.
>
> In this design there will be no PWM signal from the SoC and DCS
> commands are sent to enable and control the backlight brightness.
I'd like you to move the DSI DCS backlight stuff from intel_panel.c to a
new file, say, intel_dsi_dcs_backlight.c, similar to what I told Yetunde
to do with DP DPCD backlight [1].
[1]
http://patchwork.freedesktop.org/patch/msgid/1447698547-9027-1-git-send-email-yetundex.adeb...@intel.com
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
> Addressed the review comments from Jani which were mentioned in
> the below patch
> http://lists.freedesktop.org/archives/intel-gfx/2015-September/075819.html
>
> Went with the name CABC because the commands which are used
> here are mainly for CABC and many of the panels have the same
> commands for the CABC operation. For the cases where PWM is
> directly from panel PWM, DCS commands may be different and
> may have to add new functions to support it.
>
> drivers/gpu/drm/i915/intel_dsi.c | 14 +++-
> drivers/gpu/drm/i915/intel_dsi.h | 24 ++
> drivers/gpu/drm/i915/intel_panel.c | 145
> +++--
> 3 files changed, 177 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 170ae6f..5d1ba35 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1175,8 +1175,20 @@ void intel_dsi_init(struct drm_device *dev)
> intel_dsi->ports = (1 << PORT_C);
> }
>
> - if (dev_priv->vbt.dsi.config->dual_link)
> + if (dev_priv->vbt.dsi.config->dual_link) {
> intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
> + switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
> + case CABC_PORT_A:
> + intel_dsi->bkl_dcs_ports = (1 << PORT_A);
> + case CABC_PORT_C:
> + intel_dsi->bkl_dcs_ports = (1 << PORT_C);
> + case CABC_PORT_A_AND_C:
> + intel_dsi->bkl_dcs_ports = intel_dsi->ports;
> + default:
> + DRM_ERROR("Unknown MIPI ports for sending DCS\n");
"break;" is useful in making the switch case do what you want.
> + }
> + } else
> + intel_dsi->bkl_dcs_ports = intel_dsi->ports;
>
> /* Create a DSI host (and a device) for each port. */
> for_each_dsi_port(port, intel_dsi->ports) {
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 4fde83b..4bcee40 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -34,6 +34,30 @@
> #define DSI_DUAL_LINK_FRONT_BACK 1
> #define DSI_DUAL_LINK_PIXEL_ALT 2
>
> +#define CABC_OFF (0 << 0)
> +#define CABC_USER_INTERFACE_IMAGE(1 << 0)
> +#define CABC_STILL_PICTURE (2 << 0)
> +#define CABC_VIDEO_MODE (3 << 0)
> +
> +#define CABC_BACKLIGHT (1 << 2)
> +#define CABC_DIMMING_DISPLAY (1 << 3)
> +#define CABC_BCTRL (1 << 5)
> +
> +#define CABC_PORT_A 0x00
> +#define CABC_PORT_C 0x01
> +#define CABC_PORT_A_AND_C0x02
> +
> +#define CABC_MAX_VALUE 0xFF
> +
> +#define MIPI_DCS_CABC_LEVEL_RD 0x52
> +#define MIPI_DCS_CABC_MIN_BRIGHTNESS_RD 0x5F
> +#define MIPI_DCS_CABC_CONTROL_RD 0x56
> +#define MIPI_DCS_CABC_CONTROL_BRIGHT_RD 0x54
> +#define MIPI_DCS_CABC_LEVEL_WR 0x51
> +#define MIPI_DCS_CABC_MIN_BRIGHTNESS_WR 0x5E
> +#define MIPI_DCS_CABC_CONTROL_WR 0x55
> +#define MIPI_DCS_CABC_CONTROL_BRIGHT_WR 0x53
> +
Put these in the new .c file. The rest of the code shouldn't need to know.
> struct intel_dsi_host;
>
> struct intel_dsi {
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index a24df35..085d9a6 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include "intel_drv.h"
> +#include "intel_dsi.h"
>
> #define CRC_PMIC_PWM_PERIOD_NS 21333
>
> @@ -533,6 +534,30 @@ static u32 vlv_get_backlight(struct intel_connector
> *connector)
> return _vlv_get_backlight(dev, pipe);
> }
>
> +static u32 cabc_get_backlight(struct intel_connector *connector)
> +{
> + struct intel_dsi *intel_dsi = NULL;
> + struct intel_encoder *encoder = NULL;
> + struct
Re: [Intel-gfx] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
On Mon, 16 Nov 2015, Deepak M wrote:
> For dual link panel scenarios there are new fileds added in the
> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
> commands needs to be sent.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/intel_bios.c | 13 +
> drivers/gpu/drm/i915/intel_bios.h | 5 -
> drivers/gpu/drm/i915/intel_dsi.h | 2 ++
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index ce82f9c..2ef8721 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -793,6 +793,19 @@ parse_mipi(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
> return;
> }
>
> + /*
> + * These below bits will inform us on which port the panel blk_cntrl and
> + * CABC ON/OFF commands needs to be sent in case of dual link panels
> + * u16 dl_cabc_port:2;
> + * u16 pwm_bkl_ctrl:2;
> + * But these are introduced from the VBT version 197 onwards, so making
> + * sure that these bits are zero in the pervious versions.
> + */
> + if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
> + dev_priv->vbt.dsi.config->dl_cabc_port = 0;
> + dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
> + }
> +
dev_priv->vbt is zero by default, so none of the above is needed.
> /* We have mandatory mipi config blocks. Initialize as generic panel */
> dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 7ec8c9a..9283969 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -832,7 +832,10 @@ struct mipi_config {
> u16 dual_link:2;
> u16 lane_cnt:2;
> u16 pixel_overlap:3;
> - u16 rsvd3:9;
> + u16 rgb_flip:1;
> + u16 dl_cabc_port:2;
> + u16 pwm_bkl_ctrl:2;
> + u16 rsvd3:4;
>
> u16 rsvd4;
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index e6cb252..4fde83b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -74,6 +74,8 @@ struct intel_dsi {
>
> u8 escape_clk_div;
> u8 dual_link;
> + u8 bkl_dcs_ports;
> + u8 pwm_blk_ctrl;
This is a much more natural place to explain what these things do.
> u8 pixel_overlap;
> u32 port_bits;
> u32 bw_timer;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
On Wed, 25 Nov 2015, Jani Nikula wrote:
> On Mon, 16 Nov 2015, Deepak M wrote:
>> For dual link panel scenarios there are new fileds added in the
>> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
>> commands needs to be sent.
>>
>> Cc: Jani Nikula
>> Cc: Daniel Vetter
>> Cc: Yetunde Adebisi
>> Signed-off-by: Deepak M
>> ---
>> drivers/gpu/drm/i915/intel_bios.c | 13 +
>> drivers/gpu/drm/i915/intel_bios.h | 5 -
>> drivers/gpu/drm/i915/intel_dsi.h | 2 ++
>> 3 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index ce82f9c..2ef8721 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -793,6 +793,19 @@ parse_mipi(struct drm_i915_private *dev_priv, const
>> struct bdb_header *bdb)
>> return;
>> }
>>
>> +/*
>> + * These below bits will inform us on which port the panel blk_cntrl and
>> + * CABC ON/OFF commands needs to be sent in case of dual link panels
>> + * u16 dl_cabc_port:2;
>> + * u16 pwm_bkl_ctrl:2;
>> + * But these are introduced from the VBT version 197 onwards, so making
>> + * sure that these bits are zero in the pervious versions.
>> + */
>> +if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
>> +dev_priv->vbt.dsi.config->dl_cabc_port = 0;
>> +dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
>> +}
>> +
>
> dev_priv->vbt is zero by default, so none of the above is needed.
Ugh, I didn't realize we just copy the dsi.config verbatim from
VBT. Maybe we do want this after all.
>
>> /* We have mandatory mipi config blocks. Initialize as generic panel */
>> dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index 7ec8c9a..9283969 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -832,7 +832,10 @@ struct mipi_config {
>> u16 dual_link:2;
>> u16 lane_cnt:2;
>> u16 pixel_overlap:3;
>> -u16 rsvd3:9;
>> +u16 rgb_flip:1;
>> +u16 dl_cabc_port:2;
>> +u16 pwm_bkl_ctrl:2;
>> +u16 rsvd3:4;
>>
>> u16 rsvd4;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
>> b/drivers/gpu/drm/i915/intel_dsi.h
>> index e6cb252..4fde83b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.h
>> +++ b/drivers/gpu/drm/i915/intel_dsi.h
>> @@ -74,6 +74,8 @@ struct intel_dsi {
>>
>> u8 escape_clk_div;
>> u8 dual_link;
>> +u8 bkl_dcs_ports;
>> +u8 pwm_blk_ctrl;
>
> This is a much more natural place to explain what these things do.
>
>> u8 pixel_overlap;
>> u32 port_bits;
>> u32 bw_timer;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.
On ke, 2015-11-25 at 14:21 +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > Currently we perform our own wait in post_plane_update,
> > but the atomic core performs another one in wait_for_vblanks.
> > This means that 2 vblanks are done when a fb is changed,
> > which is a bit overkill.
> >
> > Merge them by creating a helper function that takes a crtc mask
> > for the planes to wait on.
> >
> > The broadwell vblank workaround may look gone entirely but this is
> > not the case. pipe_config->wm_changed is set to true
> > when any plane is turned on, which forces a vblank wait.
> >
> > Changes since v1:
> > - Removing the double vblank wait on broadwell moved to its own commit.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/intel_atomic.c | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 88
> > ++-
> > -
> > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > 3 files changed, 65 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index 4625f8a9ba12..8e579a8505ac 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > crtc_state->disable_lp_wm = false;
> > crtc_state->disable_cxsr = false;
> > crtc_state->wm_changed = false;
> > + crtc_state->fb_changed = false;
> >
> > return &crtc_state->base;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 60f17bc5f0ce..299edbf6f99e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4738,9 +4738,6 @@ static void intel_post_plane_update(struct intel_crtc
> > *crtc)
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > - if (atomic->wait_vblank)
> > - intel_wait_for_vblank(dev, crtc->pipe);
> > -
> > intel_frontbuffer_flip(dev, atomic->fb_bits);
> >
> > crtc->wm.cxsr_allowed = true;
> > @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
> > *crtc)
> > if (atomic->post_enable_primary)
> > intel_post_enable_primary(&crtc->base);
> >
> > + if (needs_modeset(&pipe_config->base))
> > + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> > +
> > memset(atomic, 0, sizeof(*atomic));
> > }
> >
> > @@ -11693,6 +11693,9 @@ int intel_plane_atomic_calc_changes(struct
> > drm_crtc_state *crtc_state,
> > if (!was_visible && !visible)
> > return 0;
> >
> > + if (fb != old_plane_state->base.fb)
> > + pipe_config->fb_changed = true;
> > +
> > turn_off = was_visible && (!visible || mode_changed);
> > turn_on = visible && (!was_visible || mode_changed);
> >
> > @@ -11708,8 +11711,6 @@ int intel_plane_atomic_calc_changes(struct
> > drm_crtc_state *crtc_state,
> >
> > /* must disable cxsr around plane enable/disable */
> > if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> > - if (is_crtc_enabled)
> > - intel_crtc->atomic.wait_vblank = true;
> > pipe_config->disable_cxsr = true;
> > }
> > } else if ((was_visible || visible) &&
> > @@ -11757,14 +11758,6 @@ int intel_plane_atomic_calc_changes(struct
> > drm_crtc_state *crtc_state,
> > plane_state->rotation != BIT(DRM_ROTATE_0))
> > intel_crtc->atomic.disable_fbc = true;
> >
> > - /*
> > - * BDW signals flip done immediately if the plane
> > - * is disabled, even if the plane enable is already
> > - * armed to occur at the next vblank :(
> > - */
> > - if (turn_on && IS_BROADWELL(dev))
> > - intel_crtc->atomic.wait_vblank = true;
> > -
> > intel_crtc->atomic.update_fbc |= visible || mode_changed;
> > break;
> > case DRM_PLANE_TYPE_CURSOR:
> > @@ -11779,12 +11772,10 @@ int intel_plane_atomic_calc_changes(struct
> > drm_crtc_state *crtc_state,
> > if (IS_IVYBRIDGE(dev) &&
> > needs_scaling(to_intel_plane_state(plane_state)) &&
> > !needs_scaling(old_plane_state)) {
> > - to_intel_crtc_state(crtc_state)->disable_lp_wm =
> > true;
> > - } else if (turn_off && !mode_changed) {
> > - intel_crtc->atomic.wait_vblank = true;
> > + pipe_config->disable_lp_wm = true;
> > + } else if (turn_off && !mode_changed)
> > intel_crtc->atomic.update_sprite_watermarks |=
> > 1 << i;
> > - }
> >
> > break;
> > }
> > @@ -13299,6 +13290,48 @@ static int intel_atomic_prepare_commit(
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
>
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
>
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own commit.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_display.c | 88 ++-
> -
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 3 files changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> crtc_state->disable_lp_wm = false;
> crtc_state->disable_cxsr = false;
> crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>
> return &crtc_state->base;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 60f17bc5f0ce..299edbf6f99e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4738,9 +4738,6 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
> intel_frontbuffer_flip(dev, atomic->fb_bits);
>
> crtc->wm.cxsr_allowed = true;
> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
> if (atomic->post_enable_primary)
> intel_post_enable_primary(&crtc->base);
>
> + if (needs_modeset(&pipe_config->base))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> +
> memset(atomic, 0, sizeof(*atomic));
> }
>
> @@ -11693,6 +11693,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (!was_visible && !visible)
> return 0;
>
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
> turn_off = was_visible && (!visible || mode_changed);
> turn_on = visible && (!was_visible || mode_changed);
>
> @@ -11708,8 +11711,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>
> /* must disable cxsr around plane enable/disable */
> if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank = true;
> pipe_config->disable_cxsr = true;
> }
> } else if ((was_visible || visible) &&
> @@ -11757,14 +11758,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> plane_state->rotation != BIT(DRM_ROTATE_0))
> intel_crtc->atomic.disable_fbc = true;
>
> - /*
> - * BDW signals flip done immediately if the plane
> - * is disabled, even if the plane enable is already
> - * armed to occur at the next vblank :(
> - */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
> intel_crtc->atomic.update_fbc |= visible || mode_changed;
> break;
> case DRM_PLANE_TYPE_CURSOR:
> @@ -11779,12 +11772,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (IS_IVYBRIDGE(dev) &&
> needs_scaling(to_intel_plane_state(plane_state)) &&
> !needs_scaling(old_plane_state)) {
> - to_intel_crtc_state(crtc_state)->disable_lp_wm =
> true;
> - } else if (turn_off && !mode_changed) {
> - intel_crtc->atomic.wait_vblank = true;
> + pipe_config->disable_lp_wm = true;
> + } else if (turn_off && !mode_changed)
> intel_crtc->atomic.update_sprite_watermarks |=
> 1 << i;
> - }
Did you intend to delete the braces on both sides of the if? Sorry, OCD. :)
Other than this and the comment on the other thread were I added Patrik and
Imre, this looks good.
Ander
>
> break;
> }
> @@ -13299,6 +13290,48 @@ static int intel_atomic_prepare_commit(struct
> drm_devic
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
On 11/24/2015 1:33 PM, Wang, Zhi A wrote: Hi Gurus: I’m wondering what’s the right approach to deal with the context switch reason: element_switch? According to b-spec, one ELSP submission may include two elements, when one element is finished, HW will move to process next element, the previous context will be scheduled out with a “element_switch” context switch reason. Correct, in fact you get 2 flags, element_switch & context_complete. I saw that i915 would try to start a new ELSP write which may contain two new elements when it found a “element_switch” CSB in the context switch handler. I’m a bit confused here, as HW may be still running a context at this time, I’m not sure if two new elements can be submitted at this time. So I think maybe my understanding about this context switch reason might be wrong. The driver is trying to speed up the execution when there are +3 contexts queued. The first _new_ element you mention is in fact the running context. Anyone can educate me how to deal with the “element_switch” CSB? Let's say you have contexts A, B, C and D already in queue, so A & B are sent to the ELSP. After element_switch (A completed) B starts automatically, at this point the driver will send a new execlist with B and C, effectively lite-restoring B (note it cannot be a different context since that will cause a preemption). And when B completes, the driver sends C & D. Lite-restoring the 2nd ctx of each execlist allows us to send these 4 contexts with only 3 ELSP writes. Thanks, Zhi. -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
Wow, that's nice! Thanks Michel for the clear explanation! That's just the answer I'm looking for! :) Thanks, Zhi. > -Original Message- > From: Thierry, Michel > Sent: Wednesday, November 25, 2015 8:48 PM > To: Wang, Zhi A; intel-gfx@lists.freedesktop.org > Cc: Han, Xu; Li, Weinan Z; He, Min > Subject: Re: [Intel-gfx] About dealing with CSB.context element switch in > execlist mode. > > On 11/24/2015 1:33 PM, Wang, Zhi A wrote: > > Hi Gurus: > > > > I'm wondering what's the right approach to deal with the context > > switch > > reason: element_switch? According to b-spec, one ELSP submission may > > include two elements, when one element is finished, HW will move to > > process next element, the previous context will be scheduled out with > > a "element_switch" context switch reason. > > Correct, in fact you get 2 flags, element_switch & context_complete. > > > > > I saw that i915 would try to start a new ELSP write which may contain > > two new elements when it found a "element_switch" CSB in the context > > switch handler. I'm a bit confused here, as HW may be still running a > > context at this time, I'm not sure if two new elements can be > > submitted at this time. So I think maybe my understanding about this > > context switch reason might be wrong. > > The driver is trying to speed up the execution when there are +3 contexts > queued. The first _new_ element you mention is in fact the running context. > > > > > Anyone can educate me how to deal with the "element_switch" CSB? > > > > Let's say you have contexts A, B, C and D already in queue, so A & B are > sent to the ELSP. > > After element_switch (A completed) B starts automatically, at this point > the driver will send a new execlist with B and C, effectively > lite-restoring B (note it cannot be a different context since that will > cause a preemption). > > And when B completes, the driver sends C & D. Lite-restoring the 2nd ctx > of each execlist allows us to send these 4 contexts with only 3 ELSP writes. > > > Thanks, > > > > Zhi. > > > -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Remove intel_crtc->atomic.disable_ips.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> This is a revert of commit 066cf55b9ce3 "drm/i915: Fix IPS related flicker".
> intel_pre_disable_primary already handles this, and now everything
> goes through the atomic path there's no need to try to disable ips twice.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_display.c | 16 +---
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 2 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 299edbf6f99e..1fec49c4490e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4768,9 +4768,6 @@ static void intel_pre_plane_update(struct intel_crtc
> *crtc)
> if (atomic->disable_fbc)
> intel_fbc_disable_crtc(crtc);
>
> - if (crtc->atomic.disable_ips)
> - hsw_disable_ips(crtc);
> -
> if (atomic->pre_disable_primary)
> intel_pre_disable_primary(&crtc->base);
>
> @@ -11727,19 +11724,8 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> intel_crtc->atomic.pre_disable_primary = turn_off;
> intel_crtc->atomic.post_enable_primary = turn_on;
>
> - if (turn_off) {
> - /*
> - * FIXME: Actually if we will still have any other
> - * plane enabled on the pipe we could let IPS enabled
> - * still, but for now lets consider that when we make
> - * primary invisible by setting DSPCNTR to 0 on
> - * update_primary_plane function IPS needs to be
> - * disable.
> - */
> - intel_crtc->atomic.disable_ips = true;
> -
> + if (turn_off)
> intel_crtc->atomic.disable_fbc = true;
> - }
>
> /*
>* FBC does not work on some platforms for rotated
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 66f66740ccaa..13ffefa3a6c1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -535,7 +535,6 @@ struct intel_mmio_flip {
> struct intel_crtc_atomic_commit {
> /* Sleepable operations to perform before commit */
> bool disable_fbc;
> - bool disable_ips;
> bool pre_disable_primary;
>
> /* Sleepable operations to perform after commit */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle
On 25/11/2015 01:11, Dai, Yu wrote:
On 11/24/2015 08:23 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been saved.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
This is to solve a hang with GuC submission, and a theoretical
issue with execlist submission.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
Signed-off-by: Nick Hoath
Issue: VIZ-4277
Cc: Daniel Vetter
Cc: David Gordon
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 9 -
drivers/gpu/drm/i915/intel_lrc.c | 73
++--
drivers/gpu/drm/i915/intel_lrc.h | 1 +
4 files changed, 65 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5cf30b..4d2f44c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ bool unsaved;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e955499..6fee473 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,6 +1354,14 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
{
trace_i915_gem_request_retire(request);
+ if (i915.enable_execlists) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&request->ring->execlist_lock, flags);
+ intel_lr_context_complete_check(request);
+ spin_unlock_irqrestore(&request->ring->execlist_lock, flags);
+ }
+
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
@@ -1384,7 +1392,6 @@ __i915_gem_request_retire__upto(struct
drm_i915_gem_request *req)
do {
tmp = list_first_entry(&engine->request_list,
typeof(*tmp), list);
-
i915_gem_request_retire(tmp);
} while (tmp != req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06180dc..a527c21 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -566,9 +566,6 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
- if (request->ctx != ring->default_context)
- intel_lr_context_pin(request);
-
i915_gem_request_reference(request);
spin_lock_irq(&ring->execlist_lock);
@@ -728,10 +725,16 @@ intel_logical_ring_advance_and_submit(struct
drm_i915_gem_request *request)
intel_logical_ring_advance(request->ringbuf);
request->tail = request->ringbuf->tail;
-
if (intel_ring_stopped(ring))
return;
+ if (request->ctx != ring->default_context) {
+ if (!request->ctx->engine[ring->id].unsaved) {
+ intel_lr_context_pin(request);
+ request->ctx->engine[ring->id].unsaved = true;
+ }
+ }
+
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -958,12 +961,6 @@ void intel_execlists_retire_requests(struct
intel_engine_cs *ring)
spin_unlock_irq(&ring->execlist_lock);
list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
- struct intel_context *ctx = req->ctx;
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[ring->id].state;
-
- if (ctx_obj && (ctx != ring->default_context))
- intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
}
@@ -1058,21 +1055,41 @@ reset_pin_count:
return ret;
}
-void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
+static void intel_lr_context_unpin_no_req(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
{
- struct intel_engine_cs *ring = rq->ring;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
- struct intel_ringbuffer *ringbuf = rq->ringbuf;
-
Re: [Intel-gfx] [PATCH] drm/i915: Add some more bits to CURSOR_POS_MASK
On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote:
> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
> > 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 position is bit 0:11, and even 0:12 on some hw where
> > > remaining bits up to bit 14 is MBZ. For Y position it is bits 16-27
> > > where bits 28:30 is MBZ. It should be safe to increase CURSOR_POS_MASK
> > > to 13 bits (0x1FFF) making 8192 as a new wrap around value still getting
> > > valid cursor positions on platforms with only 12bits available thanks to
> > > MBZ on adjacent bits above.
> >
> > I cannot find documentation for older hardware and this only touches
> > debugfs, so in worst case we get wrong values for really old hardware but
> > good
> > ones for newer. I think that's a fair tradeoff.
> >
> > Reviewed-by: Patrik Jakobsson
>
> If it's only used in debugfs then imo just drop it. Having a _MASK which
> isn't valid on all platforms, but where we don't have differnt #defines
> for the different platforms is really confusing.
> -Daniel
Well, not the most important patch around, but still the value of 0x7ff
is still too conservative and gives wrong cursor pos values on large
panels. I have hard times digging up really old register specs so I
still can't see which Intel platform this new value of mine isn't valid
on.
It is this patch by Chris in debugfs that is broken on large panels
wrapping coords at (x_pos/y_pos > 2048)
http://marc.info/?l=git-commits-head&m=139697989108096&w=1
> >
> > >
> > > Signed-off-by: Robert Fekete
> > > ---
> > > 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 894253228947..f351f46f8cb9 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4883,7 +4883,7 @@ enum skl_disp_power_wells {
> > > #define CURSOR_TRICKLE_FEED_DISABLE(1 << 14)
> > > #define _CURABASE0x70084
> > > #define _CURAPOS 0x70088
> > > -#define CURSOR_POS_MASK 0x007FF
> > > +#define CURSOR_POS_MASK 0x01FFF
> > > #define CURSOR_POS_SIGN 0x8000
> > > #define CURSOR_X_SHIFT0
> > > #define CURSOR_Y_SHIFT16
> > > --
> > > 1.9.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
BR
/Robert Fekete
Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Change context lifecycle
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
already have a request pending on it (Alex Dai)
Rename unsaved to dirty to avoid double negatives (Dave Gordon)
Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
Split out per engine cleanup from context_free as it
was getting unwieldy
Corrected locking (Dave Gordon)
Signed-off-by: Nick Hoath
Issue: VIZ-4277
Cc: Daniel Vetter
Cc: David Gordon
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/intel_lrc.c | 124 +++
drivers/gpu/drm/i915/intel_lrc.h | 1 +
4 files changed, 105 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5cf30b..e82717a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ bool dirty;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e955499..3829bc1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
{
trace_i915_gem_request_retire(request);
+ if (i915.enable_execlists)
+ intel_lr_context_complete_check(request);
+
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06180dc..03d5bca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -566,9 +566,6 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
- if (request->ctx != ring->default_context)
- intel_lr_context_pin(request);
-
i915_gem_request_reference(request);
spin_lock_irq(&ring->execlist_lock);
@@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
drm_i915_gem_request *request)
if (intel_ring_stopped(ring))
return;
+ if (request->ctx != ring->default_context) {
+ if (!request->ctx->engine[ring->id].dirty) {
+ intel_lr_context_pin(request);
+ request->ctx->engine[ring->id].dirty = true;
+ }
+ }
+
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
intel_engine_cs *ring)
spin_unlock_irq(&ring->execlist_lock);
list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
- struct intel_context *ctx = req->ctx;
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[ring->id].state;
-
- if (ctx_obj && (ctx != ring->default_context))
- intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
}
@@ -1058,21 +1056,39 @@ reset_pin_count:
return ret;
}
-void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
+static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
{
- struct intel_engine_cs *ring = rq->ring;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
- struct intel_ringbuffer *ringbuf = rq->ringbuf;
-
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
+ struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
if (ctx_obj) {
WARN_ON(!mutex_is_locked(&ring->dev->struct_mutex));
- if (--rq->ctx->engine[ring->id].pin_count == 0) {
+ if (--ctx->engine[ring->id].pin_count == 0) {
intel_unpin_ringbuffer_obj(ring
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
Another question about EXECLIST is: Can a preemption happen between element switch? I know this is beyond the scope of i915 a little. I'm just curious if it's possible. Let's say we have context A B C At first, we submit context A B in one ELSP write. Then, we submit context C in another ELSP write at some time. If context A or B is running and gets preempted, then there will be CSB.preempted in CSB buffer. This is the normal behavior. I'm wondering that if there is any possibility that a preemption can happen between the two elements. Then the CSB should look like: [CSB 0 idle-to-active] [CSB 1 CTX A element_switch/context_complete] [CSB 2 CTX C active-to-idle/context_complete] Is it possible? Thanks, Zhi. > -Original Message- > From: Thierry, Michel > Sent: Wednesday, November 25, 2015 8:48 PM > To: Wang, Zhi A; intel-gfx@lists.freedesktop.org > Cc: Han, Xu; Li, Weinan Z; He, Min > Subject: Re: [Intel-gfx] About dealing with CSB.context element switch in > execlist mode. > > On 11/24/2015 1:33 PM, Wang, Zhi A wrote: > > Hi Gurus: > > > > I'm wondering what's the right approach to deal with the context > > switch > > reason: element_switch? According to b-spec, one ELSP submission may > > include two elements, when one element is finished, HW will move to > > process next element, the previous context will be scheduled out with > > a "element_switch" context switch reason. > > Correct, in fact you get 2 flags, element_switch & context_complete. > > > > > I saw that i915 would try to start a new ELSP write which may contain > > two new elements when it found a "element_switch" CSB in the context > > switch handler. I'm a bit confused here, as HW may be still running a > > context at this time, I'm not sure if two new elements can be > > submitted at this time. So I think maybe my understanding about this > > context switch reason might be wrong. > > The driver is trying to speed up the execution when there are +3 contexts > queued. The first _new_ element you mention is in fact the running context. > > > > > Anyone can educate me how to deal with the "element_switch" CSB? > > > > Let's say you have contexts A, B, C and D already in queue, so A & B are > sent to the ELSP. > > After element_switch (A completed) B starts automatically, at this point > the driver will send a new execlist with B and C, effectively > lite-restoring B (note it cannot be a different context since that will > cause a preemption). > > And when B completes, the driver sends C & D. Lite-restoring the 2nd ctx > of each execlist allows us to send these 4 contexts with only 3 ELSP writes. > > > Thanks, > > > > Zhi. > > > -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.
On Mon, Nov 02, 2015 at 12:33:47PM -0800, Rafael Antognolli wrote:
> +static int __init drm_dp_aux_dev_init(void)
> +{
> + int res;
> +
> + drm_dp_aux_dev_class = class_create(THIS_MODULE, "drm_dp_aux_dev");
> + if (IS_ERR(drm_dp_aux_dev_class)) {
> + res = PTR_ERR(drm_dp_aux_dev_class);
> + goto out;
> + }
> + drm_dp_aux_dev_class->dev_groups = drm_dp_aux_groups;
> +
> + res = register_chrdev(0, "aux", &auxdev_fops);
> + if (res < 0)
> + goto out;
> + drm_dev_major = res;
> +
> + return 0;
> +out:
> + class_destroy(drm_dp_aux_dev_class);
> + return res;
> +}
> +
> +static void __exit drm_dp_aux_dev_exit(void)
> +{
> + unregister_chrdev(drm_dev_major, "aux");
> + class_destroy(drm_dp_aux_dev_class);
> +}
> +
> +MODULE_AUTHOR("Rafael Antognolli ");
> +MODULE_DESCRIPTION("DRM DP AUX /dev entries driver");
> +MODULE_LICENSE("GPL and additional rights");
> +
> +module_init(drm_dp_aux_dev_init);
> +module_exit(drm_dp_aux_dev_exit);
Since this is no longer a separate module this stuff can cause a
build failure due to drm_fb_helper.c already providing a module_init
for the same module.
So maybe we neet to have module_init/exit for drm_kms_helper.o in
some central place and have those call the init/exit functions for
drm_fb_helper and drm_dp_aux_dev?
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9535c5b..7d58f59 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -754,6 +755,8 @@ static const struct i2c_algorithm drm_dp_i2c_algo = {
> */
> int drm_dp_aux_register(struct drm_dp_aux *aux)
> {
> + int ret;
> +
> mutex_init(&aux->hw_mutex);
>
> aux->ddc.algo = &drm_dp_i2c_algo;
> @@ -768,7 +771,17 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
> sizeof(aux->ddc.name));
>
> - return i2c_add_adapter(&aux->ddc);
> + ret = drm_dp_aux_register_devnode(aux);
> + if (ret)
> + return ret;
> +
> + ret = i2c_add_adapter(&aux->ddc);
> + if (ret) {
> + drm_dp_aux_unregister_devnode(aux);
> + return ret;
> + }
> +
> + return 0;
> }
> EXPORT_SYMBOL(drm_dp_aux_register);
>
> @@ -778,6 +791,7 @@ EXPORT_SYMBOL(drm_dp_aux_register);
> */
> void drm_dp_aux_unregister(struct drm_dp_aux *aux)
> {
> + drm_dp_aux_unregister_devnode(aux);
> i2c_del_adapter(&aux->ddc);
> }
> EXPORT_SYMBOL(drm_dp_aux_unregister);
> diff --git a/include/drm/drm_dp_aux_dev.h b/include/drm/drm_dp_aux_dev.h
> new file mode 100644
> index 000..391a2cf
> --- /dev/null
> +++ b/include/drm/drm_dp_aux_dev.h
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Rafael Antognolli
> + *
> + */
> +
> +#ifndef DRM_DP_AUX_DEV
> +#define DRM_DP_AUX_DEV
> +
> +#ifdef CONFIG_DRM_DP_AUX_CHARDEV
> +
> +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
> +void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
> +
> +#else
> +
> +static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> +{
> + return 0;
> +}
> +
> +static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> +{
> + return 0;
> +}
> +
> +#endif
> +
> +#endif
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Re: [Intel-gfx] [PATCH 09/12] drm/i915: Remove some post-commit members from intel_crtc->atomic, v2.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> fb_bits is useful to have in the crtc_state for cs flips when
> the code is updated to use intel_frontbuffer_flip_prepare/complete.
> So calculate it in advance and move it to crtc_state. The other stuff
> can be calculated in post_plane_update, and aren't useful elsewhere.
>
> Changes since v1:
> - Changing wording, remove comment about loop.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_display.c | 29 -
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> 3 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 8e579a8505ac..9a45cff26767 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -98,6 +98,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> crtc_state->disable_cxsr = false;
> crtc_state->wm_changed = false;
> crtc_state->fb_changed = false;
> + crtc_state->fb_bits = 0;
>
> return &crtc_state->base;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d539703de367..95501aba7d23 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4730,15 +4730,20 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
> hsw_disable_ips(intel_crtc);
> }
>
> -static void intel_post_plane_update(struct intel_crtc *crtc)
> +static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> + struct drm_atomic_state *old_state = old_crtc_state->base.state;
> struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc->base.state);
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_plane *primary = crtc->base.primary;
> + struct drm_plane_state *old_pri_state =
> + drm_atomic_get_existing_plane_state(old_state, primary);
>
> - intel_frontbuffer_flip(dev, atomic->fb_bits);
> + intel_frontbuffer_flip(dev, pipe_config->fb_bits);
>
> crtc->wm.cxsr_allowed = true;
>
> @@ -4748,8 +4753,17 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
> if (atomic->update_fbc)
> intel_fbc_update(dev_priv);
>
> - if (atomic->post_enable_primary)
> - intel_post_enable_primary(&crtc->base);
> + if (old_pri_state) {
> + struct intel_plane_state *primary_state =
> + to_intel_plane_state(primary->state);
> + struct intel_plane_state *old_primary_state =
> + to_intel_plane_state(old_pri_state);
Hmm, old_pri_state and old_primary_state. I wonder if it is worth creating a
intel_atomic_get_existing_plane_state() helper to avoid this kind of stuff.
Something to check out later.
Reviewed-by: Ander Conselvan de Oliveira
> +
> + if (primary_state->visible &&
> + (needs_modeset(&pipe_config->base) ||
> + !old_primary_state->visible))
> + intel_post_enable_primary(&crtc->base);
> + }
>
> if (needs_modeset(&pipe_config->base))
> intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> @@ -11729,13 +11743,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> }
>
> if (visible || was_visible)
> - intel_crtc->atomic.fb_bits |=
> - to_intel_plane(plane)->frontbuffer_bit;
> + pipe_config->fb_bits |= to_intel_plane(plane)
> ->frontbuffer_bit;
>
> switch (plane->type) {
> case DRM_PLANE_TYPE_PRIMARY:
> - intel_crtc->atomic.post_enable_primary = turn_on;
> -
> if (turn_off)
> intel_crtc->atomic.disable_fbc = true;
>
> @@ -13444,7 +13455,7 @@ static int intel_atomic_commit(struct drm_device *dev,
> intel_atomic_wait_for_vblanks(dev, dev_priv, crtc_vblank_mask);
>
> for_each_crtc_in_state(state, crtc, crtc_state, i)
> - intel_post_plane_update(to_intel_crtc(crtc));
> + intel_post_plane_update(to_intel_crtc_state(crtc_state));
>
> mutex_lock(&dev->struct_mutex);
> drm_atomic_helper_cleanup_planes(dev, state);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e4ae629e7009..35ae827ab923 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -370,6 +370,7 @@ struct intel_crtc_state {
> #define PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS(1<<0) /* unreliable sync
> mode.flags */
> unsigned long quirks;
>
> + unsigned fb_bits; /*
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
On 11/25/2015 1:00 PM, Wang, Zhi A wrote: Another question about EXECLIST is: Can a preemption happen between element switch? I know this is beyond the scope of i915 a little. I'm just curious if it's possible. Let's say we have context A B C At first, we submit context A B in one ELSP write. Then, we submit context C in another ELSP write at some time. If context A or B is running and gets preempted, then there will be CSB.preempted in CSB buffer. This is the normal behavior. I'm wondering that if there is any possibility that a preemption can happen between the two elements. Then the CSB should look like: [CSB 0 idle-to-active] [CSB 1 CTX A element_switch/context_complete] [CSB 2 CTX C active-to-idle/context_complete] Is it possible? I would expect to always have a preempted event in the CSB, even in the remote case that A already completed and B hasn't started; there was an active execlist and it has been replaced by a new one: [CSB 0 idle-to-active] [CSB 1 CTX A element_switch/context_complete] [CSB 2 preempted ] [CSB 3 CTX C active-to-idle/context_complete] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Introduce bdw_{update, enable, disable}_pipe_irq()
On Tue, Nov 24, 2015 at 06:52:09PM +0100, Daniel Vetter wrote:
> On Mon, Nov 23, 2015 at 06:06:17PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Pull the BDW+ DE pipe interrupt mask frobbing into a central place,
> > like we have for other platforms.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 14 ++
> > drivers/gpu/drm/i915/i915_irq.c| 41
> > +-
> > drivers/gpu/drm/i915/intel_fifo_underrun.c | 8 ++
> > 3 files changed, 51 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index b9f86a73c543..c3330ff5016d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2762,6 +2762,20 @@ ilk_disable_display_irq(struct drm_i915_private
> > *dev_priv, uint32_t bits)
> > {
> > ilk_update_display_irq(dev_priv, bits, 0);
> > }
> > +void bdw_update_pipe_irq(struct drm_i915_private *dev_priv,
> > +enum pipe pipe,
> > +uint32_t interrupt_mask,
> > +uint32_t enabled_irq_mask);
> > +static inline void bdw_enable_pipe_irq(struct drm_i915_private *dev_priv,
> > + enum pipe pipe, uint32_t bits)
> > +{
> > + bdw_update_pipe_irq(dev_priv, pipe, bits, bits);
> > +}
> > +static inline void bdw_disable_pipe_irq(struct drm_i915_private *dev_priv,
> > + enum pipe pipe, uint32_t bits)
> > +{
> > + bdw_update_pipe_irq(dev_priv, pipe, bits, 0);
> > +}
> > void ibx_display_interrupt_update(struct drm_i915_private *dev_priv,
> > uint32_t interrupt_mask,
> > uint32_t enabled_irq_mask);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 5aea557f3776..92389a9bb301 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -438,6 +438,38 @@ static void bdw_update_port_irq(struct
> > drm_i915_private *dev_priv,
> > }
> >
> > /**
> > + * bdw_update_pipe_irq - update DE pipe interrupt
> > + * @dev_priv: driver private
> > + * @pipe: pipe whose interrupt to update
> > + * @interrupt_mask: mask of interrupt bits to update
> > + * @enabled_irq_mask: mask of interrupt bits to enable
> > + */
>
> kerneldoc is aligned like
>
> /**
> *
> */
Hmm. Copy pasted from bdw_update_port_irq() so I guess I get to fix that
one as well. I'll send a separate patch for it.
>
> With that OCD in the OCD addressed:
>
> Reviewed-by: Daniel Vetter
>
> > +void bdw_update_pipe_irq(struct drm_i915_private *dev_priv,
> > +enum pipe pipe,
> > +uint32_t interrupt_mask,
> > +uint32_t enabled_irq_mask)
> > +{
> > + uint32_t new_val;
> > +
> > + assert_spin_locked(&dev_priv->irq_lock);
> > +
> > + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> > +
> > + if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> > + return;
> > +
> > + new_val = dev_priv->de_irq_mask[pipe];
> > + new_val &= ~interrupt_mask;
> > + new_val |= (~enabled_irq_mask & interrupt_mask);
> > +
> > + if (new_val != dev_priv->de_irq_mask[pipe]) {
> > + dev_priv->de_irq_mask[pipe] = new_val;
> > + I915_WRITE(GEN8_DE_PIPE_IMR(pipe), dev_priv->de_irq_mask[pipe]);
> > + POSTING_READ(GEN8_DE_PIPE_IMR(pipe));
> > + }
> > +}
> > +
> > +/**
> > * ibx_display_interrupt_update - update SDEIMR
> > * @dev_priv: driver private
> > * @interrupt_mask: mask of interrupt bits to update
> > @@ -2658,10 +2690,9 @@ static int gen8_enable_vblank(struct drm_device
> > *dev, unsigned int pipe)
> > unsigned long irqflags;
> >
> > spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> > - dev_priv->de_irq_mask[pipe] &= ~GEN8_PIPE_VBLANK;
> > - I915_WRITE(GEN8_DE_PIPE_IMR(pipe), dev_priv->de_irq_mask[pipe]);
> > - POSTING_READ(GEN8_DE_PIPE_IMR(pipe));
> > + bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
> > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> > +
> > return 0;
> > }
> >
> > @@ -2709,9 +2740,7 @@ static void gen8_disable_vblank(struct drm_device
> > *dev, unsigned int pipe)
> > unsigned long irqflags;
> >
> > spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> > - dev_priv->de_irq_mask[pipe] |= GEN8_PIPE_VBLANK;
> > - I915_WRITE(GEN8_DE_PIPE_IMR(pipe), dev_priv->de_irq_mask[pipe]);
> > - POSTING_READ(GEN8_DE_PIPE_IMR(pipe));
> > + bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
> > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > index 48bd079bdb06..bda526660e20 100644
> > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > +++ b/drivers/gpu/drm/i915/in
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
OK. I see. Thanks Michel! :) Have a nice day. :) Thanks, Zhi. > -Original Message- > From: Thierry, Michel > Sent: Wednesday, November 25, 2015 9:15 PM > To: Wang, Zhi A; intel-gfx@lists.freedesktop.org > Cc: Han, Xu; Li, Weinan Z; He, Min; Lv, Zhiyuan; Tian, Kevin > Subject: Re: [Intel-gfx] About dealing with CSB.context element switch in > execlist mode. > > On 11/25/2015 1:00 PM, Wang, Zhi A wrote: > > Another question about EXECLIST is: Can a preemption happen between > element switch? > > > > I know this is beyond the scope of i915 a little. I'm just curious if it's > > possible. > > > > Let's say we have context A B C > > > > At first, we submit context A B in one ELSP write. > > Then, we submit context C in another ELSP write at some time. > > > > If context A or B is running and gets preempted, then there will be > CSB.preempted in CSB buffer. This is the normal behavior. > > > > I'm wondering that if there is any possibility that a preemption can happen > between the two elements. > > > > Then the CSB should look like: > > > > [CSB 0 idle-to-active] > > [CSB 1 CTX A element_switch/context_complete] [CSB 2 CTX C > > active-to-idle/context_complete] > > > > Is it possible? > > I would expect to always have a preempted event in the CSB, even in the > remote case that A already completed and B hasn't started; there was an > active execlist and it has been replaced by a new one: > > [CSB 0 idle-to-active] > [CSB 1 CTX A element_switch/context_complete] > [CSB 2 preempted ] > [CSB 3 CTX C active-to-idle/context_complete] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/drm_import_export: Always loop with mutex held
We assume that lock is held on start of the loop scope.
Some paths continuing inside loop didn't adhere to this
assumption, causing segfault on unlocking an already
unlocked mutex. Fix this by re-aquiring lock always.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93013
Cc: Michał Winiarski
Cc: Thomas Wood
Signed-off-by: Mika Kuoppala
---
tests/drm_import_export.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index 49486ab..cfe5f6d 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -161,20 +161,20 @@ static void *import_close_thread(void *data)
pthread_mutex_unlock(&t->mutex);
}
else
- /* We take the lock right after entering the
loop */
+ /* Lock should be held on entering the loop */
continue;
}
+
if (bo == NULL) {
/*
* If the bo is NULL it means that we've unreferenced
in other
* thread - therefore we should expect ENOENT
*/
igt_assert_eq(errno, ENOENT);
- continue;
+ } else {
+ drm_intel_bo_unreference(bo);
}
- drm_intel_bo_unreference(bo);
-
pthread_mutex_lock(&t->mutex);
}
pthread_mutex_unlock(&t->mutex);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On 11/25/2015 3:28 PM, Chris Wilson wrote:
On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. By doing so, we avoid unbinding objects that cannot be
shrunk and so wasting CPU cycles flushing those objects from the GPU to
the system and then immediately back again (as they will more than
likely be reused shortly after).
Based on a patch by Akash Goel.
Reported-by: Akash Goel
Signed-off-by: Chris Wilson
Cc: Akash Goel
Cc: sourab.gu...@intel.com
Cc: linux...@kvack.org should be done on this one, just in case they have
ideas for proper interfaces for this. Which might be, given that Jerome
Glisse is working on swaput-to-vram and other fun stuff like that.
Also, how does stuff like zswap (or whatever "compress my swap in memory"
is called again) factor in here? Iirc Android very much does use that.
It doesn't. We would need
#include
static bool swap_available(void)
{
return total_swap_pages || frontswap_enabled;
}
But if that then returns true for Android it seems the primary usecase
is invalidated.
Though CONFIG_FRONTSWAP is not set yet, but recently ZRAM (Compressed
Swap in RAM) has been enabled on some devices, so 'total_swap_pages'
will be nonzero on those devices.
Well swapping to frontswap should be ok. Trashing not so much, and if we
do that I suspect there's something really loopsided with memory usage
balancing going on ... Does the android workload have your "only shrink
inactive" patch already?
Sorry the "only shrink inactive" patch has not been included yet.
Will pull these 2 patches.
5763ff0 drm/i915: Avoid GPU stalls from kswapd
c9c0f5e drm/i915: During shrink_all we only need to idle the GPU
Best regards
Akash
I'll let Akash or Sourab comment, but the background to the patch was
that they observed that under memory pressure a framebuffer was being
unbound (obviously not pinned as a current scanout) and then rebound
(clflushing both ways ofc). My gut says that the priority lists in the
kernel and userspace are akilter if we either fail to purge the LRU
object in the kernel or if userspace then doesn't try to reuse the MRU
backbuffer.
One thing I did notice when also dealing with memory
pressure flushing backbuffers was (a) they were unaligned and so needed
rebinding before pinning
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c
and (b) we didn't bump the scanout on the inactive list
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=3a23ff3e5e201a52068d6e9d65f4ffb95077c21e
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/drm_import_export: Always loop with mutex held
On Wed, 2015-11-25 at 15:20 +0200, Mika Kuoppala wrote:
> We assume that lock is held on start of the loop scope.
> Some paths continuing inside loop didn't adhere to this
> assumption, causing segfault on unlocking an already
> unlocked mutex. Fix this by re-aquiring lock always.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93013
> Cc: Michał Winiarski
> Cc: Thomas Wood
> Signed-off-by: Mika Kuoppala
Reviewed-by: Michał Winiarski
> ---
> tests/drm_import_export.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
> index 49486ab..cfe5f6d 100644
> --- a/tests/drm_import_export.c
> +++ b/tests/drm_import_export.c
> @@ -161,20 +161,20 @@ static void *import_close_thread(void *data)
> pthread_mutex_unlock(&t->mutex);
> }
> else
> - /* We take the lock right after
> entering the loop */
> + /* Lock should be held on entering
> the loop */
> continue;
> }
> +
> if (bo == NULL) {
> /*
> * If the bo is NULL it means that we've
> unreferenced in other
> * thread - therefore we should expect
> ENOENT
> */
> igt_assert_eq(errno, ENOENT);
> - continue;
> + } else {
> + drm_intel_bo_unreference(bo);
> }
>
> - drm_intel_bo_unreference(bo);
> -
> pthread_mutex_lock(&t->mutex);
> }
> pthread_mutex_unlock(&t->mutex);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.
Hi,
On 25 November 2015 at 12:21, Ander Conselvan De Oliveira
wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
>> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
>> *crtc)
>> if (atomic->post_enable_primary)
>> intel_post_enable_primary(&crtc->base);
>>
>> + if (needs_modeset(&pipe_config->base))
>> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
>> +
>> memset(atomic, 0, sizeof(*atomic));
>> }
>>
>> @@ -13375,8 +13409,9 @@ static int intel_atomic_commit(struct drm_device
>> *dev,
>> for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> bool modeset = needs_modeset(crtc->state);
>> - bool update_pipe = !modeset &&
>> - to_intel_crtc_state(crtc->state)->update_pipe;
>> + struct intel_crtc_state *pipe_config =
>> + to_intel_crtc_state(crtc->state);
>> + bool update_pipe = !modeset && pipe_config->update_pipe;
>> unsigned long put_domains = 0;
>>
>> if (modeset)
>> @@ -13401,18 +13436,21 @@ static int intel_atomic_commit(struct drm_device
>> *dev,
>> (crtc->state->planes_changed || update_pipe))
>> drm_atomic_helper_commit_planes_on_crtc(crtc_state);
>>
>> + if (pipe_config->base.active &&
>> + (pipe_config->wm_changed || pipe_config->disable_cxsr ||
>> + pipe_config->fb_changed))
>> + crtc_vblank_mask |= 1 << i;
>> +
>> if (put_domains)
>> modeset_put_power_domains(dev_priv, put_domains);
>> -
>> - intel_post_plane_update(intel_crtc);
>> -
>> - if (modeset)
>> - intel_display_power_put(dev_priv,
>> POWER_DOMAIN_MODESET);
>
> Would it be too evil to move the power domain get/put out of the loop? If I
> understand correctly, intel_state->modeset already tells us if there is any
> crtc
> that needs a modeset, so we could just protect the calls with that. I'm not
> sure
> what is the impact, but at least we could avoid having the get in
> intel_atomic_commit() and the put in intel_post_plane_enable().
Even better would be if POWER_DOMAIN_MODESET was a part of
put_domains, and all domains were put after completion. I suggested
this during review of Patrik's series, but that seems to have got
lost. :(
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix kerneldoc indent fails
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c| 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ed9f1002ab36..a057cbd78ecb 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -677,7 +677,7 @@ static struct drm_i915_gem_object
*gem_allocate_guc_obj(struct drm_device *dev,
/**
* gem_release_guc_obj() - Release gem object allocated for GuC usage
* @obj: gem obj to be released
- */
+ */
static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
{
if (!obj)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 13445655e6b8..70d443330919 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -288,11 +288,11 @@ static i915_reg_t gen6_pm_ier(struct drm_i915_private
*dev_priv)
}
/**
- * snb_update_pm_irq - update GEN6_PMIMR
- * @dev_priv: driver private
- * @interrupt_mask: mask of interrupt bits to update
- * @enabled_irq_mask: mask of interrupt bits to enable
- */
+ * snb_update_pm_irq - update GEN6_PMIMR
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ */
static void snb_update_pm_irq(struct drm_i915_private *dev_priv,
uint32_t interrupt_mask,
uint32_t enabled_irq_mask)
@@ -406,11 +406,11 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
}
/**
- * bdw_update_port_irq - update DE port interrupt
- * @dev_priv: driver private
- * @interrupt_mask: mask of interrupt bits to update
- * @enabled_irq_mask: mask of interrupt bits to enable
- */
+ * bdw_update_port_irq - update DE port interrupt
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ */
static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
uint32_t interrupt_mask,
uint32_t enabled_irq_mask)
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't compare has_drrs strictly in pipe config
The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
pipe_config_compare, v2] relaxed the way to compare the pipe
configurations, but one new comparison sneaked in there: it added the
strict has_drrs value check. This causes a regression on many
machines, typically HP laptops with a docking port, where the kernel
spews warnings and eventually fails to set the mode properly like:
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected
1, found 0)
[ cut here ]
WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700
intel_modeset_check_state+0x5aa/0x870 [i915]()
pipe state doesn't match!
This patch just removes the check again for fixing the regression.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare,
v2')
Cc: # v4.3+
Reported-and-tested-by: Max Lin
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 71860f8680f9..12a2e9d1f633 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12460,7 +12460,6 @@ intel_pipe_config_compare(struct drm_device *dev,
if (INTEL_INFO(dev)->gen < 8) {
PIPE_CONF_CHECK_M_N(dp_m_n);
- PIPE_CONF_CHECK_I(has_drrs);
if (current_config->has_drrs)
PIPE_CONF_CHECK_M_N(dp_m2_n2);
} else
--
2.6.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED
From: Ville Syrjälä
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
forbidden to set it for LVDS/CRT as well. So let's move it out of the
ironlake_compute_dpll() and just do it on demand in the pll enable hook.
This allows the PLL to be shared in more cases when dealing with
different output types.
Note that we must now call the pll enable hook regarless of the current
pll state, so that DPLL_SDVO_HIGH_SPEED gets updated appropriately.
FIXME: maybe better to add a separate hook for the "pll already enabled"
case?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 26cafeea2845..ae58f1105458 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1908,6 +1908,8 @@ static void intel_enable_shared_dpll(struct intel_crtc
*crtc)
if (pll->active++) {
WARN_ON(!pll->on);
assert_shared_dpll_enabled(dev_priv, pll);
+ /* to update high speed IO clock state */
+ pll->enable(dev_priv, pll);
return;
}
WARN_ON(pll->on);
@@ -8942,11 +8944,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc
*intel_crtc,
dpll |= (crtc_state->pixel_multiplier - 1)
<< PLL_REF_SDVO_HDMI_MULTIPLIER_SHIFT;
- if (is_sdvo)
- dpll |= DPLL_SDVO_HIGH_SPEED;
- if (crtc_state->has_dp_encoder)
- dpll |= DPLL_SDVO_HIGH_SPEED;
-
/* compute bitmask from p1 value */
dpll |= (1 << (crtc_state->dpll.p1 - 1)) <<
DPLL_FPA01_P1_POST_DIV_SHIFT;
/* also FPA1 */
@@ -13626,7 +13623,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
drm_i915_private *dev_priv,
return false;
val = I915_READ(PCH_DPLL(pll->id));
- hw_state->dpll = val;
+ hw_state->dpll = val & ~DPLL_SDVO_HIGH_SPEED;
hw_state->fp0 = I915_READ(PCH_FP0(pll->id));
hw_state->fp1 = I915_READ(PCH_FP1(pll->id));
@@ -13643,10 +13640,26 @@ static void ibx_pch_dpll_mode_set(struct
drm_i915_private *dev_priv,
static void ibx_pch_dpll_enable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
+ struct drm_device *dev = dev_priv->dev;
+ struct intel_crtc *crtc;
+ u32 dpll = pll->config.hw_state.dpll;
+
+ /* Configure high speed IO clock as needed */
+ for_each_intel_crtc(dev, crtc) {
+ if (intel_crtc_to_shared_dpll(crtc) == pll &&
+ crtc->config->base.active &&
+ (crtc->config->has_dp_encoder ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))) {
+ dpll |= DPLL_SDVO_HIGH_SPEED;
+ break;
+ }
+ }
+
/* PCH refclock must be enabled first */
ibx_assert_pch_refclk_enabled(dev_priv);
- I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
+ I915_WRITE(PCH_DPLL(pll->id), dpll);
/* Wait for the clocks to stabilize. */
POSTING_READ(PCH_DPLL(pll->id));
@@ -13657,7 +13670,7 @@ static void ibx_pch_dpll_enable(struct drm_i915_private
*dev_priv,
*
* So write it again.
*/
- I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
+ I915_WRITE(PCH_DPLL(pll->id), dpll);
POSTING_READ(PCH_DPLL(pll->id));
udelay(200);
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use intel_pipe_will_have_type() in ironlake_crtc_compute_clock()
From: Ville Syrjälä ironlake_crtc_compute_clock() gets called during atomic compute phase, so we must check the future pipe type instead of the current type. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a5669a6613e8..26cafeea2845 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8988,7 +8988,7 @@ static int ironlake_crtc_compute_clock(struct intel_crtc *crtc, memset(&crtc_state->dpll_hw_state, 0, sizeof(crtc_state->dpll_hw_state)); - is_lvds = intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS); + is_lvds = intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS); WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)), "Unexpected PCH type %d\n", INTEL_PCH_TYPE(dev)); -- 2.4.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly
We had the "The master control interrupt lied (SDE)!" check and error
message in place for a long time without any problems, until
commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
Author: Sonika Jindal
Date: Wed Jul 8 17:07:47 2015 +0530
drm/i915: Handle HPD when it has actually occurred
caused the errors to start happening. This was bisected and reported,
but the error message was silenced in
commit 97e5eddcc5300a0f59a55248cd243937a8ab
Author: Daniel Vetter
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
shooting the messenger while the debugging for why Sonika's commit
triggered the errors was still in progress.
It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
register even though the hotplug trigger indicates there isn't a hotplug
irq to handle.
Cc: Ville Syrjälä
Cc: Sonika Jindal
Cc: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8ba94968aaf..982951d3153a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1825,7 +1825,17 @@ static void ibx_hpd_irq_handler(struct drm_device *dev,
u32 hotplug_trigger,
u32 dig_hotplug_reg, pin_mask = 0, long_mask = 0;
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+ if (!hotplug_trigger) {
+ u32 mask = PORTA_HOTPLUG_STATUS_MASK |
+ PORTD_HOTPLUG_STATUS_MASK |
+ PORTC_HOTPLUG_STATUS_MASK |
+ PORTB_HOTPLUG_STATUS_MASK;
+ dig_hotplug_reg &= ~mask;
+ }
+
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+ if (!hotplug_trigger)
+ return;
intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
dig_hotplug_reg, hpd,
@@ -1840,8 +1850,7 @@ static void ibx_irq_handler(struct drm_device *dev, u32
pch_iir)
int pipe;
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
- if (hotplug_trigger)
- ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
+ ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
if (pch_iir & SDE_AUDIO_POWER_MASK) {
int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
@@ -1934,8 +1943,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
int pipe;
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
- if (hotplug_trigger)
- ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
+ ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"
This reverts
commit 97e5eddcc5300a0f59a55248cd243937a8ab
Author: Daniel Vetter
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
With the proper fix ("drm/i915: fix the SDE irq dmesg warnings
properly") reliably in place, bring back the error message.
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 982951d3153a..b327b37ed3b1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2359,13 +2359,9 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
spt_irq_handler(dev, pch_iir);
else
cpt_irq_handler(dev, pch_iir);
- } else {
- /*
-* Like on previous PCH there seems to be something
-* fishy going on with forwarding PCH interrupts.
-*/
- DRM_DEBUG_DRIVER("The master control interrupt lied
(SDE)!\n");
- }
+ } else
+ DRM_ERROR("The master control interrupt lied (SDE)!\n");
+
}
I915_WRITE_FW(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't compare has_drrs strictly in pipe config
On Wed, Nov 25, 2015 at 03:26:47PM +0100, Takashi Iwai wrote:
> The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
> pipe_config_compare, v2] relaxed the way to compare the pipe
> configurations, but one new comparison sneaked in there: it added the
> strict has_drrs value check. This causes a regression on many
> machines, typically HP laptops with a docking port, where the kernel
> spews warnings and eventually fails to set the mode properly like:
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs
> (expected 1, found 0)
> [ cut here ]
> WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700
> intel_modeset_check_state+0x5aa/0x870 [i915]()
> pipe state doesn't match!
>
>
> This patch just removes the check again for fixing the regression.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
> Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare,
> v2')
> Cc: # v4.3+
> Reported-and-tested-by: Max Lin
> Signed-off-by: Takashi Iwai
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 71860f8680f9..12a2e9d1f633 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12460,7 +12460,6 @@ intel_pipe_config_compare(struct drm_device *dev,
> if (INTEL_INFO(dev)->gen < 8) {
> PIPE_CONF_CHECK_M_N(dp_m_n);
>
> - PIPE_CONF_CHECK_I(has_drrs);
> if (current_config->has_drrs)
> PIPE_CONF_CHECK_M_N(dp_m2_n2);
> } else
> --
> 2.6.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly
On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
> We had the "The master control interrupt lied (SDE)!" check and error
> message in place for a long time without any problems, until
>
> commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
> Author: Sonika Jindal
> Date: Wed Jul 8 17:07:47 2015 +0530
>
> drm/i915: Handle HPD when it has actually occurred
>
> caused the errors to start happening. This was bisected and reported,
> but the error message was silenced in
>
> commit 97e5eddcc5300a0f59a55248cd243937a8ab
> Author: Daniel Vetter
> Date: Fri Oct 23 10:56:12 2015 +0200
>
> drm/i915: shut up gen8+ SDE irq dmesg noise
>
> shooting the messenger while the debugging for why Sonika's commit
> triggered the errors was still in progress.
>
> It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
> register even though the hotplug trigger indicates there isn't a hotplug
> irq to handle.
>
> Cc: Ville Syrjälä
> Cc: Sonika Jindal
> Cc: Daniel Vetter
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
> Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_irq.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index c8ba94968aaf..982951d3153a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1825,7 +1825,17 @@ static void ibx_hpd_irq_handler(struct drm_device
> *dev, u32 hotplug_trigger,
> u32 dig_hotplug_reg, pin_mask = 0, long_mask = 0;
>
> dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> + if (!hotplug_trigger) {
> + u32 mask = PORTA_HOTPLUG_STATUS_MASK |
> + PORTD_HOTPLUG_STATUS_MASK |
> + PORTC_HOTPLUG_STATUS_MASK |
> + PORTB_HOTPLUG_STATUS_MASK;
> + dig_hotplug_reg &= ~mask;
> + }
> +
> I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> + if (!hotplug_trigger)
> + return;
I would add some kind of comment around these parts to explain that
somehow the PCH doesn't seem to really ack the interrupt to the CPU
unless we touch the hotplug register.
Otherwise (for both patches)
Reviewed-by: Ville Syrjälä
Also not sure if SKL might need something similar as well...
>
> intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> dig_hotplug_reg, hpd,
> @@ -1840,8 +1850,7 @@ static void ibx_irq_handler(struct drm_device *dev, u32
> pch_iir)
> int pipe;
> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
>
> - if (hotplug_trigger)
> - ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
> + ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
>
> if (pch_iir & SDE_AUDIO_POWER_MASK) {
> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
> @@ -1934,8 +1943,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
> pch_iir)
> int pipe;
> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>
> - if (hotplug_trigger)
> - ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
> + ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
>
> if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle
Nick Hoath writes:
> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the request/context
> lifecycle, it no longer needs to be pinned from context_queue to
> retire_requests.
>
> v2: Moved the new pin to cover GuC submission (Alex Dai)
> Moved the new unpin to request_retire to fix coverage leak
> v3: Added switch to default context if freeing a still pinned
> context just in case the hw was actually still using it
> v4: Unwrapped context unpin to allow calling without a request
> v5: Only create a switch to idle context if the ring doesn't
> already have a request pending on it (Alex Dai)
> Rename unsaved to dirty to avoid double negatives (Dave Gordon)
> Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
> Split out per engine cleanup from context_free as it
> was getting unwieldy
> Corrected locking (Dave Gordon)
>
> Signed-off-by: Nick Hoath
> Issue: VIZ-4277
> Cc: Daniel Vetter
> Cc: David Gordon
> Cc: Chris Wilson
> Cc: Alex Dai
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 3 +
> drivers/gpu/drm/i915/intel_lrc.c | 124
> +++
> drivers/gpu/drm/i915/intel_lrc.h | 1 +
> 4 files changed, 105 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d5cf30b..e82717a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -889,6 +889,7 @@ struct intel_context {
> struct {
> struct drm_i915_gem_object *state;
> struct intel_ringbuffer *ringbuf;
> + bool dirty;
> int pin_count;
> } engine[I915_NUM_RINGS];
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e955499..3829bc1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
> drm_i915_gem_request *request)
> {
> trace_i915_gem_request_retire(request);
>
> + if (i915.enable_execlists)
> + intel_lr_context_complete_check(request);
> +
> /* We know the GPU must have read the request to have
>* sent us the seqno + interrupt, so use the position
>* of tail of the request to update the last known position
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 06180dc..03d5bca 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -566,9 +566,6 @@ static int execlists_context_queue(struct
> drm_i915_gem_request *request)
> struct drm_i915_gem_request *cursor;
> int num_elements = 0;
>
> - if (request->ctx != ring->default_context)
> - intel_lr_context_pin(request);
> -
> i915_gem_request_reference(request);
>
> spin_lock_irq(&ring->execlist_lock);
> @@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
> drm_i915_gem_request *request)
> if (intel_ring_stopped(ring))
> return;
>
> + if (request->ctx != ring->default_context) {
> + if (!request->ctx->engine[ring->id].dirty) {
> + intel_lr_context_pin(request);
> + request->ctx->engine[ring->id].dirty = true;
> + }
> + }
> +
> if (dev_priv->guc.execbuf_client)
> i915_guc_submit(dev_priv->guc.execbuf_client, request);
> else
> @@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
> intel_engine_cs *ring)
> spin_unlock_irq(&ring->execlist_lock);
>
> list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
> - struct intel_context *ctx = req->ctx;
> - struct drm_i915_gem_object *ctx_obj =
> - ctx->engine[ring->id].state;
> -
> - if (ctx_obj && (ctx != ring->default_context))
> - intel_lr_context_unpin(req);
> list_del(&req->execlist_link);
> i915_gem_request_unreference(req);
> }
> @@ -1058,21 +1056,39 @@ reset_pin_count:
> return ret;
> }
>
> -void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
> +static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
> + struct intel_context *ctx)
> {
> - struct intel_engine_cs *ring = rq->ring;
> - struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
> - struct intel_ringbuffer *ringbuf = rq->ringbuf;
> -
> + struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
> + struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
> if (ctx_obj) {
> WARN_ON(!mutex_is_locked(&ring->dev->struct_mutex));
> -
[Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling
From: Ville Syrjälä
LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
for transocoder B/C. And more importnatnly we should not consider
the state of underrun reporting for transcoders B/C when checking
whether we can enable the south error interrupt.
The whole thing is a bit of mess since we store the underrun reporting
state for transcoder A under intel_crtc for pipe A, irrespective of
which pipe may actually be driving the transcoder. But I figured trying
to change that would result in more churn.
Caveat: totally untested due to lack of hw, but might explain some of
the HSW/BDW BAT fails...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index bda526660e20..04bf625a1b6c 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -48,6 +48,13 @@
* The code also supports underrun detection on the PCH transcoder.
*/
+static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
+ enum transcoder pch_transcoder)
+{
+ /* HSW/BDW have only transcoder A */
+ return !HAS_DDI(dev_priv) || pch_transcoder == TRANSCODER_A;
+}
+
static bool ivb_can_enable_err_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -69,13 +76,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
static bool cpt_can_enable_serr_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- enum pipe pipe;
- struct intel_crtc *crtc;
+ enum transcoder pch_transcoder;
assert_spin_locked(&dev_priv->irq_lock);
- for_each_pipe(dev_priv, pipe) {
- crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ for_each_pipe(dev_priv, pch_transcoder) {
+ struct intel_crtc *crtc =
+
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
+
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ continue;
if (crtc->pch_fifo_underrun_disabled)
return false;
@@ -206,6 +216,9 @@ static void cpt_check_pch_fifo_underruns(struct intel_crtc
*crtc)
assert_spin_locked(&dev_priv->irq_lock);
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ return;
+
if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
return;
@@ -222,6 +235,9 @@ static void cpt_set_fifo_underrun_reporting(struct
drm_device *dev,
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ return;
+
if (enable) {
I915_WRITE(SERR_INT,
SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling
On Wed, Nov 25, 2015 at 05:11:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> for transocoder B/C. And more importnatnly we should not consider
> the state of underrun reporting for transcoders B/C when checking
> whether we can enable the south error interrupt.
>
> The whole thing is a bit of mess since we store the underrun reporting
> state for transcoder A under intel_crtc for pipe A, irrespective of
> which pipe may actually be driving the transcoder. But I figured trying
> to change that would result in more churn.
>
> Caveat: totally untested due to lack of hw, but might explain some of
> the HSW/BDW BAT fails...
Hmm. Actually it can't since we don't use the CRCs that get signalled
via the south error interrupt. Back to the drawing board...
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index bda526660e20..04bf625a1b6c 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -48,6 +48,13 @@
> * The code also supports underrun detection on the PCH transcoder.
> */
>
> +static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
> + enum transcoder pch_transcoder)
> +{
> + /* HSW/BDW have only transcoder A */
> + return !HAS_DDI(dev_priv) || pch_transcoder == TRANSCODER_A;
> +}
> +
> static bool ivb_can_enable_err_int(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -69,13 +76,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
> static bool cpt_can_enable_serr_int(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - enum pipe pipe;
> - struct intel_crtc *crtc;
> + enum transcoder pch_transcoder;
>
> assert_spin_locked(&dev_priv->irq_lock);
>
> - for_each_pipe(dev_priv, pipe) {
> - crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + for_each_pipe(dev_priv, pch_transcoder) {
> + struct intel_crtc *crtc =
> +
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
> +
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + continue;
>
> if (crtc->pch_fifo_underrun_disabled)
> return false;
> @@ -206,6 +216,9 @@ static void cpt_check_pch_fifo_underruns(struct
> intel_crtc *crtc)
>
> assert_spin_locked(&dev_priv->irq_lock);
>
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
> if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
> return;
>
> @@ -222,6 +235,9 @@ static void cpt_set_fifo_underrun_reporting(struct
> drm_device *dev,
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
> if (enable) {
> I915_WRITE(SERR_INT,
> SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
> --
> 2.4.10
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
This testcase tries to validate -EIO behaviour by disabling gpu reset
support in the kernel. Except that the wait subtest forgot to do that,
and therefore gets a return value of 0 instead of the expected -EIO.
With this fix gem_eio passes on a kernel with my fixes completely.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
tests/gem_eio.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index a24c8f1c53b5..ad67332eae59 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -161,10 +161,14 @@ static void test_wait(int fd)
{
igt_hang_ring_t hang;
+ igt_require(i915_reset_control(false));
+
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
igt_assert_eq(__gem_wait(fd, hang.handle, -1), -EIO);
igt_post_hang_ring(fd, hang);
+ igt_assert(i915_reset_control(true));
+
trigger_reset(fd);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"
Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
hang we need to be careful to not run into the "hanging too fast
check":
- don't restore the ban period, but instead keep it at 0.
- make sure we idle the gpu fully before hanging it again (wait
subtest missted that).
With this gem_eio works now reliable even when I don't run the
subtests individually.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
tests/gem_eio.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index ad67332eae59..f6e41db63a7d 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -84,13 +84,17 @@ static void trigger_reset(int fd)
static void wedge_gpu(int fd)
{
+ igt_hang_ring_t hang;
+
/* First idle the GPU then disable GPU resets before injecting a hang */
gem_quiescent_gpu(fd);
igt_require(i915_reset_control(false));
igt_debug("Wedging GPU by injecting hang\n");
- igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
+ hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
+ hang.ban = 0;
+ igt_post_hang_ring(fd, hang);
igt_assert(i915_reset_control(true));
}
@@ -161,10 +165,14 @@ static void test_wait(int fd)
{
igt_hang_ring_t hang;
+ /* First idle the GPU then disable GPU resets before injecting a hang */
+ gem_quiescent_gpu(fd);
+
igt_require(i915_reset_control(false));
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
igt_assert_eq(__gem_wait(fd, hang.handle, -1), -EIO);
+ hang.ban = 0;
igt_post_hang_ring(fd, hang);
igt_assert(i915_reset_control(true));
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"
On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote: > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > hang we need to be careful to not run into the "hanging too fast > check": That's not how it works. It restores the GPU by triggering a manual reset. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > This testcase tries to validate -EIO behaviour by disabling gpu reset > support in the kernel. Except that the wait subtest forgot to do that, > and therefore gets a return value of 0 instead of the expected -EIO. > Wrong. It was intentionally not using reset=false. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > support in the kernel. Except that the wait subtest forgot to do that, > > and therefore gets a return value of 0 instead of the expected -EIO. > > > > Wrong. It was intentionally not using reset=false. To be more precise, the reason here is that we are not wedging the GPU but the expectation is that a wait upon a request that hangs reports the hang. Since the wait on GPU activity is explicit in the ioctl, the presumption is that the user actually cares about that activity and so should be given greater information about how it completes (timeout, GPU hung, or success). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks
We've been chasing a regression[1] that prevented us from merging the last couple patches of the ILK-style atomic watermark series. We've finally identified the culprit --- if we fail to reconstruct the BIOS FB, our internal driver state was left in an inconsistent state which caused confusion for the watermark code. Here's a series that collects that fix (along with a couple other bugfixes that were found while debugging), a few debugging enhancements, and the completion of the ILK atomic watermark series. * The first patch in this series addresses that issue and ensures that we cleanly turn off the primary plane if we're unable to inherit the framebuffer. * Patches 2-4 just clarify/expand some of the information dumped by the driver while debugging. * Patches 5 and 6 fix two additional bugs that were discovered while searching for the cause of the regression. * Patch 7 just adds some extra paranoia and invariant checking to the watermark code. * Patches 8 and 9 are the two final patches from the original atomic watermark series; with the fixes earlier in the series, we've confirmed that they no longer cause regressions on Jani's machine. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html Matt Roper (9): drm/i915: Disable primary plane if we fail to reconstruct BIOS fb drm/i915: Dump in-flight plane state while dumping in-flight CRTC state drm/i915: Clarify plane state during CRTC state dumps (v2) drm/i915: Dump pipe config after initial FB is reconstructed drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2) drm/i915: Convert hsw_compute_linetime_wm to use in-flight state drm/i915: Add extra paranoia to ILK watermark calculations drm/i915: Sanitize watermarks after hardware state readout (v2) drm/i915: Add two-stage ILK-style watermark programming (v7) drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_display.c | 195 +-- drivers/gpu/drm/i915/intel_drv.h | 31 +- drivers/gpu/drm/i915/intel_pm.c | 186 - 6 files changed, 359 insertions(+), 60 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: Add extra paranoia to ILK watermark calculations
Our low-level watermark calculation functions don't get called when the
CRTC is disabled or the relevant plane is invisible, so they should
never see a zero htotal or zero bpp. However add some checks to ensure
this is true so that we don't wind up dividing by zero if we make a
mistake elsewhere in the driver (which the atomic watermark series has
revealed we might be).
References:
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077370.html
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6efb908..d4cd5d5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1664,6 +1664,9 @@ uint32_t ilk_pipe_pixel_rate(const struct
intel_crtc_state *pipe_config)
if (pipe_h < pfit_h)
pipe_h = pfit_h;
+ if (WARN_ON(!pfit_w || !pfit_h))
+ return pixel_rate;
+
pixel_rate = div_u64((uint64_t) pixel_rate * pipe_w * pipe_h,
pfit_w * pfit_h);
}
@@ -1695,6 +1698,8 @@ static uint32_t ilk_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
if (WARN(latency == 0, "Latency value missing\n"))
return UINT_MAX;
+ if (WARN_ON(!pipe_htotal))
+ return UINT_MAX;
ret = (latency * pixel_rate) / (pipe_htotal * 1);
ret = (ret + 1) * horiz_pixels * bytes_per_pixel;
@@ -1705,6 +1710,17 @@ static uint32_t ilk_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t horiz_pixels,
uint8_t bytes_per_pixel)
{
+ /*
+* Neither of these should be possible since this function shouldn't be
+* called if the CRTC is off or the plane is invisible. But let's be
+* extra paranoid to avoid a potential divide-by-zero if we screw up
+* elsewhere in the driver.
+*/
+ if (WARN_ON(!bytes_per_pixel))
+ return 0;
+ if (WARN_ON(!horiz_pixels))
+ return 0;
+
return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)
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 programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.
We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.
v2: Move watermark sanitization after our BIOS fb reconstruction; the
watermark calculations that we do here need to look at pstate->fb,
which isn't setup yet in intel_modeset_setup_hw_state(), even
though we have an enabled & visible plane.
Cc: Maarten Lankhorst
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_atomic_helper.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 58
drivers/gpu/drm/i915/intel_pm.c | 14 +
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3731a26..8a98e0c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
}
+ drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
drm_for_each_connector(conn, dev) {
struct drm_connector_state *conn_state;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11ae5a5..5172604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
struct drm_atomic_state *state);
+ void (*program_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 00e4c37..eb52afa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
intel_enable_gt_powersave(dev);
}
+/*
+ * Calculate what we think the watermarks should be for the state we've read
+ * out of the hardware and then immediately program those watermarks so that
+ * we ensure the hardware settings match our internal state.
+ */
+static void sanitize_watermarks(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_atomic_state *state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *cstate;
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
+ int i;
+
+ /* Only supported on platforms that use atomic watermark design */
+ if (!dev_priv->display.program_watermarks)
+ return;
+
+ /*
+* Calculate what we think WM's should be by creating a dummy state and
+* running it through the atomic check code.
+*/
+ drm_modeset_acquire_init(&ctx, 0);
+ state = drm_atomic_helper_duplicate_state(dev, &ctx);
+ if (WARN_ON(IS_ERR(state)))
+ return;
+
+ ret = intel_atomic_check(dev, state);
+ if (ret) {
+ /*
+* Just give up and leave watermarks untouched if we get an
+* error back from 'check'
+*/
+ DRM_DEBUG_KMS("Could not determine valid watermarks for
inherited state\n");
+ return;
+ }
+
+ /* Write calculated watermark values back */
+ to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
+ for_each_crtc_in_state(state, crtc, cstate, i) {
+ struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
+
+ dev_priv->display.program_watermarks(cs);
+ }
+
+ drm_atomic_state_free(state);
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+}
+
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
intel_dump_pipe_config(crtc, crtc->config,
"[state after init fb reconstruction]");
}
+
+ /*
+* Make sure hardware watermarks really match the state we read out.
+* Note that we need to do this after reconstructing the BIOS fb's
+* since the watermark calculation done here will u
[Intel-gfx] [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)
Plane state objects contain two copies of src/dest coordinates: the original (requested by userspace) coordinates in the base drm_plane_state object, and a second, clipped copy (i.e., what we actually want to program to the hardware) in intel_plane_state. We've only been setting up the former set of values during boot time FB reconstruction, but we should really be initializing both. Note that the code here probably still needs some more work since we make a lot of assumptions about how the BIOS programmed the hardware that may not always be true, especially on gen9+; e.g., * Primary plane might not be positioned at 0,0 * Primary plane could have been rotated by the BIOS * Primary plane might be scaled * The BIOS fb might be a single "extended mode" FB that spans multiple displays. * ...etc... v2: Reword/expand commit message description of assumptions we make Signed-off-by: Matt Roper Reviewed-by(v1): Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 73e9bf9..00e4c37 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2599,6 +2599,8 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, struct drm_plane_state *plane_state = primary->state; struct drm_crtc_state *crtc_state = intel_crtc->base.state; struct intel_plane *intel_plane = to_intel_plane(primary); + struct intel_plane_state *intel_state = + to_intel_plane_state(plane_state); struct drm_framebuffer *fb; if (!plane_config->fb) @@ -2659,6 +2661,15 @@ valid_fb: plane_state->crtc_w = fb->width; plane_state->crtc_h = fb->height; + intel_state->src.x1 = plane_state->src_x; + intel_state->src.y1 = plane_state->src_y; + intel_state->src.x2 = plane_state->src_x + plane_state->src_w; + intel_state->src.y2 = plane_state->src_y + plane_state->src_h; + intel_state->dst.x1 = plane_state->crtc_x; + intel_state->dst.y1 = plane_state->crtc_y; + intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w; + intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h; + obj = intel_fb_obj(fb); if (obj->tiling_mode != I915_TILING_NONE) dev_priv->preserve_bios_swizzle = true; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state
The intel_dump_pipe_config() always dumps the currently active plane
state for each plane on a CRTC. If we're calling this function to dump
CRTC state that is in-flight (not yet active), then this mismatch can be
misleading and confusing. Let's pay attention to whether the state
we're dumping is part of an in-flight transaction (because
crtc_state->state is non-NULL); if it is, we'll dump the corresponding
in-flight plane state instead of the active state.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d03a235..0e74287 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12162,11 +12162,23 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
DRM_DEBUG_KMS("planes on this crtc\n");
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+ struct drm_plane_state *ps = NULL;
+
intel_plane = to_intel_plane(plane);
if (intel_plane->pipe != crtc->pipe)
continue;
- state = to_intel_plane_state(plane->state);
+ /* Get in-flight plane state, if any */
+ if (pipe_config->base.state)
+ ps =
drm_atomic_get_existing_plane_state(pipe_config->base.state,
+plane);
+
+ /* If no in-flight state, use active state instead */
+ if (!ps)
+ ps = plane->state;
+
+ state = to_intel_plane_state(ps);
+
fb = state->base.fb;
if (!fb) {
DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d "
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
When watermark calculation was moved up to the atomic check phase, the
code was updated to calculate based on in-flight atomic state rather
than already-committed state. However the hsw_compute_linetime_wm()
didn't get updated and continued to pull values out of the
currently-committed CRTC state. On platforms that call this function
(HSW/BDW only), this will cause problems when we go to enable the CRTC
since we'll pull the current mode (off) rather than the mode we're
calculating for and wind up with a divide by zero error.
This was an oversight in commit:
commit a28170f3389f4e42db95e595b0d86384a79de696
Author: Matt Roper
Date: Thu Sep 24 15:53:16 2015 -0700
drm/i915: Calculate ILK-style watermarks during atomic check (v3)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96f45d7..6efb908 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1990,14 +1990,19 @@ static void ilk_compute_wm_level(const struct
drm_i915_private *dev_priv,
}
static uint32_t
-hsw_compute_linetime_wm(struct drm_device *dev, struct drm_crtc *crtc)
+hsw_compute_linetime_wm(struct drm_device *dev,
+ struct intel_crtc_state *cstate)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- const struct drm_display_mode *adjusted_mode =
&intel_crtc->config->base.adjusted_mode;
+ const struct drm_display_mode *adjusted_mode =
+ &cstate->base.adjusted_mode;
u32 linetime, ips_linetime;
- if (!intel_crtc->active)
+ if (!cstate->base.active)
+ return 0;
+ if (WARN_ON(adjusted_mode->crtc_clock == 0))
+ return 0;
+ if (WARN_ON(dev_priv->cdclk_freq == 0))
return 0;
/* The WM are computed with base on how long it takes to fill a single
@@ -2305,8 +2310,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc
*intel_crtc,
pristate, sprstate, curstate, &pipe_wm->wm[0]);
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- pipe_wm->linetime = hsw_compute_linetime_wm(dev,
- &intel_crtc->base);
+ pipe_wm->linetime = hsw_compute_linetime_wm(dev, cstate);
/* LP0 watermarks always use 1/2 DDB partitioning */
ilk_compute_wm_maximums(dev, 0, &config, INTEL_DDB_PART_1_2, &max);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. Cc: Daniel Vetter Cc: Ville Syrjälä Signed-off-by: Matt Roper --- With this patch, the rest of this series now runs without problems on Jani's system where the regressions were originally reported. Chris pointed out that this might also fix some of the other bugzillas we have on older platforms where there's a GPU hang on failed FB takeover. I don't think I have any platforms that can reproduce those types of problems to verify, but he listed candidate bugs as: https://bugs.freedesktop.org/show_bug.cgi?id=89319 https://bugs.freedesktop.org/show_bug.cgi?id=87677 https://bugs.freedesktop.org/show_bug.cgi?id=89146 https://bugs.freedesktop.org/show_bug.cgi?id=91653 drivers/gpu/drm/i915/intel_display.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4b21d5e..d03a235 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2597,6 +2597,8 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, struct drm_i915_gem_object *obj; struct drm_plane *primary = intel_crtc->base.primary; struct drm_plane_state *plane_state = primary->state; + struct drm_crtc_state *crtc_state = intel_crtc->base.state; + struct intel_plane *intel_plane = to_intel_plane(primary); struct drm_framebuffer *fb; if (!plane_config->fb) @@ -2633,6 +2635,17 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, } } + /* +* We've failed to reconstruct the BIOS FB. Current display state +* indicates that the primary plane is visible, but has a NULL FB, +* which will lead to problems later if we don't fix it up. The +* simplest solution is to just disable the primary plane now and +* pretend the BIOS never had it enabled. +*/ + to_intel_plane_state(plane_state)->visible = false; + crtc_state->plane_mask &= ~(1 << drm_plane_index(primary)); + intel_plane->disable_plane(primary, &intel_crtc->base); + return; valid_fb: -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed
We dump during HW state readout, but that's too early to reflect how the primary plane is actually configured. In the future it would be nice if we could just read out HW state and reconstruct FB's at the same point, but at the moment we don't have GEM initialized sufficiently during hardware readout. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e5c522b..73e9bf9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15228,6 +15228,9 @@ void intel_modeset_init(struct drm_device *dev) * just get the first one. */ intel_find_initial_plane_obj(crtc, &plane_config); + + intel_dump_pipe_config(crtc, crtc->config, + "[state after init fb reconstruction]"); } } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank). Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.
v2: Significant rebasing/rewriting.
v3:
- Move 'need_postvbl_update' flag to CRTC state (Daniel)
- Don't forget to check intermediate watermark values for validity
(Maarten)
- Don't due async watermark optimization; just do it at the end of the
atomic transaction, after waiting for vblanks. We do want it to be
async eventually, but adding that now will cause more trouble for
Maarten's in-progress work. (Maarten)
- Don't allocate space in crtc_state for intermediate watermarks on
platforms that don't need it (gen9+).
- Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
now that ilk_update_wm is gone.
v4:
- Add a wm_mutex to cover updates to intel_crtc->active and the
need_postvbl_update flag. Since we don't have async yet it isn't
terribly important yet, but might as well add it now.
- Change interface to program watermarks. Platforms will now expose
.initial_watermarks() and .optimize_watermarks() functions to do
watermark programming. These should lock wm_mutex, copy the
appropriate state values into intel_crtc->active, and then call
the internal program watermarks function.
v5:
- Skip intermediate watermark calculation/check during initial hardware
readout since we don't trust the existing HW values (and don't have
valid values of our own yet).
- Don't try to call .optimize_watermarks() on platforms that don't have
atomic watermarks yet. (Maarten)
v6:
- Rebase
v7:
- Further rebase
Signed-off-by: Matt Roper
Reviewed-by(v5): Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_atomic.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 90 +++-
drivers/gpu/drm/i915/intel_drv.h | 31 ++-
drivers/gpu/drm/i915/intel_pm.c | 160 ---
5 files changed, 232 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5172604..427b488 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,7 +630,11 @@ struct drm_i915_display_funcs {
struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
struct drm_atomic_state *state);
- void (*program_watermarks)(struct intel_crtc_state *cstate);
+ int (*compute_intermediate_wm)(struct drm_device *dev,
+ struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *newstate);
+ void (*initial_watermarks)(struct intel_crtc_state *cstate);
+ void (*optimize_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 643f342..b91e166 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
+ crtc_state->wm.need_postvbl_update = false;
return &crtc_state->base;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb52afa..8db0486 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11801,6 +11801,12 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
intel_crtc->atomic.update_wm_pre = true;
}
+ /* Pre-gen9 platforms need two-step watermark updates */
+ if ((intel_crtc->atomic.update_wm_pre ||
intel_crtc->atomic.update_wm_post) &&
+ INTEL_INFO(dev)->gen < 9 &&
+ dev_priv->display.optimize_watermarks)
+ to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
+
if (visible || was_visible)
intel_crtc->atomic.fb_bits |=
to_intel_plane(plane)->frontbuffer_bit;
@@ -11957,8 +11963,29 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(intel_crtc, state);
- if (ret)
+ if (ret) {
+
[Intel-gfx] [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2)
During state dumping, list planes that have an FB but are invisible
(e.g., because they're offscreen or clipped by other planes) as "not
visible" rather than "enabled." While we're at it, dump the FB format
as a human-readable string rather than a hex format code.
v2: Don't add bpp; make format human-readable instead. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0e74287..e5c522b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12190,13 +12190,15 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
continue;
}
- DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d enabled",
+ DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d %s",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" :
"STANDARD",
plane->base.id, intel_plane->pipe,
crtc->base.primary == plane ? 0 : intel_plane->plane +
1,
- drm_plane_index(plane));
- DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x",
- fb->base.id, fb->width, fb->height, fb->pixel_format);
+ drm_plane_index(plane),
+ state->visible ? "enabled" : "not visible");
+ DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = %s",
+ fb->base.id, fb->width, fb->height,
+ drm_get_format_name(fb->pixel_format));
DRM_DEBUG_KMS("\tscaler:%d src (%u, %u) %ux%u dst (%u, %u)
%ux%u\n",
state->scaler_id,
state->src.x1 >> 16, state->src.y1 >> 16,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add some more bits to CURSOR_POS_MASK
On Wed, Nov 25, 2015 at 1:54 PM, Robert Fekete
wrote:
> On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote:
>> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
>> > 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 position is bit 0:11, and even 0:12 on some hw where
>> > > remaining bits up to bit 14 is MBZ. For Y position it is bits 16-27
>> > > where bits 28:30 is MBZ. It should be safe to increase CURSOR_POS_MASK
>> > > to 13 bits (0x1FFF) making 8192 as a new wrap around value still getting
>> > > valid cursor positions on platforms with only 12bits available thanks to
>> > > MBZ on adjacent bits above.
>> >
>> > I cannot find documentation for older hardware and this only touches
>> > debugfs, so in worst case we get wrong values for really old hardware but
>> > good
>> > ones for newer. I think that's a fair tradeoff.
>> >
>> > Reviewed-by: Patrik Jakobsson
>>
>> If it's only used in debugfs then imo just drop it. Having a _MASK which
>> isn't valid on all platforms, but where we don't have differnt #defines
>> for the different platforms is really confusing.
>> -Daniel
Yes, seems fair.
>
> Well, not the most important patch around, but still the value of 0x7ff
> is still too conservative and gives wrong cursor pos values on large
> panels. I have hard times digging up really old register specs so I
> still can't see which Intel platform this new value of mine isn't valid
> on.
I think Daniel meant that we can remove the define altogether and
hardcode a sane mask in debugfs instead. Keeping the define around
might give people the wrong idea what the bspec actually says. Also
adding a comment along with the hardcoded mask in debugfs would be
nice.
-Patrik
>
> It is this patch by Chris in debugfs that is broken on large panels
> wrapping coords at (x_pos/y_pos > 2048)
> http://marc.info/?l=git-commits-head&m=139697989108096&w=1
>
>> >
>> > >
>> > > Signed-off-by: Robert Fekete
>> > > ---
>> > > 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 894253228947..f351f46f8cb9 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -4883,7 +4883,7 @@ enum skl_disp_power_wells {
>> > > #define CURSOR_TRICKLE_FEED_DISABLE(1 << 14)
>> > > #define _CURABASE0x70084
>> > > #define _CURAPOS 0x70088
>> > > -#define CURSOR_POS_MASK 0x007FF
>> > > +#define CURSOR_POS_MASK 0x01FFF
>> > > #define CURSOR_POS_SIGN 0x8000
>> > > #define CURSOR_X_SHIFT0
>> > > #define CURSOR_Y_SHIFT16
>> > > --
>> > > 1.9.1
>> > >
>> > > ___
>> > > Intel-gfx mailing list
>> > > Intel-gfx@lists.freedesktop.org
>> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
> --
> BR
> /Robert Fekete
> Intel Open Source Technology Center
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks
On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > We've been chasing a regression[1] that prevented us from merging the last > couple patches of the ILK-style atomic watermark series. We've finally > identified the culprit --- if we fail to reconstruct the BIOS FB, our internal > driver state was left in an inconsistent state which caused confusion for the > watermark code. Here's a series that collects that fix (along with a couple > other bugfixes that were found while debugging), a few debugging enhancements, > and the completion of the ILK atomic watermark series. > > * The first patch in this series addresses that issue and >ensures that we cleanly turn off the primary plane if we're unable to > inherit >the framebuffer. > * Patches 2-4 just clarify/expand some of the information dumped by the >driver while debugging. > * Patches 5 and 6 fix two additional bugs that were discovered while >searching for the cause of the regression. > * Patch 7 just adds some extra paranoia and invariant checking to the >watermark code. > * Patches 8 and 9 are the two final patches from the original atomic > watermark >series; with the fixes earlier in the series, we've confirmed that they no >longer cause regressions on Jani's machine. > > [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html Quickly skimmed through the series to see if there was a fix to the "merging optimal wms instead of merging active wms like we should" bug we have in the current code right now. Nothing relevant caught my eye at least. > > Matt Roper (9): > drm/i915: Disable primary plane if we fail to reconstruct BIOS fb > drm/i915: Dump in-flight plane state while dumping in-flight CRTC > state > drm/i915: Clarify plane state during CRTC state dumps (v2) > drm/i915: Dump pipe config after initial FB is reconstructed > drm/i915: Setup clipped src/dest coordinates during FB reconstruction > (v2) > drm/i915: Convert hsw_compute_linetime_wm to use in-flight state > drm/i915: Add extra paranoia to ILK watermark calculations > drm/i915: Sanitize watermarks after hardware state readout (v2) > drm/i915: Add two-stage ILK-style watermark programming (v7) > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > drivers/gpu/drm/i915/i915_drv.h | 5 + > drivers/gpu/drm/i915/intel_atomic.c | 1 + > drivers/gpu/drm/i915/intel_display.c | 195 > +-- > drivers/gpu/drm/i915/intel_drv.h | 31 +- > drivers/gpu/drm/i915/intel_pm.c | 186 - > 6 files changed, 359 insertions(+), 60 deletions(-) > > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
Unfortunately the entire improved docbook project died at KS in a massive bikeshed. So we need to carry this around in drm private trees forever :( I discussed this with Dave at kernel summit and he's ok with this. I'll maintain the asciidoc support in topic/kerneldoc in the drm-intel.git tree. There's an autobuilder that pushes drm-intel-nightly (which includes all of Dave's trees) to http://dri.freedesktop.org/docs/drm/ Thomas Wood keeps care of that autobuilder, so please ping him if there's something amiss. Note that asciidoc is optional - all the kerneldoc comment layout rules are the same, those bits landed in 4.4. It will simply not quite look as pretty if you don't have it installed. Cc: Dave Airlie Cc: Thomas Wood Cc: Jonathan Corbet Acked-by: Dave Airlie Signed-off-by: Daniel Vetter --- Documentation/DocBook/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 5335955c0de5..b655343631cf 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -17,7 +17,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ tracepoint.xml gpu.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml -MARKDOWNREADY := +MARKDOWNREADY := gpu.xml include Documentation/DocBook/media/Makefile -- 2.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] scripts/kernel-doc: Adding infrastructure for markdown support
From: Danilo Cesar Lemes de Paula
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-readle text highlight (bold,
underline, etc), bullet and numbered lists, simple tables, fixed-width
text (including asciiart), requiring minimal changes to current
documentation.
At this moment, pandoc is totally optional. Docbooks ready for markdown
should be added to the MARKDOWNREADY variable inside the Makefile. In
case the developer doesn't have pandoc installed, Make will throw a
warning and the documentation build will continue, generating
simple Documentation without the features brought by pandoc.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
---
Documentation/DocBook/Makefile | 25 +++-
scripts/docproc.c | 54 --
scripts/kernel-doc | 66 --
3 files changed, 119 insertions(+), 26 deletions(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 91f6d89bb19f..246ad38550e5 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,6 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
+MARKDOWNREADY :=
+
include Documentation/DocBook/media/Makefile
###
@@ -87,18 +89,23 @@ XMLTOFLAGS += --skip-validation
# The following rules are used to generate the .xml documentation
# required to generate the final targets. (ps, pdf, html).
quiet_cmd_docproc = DOCPROC $@
- cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+ cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $<
define rule_docproc
- set -e; \
-$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)\
-$(cmd_$(1)); \
-( \
- echo 'cmd_$@ := $(cmd_$(1))';\
- echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`; \
+ set -e;
\
+ USEMARKDOWN="";
\
+ FILE=`basename $@`;
\
+ [[ "$(MARKDOWNREADY)" =~ "$${FILE}" ]] && USEMARKDOWN="-use-markdown";
\
+$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)
\
+$(cmd_$(1)) $$USEMARKDOWN >$@;
\
+(
\
+ echo 'cmd_$@ := $(cmd_$(1))';
\
+ echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;
\
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+ @(which pandoc > /dev/null 2>&1) || \
+ (echo "*** To get propper documentation you need to install pandoc
***";)
$(call if_changed_rule,docproc)
# Tell kbuild to always build the programs
@@ -109,6 +116,10 @@ notfoundtemplate = echo "*** You have to install
docbook-utils or xmlto ***"; \
db2xtemplate = db2TYPE -o $(dir $@) $<
xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
+ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+ MARKDOWNREADY := "";
+endif
+
# determine which methods are available
ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
use-db2x = db2x
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621431a..7c6b225a6a50 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -73,12 +73,15 @@ FILELINE * docsection;
#define NOFUNCTION"-nofunction"
#define NODOCSECTIONS "-no-doc-sections"
#define SHOWNOTFOUND "-show-not-found"
+#define USEMARKDOWN "-use-markdown"
static char *srctree, *kernsrctree;
static char **all_list = NULL;
static int all_list_len = 0;
+static int use_markdown = 0;
+
static void consume_symbol(const char *sym)
{
int i;
@@ -95,10 +98,11 @@ static void consume_symbol(const char *sym)
static void usage (void)
{
- fprintf(stderr, "Usage: docproc {doc|depend} file\n");
+ fprintf(stderr, "Usage: docproc {doc|depend} [-use-markdown] file\n");
fprintf(stderr, "Input is read from file.tmpl. Output is sent to
stdout\n");
fprintf(
Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks
On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote: > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > > We've been chasing a regression[1] that prevented us from merging the last > > couple patches of the ILK-style atomic watermark series. We've finally > > identified the culprit --- if we fail to reconstruct the BIOS FB, our > > internal > > driver state was left in an inconsistent state which caused confusion for > > the > > watermark code. Here's a series that collects that fix (along with a couple > > other bugfixes that were found while debugging), a few debugging > > enhancements, > > and the completion of the ILK atomic watermark series. > > > > * The first patch in this series addresses that issue and > >ensures that we cleanly turn off the primary plane if we're unable to > > inherit > >the framebuffer. > > * Patches 2-4 just clarify/expand some of the information dumped by the > >driver while debugging. > > * Patches 5 and 6 fix two additional bugs that were discovered while > >searching for the cause of the regression. > > * Patch 7 just adds some extra paranoia and invariant checking to the > >watermark code. > > * Patches 8 and 9 are the two final patches from the original atomic > > watermark > >series; with the fixes earlier in the series, we've confirmed that they > > no > >longer cause regressions on Jani's machine. > > > > [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html > > Quickly skimmed through the series to see if there was a fix to > the "merging optimal wms instead of merging active wms like we > should" bug we have in the current code right now. Nothing > relevant caught my eye at least. I'm not sure I'm aware of this problem; is there a bugzilla or mailing list thread that describes the issue? Matt > > > > > Matt Roper (9): > > drm/i915: Disable primary plane if we fail to reconstruct BIOS fb > > drm/i915: Dump in-flight plane state while dumping in-flight CRTC > > state > > drm/i915: Clarify plane state during CRTC state dumps (v2) > > drm/i915: Dump pipe config after initial FB is reconstructed > > drm/i915: Setup clipped src/dest coordinates during FB reconstruction > > (v2) > > drm/i915: Convert hsw_compute_linetime_wm to use in-flight state > > drm/i915: Add extra paranoia to ILK watermark calculations > > drm/i915: Sanitize watermarks after hardware state readout (v2) > > drm/i915: Add two-stage ILK-style watermark programming (v7) > > > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > > drivers/gpu/drm/i915/i915_drv.h | 5 + > > drivers/gpu/drm/i915/intel_atomic.c | 1 + > > drivers/gpu/drm/i915/intel_display.c | 195 > > +-- > > drivers/gpu/drm/i915/intel_drv.h | 31 +- > > drivers/gpu/drm/i915/intel_pm.c | 186 > > - > > 6 files changed, 359 insertions(+), 60 deletions(-) > > > > -- > > 2.1.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)
On Wed, Nov 25, 2015 at 08:48:34AM -0800, 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 programming, but should rather
> re-calculate how we think WM's should be programmed and then shove those
> values into the hardware.
>
> We can do this pretty easily by creating a dummy top-level state,
> running it through the check process to calculate all the values, and
> then just programming the watermarks for each CRTC.
>
> v2: Move watermark sanitization after our BIOS fb reconstruction; the
> watermark calculations that we do here need to look at pstate->fb,
> which isn't setup yet in intel_modeset_setup_hw_state(), even
> though we have an enabled & visible plane.
>
> Cc: Maarten Lankhorst
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 58
>
> drivers/gpu/drm/i915/intel_pm.c | 14 +
> 4 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3731a26..8a98e0c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> }
> }
>
> + drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> drm_for_each_connector(conn, dev) {
> struct drm_connector_state *conn_state;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 11ae5a5..5172604 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
> int (*compute_pipe_wm)(struct intel_crtc *crtc,
> struct drm_atomic_state *state);
> + void (*program_watermarks)(struct intel_crtc_state *cstate);
> void (*update_wm)(struct drm_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 00e4c37..eb52afa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
> intel_enable_gt_powersave(dev);
> }
>
> +/*
> + * Calculate what we think the watermarks should be for the state we've read
> + * out of the hardware and then immediately program those watermarks so that
> + * we ensure the hardware settings match our internal state.
> + */
> +static void sanitize_watermarks(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_atomic_state *state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> + int i;
> +
> + /* Only supported on platforms that use atomic watermark design */
> + if (!dev_priv->display.program_watermarks)
> + return;
> +
> + /*
> + * Calculate what we think WM's should be by creating a dummy state and
> + * running it through the atomic check code.
> + */
> + drm_modeset_acquire_init(&ctx, 0);
> + state = drm_atomic_helper_duplicate_state(dev, &ctx);
> + if (WARN_ON(IS_ERR(state)))
> + return;
> +
> + ret = intel_atomic_check(dev, state);
> + if (ret) {
> + /*
> + * Just give up and leave watermarks untouched if we get an
> + * error back from 'check'
> + */
> + DRM_DEBUG_KMS("Could not determine valid watermarks for
> inherited state\n");
> + return;
> + }
> +
> + /* Write calculated watermark values back */
> + to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
> +
> + dev_priv->display.program_watermarks(cs);
> + }
> +
> + drm_atomic_state_free(state);
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +}
> +
> void intel_modeset_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
> intel_dump_pipe_config(crtc, crtc->config,
> "[state after init fb reconstruction]");
> }
> +
> + /*
> + * Ma
[Intel-gfx] [PATCH 0/5] Better markup for GPU DocBook
Hi all, As you might know the markup improvements have been discussed at kernel summit: https://lwn.net/Articles/662930/ Unfortunately it died in a bikeshed fest due to an alliance of people who think docs are useless and you should just read code and others who didn't know how to build the kerneldoc into something pretty. Oh well. But I still want this, and Dave Airlie is ok with using it for drm kerneldoc as long as I maintain the support. Plan is to merge the first patch to adjust gpu.tmpl into drm properly, and keep everything else in topic/kerneldoc at git://anongit.freedesktop.org/drm-intel topic/kerneldoc If you want to build pretty docs just install asciidoc and base your drm documentation patches on top of drm-intel-nightly. That tree also includes all of Dave's tree. Alternatively pull in the above topic branch. Note that asciidoc is strictly optional, but without it the docbook will look a bit bad since beyond paragraphs there won't be any additional formatting (like tables, quoting for sourcecode snippets or lists). Intel also has an autobuilder that pushes latest drm-intel-nightly docs to http://dri.freedesktop.org/docs/drm/ Cheers, Daniel Daniel Vetter (2): scripts/kernel-doc: Use asciidoc instead of markdown drm: Enable markdown^Wasciidoc for gpu.tmpl Danilo Cesar Lemes de Paula (3): drm/doc: Convert to markdown scripts/kernel-doc: Adding infrastructure for markdown support scripts/kernel-doc: Improve Markdown results Documentation/DocBook/Makefile | 25 +--- Documentation/DocBook/gpu.tmpl | 86 -- drivers/gpu/drm/drm_modes.c| 12 ++-- drivers/gpu/drm/drm_modeset_lock.c | 14 ++--- drivers/gpu/drm/drm_prime.c| 16 ++--- drivers/gpu/drm/i915/i915_reg.h| 48 +++ scripts/docproc.c | 54 - scripts/kernel-doc | 120 - 8 files changed, 203 insertions(+), 172 deletions(-) -- 2.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/doc: Convert to markdown
From: Danilo Cesar Lemes de Paula
DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.
* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore
* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
to look pretty bad on html. Fixed by using proper code markup.
* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
a proper markup list.
* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
it doesn't support table cell spanning. But we can use fixed-width
for those special cases.
* include/drm/drm_vma_manager.h: Another code example that should be
proper indented with four spaces.
v2 (Daniel): Adjust name to gpu.xml due to rename.
v3 (Daniel):
Split out the actual enabling in the Makefile - this way we can merge
the conversion, while just keeping the enabling in a drm-private tree.
Signed-off-by: Danilo Cesar Lemes de Paula (v1)
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 86 --
drivers/gpu/drm/drm_modes.c| 12 +++---
drivers/gpu/drm/drm_modeset_lock.c | 14 +++
drivers/gpu/drm/drm_prime.c| 16 +++
drivers/gpu/drm/i915/i915_reg.h| 48 ++---
5 files changed, 42 insertions(+), 134 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 201dcd3c2e9d..c05d7df3067d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -4039,92 +4039,6 @@ int num_ioctls;
DPIO
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
-
- Dual channel PHY (VLV/CHV/BXT)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- CH0
- CH1
-
-
-
-
- CMN/PLL/REF
- CMN/PLL/REF
-
-
- PCS01
- PCS23
- PCS01
- PCS23
-
-
- TX0
- TX1
- TX2
- TX3
- TX0
- TX1
- TX2
- TX3
-
-
- DDI0
- DDI1
-
-
-
-
-
- Single channel PHY (CHV/BXT)
-
-
-
-
-
-
-
-
-
-
- CH0
-
-
-
-
- CMN/PLL/REF
-
-
- PCS01
- PCS23
-
-
- TX0
- TX1
- TX2
- TX3
-
-
- DDI2
-
-
-
-
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cd74a0953f42..9480464434cf 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -553,10 +553,10 @@ EXPORT_SYMBOL(drm_gtf_mode_complex);
* drivers/video/fbmon.c
*
* Standard GTF parameters:
- * M = 600
- * C = 40
- * K = 128
- * J = 20
+ * M = 600
+ * C = 40
+ * K = 128
+ * J = 20
*
* Returns:
* The modeline based on the GTF algorithm stored in a drm_display_mode object.
@@ -1212,7 +1212,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update);
* This uses the same parameters as the fb modedb.c, except for an extra
* force-enable, force-enable-digital and force-disable bit at the end:
*
- * x[M][R][-][@][i][m][eDd]
+ * x[M][R][-][@][i][m][eDd]
*
* The intermediate drm_cmdline_mode structure is required to store additional
* options from the command line modline like the force-enable/disable flag.
@@ -1491,4 +1491,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
out:
return ret;
-}
\ No newline at end of file
+}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 6675b1428410..7c9ca2381d78 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -40,17 +40,15 @@
* The basic usage pattern is to:
*
* drm_modeset_acquire_init(&ctx)
- * retry:
+ * retry:
* foreach (lock in random_ordered_set_of_locks) {
- * ret = drm_modeset_lock(lock, &ctx)
- * if (ret == -EDEADLK) {
- * drm_modeset_backoff(&ctx);
- * goto retry;
- * }
+ * ret = drm_mode
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)
On Wed, Nov 25, 2015 at 08:48:35AM -0800, Matt Roper wrote:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time. These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new state; they should satisfy the requirements of both
> states which means they can be programmed immediately when we commit the
> atomic state (without waiting for a vblank). Once the vblank does
> happen, we can then re-program watermarks to the more optimal final
> value.
>
> v2: Significant rebasing/rewriting.
>
> v3:
> - Move 'need_postvbl_update' flag to CRTC state (Daniel)
> - Don't forget to check intermediate watermark values for validity
>(Maarten)
> - Don't due async watermark optimization; just do it at the end of the
>atomic transaction, after waiting for vblanks. We do want it to be
>async eventually, but adding that now will cause more trouble for
>Maarten's in-progress work. (Maarten)
> - Don't allocate space in crtc_state for intermediate watermarks on
>platforms that don't need it (gen9+).
> - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
>now that ilk_update_wm is gone.
>
> v4:
> - Add a wm_mutex to cover updates to intel_crtc->active and the
>need_postvbl_update flag. Since we don't have async yet it isn't
>terribly important yet, but might as well add it now.
> - Change interface to program watermarks. Platforms will now expose
>.initial_watermarks() and .optimize_watermarks() functions to do
>watermark programming. These should lock wm_mutex, copy the
>appropriate state values into intel_crtc->active, and then call
>the internal program watermarks function.
>
> v5:
> - Skip intermediate watermark calculation/check during initial hardware
>readout since we don't trust the existing HW values (and don't have
>valid values of our own yet).
> - Don't try to call .optimize_watermarks() on platforms that don't have
>atomic watermarks yet. (Maarten)
>
> v6:
> - Rebase
>
> v7:
> - Further rebase
>
> Signed-off-by: Matt Roper
> Reviewed-by(v5): Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_display.c | 90 +++-
> drivers/gpu/drm/i915/intel_drv.h | 31 ++-
> drivers/gpu/drm/i915/intel_pm.c | 160
> ---
> 5 files changed, 232 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5172604..427b488 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,7 +630,11 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
> int (*compute_pipe_wm)(struct intel_crtc *crtc,
> struct drm_atomic_state *state);
> - void (*program_watermarks)(struct intel_crtc_state *cstate);
> + int (*compute_intermediate_wm)(struct drm_device *dev,
> +struct intel_crtc *intel_crtc,
> +struct intel_crtc_state *newstate);
> + void (*initial_watermarks)(struct intel_crtc_state *cstate);
> + void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> void (*update_wm)(struct drm_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 643f342..b91e166 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>
> crtc_state->update_pipe = false;
> crtc_state->disable_lp_wm = false;
> + crtc_state->wm.need_postvbl_update = false;
>
> return &crtc_state->base;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eb52afa..8db0486 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11801,6 +11801,12 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> intel_crtc->atomic.update_wm_pre = true;
> }
>
> + /* Pre-gen9 platforms need two-step watermark updates */
> + if ((intel_crtc->atomic.update_wm_pre ||
> intel_crtc->atomic.update_wm_post) &&
> + INTEL_INFO(dev)->gen < 9 &&
> + dev_priv->display.optimize_watermarks)
> + to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
> +
> if (visible || was_visible)
> intel_crtc->atomic.fb_bits |=
> to_intel_plane(plane)->frontbuffer_bit;
> @@ -11957,8 +11963,29 @@ static int intel_crtc_atomic_check(struct dr
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request
On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote: > On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > > The wait-request interface still has the wait-seqno legacy of having to > > acquire the reset_counter under the mutex before calling. That is quite > > hairy and causes a major complication later where we want to amalgamate > > waiters. > > Yeah, that's a sensible change. But since I don't yet understand where > exactly the current logic results in a wedge gpu I can't convince myself > that the new one is ok. Just to show where I am going with the interface change and why I think it so important (other than it removes a hairy dance that we've have had to copy all around the code): http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=75e73616f72f14ab82037adb1b2b054e2e500c21 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] scripts/kernel-doc: Improve Markdown results
From: Danilo Cesar Lemes de Paula
Using pandoc as the Markdown engine cause some minor side effects as
pandoc includes main tags for almost everything.
Original Markdown support approach removes those main tags, but it caused
some inconsistencies when that tag is not the main one, like:
..
...
As kernel-doc was already including a tag, it causes the presence
of double tags (), which is not supported by DocBook
spec.
Html target gets away with it, so it causes no harm, although other
targets might not be so lucky (pdf as example).
We're now delegating the inclusion of the main tag to pandoc
only, as it knows when it's necessary or not.
That behavior causes a corner case, the only situation where we're
certainly that is not needed, which is the content.
For those cases, we're using a $output_markdown_nopara = 1 control var.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
Cc: Graham Whaley
---
scripts/kernel-doc | 48 ++--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 28737053395a..e01e74f15a22 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -288,6 +288,7 @@ my $use_markdown = 0;
my $verbose = 0;
my $output_mode = "man";
my $output_preformatted = 0;
+my $output_markdown_nopara = 0;
my $no_doc_sections = 0;
my @highlights = @highlights_man;
my $blankline = $blankline_man;
@@ -538,8 +539,11 @@ sub markdown_to_docbook {
close(CHLD_OUT);
close(CHLD_ERR);
- # pandoc insists in adding Main , we should remove them.
- $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+ if ($output_markdown_nopara) {
+ # pandoc insists in adding Main , sometimes we
+ # want to remove them.
+ $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+ }
return $content;
}
@@ -614,7 +618,7 @@ sub output_highlight {
$line =~ s/^\s*//;
}
if ($line eq ""){
- if (! $output_preformatted) {
+ if (! $output_preformatted && ! $use_markdown) {
print $lineprefix, local_unescape($blankline);
}
} else {
@@ -1035,7 +1039,7 @@ sub output_section_xml(%) {
# programlisting is already included by pandoc
print "\n" unless $use_markdown;
$output_preformatted = 1;
- } else {
+ } elsif (! $use_markdown) {
print "\n";
}
output_highlight($args{'sections'}{$section});
@@ -1043,7 +1047,7 @@ sub output_section_xml(%) {
if ($section =~ m/EXAMPLE/i) {
print "\n" unless $use_markdown;
print "\n";
- } else {
+ } elsif (! $use_markdown) {
print "\n";
}
print "\n";
@@ -1075,7 +1079,9 @@ sub output_function_xml(%) {
print " " . $args{'function'} . "\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1113,10 +1119,12 @@ sub output_function_xml(%) {
$parameter_name =~ s/\[.*//;
print " \n
$parameter\n";
- print " \n\n";
+ print " \n";
+ print "\n" unless $use_markdown;
$lineprefix=" ";
output_highlight($args{'parameterdescs'}{$parameter_name});
- print "\n \n \n";
+ print "\n" unless $use_markdown;
+ print " \n \n";
}
print " \n";
} else {
@@ -1152,7 +1160,9 @@ sub output_struct_xml(%) {
print " " . $args{'type'} . " " . $args{'struct'} .
"\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1205,9 +1215,11 @@ sub output_struct_xml(%) {
($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
print "";
print " $parameter\n";
- print " \n";
+ print " \n";
+ print " \n" unless $use_markdown;
output_highlight($args{'parameterdescs'}{$parameter_name});
- print " \n";
+ print " \n" unless $use_markdown;
+ print " \n";
print "\n";
}
print " \n";
@@ -1246,7 +1258,9 @@ sub output_enum_xml(%) {
print " enum " . $args{'enum'} . "\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1276,9 +1290,11 @@ sub output_enum_xml(%) {
print "";
print " $parameter\n";
- print " \n";
[Intel-gfx] [PATCH 4/5] scripts/kernel-doc: Use asciidoc instead of markdown
By popular demand.
This needs some adjustment/fixups after feeding snippets to asciidoc
since compared to markdown asciidown escapes xml markup and doesn't
just let it through.
The other noticeable change is that build times increase a lot - we
need to launch the markup process per-snippet, there's a few thousand
of them and asciidoc (python) has a substantial higher overhead per
invocation than pandoc (haskell).
Cc: Danilo Cesar Lemes de Paula
Cc: Thomas Wood
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/Makefile | 6 +++---
scripts/kernel-doc | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 246ad38550e5..5335955c0de5 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -104,8 +104,8 @@ define rule_docproc
endef
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
- @(which pandoc > /dev/null 2>&1) || \
- (echo "*** To get propper documentation you need to install pandoc
***";)
+ @(which asciidoc > /dev/null 2>&1) || \
+ (echo "*** To get propper documentation you need to install asciidoc
***";)
$(call if_changed_rule,docproc)
# Tell kbuild to always build the programs
@@ -116,7 +116,7 @@ notfoundtemplate = echo "*** You have to install
docbook-utils or xmlto ***"; \
db2xtemplate = db2TYPE -o $(dir $@) $<
xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
-ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+ifneq ($(shell which asciidoc >/dev/null 2>&1 && echo found),found)
MARKDOWNREADY := "";
endif
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index e01e74f15a22..c8eed5299a4b 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -524,7 +524,7 @@ sub dump_doc_section {
sub markdown_to_docbook {
my $orig_content = $_[0];
- my $pid = open3( \*CHLD_IN, \*CHLD_OUT, \*CHLD_ERR, "pandoc
--columns=80 -f markdown -t docbook" );
+ my $pid = open3( \*CHLD_IN, \*CHLD_OUT, \*CHLD_ERR, "asciidoc
--no-header-footer --backend=docbook45 -" );
print CHLD_IN "$orig_content";
close(CHLD_IN);
@@ -605,6 +605,16 @@ sub output_highlight {
# print STDERR "contents af:$contents\n";
if ($use_markdown) {
$contents = markdown_to_docbook($contents);
+
+ # Compared to markdown asciidoc doesn't let through arbitrary xml
+ # markup. We need to un-escape the kerneldoc markup for functions,
+ # structures, ...
+ $contents =~ s/(\S*)<\/quote>/$1<\/quote>/g;
+ $contents =~
s/(\S*)<\/constant>/$1<\/constant>/g;
+ $contents =~
s/(\S*)<\/structname>/$1<\/structname>/g;
+ $contents =~
s/(\S*)<\/parameter>/$1<\/parameter>/g;
+ $contents =~
s/(\S*)<\/function>/$1<\/function>/g;
+ $contents =~ s/(\S*)<\/envar>/$1<\/envar>/g;
}
# strip whitespaces when generating html5
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks
On Wed, Nov 25, 2015 at 09:04:11AM -0800, Matt Roper wrote: > On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > > > We've been chasing a regression[1] that prevented us from merging the last > > > couple patches of the ILK-style atomic watermark series. We've finally > > > identified the culprit --- if we fail to reconstruct the BIOS FB, our > > > internal > > > driver state was left in an inconsistent state which caused confusion for > > > the > > > watermark code. Here's a series that collects that fix (along with a > > > couple > > > other bugfixes that were found while debugging), a few debugging > > > enhancements, > > > and the completion of the ILK atomic watermark series. > > > > > > * The first patch in this series addresses that issue and > > >ensures that we cleanly turn off the primary plane if we're unable to > > > inherit > > >the framebuffer. > > > * Patches 2-4 just clarify/expand some of the information dumped by the > > >driver while debugging. > > > * Patches 5 and 6 fix two additional bugs that were discovered while > > >searching for the cause of the regression. > > > * Patch 7 just adds some extra paranoia and invariant checking to the > > >watermark code. > > > * Patches 8 and 9 are the two final patches from the original atomic > > > watermark > > >series; with the fixes earlier in the series, we've confirmed that > > > they no > > >longer cause regressions on Jani's machine. > > > > > > [1] > > > http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html > > > > Quickly skimmed through the series to see if there was a fix to > > the "merging optimal wms instead of merging active wms like we > > should" bug we have in the current code right now. Nothing > > relevant caught my eye at least. > > I'm not sure I'm aware of this problem; is there a bugzilla or mailing > list thread that describes the issue? Maybe not. The problem is that ilk_wm_merge() and co. use the optimal wms when merging from all pipes. They should use the active wms instead. > > > Matt > > > > > > > > > Matt Roper (9): > > > drm/i915: Disable primary plane if we fail to reconstruct BIOS fb > > > drm/i915: Dump in-flight plane state while dumping in-flight CRTC > > > state > > > drm/i915: Clarify plane state during CRTC state dumps (v2) > > > drm/i915: Dump pipe config after initial FB is reconstructed > > > drm/i915: Setup clipped src/dest coordinates during FB reconstruction > > > (v2) > > > drm/i915: Convert hsw_compute_linetime_wm to use in-flight state > > > drm/i915: Add extra paranoia to ILK watermark calculations > > > drm/i915: Sanitize watermarks after hardware state readout (v2) > > > drm/i915: Add two-stage ILK-style watermark programming (v7) > > > > > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > > > drivers/gpu/drm/i915/i915_drv.h | 5 + > > > drivers/gpu/drm/i915/intel_atomic.c | 1 + > > > drivers/gpu/drm/i915/intel_display.c | 195 > > > +-- > > > drivers/gpu/drm/i915/intel_drv.h | 31 +- > > > drivers/gpu/drm/i915/intel_pm.c | 186 > > > - > > > 6 files changed, 359 insertions(+), 60 deletions(-) > > > > > > -- > > > 2.1.4 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Ville Syrjälä > > Intel OTC > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
Second attempt using Imres' hints. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
From: Marius Vlad
Signed-off-by: Marius Vlad
---
tests/pm_rpm.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index c4fb19c..157cf29 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool dpms)
}
}
+static void pm_test_tiling(void)
+{
+ uint32_t *handles;
+ uint8_t **gem_bufs;
+
+ int max_gem_objs = 0;
+ uint8_t off_bit = 20;
+ uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
+
+ uint32_t i, j, tiling_modes[3] = {
+ I915_TILING_NONE,
+ I915_TILING_X,
+ I915_TILING_Y,
+ };
+ uint32_t ti, sw;
+
+ /* default value */
+ uint32_t stride = 1024;
+
+ /* calculate how many objects we can map */
+ for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
+ ;
+
+ gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
+ handles = malloc(sizeof(uint32_t) * max_gem_objs);
+
+ /* map to gtt and store some random data */
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ handles[i] = gem_create(drm_fd, j);
+ gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
+ memset(gem_bufs[i], 0x65, j);
+ }
+
+ /* try to set different tiling for each handle */
+ for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
+ disable_all_screens_and_wait(&ms_data);
+
+ for (j = 0; j < max_gem_objs; j++) {
+ gem_set_tiling(drm_fd, handles[j], tiling_modes[i],
stride);
+
+ gem_get_tiling(drm_fd, handles[j], &ti, &sw);
+ igt_assert(tiling_modes[i] == ti);
+ }
+
+ enable_one_screen_and_wait(&ms_data);
+ }
+
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ igt_assert(munmap(gem_bufs[i], j) == 0);
+ gem_close(drm_fd, handles[i]);
+ }
+
+ free(gem_bufs);
+ free(handles);
+}
+
+static void pm_test_caching(void)
+{
+ uint32_t *handles;
+ uint8_t **gem_bufs;
+ int8_t has_caching_display = -1;
+
+ uint32_t i, j, got_caching;
+ uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
+ uint32_t cache_levels[3] = {
+ I915_CACHING_NONE,
+ I915_CACHING_CACHED,/* LLC caching */
+ I915_CACHING_DISPLAY, /* eDRAM caching */
+ };
+
+ int max_gem_objs = 0;
+ uint8_t off_bit = 20;
+
+ for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
+ ;
+
+ gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
+ handles = malloc(sizeof(uint32_t) * max_gem_objs);
+
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ handles[i] = gem_create(drm_fd, j);
+ gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
+ memset(gem_bufs[i], 0x65, j);
+ }
+
+ /* figure out if we have cache display available on the platform */
+ gem_set_caching(drm_fd, handles[0], I915_CACHING_DISPLAY);
+ if (gem_get_caching(drm_fd, handles[0]))
+ has_caching_display++;
+
+ for (i = 0; i < ARRAY_SIZE(cache_levels) + has_caching_display; i++) {
+ disable_all_screens_and_wait(&ms_data);
+
+ for (j = 0; j < max_gem_objs; j++) {
+ gem_set_caching(drm_fd, handles[j], cache_levels[i]);
+
+ igt_debug("Verying cache for handle %u, level %u\n", j,
i);
+ got_caching = gem_get_caching(drm_fd, handles[j]);
+
+ igt_assert(got_caching == cache_levels[i]);
+ }
+
+ enable_one_screen_and_wait(&ms_data);
+ }
+
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ igt_assert(munmap(gem_bufs[i], j) == 0);
+ gem_close(drm_fd, handles[i]);
+ }
+
+ free(handles);
+ free(gem_bufs);
+}
+
static void fences_subtest(bool dpms)
{
int i;
@@ -1927,6 +2041,12 @@ int main(int argc, char *argv[])
igt_subtest("gem-execbuf-stress-extra-wait")
gem_execbuf_stress_subtest(rounds, WAIT_STATUS | WAIT_EXTRA);
+ /* power-wake reference tests */
+ igt_subtest("pm-tiling")
+ pm_test_tiling();
+ igt_subtest("pm-caching")
+ pm_test_caching();
+
igt_fixture
teardown_environment();
--
2.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > > From: Akash Goel
> > > > >
> > > > > When the object is moved out of CPU read domain, the cachelines
> > > > > are not invalidated immediately. The invalidation is deferred till
> > > > > next time the object is brought back into CPU read domain.
> > > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > > where the cachelines were flushed previously, when the object moved
> > > > > out
> > > > > of CPU write domain. This is avoidable and would lead to some
> > > > > optimization.
> > > > > Though this is not a hypothetical case, but is unlikely to occur
> > > > > often.
> > > > > The aim is to detect changes to the backing storage whilst the
> > > > > data is potentially in the CPU cache, and only clflush in those case.
> > > > >
> > > > > Signed-off-by: Chris Wilson
> > > > > Signed-off-by: Akash Goel
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index df9316f..fedb71d 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > > unsigned long gt_ro:1;
> > > > > unsigned int cache_level:3;
> > > > > unsigned int cache_dirty:1;
> > > > > + unsigned int cache_clean:1;
> > > >
> > > > So now we have cache_dirty and cache_clean which seems redundant,
> > > > except somehow cache_dirty != !cache_clean?
> >
> > Exactly, not entirely redundant. I did think something along MESI lines
> > would be useful, but that didn't capture the different meanings we
> > employ.
> >
> > cache_dirty tracks whether we have been eliding the clflush.
> >
> > cache_clean tracks whether we know the cache has been completely
> > clflushed.
>
> Can we know that with speculative prefetching and whatnot?
"The memory attribute of the page containing the affected line has no
effect on the behavior of this instruction. It should be noted that
processors are free to speculative fetch and cache data from system
memory regions assigned a memory-type allowing for speculative reads
(i.e. WB, WC, WT memory types). The Streaming SIMD Extensions PREFETCHh
instruction is considered a hint to this speculative behavior. Because
this speculative fetching can occur at any time and is not tied to
instruction execution, CLFLUSH is not ordered with respect to PREFETCHh
or any of the speculative fetching mechanisms (that is, data could be
speculative loaded into the cache just before, during, or after the
execution of a CLFLUSH to that cache line)."
which taken to the extreme means that we can't get away with this trick.
If we can at least guarantee that such speculation can't extend beyond
a page boundary that will be enough to assert that the patch is valid.
Hopefully someone knows a CPU guru or two.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio
My apologies to Chris Wilson for being dense on this topic for
essentially for years.
This patch doesn't do any big redesign of the overall reset flow, but
instead just applies changes where it's needed to obey gem_eio. We can
redesign later on, but for now I prefer to make the testcase happy
with some minimally invasive changes:
- Ensure that set_domain_ioctl never returns -EIO. Tricky part there
is that we might race with the reset handler when doing the lockless
wait.
- Make sure debugfs/i915_wedged is actually useful to reset a wedged
gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
That's because reset_in_progress actually includes that terminal
state, which is super-confusing (and most callers got this wrong).
Fix this by changing the semantics of reset_in_progress to do what
it says on the tin (and fixup all other callers).
Also make sure that reset_in_progress is cleared when we reach the
terminal "wedged" state. Without this we kept returning -EAGAIN in
some places forever.
- Second problem with debugfs/i915_wedge was that we never got out of
the terminal wedged state. Hence manually set the reset counter out
of that state before starting the hung gpu recovery.
For safety also make sure that we are consintent with resetting the
gpu between i915_reset_and_wakeup and i915_handler_error by just
passing the boolean "wedged" around instead of trying to recompute
it wrongly. This isn't an issue for gem_eio with the debugfs fix,
but just general robustness of the code.
- Finally make sure that when gpu reset is disabled through the module
paramter the kernel doesn't generate dmesg noise that would upset
our CI/piglit. Simplest solution for that was to lift the i915.reset
check up into i915_reset().
With all these changes, plus the igt fixes I've posted, gem_eio is now
happy on many snb.
v2: Don't upset lockdep with my set_domain_ioctl changes.
Cc: Chris Wilson
Testcase: igt/gem_eio/*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 23 +++
drivers/gpu/drm/i915/i915_irq.c | 11 ++-
drivers/gpu/drm/i915/intel_uncore.c | 3 ---
6 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 411a9c68b4ee..c4006c09ef1b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
if (i915_reset_in_progress(&dev_priv->gpu_error))
return -EAGAIN;
+ /* Already wedged, force us out of this terminal state. */
+ if (i915_terminally_wedged(&dev_priv->gpu_error))
+ atomic_set(&dev_priv->gpu_error.reset_counter, 0);
+
intel_runtime_pm_get(dev_priv);
i915_handle_error(dev, val,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec1e877c4a36..1f5386bb78f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
simulated = dev_priv->gpu_error.stop_rings != 0;
+ if (!i915.reset) {
+ DRM_INFO("GPU reset disabled in module option, not
resetting\n");
+ mutex_unlock(&dev->struct_mutex);
+ return -ENODEV;
+ }
+
ret = intel_gpu_reset(dev);
/* Also reset the gpu hangman. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a47e0f4fab56..8876b4891d56 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2939,7 +2939,7 @@ int __must_check i915_gem_check_wedge(struct
i915_gpu_error *error,
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
return unlikely(atomic_read(&error->reset_counter)
- & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+ & I915_RESET_IN_PROGRESS_FLAG);
}
static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f10a5d57377e..f794e8f37f92 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -85,8 +85,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
{
int ret;
-#define EXIT_COND (!i915_reset_in_progress(error) || \
- i915_terminally_wedged(error))
+#define EXIT_COND (!i915_reset_in_progress(error))
if (EXIT_COND)
return 0;
@@ -1113,16 +1112,16 @@ int
i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible)
{
+ /* Recovery complete, but the reset failed ... */
+ if (i915_terminally_wedged(error))
+ return -EIO;
+
