date:20130927

On Thu, Sep 26, 2013 at 05:55:58PM -0700, Jesse Barnes wrote:
 We need to use the clock control reg to figure out how many CZ clks are in
 30ns and use that as the basis for our RC6 residency calculations.
 
 v2: use ULL everywhere for consistency (Chris)
 factor out bias for clarity (Chris)

I liked the NSEC_PER_MSEC as well :)

 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=69692
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/i915_reg.h   |  3 +++
  drivers/gpu/drm/i915/i915_sysfs.c | 22 --
  2 files changed, 23 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index cf995bb..6f8d0cf 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -1797,6 +1797,9 @@
   */
  #define HSW_CXT_TOTAL_SIZE   (17 * PAGE_SIZE)
  
 +#define VLV_CLK_CTL2 0x101104
 +#define   CLK_CTL2_CZCOUNT_30NS_SHIFT28
 +
  /*
   * Overlay regs
   */
 diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
 b/drivers/gpu/drm/i915/i915_sysfs.c
 index 44f4c1a..8003886 100644
 --- a/drivers/gpu/drm/i915/i915_sysfs.c
 +++ b/drivers/gpu/drm/i915/i915_sysfs.c
 @@ -37,12 +37,30 @@ static u32 calc_residency(struct drm_device *dev, const 
 u32 reg)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
   u64 raw_time; /* 32b value may overflow during fixed point math */
 + u64 units = 128ULL, div = 10ULL, bias = 100ULL;
  
   if (!intel_enable_rc6(dev))
   return 0;
  
 - raw_time = I915_READ(reg) * 128ULL;
 - return DIV_ROUND_UP_ULL(raw_time, 10);
 + /* On VLV, residency time is in CZ units rather than 1.28us */
 + if (IS_VALLEYVIEW(dev)) {
 + u32 clkctl2;
 +
 + clkctl2 = I915_READ(VLV_CLK_CTL2) 
 + CLK_CTL2_CZCOUNT_30NS_SHIFT;
 + if (!clkctl2) {
 + WARN(!clkctl2, bogus CZ count value);
 + return 0;
 + }
 + units = DIV_ROUND_UP_ULL(30ULL * bias, (u64)clkctl2);
 + if (I915_READ(VLV_COUNTER_CONTROL)  VLV_COUNT_RANGE_HIGH)
 + units = 8;
 +
 + div = 100ULL * bias;
 + }

/* On VLV, residency time is in CZ units rather than 1.28us */
if (IS_VALLEVIEW9dev)) {
u32 clkctl2;

clkctl2 = I915_READ(VLV_CLK_CTL2) 
CLK_CTL2_CZCOUNT_30NS_SHIFT;
if (!clkctl2) {
WARN(!clkctl2, bogus CZ count value);
return 0;
}

units = DIV_ROUND_UP_ULL(30ULL * bias, (u64)clkctl2);
if (I915_READ(VLV_COUNTER_CONTROL)  VLV_COUNT_RANGE_HIGH)
units = 8;

div = NSEC_PER_MSEC * bias;
} else {
units = 128;
div = USEC_PER_MSEC * bias;
}

raw_time = I915_READ(reg) * units;
return DIV_ROUND_UP_ULL(raw_time, div);

Either way, with or without the extra constants,
Both patches,
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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

[Intel-gfx] [PULL] drm-intel-next

Hi Dave,

First feature pull request for 3.13. Highlights:

drm-intel-next-2013-09-21:
- clock state handling rework from Ville
- l3 parity handling fixes for hsw from Ben
- some more watermark improvements from Ville
- ban badly behaved context from Mika
- a few vlv improvements from Jesse
- VGA power domain handling from Ville
drm-intel-next-2013-09-06:
- Basic mipi dsi support from Jani. Not yet converted over to drm_bridge
  since that was too fresh, but the porting is in progress already.
- More vma patches from Ben, this time the code to convert the execbuffer
  code. Now that the shrinker recursion bug is tracked down we can move
  ahead here again. Yay!
- Optimize hw context switching to not generate needless interrupts (Chris
  Wilson). Also some shuffling for the oustanding request allocation.
- Opregion support for SWSCI, although not yet fully wired up (we need a
  bit of runtime D3 support for that apparently, due to Windows design
  deficiencies), from Jani Nikula.
- A few smaller changes all over.

Plus a backmerge of -rc2 since things became unwielding.

Note that this contains the DSI connector/encoder #defines in drm core
that Thierry wants to use for tegar (or at least he poked me a while back
where they're stuck).

Cheers, Daniel


The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983:

  Linux 3.12-rc2 (2013-09-23 15:41:09 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel 
tags/drm-intel-next-2013-09-21-merged

for you to fetch changes up to b599c89e8c5cf0c37352e0871be240291f8ce922:

  Merge tag 'v3.12-rc2' into drm-intel-next (2013-09-24 09:32:53 +0200)



Ben Widawsky (14):
  drm/i915: Convert execbuf code to use vmas
  drm/i915: Restore the preliminary HW check.
  drm/i915: Synchronize pread/pwrite with wait_rendering
  drm/i915: Extract vm specific part of eviction
  drm/i915: evict VM instead of everything
  drm/i915: Remove extra ring
  drm/i915: Round l3 parity reads down
  drm/i915: Fix l3 parity user buffer offset
  drm/i915: Fix HSW parity test
  drm/i915: Add second slice l3 remapping
  drm/i915: Make l3 remapping use the ring
  drm/i915: Keep a list of all contexts
  drm/i915: Do remaps for all contexts
  drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF

Chon Ming Lee (3):
  drm/i915: Modify DP set clock to accomodate more eDP timings v2
  drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
  drm/i915: Add additional pipe parameter for vlv_dpio_read and 
vlv_dpio_write. v2

Chris Wilson (8):
  drm/i915: Don't destroy the vma placeholder during execbuffer reservation
  drm/i915: Always prefer CPU relocations with LLC
  drm/i915: Do not add an interrupt for a context switch
  drm/i915: Rearrange the comments in i915_add_request()
  drm/i915: Rename ring-outstanding_lazy_request
  drm/i915; Preallocate the lazy request
  drm/i915: Write RING_TAIL once per-request
  drm/i915: Remove the double-list iteration from bound_any()

Damien Lespiau (2):
  drm/i915: It's its!
  drm/i915: Remove unused mode_fixup() vfunc of struct intel_dvo_dev_ops

Dan Carpenter (1):
  drm/i915: cleanup a min_t() cast

Daniel Vetter (8):
  drm/i915: inline vma_create into lookup_or_create_vma
  drm/i915: More vma fixups around unbind/destroy
  drm/i915/dsi: s/size_t/int/
  drm/i915: Fix list corruption in vma_unbind
  drm/i915: re-layout intel_panel.c to obey 80 char limit
  drm/i915: garbage-collect vlv refclk function
  drm/i915: dump crtc timings from the pipe config
  Merge tag 'v3.12-rc2' into drm-intel-next

Jani Nikula (23):
  drm/i915: add more VLV IOSF sideband ports accessors
  drm/i915: add VLV pipeconf bit definition for DSI PLL lock
  drm/i915: add MIPI DSI register definitions
  drm/i915: add MIPI DSI output type and subtypes
  drm/i915: add structs for MIPI DSI output
  drm/i915: add MIPI DSI command sending routines
  drm/i915: add basic MIPI DSI output support
  drm/i915: fix PLL assertions for DSI PLL
  drm/i915: don't enable DPLL for DSI
  drm/i915: initialize DSI output on VLV
  drm/i915: add plumbing for SWSCI
  drm/i915: expose intel_ddi_get_encoder_port()
  drm/i915: add opregion function to notify bios of encoder enable/disable
  drm/i915: add opregion function to notify bios of adapter power state
  drm/i915: do display power state notification on crtc enable/disable
  drm/i915: name intel dp hooks per platform
  drm/i915: move backlight enable later in vlv enable sequence
  drm/i915: clean up power sequencing register port select definitions
  drm/i915: add support for per-pipe power sequencing on vlv
  drm/i915: add asserts for cursor disabled
  drm/i915: only report hpd connector status change when it

Re: [Intel-gfx] 3.12 regression:i915 warnings

On Thu, Sep 26, 2013 at 2:36 PM, Woody Suwalski terraluna...@gmail.com wrote:
 Daniel, I have noticed these warnings on 3.12-rc1, did not go away on
 3.12-rc2.
 I see it only on EeePC with i915,not on ThinkPad with Radeon.
 It is a 32-bit kernel with overlayfs and TuxOnIce patches, so not perfectly
 clean, however same config and patches on 3.11 do not show these issues.
 No,sorry, did not have time to investigate further or bisect.If you have a
 quick test in mind - I will try ;-)


a) Please always cc: relevant mailing lists, not just your maintainer.
b) Please retest with latest drm-intel-fixes from
http://cgit.freedesktop.org/~danvet/drm-intel/
c) If that doesn't help please boot with drm.debug=0xe, reproduce the
issue once and attach the complete dmesg. Please make sure that it
contains everything from boot-up to the WARN.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: reset DPIO on load and resume

On Thu, Sep 26, 2013 at 02:39:14PM -0700, Jesse Barnes wrote:
 This fixes resume on my test platform, since I think some DPIO bits need
 recalibration.
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c | 13 +
  1 file changed, 13 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index f52e6d4..320f729 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1359,6 +1359,17 @@ static void assert_pch_ports_disabled(struct 
 drm_i915_private *dev_priv,
   assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
  }
  
 +static void intel_init_dpio(struct drm_device *dev)
 +{
 + struct drm_i915_private *dev_priv = dev-dev_private;
 +
 + if (!IS_VALLEYVIEW(dev))
 + return;
 +
 + /* Reset in case DPIO was stuck across suspend/resume or boot */
 + I915_WRITE(DPIO_CTL, I915_READ(DPIO_CTL) | DPIO_RESET);

This will deassert the common lane reset, so the comment is confusing,
as is the name we have given this bit.

 +}
 +
  static void vlv_enable_pll(struct intel_crtc *crtc)
  {
   struct drm_device *dev = crtc-base.dev;
 @@ -10279,6 +10290,8 @@ void intel_modeset_init_hw(struct drm_device *dev)
  {
   intel_prepare_ddi(dev);
  
 + intel_init_dpio(dev);
 +
   intel_init_clock_gating(dev);
  
   mutex_lock(dev-struct_mutex);
 -- 
 1.8.3.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Program GMBUS Frequency based on the CDCLK for VLV.

On Fri, Sep 27, 2013 at 03:31:00PM +0800, Chon Ming Lee wrote:
 CDCLK is used to generate the gmbus clock.  This is normally done by
 BIOS. Program the value if the BIOS-less system doesn't do it.
 
 v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
 during resume. (Daniel)
 
 v3: Change GMBUS_FREQ to GMBUSFREQ_VLV, and use VLV_DISPLAY_BASE.
 (Ville).
   Remove cdclk_ratio[] table, and calculate the cdclk ratio instead.
 (Ville).
   Change the shift then mask for reg read, to mask first, then shift.
 (Ville).
   Remove the gmbus frequency calculation = cdclk/1.01.  Based on BIOS
 programming, gmbus frequency = cdclk frequency. (Ville)
   Add get_disp_clk_div, which can use to get cdclk/czclk divide.
 
 v4: Fix the mmio_offset base for CZCLK_CDCLK_FREQ_RATIO, gmbus_freq
 calculation, and duplicate check for gmbus_freq. (Ville)
 
 In VLV, the spec is wrong about 4Mhz reference frequency for GMBUS. It
 should be 1Mhz.
 
 Signed-off-by: Chon Ming Lee chon.ming@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h  |8 +
  drivers/gpu/drm/i915/intel_i2c.c |   57 
 ++
  2 files changed, 65 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index a0a9811..b37dfd8 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -391,6 +391,8 @@
  #define   FB_FMAX_VMIN_FREQ_LO_MASK  0xf800
  
  /* vlv2 north clock has */
 +#define CCK_FUSE_REG 0x8
 +#define  CCK_FUSE_HPLL_FREQ_MASK 0x3
  #define CCK_REG_DSI_PLL_FUSE 0x44
  #define CCK_REG_DSI_PLL_CONTROL  0x48
  #define  DSI_PLL_VCO_EN  (1  31)
 @@ -1438,6 +1440,12 @@
  
  #define MI_ARB_VLV   (VLV_DISPLAY_BASE + 0x6504)
  
 +#define CZCLK_CDCLK_FREQ_RATIO   (VLV_DISPLAY_BASE + 0x6508)
 +#define   CDCLK_FREQ_SHIFT   4
 +#define   CDCLK_FREQ_MASK(0x1f  CDCLK_FREQ_SHIFT)
 +#define   CZCLK_FREQ_MASK0xf
 +#define GMBUSFREQ_VLV(VLV_DISPLAY_BASE + 0x6510)
 +
  /*
   * Palette regs
   */
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index d1c1e0f7..b579ffd 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -34,6 +34,11 @@
  #include drm/i915_drm.h
  #include i915_drv.h
  
 +enum disp_clk {
 + CDCLK,
 + CZCLK
 +};
 +
  struct gmbus_port {
   const char *name;
   int reg;
 @@ -58,10 +63,62 @@ to_intel_gmbus(struct i2c_adapter *i2c)
   return container_of(i2c, struct intel_gmbus, adapter);
  }
  
 +static int get_disp_clk_div(struct drm_i915_private *dev_priv, enum disp_clk 
 clk)
 +{
 + u32 reg_val;
 + int clk_ratio;
 +
 + reg_val = I915_READ(CZCLK_CDCLK_FREQ_RATIO);
 +
 + if (clk == CDCLK)
 + clk_ratio = ((reg_val  CDCLK_FREQ_MASK)  CDCLK_FREQ_SHIFT) + 
 1;
 + else
 + clk_ratio = (reg_val  CZCLK_FREQ_MASK) + 1;
 +
 + return clk_ratio;
 +}
 +
 +static void gmbus_set_freq(struct drm_i915_private *dev_priv)
 +{
 + int vco_freq[] = { 800, 1600, 2000, 2400 };
 + int gmbus_freq = 0, cdclk_div, hpll_freq;
 +
 + BUG_ON(!IS_VALLEYVIEW(dev_priv-dev));
 +
 + /* Skip setting the gmbus freq if BIOS has already programmed it */
 + if (I915_READ(GMBUSFREQ_VLV) != 0xA0)
 + return;
 +
 + /* Obtain SKU information */
 + mutex_lock(dev_priv-dpio_lock);
 + hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG)  
 CCK_FUSE_HPLL_FREQ_MASK;
 + mutex_unlock(dev_priv-dpio_lock);
 +
 + /* Get the CDCLK divide ratio */
 + cdclk_div = get_disp_clk_div(dev_priv, CDCLK);
 +
 + /* Program the gmbus_freq based on the cdclk frequency */
 + if (cdclk_div)
 + gmbus_freq = (vco_freq[hpll_freq]  1) / cdclk_div;


OK based on the information that you dug up that we do need to aim for
1MHz GMBUS freq, the patch looks good to me. I think we should add a
comment here about the 1MHz vs. 4MHz what the spec says. Eg.:

/*
 * Program the gmbus_freq based on the cdclk frequency.
 * BSpec erroneously claims we should aim for 4MHz, but
 * in fact 1MHz is the correct frequency.
 */

Maybe Daniel can add that when applying the patch...

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

 +
 + if (WARN_ON(gmbus_freq == 0))
 + return;
 +
 + I915_WRITE(GMBUSFREQ_VLV, gmbus_freq);
 +}
 +
  void
  intel_i2c_reset(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
 +
 + /*
 +  * In BIOS-less system, program the correct gmbus frequency
 +  * before reading edid.
 +  */
 + if (IS_VALLEYVIEW(dev))
 + gmbus_set_freq(dev_priv);
 +
   I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
   I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
  }
 -- 
 1.7.7.6
 
 ___

Re: [Intel-gfx] [PATCH v3 0/4] Fix Win8 backlight issue

2013-09-27 Thread Mika Westerberg

On Tue, Sep 24, 2013 at 05:47:28PM +0800, Aaron Lu wrote:
 v3:
 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module;
 2 Remove unnecessary function acpi_video_unregister introduced in
   patch 2/3 as pointed out by Jani Nikula.
 
 v2:
 v1 has the subject of Rework ACPI video driver and is posted here:
 http://lkml.org/lkml/2013/9/9/74
 Since the objective is really to fix Win8 backlight issues, I changed
 the subject in this version, sorry about that.
 
 This patchset has three patches, the first introduced a new API named
 backlight_device_registered in backlight layer that can be used for
 backlight interface provider module to check if a specific type backlight
 interface has been registered, see changelog for patch 1/3 for details.
 Then patch 2/3 does the cleanup to sepeate the backlight control and
 event delivery functionality in the ACPI video module and patch 3/3
 solves some Win8 backlight control problems by avoiding register ACPI
 video's backlight interface if:
 1 Kernel cmdline option acpi_backlight=video is not given;
 2 This is a Win8 system;
 3 Native backlight control interface exists.
 
 Technically, patch 2/3 is not required to fix the issue here. So if you
 think it is not necessary, I can remove it from the series.
 
 Aaron Lu (4):
   backlight: introduce backlight_device_registered
   ACPI / video: seperate backlight control and event interface
   ACPI / video: Do not register backlight if win8 and native interface
 exists
   thinkpad-acpi: fix handle locate for video and query of _BCL
 
  drivers/acpi/internal.h  |   5 +-
  drivers/acpi/video.c | 442 
 ---
  drivers/acpi/video_detect.c  |  14 +-
  drivers/platform/x86/thinkpad_acpi.c |  31 ++-
  drivers/video/backlight/backlight.c  |  31 +++
  include/acpi/video.h |   2 +
  include/linux/backlight.h|   4 +
  7 files changed, 324 insertions(+), 205 deletions(-)

Just tested this series on my HP revolve 810 and this fixes the backlight
issue it had :)

Feel free to add my,

Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Code stereo layouts as an enum in the mode structure

Daniel noticed that it wasn't very smart to keep using one bit per stereo
layout now that we don't have to or them. It's a nice final touch to the new
stereo mode API extension that we should fix before committing to it.

-- 
Damien

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

[Intel-gfx] [PATCH 1/3] drm: Code stereo layouts as an enum rather than a bit field

This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.

I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reserving 32
values.

Even with that reservation, we gain 3 bits from the previous encoding.

The code adding the mandatory stereo modes needeed to be adapted as it was
relying or being able to or stereo layouts together.

Suggested-by: Daniel Vetter dan...@ffwll.ch
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/drm_edid.c  | 47 +++--
 include/drm/drm_crtc.h  |  9 -
 include/uapi/drm/drm_mode.h | 19 ++
 3 files changed, 26 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c24af1d..7d1e8a9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2562,16 +2562,16 @@ struct stereo_mandatory_mode {
 };
 
 static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
-   { 1920, 1080, 24,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1920, 1080, 24, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+   { 1920, 1080, 24, DRM_MODE_FLAG_3D_FRAME_PACKING },
{ 1920, 1080, 50,
  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
{ 1920, 1080, 60,
  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
-   { 1280, 720,  50,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
-   { 1280, 720,  60,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+   { 1280, 720,  50, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+   { 1280, 720,  50, DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1280, 720,  60, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+   { 1280, 720,  60, DRM_MODE_FLAG_3D_FRAME_PACKING }
 };
 
 static bool
@@ -2586,50 +2586,33 @@ stereo_match_mandatory(const struct drm_display_mode 
*mode,
   drm_mode_vrefresh(mode) == stereo_mode-vrefresh;
 }
 
-static const struct stereo_mandatory_mode *
-hdmi_find_stereo_mandatory_mode(const struct drm_display_mode *mode)
-{
-   int i;
-
-   for (i = 0; i  ARRAY_SIZE(stereo_mandatory_modes); i++)
-   if (stereo_match_mandatory(mode, stereo_mandatory_modes[i]))
-   return stereo_mandatory_modes[i];
-
-   return NULL;
-}
-
 static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
 {
struct drm_device *dev = connector-dev;
const struct drm_display_mode *mode;
struct list_head stereo_modes;
-   int modes = 0;
+   int modes = 0, i;
 
INIT_LIST_HEAD(stereo_modes);
 
list_for_each_entry(mode, connector-probed_modes, head) {
-   const struct stereo_mandatory_mode *mandatory;
-   u32 stereo_layouts, layout;
-
-   mandatory = hdmi_find_stereo_mandatory_mode(mode);
-   if (!mandatory)
-   continue;
-
-   stereo_layouts = mandatory-flags  DRM_MODE_FLAG_3D_MASK;
-   do {
+   for (i = 0; i  ARRAY_SIZE(stereo_mandatory_modes); i++) {
+   const struct stereo_mandatory_mode *mandatory;
struct drm_display_mode *new_mode;
 
-   layout = 1  (ffs(stereo_layouts) - 1);
-   stereo_layouts = ~layout;
+   if (!stereo_match_mandatory(mode,
+   stereo_mandatory_modes[i]))
+   continue;
 
+   mandatory = stereo_mandatory_modes[i];
new_mode = drm_mode_duplicate(dev, mode);
if (!new_mode)
continue;
 
-   new_mode-flags |= layout;
+   new_mode-flags |= mandatory-flags;
list_add_tail(new_mode-head, stereo_modes);
modes++;
-   } while (stereo_layouts);
+   }
}
 
list_splice_tail(stereo_modes, connector-probed_modes);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b2d08ca..eb6b8dc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -181,15 +181,6 @@ struct drm_display_mode {
int hsync;  /* in kHz */
 };
 
-#define DRM_MODE_FLAG_3D_MASK  (DRM_MODE_FLAG_3D_FRAME_PACKING | \
-DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE | \
-DRM_MODE_FLAG_3D_LINE_ALTERNATIVE  | \
-DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL | \
-DRM_MODE_FLAG_3D_L_DEPTH   | \
-

[Intel-gfx] [PATCH 3/3] drm: Reject stereo modes with an unknown layout

The kernel shouldn't accept invalid modes, just say No.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/drm_crtc.c  | 3 +++
 include/drm/drm_crtc.h  | 2 ++
 include/uapi/drm/drm_mode.h | 4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2ce80ed..d7a8370 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1319,6 +1319,9 @@ static int drm_crtc_convert_umode(struct drm_display_mode 
*out,
if (in-clock  INT_MAX || in-vrefresh  INT_MAX)
return -ERANGE;
 
+   if ((in-flags  DRM_MODE_FLAG_3D_MASK)  DRM_MODE_FLAG_3D_MAX)
+   return -EINVAL;
+
out-clock = in-clock;
out-hdisplay = in-hdisplay;
out-hsync_start = in-hsync_start;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index eb6b8dc..50cedad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -128,6 +128,8 @@ enum drm_mode_status {
 #define CRTC_INTERLACE_HALVE_V (1  0) /* halve V values for interlacing */
 #define CRTC_STEREO_DOUBLE (1  1) /* adjust timings for stereo modes */
 
+#define DRM_MODE_FLAG_3D_MAX   DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+
 struct drm_display_mode {
/* Header */
struct list_head head;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7980f89..c2c4ace 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -58,6 +58,10 @@
 #define DRM_MODE_FLAG_PIXMUX   (111)
 #define DRM_MODE_FLAG_DBLCLK   (112)
 #define DRM_MODE_FLAG_CLKDIV2  (113)
+ /*
+  * When adding a new stereo mode don't forget to adjust DRM_MODE_FLAGS_3D_MAX
+  * (define not exposed to user space).
+  */
 #define DRM_MODE_FLAG_3D_MASK  (0x1f14)
 #define  DRM_MODE_FLAG_3D_NONE (014)
 #define  DRM_MODE_FLAG_3D_FRAME_PACKING(114)
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 2/3] drm: Revert drm: Reject modes with more than 1 stereo flags set

Now that the coding of stereo layout has changed from a bit field to an
enum, we need remove that check.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/drm_crtc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 807309f..2ce80ed 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1319,10 +1319,6 @@ static int drm_crtc_convert_umode(struct 
drm_display_mode *out,
if (in-clock  INT_MAX || in-vrefresh  INT_MAX)
return -ERANGE;
 
-   /* At most, 1 set bit describing the 3D layout of the mode */
-   if (hweight32(in-flags  DRM_MODE_FLAG_3D_MASK)  1)
-   return -EINVAL;
-
out-clock = in-clock;
out-hdisplay = in-hdisplay;
out-hsync_start = in-hsync_start;
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 1/2] drm/dp: add defines for downstream port types

Detailed cap info at address 80h is not available with DPCD ver
1.0. Whether such devices exist in the wild I don't know, but there
should be no harm done in having the defines for downstream port 0 in
address 05h.

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 include/drm/drm_dp_helper.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ae8dbfb..83da4eb 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -77,10 +77,10 @@
 #define DP_DOWNSTREAMPORT_PRESENT   0x005
 # define DP_DWN_STRM_PORT_PRESENT   (1  0)
 # define DP_DWN_STRM_PORT_TYPE_MASK 0x06
-/* 00b = DisplayPort */
-/* 01b = Analog */
-/* 10b = TMDS or HDMI */
-/* 11b = Other */
+# define DP_DWN_STRM_PORT_TYPE_DP   (0  1)
+# define DP_DWN_STRM_PORT_TYPE_ANALOG   (1  1)
+# define DP_DWN_STRM_PORT_TYPE_TMDS (2  1)
+# define DP_DWN_STRM_PORT_TYPE_OTHER(3  1)
 # define DP_FORMAT_CONVERSION   (1  3)
 # define DP_DETAILED_CAP_INFO_AVAILABLE(1  4) /* DPI */
 
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/2] drm/i915/dp: downstream port capabilities are not present in DPCD 1.0

We haven't read the downstream port caps for DPCD 1.0, so don't use
them.

v2: use defines for DPCD 1.0 downstream port types

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..2f04f0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2817,7 +2817,6 @@ static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
uint8_t *dpcd = intel_dp-dpcd;
-   bool hpd;
uint8_t type;
 
if (!intel_dp_get_dpcd(intel_dp))
@@ -2828,8 +2827,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
 
/* If we're HPD-aware, SINK_COUNT changes dynamically */
-   hpd = !!(intel_dp-downstream_ports[0]  DP_DS_PORT_HPD);
-   if (hpd) {
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
+   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
uint8_t reg;
if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
reg, 1))
@@ -2843,9 +2842,18 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
 
/* Well we tried, say unknown for unreliable port types */
-   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
-   if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
-   return connector_status_unknown;
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11) {
+   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
+   if (type == DP_DS_PORT_TYPE_VGA ||
+   type == DP_DS_PORT_TYPE_NON_EDID)
+   return connector_status_unknown;
+   } else {
+   type = intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT] 
+   DP_DWN_STRM_PORT_TYPE_MASK;
+   if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
+   type == DP_DWN_STRM_PORT_TYPE_OTHER)
+   return connector_status_unknown;
+   }
 
/* Anything else is out of spec, warn and ignore */
DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: retry i2c-over-aux seven times on AUX DEFER

On Fri, 20 Sep 2013, Todd Previte tprev...@gmail.com wrote:
 On 09/20/2013 06:42 AM, Jani Nikula wrote:
 Per DP1.2 spec.

 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
   drivers/gpu/drm/i915/intel_dp.c |7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c
 index 9770160..6626514 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -654,7 +654,12 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int 
 mode,
  break;
  }
   
 -for (retry = 0; retry  5; retry++) {
 +/*
 + * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device is
 + * required to retry at least seven times upon receiving AUX_DEFER
 + * before giving up the AUX transaction.
 + */
 +for (retry = 0; retry  7; retry++) {
  ret = intel_dp_aux_ch(intel_dp,
msg, msg_bytes,
reply, reply_bytes);

 Hey Jani,

 Although it's not explicitly stated in the specification (I went through 
 both the 1.1a and 1.2a specifications and couldn't find it), I think the 
 the retry count of 7 applies to all AUX transactions, both native and 
 I2C. That's alluded to in the description of the link training sequence 
 (pg 382, 2nd paragraph from the bottom) where the sink may defer up to 
 seven times before the source can abort training.

 With that in mind, it might be a good idea to use a defined constant for 
 the retry count for both native and I2C AUX transactions. That would 
 keep it consistent throughout the code and be easier to update moving 
 forward should the specification change.

Todd, are you willing to give your reviewed-by on this one patch per our
irc discussion? We can do further cleanups later.

I've sent a new version of 3/4 with the #defines separately.


BR,
Jani.



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

Re: [Intel-gfx] [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll()

2013-09-27 Thread Mika Kuoppala

ville.syrj...@linux.intel.com writes:

 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
 an army of local variables.

 Also extract the code to calculate the derived values into
 vlv_clock().

 v2: Split up the earlier fixes, extract vlv_clock()

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/intel_display.c | 72 
 
  1 file changed, 31 insertions(+), 41 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index f646fea..c5f0794 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -438,6 +438,14 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
   clock-dot = clock-vco / clock-p;
  }
  
 +static void vlv_clock(int refclk, intel_clock_t *clock)
 +{
 + clock-m = clock-m1 * clock-m2;
 + clock-p = clock-p1 * clock-p2;
 + clock-vco = refclk * clock-m / clock-n;
 + clock-dot = clock-vco / clock-p;
 +}
 +
  /**
   * Returns whether any output on the specified pipe is of the specified type
   */
 @@ -670,66 +678,48 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
 drm_crtc *crtc,
  int target, int refclk, intel_clock_t *match_clock,
  intel_clock_t *best_clock)
  {
 - u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
 - u32 m, n, fastclk;
 - u32 updrate, minupdate, p;
 + intel_clock_t clock;
 + u32 minupdate = 19200;
   unsigned int bestppm = 100;
 - int dotclk, flag;
  
 - flag = 0;
 - dotclk = target * 1000;
 - fastclk = dotclk / (2*100);
 - updrate = 0;
 - minupdate = 19200;
 - n = p = p1 = p2 = m = m1 = m2 = vco = bestn = 0;
 - bestm1 = bestm2 = bestp1 = bestp2 = 0;
 + target *= 5; /* fast clock */
  
   /* based on hardware requirement, prefer smaller n to precision */
 - for (n = limit-n.min; n = ((refclk) / minupdate); n++) {
 - updrate = refclk / n;
 - for (p1 = limit-p1.max; p1  limit-p1.min; p1--) {
 - for (p2 = limit-p2.p2_fast+1; p2  0; p2--) {
 - if (p2  10)
 - p2 = p2 - 1;
 - p = p1 * p2;
 + for (clock.n = limit-n.min; clock.n = ((refclk) / minupdate); 
 clock.n++) {
 + for (clock.p1 = limit-p1.max; clock.p1  limit-p1.min; 
 clock.p1--) {
 + for (clock.p2 = limit-p2.p2_fast+1; clock.p2  0; 
 clock.p2--) {
 + if (clock.p2  10)
 + clock.p2--;
 + clock.p = clock.p1 * clock.p2;
   /* based on hardware requirement, prefer bigger 
 m1,m2 values */
 - for (m1 = limit-m1.min; m1 = limit-m1.max; 
 m1++) {
 + for (clock.m1 = limit-m1.min; clock.m1 = 
 limit-m1.max; clock.m1++) {
   unsigned int ppm, diff;
  
 - m2 = DIV_ROUND_CLOSEST(fastclk * p * n, 
 refclk * m1);
 - m = m1 * m2;
 - vco = updrate * m;
 + clock.m2 = DIV_ROUND_CLOSEST(target * 
 clock.p * clock.n,
 +  refclk * 
 clock.m1);
  
 - if (vco  limit-vco.min || vco = 
 limit-vco.max)
 + vlv_clock(refclk, clock);
 +
 + if (clock.vco  limit-vco.min ||
 + clock.vco = limit-vco.max)
   continue;
  
 - diff = abs(vco / p - fastclk);
 - ppm = div_u64(100ULL * diff, 
 fastclk);
 - if (ppm  100  ((p1 * p2)  (bestp1 * 
 bestp2))) {
 + diff = abs(clock.dot - target);
 + ppm = div_u64(100ULL * diff, 
 target);
 +
 + if (ppm  100  clock.p  
 best_clock-p) {

best_clock needs to be initialized or you end up comparing against
bytes from stack on first hitting here.

   bestppm = 0;
 - flag = 1;
 + *best_clock = clock;
   }
 +
   if (bestppm = 10  ppm  bestppm - 
 10) {
   bestppm = ppm;
 - flag = 1;
 - }
 - if (flag) {
 -

[Intel-gfx] [PATCH 1/3] drm/edid: add drm_edid_duplicate

We have some code duplication related to EDID duplication. Add a helper.

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/drm_edid.c |   12 
 include/drm/drm_crtc.h |1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c24af1d..412b80f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1264,6 +1264,18 @@ struct edid *drm_get_edid(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL(drm_get_edid);
 
+/**
+ * drm_edid_duplicate - duplicate an EDID and the extensions
+ * @edid: EDID to duplicate
+ *
+ * Return duplicate edid or NULL on allocation failure.
+ */
+struct edid *drm_edid_duplicate(const struct edid *edid)
+{
+   return kmemdup(edid, (edid-extensions + 1) * EDID_LENGTH, GFP_KERNEL);
+}
+EXPORT_SYMBOL(drm_edid_duplicate);
+
 /*** EDID parsing ***/
 
 /**
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b2d08ca..8ab633a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -980,6 +980,7 @@ extern int drm_mode_group_init_legacy_group(struct 
drm_device *dev, struct drm_m
 extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
+extern struct edid *drm_edid_duplicate(const struct edid *edid);
 extern int drm_add_edid_modes(struct drm_connector *connector, struct edid 
*edid);
 extern void drm_mode_probed_add(struct drm_connector *connector, struct 
drm_display_mode *mode);
 extern void drm_mode_copy(struct drm_display_mode *dst, const struct 
drm_display_mode *src);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/3] drm/i915/dp: use drm_edid_duplicate

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..aed9d67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2920,18 +2920,12 @@ intel_dp_get_edid(struct drm_connector *connector, 
struct i2c_adapter *adapter)
/* use cached edid if we have one */
if (intel_connector-edid) {
struct edid *edid;
-   int size;
 
/* invalid edid */
if (IS_ERR(intel_connector-edid))
return NULL;
 
-   size = (intel_connector-edid-extensions + 1) * EDID_LENGTH;
-   edid = kmemdup(intel_connector-edid, size, GFP_KERNEL);
-   if (!edid)
-   return NULL;
-
-   return edid;
+   return drm_edid_duplicate(edid);
}
 
return drm_get_edid(connector, adapter);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 3/3] drm/exynos: use drm_edid_duplicate

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4400330..26e089f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -101,7 +101,6 @@ static struct edid *vidi_get_edid(struct device *dev,
 {
struct vidi_context *ctx = get_vidi_context(dev);
struct edid *edid;
-   int edid_len;
 
/*
 * the edid data comes from user side and it would be set
@@ -112,8 +111,7 @@ static struct edid *vidi_get_edid(struct device *dev,
return ERR_PTR(-EFAULT);
}
 
-   edid_len = (1 + ctx-raw_edid-extensions) * EDID_LENGTH;
-   edid = kmemdup(ctx-raw_edid, edid_len, GFP_KERNEL);
+   edid = drm_edid_duplicate(ctx-raw_edid);
if (!edid) {
DRM_DEBUG_KMS(failed to allocate edid\n);
return ERR_PTR(-ENOMEM);
@@ -485,7 +483,6 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void 
*data,
struct exynos_drm_manager *manager;
struct exynos_drm_display_ops *display_ops;
struct drm_exynos_vidi_connection *vidi = data;
-   int edid_len;
 
if (!vidi) {
DRM_DEBUG_KMS(user data for vidi is null.\n);
@@ -524,8 +521,7 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void 
*data,
DRM_DEBUG_KMS(edid data is invalid.\n);
return -EINVAL;
}
-   edid_len = (1 + raw_edid-extensions) * EDID_LENGTH;
-   ctx-raw_edid = kmemdup(raw_edid, edid_len, GFP_KERNEL);
+   ctx-raw_edid = drm_edid_duplicate(raw_edid);
if (!ctx-raw_edid) {
DRM_DEBUG_KMS(failed to allocate raw_edid.\n);
return -ENOMEM;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time

Neither the DP spec nor the compliance test spec state or imply that we
should write the DP_TRAINING_PATTERN_SET at every voltage swing and
pre-emphasis change. Indeed we probably shouldn't. So don't.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
Signed-off-by: Jani Nikula jani.nik...@intel.com

---

I haven't tested this much, but it fixes the Zotac DP - dual-hdmi
dongle for me.
---
 drivers/gpu/drm/i915/intel_dp.c |  129 ++-
 1 file changed, 87 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..ab805d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2313,7 +2313,7 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp, 
uint32_t *DP)
 
 static bool
 intel_dp_set_link_train(struct intel_dp *intel_dp,
-   uint32_t dp_reg_value,
+   uint32_t *DP,
uint8_t dp_train_pat)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -2349,50 +2349,51 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
I915_WRITE(DP_TP_CTL(port), temp);
 
} else if (HAS_PCH_CPT(dev)  (IS_GEN7(dev) || port != PORT_A)) {
-   dp_reg_value = ~DP_LINK_TRAIN_MASK_CPT;
+   *DP = ~DP_LINK_TRAIN_MASK_CPT;
 
switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
-   dp_reg_value |= DP_LINK_TRAIN_OFF_CPT;
+   *DP |= DP_LINK_TRAIN_OFF_CPT;
break;
case DP_TRAINING_PATTERN_1:
-   dp_reg_value |= DP_LINK_TRAIN_PAT_1_CPT;
+   *DP |= DP_LINK_TRAIN_PAT_1_CPT;
break;
case DP_TRAINING_PATTERN_2:
-   dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
+   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
break;
case DP_TRAINING_PATTERN_3:
DRM_ERROR(DP training pattern 3 not supported\n);
-   dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
+   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
break;
}
 
} else {
-   dp_reg_value = ~DP_LINK_TRAIN_MASK;
+   *DP = ~DP_LINK_TRAIN_MASK;
 
switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
-   dp_reg_value |= DP_LINK_TRAIN_OFF;
+   *DP |= DP_LINK_TRAIN_OFF;
break;
case DP_TRAINING_PATTERN_1:
-   dp_reg_value |= DP_LINK_TRAIN_PAT_1;
+   *DP |= DP_LINK_TRAIN_PAT_1;
break;
case DP_TRAINING_PATTERN_2:
-   dp_reg_value |= DP_LINK_TRAIN_PAT_2;
+   *DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
DRM_ERROR(DP training pattern 3 not supported\n);
-   dp_reg_value |= DP_LINK_TRAIN_PAT_2;
+   *DP |= DP_LINK_TRAIN_PAT_2;
break;
}
}
 
-   I915_WRITE(intel_dp-output_reg, dp_reg_value);
+   I915_WRITE(intel_dp-output_reg, *DP);
POSTING_READ(intel_dp-output_reg);
 
-   intel_dp_aux_native_write_1(intel_dp,
-   DP_TRAINING_PATTERN_SET,
-   dp_train_pat);
+   ret = intel_dp_aux_native_write_1(intel_dp, DP_TRAINING_PATTERN_SET,
+ dp_train_pat);
+   if (ret != 1)
+   return false;
 
if ((dp_train_pat  DP_TRAINING_PATTERN_MASK) !=
DP_TRAINING_PATTERN_DISABLE) {
@@ -2407,6 +2408,37 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
return true;
 }
 
+static bool
+intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+   uint8_t dp_train_pat)
+{
+   memset(intel_dp-train_set, 0, 4);
+   intel_dp_set_signal_levels(intel_dp, DP);
+   return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
+}
+
+static bool
+intel_dp_update_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+  uint8_t link_status[DP_LINK_STATUS_SIZE])
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   int ret;
+
+   intel_get_adjust_train(intel_dp, link_status);
+   intel_dp_set_signal_levels(intel_dp, DP);
+
+   I915_WRITE(intel_dp-output_reg, *DP);
+   POSTING_READ(intel_dp-output_reg);
+
+   ret = intel_dp_aux_native_write(intel_dp,

Re: [Intel-gfx] [PATCH 1/3] drm/edid: add drm_edid_duplicate

On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
 We have some code duplication related to EDID duplication. Add a helper.

Lgtm, debated the merits of assuming GFP_KERNEL and inlining, then thought
better of it.

All 3, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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

Re: [Intel-gfx] [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll()

On Thu, Sep 26, 2013 at 06:30:55PM +0300, Mika Kuoppala wrote:
 ville.syrj...@linux.intel.com writes:
 
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
  an army of local variables.
 
  Also extract the code to calculate the derived values into
  vlv_clock().
 
  v2: Split up the earlier fixes, extract vlv_clock()
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 72 
  
   1 file changed, 31 insertions(+), 41 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index f646fea..c5f0794 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -438,6 +438,14 @@ static void i9xx_clock(int refclk, intel_clock_t 
  *clock)
  clock-dot = clock-vco / clock-p;
   }
   
  +static void vlv_clock(int refclk, intel_clock_t *clock)
  +{
  +   clock-m = clock-m1 * clock-m2;
  +   clock-p = clock-p1 * clock-p2;
  +   clock-vco = refclk * clock-m / clock-n;
  +   clock-dot = clock-vco / clock-p;
  +}
  +
   /**
* Returns whether any output on the specified pipe is of the specified 
  type
*/
  @@ -670,66 +678,48 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
  drm_crtc *crtc,
 int target, int refclk, intel_clock_t *match_clock,
 intel_clock_t *best_clock)
   {
  -   u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
  -   u32 m, n, fastclk;
  -   u32 updrate, minupdate, p;
  +   intel_clock_t clock;
  +   u32 minupdate = 19200;
  unsigned int bestppm = 100;
  -   int dotclk, flag;
   
  -   flag = 0;
  -   dotclk = target * 1000;
  -   fastclk = dotclk / (2*100);
  -   updrate = 0;
  -   minupdate = 19200;
  -   n = p = p1 = p2 = m = m1 = m2 = vco = bestn = 0;
  -   bestm1 = bestm2 = bestp1 = bestp2 = 0;
  +   target *= 5; /* fast clock */
   
  /* based on hardware requirement, prefer smaller n to precision */
  -   for (n = limit-n.min; n = ((refclk) / minupdate); n++) {
  -   updrate = refclk / n;
  -   for (p1 = limit-p1.max; p1  limit-p1.min; p1--) {
  -   for (p2 = limit-p2.p2_fast+1; p2  0; p2--) {
  -   if (p2  10)
  -   p2 = p2 - 1;
  -   p = p1 * p2;
  +   for (clock.n = limit-n.min; clock.n = ((refclk) / minupdate); 
  clock.n++) {
  +   for (clock.p1 = limit-p1.max; clock.p1  limit-p1.min; 
  clock.p1--) {
  +   for (clock.p2 = limit-p2.p2_fast+1; clock.p2  0; 
  clock.p2--) {
  +   if (clock.p2  10)
  +   clock.p2--;
  +   clock.p = clock.p1 * clock.p2;
  /* based on hardware requirement, prefer bigger 
  m1,m2 values */
 
 Is this comment valid as we seem to start from m1.min?

We anyway try to find the closest m2 based on m1,n,p1 and p2, and since
we start w/ large p dividers, m1*m2 will come out as something big to
compensate. Though starting with small n does mean m2 doesn't come out
as large as it could be, but I guess having a small n is considered
more important than having a large m.

The bestppm comparison we do guarantees that we prefer an earlier result
unless the new ppm is at least 10 better, and since we start with small
n and large p, it should do what we want.

Then there's ppm100 comparison which is a bit different. It means we
favor anything that is considered good enough (ppm  100) as long as
the p divider increases, and hence the VCO frequency increases. That
would seem to be in line with the other stated goals of big m and small n.

 
  -   for (m1 = limit-m1.min; m1 = limit-m1.max; 
  m1++) {
  +   for (clock.m1 = limit-m1.min; clock.m1 = 
  limit-m1.max; clock.m1++) {
  unsigned int ppm, diff;
   
  -   m2 = DIV_ROUND_CLOSEST(fastclk * p * n, 
  refclk * m1);
  -   m = m1 * m2;
  -   vco = updrate * m;
  +   clock.m2 = DIV_ROUND_CLOSEST(target * 
  clock.p * clock.n,
  +refclk * 
  clock.m1);
   
  -   if (vco  limit-vco.min || vco = 
  limit-vco.max)
  +   vlv_clock(refclk, clock);
  +
 
  +   if (clock.vco  limit-vco.min ||
  +   clock.vco = limit-vco.max)
  continue;
 
 Can intel_PLL_is_valid() used here instead of just checking the vco?

We'd need to modify intel_PLL_is_valid() a bit to skip the m1=m2 check,
and we'd also need to skip the 'm' and 'p' divider

Re: [Intel-gfx] [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll()

On Fri, Sep 27, 2013 at 02:55:32PM +0300, Mika Kuoppala wrote:
 ville.syrj...@linux.intel.com writes:
 
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
  an army of local variables.
 
  Also extract the code to calculate the derived values into
  vlv_clock().
 
  v2: Split up the earlier fixes, extract vlv_clock()
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 72 
  
   1 file changed, 31 insertions(+), 41 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index f646fea..c5f0794 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -438,6 +438,14 @@ static void i9xx_clock(int refclk, intel_clock_t 
  *clock)
  clock-dot = clock-vco / clock-p;
   }
   
  +static void vlv_clock(int refclk, intel_clock_t *clock)
  +{
  +   clock-m = clock-m1 * clock-m2;
  +   clock-p = clock-p1 * clock-p2;
  +   clock-vco = refclk * clock-m / clock-n;
  +   clock-dot = clock-vco / clock-p;
  +}
  +
   /**
* Returns whether any output on the specified pipe is of the specified 
  type
*/
  @@ -670,66 +678,48 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
  drm_crtc *crtc,
 int target, int refclk, intel_clock_t *match_clock,
 intel_clock_t *best_clock)
   {
  -   u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
  -   u32 m, n, fastclk;
  -   u32 updrate, minupdate, p;
  +   intel_clock_t clock;
  +   u32 minupdate = 19200;
  unsigned int bestppm = 100;
  -   int dotclk, flag;
   
  -   flag = 0;
  -   dotclk = target * 1000;
  -   fastclk = dotclk / (2*100);
  -   updrate = 0;
  -   minupdate = 19200;
  -   n = p = p1 = p2 = m = m1 = m2 = vco = bestn = 0;
  -   bestm1 = bestm2 = bestp1 = bestp2 = 0;
  +   target *= 5; /* fast clock */
   
  /* based on hardware requirement, prefer smaller n to precision */
  -   for (n = limit-n.min; n = ((refclk) / minupdate); n++) {
  -   updrate = refclk / n;
  -   for (p1 = limit-p1.max; p1  limit-p1.min; p1--) {
  -   for (p2 = limit-p2.p2_fast+1; p2  0; p2--) {
  -   if (p2  10)
  -   p2 = p2 - 1;
  -   p = p1 * p2;
  +   for (clock.n = limit-n.min; clock.n = ((refclk) / minupdate); 
  clock.n++) {
  +   for (clock.p1 = limit-p1.max; clock.p1  limit-p1.min; 
  clock.p1--) {
  +   for (clock.p2 = limit-p2.p2_fast+1; clock.p2  0; 
  clock.p2--) {
  +   if (clock.p2  10)
  +   clock.p2--;
  +   clock.p = clock.p1 * clock.p2;
  /* based on hardware requirement, prefer bigger 
  m1,m2 values */
  -   for (m1 = limit-m1.min; m1 = limit-m1.max; 
  m1++) {
  +   for (clock.m1 = limit-m1.min; clock.m1 = 
  limit-m1.max; clock.m1++) {
  unsigned int ppm, diff;
   
  -   m2 = DIV_ROUND_CLOSEST(fastclk * p * n, 
  refclk * m1);
  -   m = m1 * m2;
  -   vco = updrate * m;
  +   clock.m2 = DIV_ROUND_CLOSEST(target * 
  clock.p * clock.n,
  +refclk * 
  clock.m1);
   
  -   if (vco  limit-vco.min || vco = 
  limit-vco.max)
  +   vlv_clock(refclk, clock);
  +
  +   if (clock.vco  limit-vco.min ||
  +   clock.vco = limit-vco.max)
  continue;
   
  -   diff = abs(vco / p - fastclk);
  -   ppm = div_u64(100ULL * diff, 
  fastclk);
  -   if (ppm  100  ((p1 * p2)  (bestp1 * 
  bestp2))) {
  +   diff = abs(clock.dot - target);
  +   ppm = div_u64(100ULL * diff, 
  target);
  +
  +   if (ppm  100  clock.p  
  best_clock-p) {
 
 best_clock needs to be initialized or you end up comparing against
 bytes from stack on first hitting here.

Right. v3 coming up.

 
  bestppm = 0;
  -   flag = 1;
  +   *best_clock = clock;
  }
  +
  if (bestppm = 10  ppm  bestppm - 
  10) {
  bestppm = ppm;
  -   flag = 1;
  -

[Intel-gfx] [PATCH v3 05/14] drm/i915: Rewrite vlv_find_best_dpll()

2013-09-27 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
an army of local variables.

Also extract the code to calculate the derived values into
vlv_clock().

v2: Split up the earlier fixes, extract vlv_clock()
v3: Initialize best_clock

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 74 
 1 file changed, 33 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f646fea..9faf3bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -438,6 +438,14 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
clock-dot = clock-vco / clock-p;
 }
 
+static void vlv_clock(int refclk, intel_clock_t *clock)
+{
+   clock-m = clock-m1 * clock-m2;
+   clock-p = clock-p1 * clock-p2;
+   clock-vco = refclk * clock-m / clock-n;
+   clock-dot = clock-vco / clock-p;
+}
+
 /**
  * Returns whether any output on the specified pipe is of the specified type
  */
@@ -670,66 +678,50 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
drm_crtc *crtc,
   int target, int refclk, intel_clock_t *match_clock,
   intel_clock_t *best_clock)
 {
-   u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
-   u32 m, n, fastclk;
-   u32 updrate, minupdate, p;
+   intel_clock_t clock;
+   u32 minupdate = 19200;
unsigned int bestppm = 100;
-   int dotclk, flag;
 
-   flag = 0;
-   dotclk = target * 1000;
-   fastclk = dotclk / (2*100);
-   updrate = 0;
-   minupdate = 19200;
-   n = p = p1 = p2 = m = m1 = m2 = vco = bestn = 0;
-   bestm1 = bestm2 = bestp1 = bestp2 = 0;
+   target *= 5; /* fast clock */
+
+   memset(best_clock, 0, sizeof(*best_clock));
 
/* based on hardware requirement, prefer smaller n to precision */
-   for (n = limit-n.min; n = ((refclk) / minupdate); n++) {
-   updrate = refclk / n;
-   for (p1 = limit-p1.max; p1  limit-p1.min; p1--) {
-   for (p2 = limit-p2.p2_fast+1; p2  0; p2--) {
-   if (p2  10)
-   p2 = p2 - 1;
-   p = p1 * p2;
+   for (clock.n = limit-n.min; clock.n = ((refclk) / minupdate); 
clock.n++) {
+   for (clock.p1 = limit-p1.max; clock.p1  limit-p1.min; 
clock.p1--) {
+   for (clock.p2 = limit-p2.p2_fast+1; clock.p2  0; 
clock.p2--) {
+   if (clock.p2  10)
+   clock.p2--;
+   clock.p = clock.p1 * clock.p2;
/* based on hardware requirement, prefer bigger 
m1,m2 values */
-   for (m1 = limit-m1.min; m1 = limit-m1.max; 
m1++) {
+   for (clock.m1 = limit-m1.min; clock.m1 = 
limit-m1.max; clock.m1++) {
unsigned int ppm, diff;
 
-   m2 = DIV_ROUND_CLOSEST(fastclk * p * n, 
refclk * m1);
-   m = m1 * m2;
-   vco = updrate * m;
+   clock.m2 = DIV_ROUND_CLOSEST(target * 
clock.p * clock.n,
+refclk * 
clock.m1);
+
+   vlv_clock(refclk, clock);
 
-   if (vco  limit-vco.min || vco = 
limit-vco.max)
+   if (clock.vco  limit-vco.min ||
+   clock.vco = limit-vco.max)
continue;
 
-   diff = abs(vco / p - fastclk);
-   ppm = div_u64(100ULL * diff, 
fastclk);
-   if (ppm  100  ((p1 * p2)  (bestp1 * 
bestp2))) {
+   diff = abs(clock.dot - target);
+   ppm = div_u64(100ULL * diff, 
target);
+
+   if (ppm  100  clock.p  
best_clock-p) {
bestppm = 0;
-   flag = 1;
+   *best_clock = clock;
}
+
if (bestppm = 10  ppm  bestppm - 
10) {
bestppm = ppm;
-   flag = 1;
-   }
-   if (flag) {
-   bestn = n;
-

[Intel-gfx] [PATCH 15/14] drm/i915: Use intel_PLL_is_valid() in vlv_find_best_dpll()

2013-09-27 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

Everyone else uses intel_PLL_is_valid(), so make VLV use it as well.

We don't have any special p and m limits on VLV, so skip those tests,
and we also need to skip the m1=m2 test line PNV.

Reorganize the function a bit to move the n check alongside the rest of
the test for the non-derived dividers, and check the derived values
afterwards.

Note that this changes vlv_find_best_dpll() in two ways:
- The .vco comparison is now max instead of =max, and since we round
  down when calculating that stuff, we may now allow frequencies slightly
  above the max as we do on other platforms. The previous method
  disallowed exactly max and anything above it.
- We now check the .dot frequency against the data rate limits, which we
  didn't do before.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6429cbb..11d3ddf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -311,7 +311,13 @@ static const intel_limit_t 
intel_limits_ironlake_dual_lvds_100m = {
 };
 
 static const intel_limit_t intel_limits_vlv = {
-   .dot = { .min = 25000, .max = 27 },
+/*
+ * These are the data rate limits (measured in fast clocks)
+ * since those are the strictest limits we have. The fast
+ * clock and actual rate limits are more relaxed, so checking
+ * them would make no difference.
+ */
+   .dot = { .min = 25000 * 5, .max = 27 * 5 },
.vco = { .min = 400, .max = 600 },
.n = { .min = 1, .max = 7 },
.m1 = { .min = 2, .max = 3 },
@@ -452,20 +458,26 @@ static bool intel_PLL_is_valid(struct drm_device *dev,
   const intel_limit_t *limit,
   const intel_clock_t *clock)
 {
+   if (clock-nlimit-n.min   || limit-n.maxclock-n)
+   INTELPllInvalid(n out of range\n);
if (clock-p1   limit-p1.min  || limit-p1.max   clock-p1)
INTELPllInvalid(p1 out of range\n);
-   if (clock-plimit-p.min   || limit-p.maxclock-p)
-   INTELPllInvalid(p out of range\n);
if (clock-m2   limit-m2.min  || limit-m2.max   clock-m2)
INTELPllInvalid(m2 out of range\n);
if (clock-m1   limit-m1.min  || limit-m1.max   clock-m1)
INTELPllInvalid(m1 out of range\n);
-   if (clock-m1 = clock-m2  !IS_PINEVIEW(dev))
-   INTELPllInvalid(m1 = m2\n);
-   if (clock-mlimit-m.min   || limit-m.maxclock-m)
-   INTELPllInvalid(m out of range\n);
-   if (clock-nlimit-n.min   || limit-n.maxclock-n)
-   INTELPllInvalid(n out of range\n);
+
+   if (!IS_PINEVIEW(dev)  !IS_VALLEYVIEW(dev))
+   if (clock-m1 = clock-m2)
+   INTELPllInvalid(m1 = m2\n);
+
+   if (!IS_VALLEYVIEW(dev)) {
+   if (clock-p  limit-p.min || limit-p.max  clock-p)
+   INTELPllInvalid(p out of range\n);
+   if (clock-m  limit-m.min || limit-m.max  clock-m)
+   INTELPllInvalid(m out of range\n);
+   }
+
if (clock-vco  limit-vco.min || limit-vco.max  clock-vco)
INTELPllInvalid(vco out of range\n);
/* XXX: We may need to be checking Dot clock depending on the 
multiplier,
@@ -659,6 +671,7 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
drm_crtc *crtc,
   int target, int refclk, intel_clock_t *match_clock,
   intel_clock_t *best_clock)
 {
+   struct drm_device *dev = crtc-dev;
intel_clock_t clock;
unsigned int bestppm = 100;
/* min update 19.2 MHz */
@@ -684,8 +697,8 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
drm_crtc *crtc,
 
vlv_clock(refclk, clock);
 
-   if (clock.vco  limit-vco.min ||
-   clock.vco = limit-vco.max)
+   if (!intel_PLL_is_valid(dev, limit,
+   clock))
continue;
 
diff = abs(clock.dot - target);
-- 
1.8.1.5

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time

2013-09-27 Thread Paulo Zanoni

2013/9/27 Jani Nikula jani.nik...@intel.com:
 Neither the DP spec nor the compliance test spec state or imply that we
 should write the DP_TRAINING_PATTERN_SET at every voltage swing and
 pre-emphasis change. Indeed we probably shouldn't. So don't.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
 Signed-off-by: Jani Nikula jani.nik...@intel.com

 ---

 I haven't tested this much, but it fixes the Zotac DP - dual-hdmi
 dongle for me.

Still boots Haswell with eDP+DP, no new error messages. I'll leave the
review to Todd :)

Smoke-tested-by: Paulo Zanoni paulo.r.zan...@intel.com

 ---
  drivers/gpu/drm/i915/intel_dp.c |  129 
 ++-
  1 file changed, 87 insertions(+), 42 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 95a3159..ab805d3 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -2313,7 +2313,7 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp, 
 uint32_t *DP)

  static bool
  intel_dp_set_link_train(struct intel_dp *intel_dp,
 -   uint32_t dp_reg_value,
 +   uint32_t *DP,
 uint8_t dp_train_pat)
  {
 struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 @@ -2349,50 +2349,51 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
 I915_WRITE(DP_TP_CTL(port), temp);

 } else if (HAS_PCH_CPT(dev)  (IS_GEN7(dev) || port != PORT_A)) {
 -   dp_reg_value = ~DP_LINK_TRAIN_MASK_CPT;
 +   *DP = ~DP_LINK_TRAIN_MASK_CPT;

 switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
 case DP_TRAINING_PATTERN_DISABLE:
 -   dp_reg_value |= DP_LINK_TRAIN_OFF_CPT;
 +   *DP |= DP_LINK_TRAIN_OFF_CPT;
 break;
 case DP_TRAINING_PATTERN_1:
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_1_CPT;
 +   *DP |= DP_LINK_TRAIN_PAT_1_CPT;
 break;
 case DP_TRAINING_PATTERN_2:
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
 +   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
 break;
 case DP_TRAINING_PATTERN_3:
 DRM_ERROR(DP training pattern 3 not supported\n);
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
 +   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
 break;
 }

 } else {
 -   dp_reg_value = ~DP_LINK_TRAIN_MASK;
 +   *DP = ~DP_LINK_TRAIN_MASK;

 switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
 case DP_TRAINING_PATTERN_DISABLE:
 -   dp_reg_value |= DP_LINK_TRAIN_OFF;
 +   *DP |= DP_LINK_TRAIN_OFF;
 break;
 case DP_TRAINING_PATTERN_1:
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_1;
 +   *DP |= DP_LINK_TRAIN_PAT_1;
 break;
 case DP_TRAINING_PATTERN_2:
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_2;
 +   *DP |= DP_LINK_TRAIN_PAT_2;
 break;
 case DP_TRAINING_PATTERN_3:
 DRM_ERROR(DP training pattern 3 not supported\n);
 -   dp_reg_value |= DP_LINK_TRAIN_PAT_2;
 +   *DP |= DP_LINK_TRAIN_PAT_2;
 break;
 }
 }

 -   I915_WRITE(intel_dp-output_reg, dp_reg_value);
 +   I915_WRITE(intel_dp-output_reg, *DP);
 POSTING_READ(intel_dp-output_reg);

 -   intel_dp_aux_native_write_1(intel_dp,
 -   DP_TRAINING_PATTERN_SET,
 -   dp_train_pat);
 +   ret = intel_dp_aux_native_write_1(intel_dp, DP_TRAINING_PATTERN_SET,
 + dp_train_pat);
 +   if (ret != 1)
 +   return false;

 if ((dp_train_pat  DP_TRAINING_PATTERN_MASK) !=
 DP_TRAINING_PATTERN_DISABLE) {
 @@ -2407,6 +2408,37 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
 return true;
  }

 +static bool
 +intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
 +   uint8_t dp_train_pat)
 +{
 +   memset(intel_dp-train_set, 0, 4);
 +   intel_dp_set_signal_levels(intel_dp, DP);
 +   return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
 +}
 +
 +static bool
 +intel_dp_update_link_train(struct intel_dp *intel_dp, uint32_t *DP,
 +  uint8_t link_status[DP_LINK_STATUS_SIZE])
 +{
 +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 +   struct drm_device *dev = intel_dig_port-base.base.dev;
 +   struct drm_i915_private *dev_priv =

Re: [Intel-gfx] [PATCH] drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time

On Fri, Sep 27, 2013 at 03:10:44PM +0300, Jani Nikula wrote:
 Neither the DP spec nor the compliance test spec state or imply that we
 should write the DP_TRAINING_PATTERN_SET at every voltage swing and
 pre-emphasis change. Indeed we probably shouldn't. So don't.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
 Signed-off-by: Jani Nikula jani.nik...@intel.com
 
 ---
 
 I haven't tested this much, but it fixes the Zotac DP - dual-hdmi
 dongle for me.
 ---
  drivers/gpu/drm/i915/intel_dp.c |  129 
 ++-
  1 file changed, 87 insertions(+), 42 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 95a3159..ab805d3 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -2313,7 +2313,7 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp, 
 uint32_t *DP)
  
  static bool
  intel_dp_set_link_train(struct intel_dp *intel_dp,
 - uint32_t dp_reg_value,
 + uint32_t *DP,
   uint8_t dp_train_pat)
  {
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 @@ -2349,50 +2349,51 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
   I915_WRITE(DP_TP_CTL(port), temp);
  
   } else if (HAS_PCH_CPT(dev)  (IS_GEN7(dev) || port != PORT_A)) {
 - dp_reg_value = ~DP_LINK_TRAIN_MASK_CPT;
 + *DP = ~DP_LINK_TRAIN_MASK_CPT;
  
   switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
   case DP_TRAINING_PATTERN_DISABLE:
 - dp_reg_value |= DP_LINK_TRAIN_OFF_CPT;
 + *DP |= DP_LINK_TRAIN_OFF_CPT;
   break;
   case DP_TRAINING_PATTERN_1:
 - dp_reg_value |= DP_LINK_TRAIN_PAT_1_CPT;
 + *DP |= DP_LINK_TRAIN_PAT_1_CPT;
   break;
   case DP_TRAINING_PATTERN_2:
 - dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
 + *DP |= DP_LINK_TRAIN_PAT_2_CPT;
   break;
   case DP_TRAINING_PATTERN_3:
   DRM_ERROR(DP training pattern 3 not supported\n);
 - dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
 + *DP |= DP_LINK_TRAIN_PAT_2_CPT;
   break;
   }
  
   } else {
 - dp_reg_value = ~DP_LINK_TRAIN_MASK;
 + *DP = ~DP_LINK_TRAIN_MASK;
  
   switch (dp_train_pat  DP_TRAINING_PATTERN_MASK) {
   case DP_TRAINING_PATTERN_DISABLE:
 - dp_reg_value |= DP_LINK_TRAIN_OFF;
 + *DP |= DP_LINK_TRAIN_OFF;
   break;
   case DP_TRAINING_PATTERN_1:
 - dp_reg_value |= DP_LINK_TRAIN_PAT_1;
 + *DP |= DP_LINK_TRAIN_PAT_1;
   break;
   case DP_TRAINING_PATTERN_2:
 - dp_reg_value |= DP_LINK_TRAIN_PAT_2;
 + *DP |= DP_LINK_TRAIN_PAT_2;
   break;
   case DP_TRAINING_PATTERN_3:
   DRM_ERROR(DP training pattern 3 not supported\n);
 - dp_reg_value |= DP_LINK_TRAIN_PAT_2;
 + *DP |= DP_LINK_TRAIN_PAT_2;
   break;
   }
   }
  
 - I915_WRITE(intel_dp-output_reg, dp_reg_value);
 + I915_WRITE(intel_dp-output_reg, *DP);
   POSTING_READ(intel_dp-output_reg);
  
 - intel_dp_aux_native_write_1(intel_dp,
 - DP_TRAINING_PATTERN_SET,
 - dp_train_pat);
 + ret = intel_dp_aux_native_write_1(intel_dp, DP_TRAINING_PATTERN_SET,
 +   dp_train_pat);
 + if (ret != 1)
 + return false;

As a followup patch I think we should do a burst write here with the
pattern and lane set.

My rationale from the spec:
The upstream device may start Full Link Training with non-minimum
differential voltage swing and/or non-zero pre-emphasis and/or non-zero
Post Cursor2 if the optimal setting is already known, for example, as
is the case in embedded application. In this case, the upstream device
must write the swing and pre-emphasis settings at which it is starting
training to TRAINING_LANEx_SET as part of the burst write in which it
writes 21h to TRAINING_PATTERN_SET. If non-zero Post Cursor 2 is used,
then the transmitter must write the post cursor 2 setting to the LANEx
POST CURSOR2 SET fields immediately after writing 21h to TRAINING_PATTERN_SET.

Now, we don't currently start training using non-zero values, but if we
decide to do it in the future, this little bit of detail would be easy
to overlook, and then we're again left with some random failures no-one
is able to figure out.

The ordering here is also a bit questionable without the burst write.
The spec says in one

Re: [Intel-gfx] [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh

On Thu, 26 Sep 2013, Aaron Lu wrote:
 I checked the git log for the commit to use tpacpi_acpi_handle_locate to
 locate video controller's ACPI handle, it's:
 
 commit 122f26726b5e16174bf8a707df14be1d93c49d62
 Author: Henrique de Moraes Holschuh h...@hmh.eng.br
 Date:   Mon Aug 9 23:48:18 2010 -0300

Yeah...

 So I checked out that commit and found that it shouldn't work either,
 since it has the same problem of the current code.
 
 The ACPI video controller device is given an id of ACPI_VIDEO_HID, but
 it's only known to Linux ACPI, not ACPICA, so the function provided by
 ACPICA acpi_get_devices will not work in this case, as that function will
 really check the control method of _HID under the handle, which does not
 exist no matter if Linux ACPI has added an id to its device structure or
 not. OTOH, the function provided by Linux ACPI acpi_device_hid will see
 the added id. In a word, the add of the HID will not affect the ASL
 namespace layout of the device node(thus, no _HID control method will
 be added to the device node).

Erk.  It went broken for a long time, and the users didn't notice(!)...

 commit ff413195e830541afeae469fc866ecd0319abd7e
 Author: Alex Hung alex.h...@canonical.com
 Date:   Tue Apr 24 16:40:52 2012 +0800
 
 thinkpad-acpi: fix issuing duplicated key events for brightness up/down
 
 The tp_features.bright_acpimode will not be set correctly for brightness
 control because ACPI_VIDEO_HID will not be located in ACPI. As a result,
 a duplicated key event will always be sent. acpi_video_backlight_support()
 is sufficient to detect standard ACPI brightness control.
 
 Signed-off-by: Alex Hung alex.h...@canonical.com
 Signed-off-by: Matthew Garrett m...@redhat.com

Until that.  And unfortunately I did not connect the dots at the time.

Thanks for explaining the issue properly.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh

On Tue, 24 Sep 2013, Aaron Lu wrote:
 The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
 locate handle for ACPI video by HID, the problem is, ACPI video node
 doesn't really have HID defined(i.e. no _HID control method is defined
 for video device), so.. that function would fail. This can be solved by
 enhancing the callback function for acpi_get_devices, where we can use
 acpi_device_hid function to check if the ACPI node corresponds to a
 video controller.
 
 In addition to that, the _BCL control method only exists under a video
 output device node, not a video controller device node. So to evaluate
 _BCL, we need the handle of a video output device node, which is child
 of the located video controller node from tpacpi_acpi_handle_locate.
 
 The two fix are necessary for some Thinkpad models to emit notification
 on backlight hotkey press as a result of evaluation of _BCL.
 
 Signed-off-by: Aaron Lu aaron...@intel.com
 Tested-by: Igor Gnatenko i.gnatenko.br...@gmail.com

Some testing on a *60 (T60,X60...) would also be best, I cannot test this on
my T43.

Anyway, the code itself looks fine, so:

Acked-by: Henrique de Moraes Holschuh h...@hmh.eng.br

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Yves-Alexis Perez

On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
 Some testing on a *60 (T60,X60...) would also be best, I cannot test
 this on
 my T43.
 
 Anyway, the code itself looks fine, so:

I can test on T61, would that help?

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Code stereo layouts as an enum in the mode structure

On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
 Daniel noticed that it wasn't very smart to keep using one bit per stereo
 layout now that we don't have to or them. It's a nice final touch to the new
 stereo mode API extension that we should fix before committing to it.

Assuming you still trust me even though I didn't see this possibility
during my review of the original series :)

For the series:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

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

[Intel-gfx] [PATCH] drm/i915/vlv: reduce GT FIFO error info to a debug message

It indicates a probable BIOS bug, but it appears to be harmless, and
there's nothing the user can do about it anyway, so reduce to a debug
msg.  I've filed a bug with the BIOS folks about it anyway, so hopefully
they'll fix whatever GT SB read they were doing when the GT was off.

References: https://bugs.freedesktop.org/show_bug.cgi?id=69396
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 102fc49..10054b5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3804,7 +3804,8 @@ static void valleyview_enable_rps(struct drm_device *dev)
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
 
if ((gtfifodbg = I915_READ(GTFIFODBG))) {
-   DRM_ERROR(GT fifo had a previous error %x\n, gtfifodbg);
+   DRM_DEBUG_DRIVER(GT fifo had a previous error %x\n,
+gtfifodbg);
I915_WRITE(GTFIFODBG, gtfifodbg);
}
 
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh

On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
 On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
  Some testing on a *60 (T60,X60...) would also be best, I cannot test
  this on
  my T43.
  
  Anyway, the code itself looks fine, so:
 
 I can test on T61, would that help?

I think so.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: downstream port capabilities are not present in DPCD 1.0

2013-09-27 Thread Adam Jackson

On Fri, 2013-09-27 at 14:48 +0300, Jani Nikula wrote:
 We haven't read the downstream port caps for DPCD 1.0, so don't use
 them.
 
 v2: use defines for DPCD 1.0 downstream port types
 
 Signed-off-by: Jani Nikula jani.nik...@intel.com

I don't know if I've ever seen a DPCD 1.0 device, but the changes make
sense.  For the series:

Reviewed-by: Adam Jackson a...@redhat.com

- ajax

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

Re: [Intel-gfx] 3.12 regression: i915 warnings

On Fri, Sep 27, 2013 at 7:27 PM, Woody Suwalski terraluna...@gmail.com wrote:
Daniel Vetter wrote:

On Thu, Sep 26, 2013 at 2:36 PM, Woody Suwalski terraluna...@gmail.com
wrote:

Daniel, I have noticed these warnings on 3.12-rc1, did not go away on
3.12-rc2.
I see it only on EeePC with i915,not on ThinkPad with Radeon.
It is a 32-bit kernel with overlayfs and TuxOnIce patches, so not
perfectly
clean, however same config and patches on 3.11 do not show these issues.
No,sorry, did not have time to investigate further or bisect.If you have
a
quick test in mind - I will try ;-)

a) Please always cc: relevant mailing lists, not just your maintainer.
b) Please retest with latest drm-intel-fixes from
http://cgit.freedesktop.org/~danvet/drm-intel/
c) If that doesn't help please boot with drm.debug=0xe, reproduce the
issue once and attach the complete dmesg. Please make sure that it
contains everything from boot-up to the WARN.

Thanks, Daniel

For now I can do the last - a complete dmesg with drm.debug attached...
I have hoped that you were to reply Yawn, an old issue... 8-)

Here we go: Mode flag mismatch in the tv encoder, should be fixed with

http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=1062b81598bc00e2f6620e6f3788f8f8df2f01e7

Pull request is already out and patch is cc: stable, so should show up
in a kernel near you soon.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp: add defines for downstream port types

2013-09-27 Thread Todd Previte

Looks good.


Reviewed-by: Todd Previte tprev...@gmail.com


On Fri, Sep 27, 2013 at 4:48 AM, Jani Nikula jani.nik...@intel.com wrote:

 Detailed cap info at address 80h is not available with DPCD ver
 1.0. Whether such devices exist in the wild I don't know, but there
 should be no harm done in having the defines for downstream port 0 in
 address 05h.

 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  include/drm/drm_dp_helper.h |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
 index ae8dbfb..83da4eb 100644
 --- a/include/drm/drm_dp_helper.h
 +++ b/include/drm/drm_dp_helper.h
 @@ -77,10 +77,10 @@
  #define DP_DOWNSTREAMPORT_PRESENT   0x005
  # define DP_DWN_STRM_PORT_PRESENT   (1  0)
  # define DP_DWN_STRM_PORT_TYPE_MASK 0x06
 -/* 00b = DisplayPort */
 -/* 01b = Analog */
 -/* 10b = TMDS or HDMI */
 -/* 11b = Other */
 +# define DP_DWN_STRM_PORT_TYPE_DP   (0  1)
 +# define DP_DWN_STRM_PORT_TYPE_ANALOG   (1  1)
 +# define DP_DWN_STRM_PORT_TYPE_TMDS (2  1)
 +# define DP_DWN_STRM_PORT_TYPE_OTHER(3  1)
  # define DP_FORMAT_CONVERSION   (1  3)
  # define DP_DETAILED_CAP_INFO_AVAILABLE(1  4) /* DPI */

 --
 1.7.9.5


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: retry i2c-over-aux seven times on AUX DEFER

2013-09-27 Thread Todd Previte

Yep. Good to go.

Reviewed-by: Todd Previte tprev...@gmail.com


On Fri, Sep 27, 2013 at 4:51 AM, Jani Nikula jani.nik...@linux.intel.comwrote:

 On Fri, 20 Sep 2013, Todd Previte tprev...@gmail.com wrote:
  On 09/20/2013 06:42 AM, Jani Nikula wrote:
  Per DP1.2 spec.
 
  Signed-off-by: Jani Nikula jani.nik...@intel.com
  ---
drivers/gpu/drm/i915/intel_dp.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_dp.c
 b/drivers/gpu/drm/i915/intel_dp.c
  index 9770160..6626514 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -654,7 +654,12 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter,
 int mode,
   break;
   }
 
  -for (retry = 0; retry  5; retry++) {
  +/*
  + * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source
 device is
  + * required to retry at least seven times upon receiving AUX_DEFER
  + * before giving up the AUX transaction.
  + */
  +for (retry = 0; retry  7; retry++) {
   ret = intel_dp_aux_ch(intel_dp,
 msg, msg_bytes,
 reply, reply_bytes);
 
  Hey Jani,
 
  Although it's not explicitly stated in the specification (I went through
  both the 1.1a and 1.2a specifications and couldn't find it), I think the
  the retry count of 7 applies to all AUX transactions, both native and
  I2C. That's alluded to in the description of the link training sequence
  (pg 382, 2nd paragraph from the bottom) where the sink may defer up to
  seven times before the source can abort training.
 
  With that in mind, it might be a good idea to use a defined constant for
  the retry count for both native and I2C AUX transactions. That would
  keep it consistent throughout the code and be easier to update moving
  forward should the specification change.

 Todd, are you willing to give your reviewed-by on this one patch per our
 irc discussion? We can do further cleanups later.

 I've sent a new version of 3/4 with the #defines separately.


 BR,
 Jani.



 --
 Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH 0/7] gtt patches

On Fri, Sep 27, 2013 at 7:34 AM, Ben Widawsky b...@bwidawsk.net wrote:
 At this point it just seems like you're intentionally making it harder
 for me to ever merge PPGTT.

I have two issues with the merged patches:
1. There's a regression, and QA is meanwhile at the 3rd or so dupe
report. So it's not really an arcane corner case. And I've
specifically written a testcase for secure batch dispatching and
specifically asked you to test to make sure it catches the bugs we've
discussed, so I hope you understand I'm a bit underwhelmed that this
slept through.

2. I have a bit an issue with the currently merged code for rebasing
-internal. I only stumbled over that when I've tried to rebase
-internal and was a bit disappointed to see that despite that I've
raised this the first time your vm-bind/unbind patches showed up
nothing changed.

That's the firstlast patch.

The stuff in-between is to make rebasing -internal a bit easier (while
I need to do fixups anyway) since I really botched this 1-2 times
everytime there was a conflict. I've thought that the oustanding stuff
from your series only needs to touch the -enable callbacks in
i915_gem_gtt.c. A quick look at your ppgtt branches shows that in
addition to that there's only a now outdated cleanup patch and a
rather self-contained debugfs dumper on top. So my thinking was that
right now is an ideal time to polish i915_gem_gtt.c a bit.

But of course I'll drop cleanup patches when they conflict badly with
ongoing stuff, like I've done a few times already. But it didn't look
like this is the case here.

Now you seem to reject my patches, but I don't see any alternate
proposals from you. Furthermore to me it feels a bit the discussion
has derailed into non-constructive form a bit, so I guess this will
take a bit of time to resolve. Since I can't just hold public and
internal trees hostage until that's settled I'll drop your two vma
patches meanwhile.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/vlv: untangle integrated clock source handling

The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource.  It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
when pipe B shuts down.

I'm guessing on the references here, I expect this to bite any config
where multiple displays are active or displays are moved from pipe to
pipe.

References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0eeba84..def2473 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1386,6 +1386,13 @@ static void vlv_enable_pll(struct intel_crtc *crtc)
if (IS_MOBILE(dev_priv-dev)  !IS_I830(dev_priv-dev))
assert_panel_unlocked(dev_priv, crtc-pipe);
 
+   /* Make sure to use the integrated clock source */
+   if (!crtc-pipe)
+   I915_WRITE(DPLL(1), I915_READ(DPLL(1)) |
+  DPLL_INTEGRATED_CRI_CLK_VLV);
+   else
+   dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150);
@@ -1476,6 +1483,20 @@ static void i9xx_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
 }
 
+static void vlv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+{
+   u32 val = 0;
+
+   /* Make sure the pipe isn't still relying on us */
+   assert_pipe_disabled(dev_priv, pipe);
+
+   /* Leave integrated clock source enabled for the other pipe */
+   if (pipe)
+   val = I915_READ(DPLL(pipe))  DPLL_INTEGRATED_CRI_CLK_VLV;
+   I915_WRITE(DPLL(pipe), val);
+   POSTING_READ(DPLL(pipe));
+}
+
 void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
 {
u32 port_mask;
@@ -3886,7 +3907,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
if (encoder-post_disable)
encoder-post_disable(encoder);
 
-   if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+   if (IS_VALLEYVIEW(dev)  !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+   vlv_disable_pll(dev_priv, pipe);
+   else if (!IS_VALLEYVIEW(dev))
i9xx_disable_pll(dev_priv, pipe);
 
intel_crtc-active = false;
@@ -4626,8 +4649,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
/* Enable DPIO clock input */
dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
-   if (pipe)
-   dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
 
dpll |= DPLL_VCO_ENABLE;
crtc-config.dpll_hw_state.dpll = dpll;
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH 0/7] gtt patches

2013-09-27 Thread Ben Widawsky

On Fri, Sep 27, 2013 at 09:21:51PM +0200, Daniel Vetter wrote:
 On Fri, Sep 27, 2013 at 7:34 AM, Ben Widawsky b...@bwidawsk.net wrote:
  At this point it just seems like you're intentionally making it harder
  for me to ever merge PPGTT.
 
 I have two issues with the merged patches:
 1. There's a regression, and QA is meanwhile at the 3rd or so dupe
 report. So it's not really an arcane corner case. And I've
 specifically written a testcase for secure batch dispatching and
 specifically asked you to test to make sure it catches the bugs we've
 discussed, so I hope you understand I'm a bit underwhelmed that this
 slept through.
 
 2. I have a bit an issue with the currently merged code for rebasing
 -internal. I only stumbled over that when I've tried to rebase
 -internal and was a bit disappointed to see that despite that I've
 raised this the first time your vm-bind/unbind patches showed up
 nothing changed.
 
 That's the firstlast patch.
 
 The stuff in-between is to make rebasing -internal a bit easier (while
 I need to do fixups anyway) since I really botched this 1-2 times
 everytime there was a conflict. I've thought that the oustanding stuff
 from your series only needs to touch the -enable callbacks in
 i915_gem_gtt.c. A quick look at your ppgtt branches shows that in
 addition to that there's only a now outdated cleanup patch and a
 rather self-contained debugfs dumper on top. So my thinking was that
 right now is an ideal time to polish i915_gem_gtt.c a bit.
 
 But of course I'll drop cleanup patches when they conflict badly with
 ongoing stuff, like I've done a few times already. But it didn't look
 like this is the case here.
 
 Now you seem to reject my patches, but I don't see any alternate
 proposals from you. Furthermore to me it feels a bit the discussion
 has derailed into non-constructive form a bit, so I guess this will
 take a bit of time to resolve. Since I can't just hold public and
 internal trees hostage until that's settled I'll drop your two vma
 patches meanwhile.
 
 Cheers, Daniel

I do not plan to develop PPGTT any further. Please feel free to revert
as many patches as you'd like.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Program GMBUS Frequency based on the CDCLK for VLV.

On Fri, Sep 27, 2013 at 01:07:19PM +0300, Ville Syrjälä wrote:
 On Fri, Sep 27, 2013 at 03:31:00PM +0800, Chon Ming Lee wrote:
  CDCLK is used to generate the gmbus clock.  This is normally done by
  BIOS. Program the value if the BIOS-less system doesn't do it.
  
  v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
  during resume. (Daniel)
  
  v3: Change GMBUS_FREQ to GMBUSFREQ_VLV, and use VLV_DISPLAY_BASE.
  (Ville).
  Remove cdclk_ratio[] table, and calculate the cdclk ratio instead.
  (Ville).
  Change the shift then mask for reg read, to mask first, then shift.
  (Ville).
  Remove the gmbus frequency calculation = cdclk/1.01.  Based on BIOS
  programming, gmbus frequency = cdclk frequency. (Ville)
  Add get_disp_clk_div, which can use to get cdclk/czclk divide.
  
  v4: Fix the mmio_offset base for CZCLK_CDCLK_FREQ_RATIO, gmbus_freq
  calculation, and duplicate check for gmbus_freq. (Ville)
  
  In VLV, the spec is wrong about 4Mhz reference frequency for GMBUS. It
  should be 1Mhz.
  
  Signed-off-by: Chon Ming Lee chon.ming@intel.com
  ---
   drivers/gpu/drm/i915/i915_reg.h  |8 +
   drivers/gpu/drm/i915/intel_i2c.c |   57 
  ++
   2 files changed, 65 insertions(+), 0 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
  b/drivers/gpu/drm/i915/i915_reg.h
  index a0a9811..b37dfd8 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -391,6 +391,8 @@
   #define   FB_FMAX_VMIN_FREQ_LO_MASK0xf800
   
   /* vlv2 north clock has */
  +#define CCK_FUSE_REG   0x8
  +#define  CCK_FUSE_HPLL_FREQ_MASK   0x3
   #define CCK_REG_DSI_PLL_FUSE   0x44
   #define CCK_REG_DSI_PLL_CONTROL0x48
   #define  DSI_PLL_VCO_EN(1  31)
  @@ -1438,6 +1440,12 @@
   
   #define MI_ARB_VLV (VLV_DISPLAY_BASE + 0x6504)
   
  +#define CZCLK_CDCLK_FREQ_RATIO (VLV_DISPLAY_BASE + 0x6508)
  +#define   CDCLK_FREQ_SHIFT 4
  +#define   CDCLK_FREQ_MASK  (0x1f  CDCLK_FREQ_SHIFT)
  +#define   CZCLK_FREQ_MASK  0xf
  +#define GMBUSFREQ_VLV  (VLV_DISPLAY_BASE + 0x6510)
  +
   /*
* Palette regs
*/
  diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
  b/drivers/gpu/drm/i915/intel_i2c.c
  index d1c1e0f7..b579ffd 100644
  --- a/drivers/gpu/drm/i915/intel_i2c.c
  +++ b/drivers/gpu/drm/i915/intel_i2c.c
  @@ -34,6 +34,11 @@
   #include drm/i915_drm.h
   #include i915_drv.h
   
  +enum disp_clk {
  +   CDCLK,
  +   CZCLK
  +};
  +
   struct gmbus_port {
  const char *name;
  int reg;
  @@ -58,10 +63,62 @@ to_intel_gmbus(struct i2c_adapter *i2c)
  return container_of(i2c, struct intel_gmbus, adapter);
   }
   
  +static int get_disp_clk_div(struct drm_i915_private *dev_priv, enum 
  disp_clk clk)
  +{
  +   u32 reg_val;
  +   int clk_ratio;
  +
  +   reg_val = I915_READ(CZCLK_CDCLK_FREQ_RATIO);
  +
  +   if (clk == CDCLK)
  +   clk_ratio = ((reg_val  CDCLK_FREQ_MASK)  CDCLK_FREQ_SHIFT) + 
  1;
  +   else
  +   clk_ratio = (reg_val  CZCLK_FREQ_MASK) + 1;
  +
  +   return clk_ratio;
  +}
  +
  +static void gmbus_set_freq(struct drm_i915_private *dev_priv)
  +{
  +   int vco_freq[] = { 800, 1600, 2000, 2400 };
  +   int gmbus_freq = 0, cdclk_div, hpll_freq;
  +
  +   BUG_ON(!IS_VALLEYVIEW(dev_priv-dev));
  +
  +   /* Skip setting the gmbus freq if BIOS has already programmed it */
  +   if (I915_READ(GMBUSFREQ_VLV) != 0xA0)
  +   return;
  +
  +   /* Obtain SKU information */
  +   mutex_lock(dev_priv-dpio_lock);
  +   hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG)  
  CCK_FUSE_HPLL_FREQ_MASK;
  +   mutex_unlock(dev_priv-dpio_lock);
  +
  +   /* Get the CDCLK divide ratio */
  +   cdclk_div = get_disp_clk_div(dev_priv, CDCLK);
  +
  +   /* Program the gmbus_freq based on the cdclk frequency */
  +   if (cdclk_div)
  +   gmbus_freq = (vco_freq[hpll_freq]  1) / cdclk_div;
 
 
 OK based on the information that you dug up that we do need to aim for
 1MHz GMBUS freq, the patch looks good to me. I think we should add a
 comment here about the 1MHz vs. 4MHz what the spec says. Eg.:
 
 /*
  * Program the gmbus_freq based on the cdclk frequency.
  * BSpec erroneously claims we should aim for 4MHz, but
  * in fact 1MHz is the correct frequency.
  */
 
 Maybe Daniel can add that when applying the patch...

Done. Also I've massaged the patch a bit to appease checkpatch. Please run
patches through that tool before submitting ...

 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/14] drm/i915: Use DIV_ROUND_CLOSEST()

On Thu, Sep 26, 2013 at 01:09:26PM +0300, Mika Kuoppala wrote:
 ville.syrj...@linux.intel.com writes:
 
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it
  with the real thing.
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index fca56fc..4b1af94 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -696,8 +696,7 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct 
  drm_crtc *crtc,
  p = p1 * p2;
  /* based on hardware requirement, prefer bigger 
  m1,m2 values */
  for (m1 = limit-m1.min; m1 = limit-m1.max; 
  m1++) {
  -   m2 = (((2*(fastclk * p * n / m1 )) +
  -  refclk) / (2*refclk));
  +   m2 = DIV_ROUND_CLOSEST(fastclk * p * n, 
  refclk * m1);
  m = m1 * m2;
  vco = updrate * m;
   
  -- 
  1.8.1.5
 
 Not a problem with this patch but perhaps consideration for further
 cleanups: target and refclk should be u32 and further down the line
 the crtc_config.clock and xxx_get_refclk() also.
 
 Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com

Up to this all merged, thanks for patchesreview.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: use correct units for rc6 residency v2

On Fri, Sep 27, 2013 at 09:15:58AM +0100, Chris Wilson wrote:
 On Thu, Sep 26, 2013 at 05:55:58PM -0700, Jesse Barnes wrote:
  We need to use the clock control reg to figure out how many CZ clks are in
  30ns and use that as the basis for our RC6 residency calculations.
  
  v2: use ULL everywhere for consistency (Chris)
  factor out bias for clarity (Chris)
 
 I liked the NSEC_PER_MSEC as well :)
 
  
  References: https://bugs.freedesktop.org/show_bug.cgi?id=69692
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/i915_reg.h   |  3 +++
   drivers/gpu/drm/i915/i915_sysfs.c | 22 --
   2 files changed, 23 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
  b/drivers/gpu/drm/i915/i915_reg.h
  index cf995bb..6f8d0cf 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -1797,6 +1797,9 @@
*/
   #define HSW_CXT_TOTAL_SIZE (17 * PAGE_SIZE)
   
  +#define VLV_CLK_CTL2   0x101104
  +#define   CLK_CTL2_CZCOUNT_30NS_SHIFT  28
  +
   /*
* Overlay regs
*/
  diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
  b/drivers/gpu/drm/i915/i915_sysfs.c
  index 44f4c1a..8003886 100644
  --- a/drivers/gpu/drm/i915/i915_sysfs.c
  +++ b/drivers/gpu/drm/i915/i915_sysfs.c
  @@ -37,12 +37,30 @@ static u32 calc_residency(struct drm_device *dev, const 
  u32 reg)
   {
  struct drm_i915_private *dev_priv = dev-dev_private;
  u64 raw_time; /* 32b value may overflow during fixed point math */
  +   u64 units = 128ULL, div = 10ULL, bias = 100ULL;
   
  if (!intel_enable_rc6(dev))
  return 0;
   
  -   raw_time = I915_READ(reg) * 128ULL;
  -   return DIV_ROUND_UP_ULL(raw_time, 10);
  +   /* On VLV, residency time is in CZ units rather than 1.28us */
  +   if (IS_VALLEYVIEW(dev)) {
  +   u32 clkctl2;
  +
  +   clkctl2 = I915_READ(VLV_CLK_CTL2) 
  +   CLK_CTL2_CZCOUNT_30NS_SHIFT;
  +   if (!clkctl2) {
  +   WARN(!clkctl2, bogus CZ count value);
  +   return 0;
  +   }
  +   units = DIV_ROUND_UP_ULL(30ULL * bias, (u64)clkctl2);
  +   if (I915_READ(VLV_COUNTER_CONTROL)  VLV_COUNT_RANGE_HIGH)
  +   units = 8;
  +
  +   div = 100ULL * bias;
  +   }
 
   /* On VLV, residency time is in CZ units rather than 1.28us */
   if (IS_VALLEVIEW9dev)) {
   u32 clkctl2;
 
   clkctl2 = I915_READ(VLV_CLK_CTL2) 
   CLK_CTL2_CZCOUNT_30NS_SHIFT;
   if (!clkctl2) {
   WARN(!clkctl2, bogus CZ count value);
   return 0;
   }
 
   units = DIV_ROUND_UP_ULL(30ULL * bias, (u64)clkctl2);
   if (I915_READ(VLV_COUNTER_CONTROL)  VLV_COUNT_RANGE_HIGH)
   units = 8;
 
   div = NSEC_PER_MSEC * bias;
   } else {
   units = 128;
   div = USEC_PER_MSEC * bias;
   }
 
   raw_time = I915_READ(reg) * units;
   return DIV_ROUND_UP_ULL(raw_time, div);
 
 Either way, with or without the extra constants,
 Both patches,
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Both merged without further bikeshedding applied. Thanks for
patchesreview.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Code stereo layouts as an enum in the mode structure

On Fri, Sep 27, 2013 at 06:36:05PM +0300, Ville Syrjälä wrote:
 On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
  Daniel noticed that it wasn't very smart to keep using one bit per stereo
  layout now that we don't have to or them. It's a nice final touch to the new
  stereo mode API extension that we should fix before committing to it.
 
 Assuming you still trust me even though I didn't see this possibility
 during my review of the original series :)
 
 For the series:
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Merged to dinq, thansk for patchesreview.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: reduce GT FIFO error info to a debug message

On Fri, Sep 27, 2013 at 10:40:54AM -0700, Jesse Barnes wrote:
 It indicates a probable BIOS bug, but it appears to be harmless, and
 there's nothing the user can do about it anyway, so reduce to a debug
 msg.  I've filed a bug with the BIOS folks about it anyway, so hopefully
 they'll fix whatever GT SB read they were doing when the GT was off.
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=69396
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

Since it's vlv-specific code I guess this makes sense. Queued for -next,
thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/5] drm/i915/vlv: reduce GT FIFO error info to a debug message

It indicates a probable BIOS bug, but it appears to be harmless, and
there's nothing the user can do about it anyway, so reduce to a debug
msg.  I've filed a bug with the BIOS folks about it anyway, so hopefully
they'll fix whatever GT SB read they were doing when the GT was off.

References: https://bugs.freedesktop.org/show_bug.cgi?id=69396
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 102fc49..10054b5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3804,7 +3804,8 @@ static void valleyview_enable_rps(struct drm_device *dev)
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
 
if ((gtfifodbg = I915_READ(GTFIFODBG))) {
-   DRM_ERROR(GT fifo had a previous error %x\n, gtfifodbg);
+   DRM_DEBUG_DRIVER(GT fifo had a previous error %x\n,
+gtfifodbg);
I915_WRITE(GTFIFODBG, gtfifodbg);
}
 
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 5/5] drm/i915/vlv: add valleyview_crtc_disable function

To handle disabling DP after the CPU pipe is disabled, per the
workaround.

References: https://bugs.freedesktop.org/show_bug.cgi?id=58152
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 58 
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2c040cd..9a7136c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3873,6 +3873,57 @@ static void i9xx_pfit_disable(struct intel_crtc *crtc)
I915_WRITE(PFIT_CONTROL, 0);
 }
 
+static void valleyview_crtc_disable(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);
+   struct intel_encoder *encoder;
+   int pipe = intel_crtc-pipe;
+   int plane = intel_crtc-plane;
+
+   if (!intel_crtc-active)
+   return;
+
+   for_each_encoder_on_crtc(dev, crtc, encoder)
+   if (!(encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
+ encoder-type == INTEL_OUTPUT_EDP))
+   encoder-disable(encoder);
+
+   /* Give the overlay scaler a chance to disable if it's on this pipe */
+   intel_crtc_wait_for_pending_flips(crtc);
+   drm_vblank_off(dev, pipe);
+
+   if (dev_priv-fbc.plane == plane)
+   intel_disable_fbc(dev);
+
+   intel_crtc_dpms_overlay(intel_crtc, false);
+   intel_crtc_update_cursor(crtc, false);
+   intel_disable_planes(crtc);
+   intel_disable_plane(dev_priv, plane, pipe);
+
+   intel_disable_pipe(dev_priv, pipe);
+
+   for_each_encoder_on_crtc(dev, crtc, encoder)
+   if (encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
+   encoder-type == INTEL_OUTPUT_EDP)
+   encoder-disable(encoder);
+
+   i9xx_pfit_disable(intel_crtc);
+
+   for_each_encoder_on_crtc(dev, crtc, encoder)
+   if (encoder-post_disable)
+   encoder-post_disable(encoder);
+
+   if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+   vlv_disable_pll(dev_priv, pipe);
+
+   intel_crtc-active = false;
+   intel_update_watermarks(crtc);
+
+   intel_update_fbc(dev);
+}
+
 static void i9xx_crtc_disable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc-dev;
@@ -3908,10 +3959,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
if (encoder-post_disable)
encoder-post_disable(encoder);
 
-   if (IS_VALLEYVIEW(dev)  !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
-   vlv_disable_pll(dev_priv, pipe);
-   else if (!IS_VALLEYVIEW(dev))
-   i9xx_disable_pll(dev_priv, pipe);
+   i9xx_disable_pll(dev_priv, pipe);
 
intel_crtc-active = false;
intel_update_watermarks(crtc);
@@ -10048,7 +10096,7 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.get_pipe_config = i9xx_get_pipe_config;
dev_priv-display.crtc_mode_set = i9xx_crtc_mode_set;
dev_priv-display.crtc_enable = valleyview_crtc_enable;
-   dev_priv-display.crtc_disable = i9xx_crtc_disable;
+   dev_priv-display.crtc_disable = valleyview_crtc_disable;
dev_priv-display.off = i9xx_crtc_off;
dev_priv-display.update_plane = i9xx_update_plane;
} else {
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 3/5] drm/i915/vlv: warn on bad VLV PLL divider values

This avoids a divide by zero and warns appropriately on this serious bug.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8da1c96..9a83236 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5109,6 +5109,11 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
clock.p1 = (mdiv  DPIO_P1_SHIFT)  7;
clock.p2 = (mdiv  DPIO_P2_SHIFT)  0x1f;
 
+   if (!clock.n || !(clock.p1 * clock.p2)) {
+   WARN(1, bad divider values on pipe %d\n, crtc-pipe);
+   return;
+   }
+
clock.vco = refclk * clock.m1 * clock.m2 / clock.n;
clock.dot = 2 * clock.vco / (clock.p1 * clock.p2);
 
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 4/5] drm/i915/vlv: untangle integrated clock source handling v2

The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource.  It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
when pipe B shuts down.

I'm guessing on the references here, I expect this to bite any config
where multiple displays are active or displays are moved from pipe to
pipe.

v2: re-add bits in vlv_update_pll to keep from confusing the state checker

References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9a83236..2c040cd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1387,6 +1387,13 @@ static void vlv_enable_pll(struct intel_crtc *crtc)
if (IS_MOBILE(dev_priv-dev)  !IS_I830(dev_priv-dev))
assert_panel_unlocked(dev_priv, crtc-pipe);
 
+   /* Make sure to use the integrated clock source */
+   if (!crtc-pipe)
+   I915_WRITE(DPLL(1), I915_READ(DPLL(1)) |
+  DPLL_INTEGRATED_CRI_CLK_VLV);
+   else
+   dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150);
@@ -1477,6 +1484,20 @@ static void i9xx_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
 }
 
+static void vlv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+{
+   u32 val = 0;
+
+   /* Make sure the pipe isn't still relying on us */
+   assert_pipe_disabled(dev_priv, pipe);
+
+   /* Leave integrated clock source enabled for the other pipe */
+   if (pipe)
+   val = I915_READ(DPLL(pipe))  DPLL_INTEGRATED_CRI_CLK_VLV;
+   I915_WRITE(DPLL(pipe), val);
+   POSTING_READ(DPLL(pipe));
+}
+
 void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
 {
u32 port_mask;
@@ -3887,7 +3908,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
if (encoder-post_disable)
encoder-post_disable(encoder);
 
-   if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+   if (IS_VALLEYVIEW(dev)  !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+   vlv_disable_pll(dev_priv, pipe);
+   else if (!IS_VALLEYVIEW(dev))
i9xx_disable_pll(dev_priv, pipe);
 
intel_crtc-active = false;
@@ -4629,7 +4652,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
if (pipe)
dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
-
dpll |= DPLL_VCO_ENABLE;
crtc-config.dpll_hw_state.dpll = dpll;
 
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: retry i2c-over-aux seven times on AUX DEFER

On Fri, Sep 27, 2013 at 12:07:29PM -0700, Todd Previte wrote:
 Yep. Good to go.
 
 Reviewed-by: Todd Previte tprev...@gmail.com

Queued for -next, thanks for the patch.
-Daniel
 
 
 On Fri, Sep 27, 2013 at 4:51 AM, Jani Nikula 
 jani.nik...@linux.intel.comwrote:
 
  On Fri, 20 Sep 2013, Todd Previte tprev...@gmail.com wrote:
   On 09/20/2013 06:42 AM, Jani Nikula wrote:
   Per DP1.2 spec.
  
   Signed-off-by: Jani Nikula jani.nik...@intel.com
   ---
 drivers/gpu/drm/i915/intel_dp.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
  
   diff --git a/drivers/gpu/drm/i915/intel_dp.c
  b/drivers/gpu/drm/i915/intel_dp.c
   index 9770160..6626514 100644
   --- a/drivers/gpu/drm/i915/intel_dp.c
   +++ b/drivers/gpu/drm/i915/intel_dp.c
   @@ -654,7 +654,12 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter,
  int mode,
break;
}
  
   -for (retry = 0; retry  5; retry++) {
   +/*
   + * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source
  device is
   + * required to retry at least seven times upon receiving AUX_DEFER
   + * before giving up the AUX transaction.
   + */
   +for (retry = 0; retry  7; retry++) {
ret = intel_dp_aux_ch(intel_dp,
  msg, msg_bytes,
  reply, reply_bytes);
  
   Hey Jani,
  
   Although it's not explicitly stated in the specification (I went through
   both the 1.1a and 1.2a specifications and couldn't find it), I think the
   the retry count of 7 applies to all AUX transactions, both native and
   I2C. That's alluded to in the description of the link training sequence
   (pg 382, 2nd paragraph from the bottom) where the sink may defer up to
   seven times before the source can abort training.
  
   With that in mind, it might be a good idea to use a defined constant for
   the retry count for both native and I2C AUX transactions. That would
   keep it consistent throughout the code and be easier to update moving
   forward should the specification change.
 
  Todd, are you willing to give your reviewed-by on this one patch per our
  irc discussion? We can do further cleanups later.
 
  I've sent a new version of 3/4 with the #defines separately.
 
 
  BR,
  Jani.
 
 
 
  --
  Jani Nikula, Intel Open Source Technology Center
 

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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: untangle integrated clock source handling

On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
 The global integrated clock source bit resides in DPLL B on VLV, but we
 were treating it as a per-pipe resource.  It needs to be set whenever
 any PLL is active, so pull setting the bit out of vlv_update_pll and
 into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
 when pipe B shuts down.
 
 I'm guessing on the references here, I expect this to bite any config
 where multiple displays are active or displays are moved from pipe to
 pipe.
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
 References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c | 27 ---
  1 file changed, 24 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 0eeba84..def2473 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1386,6 +1386,13 @@ static void vlv_enable_pll(struct intel_crtc *crtc)
   if (IS_MOBILE(dev_priv-dev)  !IS_I830(dev_priv-dev))
   assert_panel_unlocked(dev_priv, crtc-pipe);
  
 + /* Make sure to use the integrated clock source */
 + if (!crtc-pipe)

I prefer explicit pipe != PIPE_B checks. We have a bunch of those already
in vlv code, and every time I read one of them my parser trips. Treating
enums as booleans is imo just evil ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm/i915: use wait_event_timeout when waiting for flip completions

We're shutting the crtc off and don't want to hang forever.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc25481..8da1c96 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2912,8 +2912,9 @@ static void intel_crtc_wait_for_pending_flips(struct 
drm_crtc *crtc)
 
WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
 
-   wait_event(dev_priv-pending_flip_queue,
-  !intel_crtc_has_pending_flip(crtc));
+   wait_event_timeout(dev_priv-pending_flip_queue,
+  !intel_crtc_has_pending_flip(crtc),
+  msecs_to_jiffies(50));
 
mutex_lock(dev-struct_mutex);
intel_finish_fb(crtc-fb);
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH 3/5] drm/i915/vlv: warn on bad VLV PLL divider values

On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
 This avoids a divide by zero and warns appropriately on this serious bug.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 8da1c96..9a83236 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5109,6 +5109,11 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
   clock.p1 = (mdiv  DPIO_P1_SHIFT)  7;
   clock.p2 = (mdiv  DPIO_P2_SHIFT)  0x1f;
  
 + if (!clock.n || !(clock.p1 * clock.p2)) {

if ((clock.n  clock.p1  clock.p2) == 0) {

or just

if (!clock.n || !clock.p1 || !clock.p2)

 + WARN(1, bad divider values on pipe %d\n, crtc-pipe);
 + return;
 + }
 +

So I think you want

if (WARN_ONCE(clock.n == 0 || clock.p1 == 0 || clock.p2 == 0,
  bad divider values on pipe %d (m1=%d, m2=%d, p1=%d, p2=%d, 
n=%d)\n,
  crtc-pipe, clock.m1, clock.m2, clock.p1, clock.p2, clock.n))
   return;
-Chris

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/vlv: add valleyview_crtc_disable function

On Fri, Sep 27, 2013 at 12:57:26PM -0700, Jesse Barnes wrote:
 To handle disabling DP after the CPU pipe is disabled, per the
 workaround.
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=58152
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

This also applies to g4x apparently and really encoder type checks in the
crtc code is just evil. Furthermore it seems to be already implemented, at
least that's my impression from reading intel_dp.c.
-Daniel


 ---
  drivers/gpu/drm/i915/intel_display.c | 58 
 
  1 file changed, 53 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 2c040cd..9a7136c 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3873,6 +3873,57 @@ static void i9xx_pfit_disable(struct intel_crtc *crtc)
   I915_WRITE(PFIT_CONTROL, 0);
  }
  
 +static void valleyview_crtc_disable(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);
 + struct intel_encoder *encoder;
 + int pipe = intel_crtc-pipe;
 + int plane = intel_crtc-plane;
 +
 + if (!intel_crtc-active)
 + return;
 +
 + for_each_encoder_on_crtc(dev, crtc, encoder)
 + if (!(encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
 +   encoder-type == INTEL_OUTPUT_EDP))
 + encoder-disable(encoder);
 +
 + /* Give the overlay scaler a chance to disable if it's on this pipe */
 + intel_crtc_wait_for_pending_flips(crtc);
 + drm_vblank_off(dev, pipe);
 +
 + if (dev_priv-fbc.plane == plane)
 + intel_disable_fbc(dev);
 +
 + intel_crtc_dpms_overlay(intel_crtc, false);
 + intel_crtc_update_cursor(crtc, false);
 + intel_disable_planes(crtc);
 + intel_disable_plane(dev_priv, plane, pipe);
 +
 + intel_disable_pipe(dev_priv, pipe);
 +
 + for_each_encoder_on_crtc(dev, crtc, encoder)
 + if (encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
 + encoder-type == INTEL_OUTPUT_EDP)
 + encoder-disable(encoder);
 +
 + i9xx_pfit_disable(intel_crtc);
 +
 + for_each_encoder_on_crtc(dev, crtc, encoder)
 + if (encoder-post_disable)
 + encoder-post_disable(encoder);
 +
 + if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
 + vlv_disable_pll(dev_priv, pipe);
 +
 + intel_crtc-active = false;
 + intel_update_watermarks(crtc);
 +
 + intel_update_fbc(dev);
 +}
 +
  static void i9xx_crtc_disable(struct drm_crtc *crtc)
  {
   struct drm_device *dev = crtc-dev;
 @@ -3908,10 +3959,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
   if (encoder-post_disable)
   encoder-post_disable(encoder);
  
 - if (IS_VALLEYVIEW(dev)  !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
 - vlv_disable_pll(dev_priv, pipe);
 - else if (!IS_VALLEYVIEW(dev))
 - i9xx_disable_pll(dev_priv, pipe);
 + i9xx_disable_pll(dev_priv, pipe);
  
   intel_crtc-active = false;
   intel_update_watermarks(crtc);
 @@ -10048,7 +10096,7 @@ static void intel_init_display(struct drm_device *dev)
   dev_priv-display.get_pipe_config = i9xx_get_pipe_config;
   dev_priv-display.crtc_mode_set = i9xx_crtc_mode_set;
   dev_priv-display.crtc_enable = valleyview_crtc_enable;
 - dev_priv-display.crtc_disable = i9xx_crtc_disable;
 + dev_priv-display.crtc_disable = valleyview_crtc_disable;
   dev_priv-display.off = i9xx_crtc_off;
   dev_priv-display.update_plane = i9xx_update_plane;
   } else {
 -- 
 1.8.3.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: untangle integrated clock source handling

On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
 The global integrated clock source bit resides in DPLL B on VLV, but we
 were treating it as a per-pipe resource.  It needs to be set whenever
 any PLL is active,

Actually AFAIU the cri clock has to be running even if we just attempt
to do any register access to the phy.

 so pull setting the bit out of vlv_update_pll and
 into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
 when pipe B shuts down.
 
 I'm guessing on the references here, I expect this to bite any config
 where multiple displays are active or displays are moved from pipe to
 pipe.
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
 References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c | 27 ---
  1 file changed, 24 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 0eeba84..def2473 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1386,6 +1386,13 @@ static void vlv_enable_pll(struct intel_crtc *crtc)
   if (IS_MOBILE(dev_priv-dev)  !IS_I830(dev_priv-dev))
   assert_panel_unlocked(dev_priv, crtc-pipe);
  
 + /* Make sure to use the integrated clock source */
 + if (!crtc-pipe)
 + I915_WRITE(DPLL(1), I915_READ(DPLL(1)) |
 +DPLL_INTEGRATED_CRI_CLK_VLV);

We may need the cri clock before this, so I would just put this part
into some modeset hw init function.

 + else
 + dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;

And obviously this part has to stay here, or we could do a 
 'I915_READ(DPLL(1))  DPLL_INTEGRATED_CRI_CLK_VLV)' to extract the
current setting from the hardware like you do in vlv_disable_pll().
In any case I think doing it the same way for both enable and
disable would be good.

Or we could leave setting of this bit up to vlv_update_pll() like it was
before.

 +
   I915_WRITE(reg, dpll);
   POSTING_READ(reg);
   udelay(150);
 @@ -1476,6 +1483,20 @@ static void i9xx_disable_pll(struct drm_i915_private 
 *dev_priv, enum pipe pipe)
   POSTING_READ(DPLL(pipe));
  }
  
 +static void vlv_disable_pll(struct drm_i915_private *dev_priv, enum pipe 
 pipe)
 +{
 + u32 val = 0;
 +
 + /* Make sure the pipe isn't still relying on us */
 + assert_pipe_disabled(dev_priv, pipe);
 +
 + /* Leave integrated clock source enabled for the other pipe */
 + if (pipe)
 + val = I915_READ(DPLL(pipe))  DPLL_INTEGRATED_CRI_CLK_VLV;

Right. As stated we need to either hardcode the bit on (if we assume 1
is the right answer always) or we read it back like you do.

 + I915_WRITE(DPLL(pipe), val);
 + POSTING_READ(DPLL(pipe));
 +}
 +
  void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
  {
   u32 port_mask;
 @@ -3886,7 +3907,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
   if (encoder-post_disable)
   encoder-post_disable(encoder);
  
 - if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
 + if (IS_VALLEYVIEW(dev)  !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
 + vlv_disable_pll(dev_priv, pipe);
 + else if (!IS_VALLEYVIEW(dev))
   i9xx_disable_pll(dev_priv, pipe);
  
   intel_crtc-active = false;
 @@ -4626,8 +4649,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
   /* Enable DPIO clock input */
   dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
   DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
 - if (pipe)
 - dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
  
   dpll |= DPLL_VCO_ENABLE;
   crtc-config.dpll_hw_state.dpll = dpll;
 -- 
 1.8.3.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 3/5] drm/i915/vlv: warn on bad VLV PLL divider values

On Fri, Sep 27, 2013 at 09:05:24PM +0100, Chris Wilson wrote:
 On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
  This avoids a divide by zero and warns appropriately on this serious bug.
  
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/intel_display.c | 5 +
   1 file changed, 5 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 8da1c96..9a83236 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -5109,6 +5109,11 @@ static void vlv_crtc_clock_get(struct intel_crtc 
  *crtc,
  clock.p1 = (mdiv  DPIO_P1_SHIFT)  7;
  clock.p2 = (mdiv  DPIO_P2_SHIFT)  0x1f;
   
  +   if (!clock.n || !(clock.p1 * clock.p2)) {
 
 if ((clock.n  clock.p1  clock.p2) == 0) {
 
 or just
 
 if (!clock.n || !clock.p1 || !clock.p2)
 
  +   WARN(1, bad divider values on pipe %d\n, crtc-pipe);
  +   return;
  +   }
  +
 
 So I think you want
 
 if (WARN_ONCE(clock.n == 0 || clock.p1 == 0 || clock.p2 == 0,
   bad divider values on pipe %d (m1=%d, m2=%d, p1=%d, p2=%d, 
 n=%d)\n,
 crtc-pipe, clock.m1, clock.m2, clock.p1, clock.p2, clock.n))
return;

So the bios leaves a broken setup behind or is our hw state readout not
quite careful enough?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/vlv: warn on bad VLV PLL divider values

On Fri, 27 Sep 2013 22:11:33 +0200
Daniel Vetter dan...@ffwll.ch wrote:

 On Fri, Sep 27, 2013 at 09:05:24PM +0100, Chris Wilson wrote:
  On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
   This avoids a divide by zero and warns appropriately on this serious bug.
   
   Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
   ---
drivers/gpu/drm/i915/intel_display.c | 5 +
1 file changed, 5 insertions(+)
   
   diff --git a/drivers/gpu/drm/i915/intel_display.c 
   b/drivers/gpu/drm/i915/intel_display.c
   index 8da1c96..9a83236 100644
   --- a/drivers/gpu/drm/i915/intel_display.c
   +++ b/drivers/gpu/drm/i915/intel_display.c
   @@ -5109,6 +5109,11 @@ static void vlv_crtc_clock_get(struct intel_crtc 
   *crtc,
 clock.p1 = (mdiv  DPIO_P1_SHIFT)  7;
 clock.p2 = (mdiv  DPIO_P2_SHIFT)  0x1f;

   + if (!clock.n || !(clock.p1 * clock.p2)) {
  
  if ((clock.n  clock.p1  clock.p2) == 0) {
  
  or just
  
  if (!clock.n || !clock.p1 || !clock.p2)
  
   + WARN(1, bad divider values on pipe %d\n, crtc-pipe);
   + return;
   + }
   +
  
  So I think you want
  
  if (WARN_ONCE(clock.n == 0 || clock.p1 == 0 || clock.p2 == 0,
bad divider values on pipe %d (m1=%d, m2=%d, p1=%d, p2=%d, 
  n=%d)\n,
crtc-pipe, clock.m1, clock.m2, clock.p1, clock.p2, clock.n))
 return;
 
 So the bios leaves a broken setup behind or is our hw state readout not
 quite careful enough?

No this just happens when we're really broken.  E.g. we don't set the
integrated clock bit and then try to enable a PLL and fail all over.

Shouldn't happen in practice.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: use wait_event_timeout when waiting for flip completions

On Fri, Sep 27, 2013 at 12:57:23PM -0700, Jesse Barnes wrote:
 We're shutting the crtc off and don't want to hang forever.

That scares me ever so slightly, especially ignoring the failure. Do you
want to reset the display controller if the interrupts die, or just
report a WARN, or propagate the failure back and make userspace try
again?

But not taking any action at all is a recipe for a silent disaster. It
has taken years to get to the point where we can turn off the pipes
reliably...
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp: add defines for downstream port types

2013-09-27 Thread Alex Deucher

On Fri, Sep 27, 2013 at 7:48 AM, Jani Nikula jani.nik...@intel.com wrote:
 Detailed cap info at address 80h is not available with DPCD ver
 1.0. Whether such devices exist in the wild I don't know, but there
 should be no harm done in having the defines for downstream port 0 in
 address 05h.

 Signed-off-by: Jani Nikula jani.nik...@intel.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  include/drm/drm_dp_helper.h |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
 index ae8dbfb..83da4eb 100644
 --- a/include/drm/drm_dp_helper.h
 +++ b/include/drm/drm_dp_helper.h
 @@ -77,10 +77,10 @@
  #define DP_DOWNSTREAMPORT_PRESENT   0x005
  # define DP_DWN_STRM_PORT_PRESENT   (1  0)
  # define DP_DWN_STRM_PORT_TYPE_MASK 0x06
 -/* 00b = DisplayPort */
 -/* 01b = Analog */
 -/* 10b = TMDS or HDMI */
 -/* 11b = Other */
 +# define DP_DWN_STRM_PORT_TYPE_DP   (0  1)
 +# define DP_DWN_STRM_PORT_TYPE_ANALOG   (1  1)
 +# define DP_DWN_STRM_PORT_TYPE_TMDS (2  1)
 +# define DP_DWN_STRM_PORT_TYPE_OTHER(3  1)
  # define DP_FORMAT_CONVERSION   (1  3)
  # define DP_DETAILED_CAP_INFO_AVAILABLE(1  4) /* DPI */

 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: use wait_event_timeout when waiting for flip completions

On Fri, 27 Sep 2013 21:45:39 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Fri, Sep 27, 2013 at 12:57:23PM -0700, Jesse Barnes wrote:
  We're shutting the crtc off and don't want to hang forever.
 
 That scares me ever so slightly, especially ignoring the failure. Do you
 want to reset the display controller if the interrupts die, or just
 report a WARN, or propagate the failure back and make userspace try
 again?
 
 But not taking any action at all is a recipe for a silent disaster. It
 has taken years to get to the point where we can turn off the pipes
 reliably...

Yeah this one is definitely a WIP.  I'd like to warn when this happens
and clean things up rather than just timing out and letting disaster
befall us later.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/vlv: use per-pipe backlight controls

With the connector and pipe passed around, we can now set the backlight
on the right pipe on VLV/BYT.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/i915_reg.h| 10 ++
 drivers/gpu/drm/i915/intel_panel.c | 65 +++---
 2 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96fd2ce..a3b9508 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2295,6 +2295,16 @@
 
 #define PFIT_AUTO_RATIOS (dev_priv-info-display_mmio_offset + 0x61238)
 
+#define _VLV_BLC_PWM_CTL2_A (dev_priv-info-display_mmio_offset + 0x61250)
+#define _VLV_BLC_PWM_CTL2_B (dev_priv-info-display_mmio_offset + 0x61350)
+#define VLV_BLC_PWM_CTL2(pipe) _PIPE(pipe, _VLV_BLC_PWM_CTL2_A, \
+_VLV_BLC_PWM_CTL2_B)
+
+#define _VLV_BLC_PWM_CTL_A (dev_priv-info-display_mmio_offset + 0x61254)
+#define _VLV_BLC_PWM_CTL_B (dev_priv-info-display_mmio_offset + 0x61354)
+#define VLV_BLC_PWM_CTL(pipe) _PIPE(pipe, _VLV_BLC_PWM_CTL_A, \
+   _VLV_BLC_PWM_CTL_B)
+
 /* Backlight control */
 #define BLC_PWM_CTL2   (dev_priv-info-display_mmio_offset + 0x61250) /* 965+ 
only */
 #define   BLM_PWM_ENABLE   (1  31)
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 5122f58..03f8450 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -329,6 +329,9 @@ static int is_backlight_combination_mode(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
 
+   if (IS_VALLEYVIEW(dev))
+   return 0;
+
if (IS_GEN4(dev))
return I915_READ(BLC_PWM_CTL2)  BLM_COMBINATION_MODE;
 
@@ -358,6 +361,21 @@ static u32 i915_read_blc_pwm_ctl(struct drm_device *dev, 
enum pipe pipe)
val = dev_priv-regfile.saveBLC_PWM_CTL2;
I915_WRITE(BLC_PWM_PCH_CTL2, val);
}
+   } else if (IS_VALLEYVIEW(dev)) {
+   val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+   if (dev_priv-regfile.saveBLC_PWM_CTL == 0) {
+   dev_priv-regfile.saveBLC_PWM_CTL = val;
+   dev_priv-regfile.saveBLC_PWM_CTL2 =
+   I915_READ(VLV_BLC_PWM_CTL2(pipe));
+   } else if (val == 0) {
+   val = dev_priv-regfile.saveBLC_PWM_CTL;
+   I915_WRITE(VLV_BLC_PWM_CTL(pipe), val);
+   I915_WRITE(VLV_BLC_PWM_CTL2(pipe),
+  dev_priv-regfile.saveBLC_PWM_CTL2);
+   }
+
+   if (!val)
+   val = 0x0f42;
} else {
val = I915_READ(BLC_PWM_CTL);
if (dev_priv-regfile.saveBLC_PWM_CTL == 0) {
@@ -372,9 +390,6 @@ static u32 i915_read_blc_pwm_ctl(struct drm_device *dev, 
enum pipe pipe)
I915_WRITE(BLC_PWM_CTL2,
   dev_priv-regfile.saveBLC_PWM_CTL2);
}
-
-   if (IS_VALLEYVIEW(dev)  !val)
-   val = 0x0f42;
}
 
return val;
@@ -435,13 +450,19 @@ static u32 intel_panel_get_backlight(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = dev-dev_private;
u32 val;
unsigned long flags;
+   int reg;
 
spin_lock_irqsave(dev_priv-backlight.lock, flags);
 
if (HAS_PCH_SPLIT(dev)) {
val = I915_READ(BLC_PWM_CPU_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
} else {
-   val = I915_READ(BLC_PWM_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
+   if (IS_VALLEYVIEW(dev))
+   reg = VLV_BLC_PWM_CTL(pipe);
+   else
+   reg = BLC_PWM_CTL;
+
+   val = I915_READ(reg)  BACKLIGHT_DUTY_CYCLE_MASK;
if (INTEL_INFO(dev)-gen  4)
val = 1;
 
@@ -473,6 +494,7 @@ static void intel_panel_actually_set_backlight(struct 
drm_device *dev,
 {
struct drm_i915_private *dev_priv = dev-dev_private;
u32 tmp;
+   int reg;
 
DRM_DEBUG_DRIVER(set backlight PWM = %d\n, level);
level = intel_panel_compute_brightness(dev, pipe, level);
@@ -493,11 +515,16 @@ static void intel_panel_actually_set_backlight(struct 
drm_device *dev,
pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
}
 
-   tmp = I915_READ(BLC_PWM_CTL);
+   if (IS_VALLEYVIEW(dev))
+   reg = VLV_BLC_PWM_CTL(pipe);
+   else
+   reg = BLC_PWM_CTL;
+
+   tmp = I915_READ(reg);
if (INTEL_INFO(dev)-gen  4)
level = 1;
tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
-   I915_WRITE(BLC_PWM_CTL, tmp | level);
+   I915_WRITE(reg, tmp | level);
 }
 
 /* set backlight brightness to level in

[Intel-gfx] [PATCH 1/2] drm/i915: make backlight functions take a connector

On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info.  So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c  |  8 +
 drivers/gpu/drm/i915/intel_dp.c   |  5 ++-
 drivers/gpu/drm/i915/intel_drv.h  |  8 +++--
 drivers/gpu/drm/i915/intel_lvds.c |  9 +++--
 drivers/gpu/drm/i915/intel_opregion.c | 28 ++-
 drivers/gpu/drm/i915/intel_panel.c| 66 +--
 6 files changed, 88 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9a7136c..d6a1868 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9716,6 +9716,14 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
drm_crtc_helper_add(intel_crtc-base, intel_helper_funcs);
 }
 
+enum pipe intel_get_pipe_from_connector(struct intel_connector *connector)
+{
+   struct intel_encoder *encoder = connector-encoder;
+   struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
+
+   return crtc-pipe;
+}
+
 int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
struct drm_file *file)
 {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..ef69d31 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,7 +1252,6 @@ void ironlake_edp_backlight_on(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
-   int pipe = to_intel_crtc(intel_dig_port-base.base.crtc)-pipe;
u32 pp;
u32 pp_ctrl_reg;
 
@@ -1275,7 +1274,7 @@ void ironlake_edp_backlight_on(struct intel_dp *intel_dp)
I915_WRITE(pp_ctrl_reg, pp);
POSTING_READ(pp_ctrl_reg);
 
-   intel_panel_enable_backlight(dev, pipe);
+   intel_panel_enable_backlight(intel_dp-attached_connector);
 }
 
 void ironlake_edp_backlight_off(struct intel_dp *intel_dp)
@@ -1288,7 +1287,7 @@ void ironlake_edp_backlight_off(struct intel_dp *intel_dp)
if (!is_edp(intel_dp))
return;
 
-   intel_panel_disable_backlight(dev);
+   intel_panel_disable_backlight(intel_dp-attached_connector);
 
DRM_DEBUG_KMS(\n);
pp = ironlake_get_pp_control(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a17a86a..e9b7540 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -619,6 +619,7 @@ void intel_connector_attach_encoder(struct intel_connector 
*connector,
 struct drm_encoder *intel_best_encoder(struct drm_connector *connector);
 struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 struct drm_crtc *crtc);
+enum pipe intel_get_pipe_from_connector(struct intel_connector *connector);
 int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
struct drm_file *file_priv);
 enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
@@ -767,10 +768,11 @@ void intel_pch_panel_fitting(struct intel_crtc *crtc,
 void intel_gmch_panel_fitting(struct intel_crtc *crtc,
  struct intel_crtc_config *pipe_config,
  int fitting_mode);
-void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max);
+void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
+  u32 max);
 int intel_panel_setup_backlight(struct drm_connector *connector);
-void intel_panel_enable_backlight(struct drm_device *dev, enum pipe pipe);
-void intel_panel_disable_backlight(struct drm_device *dev);
+void intel_panel_enable_backlight(struct intel_connector *connector);
+void intel_panel_disable_backlight(struct intel_connector *connector);
 void intel_panel_destroy_backlight(struct drm_device *dev);
 enum drm_connector_status intel_panel_detect(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index fb3f8ef..f3069ae2 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -206,7 +206,8 @@ static void intel_enable_lvds(struct intel_encoder *encoder)
 {
struct drm_device *dev = encoder-base.dev;
struct intel_lvds_encoder *lvds_encoder = 
to_lvds_encoder(encoder-base);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+   struct intel_connector *intel_connector =
+   lvds_encoder-attached_connector-base;
struct

[Intel-gfx] [PATCH] drm/i915/vlv: untangle integrated clock source handling v3