Broken since "gr: convert user classes to new-style nvkm_object"
Tested on a PPC64 G5 + NV34
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
bunch of drm fixes.
* tag 'topic/drm-fixes-2015-09-09' of git://anongit.freedesktop.org/drm-intel:
drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus speed
drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed
drm/dp: Define AUX_RETRY_INTERVAL as 500 us
drm/atomic: Fix bookkeeping with TEST_ONLY, v3.
Fixes headed for v4.3-rc1, including Maarten's DP MST state checker fix
you requested.
* tag 'drm-intel-next-fixes-2015-09-10' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Allow DSI dual link to be configured on any pipe
drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS
drm/i915: Fix CSR MMIO address check
drm/i915: Limit the number of loops for reading a split 64bit register
drm/i915: Fix broken mst get_hw_state.
drm/i915: Pass hpd_status_i915[] to intel_get_hpd_pins() in pre-g4x
uapi/drm/i915_drm.h: fix userspace compilation.
drm/i915: Always mark the object as dirty when used by the GPU
Due to some recent changes in
drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
were not being pruned properly. In current kernels,
drm_mode_validate_basic() is called to sanity-check each mode in the
list. If the sanity-check passes, the mode's status gets set to to
MODE_OK. In older kernels this check was not done, so old custom modes
would still have a status of MODE_UNVERIFIED at this point, and would
therefore be pruned later in the function.
As a result of this new behavior, the list of modes for a device always
includes every custom mode ever configured for the device, with the
largest one listed first. Since desktop environments usually choose the
first preferred mode when a hotplug event is emitted, this had the
result of making it very difficult for the user to reduce the size of
the display.
The qxl driver did implement the mode_valid connector function, but it
was empty. In order to restore the old behavior where old custom modes
are pruned, we implement a proper mode_valid function for the qxl
driver. This function now checks each mode against the last configured
custom mode and the list of standard modes. If the mode doesn't match
any of these, its status is set to MODE_BAD so that it will be pruned as
expected.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
With two exceptions (drm/qxl and drm/radeon) all vm_operations_struct
structs should be constant.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Comment disagrees with the code which has changed a lot since
it was documented.
Note that the logic to remove -EIO handling was dropped in
commit 1488fc08c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 24 15:47:31 2012 +0100
drm/i915: Remove the deferred-free list
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In async mode crtc->config can be updated after the locks are released,
resulting in the wrong state being duplicated.
Note that this also removes a spurious assignment of crtc_state->crtc
introduced in
commit f0c60574eb
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:12:58 2015 +0300
drm/i915: Call drm helpers when duplicating crtc and plane states
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the conversion to atomic this cannot happen any more.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unfortunately fbc still depends on legacy primary state, so
it can't be killed off completely yet.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function was still using the legacy state, convert it to atomic.
While we're at it, fix the FIXME too and disable the primary plane.
v2 (Daniel):
- Add FIXME explaining that update_primary_planes should soon get
removed anyway.
- Don't call ->disable_plane since we can't disable the primary plane
with a CS flip (noticed by Ville).
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Legacy state might not be updated any more.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like single link MIPI panels, similarly for dual link panels, pipe
to be configured is based on the DVO port from VBT Block 2. In hardware,
Port A is mapped with Pipe A and Port C is mapped with Pipe B.
This issue got introduced in -
commit 7e9804fdcf
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Jan 16 14:27:23 2015 +0200
drm/i915/dsi: add drm mipi dsi host support
Cc: stable@vger.kernel.org # v4.0
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If one disables DDR DVFS in the BIOS, Punit will apparently ignores
all DDR DVFS request. Currently we assume that DDR DVFS is always
operational, which leads to errors in dmesg when the DDR DVFS requests
time out.
Fix the problem by gently prodding Punit during driver load to find out
whether it will respond to DDR DVFS requests. If the request times out,
we assume that DDR DVFS has been permanenly disabled in the BIOS and
no longer perster the Punit about it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91629
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix a wrong logical AND (&&) used for the range check of CSR MMIO.
Spotted nicely by gcc -Wlogical-op flag:
drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’:
drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]
Fixes: eb805623d8 ('drm/i915/skl: Add support to load SKL CSR firmware.')
Cc: <stable@vger.kernel.org> # v4.2
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This may cause issues because encoders are already destroyed so removing
active primaries may use freed memory. Instead free the fb directly,
ignoring refcount.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Right now, drm_sysfs_create() returns the newly allocated "struct class"
to the caller (which is drm_core_init()), which then has to set the
global variable 'drm_class'. During cleanup, though, we call
drm_sysfs_destroy() which implicitly uses the global 'drm_class'. This is
confusing, as ownership of the global 'drm_class' is non-obvious.
This patch changes drm_sysfs_create() to drm_sysfs_init() and makes it
initialize the 'drm_class' object directly, rather than returning it.
This way, both drm_sysfs_init() and drm_sysfs_destroy() work in a similar
fashion and manage the global drm class.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simplify `foo == NULL || IS_ERR(foo)` via IS_ERR_OR_NULL(). This is
pretty commonly used all over the kernel, especially for debugfs/sysfs
cleanup paths.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_av_sync_delay() doesn't change the passed in mode, so make it const.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_select_eld() doesn't look at the passed in mode, so don't pass it
in.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
valid_inferred_mode() don't change the modes over which it iterates,
so make the iterator const.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
reads. Due to the nature of the registers we try to read in this manner,
they may increment between the two instruction (e.g. a timestamp
counter). To keep the result accurate, we repeat the read if we detect
an overflow (i.e. the upper value varies). However, some hardware is just
plain flaky and may endless loop as the the upper 32bits are not stable.
Just give up after a couple of tries and report whatever we read last.
v2: Use the most recent values when erring out on an unstable register.
Reported-by: russianneuromancer@ya.ru
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.
v2: Don't assume DP_AUX_I2C_WRITE is 0 even though it is, to make the
code more obvious to the casual reader (Jani)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict due to changed context.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c write is enough.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to treat this the same as
a normal i2c write.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
spec.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This function can be used to duplicate an atomic state object. This is
useful for example to implement suspend/resume, where the state before
suspend can be saved and restored upon resume.
v2: move locking to caller, be more explicit about prerequisites
v3: explicitly pass lock acquisition context, improve kerneldoc
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Requested by Laurent.
Note that this uses the new markdown support which will only land in
kernel 4.4 (for the code snippet).
v2: A few spelling fixes I spotted myself.
v3: Big reword for commit_planes() kerneldoc based on a text from
Laurent.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com> (v1 on irc)
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
connector->encoder is initialized as NULL. Fix this by setting it in
during pre enable. MST connectors are not read out during initial hw
readout, and have no fixed encoder mappings. So it's harmless to
return false when the connector has never been assigned to an encoder.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.
Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set this to
true.
v2: Check for NULL state->crtc before chasing the pointer. Also check
both old and new crtc if there's a switch. Finally just outright
disallow switching crtcs for a plane if the plane is in active use, on
most hardware that doesn't make sense.
v3: Since commit_planes(active_only = true) is for enabling things
only after all the crtc are on we should only look at the new crtc to
decide whether to call the plane hooks - if the current CRTC isn't on
then skip. If the old crtc (when moving a plane) went down then the
plane should have been disabled as part of the pipe shutdown work
already. For which there's currently no helper really unfortunately.
Also move the check for wether a plane gets a new CRTC assigned while
still in active use out of this patch.
v4: Rebase over exynos changes.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This removes the need to separately track fb changes i915.
That will be done as a separate commit, however.
Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
into account.
Changes since v2:
- Split out i915 changes to a separate commit.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[danvet: Squash in msm fixup from Maarten.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will make sure we get a lockdep spat in all cases
even if the context is a complete garbage pointer.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make generic_edid_names[] const since it's supposed to be immutable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow comma separated filenames in the edid_firmware parameter.
For example:
edid_firmware=eDP-1:edid/1280x480.bin,DP-2:edid/1920x1080.bin
v2: Use strsep() to simplify parsing of comma seperated string. (Matt)
Move initial bail before strdup. (Matt)
v3: Changed conditionals after while loop to make more readable (Jani)
Updated kernel-parameters.txt to reflect changes (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
[danvet: Flatten else control flow and appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.
I've put this into the core since right now no helper or driver copes
with it, no userspace has code for it and no one asks for it. Yes
there's piles of corner-cases where this would be possible to do this
like:
- switch from inactive crtc to active crtc
- switch from active crtc to inactive crtc
- genlocked display
- invisible plane (to do whatever)
- idle plane hw due to dsi cmd mode/psr
- whatever
but looking at details it's not that easy to implement this correctly.
Hence just put it into the core and add a comment, since the only
userspace we have right now for atomic (weston) doesn't want to use
direct plane switching either.
v2: don't bother with complexity and just outright disallow plane
switching without the intermediate OFF state. Simplifies drivers, we
don't have any hw that could do it anyway and current atomic userspace
(weston) works like this already anyway.
v3: Bikeshed function name (Ville) and add comment (Rob).
v4: Also bikeshed commit message (Rob).
v5: Fix compile warnings reported by 0-day.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Faster than recompiling.
Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are used by drivers to release fbdev emulation
buffers. We need to make them resilient to NULL pointers to
make the fbdev compile/runtime knobs not cause Oopses on module
unload.
Cc: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using bool and returning true upon error is very uncommon. Also an int
return value is actually what all the callers which did check it seem
to have expected.
v2: Restore hunk misplaced in a rebase, spotted by Rob.
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Without the () the markup and more important hyperlinking wont happen.
v2: Also fix nearby type Laurent spotted.
v3: Actually git add. Argh!
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The adj_start calculation for DRM_MM_CREATE_TOP should happen after
mm->color_adjust. There was an inconsistency between
drm_mm_insert_helper_range
and drm_mm_insert_helper, as the later was already updating after
color_adjust.
Didn't spot it before, as color_adjust is only done in systems without
LLC. But I'm not aware of anybody using this test case yet.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Legacy s/r hooks are only used for shadow-attaching drivers, warn
when a KMS driver tries to use them.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fall back to VBT based backlight modulation frequency if it's not
set. Do not hard code.
This could be a problem if there is no VBT.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.
The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.
v2: Fix SPT and VLV. Thanks to Clint for the VLV code.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the difference between backlight control on HSW vs. BDW/SKL is
that on HSW we modify the duty cycle on the CPU register, and have the
hardware pass the changes on to the PCH registers. We still drive the
PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not
pass these messages on to the PCH. Therefore on BDW we need to enable
the PCH override bit, and program the PCH directly. (On SPT PCH, this
mode is the default.) We could as well do this on HSW too, and in fact
I've been told this is what a certain other operating system does. So
use PCH backlight override on HSW too.
This simplifies some follow-up code, but it does have the danger of
breaking backlight on HSW machines. It should work, but mysterious are
the ways of backlight.
While at it, name the related backlight hooks according to the PCH
rather than the CPU for clarity.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add stepping check for A0 workarounds, and remove the associated
FIXME tags.
Split out unrelated WAs for later condition checking.
v2: Fixed format (PeterL)
v3: Corrected stepping check for WaDisableSDEUnitClockGating
- Ignoring comment, following hardware spec instead. (ChrisH)
Added description for TILECTL setting (JonB)
Cc: Peter Lawthers <peter.lawthers@intel.com>
Cc: Chris Harris <chris.harris@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm updates from Dave Airlie:
"This is the main pull request for the drm for 4.3. Nouveau is
probably the biggest amount of changes in here, since it missed 4.2.
Highlights below, along with the usual bunch of fixes.
All stuff outside drm should have applicable acks.
Highlights:
- new drivers:
freescale dcu kms driver
- core:
more atomic fixes
disable some dri1 interfaces on kms drivers
drop fb panic handling, this was just getting more broken, as more locking was required.
new core fbdev Kconfig support - instead of each driver enable/disabling it
struct_mutex cleanups
- panel:
more new panels
cleanup Kconfig
- i915:
Skylake support enabled by default
legacy modesetting using atomic infrastructure
Skylake fixes
GEN9 workarounds
- amdgpu:
Fiji support
CGS support for amdgpu
Initial GPU scheduler - off by default
Lots of bug fixes and optimisations.
- radeon:
DP fixes
misc fixes
- amdkfd:
Add Carrizo support for amdkfd using amdgpu.
- nouveau:
long pending cleanup to complete driver,
fully bisectable which makes it larger,
perfmon work
more reclocking improvements
maxwell displayport fixes
- vmwgfx:
new DX device support, supports OpenGL 3.3
screen targets support
- mgag200:
G200eW support
G200e new revision support
- msm:
dragonboard 410c support, msm8x94 support, msm8x74v1 support
yuv format support
dma plane support
mdp5 rotation
initial hdcp
- sti:
atomic support
- exynos:
lots of cleanups
atomic modesetting/pageflipping support
render node support
- tegra:
tegra210 support (dc, dsi, dp/hdmi)
dpms with atomic modesetting support
- atmel:
support for 3 more atmel SoCs
new input formats, PRIME support.
- dwhdmi:
preparing to add audio support
- rockchip:
yuv plane support"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (1369 commits)
drm/amdgpu: rename gmc_v8_0_init_compute_vmid
drm/amdgpu: fix vce3 instance handling
drm/amdgpu: remove ib test for the second VCE Ring
drm/amdgpu: properly enable VM fault interrupts
drm/amdgpu: fix warning in scheduler
drm/amdgpu: fix buffer placement under memory pressure
drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
drm/amdgpu: fix typo in dce11 watermark setup
drm/amdgpu: fix typo in dce10 watermark setup
drm/amdgpu: use top down allocation for non-CPU accessible vram
drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
drm/amdgpu: set MEC doorbell range for Fiji
drm/amdgpu: implement burst NOP for SDMA
drm/amdgpu: add insert_nop ring func and default implementation
drm/amdgpu: add amdgpu_get_sdma_instance helper function
drm/amdgpu: add AMDGPU_MAX_SDMA_INSTANCES
drm/amdgpu: add burst_nop flag for sdma
drm/amdgpu: add count field for the SDMA NOP packet v2
drm/amdgpu: use PT for VM sync on unmap
drm/amdgpu: make wait_event uninterruptible in push_job
...
A few more fixes for amdgpu from the last few days:
- Fix several copy paste typos
- Resume from suspend fixes for VCE
- Fix the GPU scheduler warning in kfifo_out
- Re-enable GPUVM fault interrupts which were inadvertently disabled
- GPUVM page table hang fix when paging
* 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: rename gmc_v8_0_init_compute_vmid
drm/amdgpu: fix vce3 instance handling
drm/amdgpu: remove ib test for the second VCE Ring
drm/amdgpu: properly enable VM fault interrupts
drm/amdgpu: fix warning in scheduler
drm/amdgpu: fix buffer placement under memory pressure
drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
drm/amdgpu: fix typo in dce11 watermark setup
drm/amdgpu: fix typo in dce10 watermark setup
drm/amdgpu: use top down allocation for non-CPU accessible vram
drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
It should be gfx_v8_0_init_compute_vmid since it's
part of the gfx block.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to properly handle the instances for the idle
checks and soft reset.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
it seems the VCE ring 1 ib test not reliable, remove it for now.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-and-Reviewed-by: Sonny Jiang <sonny.jiang@amd.com>
There are little changes in core part, but lots of development are
found in drivers, especially ASoC. The diffstat shows regmap-
related changes for a slight API additions / changes, and that's all.
Looking at the code size statistics, the most significant addition
is for Intel Skylake. (Note that SKL support is still underway, the
codec driver is missing.) Also STI controller driver is a major
addition as well as a few new codec drivers.
In HD-audio side, there are fewer changes than the past. The
noticeable change is the support of ELD notification from i915
graphics driver. Thus this pull request carries a few changes in
drm/i915.
Other than that, USB-audio got a rewrite of runtime PM code. It
was initiated by lockdep warning, but resulted in a good cleanup in
the end.
Below are the highlights:
Common:
- Factoring out of AC'97 reset code from ASoC into the core helper
- A few regmap API extensions (in case it's not pulled yet)
ASoC:
- New drivers for Cirrus CS4349, GTM601, InvenSense ICS43432, Realtek
RT298 and ST STI controllers
- Machine drivers for Rockchip systems with MAX98090 and RT5645 and
RT5650
- Initial driver support for Intel Skylake devices
- Lots of rsnd cleanup and enhancements
- A few DAPM fixes and cleanups
- A large number of cleanups in various drivers (conversion and
standardized to regmap, component) mostly by Lars-Peter and Axel
HD-audio:
- Extended HD-audio core for Intel Skylake controller support
- Quirks for Dell headsets, Alienware 15
- Clean up of pin-based quirk tables for Realtek codecs
- ELD notifier implenetation for Intel HDMI/DP
USB-audio:
- Refactor runtime PM code to make lockdep happier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJV6TwJAAoJEGwxgFQ9KSmkZoEP/06GrsGlfgIfBbnlAKcsZ0t0
RDDCbxmwD8IsjTk180Gs3qBuhVPurhmPxq6Leow5fBktkEK5bIN3eAQkO9aIMroW
xxU1UF6Q9XE2j97e/PhhUld7/NP0IQK/YTMuwX74G2kfEkA9Lktl4UjNMw9mKJX2
8OIwz8ZuqSG60znmGlgiqRE4M3Svs1L/jVP1wrPg2DXQfe+ptAJpUTsyVGOMRWm3
IaJ9h5OelPg8Jm61zcg6/pgsdYx4oquCV5wLwMz8rzIUfHb7ox8F7YKOzB+sXtYI
zcsTfF2CqifoBcQAh9c+XE4+gMamAdheA+uc8ScUkcskucTj4Fr5tXLiPSN9QMt4
QGOOVjqcpWv5rWwAgzUJvl1/PT4HyQfkXn5tEQVGdg9Ab1SIcQBzD1+nHUV94vKZ
N7/grMdqJ56zUGK2fEcBS6BEDlaSToOIHDrQ1iPFNBvmW8qjBq9tYaufTGC6Vtj2
0YKJukzIbyqLIgQtQf44aqLouFIz2lq437PqRQ4W+9C3FwGN9FKCYJ/JzvOGDIJa
sSjEwQkJ9vnmZ3E2B30NKb24TG8pPq9WPIN2Rqe5EbHctU3gEnMScwvmG7SmCSG5
LtDVr6Q5XKFM56cVb7tdZl6Jv97BvGu6EERM+zN+8YyMver206rC8upWOev6R2q3
asvLDEchv7Qm3upx+PYg
=/sXs
-----END PGP SIGNATURE-----
Merge tag 'sound-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"There are little changes in core part, but lots of development are
found in drivers, especially ASoC. The diffstat shows regmap-related
changes for a slight API additions / changes, and that's all.
Looking at the code size statistics, the most significant addition is
for Intel Skylake. (Note that SKL support is still underway, the
codec driver is missing.) Also STI controller driver is a major
addition as well as a few new codec drivers.
In HD-audio side, there are fewer changes than the past. The
noticeable change is the support of ELD notification from i915
graphics driver. Thus this pull request carries a few changes in
drm/i915.
Other than that, USB-audio got a rewrite of runtime PM code. It was
initiated by lockdep warning, but resulted in a good cleanup in the
end.
Below are the highlights:
Common:
- Factoring out of AC'97 reset code from ASoC into the core helper
- A few regmap API extensions (in case it's not pulled yet)
ASoC:
- New drivers for Cirrus CS4349, GTM601, InvenSense ICS43432, Realtek
RT298 and ST STI controllers
- Machine drivers for Rockchip systems with MAX98090 and RT5645 and
RT5650
- Initial driver support for Intel Skylake devices
- Lots of rsnd cleanup and enhancements
- A few DAPM fixes and cleanups
- A large number of cleanups in various drivers (conversion and
standardized to regmap, component) mostly by Lars-Peter and Axel
HD-audio:
- Extended HD-audio core for Intel Skylake controller support
- Quirks for Dell headsets, Alienware 15
- Clean up of pin-based quirk tables for Realtek codecs
- ELD notifier implenetation for Intel HDMI/DP
USB-audio:
- Refactor runtime PM code to make lockdep happier"
* tag 'sound-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (411 commits)
drm/i915: Add locks around audio component bind/unbind
drm/i915: Drop port_mst_index parameter from pin/eld callback
ALSA: hda - Fix missing inline for dummy snd_hdac_set_codec_wakeup()
ALSA: hda - Wake the codec up on pin/ELD notify events
ALSA: hda - allow codecs to access the i915 pin/ELD callback
drm/i915: Call audio pin/ELD notify function
drm/i915: Add audio pin sense / ELD callback
ASoC: zx296702-i2s: Fix resource leak when unload module
ASoC: sti_uniperif: Ensure component is unregistered when unload module
ASoC: au1x: psc-i2s: Convert to use devm_ioremap_resource
ASoC: sh: dma-sh7760: Convert to devm_snd_soc_register_platform
ASoC: spear_pcm: Use devm_snd_dmaengine_pcm_register to fix resource leak
ALSA: fireworks/bebob/dice/oxfw: fix substreams counting at vmalloc failure
ASoC: Clean up docbook warnings
ASoC: txx9: Convert to devm_snd_soc_register_platform
ASoC: pxa: Convert to devm_snd_soc_register_platform
ASoC: nuc900: Convert to devm_snd_soc_register_platform
ASoC: blackfin: Convert to devm_snd_soc_register_platform
ASoC: au1x: Convert to devm_snd_soc_register_platform
ASoC: qcom: Constify asoc_qcom_lpass_cpu_dai_ops
...
Core changes:
- Root out the wrapper devm_gpiod_get() and gpiod_get() etc
versions of the descriptor calls that did not use the flags
argument on the end. This was around for too long and eventually
Uwe Kleine-König took the time to clean it out and the last
users are removed along with the macros in this tag. In several
cases the use of flags simplifies the code. For this reason we
have (ACKed) patches hitting in DRM, IIO, media, NFC, USB+PHY
up until we hammer in the nail with removing the macros.
- Add a fat document describing how much ready-made GPIO stuff
we have i the kernel to discourage people from reinventing
a square wheel in userspace, as so often happens.
- Create a separate lockdep class for each instance of a GPIO
IRQ chip instead of using one class for all chips, as the current
code will not work with systems with several GPIO chips doing
lockdep debugging.
- Protect against driver unloading also when a GPIO line is only
used as IRQ for the GPIOLIB_IRQCHIP helpers.
- If the GPIO chip has no designated owner, assign the parent
device driver owner as owner.
- Consolidation of chained IRQ handler install/remove replacing
all call sites where irq_set_handler_data() and
irq_set_chained_handler() were done in succession with a
combined call to irq_set_chained_handler_and_data(). This
series was created by Thomas Gleixner after the problem was
observed by Russell King.
- Tglx also made another series of patches switching
__irq_set_handler_locked() for irq_set_handler_locked() which
is way cleaner.
- Tglx and Jiang Liu wrote a good bunch of patches to make use of
irq_desc_get_xxx() accessors and avoid looking up irq_descs
from IRQ numbers. The goal is to get rid of the irq number
from the handlers in the IRQ flow which is nice.
- Rob Herring killed off the set_irq_flags() for all GPIO
drivers. This was an ARM specific function that is replaced
with the generic irq_modify_status() where special flags
are actually needed.
- When an OF node has a pin range for its GPIOs, return
-EPROBE_DEFER if the pin controller isn't available.
Pretty logical, yet needed to be fixed.
- If a driver using GPIOLIB_IRQCHIP has its own
irq_*_resources call back, then call these instead of the
defaults provided by the GPIOLIB.
- Fix an undocumented ABI hole: named GPIOs were not
properly documented.
Driver improvements:
- Add get_direction() support to the generic GPIO driver, it's
strange that we didn't have that before.
- Make it possible to have input-only GPIO chips using the
generic GPIO driver.
- Clean out platform data support from the Emma Mobile (EM)
driver
- Finegrained runtime PM support for the RCAR driver.
- Support r8a7795 (R-car H3) in the RCAR driver.
- Support interrupts on GPIOs 16 thru 31 in the DaVinci driver.
- Some consolidation and new support in the MPC8xxx driver,
we now support MPC5125.
- Preempt-RT-friendly patches: the OMAP, MPC8xxx, drivers uses raw
spinlocks making it work better with the realime patches.
- Interrupt support for the EXTRAXFS GPIO driver.
- Make the ETRAXFS GPIO driver support also ARTPEC-3.
- Interrupt and wakeup support for the BRCMSTB driver, also for
wakeup from S5 cold boot.
- Mask MXC IRQs during suspend.
- Improve OMAP2 GPIO set_debounce() to work according to spec.
- The VF610 driver handles IRQs properly.
New drivers:
- ZTE ZX GPIO driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV52lvAAoJEEEQszewGV1zOVcP/2ZgkfRgl119LZnWShfrEJWq
UXaNzSaPNgvDzvGaqqi62SZQuhrdIWRKfMPtAuMGbEn5aJx0JC5UAOYjjfkKBqpO
toqc1w2DScc0JTorY8qgczIBDO1A3ZBAcIvXXpOduy/JaKPoQteRN8WYTynPw48/
0+97ZODwhyOkfeqmvUClkc9gW4XT68dudb0Lv1nQjsZmd1dHF2PZlwH3aL9sV68j
GJAqf09xNqZaWWQBhs+J3ptsYjaJfYjo9NOOUf0Y/UgqXO3vB+2S4EmRATaRHS2F
aHdj03sNZCNSDEa35WwetbLRGxPzSWmfxmBzQQ1baGdcJICn7Yv58EklPKRvwtMo
ZpUsgiOV4OUIEClPJohs4xbl2HRsOYB3VbcihkXjVAxS6i2/jgA3Tn8ATvUSZ8wq
TX8D6BfciigRCkT2G+B0TQBmcX1IQsMd1DBUNfw7Dk1TK/vxH4UYWbke422RjKGz
ORJ+0DfShMCdYjrCVlt7UbFcqE3L5CnrztLQ3oFt0om2JsSWztV9V579G+Dqo9CI
fE4G3xlsF33UCvXcmnOp6PuU+ZYBodLggkmK4REy2D3LCOnkcKq0U8Fj5RssApZ9
FdqVYck555ZpcBiN8ihB97WsmU+0XhBjblCbgzr6GxUw8EJ4x8H9nlraA6bluFoP
9c2qgPxjCq/VWA/F0YOU
=iQ2P
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.3 kernel cycle.
There is quite a lot going on in the GPIO subsystem this merge window,
so the main matter is decribed below.
The hits in other subsystems when making the GPIO flags optional are
all ACKed by their respective subsystem maintainers.
Core changes:
- Root out the wrapper devm_gpiod_get() and gpiod_get() etc versions
of the descriptor calls that did not use the flags argument on the
end. This was around for too long and eventually Uwe Kleine-König
took the time to clean it out and the last users are removed along
with the macros in this tag. In several cases the use of flags
simplifies the code. For this reason we have (ACKed) patches
hitting in DRM, IIO, media, NFC, USB+PHY up until we hammer in the
nail with removing the macros.
- Add a fat document describing how much ready-made GPIO stuff we
have i the kernel to discourage people from reinventing a square
wheel in userspace, as so often happens.
- Create a separate lockdep class for each instance of a GPIO IRQ
chip instead of using one class for all chips, as the current code
will not work with systems with several GPIO chips doing lockdep
debugging.
- Protect against driver unloading also when a GPIO line is only used
as IRQ for the GPIOLIB_IRQCHIP helpers.
- If the GPIO chip has no designated owner, assign the parent device
driver owner as owner.
- Consolidation of chained IRQ handler install/remove replacing all
call sites where irq_set_handler_data() and
irq_set_chained_handler() were done in succession with a combined
call to irq_set_chained_handler_and_data().
This series was created by Thomas Gleixner after the problem was
observed by Russell King.
- Tglx also made another series of patches switching
__irq_set_handler_locked() for irq_set_handler_locked() which is
way cleaner.
- Tglx and Jiang Liu wrote a good bunch of patches to make use of
irq_desc_get_xxx() accessors and avoid looking up irq_descs from
IRQ numbers. The goal is to get rid of the irq number from the
handlers in the IRQ flow which is nice.
- Rob Herring killed off the set_irq_flags() for all GPIO drivers.
This was an ARM specific function that is replaced with the generic
irq_modify_status() where special flags are actually needed.
- When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER
if the pin controller isn't available. Pretty logical, yet needed
to be fixed.
- If a driver using GPIOLIB_IRQCHIP has its own irq_*_resources call
back, then call these instead of the defaults provided by the
GPIOLIB.
- Fix an undocumented ABI hole: named GPIOs were not properly
documented.
Driver improvements:
- Add get_direction() support to the generic GPIO driver, it's
strange that we didn't have that before.
- Make it possible to have input-only GPIO chips using the generic
GPIO driver.
- Clean out platform data support from the Emma Mobile (EM) driver
- Finegrained runtime PM support for the RCAR driver.
- Support r8a7795 (R-car H3) in the RCAR driver.
- Support interrupts on GPIOs 16 thru 31 in the DaVinci driver.
- Some consolidation and new support in the MPC8xxx driver, we now
support MPC5125.
- Preempt-RT-friendly patches: the OMAP, MPC8xxx, drivers uses raw
spinlocks making it work better with the realime patches.
- Interrupt support for the EXTRAXFS GPIO driver.
- Make the ETRAXFS GPIO driver support also ARTPEC-3.
- Interrupt and wakeup support for the BRCMSTB driver, also for
wakeup from S5 cold boot.
- Mask MXC IRQs during suspend.
- Improve OMAP2 GPIO set_debounce() to work according to spec.
- The VF610 driver handles IRQs properly.
New drivers:
- ZTE ZX GPIO driver"
* tag 'gpio-v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (87 commits)
Revert "gpio: extraxfs: fix returnvar.cocci warnings"
gpio: tc3589x: use static container helper
gpio: xlp: fix error return code
gpio: vf610: handle level IRQ's properly
gpio: max732x: Fix error handling in probe()
gpio: omap: fix clk_prepare/unprepare usage
gpio: omap: protect regs access in omap_gpio_irq_handler
gpio: omap: fix omap2_set_gpio_debounce
gpio: omap: switch to use platform_get_irq
gpio: omap: remove wrong irq_domain_remove usage in probe
gpiolib: add description for gpio irqchip fields in struct gpio_chip
gpio: extraxfs: fix returnvar.cocci warnings
gpiolib: irqchip: use different lockdep class for each gpio irqchip
gpio/grgpio: fix deadlock in grgpio_irq_unmap()
Documentation: gpio: consumer: describe active low property
gpio: mxc: fix section mismatch warning
gpio/mxc: mask gpio interrupts in suspend
gpio: omap: Fix missing raw locks conversion
gpio: brcmstb: support wakeup from S5 cold boot
gpio: brcmstb: Add interrupt and wakeup source support
...
This should never happen so warn when the count does
not equal the expected size.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes regression from
commit f1afe24f0e
Author: Arun Siluvery <arun.siluvery@linux.intel.com>
Date: Tue Aug 4 16:22:20 2015 +0100
drm/i915: Change SRM, LRM instructions to use correct length
which forgot to account for the length bias when declaring the fixed
length.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pfit state is stored as register values, so dump them as hex instead
of decimal to make some sense of the error messages.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These registers exist only before GEN5, so currently we may access
undefined registers on VLV/CHV and BXT. Apply the workaround only pre
GEN5.
Since the workaround is relevant only when LVDS is present, for clarity
apply it only if this is the case.
This triggered an unclaimed register access warning on BXT.
v2: (Ville)
- move the workaround to the LVDS init code
- print a debug note about the workaround
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This register exists only pre GEN5, but atm we also access it on
VLV/BXT/CHV. Prevent accessing it on these latter platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A small, very small, step to sharing the duplicate code between
execlists and legacy submission engines, starting with the ringbuffer
allocation code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.
Log an error if the sink has advertized HBR2 capability without TPS3
capability.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is another case where we can consider the default is the
newest available and not actually a missed case.
No functional change.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unless future specs tells otherwise we can assume future gens
inherit some stuff from the previous so let's handle
missed cases when we know tehy should't be there and assume
default equals newest one.
No functional changes.
v2: Remove useless case as pointed out by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are already being called for gen >= 9,
so let's be sure when this happens we use whatever is
there already for the latest platform.
No functional change.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do a single kcalloc, we can also drop the size
from free_gen8_temp_bitmaps since it's no longer used.
v2: Use GFP_TEMPORARY to make the allocations reclaimable.
v3: Drop the 2D array, just allocate a single block.
v4: Rebase to handle gen8_preallocate_top_level_pdps.
v5: Align misaligned bracket.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Correct kcalloc arguments as suggested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats
list.
Testcase: igt/kms_universal_plane.c
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Cc: Konduru, Chandra <chandra.konduru@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not
filling bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Cc: Konduru, Chandra <chandra.konduru@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915 display fixes headed for v4.3. Mostly SKL, but some regression
fixes too.
* tag 'drm-intel-next-fixes-2015-09-02' of git://anongit.freedesktop.org/drm-intel:
i915: Set ddi_pll_sel in DP MST path
drm/i915: Don't use link_bw for PLL setup
drm/i915: Preserve SSC earlier
drm/i915/skl: Adding DDI_E power well domain
drm/i915: eDP can be present on DDI-E
drm/i915/skl: Enable DDI-E
drm/i915: Enable HDMI on DDI-E
drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6
drm/i915: Check DP link status on long hpd too
drm/i915: set CDCLK if DPLL0 enabled during resuming from S3
Here are some fixes and some new features for rockchip drm,
tested on popmetal rk3288 board, can you land them?
* 'drm-rockchip-2015-08-26' of https://github.com/markyzq/kernel-drm-rockchip:
drm/rockchip: vop: support plane scale
drm/rockchip: vop: restore vop registers when resume
drm/rockchip: vop: Default enable win2/3 area0 bit
drm/rockchip: vop: Add yuv plane support
drm/rockchip: vop: Fix window dest start point
drm/rockchip: vop: Fix virtual stride calculation
Pull request of 2015-09-01
A single commit. Workaround for
https://bugzilla.redhat.com/show_bug.cgi?id=1227193
* tag 'vmwgfx-next-15-09-01' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes v2
This is a last pull request, which includes two g2d patches
I missed, and more cleanup series of Exynos drm driver.
The cleanup series makes Exynos drm driver more simple,
and removes unnecessary codes, and considers multiple plane format
of framebuffer. I hope this not to be late.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: remove buf_cnt from struct exynos_drm_fb
drm/exynos: remove exynos_drm_fb_get_buf_cnt()
drm/exynos: cleanup exynos_user_fb_create()
drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers
drm/exynos: cleanup to get gem object for fb
drm/exynos: update fb_info via only one function
drm/exynos: cleanup exynos_drm_fbdev_update()
drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c
drm/exynos: remove exynos_drm_fb_set_buf_cnt()
drm/exynos: remove superfluous checks in g2d_check_reg_offset()
drm/exynos: fix size check in g2d_check_buf_desc_is_valid()
More fixes for radeon and amdgpu for 4.3:
- Send full DP aux address fixes for radeon and amdgpu
- Fix an HDMI display regression for pre-DCE5 parts
- UVD suspend fixes for amdgpu
- Add an rs480 suspend quirk
- Fix bo reserve handling in amdgpu GEM_OP ioctl
- GPU scheduler fixes
- SDMA optimizations
- MEC fix for Fiji
* 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux: (21 commits)
drm/amdgpu: set MEC doorbell range for Fiji
drm/amdgpu: implement burst NOP for SDMA
drm/amdgpu: add insert_nop ring func and default implementation
drm/amdgpu: add amdgpu_get_sdma_instance helper function
drm/amdgpu: add AMDGPU_MAX_SDMA_INSTANCES
drm/amdgpu: add burst_nop flag for sdma
drm/amdgpu: add count field for the SDMA NOP packet v2
drm/amdgpu: use PT for VM sync on unmap
drm/amdgpu: make wait_event uninterruptible in push_job
drm/amdgpu: fix amdgpu_bo_unreserve order in GEM_OP IOCTL v2
drm/amdgpu: partially revert "modify amdgpu_fence_wait_any() to amdgpu_fence_wait_multiple()" v2
Add radeon suspend/resume quirk for HP Compaq dc5750.
drm/amdgpu: re-work sync_resv
drm/amdgpu/atom: Send out the full AUX address
drm/radeon/native: Send out the full AUX address
drm/radeon/atom: Send out the full AUX address
drm/amdgpu: use IB for fill_buffer instead of direct command
drm/amdgpu: stop trying to suspend UVD sessions v2
drm/amdgpu: add scheduler dependency callback v2
drm/amdgpu: let the scheduler work more with jobs v2
...
Pull locking and atomic updates from Ingo Molnar:
"Main changes in this cycle are:
- Extend atomic primitives with coherent logic op primitives
(atomic_{or,and,xor}()) and deprecate the old partial APIs
(atomic_{set,clear}_mask())
The old ops were incoherent with incompatible signatures across
architectures and with incomplete support. Now every architecture
supports the primitives consistently (by Peter Zijlstra)
- Generic support for 'relaxed atomics':
- _acquire/release/relaxed() flavours of xchg(), cmpxchg() and {add,sub}_return()
- atomic_read_acquire()
- atomic_set_release()
This came out of porting qwrlock code to arm64 (by Will Deacon)
- Clean up the fragile static_key APIs that were causing repeat bugs,
by introducing a new one:
DEFINE_STATIC_KEY_TRUE(name);
DEFINE_STATIC_KEY_FALSE(name);
which define a key of different types with an initial true/false
value.
Then allow:
static_branch_likely()
static_branch_unlikely()
to take a key of either type and emit the right instruction for the
case. To be able to know the 'type' of the static key we encode it
in the jump entry (by Peter Zijlstra)
- Static key self-tests (by Jason Baron)
- qrwlock optimizations (by Waiman Long)
- small futex enhancements (by Davidlohr Bueso)
- ... and misc other changes"
* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (63 commits)
jump_label/x86: Work around asm build bug on older/backported GCCs
locking, ARM, atomics: Define our SMP atomics in terms of _relaxed() operations
locking, include/llist: Use linux/atomic.h instead of asm/cmpxchg.h
locking/qrwlock: Make use of _{acquire|release|relaxed}() atomics
locking/qrwlock: Implement queue_write_unlock() using smp_store_release()
locking/lockref: Remove homebrew cmpxchg64_relaxed() macro definition
locking, asm-generic: Add _{relaxed|acquire|release}() variants for 'atomic_long_t'
locking, asm-generic: Rework atomic-long.h to avoid bulk code duplication
locking/atomics: Add _{acquire|release|relaxed}() variants of some atomic operations
locking, compiler.h: Cast away attributes in the WRITE_ONCE() magic
locking/static_keys: Make verify_keys() static
jump label, locking/static_keys: Update docs
locking/static_keys: Provide a selftest
jump_label: Provide a self-test
s390/uaccess, locking/static_keys: employ static_branch_likely()
x86, tsc, locking/static_keys: Employ static_branch_likely()
locking/static_keys: Add selftest
locking/static_keys: Add a new static_key interface
locking/static_keys: Rework update logic
locking/static_keys: Add static_key_{en,dis}able() helpers
...
Some buffers (UVD/VM page tables) must be placed in VRAM,
but the byte restriction for moving buffers didn't took this
into account.
Port of radeon commit 4b09556660.
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>
The logic was reversed. This feature is not enabled
at the moment, but fix it now for the future.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Using the wrong watermwark value for the secondary
watermark. Copy paste typo. Noticed by Mykola.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Using the wrong watermwark value for the secondary
watermark. Copy paste typo. Noticed by Mykola.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Should help avoid fragmentation of vram due to CPU access
requirements.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For kernel driver BOs, be explicit about whether we need
vram access up front. This avoids unecessary migrations and
avoids using visible vram for buffers were it's not needed.
v2: line wrap fixes
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This will make sure that audio callbacks do not race with
component bind/unbind.
[Note: this is an update patch to commit [51e1d83cab: drm/i915: Call
audio pin/ELD notify function] where I mistakenly applied the older
version. Jani and Daniel's review tags were to the latest version,
so I add them below, too -- tiwai]
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The port_mst_index parameter was reserved for future use, but
maintainers prefer to add it later when it is actually used.
[Note: this is an update patch to commit [51e1d83cab: drm/i915: Call
audio pin/ELD notify function] where I mistakenly applied the older
version. Jani and Daniel's review tags were to the latest version,
so I add them below, too -- tiwai]
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Customize the insert_nop func for SDMA rings, and use burst NOP for
ring/IB submissions in other places as well
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The insert_nop function is added to amdgpu_ring_funcs structure as
well as the default implementation
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This function is added to map the ring to sdma instance
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The burst NOP is supported for SDMA when feature_version is >= 20.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This is added to support the burst NOP
v2: squash the typo fix
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Instead of the array which is used for ID management.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
No copy_(to|from)_user while BO is reserved.
v2: handle default path as well
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
That isn't used any more.
v2: rebase
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.
Signed-off-by: Jeffery Miller <jmiller@neverware.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
sync_resv is to handle both amdgpu_fence and sched_fence.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Port of:
drm/radeon/atom: Send out the full AUX address
to amdgpu
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
On GMCH plaforms we are now getting the following spew on aux
interrupts:
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064
Prevent it by not calling intel_get_hpd_pins() unless one of the HPD
interrupt bits are actually set.
I already fixed similar annoyance once with
4bca26d0a6 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV
but another source for it got added in
fd63e2a972 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to
serve as the new unified piece of code. pch_get_hpd_pins() had the debug
print, and i9xx_get_hpd_pins() didn't.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rewrite the BXT hpd setup to match the way we do it on other platforms:
- Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG
- Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall()
- Update DE port IMR using bdw_update_port_irq()
Also throw out port D from bxt_port_hotplug_long_detect() since BXT only
goes up to C.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A lot of the hpd irq handling is duplicated code, so refactor it a bit
by observing that in several places the only difference is the hpd[]
array. So pull the code to a few functions and pass in the hpd[] array
from the caller. Another option would be to determine the correct array
to use within the functions themselves, but somehow passing it in felt
nicer.
Further code reduction could be achieved by passing in the hotplug
register offset, and the long pulse detection function pointer. But that
didn't feel as good for some reason, so I left it at the middle ground.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bxt_hpd_handler() looks different to everyone else for no good reason.
Rewrite it to use the standard variable namees etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Runtime suspends disabled all interrupts, so in order to get them back
fully we need to also do the HPD irq setup on runtime resume. Except
on VLV/CHV where the display interrupt initialization is part of the
display power well powerup.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On SKL the port A HPD has moved to the PCH. Hook it up.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wire up the port A HPD for BDW. Compared to earlier platforms the
interrupt setup is a bit different, but basically everything else
looks the same.
v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes
Check for BDW before processing the HPD to not break BXT
Set found=true when processing port A HPD
Sort out the mess I made of the irq setup in v1
Warn about bad irq mask vs. enable bits in bdw_update_port_irq() (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the CPU and PCH are on the same package we must enabled the port A
HPD also in the south hotplug register. To identify the package type
we simply look at the PCH type: LPT-H means separate package, and
LPT-LP means multi chip package (MCP).
v2: Add comment and pimp commit message
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As with ILK/SNB wire up the port A HPD on IVB/HSW.
This might be more important on HSW with PSR. BSpec tells us that if the
automagic link training performed by the hardware fails for some reason,
we're going to get a short HPD and are supposed to re-train the link
manyally.
v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes
Add a comment about the pulse duration bits being reserved on HSW+
like we have for LPT+ in ibx_hpd_irq_setup()
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least
try to wite it up so that we might notice if the link has issues.
The eDP spec suggests that if HPD is not wired up, one should poll the
link status instead. We don't even do that currently.
v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Starting from SPT the only interrupts living in the south are GMBUS and
HPD. What's worse some of the SPT specific new bits conflict with some
other bits on earlier PCH generations. So better not use the
cpt_irq_handler() for SPT+ anymore.
Also kill the hand rolled port E handling with something more
standardish. This also avoids accidentally confusing port B and port E
long pulses since the bits occupy the same positions, just in different
registers.
Also add a comment noting that the short pulse duration bits are
reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the
MBZ in the spec.
v2: Call intel_hpd_irq_handler() only once (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the 0 initialization of pin_mask and long_mask from
intel_get_hpd_pins() into each caller. This we we can call
intel_get_hpd_pins() multiple times to accumulate more pins from several
sources.
v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PORTA HPD defines are not BXT specific. They also exist on SPT,
and partially already on LPT:LP.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extract the core of ironlake_{enable,disable}_display_irq() into a new
function. We'll have further use for it later.
v2: Warn about invalid mask vs. enable bits (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eliminate a bunch of duplicated code that calculates the currently
enabled HPD interrupt bits.
v2: s/;/:/ in patch subject (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space
vs. tab issues.
v2: Document pre-HSW/LPT bits, and order another tab (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Forgot to do that in
commit d328c9d78d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 10 16:22:37 2015 +0200
drm/i915: Select starting pipe bpp irrespective or the primary plane
and it's confusing. Fix it.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Looking other drm drivers, there is no the restriction that framebuffer
has only one buffer in .create_handle() callback. They use just first
buffer.
If this limitation is removed, there is no reason keeping buffer count
for framebuffer, so we can remove buf_cnt from struct exynos_drm_fb.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
We can get buffer count of framebuffer using drm_format_num_planes(), so
keeping exynos_drm_fb_get_buf_cnt() is unnecessary.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This modifies exynos_drm_framebuffer_init() to be possible to support
multiple buffers. Then it can be used by exynos_user_fb_create().
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Current codes get first gem object and then again get remain gem
objects. They can be unified to one routine.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch moves codes to update fb_info into exynos_drm_fbdev_update(),
so fb_info is updated via only one function.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It can get exynos_gem object via function argument, so no need to call
exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update.
It also can get struct drm_framebuffer *fb via helper->fb, so can remove
a function argument for it.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The variable name "exynos_gem_obj" is too long, so some lines exceed 80
characters. It's simple to use "obj" instead of "exynos_gem_obj".
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in
exynos_drm_fbdev_update(). This patch sets directly buffer count in
exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(),
so there is no any reason to keep exynos_drm_fb_set_buf_cnt().
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The cases of the switch statement ensure that reg_type
can never be REG_TYPE_NONE here.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The size check was incomplete. It only computed the
size of area of the drawing rectangle and checked if
the size still fit inside the buffer.
The correct check is to compute the position of the
last byte that the G2D engine is going to access and
then check if that position is still contained in the
buffer. In particular we need the stride information
to determine this.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x
platforms.
This got broken in the following commit:
commit fd63e2a972
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Jul 21 15:32:44 2015 -0700
drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Egbert Eich <eich@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There have been many hard to track down bugs whereby userspace forgot to
flag a write buffer and then cause graphics corruption or a hung GPU
when that buffer was later purged under memory pressure (as the buffer
appeared clean, its pages would have been evicted rather than preserved
and any changes more recent than in the backing storage would be lost).
In retrospect this is a rare optimisation against memory pressure,
already the slow path. If we always mark the buffer as dirty when
accessed by the GPU, anything not used can still be evicted cheaply
(ideal behaviour for mark-and-sweep eviction) but we do not run the risk
of corruption. For correct read serialisation, userspace still has to
notify when the GPU writes to an object. However, there are certain
situations under which userspace may wish to tell white lies to the
kernel...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Goel, Akash" <akash.goel@intel.co>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
To help with debugging i2c-over-aux issues, add a module parameter than
can be used to tweak the assumed i2c bus speed, and thus the maximum
number of retries we will do for each aux message.
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Calculate the number of retries we should do for each i2c-over-aux
message based on the time it takes to perform the i2c transfer vs. the
aux transfer. We assume the shortest possible length for the aux
transfer, and the longest possible (exluding clock stretching) for the
i2c transfer.
The DP spec has some examples on how to calculate this, but we don't
calculate things quite the same way. The spec doesn't account for the
retry interval (assumes immediate retry on defer), and doesn't assume
the best/worst case behaviour as we do.
Note that currently we assume 10 kHz speed for the i2c bus. Some real
world devices (eg. some Apple DP->VGA dongle) fails with less than 16
retries. and that would correspond to something close to 15 kHz (with
our method of calculating things) But let's just go for 10 kHz to be
on the safe side. Ideally we should query/set the i2c bus speed via
DPCD but for now this should at leaast remove the regression from the
1->16 byte trasnfer size change. And of course if the sink completes
the transfer quicker this shouldn't slow things down since we don't
change the interval between retries.
I did a few experiments with a DP->DVI dongle I have that allows you
to change the i2c bus speed. Here are the results of me changing the
actual bus speed and the assumed bus speed and seeing when we start
to fail the operation:
actual i2c khz assumed i2c khz max retries
1 1 ok -> 2 fail 211 ok -> 106 fail
5 8 ok -> 9 fail 27 ok -> 24 fail
10 17 ok -> 18 fail 13 ok -> 12 fail
100 210 ok -> 211 fail 2 ok -> 1 fail
So based on that we have a fairly decent safety margin baked into
the formula to calculate the max number of retries.
Fixes a regression with some DP dongles from:
commit 1d002fa720
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Tue Feb 10 18:38:08 2015 +0000
drm/dp: Use large transactions for I2C over AUX
v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
Add a define our AUX retry interval and account for it
v3: Make everything usecs to avoid confusion about units (Daniel)
Add a comment reminding people about the AUX bitrate (Daniel)
Use DIV_ROUND_UP() since we're after the "worst" case for i2c
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Tested-by: moosotc@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently we react to native and i2c defers by waiting either 400-500 us
or 500-600 us, depending on which code path we take. Consolidate them
all to one define AUX_RETRY_INTERVAL which defines the minimum interval.
Since we've been using two different intervals pick the longer of them
and define AUX_RETRY_INTERVAL as 500 us. For the maximum just use
AUX_RETRY_INTERVAL+100 us.
I want to have a define for this so that I can use it when calculating
the estimated duration of i2c-over-aux transfers. Without a define it
would be very easy to change the sleep duration and neglect to update
the i2c-over-aux estimates.
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Backmerge -fixes since there's more DDI-E related cleanups on top of
the pile of -fixes for skl that just landed for 4.3.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i914/intel_dp.c
drivers/gpu/drm/i915/intel_lrc.c
Conflicts are all fairly harmless adjacent line stuff.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This makes the error message slightly more useful.
Changes since v1:
- Use ktime_get() while irqs are still disabled. (vsyrjala)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's already a per crtc member that can be used for it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When i915 drivers run inside a VM with Intel GVT-g, some explicit
notifications are needed from guest to host device model through PV
INFO page write. The notifications include:
PPGTT create
PPGTT destroy
They are used for the shadow implementation of PPGTT. Intel GVT-g
needs to write-protect the guest pages of PPGTT, and clear the write
protection when they end their life cycle.
v2:
- Use lower_32_bits()/upper_32_bits() for qword operations;
- Remove the notification of guest context creation/destroy;
Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some more definitions in the PV info page are added. They are mainly
for the guest notification to Intel GVT-g device model. They are used
for Broadwell enabling.
The notification of PPGTT page table creation/destroy is to notify
GVT-g device model the life cycle of guest page tables. Then device
model will implement shadow page table for guests.
The notification of context create/destroy is optional. If it is used,
the device model will create/destroy shadow context corresponding to
the context's life cycle. Guest driver needs to make sure that the
context's LRCA and backing storage address unchanged. If it is not
used, the device model will perform the context shadow work in the
context scheduling time.
Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Broadwell hardware supports both ring buffer mode and execlist mode.
When i915 runs inside a VM with Intel GVT-g, we allow execlist mode
only.
The main reason of EXECLIST only is that GVT-g does not support the
dynamic mode switch between ring buffer mode and execlist mode when
running multiple virtual machines.
v2:
- Adjust the position of vgpu check in sanitize function (Joonas)
- Add vgpu error check in context initialization. (Joonas, Daniel)
Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is based on Mika Kuoppala's patch below:
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61104/match=workaround+hw+preload
The patch will preallocate the page directories for 32-bit PPGTT when
i915 runs inside a virtual machine with Intel GVT-g. With this change,
the root pointers in EXECLIST context will always keep the same.
The change is needed for vGPU because Intel GVT-g will do page table
shadowing, and needs to track all the page table changes from guest
i915 driver. However, if guest PPGTT is modified through GPU commands
like LRI, it is not possible to trap the operations in the right time,
so it will be hard to make shadow PPGTT to work correctly.
Shadow PPGTT could be much simpler with this change. Meanwhile
hypervisor could simply prohibit any attempt of PPGTT modification
through GPU command for security.
The function gen8_preallocate_top_level_pdps() in the patch is from
Mika, with only one change to set "used_pdpes" to avoid duplicated
allocation later.
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the audio codec is enabled or disabled, notify the audio driver.
This will enable the audio driver to get the notification at all times
(even when audio is in different powersave states).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a common function to return "yes" or "no" string based on the
argument, and drop the local versions of it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If rc6 is enabled, notify GuC so it can do proper forcewake before
command submission.
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The firmware layout changes that now it only has css header +
uCode + RSA signature. Plus, other trivial changes to support
GuC V4.3.
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The driver doesn't support UMS any more, so set DRIVER_MODESET by default,
remove the legacy s/r callbacks, and rename the s/r functions to make it more clear
they're only in use by switcheroo now.
Also remove an obsolete comment about atomic. Normal updates are supported only
async updates aren't yet.
v2: Don't unconditionally set DRIVER_ATOMIC, we're not yet there.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make the code mode readable by pulling the "does this crtc have any
encoders?" deduction into a separate function.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
