Commit Graph

350036 Commits

Author SHA1 Message Date
Alex Deucher
a65a4369f7 drm/radeon: use status regs to determine what to reset (evergreen)
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:53 -05:00
Alex Deucher
f13f7731a2 drm/radeon: use status regs to determine what to reset (6xx/7xx)
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:52 -05:00
Alex Deucher
1c53467144 drm/radeon: rework GPU reset on cayman/TN
Update the code to better match the recommended
programming sequence for soft reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:51 -05:00
Alex Deucher
187e359311 drm/radeon: rework GPU reset on cayman/TN
Update the code to better match the recommended
programming sequence for soft reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:51 -05:00
Alex Deucher
b7630473de drm/radeon: rework GPU reset on evergreen
Update the code to better match the recommended
programming sequence for soft reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:50 -05:00
Alex Deucher
d3cb781e83 drm/radeon: rework GPU reset on r6xx/r7xx
Update the code to better match the recommended
programming sequence for soft reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:49 -05:00
Alex Deucher
410a3418a8 drm/radeon: add a bios scratch asic hung helper
Used by all asic families from r600+.
Flag for the vbios and later instances of the driver
that the GPU is hung.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:49 -05:00
Alex Deucher
9ff0744c6d drm/radeon: add additional reset flags
This adds further flags for fine grained reset.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:48 -05:00
Christian König
14adc89298 drm/radeon: Deprecate UMS support v2
KMS support is out and stable for a couple of years now and
the userspace code has deprecated or abandoned the old UMS interface.

So make the KMS interface the default and deprecate the UMS interface
in the kernel as well.

v2: rebased on alex/drm-next-3.9-wip

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:47 -05:00
Jerome Glisse
0fcb6155cb radeon/kms: cleanup async dma packet checking
This simplify and cleanup the async dma checking.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:47 -05:00
Ilija Hadzic
4e872ae2bb drm/radeon: consolidate redundant macros and constants
After refactoring the _cs logic, we ended up with many
macros and constants that #define the same thing.
Clean'em up.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:46 -05:00
Ilija Hadzic
012e976d42 drm/radeon: use common next_reloc function
This patch eliminates ASIC-specific ***_cs_packet_next_reloc
functions and hooks up the new common function.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:45 -05:00
Ilija Hadzic
e971699309 drm/radeon: pull out common next_reloc function
next_reloc function does the same thing in all ASICs with
the exception of R600 which has a special case in legacy mode.
Pull out the common function in preparation for refactoring.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:45 -05:00
Ilija Hadzic
c3ad63afcd drm/radeon: rename r100_cs_dump_packet to radeon_cs_dump_packet
This function is not limited to r100, but it can dump a
(raw) packet for any ASIC. Rename it accordingly and move
its declaration to radeon.h

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:44 -05:00
Ilija Hadzic
d6e18a3406 drm/radeon: add a check to wait_reg_mem command
WAIT_REG_MEM on register does not allow the use of PFP.
Enforce this restriction when checking packets sent from
userland.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:44 -05:00
Ilija Hadzic
40592a17b8 drm/radeon: refactor vline packet parsing function
vline packet parsing function for R600 and Evergreen+ are
the same, except that they use different registers. Factor
out the algorithm into a common function that uses register
table passed from ASIC-specific caller.

This reduces ASIC-specific function to (trivial) setup
of register table and call into the common function.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:43 -05:00
Ilija Hadzic
9ffb7a6dca drm/radeon: factor out cs_next_is_pkt3_nop function
Once we factored out radeon_cs_packet_parse function,
evergreen_cs_next_is_pkt3_nop and r600_cs_next_is_pkt3_nop
functions became identical, so they can be factored out
into a common function.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:42 -05:00
Ilija Hadzic
c38f34b53e drm/radeon: use common cs packet parse function
We now have a common radeon_cs_packet_parse function
that is good for all ASICs. Hook it up and eliminate
ASIC-specific versions.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:42 -05:00
Ilija Hadzic
4db013110c drm/radeon: implement common cs packet parse function
CS packet parse functions have a lot of in common across
all ASICs. Implement a common function and take care of
small differences between families inside the function.

This patch is a prep for major refactoring and consolidation
of CS parsing code.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:41 -05:00
Ilija Hadzic
66b3543ef3 drm/radeon: fix formatting
Preparatory patch: patches to follow will touch a piece of code
that had broken indentication, so fix it before touching it.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:41 -05:00
Ilija Hadzic
d201450435 drm/radeon: remove unused prototype from radeon_cs
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:40 -05:00
Ilija Hadzic
580f839892 drm/radeon: remove unecessary assignment
length_dw field was assigned twice. While at it, move user_ptr
assignment together with all other assignments to p->chunks[i]
structure to make the code more readable.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:24:39 -05:00
Alex Deucher
3646e4209f drm/radeon: switch back to the CP ring for VM PT updates
For large VM page table updates, we can sometimes generate
more packets than there is space on the ring.  This happens
more readily with the DMA ring since it is 64K (vs 1M for the
CP).  For now, switch back to the CP.  For the next kernel,
I have a patch to utilize IBs for VM PT updates which
alleviates this problem.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=58354

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:19:19 -05:00
Alex Deucher
fd5d93a001 drm/radeon: prevent crash in the ring space allocation
If the requested number of DWs on the ring is larger than
the size of the ring itself, return an error.

In testing with large VM updates, we've seen crashes when we
try and allocate more space on the ring than the total size
of the ring without checking.

This prevents the crash but for large VM updates or bo moves
of very large buffers, we will need to break the transaction
down into multiple batches.  I have patches to use IBs for
the next kernel.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-01-31 16:14:16 -05:00
liu chuansheng
f2d68cf4da drm/radeon: Calling object_unrefer() when creating fb failure
When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().

Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-01-31 16:14:15 -05:00
Alex Deucher
39dc9aabd8 drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout
Some chips seem to need a little delay after blacking out
the MC before the requests actually stop. Stop DMAR errors
reported by Shuah Khan.

Reported-by: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31 16:13:42 -05:00
Michael S. Tsirkin
71f1e45aa9 tcm_vhost: fix pr_err on early kick
It's OK to get kick before backend is set or after
it is cleared, we can just ignore it.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-01-31 13:06:06 -08:00
Benjamin Tissoires
c284979aff HID: i2c-hid: fix i2c_hid_output_raw_report
i2c_hid_output_raw_report is used by hidraw to forward set_report requests.
The current implementation of i2c_hid_set_report needs to take the
report_id as an argument. The report_id is stored in the first byte
of the buffer in argument of i2c_hid_output_raw_report.

Not removing the report_id from the given buffer adds this byte 2 times
in the command, leading to a non working command.

Reported-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-01-31 17:57:53 +01:00
Al Cooper
58b69401c7 MIPS: Function tracer: Fix broken function tracing
Function tracing is currently broken for all 32 bit MIPS platforms.
When tracing is enabled, the kernel immediately hangs on boot.
This is a result of commit b732d439cb
that changes the kernel/trace/Kconfig file so that is no longer
forces FRAME_POINTER when FUNCTION_TRACING is enabled.

MIPS frame pointers are generally considered to be useless because
they cannot be used to unwind the stack. Unfortunately the MIPS
function tracing code has bugs that are masked by the use of frame
pointers. This commit fixes the bugs so that MIPS frame pointers
don't need to be enabled.

The bugs are a result of the odd calling sequence used to call the trace
routine. This calling sequence is inserted into every traceable function
when the tracing CONFIG option is enabled. This sequence is generated
for 32bit MIPS platforms by the compiler via the "-pg" flag.

Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
call to the trace routine "_mcount" (some legacy thing where 2 arguments
used to be pushed on the stack). The _mcount routine is expected to
adjust the sp by +8 before returning.  So when not disabled, the original
jalr and addiu will be there, so _mcount has to adjust sp.

The problem is that when tracing is disabled for a function, the
"jalr _mcount" instruction is replaced with a nop, but the
"addiu sp,sp,-8" is still executed and the stack pointer is left
trashed. When frame pointers are enabled the problem is masked
because any access to the stack is done through the frame
pointer and the stack pointer is restored from the frame pointer when
the function returns.

This patch writes two nops starting at the address of the "jalr _mcount"
instruction whenever tracing is disabled. This means that the
"addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
disabled, there will be two nops.

This is SMP safe because the first time this happens is during
ftrace_init() which is before any other processor has been started.
Subsequent calls to enable/disable tracing when other CPUs ARE running
will still be safe because the enable will only change the first nop
to a "jalr" and the disable, while writing 2 nops, will only be changing
the "jalr". This patch also stops using stop_machine() to call the
tracer enable/disable routines and calls them directly because the
routines are SMP safe.

When the kernel first boots we have to be able to handle the gcc
generated jalr, addui sequence until ftrace_init gets a chance to run
and change the sequence. At this point mcount just adjusts the stack
and returns. When ftrace_init runs, we convert the jalr/addui to nops.
Then whenever tracing is enabled we convert the first nop to a "jalr
mcount+8". The mcount+8 entry point skips the stack adjust.

[ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Cc: rostedt@goodmis.org
Cc: ddaney.cavm@gmail.com
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4806/
Patchwork: https://patchwork.linux-mips.org/patch/4841/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-01-31 15:28:48 +01:00
Alasdair G Kergon
fe7af2d3ba dm: fix write same requests counting
When processing write same requests, fix dm to send the configured
number of WRITE SAME requests to the target rather than the number of
discards, which is not always the same.

Device-mapper WRITE SAME support was introduced by commit
23508a96cd ("dm: add WRITE SAME support").

Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
2013-01-31 14:23:36 +00:00
Steven Rostedt
196897a297 mips: Move __virt_addr_valid() to a place for MIPS 64
Commit d3ce884318 "MIPS: Fix modpost error in modules attepting to use
virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
32, and not for MIPS 64.

When compiling for my yeeloong2, which supposedly supports hibernation,
which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
got this error:

  LD      init/built-in.o
kernel/built-in.o: In function `memory_bm_free':
snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e44c): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e890): undefined reference to `__virt_addr_valid'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2

I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
mmap.c such that it gets compiled for mips 64 and 32.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4842/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-01-31 15:14:59 +01:00
Mike Snitzer
0f640dca08 dm thin: fix queue limits stacking
thin_io_hints() is blindly copying the queue limits from the thin-pool
which can lead to incorrect limits being set.  The fix here simply
deletes the thin_io_hints() hook which leaves the existing stacking
infrastructure to set the limits correctly.

When a thin-pool uses an MD device for the data device a thin device
from the thin-pool must respect MD's constraints about disallowing a bio
from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
chunksize is 1152K and thin-pool chunksize is 256K I see the following
md/raid0 error (with extra debug tracing added to thin_endio) when
mkfs.xfs is executed against the thin device:

md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0

This extra DM debugging shows that the failing bio is spanning across
the first and second logical 1152K chunk (sector 2080 + 255 takes the
bio beyond the first chunk's boundary of sector 2304).  So the bio
splitting that DM is doing clearly isn't respecting the MD limits.

max_hw_sectors_kb is 127 for both the thin-pool and thin device
(queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
precision).  So this explains why bi_size is 130560.

But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
that it doesn't have a .merge function (for bio_add_page to consult
indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
device that has a compulsory merge_bvec_fn.  This scenario is exactly
why DM must resort to sending single PAGE_SIZE bios to the underlying
layer. Some additional context for this is available in the header for
commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").

Long story short, the reason a thin device doesn't properly get
configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
thin_io_hints() is blindly copying the queue limits from the thin-pool
device directly to the thin device's queue limits.

Fix this by eliminating thin_io_hints.  Doing so is safe because the
block layer's queue limits stacking already enables the upper level thin
device to inherit the thin-pool device's discard and minimum_io_size and
optimal_io_size limits that get set in pool_io_hints.  But avoiding the
queue limits copy allows the thin and thin-pool limits to be different
where it is important, namely max_hw_sectors_kb.

Reported-by: Daniel Browning <db@kavod.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2013-01-31 14:11:14 +00:00
Alex Deucher
ed39fadd6d drm/radeon/evergreen+: wait for the MC to settle after MC blackout
Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-01-31 09:03:22 -05:00
Luis Llorente Campo
8de7f4da8f USB: add OWL CM-160 support to cp210x driver
This adds support for the OWL CM-160 electricity monitor to the cp210x
driver.

Signed-off-by: Luis Llorente <luisllorente@luisllorente.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-31 13:51:12 +01:00
Ville Syrjälä
209d52110a drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too
From BSpec / SR01 - Clocking Mode:
"The following sequence must be used when disabling the VGA plane.
 Write SR01 to set bit 5 = 1 to disable video output.
 Wait for 100us.
 Disable the VGA plane via Bit 31 of the MMIO VGA control."

So simply call i915_disable_vga() from i915_redisable_vga().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:13 +01:00
Ville Syrjälä
fe31b574fb drm/i915: Kill IS_DISPLAYREG()
All display registers should now include the proper offset on VLV.
That means IS_DISPLAYREG() is now useless, and we can eliminate it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:13 +01:00
Ville Syrjälä
766aa1c423 drm/i915: Introduce i915_vgacntrl_reg()
The VGACNTRL register has moved around between different platforms.
To handle the differences add i915_vgacntrl_reg() which returns the
correct offset for the VGACNTRL register.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:12 +01:00
Changlong Xie
d93c623354 drm/i915: gen6_gmch_remove can be static
Signed-off-by: Changlong Xie <changlongx.xie@intel.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:12 +01:00
Daniel Vetter
d6dd9eb1d9 drm/i915: dynamic Haswell display power well support
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that early (yet), we need to help us with a trick to simply
check for any edp encoders.

v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.

v3: Made by Paulo Zanoni
  - Rebase patch to be on top of "fix intel_init_power_wells" patch
  - Fix typos
  - Fix a small bug by adding a "connectors_active" check
  - Restore the initial code that unconditionally enables the power
    well when taking over from the BIOS

v4: Made by Paulo Zanoni
  - One more typo spotted by Jani Nikula

v5: Made by Paulo Zanoni
  - Rebase

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:11 +01:00
Paulo Zanoni
693101618a drm/i915: check the power down well on assert_pipe()
If the power well is disabled, we should not try to read its
registers, otherwise we'll get "unclaimed register" messages.

V2: Don't check whether the power well is enabled or not, just check
whether we asked it to be enabled or not: if we asked to disable the
power well, don't use the registers on it, even if it's still enabled.

V3: Fix bug that breaks all non-Haswell machines.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:11 +01:00
Paulo Zanoni
10aa17c86f drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A
The DP_TP_STATUS register for PORT_A doesn't exist. Our documentation
will be fixed soon, so the code does not match it for now.

This solves "Timed out waiting for DP idle patterns" and "unclaimed
register" messages on eDP.

V1: Was called "drm/i915: don't read DP_TP_STATUS(PORT_A)"
V2: Was called "drm/i915: don't send DP idle pattern before normal
pattern on HSW"
V3: Only change the code that touches PORT_A.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:10 +01:00
Daniel Vetter
d5f21e4072 drm/i915: don't run hsw power well code on !hsw
Dumps annoying noise into the dmesg:

[drm:intel_set_power_well] *ERROR* Timeout enabling power well

Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:10 +01:00
Daniel Vetter
6b25a88752 drm/i915: kill cargo-culted locking from power well code
We may not concurrently change the power wells code. Which
is already guaranteed since modesets aren't concurrent. That
leaves races against setup/teardown/suspend/resume, and for
those we already (try) rather hard not to hit concurrent
modesets.

No debug WARN_ON added since that would require us to grab the
modeset locks in init/suspend code. Which is again just cargo
culting since just grabbing the locks in those paths isn't good
enough, we need the right order of operations, too.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:09 +01:00
Chris Wilson
725a5b5402 drm/i915: Only run idle processing from i915_gem_retire_requests_worker
When adding the fb idle detection to mark-inactive, it was forgotten
that userspace can drive the processing of retire-requests. We assumed
that it would be principally driven by the retire requests worker,
running once every second whilst active and so we would get the deferred
timer for free. Instead we spend too many CPU cycles reclocking the LVDS
preventing real work from being done.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Alexander Lam <lambchop468@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843
Cc: stable@vger.kernel.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:09 +01:00
Ben Widawsky
f82855d342 drm/i915: Fix CAGF for HSW
The shift changed, hurray.

Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:08 +01:00
Ben Widawsky
e78891ca76 drm/i915: Reclaim GTT space for failed PPGTT
When the PPGTT init fails, we may as well reuse the space that we were
reserving for the PPGTT PDEs.

This also fixes an extraneous mutex_unlock.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
2013-01-31 11:50:08 +01:00
Ben Widawsky
a54c0c279f drm/i915: remove intel_gtt structure
With the probe call in our dispatch table, we can now cut away the
last three remaining members in the intel_gtt shared struct and so
remove it completely.

v2: Rebased on top of Daniel's series

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: bikeshed commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:07 +01:00
Ben Widawsky
baa09f5fd8 drm/i915: Add probe and remove to the gtt ops
The idea, and much of the code came originally from:

commit 0712f0249c3148d8cf42a3703403c278590d4de5
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Jan 18 17:23:16 2013 -0800

    drm/i915: Create a vtable for i915 gtt

Daniel didn't like the color of that patch series, and so I asked him to
start something which appealed to his sense of color. The preceding
patches are those, and now this is going on top of that.

[extracted from the original commit message]

One immediately obvious thing to implement is our gmch probing. The init
function was getting massively bloated. Fundamentally, all that's needed
from GMCH probing is the GTT size, and the stolen size. It makes design
sense to put the mappable calculation in there as well, but the code
turns out a bit nicer without it (IMO)

The intel_gtt bridge thing is still here, but the subsequent patches
will finish ripping that out.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Bikeshedded one comment (GMADR is just the PCI aperture, we
use it for other things than just accessing tiled surfaces through a
linear view) and cut the newly added long lines a bit. Also one
checkpatch error.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:07 +01:00
Daniel Vetter
3440d26585 drm/i915: extract hw ppgtt setup/cleanup code
At the moment only cosmetics, but being able to initialize/cleanup
arbitrary ppgtt address spaces paves the way to have more than one of
them ... Just in case we ever get around to implementing real
per-process address spaces. Note that in that case another vfunc for
ppgtt would be beneficial though. But that can wait until the code
grows a second place which initializes ppgtts.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:06 +01:00
Daniel Vetter
960e3e429f drm/i915: pte_encode is gen6+
All the other gen6+ hw code has the gen6_ prefix, so be consistent
about it.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31 11:50:06 +01:00