Insert wait for reg mem after EOP to fix potential issue with vm context switch
v2: move wait to vm_flush() use equal instead of greater than.
Signed-off-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Provide module parameter to enable/disable them. Still
enabled by default.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Just adding the rotated UV plane at the end of the rotated Y plane.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By providing a start offset into the source array of pages, and returning the
end position in the scatter-gather table, we will be able to append the UV
plane to the rotated mapping in later patches.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be needed for NV12 support.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Nick Hoath <nicholas.hoath@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
FIXME: Should there be a WARN(i != 9) or something, or what does the
entry 9 comment mean?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_sdvo_select_ddc_bus() and intel_sdvo_select_i2c_bus() have no used
for the passed in 'reg', so just drop it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT and DEVICE_TYPE_DIGITAL_OUTPUT when
trying to determine the presence of eDP based on the VBT child device
type. Apparently a significant portion of VLV systems have these bits
set incorrectly, and so we currently fail to detect eDP on said systems.
This is based on an earlier patch [1] from Andreas Lampersperger.
Instead of ignoring the bits just on VLV as was done in the orignal
patch, we now ignore them for all platforms. We should still have
enough bits in there to avoid false positives (unless the VBT is totally
bonkers).
Quoting the orignal patch:
> When the i915.ko identify an eDP output on a valleyview
> board, it should be more slackly. The reason for that is,
> that BIOS DATA TABLES generated with intel BMP (Binary
> Modification Program) do not set bits for NOT_HDMI or
> DIGITAL_OUTPUT on the device type. Due to Adolfo
> Sanchez from Intel EMGD, this is not possible.
> To solve this problem and enable i915.ko on embedded
> vlv boards with eDP, we ignore this two bits.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069416.html
Cc: Andreas Lampersperger <lampersperger.andreas@heidenhain.de>
Cc: "Sanchez, AdolfoX" <adolfox.sanchez@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't support eDP on g4x, so let's not even look at the VBT
to determine the port type, just in case the VBT is bonkers
on some g4x machines and indicates the precense of eDP.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
An HPD interrupt may fire while we are in a function that changes
the PORT_HOTPLUG_EN register - especially when an HPD interrupt
storm occurs.
Since the interrupt handler changes the enabled HPD lines when it
detects such a storm the read-modify-write cycles may interfere.
To avoid this, shiled the rmw cycles with IRQ save spinlocks.
Changes since v1:
- Implement a function which takes care of accessing PORT_HOTPLUG_EN.
Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VBT MIPI Sequence Block version 3 has forward incompatible changes:
First, the block size in the header has been specified reserved, and the
actual size is a separate 32-bit value within the block. The current
find_section() function to will only look at the size in the block
header, and, depending on what's in that now reserved size field,
continue looking for other sections in the wrong place.
Fix this by taking the new block size field into account. This will
ensure that the lookups for other sections will work properly, as long
as the new 32-bit size does not go beyond the opregion VBT mailbox size.
Second, the contents of the block have been completely
changed. Gracefully refuse parsing the yet unknown data version.
Cc: Deepak M <m.deepak@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We can calculate BXT values correctly from GFX fuse values without
hardcoding special limits.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matthew D Roper <matthew.d.roper@intel.com>
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It would be initialized just moments later by i915_init_vm.
Rearrange the code such that i915_init_vm() is next to its callers
inside i915_gem_gtt (and so we can make it static). After removing the
dance around the files, it is clear that we are repeating some work
inside the initializers (such as calling drm_mm_init() multiple times),
so take advantage of the refactor to also remove some redundant code and
clean up the interface.
v2: Commit msg update,
s/i915_init_vm/i915_address_space_init, move to i915_gem_gtt.c,
init address_space during i915_gem_setup_global_gtt for ggtt.
v3: Do not init global_link - we are adding it to vm_list moments later,
make i915_address_space_init static, use OOP style parameter order.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Finally managed to dig up enough hints as to where the stolen
reserved stuff lives on ctg/elk. So add the code to decode it.
This was a combination of old chipset specs, diggin up an old
elk grits release with an ctg/elk AubLoad etc.
This was only tested on an elk as I don't have a ctg here
unfortunately.
This leaves ilk as the only platform that doesn't have a way
to detect this stuff. Looking at the register contents on my
ilk, it might be that the elk way works there too, but I
can't be sure since I can't affect the amount of reserved
memory on that machine, and if I am to trust the register
contents, by default it would reserve 0 bytes.
v2: s/WARN_ON_ONCE/WARN_ON/ since it's in one time init code
anyway (Paulo)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-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>
I only tested this on BDW and SKL, but since the register description
is the same ever since gen4, let's assume that all gens take the same
register format. If that's not true, then hopefully someone will
bisect a bug to this patch and we'll fix it.
Notice that the wrong fence offset register just means that the
hardware tracking will be wrong.
Testcases:
- igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt
- igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt
v2:
- Add intel_crtc->adjusted_{x,y} so this code can work independently
of intel_gen4_compute_page_offset(). (Ville).
- This version also works on SKL.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is essentially a rewrite of "drm/i915: Check pixel format
for fbc" from Ville Syrjälä. The idea is the same, but the code is
different due to all the changes that happened since his original
patch. So any bugs are due to my bad rewrite.
v2:
- Drop the alpha formats (Ville).
v3:
- Drop the stale comment (Ville).
Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-*
Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This WA is only for HSW/BDW.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The spec says the register should have that value for the entire time
that FBC is enabled, so apply the WA before we enable FBC.
Notice that we also have this WA for ILK/SNB, but it is implemented at
init_clock_gating(). I could move the IVB/HSW/BDW WA code to
init_clock_gating() too, but since we recently had some complaints
about WAs not staying after being set, I'm going to play safe and keep
this here for now.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate
exceeds 95% of the core display clock.
v2:
- HSW also needs the WA (Ville).
- Add the WA name (Ville).
- Use the current cdclk (Ville).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And also print the threshold. I was surprised to see a log message
claiming the CFB size was 32mb when there was less than 24mb available
for it.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The FBC hardware for these platforms doesn't have access to the
bios_reserved range, so it always assumes the maximum (8mb) is used.
So avoid this range while allocating.
This solves a bunch of FIFO underruns that happen if you end up
putting the CFB in that memory range. On my machine, with 32mb of
stolen, I need a 2560x1440 mode for that.
Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't allow FBC for cases where the spec says we can't FBC.
v2:
- Just WARN_ON() the strides that should have been caught earlier
(Daniel)
- Make it a new function since I expect this to grow more.
v3:
- Document which IGT test is exercised by this.
v4:
- Implement the restrictions for gens 2-6 too (Ville).
- Fix off-by-one mistake (Ville).
Testcase: igt/kms_frontbuffer_tracking/fbc-badstride
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.
v2: Improve commit message (Chris).
v3: Constify struct drm_framebuffer (Ville).
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The scaler_id in intel_pipe_config_compare should not be checked
when adjusting in intel_pipe_config_compare. The hw scaler id may
be changed in intel_update_pipe_config.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Enable TO mode for RC6 for SKL till D0 and BXT till A0.
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
[danvet: Fixup line continuation alignment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes the warnings like
"plane A assertion failure, should be disabled but not"
that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.
Most likely caused by
commit 36750f284b
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 1 12:49:54 2015 +0200
drm/i915: update plane state during init
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429
Reported-and-tested-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be
disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0.
v2: Added GT3/GT4 Check.
Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
[danvet: Align continuation properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will be usefull to specify w/a that affects only SKL GT3 and GT4.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like this was introduced in:
commit d1675198ed
Author: Alex Dai <yu.dai@intel.com>
Date: Wed Aug 12 15:43:43 2015 +0100
drm/i915: Integrate GuC-based command submission
This patch assumed LRC contexts and HWS layout, which is incorrect on
platforms without execlists. This can lead to a crash in GPU error
state readout on those platforms.
I don't see a bug filed for this, but there may be one that I haven't
found.
v2: fixup offset handling for error capture fix (Dave)
Cc: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_modeset_readout_hw_state() seems like the more appropriate place
for populating the scanline_offset and timestamping constants than
intel_sanitize_crtc() since they are basically part of the state we
read out.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@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: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().
The plane disabling was first added in
4cf0ebbd4f drm/i915: Rework plane readout.
I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.
Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled
v2: Steal Maarten's idea to move crtc->mode etc. assignment too
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch modifies dsi_prepare() function to support the same
modeset prepare sequence for BXT also. Main changes are:
1. BXT port control register is different than VLV.
2. BXT modeset sequence needs vdisplay and hdisplay programmed
for transcoder.
3. BXT can select PIPE for MIPI transcoders.
4. BXT needs to program register MIPI_INIT_COUNT for both the ports,
even if only one is being used.
v2: Fixed Jani's review comments. Rectified the DSI Macros to get
proper register offsets using _MIPI_PORT instead of _TRANSCODER
v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds two new functions:
- disable_dsi_pll.
BXT DSI disable sequence and registers are
different from previous platforms.
- intel_disable_dsi_pll
wrapper function to re-use the same code for
multiple platforms. It checks platform type and
calls appropriate core pll disable function.
v2: Fixed Jani's review comments.
v3: Rebased on latest drm-nightly branch.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds new functions for BXT clock and PLL programming.
They are:
1. configure_dsi_pll for BXT.
This function does the basic math and generates the divider ratio
based on requested pixclock, and program clock registers.
2. enable_dsi_pll function.
This function programs the calculated clock values on the PLL.
3. intel_enable_dsi_pll
Wrapper function to use same code for multiple platforms. It checks the
platform and calls appropriate core pll enable function.
v2: Fixed Jani's review comments. Macros are adjusted as per convention.
v3: Removed a redundant change wrt code comment.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On BXT, We Observe timeout for forcewake request completion with 2ms polling period as given here:
[drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack request.
Polling for 50ms is recommended to avoid these timeouts.
Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD exit.
Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed by: Alex Dai <yu.dai@intel.com>.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modified HAS_CSR macro defination which earlier only supported
for skl, now added support for BXT.
v1: Initial version.
v2: Instaed of skylake/broxton check added gen9 check alone based
on review comment from Sunil.
Cc: Vetter, Daniel <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added stepping info in intel_csr.c which is required to extract
specific firmware from packaged dmc firmware.
Stepping info is aligned with current bspec info.
Cc: Vetter, Daniel <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Broxton also has dmc to manage low-power display engine state.
Path of the firmware added in intel_csr.c.
Naming convention followed as <platform>_dmc_<api-version>.bin
v1: Initial version.
v2: Commit description added based on review comment from Sunil.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On HSW at least (still testing other platforms, but should be harmless
elsewhere), the DSL reg reads back as 0 when read around vblank start
time. This ends up confusing the atomic start/end checking code, since
it causes the update to appear as if it crossed a frame count boundary.
Avoid the problem by making sure we don't return scanline_offset from
the get_crtc_scanline function. In moving the code there, I add to add
an additional delay since it could be called and have a legitimate 0
result for some time (depending on the pixel clock).
v2: move hsw dsl read hack to get_crtc_scanline (Ville)
v3: use break instead of goto (Ville)
update comment with workaround details (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Clearing the watermarks for all pipes/planes when updating the
watermarks for a single CRTC change seems like the wrong thing to
do here. As is, this code will ony update any pipe/plane watermarks
that need updating and leave the remaining set to zero. Later, the
watermark checks in check_wm_state() will flag these zero'd out pipe/plane
watermarks and throw errors.
By clearing only the watermark values associated with the specific crtc
the other watermark values may remain unchanged.
v2: Make sure all the dirty flags are cleared. Damien
Clear all values assoicated with crtc/pipe being updated. Damien
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't want random people to touch these.
Especially true since we've just screwed up SKL by holding it way too
long under the preliminary flag because of some ABI issues. And now
there's howtos all over the internets about how to set this. Same
pretty much for anything else.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: drop fastboot changes, that option is gone.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.
vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds an "Overview" DOC section plus two DOC sections for the modes
of use ("Manual switching and manual power control" and "Driver power
control").
Also included is kernel-doc for all public functions, structs and enums.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL port E handling was added in
commit 26951caf55
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date: Mon Aug 17 15:55:50 2015 +0800
drm/i915/skl: enable DDI-E hotplug
but the whole function was moved in a another branch in
commit b93433ccf6
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Aug 20 10:47:36 2015 +0300
drm/i915: move ibx_digital_port_connected to intel_dp.c
and the addition was lost at some backmerge that I was unable to
identify. Put it back in.
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix the following 'make htmldocs' warnings:
.//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder'
.//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable'
.//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder'
.//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable'
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Not the first time! not the last time?
There is a possibility to use gcc 5's -Wbool-compare to try and compare
(reg) in those macros to a constant and gcc will warn that the
comparison between a boolean expression and a constant is always either
true or false. Maybe.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We allocate memory for LVDS modes while parsing the VBT at startup, but
never free this memory when the driver is unloaded, causing a small
leak.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use the new debug info in the intel_crtc struct in these functions
rather than passing them as args.
v2: move min/max assignment back above first trace call (Ville)
use scanline from crtc->debug rather than fetching a new one (Ville)
v3: fix up trace_i915_pipe_update_end, needs end scanline (Ville)
Requested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
ioremap_cache() is currently not available on some architectures.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
I used these additional fields to track down the issue I saw on HSW.
v2: move debug fields into a substruct (Ville)
v3: clean up debug code more (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix the following 'make htmldocs' warnings:
.//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vma'
.//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vmf'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'old'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'new'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'frontbuffer_bits'
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
i915 supports enough atomic to have atomic fb-helper paths, even though
it does not yet advertise DRIVER_ATOMIC.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for using atomic code-paths for restore_fbdev_mode().
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Bikeshed comments slightly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Most interrupt flow handlers do not use the irq argument. Those few
which use it can retrieve the irq number from the irq descriptor.
Remove the argument.
Search and replace was done with coccinelle and some extra helper
scripts around it. Thanks to Julia for her help!
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
We have two identical places in the overlay code which retire the drm
framebuffer. Factor these out into a common function.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We can do better with armada_drm_crtc_complete_frame_work() - we can
avoid taking the event lock unless a call to drm_send_vblank_event()
is required, and using cmpxchg() and xchg(), we can eliminate the
locking around dcrtc->frame_work entirely.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When the CRTC is in low power mode, it isn't running, and so there's
no point keeping the CRTC clock enabled. Disable the CRTC clock during
DPMS.
We need to re-enable it in the mode_set callback to ensure that the
variant's compute_clock() continues to see its clock in the expected
state (enabled).
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use drm_plane_force_disable() to disable the overlay plane on a mode_set
rather than coding this ourselves.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Our vblank event code belongs in armada_crtc.c rather than the core of
the driver. Move it there.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Now that the transition of TDA998x to the component helpers is complete,
remove the non-componentised support from the Armada DRM driver. All
outputs are expected to use the component helpers from now on.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As reading the interrupt registers clears the outstanding interrupts, we
must process all received interrupts to avoid dropping any. Rearrange
the code to achieve this, and properly check for a HPD interrupt from
the CEC_RXSHPDINT register.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
C99 types are against the style of the Linux kernel. Convert to using
Linus-friendly types. See https://lwn.net/Articles/113367/ for more
information.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 6833d26ef8 ("drm: tda998x: Fix EDID read timeout on HDMI
connect") used a weak scheme to try and delay reading EDID on a HDMI
connect event. It is weak because delaying the notification of a
hotplug event does not stop userspace from trying to read the EDID
within the 100ms delay.
The solution provided here solves this issue:
* When a HDMI connection event is detected, mark a blocking flag for
EDID reads, and start a timer for the delay.
* If an EDID read is attempted, and the blocking flag is set, wait
for the blocking flag to clear.
* When the timer expires, clear the blocking flag and wake any thread
waiting for the EDID read.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rather than always reporting that the interrupt was handled, we should
report whether we did handle the interrupt. Arrange to report IRQ_NONE
for cases where we found nothing to do.
This allows us to (eventually) recover from stuck-IRQ problems, rather
than causing the kernel to solidly lock up.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There is no way 'priv' can be NULL in tda998x_irq_thread() - this can
only happen if request_threaded_irq() was passed a NULL priv pointer,
and we would have crashed long before then if that was the case.
We also always ensure that priv->encoder is correctly setup, which
must have been initialised prior to the interrupt being claimed, so we
can remove this check as well.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In the event that TTM doesn't find a compatible memory type for the
driver's first placement choice (placement without eviction), TTM
returns -EINVAL without trying the driver's second choice.
This causes problems on vmwgfx when VRAM is disabled before first modeset
and during VT switches when fbdev is not enabled.
Fix this by also trying the driver's second choice before returning
-EINVAL.
v2: Also check that man->use_type is true for the driver's second choice.
Fixes a bug where disallowed memory types could be used.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Shared frontbuffer bits are causing warnings when same FB is displayed
in another plane without clearing the bits from previous plane.
v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel)
Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
[danvet: Drop INTEL_FRONTBUFFER_SPRITE_MASK since unused.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This stolen reserved stuff was introduced on g4x, so no need to waste
stolen on older platforms. Unfortunately configdb is no more so I can't
look up the right way to detect this stuff. I do have one hint as to
where the register might be on ctg, but I don't have a ctg to test it,
and on the elk I have here it doesn't contain sensible looking data.
For ilk grits suggegsts it might be in the same place as on snb (the
original PCI reg, not the mirror) but I can't be entirely sure about it
The register shows a round zero on my ilk.
So when there's no really good data for any of these platforms leave the
current "assume 1MiB" approach in place.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
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>
This patch fix following warnings while "make xmldocs".
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description
found for parameter 'req'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
parameter 'request' description in 'intel_logical_ring_begin'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
parameter 'ctx' description in 'intel_logical_ring_begin'
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extend init/init_hw split to context init.
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality &
alloc/init split.
This patch is intended to split out the allocation of resources &
initialisation to allow easier reuse of code for resume/gpu reset.
v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
Left ->init_context int intel_lr_context_deferred_alloc
(Daniel Vetter)
Remove unnecessary init flag & ring type test. (Daniel Vetter)
Improve commit message (Daniel Vetter)
v3: On init/reinit, set the hw next sequence number to the sw next
sequence number. This is set to 1 at driver load time. This prevents
the seqno being reset on reinit (Chris Wilson)
v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
on reset.
This makes it obvious which bbs are which after a reset. (David Gordon
& John Harrison)
Rebase.
v5: Rebase. Fixed rebase breakage. Put context pinning in separate
function. Removed code churn. (Thomas Daniel)
v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
Issue: VIZ-4798
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This avoids some bad register writes and generally feels more correct
than unconditionally trying to redirect interrupts and such.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91777
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use WARN_ONCE in a bunch of places and demote a message that would
continually spam us.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When WaEnableForceRestoreInCtxtDescForVCS is required, it is only
safe to send new contexts if the last reported event is "active to
idle". Otherwise the same context can fully preempt itself because
lite-restore is disabled.
Testcase: igt/gem_concurrent_blit
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also check for correct revision id in each Gen9 platform (SKL until B0
and BXT until A0).
Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On the guest kernel side, previously the FIFO has been mapped write-
combined. This has worked since VMs up to now has not honored the mapping
type and mapped the FIFO cached anyway. Since the FIFO is accessed cached
by the CPU on the virtual device side, this leads to inconsistent
mappings once the guest starts to honor the mapping types.
So ask for cached mappings when we map the FIFO. We do this by
using ioremap_cache() instead of ioremap_wc(), and remove the MTRR setup.
On the TTM side, MOBs, GMRs and VRAM buffers are already requesting
cached mappings for kernel- and user-space.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.
Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This is done as a separate commit, to make it easier to revert
when things break.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of doing a hack during primary plane commit the state
is updated during atomic evasion. It handles differences in
pipe size and the panel fitter.
This is continuing on top of Daniel's work to make faster
modesets atomic, and not yet enabled by default.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet:
- simplify/future-proof if ladder that Jesse spotted
- resolve conflict in pipe_config_check and don't spuriously move the
code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The initial state is read out correctly and the state is atomic,
so it's safe to preserve the fb without any hacks if it's suitable.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It should really use the atomic state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This might not have been set during boot, and when we preserve
the initial mode this can result in a black screen.
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since commit "drm/atomic-helper: Add option to update planes only on
active crtc" the drm_atomic_helper_commit_planes() function accepts an
active_only argument to skip updating planes when the associated CRTC is
inactive. Planes being disabled on an active CRTC are incorrectly
considered as associated with an inactive CRTC and are thus skipped,
preventing any plane disabling update from reaching drivers.
Fix it by checking the state of the CRTC stored in the old plane state
for planes being disabled.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV8WvjAAoJEAhfPr2O5OEV5wIP/AjmqOau99ms4FvOQ932sO57
kKDM4CYeTBkYY2Xz2eGStgxhcEj538JTf6SXdrceEEYJHb/GNCb2iBM1TnB4YciF
rqhFv+n3R8h4Yn5KmhEhYzEfO7HUoyHPrOhcmTLzDoTO5wyrhAlPZxDWHohmfU84
uQ8WyGPYLxwm8hdZ+/NkB8PXsGbWN65EoKzN6tt2kA6HUP52UxE0Cw7Qu7Iu5zmO
y/x03mMbjhCBFFE41EeM76J+xKBhuaS4cyf8g08DJy5Zpf6ic8bKFmVg1tAFOZRD
mCETLrUlPYhglHqOoVS25bCI5kCw9xTAyjPZdQnwCTwgHl5gG3E4oJYKASrmZlps
igMSmLJEpQilsLy1Ze+K+Ci8EILmZzwbi21X0sbjq74Jd+tJZ+C8ZuWHVmPEF9j7
iHtZNIRzkzufNBJZn3DsmlGBb/Xc/UqfZVnJAB9gu3Ktav6dmtEIHrGRPpL19iYH
WtJWLt/Bpyb318K+fnxL8SzUqUxZJ4+8DrMtlgTqHmIRwVQ4CczyeWi0utQmBXEF
CaNp00S2V9N1hn8OIc+gaf7LTYJn0LkHFsskoiUZ5aZQd9ai0ql0IT1xLe0r8lMi
+ieB0Vp4wJtaodWIXOPeFugDqQXIb0Mh2M8J9FIJ116FLIai6btzO2iyVCtlR9Bg
1uPztCfJ/nusPPHnE26R
=TEFw
-----END PGP SIGNATURE-----
Merge tag 'media/v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
"A series of patches that move part of the code used to allocate memory
from the media subsystem to the mm subsystem"
[ The mm parts have been acked by VM people, and the series was
apparently in -mm for a while - Linus ]
* tag 'media/v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
[media] media: vb2: Remove unused functions
[media] media: vb2: Convert vb2_dc_get_userptr() to use frame vector
[media] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector
[media] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector
[media] vb2: Provide helpers for mapping virtual addresses
[media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
[media] mm: Provide new get_vaddr_frames() helper
[media] vb2: Push mmap_sem down to memops
Pull drm fixes from Dave Airlie:
"Just a bunch of fixes to squeeze in before -rc1:
- three nouveau regression fixes
- one qxl regression fix
- a bunch of i915 fixes
... and some core displayport/atomic fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau/device: enable c800 quirk for tecra w50
drm/nouveau/clk/gt215: Unbreak engine pausing for GT21x/MCP7x
drm/nouveau/gr/nv04: fix big endian setting on gr context
drm/qxl: validate monitors config modes
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
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.
three nouveau regression fixes.
* 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/device: enable c800 quirk for tecra w50
drm/nouveau/clk/gt215: Unbreak engine pausing for GT21x/MCP7x
drm/nouveau/gr/nv04: fix big endian setting on gr context
Typo that snuck in with commit 6979c6303a
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Reported-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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
...
This time we have aded a new capability for scatter-gathered memset using
dmaengine APIs. This is supported in xdmac & hdmac drivers
We have added support for reusing descriptors for examples like video
buffers etc. Driver will follow
The behaviour of descriptor ack has been clarified and documented
New devices added are:
- dma controller in sun[457]i SoCs
- lpc18xx dmamux
- ZTE ZX296702 dma controller
- Analog Devices AXI-DMAC DMA controller
- eDMA support for dma-crossbar
- imx6sx support in imx-sdma driver
- imx-sdma device to device support
Others
- jz4780 fixes
- ioatdma large refactor and cleanup for removal of ioat v1 and v2 which is
deprecated and fixes
- ACPI support in X-Gene DMA engine driver
- ipu irq fixes
- mvxor fixes
- minor fixes spread thru drivers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV5+nSAAoJEHwUBw8lI4NHiXQQAI/++7PmUGZ6BDZGu0B9Bj7U
JalNijm43p858nka1zVhDea8pi7Cq3zJdE8EAB7FPQGESvCODWr62oZBr+mSaQ1C
oU1RTIRTSiU2HPE4EFeGUvVGrnmTbHR2b1apI1SU41gKn+oQ5RJRRoQwEVwO6uuZ
1VYcUqhurIAZs1FrMIAUa2vg7KTcK9UotfwR2gGBmSvXMf1aJ/dNZC7i/pBJjoyt
v6KrLuYjEBAJvY7l368+NhLY/MS+2xdCMQo84B+HNEG7eA7y2MFOcRPXQA3a7dzr
NwNuAZcTYDU11r2jiAPcnBM5sPo4bokX6Td0oDbYH6Rn2uIWlof7jGIceUaWLQQq
QGZc4QPI4KdjTGNedRN8g9zqv0irFVfDr5v1A+B7N7ehvlubnB4jV8LmLpqN6UQH
B38VnDJ3hqdZ6j9RHQTyUoQskSYMPbOAUYbL0qQLkyx8AnLc8TRv7DgtSvZjnz5W
oF6So2A5SWZ7UmXKupd6TKtdyG3xtFAh+/MGVQ1RS9bCmnyhaIxJRiJwfftCBTBx
IZePOsqlwl2dojM62BDlGS4CLRZve2VgiUEJaPINsdm/On3tQs9+iDbNY3cpvLQS
P9u4po1TQPZnKG732vPAxEqdlq709kta7Fj5KIEvNjuWBBGKfypNP8BHKRvTLFlR
kcbO03NzwSO6PZpmiUsx
=gQZ6
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-4.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine updates from Vinod Koul:
"This time we have aded a new capability for scatter-gathered memset
using dmaengine APIs. This is supported in xdmac & hdmac drivers
We have added support for reusing descriptors for examples like video
buffers etc. Driver will follow
The behaviour of descriptor ack has been clarified and documented
New devices added are:
- dma controller in sun[457]i SoCs
- lpc18xx dmamux
- ZTE ZX296702 dma controller
- Analog Devices AXI-DMAC DMA controller
- eDMA support for dma-crossbar
- imx6sx support in imx-sdma driver
- imx-sdma device to device support
Other:
- jz4780 fixes
- ioatdma large refactor and cleanup for removal of ioat v1 and v2
which is deprecated and fixes
- ACPI support in X-Gene DMA engine driver
- ipu irq fixes
- mvxor fixes
- minor fixes spread thru drivers"
[ The Kconfig and Makefile entries got re-sorted alphabetically, and I
handled the conflict with the new Intel integrated IDMA driver by
slightly mis-sorting it on purpose: "IDMA64" got sorted after "IMX" in
order to keep the Intel entries together. I think it might be a good
idea to just rename the IDMA64 config entry to INTEL_IDMA64 to make
the sorting be a true sort, not this mismash.
Also, this merge disables the COMPILE_TEST for the sun4i DMA
controller, because it does not compile cleanly at all. - Linus ]
* tag 'dmaengine-4.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (89 commits)
dmaengine: ioatdma: add Broadwell EP ioatdma PCI dev IDs
dmaengine :ipu: change ipu_irq_handler() to remove compile warning
dmaengine: ioatdma: Fix variable array length
dmaengine: ioatdma: fix sparse "error" with prep lock
dmaengine: hdmac: Add memset capabilities
dmaengine: sort the sh Makefile
dmaengine: sort the sh Kconfig
dmaengine: sort the dw Kconfig
dmaengine: sort the Kconfig
dmaengine: sort the makefile
drivers/dma: make mv_xor.c driver explicitly non-modular
dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
devicetree: Add bindings documentation for Analog Devices AXI-DMAC
dmaengine: xgene-dma: Fix the lock to allow client for further submission of requests
dmaengine: ioatdma: fix coccinelle warning
dmaengine: ioatdma: fix zero day warning on incompatible pointer type
dmaengine: tegra-apb: Simplify locking for device using global pause
dmaengine: tegra-apb: Remove unnecessary return statements and variables
dmaengine: tegra-apb: Avoid unnecessary channel base address calculation
dmaengine: tegra-apb: Remove unused variables
...
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 [51e1d83cab99: 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 [51e1d83cab99: 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>
The BIOS sometimes likes to enable pipes w/o any ports, at least on
older machines. Currently we fail to assign anything sensible to
crtc->hwmode.crtc_clock which leads to complaints from the vblank code.
Deal with active pipes w/o ports and assign something sensible to
crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will
override this if the port is enabled.
Gets rid of rest of these on my gen4:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 1 is disabled
v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten)
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>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At various points when changing the DPIO lane/phy power states,
construct an expected value of the DISPLAY_PHY_STATUS register
and compare it with the real thing.
To construct the expected value we look at our shadow PHY_CONTROL
register value (which should match what we've just written to the
hardware), and we also need to look at the actual state of the cmn
power wells as a disabled power well causes the relevant LDO status
to be reported as 'on' in DISPLAY_PHY_STATUS.
When initially powering up the PHY it performs various internal
calibrations for which it fully powers up. That means that if we check
for the expetected power state immediately upon releasing cmnreset we
would get the occasional false positive. But we can of course
poll until the expected value appears. It shouldn't be too long so
this shouldn't make modesets substantially longer.
One extra complication is introduced when we cross the streams, ie.
drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
into life by temporaily powering up the lanes in the second channel,
and once the pipe is up and runnign we release the lane power override.
At that point the power state of CL2 has somehow gotten entangled with
the power state of the first channel. That means that constructing the
expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
lane power states in the second channel, CL2 should also be powered
down. But we can use the DPLL enable bit to determine when CL2 should
be alive even if the lanes are powered down. However the power state
of CL2 isn't actually tied in with the DPLL state, but to the state
of the lanes in first channel, so we have to avoid checking the
expected state between shutting down the DPLL and powering down
the lanes in the first channel. So no calling assert_chv_phy_status()
before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
but after the write is a safe time to check.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add some checks that the state of the DPIO lanes is more or less what we
expect based on the overrides.
The hardware only provides two bits per channel indicating whether all
or some of the lanes are powered down, so we can't do an exact check.
Additionally, CL2 powering down before we can check it adds another
twist. To work around this we simply check for the 0 value of the
CL2 register (which is what we get when it's powered down) and
adjust our expectations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we release the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.
The one confusing thing in this is that when we remove the power down
override from the lanes, they power up with defaul register values,
which do not have the soft reset overrides enabled. And according to
some docs by default the data lane resets are tied to cmnreset. So that
would mean that lanes would come out of reset without staggering as
soon as the power down overrides are removed. But since we can't access
either the lane stagger register nor the soft reset override registers
until the lanes are powered on, we can't really do anything about it.
So let's just set the soft reset overrides as soon as the lane is
powered on and hope for the best.
v2: Fix typos in commit message (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The DP MST encoder config function never sets ddi_pll_sel, even though
its value is programmed in its ->pre_enable() hook. That used to work
because a new pipe_config was kzalloc'ed at every modeset, and the value
of zero selects the highest clock for the PLL. Starting with the commit
below, the value of ddi_pll_sel is preserved through modesets, and since
the correct value wasn't properly setup by the MST code, it could lead
to warnings and blank screens.
commit 8504c74c7a
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri May 15 11:51:50 2015 +0300
drm/i915: Preserve ddi_pll_sel when allocating new pipe_config
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628
Cc: stable@vger.kernel.org # 7e6313a251 drm/i915: Don't use link_bw for PLL setup
Cc: stable@vger.kernel.org
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This was forgotten in
commit d351f6d948
Author: Francisco Jerez <currojerez@riseup.net>
Date: Fri May 29 16:44:15 2015 +0300
drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/intel_dp_tps/drm_dp_tps/.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.
v2: Fix typo in commit message (Sivakumar)
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from future.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Applications like gnome-shell may try to render after dropping master
privileges. Since the driver should now be safe against this scenario,
allow those applications to use their legacy node like a render node.
v2: Add missing return statement.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Commit ec9f932ed4
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
Changes since v1:
- Fix -EDEADLK handling of vblank events too.
- Free state last with CHECK_ONLY.
Changes since v2:
- Add comment about freeing crtc_state->event with TEST_ONLY.
(Daniel Stone)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 92122789b2 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.
However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.
Due to 92122789b2 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.
Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).
Fix this by moving the code introduced by 92122789b2 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.
Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Fixes: 92122789b2 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
and the addition of new clock drivers. Stephen Boyd has also done a lot
of subsystem-wide driver clean-ups (thanks!). There are also fixes to
the framework core and changes to better split clock provider drivers
from clock consumer drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV5KelAAoJEKI6nJvDJaTUwaQP/RVb70v6XSgMIePuOq3iaECT
bclCAyito3YFwykrPPmQ1DucHvEjlWopeFwKqEE9VjNl07TVIH/OMGeonb9yErIY
aN+FMoA9RUGVexMhy004q5sSbOEihAqTgKWaOiYoY8zAfJfeTpYXUoy34FcrW7MB
j/cDDJgigtWe9zzcdrW04oT454lXQaSQuGX39tDCR0s0S3soYU2JyjkyBGiO5Yid
1yIMq/nzI8SrCwxwD/nFwQNtg7lqiAN291Nbi4At1vvG5r4RhNveuLGv8uJ50XRB
xwy0sdHLIVJrIJ8OUcs1sY8wxu7ghDS8u+vjTNO2RzBf3KZWbuXWX+yVM7JQi4Ty
0iL5hGbvERy5E9QSzzH+Ox2jVt5e/r/dyvRf3oBDPVrFXhKusYhn6JmdUVJkTZ83
GTw2sQdEpcmry4z/50/MaqpZuXVZ09VTOCTqp8ToseJjsz9jXxVhQ4HdAwLc8cmV
txWGRXuBxCB+2o8M0oky3IKS69VFFH5u6QQ0KG8+JYOrDDG7GcnJsFeV7mQjlu8g
3evYUILNAUfJGBpkOeLs654KUBHwUyXc87cUIKwjGaPruWb2048+kdCVrL3IFwPb
sS/7Qn3DQ90pHFUTssDnWLz3X0IWT3H0iV4zZyAqqdARugEo+mpykmXmMWcWc3VR
MrD1l3GVxLegEf242Zpo
=QAiQ
-----END PGP SIGNATURE-----
Merge tag 'clk-for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk updates from Michael Turquette:
"The clk framework changes for 4.3 are mostly updates to existing
drivers and the addition of new clock drivers. Stephen Boyd has also
done a lot of subsystem-wide driver clean-ups (thanks!). There are
also fixes to the framework core and changes to better split clock
provider drivers from clock consumer drivers"
* tag 'clk-for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (227 commits)
clk: s5pv210: add missing call to samsung_clk_of_add_provider()
clk: pistachio: correct critical clock list
clk: pistachio: Fix PLL rate calculation in integer mode
clk: pistachio: Fix override of clk-pll settings from boot loader
clk: pistachio: Fix 32bit integer overflows
clk: tegra: Fix some static checker problems
clk: qcom: Fix MSM8916 prng clock enable bit
clk: Add missing header for 'bool' definition to clk-conf.h
drivers/clk: appropriate __init annotation for const data
clk: rockchip: register pll mux before pll itself
clk: add bindings for the Ux500 clocks
clk/ARM: move Ux500 PRCC bases to the device tree
clk: remove duplicated code with __clk_set_parent_after
clk: Convert __clk_get_name(hw->clk) to clk_hw_get_name(hw)
clk: Constify clk_hw argument to provider APIs
clk: Hi6220: add stub clock driver
dt-bindings: clk: Hi6220: Document stub clock driver
dt-bindings: arm: Hi6220: add doc for SRAM controller
clk: atlas7: fix pll missed divide NR in fraction mode
clk: atlas7: fix bit field and its root clk for coresight_tpiu
...
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.
In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.
Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.
This patch also fix the DDI-E hotplug function.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.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 radeon non-atom aux path
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Enable eDP on DDI-E.
Also let's remove duplicated definitions to avoid later confusion.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There are OEMs using DDI-E out there,
so let's enable it.
Unfortunately there is no detection bit for DDI-E
So we need to rely on VBT for that.
I also need to give credits to Xiong since before seing
his approach to check info->support_* I was creating an ugly
vbt->ddie_sfuse_strap in order to propagate the ddi presence info
v2: Rebased as last patch in the series. since all other patches
in this series are needed for anything working propperly on DDI-E.
Credits-to: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
v3: MISSING_CASE take place of BUG()
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit da2bc1b9db
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Oct 23 19:23:26 2014 +0300
drm/i915: add poweroff_late handler
introduced a regression on old platforms during hibernation. A workaround was
added in
commit ab3be73fa7
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Mar 2 13:04:41 2015 +0200
drm/i915: gen4: work around hang during hibernation
using an explicit blacklist for the GENs/BIOS vendors where the issue was
reported. Later there we had reports of the same failure on platforms not on
this list.
To my best knowledge the correct thing to do is still to put the device to PCI
D3 state during hibernation, see [1] and [2] for the reasons. This also aligns
with our future plans to unify more the runtime and system suspend/resume
paths. Since an exact blacklist seems to be impractical (multiple GENs and
BIOS vendors are affected) apply the workaround on everything pre GEN6.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html
[2] https://lkml.org/lkml/2015/6/22/274
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061
Reported-by: Ilya Tumaykin <itumaykin@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Reported-by: Pavel Machek <pavel@ucw.cz>
Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Reported-by: Paul Bolle <pebolle@tiscali.nl>
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.
If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.
Also remove the leftover comment that referred to the old retraining
from .hot_plug().
Fixes a regression introduced in:
commit 0e32b39cee
Author: Dave Airlie <airlied@redhat.com>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Tested-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This is a second pull-request which adds last part of
atomic modeset/pageflip support, render node support,
clean-up, and fix-up.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: fix build warning to exynos_drm_gem.c
drm/exynos: Properly report supported formats for each device
drm/exynos: add render node support
drm/exynos: implement atomic_{begin/flush} of DECON
drm/exynos: remove legacy ->suspend()/resume()
drm/exynos: Enable atomic modesetting feature
drm/exynos: remove wait queue for pending page flip
drm/exynos: wait all planes updates to finish
drm/exynos: add atomic asynchronous commit
drm/exynos: fimd: only finish update if START == START_S
drm/exynos: add macro to get the address of START_S reg
drm/exynos: check for pending fb before finish update
drm/exynos: fimd: move window protect code to prepare/cleanup_plane
drm/exynos: add prepare and cleanup phases for planes
drm/exynos: fimd: unify call to exynos_drm_crtc_finish_pageflip()
drm/exynos: don't track enabled state at exynos_crtc
Some i915 fixes headed for v4.3. SKL DDI-E is a wip, but here's the
first in a series.
* tag 'drm-intel-next-fixes-2015-08-28' of git://anongit.freedesktop.org/drm-intel:
drm/i915/skl: enable DDI-E hotplug
drm/i915: Fix build warning on 32-bit
drm/i915/skl: Update DDI buffer translation programming.
drm/i915: Allow parsing of variable size child device entries from VBT
drm/i915: fix link rates reported for SKL
drm/i915: fix VBT parsing for SDVO child device mapping
Exynos DRM reported that all planes for all supported sub-devices supports
only three pixel formats: XRGB24, ARGB24 and NV12. This patch lets each
Exynos DRM sub-drivers to provide the list of supported pixel formats
and registers this list to DRM core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch allows clients who want to use render node to access
rendering relevant ioctls - g2d, post processor and gem allocation.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
registers to active register in the functions. This patch achieves these
purpose by moving the setting of protection bits to those functions from
decon_update_plane.
v2: rebased to the branch exynos-drm-next
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
These legacy helpers should only be used by shadow-attaching drivers.
KMS drivers has its own way to handle suspend/resume and don't need to
use these two helpers.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <daeinki@gmail.com>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Now that atomic modesetting is implemented for exynos enable the
DRIVER_ATOMIC flag on the driver's features.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Exynos atomic commit procedures already does this job of waiting for
pending updates to finish, that means using pending_flip_queue is
pointless now because the disable CRTC procedure will never happen
during a page_flip.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Add infrastructure to wait for all planes updates to finish by using
an atomic_t variable to track how many pending updates we are waiting
plus a wait_queue for the wait part.
It also changes vblank behaviour and keeps it enabled for all types
of updates
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will now schedule a work task to run the update later.
It also serializes commits that needs to run on the same crtc, putting the
following commit to wait until the current one is finished.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
fimd_update_plane() programs BUF_START[win] and during the update
BUF_START[win] is copied to BUF_START_S[win] (its shadow register)
and starts scanning out, then it raises a irq.
The fimd_irq_handler, in the case we have a pending_fb, will check
the fb value was copied to START_S register and finish the update
in case of success.
Based on patch from Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The current code was ignoring the end of update for all overlay planes,
caring only for the primary plane update in case of pageflip.
This change adds a change to start to check for pending updates for all
planes through exynos_plane->pending_fb. At the start of plane update the
pending_fb is set with the fb to be shown on the screen. Then only when to
fb is already presented in the screen we set pending_fb to NULL to
signal that the update was finished.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
fixup! drm/exynos: check for pending fb before finish update
Only set/clear the update bit in the CRTC's .atomic_begin()/flush()
so all planes are really committed at the same time.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
.prepare_plane() and .cleanup_plane() allows to perform extra operations
before and after the update of planes. For FIMD for example this will
be used to enable disable the shadow protection bit.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Unify handling of finished plane update to prepare for a following patch
that will check for the START and START_S regs to really make sure that
the plane was updated.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
struct drm_crtc already stores the enabled state of the crtc
thus we don't need to replicate enabled in exynos_drm_crtc.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The latter is a default version of <asm/mman.h> and not for driver use.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Saving the current UVD state on suspend and restoring it on resume
just doesn't work reliable. Just close cleanup all sessions on suspend.
Ported from radeon commit "12e49feadff6d7b7ebbe852b36943a71524d8d34".
v2: rebased
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
This way the scheduler doesn't wait in it's work thread any more.
v2: fix race conditions
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiong Y Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The copyright header in nvkm/engine/device/platform.c has been replaced
with the NVIDIA one from drm/nouveau_platform.c, as most of the actual
code is now theirs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Doesn't fix any known issue, but best be safe in case control is handed
to us from firmware with these left enabled.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This ensures we have a valid mask of disabled engines before we start
trying to execute fini()/init() on the subdevs, potentially touching
devices that don't exist.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
An upcoming commit requires being able to modify the PRAMIN BAR page
tables while already holding the MMU subdev mutex.
To solve this issue, each VM has been given its own mutex. As a nice
side-effect, this also allows separate VMs to be updated concurrently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A variety of tweaks to the NVIF library interfaces, mostly ripping out
things that turned out to be not so useful.
- Removed refcounting from nvif_object, callers are expected to not be
stupid instead.
- nvif_client is directly reachable from anything derived from nvif_object,
removing the need for heuristics to locate it
- _new() versions of interfaces, that allocate memory for the object
they construct, have been removed. The vast majority of callers used
the embedded _init() interfaces.
- No longer storing constructor arguments (and the data returned from
nvkm) inside nvif_object, it's more or less unused and just wastes
memory.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Replaces the piece-by-piece (in response to NV_DEVICE ctor args) device
contruction with a once-off all-or-nothing approach, eliminating some
tricky refcounting issues. The partial device init capability was only
required by some tools, and has been moved to probe time instead.
Temporarily removes a workaround for some boards where we need to fiddle
with AGP registers before executing the DEVINIT scripts. A later commit
in this series reinstates it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These require an explicit struct nvkm_gpuobj pointer, unlike the previous
macros which take a void *, and work with any nvkm_object.
New semantics require acquiring/releasing a gpuobj before accessing them,
which will be made use of in later patches to greatly reduce the overhead
of accesses, particularly when a direct mmio mapping of the object is not
available (suspend/resume, out of ioremap() space, and on GK20A).
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Anatoli Antonovitch