Commit Graph

7617 Commits

Author SHA1 Message Date
Ben Widawsky
8dee3eea3c drm/i915: Never read FORCEWAKE
The same designer from the previous patch has told us to never read
FORCEWAKE. We only do this for the POSTING_READ(), so simply change that
to something within the same cacheline (for no reason in particular
other than it sounds nice). In the _mt case we can leverage
the gtfifodbg check for the POSTING_READ.

This partially reverts
commit 6af2d180f8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 16:24:50 2012 +0200

    drm/i915: fix forcewake related hangs on snb

v2: commit message, comments about posting read from (Daniel)

Note: vlv forcewake doesn't need any changes for this special
treatment since FORCEWAKE_VLV is in a totally different register
range, and the readback FORCEWAKE_ACK_VLV readback that follows is in
the same range.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:28:32 +02:00
Ben Widawsky
057d386061 drm/i915: Change forcewake timeout to 2ms
A designer familiar with the hardware has stated that the forcewake
timeout can theoretically be as high as a little over 1ms. Therefore we
modify our code to use 2ms (appropriate fudge and because we don't want
to round down).

Hopefully this can't prevent spurious timeouts.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.oc.uk>
[danvet: again fix conflict with vlv patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:28:28 +02:00
Ben Widawsky
0cc2764cc4 drm/i915: use cpu_relax() in wait_for_atomic
As part of the advice given to us from the hardware designers regarding
the maximum wait time on the forcewake handshake we need to move from us
granularity to ms granularity. In earlier patches to do this, Jani
noticed that wait_for_us was properly converted to use cpu_relax(), but
wait_for was not.

The issue has existed since the introduction of the macro:
commit 913d8d1100
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Aug 7 11:01:35 2010 +0100

    drm/i915: Ensure that while(INREG()) are bounded (v2)

CC: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.oc.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:21:29 +02:00
Ben Widawsky
b67a4376d5 drm/i915: Extract forcewake ack timeout
It's used all over the place, and we want to be able to play around with
the value, apparently. Note that it doesn't touch other timeouts of the
same value (like gtfifo, and thread C0 wait).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.oc.uk>
[danvet: fixup conflict with vlv forcewake patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:20:43 +02:00
Jani Nikula
5fa7ac9c9c drm/i915: fix sdvo hotplug support check and activation
The sdvo hotplug support check and activation has worked by coincidence for
TMDS0. The boolean value returned by intel_sdvo_supports_hotplug() was
masked with a bit shifted by device number, which also should have been one
of SDVO_OUTPUT_* bits instead. Boolean true masked with 1 shifted by 0 just
happened to match SDVO_OUTPUT_TMDS0...

Get hotplug support as a bit mask, check the correct bits for support, and
use the correct bits for activating hotplug support.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:30 +02:00
Jani Nikula
ff04b35af0 drm/i915: only enable sdvo hotplug irq if needed
Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:

commit 768b107e4b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri May 4 11:29:56 2012 +0200

    drm/i915: disable sdvo hotplug on i945g/gm

v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Tested-by: Dominik Köppl <dominik@devwork.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:29 +02:00
Chris Wilson
a2c7f6fd4d drm/i915: Convert remaining debugfs iterators over rings to for_each_ring()
For code consolidation and future maintainability.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-Tested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:29 +02:00
Daniel Vetter
8a038fd633 drm/i915: differ error message between forcwake timeouts
<ickle> danvet: in the force wake, both DRM_ERRORs have the same string.
<ickle> useful for .txt shrinkage, horrible for debugging

Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:28 +02:00
Daniel Vetter
5ab140a4ac drm/i915: align vlv forcewake with common lore
For some odd reasons, the vlv forcewake code is rather different from
all other platforms, with no clear justification. Adjust things:

- Don't check whether the gt is awake already (and bail out early), we
  need to grab a forcewake anyway. Otherwise the chip might go to
  sleep too early. And this would also screw up our forcewake
  accounting.
- Like all other platforms, check whether the gt has cleared the
  forcewake bit in the _ACK register before setting it again.
- Use _MASKED_BIT_ENABLE/DISABLE macros
- Only use bit0 of the forcewake reg, not all 16 bits.
- check the gtfifodb reg like on all other platforms in _put.
- Drop the POSTING_READs for consistency.

v2: Failure to git add ... again.

v3: Fixup the spelling fail a bit.

Tested-by: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>
Tested-by: "Widawsky, Benjamin" <benjamin.widawsky@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:28 +02:00
Daniel Vetter
be2cde9a6d drm/i915: add a tracepoint for gpu frequency changes
We've had and still have too many issues where the gpu turbo doesn't
quite to what it's supposed to do (or what we want it to do).

Adding a tracepoint to track when the desired gpu frequency changes
should help a lot in characterizing and understanding problematic
workloads.

Also, this should be fairly interesting for power tuning (and
especially noticing when the gpu is stuck in high frequencies, as has
happened in the past) and hence for integration into powertop and
similar tools.

Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:27 +02:00
Daniel Vetter
20e4d407fb drm/ips: move drps/ips/ilk related variables into dev_priv->ips
Like with the equivalent change for gen6+ rps state, this helps in
clarifying the code (and in fixing a few places that have fallen through
the cracks in the locking review).

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:27 +02:00
Paulo Zanoni
f39876317a drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:

"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."

Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.

There's also a second workaround for the PIPE_CONTROL command itself:

"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"

For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+

Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.

This is a regression that has been introduced in the pipe_control
cleanup:

commit 6c6cf5aa9c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 18:02:28 2012 +0100

    drm/i915: Only apply the SNB pipe control w/a to gen6

It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:26 +02:00
Paulo Zanoni
b311150927 drm/i915: add workarounds directly to gen6_render_ring_flush
Since gen 7+ now run the new gen7_render_ring_flush function.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:26 +02:00
Paulo Zanoni
4772eaebcd drm/i915: add gen7_render_ring_flush
For now, just a copy of gen6_render_ring_flush. Different gens have
different workarounds, so we want different functions.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03 10:09:25 +02:00
Daniel Vetter
85f9e50d81 drm/i915: move i915_get_extra_insdone out of CONFIG_DEBUG_FS block
Otherwise it just won't compile ...

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-09-03 18:06:37 +10:00
Dave Airlie
65983bd605 Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
"New stuff for -next. Highlights:
- prep patches for the modeset rework. Note that one of those patches
  touches the fb helper in the common drm code.
- hasw hdmi audio support (Wang Xingchao)
- improved instdone dumping for gen7 (Ben)
- unbound tracking and a few follow-up patches from Chris
- dma_buf->begin/end_cpu_access plus fix for drm/udl (Dave)
- improve mmio error reporting for hsw
- prep patch for WQ_NON_REENTRANT removal (Tejun Heo)
"

* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (41 commits)
  drm/i915: Remove __GFP_NO_KSWAPD
  drm/i915: disable rc6 on ilk when vt-d is enabled
  drm/i915: Avoid unbinding due to an interrupted pin_and_fence during execbuffer
  drm/i915: Use new INSTDONE registers (Gen7+)
  drm/i915: Add new INSTDONE registers
  drm/i915: Extract reading INSTDONE
  drm/i915: Use a non-blocking wait for set-to-domain ioctl
  drm/i915: Juggle code order to ease flow of the next patch
  drm/i915: Use cpu relocations if the object is in the GTT but not mappable
  drm/i915: Extract general object init routine
  drm/i915: Protect private gem objects from truncate (such as imported dmabuf)
  drm/i915: Only pwrite through the GTT if there is space in the aperture
  i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
  drm/i915: Find unclaimed MMIO writes.
  drm/i915: Add ERR_INT to gen7 error state
  drm/i915: Cantiga+ cannot handle a hsync front porch of 0
  drm/i915: fix reassignment of variable "intel_dp->DP"
  drm/i915: Try harder to allocate an mmap_offset
  drm/i915: Show pin count in debugfs
  drm/i915: Show (count, size) of purgeable objects in i915_gem_objects
  ...
2012-09-03 12:05:01 +10:00
Sedat Dilek
d7c3b937bd drm/i915: Remove __GFP_NO_KSWAPD
When I pulled-in today's drm-intel-next into linux-next (next-20120824)
I saw this build-breakage:

drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_object_get_pages_gtt':
drivers/gpu/drm/i915/i915_gem.c:1778:40: error: '__GFP_NO_KSWAPD' undeclared (first use in this function)
drivers/gpu/drm/i915/i915_gem.c:1778:40: note: each undeclared identifier is reported only once for each function it appears in

This is caused by commit ba099ef165f8 ("mm: remove __GFP_NO_KSWAPD")
and commit b6beae2c2014 ("mm: remove __GFP_NO_KSWAPD fixes") in
linux-next (next-20120824).

Fix this by removing __GFP_NO_KSWAPD from drm/i915 driver.

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-27 17:11:38 +02:00
Dave Airlie
93bb70e0c0 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next
There was some merge conflicts in -next and they weren't so pretty, so
backmerge now to avoid them.

Conflicts:
	drivers/gpu/drm/i915/i915_gem.c
	drivers/gpu/drm/i915/intel_modes.c
2012-08-27 16:22:20 +10:00
Daniel Vetter
cd7988eea5 drm/i915: disable rc6 on ilk when vt-d is enabled
It blows up. And hopefully this is the root-cause of the mysterious
rc6 related hang on ilk. For reference, the commit that enabled rc6 on
ilk again is:

commit 456470eb58
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 8 23:35:40 2012 +0200

    drm/i915: enable rc6 on ilk again

Reported-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-26 20:35:57 +02:00
Chris Wilson
7788a76520 drm/i915: Avoid unbinding due to an interrupted pin_and_fence during execbuffer
If we need to stall in order to complete the pin_and_fence operation
during execbuffer reservation, there is a high likelihood that the
operation will be interrupted by a signal (thanks X!). In order to
simplify the cleanup along that error path, the object was
unconditionally unbound and the error propagated. However, being
interrupted here is far more common than I would like and so we can
strive to avoid the extra work by eliminating the forced unbind.

v2: In discussion over the indecent colour of the new functions and
unwind path, we realised that we can use the new unreserve function to
clean up the code even further.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 21:02:51 +02:00
Ben Widawsky
050ee91f12 drm/i915: Use new INSTDONE registers (Gen7+)
Using the extracted INSTDONE reading, and our new register definitions,
update our hangcheck detection and error collection to use it. This
primarily means changing == to memcmp, and changing = to memcpy.
Hopefully this will give more info on error dump, and provide more
accurate hangcheck detection (both are actually TBD).

Also, remove the reading of instdone1 from the ring error collection
function, and just crap everything in capture_error_state (that could be
split into a separate patch if it wasn't so trivial).

v2: Now assuming i915_get_extra_instdone does the memset we can clean up the
code a bit (Jani)

v3: use ARRAY_SIZE as requested earlier by Jani (didn't change sizeof)
Updated commit msg

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 16:58:36 +02:00
Ben Widawsky
d53bd48459 drm/i915: Add new INSTDONE registers
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 16:58:12 +02:00
Ben Widawsky
bd9854f995 drm/i915: Extract reading INSTDONE
INSTDONE is used in many places, and it varies from generation to
generation. This provides a good reason for us to extract the logic to
read the relevant information.

The patch has no functional change. It's prep for some new stuff.

v2: move the memset inside of i915_get_extra_instdone (Jani)
v3,4: bugs caught by (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 16:57:54 +02:00
Chris Wilson
3236f57a01 drm/i915: Use a non-blocking wait for set-to-domain ioctl
The principal use for set-to-domain is for userspace to serialise
operations with a particular buffer, for example to maintain coherency
with a CPU map or to ratelimit its rendering by waiting on all previous
operations before continuing. As such we tend to hold the struct_mutex
for long periods during the synchronisation and so cause contention
issues with other users of the graphics device, even for independent
operations as memory management. An example is the contention between
compiz and X which causes jitter in the display and a drop in peak
throughput.

The ultimate solution would be a set of fine grained locks and lockless
operations, but an intermediate step is to first attempt the
synchronisation for set-to-domain without holding the mutex. This
introduces a number of race conditions, so we limit it use to the ioctl
periphery where we have no dependent state and can safely complete with
a locked synchronisation afterwards.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 11:12:56 +02:00
Chris Wilson
b361237bcc drm/i915: Juggle code order to ease flow of the next patch
Move the wait-for-rendering logic around in the file so that we can
group it together with the subsequent variations. The general goal is to
have the lower level routines clustered together and then the higher
level logic building upon those low level routines that came before.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 11:12:53 +02:00
Alan Cox
6f314ebbaa gma500: Fix frequency detection
If we have a 266MHz part we set core_freq to 0 in several spots

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-08-24 17:02:42 +10:00
Jani Nikula
f64c48f1d3 gma500: remove references to drm_display_info raw_edid field
Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-08-24 17:00:37 +10:00
Dave Airlie
ce5fdd6375 gma500: fix incorrect declaration.
this header was incorrect, caused a build failure.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 13:53:49 +10:00
Chris Wilson
504c7267a1 drm/i915: Use cpu relocations if the object is in the GTT but not mappable
This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 02:29:16 +02:00
Chris Wilson
0327d6ba99 drm/i915: Extract general object init routine
As we wish to create specialised object constructions in the near
future that share the same basic GEM object struct, export the default
initializer.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 02:04:38 +02:00
Chris Wilson
4d6294bf77 drm/i915: Protect private gem objects from truncate (such as imported dmabuf)
If the object has no backing shmemfs filp, then we obviously cannot
perform a truncation operation upon it.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 02:04:31 +02:00
Chris Wilson
86a1ee26bb drm/i915: Only pwrite through the GTT if there is space in the aperture
Avoid stalling and waiting for the GPU by checking to see if there is
sufficient inactive space in the aperture for us to bind the buffer
prior to writing through the GTT. If there is inadequate space we will
have to stall waiting for the GPU, and incur overheads moving objects
about. Instead, only incur the clflush overhead on the target object by
writing through shmem.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24 02:03:33 +02:00
Sachin Kamat
78b9c3537e drm: Add misssing static storage class specifier in drm_fb_helper.c file
Fixes the following sparse warning:
drivers/gpu/drm/drm_fb_helper.c:239:6: warning:
symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static?

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 10:01:15 +10:00
Sachin Kamat
ea7f7abcbb drm: Add missing static storage class specifier in drm_irq.c file
Fixes the following sparse warning:
drivers/gpu/drm/drm_irq.c:1239:6:
warning: symbol 'drm_handle_vblank_events' was not declared. Should it be static?

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 10:00:56 +10:00
Mark Brown
0227a7fdc2 drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.

Also remove the suspend function since all it does is log.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:56:08 +10:00
Sachin Kamat
df0b344300 drm/usb: select USB_SUPPORT in Kconfig
DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD.
Thus, selecting USB_SUPPORT in Kconfig avoids the following warning
(detected when DisplayLink was selected using exynos4_defconfig):

warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:54:54 +10:00
Jani Nikula
32285038f5 gma500: remove an unreachable return statement
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:48:48 +10:00
Forest Bond
f835bc0fca gma500: psb_intel_crtc: Drop crtc_enable flag.
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.

Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:43:27 +10:00
Forest Bond
28bbda39b6 gma500: Fix comment mispelling in cdv_intel_limits definition.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:43:21 +10:00
Huacai Chen
04cf55e1fa drm: Handle io prot correctly for MIPS.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Hongliang Tao <taohl@lemote.com>
Signed-off-by: Hua Yan <yanh@lemote.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:41:05 +10:00
Jani Nikula
451023dc32 drm: remove the raw_edid field from struct drm_display_info
Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.

Remove the raw_edid field, and fix drivers as necessary.

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:37:36 +10:00
Jani Nikula
993dcb05e4 drm/ast: fix EDID memory leak
The EDID returned by drm_get_edid() was never freed.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:37:09 +10:00
Jani Nikula
bcd7235cea drm/i915: fix EDID memory leak in SDVO
The EDID returned by drm_get_edid() was never freed.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:37:03 +10:00
Maarten Lankhorst
7d406b1cc0 drm/mgag200: remove unused validate_sequence
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:34:52 +10:00
Maarten Lankhorst
5d77f13c1e drm/cirrus: Remove unused validate_sequence
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:34:46 +10:00
Maarten Lankhorst
a8e2fad3e9 drm/ast: remove unused validate_sequence
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:34:41 +10:00
Alan Cox
f76c0dde78 gma500/cdv: Fix call to cdv_intel_dp_set_m_n
We should be making this call not praying that the values are right.
In addition as noted by Josiah Standing we should be calling this
for eDP as well.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:33:32 +10:00
Laurent Pinchart
4d46259f00 drm: gma500: Kill the GEM glue layer
The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:30:02 +10:00
Zhao Yakui
9a9f5786fc gma500: Disable the clock gating of display controller to make DP/eDP work well
I don't know why the DP/eDP is affected by the clock gating. But the test
shows that it really fixes the DP/eDP clock issue during enabling DP/eDP.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[Updated to only apply the workaround if the device has DP. We don't want
 to do this on netbooks]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:29:31 +10:00
Zhao Yakui
d112a8163f gma500/cdv: Add eDP support
Introduce the eDP support into the driver.

This has been reworked a bit because kernel driver proper uses encoder/connectors
while the legacy Intel driver uses the old output stuff.

It also diverges on the backlight handling. The legacy Intel driver adds a panel
abstraction based upon the i915 one. It's only really used for backlight bits
and we have a perfectly good backlight abstraction which can extend instead.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[ported to upstream driver, redid backlight abstraction]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:29:25 +10:00