CHV has three pipes so let's expose them all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unsurprisingly the cursor C regiters are also at a weird offset on CHV.
Add more pipe offsets to handle them.
This also gets rid of most of the differences between the i9xx vs. ivb
cursor code. We can unify the remaining code as well, but I'll leave
that for another patch.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On CHV the GMBUS port for port D is different from other gmch platforms
which have port D. Fix it up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On CHV pipe C can driver only port D, and pipes A and B can drivbe only
ports B and C. Configure the crtc_mask appropriately to reflect that.
v2: Moar braces (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for the third pipe in cherrview
v2: Don't use spaces for indentation (Jani)
Wrap long lines
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
[vsyrjala: slightly massaged the patch]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cherryview also needs this WA.
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
[vsyrjala: Looks like it's for pre-prodution hw only]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We implement the following workarounds:
* WaDisableAsyncFlipPerfMode:chv
* WaProgramMiArbOnOffAroundMiSetContext:chv
v2: Drop WaDisableSemaphoreAndSyncFlipWait note
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This workaround is listed for CHV, but not for BDW. However BSpec notes
that on BDW CSunit clock gating is always disabled irrespective of the
relevant bit in the GEN6_UGCTL1 registers. For CHV however, such text
is not present in BSpec, so it seems safer to just set the bit.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BDW has the same requirement but the w/a database doens't list
this w/a for BDW. Seems to be another one of those "stick a bunch
of known workarounds into this bag and write something on the label"
type of things.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Besides the fairly useless BUG_ON the logic is completely generic
and cane be used on any platform what wants to reuse the shared
dpll support code.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the last piece of code which write state to the hardware in
the ironalake ->crtc_mode_set callback.
I think we could merge this with the pll->enable hook, but otoh the
ordering requirements with the ldvs port are really tricky. Doing the
FP0/1 writes up-front before we even prepare the lvds port (in the
pre_pll_enable hook) like on i9xx seems safest.
With this ilk+ platforms are now ready for runtime PM with DPMS. Since
hsw/bdw also support runtime pm besides snb we need to first make the
haswell code save before we can touch the core code.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of every time it isn't active: We only need to do that when
the pll is currently unused, i.e. when pll->refcount == 0. For
paranoia add a warning for the ibx case where plls have a fixed
mapping and hence should always be unused after the call to
intel_put_shared_dpll.
v2: Simplify control flow and use struct assignment instead of memcpy
as suggested by Damien.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this all hw writes are also gone from the ->crtc_mode_set hook on
vlv. I wondered whether we should track more of the pll state in the
pipe config, but otoh as long as we don't have shared plls that's not
really useful - the cross-checking of the port clock should be
sufficient.
While at it also de-magic some of the pipe checks, this has been
irking me since a long time.
Whit this vlv is now ready for runtime PM on dpms. If we'd have
runtime PM support in general ...
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These two writes are the very last hw writes from the
->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit
different, so this here is just warm-up.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again the same story: This code just transform sw state from the pipe
config into hardware state. And again we can't move the pll code, but
this time around because the state isn't properly tracked in the pipe
config.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again this code just transforms sw state from the pipe config into
hardware state, so we can just move it around. Unfortunately again a
few forward declarations since intel_display.c is becoming a bit of a
mess.
Note that both for i9xx and ironlake code the only things remaining in
the ->crtc_mode_set hook is now the clock state computation and
sharing code. That needs to be moved into the compute config stage so
that we can catch impossible configurations earlier.
Also note that some of the DPLL hw setup code is still run from within
->crtc_mode_set, namele the pll->mode_set callback. We need to move
that first before we can do fancy things like enable runtime PM for
dpms off.
v2: Make it compile again after the rebase, bisectability issue
reported by Wu Fengguang.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now this really should be in the pipe config somewhere, but till now
it isn't. We can at least move it up a bit next to all the other pll
code since intel_dp_set_m_n really doesn't depend upon this.
This is just prep work so that moving all the hw frobbing code from
->crtc_mode_set to ->crtc_enable is clean.
v2: Do the same for haswell while at it, not just for ivb.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All these functions simply convert sw state as encoded in the pipe
config or primary framebuffer into hardware state. So we can move them
all into the crtc enable hook. Unfortunately this means a little bit
of duplication between the i9xx and vlv functions, but since we
already have highly refactored code I think this is acceptable.
Also a pile of forward declarations unfortunately.
Note also that the various <platform>_update_pll functions are still
called from within the ->crtc_mode_set hook. Mostly they compute the
clock state for the pipe config, but unfortunately there are some
random register writes interspersed. Those need to be moved out first
before we can enable runtime PM for DPMS.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Before the process killer is invoked, oom-notifiers are executed for one
last try at recovering pages. We can hook into this callback to be sure
that everything that can be is purged from our page lists, and to give a
summary of how much memory is still pinned by the GPU in the case of an
oom. This should be really valuable for debugging OOM issues.
Note that the last-ditch effort call to shrink_all we've previously
called from our normal shrinker when we could free as much as the vm
demaned is moved into the oom notifier. Since the shrinker accounting
races against bind/unbind operations we might have called shrink_all
prematurely, which this approach with an oom notifier avoids.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72742
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com>
[danvet: Bikeshed logical | into || and pimp commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.
We were actually always writing 0x2 to the reset domain bits, which
is a reserved value. In practice it looks like the hardware ignores that
value since nothing happens if I write that value when there's a 3D
workload running. Writing the _correct_ render domain value actually
makes the GPU stop.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should be waiting for the reset bit to clear, not remain set.
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>
There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does, ie. we don't perform a display reset. Drop
the bogus comments.
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>
Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory pressure and forced to drop GEM objects from
memory. In effect, this should just allow us to discard unused pages for
memory reclaim and to start writeback earlier.
v2: Hugh Dickins warned that explicitly starting writeback from
shrink_slab was prone to deadlocks within shmemfs.
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Robert Beckett <robert.beckett@intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can share a few lines of tricky lock handling we need to use for both
shrinker routines and in the process fix the return value for count()
when reporting a deadlock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Robert Beckett <robert.beckett@intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the machine is under a lot of memory pressure and being stressed by
multiple GPU threads, we quite often report fewer than shrinker->batch
(i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to
skip calling into i915.ko to release pages, despite the GPU holding onto
most of the physical pages in its active lists.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72742
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Robert Beckett <robert.beckett@intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
shmemfs first checks if there is enough memory to allocate the page
and reports ENOSPC should there be insufficient, along with
the usual ENOMEM for a genuine allocation failure.
We use ENOSPC in our driver to mean that we have run out of aperture
space and so want to translate the error from shmemfs back to
our usual understanding of ENOMEM. None of the the other GEM users
appear to distinguish between ENOMEM and ENOSPC in their error handling,
hence it is easiest to do the fixup in i915.ko
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Robert Beckett <robert.beckett@intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary "this is a lost
cause" timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78383
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>
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these registers are reset and failing to program them results
in a blank screen.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer <sulamiification@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our two ->crtc_mode_set callbacks really don't care whether the fb is
pinned and set up already or not - all the state computation and
handling which originally looked at the framebuffer is already using
the indirection through the pipe configuration.
Eventually we want to move this up a bit more, but as long as the crtc
mode_set callback still exists (and as long as we don't need to pin an
entire pile of planes due to atomic modesets) there's not much point
in it. So I'll let this be for now.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A lot of the code in set_base is uncessary when the crtc is off, so we
can get rid of it all. Also, we don't need to call the fbc/psr update
functions since the crtc enable/disable hooks do that already.
The only things we really need are:
- Pin the new framebuffer and potentially unpin the old framebuffer
(if the crtc has been on and we only change the configuration).
- Update the plane registers.
The first step will move out of platform code with the very next
patch.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My plan here is to split up set_base into a prepare step, which does
the pinning, and a commit stage, which updates the hw state. Eventually
we should be able to move the prepare step at the beginning of any
atomic update. For now I only want to move the commit step into the
crtc_enable callbacks.
As a prep step sprinkle intel_edp_psr_update all over the place so
that we don't have to concern ourselves with that in the commit step.
v2: Rebase on top of Ville's enable/disable functions for all planes.
v3: Rebase more.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just for consistency, this patch won't fix anything really.
v2: Rebase over all the recent plane enabling shuffling.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Way back we've used this to reject framebuffers with unsupported
pixel formats. But since the modesetting reorg with the compute
config stage we reject those much earlier and just BUG() in this
callback. So switch to a void return type.
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
More fallout from
commit c8725f3dc0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 17 12:21:55 2014 +0000
drm/i915: Do not call retire_requests from wait_for_rendering
is that we can completely fill all of memory using small objects, such
that we exhaust the filp space, and spend all of our time evicting
objects from the aperture. As such, we never fill the ring, and never
trigger the last resort flushing in
commit 1cf0ba1474
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon May 5 09:07:33 2014 +0100
drm/i915: Flush request queue when waiting for ring space
and so all the requests are left active and the objects keep that last
active reference. Eventually the system comes to a halt as it runs out
of memory.
The impact is mainly limited to test cases as regular userspace will
trigger retirement by manually checking whether an object is active.
Testcase: igt/gem_lut_handle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78724
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since commit 691e6415c8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we have contexts everywhere, and so we must be careful to distinguish
fake contexts, which do not have an associated bo, and real ones, which
do. In particular, we now need to be careful not to dereference NULL
pointers.
This is one such example, as the commit highlighted above failed to move
the unpinning of the default ctx object into the real-context-only
branch.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78792
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some platforms have a shared error interrupt, so if FIFO underrun
reporting gets disabled for one pipe/transcoder it gets disabled
for all pipes/transcoders.
When we disable FIFO underrun reporting we check whether the
interrupt was enabled or not. If it wasn't we might have missed
an underrun and we perform one last check right there. Currently
we print a debug message when an underrun is detect using this
mechanism. Promote the message to DRM_ERROR() to match the other
underrun error messages.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is still not pinned
to GGTT and maybe not even bound, so we have to check before we
dereference its GGTT vma.
The IGT kms_flip/bo-too-big tests for this bug.
v2: Chris Wilson says restoring the old value is easier, but that
is_pin_display is useful as a theory of operation. Take the solomonic
decision: at least this way is_pin_display is a little more robust
(until Chris can kill it off).
v3: Chris suggests the WARN in i915_gem_obj_to_ggtt has outlived its
usefulness: add a reminder to remove it.
Issue: VIZ-3772
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Testcase: igt/kms_flip/bo-too-big
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
code.
- All the modeset state seems to be tracked in the intel_dsi structure
instead of the pipe config.
Given all that I can't properly audit the dsi ->mode_set callback. So
just do it as the first thing in the ->pre_pll_enable hook and hope
for the best.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A bit more care required here since there are some very few things
between the call to encoder->mode_set and encoder->pre_enable. But
they're either book-keeping or only matter for the vga port on the
pch. So of no concern.
Note that with the new sequence we write the infoframes after
selecting the clock source, but that shouldn't matter. I've simply
opted for this to have simpler code.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All the hard work was already done, only thing left to do is remove
the empty callback. And a now rather misleading comment I've spotted
while reading through code.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to dp the only thing we do is call intel_write_eld and prepare
a bit of state for the enable hooks. The only difference is that we
write that to the hardware instead of keeping track of it somewhere in
software.
Still we can just move all this to the very first enable hook.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those functions are only used on vlv platforms, so no need to check.
Especially if we're not too consistent about it.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With all the preceding refactoring the dp mode_set callback only
computes a bit of state (all derived from the pipe config) and also
writes the eld. As long as we do that before we enable the audio bit
or depend upon the correct value in intel_dp->DP we'll be fine.
No other hw state is touched.
We therefore only need to check that clearing intel_dp->DP is save.
Which it is since when we re-enable we already mask out all the bits
the link training code sets. And we need to keep on doing that so that
the re-train loop walking over pre-emph/voltage-swing values still
works properly.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only ilk/snb/ivb need the port A pll setup, so move it to the
pre_enable hook for those platforms. We can savely do this since on
those platforms there's nothing that touches the hardware between the
encoder->mode_set and the encoder->pre_enable calls.
Also add a comment that port A is ilk+ only.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.
Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
that means some pretty extensive reworking of our code which
currently does all this while the pipe/port is still off.
I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
encoder.
I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no need to check whether audio is enabled (which for ddi ports
is done through the crtc->eld_vld flag) since at the cost of a
potentially unecessary register rmw cycle we can unconditionally do
this.
Note that the edp check is just paranoia since we won't ever call the
write_eld function for an edp panel.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way we can rely on the state cross-checker to have a bit
assurance that we'll get it right.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on those platforms which have a simple bit and don't rely
on the fully programmable CSC unit to do this.
Note that with the current code this includes CHV, but I guess that
platform will match BYT.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We in the pre_enable hook we should only rely on the pipe config and
not on some other state set through properties or detect functions.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For compliance we really should be sending NULL infoframes always
when we detect a hdmi capable monitor. Also remove the now redudant
setting for the has_audio case and enforce that audio is only
possible with a hdmi sink.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everything should be in place so enable rc6/rps for bdw.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
by correctly displaying result and requested.
Suggested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
v2: Add (1<<31) mask (Ville)
v3: Add Gen check for the mask (ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requiring changes to the interrupt handling. As
such it /should/ be relatively trivial. It's highly likely that I missed
some places where I need a gen8 version of the PM interrupts, but it has
become invisible to me by now.
This patch could probably be split into adding the new functions,
followed by actually handling the interrupts. Since the code is
currently disabled (and broken) I think the patch stands better by
itself.
v2: Move the commit about not touching the ringbuffer interrupt to the
snb_* function where it belongs (Rodrigo)
v3: Rebased on Paulo's runtime PM changes
v4: Not well validated, but rebase on
commit 730488b2ed
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Mar 7 20:12:32 2014 -0300
drm/i915: kill dev_priv->pm.regsave
v5: Rebased on latest code base. (Deepak)
v6: Remove conflict markers, Unnecessary empty line and use right
IIR interrupt (Ville)
v7: mask modified without rmw (Ville Syrjälä)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we dont have semaphores enabled, we allocate 4
dwords for signalling. But end up emitting more regardless.
Fix this by bailing out early if semaphores are not enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78274
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78283
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added as generic parameters which will be initialized in the panel
driver and are specific to panels.
Backlight delays have also kept as placeholders and will be used used
once we have MIPI backlight enabling support
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In VBT fields operation mode is 0 for Video mode and 1 for command mode.
This field will be directly used as is in generic panel driver. So
adjust accordingly.
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are generated with intel-gpu-tools/tools/null_state_gen
v2: Don't use header file for states (Daniel Vetter)
v3: Proper URB state size for gen8/GT3 (Damien Lespiau)
Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1)
Tested-by: Oscar Mateo <oscar.mateo@intel.com> (v2)
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
- use .c files for state (Daniel Vetter)
- no need to flush as i915_add_request does it
- remove parameter for batch alloc size
- don't wait for the init (Ben Widawsky)
v3: - move to cpu/gpu (Chris Wilson)
Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1)
Tested-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
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>
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite gtt
fastpath. But that one checks of obj tiling, so should be ok.
But one thing that _does_ blow up is the vma unbinding with more than
one address space. The next patch will fix this.
v2: Use a WARN_ON - Chris pointed out that we already catch all cases
so userspace can't provoke this like I've originally feared.
While reviewing relevant code I've noticed a pile of DRM_ERROR in the
overlay&cursor code which are all triggerable by userspace. Tune them
down while at it.
v3: Split out the DRM_ERROR->DRM_DEBUG_KMS change into a separate patch,
as requested by Chris.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: 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>
During initial probing of the modes to assign to the fbdev console, we
use the CRTC and connector ids. These are much harder for us to
understand than if we used their actual names (or pipe in the CRTC
case). Similarly, we want to manually print the mode size rather than
rely on mode->name being set.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Patch done using the following semantic patch (thanks Daniel for the
help!)
@@
iterator name list_for_each_entry;
iterator name for_each_crtc;
struct drm_crtc * crtc;
struct drm_device * dev;
@@
-list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) {
+for_each_crtc(dev,crtc) {
...
}
Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Generated using the semantic patch:
@@
iterator name list_for_each_entry;
iterator name for_each_intel_crtc;
struct intel_crtc * crtc;
struct drm_device * dev;
@@
-list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) {
+for_each_intel_crtc(dev,crtc) {
...
}
Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fed up with having that long list_for_each_entry() invocation?
Use for_each_intel_crtc()!
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Squash in patch that exported ilk_wm_max_level.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That's not necessary and makes the code not as neat as it could be.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow UXA submits a completely bogus DR4 value since essentially
forever. It was originally introduced in
commit bade7d7d2505a10a8a7d24b084aff9742e2d6d64
Author: Eric Anholt <eric@anholt.net>
Date: Fri Jun 6 14:03:25 2008 -0700
Use the DRM for submitting batchbuffers when available.
and dutifully copied around ever since. Since we want to keep the
general dirt catching around just special case the UXA value.
This regression was introduced in
commit 9cb346648d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 08:09:11 2014 +0200
drm/i915: Catch dirt in unused execbuffer fields
Comment from Chris' review:
"To be fair, it is a sensible value if one supposes a Region style API to
cliprects. Under that API, DR[14] define the extents of the clip region,
and ((0,0), (0,0)) [DR1==DR4==0] would mean all clipped, do not draw
anything."
v2: Pimp commit message a bit and remove the double space.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78494
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jörg Otte <jrg.otte@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The fence pin count should always be <= the bo pin count. If that's
not the case then we have a funny problem and are leaking references
somewhere.
Which means we can catch fence pin leaks by checking for the same
upper limit as we do for the bo pin count. Inspired by a discussion
with Ville about a fence leak igt testcase.
v2: Also check for fence->pin_count <= ggtt_vma->pin_count, since that
might catch a leak even quicker. Also de-inline them, they're getting
too big.
v3: Don't separately check for MAX_PIN_COUNT since the > vma->pin_count
check will catch that already (Chris).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pipe might not start to actually run until the port has been enabled
(depends on the platform and port type). So don't try to wait for vblank
after we enabled the pipe but haven't yet enabled the port.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already moved the plane disable/enable to happen as the first/last
thing on every other platforms. Follow suit with gmch platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict, as usual.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is missing in:
commit 78325f2d27
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Tue Apr 29 14:52:29 2014 -0700
drm/i915: Virtualize the ringbuffer signal func
Looks to me like a rebase side-effect...
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field
(GFX stolen memory size) with the addition of finer granularity modes:
4MB increments from 0x11 (8MB) to 0x1d.
Values strictly above 0x1d are either reserved or not supported.
v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new
values (Ville Syrjälä)
v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville
Syrjälä)
v4: Don't assign a value that needs 20bits or more to a u16 (Rafael
Barbalho)
[vsyrjala: v5: Split the early quirks to another patch]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No CRT output on CHV, so don't call intel_crt_init().
v2: Don't disable CRT on HAS.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add chv_crtc_clock_get() to read out the DPLL settings.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fix compile due to bikeshedded headers in an earlier patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With additional of pipe C, current 1 bit registers for pipe select
for HDMI and DP are no longer able to gather for 3 pipes. As a result,
new bits location in the same registers are added.
For HDMI, VLV uses bit 30, CHV uses bit 24-25.
For DP, VLV uses bit 30, CHV uses bit 16-17.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added programming phy layer for CHV based on "Application note for 1273
CHV Display phy".
v2: Rebase the code and do some cleanup.
v3: Rework based on Ville review.
-Fix the macro where the ch info need to swap, and add parens to ?
operator.
-Fix wrong bit define for DPIO_PCS_SWING_CALC_0 and
DPIO_PCS_SWING_CALC_1 and rename for meaningful.
-Add some comments for CHV specific DPIO registers.
-Change the dp margin registery value to decimal to align with the
doc.
-Fix the not clearing some value in vlv_dpio_read before write again.
-Create new hdmi/dp encoder function for chv instead of share with
valleyview.
v4: Rebase the code after rename the DPIO registers define and upstream
change.
Based on Ville review.
-For unique transition scale selection, after Ville point out, look
like the doc might wrong for the bit 26. Use bit 27 for ch0 and
ch1.
-Break up some dpio write value into two/three steps for readability.
-Remove unrelated change.
-Add some shift define for some registers instead just give the hex
value.
-Fix a bug where write to wrong VLV_TX_DW3.
v5: Based on Ville review.
- Move tx lane latency optimal setting from chv_dp_pre_pll_enable to
chv_pre_enable_dp, and chv_hdmi_pre_pll_enable to
chv_hdmi_pre_enable respectively.
- Fix typo in one margin_reg_value for DP_TRAIN_VOLTAGE_SWING_400.
- Clear DPIO_TX_UNIQ_TRANS_SCALE_EN for DP and HDMI.
- Mask the old deemph and swing bits for hdmi.
v6: Remove stub for pre_pll_enable for dp and hdmi.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[vsyrjala: Don't touch panel power sequencing on DP]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added programming PLL for CHV based on "Application note for 1273 CHV
Display phy".
v2: -Break the common lane reset into another patch.
-Break the clock calculation into another patch.
-The changes are based on Ville review.
-Rework based on DPIO register define naming convention change.
-Break the dpio write into few lines to improve readability.
-Correct the udelay during chv_enable_pll.
-clean up some magic numbers with some new define.
-program the afc recal bit which was missed.
v3: Based on Ville review
- minor correction of the bit defination
- add deassert/propagate data lane reset
v4: Corrected the udelay between dclkp enable and pll enable.
Minor comment and better way to clear the TX lane reset.
v5: Squash in fixup from Rafael Barbalho.
[vsyrjala: v6: Polish the defines (Imre)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the chv clock limit, find the best divisor.
The divisor data has been verified with this spreadsheet.
P1273_DPLL_Programming Spreadsheet.
v2: Rebase the code and change the chv_find_best_dpll based on new
standard way to use intel_PLL_is_valid. Besides, clean up some extra
variables.
v3: Ville suggest better fixed point for m2 calculation.
v4: -Add comment for the limit is compute using fast clock. (Ville)
-Don't pass the request clock to chv_clock, as the same function will
be use clock readout, which doens't have request clock. (Ville)
-Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock
calculation. (Ville)
-Fix the dp m2 after m2 has stored fixed point. (Ville)
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Avoid div-by-zero in chv_clock()]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During cold boot, the display controller needs to deassert the common
lane reset. Only do it once during intel_init_dpio for both PHYx2 and
PHYx1.
Besides, assert the common lane reset when disable pll. This still
to be determined whether need to do it by driver.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Don't disable DPIO PLL when using DSI]
[vsyrjala: Don't call vlv_disable_pll() by accident on CHV]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Move part of a moved comment back as suggested by Imre since
it's valid for both byt and chv.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cherryview has 3 pipes. Some of the pll dpio offset calculation is
based on pipe number. Need to use vlv_pipe_to_channel to calculate the
correct phy channel to use for the pipe.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The additional DPLL registers added to support Port D. Besides, add
some new PHY control and status registers based on B-spec.
v2: Based on Ville review
- Corrected DPIO_PHY_STATUS offset and name.
- Rebase based on upstream change after introduce enum dpio_phy and
enum dpio_channel.
v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for
the DPLL registers aren't in place yet, so this introduces a slight regression.
But since 3 pipe support isn't fully enabled yet anyaway in -internal this
shouldn't matter too much.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV has 2 display phys. First phy (IOSF offset 0x1A) has two channels,
and second phy (IOSF offset 0x12) has single channel. The first phy is
used for port B and port C, while second phy is only for port D.
v2: Move the pipe to determine which phy to select for
vlv_dpio_read/vlv_dpio_write to another patch. (Daniel)
v3: Rebase the code based on rework on how to calculate DPIO offset.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
