Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs

[Ander Conselvan De Oliveira]

On Mon, 2016-03-14 at 19:55 +0200, Imre Deak wrote:
> After the commit below the Broxton PLL IDs had an off-by-one error, so
> fix this up. Also add a missing brace at intel_shared_dpll_init(), it
> happened to compile only due to the way the IS_BROXTON macro is defined.
> 
> v2:
> - remove debugging left-over
> 
> Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll
> code")
> CC: Ander Conselvan de Oliveira 
> CC: Maarten Lankhorst 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 6 +++---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a720628..3cbb02b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9762,15 +9762,15 @@ static void bxt_get_ddi_pll(struct drm_i915_private
> *dev_priv,
>   switch (port) {
>   case PORT_A:
>   pipe_config->ddi_pll_sel = SKL_DPLL0;
> - id = DPLL_ID_SKL_DPLL1;
> + id = DPLL_ID_SKL_DPLL0;
>   break;
>   case PORT_B:
>   pipe_config->ddi_pll_sel = SKL_DPLL1;
> - id = DPLL_ID_SKL_DPLL2;
> + id = DPLL_ID_SKL_DPLL1;
>   break;
>   case PORT_C:
>   pipe_config->ddi_pll_sel = SKL_DPLL2;
> - id = DPLL_ID_SKL_DPLL3;
> + id = DPLL_ID_SKL_DPLL2;

Hmm, I think the mistake is that BXT relied on SKL DPLL ids in the first place.
This is fine as a fix up, but maybe it would be better to just add separate ids
for broxton too. Or even better, get rid of pll->id.

>   break;
>   default:
>   DRM_ERROR("Incorrect port type\n");
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 4b636c4..74d5aec 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1706,9 +1706,9 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
>  };
>  
>  static const struct dpll_info bxt_plls[] = {
> - { "PORT PLL A", 0, &bxt_ddi_pll_funcs, 0 },
> - { "PORT PLL B", 1, &bxt_ddi_pll_funcs, 0 },
> - { "PORT PLL C", 2, &bxt_ddi_pll_funcs, 0 },
> + { "PORT PLL A", DPLL_ID_SKL_DPLL0, &bxt_ddi_pll_funcs, 0 },
> + { "PORT PLL B", DPLL_ID_SKL_DPLL1, &bxt_ddi_pll_funcs, 0 },
> + { "PORT PLL C", DPLL_ID_SKL_DPLL2, &bxt_ddi_pll_funcs, 0 },
>   { NULL, -1, NULL, },
>  };
>  
> @@ -1726,7 +1726,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
>  
>   if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
>   dpll_mgr = &skl_pll_mgr;
> - else if IS_BROXTON(dev)
> + else if (IS_BROXTON(dev))

Wow, really don't know how I managed to do this. Thanks for fixing.

Reviewed-by: Ander Conselvan de Oliveira 

>   dpll_mgr = &bxt_pll_mgr;
>   else if (HAS_DDI(dev))
>   dpll_mgr = &hsw_pll_mgr;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Daniel Vetter]

On Mon, Mar 14, 2016 at 02:37:44PM +0100, Bastien Nocera wrote:
> Do you have references for the i915 runtime PM support, a bugzilla or
> mailing-list thread?

i915.ko has runtime PM support, it's just not yet enabled by default due
to some funky corner cases. If you enable it you might hit a bunch of
sanity check warnings in dmesg. But besides those it should mostly work.
I didn't read the full context, just figured I'll throw this in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

[Patchwork]

== Series Details ==

Series: drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write
URL   : https://patchwork.freedesktop.org/series/4446/
State : failure

== Summary ==

Series 4446v1 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno 
write
http://patchwork.freedesktop.org/api/1.0/series/4446/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> SKIP   (skl-i5k-2)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> SKIP   (snb-dellxps)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7)
Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_exec_whisper:
Subgroup basic:
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_pread:
Subgroup basic:
pass   -> DMESG-WARN (skl-i5k-2)
Test gem_render_linear_blits:
Subgroup basic:
pass   -> DMESG-WARN (bdw-nuci7)
Test gem_render_tiled_blits:
Subgroup basic:
pass   -> DMESG-WARN (bdw-nuci7)
Test gem_ringfill:
Subgroup basic-default:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup basic-default-bomb:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-default-child:
pass   -> DMESG-WARN (skl-nuci5)
Subgroup basic-default-hang:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-default-interruptible:
pass   -> DMESG-WARN (skl-nuci5)
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test gem_storedw_loop:
Subgroup basic-blt:
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup basic-default:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-render:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-ultra) UNSTABLE
Test gem_sync:
Subgroup basic-all:
pass   -> DMESG-FAIL (bsw-nuc-2)
pass   -> DMESG-FAIL (skl-i5k-2)
pass   -> DMESG-FAIL (bdw-ultra)
pass   -> DMESG-FAIL (skl-i7k-2)
pass   -> DMESG-FAIL (skl-nuci5)
pass   -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-blt:
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup basic-default:
pass   -> DMESG-FAIL (bsw-nuc-2)
pass   -> DMESG-FAIL (skl-i5k-2)
pass   -> DMESG-FAIL (bdw-ultra)
pass   -> DMESG-FAIL (skl-i7k-2)
pass   -> DMESG-FAIL (skl-nuci5)
pass   -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-render:
pass   -> DMESG-FAIL (bsw-nuc-2)
pass   -> DMESG-FAIL (skl-i5k-2) UNSTABLE
pass   -> DMESG-FAIL (bdw-ultra) UNSTABLE
pass   -> DMESG-FAIL (skl-i7k-2) UNSTABLE
pass   -> DMESG-FAIL (skl-nuci5)
pass   -> DMESG-FAIL (bdw-nuci7) UNSTABLE
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_addfb_basic:
Subgroup addfb25-x-tiled:
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup basic-y-tiled:
pass   -> DMESG-WARN (skl-i5k-2)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-modifier:
pass   -> DMESG-WARN (skl-i5k-2)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: remove intel_hdmi variable declaration

[Patchwork]

== Series Details ==

Series: drm: i915: remove intel_hdmi variable declaration
URL   : https://patchwork.freedesktop.org/series/4452/
State : failure

== Summary ==

Series 4452v1 drm: i915: remove intel_hdmi variable declaration
http://patchwork.freedesktop.org/api/1.0/series/4452/revisions/1/mbox/

Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledy:
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_addfb_basic:
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-dellxps)
Test prime_self_import:
Subgroup basic-llseek-size:
incomplete -> PASS   (ilk-hp8440p)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:155  dwarn:1   dfail:0   fail:1   skip:37 
byt-nuc  total:194  pass:154  dwarn:4   dfail:0   fail:1   skip:35 
hsw-brixbox  total:194  pass:172  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:194  pass:125  dwarn:5   dfail:0   fail:1   skip:63 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1599/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
3d6fb5036918c8fcbebc734afb35ce578b909c13 drm: i915: remove intel_hdmi variable 
declaration

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Joonas Lahtinen]

On ma, 2016-03-14 at 16:59 +0200, Imre Deak wrote:
> Add support for forcing an error at selected places in the driver. As
> an
> example add 4 options to fail during driver loading.
> 
> Requested by Chris.
> 
> v2:
> - Add fault point for modeset initialization
> - Print debug message when injecting an error
> v3:
> - Rename inject_fault to inject_load_failure, rename the related
> macros
>   and helper accordingly (Chris)
> 
> CC: Chris Wilson 
> Signed-off-by: Imre Deak 
> ---
> 
> [This depends on
>  https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597.h
> tml]
> 
>  drivers/gpu/drm/i915/i915_dma.c| 12 
>  drivers/gpu/drm/i915/i915_drv.h| 16 
>  drivers/gpu/drm/i915/i915_params.c |  5 +
>  drivers/gpu/drm/i915/i915_params.h |  1 +
>  4 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c
> index a5121cd..7490307 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct
> drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_MODESET))
> + return -ENODEV;
> +
>   ret = intel_bios_init(dev_priv);
>   if (ret)
>   DRM_INFO("failed to find VBIOS tables\n");
> @@ -950,6 +953,9 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv,
>   struct intel_device_info *device_info;
>   int ret = 0;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_EARLY))
> + return -ENODEV;
> +
>   dev_priv->dev = dev;
>  
>   /* Setup the write-once "constant" device info */
> @@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   int ret;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_MMIO))
> + return -ENODEV;
> +
>   if (i915_get_bridge_dev(dev))
>   return -EIO;
>  
> @@ -1107,6 +1116,9 @@ static int i915_driver_init_hw(struct
> drm_i915_private *dev_priv)
>   uint32_t aperture_size;
>   int ret;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_HW))
> + return -ENODEV;
> +
>   intel_device_info_runtime_init(dev);
>  
>   ret = i915_gem_gtt_init(dev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 25274e1..e2d21d5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -98,6 +98,22 @@
>  #define I915_STATE_WARN_ON(x)
>   \
>   I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
>  
> +#define I915_FAIL_INIT_EARLY BIT(0)
> +#define I915_FAIL_INIT_MMIO  BIT(1)
> +#define I915_FAIL_INIT_HWBIT(2)
> +#define I915_FAIL_INIT_MODESET   BIT(3)
> +
> +static inline bool i915_inject_load_failure(unsigned int fail_mask)
> +{
> + if (i915.inject_load_failure & fail_mask) {
> + DRM_DEBUG_DRIVER("Injecting failure %08x\n",
> fail_mask);
> +
> + return true;
> + }
> +
> + return false;
> +}
> +
>  static inline const char *yesno(bool v)
>  {
>   return v ? "yes" : "no";
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 278c9c4..4faeeed 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
>   .edp_vswing = 0,
>   .enable_guc_submission = false,
>   .guc_log_level = -1,
> + .inject_load_failure = 0,
>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable
> GuC submission (default:false)")
>  module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
>  MODULE_PARM_DESC(guc_log_level,
>   "GuC firmware logging level (-1:disabled (default), 0-
> 3:enabled)");
> +
> +module_param_named(inject_load_failure, i915.inject_load_failure,
> uint, 0600);

This most definitely should be module_param_named_unsafe.

I think I'd also hope to see some kind of compile time option to enable
this. I don't think average user wants this by default.

> +MODULE_PARM_DESC(inject_load_failure,
> + "Force an error at selected points (0:disabled,
> 0x1:INIT_EARLY, 0x2:INIT_MMIO, 0x4:INIT_HW, 0x8:INIT_MODESET)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index bd5026b..b691026 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -59,6 +59,7 @@ struct i915_params {
>   bool enable_guc_submission;
>   bool verbose_state_checks;
>   bool nuclear_pageflip;
> + unsigned int inject_load_failure;

Duh, add it above the bools, this struct was cleaned once already :P

Regards, Joonas

>  };

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Daniel Vetter]

On Mon, Mar 14, 2016 at 04:20:19PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 14, 2016 at 10:04:00AM +0100, Daniel Vetter wrote:
> > On Fri, Mar 11, 2016 at 09:09:12PM +0200, Ville Syrjälä wrote:
> > > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > > > Thanks for the review Ville
> > > > 
> > > > [snip]
> > > > 
> > > > > Kinda hard to see where everything gets used due to the way the 
> > > > > patches
> > > > > are split up.
> > > > 
> > > > Yes, it's far from great...
> > > > 
> > > > > At least the hotplug/mode change events are not needed. We only have 
> > > > > the
> > > > > two points where i915 should inform the audio driver about this stuff,
> > > > > and those are the intel_audio_code_enable/disable(). For that we
> > > > > already have the .pin_eld_notify() hook.
> > > > >
> > > > > The interrupt stuff should mostly vanish from i915 with the subdevice
> > > > > approach. As in i915 would just call the interrupt handler of the 
> > > > > audio
> > > > > driver based on the LPE bits in IIR, and the audio driver can then do
> > > > > whatever it wants based on its own status register.
> > > > 
> > > > Are you saying that the subdevice would provide a read/write interface 
> > > > for the audio driver to look at display registers, and the i915 driver 
> > > > would only provide a notification interface (EDID and interrupts) to 
> > > > the 
> > > > audio driver?
> > > 
> > > The audio driver would simply ioremap the appropriate range of
> > > registers itself.
> > > 
> > > > If yes, would there be two component framework links, one between 
> > > > i915/audio driver and one between subdevice/audio driver.
> > > 
> > > Yeah sort of. i915 registers the platform device for the audio, the
> > > audio driver can then bind to the device via the platform driver .probe
> > > callback. It can then register with the audio component stuff at some
> > > point to get the relevant notifications on the display state. When
> > > i915 gets unloaded we remove the platform device, at which point the
> > > audio driver's platform driver .remove() callback gets invoked and
> > > it should unregister/cleanup everything.
> > > 
> > > I just tried to frob around with the VED code a bit, and got it to load
> > > at least. It's not quite happy about reloading i915 while the ipvr
> > > driver was loaded though. Not sure what's going on there, but I do
> > > think this approach should work. So the VED patch could serve as a
> > > decent enough model to follow.
> > 
> > platform devices registerd by modules are apparently inherently racy and
> > in an unfixable way. At least I remember something like that from VED
> > discussion.
> > 
> > In short you _must_ unload VED manually before unloading i915, or it all
> > goes boom. If this is the only thing that went boom it's acceptable.
> 
> VED goes boom due drm_global_mutex deadlock at least if you load
> i915 while ipvr is already loaded. I didn't check to hard if there
> were any booms on pure unload so far.

Oh right another boom that happened, but can be avoided by dropping the
->load callback and directly calling drm_dev_alloc/register. Shouldn't be
a problem with a non-drm driver though.

> Anyways, I was a bit worried about the races so I did a pair of 
> small test modules to try out this model, and to me it looked to
> work so far. I just unregistered the platform device from the parent
> pci driver .remove() hook, and it got blocked until the platform
> driver's .remove() hook was done.
> 
> In any case if this is broken, then I assume mfd must be broken. And
> that thing is at least used quite extensively.

Hm, I don't remember the exact details, but iirc the problem was that the
struct device is refcounted, but you can't add a module ref for the vtable
is has (specifically the final release method) since that would result in
a ref-loop. Usually it works, but if someone keeps the device alive
(through sysfs or whatever) and you manage to unload everything before
that last ref gets dropped it goes boom.

So "works", but not in a safe way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Daniel Vetter]

On Mon, Mar 14, 2016 at 10:04:00AM +0100, Daniel Vetter wrote:
> On Fri, Mar 11, 2016 at 09:09:12PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > > Thanks for the review Ville
> > > 
> > > [snip]
> > > 
> > > > Kinda hard to see where everything gets used due to the way the patches
> > > > are split up.
> > > 
> > > Yes, it's far from great...
> > > 
> > > > At least the hotplug/mode change events are not needed. We only have the
> > > > two points where i915 should inform the audio driver about this stuff,
> > > > and those are the intel_audio_code_enable/disable(). For that we
> > > > already have the .pin_eld_notify() hook.
> > > >
> > > > The interrupt stuff should mostly vanish from i915 with the subdevice
> > > > approach. As in i915 would just call the interrupt handler of the audio
> > > > driver based on the LPE bits in IIR, and the audio driver can then do
> > > > whatever it wants based on its own status register.
> > > 
> > > Are you saying that the subdevice would provide a read/write interface 
> > > for the audio driver to look at display registers, and the i915 driver 
> > > would only provide a notification interface (EDID and interrupts) to the 
> > > audio driver?
> > 
> > The audio driver would simply ioremap the appropriate range of
> > registers itself.
> > 
> > > If yes, would there be two component framework links, one between 
> > > i915/audio driver and one between subdevice/audio driver.
> > 
> > Yeah sort of. i915 registers the platform device for the audio, the
> > audio driver can then bind to the device via the platform driver .probe
> > callback. It can then register with the audio component stuff at some
> > point to get the relevant notifications on the display state. When
> > i915 gets unloaded we remove the platform device, at which point the
> > audio driver's platform driver .remove() callback gets invoked and
> > it should unregister/cleanup everything.
> > 
> > I just tried to frob around with the VED code a bit, and got it to load
> > at least. It's not quite happy about reloading i915 while the ipvr
> > driver was loaded though. Not sure what's going on there, but I do
> > think this approach should work. So the VED patch could serve as a
> > decent enough model to follow.
> 
> platform devices registerd by modules are apparently inherently racy and
> in an unfixable way. At least I remember something like that from VED
> discussion.
> 
> In short you _must_ unload VED manually before unloading i915, or it all
> goes boom. If this is the only thing that went boom it's acceptable.
> 
> Another bit we didn't fully do for VED is abstracting away the dma mapping
> stuff, because x86 dma abstraction sucks (compared to arm). Not sure, but
> this might have been fixed meanwhile - if we can set up a dma_ops that the
> subdevice would use, we should do so (instead of the page_to_pfn hacks VED
> used).

This one might be a bit a problem - on byt we got away with pfn_to_page
because no iommu at all, but that's not a good idea really. Definitely
need to reevaluate this again. Iirc there's been some talk of just walking
up a chain of platform devices until the core x86 dma code finds something
with dma support, then use that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Daniel Vetter]

On Mon, Mar 14, 2016 at 12:27:51PM -0500, Pierre-Louis Bossart wrote:
> On 3/14/16 10:30 AM, Ville Syrjälä wrote:
> >On Mon, Mar 14, 2016 at 05:21:54PM +0200, Ville Syrjälä wrote:
> >>On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:
> >>>On 3/11/16 1:09 PM, Ville Syrjälä wrote:
> On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> >Thanks for the review Ville
> >
> >[snip]
> >
> >>Kinda hard to see where everything gets used due to the way the patches
> >>are split up.
> >
> >Yes, it's far from great...
> >
> >>At least the hotplug/mode change events are not needed. We only have the
> >>two points where i915 should inform the audio driver about this stuff,
> >>and those are the intel_audio_code_enable/disable(). For that we
> >>already have the .pin_eld_notify() hook.
> >>
> >>The interrupt stuff should mostly vanish from i915 with the subdevice
> >>approach. As in i915 would just call the interrupt handler of the audio
> >>driver based on the LPE bits in IIR, and the audio driver can then do
> >>whatever it wants based on its own status register.
> >
> >Are you saying that the subdevice would provide a read/write interface
> >for the audio driver to look at display registers, and the i915 driver
> >would only provide a notification interface (EDID and interrupts) to the
> >audio driver?
> 
> The audio driver would simply ioremap the appropriate range of
> registers itself.
> 
> >If yes, would there be two component framework links, one between
> >i915/audio driver and one between subdevice/audio driver.
> 
> Yeah sort of. i915 registers the platform device for the audio, the
> audio driver can then bind to the device via the platform driver .probe
> callback. It can then register with the audio component stuff at some
> point to get the relevant notifications on the display state. When
> i915 gets unloaded we remove the platform device, at which point the
> audio driver's platform driver .remove() callback gets invoked and
> it should unregister/cleanup everything.
> >>>
> >>>we don't want to expose this interface when HDAudio is present and
> >>>enabled so we would need to add a test for this.
> >>>Also it looks like you want the creation of the platform device done in
> >>>i915, we were thinking of doing this as part of the audio drivers but in
> >>>the end this looks equivalent. In both cases we would end-up ignoring
> >>>the HAD022A8 HID and not use acpi for this extension
> >>
> >>Well, if you have a device you can hang off from then i915 should need
> >>to register it I suppose. Though that would make the interrupt
> >>forwarding perhaps less nice. There's also the suspend/resume order
> >>dependency to deal with if there's no parent/child relationship between
> >>the devices.
> >
> >Oh and I suppose you'd end up ioremapping part of the pci dev2 mmio bar
> >to get at the registers, which would look a bit funkly at least.
> 
> I understand the benefits of a parent/child device/subdevice model. What I
> don't see is whether we need the component framework at all here?
> It was used in the case of HDaudio since both i915 and HDaudio controllers
> get probed at different times, here the HDMI interface is just a bunch of
> registers/DMA from the same hardware so the whole master/client interface
> exposed by the component framework to 'bind' independent drivers is a bit
> overkill?

I haven't read the patches, but using component.c when you instead can
model it with parent/child smells like abuse. Component.c is meant for
when you have multiple devices all over the device tree that in aggregate
constitute the overall logical driver. This doesn't seem to be the case
here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] intel: New libdrm interface to create unbound wc user mappings for objects

[Daniel Vetter]

On Mon, Mar 14, 2016 at 06:51:54PM +0200, Martin Peres wrote:
> On 10/03/16 10:39, Martin Peres wrote:
> >On 09/03/16 11:09, akash.g...@intel.com wrote:
> >>From: Akash Goel 
> >>
> >>A new libdrm interface 'drm_intel_gem_bo_map_wc' is provided by this
> >>patch. Through this interface Gfx clients can create write combining
> >>virtual mappings of the Gem object. It will provide the same funtionality
> >>of 'mmap_gtt' interface without the constraints of limited aperture
> >>space,
> >>but provided clients handles the linear to tile conversion on their own.
> >>This patch is intended for improving the CPU write operation performance,
> >>as with such mapping, writes are almost 50% faster than with mmap_gtt.
> >>Also it avoids the Cache flush after update from CPU side, when object is
> >>passed on to GPU, which will be the case if regular mmap interface is
> >>used.
> >>This type of mapping is specially useful in case of sub-region
> >>update, i.e. when only a portion of the object is to be updated.
> >>Also there is a support for the unsynchronized version of this interface
> >>named 'drm_intel_gem_bo_map_wc_unsynchronized', through which wc virtual
> >>mappings, but unsynchronized one, can be created of the Gem object.
> >>To ensure the cache coherency, before using this mapping, the GTT
> >>domain has
> >>been reused here. This provides the required Cache flush if the object
> >>is in
> >>CPU domain or synchronization against the concurrent rendering
> >>
> >>The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has
> >>been
> >>extended with a new flags field (defaulting to 0 for existent users). In
> >>order for userspace to detect the extended ioctl, a new parameter
> >>I915_PARAM_HAS_EXT_MMAP has been added for versioning the ioctl
> >>interface.
> >>
> >>v2: Aligned with the v2 of the corresponding kernel patch (Chris)
> >>v3: Added the unmap calls for the wc mapping (Damien)
> >> Added the param feature check before creating the wc mapping &
> >>reduced
> >> the vma limit (Chris)
> >>v4: Removed the extraneous unlock call from map_wc function (Damien)
> >>v5: Rebased.
> >>
> >>Signed-off-by: Akash Goel 
> >>Signed-off-by: Chris Wilson 
> >>Reviewed-by: Damien Lespiau 
> >
> >Chris, Damien,
> >
> >Do you still stand by your S-o-b and R-b? If so, I can push the patch in
> >the coming days.
> 
> Another ping, with both Chris and Damien CCed this time.

Not entirely sure, but we tended to not push libdrm patches if the open
source userspace wasn't there yet. That's why this one was hanging in the
air forever iirc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [i915] add module param "enable_dp_mst"

[Daniel Vetter]

On Mon, Mar 14, 2016 at 11:36:29AM -0500, Nathan Schulte wrote:
> Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
> drm driver: "enable_dp_mst", which is enabled by default.  Disabling the
> parameter forces newly connected DisplayPort sinks to report as not
> supporting multi-stream transport (MST), thus "forcing" the use of
> single-stream transport (SST).

Patch itself looks good, but you're missing the s-o-b line per
Documentation/SubmittingPatches, "developers certificate of origin". I
need that before I can apply it.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_params.c | 5 +
>  drivers/gpu/drm/i915/i915_params.h | 1 +
>  drivers/gpu/drm/i915/intel_dp.c| 3 +++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 278c9c4..97691f1 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
>   .edp_vswing = 0,
>   .enable_guc_submission = false,
>   .guc_log_level = -1,
> + .enable_dp_mst = true,
>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
> submission (default:false)")
>  module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
>  MODULE_PARM_DESC(guc_log_level,
>   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
> +
> +module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
> +MODULE_PARM_DESC(enable_dp_mst,
> + "Enable multi-stream transport (MST) for new DisplayPort sinks. 
> (default: true)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index bd5026b..87153b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -59,6 +59,7 @@ struct i915_params {
>   bool enable_guc_submission;
>   bool verbose_state_checks;
>   bool nuclear_pageflip;
> + bool enable_dp_mst;
>  };
>  
>  extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0e326e7..ba2d024 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3882,6 +3882,9 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
>  {
>   u8 buf[1];
>  
> + if (!i915.enable_dp_mst)
> + return false;
> +
>   if (!intel_dp->can_mst)
>   return false;
>  
> -- 
> 2.7.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 17/17] drm/i915: Split out load time interface registration

[Daniel Vetter]

On Mon, Mar 14, 2016 at 01:00:41PM +0200, Imre Deak wrote:
> According to the new init phases scheme we should register the device
> making it available via some kernel internal or user space interface as
> the last step in the init sequence, so move the corresponding code to a
> separate function.
> 
> Also add a TODO comment about code that still needs to be moved around
> to one of the init phases functions depending on what the role and effect
> of that code is.
> 
> No functional change, except for the reordering of the unload time
> unregistration steps of sysfs wrt. acpi and opregion.
> 
> Suggested by Chris.
> 
> v3:
> - rename i915_driver_init_register to i915_driver_init_frameworks
>   (Chris)
> v4:
> - rename i915_driver_init_frameworks to i915_driver_register (Daniel)
> 
> CC: Chris Wilson 
> CC: Daniel Vetter 
> Signed-off-by: Imre Deak 

Yeah, this brings us a large step towards de-midlayering i915 load/unload,
I like.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 83 
> +++--
>  1 file changed, 54 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index aaf1b17..a5121cd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1209,6 +1209,53 @@ static void i915_driver_cleanup_hw(struct 
> drm_i915_private *dev_priv)
>  }
>  
>  /**
> + * i915_driver_register - register the driver with the rest of the system
> + * @dev_priv: device private
> + *
> + * Perform any steps necessary to make the driver available via kernel
> + * internal or userspace interfaces.
> + */
> +static void i915_driver_register(struct drm_i915_private *dev_priv)
> +{
> + struct drm_device *dev = dev_priv->dev;
> +
> + i915_gem_shrinker_init(dev_priv);
> + /*
> +  * Notify a valid surface after modesetting,
> +  * when running inside a VM.
> +  */
> + if (intel_vgpu_active(dev))
> + I915_WRITE(vgtif_reg(display_ready), VGT_DRV_DISPLAY_READY);
> +
> + i915_setup_sysfs(dev);
> +
> + if (INTEL_INFO(dev_priv)->num_pipes) {
> + /* Must be done after probing outputs */
> + intel_opregion_init(dev);
> + acpi_video_register();
> + }
> +
> + if (IS_GEN5(dev_priv))
> + intel_gpu_ips_init(dev_priv);
> +
> + i915_audio_component_init(dev_priv);
> +}
> +
> +/**
> + * i915_driver_unregister - cleanup the registration done in 
> i915_driver_regiser()
> + * @dev_priv: device private
> + */
> +static void i915_driver_unregister(struct drm_i915_private *dev_priv)
> +{
> + i915_audio_component_cleanup(dev_priv);
> + intel_gpu_ips_teardown();
> + acpi_video_unregister();
> + intel_opregion_fini(dev_priv->dev);
> + i915_teardown_sysfs(dev_priv->dev);
> + i915_gem_shrinker_cleanup(dev_priv);
> +}
> +
> +/**
>   * i915_driver_load - setup chip and create an initial config
>   * @dev: DRM device
>   * @flags: startup flags
> @@ -1246,6 +1293,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   if (ret < 0)
>   goto out_cleanup_mmio;
>  
> + /*
> +  * TODO: move the vblank init and parts of modeset init steps into one
> +  * of the i915_driver_init_/i915_driver_register functions according
> +  * to the role/effect of the given init step.
> +  */
>   if (INTEL_INFO(dev)->num_pipes) {
>   ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
>   if (ret)
> @@ -1258,26 +1310,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   goto out_power_well;
>   }
>  
> - i915_gem_shrinker_init(dev_priv);
> - /*
> -  * Notify a valid surface after modesetting,
> -  * when running inside a VM.
> -  */
> - if (intel_vgpu_active(dev))
> - I915_WRITE(vgtif_reg(display_ready), VGT_DRV_DISPLAY_READY);
> -
> - i915_setup_sysfs(dev);
> -
> - if (INTEL_INFO(dev)->num_pipes) {
> - /* Must be done after probing outputs */
> - intel_opregion_init(dev);
> - acpi_video_register();
> - }
> -
> - if (IS_GEN5(dev))
> - intel_gpu_ips_init(dev_priv);
> -
> - i915_audio_component_init(dev_priv);
> + i915_driver_register(dev_priv);
>  
>   intel_runtime_pm_enable(dev_priv);
>  
> @@ -1316,15 +1349,7 @@ int i915_driver_unload(struct drm_device *dev)
>  
>   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
>  
> - i915_audio_component_cleanup(dev_priv);
> -
> - intel_gpu_ips_teardown();
> -
> - i915_teardown_sysfs(dev);
> -
> - acpi_video_unregister();
> - intel_opregion_fini(dev);
> - i915_gem_shrinker_cleanup(dev_priv);
> + i915_driver_unregister(dev_priv);
>  
>   drm_vblank_cleanup(dev);
>  
> -- 
> 2.5.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Daniel Vetter]

On Mon, Mar 14, 2016 at 04:59:20PM +0200, Imre Deak wrote:
> Add support for forcing an error at selected places in the driver. As an
> example add 4 options to fail during driver loading.
> 
> Requested by Chris.
> 
> v2:
> - Add fault point for modeset initialization
> - Print debug message when injecting an error
> v3:
> - Rename inject_fault to inject_load_failure, rename the related macros
>   and helper accordingly (Chris)
> 
> CC: Chris Wilson 
> Signed-off-by: Imre Deak 
> ---
> 
> [This depends on
>  https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597.html]
> 
>  drivers/gpu/drm/i915/i915_dma.c| 12 
>  drivers/gpu/drm/i915/i915_drv.h| 16 
>  drivers/gpu/drm/i915/i915_params.c |  5 +
>  drivers/gpu/drm/i915/i915_params.h |  1 +
>  4 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a5121cd..7490307 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_MODESET))
> + return -ENODEV;
> +
>   ret = intel_bios_init(dev_priv);
>   if (ret)
>   DRM_INFO("failed to find VBIOS tables\n");
> @@ -950,6 +953,9 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
>   struct intel_device_info *device_info;
>   int ret = 0;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_EARLY))
> + return -ENODEV;
> +
>   dev_priv->dev = dev;
>  
>   /* Setup the write-once "constant" device info */
> @@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   int ret;
>  
> + if (i915_inject_load_failure(I915_FAIL_INIT_MMIO))
> + return -ENODEV;
> +
>   if (i915_get_bridge_dev(dev))
>   return -EIO;

Ok, thought a bit more about this, and if we really want to check all the
load failure paths then this will become extremely verbose. Since we'd
need to have a bitflag for every return -EFAIL. So maybe another look at
lib/fault-inject.c is warranted, plus then some macro magic that we could
to wrap _all_ the checks in our load code like this:

if (i915_load_failure(i915_get_bridge_dev(dev)))
return -EIO;

i915_load_failure ofc needs to fail if it's argument is false, but it
could also increment a counter every time it's called and then use that
counter to inquire the fault injection framework with
should_fail(i915_load_failures, counter). Abusing a counter for the size
would allow us to easily restrict fault injection to a certain range of
faults. We could also expose the final value of that counter in debugfs,
so that the igt can tune itself.

Anyway, this is kinda a big plan, but the part I think we should ponder is
how to make the fault injection less noise and intrusive. A macro to wrap
existing checks seems like a good idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH 3/4] dim: run checkpatch on committed patches on apply

[Jani Nikula]

The input messages may have base64 encoding and whatnot, and
checkpatch.pl can't cope with them. Just let 'git am' handle that. The
upside is that checkpatch will now catch e.g. duplicate signed-off-bys.

This is a partial revert of

commit a913db697bb063d374229e5e806e514fa44985d0
Author: Daniel Vetter 
Date:   Wed Oct 14 18:32:49 2015 +0200

dim: Store patch in a temp file in apply-patch

although we'll still keep the temp file for other purposes, such as
extracting the message-id.

While at it, drop the obsolete check for drm_i915_private_t. We'll now
get a build fail for that.

Signed-off-by: Jani Nikula 
---
 dim | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/dim b/dim
index a287c9126047..83cc5161c767 100755
--- a/dim
+++ b/dim
@@ -421,8 +421,6 @@ function dim_apply_branch
 
local message_id=$(message_get_id $file)
 
-   shell_checkpatch "cat $file"
-
local commiter_email=$(git config --get user.email)
local patch_from=$(grep "From:" "$file" | head -1)
local sob
@@ -438,6 +436,8 @@ function dim_apply_branch
echo "No message-id found in the patch file."
fi
 
+   checkpatch_commit HEAD
+
eval $DRY $DIM_POST_APPLY_ACTION
 }
 
@@ -686,25 +686,17 @@ function check_repo_clean
 
 }
 
-# $1 is the shell command to display the patch/commit
-function shell_checkpatch
-{
-   local cmd=$1
-
-   $cmd | scripts/checkpatch.pl -q --strict - || true
-   if $cmd | grep '^\+.*\WBUG' > /dev/null; then
-   warn_or_fail "New BUG macro added"
-   fi
-   $cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New 
drm_i915_private_t added" || true
-}
-
 # $1 is the git sha1 to check
 function checkpatch_commit
 {
local commit=$1
 
git --no-pager log --oneline -1 $commit
-   shell_checkpatch "git show $commit --pretty=email"
+   git show $commit --pretty=email | scripts/checkpatch.pl -q --emacs 
--strict - || true
+
+   if git show $commit --pretty=email | grep '^\+.*\WBUG' > /dev/null; then
+   warn_or_fail "New BUG macro added"
+   fi
 }
 
 dim_alias_check_patch=checkpatch
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH 2/4] dim: have update-branches also fetch origin and drm upstream repos

[Jani Nikula]

Convenient in many cases, but not as intrusive as full remote update.

Signed-off-by: Jani Nikula 
---
 dim | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index e3fca75bc5e6..a287c9126047 100755
--- a/dim
+++ b/dim
@@ -991,7 +991,9 @@ dim_alias_ub=update-branches
 function dim_update_branches
 {
cd $DIM_PREFIX/$DIM_DRM_INTEL
-   git fetch $DIM_DRM_INTEL_REMOTE
+   for remote in $DIM_DRM_INTEL_REMOTE $DIM_DRM_UPSTREAM_REMOTE origin; do
+   git fetch $remote
+   done
check_repo_clean $DIM_PREFIX/$DIM_DRM_INTEL Kernel
 
for branch in $dim_branches ; do
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH 1/4] dim: update for-next branches as part of nightly rebuild

[Jani Nikula]

Currently the for-linux-next-fixes and for-linux-next branches only get
updated after the nightly rebuild after pushing branches. If the nightly
rebuild fails at that point, the for-next branches won't get updated
until the next time something is pushed, not upon nightly rebuild. Fix
this by making for-next branch update part of dim rebuild-nightly.

Signed-off-by: Jani Nikula 
---
 dim | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index 1e7622a1e902..e3fca75bc5e6 100755
--- a/dim
+++ b/dim
@@ -348,8 +348,10 @@ function dim_rebuild_nightly
git push $DRY_RUN origin HEAD >& /dev/null && echo "Done."
else
echo "Fail: Branch setup for the rerere-cache is borked."
+   exit 1
fi
 
+   update_linux_next
 }
 
 function dim_nightly_forget
@@ -378,7 +380,6 @@ function dim_push_branch
git push $DRY_RUN $DIM_DRM_INTEL_REMOTE $branch "$@"
 
dim_rebuild_nightly
-   update_linux_next
 }
 
 dim_alias_pq=push-queued
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH 4/4] dim: unify repo clean checks to a single assert_repo_clean helper

[Jani Nikula]

Moreover, 'git diff-index --quiet HEAD' kept failing on me even though
the repo was clean (merely running 'git status' always fixed this). So
use the other one.

Signed-off-by: Jani Nikula 
---
 dim | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/dim b/dim
index 83cc5161c767..9c8ae1098977 100755
--- a/dim
+++ b/dim
@@ -411,11 +411,7 @@ function dim_apply_branch
local file=`mktemp`
 
assert_branch $branch
-
-   if [[ -n `git status --porcelain --untracked-files=no` ]] ; then
-   echo Repository not clean, aborting
-   exit 2
-   fi
+   assert_repo_clean
 
cat > $file
 
@@ -676,16 +672,6 @@ function dim_conf
dim_checkout drm-intel-next-fixes "$@"
 }
 
-function check_repo_clean
-{
-   cd $1
-   if ! git diff-index --quiet HEAD ; then
-   echo $2 repo not clean, aborting
-   exit 1
-   fi
-
-}
-
 # $1 is the git sha1 to check
 function checkpatch_commit
 {
@@ -986,7 +972,8 @@ function dim_update_branches
for remote in $DIM_DRM_INTEL_REMOTE $DIM_DRM_UPSTREAM_REMOTE origin; do
git fetch $remote
done
-   check_repo_clean $DIM_PREFIX/$DIM_DRM_INTEL Kernel
+
+   assert_repo_clean
 
for branch in $dim_branches ; do
dim_checkout $branch
@@ -1110,6 +1097,14 @@ function assert_branch
fi
 }
 
+function assert_repo_clean
+{
+   if [[ -n "$(git status --porcelain --untracked-files=no)" ]]; then
+   echo "Repository not clean, aborting."
+   exit 1
+   fi
+}
+
 # Note: used by bash completion
 function dim_list_commands
 {
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

[Michał Winiarski]

On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords.

v2: Fix BAT failures

Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_lrc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..5b7b2ae 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1925,7 +1925,7 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
struct intel_ringbuffer *ringbuf = request->ringbuf;
int ret;
 
-   ret = intel_logical_ring_begin(request, 6 + WA_TAIL_DWORDS);
+   ret = intel_logical_ring_begin(request, 8 + WA_TAIL_DWORDS);
if (ret)
return ret;
 
@@ -1933,7 +1933,7 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
 * need a prior CS_STALL, which is emitted by the flush
 * following the batch.
 */
-   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
+   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
intel_logical_ring_emit(ringbuf,
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
@@ -1941,7 +1941,9 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
intel_logical_ring_emit(ringbuf, hws_seqno_address(request->ring));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
+   intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
+   intel_logical_ring_emit(ringbuf, 0);
return intel_logical_ring_advance_and_submit(request);
 }
 
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs

[Imre Deak]

On ti, 2016-03-15 at 09:50 +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-03-14 at 19:55 +0200, Imre Deak wrote:
> > After the commit below the Broxton PLL IDs had an off-by-one error,
> > so
> > fix this up. Also add a missing brace at intel_shared_dpll_init(),
> > it
> > happened to compile only due to the way the IS_BROXTON macro is
> > defined.
> > 
> > v2:
> > - remove debugging left-over
> > 
> > Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the
> > shared dpll
> > code")
> > CC: Ander Conselvan de Oliveira  > com>
> > CC: Maarten Lankhorst 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c  | 6 +++---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a720628..3cbb02b 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9762,15 +9762,15 @@ static void bxt_get_ddi_pll(struct
> > drm_i915_private
> > *dev_priv,
> >     switch (port) {
> >     case PORT_A:
> >     pipe_config->ddi_pll_sel = SKL_DPLL0;
> > -   id = DPLL_ID_SKL_DPLL1;
> > +   id = DPLL_ID_SKL_DPLL0;
> >     break;
> >     case PORT_B:
> >     pipe_config->ddi_pll_sel = SKL_DPLL1;
> > -   id = DPLL_ID_SKL_DPLL2;
> > +   id = DPLL_ID_SKL_DPLL1;
> >     break;
> >     case PORT_C:
> >     pipe_config->ddi_pll_sel = SKL_DPLL2;
> > -   id = DPLL_ID_SKL_DPLL3;
> > +   id = DPLL_ID_SKL_DPLL2;
> 
> Hmm, I think the mistake is that BXT relied on SKL DPLL ids in the
> first place.
> This is fine as a fix up, but maybe it would be better to just add
> separate ids
> for broxton too. Or even better, get rid of pll->id.

Yes, SKL_DPLLx and DPLL_ID_SKL_DPLLx that were defined originally had
confusingly different indexes already, not sure for the reason for
that. Removing 'id' if possible seems like a good idea.

> 
> >     break;
> >     default:
> >     DRM_ERROR("Incorrect port type\n");
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 4b636c4..74d5aec 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -1706,9 +1706,9 @@ static const struct intel_dpll_mgr
> > skl_pll_mgr = {
> >  };
> >  
> >  static const struct dpll_info bxt_plls[] = {
> > -   { "PORT PLL A", 0, &bxt_ddi_pll_funcs, 0 },
> > -   { "PORT PLL B", 1, &bxt_ddi_pll_funcs, 0 },
> > -   { "PORT PLL C", 2, &bxt_ddi_pll_funcs, 0 },
> > +   { "PORT PLL A", DPLL_ID_SKL_DPLL0, &bxt_ddi_pll_funcs, 0
> > },
> > +   { "PORT PLL B", DPLL_ID_SKL_DPLL1, &bxt_ddi_pll_funcs, 0
> > },
> > +   { "PORT PLL C", DPLL_ID_SKL_DPLL2, &bxt_ddi_pll_funcs, 0
> > },
> >     { NULL, -1, NULL, },
> >  };
> >  
> > @@ -1726,7 +1726,7 @@ void intel_shared_dpll_init(struct drm_device
> > *dev)
> >  
> >     if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
> >     dpll_mgr = &skl_pll_mgr;
> > -   else if IS_BROXTON(dev)
> > +   else if (IS_BROXTON(dev))
> 
> Wow, really don't know how I managed to do this. Thanks for fixing.
> 
> Reviewed-by: Ander Conselvan de Oliveira 

Thanks for the review.

> 
> >     dpll_mgr = &bxt_pll_mgr;
> >     else if (HAS_DDI(dev))
> >     dpll_mgr = &hsw_pll_mgr;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Chris Wilson]

On Tue, Mar 15, 2016 at 10:34:02AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-03-14 at 16:59 +0200, Imre Deak wrote:
> > +module_param_named(inject_load_failure, i915.inject_load_failure,
> > uint, 0600);
> 
> This most definitely should be module_param_named_unsafe.
> 
> I think I'd also hope to see some kind of compile time option to enable
> this. I don't think average user wants this by default.

That's not a bad idea. We can get rid of most of the dangerous params
this way. On the other hand, we need to keep the debug/quirk params
around so that we can test options in the wild (bug reporters).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

[Chris Wilson]

On Tue, Mar 15, 2016 at 10:20:09AM +0100, Michał Winiarski wrote:
> On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords.

But gen8/gen9 still respect 5 for a dword write instead of a qword write.
Please include an explanation of the impact.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

On Mon, Mar 14, 2016 at 03:11:02PM +, Peter Antoine wrote:
> Allow for the MOCS to be programmed for all engines.
> Currently we program the MOCS when the first render batch
> goes through. This works on most platforms but fails on
> platforms that do not run a render batch early,
> i.e. headless servers. The patch now programs all initialised engines
> on init and the RCS is programmed again within the initial batch. This
> is done for predictable consistency with regards to the hardware
> context.
> 
> Hardware context loading sets the values of the MOCS for RCS
> and L3CC. Programming them from within the batch makes sure that
> the render context is valid, no matter what the previous state of
> the saved-context was.
> 
> v2: posted correct version to the mailing list.
> v3: moved programming to within engine->init_hw() (Chris Wilson)
> v4: code formatting and white-space changes. (Chris Wilson)
> 
> Signed-off-by: Peter Antoine 

So testcase?

Execute a bunch of MI_STORE_REGISTER_MEM on the various rings in a fresh
context each time and confirm the ABI for the first N locations.

Repeat across suspend/resume (i.e. make sure the context image maintain
the register state). Then verify that freshly constructed contexts also
have the correct settings after resume.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 27/35] drm/i915: Added debug state dump facilities to scheduler

[Joonas Lahtinen]

Hi,

On pe, 2016-03-11 at 16:38 +, John Harrison wrote:
> The intention of the state dump code is not really for it to be a user 
> accessible debugfs entry (although one of the later patches does add a 
> debugfs interface). It is more intended for debugging lock ups and 
> unexpected behaviour by adding a dump function call to whatever WARN_ON 
> or similar is being hit. So in theory, the code should not be necessary 
> and there is no point upstreaming it. On the other hand, it does come in 
> very handy when debugging scheduler related issues and it is complicated 
> enough that you can't just knock it up in five minutes when a bug report 
> is logged.
> 
> The code could certainly be moved into a separate file, e.g. 
> i915_scheduler_debug.c. I don't think it would be good to move it to 
> debugfs and make it all 'seq_printf' style output only. It is much more 
> use as ordinary printk style output so you can call it directly at the 
> point of detecting an inconsistent state and get the dmesg output prior 
> to the kernel panic.
> 

In that case, it could be moved to it's own file and enabled
conditionally through a config parameter?

If we want to keep feature debugging code, there should be a configure switch 
within i915 configuration to enable the bits.

CC'd Daniel and Chris as this relates to the fault injection code too.
Something along CONFIG_I915_DEBUG_SCHEDULER and CONFIG_I915_DEBUG_FAULT_INJECT 
could be added?

Regards, Joonas

> 
> On 07/03/2016 12:31, Joonas Lahtinen wrote:
> > 
> > Hi,
> > 
> > On to, 2016-02-18 at 14:27 +, john.c.harri...@intel.com wrote:
> > > 
> > > From: John Harrison 
> > > 
> > > When debugging batch buffer submission issues, it is useful to be able
> > > to see what the current state of the scheduler is. This change adds
> > > functions for decoding the internal scheduler state and reporting it.
> > > 
> > > v3: Updated a debug message with the new state_str() function.
> > > 
> > > v4: Wrapped some long lines to keep the style checker happy. Removed
> > > the fence/sync code as that will now be part of a separate patch series.
> > > 
> > > v5: Removed forward declarations and white space. Added documentation.
> > > [Joonas Lahtinen]
> > > 
> > > Also squashed in later patch to add seqno information from the start.
> > > It was only being added in a separate patch due to historical reasons
> > > which have since gone away.
> > > 
> > > For: VIZ-1587
> > > Signed-off-by: John Harrison 
> > > Cc: Joonas Lahtinen 
> > > ---
> > >   drivers/gpu/drm/i915/i915_scheduler.c | 302 
> > > +-
> > >   drivers/gpu/drm/i915/i915_scheduler.h |  15 ++
> > >   2 files changed, 315 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> > > b/drivers/gpu/drm/i915/i915_scheduler.c
> > > index f7f29d5..d0eed52 100644
> > > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > > @@ -40,6 +40,117 @@ bool i915_scheduler_is_enabled(struct drm_device *dev)
> > >   return dev_priv->scheduler != NULL;
> > >   }
> > > 
> > These sort of functions should be in i915_debugfs.c, so that nobody
> > even thinks of using them for other purposes.
> > 
> > > 
> > >   
> > > +const char *i915_qe_state_str(struct i915_scheduler_queue_entry *node)
> > > +{
> > > + static char str[50];
> > > + char*ptr = str;
> > > +
> > > + *(ptr++) = node->bumped ? 'B' : '-',
> > > + *(ptr++) = i915_gem_request_completed(node->params.request) ? 'C' : '-';
> > > +
> > Especially this kind of code needs to be in i915_debugfs.c. I'd
> > implement new code more along lines of i915_sseu_status(), but I see
> > this kind of code was previously merged.
> > 
> > > 
> > > + *ptr = 0;
> > > +
> > > + return str;
> > > +}
> > > +
> > > +char i915_scheduler_queue_status_chr(enum i915_scheduler_queue_status 
> > > status)
> > > +{
> > > + switch (status) {
> > > + case i915_sqs_none:
> > > + return 'N';
> > > +
> > > + case i915_sqs_queued:
> > > + return 'Q';
> > > +
> > > + case i915_sqs_popped:
> > > + return 'X';
> > > +
> > > + case i915_sqs_flying:
> > > + return 'F';
> > > +
> > > + case i915_sqs_complete:
> > > + return 'C';
> > > +
> > > + case i915_sqs_dead:
> > > + return 'D';
> > > +
> > > + default:
> > > + break;
> > > + }
> > > +
> > Bad indent.
> > 
> > > 
> > > + return '?';
> > > +}
> > > +
> > > +const char *i915_scheduler_queue_status_str(
> > > + enum i915_scheduler_queue_status status)
> > > +{
> > > + static char str[50];
> > > +
> > > + switch (status) {
> > > + case i915_sqs_none:
> > > + return "None";
> > > +
> > > + case i915_sqs_queued:
> > > + return "Queued";
> > > +
> > > + case i915_sqs_popped:
> > > + return "Popped";
> > > +
> > > + case i915_sqs_flying:
> > > + return "Flying";
> > > +
> > > + case i915_sqs_complete:
> > > + return "Complete";
> > > +
> > > + case i915_sqs_dead:
> > > + return "Dead";
> > > +
> > > + def

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write 
(rev2)
URL   : https://patchwork.freedesktop.org/series/4446/
State : warning

== Summary ==

Series 4446v2 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno 
write
http://patchwork.freedesktop.org/api/1.0/series/4446/revisions/2/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (hsw-brixbox)
Test gem_exec_basic:
Subgroup gtt-render:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (hsw-gt2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (hsw-gt2)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (hsw-gt2)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (snb-dellxps)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:157  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:175  dwarn:2   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:160  dwarn:0   dfail:1   fail:0   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1600/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
0739b41c7c5d73597668f969418b6ddef9bde7aa drm/i915: Adjust size of PIPE_CONTROL 
used for gen8 render seqno write

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Dave Airlie]

>
> I guess that's only useful until we get runtime PM support.

For the discrete GPUs on regular laptops we have runtime PM support for
powerdown already. Some newer laptops need a bit of work in the PCIE layer
but for most things we have it covered. The known broken ones are Apple
laptops. If the apple-gmux code is working well enough to power off GPUs,
then it should be possible to hook up runtime-pm on those machines pretty
simply.

So there shouldn't really be a case we care about.

runtime PM for the Intel GPU isn't as important. We don't even want to
turn the i915 fully off anymore.

>
> After looking at our use cases in the GNOME wiki, I think that might
> not be necessary as we'll want to always run the desktop on the
> integrated GPU. That'll something to keep in mind if we ever want to
>
> Reading through the whole mail it seems to me that it's close to
> impossible to implement a decent integration without runtime PM
> support:
> - DRI_PRIME wouldn't work
> - no external display detection on some machines
>
> Do you have references for the i915 runtime PM support, a bugzilla or
> mailing-list thread?

the i915 runtime PM doesn't matter for this. Only nouveau/radeon runtime
PM matters for this, and that should work on most Windows compatible hw right
now. For Windows 10 machines there are some patches going around to make
things work. For Apple I'm pretty much in the it'll catch up or it
won't, but don't
block on it.

Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

[Maarten Lankhorst]

Op 11-03-16 om 09:25 schreef Mayuresh Gharpure:
> Co-Author : Marius Vlad 
> Co-Author : Pratik Vishwakarma 
>
> So far we have had only two commit styles, COMMIT_LEGACY
> and COMMIT_UNIVERSAL. This patch adds another commit style
> COMMIT_ATOMIC which makes use of drmModeAtomicCommit()
>
> v2: (Marius)
>   i)Set CRTC_ID to zero while disabling plane
>   ii)Modified the log message in igt_atomic_prepare_plane_commit
>   https://patchwork.freedesktop.org/patch/71945/
>
> v3: (Marius)Set FB_ID to zero while disabling plane
>   https://patchwork.freedesktop.org/patch/72179/
>
> v4: (Maarten) Corrected the typo in commit message
>   https://patchwork.freedesktop.org/patch/72598/
>
> v5: Added check for DRM_CLIENT_CAP_ATOMIC in igt_display_init
> (Marius)
>   i)Removed unused props from igt_display_init
>   ii)Removed unused ret. Changed function to void
>   iii)Declare the variable before checking if we have
>   DRM_CLIENT_CAP_ATOMIC.
>   https://patchwork.freedesktop.org/patch/73505/
>
> v6: (Jani) Corrected typo in commit message
>
> v7: Added is_atomic check for DRM_CLIENT_CAP_ATOMIC in
>   igt_display_init and igt_atomic_commit
>
> v8: (Matthew Auld) Replaced for loops by for_each_connected_output and
>   for_each_plane_on_pipe
> (Lionel) Populate properties only if the value has changed
>   Remove the resetting of values in disable case
>   Note : I've used Maarten's diff patch
>
> v9: (Lionel) Added resetting of rotation property
>
> v10: (Marius) Modified the macro declaration to avoid shadow declaration
>   warning, also removed one unused variable
>
> Signed-off-by: Mayuresh Gharpure 
> Signed-off-by: Pratik Vishwakarma 
> Signed-off-by: Mayuresh Gharpure 
> ---
>  lib/igt_kms.c | 289 
> +-
>  lib/igt_kms.h |  76 ++-
>  2 files changed, 361 insertions(+), 4 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 9f18aef..f9a7bb0 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -145,6 +145,120 @@ const unsigned char* igt_kms_get_base_edid(void)
>   *
>   * Returns: an alternate edid block
>   */
> +static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
> + "SRC_X",
> + "SRC_Y",
> + "SRC_W",
> + "SRC_H",
> + "CRTC_X",
> + "CRTC_Y",
> + "CRTC_W",
> + "CRTC_H",
> + "FB_ID",
> + "CRTC_ID",
> + "type",
> + "rotation"
> +};
> +
> +static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> + "background_color"
> +};
> +
> +static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> + "scaling mode",
> + "DPMS"
> +};
> +
> +/*
> + * Retrieve all the properies specified in props_name and store them into
> + * plane->atomic_props_plane.
> + */
> +static void
> +igt_atomic_fill_plane_props(igt_display_t *display, igt_plane_t *plane,
> + int num_props, const char **prop_names)
> +{
> + drmModeObjectPropertiesPtr props;
> + int i, j, fd;
> +
> + fd = display->drm_fd;
> +
> + props = drmModeObjectGetProperties(fd, plane->drm_plane->plane_id, 
> DRM_MODE_OBJECT_PLANE);
> + igt_assert(props);
> +
> + for (i = 0; i < props->count_props; i++) {
> + drmModePropertyPtr prop =
> + drmModeGetProperty(fd, props->props[i]);
> +
> + for (j = 0; j < num_props; j++) {
> + if (strcmp(prop->name, prop_names[j]) != 0)
> + continue;
> +
> + plane->atomic_props_plane[j] = props->props[i];
> + break;
> + }
> +
> + drmModeFreeProperty(prop);
> + }
> +
> + drmModeFreeObjectProperties(props);
> +}
> +
> +/*
> + * Retrieve all the properies specified in props_name and store them into
> + * config->atomic_props_crtc and config->atomic_props_connector.
> + */
> +static void
> +igt_atomic_fill_props(igt_display_t *display, igt_output_t *output,
> + int num_crtc_props, const char **crtc_prop_names,
> + int num_connector_props, const char **conn_prop_names)
> +{
> + drmModeObjectPropertiesPtr props;
> + int i, j, fd;
> +
> + fd = display->drm_fd;
> +
> + props = drmModeObjectGetProperties(fd, output->config.crtc->crtc_id, 
> DRM_MODE_OBJECT_CRTC);
> + igt_assert(props);
> +
> + for (i = 0; i < props->count_props; i++) {
> + drmModePropertyPtr prop =
> + drmModeGetProperty(fd, props->props[i]);
> +
> + for (j = 0; j < num_crtc_props; j++) {
> + if (strcmp(prop->name, crtc_prop_names[j]) != 0)
> + continue;
> +
> + output->config.atomic_props_crtc[j] = props->props[i];
> + break;
> + }
> +
> + drmModeFreeProperty(prop);
> + }
> +
> + drmModeFreeObjectProperties(props);
> +

[Intel-gfx] [PATCH] drm/i915: Add delay on DPCD reads

[Mika Kahola]

Additional 50 ms delay is needed between DPCD reads on HP Bizlink 1326
DP to VGA adapter. Having said that, I haven't noticed a need for
additional delay between DPCD reads on other DP-VGA dongles.

While at it, let's replace mdelay() with usleep_range() routine.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e326e7..ff3883c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3125,9 +3125,11 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned 
int offset,
 
for (i = 0; i < 3; i++) {
ret = drm_dp_dpcd_read(aux, offset, buffer, size);
-   if (ret == size)
+   if (ret == size) {
+   usleep_range(5, 50100);
return ret;
-   msleep(1);
+   }
+   usleep_range(1000, 1100);
}
 
return ret;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Tue, 2016-03-15 at 21:10 +1000, Dave Airlie wrote:
> > 
> > 
> > I guess that's only useful until we get runtime PM support.
> For the discrete GPUs on regular laptops we have runtime PM support
> for
> powerdown already. Some newer laptops need a bit of work in the PCIE
> layer
> but for most things we have it covered. The known broken ones are
> Apple
> laptops. If the apple-gmux code is working well enough to power off
> GPUs,
> then it should be possible to hook up runtime-pm on those machines
> pretty
> simply.
> 
> So there shouldn't really be a case we care about.
> 
> runtime PM for the Intel GPU isn't as important. We don't even want
> to
> turn the i915 fully off anymore.

Fair enough. And it's not that big a problem if we want to try and run
the compositor on the integrated card by default either.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add delay on DPCD reads

[Patchwork]

== Series Details ==

Series: drm/i915: Add delay on DPCD reads
URL   : https://patchwork.freedesktop.org/series/4462/
State : failure

== Summary ==

Series 4462v1 drm/i915: Add delay on DPCD reads
http://patchwork.freedesktop.org/api/1.0/series/4462/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (hsw-brixbox)
Test gem_exec_basic:
Subgroup gtt-render:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write-read-distinct:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (skl-nuci5)
Test gem_storedw_loop:
Subgroup basic-default:
pass   -> DMESG-WARN (skl-nuci5)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (skl-nuci5)
dmesg-warn -> PASS   (hsw-brixbox)
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (skl-nuci5)
Subgroup basic-rte:
pass   -> DMESG-WARN (hsw-brixbox)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:168  dwarn:0   dfail:0   fail:0   skip:26 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:179  dwarn:4   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:159  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:1   fail:0   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1601/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
e27d236d26c47ce33af053d63391704c3a6a1311 drm/i915: Add delay on DPCD reads

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

[Shubhangi Shrivastava]

This patch adds new fields that are not yet added in drm code
in child devices struct

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Durgadoss R 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/intel_bios.c | 15 ++-
 drivers/gpu/drm/i915/intel_bios.h | 16 +++-
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index bf62a19..a26d4b4 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1124,7 +1124,7 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
}
 
/* Parse the I_boost config for SKL and above */
-   if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+   if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level = 
translate_iboost(child->common.iboost_level & 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
  port_name(port), info->dp_boost_level);
@@ -1250,6 +1250,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
 */
memcpy(child_dev_ptr, p_child,
   min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+   /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+   if (bdb->version < 196) {
+   /* Set default values for bits added from v196 */
+   child_dev_ptr->common.iboost = 0;
+   child_dev_ptr->common.hpd_invert = 0;
+   }
+
+   if (bdb->version < 192)
+   child_dev_ptr->common.lspcon = 0;
}
return;
 }
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 350d4e0..2898323 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -250,9 +250,6 @@ struct old_child_dev_config {
  * versions. Notice that the meaning of the contents contents may still change,
  * but at least the offsets are consistent. */
 
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
 struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -261,8 +258,17 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
-   u8 obsolete;
-   u8 flags_1;
+   u8 dvo_cfg; /* See DEVICE_CFG_* above */
+   u8 efp_routed:1;
+   u8 lane_reversal:1;
+   u8 lspcon:1;
+   u8 iboost:1;
+   u8 hpd_invert:1;
+   u8 flag_reserved:3;
+   u8 hdmi_support:1;
+   u8 dp_support:1;
+   u8 tmds_support:1;
+   u8 support_reserved:5;
u8 not_common3[13];
u8 iboost_level;
 } __packed;
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

[Shubhangi Shrivastava]

This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.

v2: Separated VBT parsing from the rest of the logic. (Jani)

v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
and changed its logic to avoid looping twice. (Ville)

v4: Changed the logic to mask out the bits first and then
set them to remove need of temporary variable. (Ville)

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Durgadoss R 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_irq.c   | 20 
 drivers/gpu/drm/i915/i915_reg.h   |  8 
 drivers/gpu/drm/i915/intel_bios.c | 35 +++
 4 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1557d65..7a00966 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3334,6 +3334,8 @@ extern void intel_i2c_reset(struct drm_device *dev);
 /* intel_bios.c */
 int intel_bios_init(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
+enum port port);
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 53e5104..0a1e378 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3503,6 +3503,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
+
+   DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
+   hotplug, enabled_irqs);
+   hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
+
+   /*
+* For BXT invert bit has to be set based on AOB design
+* for HPD detection logic, update it based on VBT fields.
+*/
+
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
+   hotplug |= BXT_DDIA_HPD_INVERT;
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
+   hotplug |= BXT_DDIB_HPD_INVERT;
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
+   hotplug |= BXT_DDIC_HPD_INVERT;
+
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..f80b870 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6213,6 +6213,14 @@ enum skl_disp_power_wells {
 #define  PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
 #define  PORTB_HOTPLUG_LONG_DETECT (2 << 0)
 
+/* BXT hotplug control */
+#define BXT_DDIA_HPD_INVERT(1 << 27)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
+#define BXT_DDI_HPD_INVERT_MASK(BXT_DDIA_HPD_INVERT | \
+   BXT_DDIB_HPD_INVERT | \
+   BXT_DDIC_HPD_INVERT)
+
 #define PCH_PORT_HOTPLUG2  _MMIO(0xc403C)  /* SHOTPLUG_CTL2 SPT+ */
 #define  PORTE_HOTPLUG_ENABLE  (1 << 4)
 #define  PORTE_HOTPLUG_STATUS_MASK (3 << 0)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index a26d4b4..71d62f8 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -105,6 +105,41 @@ find_section(const void *_bdb, int section_id)
return NULL;
 }
 
+bool
+intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   int i;
+
+   if (WARN_ON_ONCE(!IS_BROXTON(dev_priv)))
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+
+   if (!dev_priv->vbt.child_dev[i].common.hpd_invert)
+   continue;
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (port == PORT_A)
+   return true;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (port == PORT_B)
+   return true;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (port == PORT_C)
+   return true;
+   default:
+   break;
+   }
+   }
+
+   return false;
+}
+
 sta

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Daniel Vetter]

On Tue, Mar 15, 2016 at 09:28:34AM +, Chris Wilson wrote:
> On Tue, Mar 15, 2016 at 10:34:02AM +0200, Joonas Lahtinen wrote:
> > On ma, 2016-03-14 at 16:59 +0200, Imre Deak wrote:
> > > +module_param_named(inject_load_failure, i915.inject_load_failure,
> > > uint, 0600);
> > 
> > This most definitely should be module_param_named_unsafe.
> > 
> > I think I'd also hope to see some kind of compile time option to enable
> > this. I don't think average user wants this by default.
> 
> That's not a bad idea. We can get rid of most of the dangerous params
> this way. On the other hand, we need to keep the debug/quirk params
> around so that we can test options in the wild (bug reporters).

Yeah, most of the _unsafe stuff is _really_ useful for quick bug triage.
Definitely don't want to disable those by default. Maybe an
i915.fry_my_kernel option? But even that is too confusing I think for
testers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 3/4] dim: run checkpatch on committed patches on apply

[Daniel Vetter]

On Tue, Mar 15, 2016 at 11:20:37AM +0200, Jani Nikula wrote:
> The input messages may have base64 encoding and whatnot, and
> checkpatch.pl can't cope with them. Just let 'git am' handle that. The
> upside is that checkpatch will now catch e.g. duplicate signed-off-bys.
> 
> This is a partial revert of
> 
> commit a913db697bb063d374229e5e806e514fa44985d0
> Author: Daniel Vetter 
> Date:   Wed Oct 14 18:32:49 2015 +0200
> 
> dim: Store patch in a temp file in apply-patch
> 
> although we'll still keep the temp file for other purposes, such as
> extracting the message-id.
> 
> While at it, drop the obsolete check for drm_i915_private_t. We'll now
> get a build fail for that.
> 
> Signed-off-by: Jani Nikula 
> ---
>  dim | 22 +++---
>  1 file changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/dim b/dim
> index a287c9126047..83cc5161c767 100755
> --- a/dim
> +++ b/dim
> @@ -421,8 +421,6 @@ function dim_apply_branch
>  
>   local message_id=$(message_get_id $file)
>  
> - shell_checkpatch "cat $file"
> -
>   local commiter_email=$(git config --get user.email)
>   local patch_from=$(grep "From:" "$file" | head -1)
>   local sob
> @@ -438,6 +436,8 @@ function dim_apply_branch
>   echo "No message-id found in the patch file."
>   fi
>  
> + checkpatch_commit HEAD
> +
>   eval $DRY $DIM_POST_APPLY_ACTION
>  }
>  
> @@ -686,25 +686,17 @@ function check_repo_clean
>  
>  }
>  
> -# $1 is the shell command to display the patch/commit
> -function shell_checkpatch
> -{
> - local cmd=$1
> -
> - $cmd | scripts/checkpatch.pl -q --strict - || true
> - if $cmd | grep '^\+.*\WBUG' > /dev/null; then
> - warn_or_fail "New BUG macro added"
> - fi
> - $cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New 
> drm_i915_private_t added" || true

This here seems now lost.
-Daniel

> -}
> -
>  # $1 is the git sha1 to check
>  function checkpatch_commit
>  {
>   local commit=$1
>  
>   git --no-pager log --oneline -1 $commit
> - shell_checkpatch "git show $commit --pretty=email"
> + git show $commit --pretty=email | scripts/checkpatch.pl -q --emacs 
> --strict - || true
> +
> + if git show $commit --pretty=email | grep '^\+.*\WBUG' > /dev/null; then
> + warn_or_fail "New BUG macro added"
> + fi
>  }
>  
>  dim_alias_check_patch=checkpatch
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 4/4] dim: unify repo clean checks to a single assert_repo_clean helper

[Daniel Vetter]

On Tue, Mar 15, 2016 at 11:20:38AM +0200, Jani Nikula wrote:
> Moreover, 'git diff-index --quiet HEAD' kept failing on me even though
> the repo was clean (merely running 'git status' always fixed this). So
> use the other one.
> 
> Signed-off-by: Jani Nikula 

Oh nice find, never figured out that one really. One nitpick on patch 3,
with that addressed on the entire series:

Reviewed-by: Daniel Vetter 
> ---
>  dim | 27 +++
>  1 file changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/dim b/dim
> index 83cc5161c767..9c8ae1098977 100755
> --- a/dim
> +++ b/dim
> @@ -411,11 +411,7 @@ function dim_apply_branch
>   local file=`mktemp`
>  
>   assert_branch $branch
> -
> - if [[ -n `git status --porcelain --untracked-files=no` ]] ; then
> - echo Repository not clean, aborting
> - exit 2
> - fi
> + assert_repo_clean
>  
>   cat > $file
>  
> @@ -676,16 +672,6 @@ function dim_conf
>   dim_checkout drm-intel-next-fixes "$@"
>  }
>  
> -function check_repo_clean
> -{
> - cd $1
> - if ! git diff-index --quiet HEAD ; then
> - echo $2 repo not clean, aborting
> - exit 1
> - fi
> -
> -}
> -
>  # $1 is the git sha1 to check
>  function checkpatch_commit
>  {
> @@ -986,7 +972,8 @@ function dim_update_branches
>   for remote in $DIM_DRM_INTEL_REMOTE $DIM_DRM_UPSTREAM_REMOTE origin; do
>   git fetch $remote
>   done
> - check_repo_clean $DIM_PREFIX/$DIM_DRM_INTEL Kernel
> +
> + assert_repo_clean
>  
>   for branch in $dim_branches ; do
>   dim_checkout $branch
> @@ -1110,6 +1097,14 @@ function assert_branch
>   fi
>  }
>  
> +function assert_repo_clean
> +{
> + if [[ -n "$(git status --porcelain --untracked-files=no)" ]]; then
> + echo "Repository not clean, aborting."
> + exit 1
> + fi
> +}
> +
>  # Note: used by bash completion
>  function dim_list_commands
>  {
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add delay on DPCD reads

[Daniel Vetter]

On Tue, Mar 15, 2016 at 01:38:58PM +0200, Mika Kahola wrote:
> Additional 50 ms delay is needed between DPCD reads on HP Bizlink 1326
> DP to VGA adapter. Having said that, I haven't noticed a need for
> additional delay between DPCD reads on other DP-VGA dongles.
> 
> While at it, let's replace mdelay() with usleep_range() routine.
> 
> Signed-off-by: Mika Kahola 

Please don't add more hacks to our own private copy of read_wake. This
stuff needs to move into drm core, since really we can't be the only ones
who try to plug in shit dongles ;-)

Would be great to test this with an amd DP card and the exact same
connector and see what happens. Then move these read_wake hacks into the
drm_dp_dpcd_read function. Lyude is also working on something like this,
but for DP MST hubs.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0e326e7..ff3883c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3125,9 +3125,11 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, 
> unsigned int offset,
>  
>   for (i = 0; i < 3; i++) {
>   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> - if (ret == size)
> + if (ret == size) {
> + usleep_range(5, 50100);
>   return ret;
> - msleep(1);
> + }
> + usleep_range(1000, 1100);
>   }
>  
>   return ret;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 3/4] dim: run checkpatch on committed patches on apply

[Jani Nikula]

On Tue, 15 Mar 2016, Daniel Vetter  wrote:

[snip]

>> While at it, drop the obsolete check for drm_i915_private_t. We'll now
>> get a build fail for that.

[snip]

>> -$cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New 
>> drm_i915_private_t added" || true
>
> This here seems now lost.

Yes. Who needs it now that we don't have the typedef anymore?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Ville Syrjälä]

On Tue, Mar 15, 2016 at 09:35:26AM +0100, Daniel Vetter wrote:
> On Mon, Mar 14, 2016 at 04:20:19PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 14, 2016 at 10:04:00AM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 11, 2016 at 09:09:12PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > > > > Thanks for the review Ville
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > > Kinda hard to see where everything gets used due to the way the 
> > > > > > patches
> > > > > > are split up.
> > > > > 
> > > > > Yes, it's far from great...
> > > > > 
> > > > > > At least the hotplug/mode change events are not needed. We only 
> > > > > > have the
> > > > > > two points where i915 should inform the audio driver about this 
> > > > > > stuff,
> > > > > > and those are the intel_audio_code_enable/disable(). For that we
> > > > > > already have the .pin_eld_notify() hook.
> > > > > >
> > > > > > The interrupt stuff should mostly vanish from i915 with the 
> > > > > > subdevice
> > > > > > approach. As in i915 would just call the interrupt handler of the 
> > > > > > audio
> > > > > > driver based on the LPE bits in IIR, and the audio driver can then 
> > > > > > do
> > > > > > whatever it wants based on its own status register.
> > > > > 
> > > > > Are you saying that the subdevice would provide a read/write 
> > > > > interface 
> > > > > for the audio driver to look at display registers, and the i915 
> > > > > driver 
> > > > > would only provide a notification interface (EDID and interrupts) to 
> > > > > the 
> > > > > audio driver?
> > > > 
> > > > The audio driver would simply ioremap the appropriate range of
> > > > registers itself.
> > > > 
> > > > > If yes, would there be two component framework links, one between 
> > > > > i915/audio driver and one between subdevice/audio driver.
> > > > 
> > > > Yeah sort of. i915 registers the platform device for the audio, the
> > > > audio driver can then bind to the device via the platform driver .probe
> > > > callback. It can then register with the audio component stuff at some
> > > > point to get the relevant notifications on the display state. When
> > > > i915 gets unloaded we remove the platform device, at which point the
> > > > audio driver's platform driver .remove() callback gets invoked and
> > > > it should unregister/cleanup everything.
> > > > 
> > > > I just tried to frob around with the VED code a bit, and got it to load
> > > > at least. It's not quite happy about reloading i915 while the ipvr
> > > > driver was loaded though. Not sure what's going on there, but I do
> > > > think this approach should work. So the VED patch could serve as a
> > > > decent enough model to follow.
> > > 
> > > platform devices registerd by modules are apparently inherently racy and
> > > in an unfixable way. At least I remember something like that from VED
> > > discussion.
> > > 
> > > In short you _must_ unload VED manually before unloading i915, or it all
> > > goes boom. If this is the only thing that went boom it's acceptable.
> > 
> > VED goes boom due drm_global_mutex deadlock at least if you load
> > i915 while ipvr is already loaded. I didn't check to hard if there
> > were any booms on pure unload so far.
> 
> Oh right another boom that happened, but can be avoided by dropping the
> ->load callback and directly calling drm_dev_alloc/register. Shouldn't be
> a problem with a non-drm driver though.
> 
> > Anyways, I was a bit worried about the races so I did a pair of 
> > small test modules to try out this model, and to me it looked to
> > work so far. I just unregistered the platform device from the parent
> > pci driver .remove() hook, and it got blocked until the platform
> > driver's .remove() hook was done.
> > 
> > In any case if this is broken, then I assume mfd must be broken. And
> > that thing is at least used quite extensively.
> 
> Hm, I don't remember the exact details, but iirc the problem was that the
> struct device is refcounted, but you can't add a module ref for the vtable
> is has (specifically the final release method) since that would result in
> a ref-loop. Usually it works, but if someone keeps the device alive
> (through sysfs or whatever) and you manage to unload everything before
> that last ref gets dropped it goes boom.
> 
> So "works", but not in a safe way.

I was worried that it's something like that. I guess I'll need to try
grab a ref on something in my test module and see how it fares.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Ville Syrjälä]

On Tue, Mar 15, 2016 at 09:39:48AM +0100, Daniel Vetter wrote:
> On Mon, Mar 14, 2016 at 12:27:51PM -0500, Pierre-Louis Bossart wrote:
> > On 3/14/16 10:30 AM, Ville Syrjälä wrote:
> > >On Mon, Mar 14, 2016 at 05:21:54PM +0200, Ville Syrjälä wrote:
> > >>On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:
> > >>>On 3/11/16 1:09 PM, Ville Syrjälä wrote:
> > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > >Thanks for the review Ville
> > >
> > >[snip]
> > >
> > >>Kinda hard to see where everything gets used due to the way the 
> > >>patches
> > >>are split up.
> > >
> > >Yes, it's far from great...
> > >
> > >>At least the hotplug/mode change events are not needed. We only have 
> > >>the
> > >>two points where i915 should inform the audio driver about this stuff,
> > >>and those are the intel_audio_code_enable/disable(). For that we
> > >>already have the .pin_eld_notify() hook.
> > >>
> > >>The interrupt stuff should mostly vanish from i915 with the subdevice
> > >>approach. As in i915 would just call the interrupt handler of the 
> > >>audio
> > >>driver based on the LPE bits in IIR, and the audio driver can then do
> > >>whatever it wants based on its own status register.
> > >
> > >Are you saying that the subdevice would provide a read/write interface
> > >for the audio driver to look at display registers, and the i915 driver
> > >would only provide a notification interface (EDID and interrupts) to 
> > >the
> > >audio driver?
> > 
> > The audio driver would simply ioremap the appropriate range of
> > registers itself.
> > 
> > >If yes, would there be two component framework links, one between
> > >i915/audio driver and one between subdevice/audio driver.
> > 
> > Yeah sort of. i915 registers the platform device for the audio, the
> > audio driver can then bind to the device via the platform driver .probe
> > callback. It can then register with the audio component stuff at some
> > point to get the relevant notifications on the display state. When
> > i915 gets unloaded we remove the platform device, at which point the
> > audio driver's platform driver .remove() callback gets invoked and
> > it should unregister/cleanup everything.
> > >>>
> > >>>we don't want to expose this interface when HDAudio is present and
> > >>>enabled so we would need to add a test for this.
> > >>>Also it looks like you want the creation of the platform device done in
> > >>>i915, we were thinking of doing this as part of the audio drivers but in
> > >>>the end this looks equivalent. In both cases we would end-up ignoring
> > >>>the HAD022A8 HID and not use acpi for this extension
> > >>
> > >>Well, if you have a device you can hang off from then i915 should need
> > >>to register it I suppose. Though that would make the interrupt
> > >>forwarding perhaps less nice. There's also the suspend/resume order
> > >>dependency to deal with if there's no parent/child relationship between
> > >>the devices.
> > >
> > >Oh and I suppose you'd end up ioremapping part of the pci dev2 mmio bar
> > >to get at the registers, which would look a bit funkly at least.
> > 
> > I understand the benefits of a parent/child device/subdevice model. What I
> > don't see is whether we need the component framework at all here?
> > It was used in the case of HDaudio since both i915 and HDaudio controllers
> > get probed at different times, here the HDMI interface is just a bunch of
> > registers/DMA from the same hardware so the whole master/client interface
> > exposed by the component framework to 'bind' independent drivers is a bit
> > overkill?
> 
> I haven't read the patches, but using component.c when you instead can
> model it with parent/child smells like abuse. Component.c is meant for
> when you have multiple devices all over the device tree that in aggregate
> constitute the overall logical driver. This doesn't seem to be the case
> here.

We still need the eld notify hooks so that i915 can inform the audio
driver about the state of the display. Whether that's best done via
the component stuff or something else I don't know.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Daniel Vetter]

On Tue, Mar 15, 2016 at 03:35:45PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 15, 2016 at 09:39:48AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 14, 2016 at 12:27:51PM -0500, Pierre-Louis Bossart wrote:
> > > On 3/14/16 10:30 AM, Ville Syrjälä wrote:
> > > >On Mon, Mar 14, 2016 at 05:21:54PM +0200, Ville Syrjälä wrote:
> > > >>On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:
> > > >>>On 3/11/16 1:09 PM, Ville Syrjälä wrote:
> > > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > > >Thanks for the review Ville
> > > >
> > > >[snip]
> > > >
> > > >>Kinda hard to see where everything gets used due to the way the 
> > > >>patches
> > > >>are split up.
> > > >
> > > >Yes, it's far from great...
> > > >
> > > >>At least the hotplug/mode change events are not needed. We only 
> > > >>have the
> > > >>two points where i915 should inform the audio driver about this 
> > > >>stuff,
> > > >>and those are the intel_audio_code_enable/disable(). For that we
> > > >>already have the .pin_eld_notify() hook.
> > > >>
> > > >>The interrupt stuff should mostly vanish from i915 with the 
> > > >>subdevice
> > > >>approach. As in i915 would just call the interrupt handler of the 
> > > >>audio
> > > >>driver based on the LPE bits in IIR, and the audio driver can then 
> > > >>do
> > > >>whatever it wants based on its own status register.
> > > >
> > > >Are you saying that the subdevice would provide a read/write 
> > > >interface
> > > >for the audio driver to look at display registers, and the i915 
> > > >driver
> > > >would only provide a notification interface (EDID and interrupts) to 
> > > >the
> > > >audio driver?
> > > 
> > > The audio driver would simply ioremap the appropriate range of
> > > registers itself.
> > > 
> > > >If yes, would there be two component framework links, one between
> > > >i915/audio driver and one between subdevice/audio driver.
> > > 
> > > Yeah sort of. i915 registers the platform device for the audio, the
> > > audio driver can then bind to the device via the platform driver 
> > > .probe
> > > callback. It can then register with the audio component stuff at some
> > > point to get the relevant notifications on the display state. When
> > > i915 gets unloaded we remove the platform device, at which point the
> > > audio driver's platform driver .remove() callback gets invoked and
> > > it should unregister/cleanup everything.
> > > >>>
> > > >>>we don't want to expose this interface when HDAudio is present and
> > > >>>enabled so we would need to add a test for this.
> > > >>>Also it looks like you want the creation of the platform device done in
> > > >>>i915, we were thinking of doing this as part of the audio drivers but 
> > > >>>in
> > > >>>the end this looks equivalent. In both cases we would end-up ignoring
> > > >>>the HAD022A8 HID and not use acpi for this extension
> > > >>
> > > >>Well, if you have a device you can hang off from then i915 should need
> > > >>to register it I suppose. Though that would make the interrupt
> > > >>forwarding perhaps less nice. There's also the suspend/resume order
> > > >>dependency to deal with if there's no parent/child relationship between
> > > >>the devices.
> > > >
> > > >Oh and I suppose you'd end up ioremapping part of the pci dev2 mmio bar
> > > >to get at the registers, which would look a bit funkly at least.
> > > 
> > > I understand the benefits of a parent/child device/subdevice model. What I
> > > don't see is whether we need the component framework at all here?
> > > It was used in the case of HDaudio since both i915 and HDaudio controllers
> > > get probed at different times, here the HDMI interface is just a bunch of
> > > registers/DMA from the same hardware so the whole master/client interface
> > > exposed by the component framework to 'bind' independent drivers is a bit
> > > overkill?
> > 
> > I haven't read the patches, but using component.c when you instead can
> > model it with parent/child smells like abuse. Component.c is meant for
> > when you have multiple devices all over the device tree that in aggregate
> > constitute the overall logical driver. This doesn't seem to be the case
> > here.
> 
> We still need the eld notify hooks so that i915 can inform the audio
> driver about the state of the display. Whether that's best done via
> the component stuff or something else I don't know.

Hm right. I guess we could stuff it into the platform data stuff maybe
instead, so the driver could get at the i915/snd interface directly?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 3/4] dim: run checkpatch on committed patches on apply

[Daniel Vetter]

On Tue, Mar 15, 2016 at 03:29:01PM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2016, Daniel Vetter  wrote:
> 
> [snip]
> 
> >> While at it, drop the obsolete check for drm_i915_private_t. We'll now
> >> get a build fail for that.
> 
> [snip]
> 
> >> -  $cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New 
> >> drm_i915_private_t added" || true
> >
> > This here seems now lost.
> 
> Yes. Who needs it now that we don't have the typedef anymore?

Hah, silly me, didn't realized we managed to nuke it ;-) r-b on everything
as-is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Imre Deak]

On ti, 2016-03-15 at 09:56 +0100, Daniel Vetter wrote:
> On Mon, Mar 14, 2016 at 04:59:20PM +0200, Imre Deak wrote:
> > Add support for forcing an error at selected places in the driver.
> > As an
> > example add 4 options to fail during driver loading.
> > 
> > Requested by Chris.
> > 
> > v2:
> > - Add fault point for modeset initialization
> > - Print debug message when injecting an error
> > v3:
> > - Rename inject_fault to inject_load_failure, rename the related
> > macros
> >   and helper accordingly (Chris)
> > 
> > CC: Chris Wilson 
> > Signed-off-by: Imre Deak 
> > ---
> > 
> > [This depends on
> >  https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597
> > .html]
> > 
> >  drivers/gpu/drm/i915/i915_dma.c| 12 
> >  drivers/gpu/drm/i915/i915_drv.h| 16 
> >  drivers/gpu/drm/i915/i915_params.c |  5 +
> >  drivers/gpu/drm/i915/i915_params.h |  1 +
> >  4 files changed, 34 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index a5121cd..7490307 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct
> > drm_device *dev)
> >     struct drm_i915_private *dev_priv = dev->dev_private;
> >     int ret;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_MODESET))
> > +   return -ENODEV;
> > +
> >     ret = intel_bios_init(dev_priv);
> >     if (ret)
> >     DRM_INFO("failed to find VBIOS tables\n");
> > @@ -950,6 +953,9 @@ static int i915_driver_init_early(struct
> > drm_i915_private *dev_priv,
> >     struct intel_device_info *device_info;
> >     int ret = 0;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_EARLY))
> > +   return -ENODEV;
> > +
> >     dev_priv->dev = dev;
> >  
> >     /* Setup the write-once "constant" device info */
> > @@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct
> > drm_i915_private *dev_priv)
> >     struct drm_device *dev = dev_priv->dev;
> >     int ret;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_MMIO))
> > +   return -ENODEV;
> > +
> >     if (i915_get_bridge_dev(dev))
> >     return -EIO;
> 
> Ok, thought a bit more about this, and if we really want to check all the
> load failure paths then this will become extremely verbose. Since we'd
> need to have a bitflag for every return -EFAIL.

I'm not sure if you want to check all failure paths, I think for that
the existing failslab etc. mechanisms are better suited. This new
option would be used at relatively few well defined places. The option
is a mask since Chris wanted the possibility to mix failures (which
makes sense when injecting a non-fatal failure somewhere). If he
doesn't insist on that possibility I can convert the mask option to a
counter based one identifying a single failure spot instead as you
suggest. Chris?

> So maybe another look at
> lib/fault-inject.c is warranted, plus then some macro magic that we could
> to wrap _all_ the checks in our load code like this:
> 
>   if (i915_load_failure(i915_get_bridge_dev(dev)))
>   return -EIO;

The above will not work when we want to propagate the error and I
haven't found a nice way to do that with such a helper taking the
function call as argument. I could move the check to the call site
instead of having it inside the called function, if that's what you'd
prefer:

if ((ret = i915_load_failure(...)) < 0 ||
(ret = i915_driver_init_mmio(...)) < 0)
return ret;

Although I'm not sure if this makes things clearer. Other suggestions are
welcome.

> i915_load_failure ofc needs to fail if it's argument is false, but it
> could also increment a counter every time it's called and then use that
> counter to inquire the fault injection framework with
> should_fail(i915_load_failures, counter). Abusing a counter for the size
> would allow us to easily restrict fault injection to a certain range of
> faults. We could also expose the final value of that counter in debugfs,
> so that the igt can tune itself.

Yes, I could do this provided Chris doesn't oppose the idea of the
counter based approach.

> Anyway, this is kinda a big plan, but the part I think we should ponder is
> how to make the fault injection less noise and intrusive. A macro to wrap
> existing checks seems like a good idea.

I can switch to using a counter instead of the mask and if there is a
good suggestion about the macro I can use that instead.

--Imre

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Imre Deak]

On ti, 2016-03-15 at 10:34 +0200, Joonas Lahtinen wrote:
> On ma, 2016-03-14 at 16:59 +0200, Imre Deak wrote:
> > Add support for forcing an error at selected places in the driver.
> > As
> > an
> > example add 4 options to fail during driver loading.
> > 
> > Requested by Chris.
> > 
> > v2:
> > - Add fault point for modeset initialization
> > - Print debug message when injecting an error
> > v3:
> > - Rename inject_fault to inject_load_failure, rename the related
> > macros
> >   and helper accordingly (Chris)
> > 
> > CC: Chris Wilson 
> > Signed-off-by: Imre Deak 
> > ---
> > 
> > [This depends on
> >  https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597
> > .h
> > tml]
> > 
> >  drivers/gpu/drm/i915/i915_dma.c| 12 
> >  drivers/gpu/drm/i915/i915_drv.h| 16 
> >  drivers/gpu/drm/i915/i915_params.c |  5 +
> >  drivers/gpu/drm/i915/i915_params.h |  1 +
> >  4 files changed, 34 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index a5121cd..7490307 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct
> > drm_device *dev)
> >     struct drm_i915_private *dev_priv = dev->dev_private;
> >     int ret;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_MODESET))
> > +   return -ENODEV;
> > +
> >     ret = intel_bios_init(dev_priv);
> >     if (ret)
> >     DRM_INFO("failed to find VBIOS tables\n");
> > @@ -950,6 +953,9 @@ static int i915_driver_init_early(struct
> > drm_i915_private *dev_priv,
> >     struct intel_device_info *device_info;
> >     int ret = 0;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_EARLY))
> > +   return -ENODEV;
> > +
> >     dev_priv->dev = dev;
> >  
> >     /* Setup the write-once "constant" device info */
> > @@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct
> > drm_i915_private *dev_priv)
> >     struct drm_device *dev = dev_priv->dev;
> >     int ret;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_MMIO))
> > +   return -ENODEV;
> > +
> >     if (i915_get_bridge_dev(dev))
> >     return -EIO;
> >  
> > @@ -1107,6 +1116,9 @@ static int i915_driver_init_hw(struct
> > drm_i915_private *dev_priv)
> >     uint32_t aperture_size;
> >     int ret;
> >  
> > +   if (i915_inject_load_failure(I915_FAIL_INIT_HW))
> > +   return -ENODEV;
> > +
> >     intel_device_info_runtime_init(dev);
> >  
> >     ret = i915_gem_gtt_init(dev);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 25274e1..e2d21d5 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -98,6 +98,22 @@
> >  #define I915_STATE_WARN_ON(x)  
> > \
> >     I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
> >  
> > +#define I915_FAIL_INIT_EARLY   BIT(0)
> > +#define I915_FAIL_INIT_MMIOBIT(1)
> > +#define I915_FAIL_INIT_HW  BIT(2)
> > +#define I915_FAIL_INIT_MODESET BIT(3)
> > +
> > +static inline bool i915_inject_load_failure(unsigned int
> > fail_mask)
> > +{
> > +   if (i915.inject_load_failure & fail_mask) {
> > +   DRM_DEBUG_DRIVER("Injecting failure %08x\n",
> > fail_mask);
> > +
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static inline const char *yesno(bool v)
> >  {
> >     return v ? "yes" : "no";
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 278c9c4..4faeeed 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
> >     .edp_vswing = 0,
> >     .enable_guc_submission = false,
> >     .guc_log_level = -1,
> > +   .inject_load_failure = 0,
> >  };
> >  
> >  module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable
> > GuC submission (default:false)")
> >  module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
> >  MODULE_PARM_DESC(guc_log_level,
> >     "GuC firmware logging level (-1:disabled (default), 0-
> > 3:enabled)");
> > +
> > +module_param_named(inject_load_failure, i915.inject_load_failure,
> > uint, 0600);
> 
> This most definitely should be module_param_named_unsafe.

Ok, will change that.

> 
> I think I'd also hope to see some kind of compile time option to
> enable
> this. I don't think average user wants this by default.

I agree with Chris and Daniel, so I'll leave this out for now. It can
be added later in any case. 

> 
> > +MODULE_PARM_DESC(inject_load_failure,
> > +   "Force an error at selected points (0:disabled,
> > 0x1:INIT_EARLY, 0x2:INIT_MMIO, 0x4:INIT_HW, 0x8:INIT_MODESET)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915

Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

[Chris Wilson]

On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote:
> I'm not sure if you want to check all failure paths, I think for that
> the existing failslab etc. mechanisms are better suited. This new
> option would be used at relatively few well defined places. The option
> is a mask since Chris wanted the possibility to mix failures (which
> makes sense when injecting a non-fatal failure somewhere). If he
> doesn't insist on that possibility I can convert the mask option to a
> counter based one identifying a single failure spot instead as you
> suggest. Chris?

We can extend the counter mechanism by having multiple counters behind
i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1)
so extensibility for more testing seems fine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Update VBT fields for child devices

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Update VBT fields for child devices
URL   : https://patchwork.freedesktop.org/series/4470/
State : warning

== Summary ==

Series 4470v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4470/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c:
fail   -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-nuci5)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (snb-dellxps)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:168  dwarn:0   dfail:0   fail:0   skip:26 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1602/

fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 
2016y-03m-15d-13h-10m-41s UTC integration manifest
5b38fbbcf8f3c34cbe7e69dba131ede276dcf3ce drm/i915: Set invert bit for hpd based 
on VBT
f126ba1a17fd78ac142bd3f2505b0f7acf895829 drm/i915: Update VBT fields for child 
devices

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/16] drm/i915: Throw out BUGs from DPLL/PCH functions

[ville . syrjala]

From: Ville Syrjälä 

These BUGs don't serve any purpose IMO. Throw them out.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ce55f0b683c6..22930f05457c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1661,9 +1661,6 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
 
assert_pipe_disabled(dev_priv, crtc->pipe);
 
-   /* No really, not for ILK+ */
-   BUG_ON(INTEL_INFO(dev)->gen >= 5);
-
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev) && !IS_I830(dev))
assert_panel_unlocked(dev_priv, crtc->pipe);
@@ -1839,9 +1836,6 @@ static void ironlake_enable_pch_transcoder(struct 
drm_i915_private *dev_priv,
i915_reg_t reg;
uint32_t val, pipeconf_val;
 
-   /* PCH only available on ILK+ */
-   BUG_ON(!HAS_PCH_SPLIT(dev));
-
/* Make sure PCH DPLL is enabled */
assert_shared_dpll_enabled(dev_priv, intel_crtc->config->shared_dpll);
 
@@ -1895,9 +1889,6 @@ static void lpt_enable_pch_transcoder(struct 
drm_i915_private *dev_priv,
 {
u32 val, pipeconf_val;
 
-   /* PCH only available on ILK+ */
-   BUG_ON(!HAS_PCH_SPLIT(dev_priv->dev));
-
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Peter Antoine]

Chris,

Testcases are underway, validation are working on them.

Peter.

On Tue, 15 Mar 2016, Chris Wilson wrote:


On Mon, Mar 14, 2016 at 03:11:02PM +, Peter Antoine wrote:

Allow for the MOCS to be programmed for all engines.
Currently we program the MOCS when the first render batch
goes through. This works on most platforms but fails on
platforms that do not run a render batch early,
i.e. headless servers. The patch now programs all initialised engines
on init and the RCS is programmed again within the initial batch. This
is done for predictable consistency with regards to the hardware
context.

Hardware context loading sets the values of the MOCS for RCS
and L3CC. Programming them from within the batch makes sure that
the render context is valid, no matter what the previous state of
the saved-context was.

v2: posted correct version to the mailing list.
v3: moved programming to within engine->init_hw() (Chris Wilson)
v4: code formatting and white-space changes. (Chris Wilson)

Signed-off-by: Peter Antoine 


So testcase?

Execute a bunch of MI_STORE_REGISTER_MEM on the various rings in a fresh
context each time and confirm the ABI for the first N locations.

Repeat across suspend/resume (i.e. make sure the context image maintain
the register state). Then verify that freshly constructed contexts also
have the correct settings after resume.
-Chris




--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/16] drm/i915: Make {vlv, chv}_{disable, update}_pll() more similar

[ville . syrjala]

From: Ville Syrjälä 

The VLV and CHV DPLL disable and update are almost identical in
how the DPLL/DPLL_MD registers need to be set up. But the code
looks more different than it really is. Try to bring them into
line.

v2: s/chv_update_pll/chv_compute_dpll/

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 63 ++--
 1 file changed, 25 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 22930f05457c..414ed5007e60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1759,16 +1759,13 @@ static void vlv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
/* Make sure the pipe isn't still relying on us */
assert_pipe_disabled(dev_priv, pipe);
 
-   /*
-* Leave integrated clock source and reference clock enabled for pipe B.
-* The latter is needed for VGA hotplug / manual detection.
-*/
-   val = DPLL_VGA_MODE_DIS;
-   if (pipe == PIPE_B)
-   val = DPLL_INTEGRATED_CRI_CLK_VLV | DPLL_REF_CLK_ENABLE_VLV;
+   val = DPLL_INTEGRATED_REF_CLK_VLV |
+   DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
+   if (pipe != PIPE_A)
+   val |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
-
 }
 
 static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
@@ -1779,11 +1776,11 @@ static void chv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
/* Make sure the pipe isn't still relying on us */
assert_pipe_disabled(dev_priv, pipe);
 
-   /* Set PLL en = 0 */
val = DPLL_SSC_REF_CLK_CHV |
DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
if (pipe != PIPE_A)
val |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
 
@@ -7240,24 +7237,27 @@ void intel_dp_set_m_n(struct intel_crtc *crtc, enum 
link_m_n_set m_n)
 static void vlv_compute_dpll(struct intel_crtc *crtc,
 struct intel_crtc_state *pipe_config)
 {
-   u32 dpll, dpll_md;
+   pipe_config->dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV |
+   DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
+   DPLL_VCO_ENABLE | DPLL_EXT_BUFFER_ENABLE_VLV;
+   if (crtc->pipe != PIPE_A)
+   pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
 
-   /*
-* Enable DPIO clock input. We should never disable the reference
-* clock for pipe B, since VGA hotplug / manual detection depends
-* on it.
-*/
-   dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REF_CLK_ENABLE_VLV |
-   DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_REF_CLK_VLV;
-   /* We should never disable this, set it here for state tracking */
-   if (crtc->pipe == PIPE_B)
-   dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
-   dpll |= DPLL_VCO_ENABLE;
-   pipe_config->dpll_hw_state.dpll = dpll;
+   pipe_config->dpll_hw_state.dpll_md =
+   (pipe_config->pixel_multiplier - 1) << 
DPLL_MD_UDI_MULTIPLIER_SHIFT;
+}
+
+static void chv_compute_dpll(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config)
+{
+   pipe_config->dpll_hw_state.dpll = DPLL_SSC_REF_CLK_CHV |
+   DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
+   DPLL_VCO_ENABLE;
+   if (crtc->pipe != PIPE_A)
+   pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
 
-   dpll_md = (pipe_config->pixel_multiplier - 1)
-   << DPLL_MD_UDI_MULTIPLIER_SHIFT;
-   pipe_config->dpll_hw_state.dpll_md = dpll_md;
+   pipe_config->dpll_hw_state.dpll_md =
+   (pipe_config->pixel_multiplier - 1) << 
DPLL_MD_UDI_MULTIPLIER_SHIFT;
 }
 
 static void vlv_prepare_pll(struct intel_crtc *crtc,
@@ -7351,19 +7351,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
mutex_unlock(&dev_priv->sb_lock);
 }
 
-static void chv_compute_dpll(struct intel_crtc *crtc,
-struct intel_crtc_state *pipe_config)
-{
-   pipe_config->dpll_hw_state.dpll = DPLL_SSC_REF_CLK_CHV |
-   DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
-   DPLL_VCO_ENABLE;
-   if (crtc->pipe != PIPE_A)
-   pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
-
-   pipe_config->dpll_hw_state.dpll_md =
-   (pipe_config->pixel_multiplier - 1) << 
DPLL_MD_UDI_MULTIPLIER_SHIFT;
-}
-
 static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config)
 {
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/16] drm/i915: Change lfsr_converts[] to u16

[ville . syrjala]

From: Ville Syrjälä 

All the values in the DSI PLL LFSR seed table fit into 9bits, so change
the type to u16 from u32 to save a bit of space.

 drivers/gpu/drm/i915/i915.ko:
-.rodata90824
+.rodata90760

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 2451c84949bd..916cc92c1400 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -56,7 +56,7 @@ struct dsi_mnp {
u32 dsi_pll_div;
 };
 
-static const u32 lfsr_converts[] = {
+static const u16 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213,   /* 71 - 80 */
106, 53, 282, 397, 454, 227, 113, 56, 284, 142, /* 81 - 90 */
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/16] drm/i915: Add a local pipe variable to vlv_enable_pll()

[ville . syrjala]

From: Ville Syrjälä 

Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local
pipe variable. Also makes it look more like the corresponding CHV code.

While at is change the CHV code to enum pipe from int,

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 18158b0324ed..638ce9de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1572,24 +1572,25 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   i915_reg_t reg = DPLL(crtc->pipe);
+   enum pipe pipe = crtc->pipe;
+   i915_reg_t reg = DPLL(pipe);
u32 dpll = pipe_config->dpll_hw_state.dpll;
 
-   assert_pipe_disabled(dev_priv, crtc->pipe);
+   assert_pipe_disabled(dev_priv, pipe);
 
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev_priv->dev))
-   assert_panel_unlocked(dev_priv, crtc->pipe);
+   assert_panel_unlocked(dev_priv, pipe);
 
I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150);
 
if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
-   DRM_ERROR("DPLL %d failed to lock\n", crtc->pipe);
+   DRM_ERROR("DPLL %d failed to lock\n", pipe);
 
-   I915_WRITE(DPLL_MD(crtc->pipe), pipe_config->dpll_hw_state.dpll_md);
-   POSTING_READ(DPLL_MD(crtc->pipe));
+   I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
+   POSTING_READ(DPLL_MD(pipe));
 
/* We do this three times for luck */
I915_WRITE(reg, dpll);
@@ -1608,11 +1609,11 @@ static void chv_enable_pll(struct intel_crtc *crtc,
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int pipe = crtc->pipe;
+   enum pipe pipe = crtc->pipe;
enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 tmp;
 
-   assert_pipe_disabled(dev_priv, crtc->pipe);
+   assert_pipe_disabled(dev_priv, pipe);
 
mutex_lock(&dev_priv->sb_lock);
 
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/16] drm/i915: Fix CHV DSI PLL refclk during state readout

[ville . syrjala]

From: Ville Syrjälä 

Use the proper refclock frequency (100MHz) when reading out the
current DSI clock on CHV.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index d35c8dc28fb6..99236baa946b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -255,7 +255,7 @@ static u32 vlv_dsi_get_pclk(struct intel_encoder *encoder, 
int pipe_bpp,
u32 dsi_clock, pclk;
u32 pll_ctl, pll_div;
u32 m = 0, p = 0, n;
-   int refclk = 25000;
+   int refclk = IS_CHERRYVIEW(dev_priv) ? 10 : 25000;
int i;
 
DRM_DEBUG_KMS("\n");
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/16] drm/i915: Don't read out port_clock on CHV when DPLL is disabled

[ville . syrjala]

From: Ville Syrjälä 

Check whether the DPLL is even enabled before readoing out the dividers
and trying to derive port_clock on CHV. We already did this on VLV.

Also remove the comment "MIPI" comment from the VLV code since we call
this function whenever the pipe is enabled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 98aae3914e9e..3e6b5fb140ad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7969,8 +7969,8 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
u32 mdiv;
int refclk = 10;
 
-   /* In case of MIPI DPLL will not even be used */
-   if (!(pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE))
+   /* In case of DSI, DPLL will not be used */
+   if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
return;
 
mutex_lock(&dev_priv->sb_lock);
@@ -8066,6 +8066,10 @@ static void chv_crtc_clock_get(struct intel_crtc *crtc,
u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
int refclk = 10;
 
+   /* In case of DSI, DPLL will not be used */
+   if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
+   return;
+
mutex_lock(&dev_priv->sb_lock);
cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/16] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV

[ville . syrjala]

From: Ville Syrjälä 

Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
the DPLL isn't used to provide the clock we still need the refclock, and
it appears that the pixel repeat factor also has an effect on DSI
output. So set up eveyrhing in DPLL and DPLL_MD as we would do for
DP/HDMI/VGA, but don't actually enable the DPLL or configure the
dividers via DPIO.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 117 ++-
 drivers/gpu/drm/i915/intel_dsi.c |  28 +++--
 2 files changed, 80 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c85b77c1188d..98aae3914e9e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1567,45 +1567,47 @@ static void assert_pch_ports_disabled(struct 
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
 }
 
+static void _vlv_enable_pll(struct intel_crtc *crtc,
+   const struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   I915_WRITE(DPLL(pipe), pipe_config->dpll_hw_state.dpll);
+   POSTING_READ(DPLL(pipe));
+   udelay(150);
+
+   if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
+   DRM_ERROR("DPLL %d failed to lock\n", pipe);
+}
+
 static void vlv_enable_pll(struct intel_crtc *crtc,
   const struct intel_crtc_state *pipe_config)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   i915_reg_t reg = DPLL(pipe);
-   u32 dpll = pipe_config->dpll_hw_state.dpll;
 
assert_pipe_disabled(dev_priv, pipe);
 
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
 
-   I915_WRITE(reg, dpll);
-   POSTING_READ(reg);
-   udelay(150);
-
-   if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
-   DRM_ERROR("DPLL %d failed to lock\n", pipe);
+   if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+   _vlv_enable_pll(crtc, pipe_config);
 
I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
POSTING_READ(DPLL_MD(pipe));
 }
 
-static void chv_enable_pll(struct intel_crtc *crtc,
-  const struct intel_crtc_state *pipe_config)
+
+static void _chv_enable_pll(struct intel_crtc *crtc,
+   const struct intel_crtc_state *pipe_config)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 tmp;
 
-   assert_pipe_disabled(dev_priv, pipe);
-
-   /* PLL is protected by panel, make sure we can write it */
-   assert_panel_unlocked(dev_priv, pipe);
-
mutex_lock(&dev_priv->sb_lock);
 
/* Enable back the 10bit clock to display controller */
@@ -1626,6 +1628,21 @@ static void chv_enable_pll(struct intel_crtc *crtc,
/* Check PLL is locked */
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
+}
+
+static void chv_enable_pll(struct intel_crtc *crtc,
+  const struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   assert_pipe_disabled(dev_priv, pipe);
+
+   /* PLL is protected by panel, make sure we can write it */
+   assert_panel_unlocked(dev_priv, pipe);
+
+   if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+   _chv_enable_pll(crtc, pipe_config);
 
if (pipe != PIPE_A) {
/*
@@ -6125,14 +6142,12 @@ static void valleyview_crtc_enable(struct drm_crtc 
*crtc)
if (encoder->pre_pll_enable)
encoder->pre_pll_enable(encoder);
 
-   if (!intel_crtc->config->has_dsi_encoder) {
-   if (IS_CHERRYVIEW(dev)) {
-   chv_prepare_pll(intel_crtc, intel_crtc->config);
-   chv_enable_pll(intel_crtc, intel_crtc->config);
-   } else {
-   vlv_prepare_pll(intel_crtc, intel_crtc->config);
-   vlv_enable_pll(intel_crtc, intel_crtc->config);
-   }
+   if (IS_CHERRYVIEW(dev)) {
+   chv_prepare_pll(intel_crtc, intel_crtc->config);
+   chv_enable_pll(intel_crtc, intel_crtc->config);
+   } else {
+

[Intel-gfx] [PATCH 06/16] drm/i915: Remove the "three times for luck" trick from vlv_enable_pll()

[ville . syrjala]

From: Ville Syrjälä 

VLV DPLL is somewhat sane and doesn't run on luck.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d3332a33f8a7..c85b77c1188d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1590,17 +1590,6 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
 
I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
POSTING_READ(DPLL_MD(pipe));
-
-   /* We do this three times for luck */
-   I915_WRITE(reg, dpll);
-   POSTING_READ(reg);
-   udelay(150); /* wait for warmup */
-   I915_WRITE(reg, dpll);
-   POSTING_READ(reg);
-   udelay(150); /* wait for warmup */
-   I915_WRITE(reg, dpll);
-   POSTING_READ(reg);
-   udelay(150); /* wait for warmup */
 }
 
 static void chv_enable_pll(struct intel_crtc *crtc,
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 16/16] drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

[ville . syrjala]

From: Ville Syrjälä 

We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI,
and just trying to frob the display timings to include borders results
in a corrupted picture. So reject the 'Center' scaling mode on GMCH
platforms for eDP and DSI.

TODO: Should really filter out the unsupported modes from the prop,
but that would be fairly invasive since the prop is now created and
stored by drm core. So leave it for a rainy day.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c  | 5 +
 drivers/gpu/drm/i915/intel_dsi.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e326e776e8f..f268bda6d55e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4754,6 +4754,11 @@ intel_dp_set_property(struct drm_connector *connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+   if (HAS_GMCH_DISPLAY(dev_priv) &&
+   val == DRM_MODE_SCALE_CENTER) {
+   DRM_DEBUG_KMS("centering not supported\n");
+   return -EINVAL;
+   }
 
if (intel_connector->panel.fitting_mode == val) {
/* the eDP scaling property is not changed */
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3823425a3e36..0ffa125a83e7 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1082,6 +1082,11 @@ static int intel_dsi_set_property(struct drm_connector 
*connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+   if (HAS_GMCH_DISPLAY(dev) &&
+   val == DRM_MODE_SCALE_CENTER) {
+   DRM_DEBUG_KMS("centering not supported\n");
+   return -EINVAL;
+   }
 
if (intel_connector->panel.fitting_mode == val)
return 0;
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 15/16] drm/i915: Hook up pfit for DSI

[ville . syrjala]

From: Ville Syrjälä 

Add the scaling mode property to DSI connectors, handle changes in the
property value, and compute the panel fitter state during
.compute_config().

v2: Handle BXT as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dsi.c | 74 +---
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1b4e83df4560..3823425a3e36 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -268,10 +268,12 @@ static inline bool is_cmd_mode(struct intel_dsi 
*intel_dsi)
 static bool intel_dsi_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
   base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
-   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
+   const struct drm_display_mode *fixed_mode = 
intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = 
&pipe_config->base.adjusted_mode;
int ret;
 
@@ -279,9 +281,17 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->has_dsi_encoder = true;
 
-   if (fixed_mode)
+   if (fixed_mode) {
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
 
+   if (HAS_GMCH_DISPLAY(dev_priv))
+   intel_gmch_panel_fitting(crtc, pipe_config,
+
intel_connector->panel.fitting_mode);
+   else
+   intel_pch_panel_fitting(crtc, pipe_config,
+   
intel_connector->panel.fitting_mode);
+   }
+
/* DSI uses short packets for sync events, so clear mode flags for DSI 
*/
adjusted_mode->flags = 0;
 
@@ -731,7 +741,7 @@ intel_dsi_mode_valid(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
-   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   const struct drm_display_mode *fixed_mode = 
intel_connector->panel.fixed_mode;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
DRM_DEBUG_KMS("\n");
@@ -1054,6 +1064,43 @@ static int intel_dsi_get_modes(struct drm_connector 
*connector)
return 1;
 }
 
+static int intel_dsi_set_property(struct drm_connector *connector,
+ struct drm_property *property,
+ uint64_t val)
+{
+   struct drm_device *dev = connector->dev;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct drm_crtc *crtc;
+   int ret;
+
+   ret = drm_object_property_set_value(&connector->base, property, val);
+   if (ret)
+   return ret;
+
+   if (property == dev->mode_config.scaling_mode_property) {
+   if (val == DRM_MODE_SCALE_NONE) {
+   DRM_DEBUG_KMS("no scaling not supported\n");
+   return -EINVAL;
+   }
+
+   if (intel_connector->panel.fitting_mode == val)
+   return 0;
+
+   intel_connector->panel.fitting_mode = val;
+   }
+
+   crtc = intel_attached_encoder(connector)->base.crtc;
+   if (crtc && crtc->state->enable) {
+   /*
+* If the CRTC is enabled, the display will be changed
+* according to the new panel fitting mode.
+*/
+   intel_crtc_restore_mode(crtc);
+   }
+
+   return 0;
+}
+
 static void intel_dsi_connector_destroy(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -1096,11 +1143,25 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.detect = intel_dsi_detect,
.destroy = intel_dsi_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
+   .set_property = intel_dsi_set_property,
.atomic_get_property = intel_connector_atomic_get_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 };
 
+static void intel_dsi_add_properties(struct intel_connector *connector)
+{
+   struct drm_device *dev = connector->base.dev;
+
+   if (connector->panel.fixed_mode) {
+   drm_mode_create_scaling_mode_property(dev);
+   drm_object_attach_property(&conn

[Intel-gfx] [PATCH 00/16] drm/i915: DSI and DPLL stuff for VLV/CHV mostly

[ville . syrjala]

From: Ville Syrjälä 

Here's a pile of pending VLV/CHV DSI and DPLL patches I had lying around.
Most of these have been posted before. Would be nice to finally get them
in.

I've tried to rebase things to account for BXT as well, but obviously
that part is not tested. I have tested this on a BYT FFRD8 which has
a DSI panel.

Apart from the VLV/CHV specific stuff, the main thing here is moving
the DSI PLL calculations to the .compute_config() phase. Another neat
thing is hooking up the panel fitter for DSI.

Ville Syrjälä (16):
  drm/i915: Throw out BUGs from DPLL/PCH functions
  drm/i915: Make {vlv,chv}_{disable,update}_pll() more similar
  drm/i915: Implement WaPixelRepeatModeFixForC0:chv
  drm/i915: Add a local pipe variable to vlv_enable_pll()
  drm/i915: assert_panel_unlocked() in chv_enable_pll()
  drm/i915: Remove the "three times for luck" trick from
vlv_enable_pll()
  drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV
  drm/i915: Don't read out port_clock on CHV when DPLL is disabled
  drm/i915: Change lfsr_converts[] to u16
  drm/i915: Power down the DSI PLL before reconfiguring it
  drm/i915: Compute DSI PLL parameters during .compute_config()
  drm/i915: Fix CHV DSI PLL refclk during state readout
  drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()
  drm/i915: Dump pfit PGM_RATIOS as hex
  drm/i915: Hook up pfit for DSI
  drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

 drivers/gpu/drm/i915/i915_drv.h  |   7 +
 drivers/gpu/drm/i915/i915_reg.h  |   4 +
 drivers/gpu/drm/i915/intel_display.c | 244 +++
 drivers/gpu/drm/i915/intel_dp.c  |   5 +
 drivers/gpu/drm/i915/intel_drv.h |   5 +
 drivers/gpu/drm/i915/intel_dsi.c | 120 +
 drivers/gpu/drm/i915/intel_dsi.h |  14 +-
 drivers/gpu/drm/i915/intel_dsi_pll.c | 155 +++---
 8 files changed, 332 insertions(+), 222 deletions(-)

-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/16] drm/i915: Implement WaPixelRepeatModeFixForC0:chv

[ville . syrjala]

From: Ville Syrjälä 

DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.

Fortunately the pixel repeat propagation appears to be a oneshot
operation, so once the value has been written we can clear the
chicken bits. So it is still possible to drive pipe B and C with
different pixel multipliers simultaneosly.

Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
for this to work. But since we keep that bit always set in all
DPLLs there's no problem.

This of course means we can't reliably read out the pixel multiplier
for pipes B and C. That would make the state checker unhappy, so I
added shadow copies of those registers in to dev_priv. The other
option would have been to skip pixel multiplier, dpll_md an dotclock
checks entirely on CHV, but that feels like a serious loss of cross
checking, so just pretending that we have working DPLL MD registers
seemed better. Obviously with the shadow copies we can't detect if
the pixel multiplier was properly configured, nor can we take over
its state from the BIOS, but hopefully people won't have displays
that would be limitd to such crappy modes.

There is one strange flicker still remaining. It's visible on
pipe C/HDMID when HDMIB is enabled while driven by pipe B.
It doesn't occur if pipe A drives HDMIB, nor is there any glitch
on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
with HDMIC so not sure if it happens there too. So I'm not sure
if it's somehow tied in with this strange linkage between pipe B
and C. Sadly I was unable to find an enable sequence that would
avoid the glitch, but at least it's not fatal ie. the output
recovers afterwards.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 +++
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_display.c | 30 ++
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1ba302..31689e1b19e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1871,7 +1871,14 @@ struct drm_i915_private {
 
u32 fdi_rx_config;
 
+   /* Shadow for DISPLAY_PHY_CONTROL which can't be safely read */
u32 chv_phy_control;
+   /*
+* Shadows for CHV DPLL_MD regs to keep the state
+* checker somewhat working in the presence hardware
+* crappiness (can't read out DPLL_MD for pipes B & C).
+*/
+   u32 chv_dpll_md[I915_MAX_PIPES];
 
u32 suspend_count;
bool suspended_to_idle;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc4007f3fa..f138588a88cd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4778,6 +4778,10 @@ enum skl_disp_power_wells {
 #define  CBR_PND_DEADLINE_DISABLE  (1<<31)
 #define  CBR_PWM_CLOCK_MUX_SELECT  (1<<30)
 
+#define CBR4_VLV   _MMIO(VLV_DISPLAY_BASE + 0x70450)
+#define  CBR_DPLLBMD_PIPE_C(1<<29)
+#define  CBR_DPLLBMD_PIPE_B(1<<18)
+
 /* FIFO watermark sizes etc */
 #define G4X_FIFO_LINE_SIZE 64
 #define I915_FIFO_LINE_SIZE64
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 414ed5007e60..18158b0324ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1635,9 +1635,27 @@ static void chv_enable_pll(struct intel_crtc *crtc,
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
 
-   /* not sure when this should be written */
-   I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
-   POSTING_READ(DPLL_MD(pipe));
+   if (pipe != PIPE_A) {
+   /*
+* WaPixelRepeatModeFixForC0:chv
+*
+* DPLLCMD is AWOL. Use chicken bits to propagate
+* the value from DPLLBMD to either pipe B or C.
+*/
+   I915_WRITE(CBR4_VLV, pipe == PIPE_B ? CBR_DPLLBMD_PIPE_B : 
CBR_DPLLBMD_PIPE_C);
+   I915_WRITE(DPLL_MD(PIPE_B), pipe_config->dpll_hw_state.dpll_md);
+   I915_WRITE(CBR4_VLV, 0);
+   dev_priv->chv_dpll_md[pipe] = 
pipe_config->dpll_hw_state.dpll_md;
+
+   /*
+* DPLLB VGA mode also seems to cause problems.
+* We should always have it disabled.
+*/
+   WARN_ON((I915_READ(DPLL(PIPE_B)) & DPLL_VGA_MODE_DIS) == 0);
+   } else {
+   I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
+   POSTING_READ(DPLL_MD(pipe));
+   }
 }
 
 static int intel_num_dvo_pipes(struct d

[Intel-gfx] [PATCH 10/16] drm/i915: Power down the DSI PLL before reconfiguring it

[ville . syrjala]

From: Ville Syrjälä 

On VLV at least, the BIOS may leave the DSI PLL enabled in some wonky
state where it just refuses to lock. Simply disabling the PLL before
reconfiguring it is not enough to fix it, but power gating the PLL
prior to reconfiguring does work.

This happens on BYT FFRD8 when booting with HDMI connected so the DSI
display will not be lit up by the BIOS.

Also we can remove the code for BXT that disables the PLL before
enabling it again.

v2: s/vlv/intel/ since BXT made thing generic
v3: Remove the BXT disable PLL before enable trick

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dsi.c | 6 ++
 drivers/gpu/drm/i915/intel_dsi_pll.c | 8 
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 4023b6bffa47..787411e1c36f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -482,7 +482,13 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
 
DRM_DEBUG_KMS("\n");
 
+   /*
+* The BIOS may leave the PLL in a wonky state where it doesn't
+* lock. It needs to be fully powered down to fix it.
+*/
+   intel_disable_dsi_pll(encoder);
intel_enable_dsi_pll(encoder);
+
intel_dsi_prepare(encoder);
 
/* Panel Enable over CRC PMIC */
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 916cc92c1400..978cc2668a3d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -474,14 +474,6 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
*encoder)
 
DRM_DEBUG_KMS("\n");
 
-   val = I915_READ(BXT_DSI_PLL_ENABLE);
-
-   if (val & BXT_DSI_PLL_DO_ENABLE) {
-   WARN(1, "DSI PLL already enabled. Disabling it.\n");
-   val &= ~BXT_DSI_PLL_DO_ENABLE;
-   I915_WRITE(BXT_DSI_PLL_ENABLE, val);
-   }
-
/* Configure PLL vales */
if (!bxt_configure_dsi_pll(encoder)) {
DRM_ERROR("Configure DSI PLL failed, abort PLL enable\n");
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 11/16] drm/i915: Compute DSI PLL parameters during .compute_config()

[ville . syrjala]

From: Ville Syrjälä 

Compute the DSI PLL parameters during .compute_config() rather than
.pre_pll_enable() so that we can fail gracefully if we can't find
suitable parameters.

In order to do that we need to store the DSI PLL parameters in
pipe_config.

v2: Handle BXT too

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c |   3 +
 drivers/gpu/drm/i915/intel_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_dsi.c |  15 ++--
 drivers/gpu/drm/i915/intel_dsi.h |  14 ++--
 drivers/gpu/drm/i915/intel_dsi_pll.c | 155 +++
 5 files changed, 112 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e6b5fb140ad..d0b7fc85bc3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12757,6 +12757,9 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
 
+   PIPE_CONF_CHECK_X(dsi_pll.ctrl);
+   PIPE_CONF_CHECK_X(dsi_pll.div);
+
if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 02b3d22862a1..89229037436d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -495,6 +495,11 @@ struct intel_crtc_state {
/* Actual register state of the dpll, for shared dpll cross-checking. */
struct intel_dpll_hw_state dpll_hw_state;
 
+   /* DSI PLL registers */
+   struct {
+   u32 ctrl, div;
+   } dsi_pll;
+
int pipe_bpp;
struct intel_link_m_n dp_m_n;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 787411e1c36f..1b4e83df4560 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -273,6 +273,7 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
struct intel_connector *intel_connector = intel_dsi->attached_connector;
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = 
&pipe_config->base.adjusted_mode;
+   int ret;
 
DRM_DEBUG_KMS("\n");
 
@@ -284,10 +285,10 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
/* DSI uses short packets for sync events, so clear mode flags for DSI 
*/
adjusted_mode->flags = 0;
 
-   /*
-* FIXME move the DSI PLL calc from vlv_enable_dsi_pll()
-* to .compute_config().
-*/
+   ret = intel_compute_dsi_pll(encoder, pipe_config);
+   if (ret)
+   return false;
+
pipe_config->clock_set = true;
 
return true;
@@ -477,6 +478,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
enum port port;
u32 tmp;
 
@@ -487,7 +489,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
 * lock. It needs to be fully powered down to fix it.
 */
intel_disable_dsi_pll(encoder);
-   intel_enable_dsi_pll(encoder);
+   intel_enable_dsi_pll(encoder, crtc->config);
 
intel_dsi_prepare(encoder);
 
@@ -715,7 +717,8 @@ static void intel_dsi_get_config(struct intel_encoder 
*encoder,
 
pipe_config->has_dsi_encoder = true;
 
-   pclk = intel_dsi_get_pclk(encoder, pipe_config->pipe_bpp);
+   pclk = intel_dsi_get_pclk(encoder, pipe_config->pipe_bpp,
+ pipe_config);
if (!pclk)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 92f39227b361..e94c07170bf6 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -126,11 +126,15 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
 }
 
-extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
-extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
-extern u32 intel_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp);
-extern void intel_dsi_reset_clocks(struct intel_encoder *encoder,
-   enum port port);
+int intel_compute_dsi_pll(struct intel_encoder *encoder,
+ struct intel_crtc_state *config);
+void intel_enable_dsi_pll(struct intel_encoder *encoder,
+ const struct intel_crtc_state *config);
+void intel_disable_dsi_pll(struct intel_encoder *encoder);
+u32 intel_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bp

[Intel-gfx] [PATCH 05/16] drm/i915: assert_panel_unlocked() in chv_enable_pll()

[ville . syrjala]

From: Ville Syrjälä 

Supposedly the power sequencer still locks out the DPLL registers on
CHV, so let's issue a warning if it's still locked when enabling the
DPLL.

Also drop the redundant IS_MOBILE() check for VLV when we check the same
thing.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 638ce9de..d3332a33f8a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1579,8 +1579,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
assert_pipe_disabled(dev_priv, pipe);
 
/* PLL is protected by panel, make sure we can write it */
-   if (IS_MOBILE(dev_priv->dev))
-   assert_panel_unlocked(dev_priv, pipe);
+   assert_panel_unlocked(dev_priv, pipe);
 
I915_WRITE(reg, dpll);
POSTING_READ(reg);
@@ -1615,6 +1614,9 @@ static void chv_enable_pll(struct intel_crtc *crtc,
 
assert_pipe_disabled(dev_priv, pipe);
 
+   /* PLL is protected by panel, make sure we can write it */
+   assert_panel_unlocked(dev_priv, pipe);
+
mutex_lock(&dev_priv->sb_lock);
 
/* Enable back the 10bit clock to display controller */
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 13/16] drm/i915: Eliminate {vlv, bxt}_configure_dsi_pll()

[ville . syrjala]

From: Ville Syrjälä 

Fold the DSI PLL configuration functions into the DSI PLL
enable functions since they are small and not called from anywhere else.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 99236baa946b..3d3132c12edb 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -162,17 +162,6 @@ static int vlv_compute_dsi_pll(struct intel_encoder 
*encoder,
return 0;
 }
 
-static void vlv_configure_dsi_pll(struct intel_encoder *encoder,
- const struct intel_crtc_state *config)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
- config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
-}
-
 static void vlv_enable_dsi_pll(struct intel_encoder *encoder,
   const struct intel_crtc_state *config)
 {
@@ -182,7 +171,10 @@ static void vlv_enable_dsi_pll(struct intel_encoder 
*encoder,
 
mutex_lock(&dev_priv->sb_lock);
 
-   vlv_configure_dsi_pll(encoder, config);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
+ config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
 
/* wait at least 0.5 us after ungating before enabling VCO */
usleep_range(1, 10);
@@ -461,15 +453,6 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
*encoder,
return 0;
 }
 
-static void bxt_configure_dsi_pll(struct intel_encoder *encoder,
- const struct intel_crtc_state *config)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
-   I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
-   POSTING_READ(BXT_DSI_PLL_CTL);
-}
-
 static void bxt_enable_dsi_pll(struct intel_encoder *encoder,
   const struct intel_crtc_state *config)
 {
@@ -481,7 +464,8 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
*encoder,
DRM_DEBUG_KMS("\n");
 
/* Configure PLL vales */
-   bxt_configure_dsi_pll(encoder, config);
+   I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
+   POSTING_READ(BXT_DSI_PLL_CTL);
 
/* Program TX, RX, Dphy clocks */
for_each_dsi_port(port, intel_dsi->ports)
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 14/16] drm/i915: Dump pfit PGM_RATIOS as hex

[ville . syrjala]

From: Ville Syrjälä 

pgm_ratios in stored as a register value in pipe config, so let's dump
this one as hex as well.

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 d0b7fc85bc3a..ecda7e28ab9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12722,7 +12722,7 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_X(gmch_pfit.control);
/* pfit ratios are autocomputed by the hw on gen4+ */
if (INTEL_INFO(dev)->gen < 4)
-   PIPE_CONF_CHECK_I(gmch_pfit.pgm_ratios);
+   PIPE_CONF_CHECK_X(gmch_pfit.pgm_ratios);
PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits);
 
if (!adjust) {
-- 
2.4.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

[Ville Syrjälä]

On Tue, Mar 15, 2016 at 06:43:54PM +0530, Shubhangi Shrivastava wrote:
> This patch sets the invert bit for hpd detection for each port
> based on VBT configuration. Since each AOB can be designed to
> depend on invert bit or not, it is expected if an AOB requires
> invert bit, the user will set respective bit in VBT.
> 
> v2: Separated VBT parsing from the rest of the logic. (Jani)
> 
> v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
> and changed its logic to avoid looping twice. (Ville)
> 
> v4: Changed the logic to mask out the bits first and then
> set them to remove need of temporary variable. (Ville)
> 
> Signed-off-by: Sivakumar Thulasimani 
> Signed-off-by: Durgadoss R 
> Signed-off-by: Shubhangi Shrivastava 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
>  drivers/gpu/drm/i915/i915_irq.c   | 20 
>  drivers/gpu/drm/i915/i915_reg.h   |  8 
>  drivers/gpu/drm/i915/intel_bios.c | 35 +++
>  4 files changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1557d65..7a00966 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3334,6 +3334,8 @@ extern void intel_i2c_reset(struct drm_device *dev);
>  /* intel_bios.c */
>  int intel_bios_init(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> +bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
> +  enum port port);
>  
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 53e5104..0a1e378 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3503,6 +3503,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
>   hotplug = I915_READ(PCH_PORT_HOTPLUG);
>   hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
>   PORTA_HOTPLUG_ENABLE;
> +
> + DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
> + hotplug, enabled_irqs);
> + hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
> +
> + /*
> +  * For BXT invert bit has to be set based on AOB design
> +  * for HPD detection logic, update it based on VBT fields.
> +  */
> +
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
> +  intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
> + hotplug |= BXT_DDIA_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
> +  intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
> + hotplug |= BXT_DDIB_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
> +  intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
> + hotplug |= BXT_DDIC_HPD_INVERT;
> +
>   I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7dfc400..f80b870 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6213,6 +6213,14 @@ enum skl_disp_power_wells {
>  #define  PORTB_HOTPLUG_SHORT_DETECT  (1 << 0)
>  #define  PORTB_HOTPLUG_LONG_DETECT   (2 << 0)
>  
> +/* BXT hotplug control */
> +#define BXT_DDIA_HPD_INVERT  (1 << 27)
> +#define BXT_DDIC_HPD_INVERT  (1 << 11)
> +#define BXT_DDIB_HPD_INVERT  (1 << 3)
> +#define BXT_DDI_HPD_INVERT_MASK  (BXT_DDIA_HPD_INVERT | \
> + BXT_DDIB_HPD_INVERT | \
> + BXT_DDIC_HPD_INVERT)

The bits defines should be inserted to the proper place in the already
existing set of defines for this register.

> +
>  #define PCH_PORT_HOTPLUG2_MMIO(0xc403C)  /* SHOTPLUG_CTL2 SPT+ */
>  #define  PORTE_HOTPLUG_ENABLE(1 << 4)
>  #define  PORTE_HOTPLUG_STATUS_MASK   (3 << 0)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index a26d4b4..71d62f8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -105,6 +105,41 @@ find_section(const void *_bdb, int section_id)
>   return NULL;
>  }
>  
> +bool
> +intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + int i;
> +
> + if (WARN_ON_ONCE(!IS_BROXTON(dev_priv)))
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> +
> + if (!dev_priv->vbt.child_dev[i].common.hpd_invert)
> + continue;
> +
> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> + case DVO_PORT_DPA:
> + case DVO_PORT_HDMIA:
> + if (port == PORT_A)
> + return true;

break;

> + case DVO_PORT_DPB:
> + case DVO_PORT_HDMIB:
> + i

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

[Ville Syrjälä]

On Tue, Mar 15, 2016 at 06:43:53PM +0530, Shubhangi Shrivastava wrote:
> This patch adds new fields that are not yet added in drm code
> in child devices struct
> 
> Signed-off-by: Sivakumar Thulasimani 
> Signed-off-by: Durgadoss R 
> Signed-off-by: Shubhangi Shrivastava 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 15 ++-
>  drivers/gpu/drm/i915/intel_bios.h | 16 +++-
>  2 files changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index bf62a19..a26d4b4 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1124,7 +1124,7 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv, enum port port,
>   }
>  
>   /* Parse the I_boost config for SKL and above */
> - if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
> + if (bdb->version >= 196 && child->common.iboost) {
>   info->dp_boost_level = 
> translate_iboost(child->common.iboost_level & 0xF);
>   DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
> port_name(port), info->dp_boost_level);
> @@ -1250,6 +1250,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
>*/
>   memcpy(child_dev_ptr, p_child,
>  min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
> +
> + /*
> +  * copied full block, now init values when they are not
> +  * available in current version
> +  */
> + if (bdb->version < 196) {
> + /* Set default values for bits added from v196 */
> + child_dev_ptr->common.iboost = 0;
> + child_dev_ptr->common.hpd_invert = 0;
> + }
> +
> + if (bdb->version < 192)
> + child_dev_ptr->common.lspcon = 0;
>   }
>   return;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0..2898323 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -250,9 +250,6 @@ struct old_child_dev_config {
>   * versions. Notice that the meaning of the contents contents may still 
> change,
>   * but at least the offsets are consistent. */
>  
> -/* Definitions for flags_1 */
> -#define IBOOST_ENABLE (1<<3)
> -
>  struct common_child_dev_config {
>   u16 handle;
>   u16 device_type;
> @@ -261,8 +258,17 @@ struct common_child_dev_config {
>   u8 not_common2[2];
>   u8 ddc_pin;
>   u16 edid_ptr;
> - u8 obsolete;
> - u8 flags_1;
> + u8 dvo_cfg; /* See DEVICE_CFG_* above */
> + u8 efp_routed:1;
> + u8 lane_reversal:1;
> + u8 lspcon:1;
> + u8 iboost:1;
> + u8 hpd_invert:1;
> + u8 flag_reserved:3;
> + u8 hdmi_support:1;
> + u8 dp_support:1;
> + u8 tmds_support:1;
> + u8 support_reserved:5;

I think we should probably annotate each of these with a version
comment. Otherwise you always have to dig up the spec to see which
version added which field.

Anyways these look to match the spec, so
Reviewed-by: Ville Syrjälä 

>   u8 not_common3[13];
>   u8 iboost_level;
>  } __packed;
> -- 
> 2.6.1

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: add module param "enable_dp_mst"

[Nathan Schulte]

Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
drm driver: "enable_dp_mst", which is enabled by default.  Disabling the
parameter forces newly connected DisplayPort sinks to report as not
supporting multi-stream transport (MST), thus "forcing" the use of
single-stream transport (SST).

v2: rename parameter to conform to style
v3: add signoff

Signed-off-by: Nathan Schulte 
---
 drivers/gpu/drm/i915/i915_params.c | 5 +
 drivers/gpu/drm/i915/i915_params.h | 1 +
 drivers/gpu/drm/i915/intel_dp.c| 3 +++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 278c9c4..97691f1 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
+   .enable_dp_mst = true,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
submission (default:false)")
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+
+module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
+MODULE_PARM_DESC(enable_dp_mst,
+   "Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index bd5026b..87153b0 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,6 +59,7 @@ struct i915_params {
bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
+   bool enable_dp_mst;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e326e7..ba2d024 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3882,6 +3882,9 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
 {
u8 buf[1];
 
+   if (!i915.enable_dp_mst)
+   return false;
+
if (!intel_dp->can_mst)
return false;
 
-- 
2.7.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: DSI and DPLL stuff for VLV/CHV mostly

[Patchwork]

== Series Details ==

Series: drm/i915: DSI and DPLL stuff for VLV/CHV mostly
URL   : https://patchwork.freedesktop.org/series/4472/
State : failure

== Summary ==

Series 4472v1 drm/i915: DSI and DPLL stuff for VLV/CHV mostly
http://patchwork.freedesktop.org/api/1.0/series/4472/revisions/1/mbox/

Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup read-crc-pipe-c:
fail   -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-nuci5)

bdw-nuci7total:194  pass:181  dwarn:0   dfail:0   fail:0   skip:13 
bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:170  dwarn:2   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:159  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1603/

fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 
2016y-03m-15d-13h-10m-41s UTC integration manifest
5efddb67a1588b732ac2ba0c89e258e6e3f72002 drm/i915: Reject 'Center' scaling mode 
for eDP/DSI on GMCH platforms
51623533abb03a96a2bedd5577fee9bea750 drm/i915: Hook up pfit for DSI
3e4440df66c6bc0baa57caeb590c8af1593cc471 drm/i915: Dump pfit PGM_RATIOS as hex
6879ed09b83ff3930c87404d65c43fb4e2828c12 drm/i915: Eliminate {vlv, 
bxt}_configure_dsi_pll()
6241adc4210412cef902b68e5fa39856beee86b9 drm/i915: Fix CHV DSI PLL refclk 
during state readout
7342e732e9304757e934440cfa5898c5c5c355b8 drm/i915: Compute DSI PLL parameters 
during .compute_config()
02cf9fe74efea1129b67c4f28e6b43f7f08b614a drm/i915: Power down the DSI PLL 
before reconfiguring it
fbd316324fb7b13e22ae14e815fdab5fca660cb1 drm/i915: Change lfsr_converts[] to u16
4a5fab6b1d66564ade2b5cc4eba6c0ec010f3e28 drm/i915: Don't read out port_clock on 
CHV when DPLL is disabled
bd993168e7a30cb208f1100906a4bf65363dd220 drm/i915: Setup DPLL/DPLLMD for DSI 
too on VLV/CHV
268fdd323dbe09d74cb575309f17b3a860ceaf1f drm/i915: Remove the "three times for 
luck" trick from vlv_enable_pll()
61a6befc33acbea46128efc806cfcc11214a5b72 drm/i915: assert_panel_unlocked() in 
chv_enable_pll()
6e59870b7c5559c18a0786b60af03df714e3a3bf drm/i915: Add a local pipe variable to 
vlv_enable_pll()
4c55229a544f6e165b54fc82c30758a6d775c1ee drm/i915: Implement 
WaPixelRepeatModeFixForC0:chv
9c162eb9644a4676365ba5e5e30aec6f157eb367 drm/i915: Make {vlv, chv}_{disable, 
update}_pll() more similar
b67e0e51444022117f76de04947bb2df1a31 drm/i915: Throw out BUGs from DPLL/PCH 
functions

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: unify partial/normal page insertion loops

[Matthew Auld]

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 40 
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2..13ce2bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1798,6 +1798,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
unsigned long pfn;
int ret = 0;
bool write = !!(vmf->flags & FAULT_FLAG_WRITE);
+   unsigned long base, size;
 
intel_runtime_pm_get(dev_priv);
 
@@ -1859,17 +1860,25 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
i915_gem_obj_ggtt_offset_view(obj, &view);
pfn >>= PAGE_SHIFT;
 
+   base = vma->vm_start;
+
if (unlikely(view.type == I915_GGTT_VIEW_PARTIAL)) {
+   base += view.params.partial.offset << PAGE_SHIFT;
+   size = view.params.partial.size;
+   } else {
+   size = min_t(unsigned long, vma->vm_end - vma->vm_start,
+obj->base.size) >> PAGE_SHIFT;
+   }
+
+   if (!obj->fault_mappable || view.type == I915_GGTT_VIEW_PARTIAL) {
+   unsigned long i;
+
/* Overriding existing pages in partial view does not cause
 * us any trouble as TLBs are still valid because the fault
 * is due to userspace losing part of the mapping or never
 * having accessed it before (at this partials' range).
 */
-   unsigned long base = vma->vm_start +
-(view.params.partial.offset << PAGE_SHIFT);
-   unsigned int i;
-
-   for (i = 0; i < view.params.partial.size; i++) {
+   for (i = 0; i < size; i++) {
ret = vm_insert_pfn(vma, base + i * PAGE_SIZE, pfn + i);
if (ret)
break;
@@ -1877,25 +1886,8 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
 
obj->fault_mappable = true;
} else {
-   if (!obj->fault_mappable) {
-   unsigned long size = min_t(unsigned long,
-  vma->vm_end - vma->vm_start,
-  obj->base.size);
-   int i;
-
-   for (i = 0; i < size >> PAGE_SHIFT; i++) {
-   ret = vm_insert_pfn(vma,
-   (unsigned 
long)vma->vm_start + i * PAGE_SIZE,
-   pfn + i);
-   if (ret)
-   break;
-   }
-
-   obj->fault_mappable = true;
-   } else
-   ret = vm_insert_pfn(vma,
-   (unsigned long)vmf->virtual_address,
-   pfn + page_offset);
+   ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address,
+   pfn + page_offset);
}
 unpin:
i915_gem_object_ggtt_unpin_view(obj, &view);
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Vinod Koul]

On Tue, Mar 15, 2016 at 03:35:45PM +0200, Ville Syrjälä wrote:
> > > I understand the benefits of a parent/child device/subdevice model. What I
> > > don't see is whether we need the component framework at all here?
> > > It was used in the case of HDaudio since both i915 and HDaudio controllers
> > > get probed at different times, here the HDMI interface is just a bunch of
> > > registers/DMA from the same hardware so the whole master/client interface
> > > exposed by the component framework to 'bind' independent drivers is a bit
> > > overkill?
> > 
> > I haven't read the patches, but using component.c when you instead can
> > model it with parent/child smells like abuse. Component.c is meant for
> > when you have multiple devices all over the device tree that in aggregate
> > constitute the overall logical driver. This doesn't seem to be the case
> > here.

Right I do think that might be the case.

> We still need the eld notify hooks so that i915 can inform the audio
> driver about the state of the display. Whether that's best done via
> the component stuff or something else I don't know.

There is already work ongoing by ARM folks for the interface, should we
reuse that [1]. I would certainly argue reusing rather than redfeining a
new one would be better.

Btw this interface seems to rely on display side implemting these ops.

Thanks
-- 
~Vinod

[1]: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105526.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: unify partial/normal page insertion loops

[Chris Wilson]

On Tue, Mar 15, 2016 at 04:05:58PM +, Matthew Auld wrote:
> Cc: Joonas Lahtinen 
> Signed-off-by: Matthew Auld 

I know I sent patches to make this even simpler than what you present
here, and that *fix* *actual* *bugs* in the partial VMA code.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: unify partial/normal page insertion loops

[Patchwork]

== Series Details ==

Series: drm/i915: unify partial/normal page insertion loops
URL   : https://patchwork.freedesktop.org/series/4476/
State : failure

== Summary ==

Series 4476v1 drm/i915: unify partial/normal page insertion loops
http://patchwork.freedesktop.org/api/1.0/series/4476/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c:
fail   -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-nuci5)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:159  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1605/

fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 
2016y-03m-15d-13h-10m-41s UTC integration manifest
ec4aa8c47920d5aacf5b35e9237de07d092d3ef5 drm/i915: unify partial/normal page 
insertion loops

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

[Michał Winiarski]

On gen8+ size of PIPE_CONTROL with Post Sync Operation should be
6 dwords. When we're using older 5-dword variant it's possible to
observe inconsistent values written by 6-dword PIPE_CONTROL with Post
Sync Operation from user batches.

v2: Fix BAT failures
v3: Comments on alignment and thrashing high dword of seqno (Chris)

Testcase: igt/gem_pipe_control_store_loop/*-qword-write
Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_lrc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..4c7ebc4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1925,15 +1925,18 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
struct intel_ringbuffer *ringbuf = request->ringbuf;
int ret;
 
-   ret = intel_logical_ring_begin(request, 6 + WA_TAIL_DWORDS);
+   ret = intel_logical_ring_begin(request, 8 + WA_TAIL_DWORDS);
if (ret)
return ret;
 
+   /* We're using qword write, seqno should be aligned to 8 bytes. */
+   BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
+
/* w/a for post sync ops following a GPGPU operation we
 * need a prior CS_STALL, which is emitted by the flush
 * following the batch.
 */
-   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
+   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
intel_logical_ring_emit(ringbuf,
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
@@ -1941,7 +1944,10 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
intel_logical_ring_emit(ringbuf, hws_seqno_address(request->ring));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
+   /* We're thrashing one dword of HWS. */
+   intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
+   intel_logical_ring_emit(ringbuf, MI_NOOP);
return intel_logical_ring_advance_and_submit(request);
 }
 
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Lukas Wunner]

Hi Alex,

On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> Is there any reason to make use of the mux?

Performance (lower latency => no need for framebuffer writes over PCIe),
improved battery life (no need to use 2 GPUs simultaneously).

Technically you can't just ignore that the mux is there on the MBP
because the kernel has no control over the GPU used on boot.
(It's determined by EFI).


> > I've heard that the AMD GPU is picky about external monitors and
> > doesn't recognize them unless they're plugged in at exactly the
> > right moment, so you may need to retry a couple of times until it
> > works.
> 
> Are talking about some issue specific to these muxed apple systems or
> in general?

Feedback I got from William Brown of Red Hat who tested the GPU switching
patches on an MBP8,2 and reported that (independently of the patches),
a display connected with an original Apple DP-to-DVI adapter would only
be recognized if plugged in at exactly the right moment and in the correct
order (first adapter, then display). However it doesn't seem to work
better on OS X.


> If you are having issues, please file a bug.

I'm not having issues so can't file a bug. Besides, filing a bug is no
guarantee that things get fixed. He had opened a bug for GPU switching
3 years ago (https://bugs.freedesktop.org/show_bug.cgi?id=61115) and
nobody did a thing. Obviously whether something gets fixed is a function
of the perceived importance by maintainers, unless a volunteer comes
along and does the dirty work.

Best regards,

Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt/gem_pipe_control_store_loop: Add qword write tests

[Michał Winiarski]

Starting from gen8 it's possible to use PIPE_CONTROL writing qword
instead of dword, let's add new *-qword-write tests to check coherency
of qword writes.

Signed-off-by: Michał Winiarski 
---
 tests/gem_pipe_control_store_loop.c | 49 -
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/tests/gem_pipe_control_store_loop.c 
b/tests/gem_pipe_control_store_loop.c
index a155ad1..c2cd292 100644
--- a/tests/gem_pipe_control_store_loop.c
+++ b/tests/gem_pipe_control_store_loop.c
@@ -26,7 +26,7 @@
  */
 
 /*
- * Testcase: (TLB-)Coherency of pipe_control QW writes
+ * Testcase: (TLB-)Coherency of pipe_control writes
  *
  * Writes a counter-value into an always newly allocated target bo (by 
disabling
  * buffer reuse). Decently trashes on tlb inconsistencies, too.
@@ -43,7 +43,7 @@
 #include "drm.h"
 #include "intel_bufmgr.h"
 
-IGT_TEST_DESCRIPTION("Test (TLB-)Coherency of pipe_control QW writes.");
+IGT_TEST_DESCRIPTION("Test (TLB-)Coherency of pipe_control writes.");
 
 static drm_intel_bufmgr *bufmgr;
 struct intel_batchbuffer *batch;
@@ -60,13 +60,23 @@ uint32_t devid;
 #define   PIPE_CONTROL_CS_STALL(1<<20)
 #define   PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
 
+#define PIPE_CONTROL_STATE_BUFFER_REUSED   (1 << 0)
+#define PIPE_CONTROL_STATE_QWORD_WRITE (1 << 1)
+#define PIPE_CONTROL_STATE_ALL_FLAGS (PIPE_CONTROL_STATE_BUFFER_REUSED | \
+ PIPE_CONTROL_STATE_QWORD_WRITE)
+
 /* Like the store dword test, but we create new command buffers each time */
 static void
-store_pipe_control_loop(bool preuse_buffer)
+store_pipe_control_loop(uint32_t flags)
 {
int i, val = 0;
uint32_t *buf;
drm_intel_bo *target_bo;
+   bool preuse_buffer = flags & PIPE_CONTROL_STATE_BUFFER_REUSED;
+   bool qword_write = flags & PIPE_CONTROL_STATE_QWORD_WRITE;
+
+   if (qword_write)
+   igt_require(intel_gen(devid) >= 8);
 
for (i = 0; i < SLOW_QUICK(0x1, 4); i++) {
/* we want to check tlb consistency of the pipe_control target,
@@ -97,7 +107,17 @@ store_pipe_control_loop(bool preuse_buffer)
/* gem_storedw_batches_loop.c is a bit overenthusiastic with
 * creating new batchbuffers - with buffer reuse disabled, the
 * support code will do that for us. */
-   if (batch->gen >= 8) {
+   if (qword_write) {
+   BEGIN_BATCH(5, 1);
+   OUT_BATCH(GFX_OP_PIPE_CONTROL + 2);
+   OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
+   OUT_RELOC_FENCED(target_bo,
+I915_GEM_DOMAIN_INSTRUCTION, 
I915_GEM_DOMAIN_INSTRUCTION,
+PIPE_CONTROL_GLOBAL_GTT);
+   OUT_BATCH(val); /* write data */
+   OUT_BATCH(0);
+   ADVANCE_BATCH();
+   } else if (batch->gen >= 8) {
BEGIN_BATCH(4, 1);
OUT_BATCH(GFX_OP_PIPE_CONTROL + 1);
OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
@@ -106,7 +126,6 @@ store_pipe_control_loop(bool preuse_buffer)
 PIPE_CONTROL_GLOBAL_GTT);
OUT_BATCH(val); /* write data */
ADVANCE_BATCH();
-
} else if (batch->gen >= 6) {
/* work-around hw issue, see 
intel_emit_post_sync_nonzero_flush
 * in mesa sources. */
@@ -144,7 +163,11 @@ store_pipe_control_loop(bool preuse_buffer)
drm_intel_bo_map(target_bo, 1);
 
buf = target_bo->virtual;
-   igt_assert(buf[0] == val);
+   if (qword_write)
+   /* We're always writing 0 to high dword */
+   igt_assert(((uint64_t*)buf)[0] == val);
+   else
+   igt_assert(buf[0] == val);
 
drm_intel_bo_unmap(target_bo);
/* Make doublesure that this buffer won't get reused. */
@@ -178,11 +201,15 @@ igt_main
igt_assert(batch);
}
 
-   igt_subtest("fresh-buffer")
-   store_pipe_control_loop(false);
-
-   igt_subtest("reused-buffer")
-   store_pipe_control_loop(true);
+   for (uint32_t flags = 0; flags < PIPE_CONTROL_STATE_ALL_FLAGS + 1; 
flags++) {
+   igt_subtest_f("%sbuffer%s",
+ flags & PIPE_CONTROL_STATE_BUFFER_REUSED ?
+ "reused-" : "fresh-",
+ flags & PIPE_CONTROL_STATE_QWORD_WRITE ?
+ "-qword-write" : "") {
+   store_pipe_control_loop(flags);
+   }
+   }
 
igt_fixture {
intel_batchbuffer_free(batch);
-- 
2.7.1

___
Intel-

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs

[Imre Deak]

After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.

v2:
- remove debugging left-over

Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll 
code")
CC: Ander Conselvan de Oliveira 
CC: Maarten Lankhorst 
Signed-off-by: Imre Deak 
Reviewed-by: Ander Conselvan de Oliveira 
---
 drivers/gpu/drm/i915/intel_display.c  | 6 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ce55f0b..df8b78a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9778,15 +9778,15 @@ static void bxt_get_ddi_pll(struct drm_i915_private 
*dev_priv,
switch (port) {
case PORT_A:
pipe_config->ddi_pll_sel = SKL_DPLL0;
-   id = DPLL_ID_SKL_DPLL1;
+   id = DPLL_ID_SKL_DPLL0;
break;
case PORT_B:
pipe_config->ddi_pll_sel = SKL_DPLL1;
-   id = DPLL_ID_SKL_DPLL2;
+   id = DPLL_ID_SKL_DPLL1;
break;
case PORT_C:
pipe_config->ddi_pll_sel = SKL_DPLL2;
-   id = DPLL_ID_SKL_DPLL3;
+   id = DPLL_ID_SKL_DPLL2;
break;
default:
DRM_ERROR("Incorrect port type\n");
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b636c4..74d5aec 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1706,9 +1706,9 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
 };
 
 static const struct dpll_info bxt_plls[] = {
-   { "PORT PLL A", 0, &bxt_ddi_pll_funcs, 0 },
-   { "PORT PLL B", 1, &bxt_ddi_pll_funcs, 0 },
-   { "PORT PLL C", 2, &bxt_ddi_pll_funcs, 0 },
+   { "PORT PLL A", DPLL_ID_SKL_DPLL0, &bxt_ddi_pll_funcs, 0 },
+   { "PORT PLL B", DPLL_ID_SKL_DPLL1, &bxt_ddi_pll_funcs, 0 },
+   { "PORT PLL C", DPLL_ID_SKL_DPLL2, &bxt_ddi_pll_funcs, 0 },
{ NULL, -1, NULL, },
 };
 
@@ -1726,7 +1726,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
 
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
dpll_mgr = &skl_pll_mgr;
-   else if IS_BROXTON(dev)
+   else if (IS_BROXTON(dev))
dpll_mgr = &bxt_pll_mgr;
else if (HAS_DDI(dev))
dpll_mgr = &hsw_pll_mgr;
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Alex Deucher]

On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner  wrote:
> Hi Alex,
>
> On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
>> Is there any reason to make use of the mux?
>
> Performance (lower latency => no need for framebuffer writes over PCIe),
> improved battery life (no need to use 2 GPUs simultaneously).
>
> Technically you can't just ignore that the mux is there on the MBP
> because the kernel has no control over the GPU used on boot.
> (It's determined by EFI).
>

Is GPU power switching also handled by the mux?  Is it independent of
the display mux?

>
>> > I've heard that the AMD GPU is picky about external monitors and
>> > doesn't recognize them unless they're plugged in at exactly the
>> > right moment, so you may need to retry a couple of times until it
>> > works.
>>
>> Are talking about some issue specific to these muxed apple systems or
>> in general?
>
> Feedback I got from William Brown of Red Hat who tested the GPU switching
> patches on an MBP8,2 and reported that (independently of the patches),
> a display connected with an original Apple DP-to-DVI adapter would only
> be recognized if plugged in at exactly the right moment and in the correct
> order (first adapter, then display). However it doesn't seem to work
> better on OS X.

Sounds like a issue with their adapter.

>
>
>> If you are having issues, please file a bug.
>
> I'm not having issues so can't file a bug. Besides, filing a bug is no
> guarantee that things get fixed. He had opened a bug for GPU switching
> 3 years ago (https://bugs.freedesktop.org/show_bug.cgi?id=61115) and
> nobody did a thing. Obviously whether something gets fixed is a function
> of the perceived importance by maintainers, unless a volunteer comes
> along and does the dirty work.

Well, of course everyone is busy and developers will prioritize
issues.  However, bugs that are not reported have substantially less
chance of getting fixed.

Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Video freezes continue to plague me

[Chris]

My system is a Dell Optiplex 780. I've filed several bug reports both
with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages.
Initially back when this started in 2014 every 'freeze' would result in
an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer
elapsed... render ring idle' in syslog. It would happen every few days
or so and nothing that was done would correct the problem. Eventually in
2015 it got to where the video would still freeze however the
'Hangcheck' error would not show up in the syslog. Sometimes it got to
where I could go 30 or 40 days without a freeze and at other times 2 or
3 days it is totally random. I've tried different kernel versions, the
latest one I tried last year was 4.2.2 which still produced a freeze. At
that time I started going back to the latest Ubuntu 3.19 kernels. When a
freeze happens the mouse cursor will continue to move and all background
processes such as fetchmail, procmail, spamassassin, clamav and so forth
continue to work as if nothing has happened. Only the video is frozen.
The first thing that keys me to this is that the clock on the upper task
bar has stopped ticking over the seconds. Another issue that is
happening and has been for awhile is that the video will 'flicker' when
I'm switching between desktops or sometimes when I'm scrolling through
my twitter feed using Firefox. 

I've attached my Xorg.0.log in case it's any help. I'm using Ubuntu
14.04.4 LTS with Gnome 3.12.2.

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
14:30:39 up 2:43, 1 user, load average: 0.17, 0.16, 0.27
Ubuntu 14.04.4 LTS, kernel 3.19.0-56-generic #62~14.04.1-Ubuntu SMP Fri
Mar 11 11:03:15 UTC 2016


Xorg.0.log.xz
Description: application/xz
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 04/10] drm/i915/bxt: fix dsi hw state pipe readout

[Jani Nikula]

BXT isn't as limited as BYT and CHT regarding DSI pipes and ports.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_dsi.c | 14 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc4007f3fa..a5035991dd57 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8144,6 +8144,7 @@ enum skl_disp_power_wells {
 #define  READ_REQUEST_PRIORITY_HIGH(3 << 3)
 #define  RGB_FLIP_TO_BGR   (1 << 2)
 
+#define  BXT_PIPE_SELECT_SHIFT 7
 #define  BXT_PIPE_SELECT_MASK  (7 << 7)
 #define  BXT_PIPE_SELECT(pipe) ((pipe) << 7)
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6574b9ac3698..73c15210fdb1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -700,7 +700,19 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
continue;
 
-   *pipe = port == PORT_A ? PIPE_A : PIPE_B;
+   if (IS_BROXTON(dev_priv)) {
+   u32 tmp = I915_READ(MIPI_CTRL(port));
+   tmp &= BXT_PIPE_SELECT_MASK;
+   tmp >>= BXT_PIPE_SELECT_SHIFT;
+
+   if (WARN_ON(tmp > PIPE_C))
+   continue;
+
+   *pipe = tmp;
+   } else {
+   *pipe = port == PORT_A ? PIPE_A : PIPE_B;
+   }
+
active = true;
break;
}
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 05/10] drm/i915: split get/set pipe timings to pipe and transcoder parts

[Jani Nikula]

Prep work for DSI transcoders. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7977a818326d..4bfad0199232 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7648,11 +7648,10 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
crtc_state->dpll_hw_state.dpll = dpll;
 }
 
-static void intel_set_pipe_timings(struct intel_crtc *intel_crtc)
+static void intel_set_trans_timings(struct intel_crtc *intel_crtc)
 {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   enum pipe pipe = intel_crtc->pipe;
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
const struct drm_display_mode *adjusted_mode = 
&intel_crtc->config->base.adjusted_mode;
uint32_t crtc_vtotal, crtc_vblank_end;
@@ -7699,6 +7698,16 @@ static void intel_set_pipe_timings(struct intel_crtc 
*intel_crtc)
I915_WRITE(VSYNC(cpu_transcoder),
   (adjusted_mode->crtc_vsync_start - 1) |
   ((adjusted_mode->crtc_vsync_end - 1) << 16));
+}
+
+static void intel_set_pipe_timings(struct intel_crtc *intel_crtc)
+{
+   struct drm_device *dev = intel_crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   enum pipe pipe = intel_crtc->pipe;
+   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+
+   intel_set_trans_timings(intel_crtc);
 
/* Workaround: when the EDP input selection is B, the VTOTAL_B must be
 * programmed with the VTOTAL_EDP value. Same for VTOTAL_C. This is
@@ -7716,8 +7725,8 @@ static void intel_set_pipe_timings(struct intel_crtc 
*intel_crtc)
   (intel_crtc->config->pipe_src_h - 1));
 }
 
-static void intel_get_pipe_timings(struct intel_crtc *crtc,
-  struct intel_crtc_state *pipe_config)
+static void intel_get_trans_timings(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -7749,6 +7758,16 @@ static void intel_get_pipe_timings(struct intel_crtc 
*crtc,
pipe_config->base.adjusted_mode.crtc_vtotal += 1;
pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
}
+}
+
+static void intel_get_pipe_timings(struct intel_crtc *crtc,
+  struct intel_crtc_state *pipe_config)
+{
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t tmp;
+
+   intel_get_trans_timings(crtc, pipe_config);
 
tmp = I915_READ(PIPESRC(crtc->pipe));
pipe_config->pipe_src_h = (tmp & 0x) + 1;
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 03/10] drm/i915/dsi: refactor dsi get hw state readout

[Jani Nikula]

Make the code easier to read and update. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 01b8e9f4c272..6574b9ac3698 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -667,7 +667,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
struct drm_device *dev = encoder->base.dev;
enum intel_display_power_domain power_domain;
enum port port;
-   bool ret;
+   bool active = false;
 
DRM_DEBUG_KMS("\n");
 
@@ -675,38 +675,39 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
 
-   ret = false;
-
/* XXX: this only works for one DSI output */
for_each_dsi_port(port, intel_dsi->ports) {
i915_reg_t ctrl_reg = IS_BROXTON(dev) ?
BXT_MIPI_PORT_CTRL(port) : MIPI_PORT_CTRL(port);
-   u32 dpi_enabled, func;
-
-   func = I915_READ(MIPI_DSI_FUNC_PRG(port));
-   dpi_enabled = I915_READ(ctrl_reg) & DPI_ENABLE;
+   bool enabled = I915_READ(ctrl_reg) & DPI_ENABLE;
 
/* Due to some hardware limitations on BYT, MIPI Port C DPI
 * Enable bit does not get set. To check whether DSI Port C
 * was enabled in BIOS, check the Pipe B enable bit
 */
if (IS_VALLEYVIEW(dev) && port == PORT_C)
-   dpi_enabled = I915_READ(PIPECONF(PIPE_B)) &
-   PIPECONF_ENABLE;
+   enabled = I915_READ(PIPECONF(PIPE_B)) & PIPECONF_ENABLE;
 
-   if (dpi_enabled || (func & CMD_MODE_DATA_WIDTH_MASK)) {
-   if (I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY) {
-   *pipe = port == PORT_A ? PIPE_A : PIPE_B;
-   ret = true;
-
-   goto out;
-   }
+   /* Try command mode if video mode not enabled */
+   if (!enabled) {
+   u32 tmp = I915_READ(MIPI_DSI_FUNC_PRG(port));
+   enabled = tmp & CMD_MODE_DATA_WIDTH_MASK;
}
+
+   if (!enabled)
+   continue;
+
+   if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
+   continue;
+
+   *pipe = port == PORT_A ? PIPE_A : PIPE_B;
+   active = true;
+   break;
}
-out:
+
intel_display_power_put(dev_priv, power_domain);
 
-   return ret;
+   return active;
 }
 
 static void intel_dsi_get_config(struct intel_encoder *encoder,
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 00/10] drm/i915/bxt: add dsi transcoders

[Jani Nikula]

Here's my first attempt at adding bxt dsi transcoder support. Patch 8 is
the real deal, everything else is almost trivial. It was painful to try
ensure we really aren't indexing any regular transcoder registers with
the dsi transcoder enumerations, but I think I got them all. It's fairly
straightforward to check everything I changed; much harder to try to
figure out what I missed...

This is all untested. Paraphrasing Bob Marley, no hardware, no cry.

BR,
Jani.


Jani Nikula (10):
  drm/i915: add for_each_port_masked macro
  drm/i915: make transcoder_name return a string
  drm/i915/dsi: refactor dsi get hw state readout
  drm/i915/bxt: fix dsi hw state pipe readout
  drm/i915: split get/set pipe timings to pipe and transcoder parts
  drm/i915: split set pipeconf to pipe and transcoder parts
  drm/i915: abstract get config for cpu transcoder
  drm/i915/bxt: add dsi transcoders
  drm/i915/dsi: use the BIT macro for clarity
  drm/i915/bxt: allow dsi on any pipe

 drivers/gpu/drm/i915/i915_drv.h|  31 -
 drivers/gpu/drm/i915/i915_reg.h|   1 +
 drivers/gpu/drm/i915/intel_ddi.c   |   6 +
 drivers/gpu/drm/i915/intel_display.c   | 210 ++---
 drivers/gpu/drm/i915/intel_drv.h   |   3 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  71 ++
 drivers/gpu/drm/i915/intel_dsi.h   |   4 +-
 drivers/gpu/drm/i915/intel_fifo_underrun.c |   6 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c|   6 +
 9 files changed, 256 insertions(+), 82 deletions(-)

-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 02/10] drm/i915: make transcoder_name return a string

[Jani Nikula]

Nicer for eDP (actually "eDP" instead of "D"), and makes future
expansion for DSI transcoders easier.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h| 17 -
 drivers/gpu/drm/i915/intel_display.c   |  4 ++--
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  6 +++---
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8ef3c88d0ed2..5e4a42d996d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -125,7 +125,22 @@ enum transcoder {
TRANSCODER_EDP,
I915_MAX_TRANSCODERS
 };
-#define transcoder_name(t) ((t) + 'A')
+
+static inline const char *transcoder_name(enum transcoder transcoder)
+{
+   switch (transcoder) {
+   case TRANSCODER_A:
+   return "A";
+   case TRANSCODER_B:
+   return "B";
+   case TRANSCODER_C:
+   return "C";
+   case TRANSCODER_EDP:
+   return "eDP";
+   default:
+   return "";
+   }
+}
 
 /*
  * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ce55f0b683c6..7977a818326d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12096,7 +12096,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
DRM_DEBUG_KMS("[CRTC:%d]%s config %p for pipe %c\n", crtc->base.base.id,
  context, pipe_config, pipe_name(crtc->pipe));
 
-   DRM_DEBUG_KMS("cpu_transcoder: %c\n", 
transcoder_name(pipe_config->cpu_transcoder));
+   DRM_DEBUG_KMS("cpu_transcoder: %s\n", 
transcoder_name(pipe_config->cpu_transcoder));
DRM_DEBUG_KMS("pipe bpp: %i, dithering: %i\n",
  pipe_config->pipe_bpp, pipe_config->dither);
DRM_DEBUG_KMS("fdi/pch: %i, lanes: %i, gmch_m: %u, gmch_n: %u, link_m: 
%u, link_n: %u, tu: %u\n",
@@ -16227,7 +16227,7 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,
}
 
for (i = 0; i < error->num_transcoders; i++) {
-   err_printf(m, "CPU transcoder: %c\n",
+   err_printf(m, "CPU transcoder: %s\n",
   
transcoder_name(error->transcoder[i].cpu_transcoder));
err_printf(m, "  Power: %s\n",
   onoff(error->transcoder[i].power_domain_on));
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index bda526660e20..19e50fdf9a91 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -212,7 +212,7 @@ static void cpt_check_pch_fifo_underruns(struct intel_crtc 
*crtc)
I915_WRITE(SERR_INT, SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
POSTING_READ(SERR_INT);
 
-   DRM_ERROR("pch fifo underrun on pch transcoder %c\n",
+   DRM_ERROR("pch fifo underrun on pch transcoder %s\n",
  transcoder_name(pch_transcoder));
 }
 
@@ -235,7 +235,7 @@ static void cpt_set_fifo_underrun_reporting(struct 
drm_device *dev,
 
if (old && I915_READ(SERR_INT) &
SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) {
-   DRM_ERROR("uncleared pch fifo underrun on pch 
transcoder %c\n",
+   DRM_ERROR("uncleared pch fifo underrun on pch 
transcoder %s\n",
  transcoder_name(pch_transcoder));
}
}
@@ -386,7 +386,7 @@ void intel_pch_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 {
if (intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
  false))
-   DRM_ERROR("PCH transcoder %c FIFO underrun\n",
+   DRM_ERROR("PCH transcoder %s FIFO underrun\n",
  transcoder_name(pch_transcoder));
 }
 
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 08/10] drm/i915/bxt: add dsi transcoders

[Jani Nikula]

The BXT display connections have DSI transcoders A and C that can be
muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI
transcoders.

The "normal" transcoders A, B and C are not used with BXT DSI, so care
must be taken to avoid accessing those registers with DSI transcoders in
the hardware state readout, modeset, and generally everywhere.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 10 
 drivers/gpu/drm/i915/intel_ddi.c|  6 +++
 drivers/gpu/drm/i915/intel_display.c| 90 +
 drivers/gpu/drm/i915/intel_drv.h|  3 +-
 drivers/gpu/drm/i915/intel_dsi.c|  9 
 drivers/gpu/drm/i915/intel_runtime_pm.c |  6 +++
 6 files changed, 112 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5e4a42d996d8..0ddd0f492ca9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -123,6 +123,8 @@ enum transcoder {
TRANSCODER_B,
TRANSCODER_C,
TRANSCODER_EDP,
+   TRANSCODER_DSI_A,
+   TRANSCODER_DSI_C,
I915_MAX_TRANSCODERS
 };
 
@@ -137,11 +139,17 @@ static inline const char *transcoder_name(enum transcoder 
transcoder)
return "C";
case TRANSCODER_EDP:
return "eDP";
+   case TRANSCODER_DSI_A:
+   return "DSI A";
+   case TRANSCODER_DSI_C:
+   return "DSI C";
default:
return "";
}
 }
 
+#define IS_DSI_TRANSCODER(t) ((t) == TRANSCODER_DSI_A || (t) == 
TRANSCODER_DSI_C)
+
 /*
  * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
  * number of planes per CRTC.  Not all platforms really have this many planes,
@@ -192,6 +200,8 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
+   POWER_DOMAIN_TRANSCODER_DSI_A,
+   POWER_DOMAIN_TRANSCODER_DSI_C,
POWER_DOMAIN_PORT_DDI_A_LANES,
POWER_DOMAIN_PORT_DDI_B_LANES,
POWER_DOMAIN_PORT_DDI_C_LANES,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 91654ffc3a42..8726711864eb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1061,6 +1061,8 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
uint32_t temp;
 
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP || 
type == INTEL_OUTPUT_DP_MST) {
+   WARN_ON(IS_DSI_TRANSCODER(cpu_transcoder));
+
temp = TRANS_MSA_SYNC_CLK;
switch (intel_crtc->config->pipe_bpp) {
case 18:
@@ -1942,6 +1944,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_hdmi *intel_hdmi;
u32 temp, flags = 0;
 
+   /* XXX: DSI transcoder paranoia */
+   if (WARN_ON(IS_DSI_TRANSCODER(cpu_transcoder)))
+   return;
+
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (temp & TRANS_DDI_PHSYNC)
flags |= DRM_MODE_FLAG_PHSYNC;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 842467528892..f1d0a868e80c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4906,7 +4906,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
 
intel_set_pipe_timings(intel_crtc);
 
-   if (intel_crtc->config->cpu_transcoder != TRANSCODER_EDP) {
+   if (intel_crtc->config->cpu_transcoder < TRANSCODER_EDP) {
I915_WRITE(PIPE_MULT(intel_crtc->config->cpu_transcoder),
   intel_crtc->config->pixel_multiplier - 1);
}
@@ -4957,7 +4957,10 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
dev_priv->display.initial_watermarks(pipe_config);
else
intel_update_watermarks(crtc);
-   intel_enable_pipe(intel_crtc);
+
+   /* XXX: Do the pipe assertions at the right place for BXT DSI. */
+   if (!intel_crtc->config->has_dsi_encoder)
+   intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
lpt_pch_enable(crtc);
@@ -5090,7 +5093,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
drm_crtc_vblank_off(crtc);
assert_vblank_disabled(crtc);
 
-   intel_disable_pipe(intel_crtc);
+   /* XXX: Do the pipe assertions at the right place for BXT DSI. */
+   if (!intel_crtc->config->has_dsi_encoder)
+   intel_disable_pipe(intel_crtc);
 
if (intel_crtc->config->dp_encoder_is_mst)
intel_ddi_set_vc_payload_alloc(crtc, false);
@@ -7707,7 +7712,8 @@ static void intel_set_pipe_timings(struct intel_crtc 
*intel_crtc)
enum pipe pipe = intel_crtc->pipe;
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
 
-   intel_set_tra

[Intel-gfx] [RFC PATCH 10/10] drm/i915/bxt: allow dsi on any pipe

[Jani Nikula]

BXT isn't as limited as BYT and CHT regarding DSI pipes and ports.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index a249549a1d86..dbdd5e7d9ef8 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1195,6 +1195,9 @@ void intel_dsi_init(struct drm_device *dev)
if (dev_priv->vbt.dsi.config->dual_link)
intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
 
+   if (IS_BROXTON(dev_priv))
+   intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | 
BIT(PIPE_C);
+
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
struct intel_dsi_host *host;
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Nuke fbc members from intel_crtc->atomic, v4.

[Zanoni, Paulo R]

Em Qua, 2016-03-09 às 10:35 +0100, Maarten Lankhorst escreveu:
> Whenever there's an update to the primary plane,
> fbc_pre_update and fbc_post_update are called. Kill off
> intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
> is empty, kill it off too.
> 
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.
> Changes since v2:
> - Remove intel_fbc_supports_rotation_helper.
> - Remove unrelated changes.
> Changes since v3:
> - Rebase
> 
> Signed-off-by: Maarten Lankhorst 

Looks like the WM fixes indeed solved the problems I pointed in my
previous review, so:

Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 51 +++---
> --
>  drivers/gpu/drm/i915/intel_drv.h | 15 ---
>  2 files changed, 16 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2d31755608ce..6e6d8b342517 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4912,11 +4912,9 @@ 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);
> @@ -4928,22 +4926,19 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (pipe_config->wm_changed && pipe_config->base.active)
>   intel_update_watermarks(&crtc->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_post_update(crtc);
> -
>   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);
>  
> + intel_fbc_post_update(crtc);
> +
>   if (primary_state->visible &&
>   (needs_modeset(&pipe_config->base) ||
>    !old_primary_state->visible))
>   intel_post_enable_primary(&crtc->base);
>   }
> -
> - memset(atomic, 0, sizeof(*atomic));
>  }
>  
>  static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state)
> @@ -4951,7 +4946,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> @@ -4960,15 +4954,14 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
>   bool modeset = needs_modeset(&pipe_config->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_pre_update(crtc);
> -
>   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);
>  
> + intel_fbc_pre_update(crtc);
> +
>   if (old_primary_state->visible &&
>   (modeset || !primary_state->visible))
>   intel_pre_disable_primary(&crtc->base);
> @@ -12027,27 +12020,17 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (visible || was_visible)
>   pipe_config->fb_bits |= to_intel_plane(plane)-
> >frontbuffer_bit;
>  
> - switch (plane->type) {
> - case DRM_PLANE_TYPE_PRIMARY:
> - intel_crtc->atomic.update_fbc = true;
> -
> - break;
> - case DRM_PLANE_TYPE_CURSOR:
> - break;
> - case DRM_PLANE_TYPE_OVERLAY:
> - /*
> -  * WaCxSRDisabledForSpriteScaling:ivb
> -  *
> -  * cstate->update_wm was already set above, so this
> flag will
> -  * take effect when we commit and program
> watermarks.
> -  */
> - if (IS_IVYBRIDGE(dev) &&
> - needs_scaling(to_intel_plane_state(plane_state))
> &&
> - !needs_s

[Intel-gfx] [RFC PATCH 01/10] drm/i915: add for_each_port_masked macro

[Jani Nikula]

Same as for_each_dsi_port, but for general use. Leave the
for_each_dsi_port version around as an "alias" for now to not cause too
much churn. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h  | 4 
 drivers/gpu/drm/i915/intel_dsi.h | 4 +---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1ba302..8ef3c88d0ed2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -274,6 +274,10 @@ struct i915_hotplug {
 (__s) < INTEL_INFO(__dev_priv)->num_sprites[(__p)];\
 (__s)++)
 
+#define for_each_port_masked(__port, __ports_mask) \
+   for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
+   for_each_if ((__ports_mask) & (1 << (__port)))
+
 #define for_each_crtc(dev, crtc) \
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 92f39227b361..0b5e0b8ac08d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -117,9 +117,7 @@ static inline struct intel_dsi_host 
*to_intel_dsi_host(struct mipi_dsi_host *h)
return container_of(h, struct intel_dsi_host, base);
 }
 
-#define for_each_dsi_port(__port, __ports_mask) \
-   for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
-   for_each_if ((__ports_mask) & (1 << (__port)))
+#define for_each_dsi_port(__port, __ports_mask) for_each_port_masked(__port, 
__ports_mask)
 
 static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
 {
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 06/10] drm/i915: split set pipeconf to pipe and transcoder parts

[Jani Nikula]

Prep work for DSI transcoders. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4bfad0199232..e485c1f9ca2b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8748,14 +8748,13 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
}
 }
 
-static void haswell_set_pipeconf(struct drm_crtc *crtc)
+static void haswell_set_transconf(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
-   uint32_t val;
+   u32 val;
 
val = 0;
 
@@ -8769,6 +8768,17 @@ static void haswell_set_pipeconf(struct drm_crtc *crtc)
 
I915_WRITE(PIPECONF(cpu_transcoder), val);
POSTING_READ(PIPECONF(cpu_transcoder));
+}
+
+static void haswell_set_pipeconf(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
+   u32 val;
+
+   haswell_set_transconf(crtc);
 
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
POSTING_READ(GAMMA_MODE(intel_crtc->pipe));
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 09/10] drm/i915/dsi: use the BIT macro for clarity

[Jani Nikula]

No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 47fd0296a05a..a249549a1d86 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -412,7 +412,7 @@ static void intel_dsi_port_enable(struct intel_encoder 
*encoder)
temp &= ~LANE_CONFIGURATION_MASK;
temp &= ~DUAL_LINK_MODE_MASK;
 
-   if (intel_dsi->ports == ((1 << PORT_A) | (1 << PORT_C))) {
+   if (intel_dsi->ports == (BIT(PORT_A) | BIT(PORT_C))) {
temp |= (intel_dsi->dual_link - 1)
<< DUAL_LINK_MODE_SHIFT;
temp |= intel_crtc->pipe ?
@@ -1185,15 +1185,15 @@ void intel_dsi_init(struct drm_device *dev)
 
/* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
-   intel_encoder->crtc_mask = (1 << PIPE_A);
-   intel_dsi->ports = (1 << PORT_A);
+   intel_encoder->crtc_mask = BIT(PIPE_A);
+   intel_dsi->ports = BIT(PORT_A);
} else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
-   intel_encoder->crtc_mask = (1 << PIPE_B);
-   intel_dsi->ports = (1 << PORT_C);
+   intel_encoder->crtc_mask = BIT(PIPE_B);
+   intel_dsi->ports = BIT(PORT_C);
}
 
if (dev_priv->vbt.dsi.config->dual_link)
-   intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
+   intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
 
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 07/10] drm/i915: abstract get config for cpu transcoder

[Jani Nikula]

Makes it neater to add the same for DSI transcoder. No functional
changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 83 
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e485c1f9ca2b..842467528892 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9893,6 +9893,49 @@ static void haswell_get_ddi_pll(struct drm_i915_private 
*dev_priv,
pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
 }
 
+static bool hsw_get_trans_config(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config,
+unsigned long *power_domain_mask)
+{
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   enum intel_display_power_domain power_domain;
+   u32 tmp;
+
+   pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
+   if (tmp & TRANS_DDI_FUNC_ENABLE) {
+   enum pipe trans_edp_pipe;
+   switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
+   default:
+   WARN(1, "unknown pipe linked to edp transcoder\n");
+   case TRANS_DDI_EDP_INPUT_A_ONOFF:
+   case TRANS_DDI_EDP_INPUT_A_ON:
+   trans_edp_pipe = PIPE_A;
+   break;
+   case TRANS_DDI_EDP_INPUT_B_ONOFF:
+   trans_edp_pipe = PIPE_B;
+   break;
+   case TRANS_DDI_EDP_INPUT_C_ONOFF:
+   trans_edp_pipe = PIPE_C;
+   break;
+   }
+
+   if (trans_edp_pipe == crtc->pipe)
+   pipe_config->cpu_transcoder = TRANSCODER_EDP;
+   }
+
+   power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
+   if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
+   return false;
+   *power_domain_mask |= BIT(power_domain);
+
+   tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
+
+   return tmp & PIPECONF_ENABLE;
+}
+
 static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
   struct intel_crtc_state *pipe_config)
 {
@@ -9943,48 +9986,18 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
enum intel_display_power_domain power_domain;
unsigned long power_domain_mask;
-   uint32_t tmp;
-   bool ret;
+   bool active;
 
power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
power_domain_mask = BIT(power_domain);
 
-   ret = false;
-
-   pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
pipe_config->shared_dpll = NULL;
 
-   tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
-   if (tmp & TRANS_DDI_FUNC_ENABLE) {
-   enum pipe trans_edp_pipe;
-   switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
-   default:
-   WARN(1, "unknown pipe linked to edp transcoder\n");
-   case TRANS_DDI_EDP_INPUT_A_ONOFF:
-   case TRANS_DDI_EDP_INPUT_A_ON:
-   trans_edp_pipe = PIPE_A;
-   break;
-   case TRANS_DDI_EDP_INPUT_B_ONOFF:
-   trans_edp_pipe = PIPE_B;
-   break;
-   case TRANS_DDI_EDP_INPUT_C_ONOFF:
-   trans_edp_pipe = PIPE_C;
-   break;
-   }
-
-   if (trans_edp_pipe == crtc->pipe)
-   pipe_config->cpu_transcoder = TRANSCODER_EDP;
-   }
-
-   power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
-   if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
-   goto out;
-   power_domain_mask |= BIT(power_domain);
+   active = hsw_get_trans_config(crtc, pipe_config, &power_domain_mask);
 
-   tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
-   if (!(tmp & PIPECONF_ENABLE))
+   if (!active)
goto out;
 
haswell_get_ddi_port_state(crtc, pipe_config);
@@ -10020,13 +10033,11 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
pipe_config->pixel_multiplier = 1;
}
 
-   ret = true;
-
 out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put(dev_priv, power_domain);
 
-   return ret;
+   return active;
 }
 
 static void i845_update_cursor(struct drm_crtc *crtc, u32 base,
-- 
2.1.4

___
Intel

Re: [Intel-gfx] Video freezes continue to plague me

[Felix Miata]

Chris composed on 2016-03-15 14:50 (UTC-0500):


My system is a Dell Optiplex 780.


Which? Tower? Desktop? SFF? USFF?


I've filed several bug reports both
with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages.
Initially back when this started in 2014 every 'freeze' would result in
an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer
elapsed... render ring idle' in syslog. It would happen every few days
or so and nothing that was done would correct the problem


Was ensuring heat is a non-issue also done? SFF & USFF models tend to run 
rather hot, so accumulated dust, and especially tobacco tar, within, 
especially within the power supply, can become an intermittent problem for 
software.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Lukas Wunner]

Hi Alex,

On Tue, Mar 15, 2016 at 02:33:56PM -0400, Alex Deucher wrote:
> On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner  wrote:
> > On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> >> Is there any reason to make use of the mux?
> >
> > Performance (lower latency => no need for framebuffer writes over PCIe),
> > improved battery life (no need to use 2 GPUs simultaneously).
> >
> > Technically you can't just ignore that the mux is there on the MBP
> > because the kernel has no control over the GPU used on boot.
> > (It's determined by EFI).
> >
> Is GPU power switching also handled by the mux?  Is it independent of
> the display mux?

Yes and yes.

Best regards,

Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_pipe_control_store_loop: Add qword write tests

[Chris Wilson]

On Tue, Mar 15, 2016 at 06:54:01PM +0100, Michał Winiarski wrote:
> Starting from gen8 it's possible to use PIPE_CONTROL writing qword
> instead of dword, let's add new *-qword-write tests to check coherency
> of qword writes.

It's always been possible to do either qword or dword writes using
pipecontrol (all the way back to gen4). What I expected to see here was
evidence that dword writes were no longer working as expected (i.e. a
test to catch the stray write).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Pierre-Louis Bossart]

On 3/15/16 11:21 AM, Vinod Koul wrote:

On Tue, Mar 15, 2016 at 03:35:45PM +0200, Ville Syrjälä wrote:

I understand the benefits of a parent/child device/subdevice model. What I
don't see is whether we need the component framework at all here?
It was used in the case of HDaudio since both i915 and HDaudio controllers
get probed at different times, here the HDMI interface is just a bunch of
registers/DMA from the same hardware so the whole master/client interface
exposed by the component framework to 'bind' independent drivers is a bit
overkill?


I haven't read the patches, but using component.c when you instead can
model it with parent/child smells like abuse. Component.c is meant for
when you have multiple devices all over the device tree that in aggregate
constitute the overall logical driver. This doesn't seem to be the case
here.


Right I do think that might be the case.


We still need the eld notify hooks so that i915 can inform the audio
driver about the state of the display. Whether that's best done via
the component stuff or something else I don't know.


There is already work ongoing by ARM folks for the interface, should we
reuse that [1]. I would certainly argue reusing rather than redfeining a
new one would be better.

Btw this interface seems to rely on display side implemting these ops.


My understanding is that it's an interface for external encoders that 
have an I2S or S/PDIF link. Such external encoders appear as ASoC codecs 
that can be bound to the SoC with DT bindings. I don't see what we could 
reuse here?


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH V11] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

[clinton . a . taylor]

From: Clint Taylor 

WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
is enabled when the cdclk is less then required. DP connected to DDI2
and HPD on either port works correctly.

Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.

The vco is now tracked at the atomic level and all CRTCs updated if
the required vco is changed. Not tested with eDP v1.4 panels that
require 8640 vco due to availability.

V1: initial version
V2: add vco tracking in intel_dp_compute_config(), rename
skl_boot_cdclk.
V3: rebase, V2 feedback not possible as encoders are not aware of
atomic.
V4: track target vco is atomic state. modeset all CRTCs if vco changes
V5: rename atomic variable, cleaner if/else logic, use existing vco if
  encoder does not return a new vco value. check_patch.pl cleanup
V6: simplify logic in intel_modeset_checks.
V7: reorder an IF for readability and whitespace fix.
V8: use dev_cdclk for tracking new cdclk during atomic
V9: correctly handle vco 8640 when crtcs==0
V10: Clean up if else in crtcs==0
V11: Rebase for new intel_dpll_mgr.c

Reviewed-by: Ville Syrjälä 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/i915_drv.h   |2 +-
 drivers/gpu/drm/i915/intel_display.c  |  111 -
 drivers/gpu/drm/i915/intel_dpll_mgr.c |9 +--
 drivers/gpu/drm/i915/intel_drv.h  |5 ++
 4 files changed, 106 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1..bf87e62 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1759,7 +1759,7 @@ struct drm_i915_private {
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
 
unsigned int fsb_freq, mem_freq, is_ddr3;
-   unsigned int skl_boot_cdclk;
+   unsigned int skl_vco_freq;
unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
unsigned int max_dotclk_freq;
unsigned int rawclk_freq;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ce55f0b..fc5268c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5584,7 +5584,7 @@ static unsigned int skl_cdclk_decimal(unsigned int freq)
return (freq - 1000) / 500;
 }
 
-static unsigned int skl_cdclk_get_vco(unsigned int freq)
+unsigned int skl_cdclk_get_vco(unsigned int freq)
 {
unsigned int i;
 
@@ -5742,17 +5742,21 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
 
 void skl_init_cdclk(struct drm_i915_private *dev_priv)
 {
-   unsigned int required_vco;
+   unsigned int cdclk;
 
/* DPLL0 not enabled (happens on early BIOS versions) */
if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
/* enable DPLL0 */
-   required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
-   skl_dpll0_enable(dev_priv, required_vco);
+   if (dev_priv->skl_vco_freq != 8640)
+   dev_priv->skl_vco_freq = 8100;
+   skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
+   cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
+   } else {
+   cdclk = dev_priv->cdclk_freq;
}
 
-   /* set CDCLK to the frequency the BIOS chose */
-   skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
+   /* set CDCLK to the lowest frequency, Modeset follows */
+   skl_set_cdclk(dev_priv, cdclk);
 
/* enable DBUF power */
I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
@@ -5768,7 +5772,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
 {
uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
uint32_t cdctl = I915_READ(CDCLK_CTL);
-   int freq = dev_priv->skl_boot_cdclk;
+   int freq = dev_priv->cdclk_freq;
 
/*
 * check if the pre-os intialized the display
@@ -5792,11 +5796,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
/* All well; nothing to sanitize */
return false;
 sanitize:
-   /*
-* As of now initialize with max cdclk till
-* we get dynamic cdclk support
-* */
-   dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
+
skl_init_cdclk(dev_priv);
 
/* we did have to sanitize */
@@ -9753,6 +9753,73 @@ static void broadwell_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
broadwell_set_cdclk(dev, req_cdclk);
 }
 
+static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
+{
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct drm_i915_private *dev_priv = to_i915(state->dev);
+   const int max_pixclk = ilk_max_pixel_rate(state);
+   int cdclk;
+
+   /*
+* FIXME should also account for plane ratio

Re: [Intel-gfx] Video freezes continue to plague me

[Chris]

On Tue, 2016-03-15 at 16:37 -0400, Felix Miata wrote:
> Chris composed on 2016-03-15 14:50 (UTC-0500):
> 
> > My system is a Dell Optiplex 780.
> 
> Which? Tower? Desktop? SFF? USFF?

Sorry, it's a desktop
> 
> > I've filed several bug reports both
> > with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages.
> > Initially back when this started in 2014 every 'freeze' would result in
> > an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer
> > elapsed... render ring idle' in syslog. It would happen every few days
> > or so and nothing that was done would correct the problem
> 
> Was ensuring heat is a non-issue also done? SFF & USFF models tend to run 
> rather hot, so accumulated dust, and especially tobacco tar, within, 
> especially within the power supply, can become an intermittent problem for 
> software.

Currently it's 87F outside. I have a window open directly behind the
system and a fan blowing on the front of it. We're just not ready to
turn the AC on yet. CPU0 is running around 116F and CPU1 109F. This
whole issue of the video freezing whether it's with or without the
Hangcheck error has been ongoing here on my system since 13 Sept 2014.
The last time the video froze with the Hangcheck error was Jan 17 2016.
Since then the video has frozen without the error on 1/21/16; 1/27/16;
2/25/16; 3/08/16; 3/11/16; and today 3/15/16 at 09:50am. I came back to
the desktop at around 11am to find it frozen at 9:50. I moved the mouse,
the video flickered and the clock caught up and came unfrozen. The only
thing in my syslog for that time is:

09:50:07 localhost kernel: [347769.284331] [drm:drm_mode_addfb2] [FB:60]
09:50:07 localhost kernel: [347769.303256] [drm:drm_mode_addfb2] [FB:62]
09:50:07 localhost kernel: [347769.324369] [drm:drm_mode_addfb2] [FB:63]

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
17:25:15 up 5:37, 1 user, load average: 0.85, 0.58, 0.44
Ubuntu 14.04.4 LTS, kernel 3.19.0-56-generic #62~14.04.1-Ubuntu SMP Fri
Mar 11 11:03:15 UTC 2016

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Video freezes continue to plague me

[Felix Miata]

Chris composed on 2016-03-15 17:43 (UTC-0500):


On Tue, 2016-03-15 at 16:37 -0400, Felix Miata wrote:



Chris composed on 2016-03-15 14:50 (UTC-0500):



> My system is a Dell Optiplex 780.



Which? Tower? Desktop? SFF? USFF?



Sorry, it's a desktop



> I've filed several bug reports both
> with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages.
> Initially back when this started in 2014 every 'freeze' would result in
> an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer
> elapsed... render ring idle' in syslog. It would happen every few days
> or so and nothing that was done would correct the problem



Was ensuring heat is a non-issue also done? SFF & USFF models tend to run
rather hot, so accumulated dust, and especially tobacco tar, within,
especially within the power supply, can become an intermittent problem for
software.



Currently it's 87F outside. I have a window open directly behind the
system and a fan blowing on the front of it. We're just not ready to
turn the AC on yet. CPU0 is running around 116F and CPU1 109F. This
whole issue of the video freezing whether it's with or without the
Hangcheck error has been ongoing here on my system since 13 Sept 2014.
The last time the video froze with the Hangcheck error was Jan 17 2016.
Since then the video has frozen without the error on 1/21/16; 1/27/16;
2/25/16; 3/08/16; 3/11/16; and today 3/15/16 at 09:50am. I came back to
the desktop at around 11am to find it frozen at 9:50. I moved the mouse,
the video flickered and the clock caught up and came unfrozen. The only
thing in my syslog for that time is:



09:50:07 localhost kernel: [347769.284331] [drm:drm_mode_addfb2] [FB:60]
09:50:07 localhost kernel: [347769.303256] [drm:drm_mode_addfb2] [FB:62]
09:50:07 localhost kernel: [347769.324369] [drm:drm_mode_addfb2] [FB:63]


Ambient temps tolerated by humans really shouldn't matter. Excess heat inside 
the case is often a problem elsewhere than where temp probes lie when dust 
has materially accumulated. What I was really asking is, is its inside 
reasonably clean, including inside the PSU? In 2014 it would have been around 
5 or 6 years old. Also, is the PSU fan always moving some air?


Maybe it's time to give it an overnight memtest workout. Could be there's 
become an iffy bit in the video RAM area.


I have a 780 too, and a 760, and a 745, and several 620s, but they are all 
SFF, and don't often get left on more than a couple of hours at a time. Video 
lockups I don't remember ever seeing on any of them. Gnome isn't installed on 
any. Kubuntu on one 620 might be 14.10, but only openSUSE 13.1, 13.2, 42.1 
and Tumbleweed are on my 780. 13.2 uses kernel 3.16.7, 42.1 4.1.15, and TW 
(currently) 4.4.3.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

[Dongwon Kim]

For BXT, Polarity of PORT_PLL_REF_SEL is reversed in
its description in Bspec. This bit should be set for
"Non-SSC".

Signed-off-by: Dongwon Kim 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b636c4..d55b308 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1285,7 +1285,7 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
enum port port = (enum port)pll->id;/* 1:1 port->PLL mapping */
 
temp = I915_READ(BXT_PORT_PLL_ENABLE(port));
-   temp &= ~PORT_PLL_REF_SEL;
+   temp |= PORT_PLL_REF_SEL;
/* Non-SSC reference */
I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Video freezes continue to plague me

[Chris]

On Tue, 2016-03-15 at 19:17 -0400, Felix Miata wrote:
> Chris composed on 2016-03-15 17:43 (UTC-0500):
> 
> > On Tue, 2016-03-15 at 16:37 -0400, Felix Miata wrote:
> 
> >> Chris composed on 2016-03-15 14:50 (UTC-0500):
> 
> >> > My system is a Dell Optiplex 780.
> 
> >> Which? Tower? Desktop? SFF? USFF?
> 
> > Sorry, it's a desktop
> 
> >> > I've filed several bug reports both
> >> > with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages.
> >> > Initially back when this started in 2014 every 'freeze' would result in
> >> > an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer
> >> > elapsed... render ring idle' in syslog. It would happen every few days
> >> > or so and nothing that was done would correct the problem
> 
> >> Was ensuring heat is a non-issue also done? SFF & USFF models tend to run
> >> rather hot, so accumulated dust, and especially tobacco tar, within,
> >> especially within the power supply, can become an intermittent problem for
> >> software.
> 
> > Currently it's 87F outside. I have a window open directly behind the
> > system and a fan blowing on the front of it. We're just not ready to
> > turn the AC on yet. CPU0 is running around 116F and CPU1 109F. This
> > whole issue of the video freezing whether it's with or without the
> > Hangcheck error has been ongoing here on my system since 13 Sept 2014.
> > The last time the video froze with the Hangcheck error was Jan 17 2016.
> > Since then the video has frozen without the error on 1/21/16; 1/27/16;
> > 2/25/16; 3/08/16; 3/11/16; and today 3/15/16 at 09:50am. I came back to
> > the desktop at around 11am to find it frozen at 9:50. I moved the mouse,
> > the video flickered and the clock caught up and came unfrozen. The only
> > thing in my syslog for that time is:
> 
> > 09:50:07 localhost kernel: [347769.284331] [drm:drm_mode_addfb2] [FB:60]
> > 09:50:07 localhost kernel: [347769.303256] [drm:drm_mode_addfb2] [FB:62]
> > 09:50:07 localhost kernel: [347769.324369] [drm:drm_mode_addfb2] [FB:63]
> 
> Ambient temps tolerated by humans really shouldn't matter. Excess heat inside 
> the case is often a problem elsewhere than where temp probes lie when dust 
> has materially accumulated. What I was really asking is, is its inside 
> reasonably clean, including inside the PSU? In 2014 it would have been around 
> 5 or 6 years old. Also, is the PSU fan always moving some air?
> 
> Maybe it's time to give it an overnight memtest workout. Could be there's 
> become an iffy bit in the video RAM area.
> 
> I have a 780 too, and a 760, and a 745, and several 620s, but they are all 
> SFF, and don't often get left on more than a couple of hours at a time. Video 
> lockups I don't remember ever seeing on any of them. Gnome isn't installed on 
> any. Kubuntu on one 620 might be 14.10, but only openSUSE 13.1, 13.2, 42.1 
> and Tumbleweed are on my 780. 13.2 uses kernel 3.16.7, 42.1 4.1.15, and TW 
> (currently) 4.4.3.

Thanks Felix, I'll see if giving it a good will make any difference.

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
19:28:00 up 7:40, 1 user, load average: 0.75, 0.52, 0.44
Ubuntu 14.04.4 LTS, kernel 3.19.0-56-generic #62~14.04.1-Ubuntu SMP Fri
Mar 11 11:03:15 UTC 2016

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

[Vinod Koul]

On Tue, Mar 15, 2016 at 04:14:19PM -0500, Pierre-Louis Bossart wrote:
> On 3/15/16 11:21 AM, Vinod Koul wrote:
> >On Tue, Mar 15, 2016 at 03:35:45PM +0200, Ville Syrjälä wrote:
> I understand the benefits of a parent/child device/subdevice model. What I
> don't see is whether we need the component framework at all here?
> It was used in the case of HDaudio since both i915 and HDaudio controllers
> get probed at different times, here the HDMI interface is just a bunch of
> registers/DMA from the same hardware so the whole master/client interface
> exposed by the component framework to 'bind' independent drivers is a bit
> overkill?
> >>>
> >>>I haven't read the patches, but using component.c when you instead can
> >>>model it with parent/child smells like abuse. Component.c is meant for
> >>>when you have multiple devices all over the device tree that in aggregate
> >>>constitute the overall logical driver. This doesn't seem to be the case
> >>>here.
> >
> >Right I do think that might be the case.
> >
> >>We still need the eld notify hooks so that i915 can inform the audio
> >>driver about the state of the display. Whether that's best done via
> >>the component stuff or something else I don't know.
> >
> >There is already work ongoing by ARM folks for the interface, should we
> >reuse that [1]. I would certainly argue reusing rather than redfeining a
> >new one would be better.
> >
> >Btw this interface seems to rely on display side implemting these ops.
> 
> My understanding is that it's an interface for external encoders
> that have an I2S or S/PDIF link. Such external encoders appear as
> ASoC codecs that can be bound to the SoC with DT bindings. I don't
> see what we could reuse here?

That is one of the intended usages. Right now three folks are developing
on that, TI which seems to be encoder case, then sti (don't know if that
off chip or not) and mediatek.

The point here is that we can use the same interface here too if we are
not going i915 way. Possibly we might want to modify or add to this and
not make it ASoC dependent as this driver won't be an ASoC one. But yes
I haven't looked closely enough to say that if this should be the way or
not. I wanted to pint our an alternate interface being developed which
can be possible reused in non i915 case

Thanks
-- 
~Vinod
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv3 10/15] drm/i915: update PDPs by condition when submit the LRC context

[Zhi Wang]

Hi Chris:
Your idea is good. :) We could emit PDP upgrade LRIs like i915 
before emit GVT worload under GVT context, then we can reuse the 
pd_dirty_ring bitmap.


But I have to expose intel_logical_ring_emit_pdps() function for GVT-g. 
Is it acceptable?


Thanks,
Zhi.

On 03/11/16 20:56, Wang, Zhi A wrote:

OK. I will see. :) Thanks for the comments.

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, March 11, 2016 7:28 PM
To: Wang, Zhi A
Cc: intel-gfx@lists.freedesktop.org; igv...@lists.01.org; Tian, Kevin; Lv, 
Zhiyuan; Niu, Bing; Song, Jike; daniel.vet...@ffwll.ch; Cowperthwaite, David J; 
joonas.lahti...@linux.intel.com
Subject: Re: [RFCv3 10/15] drm/i915: update PDPs by condition when submit the 
LRC context

On Fri, Mar 11, 2016 at 06:59:41PM +0800, Zhi Wang wrote:

Previously the PDPs inside the ring context will be updated

- When populating a LRC context
- Before submitting a LRC context (only for 32 bit PPGTT, as the amount
of used PDPs may be changed during PPGTT page table grow)

Under GVT-g, each VM owns a GVT context used as the shadow context. When
guest submits a context, GVT-g will load guest context into the GVT
context, and submit this context to i915 GEM submission system.

So this GVT context could be used by different guest context, and the
PPGTT root pointer in guest contexts might be different as well, if guest
is using full PPGTT mode.

In current i915, the root pointer in a LRC context will only be updated
during the LRC context creation.

This patch postpones the root pointer upgrade to the time of submission,
which will give GVT-g a chance to reload a new PPGTT page table root
pointer into an existing GVT context.


Not explained is why you cannot use the existing dirty flags.
-Chris


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx