While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in "vol4g CPU Display
Registers [DevILK]", Section 4.1.7.1 "DP_A—DisplayPort A
Control Register", "DP_PLL_Frequency_Select".
v2: Keep a debug message as a hint in case something regresses.
Requested by Chris Wilson.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we enable the cpu edp pll in intel_dp->pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp->mode_set callback. Previously this was not possible because
the encoder ->mode_set callbacks are called after the crtc mode set
callback.
v2: Rebase on top of copy&pasted hsw crtc_mode_set.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Especially getting rid of all things lvds is ... great!
v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.
v3:
- handle DP ports correctly (spoted by Paulo)
- don't leave {} behind for a single-line block (again spotted by
Paulo)
- kill another if (IBX || CPT) block
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Before queuing the flip but crucially after attaching the unpin-work to
the crtc, we continue to setup the unpin-work. However, should the
hardware fire early, we see the connected unpin-work and queue the task.
The task then promptly runs and unpins the fb before we finish taking
the required references or even pinning it... Havoc.
To close the race, we use the flip-pending atomic to indicate when the
flip is finally setup and enqueued. So during the flip-done processing,
we can check more accurately whether the flip was expected.
v2: Add the appropriate mb() to ensure that the writes to the page-flip
worker are complete prior to marking it active and emitting the MI_FLIP.
On the read side, the mb should be enforced by the spinlocks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Review the barriers a bit, we need a write barrier both
before and after updating ->pending. Similarly we need a read barrier
in the interrupt handler both before and after reading ->pending. With
well-ordered irqs only one barrier in each place should be required,
but since this patch explicitly sets out to combat spurious interrupts
with is staged activation of the unpin work we need to go full-bore on
the barriers, too. Discussed with Chris Wilson on irc and changes
acked by him.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Having 9500 lines repeated on dmesg does not help me at all.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
TRANS_DP_VIDEO_AUDIO is not used at all.
The other 3 has duplicated #defines.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Less clutter in the traces. And in both cases we yell rather loud
into the logs if we time out. Patch suggested by Chris Wilson.
v2: Annotate another I915_READ in dp_aux to be consistent - we filter
out all register io in wait_for and similar loops. Chris also
suggested to mark all dp_aux register access as _NOTRACE, but I think
we should keep all functionally relevant access around, and filter
unneeded bits in userspace after the trace is captured.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on the platforms that have a dp aux irq and also have it
enabled - vlvhsw should have one, too. But I don't have a machine to
test this on. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an ivb cpu edp machine, so the dp aux A code for
snb/ilk is untested.
For dpcd probing when nothing is connected it slashes about 5ms of cpu
time (cpu time is now negligible), which agrees with 3 * 5 400 usec
timeouts.
A previous version of this patch increases the time required to go
through the dp_detect cycle (which includes reading the edid) from
around 33 ms to around 40 ms. Experiments indicated that this is
purely due to the irq latency - the hw doesn't allow us to queue up
dp aux transactions and hence irq latency directly affects throughput.
gmbus is much better, there we have a 8 byte buffer, and we get the
irq once another 4 bytes can be queued up.
But by using the pm_qos interface to request the lowest possible cpu
wake-up latency this slowdown completely disappeared.
Since all our output detection logic is single-threaded with the
mode_config mutex right now anyway, I've decide not ot play fancy and
to just reuse the gmbus wait queue. But this would definitely prep the
way to run dp detection on different ports in parallel
v2: Add a timeout for dp aux transfers when using interrupts - the hw
_does_ prevent this with the hw-based 400 usec timeout, but if the
irq somehow doesn't arrive we're screwed. Lesson learned while
developing this ;-)
v3: While at it also convert the busy-loop to wait_for_atomic, so that
we don't run the risk of an infinite loop any more.
v4: Ensure we have the smallest possible irq latency by using the
pm_qos interface.
v5: Add a comment to the code to explain why we frob pm_qos. Suggested
by Chris Wilson.
v6: Disable dp irq for vlv, that's easier than trying to get at docs
and hw.
v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the
dp aux registers aren't at a fixed offset any more, but can be on the
PCH while the DP port is on the cpu die.
Reviewed-by: Imre Deak <imre.deak@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doesn't do anything yet than call dp_aux_irq_handler.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use the wait_event_timeout helper directly without
jumping through hoops to catch NAKs.
Since gen2/3 don't have gmbus interrupts, handle them separately with
the old wait_for macro.
This shaves another few ms off reading EDID from a hdmi screen on my
testbox here. EDID reading with interrupt driven gmbus is now as fast
as with busy-looping gmbus at 28 ms here (with negligible cpu
overhead).
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can check for NAKs. This way we also subsume gmbus
support for platforms without interrupts (or where those are not
yet enabled).
The important bit really is to only enable one gmbus interrupt source
at the same time - with that piece of lore figured out, this seems to
work flawlessly.
Ben Widawsky rightfully complained the lack of measurements for the
claimed benefits (especially since the first version was actually
broken and fell back to bit-banging). Previously reading the 256 byte
hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
Given that transfering the 256 bytes over i2c at wire speed takes
20.5ms alone, the reduction in additional overhead is rather nice.
v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
when booting up an hence result in some spurious interrupts. Since we
clear GMBUS4 after every wait and we do gmbus transfer really early in
the setup sequence to detect displays the window is small, but still
be paranoid and clear it properly.
v3: Clarify the comment that gmbus irq generation can only support one
kind of event, why it bothers us and how we work around that limit.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.
Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as "Test mode").
v2: Wire up the irq handler for vlv and gen4 properly.
v3: i915_enable_pipestat expects the mask bit, not the status bits ... and
for added hilarity those are rather inconsistently named.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.
To prepare for this mess, start by extracting the hw status wait
loop into it's own function, consolidate the NAK error handling a
bit. To keep things flexible, pass in the status bit we care about
(in addition to any NAK signalling).
v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted,
Chris Wilson gladly pointed that out for me. To keep things simple,
ignore that case for now (we only need to idle the gmbus controller
at the end of an entire i2c transaction, not after every message).
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.
v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.
v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.
v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.
v6: Fixup cleanup sequence, too.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... together with all the other irq related resources in
intel_irq_init. I've managed to oops in the notify_ring function on my
ilk, presumably because of the powerctx setup call to i915_gpu_idle.
Note that this is only a problem with the reorder irq setup sequence
for irq-driver gmbus/dp aux.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is for legacy legacy stuff, and checking with the leftover
pipe from the previous loop is propably not what we want. Since
pipe == 2 after the loop ... Then we only assing a variable and do
nothing with it.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If there are pre-wrap values in semaphore-mbox registers after wrap,
syncing against some after-wrap request will complete immediately.
Fix this by emitting ring commands to set mbox registers to zero
when the wrap happens.
v2: Use __intel_ring_begin to emit ring commands, from
Chris Wilson.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a small comment to handle_seqno_wrap.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for handling ring seqno wrapping, split
intel_ring_begin into helper part which doesn't allocate
seqno.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When l3 parity support for Haswell was enabled in
commit f27b92651d
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Tue Jul 24 20:47:32 2012 -0700
drm/i915: Expand DPF support to Haswell
no one noticed that the patch which introduced this macro
commit e1ef7cc299
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Tue Jul 24 20:47:31 2012 -0700
drm/i915: Macro to determine DPF support
missed one spot. Fix this.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
seqno's are u32 so print accordingly
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed for testing seqno wrapping. Be careful to not bump next_seqno
more than 0x7FFFFFFF at a time (between some handled requests) as
i915_seqno_passed() can't handle bigger difference in between.
v2: Address review comments from Chris Wilson.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Squash in fixup to properly remove the debugfs file on driver
unload again.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In a couple of places we attempt to adjust the existing watermark
registers to update them for the new cursor watermarks. This goes
horribly wrong as instead of clearing the cursor bits prior to or'ing in
the new values, we clear the rest of the register with the result that
the watermark registers contain bogus values.
References: https://bugs.freedesktop.org/show_bug.cgi?id=47034
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BLC_PWM_CTL2 register does not exist before gen4. While at it, do a
slight drive by cleanup of the code.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- __iomem where there is none (I love how we mix these things up).
- Use gfp_t instead of an other plain type.
- Unconfuse one place about enum pipe vs enum transcoder - for the pch
transcoder we actually use the pipe enum. Fixup the other cases
where we assign the pipe to the cpu transcoder with explicit casts.
- Declare the mch_lock properly in a header.
There is still a decent mess in intel_bios.c about __iomem, but heck,
this is x86 and we're allowed to do that.
Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use a space after the cast consistently and fix up the
newly-added cast in i915_irq.c to properly use __iomem.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply use the last write-domain set for the object in the batch,
trusting userspace to have correctly flushed the caches between usage as
a write target. This check dates back from the golden age of having only
a single operation per batch with the kernel repeating it for each
cliprect, and conflicts both with userspace trying to efficiently batch
multiple operations and with reducing the kernel overhead of relocation
processing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Be specific for the GPU domains so that we can detect if userspace ever
passed in an invalid combination, as well as accurately reflect the
known GPU domains when printing state.
Fixes i-g-t/gem_exec_bad_domains
References: https://bugs.freedesktop.org/show_bug.cgi?id=57826
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From BSpec:
"If the Ring Buffer Head Pointer and the Tail Pointer are on the same
cacheline, the Head Pointer must not be greater than the Tail
Pointer."
The easiest way to enforce this is to reduce the reported ring space.
References:
Gen2 BSpec "1. Programming Environment" / 1.4.4.6 "Ring Buffer Use"
Gen3 BSpec "vol1c Memory Interface Functions" / 2.3.4.5 "Ring Buffer Use"
Gen4+ BSpec "vol1c Memory Interface and Command Stream" / 5.3.4.5 "Ring Buffer Use"
v2: Include the exact BSpec references in the description
v3: s/64/I915_RING_FREE_SPACE, and add the BSpec information to the code
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we may actually allocate in order to save the physical swizzling bits
during the free, we have to be careful not to trigger the shrinker on
the same object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added a small comment in the code to really drive the
scariness of this patch home.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The primary purpose of this was to debug some use-after-free memory
corruption that was causing an OOPS inside drm/i915. As it turned out
the corruption was being caused elsewhere and i915.ko as a major user of
many objects was being hit hardest.
Indeed as we do frequent the generic kmalloc caches, dedicating one to
ourselves (or at least naming one for us depending upon the core) aids
debugging our own slab usage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow for the creation of GEM objects backed by stolen memory. As these
are not backed by ordinary pages, we create a fake dma mapping and store
the address in the scatterlist rather than obj->pages.
v2: Mark _i915_gem_object_create_stolen() as static, as noticed by Jesse
Barnes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to accommodate objects that are not backed by struct pages, but
instead point into a contiguous region of stolen space, we need to make
various changes to avoid dereferencing obj->pages or obj->base.filp.
First introduce a marker for the stolen object, that specifies its
offset into the stolen region and implies that it has no backing pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As FBC is commonly disabled due to limitations of the chipset upon
output configurations, on many systems FBC is never enabled. For those
systems, it is advantageous to make use of the stolen memory for other
objects and so we defer allocation of the FBC chunk until we actually
require it. This increases the likelihood of that allocation failing,
but that in turns means that we are already taking advantage of the
stolen memory!
As well as delaying the allocation from driver initialisation until the
first use of FBC, we also return the stolen block after we finish using
it - allowing greater flexibility in our usage of stolen space. A side
effect of this is that we can then attempt to allocate only the required
amount of space (with a little slack to reduce reallocation rate and
avoid fragmentation).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As yet we do not do any preallocation (chicken-and-egg problem), but we
may like to preserve anything already allocated by the BIOS or grub and
reuse for own purposes after initialising the driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.
Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only need to read/write the south interrupt register if the
corresponding bit is set in the north master interrupt register.
Noticed while reading our interrupt handling code.
Same optimization has already been applied on ivb in
commit 0e43406bcc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed May 9 21:45:44 2012 +0100
drm/i915: Simplify interrupt processing for IvyBridge
We can take advantage that the PCH_IIR is a subordinate register to
reduce one of the required IIR reads, and that we only need to clear
interrupts handled to reduce the writes. And by simply tidying the code
we can reduce the line count and hopefully make it more readable.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
spinlock_t should always be used.
LD drivers/gpu/drm/i915/built-in.o
CHECK drivers/gpu/drm/i915/i915_drv.c
CC [M] drivers/gpu/drm/i915/i915_drv.o
CHECK drivers/gpu/drm/i915/i915_dma.c
CC [M] drivers/gpu/drm/i915/i915_dma.o
CHECK drivers/gpu/drm/i915/i915_irq.c
CC [M] drivers/gpu/drm/i915/i915_irq.o
CHECK drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression
CC [M] drivers/gpu/drm/i915/i915_debugfs.o
CHECK drivers/gpu/drm/i915/i915_suspend.c
CC [M] drivers/gpu/drm/i915/i915_suspend.o
CHECK drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14: expected unsigned int [unsigned] [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14: got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
drivers/gpu/drm/i915/i915_gem.c:3706:22: left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22: right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22: left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22: right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39: expected restricted gfp_t [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39: got unsigned int [unsigned] [usertype] mask
CC [M] drivers/gpu/drm/i915/i915_gem.o
CHECK drivers/gpu/drm/i915/i915_gem_context.c
CC [M] drivers/gpu/drm/i915/i915_gem_context.o
CHECK drivers/gpu/drm/i915/i915_gem_debug.c
CC [M] drivers/gpu/drm/i915/i915_gem_debug.o
CHECK drivers/gpu/drm/i915/i915_gem_evict.c
CC [M] drivers/gpu/drm/i915/i915_gem_evict.o
CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c
CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o
CHECK drivers/gpu/drm/i915/i915_gem_gtt.c
CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o
CHECK drivers/gpu/drm/i915/i915_gem_stolen.c
CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o
CHECK drivers/gpu/drm/i915/i915_gem_tiling.c
CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o
CHECK drivers/gpu/drm/i915/i915_sysfs.c
CC [M] drivers/gpu/drm/i915/i915_sysfs.o
CHECK drivers/gpu/drm/i915/i915_trace_points.c
CC [M] drivers/gpu/drm/i915/i915_trace_points.o
CHECK drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder
CC [M] drivers/gpu/drm/i915/intel_display.o
CHECK drivers/gpu/drm/i915/intel_crt.c
CC [M] drivers/gpu/drm/i915/intel_crt.o
CHECK drivers/gpu/drm/i915/intel_lvds.c
CC [M] drivers/gpu/drm/i915/intel_lvds.o
CHECK drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60: expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60: got void [noderef] <asn:2>*vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42: expected void const *<noident>
drivers/gpu/drm/i915/intel_bios.c:726:42: got unsigned char [noderef] [usertype] <asn:2>*
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression
CC [M] drivers/gpu/drm/i915/intel_bios.o
CHECK drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder
CC [M] drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here
CHECK drivers/gpu/drm/i915/intel_dp.c
CC [M] drivers/gpu/drm/i915/intel_dp.o
CHECK drivers/gpu/drm/i915/intel_hdmi.c
CC [M] drivers/gpu/drm/i915/intel_hdmi.o
CHECK drivers/gpu/drm/i915/intel_sdvo.c
CC [M] drivers/gpu/drm/i915/intel_sdvo.o
CHECK drivers/gpu/drm/i915/intel_modes.c
CC [M] drivers/gpu/drm/i915/intel_modes.o
CHECK drivers/gpu/drm/i915/intel_panel.c
CC [M] drivers/gpu/drm/i915/intel_panel.o
CHECK drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static?
CC [M] drivers/gpu/drm/i915/intel_pm.o
CHECK drivers/gpu/drm/i915/intel_i2c.c
CC [M] drivers/gpu/drm/i915/intel_i2c.o
CHECK drivers/gpu/drm/i915/intel_fb.c
CC [M] drivers/gpu/drm/i915/intel_fb.o
CHECK drivers/gpu/drm/i915/intel_tv.c
CC [M] drivers/gpu/drm/i915/intel_tv.o
CHECK drivers/gpu/drm/i915/intel_dvo.c
CC [M] drivers/gpu/drm/i915/intel_dvo.o
CHECK drivers/gpu/drm/i915/intel_ringbuffer.c
CC [M] drivers/gpu/drm/i915/intel_ringbuffer.o
CHECK drivers/gpu/drm/i915/intel_overlay.c
CC [M] drivers/gpu/drm/i915/intel_overlay.o
CHECK drivers/gpu/drm/i915/intel_sprite.c
CC [M] drivers/gpu/drm/i915/intel_sprite.o
CHECK drivers/gpu/drm/i915/intel_opregion.c
CC [M] drivers/gpu/drm/i915/intel_opregion.o
CHECK drivers/gpu/drm/i915/dvo_ch7xxx.c
CC [M] drivers/gpu/drm/i915/dvo_ch7xxx.o
CHECK drivers/gpu/drm/i915/dvo_ch7017.c
CC [M] drivers/gpu/drm/i915/dvo_ch7017.o
CHECK drivers/gpu/drm/i915/dvo_ivch.c
CC [M] drivers/gpu/drm/i915/dvo_ivch.o
CHECK drivers/gpu/drm/i915/dvo_tfp410.c
CC [M] drivers/gpu/drm/i915/dvo_tfp410.o
CHECK drivers/gpu/drm/i915/dvo_sil164.c
CC [M] drivers/gpu/drm/i915/dvo_sil164.o
CHECK drivers/gpu/drm/i915/dvo_ns2501.c
CC [M] drivers/gpu/drm/i915/dvo_ns2501.o
CHECK drivers/gpu/drm/i915/i915_gem_dmabuf.c
CC [M] drivers/gpu/drm/i915/i915_gem_dmabuf.o
CHECK drivers/gpu/drm/i915/i915_ioc32.c
CC [M] drivers/gpu/drm/i915/i915_ioc32.o
CHECK drivers/gpu/drm/i915/intel_acpi.c
CC [M] drivers/gpu/drm/i915/intel_acpi.o
LD [M] drivers/gpu/drm/i915/i915.o
Building modules, stage 2.
MODPOST 1 modules
CC drivers/gpu/drm/i915/i915.mod.o
LD [M] drivers/gpu/drm/i915/i915.ko
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
supports DP_LINK_BW_5_4 and is also used by the other drivers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do an early return in case we don't have DDI instead of having the
whole function inside an "if" statement.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is not called on Haswell anymore.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's not even declared on header files.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).
But we only need to do this if we start in the cpu domain and the
object requires flushing for coherency. So don't do the flushing if
the object is coherent anyway or if we've done in-line clfushing
already.
v2: i915_gem_clflush_object already checks whether the object is
coherent and if so, drops the flushing. Hence we don't need to check
that ourselves, simplifying the condition.
v3: Reorder the checks for better clarity (and adjust the comment
accordingly), suggested by Chris Wilson.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The shmem paths for pwrite/pread used a clever trick to hold onto a
single page when dropping the big dev->struct_mutex for the slowpath.
But this ran the risk of reinstating (or not completely purging) the
backing storage when dropping purgeable objects.
Hence the code needed to keep track of whether it ever dropped the
lock, and if it did, manually check whether it needs to re-purge the
backing storage. But thanks to the pages pin count introduced in
commit a5570178c0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 4 21:02:54 2012 +0100
drm/i915: Pin backing pages whilst exporting through a dmabuf vmap
which allowed us to pin the backing storage and remove that page
reference trick from shmem_pwrite/read in
commit f60d7f0c1d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 4 21:02:56 2012 +0100
drm/i915: Pin backing pages for pread
and
commit 755d22184f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 4 21:02:55 2012 +0100
drm/i915: Pin backing pages for pwrite
we can now abolish this check. The slowpath cleanup completely
disappears from pread, and for pwrite we're only left with the domain
fixup in case someone moved the object out of the cpu domain from
under us. A follow-on patch will optimize that a notch more.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode
v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether
we shouldn't add an attached_panel pointer to intel_encoder, to
replace the encoder private ->attached_connector pointers, since
that's essentially what we need.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...
v2: Rebase on top of Jani Nikula's panel rework.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yeah, all users (both the clock selection special cases and the lvds
pin pair stuff) are still in common code, but this will change.
v2: Rebase on top of Jani Nikula's panel rework.
v3: Incorporate review from Paulo Zanoni:
- s/__is_dual_link_lvds/compute_is_dual_link_lvds
- kill dev_priv->lvds_val
- drop spurious whitespace change
v4: Add a debug printk to display the dual-link status, as suggested
by Paulo Zanoni in review.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a prep patch to make this a property of intel_lvds. Makes more
sense, removes clutter from intel_display.c and eventually I want to
move all the encoder special cases wrt clock handling to encoders
anyway.
v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static
now.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... with is_dual_link_lvds introduced in
commit b03543857f
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Mar 20 13:07:05 2012 +0100
drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
All these checks predate this commit and have simply been overlooked.
Since we don't support switching between single-link and dual-link
modes anyway, this different checks could at best only get in the way
of refactorings, and in the worst case cause inconsistencies.
v2: Update the comment, we now have a solid way to figure out whether
we need dual-link lvds or not (falling back to vbt values as a last
resort). We still don't know how to switch between dual-link and
single link so leave that part intact. I'm not sure though whether
switching between these two modes makes any sense - we always drive
the panel at its fixed mode (with a fixed bpc) anyway ...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we have two encoder specific bits in the common mode_set
functions:
- lvds pin pair enabling
- dp m/n setting and computation
Now the lvds stuff needs to happen before the pll is enabled. Since
that is done in the crtc_mode_set functions, we need to add a new
callback to be able to move them to the encoder code (where they
belong). The dp m/n stuff is a giant mess anyway (since it also
confuses itself with the fdi link m/n handling), so that needs to be
handled separately.
I think that we can move the pll enabling down quite a bit, which
might allow us to eventually merge encoder->pre_enable with this new
pre_pll_enable callback. But for now this will allow us to clean
things up a bit.
Note that vlv doesn't support lvds, hence we don't need to change
anything in there.
v2: Fixup commit message, both suggested from Paulo Zanoni.
- dp m/n doesn't need to happen before pll enabling
- lvds doesn't exist on vlv, hence no changes required in the vlv pll
function.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we do not have any domains occupying the high bits, there is no point
in always printing the leading 00.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.
This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is still
being scanned out by the display controller.
The recommended alternative is to use the page flip events to
wait for the page flips to fully complete before reusing the BO
of the old front buffer. Or use more buffers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: don't remove obj->pending_flips, still required due to
reorder patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow a chunk of unused register defines ended up in the middle of
the PLL defines. They go back to the original kms merging.
The only used #define is SR01, move it to the register name together
with the other legacy vga stuff.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_handle_seqno_wrap() will zero all sync_seqnos but as the
wrap can happen inside ring->sync_to(), pre wrap seqno was
carried over and overwrote the zeroed sync_seqno.
When wrap is handled, all outstanding requests will be retired and
objects moved to inactive queue, causing their last_read_seqno to be zero.
Use this to update the sync_seqno correctly.
RING_SYNC registers after wrap will contain pre wrap values which
are >= seqno. So injecting the semaphore wait into ring completes
immediately.
Original idea for using last_read_seqno from Chris Wilson.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Should be useful to know what the driver thought the other ring's seqno
was when it last used a semaphore.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Replace the wait for the ring to be clear with the more common wait for
the ring to be idle. The principle advantage is one less exported
intel_ring_wait function, and the removal of a hardcoded value.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we now always preallocate the seqno before writing to the ring, we
can trivially test if we have any pending activity on the ring by
inspecting the olr. This makes it then possible to flush operations that
are not normally associated with a request, like power-management.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the work by Mika Kuoppala, we realised that we need to handle
seqno wraparound prior to committing our changes to the ring. The most
obvious point then is to grab the seqno inside intel_ring_begin(), and
then to reuse that seqno for all ring operations until the next request.
As intel_ring_begin() can fail, the callers must already be prepared to
handle such failure and so we can safely add further checks.
This patch looks like it should be split up into the interface
changes and the tweaks to move seqno wrapping from the execbuffer into
the core seqno increment. However, I found no easy way to break it into
incremental steps without introducing further broken behaviour.
v2: Mika found a silly mistake and a subtle error in the existing code;
inside i915_gem_retire_requests() we were resetting the sync_seqno of
the target ring based on the seqno from this ring - which are only
related by the order of their allocation, not retirement. Hence we were
applying the optimisation that the rings were synchronised too early,
fortunately the only real casualty there is the handling of seqno
wrapping.
v3: Do not forget to reset the sync_seqno upon module reinitialisation,
ala resume.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There seem to be indeed some awkwards machines around, mostly those
without OpRegion support, where the firmware changes the display hw
state behind our backs when closing the lid.
This force-restore logic has been originally introduced in
commit c1c7af6089
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Sep 10 15:28:03 2009 -0700
drm/i915: force mode set at lid open time
but after the modeset-rework we've disabled it in the vain hope that
it's no longer required:
commit 3b7a89fce3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Sep 17 22:27:21 2012 +0200
drm/i915: fix OOPS in lid_notify
Alas, no.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In commit 69c2fc8913
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 12:41:03 2012 +0100
drm/i915: Remove the per-ring write list
the explicit flush was removed from i915_ring_idle(). However, we
continued to wait upon the next seqno which now did not correspond to
any request (except for the unusual condition of a failure to queue a
request after execbuffer) and so would wait indefinitely.
This has an important side-effect that i915_gpu_idle() does not cause
the seqno to be incremented. This is vital if we are to be able to idle
the GPU to handle seqno wraparound, as in subsequent patches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dereference dev_priv only after we know it is valid.
Found with smatch.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some devices may respond very slowly and only flag that the reply is
pending within the first 15us response window. Be kind to such devices
and wait a further 15ms, before checking for the pending reply. This
moves the existing special case delay of 30ms down from the detection
routine into the common path and pretends to explain it...
v2: Simplify the loop constructs as suggested by Jani Nikula.
References: https://bugs.freedesktop.org/show_bug.cgi?id=36997
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently set "0" as the VIC value of the AVI InfoFrames. According
to the specs this should be fine and work for every mode, so to my
point of view we can't consider the current behavior as a bug. The
problem is that we recently received a bug report (Kernel bug #50371)
from a user that has an AV receiver that gives a black screen for any
mode with VIC set to 0.
So in order to make at least some modes work for him, this patch sets
the correct VIC number when sending AVI InfoFrames.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This bug was introduced by me:
commit e76e9aebcd
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Sun Nov 4 09:21:27 2012 -0800
drm/i915: Stop using AGP layer for GEN6+
The existing code uses memset_io which follows memset semantics in only
guaranteeing a write of individual bytes. Since a PTE entry is 4 bytes,
this can only be correct if the scratch page address is 0.
This caused unsightly errors when we clear the range at load time,
though I'm not really sure what the heck is referencing that memory
anyway. I caught this is because I believe we have some other bug where
the display is doing reads of memory we feel should be cleared (or we
are relying on scratch pages to be a specific value).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even with the cumulative set of ilk w/a, rc6 is demonstrably still
failing and causing GPU hangs as found by Peter Wu. So we need to disable
it again until it is stable.
This reverts
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
and the follow-on
commit cd7988eea5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 26 20:33:18 2012 +0200
drm/i915: disable rc6 on ilk when vt-d is enabled
Note: The situation around the gen4/5 gpu hangs that cropped up in 3.7
is rather strange. Most useful bisects have lead to
commit 6c085a728c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 20 11:40:46 2012 +0200
drm/i915: Track unbound pages
or even later commits that affect the gem bo recycling, which all is
way past the point where we re-enabled rc6. But somehow
reverting/disabling those commits doesn't help, but disabling rc6 at
least helps for many hangs on ilk. Obviously it doesn't change
anything at all on gen4, and there are still strange issues left on
gen5 (which we unfortunately can't readily reproduce).
Also, the error_state signature of the hangs which can be fixed with
this patch look remarkably different to those which seem to be
unaffected by the rc6 settings: The rc6 hangs are in the ring,
somewhere in the MI_FLUSH/PIPE_CONTROL sequence to make ilk coherent,
wheras all the other hangs tend to be at a random point in the middle
of the user batch. So it could also be that we have different issues.
Until we grow more clue, this at least helps some users.
Reported-by: Peter Wu <lekensteyn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note with some more details about the gen4/5 3.7
gpu hang regression.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since it should be working a little bit better now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: resolve conflict around the call to intel_crtc_mode_get. And
add the missing NULL check Chris spotted while at it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the recorded panel fixed-mode to populate the get_modes() request in
the absence of an EDID.
Fixes regression from
commit 9cd300e038
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Oct 19 14:51:52 2012 +0300
drm/i915: Move cached EDID to intel_connector
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the retval-changing hunk, as suggested by Jani in his
review and acked by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 500a8cc466
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Wed Jan 13 11:19:52 2010 +0800
drm/i915: parse eDP panel color depth from VBT block
originally introduced parsing bpp for eDP from VBT, with a default of 18
bpp if the eDP BIOS data block is not present. Turns out that default seems
to break the Macbook Pro with retina display, as noted in
commit 4344b813f1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 10 11:10:20 2012 +0200
drm/i915: ignore eDP bpc settings from vbt
Since we can't ignore bpc settings from VBT completely after all, get rid
of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is
missing from VBT.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
[danvet: paste in the updated commit message from irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the base fields in both struct intel_connector and struct
intel_sdvo_connector are at the beginning of the enclosing struct, the
pointers are essentially the same, but there is no requirement or guarantee
that this is always the case. Kfree the enclosing intel_sdvo_connector
pointer that was originally allocated, not the enclosed drm_connector, in
case someone ever rearranges the structs.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Rebased.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1)
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was leftover crap from kill-agp. The current code is theoretically
broken for 64b bars. (I resist removing theoretically because I am too
lazy to test).
We still need to ioremap things ourselves because we want to ioremap_wc
the PTEs.
v2: Forgot to kill the tmp variable in v1
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we have hit oom whilst holding our struct_mutex, then currently we
cannot reap our own GPU buffers which likely pin most of memory, making
an outright OOM more likely. So if we are running in direct reclaim and
already hold the mutex, attempt to free buffers knowing that the
original function can not continue until we return.
v2: Add a note explaining that the mutex may be stolen due to
pre-emption, and that is bad.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we may invoke the shrinker whilst trying to allocate memory to hold
the gtt_space for this object, we need to be careful not to mark the
drm_mm_node as activated (by assigning it to this object) before we
have finished our sequence of allocations.
Note: We also need to move the binding of the object into the actual
pagetables down a bit. The best way seems to be to move it out into
the callsites.
Reported-by: Imre Deak <imre.deak@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added small note to commit message to summarize review
discussion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As the SDVO/HDMI registers are multiplex, it is safe to assume that the
w/a required for HDMI on IbexPoint, namely that the SDVO register cannot
both be disabled and have selected transcoder B, is also required for
SDVO. At least the modeset state checker detects that the transcoder
selection is left in the undefined state, and so it appears sensible to
apply the w/a:
[ 1814.480052] WARNING: at drivers/gpu/drm/i915/intel_display.c:1487 assert_pch_hdmi_disabled+0xad/0xb5()
[ 1814.480053] Hardware name: Libretto W100
[ 1814.480054] IBX PCH hdmi port still using transcoder B
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also document the WA name for the previous gens that implement it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now, this code is just used by the eDP AUX channel frequency.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This goes on a separate patch since it won't apply on the stable
trees and there's nothing using panel fitter on HSW on the older
Kernels.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I actually found this problem on Haswell, but then discovered Ivy
Bridge also has it by reading the spec.
I don't have the hardware to test this.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DDI A and E have 4 lanes to share, so if DDI A is using 4 lanes,
there's nothing left for DDI E, which means there's no CRT port on the
machine.
The bit we're checking here is programmed at system boot and it cannot
be changed afterwards, so we cannot change the amount of lanes
reserved for each DDI port.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to enable a special bit, otherwise none of the DP functions
requiring the PCH will work.
Version 2: store the PCH ID inside dev_priv, as suggested by Daniel
Vetter.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't check if the "unclaimed register" bit is set before we call
writel, so if it was already set before, we might print a misleading
message about "unclaimed write" on the wrong register.
This patch makes us check the unclaimed bit before the writel, so we
can print a new "Unknown unclaimed register before writing to %x"
message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function runs on Haswell, so set the correct pch_transcoder and
cpu_transcoder variables. This fixes an assertion failure on Haswell
VGA.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a full revert of 59c859d6f2e78344945e8a8406a194156176bc4e:
drm/i915: account for only one PCH receiver on Haswell
Now that the PCH code is fixed to be able use the only PCH transcoder
independently of the pipe and CPU transcoder, we can revert this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Resolve conflict due to the rebasing of dinq on top of
drm-next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Note: It is important that we switch from the system workqueue to our
own dev_priv->wq since all work items on that queue are guaranteed to
only need the dev->struct_mutex and not any modeset resources. For
otherwise if we have a work item ahead in the queue which needs the
modeset lock (like the output detect work used by both polling or
hpd), this work and so the unpin work will never execute since the
pageflip code already holds that lock. Unfortunately there's no
lockdep support for this scenario in the workqueue code.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note about workqueu deadlock.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56337
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
But disabled by default. This essentially reverts
commit bcd5023c96
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Mar 14 14:17:55 2011 +1000
drm/i915: disable opregion lid detection for now
but leaves the autodetect mode disabled. There's also the explicit lid
status option added in
commit fca8740925
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Feb 17 13:44:48 2011 +0000
drm/i915: Add a module parameter to ignore lid status
Which overloaded the meaning for the panel_ignore_lid parameter even
more. To fix up this mess, give the non-negative numbers 0,1 the
original meaning back and use negative numbers to force a given state.
So now we have
1 - disable autodetect, return unknown
0 - enable autodetect
-1 - force to disconnected/lid closed
-2 - force to connected/lid open
v2: My C programmer license has been revoked ...
v3: Beautify the code a bit, as suggested by Chris Wilson.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27622
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds the missing code to send ELD for Haswell DisplayPort,
based on Xingchao's original patch.
A test was performed with HSW-D machine and NEC EA232Wmi DP monitor.
Cc: Xingchao Wang <xingchao.wang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to prevent reaping of the object whilst setting it up to
handle the pagefault, we need to mark it as pinned. This has the nice
side-effect of eliminating some special cases from the pagefault handler
as well!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the circumstances that the shrinker is allowed to steal the mutex
in order to reap pages, we need to be careful to prevent it operating on
the current object and shooting ourselves in the foot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intention of checking obj->gtt_offset!=0 is to verify that the
target object was listed in the execbuffer and had been bound into the
GTT. This is guarranteed by the earlier rearrangement to split the
execbuffer operation into reserve and relocation phases and then
verified by the check that the target handle had been processed during
the reservation phase.
However, the actual checking of obj->gtt_offset==0 is bogus as we can
indeed reference an object at offset 0. For instance, the framebuffer
installed by the BIOS often resides at offset 0 - causing EINVAL as we
legimately try to render using the stolen fb.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we always restore the HWS registers (both physical and GTT
virtual addresses) when re-initialising the rings, we can eliminate the
superfluous save/restore of the register across suspend and resume.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '______f' is static but
declared in inline function 'i915_gem_chipset_flush' which is not static
Reported-by: kbuild test robot <fengguang.wu@intel.com>
dri-devel-Reference: <50a4d41c.586VhmwghPuKZbkB%fengguang.wu@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ILK+ have this register on the PCH. This check was triggering unclaimed
writes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula noticed that the parentheses are wrong and we & the bit
with the register address instead of the read-back value. He sent a
patch to correct that.
On second look, we write the same register in the previous line, and
the w/a seems to be to set FDI_RX_PHASE_SYNC_POINTER_OVR to enable the
logic, then keep always set FDI_RX_PHASE_SYNC_POINTER_OVR and toggle
FDI_RX_PHASE_SYNC_POINTER_EN before/after enabling the pc transcoder.
So the right things seems to be to simply kill the 2nd write.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Dropped a bogus ~ from the commit message that somehow crept
in.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bspec was recently updated to remove the ability to update the
semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon
the semaphore value remained. Instead the advice is to update the
register using the MI_LOAD_REGISTER_IMM command. In cursory testing,
semaphores continue to function - the question is whether this fixes
some of the deadlocks where the semaphore registers contained stale
values?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends. This optimization rips 32 bytes of
binary code on x86_64.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After the recent pile of disable-cloning patches, e.g.
commit e3b86d6941
Author: Egbert Eich <eich@suse.de>
Date: Sat Oct 13 14:30:15 2012 +0200
DRM/i915: Don't clone SDVO LVDS with analog
and a bug report from Chris Wilson indicating that cloning doesn't
even work for DVI-SDVO and native VGA, let's just disable cloning on
sdvo encoders completely.
v2: Update the comment in the code as discussed with Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29259
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
Highlights of this -next round:
- ivb fdi B/C fixes
- hsw sprite/plane offset fixes from Damien
- unified dp/hdmi encoder for hsw, finally external dp support on hsw
(Paulo)
- kill-agp and some other prep work in the gtt code from Ben
- some fb handling fixes from Ville
- massive pile of patches to align hsw VGA with the spec and make it
actually work (Paulo)
- pile of workarounds from Jesse, mostly for vlv, but also some other
related platforms
- start of a dev_priv reorg, that thing grew out of bounds and chaotic
- small bits&pieces all over the place, down to better error handling for
load-detect on gen2 (Chris, Jani, Mika, Zhenyu, ...)
On top of the previous pile (just copypasta):
- tons of hsw dp prep patches form Paulo
- round scheduled work items and timers to nearest second (Chris)
- some hw workarounds (Jesse&Damien)
- vlv dp support and related fixups (Vijay et al.)
- basic haswell dp support, not yet wired up for external ports (Paulo)
- edp support (Paulo)
- tons of refactorings to prepare for the above (Paulo)
- panel rework, unifiying code between lvds and edp panels (Jani)
- panel fitter scaling modes (Jani + Yuly Novikov)
- panel power improvements, should now work without the BIOS setting it up
- extracting some dp helpers from radeon/i915 and move them to
drm_dp_helper.c
- randome pile of workarounds (Damien, Ben, ...)
- some cleanups for the register restore code for suspend/resume
- secure batchbuffer support, should enable tear-free blits on gen6+
Chris)
- random smaller fixlets and cleanups.
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (231 commits)
drm/i915: Restore physical HWS_PGA after resume
drm/i915: Report amount of usable graphics memory in MiB
drm/i915/i2c: Track users of GMBUS force-bit
drm/i915: Allocate the proper size for contexts.
drm/i915: Update load-detect failure paths for modeset-rework
drm/i915: Clear unused fields of mode for framebuffer creation
drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer
drm/i915: Fix sparse warnings in from AGP kill code
drm/i915: Missed lock change with rps lock
drm/i915: Move the remaining gtt code
drm/i915: flush system agent TLBs on SNB
drm/i915: Kill off now unused gen6+ AGP code
drm/i915: Calculate correct stolen size for GEN7+
drm/i915: Stop using AGP layer for GEN6+
drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush
drm/i915: don't rewrite the GTT on resume v4
drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex
drm/i915: put ring frequency and turbo setup into a work queue v5
drm/i915: don't block resume on fb console resume v2
drm/i915: extract l3_parity substruct from dev_priv
...
By always setting up the HWS register for both physical and virtual
address variations during render ring we can reduce the number of
different special cases that get set up at varying different times
during module load.
Fixes regression from
commit c630119f43
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Oct 17 11:32:57 2012 +0200
drm/i915: don't save/restore HWS_PGA reg for kms
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
...rather than kilo-PTE.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Apply s/Usabel/usable/ bikeshed suggested by Ben Widawsky.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a regression for SDVO from
commit fbfcc4f3a0
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Oct 22 16:12:18 2012 +0300
drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures
As SDVOB and SDVOC are multiplexed on the same pin, if a chipset does
not have the second SDVO encoder, it will then remove the force-bit
setting on the common i2c adapter during teardown. All subsequent
attempts of trying to use GMBUS with SDVOB then fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: fixup inversion in the debug printout, noticed by Jani
Nikulai.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are laptops out there that need the eDP bpc from VBT. This is
effectively a revert of
commit 4344b813f1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 10 11:10:20 2012 +0200
drm/i915: ignore eDP bpc settings from vbt
but putting the VBT check after the EDID check to see them both in dmesg if
this clamps more than the EDID. We have enough history with bpc clamping to
warrant the extra debug info.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
left behind ghost connectors, attached (with a dangling pointer) to the
sdvo that has been cleaned up and freed. Properly destroy any connectors
attached to the encoder.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: bjo@nord-west.org
[danvet: added a comment to explain why we need to clean up connectors
even when sdvo_output_setup fails.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Whoops. This was fixed previously, but not sure how it got lost. It's
not needed for -fixes or stable because at the moment
drm_i915_file_private is way bigger than i915_hw_context (by 120 bytes
on my 64b build).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After the rework, intel_set_mode() became a little better behaved in
restoring the current mode if we failed to apply the requested modeline.
However, the failure path for load-detect would clobber the existing
state, leading to an oops during BIOS takeover on older machines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the stricter checks introduced in
commit ac911edae5960d7dccd9883f5fa5d25b591520de
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Oct 31 17:50:19 2012 +0200
drm/i915: Check the framebuffer offset
(and friends), it became especially prudent to make sure that the
additional fields inside the mode were cleared before attempting to
create a framebuffer. In particular, the fb created for load detection
failed to do so and hence failed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The specs for gen2 say that the watermark values "should always be set
assuming a 32bpp display mode, even though the display mode may be 15 or
16 bpp."
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes a WARN_ON in igt/tests/debugfs_reader
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's pretty much all consolidated now that we've killed AGP. We can move
the one outlier, and defines too.
(Kill some unused defines in the process)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to map the PTEs WC. I've not done thorough testing or
performance measurements with this patch, but it should be decent.
This is based on a patch from Jesse with the original commit message
> I've only lightly tested this so far, but the corruption seems to be
> gone if I write the GFX_FLSH_CNTL reg after binding an object. This
> register should control the TLB for the system agent, which is what CPU
> mapped objects will go through.
It has been updated for the new AGP-less code by me, and included with
it is feedback from the original patch.
v2: Updated to reflect paranoia on pte updates/register posting reads.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by [v1]: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This bug existed in the old code, but was easier to fix here in the
rework. Unfortunately gen7 doesn't have a nice way to figure out the
size and we must use a lookup table.
As Jesse pointed out, there is some confusion in the docs about these
definitions. We're picking the one which seems more accurate, but we
really aren't certain.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.
This should preserve the old gtt init behavior which upon writing these
patches seems incorrect. The next patch will fix these things.
The one exception is VLV which doesn't have the preserved flush control
write behavior. Since we want to do that for all GEN6+ stuff, we'll
handle that in a later patch. Mainstream VLV support doesn't actually
exist yet anyway.
v2: Update the comment to remove the "voodoo"
Check that the last pte written matches what we readback
v3: actually kill cache_level_to_agp_type since most of the flags will
disappear in an upcoming patch
v4: v3 was actually not what we wanted (Daniel)
Make the ggtt bind assertions better and stricter (Chris)
Fix some uncaught errors at gtt init (Chris)
Some other random stuff that Chris wanted
v5: check for i==0 in gen6_ggtt_bind_object to shut up gcc (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by [v4]: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Make the cache_level -> agp_flags conversion for pre-gen6 a
tad more robust by mapping everything != CACHE_NONE to the cached agp
flag - we have a 1:1 uncached mapping, but different modes of
cacheable (at least on later generations). Suggested by Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has been introduced in "drm/i915: TLB invalidation with
MI_FLUSH_DW requires a post-sync op".
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS shouldn't be touching this memory across suspend/resume, so
just leave it alone. This saves us ~6ms on resume on my T420 (retested
with write combined PTEs).
v2: change gtt restore default on pre-gen4 (Chris)
move needs_gtt_restore flag into dev_priv
v3: make sure we restore GTT on resume from hibernate (Daniel)
use opregion support as the cutoff for restore from resume (Chris)
v4: use a better check for opregion (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Kill the needs_gtt_restore indirection and check directly for
OpRegion. Also explain in a comment what's going on.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows the power related code to run independently of the rest of
the pipeline, extending the resume and init time improvements into
userspace, which would otherwise have been blocked on the struct mutex
if we were doing PCU communication.
v2: Also convert the locking for the rps sysfs interface.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Communicating via the mailbox registers with the PCU can take quite
awhile. And updating the ring frequency or enabling turbo is not
something that needs to happen synchronously, so take it out of our init
and resume paths to speed things up (~200ms on my T420).
v2: add comment about why we use a work queue (Daniel)
make sure work queue is idle on suspend (Daniel)
use a delayed work queue since there's no hurry (Daniel)
v3: make cleanup symmetric and just call cancel work directly (Daniel)
v4: schedule the work using round_jiffies_up to batch work better (Chris)
v5: fix the right schedule_delayed_work call (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
Signed-of-by: Jesse Barnes <jbarnes@virtuougseek.org>
[danvet: bikeshed the placement of the new delayed work, move it to
all the other gen6 power mgmt stuff.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend into the global
work queue that can happen anytime. I've measured this to take around
200ms on my T420. Combined with the ring freq/turbo change, we should
save almost 1/2 a second on resume.
v2: use console_trylock() to try to resume the console immediately (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: move dev_priv->console_resume_work next to the fbdev
pointer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pretty astonishing how far apart these two members landed ... Especially since
I've already removed almost 200 lines in between.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also, move dev_priv->counter there, it's only used in i915_dma.c
And also move the dri1 dungeon at the end of dev_priv where no one
cares about it.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And give the structs slightly more generic names. I've decided to keep
the short rps/ips prefix, since that's just easier and less churn.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dev_priv has grown way too big, and grouping memebers into substructs
and moving them out of line helps re-gain some overview.
Unfortunatley I couldn't just call the substruct save and drop the prefix, since
that will make most member names clash with registers #defines. Changes in
i915_drv.h done by hand, everything else changed with
s/\<save\([A-Z]*\)/regfile.save\1/ in vim.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So we can write them properly.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
"If ENABLED, PIPE_CONTROL command will flush the in flight data written
out by render engine to Global Observation point on flush done. Also
Requires stall bit ([20] of DW1) set."
So set the stall bit to ensure proper invalidation.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So store into the scratch space of the HWS to make sure the invalidate
occurs.
v2: use GTT address space for store, clean up #defines (Chris)
v3: use correct #define in blt ring flush (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1063252
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Workaround for dual port PS dispatch on GT1.
v2: pull in register definition & offset handling
v3: use IVB GT1 macro to get the right regs (Ben)
v4: add for VLV too (Ben)
v5: don't read the reg, it's masked so we'll only enable the one extra bit (Chris)
v6: use a _GT2 suffix for the second reg (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to get the right vblank interrupt frequency.
v2: pull in register definition
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needs to be set on every context restore as well, so set it as part of
the initial state so we can save/restore it. Note this removes the IVB
workaround value from VLV and uses the default value, just adding in the
L3 cache aging disable bit, since the IVB value is wrong for VLV.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit makes hsw_fdi_link_train responsible for implementing
everything described in the "Enable and train FDI" section from the
Hawell CRT mode set sequence documentation. We completely rewrite
hsw_fdi_link_train to match the documentation and we also call it in
the right place.
This patch was initially sent as a series of tiny patches fixing every
little problem of the function, but since there were too many patches
fixing the same function it got a little difficult to get the "big
picture" of how the function would be in the end, so here we amended
all the patches into a single big patch fixing the whole function.
Problems we fixed:
1 - Train Haswell FDI at the right time.
We need to train the FDI before enabling the pipes and planes, so
we're moving the call from lpt_pch_enable to haswell_crtc_enable
directly.
We are also removing ironlake_fdi_pll_enable since the PLL
enablement on Haswell is completely different and is also done
during the link training steps.
2 - Use the right FDI_RX_CTL register on Haswell
There is only one PCH transcoder, so it's always _FDI_RXA_CTL.
Using "pipe" here is wrong.
3 - Don't rely on DDI_BUF_CTL previous values
Just set the bits we want, everything else is zero. Also
POSTING_READ the register before sleeping.
4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train
According to the mode set sequence documentation, this is the
right place. According to the FDI_RX_TUSIZE register description,
this is the value we should set.
Also remove the code that sets this register from the old
location: lpt_pch_enable.
5 - Properly program FDI_RX_MISC pwrdn lane values on HSW
6 - Wait only 35us for the FDI link training
First we wait 30us for the FDI receiver lane calibration, then we
wait 5us for the FDI auto training time.
7 - Remove an useless indentation level on hsw_fdi_link_train
We already "break" when the link training succeeds.
8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE
When we fail the training.
9 - Change Haswell FDI link training error messages
We shouldn't call DRM_ERROR when still looping through voltage
levels since this is expected and not really a failure. So in this
commit we adjust the error path to only DRM_ERROR when we really
fail after trying everything.
While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since
it's what we use everywhere.
10 - Try each voltage twice at hsw_fdi_link_train
Now with Daniel Vetter's suggestion to use "/2" instead of ">>1".
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Applied tiny bikesheds:
- mention in comment that we test each voltage/emphasis level twice
- realing arguments of the only untouched reg write, it spilled over
the 80 char limit ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We had 2 places using X2 and one place using X1.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we no longer pretend to have flexibility in matching any
north display block with any pch, we can ditch this.
v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1"
v2: Make it compile.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the transcoder. We also have to
clear that bit again after disabling the pch transcoder.
See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "Graphics BSpec: vol4h South Display
Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI
Control, Transcoder Debug and DFT, TRANS_CHICKEN_2" bit 31:
"Workaround : Enable the override prior to enabling the transcoder.
Disable the override after disabling the transcoder."
While at it, use the _PIPE macro for the other TRANS_DP register.
v2: Keep the w/a as-is, but kill the original (but wrongly placed)
workaround introduced in
commit 3bcf603f6d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Jul 27 11:51:40 2011 -0700
drm/i915: apply timing generator bug workaround on CPT and PPT
and
commit d4270e57ef
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Oct 11 10:43:02 2011 -0700
drm/i915: export a CPT mode set verification function
Note that this old code has unconditionally set the w/a, which might
explain why fdi link training sometimes silently fails, and especially
why the auto-train did not seem to work properly.
v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.
Hence move to workaround into enable/disable_transcoder, where the pch
transcoder gets enabled/disabled.
v4: Whitespace changes dropped.
v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT.
v6:
- resolve conflicts with Paulo's big hsw vga rework
- s/!IBX/CPT since hsw paths are now all separate, and Paulo's patch
to implement the equivalent w/a for LPT is already merged.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v5)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They are all written for a specific north disaplay->pch combination.
So stop pretending otherwise.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't really support fancy north display/pch combinations, so
put a big yelling WARN_ON in there. It /should/ be impossible, but
alas, the rumours don't stop (mostly due to really early silicon
sometimes using older PCHs).
v2: Fixup the logic fumble noticed by Paulo Zanoni. I should actually
try to test run the patch next time around ...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This essentially reverts
commit cb0953d734
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
simply because it doesn't scale: It misses SDVO and DVO panels,
and now with DDI encoders on haswell this is becoming unmanageable.
Instead we simply sort the connector list after everything is
set up.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell/LPT we must disable the PCH transcoder before we disable
the FDI, so don't check for disabled FDI there.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is only for the previous gens.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These workarounds are documented on the CRT mode set sequence.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of PIPECONF_INTERLACE_MASK.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: applied the change by hand due to patch reorder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That function is made for IBX. Running it on LPT will trigger tons of
"unclaimed register" errors. The only port remaining on LPT is
PCH_ADPA.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because we already set all the bits we can set.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: apply by hand due to dropped patch. Also, obey my OCD a bit
and do a s/_TRANSACONF/TRANSCONF(TRANSCODER_A)/, makes it more
consisten with other lpt pch code imnsho ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of using "pipe". As already explained in previous commits,
since Haswell/LPT cpu_transcoder, pch_transcoder and pipe are not the
same thing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll
function we even "return" in case we detect LPT, but I prefer to just
not call it. In the future we might rename to something like
ibx_assert_pch_pll.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since now we have lpt_enable_pch_transcoder.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now the new functions are just copies. Differences will be added
later.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To ironlake_{en,dis}able_pch_transcoder since these functions will be
different on Haswell/LPT and since the "transcoder" they {en,dis}able
is on the PCH.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: again a small conflict because the fdi disable sequenc looks
a bit different here.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell/LPT, pipe, cpu_transcoder and pch_transcoder are different
things with different values, unlinke the previous gens. So here we
use the right thing at the right place.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: apply the patch by hand due to the reorder patch sequence. We
also can't kill all uses of pipe where we should, since the fdi link
train code isn't fixed up yet on this baselin.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no LVDS, so don't poke the LVDS registers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is just wrong. The lpt_program_iclkip should disable the PCH
pixel clocks (and yes, we plan to rename it later).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because this function is only for the older PCHs, not the newer ones.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since this function will only run on Haswell/LPT and newer.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since now we have lpt_pch_enable for them.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now it's just a fork of ironlake_pch_enable. The next commits will
change this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because things changed on Haswell/LPT and the bits checked by
intel_crt_get_hw_state have moved to other registers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those bits just don't exist on LPT. The CRT DAC, PCH transcoder and
FDI RX are always connected to DDI E.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Makes more sense to group the entire mode_set stage into one function.
Noticed while discussiing the rather confusing set of function names
with Paulo Zanoni. Unfortunately I don't have an idea to make the
function names lesss confusion.
v2: Use for_each_encoder_on_crtc as suggested by Chris Wilson.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Refactor the code that stores the panning x/y position into the sarea.
This also changes the code so that it won't mistakenly update
sareaB_x/y for pipe >= C.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The framebuffer pixel format is already checked by the common code.
So there's no way an invalid format could reach the driver. So instead
of falling back to a default format, call BUG().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current code can't deal with framebuffers with an offset. Return an
error when trying to create such a framebuffer until the rest of the
code is fixed to handle them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make sure the the framebuffer stride is smaller than 32k. That
seems to be the limit on recent hardware. Not quite sure if
<=Gen4 has smaller limits.
Also when using a tiled memory make sure the object stride matches
the framebuffer stride.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
format).
Fix intel_init_framebuffer() to match hardware and driver limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 & co. are supported on Gen3 and earlier
* XRGB210101010 & co. are supported from Gen4 onwards
* BGR formats are supported from Gen4 onwards
* YUV formats are supported from Gen5 onwards (driver limitation)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to handle differences in pte encoding between architectures it
is desirable to have one helper function, pte_encode, do it all for us.
As such, this commit moves the code around so we're in good shape to do
that.
Luckily the ppgtt pte and the ggtt pte look very similar.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HSW will change the PTE encoding, and laying this out now will be
helpful when we're ready to implement that. More importantly, GGTT and
PPGTT PTE encoding is quite similar, so moving this out into a helper
function will enable us to lance the AGP layer.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will make the calculations of size easier to read instead of just
assuming uint32_t everywhere.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some subsequent commits will need to know what generation we're running
on to do different pte encoding for the ppgtt. Since it's not much
hassle or overhead to store it in the ppgtt structure, do that.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The mid-level cache or as it's more commonly referred to now as L3, is
not setup this way on HSW.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make intel_render_ring_init_dri and intel_init_ring_buffer symmetrical
with regards of workaround introduced by:
commit 27c1cbd06a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Apr 9 13:59:46 2012 +0100
drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
inits the encoder and then calls the proper init_connector functions.
Notice that for non-eDP ports we call both HDMI and DP connector init,
so we have 2 connectors attached to each DDI encoder.
After this change, intel_hdmi_init and intel_dp_init are only called
by Ivy Bridge and earlier, while hardware containing DDI outputs
should call intel_ddi_init.
Also added/removed quite a few "static" keywords due to the fact that
some function pointers were moved from intel_dp.c and intel_hdmi.c to
intel_ddi.c.
DP finally works on Haswell now! \o/
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this since now on DDI we will have 2 connectors on each
encoder.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
always had the same value. It makes more sense to move this to
intel_digital_port, so we can know the port independently of the
connector type.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When intel_hdmi_detect detects a monitor, set intel_encoder->type with
INTEL_OUTPUT_HDMI. Same for DP.
This should not break the current code because these variables never
change. This will be used after we create the DDI encoder because it
will have both DP and HDMI connectors.
We won't support eDP+HDMI on the same port, so if an encoder is eDP we
should expect it to always remain eDP and never change.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same reason as the previous HDMI commit: the DDI code will have its
own encoder init function but still use the DP and HDMI connectors.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: kill the unnecessarily added line that Damien spotted in
review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to split the HDMI connector and encoder initialization because
in the future the DDI code will have its own "encoder init" function,
but it will still call intel_hdmi_init_connector. The DDI encoder will
actually have two connectors attached to it: HDMI and DP.
The best way to look at this patch is to imagine that we're renaming
intel_hdmi_init to intel_hdmi_init_connector and removing the
encoder-specific pieces and placing them into intel_hdmi_init.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal is to have one single encoder capable of controlling both DP
and HDMI outputs. This patch just adds the initial infrastructure, no
functional changes.
Previously, both intel_dp and intel_hdmi were intel_encoders. Now,
these 2 structs do not have intel_encoder as members anymore. The new
struct intel_digital_port has intel_encoder as a member, and it also
includes intel_dp and intel_hdmi as members. In other words: see the
changes inside intel_drv.h: it's the most important change, everything
else is only to make it compile and work.
For now, each intel_digital_port is still only able to control one of
HDMI or DP, but not both together.
In the future we should also try to merge the common fields from
intel_dp and intel_hdmi (e.g., port).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add the missing ' ' spotted by Damien Lespiau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we add struct intel_digital_port, there will be no direct way of
going from intel_{dp,hdmi} to drm_device: we will need to call
container_of().
This patch adds functions to go from intel_{dp,hdmi} to drm_device.
The main goal here is to greatly reduce the size of the next patch,
where we will change the implementation of the functions we just
added here (among other things).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Replace container_of with enc_to_intel_dp.
- Walk through less structures when making assignments.
- Rename some variables to keep our naming standards.
As a bonus, this will reduce the usage of "struct intel_dp", making
the future patch that introduces intel_digital_port smaller and easier
to review.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix power well control state by reading real register offset.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were writing DSP_ADDR and DSP_SURF unconditionally. This did not
trigger an unclaimed write before HSW as the address of DSP_ADDR has
been repurposed as DSP_LINOFF.
On HSW, though, DSP_LINOFF has been removed and then writting to it
triggers an unclaimed write.
This patch writes to DSP_ADDR or DSP_SURF to flush the display plane
configuration depending on the gen we're running on.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment says for eaglelake/cantiga, but it's listed in the ilk table,
too. So apply it to both.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Or at least our best understanding of it.
v2: Fixup commit message and put the wa name into the comment block.
And actually update the commit, too.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like in:
commit c2c7513124
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 5 12:17:30 2012 +0200
drm/i915: adjust framebuffer base address on gen4+
but this time, for the sprite planes. This ensures that the
sprite offset are always inside the supported hardware limits since it
becomes the offset into a page and we adjust the base address to a page
boundary.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
register.
v2: Remove a useless level of indentation (Paulo Zanoni)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Use a switch for consistency (Chris Wilson)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of writing to the DSP_ADDR ourselves. This will do the right
thing on gen >= 4 as well.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And properly toggle the chicken bit in the pch to enable/disable fdi C
rx. If we don't set this bit correctly, the rx gets confused in link
training, which can result in an fdi link that silently fails to train
the link (since the corresponding register reports success). Note that
both fdi link B and C can suffer when this bit is not set correctly.
The code as-is has a few deficiencies:
- We presume all pipes use the pch which is not the case for cpu edp.
- We don't bother with disabling both pipes when we could make things
work, e.g. when pipe B switched from 4 to 2 lanes due to a mode
change, we don't bother updating the w/a bit.
- It's ugly.
All of these are because we compute ->fdi_lanes way too late, when
we're already setting up individual pipes. We need to have this
information in ->modeset_global_resources already, to set things up
correctly. But that is a much larger reorg of the code.
Note that we actually hit the 2 lanes limit in practice rather
quickly: Even though the 1920x1200 mode native mode of my screen fits
into 2 lanes, it needs 3 lanes for the 1920x1080 (since that somehow
has much more blanking ...). Not obeying this restriction seems to
results in cute-looking digital noise.
v2: Only ever clear the chicken bit when both pipes are off.
v3: Use the new ->modeset_global_resources callback.
v4: Move the WARNs to the right place. Oh how I hate hacks.
v5: Fix spelling, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After all relevant pipes are disabled and after we've updated all the
state with the staged state, but before we call the per-crtc
->mode_set functions there's a very natural point to set up any
shared/global resources like
- shared plls (obviously only the setup, the enabling needs to be
separately handling with a separate refcount)
- global watermark state like the DSPARB on gmch platforms
- workaround bits that depend upon the exact global output
configuration
- enabling the right set of refclocks
- enabling/disabling manual power wells.
Now for a lot of these things we can't move them into this function
yet, most often because we only compute the required information in
the per-crtc ->mode_set callback. Which is too late. But due to a
bunch of reasons (check-only atomic modeset, fastboot&hw state checks,
...) we need to separate the computation of that state from the actual
hw frobbery anyway. So we can move things into this new callback step-
by-step.
Others can't be moved here (or implemented at all) because our code
lacks the smarts to properly update them. E.g. the DSPARB can only be
updated when all pipes are disabled, so if we decide to change it's
value, we need to disable _all_ pipes. The infrastructure for that is
already in place (with the various pipe masks that driver the modeset
logic). But again we need to move a few things out of ->mode_set
first before we can even implement the correct decision making.
In any case, we need to start somewhere, so let's start with the
callback: Some small follow-up patches will make immediate good use of
it.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since it is one. We need to move this code to encoder specific callbacks
eventually, to kill all that inversion of control ...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we have a few funny issues where we enable/disable shared
pll clocks. To make it clear that we are not required to enable/
disable the pch plls together with the other pch resources (and
so should keep it running when it's used by another pipe in
a shared pll configuration) add a comment.
This note is lifted from "Graphics BSpec: vol4g North Display Engine
Registers [IVB], Display Mode Set Sequence", step 9.d. of the enable
sequence:
"Configure and enable PCH DPLL, wait for PCH DPLL warmup (Can be
done anytime before enabling PCH transcoder)."
Since fixing the pll sharing code to no longer disable shared plls
if they're still in use is more involved, let's just stick with the
comment for now.
v2: Make the comment in the code clearer, to address questions raised
by Paulo Zanoni in review.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My machine here has the correct ones already, but better safe
than sorry. IBX has different settings for that register, and
on IBX the device defaults match the recommended values. Hence
I did not add the respective writes for IBX.
LPT needs the same settings, but that has been done already
commit 4acf518626
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Wed Jul 4 20:15:16 2012 -0300
drm/i915: program FDI_RX TP and FDI delays
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For reference, see "Graphics BSpec: vol4g North Display Engine
Registers [IVB], Display Mode Set Sequence", step 4 of the enabling
sequence:
a. "Enable PCH FDI Receiver PLL, wait for warmup plus DMI latency
b. "Switch from Rawclk to PCDclk in FDI Receiver
c. "Enable CPU FDI Transmitter PLL, wait for warmup"
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" We need to write the TU size register
of the fdi RX unit _before_ starting to train the link.
Note: The current code is actually correct as Paulo mentioned in
review, but it's a bit confusion since only the fdi rx/tx plls need to
be enabled before the cpu pipes/planes. Hence it's still a good idea
to move the TU_SIZE setting to the "right" spot in the sequence, to
better match Bspec.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The debug message is only relevant on CPT/PPT PCH ports, so move
it into the correct if clause.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PCH platforms and VLV should map DPMS standby and suspend modes to off, but
due to a buggy reversed comparison this is done on pre-PCH platforms
instead.
Reported-by: Loïc Yhuel <loic.yhuel@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56754
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel's backmerge
commit c2fb791692
Merge: 29de6ce6f0c058
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Oct 22 14:34:51 2012 +0200
Merge tag 'v3.7-rc2' into drm-intel-next-queued
to solve conflicts blew up (either git or Daniel was trying to be too
clever for their own good; it's usually convenient to blame tools ;) and
caused the changes of
commit 0c96c65b48
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Sep 26 18:43:10 2012 +0300
drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
in ironlake_crtc_mode_set() to be dropped.
Fix the call in ironlake_crtc_mode_set() again, and while at it, also fix
the new, copy-pasted haswell_crtc_mode_set() to use adjusted_mode.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Yuly Novikov <ynovikov@chromium.org>
[Jani: ripped this change separate from the scaling mode change support]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prepare for supporting scaling mode configuration also in eDP.
Includes a drive-by-removal of an outdated comment about fitting mode.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At some point the DPCD size was increased, but the debug print not. While
at it, switch to using hex dump.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like HSW, VLV does not have a sprite scale. Set
intel_plane->can_scale accordingly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we may remove the only console for a nomodeset system.
We became more aggressive in our kicking with
commit e188719a28
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 12 11:28:17 2012 +0200
drm/i915: kick any firmware framebuffers before claiming the gtt
Reported-and-tested-by: monnier@iro.umontreal.ca
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54615
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # v3.6
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 28dcc2d60c
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Sep 3 16:25:12 2012 +0300
drm/i915: do not expose a dysfunctional backlight interface to userspace
prevents backlight interface creation if the BIOS has not set the backlight
PWM CTL registers that contain the max PWM value. It's apparently normal on
those machines, so demote the message about it to debug level.
Reported-by: Orion Poplawski <orion@cora.nwra.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56330
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c
adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO
bit-banging instead of gmbus). Restore i2c adapter config before error
return from intel_sdvo_init(), letting HDMIB enjoy the joys of gmbus.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 63abf3edaf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 8 16:48:21 2010 +0000
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
added a default fallback if BIOS provides an invalid pin mapping, but
failed to force GPIO bit-banging on it. Finish the job, and also clean up
the function a bit. With bit-banging, setting the gmbus speed has no
effect, so drop it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Extend comment about gmbus in the code a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that all the eDP enablement bits are there, we can actually try to
use the eDP.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's an important step :)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cdclk frequency is not always the same, so the value here should
be adjusted to match it.
Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
See the documentation for the DDI_FUNC_CTL register, EDP Input Select
bits: when the EDP input selection is B, the VTOTAL_B must be
programmed with the VTOTAL_EDP value, same thing for selection C.
V2: Use I915_READ as suggested by Daniel Vetter.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because the PIPECONF register is actually part of the CPU transcoder,
not the CPU pipe.
Ideally we would also rename PIPECONF to TRANSCONF to remind people
that they should use the transcoder instead of the pipe, but let's
keep it like this for now since most Gens still name it PIPECONF.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to check if any of the pipes is using TRANSCODER_EDP.
V2: DDI_BUF_CTL was renamed, so fix the usage here.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new naming scheme before it confuses more people.
Notice that there's a big improvement on intel_ddi_get_hw_state due to
the new TRANSCODER_EDP.
V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by
Damien Lespiau.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcoder register even though it does not have an EDP version.
Even though Haswell names this register PIPE_CLK_SEL, it will be
renamed to TRANS_CLK_SEL in the future, so let's just start using the
real name that makes more sense and avoids misusage.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
(only used for VGA).
For all the outputs except for EDP we have an 1:1 mapping on the CPU
pipes and CPU transcoders, so if you're using CPU pipe A you have to
use CPU transcoder A. When have an eDP output you have to use
transcoder EDP and you can attach this CPU transcoder to any of the 3
CPU pipes. When using VGA you need to select a pair of matching CPU
pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
PCH transcoder.
For now we're just creating the cpu_transcoder definitions and setting
cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
registers was ported to use transcoder instead of pipe. The goal is to
keep the code backwards-compatible since on all cases except when
using eDP we must have pipe == cpu_transcoder.
V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
and Daniel Vetter.
We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
can be used by any CRTC, so when you stop using it you have to stop
saying you're using it, otherwise you may have at some point 2 CRTCs
claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
one), then the HW state readout code will get completely confused.
In other words:
Imagine the following case:
xrandr --output eDP1 --auto --crtc 0
xrandr --output eDP1 --off
xrandr --output eDP1 --auto --crtc 2
After the last command you could get a "pipe A assertion failure
(expected off, current on)" because CRTC 0 still claims it's using
TRANSCODER_EDP, so the HW state readout function will read it
(through PIPECONF) and expect it to be off, when it's actually on
because it's being used by CRTC 2.
So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
make sure we're pointing to our own original CRTC which is certainly
not used by any other CRTC.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Ironlake we have one PCH transcoder and FDI per pipe, so we know
that if ironlake_crtc_driving_pch returns false we can disable the PCH
transcoder and we also know that when we disable the crtc we can also
disable the PCH transcoder.
On Haswell there is only 1 PCH transcoder and FDI and they can be used
by any CRTC. So if for one specific crtc haswell_crtc_driving_pch
returns false we can't assert anything about the state of the PCH
transcoder or the FDI link without checking if any other CRTC is using
the PCH.
So on this commit remove the "assert_fdi_{t,r}x_disabled" form
haswell_crtc_enable and also only disable FDI and the PCH transcoder
if the port being disabled was actually a PCH port (we only have one
port using PCH: the VGA port).
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>
By forking Ironlake and Haswell functions. The only callers are
{ironlake,haswell}_crtc_enable anyway, and this way we won't need to
add other checks on the Haswell version for the next gens.
V2: Even simpler, as pointed by Jani Nikula.
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>
These functions were forked from their Ironlake versions, so now fix
the gen checks to reflect the fact that they will only run on Haswell.
It is worth noticing that we are not considering IBX/CPT possible on
Haswell anymore. So far on Haswell enablement we kept trying to still
consider IBX/CPT as a possibility with a Haswell CPU, but this was
never tested, I really doubt it will work with the current code and we
don't really have plans to support it. Future patches will remove the
IBX/CPT code from other Haswell functions. Notice that we still have a
WARN on haswell_crtc_mode_set in case we detect non-LPT PCH.
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>
The last commit forked a Haswell version, so now we remove Haswell
code from these functions.
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>
The way we enable and disable the PCH on Haswell changed considerably
since now we have only one PCH transcoder, so we can't keep the same
asserts and we also can't just unconditionally disable the PCH
transcoder for non-PCH outputs. So let's fork a Haswell version.
These new functions look exactly the same as the ironlake versions.
The next patches will introduce the differences.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Identical #define is now available in include/drm/drm_dp_helper.h, nuke the
dupe.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That thing has grown way too big already.
Also move around a comment to the right spot.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise dp aux won't work on some hsw platforms, since they use a
different rawclk than the 125MHz clock used thus far.
To absolutely not change anything, round up: That way we get the old
63 divider for the default 125MHz clock.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this when the bios forgets even to set that bit up. Most seem
to do that, even when they don't set up anything else in the panel
power sequencer.
Note that on IBX the rawclk is variable according to Bspec, but
everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but
luckily we still have the same register available. On hsw, different
variants have different clocks, hence we need to check the register.
Since other pieces are driven by the rawclock, too, keep the little
helper in a central place.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like we already do for the LVDS panels. This seems to help greatly
in setting up the backlight, since the BIOS might refuse to cooperate.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
v2: Move the backlight_off call from panel_off to edp_backlight_off,
noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like in the case of native hdmi, which is fixed already in
commit adf00b26d1
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Tue Sep 25 13:23:34 2012 -0300
drm/i915: make sure we write all the DIP data bytes
we need to clear the entire sdvo buffer to avoid upsetting the
display.
Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.
v2: Cite the right commit above, spotted by Paulo Zanoni.
v3: I'm too stupid to paste the right commit.
v4: Ben Hutchings noticed that I've failed to handle an underflow in
my loop logic, breaking it for i >= length + 8. Since I've just lost C
programmer license, use his solution. Also, make the frustrated 0-base
buffer size a notch more clear.
Reported-and-tested-by: Jürg Billeter <j@bitron.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: stable@vger.kernel.org
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3 changes:
- If a given value is unset, use the maximal limits from the eDP spec.
- Write back the new values, since otherwise the panel power sequencing
hw will not dtrt.
- Revert the early bail-out in case the register values are unset.
The last change reverts
commit bfa3384a9a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Apr 10 11:58:04 2012 -0700
drm/i915: check PPS regs for sanity when using eDP
v2:
- Unlock the PP regs as the very first thing. This is a required w/a
for cpu eDP on port A, and generally a good idea.
- Fixup the panel power control port selection bits.
v3: Paulo Zanoni noticed that I've fumbled the computation of the spec
limit values. Fix them up. We've also noticed that the t8/t9 values in
the vbt/bios-programmed pp are much larger than any limits. My guess
is that this is to conceal any backlight enable/disable delays. So by
using the much shorter limits from the spec, which only concerns the
sink, we risk that we might display before the backlight is fully on,
or disable the output while the backlight still has afterglow. I've
figured I don't care too much, since this will only happen when both
the pp regs are not programmed, and the vbt tables don't contain
anything useful.
v4: Don't set the port selection bits on hsw/LPT, they don't exist any
more.
v5: Fixup spelling issues in comments, as noticed by Jesse Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell does not have a scaler in the sprite pipeline anymore, so let's
ensure:
1/ We bail out of update_plate() when someone is trying to ask to
display a scaled framebuffer,
2/ We never write to the nonexistent SPR_SCALE register
v2: Smash in the fixup from Damien in the disable_plane function.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (for v1)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... like the comment says. No idea whether this has any effect, but
I guess it's better to not lie to the display by acking a test request
and never following through with it. This goes back to the commit that
originally introduced this code:
commit a60f0e38d7
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Oct 20 15:09:17 2011 -0700
drm/i915: add DP test request handling
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bit doesn't stick, and the output is always cloned from pipe A,
even when it's supposed to scan out from pipe B.
Shuts up annoying warnings from the modeset-rework, too.
I've noticed that with this patch we know get and unknown connection
state since the code can't find a suitable pipe for load detection.
But that beats the previous state of affairs, where it tried to use
pipe B, actually used pipe A and concluded that something is connected
(although it's the LVDS on pipe A and nothing on the VGA connector on
pipe B).
I've tried to make load detect work by remapping the pipe->planes
stuff, so that crtc 0 will use pipe B and hence we still have
something left for load-detect on pipe A. But alas, that upset the hw
a bit.
So there's still some things to figure out, but this here will at
least paper over some of the problems.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: extend the commit message a bit with recent observations.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The overlay on the i830M has a peculiar failure mode: It works the
first time around after boot-up, but consistenly hangs the second time
it's used.
Chris Wilson has dug out a nice errata:
"1.5.12 Clock Gating Disable for Display Register
Address Offset: 06200h–06203h
"Bit 3
Ovrunit Clock Gating Disable.
0 = Clock gating controlled by unit enabling logic
1 = Disable clock gating function
DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay
& L2 Cache clock gating must be disabled in order to prevent device
hangs when turning off overlay.SW must turn off Ovrunit clock gating
(6200h) and L2 Cache clock gating (C8h)."
Now I've nowhere found that 0xc8 register and hence couldn't apply the
l2 cache workaround. But I've remembered that part of the magic that
the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache
allocations so that the overlay scaler has some scratch space.
And while pondering how that could explain the hang the 2nd time we
enable the overlay, I've remembered that the old ums overlay code did
_not_ issue the OVERLAY_OFF cmd.
And indeed, disabling the OFF cmd results in the overlay working
flawlessly, so I guess we can workaround the lack of the above
workaround by simply never disabling the overlay engine once it's
enabled.
Note that we have the first part of the above w/a already implemented
in i830_init_clock_gating - leave that as-is to avoid surprises.
v2: Add a comment in the code.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827
Cc: stable@vger.kernel.org
Tested-by: Rhys <rhyspuk@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.
Also move a comment that went misplaced in the recent refactorings to
the right spot again.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the various dpcd arrays in the radeon driver, use
proper symbolic constants where applicable (one place overallocated
the dpcd array to 25 bytes). Then also drop the rd_interval cache -
radeon_dp_link_train_init re-reads the dpcd block, so the values we'll
consume in train_cr and train_ce will always be fresh.
To avoid needless diff-churn, #define the old size of dpcd as the new
one and keep it around.
v2: Alex Deucher noticed one place where I've forgotten to replace 8
with DP_RECEIVER_CAP_SIZE.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
radeon and intel use the exact same definition.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
v2: Kill 2 more helpers in intel_dp.c that I've missed.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
radeon and intel use the exact same definition.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the cached EDID from intel_dp and intel_lvds_connector to
intel_connector. Unify cached EDID handling for LVDS and eDP, in
preparation for adding more generic EDID caching later.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The caller, not intel_connector_update_modes(), should free the edid. This
improves the reusability of intel_connector_update_modes().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pave the way for sharing some logic between eDP and LVDS.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Create a generic struct intel_panel for sharing a data structure and code
between eDP and LVDS panels. Add the new struct to intel_connector so that
later on we can have generic EDID and mode reading functions with EDID
caching that transparently fallback to fixed mode when EDID is not
available.
Add intel_panel as a dummy first, and move data (such as the mentioned
fixed mode) to it in later patches.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup tiny conflict in intel_dp_destroy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we do EDID caching in intel_dp_init, we can do the fixed mode
initialization there too. This should not change the functionality apart
from initializing fixed mode earlier. Particularly retain the behaviour of
only falling back to VBT if EDID is not available to not regress
commit 47f0eb2234
Author: Keith Packard <keithp@keithp.com>
Date: Mon Sep 19 14:33:26 2011 -0700
drm/i915: Only use VBT panel mode on eDP if no EDID is found
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As there is 1:1 mapping between encoder and connector for the LVDS, the
goal is to simply reduce the amount of noise within the connector
functions, i.e. we split the encoder/connector for LVDS as best we can and
try to only operate on the LVDS connector from the connector funcs and the
LVDS encoder form the encoder funcs.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Get rid of saved int_lvds_connector and int_edp_connector in
drm_i915_private.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce a local structure to move LVDS specific information away from the
drm_i915_private and onto the LVDS connector.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for introducing intel_lvds_connector to move some of the
LVDS specific storage away from drm_i915_private, first rename the encoder
to avoid potential confusion.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJQgvdwAAoJEHm+PkMAQRiG+3AH/i2XsqqN3VctL0nnbWfvds+Q
aKulfIdJTjKiVAsawPUtRqReZ8ijiebrgA/53lZLlrFOoPPQ5+LHmnSyQF6gErOY
NuAE1lijXDRM1pwBlhvOBbAj26wUobGjqONFJ9OkKr758Ue8ds/Q7UdxyEgmYgmg
tvVMzfRcICzryUV3PcqL+3cNPpCUdT6wGGRJ9DCv/jvGiWKExWhOle5oltrmxk+D
NsqRcws5pEubfHE4J8BvNWr8lE1kHfYVhrJETiLJUiN2XAJcbI4Jy7rU/3EGteNS
0HMZdaPPjV874lohdM70X2225SbYrCVkAYB5hnZCTeC3tYyCawBBPMQoyAiOcmU=
=+861
-----END PGP SIGNATURE-----
Merge tag 'v3.7-rc2' into drm-intel-next-queued
Linux 3.7-rc2
Backmerge to solve two ugly conflicts:
- uapi. We've already added new ioctl definitions for -next. Do I need to say more?
- wc support gtt ptes. We've had to revert this for snb+ for 3.7 and
also fix a few other things in the code. Now we know how to make it
work on snb+, but to avoid losing the other fixes do the backmerge
first before re-enabling wc gtt ptes on snb+.
And a few other minor things, among them git getting confused in
intel_dp.c and seemingly causing a conflict out of nothing ...
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_modes.c
include/drm/i915_drm.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
The big thing is the disabling of the hsw support by default, cc: stable.
We've aimed for basic hsw support in 3.6, but due to a few bad
happenstances we've screwed up and only 3.8 will have better modeset
support than vesa. To avoid yet another round of fallout from such a
gaffle on for the next platform we've added a module option to disable
early hw support by default. That should also give us more flexibility in
bring-up.
Otherwise just small fixes:
- 3 fixes from Egbert for sdvo corner cases
- invert-brightness quirk entry from Egbert
- revert a dp link training change, it regresses some setups
- and shut up a spurious WARN in our gem fault handler.
- regression fix for an oops on bit17 swizzling machines, introduce in 3.7
- another no-lvds quirk
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Initialize obj->pages before use by i915_gem_object_do_bit17_swizzle()
drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
drm/i915: Insert i915_preliminary_hw_support variable.
drm/i915: shut up spurious WARN in the gtt fault handler
Revert "drm/i915: Try harder to complete DP training pattern 1"
DRM/i915: Restore sdvo_flags after dtd->mode->dtd Roundrtrip.
DRM/i915: Don't clone SDVO LVDS with analog.
DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.
DRM/i915: Don't delete DPLL Multiplier during DAC init.
We were programming register 0x42020 twice on those platforms. Once
should be enough.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the consolidated registers, it appears that we're setting the same
bis several times. Let's just collect the bits we want to set and program
it once.
v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non
mobile platforms (Paulo Zanoni)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Undo the functional change as discussed on irc.]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we leave obj->pages set to NULL before attempting to deswizzle them,
then an OOPS is well deserved.
Fixes regression introduced in commit 9da3da660d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 1 15:20:22 2012 +0100
drm/i915: Replace the array of pages with a scatterlist
Reported-and-tested-by: Krzysztof Kolasa
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-and-tested-by: Francois Tigeot <ftigeot@wolfpond.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.
The transforms done are:
PCH_DSPCLK_GATE_D -> ILK_DSPCLK_GATE_D
ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D
DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
ILK_DPARB_CLK_GATE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_DPFD_CLK_GATE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_CLK_FBC -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS1 -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS2 -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D.
Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the
register change, so I went with re-defining it, well more precisely rename
IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So:
IVB_VRHUNIT_CLK_GATE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE
VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code)
This commit is only a renaming commit, further commits will clean up the
logic.
v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock
gating on their respective units, contrary to all of the other bits
(Paulo Zanoni)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Single-threaded forcewake was only used on some early pre-production
ivybridge machines, all the latest ones should use mt forcewake. And
we already assume this in other places of the code (e.g. DERRMR
support in the ddx, or the latest intel_gt_reset patch to reset any
lingering forcewake references left behind by the bios), so don't
bother here, too.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the final remaining piece of Haswell DP enablement. After this
patch, just calling intel_dp_init on any port will make DP work. We
still do not do this because we're currently initializing HDMI on all
the ports, so if we replace intel_hdmi_init with intel_dp_init, we
will break HDMI, and we can't call both because they share the same
registers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previous patch "drm/i915: add basic Haswell DP link train bits"
implemented the basic structure to set the voltage levels and training
patterns. This patch adds the higher-level bits that are part of the
mode set sequence and hot plug.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have to write the correct values inside intel_dp_set_m_n and then
prevent these values from being overwritten later.
V2: Unconfuse double negation.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a missing register. There is no problem to run this code when the
output is HDMI.
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>
We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
DP we need to do this earlier, and the values written to the register
are also different.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old rule that the AUX registers are just an offset (+4 and +10)
from output_reg is not true anymore, since output_reg in on the CPU
and some AUX regs are on the PCH.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: use the existing #defines as spotted by Damien Lespiau.]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.
Reported-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We now no longer rely on this.
This is step 1 on a long journey to rid us of the save/restore
madness, which tends to lightly paper over many issues, and cause
tons of bad things itself ...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: satisfy Paulo's ocd and drop the needless braces.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of relying on the register save/restore madness to do this.
To extract a bit of code call drm_mode_config_reset both on resume
and boot-up and move the hw state frobbing from the crt_init to the
->reset callback. The crt connector is the only one with a ->reset
callback, hence we can easily do this.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... since they don't apply to pre-pch platforms and could actually be
harmful.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already do that as part of the ringbuffer re-setup at resume time.
Furthermore the register offset has moved on gen6+ around quite a bit,
and on ilk/gm45 we also need to restore the HWS reg for the bsd ring,
not just the render ring.
So again in kms mode this is only confusing a best, hence don't
bother.
v2: Fixup logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already call drm_irq_install/uninstall at the right time, which
will set up the irq registers with the correct values (through the
preinstall hooks).
For kms this is at best harmless, in the worst case we get an
interrupt when we don't really expect it.
v2: Fixup the logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We completely compute these anew in each modeset, hence we don't rely
on them containing anything valid after resume.
To avoid breaking any ums setup due to reordering of the reads/writes
simply don't reorder anything, but bracket the reads/writes into if
(!kms) conditionals. More churn, but safer.
v2: Fixup the logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Much simpler and looks more like the M/N code inside intel_display.c.
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>
Previously, the DP register was used for everything. On Haswell, it
was split into DDI_BUF_CTL (which is the new intel_dp->DP register)
and DP_TP_CTL.
The logic behind this patch is based on a patch written by Shobhit
Kumar, but the way the code was written is very different.
Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fixup the logic error spotted by Jani Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In theory, all the DDI pipe settings should be set here, including
timing and M/N registers. For now, let's just set the DP MSA
attributes.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixed up the unused typo in a #define, spotted by Jani
Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Daniel Vetter