Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.
v2:
[Jani] Added 2nd set of PPS registers and the macro
Jani's review comments
- remove reference in i915_suspend.c
- Use BXT PP macro
Squashing all PPS related patches into one.
v3: Jani's review comments addressed
- Use pp_ctl instead of pp
- ironlake_get_pp_control() is not required for BXT
- correct the use of && in the print statement
- drop the shift in the print statement
v4: Jani's comments
- modify ironlake_get_pp_control() - dont set unlock key for bxt
v5: Sonika's comments addressed
- check alignment
- move pp_ctrl_reg write (after ironlake_get_pp_control())
to !IS_BROXTON case.
- check before subtracting 1 for t11_t12
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fixes and virtio-vga support.
* 'virtio-gpu-drm-next' of git://git.kraxel.org/linux:
virtio-gpu: add locking for vbuf pool
drm/virtgpu: initialise fbdev after getting initial display info
Add virtio-vga bits.
This contains fixes for the long-standing build issues that some of the
bridge drivers were exposing. Other than that it's mostly cleanup and a
couple of new simple panels that are supported.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVevAhAAoJEN0jrNd/PrOhuokQAL/sac6eVn1KSH0e1oYR9dib
4qdwP3YwO0C5KyqMcN5LCYUXuAsiSIUuEdhsXvvCiFIwuZfkZwBe+oA9rm0NzFBG
45fgICpPq93Cwt1PKU0ELDpkgJqog7FV91tMpZosTTJbCe1E1KYxSO5TkS/XAaoq
wrb+M0hWxybHscSD+rdoqNPfC7sFS3UTxCaXE6CkUGSVZ9desGp7iwmWVxBsSuow
t7PUyjz02+sPgkaBaVzEk3ynJ52GQz+GB0lbmDkrUd0t7wVV9GY/si7GTsH+4olX
6jPJDJZoshH97FFYsz7QGLC3owiuGaEOApSaI/vkGShLNVz+LFPQQQVENRwxqxr3
GOR6OzElfQyuBCRWNFo1owPTqVPT4S/eiLYD3IFoDlxOteiNB/yVnDYZKcK6tISX
A/S1uXzX26xxf6SOxe+PcoM+7Q/EFU9iG0xLPaEBgs0ly0pfWuyWhOCmhoqKzYqa
ZkkKbKsRc5gZGEArZD3WaHx7SND6ahiKYR6mTzzflhDrHDj2PUNc7Knw2BxgJg12
UxF3tPmL10zA8I/2dektfm1W0nWwtieQEUNpi5PsWMjNWpL9U3MWKVuEKHGZfY4M
gONC6K4lOLWwF02kSYuKXYoCwvHtgSYopw5O+Cr285h50ZYP3D0ylhL3PuF5PDYW
dpRANnj0z4YJG5wRgiNN
=4rJg
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.2-rc1
This contains fixes for the long-standing build issues that some of the
bridge drivers were exposing. Other than that it's mostly cleanup and a
couple of new simple panels that are supported.
* tag 'drm/panel/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Add bus format for HannStar HSD100PXN1
drm/panel: simple: Add display timing for HannStar HSD100PXN1
drm/panel: ld9040: Remove useless padding
drm/panel: Constify OF match tables
drm/bridge: Remove stale ptn3460.h include
drm/bridge: ps8622: Include linux/gpio/consumer.h
drm/bridge: ptn3460: Include linux/gpio/consumer.h
drm/bridge: dw-hdmi: Return number of EDID modes
drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel
drm/bridge: ptn3460: Pass flags to devm_gpiod_get()
drm/bridge: ps8622: Pass flags to devm_gpiod_get()
drm/bridge: ptn3460: Fix I2C ID table to match the reported modalias
drm/bridge: dw-hdmi: Staticize dw_hdmi_bridge_funcs
This contains a couple of mostly fixes for issues that have crept up in
recent versions of linux-next. One issue is that DP AUX transactions of
more than 4 bytes will access the wrong FIFO registers and hence become
corrupt. Another fix is required to restore functionality of Tegra20 if
using the GART. The current code expects the IOMMU aperture to be the
complete 4 GiB address space, whereas the GART on Tegra20 only provides
a 128 MiB aperture. One more issue with IOMMU support is that on 64-bit
ARM, swiotlb is the default IOMMU implementation backing the DMA API. A
side-effect of that is that when dma_map_sg() is called to flush caches
(yes, this is a bit of a hack, but ARM does not provide a better API),
swiotlb will immediately run out of memory because its bounce buffer is
too small to make a framebuffer.
Finally I've included a mostly cosmetic fix that stores register values
in u32 rather than unsigned long to avoid sign-extension issues on 64-
bit ARM. This is only a precaution since it hasn't caused any issues
(yet).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVeu52AAoJEN0jrNd/PrOhQbEQAIqhhiQdQKBXkgCNZDflqUT9
qN0PkFAlZF+pftDUCqvQg5nN5INWPEqUuzd2UAXPxXBFeRr8YabFN6SgK+/3XDYE
+5tFyADFAm9CJhxFWpoIm7uWFEWbbGPKsokNe4WUdmYMIkROuztTodFw/lAkd1rM
WNMbCbC9qx8HaHZMA5wnQRhWMlpY+o7TahYYYjroiHlHBYJgcEgigQb7d5pyrbG3
10jJT3xx78+gN04RuMg4z6HJ9SjuuhWgKEoI7fr0EyTfIdQ390MLDh/SEnX4YeRr
o3Ww+nkaKG+iENK8GNwJ8w6s7w5X1QiMLB6t0ShU29khUMaCkz9Swr5OsCONUTD7
bEV17B5HNpAgQtWjqiF/YW9b4xe3PQJW0fU6MFkcyo7dZCm1o64tY0u4dCa7WqMb
55NNXkoYpod3VT7S5+qg1ghIEg1NJTxvH41FwkAKZvd4BTO6Jn97GJdGokb+NRsn
WkpR/q+kxcHkuFTxK/SRuG7nT7ss6jrZNTDo2aitX8sxs1VW5lgLlMBg1SkafC6S
N0t5g+jM1j4j/BETBJjZI+VeyeVZcgQPeO+DaDOEp6TIvMxb3l8ox8LCjtxRbU89
Z+s0y3HL2//vjPh7AMK4Dy5weyfX3LT5c93JJBClhregCYczFG6tcfa1vfiyw9Bo
cwI90g4aC4xi41m+INbt
=3vlA
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.2-rc1
This contains a couple of mostly fixes for issues that have crept up in
recent versions of linux-next. One issue is that DP AUX transactions of
more than 4 bytes will access the wrong FIFO registers and hence become
corrupt. Another fix is required to restore functionality of Tegra20 if
using the GART. The current code expects the IOMMU aperture to be the
complete 4 GiB address space, whereas the GART on Tegra20 only provides
a 128 MiB aperture. One more issue with IOMMU support is that on 64-bit
ARM, swiotlb is the default IOMMU implementation backing the DMA API. A
side-effect of that is that when dma_map_sg() is called to flush caches
(yes, this is a bit of a hack, but ARM does not provide a better API),
swiotlb will immediately run out of memory because its bounce buffer is
too small to make a framebuffer.
Finally I've included a mostly cosmetic fix that stores register values
in u32 rather than unsigned long to avoid sign-extension issues on 64-
bit ARM. This is only a precaution since it hasn't caused any issues
(yet).
* tag 'drm/tegra/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: dpaux: Registers are 32-bit
drm/tegra: gem: Flush pages after allocation
drm/tegra: gem: Take into account IOMMU aperture
drm/tegra: dpaux: Fix transfers larger than 4 bytes
rcar-du fixes
* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev:
drm: rcar-du: Use the drm atomic state duplication helpers for planes
drm: rcar-du: Clean up planes in the error paths of .atomic_commit()
drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0
drm: rcar-du: Clarify error message when encoder initialization fails
drm: rcar-du: Fix crash with groups that have less than 9 planes
drm: rcar-du: Disable all planes when stopping the CRTC
drm: rcar-du: Print the error value when DRM/KMS init fails
- Dan fixed some range checks in the address watch ioctl impl.
- Remove obsolete member from radeon_device structure
* tag 'drm-amdkfd-next-fixes-2015-06-16' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: fix some range checks in address watch ioctl
drm/radeon: remove obsolete kfd_bo from radeon_device
We need to call drm_atomic_set_mode_for_crtc() rather than copying the
mode in manually. As of commit
commit 99cf4a29fa
Author: Daniel Stone <daniels@collabora.com>
Date: Mon May 25 19:11:51 2015 +0100
drm/atomic: Add current-mode blob to CRTC state
the helper now also takes care of setting up the mode property blob for
us; if we don't use the helper and never setup the mode blob, this will
also trigger a failure in drm_atomic_crtc_check() when we have the
DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support
via i915.nuclear_pageflip kernel command line parameter).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The code in intel_crtc_restore_mode() sets the enabled value of all the
CRTCs when restoring the mode after a suspend/resume cycle. When more
than one CRTC is enabled, that causes drm_atomic_helper_check_modeset()
to fail if there is more than one pipe enabled, since all but one CRTC
has valid connector data. Instead, set only the enabled value for the
CRTC passed as an argument.
v2: Don't leak atomic state. (Matt)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90468
References: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
The force restore path relies on the staged config to preserve the
configuration used before a suspend/resume cycle. The update done to it
in intel_modeset_fixup_state() would cause that information to be lost
after the first modeset, making it impossible to restore the modes for
pipes B and C.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90468
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since the force restore logic will restore the CRTCs state one at a
time, it is possible that the state will be inconsistent until the whole
operation finishes. A call to intel_modeset_check_state() is done once
it's over, so don't check the state multiple times in between. This
regression was introduced in:
commit 7f27126ea3
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Nov 5 14:26:06 2014 -0800
drm/i915: factor out compute_config from __intel_set_mode v3
v2: Rename check parameter to force_restore. (Matt)
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
buf_size_in_bytes must be large enough to hold ->num_watch_points and
watch_mode so I have added a sizeof(int) * 2 to the minimum size.
Also we have to subtract sizeof(*args) from the max args_idx limit so
that it matches the allocation. Also I changed a > to >= for the last
compare.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Ensure that the duplicate and destroy plane state operations will always
be in sync with the DRM core implementation of the plane state by using
the __drm_atomic_helper_plane_duplicate_state() and
__drm_atomic_helper_plane_destroy_state() functions designed especially
for this purpose.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
When the .atomic_commit() handler fails, clean up planes previoulsy
prepared by drm_atomic_helper_prepare_planes() with a call to
drm_atomic_helper_cleanup_planes().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The function returns 1 on success, and either 0 or a negative error code
on failure. As the 0 and negative values don't need to be differentiated
by the caller, convert it to the usual scheme of returning 0 on success
and a negative error code on failure.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
A failure to initialize an encoder currently prints an error message in
the kernel log without mentioning which encoder failed to initialize. To
help debugging initialization issues print the encoder DT node name.
This requires moving the error message to the rcar_du_encoders_init_one
function and refactoring it slightly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Commit 917de18037 ("drm: rcar-du: Implement universal plane support")
made the number of planes per group dynamic, but didn't update all loops
over the planes array, resulting in out-of-bound accesses on DU
instances that have an odd number of CRTCs (such as the R8A7790). Fix
it.
Fixes: 917de18037 ("drm: rcar-du: Implement universal plane support")
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The DSnPR plane configuration registers are updated on vblank, and no
vblank will occur once the CRTC is stopped. We thus can't only disable
planes right before starting the CRTC as it would start scanning out
immediately from old frame buffers until the next vblank.
Fix the problem by disabling all planes when stopping the CRTC and wait
for the change to take effect. This increases the CRTC stop delay,
especially when multiple CRTCs are stopped in one operation as we now
wait for one vblank per CRTC. Whether this can be improved needs to be
researched.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
This should avoid issues with the fbdev path trying to render
before we've gotten the display info.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ kraxel: wait for display-info reply ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Atomic modesetting support for omapdrm.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVfrehAAoJEPo9qoy8lh71/MUP/0bepCd6YfO4jGtxFFqhtpkN
1l1yooLcZAxmaWL4rFmY6+fpkuasICNAMQRWOqbHO32q+fdip5eFv3a2qHyCjM/M
bpXOzDEqafqQMOEnsdRRUpcPiznbRhYCWcgLEkvN8pkrCCOJyXSgUiNR18i0Td7/
UXS4Bk6vB0u+WbNHgXByY8q2Rlgxk829Znkoib0On+dwJGF/mKh/NJQvuiWQ9f/R
S2XyaNM6xWxAJd/fjHEfoIhZ7GX3OaCk/KMEBFI2Dud4N2M0dRyp0APu11vbEopy
b5cTxpYcHfCKjOtlB5Ckbv/Hv/iszhP24BFSMIfC+9EH92PibmX8Nx+DqWpo3+tI
5UX2++q1K639ba6ZwdQzaCskRur4ZslCOmsMOuSDh7oy3Su8qIgnhHuS3jSyp5JH
BuoyT2Rgw3OxToHAvc1/kPdXCDo/qVwYZzmQFEcIPjdtFY1J9vSTK2k2nmbsIoB2
RLyorKJ4L25Y5mEBXVzOAWE0wjvRbsAvWaFUGm/OJ7aPS3tfTGyi3TcjjvOmL+c0
xcDKtARJzL9WQR0fMkRvAUc3JzkwVownZRZpuw8Z3TpguaQwaVxbsiVm0wivxpko
b1KKZFPzgi8CIX+cIBCGXe1UrPPUgblUKOlmVHM6G+63tAlD/WvdjXUr0VVkp3Ob
sAh9UOSdefqcd+dcUE59
=PlyA
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
omapdrm atomic modesetting support
Atomic modesetting support for omapdrm.
" we've had issues with omapdrm for years,
which we've not been able to fix properly (like warnings/crashes when unloading
modules, page-flips tearing, race issues with fbs). All those problems seem to
be gone after this rewrite of omapdrm for atomic modesetting, and the resulting
code is much cleaner and more maintainable."
* tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (43 commits)
drm: omapdrm: new vblank and event handling
drm: omapdrm: merge omap_crtc_flush and omap_crtc_atomic_flush
drm: omapdrm: add lock for fb pinning
drm: omapdrm: if omap_plane_atomic_update fails, disable plane
drm: omapdrm: inline omap_plane_setup into update/disable
drm: omapdrm: omap_plane_setup() cannot fail, use WARN
drm: omapdrm: Don't setup planes manually from CRTC .enable()/.disable()
drm: omapdrm: Don't flush CRTC when enabling or disabling it
drm: omapdrm: Move encoder setup to encoder operations
drm: omapdrm: Simplify DSS power management
drm: omapdrm: Remove nested PM get/sync when configuring encoders
drm: omapdrm: Support unlinking page flip events prematurely
drm: omapdrm: omap_crtc_flush() isn't called with modeset locked
drm: omapdrm: Don't get/put dispc in omap_crtc_flush()
drm: omapdrm: Make the omap_crtc_flush function static
drm: omapdrm: Remove omap_plane enabled field
drm: omapdrm: Remove omap_crtc enabled field
drm: omapdrm: Move crtc info out of the crtc structure
drm: omapdrm: Move plane info and win out of the plane structure
drm: omapdrm: Switch crtc and plane set_property to atomic helpers
...
Leftover from the big purge
commit a561165493
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Thu Mar 5 14:03:03 2015 +0000
drm/i915: Remove ironlake rc6 support
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Reported-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Limit CHV maximum cdclk to 320MHz.
v2: Rebase to the latest
v3: Clean up of if-else tree
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is just to make the intentions explicit: on HSW+ these
bits are MBZ, but since we only support plane A and the macro
evaluates to zero when plane A is the parameter, we're not fixing any
bug.
v2:
- Remove useless extra blank like (Chris).
- Init dpfc_ctl in another place (Chris).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit has two main advantages: simplify intel_fbc_update()
and deduplicate the strings.
v2:
- Rebase due to changes on P1.
- set_no_fbc_reason() can now return void (Chris).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because we're currently using FBC_UNSUPPORTED_MODE for two different
cases.
This commit will also allow us to write the next one without hiding
information from the user.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already had a few bugs in the past where FBC was compressing
nothing when it was enabled, which makes the feature quite useless.
Add this information to debugfs so the test suites can check for
regressions in this piece of the code.
Our igt/tests/kms_frontbuffer_tracking already has support for this
message.
v2: - Remove pointless VLV check (Ville).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The docs don't support the 64k linear scanout alignment we impose
on gen2/3. And it really makes no sense since we have no DSPSURF
register, so the only thing that the hardware will see is the linear
offset which will be just pixel aligned anyway.
There is one case where 64k comes into the picture, and that's FBC.
The start of the line length buffer corresponds to a 64k aligned
address of the uncompressed framebuffer. So if the uncompressed fb is
not 64k aligned, the first actually used entry in the line length
buffer will not be byte 0. There are 32 extra entries in the line
length buffer to account for this extra alignment so we shouldn't
have to worry about it when mapping the uncompressed fb to the GTT.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV
docs got updated at some point to say that we need to align them to
128k, just like we do on gen4.
So far I've seen the problem manifest when the stride is an odd multiple
of 512 bytes, and the surface address meets the following pattern
'(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The
result is a starcase effect (so some pages get dropped maybe?), with a
few pages here and there clearly getting scannout out at the wrong position.
I've not actually been able to reproduce this problem on gen4, so it's
not clear of the issue is any way related to the 128k restrictions
supposedly inherited from gen4. But let's hope the 128k alignment is
sufficient to hide it all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently intel_gen4_compute_page_offset() simply picks the closest
page boundary below the linear offset. That however may not be suitably
aligned to satisfy any hardware specific restrictions. So let's make
sure the page boundary we choose is properly aligned.
Also to play it a bit safer lets split the remaining linear offset into
x and y values instead of just x. This should make no difference for
most platforms since we convert the x and y offsets back into a linear
offset before feeding them to the hardware. HSW+ are different however
and use x and y offsets even with linear buffers, so they might have
trouble if either the x or y get too big.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Corrected the documentation on the intel_edp_drrs_flush and
intel_edp_drrs_invalidate.
And accordingly edp_drrs_flush function is modified to restart the idleness
detection after upclocking.
v2: Update kerneldoc
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1)
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The i915 atomic conversion is a real beast and it's not getting easier
wrangling in a separate branch. I'm might be regretting this, but
right after vacation nothing can burst my little bubble here!
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In igt, we want to test handling of GPU hangs, both for recovery
purposes and for reporting. However, we don't want to inject a genuine
GPU hang onto a machine that cannot recover and so be permenantly
wedged. Rather than embed heuristics into igt, have the kernel report
exactly when it expects the GPU reset to work.
This can also be usefully extended in future to indicate different
levels of fine-grained resets.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tim Gore <tim.gore@intel.com>
Cc: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’:
drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’
atomic_read(&dev->dev->power.usage_count));
Regression from commit a6aaec8be2
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Jun 4 18:23:58 2015 +0100
drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be
set because of security-sensitive bits we don't want userspace to mess
with. On HSW hardware the whitelisted bits control whether atomic
read-modify-write operations are performed on L3 or on GTI, and when
set to L3 (which can be 10x-30x better performing than on GTI,
depending on the application) require great care to avoid a system
hang, so we currently program them to be handled on GTI by default.
Beignet can immediately start taking advantage of this change to
enable L3 atomics. Mesa should eventually switch to L3 atomics too,
but a number of non-trivial changes are still required so it will
continue using GTI atomics for now.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In some cases it might be unnecessary or dangerous to give userspace
the right to write arbitrary values to some register, even though it
might be desirable to give it control of some of its bits. This patch
extends the register whitelist entries to contain a mask/value pair in
addition to the register offset. For registers with non-zero mask,
any LRM writes and LRI writes where the bits of the immediate given by
the mask don't match the specified value will be rejected.
This will be used in my next patch to grant userspace partial write
access to some sensitive registers.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Until now the software command checker assumed that commands could
read or write at most a single register per packet. This is not
necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length
list of offset/value pairs and writes them in sequence. The previous
code would only check whether the first entry was valid, effectively
allowing userspace to write unrestricted registers of the MMIO space
by sending a multi-register write with a legal first register, with
potential security implications on Gen6 and 7 hardware.
Fix it by extending the drm_i915_cmd_descriptor table to represent
multi-register access and making validate_cmd() iterate for all
register offsets present in the command packet.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I noticed one of those and it turned out we have a few lingering around.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's handy to have debug message for the "big" events and this one
qualifies IMHO. Also helpful to see what's happening while we're loading
the firwmare and how much time it takes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Linux, macros are usually well done and protect their arguments
properly, even avoiding multiple evaluations of the parameters. Extra ()
are really not needed.
Cc: Suketu Shah <suketu.j.shah@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be
set because of security-sensitive bits we don't want userspace to mess
with. On HSW hardware the whitelisted bits control whether atomic
read-modify-write operations are performed on L3 or on GTI, and when
set to L3 (which can be 10x-30x better performing than on GTI,
depending on the application) require great care to avoid a system
hang, so we currently program them to be handled on GTI by default.
Beignet can immediately start taking advantage of this change to
enable L3 atomics. Mesa should eventually switch to L3 atomics too,
but a number of non-trivial changes are still required so it will
continue using GTI atomics for now.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases it might be unnecessary or dangerous to give userspace
the right to write arbitrary values to some register, even though it
might be desirable to give it control of some of its bits. This patch
extends the register whitelist entries to contain a mask/value pair in
addition to the register offset. For registers with non-zero mask,
any LRM writes and LRI writes where the bits of the immediate given by
the mask don't match the specified value will be rejected.
This will be used in my next patch to grant userspace partial write
access to some sensitive registers.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Until now the software command checker assumed that commands could
read or write at most a single register per packet. This is not
necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length
list of offset/value pairs and writes them in sequence. The previous
code would only check whether the first entry was valid, effectively
allowing userspace to write unrestricted registers of the MMIO space
by sending a multi-register write with a legal first register, with
potential security implications on Gen6 and 7 hardware.
Fix it by extending the drm_i915_cmd_descriptor table to represent
multi-register access and making validate_cmd() iterate for all
register offsets present in the command packet.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Switch from using 31 PFI credits to 63 PFI credits when cdclk>=czclk on
CHV. The spec lists both 31 and 63 as "suggested" values, but based on
feedback from hardware folks we should actually be using 63. Originally
I picked the 31 basically by flipping a coin.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes the resume from suspend-to-ram on the IBM X30
laptop. The problem is caused by the Bios missing to re-initialize
the iVCH registers, especially the PLL registers.
This patch records the iVCH registers during initialization, and
re-installs this register set when resuming.
Signed-off-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We are always allocating a single page. No need to be verbose so
remove the suffix.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Free the scratch page if dma mapping fails.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
