[Intel-gfx] [PATCH] drm/i915: Drop the misleading cast to the wrong user pointer type

2012-09-14 Thread Chris Wilson 
The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
a drm_i915_gem_relocation_entry is very confusing!

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 4ab0083..8186f63 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1102,8 +1102,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
return -ENOMEM;
}
ret = copy_from_user(exec_list,
-(struct drm_i915_relocation_entry __user *)
-(uintptr_t) args-buffers_ptr,
+(void __user *)(uintptr_t)args-buffers_ptr,
 sizeof(*exec_list) * args-buffer_count);
if (ret != 0) {
DRM_DEBUG(copy %d exec entries failed %d\n,
@@ -1142,8 +1141,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
for (i = 0; i  args-buffer_count; i++)
exec_list[i].offset = exec2_list[i].offset;
/* ... and back out to userspace */
-   ret = copy_to_user((struct drm_i915_relocation_entry __user *)
-  (uintptr_t) args-buffers_ptr,
+   ret = copy_to_user((void __user *)(uintptr_t)args-buffers_ptr,
   exec_list,
   sizeof(*exec_list) * args-buffer_count);
if (ret) {
@@ -1197,8 +1195,7 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
ret = i915_gem_do_execbuffer(dev, data, file, args, exec2_list);
if (!ret) {
/* Copy the new buffer offsets back to the user's exec list. */
-   ret = copy_to_user((struct drm_i915_relocation_entry __user *)
-  (uintptr_t) args-buffers_ptr,
+   ret = copy_to_user((void __user *)(uintptr_t)args-buffers_ptr,
   exec2_list,
   sizeof(*exec2_list) * args-buffer_count);
if (ret) {
-- 
1.7.10.4

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

[Intel-gfx] [PATCH 1/2] drm/i915: Limit the ioremap of the PCI bar to the registers

2012-09-14 Thread Chris Wilson 
In the future we may like to experiment with using a WC map of the GTT
portion. However, that will conflict with i915.ko mapping the entire bar
as UC in order to access the GPU registers. Instead we can shrink the
register ioremap to only map the register block.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_dma.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ee9fe72..18bb48b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1460,7 +1460,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 {
struct drm_i915_private *dev_priv;
struct intel_device_info *info;
-   int ret = 0, mmio_bar;
+   int ret = 0, mmio_bar, mmio_size;
uint32_t aperture_size;
 
info = (struct intel_device_info *) flags;
@@ -1524,8 +1524,18 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(32));
 
+   /* Restrict iomap to avoid clobbering the GTT which we want WC mapped.
+* Do not attempt to map the whole BAR!
+*/
mmio_bar = IS_GEN2(dev) ? 1 : 0;
-   dev_priv-regs = pci_iomap(dev-pdev, mmio_bar, 0);
+   if (info-gen  3)
+   mmio_size = 64*1024;
+   else if (info-gen  5)
+   mmio_size = 512*1024;
+   else
+   mmio_size = 2*1024*1024;
+
+   dev_priv-regs = pci_iomap(dev-pdev, mmio_bar, mmio_size);
if (!dev_priv-regs) {
DRM_ERROR(failed to map registers\n);
ret = -EIO;
-- 
1.7.10.4

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

[Intel-gfx] [PATCH 2/2] agp/intel: Use a write-combining map for updating PTEs

2012-09-14 Thread Chris Wilson 
Rewriting the PTE entries using an WC mapping is roughly an order of
magnitude faster than through the uncached mapping. This makes an
observable difference on workloads that cycle through large numbers of
buffers, for example Chromium using ShmPixmaps where virtually all the
CPU time is currently spent rebinding the userptr.

v2: Limit the WC mapping to older generations as we should the TLB
invalidation on SandyBridge+ unreliable.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/char/agp/intel-gtt.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 258873a..8b0f6d19 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -666,9 +666,14 @@ static int intel_gtt_init(void)
 
gtt_map_size = intel_private.base.gtt_total_entries * 4;
 
-   intel_private.gtt = ioremap(intel_private.gtt_bus_addr,
-   gtt_map_size);
-   if (!intel_private.gtt) {
+   intel_private.gtt = NULL;
+   if (INTEL_GTT_GEN  6)
+   intel_private.gtt = ioremap_wc(intel_private.gtt_bus_addr,
+  gtt_map_size);
+   if (intel_private.gtt == NULL)
+   intel_private.gtt = ioremap(intel_private.gtt_bus_addr,
+   gtt_map_size);
+   if (intel_private.gtt == NULL) {
intel_private.driver-cleanup();
iounmap(intel_private.registers);
return -ENOMEM;
-- 
1.7.10.4

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

Re: [Intel-gfx] [PATCH 2/2] agp/intel: Use a write-combining map for updating PTEs

2012-09-14 Thread Chris Wilson 
On Fri, 14 Sep 2012 11:57:47 +0100, Chris Wilson ch...@chris-wilson.co.uk 
wrote:
 v2: Limit the WC mapping to older generations as we should the TLB
 invalidation on SandyBridge+ unreliable.

/me fires his editor and proof-reader

v2: Limit the WC mapping to older generations as we have observed that
the TLB invalidation on SandyBridge+ is unreliable with WC updates.
See i-g-t/tests/gem_gtt_cpu_tlb
-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] drm/i915: Drop the misleading cast to the wrong user pointer type

2012-09-14 Thread Jani Nikula 
On Fri, 14 Sep 2012, Chris Wilson ch...@chris-wilson.co.uk wrote:
 The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
 a drm_i915_gem_relocation_entry is very confusing!

Reviewed-by: Jani Nikula jani.nik...@intel.com


 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 4ab0083..8186f63 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1102,8 +1102,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
   return -ENOMEM;
   }
   ret = copy_from_user(exec_list,
 -  (struct drm_i915_relocation_entry __user *)
 -  (uintptr_t) args-buffers_ptr,
 +  (void __user *)(uintptr_t)args-buffers_ptr,
sizeof(*exec_list) * args-buffer_count);
   if (ret != 0) {
   DRM_DEBUG(copy %d exec entries failed %d\n,
 @@ -1142,8 +1141,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
   for (i = 0; i  args-buffer_count; i++)
   exec_list[i].offset = exec2_list[i].offset;
   /* ... and back out to userspace */
 - ret = copy_to_user((struct drm_i915_relocation_entry __user *)
 -(uintptr_t) args-buffers_ptr,
 + ret = copy_to_user((void __user *)(uintptr_t)args-buffers_ptr,
  exec_list,
  sizeof(*exec_list) * args-buffer_count);
   if (ret) {
 @@ -1197,8 +1195,7 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
   ret = i915_gem_do_execbuffer(dev, data, file, args, exec2_list);
   if (!ret) {
   /* Copy the new buffer offsets back to the user's exec list. */
 - ret = copy_to_user((struct drm_i915_relocation_entry __user *)
 -(uintptr_t) args-buffers_ptr,
 + ret = copy_to_user((void __user *)(uintptr_t)args-buffers_ptr,
  exec2_list,
  sizeof(*exec2_list) * args-buffer_count);
   if (ret) {
 -- 
 1.7.10.4

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

[Intel-gfx] Valid DP connection without EDID?

2012-09-14 Thread Takashi Iwai 
Hi,

we've got a machine showing a ghost DP2 output on a docking station.
The docking station has only one DP port and it's connected to DP1.
As a result, we get an DP2 active output containing the bogus VESA
standard modes 1024x768, 800x600, 640x480 although it's not connected
at all.

Looking a bit deeply on it, it seems that the connector gives actually
the valid DPCD.  So intel_dp_detect() returns
connector_status_connected.  But since there is no real connection,
EDID isn't obtained.  Thus of course no valid modes set.

A quick patch below adds (moves) a check of EDID and returns the
disconnected state when no valid EDID is returned.  An open question
is whether this is really safe.  Is there any case where no valid EDID
is returned but the connection is still valid?


thanks,

Takashi

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a6c426a..144da02 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2200,16 +2200,17 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
 
intel_dp_probe_oui(intel_dp);
 
+   edid = intel_dp_get_edid(connector, intel_dp-adapter);
+   if (!edid)
+   return connector_status_disconnected;
+
if (intel_dp-force_audio != HDMI_AUDIO_AUTO) {
intel_dp-has_audio = (intel_dp-force_audio == HDMI_AUDIO_ON);
} else {
-   edid = intel_dp_get_edid(connector, intel_dp-adapter);
-   if (edid) {
-   intel_dp-has_audio = drm_detect_monitor_audio(edid);
-   connector-display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   intel_dp-has_audio = drm_detect_monitor_audio(edid);
}
+   connector-display_info.raw_edid = NULL;
+   kfree(edid);
 
return connector_status_connected;
 }

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

[Intel-gfx] macbook pro retina and intel

2012-09-14 Thread Benoit Gschwind 
Hello,

I get an issue with mac book pro retina with git snapshot of kernel[1].
the screen flickering like this http://www.youtube.com/watch?v=Oq0l-bHmSYE

anyone has an idea where the issue can come ?

if not this could be a bug report ^^

the flickering is more visible on screen update, like refresh firefox page.

Best regards

[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=fbcbe2b3c92ee1c930dcfcf8bb764074c100fd63
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Valid DP connection without EDID?

2012-09-14 Thread Adam Jackson 

On 9/14/12 10:19 AM, Takashi Iwai wrote:

Hi,

we've got a machine showing a ghost DP2 output on a docking station.
The docking station has only one DP port and it's connected to DP1.
As a result, we get an DP2 active output containing the bogus VESA
standard modes 1024x768, 800x600, 640x480 although it's not connected
at all.

Looking a bit deeply on it, it seems that the connector gives actually
the valid DPCD.  So intel_dp_detect() returns
connector_status_connected.  But since there is no real connection,
EDID isn't obtained.  Thus of course no valid modes set.


Can you be more specific here?  What DPCD does it return?  Does it claim 
to be a branch device?  We don't currently get that case right, try for 
instance plugging in a DP-VGA pigtail.



A quick patch below adds (moves) a check of EDID and returns the
disconnected state when no valid EDID is returned.  An open question
is whether this is really safe.  Is there any case where no valid EDID
is returned but the connection is still valid?


DisplayPort requires EDID.  There may be a platform method for obtaining 
it for eDP, but for normal DP it has to exist over AUXCH.


DVI and HDMI require it too, in fact.  The only one that doesn't is VGA.

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

Re: [Intel-gfx] [pull] drm-intel-next

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote:
 This tree gives me recursive dependency problems, which ends up
 removing a big ( important) part of my .config:
 
 [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09
 HEAD is now at e04190e drm/fb helper: don't call
 drm_helper_connector_dpms directly
 [bpowers@fina linux]$ git status
 # On branch master
 # Your branch and 'origin/master' have diverged,
 # and have 207 and 323 different commits each, respectively.
 #
 nothing to commit (working directory clean)
 [bpowers@fina linux]$ make oldconfig
 scripts/kconfig/conf --oldconfig Kconfig
 drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
 drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on 
 USB_ARCH_HAS_HCD
 drivers/usb/Kconfig:76:   symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
 drivers/usb/Kconfig:58:   symbol USB_SUPPORT is selected by DRM_USB
 drivers/gpu/drm/Kconfig:22:   symbol DRM_USB is selected by DRM_UDL
 #
 # configuration written to .config
 #

That's an issue with Dave Airlie's udl code I'd say - the drm-intel-next
tree here simply includes a few drm-next patches already. Dave?
-Daniel

 
 
 I've attached my config  the diff between what is attached and the
 result of make oldconfig.  Let me know if there is any other info that
 would help, or if I'm just doing something boneheaded.  Thanks!
 
 yours,
 Bobby
 
 On Thu, Sep 13, 2012 at 10:18 AM, Daniel Vetter dan...@ffwll.ch wrote:
  Hi Dave,
 
  The big ticket item here is the new i915 modeset infrastructure.
  Shockingly it didn't not blow up all over the place (i.e. I've managed to
  fix the ugly issues before merging). 1-2 smaller corner cases broke, but
  we have patches. Also, there's tons of patches on top of this that clean
  out cruft and fix a few bugs that couldn't be fixed with the crtc helper
  based stuff. So more stuff to come ;-)
 
  Also a few other things:
  - Tiny fix in the fb helper to go through the official dpms interface
instead of calling the crtc helper code.
  - forcewake code frobbery from Ben, code should be more in-line with
what Windows does now.
  - fixes for the render ring flush on hsw (Paulo)
  - gpu frequency tracepoint
  - vlv forcewake changes to better align it with our understanding of the
forcewake magic.
  - a few smaller cleanups
 
  Cheers, Daniel
 
 
  The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:
 
drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)
 
  are available in the git repository at:
 
git://people.freedesktop.org/~danvet/drm-intel 
  tags/drm-intel-next-2012-09-09
 
  for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:
 
drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 
  00:51:15 +0200)
 
  
 
  Ben Widawsky (5):
drm/i915: Extract forcewake ack timeout
drm/i915: use cpu_relax() in wait_for_atomic
drm/i915: Change forcewake timeout to 2ms
drm/i915: Never read FORCEWAKE
drm/i915: Enable some sysfs stuff without CONFIG_PM
 
  Chris Wilson (1):
drm/i915: Convert remaining debugfs iterators over rings to 
  for_each_ring()
 
  Daniel Vetter (66):
drm/ips: move drps/ips/ilk related variables into dev_priv-ips
drm/i915: add a tracepoint for gpu frequency changes
drm/i915: align vlv forcewake with common lore
drm/i915: differ error message between forcwake timeouts
drm/i915: add crtc-enable/disable vfuncs insted of dpms
drm/i915: rip out crtc prepare/commit indirection
drm/i915: add direct encoder disable/enable infrastructure
drm/i915/hdmi: convert to encoder-disable/enable
drm/i915/tv: convert to encoder enable/disable
drm/i915/lvds: convert to encoder disable/enable
drm/i915/dp: convert to encoder disable/enable
drm/i915/crt: convert to encoder disable/enable
drm/i915/sdvo: convert to encoder disable/enable
drm/i915/dvo: convert to encoder disable/enable
drm/i915: convert dpms functions of dvo/sdvo/crt
drm/i915: rip out encoder-disable/enable checks
drm/i915: clean up encoder_prepare/commit
drm/i915: copypaste drm_crtc_helper_set_config
drm/i915: call set_base directly
drm/i915: inline intel_best_encoder
drm/i915: copypaste drm_crtc_helper_set_mode
drm/i915: simplify intel_crtc_prepare_encoders
drm/i915: rip out encoder-prepare/commit
drm/i915: call crtc functions directly
drm/i915: WARN when trying to enabled an unused crtc
drm/i915: Add interfaces to read out encoder/connector hw state
drm/i915/dp: implement get_hw_state
drm/i915/hdmi: implement get_hw_state
drm/i915/tv: implement get_hw_state
drm/i915/lvds: implement get_hw_state
drm/i915/crt: implement

[Intel-gfx] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches

2012-09-14 Thread Nicolas Kalkhof 
Hello,the patchset from ~danvet/drm-intel git from earlier september concerning forcewake and gpu frequency made my SNB much calmer during idle times. However the GPU wont hit the turbo throttle when the load goes up resulting in very low framerates during gameplay. Most times the frequency read from /sys/class/drm/card0/gt_cur_freq_mhz is stuck to the lowest frequency.Sysfs yields the following during load spikes:i915_gen6_forcewake_count: 1i915_cur_delayinfo:GT_PERF_STATUS: 0x0d8aRPSTAT1: 0x00040d00Render p-state ratio: 13Render p-state VID: 138Render p-state limit: 255CAGF: 650MHzRP CUR UP EI: 18814usRP CUR UP: 10217usRP PREV UP: 43514usRP CUR DOWN EI: 0usRP CUR DOWN: 0usRP PREV DOWN: 0usLowest (RPN) frequency: 650MHzNominal (RP1) frequency: 650MHzMax non-overclocked (RP0) frequency: 1300MHzsensors:acpitz-virtual-0Adapter: Virtual devicetemp1: +62.0 C (crit = +98.0 C)coretemp-isa-Adapter: ISA adapterPhysical id 0: +63.0 C (high = +86.0 C, crit = +100.0 C)Core 0: +63.0 C (high = +86.0 C, crit = +100.0 C)Core 1: +63.0 C (high = +86.0 C, crit = +100.0 C)/sys/class/drm/card0/gt_cur_freq_mhz: 650/sys/class/drm/card0/gt_max_freq_mhz: 1300/sys/class/drm/card0/gt_min_freq_mhz: 650Kernel Params: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1Setting /sys/class/drm/card0/gt_min_freq_mhz to 1300MHz manually fixes the throttling issue however the gpu obviously wont throttle back then.Any ideas/clues?Best regards,Nic
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Drop the misleading cast to the wrong user pointer type

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 14, 2012 at 04:24:46PM +0300, Jani Nikula wrote:
 On Fri, 14 Sep 2012, Chris Wilson ch...@chris-wilson.co.uk wrote:
  The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
  a drm_i915_gem_relocation_entry is very confusing!
 
 Reviewed-by: Jani Nikula jani.nik...@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] drm/i915: rip out edp special case from dp_link_down

2012-09-14 Thread Daniel Vetter 
On Thu, Sep 13, 2012 at 07:17:55PM -0300, Paulo Zanoni wrote:
 Hi
 
 2012/9/9 Daniel Vetter daniel.vet...@ffwll.ch:
  This has been tons of fun to figure out with git blame. The first
  notion of this code block goes back to the original cpu edp enabling
  for ilk in
 
  commit 32f9d658aee5be09ebdd28fc730630e61d0b46db
  Author: Zhenyu Wang zhen...@linux.intel.com
  Date:   Fri Jul 24 01:00:32 2009 +0800
 
  drm/i915: Add eDP support on IGDNG mobile chip
 
  Two things are notable in this commit wrt to the this edp special
  case:
  - The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
  - The cpu edp port is disabled at the top of the dp_link_down function.
 
  My theory is that these hacks was added to work around the completely
  different modeset sequence for cpu edp ports compared to pch edp
  ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
  this shouldn't be required any more.
 
  The really interesting question is how this special cases survived
  this long in the code. The first step is declaring the pch port D as
  eDP if it's used for an internal panel:
 
  commit b329530ca7cdf6bf014f2124efd983e01265d623
  Author: Adam Jackson a...@redhat.com
  Date:   Fri Jul 16 14:46:28 2010 -0400
 
  drm/i915/dp: Correctly report eDP in the core connector type
 
  This commit unfortunately failed to notice that not all edp ports are
  created equal. Then follow a flurry of refactorings, culminating in a
  patch from Keith Packard which resulted in the current logic (by
  making it correct for all platforms that have edp):
 
  commit 417e822deee1d2bcd8a8a60660c40a0903713f2b
  Author: Keith Packard kei...@keithp.com
  Date:   Tue Nov 1 19:54:11 2011 -0700
 
  drm/i915: Treat PCH eDP like DP in most places
 
  None of these cleanups or refactorings supply any reason why we need
  this code, they've simply carried it on as-is.
 
  Hence presume it might be harmful with the current code and rip it
  out. We do rewrite the link training bits completely anyway when
  re-training the link.
 
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 After looking for a long time I could not find a reason why we should
 set the pattern to train off while disabling the eDP port. Notice
 that train off means send normal pixels (see BSpec). All the docs
 say is that when _enabling_ the port we need to set training pattern
 1, which we should already be doing. After your patch, when we disable
 the port we will disable it with training pattern already set to 1
 (instead of send normal pixels/ train off), but there's nothing
 saying we shouldn't do this. So yeah, your patch looks fine. If we
 ever revert this patch, let's make sure we add a big comment
 explaining it.

Yeah, I if this blows up we can add a fun story to our code in a comment
;-)

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

Thanks for the review, patch is queued for -next.
-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] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 14, 2012 at 06:23:59PM +0200, Nicolas Kalkhof wrote:
 Hello,
 
 the patchset from ~danvet/drm-intel git  from earlier september concerning
 forcewake and gpu frequency made my SNB much calmer during idle times. However
 the GPU won't hit the turbo throttle when the load goes up resulting in very
 low framerates during gameplay. Most times the frequency read from /sys/class/
 drm/card0/gt_cur_freq_mhz is stuck to the lowest frequency.
 
 Sysfs yields the following during load spikes:
 
 i915_gen6_forcewake_count: 1
 
 i915_cur_delayinfo:
 GT_PERF_STATUS: 0x0d8a
 RPSTAT1: 0x00040d00
 Render p-state ratio: 13
 Render p-state VID: 138
 Render p-state limit: 255
 CAGF: 650MHz
 RP CUR UP EI: 18814us
 RP CUR UP: 10217us
 RP PREV UP: 43514us
 RP CUR DOWN EI: 0us
 RP CUR DOWN: 0us
 RP PREV DOWN: 0us
 Lowest (RPN) frequency: 650MHz
 Nominal (RP1) frequency: 650MHz
 Max non-overclocked (RP0) frequency: 1300MHz
 
 sensors:
 acpitz-virtual-0
 Adapter: Virtual device
 temp1:+62.0 C  (crit = +98.0 C)
 coretemp-isa-
 Adapter: ISA adapter
 Physical id 0:  +63.0 C  (high = +86.0 C, crit = +100.0 C)
 Core 0: +63.0 C  (high = +86.0 C, crit = +100.0 C)
 Core 1: +63.0 C  (high = +86.0 C, crit = +100.0 C)
 
 /sys/class/drm/card0/gt_cur_freq_mhz: 650
 /sys/class/drm/card0/gt_max_freq_mhz: 1300
 /sys/class/drm/card0/gt_min_freq_mhz: 650
 
 Kernel Params: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1
 i915.lvds_downclock=1
 
 Setting /sys/class/drm/card0/gt_min_freq_mhz to 1300MHz manually fixes the
 throttling issue however the gpu obviously won't throttle back then.
 
 Any ideas/clues?

One issue we know about is when both gpu/cpu aren't 100% busy the tuning
can get into a death-spiral where we clock down the gpu a bit. Which then
makes the cpu less busy (since in needs to wait more on the gpu),
resulting in the cpu getting downclocked. Which in turn makes the gpu less
busy ...

To check whether it's not this case, can you benchmark with the cpu
frequency fixed to the maximum?

Since things previously worked with the old tuning values I don't think
it's an issue with the up clocking  code itself.
-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] [REPOST PATCH 7/7] drm/i915: Show render P state thresholds in sysfs

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 07, 2012 at 07:43:44PM -0700, Ben Widawsky wrote:
 This is useful for userspace utilities which wish to use the previous
 interface, specifically for micromanaging the increase/decrease steps by
 setting min == max.
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

I've now also queued this and the latest iteration of patch 6, thanks a
lot.
-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 06/24] drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops

2012-09-14 Thread Ben Widawsky 
On Tue,  4 Sep 2012 21:02:58 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 By providing a callback for when we need to bind the pages, and then
 release them again later, we can shorten the amount of time we hold the
 foreign pages mapped and pinned, and importantly the dmabuf objects then
 behave as any other normal object with respect to the shrinker and
 memory management.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
with nitpicks below:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_drv.h|1 -
  drivers/gpu/drm/i915/i915_gem.c|   10 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |   44 
 ++--
  drivers/gpu/drm/i915/i915_gem_gtt.c|4 +--
  4 files changed, 37 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 1a714fa..a86f50d 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -998,7 +998,6 @@ struct drm_i915_gem_object {
   int pages_pin_count;
  
   /* prime dma-buf support */
 - struct sg_table *sg_table;
   void *dma_buf_vmapping;
   int vmapping_count;
  
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 06589a9..58075e3 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1692,7 +1692,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
 *obj)
  {
   const struct drm_i915_gem_object_ops *ops = obj-ops;
  
 - if (obj-sg_table || obj-pages == NULL)
 + if (obj-pages == NULL)
   return 0;
  
   BUG_ON(obj-gtt_space);
 @@ -1838,7 +1838,7 @@ i915_gem_object_get_pages(struct drm_i915_gem_object 
 *obj)
   const struct drm_i915_gem_object_ops *ops = obj-ops;
   int ret;
  
 - if (obj-sg_table || obj-pages)
 + if (obj-pages)
   return 0;
  
   BUG_ON(obj-pages_pin_count);
 @@ -3731,9 +3731,6 @@ void i915_gem_free_object(struct drm_gem_object 
 *gem_obj)
  
   trace_i915_gem_object_destroy(obj);
  
 - if (gem_obj-import_attach)
 - drm_prime_gem_destroy(gem_obj, obj-sg_table);
 -
   if (obj-phys_obj)
   i915_gem_detach_phys_object(dev, obj);
  
 @@ -3755,6 +3752,9 @@ void i915_gem_free_object(struct drm_gem_object 
 *gem_obj)
  
   BUG_ON(obj-pages);
  
 + if (obj-base.import_attach)
 + drm_prime_gem_destroy(obj-base, NULL);
 +
   drm_gem_object_release(obj-base);
   i915_gem_info_remove_obj(dev_priv, obj-base.size);
  

Was the order in which destroy happens moved intentionally?

 diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
 b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 index 4bb1b94..ca3497e 100644
 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 @@ -82,7 +82,8 @@ out:
  }
  
  static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
 - struct sg_table *sg, enum dma_data_direction dir)
 +struct sg_table *sg,
 +enum dma_data_direction dir)
  {
   dma_unmap_sg(attachment-dev, sg-sgl, sg-nents, dir);
   sg_free_table(sg);

I thought we frown upon unnecessary whitespace fixes in patches which
have behavioral changes?

 @@ -228,11 +229,35 @@ struct dma_buf *i915_gem_prime_export(struct drm_device 
 *dev,
   return dma_buf_export(obj, i915_dmabuf_ops, obj-base.size, 0600);
  }
  
 +static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
 +{
 + struct sg_table *sg;
 +
 + sg = dma_buf_map_attachment(obj-base.import_attach, DMA_BIDIRECTIONAL);
 + if (IS_ERR(sg))
 + return PTR_ERR(sg);
 +
 + obj-pages = sg;
 + obj-has_dma_mapping = true;
 + return 0;
 +}
 +
 +static void i915_gem_object_put_pages_dmabuf(struct drm_i915_gem_object *obj)
 +{
 + dma_buf_unmap_attachment(obj-base.import_attach,
 +  obj-pages, DMA_BIDIRECTIONAL);
 + obj-has_dma_mapping = false;
 +}
 +
 +static const struct drm_i915_gem_object_ops i915_gem_object_dmabuf_ops = {
 + .get_pages = i915_gem_object_get_pages_dmabuf,
 + .put_pages = i915_gem_object_put_pages_dmabuf,
 +};
 +
  struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
  {
   struct dma_buf_attachment *attach;
 - struct sg_table *sg;
   struct drm_i915_gem_object *obj;
   int ret;
  
 @@ -251,34 +276,25 @@ struct drm_gem_object *i915_gem_prime_import(struct 
 drm_device *dev,
   if (IS_ERR(attach))
   return ERR_CAST(attach);
  
 - sg = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
 - if (IS_ERR(sg)) {
 - ret = PTR_ERR(sg);
 - goto fail_detach;
 - }
  
   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
   if (obj == NULL) {

Re: [Intel-gfx] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches

2012-09-14 Thread Nicolas Kalkhof 
Hi Daniel,ok fixing cpu freq static to max (2700MHz) on both cores does increase performance a little bit however gpu freq reported by /sys/class/drm/card0/gt_cur_freq_mhz stays fixed at 650 MHz. 
-Nic

Gesendet:Freitag, 14. September 2012 um 18:44 Uhr
Von:Daniel Vetter dan...@ffwll.ch
An:Nicolas Kalkhof nkalk...@web.de
Cc:intel-gfx@lists.freedesktop.org
Betreff:Re: [Intel-gfx] i915/drm: SNB gpu wont throttle up with latest forcewake/gpufreq tracepoint drm patches


On Fri, Sep 14, 2012 at 06:23:59PM +0200, Nicolas Kalkhof wrote:
 Hello,
 
 the patchset from ~danvet/drm-intel git  from earlier september concerning
 forcewake and gpu frequency made my SNB much calmer during idle times. However
 the GPU wont hit the turbo throttle when the load goes up resulting in very
 low framerates during gameplay. Most times the frequency read from /sys/class/
 drm/card0/gt_cur_freq_mhz is stuck to the lowest frequency.
 
 Sysfs yields the following during load spikes:
 
 i915_gen6_forcewake_count: 1
 
 i915_cur_delayinfo:
 GT_PERF_STATUS: 0x0d8a
 RPSTAT1: 0x00040d00
 Render p-state ratio: 13
 Render p-state VID: 138
 Render p-state limit: 255
 CAGF: 650MHz
 RP CUR UP EI: 18814us
 RP CUR UP: 10217us
 RP PREV UP: 43514us
 RP CUR DOWN EI: 0us
 RP CUR DOWN: 0us
 RP PREV DOWN: 0us
 Lowest (RPN) frequency: 650MHz
 Nominal (RP1) frequency: 650MHz
 Max non-overclocked (RP0) frequency: 1300MHz
 
 sensors:
 acpitz-virtual-0
 Adapter: Virtual device
 temp1:+62.0 C  (crit = +98.0 C)
 coretemp-isa-
 Adapter: ISA adapter
 Physical id 0:  +63.0 C  (high = +86.0 C, crit = +100.0 C)
 Core 0: +63.0 C  (high = +86.0 C, crit = +100.0 C)
 Core 1: +63.0 C  (high = +86.0 C, crit = +100.0 C)
 
 /sys/class/drm/card0/gt_cur_freq_mhz: 650
 /sys/class/drm/card0/gt_max_freq_mhz: 1300
 /sys/class/drm/card0/gt_min_freq_mhz: 650
 
 Kernel Params: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1
 i915.lvds_downclock=1
 
 Setting /sys/class/drm/card0/gt_min_freq_mhz to 1300MHz manually fixes the
 throttling issue however the gpu obviously wont throttle back then.
 
 Any ideas/clues?

One issue we know about is when both gpu/cpu arent 100% busy the tuning
can get into a death-spiral where we clock down the gpu a bit. Which then
makes the cpu less busy (since in needs to wait more on the gpu),
resulting in the cpu getting downclocked. Which in turn makes the gpu less
busy ...

To check whether its not this case, can you benchmark with the cpu
frequency fixed to the maximum?

Since things previously worked with the old tuning values I dont think
its an issue with the up clocking  code itself.
-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 06/24] drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops

2012-09-14 Thread Chris Wilson 
On Fri, 14 Sep 2012 11:02:02 -0700, Ben Widawsky b...@bwidawsk.net wrote:
 On Tue,  4 Sep 2012 21:02:58 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:
  @@ -3731,9 +3731,6 @@ void i915_gem_free_object(struct drm_gem_object 
  *gem_obj)
   
  trace_i915_gem_object_destroy(obj);
   
  -   if (gem_obj-import_attach)
  -   drm_prime_gem_destroy(gem_obj, obj-sg_table);
  -
  if (obj-phys_obj)
  i915_gem_detach_phys_object(dev, obj);
   
  @@ -3755,6 +3752,9 @@ void i915_gem_free_object(struct drm_gem_object 
  *gem_obj)
   
  BUG_ON(obj-pages);
   
  +   if (obj-base.import_attach)
  +   drm_prime_gem_destroy(obj-base, NULL);
  +
  drm_gem_object_release(obj-base);
  i915_gem_info_remove_obj(dev_priv, obj-base.size);
   
 
 Was the order in which destroy happens moved intentionally?

Yes. ;)

  diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
  b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  index 4bb1b94..ca3497e 100644
  --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  @@ -82,7 +82,8 @@ out:
   }
   
   static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
  -   struct sg_table *sg, enum dma_data_direction dir)
  +  struct sg_table *sg,
  +  enum dma_data_direction dir)
   {
  dma_unmap_sg(attachment-dev, sg-sgl, sg-nents, dir);
  sg_free_table(sg);
 
 I thought we frown upon unnecessary whitespace fixes in patches which
 have behavioral changes?

Call it a leftover from the time I spent moving much of the common code
to drm_prime.c
-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] sysfs rps test added

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 07, 2012 at 07:43:45PM -0700, Ben Widawsky wrote:
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---

One small improvement would be nice:

[snip]

 +static void writeval(FILE *filp, int val)
 +{
 + rewind(filp);
 + fprintf(filp, %d, val);
 + fflush(filp);
 +}

Adding some assert here to check whether a write we expect to succeed
indeed worked, and that a write we expect to return -EINVAL indeed fails
with that error.
-Daniel

 +
 +#define fcur (readval(stuff[CUR].filp))
 +#define fmin (readval(stuff[MIN].filp))
 +#define fmax (readval(stuff[MAX].filp))
 +#define frp0 (readval(stuff[RP0].filp))
 +#define frp1 (readval(stuff[RP1].filp))
 +#define frpn (readval(stuff[RPn].filp))
 +
 +static void setfreq(int val)
 +{
 + writeval(stuff[MIN].filp, val);
 + writeval(stuff[MAX].filp, val);
 +}
 +
 +static void checkit(void)
 +{
 + restore_assert(fmin = fmax);
 + restore_assert(fcur = fmax);
 + restore_assert(fmin = fcur);
 + restore_assert(frpn = fmin);
 + restore_assert(fmax = frp0);
 + restore_assert(frp1 = frp0);
 + restore_assert(frpn = frp1);
 + restore_assert(frp0 != 0);
 + restore_assert(frp1 != 0);
 +}
 +
 +static void dumpit(void)
 +{
 + struct junk *junk = stuff;
 + do {
 + printf(gt frequency %s (MHz):  %d\n, junk-name, 
 readval(junk-filp));
 + junk++;
 + } while(junk-name != NULL);
 +
 + printf(\n);
 +}
 +
 +
 +int main(int argc, char *argv[])
 +{
 + const int device = drm_get_card(0);
 + struct junk *junk = stuff;
 + int fd, ret;
 +
 + if (argc  1)
 + verbose++;
 +
 + /* Use drm_open_any to verify device existence */
 + fd = drm_open_any();
 + close(fd);
 +
 + do {
 + int val = -1;
 + char *path;
 + ret = asprintf(path, sysfs_base_path, device, junk-name);
 + assert(ret != -1);
 + junk-filp = fopen(path, junk-mode);
 + if (junk-filp == NULL) {
 + fprintf(stderr, Kernel is too old. GTFO\n);
 + exit(77);
 + }
 + val = readval(junk-filp);
 + assert(val = 0);
 + junk++;
 + } while(junk-name != NULL);
 +
 + origmin = fmin;
 + origmax = fmax;
 +
 + if (verbose)
 + printf(Original min = %d\nOriginal max = %d\n, origmin, 
 origmax);
 +
 + if (verbose)
 + dumpit();
 +
 + checkit();
 + setfreq(fmin);
 + if (verbose)
 + dumpit();
 + restore_assert(fcur == fmin);
 + setfreq(fmax);
 + if (verbose)
 + dumpit();
 + restore_assert(fcur == fmax);
 + checkit();
 +
 + /* And some errors */
 + writeval(stuff[MIN].filp, frpn - 1);
 + writeval(stuff[MAX].filp, frp0 + 1000);
 + checkit();
 +
 + writeval(stuff[MIN].filp, fmax + 1000);
 + writeval(stuff[MAX].filp, fmin - 1);
 + checkit();
 +
 + writeval(stuff[MIN].filp, origmin);
 + writeval(stuff[MAX].filp, origmax);
 +
 + exit(EXIT_SUCCESS);
 +}
 -- 
 1.7.12
 
 ___
 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 1/2] drm/i915: Limit the ioremap of the PCI bar to the registers

2012-09-14 Thread Ben Widawsky 
On Fri, 14 Sep 2012 11:57:46 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 In the future we may like to experiment with using a WC map of the GTT
 portion. However, that will conflict with i915.ko mapping the entire bar
 as UC in order to access the GPU registers. Instead we can shrink the
 register ioremap to only map the register block.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Since I really don't want to pull out docs for anything less than
gen6...
Tested-by (IVB): Ben Widawsky b...@bwidawsk.net
Acked-by: Ben Widawsky b...@bwidawsk.net

-- 
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] [pull] drm-intel-next

2012-09-14 Thread Paulo Zanoni 
Hi

2012/9/14 Daniel Vetter dan...@ffwll.ch:
 On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote:
 This tree gives me recursive dependency problems, which ends up
 removing a big ( important) part of my .config:

 [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09
 HEAD is now at e04190e drm/fb helper: don't call
 drm_helper_connector_dpms directly
 [bpowers@fina linux]$ git status
 # On branch master
 # Your branch and 'origin/master' have diverged,
 # and have 207 and 323 different commits each, respectively.
 #
 nothing to commit (working directory clean)
 [bpowers@fina linux]$ make oldconfig
 scripts/kconfig/conf --oldconfig Kconfig
 drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
 drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on 
 USB_ARCH_HAS_HCD
 drivers/usb/Kconfig:76:   symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
 drivers/usb/Kconfig:58:   symbol USB_SUPPORT is selected by DRM_USB
 drivers/gpu/drm/Kconfig:22:   symbol DRM_USB is selected by DRM_UDL
 #
 # configuration written to .config
 #


You want this: 
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=95ca19cf8cbf6163805dc9dc6a83f73b3e75ea13


 That's an issue with Dave Airlie's udl code I'd say - the drm-intel-next
 tree here simply includes a few drm-next patches already. Dave?
 -Daniel



 I've attached my config  the diff between what is attached and the
 result of make oldconfig.  Let me know if there is any other info that
 would help, or if I'm just doing something boneheaded.  Thanks!

 yours,
 Bobby

 On Thu, Sep 13, 2012 at 10:18 AM, Daniel Vetter dan...@ffwll.ch wrote:
  Hi Dave,
 
  The big ticket item here is the new i915 modeset infrastructure.
  Shockingly it didn't not blow up all over the place (i.e. I've managed to
  fix the ugly issues before merging). 1-2 smaller corner cases broke, but
  we have patches. Also, there's tons of patches on top of this that clean
  out cruft and fix a few bugs that couldn't be fixed with the crtc helper
  based stuff. So more stuff to come ;-)
 
  Also a few other things:
  - Tiny fix in the fb helper to go through the official dpms interface
instead of calling the crtc helper code.
  - forcewake code frobbery from Ben, code should be more in-line with
what Windows does now.
  - fixes for the render ring flush on hsw (Paulo)
  - gpu frequency tracepoint
  - vlv forcewake changes to better align it with our understanding of the
forcewake magic.
  - a few smaller cleanups
 
  Cheers, Daniel
 
 
  The following changes since commit 
  d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:
 
drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)
 
  are available in the git repository at:
 
git://people.freedesktop.org/~danvet/drm-intel 
  tags/drm-intel-next-2012-09-09
 
  for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:
 
drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 
  00:51:15 +0200)
 
  
 
  Ben Widawsky (5):
drm/i915: Extract forcewake ack timeout
drm/i915: use cpu_relax() in wait_for_atomic
drm/i915: Change forcewake timeout to 2ms
drm/i915: Never read FORCEWAKE
drm/i915: Enable some sysfs stuff without CONFIG_PM
 
  Chris Wilson (1):
drm/i915: Convert remaining debugfs iterators over rings to 
  for_each_ring()
 
  Daniel Vetter (66):
drm/ips: move drps/ips/ilk related variables into dev_priv-ips
drm/i915: add a tracepoint for gpu frequency changes
drm/i915: align vlv forcewake with common lore
drm/i915: differ error message between forcwake timeouts
drm/i915: add crtc-enable/disable vfuncs insted of dpms
drm/i915: rip out crtc prepare/commit indirection
drm/i915: add direct encoder disable/enable infrastructure
drm/i915/hdmi: convert to encoder-disable/enable
drm/i915/tv: convert to encoder enable/disable
drm/i915/lvds: convert to encoder disable/enable
drm/i915/dp: convert to encoder disable/enable
drm/i915/crt: convert to encoder disable/enable
drm/i915/sdvo: convert to encoder disable/enable
drm/i915/dvo: convert to encoder disable/enable
drm/i915: convert dpms functions of dvo/sdvo/crt
drm/i915: rip out encoder-disable/enable checks
drm/i915: clean up encoder_prepare/commit
drm/i915: copypaste drm_crtc_helper_set_config
drm/i915: call set_base directly
drm/i915: inline intel_best_encoder
drm/i915: copypaste drm_crtc_helper_set_mode
drm/i915: simplify intel_crtc_prepare_encoders
drm/i915: rip out encoder-prepare/commit
drm/i915: call crtc functions directly
drm/i915: WARN when trying to enabled an unused crtc
drm/i915: Add interfaces to read out encoder/connector hw state
drm/i915/dp: implement get_hw_state

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Limit the ioremap of the PCI bar to the registers

2012-09-14 Thread Daniel Vetter 
On Fri, Sep 14, 2012 at 11:50:30AM -0700, Ben Widawsky wrote:
 On Fri, 14 Sep 2012 11:57:46 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:
 
  In the future we may like to experiment with using a WC map of the GTT
  portion. However, that will conflict with i915.ko mapping the entire bar
  as UC in order to access the GPU registers. Instead we can shrink the
  register ioremap to only map the register block.
  
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 
 Since I really don't want to pull out docs for anything less than
 gen6...
 Tested-by (IVB): Ben Widawsky b...@bwidawsk.net
 Acked-by: Ben Widawsky b...@bwidawsk.net

Both patches merged, with the commit message frobbed.

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