The return type of exec_lookup() is struct nvkm_output *, so it should
return NULL rather than 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There is always the possiblity that the ppm->context pointer would get
partially updated and accidentally would equal ctx. This would allow two
contexts to co-exist, which is not acceptable. Moving the test to the
critical section takes care of this problem.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This fixes a crash when multiple PM engine contexts are created.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
After submitting a GO_IDLE bundle, one must wait for GR to effectively
be idle before submitting the next bundle. Failure to do so may result
in undefined behavior in some rare cases.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Kary Jin <karyj@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When emitting the ICMD bundle, wait on the bottom half (bit 3 of the
GR_STATUS register) instead of upper half (bit 2) to make sure methods
are effectively emitted.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kicking channels is part of their deactivation process. Maxwell chips
are particularly sensitive to this, and can start fetching the previous
pushbuffer of a recycled channel if this is not done.
While we are at it, improve the channel preemption code to only wait for
bit 20 of 0x002634 to turn to 0, as it is the bit indicating a
preempt is pending.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Increase clock timeout for SYS, FPB and GPC in order to avoid operation
failure at high gpcclk rate.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The lack of IOMMU API support can make nouveau_platform_probe_iommu()
fail to compile because struct iommu_ops is then empty. Fix this by
skipping IOMMU probe in that case - lack of IOMMU on platform devices
is sub-optimal, but is not an error.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The memory allocated for a nouveau_cli object in nouveau_cli_create() is
never freed. Free the memory in nouveau_cli_destroy() to plug this leak.
kmemleak recorded this after running a couple of nouveau test programs.
Note that kmemleak points at drm_open_helper() because for some reason
it thinks that skipping the first two stack frames is a good idea.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Chris rightfully suggested that documenting fences without documenting
the BO tiling tracking doesn't make much sense, so fix that.
The important bit to stress here (since it lead to some confusion) is
the GEM doesn't really care about tiling. Except for a few select cases
where the kernel needs to manage something that userspace can't take
care of: Namely the limited number of fences and fixing up swizzling,
although we still fail at the later.
v2: Move the low-level tiling/swizzling functions and kerneldoc to
i915_gem_fence.c and leave only the userspace interface here.
Suggested by Chris.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It fits more with the low-level fence code, and this move leaves only
the userspace tiling ioctl handling in i915_gem_tiling.c.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
v2: Clarify that this is about fence _registers_. Also clarify that
the fence code revokes cpu ptes and not gtt ptes. Both suggested by
Chris.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
No code changes, just moving all the fence related code into a
separate file (and avoiding a bunch of forward declarations while at
it).
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Sorting became confused and a few new files ended up in strange
places. Also move i915_irq.c to core since with the recent-ish
extraction of i915_gpu_error.c and intel_hotplug.c it's more and more
really just basic irq handling code.
When adding new files please don't put them somewhere randomly.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.
Changes since v1:
- Update kerneldocs slightly.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
connector hotplug locking cleanup and fixes to make it save against
atomic. Note that because of depencies this is based on top of the
drm-intel-next pull, so that one needs to go in before this one.
I've also thrown in the mode_group removal on top since it's defunct,
never worked really, no one seems to care and the code can be resurrected
easily.
* tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm: gc now dead mode_group code
drm: Stop filtering according to mode_group in getresources
drm: Roll out drm_for_each_{plane,crtc,encoder}
drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show
drm: Roll out drm_for_each_connector more
drm: Amend connector list locking rules
drm/radeon: Take all modeset locks for DP MST hotplug
drm/i915: Take all modeset locks for DP MST hotplug
drm: Check locking in drm_for_each_fb
drm/i915: Use drm_for_each_fb in i915_debugfs.c
drm: Check locking in drm_for_each_connector
drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
drm: Add modeset object iterators
drm: Simplify drm_for_each_legacy_plane arguments
crystalcove pmic support from Shobhit. Patch series has all acks/r-bs from
other mainainers so ok to pull into drm-next. But I'm cc'ing all other
maintainers as fyi and in case they want to pull it into their trees too
to avoid conflicts.
* tag 'topic/crc-pmic-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled
drm/i915: Backlight control using CRC PMIC based PWM driver
drm/i915: Use the CRC gpio for panel enable/disable
pwm: crc: Add Crystalcove (CRC) PWM driver
mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal
gpiolib: Add support for removing registered consumer lookup table
- prelim hw support dropped for skl after Damien fixed an ABI issue around
planes
- legacy modesetting is done using atomic infrastructure now (Maarten)!
- more gen9 workarounds (Arun&Nick)
- MOCS programming (cache control for better performance) for skl/bxt
- vlv/chv dpll improvements (Ville)
- PSR fixes from Rodrigo
- fbc improvements from Paulo
- plumb requests into execlist submit functions (Mika)
- opregion code cleanup from Jani
- resource streamer support from Abdiel for mesa
- final fixes for 12bpc hdmi + enabling support from Ville
drm-intel-next-2015-07-03:
- dsi improvements (Gaurav)
- bxt ddi dpll hw state readout (Imre)
- chv dvfs support and overall wm improvements for both vlv and chv (Ville)
- ppgtt polish from Mika and Michel
- cdclk support for bxt (Bob Pauwe)
- make frontbuffer tracking more precise
- OLR removal (John Harrison)
- per-ctx WA batch buffer support (Arun Siluvery)
- remvoe KMS Kconfig option (Chris)
- more hpd handling refactoring from Jani
- use atomic states throughout modeset code and integrate with atomic plane
update (Maarten)
drm-intel-next-2015-06-19:
- refactoring hpd irq handlers (Jani)
- polish skl dpll code a bit (Damien)
- dynamic cdclk adjustement (Ville & Mika)
- fix up 12bpc hdmi and enable it for real again (Ville)
- extend hsw cmd parser to be useful for atomic configuration (Franscico Jerez)
- even more atomic conversion and rolling state handling out across modeset code
from Maarten & Ander
- fix DRRS idleness detection (Ramalingam)
- clean up dsp address alignment handling (Ville)
- some fbc cleanup patches from Paulo
- prevent hard-hangs when trying to reset the gpu on skl (Mika)
* tag 'drm-intel-next-2015-07-17' of git://anongit.freedesktop.org/drm-intel: (386 commits)
drm/i915: Update DRIVER_DATE to 20150717
drm/i915/skl: Drop the preliminary_hw_support flag
drm/i915/skl: Don't expose the top most plane on gen9 display
drm/i915: Fix divide by zero on watermark update
drm/i915: Invert fastboot check
drm/i915: Clarify logic for initial modeset
drm/i915: Unconditionally check gmch pfit state
drm/i915: always disable irqs in intel_pipe_update_start
drm/i915: Remove use of runtime pm in atomic commit functions
drm/i915: Call plane update functions directly from intel_atomic_commit.
drm/i915: Use full atomic modeset.
drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
drm/i915: Enable WA batch buffers for Gen9
drm/i915/gen9: Implement WaDisableKillLogic for gen 9
drm/i915: Use expcitly fixed type in compat32 structs
drm/i915: Fix noatomic crtc disabling, v2.
drm/i915: fill in more mode members
drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro
...
Update drm-misc pull request since the first one didn't go in yet. Few
atomic helper patches, rejecting some old dri1 crap for modern drivers and
a few trivial things on top.
* tag 'topic/drm-misc-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm/mgag200: remove unneeded variable
drm/mgag200: remove unused variables
drm/atomic: Only update crtc->x/y if it's part of the state, v2.
drm/fb: drop panic handling
drm: Fix warning with make xmldocs caused by drm_irq.c
drm/gem: rip out drm vma accounting for gem mmaps
drm/fourcc: Add formats R8, RG88, GR88
drm/atomic: Cleanup on error properly in the atomic ioctl.
drm: Update plane->fb also for page_flip
drm: remove redundant code form drm_ioc32.c
drm: reset empty state in transitional helpers
drm/crtc-helper: Fixup error handling in drm_helper_crtc_mode_set
drm/atomic: Update old_fb after setting a property.
drm: Remove useless blank line
drm: Reject DRI1 hw lock ioctl functions for kms drivers
drm: Convert drm_legacy_ctxbitmap_init to void return type
drm: Turn off Legacy Context Functions
Regression fix for systemd getting confused about unknown connector state
after resume. Just stop setting the state to unknown, turned out to be a
silly idea anyway. What drivers imo really should do (and i915 still does
that) is forcing a full reprobe on resume to make sure connector changes
while suspended are caught. Most drivers seem to get this wrong. Otoh it
took us years to get fixes merged where some probe races resulted in
eating uevents, I guess userspace expectations for reliable hpd are just
really low :(
* tag 'topic/drm-fixes-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm: Stop resetting connector state to unknown
arb_timer kernel side fix from Chris.
* tag 'drm-intel-fixes-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls
Some amdgpu fixes.
* 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu/cz/dpm: properly report UVD and VCE clock levels
drm/amdgpu/cz: implement voltage validation properly
drm/amdgpu: add VCE harvesting instance query
drm/amdgpu: implement VCE 3.0 harvesting support (v4)
drm/amdgpu/dce10: Re-set VBLANK interrupt state when enabling a CRTC
drm/amdgpu/dce11: Re-set VBLANK interrupt state when enabling a CRTC
Return proper pgprot for ARM64. This is required for objects like
Nouveau fences to be mapped with expected coherency.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
VCE, UVD DPM work similarly to SCLK DPM. Report the current
clock levels for UVD and VCE via debugfs.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CZ uses a different set of registers compared to previous asics
and supports separate NB and GFX planes.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For boards with bad VCE blocks, only configure the working
block.
v2: use the harvest info for pipe setup
v3: fix mask check as noted by Leo
v4: add dGPU support
Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This doesn't seem strictly necessary with Tonga right now, but that might
change with future power management enhancements.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Something (ATOM BIOS?) seems to be clobbering the LB_INTERRUPT_MASK
register while the CRTC is off, which caused e.g. glxgears or
gnome-shell to hang after a modeset.
Reviewed-and-Tested-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Sonny Jiang <sonny.jiang@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Two nice things here:
- drm_dev_register will truly register everything in the right order
if the driver doesn't have a ->load callback. Before this we had to
init the primary mode_group after the device nodes where already
registered.
- Less things to keep track of when reworking the connector locking,
yay!
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.
Given overwhelming evidence it looks like this isn't a feature we
need, hence remove it.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Remaining manual work in the drm core&helpers. Nothing special here,
no surprises.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
v2: Drop unused dev spotted by 0day.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.
Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.
The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Just so I have a user for this macro.
v2: Use the right macro - somehow I thought gcc should scream at me,
but list_for_each isn't really typesafe unfortunately. Spotted by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
fbdev can actually cope with hotplug changes. And it's also more
consistent with the connector hotadd/remove dp mst needs to do.
Therefore document this as new official behavior.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a locking WARN_ON I'd like to
add, which means init code gets some additional locks just for
uniformity.
v2: Also grab the lock for the public poll_enable, not just poll_init
which is used for resume, with the same justification.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by a
list_for_each_entry_safe in the driver teardown code.
Search&replace was done with the below cocci spatch. Note that there's
a bunch more places that didn't match and which would need some manual
changes, but I've intentially left these out for this mostly automated
patch.
iterator name drm_for_each_crtc;
struct drm_crtc *crtc;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ drm_for_each_crtc (crtc, dev) {
...
}
@@
iterator name drm_for_each_encoder;
struct drm_encoder *encoder;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ drm_for_each_encoder (encoder, dev) {
...
}
@@
iterator name drm_for_each_fb;
struct drm_framebuffer *fb;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+ drm_for_each_fb (fb, dev) {
...
}
@@
iterator name drm_for_each_connector;
struct drm_connector *connector;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_for_each_connector (connector, dev) {
...
}
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Mar 6 12:36:42 2015 +0000
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos <tiagomatos@gmail.com>
Cc: Julien Wajsberg <felash@gmail.com>
Cc: kuddel.mail@gmx.de
Cc: Lennart Poettering <mzxreary@0pointer.de>
Cc: stable@vger.kernel.org
Acked-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rui Tiago Cação Matos <tiagomatos@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is a requirement for enabling display port HPD support on the port
A HPD pin. This support is to be added by follow-up patches.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently HPD_PORT_A is used as an alias for HPD_NONE to mean that the
given port doesn't support long/short HPD pulse detection. SDVO and CRT
ports are like this and for these ports we only want to know whether an
hot plug event was detected on the corresponding pin. Since at least on
BXT we need long/short pulse detection on PORT A as well (added by the
next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the
return value of intel_hpd_pin_to_port() show whether long/short pulse
detection is supported on the passed in pin.
No functional change.
v2:
- rebase on top of -nightly (Daniel)
- make the check for intel_hpd_pin_to_port() return value more readable
(Sivakumar)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are quite similar, so combine them with the use of a new
argument for a function that detects long pulses. This will be also
needed by an upcoming patch adding support for BXT long pulse detection.
No functional change.
v2:
- rebase on top -nightly (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The extra check for connector_type is not required as we are already
checking for connector_type != DRM_MODE_CONNECTOR_DisplayPort.
The check was added by commit eb3394faeb ("drm/i915: Add debugfs test
control files for Displayport compliance testing")
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While creating the debugfs file we are setting the inode->i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). Moreover single_open is setting
file->private_data->private to dev.
So at this point it can never be NULL.
This check was added by commit eb3394faeb ("drm/i915: Add debugfs test
control files for Displayport compliance testing")
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the hardware sometimes mysteriously totally flummoxes the 64bit
read of a 64bit register when read using a single instruction, split the
read into two instructions. Since the read here is of automatically
incrementing timestamp counters, we also have to be very careful in
order to make sure that it does not increment between the two
instructions.
However, since userspace tried to workaround this issue and so enshrined
this ABI for a broken hardware read and in the process neglected that
the read only fails in some environments, we have to introduce a new
uABI flag for userspace to request the 2x32 bit accurate read of the
timestamp.
v2: Fix alignment check and include details of the workaround for
userspace.
Reported-by: Karol Herbst <freedesktop@karolherbst.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317
Testcase: igt/gem_reg_read
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Tested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Golden batch carries 3D state at the beginning so that HW starts with
a known state. It is carried as a binary blob which is auto-generated from
source. The idea was it would be easier to maintain and keep the complexity
out of the kernel which makes sense as we don't really touch it. However if
you really need to update it then you need to update generator source and
keep the binary blob in sync with it.
There is a need to patch this in bxt to send one additional command to enable
a feature. A solution was to patch the binary data with some additional
data structures (included as part of auto-generator source) but it was
unnecessarily complicated.
Chris suggested the idea of having a secondary batch and execute two batch
buffers. It has clear advantages as we needn't touch the base golden batch,
can customize secondary/auxiliary batch depending on Gen and can be carried
in the driver with no dependencies.
This patch adds support for this auxiliary batch which is inserted at the
end of golden batch and is completely independent from it. Thanks to Mika
for the preliminary review.
v2: Strictly conform to the batch size requirements to cover Gen2 and
add comments to clarify overflow check in macro (Chris, Mika).
v3: aux_batch_offset was declared as u64, change it to u32 (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Armin Reese <armin.c.reese@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Kunmap the renderstate page on error path.
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in case pwm_get fails
- in case pwm_config error return error cdoe from pwm_config
- Cleanup pwm in intel_panel_destroy_backlight
v4: Removed unused #defines and initialized backlight with INVALID_PIPE (Ville)
CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.
v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code (Ville)
v4: Moved PWM vs SoC backlight #defines to intel_bios.h (Jani)
CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_guc_fwif.h contains the subset of the GuC interface that we
will need for submission of commands through the GuC. These MUST
be kept in sync with the definitions used by the GuC firmware, and
updates to this file will (or should) be autogenerated from the
source files used to build the firmware. Editing this file is
therefore not recommended.
i915_guc_reg.h contains definitions of GuC-related hardware:
registers, bitmasks, etc. These should match the BSpec.
v2:
Files renamed & resliced per review comments by Chris Wilson
v4:
Added DON'T-EDIT-ME warning [Tom O'Rourke]
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Two new module parameters: "enable_guc_submission" which will turn
on submission of batchbuffers via the GuC (when implemented), and
"guc_log_level" which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai <yu.dai@intel.com>
v4:
Mark "enable_guc_submission" unsafe [Daniel Vetter]
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(), originally by Alex Dai
v2:
Change of function: now allocates & fills a new object, rather than
writing to an existing object
New name courtesy of Chris Wilson
Explicit domain-setting and other improvements per review comments
by Chris Wilson & Daniel Vetter
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_vblank_on() now warns on nested use or if vblank is not properly
initialized. This patch fixes Atmel HLCDC vblank initial state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
This reverts commit 6adfb1ef10.
Ironlake RPS code runs under an irqsave spinlock and hence sleeping
isn't allowed. Not a this long delay while blocking irqs isn't great
at all, but fixing the locking scheme is a lot more involved.
So just revert for now.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: kernel test robot <ying.huang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This patch makes use of the new amd headers (that are part of the new
amdgpu driver), instead of private defines.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
The MAP_QUEUES packet length for Carrizo is different than for Kaveri.
Therefore, we now need to calculate the runlist length with regard to the
underlying H/W.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch adds support for the VI APU in the DQM module.
Most of the functionality of DQM is shared between CI and VI. Therefore,
only a handful of functions are required to be in the
H/W-specific part of DQM.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch implements all the VI MQD manager functions.
This is done in a different file as the MQD format is different
between CI and VI
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch adds the PCI IDs of supported CZ devices to the
supported_devices structure in amdkfd. That structure is used during the
amdkfd probing stage, to check if the currently probed device is eligible
to be handled by amdkfd.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch adds the gfx8 interface file between amdgpu and amdkfd. This
interface file is currently in use when running on a Carrizo-based
system.
The interface itself is represented by a pointer to struct
kfd_dev. The pointer is located inside amdgpu_device structure.
All the register accesses that amdkfd need are done using this
interface. This allows us to avoid direct register accesses in
amdkfd proper, while also allows us to avoid locking between
amdkfd and amdgpu.
The single exception is the doorbells that are used in both of
the drivers. However, because they are located in separate pci
bar pages, the danger of sharing registers between the drivers
is minimal.
Having said that, we are planning to move the doorbells as well
to amdgpu.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch adds the gfx7 interface file between amdgpu and amdkfd. This
interface file mirrors (some) of the functions in radeon_kfd.c
(the interface file between radeon and amdkfd).
The gfx7 interface is used when it is run on a Kaveri-based system.
This interface file was used for bring-up of amdkfd on amdgpu and for
debugging purposes. For users who would like to run HSA on Kaveri, please
use the radeon graphic driver.
Note: CONFIG_DRM_AMDGPU_CIK must be selected for amdgpu to handle Kaveri.
v2: removed MTYPE_NONCACHED enum definition as it is defined in another
patch
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch adds an interface file between amdgpu and amdkfd. This
interface file is H/W agnostic, thus containing functions that
operate the same for any AMD APU/GPU H/W generation.
The functions in this interface mirror (some) of the functions in
radeon_kfd.c (the radeon<-->amdkfd interface file). The main functions
are:
- amdgpu_amdkfd_init - initialize the amdkfd module
- amdgpu_amdkfd_load_interface - load the H/W interface according to the
currently probed device
- amdgpu_amdkfd_device_probe - probe the device in amdkfd
- amdgpu_amdkfd_device_init - initialize the device in amdkfd
- amdgpu_amdkfd_interrupt - call the ISR of amdkfd
- amdgpu_amdkfd_suspend - suspend callback from amdgpu
- amdgpu_amdkfd_resume - resume callback from amdgpu
This patch also modifies the relevant amdgpu files, to use this new
interface.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
This patch splits the KGD_ENGINE_SDMA to KGD_ENGINE_SDMA1 and
KGD_ENGINE_SDMA2 to match CZ definitions.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
minimize those wait until pool grow beyond batch size before
draining the pool.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-and-Tested-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Current code never allowed the page pool to actualy fill in anyway.
This fix it, so that we only start freeing page from the pool when
we go over the pool size.
Changed since v1:
- Move the page batching optimization to its separate patch.
Changed since v2:
- Do not remove code part of the batching optimization with
this patch.
- Better commit message.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Time to light a candle and remove the preliminary_hw_support flag.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
on SKL/BXT, the top most plane hardware is shared between the legacy
cursor registers and an actual plane. Daniel and Ville don't want to
expose 2 DRM planes and would rather expose a CURSOR plane that has all
the usual plane properties, and that's a blocker for lifting the
prelimary_hw_support flag.
Unfortunately noone has had the time to finish this yet, but lifting the
prelimary_hw_support flag is long overdue. As an intermediate solution
we can merely not expose the top most plane
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix divide by zero if we end up updating the watermarks
with zero dotclock.
This is a stop gap measure to allow module load in cases
where our state keeping fails.
v2: WARN_ON added (Paulo)
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-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>
ttm_bo_validate() returns 0 or error. So we can return the value
directly and remove the variable 'ret'.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These variables were assigned some values but they were never used.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These patches fix the parallel-display driver to use the standard OF
graph bindings for connecting a drm_panel via device tree instead of
an undocumented, driver specific device tree property, take care to
disable all IPU interrupts before setting up the irq chip to fix a
kexec lockup, and fix VGA output on i.MX53-QSB boards by correcting
the media bus format set by the imx-tve driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVpLBMAAoJEFDCiBxwnmDrlw4P+wXO1F70lPLc9/XadcNVQnZn
smKhchEFLQNcYOZIwV2r0Y5v8TDtY/qhb/212kYUrrWgYqK8ASmgadGxp43ROAqa
VWF3UaNtPCg6BOjInRzwVoVDAzFUi3AIsEdZN6YXOyNc//fJGHEut3PqayTCfqop
TD0R55If6volfRHyGmvDR5Tsdzx1SKPn8hKDvqVtLocu5FzptKS+/0imDlcYeeii
PIJ1bcBLWAJIPcIfRcq1oJ/NDR8ELM1YMYtmJJ+CoIWp0cN3rYK+35Ja4XUFvbYt
aPSUV85RcLyXRZmZlssmUeIbDN0zFGoEFMghY8er7KUS2gQKf/o5agMn3ffXhNF5
iW4a7dpdtDmf0O4vC3g8WwO2IvzjVWQkjLppYW+NUd3Hl8y1iNZo8OWhb8pq8RlM
bjNuaF+oLftFKKZ0HVoACpuLhga6sQN7XA1oUwIhzNhIDBNrdx2eJhvkMZfYsaUF
kxn/Kbtgu7gsbg8TfiABB2g7C8F92frHh1ucSLpm6GBUE2hK+fmkWusdFoiztSPq
fRi+zFqT9+Kf8anRzKu7mGxYoGxymduySNzX4Um5cmZ0BHguwPcitjTCALZwFVa4
bXl5ykPcQnTb0WI0Zc9ZAT1geUKifJpTvwJchA5U9htFiJfNSd6E0QMPyPYB0rz6
PFU1foBZa1dnus1FJFCJ
=pGBQ
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2015-07-14' of git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: fixes for parallel-display, imx-tve, and ipu-common
These patches fix the parallel-display driver to use the standard OF
graph bindings for connecting a drm_panel via device tree instead of
an undocumented, driver specific device tree property, take care to
disable all IPU interrupts before setting up the irq chip to fix a
kexec lockup, and fix VGA output on i.MX53-QSB boards by correcting
the media bus format set by the imx-tve driver.
* tag 'imx-drm-fixes-2015-07-14' of git://git.pengutronix.de/git/pza/linux:
drm/imx: tve: fix media bus format for VGA output
GPU: ipu: fix lockup caused by pending chained interrupts
drm/imx: parallel-display: fix drm_panel support
A range of fixes for the Armada DRM driver:
- A missing wakeup could result in overlay frames being delayed, causing
video playback to hiccup.
- Avoid unmapping a dma-buf attachment which was never mapped
- Fix the overlay when partially off the screen by switching to the
drm_plane_helper_check_update() helper and using the calculated
coordinates to set the start address.
- Remove an incorrect assignment to crtc->mode - which should be the
unadjusted mode.
- Fix a missing call to drm_plane_cleanup() in the overlay code.
* 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/armada: avoid saving the adjusted mode to crtc->mode
drm/armada: fix overlay when partially off-screen
drm/armada: convert overlay to use drm_plane_helper_check_update()
drm/armada: fix gem object free after failed prime import
drm/armada: fix incorrect overlay plane cleanup
drm/armada: fix missing overlay wake-up
Next batch of i915 fixes. Note that the compat32 patch here needs the drm
core one to be actually useful, I'll send you that one with a separate
drm-fixes pull request. One revert because a fix in -rc2 did break
existing userspace.
* tag 'drm-intel-fixes-2015-07-15' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.
Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"
drm/i915: Forward all core DRM ioctls to core compat handling
drm/i915: fix oops in primary_check_plane
drm/i915: remove unused has_dma_mapping flag
drm/i915: Fix missing return warning for !CONFIG_DEBUGFS
drm/i915: avoid leaking DMA mappings
drm/i915: Snapshot seqno of most recently submitted request.
drm/i915: Store device pointer in contexts for late tracepoint usafe
Ok next attempt at drm-fixes pull. Big thing really is just the compat32
one for addfb2.1.
* tag 'topic/drm-fixes-2015-07-16' of git://anongit.freedesktop.org/drm-intel:
drm: Provide compat ioctl for addfb2.1
Documentation: drm: Fix tablulation in KMS properties table
drm: add a check for x/y in drm_mode_setcrtc
drm/rockchip: use drm_gem_mmap helpers
Something (ATOM BIOS?) seems to be clobbering the LB_INTERRUPT_MASK
register while the CRTC is off, which caused e.g. glxgears or
gnome-shell to hang after a modeset.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
So the selected forced level shows up properly in sysfs.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is necessary to properly reset the min/max limits before
clamping them otherwise we may get improper clamping depending
on what what was the last forced level.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Always respect the harvest configuration as is.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If we run into a part with a harvest configuration where the entire
IP block is unusable, just disable the IP block.
v2: fix logic as noted by Christian
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Just to make sure userspace don't send nonsense to the kernel.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Port of amdgpu patch 9298e52f8b.
Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.
Fixes panic on powering off R7xx GPUs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Universal planes may not be assigned to the current crtc, so only
update crtc->x/y when the primary is part of the state and bound
to the current crtc.
Changes since v1:
- Add the crtc check.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This really doesn't seem to have much chance of working anymore,
esp for irq context, qxl at least tries to talk to the hw,
and waits for irqs, and fails.
with runtime pm and other stuff I think we should just
bail on this for now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're not supposed to store the adjusted mode into crtc->mode. We don't
use it anyway, so we can safely remove this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the start address calculation when overlay is partially off screen.
fb->bits_per_pixel is not set for YUV formats, and is always zero, which
led to the first component always starting at zero.
Use drm_format_plane_cpp() instead.
This also revealed a problem in that YUYV formats toggle the U/V data
for odd pixel start address offsets. We try to rectify that by
toggling the U/V swap, which for the most part works, but seemingly
introduces a flicker for one scan frame of swapped U/V.
However, these changes result in an overall improvement.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use drm_plane_helper_check_update() rather than our own code to validate
and limit the size of the displayed image. As we are able to support
scaling, permit the full scaling ability.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the gem object freeing after a partial import of a dma buffer,
eg, one which has been imported, but not mapped. This was provoking
a warning from the dma_buf code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Armada overlay plane wasn't being properly cleaned up as it was
missing a call to drm_plane_cleanup(). It also wasn't freeing the
right type of pointer (although we were still freeing the right
pointer value.)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Nothing was waking up the overlay plane wait queue, so we were fully
reliant on the HZ/25 wait timing out to make progress. Fix the lack
of wake-up.
We were also mis-handling the wait_event_timeout() return value - this
returns an unsigned integer of the remaining time, or zero on timeout
and the condition evaluated false. Checking this for less than zero
is not sane.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fastboot should only downgrade a modeset if we have a match, not be
used to upgrade to a full modeset. Otherwise we can only use it in a
very restricted way: Initial modeset when the request mode is the
preferred one of the panel and there's still a pfit active. And that
only works because our mode_from_pipe_config fills in the wrong mode
(it takes the adjusted mode, not the requested one).
But we want fast modesets everywhere even after boot-up (especially
for testing, but not only there). Hence we need to be able to make any
modeset a fast one, which means we need to invert the logic and
optionally downgrade a modeset.
Note that this needs ->connector_changed split out from ->mode_changed
otherwise it's not going to work (because we might loose a modeset
because connectors changed but otherwise the config matches). As soon
as that's merged we can drop the i915.fastboot check from this code.
Also make sure that we don't accidentally clear any_ms and that we add
the planes for any kind of modeset.
Finally rename fastboot to fastset (yeah it's a silly name) since this
really isn't about booting all that much.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we both set mode->private_flags to some value and also use
the pipe_config quirk. But since the pipe_config quirk isn't tied to
the lifetime of the mode object we need to check both.
Simplify this by only using mode.private_flags and stop using the
INHERITED_MODE quirk. Also for clarity add an explicit #define for
that driver priavete mode flag.
By using crtc_state->mode_changed we can also remove the recalc local
variable.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we recompute the pipe config for all CRTCs that have changed
we don't have problems with stale configuration data for the global
pfit and can remove this hack. Yay!
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge fixes since it's getting out of hand again with the massive
split due to atomic between -next and 4.2-rc. All the bugfixes in
4.2-rc are addressed already (by converting more towards atomic
instead of minimal duct-tape) so just always pick the version in next
for the conflicts in modeset code.
All the other conflicts are just adjacent lines changed.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_drv.h
drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This can only fail because of a bug in the code.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in follow-up to also remove start_vbl_count from
intel_crtc->atomic and put it into the intel_crtc directly - it's not
precomputed state.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We needed this originally for updating pagetables in plane commit
functions. But that's extracted into prepare/cleanup now. The other
issue was running updates when the pipe was off. That's also now
fixed.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Huzzah! \o/
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
v3: explain why part of the WA is in Per ctx batch (Mika)
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt
v2: address static checker warning where unsigned value was checked for
less than zero which is never true (Dan Carpenter).
v3: The WA uses default value of GEN8_L3SQCREG4 during flush but that disables
some other WA; update default value to retain it and document dependency (Mika).
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
v3: use updated macro.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Robert Beckett <robert.beckett@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch only enables support for Gen9, the actual WA will be
initialized in subsequent patches.
The WARN that we use to warn user if WA batch support is not available
for a particular Gen is replaced with DRM_ERROR as warning here doesn't
really add much value.
v2: include all infrastructure bits in this patch so that subsequent
changes only correspond the WA added (Chris)
v3: use updated macro.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fix following warnings.
Warning(.//drivers/gpu/drm/drm_irq.c:1279): No description
found for parameter drm_crtc'
Warning(.//drivers/gpu/drm/drm_irq.c:1279): Excess function
parameter 'crtc' description in 'drm_crtc_vblank_reset'
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was confused shortly whether the compat was needed for the int,
until I noticed the pointer in the original.
Also remove typedef.
v2: Review from Chris.
- Add comments.
- Also change the int param in the original structure.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Frame buffer modifiers extensions provided in;
commit e3eb3250d8
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Feb 5 14:41:52 2015 +0000
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem where 64-bit
members were added after the odd number of 32-bit ones. This
makes the compiler produce structures of different sizes under
32- and 64-bit x86 targets and makes the ioctl need explicit
compat handling.
v2: Removed the typedef. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: stable@vger.kernel.org
[danvet: Squash in compile fix from Mika.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes the breakage caused by
commit eddfcbcdc2
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 15 12:33:53 2015 +0200
drm/i915: Update less state during modeset.
No need to repeatedly call update_watermarks, or update_fbc.
Down to a single call to update_watermarks in .crtc_enable
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add missing shared dpll disable to the noatomic disable function.
This function will be replaced by its atomic counterpart soon.
Changes since v1:
- intel_crtc->active and watermarks are fixed by a patch from
Patrik Jakobsson
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Updated the HAS_CORE_RING_FREQ macro to add the broxton check,
so as to disallow the programming & read of ring frequency
table for it.
Issue: VIZ-5144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added a new HAS_CORE_RING_FREQ macro, currently used in
gen6_update_ring_freq & i915_ring_freq_table debugfs function.
The programming & read of ring frequency table is needed for newer
GEN(>=6) platforms, except VLV/CHV.
Issue: VIZ-5144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Calculate all state using a normal transition, but afterwards fudge
crtc->state->active back to its old value. This should still allow
state restore in setup_hw_state to work properly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
Because this is not yet done atomically, assume a full modeset is
needed and force a modeset on the crtc.
Changes since v1:
- s/reset/force modeset/
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.
intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.
intel_display_setup_hw_state now only reads out the atomic state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Readout initial hw mode, v2.
Atomic requires a mode blob when crtc_state->enable is true, or
you get a huge warn_on.
With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so for now force a modeset the first time the mode blob's
updated.
This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.
Changes since v1:
- Add a description in intel_modeset_readout_hw_state of how the
recalculation is done.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is required to properly initialize vblanks on the active crtc.
Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
crtc 0: Noop due to uninitialized mode.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property.
If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.
v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: Peter Antoine <peter.antoine@intel.com>
v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
tables. Prefix L3-specific defines consistently with L3_ and
e/LLC-specific defines with LE_ to avoid this kind of confusion in
the future.
- Change L3CC WT define back to RESERVED (matches my hardware
documentation and the original patch, probably a misunderstanding
of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
(Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
Wilson).
- Add comment about undefined entries being implicitly set to uncached
for forwards compatibility.
v9 (Francisco Jerez):
- Minor style fixes.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totatlly forgotten that we have these when nuking all the UMS code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.
Changes since v1:
- Remove unrelated changes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The src and crtc rectangles were never set, resulting in the primary
plane being made invisible on first atomic update.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.
Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.
Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.
Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
- Add adjust parameter to intel_compare_link_m_n, which is
used to adjust m2_n2 if it's a multiple of m_n.
- Add exact parameter intel_compare_m_n.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.
The size can be found in the fb, no need for the plane_config.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.
This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc->config pointer, resulting in hard
to find bugs.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 19ee835cdb.
It breaks existing old userspace which doesn't handle UNKNOWN
swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
still is on some other platforms, but it still pretty clearly broke
the testers machine. If we want this we need to extend the ioctl with
new paramters that only new userspace looks at.
Cc: Harald Arnesen <harald@skogtun.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Harald Arnesen <harald@skogtun.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Doesn't really add anything which can't be figured out through
proc files. And more clearly separates the new gem mmap handling
code from the old drm maps mmap handling code, which is surely a
good thing.
Cc: Martin Peres <martin.peres@free.fr>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ring frequency table programming is not required on BXT. Added separate
checks to enable the programming only for SKL & skip for BXT.
v2: Removed the BXT check from gen6_update_ring_freq function
Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
forwarded, but the drm.h header suggests (and reality confirms) ones
after (and including) DRM_COMMAND_END should be forwarded as well.
We need this to correctly forward the compat ioctl for the botched-up
addfb2.1 extension.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: stable@vger.kernel.org # 4.1+
[danvet: Explain why this is suddenly needed and add cc: stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
> > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
>
> Ugh. Please enable KALLSYMS to get sane symbols.
>
> But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
> so it's pretty clearly just that change frm
>
> - if (intel_crtc->active) {
> + if (crtc_state->base.active) {
>
> and "crtc_state" is NULL.
>
> And the code very much knows that crtc_state can be NULL, since it's
> initialized with
>
> crtc_state = state->base.state ?
> intel_atomic_get_crtc_state(state->base.state,
> intel_crtc) : NULL;
>
> Tssk. Daniel? Should I just revert that commit dec4f799d0
> ("drm/i915: Use crtc_state->active in primary check_plane func") for
> now, or is there a better fix? Like just checking crtc_state for NULL?
Indeed embarrassing. I've missed that we still have 1 caller left that's
using the transitional helpers, and those don't fill out
plane_state->state backpointers to the global atomic update since there is
no global atomic update for transitional helpers. Below diff should fix
this - we need to preferentially check crts_state->active and if that's
not set intel_crtc->active should yield the right result for the one
remaining caller (it's in the crtc_disable paths).
This fixes a regression introduced in
commit dec4f799d0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 7 11:15:47 2015 +0200
drm/i915: Use crtc_state->active in primary check_plane func
which was quickly reverted in
commit 01e2d0627a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Jul 12 15:00:20 2015 -0700
Revert "drm/i915: Use crtc_state->active in primary check_plane func"
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Yeah this isn't really fixes but it's a nice cleanup to
clarify the code but not really worth the hassle of backmerging. So
just add to -fixes, we're still early in -rc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This broken code was introduced in
commit aa7471d228
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 1 11:15:21 2015 +0300
drm/i915: add i915 specific connector debugfs file for DPCD
v2: Drop hunk that accidentally crept in.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: François Valenduc <francoisvalenduc@gmail.com>
Reported-by: François Valenduc <francoisvalenduc@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects
For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the
corresponding backing pages and so in practice we create/release the
mapping in the object's get_pages/put_pages callback.
For 3. the lifetime of the mapping matches that of any existing GPU binding
of the object, so we'll create the mapping when the object is bound to
the first vma and release the mapping when the object is unbound from its
last vma.
Since the object can be bound to multiple vmas, we can end up creating a
new DMA mapping in the 3. case even if the object already had one. This
is not allowed by the DMA API and can lead to leaked mapping data and
IOMMU memory space starvation in certain cases. For example HW IOMMU
drivers (intel_iommu) allocate a new range from their memory space
whenever a mapping is created, silently overriding a pre-existing
mapping.
Fix this by moving the creation/removal of DMA mappings to the object's
get_pages/put_pages callbacks. These callbacks already check for and do
an early return in case of any nested calls. This way objects of the 3.
case also become more like the other object types.
I noticed this issue by enabling DMA debugging, which got disabled after
a while due to its internal mapping tables getting full. It also reported
errors in connection to random other drivers that did a DMA mapping for
an address that was previously mapped by i915 but was never released.
Besides these diagnostic messages and the memory space starvation
problem for IOMMUs, I'm not aware of this causing a real issue.
The fix is based on a patch from Chris.
v2:
- move the DMA mapping create/remove calls to the get_pages/put_pages
callbacks instead of adding new callbacks for these (Chris)
v3:
- also fix the get_page cache logic on the userptr async path (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.
One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.
This fixes a regression introduced in
commit 44cdd6d219
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Mon Nov 24 18:49:40 2014 +0000
drm/i915: Convert 'ring_idle()' to use requests not seqnos
v2 (Chris Wilson):
- Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather
than compute it over again.
- Remove extra whitespace.
Issue: VIZ-5998
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regressing commit citation provided by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Watermark calculations depend on the intel_crtc->active flag to be set
properly. Suspend/resume is broken on SKL and we also get DDB mismatches
without this patch.
The regression was introduced in:
commit eddfcbcdc2
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 15 12:33:53 2015 +0200
drm/i915: Update less state during modeset.
No need to repeatedly call update_watermarks, or update_fbc.
Down to a single call to update_watermarks in .crtc_enable
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Don't touch disable_shared_dpll()
Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91203
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we update the freq before masking the interrupts, which can
allow new interrupts to occur before the frequency has changed. These
extra interrupts might waste some cpu cycles. This patch corrects
this by masking interrupts prior to updating the frequency.
Note from Chris:
"Well it won't waste CPU cycles as the interrupt is also masked by the
threshold limits, but there should be no harm at all in reordering the
patch so, and it does make a certain amount of sense."
Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Praveen Paneri <praveen.paneri@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note from Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Update the hotplug documentation to explain that hotplug storm
is not expected for Display port panels and hence is not handled
in current code.
v2: update the statements as recommended by Daniel
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit e62925567c
Author: Vandana Kannan <vandana.kannan@intel.com>
Date: Wed Jul 1 17:02:57 2015 +0530
drm/i915/bxt: BUNs related to port PLL
BXT DPLL can now generate frequencies in the 216-223 MHz range.
Adjust the HDMI port clock checks to account for the reduced range
of invalid frequencies.
Cc: Vandana Kannan <vandana.kannan@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
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>
We do the exact same steps around the disp2d/pipe A power well
enable/disable on VLV and CHV. Refactor the shared code into
some helpers.
Note that this means we now call vlv_power_sequencer_reset() before
turning off the power well, whereas before we did it after. That
doesn't matter though since vlv_power_sequencer_reset() just resets
the power sequencer software tracking and doesn't touch the hardware
at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pipe A power well is the "disp2d" well on CHV and pipe B and C wells
don't even exist. Thereforce we can remove the checks for pipe A vs.
others and just assume it's always pipe A.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep things
as similar as possible between them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Updated the i915_ring_freq_table debugfs function to support the read
of ring frequency table, through Punit interface, for SKL also.
Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ring frequency table programming changes for SKL. No need for a
floor on ring frequency, as the issue of performance impact with
ring running below DDR frequency, is believed to be fixed on SKL
v2: Removed the check for avoiding ring frequency programming for BXT (Rodrigo)
Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Read the efficient frequency (aka RPe) value through the the mailbox
command (0x1A) from the pcode, as done on Haswell and Broadwell.
The turbo minimum frequency softlimit is not revised as per the
efficient frequency value.
v2: Replaced the conditional expression operator with 'if' statement (Tom)
v3: Corrected the derivation of efficient frequency & shifted the
GEN9_FREQ_SCALER multiplications downwards (Ville)
Issue: VIZ-5143
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
hardware cursor windows only have some fixed size, and not support
width virtual, when move hardware cursor windows outside of left,
the display would be wrong, so this window can't for cursor now.
And Tag hardware cursor window as a overlay is wrong, will make
userspace wrong behaviour.
So just remove the hardware cursor window
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Window 1 support scale and yuv format, it's waste use it for a
cursor, use window 3 is enough.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
routines.
Once the core functions return successfully, the rockchip mmap routines
can still use dma_mmap_attrs() to simply mmap the entire buffer.
[0] Previously, we were performing the mmap() without first taking a
reference on the underlying gem buffer. This could leak ptes if the gem
object is destroyed while userspace is still holding the mapping.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Add a check for the presence of fb_helper to rockchip_drm_output_poll_changed()
to only call drm_fb_helper_hotplug_event if there is actually a fb_helper
available. Without this check I see NULL pointer dereferences when the
hdmi hotplug irq fires before the fb_helper got initialized.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
VOP can support BGR formats in all windows thanks to red/blue swap option
provided in WINx_CTRL0 registers. This patch enables support for
ABGR8888, XBGR8888, BGR888 and BGR565 formats by using this feature.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
This reverts commit dec4f799d0.
Jörg Otte reports a NULL pointder dereference due to this commit, as
'crtc_state' very much can be NULL:
crtc_state = state->base.state ?
intel_atomic_get_crtc_state(state->base.state, intel_crtc) : NULL;
So the change to test 'crtc_state->base.active' cannot possibly be
correct as-is.
There may be some other minimal fix (like just checking crtc_state for
NULL), but I'm just reverting it now for the rc2 release, and people
like Daniel Vetter who actually know this code will figure out what the
right solution is in the longer term.
Reported-and-bisected-by: Jörg Otte <jrg.otte@gmail.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit a7c6e76fee ("drm/imx: switch to use media bus formats") accidentally
replaced IPU_PIX_FMT_GBR24 with MEDIA_BUS_FMT_YUV8_1X24 instead of the correct
MEDIA_BUS_FMT_GBR888_1X24. This patch is needed to fix VGA output in i.MX53.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Even with the oops fixed by a previous patch, the system still fails to
kexec, due to a stuck chained interrupt locking the system. We must
disable the child interrupts prior to setting up the irq chip to ensure
we don't get stuck here.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The parallel-display driver used an undocumented, non-standard property
"fsl,panel" to optionally associate with a drm_panel device. This patch
fixes the driver to use the same OF graph bindings as the LDB driver
instead:
parallel-display {
compatible = "fsl,imx-parallel-display";
...
port@1 {
reg = <1>;
parallel_out: endpoint {
remote_endpoint = <&panel_in>;
};
};
};
panel {
...
port {
panel_in: endpoint {
remote-endpoint = <¶llel_out>;
};
};
};
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Gary Bisson <gary.bisson@boundarydevices.com>
Small fixes for omapdrm, including:
* Fix packed 24 bit color formats
* Ensure the planes are inside the crtc
* Handle out-of-dma-memory error
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVlkYTAAoJEPo9qoy8lh710vwQAJ6UlpVR9Yo1YjywKbFw3GrM
NAhtBxpUkM13QIpWIq7dzEtSzOU90KC7rCPmlxCLSE8zDKUWDbBexja1gdpe43n4
I2HViKQI/GMtph4OkolPVWn3tiIQJp8JAqQsBpZkiJpLvRQZC/SKSm42ZkuqPwMX
4+gq3c82ZCnA86BrXeVkxIGit+J2Jzf+dqb5F/4g+sVu+XjpsHIyHv5wCXBetTkW
HiCIlej0FaROQMDqnYOE+M8InpFuA4Wc9JGPgUGRH/RQKnBocaOsdp/i98iAyBPD
rqjFJYMMt+TOE9/I6NFZ+GyAFSV3M5WT+bc7KUmj7RgCXNHBxxGBzWC3SH56Zk3o
ipDsjyLyZksLyMvrVG9dPjMCcU3rm7JOYeodQa9Y3Hc6Em3Wc7UwWXg9JoPLJXRN
0UayZYSQJsP2/mBF+1eNsiNgDNz1AyRwB4qPb7jEgwCti6kbGv4AMTiwX+BbIJpm
989UaRBze07GAbjiO0UVjydegNKf6Vp8J3B8+GnGHBQWnFIyB3a6bGmdBSeubjsg
uPcsC/r8f2RTkOpyf6Mk3pCpkyi+S8hQvUchaPqdgjl37o/xRl2tq9mo3szRASDV
HvxYh1eqnM1YIgDrDfO/FJtNqQlVULlg0HQO1Tu+wwOMOC9rAuSHSvBXDKVLN7KU
8kS017e4KRPXlGHDAL6q
=mgUq
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes
omapdrm fixes for 4.2
Small fixes for omapdrm, including:
* Fix packed 24 bit color formats
* Ensure the planes are inside the crtc
* Handle out-of-dma-memory error
* tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN
drm/omap: fix align_pitch() for 24 bits per pixel
drm/omap: fix omap_gem_put_paddr() error handling
drm/omap: fix omap_framebuffer_unpin() error handling
drm/omap: increase DMM transaction timeout
drm/omap: check that plane is inside crtc
drm/omap: return error if dma_alloc_writecombine fails
Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd
kind of WARNING Linus's been seeing, please ask him to scream if that's
not the case.
* tag 'drm-intel-fixes-2015-07-09' of git://anongit.freedesktop.org/drm-intel:
Revert "drm/i915: Allocate context objects from stolen"
drm/i915: Declare the swizzling unknown for L-shaped configurations
drm/i915: Use crtc_state->active in primary check_plane func
drm/i915: Check crtc->active in intel_crtc_disable_planes
drm/i915: Restore all GGTT VMAs on resume
drm/i915/chv: fix HW readout of the port PLL fractional divider
A single fix so far for 4.2:
- checking a pointer is not null before using it
* tag 'drm-amdkfd-fixes-2015-07-09' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: validate pdd where it acquired first
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also add the invalidate hack here while we don't have
a reliable dirty fbdev op.
v2: As pointed by Paulo: removed seg fault risk, used fb_helper
when possible and put brackets on if.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_fbcon_fbt/psr
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in
commit 031b698a77
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jun 26 19:35:16 2015 +0200
drm/i915: Unconditionally do fb tracking invalidate in set_domain
Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.
Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.
So this patch fixes this issue.
v2: Make invalidate directly and unconditionally and
fix commit message indicating the set_domain fix
as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Idle frames the number of identical frames needed
before panel can enter PSR.
There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and VBT isn't being
set at all.
Let's trust VBT when it is set + 1 and use minimum of 4 + 1
when VBT isn't set. "+1" covers the "of-by-one" case.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.
Apparently audio driver is tying power well management
and runtime PM for some reason. But with audio runtime
PM working or with audio completely out of picture
we should remove this mask, otherwise we have a high
risk of miss screen updates as faced by Matthew.
WARNING: With this patch if snd_intel_hda driver is
running and not releasing power well properly PSR will
constant Exit and Performance Counter will be 0.
But the best thing of this patch is that with one more
HW tracking working the risks of missed blank screen
are minimized at most.
This affects just core platforms where PSR exit are also
helped by HW tracking: Haswell, Broadwell and Skylake
for now.
v2: Fix commit message explanation. It has nothing to do
with runtime PM on i915 as previously advertised.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported by the kbuild test robot.
Regression introduced by:
commit fdbff9282c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jun 18 11:23:24 2015 +0200
drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported by the kbuild test robot.
Regression introduced by:
commit de152b627e
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Tue Jul 7 16:28:51 2015 -0700
drm/i915: Add origin to frontbuffer tracking flush
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cayman does not have vce. There were a few places in the
shared cayman/TV code where we were trying to do vce stuff.
v2: remove -ENOENT check
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise we try to clear BO_VAs without an address.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91141
Signed-off-by: Christian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to allways add the VM clear duplicate of the BO_VA,
no matter what the old status was.
Signed-off-by: Christian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.
[Michel Dänzer: Add pinning BOs on resume]
v2:
[Alex Deucher: merge cursor unpin into fb unpin loop]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.
This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Cc: stable@vger.kernel.org
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.
This patch solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like Plymouth.
Previously PSR was being invalidated by fbdev and Plymounth
was taking control with PSR yet invalidated and could get screen
updates normally. However with some atomic modeset changes
Pymouth modeset over ioctl was now causing frontbuffer flushes
making PSR gets back to work while it cannot track the
screen updates and exit properly.
By adding this flush on dirtyfb we properly track frontbuffer
writes and properly exit PSR.
Actually all mmap_wc users should call this dirty callback
in order to have a proper frontbuffer tracking.
In the future it can be extended to return 0 if the whole
screen has being flushed or the number of rects flushed
as Chris suggested.
v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
callback is just called after few screen updates and not on
everyone as pointed by Daniel.
v3: Use flush instead of invalidate since flush means
invalidate + flush and dirty means drawn had finished and
it can be flushed.
v4: Remove PSR from subject since it is purely frontbuffer tracking
change and that can be useful for FBC as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix alignment as spotted by Paulo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracking like when flush has been originated by a flip.
Also flip had just invalidated it already.
It also uses origin to minimize the a bit the amount of
disable/enabled, mainly when flip already had invalidated.
With this patch in place it is possible to do a flush on dirty areas
properly in a following patch.
v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently pdd is validate after dereferencing it, which is
not correct, Thus validate pdd before its first use.
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Stolen gets trashed during hibernation, so storing contexts there
is not a very good idea. On my IVB machines this leads to a totally
dead GPU on resume. A reboot is required to resurrect it. So let's
not store contexts where they will get trampled.
This reverts commit 149c86e74f.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
