MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch is a preparation patch for adding support for Exynos5433
DECON. Exynos7 DECON have to be distinguished from Exynos5433 DECON.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Every CRTC drivers in Exynos DRM implements the code which checks
whether IOMMU is supported or not, and if supported enable it.
Making new helper for it generalize each CRTC drivers.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Without this dependency, Kbuild is confused and the configs below
them are not placed under Exynos DRM. This patch fixes it, so the
configs below them become to be placed under Exynos DRM.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This dependency is a historical thing. It is added when this DP driver is
under media subsystem. Now because it is under Exynos DRM, this dependency
is not needed anymore.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Silence the following -Wmaybe-uninitialized warnings and make the code
more clear.
drivers/gpu/drm/i915/intel_display.c: In function ‘__intel_set_mode’:
drivers/gpu/drm/i915/intel_display.c:11844:14: warning: ‘crtc_state’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return state->mode_changed || state->active_changed;
^
drivers/gpu/drm/i915/intel_display.c:11854:25: note: ‘crtc_state’ was declared here
struct drm_crtc_state *crtc_state;
^
drivers/gpu/drm/i915/intel_display.c:11868:6: warning: ‘crtc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (crtc != intel_encoder->base.crtc)
^
drivers/gpu/drm/i915/intel_display.c:11853:19: note: ‘crtc’ was declared here
struct drm_crtc *crtc;
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
gem_prime_map is not currently described in the DRM manual, lets document
it.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch resolves the issue that refresh rate got low
at extension mode test with fimd and vidi combination.
The problem was because atomic_commit callback waited
for the completion of vblank to gaurantee crtc relevant
registers are updated from shadow registers to real ones.
However, the waiting there is really unnecessary because
page flip operation does already it.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
2a3098ff6c ("drm/exynos: add userptr feature for g2d module") but is
not referenced anywhere.
One instance of 'exynos_drm_gem_obj' may be mapped to multiple
user-space VMAs so 'vma' field does not look useful anyway.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch resolves page fault issue with iommu and atomic feature
when modetest test application is terminated.
ENWIN_F field of WINCONx register enables or disable a dma channel to
each hardware overlay - the value of the field will be updated to real
register after vsync.
So this patch makes sure the dma channel is disabled by waiting for vsync
one time after clearing shadow registers to all dma channels.
Below shows the page fault issue:
setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29
freq: 59.99Hz
[ 34.831025] PAGE FAULT occurred at 0x20400000 by 11e20000.sysmmu(Page
table base: 0x6e324000)
[ 34.838072] Lv1 entry: 0x6e92dc01
[ 34.841489] ------------[ cut here ]------------
[ 34.846058] kernel BUG at drivers/iommu/exynos-iommu.c:364!
[ 34.851614] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 34.857428] Modules linked in:
<--snip-->
[ 35.210894] [<c02880d0>] (exynos_sysmmu_irq) from [<c00608f8>]
(handle_irq_event_percpu+0x78/0x134)
[ 35.219914] [<c00608f8>] (handle_irq_event_percpu) from [<c00609f0>]
(handle_irq_event+0x3c/0x5c)
[ 35.228768] [<c00609f0>] (handle_irq_event) from [<c0063698>]
(handle_level_irq+0xc4/0x13c)
[ 35.237101] [<c0063698>] (handle_level_irq) from [<c005ff7c>]
(generic_handle_irq+0x2c/0x3c)
[ 35.245521] [<c005ff7c>] (generic_handle_irq) from [<c02214ec>]
(combiner_handle_cascade_irq+0x94/0x100)
[ 35.254980] [<c02214ec>] (combiner_handle_cascade_irq) from
[<c005ff7c>] (generic_handle_irq+0x2c/0x3c)
[ 35.264353] [<c005ff7c>] (generic_handle_irq) from [<c0060248>]
(__handle_domain_irq+0x7c/0xec)
[ 35.273034] [<c0060248>] (__handle_domain_irq) from [<c0009434>]
(gic_handle_irq+0x30/0x68)
[ 35.281366] [<c0009434>] (gic_handle_irq) from [<c0012ec0>]
(__irq_svc+0x40/0x74)
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DRM Exynos driver is relying on dma-mapping internal structures when used
with IOMMU enabled. This patch partially hides dma-mapping internal things
by using proper get_dma_ops/set_dma_ops calls.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch adds code, which detach sub-device nodes from default iommu
domain if such has been configured. This lets Exynos DRM driver to properly
attach sub-devices to its own, common for all sub-devices domain.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
When the fimd is disabled by fimd_disable(), enabled overlay layers also
are disabled. If clocks for fimd are enabled by fimd_enable() on this
case, it can lead IOMMU page fault. The reason is that VIDCON0_ENVID and
VIDCON0_ENVID_F bits of VIDCON0 register are set still even though fimd
is disabled, so it may continue display output of prior when clocks for
fimd are enabled again.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
With atomic modesetting all the control for CRTC, Planes, Encoders and
Connectors should come from DRM core, so the driver is not allowed to
enable or disable planes from inside the crtc_enable()/disable() call.
But it needs to disable planes with crtc_disable in exynos driver
internally. Because crtc is disabled before plane is disabled, it means
plane_disable just returns without any register changes, then we cannot
be sure setting register to disable plane when crtc is disable.
This patch removes this chainned calls to enable plane from exynos hw
drivers code letting only DRM core touch planes except to disable plane.
Also it leads eliminable enabled and resume of struct exynos_drm_plane.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The reason waiting vblank is to be power gated and disabled clocks after
dma operation is completed. The dma operation is stopped already before
be power gated and clocks are disabled when mixer is disabled by commit
381be025ac1a6("drm/exynos: stop mixer before gating clocks during
poweroff"). Don't need to wait vblank anymore.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
FIMC & GSC driver can calculate the offset of planes. So there are
use cases which IPP receives just one GEM handle of an image with
multiple plane. This patch extends ipp_validate_mem_node() to validate
this case.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Config depends on the opreation. So it must be referenced by an
operation id, not a property id.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
SoC checking code is not necessary anymore, as exynos_drm_match_add and
exynos_drm_platform_probe already properly handles situation when there are
no Exynos DRM components.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
In case there are multiple pipelines and deferred probe occurs, only components
of the first pipeline were bound. As a result only one pipeline was available.
The main cause of this issue was dynamic generation of component match table -
every component driver during probe registered itself on helper list, if there
was at least one pipeline present on this list component match table were
created without deferred components.
This patch removes this helper list, instead it creates match table from
existing devices requiring exynos_drm KMS drivers. This way match table do not
depend on probe/deferral order and contains all KMS components.
As a side effect patch makes the code cleaner and significantly smaller.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Code registering different drivers and simple platform devices was dispersed
across multiple sub-modules. This patch moves it to one place. As a result
initialization code is shorter and cleaner and should simplify further
development.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch makes one of Linux framebuffer and DRM CRTC drivers
to be enabled.
Display controllers, FIMD and DECON, can be controlled by Linux
framebuffer or DRM CRTC drivers so only one of them should be
enabled.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
To follow more closely the new atomic API we split the dpms()
helper into the enable() and disable() helper to get exactly the
same semantics.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms()
- do not use WARN_ON on crtc enable/disable
v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge
v4: - remove win_commit() call from .enable()
v5: - move .atomic_check() to the atomic PageFlip patch, and transform it
in .atomic_begin()
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
exynos needs to update planes with the crtc enabled (mainly for the FIMD
case) so this specific atomic commit changes the order of
drm_atomic_helper_commit_modeset_enables() and
drm_atomic_helper_commit_planes() to commit planes after we enable crtc
and encoders.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This is a preparation commit to move exynos_drm_crtc_disable() together
with the future exynos_drm_crtc_enable() that will come from the split of
exynos_drm_crtc_dpms() callback.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.
v2: remove unused exynos_drm_crtc
v3: fix checkpatch error (reported by Joonyoung)
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.
v2: Add .atomic_begin() step to handle the vblank part we removed from
exynos page_flip code.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.
v2: also remove .prepare() callback
v3: remove .mode_set() and .mode_set_base() and encoder's
.prepare() callbacks
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Handle changes by removing copy from adjusted_mode to mode as using
adjusted_mode of crtc_state.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane() before.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>y
Signed-off-by: Inki Dae <inki.dae@samsung.com>
As the clflush operates on cache lines, and we can flush any byte
address, in order to flush all bytes given in the range we issue an
extra clflush on the last byte to ensure the last cacheline is flushed.
We can can the iteration to be over the actual cache lines to avoid this
double clflush on the last byte.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use the same check already in the atomic core, so might as well
make this official. And it's also reused in e.g. i915.
Motivated by Maarten's idea to extract a connector_changed state out
of mode_changed.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-By: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
i915 fixes for stuff in next
* tag 'drm-intel-next-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Don't set enabled value of all CRTCs when restoring the mode
drm/i915: Don't update staged config during force restore modesets
drm/i915: Don't check modeset state in the hw state force restore path
drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.
drm/i915: Extend the parser to check register writes against a mask/value pair.
drm/i915: Fix command parser to validate multiple register access with the same command.
drm/i915: Don't skip request retirement if the active list is empty
In order for gen8+ hardware to guarantee that no context switch
takes place during engine reset and that current context is properly
saved, the driver needs to notify and query hw before commencing
with reset.
There are gpu hangs where the engine gets so stuck that it never will
report to be ready for reset. We could proceed with reset anyway, but
with some hangs with skl, the forced gpu reset will result in a system
hang. By inspecting the unreadiness for reset seems to correlate with
the probable system hang.
We will only proceed with reset if all engines report that they
are ready for reset. If root cause for system hang is found and
can be worked around with another means, we can reconsider if
we can reinstate full reset for unreadiness case.
v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel)
v3: updated commit msg
v4: timeout_ms, simpler error path (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=89959
References: https://bugs.freedesktop.org/show_bug.cgi?id=90854
Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked
Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tomas Elf <tomas.elf@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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
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>
The divider value to convert from CZ clock rate to ms needs a +1
adjustment on VLV just like on CHV. This matches both the spec and
the accuracy test by pm_rc6_residency.
v2:
- simplify logic checking for the CHV 320MHz special case (Rodrigo)
Testcase: igt/pm_rc6_residency
Signed-off-by: Imre Deak <imre.deak@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76877
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we're forgetting to double the port clock when using double
clocked modes with 12bpc on HDMI. We're only accounting for the 1.5x
factor due to the 12bpc. So further double the 1.5x port clock when we
have a double clocked mode.
Unfortunately I don't have any displays that support both 12bpc and
double clocked modes, so I was unable to test this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Account for the pixel multiplier when reading out the HDMI
mode dotclock. Makes the state checked happier on my ILK when using
double clocked modes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
