The driver assumes that only objects backed by shmem need to be mapped
through DMM. While this is true with the current code, the assumption
won't hold with dma_buf import support.
Condition the mapping based on whether the buffer has been allocated
using the DMA mapping API instead and clean up the flags to avoid having
to check both flags and GEM object filp field to decide how to process
buffers. Flags are not the authoritative source of information regarding
where the buffer memory comes from, and are renamed to make that
clearer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If the panel's enable fails, omap_encoder silently ignores the failure.
omapdrm should really handle the failure, but unfortunately the whole
encoder enable codepath is expected to always succeed.
So for now, catch the enable failure and print an error.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
omap_gem_dma_sync() calls dma_map_page() but does not check the possible
error with dma_mapping_error(). If DMA-API debugging is enabled, the
debug layer will give a warning if dma_mapping_error() has not been
used.
This patch adds proper error handling to omap_gem_dma_sync().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
omap_gem_attach_pages() calls dma_map_page() but does not check the
possible error with dma_mapping_error(). If DMA-API debugging is
enabled, the debug layer will give a warning if dma_mapping_error() has
not been used.
This patch adds proper error handling to omap_gem_attach_pages().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
tpd12s015 HW has LS_OE, CT_CP_HPD and HPD gpios. Out of these gpios,
driver only handled LS_OE as optional. The CT_CP_HPD gpio should also
be treated as optional gpio as it is just a power saving feature. Some
boards hardwire this gpio to be always enable. In this patch, all access
to CT_CP_HPD gpio is made optional.
Signed-off-by: Manisha Agrawal <manisha.agrawal@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
All devices using tpd12s015 driver are doing DT boot. No need of further
supporting the platform data. This patch removes support for platform
data.
Signed-off-by: Manisha Agrawal <manisha.agrawal@ti.com>
[tomi.valkeinen@ti.com: minor adjustments]
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This patch adds wrapper functions for readl() and writel(), dmm_read()
and dmm_write(), so that we can implement workaround for DRA7 errata
i878.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The current driver uses non-blocking DMM fill when releasing memory.
This gives us a small performance increase as we don't have to wait for
the fill operation to finish.
However, the driver does not have any error handling for non-blocking
fill. In case of an error, the fill operation may silently fail, leading
to leaking DMM engines, which may eventually lead to deadlock if we run
out of DMM engines.
This patch makes the DMM driver always use blocking fills, so that we
can catch the errors. A more complex option would be to allow
non-blocking fills, and implement proper error handling, but that is
left for the future.
This patch is a HACK, as the proper fix is to either decide to always
use sync fills and remove all the async related code, or fix the async
code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We occasionally see DISPC sync-lost errors when enabling and disabling
HDMI. Sometimes we get only a few, which get handled (ignored) by the
driver, but sometimes there's a flood of the errors which doesn't seem
to stop.
The HW team has root caused this to the order in which HDMI and DISPC
are enabled/disabled. Currently we enable HDMI first, and then DISPC,
and vice versa when disabling. HW team's suggestion is to do it the
other way around.
This patch changes the order, but this has two side effects as the pixel
clock is produced by HDMI, and the clock is not running when we
enable/disable DISPC:
* When enabling DISPC first, we don't get vertical sync events
* When disabling DISPC last, we don't get FRAMEDONE event
At the moment we use both of those to verify that DISPC has been
enabled/disabled properly. Thus this patch also needs to change the
omapdrm and omapdss which handle the DISPC side.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The STi drm driver correctly warns about invalid format strings
when built with 64-bit dma_addr_t:
sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
sti_hqvdp.c:605:119: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t {aka long long
unsigned int}' [-Wformat=]
sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
sti_hqvdp.c:931:118: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t {aka long long
unsigned int}' [-Wformat=]
This could be changed to using the %pad format string, but that
does not work when printing an rvalue, so instead I'm changing
the type in the sti_hqvdp structure to u32, which is what gets
written into the registers anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
commit we don't need to hack flags anymore.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix some copy paste typos.
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes for radeon and amdgpu:
- Fix GPUVM flushing on CI and VI
- Misc DPM and Powerplay fixes
- VCE DPM fixes for CZ/ST
- DP hotplug fix
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: return from atombios_dp_get_dpcd only when error
drm/amdgpu/cz: remove commented out call to enable vce pg
drm/amdgpu/powerplay/cz: enable/disable vce dpm independent of vce pg
drm/amdgpu/cz: enable/disable vce dpm even if vce pg is disabled
drm/amdgpu/gfx8: specify which engine to wait before vm flush
drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well
drm/amd/powerplay: send event to notify powerplay all modules are initialized.
drm/amd/powerplay: export AMD_PP_EVENT_COMPLETE_INIT task to amdgpu.
drm/radeon/pm: update current crtc info after setting the powerstate
drm/amdgpu/pm: update current crtc info after setting the powerstate
VDD regulator input was specified for MSM8916. It turns our that this
regulator is used for the display panels used on MSM8916 platforms, but
not the DSI controller itself. Drop this regulator from the list.
Reported-by: Vinay Simha <vinaysimha@inforcecomputing.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the implementation of of_graph parsing, it isn't any longer
necessary for msm_host->device node to be same as dsi->dev.of_node. This
only holds true when the connected device is also a child of the dsi_host.
In the case of external bridge chips belonging to a different control
bus, these are guaranteed to be different.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We have a msm_fbev_free function to uninit fb_helper stuff, but we aren't
using it. Call it in msm_unload.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
attach_dev gets called in mdp4_kms_init, but there is no corresponding
detach_dev called in the error path or in the kms driver unload path.
Detach and destroy mmu in mdp4_destroy.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Assign drm_atomic_helper_crtc_set_property helper to MDP4 and MDP5
crtcs' set_property ops. This replaces the custom funcs that
returned an error even for standard crtc properties.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of forcing bridges to implement empty callbacks make them all
optional.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT
LCD panels in the simple-panel driver.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
panel, which can be supported by the simple panel driver.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Set hsync/vsync to active low for g121x1_l03 panel to match the
recommended setting in the datasheet.
Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
MIPI DSI devices are inherently aware of their host because they share a
parent-child hierarchy in the device tree.
Non-DSI drivers that create DSI device don't have this data. In order to
get this information, they require to a phandle to the DSI host in the
device tree.
Maintain a list of all the DSI hosts that are currently registered. This
list will be used to find the struct mipi_dsi_host corresponding to the
device tree node passed to of_find_mipi_dsi_host_by_node().
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
A driver calling mipi_dsi_device_register_full() might want to remove
the device once it's done. It might also require it in an error handling
path in case something went wrong.
Create mipi_dsi_device_unregister() for this purpose and use it within
mipi_dsi_remove_device_fn() as it does the same thing.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
In amdgpu_connector_hotplug(), we need to start DP link
training only after we have received DPCD. The function
amdgpu_atombios_dp_get_dpcd() returns non-zero value only
when an error condition is met, otherwise returns zero.
So in case the function encounters an error, we need to
skip rest of the code and return from amdgpu_connector_hotplug()
immediately. Only when we are successfull in reading DPCD
pin, we should carry on with turning-on the monitor.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This code path is not currently enabled now that we properly
respect the vce pg flags, so uncomment the actual pg calls
so the code is as it should be we are eventually able to
enable vce pg.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If we don't disable it when vce is not in use, we use extra power
if vce pg is disabled.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
I missed this when cleaning up the vce pg handling.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Select between me and pfp properly.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We never ported that back to CIK, so we could run into VM faults here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
with this event, powerplay can adjust current power state if needed.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This is needed to init the dynamic states without a display. To be
used in the next commit.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again. In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again. In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Add a device name field in struct mipi_dsi_device. This name is not the
same as the device name (which is of the format "hostname.reg"). When
the device is created via DT, this name is set to the modalias string.
In the non-DT case, the driver creating the DSI device provides the
name by populating a field in struct mipi_dsi_device_info.
Matching for DT case would be as it was before. For the non-DT case, we
compare the device and driver names. Other buses (like I2C/SPI) perform
a non-DT match by comparing the device name and entries in the driver's
id_table. Such a mechanism isn't used for the DSI bus.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use mipi_dsi_device_register_full() for device creation. This takes in
a struct mipi_dsi_device_info as a template to populate the DSI device
information.
The reason to introduce this is to have a way to create DSI devices not
available via DT. Drivers that want to create a DSI device can populate
a struct mipi_dsi_device_info and call this function. For DSI devices
available via DT, of_mipi_dsi_device_add() is used as before, but this
now calls mipi_dsi_device_register_full() internally.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
of_mipi_dsi_device_add() is used only when CONFIG_OF is enabled. It
currently works if OF support is disabled, but this will change when we
add more functionality to it.
Define the original function if CONFIG_OF is enabled and a dummy
function otherwise.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
commit 0973128002
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 17 14:17:42 2016 +0200
drm/i915: Add helper to get a display power ref if it was already enabled
left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as
intel_runtime_pm_get_if_in_use() would return true without incrementing
the local bookkeeping required for the assertions.
Fixes: 0973128002 ("drm/i915: Add helper to get a display power ref if it was already enabled")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Mika Kuoppala <mika.kuoppala@intel.com>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 135dc79efb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During system suspend we need to first disable power wells then
unitialize the display core. In case power well support is disabled we
did this in the wrong order, so fix this up.
Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option")
CC: stable@vger.kernel.org
CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 2622d79bd9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Add and make use of drm_of_active_endpoint helpers
- Silence a noisy dev_info into a dev_dbg
- Stop touching primary fb on pageflips
- Track flip state explicitly
- Keep GEM buffer objects referenced while scanout is active
- Implement fence sync by deferring flips to a workqueue for
dma-bufs with pending fences
- Actually disable vblank IRQs while they are not needed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW1UXsAAoJEFDCiBxwnmDrcLAP/RSK97JkP35sgPT4+YCuGtsD
ToXzJaJnKwSMaXQif1IN7xwcX+sYhhivzTYVM5Cj9/CGwAME9fkqirFxC4ZZ4b5B
0tx/XcRWoyl7zuxTpAPTFxtr7aDQ5cQ2gHMjqasNDXtvQS3h+vjmYuRfNI2PmdLO
9Bnj7zrun3kW3V05RE2W+3VsFZALQ64tMAuZPnTEI8/F/DH4lyH7q6V9d+jBZiR6
rYRw4jWn5J37xu84jhjYxISokBB46Ldb1ccLQ9910Whuj6vVnvSd0mufL+MLPYot
/ZSlcNrjIN6QmeHxWcO17MogW3l94Yp5xvRih9hjO9wc/tgoWNkOw7wcnvE7GW3z
P5YzlDgRy/MrIxsqIjSTu9yzv6GjDpZCqu/qib9TKWTcsnvz1O23r3Q/CjmILwdk
Tb0DBHZL2RM01YgunAcuvUQmKoz4MwAk0nqhKGJzkHUUQoXDyk+EJTVFw5liOoOP
Qb8enNfGhoLVLCKM1sdX5hdrc2WGOiZSXQWK6rsFfK5vuuTFOQC84nH/jj5LasEk
x07tXnwHEUFEOCLNPjPRrvv6K1juB3n5wmwnmCiaNlnp2alIjRb0ZBGH95egKrGL
vKuBzwz/FfR2uUDM/fiblwaGV8htmZ0cCWoKckOmyZvTWA/96qEVbvcgOoHDMN6R
lsv2qUwrkhMQOE9Nr90a
=ufbY
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-20160301' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm vblank IRQ control, fence support, and of endpoint helpers
- Add and make use of drm_of_active_endpoint helpers
- Silence a noisy dev_info into a dev_dbg
- Stop touching primary fb on pageflips
- Track flip state explicitly
- Keep GEM buffer objects referenced while scanout is active
- Implement fence sync by deferring flips to a workqueue for
dma-bufs with pending fences
- Actually disable vblank IRQs while they are not needed
* tag 'imx-drm-next-20160301' of git://git.pengutronix.de/git/pza/linux:
drm/imx: only enable vblank IRQs when needed
drm/imx: implement fence sync
drm/imx: keep GEM object referenced as long as scanout is active
drm/imx: track flip state explicitly
drm/imx: don't touch primary fb on pageflip
drm/imx: ipuv3 plane: Replace dev_info with dev_dbg if a plane's CRTC changes
gpu: ipu-v3: ipu-dc: Simplify display controller microcode setup
drm/rockchip: remove rockchip_drm_encoder_get_mux_id
drm/imx: remove imx_drm_encoder_get_mux_id
drm: add drm_of_encoder_active_endpoint helpers
During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.
Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Core provides generic helper to create DSI packet, use it instead of
custom code.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch changes device pointer provided to all calls to DMA-mapping
subsystem from the virtual exynos-drm 'device' to the real device pointer
of one of the CRTC devices (decon, fimd or mixer). This way no more hacks
will be needed to configure proper DMA-mapping address space on the common
virtual exynos-drm device. This change also removes the need for some
hacks in IOMMU related code. It also finally solves the problem of Exynos
DRM driver not working on ARM64 architecture, which provides noop-based
DMA-mapping operations for virtual platform devices.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch refactors driver and device registration by moving all drivers
to the common array. This way additional flags can be added later for
new features. #ifdef-based code has been replaced by IS_ENABLED() macro
usage.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Polarization was never configured for DRM-FIMC device, so fimc_set_polarity
function did nothing. In fact DRM does not use camera interface so there
is no point in configuring it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
struct exynos_drm_panel_info is not used anymore, except exynos_dp,
which can integrate useful fields directly into its context.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch adds a exynos5420 driver data to support mic_bypass
option to bypass the mic from display out path.
The mic(Mobile image compressor) compresses RGB data from fimd
and send the compressed data to the mipi dsi.
The bypass option can be founded from system register and the bit
is 11. The option bit has been introduced since exynos5420. The
only difference between exynos5250 and exynos5420/exynos5422 is
existence of the bit. Until the MIC is defined and enabled from
device tree, the bypass mic will be default option.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch uses DIV_ROUND_CLOSEST instead of DIV_ROUND_UP
The DIV_ROUND_CLOSEST can be used to find the closest integer
value when we divide some integers.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Include directories are provided by core already, adding them in driver
is redundand and causes warnings in case of out-of-tree build.
v2:
- fixed include in exynos_drm_iommu.c
- typo in commit message
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Functions are preferred over macros as more type-safe.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch supports mipi dsi for exynos5422. The dsi register
offsets of the exynos5422 are similar with exynos5433. However,
the values of the registers are quite different from the
exynos5433. For example, the exynos5422 uses sw reset like
previous chips.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Decon requires that clocks should be disabled in reverse order. Otherwise
system hangs.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
dma_mmap_attrs() should be called with cpu address returned by
dma_alloc_attrs(). Existing code however passed pages array base as cpu
address. This worked only by a pure luck on ARM architecture. This patch
fixes this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
BIT_IRQS_ENABLED was never set because of incorrect test in
decon_vlank_enable() function, what resulted in lack of enabling vblank
support. This patch fixes this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Patch ebf3fd403b ("drm/exynos: add
pm_runtime to DECON 5433") removed some code from decon_enable()
function, but it left set_bit(BIT_SUSPENDED, &ctx->flags) call, which
was earlier called only in error path. This patch removes it, what
finally lets driver to go out of suspended state.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes issue introduced by commit
cf67cc9a29 ("drm/exynos: remove struct
exynos_drm_display"), which removed assigning of drm bridge to drm
encoder. Lack of it caused that no bridge callbacks were called on
encoder enable/disable actions.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
There is no point exposing all internal functions to global kernel name
space, so make all internals functions static.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
MIC is SoC component and important part of kms pipeline on Exynos5433,
so convert it to use component framework like other KMS/CRTC drivers.
MIC driver is already listed on KMS component driver list in Exynos DRM
core, so without this conversion, initialization of Exynos DRM core
fails on Exynos 5433 SoC.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Drivers should use devm_clk* interface instead of of_clk* functions.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes compilation warnings (on 64bit architectures) and bugs
related to casting pointers through 32bit integers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Drivers should use %p for printing pointers instead of hardcoding them
as hexadecimal integers. This patch fixes compilation warnings on 64bit
architectures.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Because PLAT_SAMSUNG isn't include exynos SoCs for arm64, but
ARCH_EXYNOS can do it. And it also needs to add ARCH_S3C64XX instead of
PLAT_SAMSUNG.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The vblank IRQ is only needed to trigger page flip work, so we
might as well disable it when there is no work to do.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
If the FB is backed by a GEM object with an dma-buf attached
we need to wait for any pending fences to signal before executing
the page flip.
The implementation is straight forward by deferring the flip to
a workqueue in that case.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The DRM core only references the currently queued/active framebuffer.
So there is a period of time where the flip is not completed, but
the GEM object backing the FB is already unreferenced and could be
destroyed if userspace closes its handle.
Make sure to keep a reference to the GEM object until the flip is
actually executed clean things up in a worker running behind the
flip execution.
Also move the page flip event into the context of this worker, so
it gets cleaned up automatically.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Start tracking the flip state explicitly, as opposed to inferring
it from the presence if a new FB. This is a preparatory step to
introduce an new immediate state, where we can wait for a fence to
signal.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The core already does the correct replacemet if the driver
page flip function returns without an error, so there is no
need to do it here.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This patch changes the dev_info() call to dev_dbg() in ipu_plane_update()
to print out the information that a plane's CRTC is changed, because this
kind of information is only useful for debugging.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
It is replaced by drm_of_encoder_active_endpoint_id.
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Yakir Yang <ykk@rock-chips.com>
[for dw_hdmi-rockchip]
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
It is replaced by drm_of_encoder_active_port_id.
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
- lots and lots of fbc work from Paulo
- max pixel clock checks from Mika Kahola
- prep work for nv12 offset handling from Ville
- piles of small fixes and refactorings all around
* tag 'drm-intel-next-2016-02-14' of git://anongit.freedesktop.org/drm-intel: (113 commits)
drm/i915: Update DRIVER_DATE to 20160214
drm/i915: edp resume/On time optimization.
agp/intel-gtt: Only register fake agp driver for gen1
drm/i915: TV pixel clock check
drm/i915: CRT pixel clock check
drm/i915: SDVO pixel clock check
drm/i915: DisplayPort-MST pixel clock check
drm/i915: HDMI pixel clock check
drm/i915: DisplayPort pixel clock check
drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
drm/i915: fix error path in intel_setup_gmbus()
drm/i915: Stop depending upon CONFIG_AGP_INTEL
agp/intel-gtt: Don't leak the scratch page
drm/i915: Capture PCI revision and subsytem details in error state
drm/i915: fix context/engine cleanup order
drm/i915: Handle PipeC fused off on IVB/HSW/BDW
drm/i915/skl: Fix typo in DPLL_CFGCR1 definition
drm/i915: Skip DDI PLL selection for DSI
drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select()
drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
...
commit 0973128002
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 17 14:17:42 2016 +0200
drm/i915: Add helper to get a display power ref if it was already enabled
left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as
intel_runtime_pm_get_if_in_use() would return true without incrementing
the local bookkeeping required for the assertions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Mika Kuoppala <mika.kuoppala@intel.com>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Makes matching it to the flushes much easier.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The owner must be per ring as long as we don't
support sharing VMIDs per process. Also move the
assigned VMID and page directory address into the
IB structure.
v3: assign the VMID to all IBs, not just the first one.
v4: use correct pointer for owner
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add support for the HDMI PHY/PLL found in MSM8996/APQ8096.
Unlike the previous PHYs supported in the driver, this doesn't need
the powerup/powerdown ops. The PLL prepare/unprepare clock ops
enable/disable the phy itself.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
- Create separate domains for 8960 PHY and PLL
- Create separate domains for 8x60 PHY
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Remove the old PHY ops managed by hdmi_platform_config and use them as ops
provided by the HDMI PHY driver.
Remove the old HDMI 8960 PLL code that used the top level HDMI TX mmio
base.
NOTE: With this commit, HDMI functionality will break until the HDMI
PHY/PLL register offsets in hdmi.xml.h aren't updated to be used as
separate domains.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Make HDMI core get its PHY by parsing the "phys" phandle. The core will use
this PHY reference to enable/disable PHY. The driver defers probe until PHY
isn't available.
The DT bindings used here is the same as the one used for PHYs using the
common PHY framework bindings.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a helper to initialize PLL in the PHY driver. HDMI PLLs are going to
have their own mmio base different from that of PHY.
For the clock code in hdmi_phy_8960.c, some changes were needed for it to
work with the updated register offsets. Create a copy of the updated clock
code in hdmi_pll_8960.c, instead of rewriting it in hdmi_phy_8960.c
itself. This removes the need to place CONFIG_COMMON_CLOCK checks all
around, makes the code more legible, and also removes some old checkpatch
warnings with the original code.
The older hdmi pll clock ops in hdmi_phy_8960.c will be removed later. The
driver will use these until the HDMI PHY/PLL register offsets aren't
considered as separate domains (i.e. their offsets start from 0).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Create a PHY device that represents the TX PHY and PLL parts of the HDMI
block.
This makes management of PHY specific resources (regulators and clocks)
much easier, and makes the PHY and PLL usable independently. It also
simplifies the core HDMI driver, which currently assigns phy ops among
many other things.
The PHY driver implementation done here is very similar to the PHY driver
we already have for DSI.
Keep the old hdmi_phy_funcs ops for now. The driver will use these until
the HDMI PHY/PLL register offsets aren't considered as separate
domains (i.e. their offsets start from 0).
The driver doesn't use the common PHY framework for now. This is because
it's hard to map our ops with the ops provided by the framework. The
bindings used for this is the generic phy bindings. So, this can be
adapted to the PHY framework in the future, if possible.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some platforms may not have a HPD gpio line to detect Hot Plug signal from
the connector. They need to rely only on reading REG_HDMI_HPD_INT_STATUS
for HPD.
Modify hdmi_connector_detect logic such that it checks for HPD only using
the status register if there is no HPD gpio.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Make gpio allocation and usage iterative by parsing the gpios on a given
platform from a list. This gives us flexibility over what all gpios exist
for a platform, whether they are input or output, and what value they
should be set to.
In particular, this will make HDMI on 8x96 platforms easier to integrate
with the driver, as it doesn't have a HPD gpio input to them. Also, it
cleans things up a bit.
We still use the legacy gpio api here, as we might need to backport this
driver to downstream kernels.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
amdgpu must load only after amdkfd's loading has been completed. If that
is not enforced, then amdgpu's call into amdkfd's functions will cause a
kernel BUG.
When amdgpu and amdkfd are built as kernel modules, that rule is enforced
by the kernel's modules loading mechanism. When amdgpu and amdkfd are
built inside the kernel image, that rule is enforced by ordering in the
drm Makefile (amdkfd before amdgpu).
Instead of using drm Makefile ordering, we can now use deferred loading
as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is not yet
loaded.
This patch defers amdgpu loading by propagating -EPROBE_DEFER to the
kernel's drivers loading infrastructure. That will put amdgpu into the
pending drivers list (see description in dd.c). Once amdkfd is loaded,
a call to kgd2kfd_init() will return successfully and amdgpu will be able
to load.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
radeon must load only after amdkfd's loading has been completed. If that
is not enforced, then radeon's call into amdkfd's functions will cause a
kernel BUG.
When radeon and amdkfd are built as kernel modules, that rule is
enforced by the kernel's modules loading mechanism. When radeon and
amdkfd are built inside the kernel image, that rule is enforced by
ordering in the drm Makefile (amdkfd before radeon).
Instead of using drm Makefile ordering, we can now use deferred
loading as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is
not yet loaded.
This patch defers radeon loading by propagating -EPROBE_DEFER to the
kernel's drivers loading infrastructure. That will put radeon into the
pending drivers list (see description in dd.c). Once amdkfd is loaded,
a call to kgd2kfd_init() will return successfully and radeon will be
able to load.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Current dependencies between amdkfd and radeon/amdgpu force the loading
of amdkfd _before_ radeon and/or amdgpu are loaded. When all these kernel
drivers are built as modules, this ordering is enforced by the kernel
built-in mechanism of loading dependent modules.
However, there is no such mechanism in case where all these drivers are
compiled inside the kernel image (not as modules). The current way to
enforce loading of amdkfd before radeon/amdgpu, is to put amdkfd before
radeon/amdgpu in the drm Makefile, but that method is way too fragile.
In addition, there is no kernel mechanism to check whether a kernel
driver that is built inside the kernel image, has already been loaded.
To solve this, this patch adds to kfd_module.c a new static variable,
amdkfd_init_completed, that is set to 1 only when amdkfd's
module initialization function has been completed (successfully).
kgd2kfd_init(), which is the initialization function of the
kgd-->kfd interface, and which is the first function in amdkfd called by
radeon/amdgpu, will return successfully only if amdkfd_init_completed is
equal 1.
If amdkfd_init_completed is not equal to 1, kgd2kfd_init() will
return -EPROBE_DEFER to signal radeon/amdgpu they need to defer
their loading until amdkfd is loaded.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We weren't updating the interlaced bit, so we'd scan out incorrectly
if the firmware had brought up the TV encoder and we were switching to
HDMI.
Signed-off-by: Eric Anholt <eric@anholt.net>
It looks like when I went to add the interlaced bits, I just took the
existing PV_VERT* block and indented it, instead of copy and pasting
it first. Without this, changing resolution never worked.
Signed-off-by: Eric Anholt <eric@anholt.net>
If the firmware hadn't brought up HDMI for us, we need to do its
power-on reset sequence (reset HD and and clear its STANDBY bits,
reset HDMI, and leave the PHY disabled).
Signed-off-by: Eric Anholt <eric@anholt.net>
We'd need X to queue up an async pageflip while another is
outstanding, and then take a SIGIO. I think X actually avoids sending
out the next pageflip while one's already queued, but I'm not sure.
Signed-off-by: Eric Anholt <eric@anholt.net>
It's simpler to just use snprintf() to print this to one buffer instead
of using strcpy() and strcat(). Also using snprintf() is slightly safer
than using sprintf().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Given that the intel_lr_context_pin cannot succeed without the object,
we cannot reach intel_lr_context_unpin() without first allocating that
object - so we can remove the redundant test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456485751-15213-1-git-send-email-tvrtko.ursulin@linux.intel.com
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456484600-11477-1-git-send-email-tvrtko.ursulin@linux.intel.com
Elsewhere we have adopted the convention of using '_link' to denote
elements in the list (and '_list' for the actual list_head itself), and
that the name should indicate which list the link belongs to (and
preferrably not just where the link is being stored).
s/vma_link/obj_link/ (we iterate over obj->vma_list)
s/mm_list/vm_link/ (we iterate over vm->[in]active_list)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
commit 0973128002
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 17 14:17:42 2016 +0200
drm/i915: Add helper to get a display power ref if it was already enabled
left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as
intel_runtime_pm_get_if_in_use() would return true without incrementing
the local bookkeeping required for the assertions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Mika Kuoppala <mika.kuoppala@intel.com>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Imre Deak <imre.deak@intel.com>
The cache line offset for the Indirect CS context (0x21C8) varies from gen
to gen.
v2: Move it into a function (Arun), use MISSING_CASE (Chris)
v3: Rebased (catched by ci bat)
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456223509-6454-1-git-send-email-michel.thierry@intel.com
Display fps on demand for each used plane:
cat /sys/kernel/debug/dri/0/fps_get
Display fps in live in the console for each used plane:
echo 255 > /sys/kernel/debug/dri/0/fps_show
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Configures the framer of the HDMI connection.
By default starts in HDMI mode and can be swtich to DVI.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Make the value of the colorspace of the HDMI infoframe configurable.
HDMI colorspace could be: RGB, YUV422 or YUV444
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Vendor specific infoframe is mandatory for 4K2K resolution.
Without this, the HDMI protocol compliance fails.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Clear all infoframe registers when the HDMI link is stopped.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Set the infoframe transmission mode according to the type of
the infoframe.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Make sure the HD DACS are disabled when the HDA connector
is created.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Modify AWG algorithm in order to handle more than 1023 lines
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Modify delay to display last pixel column on DVO
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
The DVO connector is tag as disconnect because of a wrong management
of the panel detection.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Disable the clipping mode for hdmi, dvo and hda connectors.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Use BT601 for SD/ED resolution and BT709 for HD resolution
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Atomic update should never fail. Thus all checks must be done in
the atomic_check function for each plane (gdp, hqvdp and cursor).
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
It may happen that the cursor is displayed with wrong colors which can
be explained by a CLUT wrongly fetched at the first display.
Fetching the CLUT at each commit (=move) ensures that the right colors
are used, at least from the first cursor move.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
GDP source width should be equal to the destination width to get
rid of this issue.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
When a GDP gets a scale request (which it does not support), it accepts it
but crops or clamps and outputs a warning message.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Only RGB formats supported by GDP planes
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
When a frame or a field is skipped, output a Warning message instead of
an Error message.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
data_en is a local variable that doesn't need to be set as
awg_generate_instr can be called directly with the requested value.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
This update eases to understand the VTG programming.
It also sets a VTG output id for each supported connectors.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
sti now support of atomic modesetting so set the flag to enable it.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Set CRTC modesetting parameters to avoid warnings in atomic mode.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
In some cases last_close() could be called before sti_gdp_disable()
and make kernel crash because mixer structure has been destroy.
Let's gdp keep a reference on vtg to fix that (like it is already done
in HQVDP)
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for
Vybrid) whereas the register enumeration start from 1 (1-10 for
LS1021a and 1-9 for Vybrid). The loop started off from 0 for both
iterations and initialized the number of layers inclusive, which
is one layer too many.
All extensively written registers seem to be unassigned, it seems
that the write to those registers did not do any harm in practice.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The current default configuration is as follows:
- Invert VSYNC signal (active LOW)
- Invert HSYNC signal (active LOW)
The mode flags allow to specify the required polarity per
mode. Furthermore, none of the current driver settings is
actually a standard polarity.
This patch applies the current driver default polarities as
explicit flags to the display which has been introduced with
the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now
also parses the flags field and applies the configuration
accordingly, by using the following values as standard
polarities: (e.g. when no flags are specified):
- VSYNC signal not inverted (active HIGH)
- HSYNC signal not inverted (active HIGH)
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Fix alpha blending by enabling alpha blending for the whole frame if
a color mode with alpha channel is selected (DRM_FORMAT_ARGB*). Also
support color modes without alpha channel (DRM_FORMAT_XRGB*) by just
not enabling alpha blending on layer level.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The state of the interrupt mask register on initialization is
unknown, e.g. U-Boot could already used the DCU. So depending on
the boot loader, the outcome of the interrupt mask register could
be different. A defined state is much more preferable. Also, there
is no value in keeping interrupts enabled which we don't need.
Therefor, mask all interrupts on initialization.
Signed-off-by: Stefan Agner <stefan@agner.ch>
If initialization fails (e.g. due to missing panel node or deferred
probe) make sure to roll-back all operations and return the error
code.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Improve error handling during CRTC initialization. Especially avoid
memory leaks in the primary plane initialization error path.
Signed-off-by: Stefan Agner <stefan@agner.ch>
It is not common to do regmap return value checks, especially not
for memory mapped device. We can rule out most error returns since
the conditions are static and we know they are ok (e.g. offset
aligned to register stride). Also without proper error handling
they are not really valuable for the user. Hence remove most of
them.
The check in the interrupt handler is worth keeping since a
volatile register won't be readable in case register caching is
still enabled.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Since we are using cached registers, we need to specify volatile
registers explicitly to avoid reading their value from the cache.
This allows to read the correct interrupt status in fsl_dcu_drm_irq
and clear the asserted bits only.
Signed-off-by: Stefan Agner <stefan@agner.ch>
For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
function, if so, return 0.
Signed-off-by: Meng Yi <meng.yi@nxp.com>
Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
By default, not only this driver is enabled on all platforms, but also
generic PM Domains and Multi-Function Devices.
Drop the "default y" to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When I reworked this code, I messed up num rb count.
v2: use hweight32
Reviewed-by: Ken Wang <Qingquing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use devm_kzalloc() and devm_kcalloc() for private data allocation at
driver load time.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Initialize port device node pointer in the tilcdc crtc. Fixes "Falling
back to first CRTC" warning from tda998x driver.
The tda998x encoder driver calls drm_of_find_possible_crtcs() to
initialize possible_crtcs of struct drm_encoder. The crtc->port needs
to be initialized for drm_of_find_possible_crtcs() to work.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Disable the sync lost interrupt if it fires on every frame for 50
consecutive frames in a row. This is relatively sure sign of the sync
lost interrupt being stuck and firing on every frame even if the
display otherwise appears to work OK.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add ratelimited prints on sync lost and FIFO underrun interrupts.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Removes the duplicate LCDC_INT_ENABLE_SET_REG-entry in registers array.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fix interrupt enable/disable code for version 2 tilcdc. In version 2
tilcdc there is a separate register for disabling interrupts. Writing
0 to enable registers bits does not have any effect. The interrupt
clear register works the same way, writing 1 to specific bit disables
the interrupt and writing 0 does not have any effect.
The "bug" that is fixed here does not really do any harm since the
interrupts are enabled only once in the power up and disabled before
power down.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Do not update the next frame buffer close to vertical blank. This is
to avoid situation when the frame changes between writing of
LCDC_DMA_FB_BASE_ADDR_0_REG and LCDC_DMA_FB_CEILING_ADDR_0_REG.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Get rid of complex ping-pong mechanism and replace it with simpler
single buffer flipping code.
The LCDC HW appears to be designed mainly static framebuffers in
mind. There are two modes of operation, either static single buffer,
or ping pong double buffering with two static buffers switching back
and forth. Luckily the framebuffer start address is fetched only in
the beginning of the frame and changing the address after that only
takes effect after the next vertical blank. The page flipping code can
simply write the address of the new framebuffer and the page is
flipped automatically after the next vertical blank. Using the ping
pong double buffering makes the flipping code way more complex and it
does not provide any benefit, so it is better to switch to single
buffer operation.
There is still one problem in updating the framebuffer dma address on
the fly. There are two registers defining the framebuffer dma area and
things may break if the dma address is fetched in while the registers
are are being updated.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Cleanup irq handling. Clear the irq status unconditionally and
restructure the status bit conditions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Remove broken error handling. The condition for handling the
LCDC_SYNC_LOST and LCDC_FIFO_UNDERFLOW could never be satisfied as the
LCDC_SYNC_LOST interrupt is not enabled. Also the requirement to have
both LCDC_SYNC_LOST and LCDC_FIFO_UNDERFLOW fired at once before
handling the error looks weird.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Split reset to a separate function and use usleep_range(250, 1000)
instead of msleep(1) to to keep the reset bit on long enough.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch, changed mdelay(500) to usleep_range(250, 1000)]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Disable crtc on unload. Call tilcdc_crtc_dpms() with DRM_MODE_DPMS_OFF
in the beginning of unload function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Cleanup runtime PM handling. Before the patch the usage of pm_runtime
calls was inconsistent and hard to follow. After the update the
pm_runtime calls are removed from set_scanout() and called around
major operations that access the HW. After the patch the DPMS code does
not have pm_runtime_forbid/allow calls any more and
pm_runtime_irq_safe() is not set anymore.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[Added description to the patch]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Allocate suspend/resume register storage based on the actual number
registers the driver is aware of. The static allocation for register
storage had fallen behind badly.
Reported-by: Michael Bode <michael@bumbleB.de>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fix build error when !CONFIG_CPU_FREQ
drivers/gpu/drm/tilcdc/tilcdc_drv.c: In function 'tilcdc_load':
drivers/gpu/drm/tilcdc/tilcdc_drv.c:327:1: error: label 'fail_put_clk' defined but not used [-Werror=unused-label]
fail_put_clk:
^
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
There is nothing special about tilcdc HW when the video memory is
concerned. Just using the standard drm helpers for implementation is
enough.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The LCD controller must be deactivated and all DMA transactions stopped
when the suspend power state is entered otherwise the PRCM causes the L3
bus to get stuck in transition state.
This commit forces the lcdc to be shut down and waits for all pending DMA
transactions to complete as part of the suspend handler for this driver.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The frame_done interrupt was only being enabled when the vsync
interrupts were being enabled by DRM. However the frame_done is
used to determine if the LCD controller has successfully completed
the raster_enable, raster_disable commands and the vsync interrupts
are not always enabled during these operations.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On BeagleBone Black if no HDMI monitor is connected and suspend
is requested a kernel panic will result:
root@am335x-evm:~# echo mem > /sys/power/state
[ 65.548710] PM: Syncing filesystems ... done.
[ 65.631311] Freezing user space processes ... (elapsed 0.006 seconds) done.
[ 65.648619] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
[ 65.833500] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa30e004
[ 65.841692] Internal error: : 1028 [#1] SMP ARM
<snip>
[ 66.105287] [<c03765f0>] (platform_pm_suspend) from [<c037b6d4>] (dpm_run_callback+0x34/0x70)
[ 66.114370] [<c037b6d4>] (dpm_run_callback) from [<c037ba84>] (__device_suspend+0x10c/0x2f4)
[ 66.123357] [<c037ba84>] (__device_suspend) from [<c037d004>] (dpm_suspend+0x58/0x218)
[ 66.131796] [<c037d004>] (dpm_suspend) from [<c008d948>] (suspend_devices_and_enter+0x9c/0x3c0)
[ 66.141055] [<c008d948>] (suspend_devices_and_enter) from [<c008de7c>] (pm_suspend+0x210/0x24c)
[ 66.150312] [<c008de7c>] (pm_suspend) from [<c008cabc>] (state_store+0x68/0xb8)
[ 66.158103] [<c008cabc>] (state_store) from [<c02e9654>] (kobj_attr_store+0x14/0x20)
[ 66.166355] [<c02e9654>] (kobj_attr_store) from [<c0185c70>] (sysfs_kf_write+0x4c/0x50)
[ 66.174883] [<c0185c70>] (sysfs_kf_write) from [<c018926c>] (kernfs_fop_write+0xb4/0x150)
[ 66.183598] [<c018926c>] (kernfs_fop_write) from [<c0122638>] (vfs_write+0xa8/0x180)
[ 66.191846] [<c0122638>] (vfs_write) from [<c01229f8>] (SyS_write+0x40/0x8c)
[ 66.199365] [<c01229f8>] (SyS_write) from [<c000e580>] (ret_fast_syscall+0x0/0x48)
[ 66.207426] Code: e595c210 e5932000 e59cc000 e08c2002 (e592c000)
This is because the lcdc module is not enabled when no monitor is detected
to save power. However the suspend handler just blindly tries to save the
lcdc state by copying out the pertinent registers. However module is off
so no good things happen when you try and access it.
This patch only saves off the registers if the module is enabled, and
then only restores the registers on resume if they were saved off during
suspend.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Update tilcdc driver to set the state of the pins to:
- "default on resume
- "sleep" on suspend
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- minimize current leakage from pins and thus save power,
- prevent the IP from driving pins output in an uncontrolled manner,
which may happen if the power domain drops the domain regulator.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
LCDC hardware does not support fb pitch that is different (i.e. larger)
than the screen size. The driver currently does no checks for this, and
the results of too big pitch are are flickering and lower fps.
This issue easily happens when using libdrm's modetest tool with non-32
bpp modes. As modetest always allocated 4 bytes per pixel, it implies a
bigger pitch for 16 or 24 bpp modes.
This patch adds a check to reject pitches the hardware cannot support.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Updating the tilcdc DRM driver code to calculate the LCD controller
pixel clock more accurately. Based on a suggested implementation by
Tomi Valkeinen.
The current code does not work correctly and produces wrong results
with many requested clock rates. It also oddly uses two different
clocks, a display pll clock and a divider clock (child of display
pll), instead of just using the clock coming to the lcdc.
This patch removes the use of the display pll clock, and rewrites the
code to calculate the clock rates. The idea is simply to request a
clock rate of pixelclock*2, as the LCD controller has an internal
divider which we set to 2.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
[Rewrapped description]
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently we perform our own wait in post_plane_update,
but the atomic core performs another one in wait_for_vblanks.
This means that 2 vblanks are done when a fb is changed,
which is a bit overkill.
Merge them by creating a helper function that takes a crtc mask
for the planes to wait on.
The broadwell vblank workaround may look gone entirely but this is
not the case. pipe_config->wm_changed is set to true
when any plane is turned on, which forces a vblank wait.
Changes since v1:
- Removing the double vblank wait on broadwell moved to its own commit.
Changes since v2:
- Move out POWER_DOMAIN_MODESET handling to its own commit.
Changes since v3:
- Do not wait for vblank on legacy cursor updates. (Ville)
- Move broadwell vblank workaround comment to page_flip_finished. (Ville)
Changes since v4:
- Compile fix, legacy_cursor_flip -> *_update.
Changes since v5:
- Kill brackets.
- Add WARN_ON when wait_for_vblanks fails.
- Remove extra newlines.
- Split the checks whether vblank is needed to a separate function,
with comments why a vblank is needed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56CD84DA.5030507@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Use our newly created encoder_mask to iterate over the encoders.
This makes it possible to get the crtc power domains from the
crtc_state at any time, without any locks or having to look at
the legacy state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This can happen under some annoying circumstances, and is a quick fix
until more substantial changes can be made.
Fixed eDP mode changes on (at least) the Lenovo P50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
This is a bit large, but it really helps Skylake bugs we are seeing
on a number of laptops.
Most of the commits are quite similar, ensuring the display power
doesn't vanish under us during hardware access. Also do note that it's
not just Skylake that's affected.
* tag 'drm-intel-fixes-2016-02-22' of git://anongit.freedesktop.org/drm-intel:
drm/i915/gen9: Verify and enforce dc6 state writes
drm/i915/gen9: Check for DC state mismatch
drm/i915/skl: Ensure HW is powered during DDB HW state readout
drm/i915/lvds: Ensure the HW is powered during HW state readout
drm/i915/hdmi: Ensure the HW is powered during HW state readout
drm/i915/dsi: Ensure the HW is powered during HW state readout
drm/i915/dp: Ensure the HW is powered during HW state readout
drm/i915: Ensure the HW is powered when accessing the CRC HW block
drm/i915/ddi: Ensure the HW is powered during HW state readout
drm/i915/crt: Ensure the HW is powered during HW state readout
drm/i915: Ensure the HW is powered during HW access in assert_pipe
drm/i915: Ensure the HW is powered when disabling VGA
drm/i915/ibx: Ensure the HW is powered during PLL HW readout
drm/i915: Ensure the HW is powered during display pipe HW readout
drm/i915: Add helper to get a display power ref if it was already enabled
That should make user space bugs more obvious.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The event_data passed from pem_fini was not cleared upon initialization.
This caused NULL checks to pass and cast_const_phw_tonga_power_state to
attempt to dereference an invalid pointer. Clear the event_data in
pem_init and pem_fini before calling pem_handle_event.
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Bradley Pankow <btpankow@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Print a message when the HDMI I2C slave encoder can't be found to help
debugging probe deferral issues.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The LVDS encoder differs slightly in Gen3 SoCs in its PLL configuration.
Add support for the Gen3 LVDS PLL parameters and startup procedure.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Document the R8A7795-specific DT bindings and support them in the
driver. The HDMI and LVDS outputs are currently not supported.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The ODDF signal, output by default on the ODDF pin, isn't used on any
board supported in the kernel. As the Gen3 Salvator-X board uses the
ODDF pin as a DISP signal, hardcode that configuration in the driver.
Use of the ODDF signal will be implemented later through proper DT-based
configuration of the DU pins.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The DE signal is currently configured to be identical to the DISP
signal and is used for the same purpose. To make it clearer that the
DISP pin outputs the DISP signal, select it explicitly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The Gen3 R8A7795 DU has 4 CRTCs, support them all.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
LVDS support depends on DRM_RCAR_DU which already depends on OF. Drop
the explicit dependency.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The R8A7795 SoC is ARM64-based and include a DU. Enable driver
compilation on ARM64.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Use %tu instead of %u to print difference between pointers.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
On R-Car Gen3 SoCs the DU lost its ability to access memory directly and
needs to work in conjunction with the VSP to do so. This commit handles
the VSP internally to hide it from the user.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the
relevant display power well. So we should make sure we've finished
processing them before turning off the power well.
The pipe interrupts shouldn't really happen at this point anymore since
we've already shut down the planes/pipes/whatnot, but being a bit
paranoid shouldn't hurt.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
After we've told the irq code we don't want to handle display irqs
anymore, we must make sure any display irq handling already
kicked off has finished before we actually turn off the power well.
I wouldn't expect PIPESTAT based interrupts to occur anymore since
vblanks/page flips/gmbus/etc should all be quiescent at this point.
But at least hotplug interrupts could still occur. Hotplug
interrupts may also kick off the workqueue based hotplug processing,
but that code should take the required power domain references
itself, so there shouldn't be any need to synchronize with the
hotplug processing from the power well code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455900112-15387-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
PIPESTAT registers live in the display power well on VLV/CHV, so we
shouldn't access them when things are powered down. Let's check
whether the display interrupts are on or off before accessing the
PIPESTAT registers.
Another option would be to read the PIPESTAT registers only when
the IIR register indicates that there's a pending pipe event. But
that would mean we might miss even more underrun reports than we
do now, because the underrun status bit lives in PIPESTAT but doesn't
actually generate an interrupt.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93738
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455825266-24686-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
It has been observed that sometimes disabling the dc6 fails
and dc6 state pops back up, brief moment after disabling. This
has to be dmc save/restore timing issue or other bug in the
way dc states are handled.
Try to work around this issue as we don't have firmware fix
yet available. Verify that the value we wrote for the dmc sticks,
and also enforce it by rewriting it, if it didn't.
v2: Zero rereads on rewrite for extra paranoia (Imre)
Testcase: kms_flip/basic-flip-vs-dpms
References: https://bugs.freedesktop.org/show_bug.cgi?id=93768
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 779cb5d3dd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The DMC can incorrectly run off and allow DC states on it's own. We
don't know the root-cause for this yet but this patch makes it more
visible.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 832dba889e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
I.e., doesn't make sense to change power states or check the
temperature when the asic is powered off.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Looks like a copy paste typo when we added powerplay
support.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Looks like a copy/paste typo.
Reviewed-by: Christian König <christian.koenig@amd.com>
Noticed-by: David Panariti <David.Panariti@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 4d80003023)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com
(cherry picked from commit ecb2448218)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com
(cherry picked from commit 5b0921748c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com
(cherry picked from commit 3f3f42b887)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com
(cherry picked from commit 6fa9a5ecf7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
While at it also add the missing reference around the HW access in
i915_interrupt_info().
v2:
- update the commit message mentioning that this also fixes the
HW access in the interrupt info debugfs entry (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com
(cherry picked from commit e129649b7a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com
(cherry picked from commit e27daab497)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com
(cherry picked from commit 1c8fdda1ea)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com
(cherry picked from commit 4feed0ebfa)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com
(cherry picked from commit 6392f8478e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com
(cherry picked from commit 12fda3876d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Revieved-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com
(cherry picked from commit 1729050eb4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold. In such cases we get either the wakeref
not held, or an unclaimed register access error message. To fix this in
a future-proof way that's independent of other locks wrap any such
access with a get_ref_if_enabled()/put_ref() pair.
Kudos to Ville and Joonas for the ideas of this new interface.
v2:
- init the power_domains ptr when declaring it everywhere (Joonas)
v3:
- don't report the device to be powered if runtime PM is disabled
CC: Mika Kuoppala <mika.kuoppala@intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 0973128002)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cores need to be included into the debug mask. We don't exactly
know what it does but the spec says it must be enabled. So obey.
v2: Cores should be only set for BXT (Imre, Art)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455877564-5128-1-git-send-email-mika.kuoppala@intel.com
It has been observed that sometimes disabling the dc6 fails
and dc6 state pops back up, brief moment after disabling. This
has to be dmc save/restore timing issue or other bug in the
way dc states are handled.
Try to work around this issue as we don't have firmware fix
yet available. Verify that the value we wrote for the dmc sticks,
and also enforce it by rewriting it, if it didn't.
v2: Zero rereads on rewrite for extra paranoia (Imre)
Testcase: kms_flip/basic-flip-vs-dpms
References: https://bugs.freedesktop.org/show_bug.cgi?id=93768
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
The DMC can incorrectly run off and allow DC states on it's own. We
don't know the root-cause for this yet but this patch makes it more
visible.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
The plane allocator is specific to DU planes and won't be used for
VSP-based planes, move it with the rest of the DU planes code where it
belongs.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Configure the plane source at plane setup time to source frames from
memory or from the VSP1.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
maximum availability of planes 0 and 1.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Rename plane setup functions using more explicit names, and use local
variables to store intermediate values to increase readability. This
also prepares for VSP compositor support.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
There's no need for a read-modify-write pattern, all register bits can
be set explicitly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
A disabled CRTC can't display planes, the driver shouldn't try to
configure it when updating planes. The DRM core will store the plane
state for us, and the plane will be configured appropriately the next
time the CRTC is enabled.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The atomic framework guarantees that the CRTC enable and disable
functions will only be called when needed, there's no need to duplicate
the CRTC state check. By replacing the local CRTC enabled state check at
resume time with the CRTC active state we can remove the local CRTC
enabled state altogether.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a regression introduced in Linux 4.4.
This is a port of the same fix for radeon-kms in the
patch "drm/radeon: Don't hang in radeon_flip_work_func
on disabled crtc. (v2)"
Limit the amount of time amdgpu_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of amdgpu_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. amdgpu_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit 8e36f9d33c ("drm/amdgpu: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This fixes a regression introduced in Linux 4.4.
Limit the amount of time radeon_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of radeon_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. radeon_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit 5b5561b366 ("drm/radeon: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
v2: Skip wait immediately if !radeon_crtc->enabled, as
suggested by Michel.
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These platforms should be fine now.
FBC can allow very significant power savings for screen-on idle
systems, but it is worth mentioning that a lot of people won't get
significant power savings by enabling this feature because they may
have something else preventing the system from getting into the
deepest sleep states. Examples may include a hungry wifi device or a
max_performance SATA link power management policy. You can check your
PC state residencies on the powertop "Idle stats" tab. I recommend
trying to run "sudo powertop --auto-tune" and then seeing if the
residencies improve.
Oh, and in case you - the person reading this commit message - found
this commit through git bisect, please do the following:
- Check your dmesg and see if there are error messages mentioning
underruns around the time your problem started happening.
- Download intel-gpu-tools, compile it, and run:
$ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt
Then send us the fbc.txt file, especially if you get a failure.
This will really maximize your chances of getting the bug fixed
quickly.
- Try to find a reliable way to reproduce the problem, and tell us.
- Boot with drm.debug=0xe, reproduce the problem, then send us the
dmesg file.
v2: Don't enable by default on SKL.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455655643-2535-1-git-send-email-paulo.r.zanoni@intel.com
The bpp value which is used while calulating the txbyteclkhs values
should be wrt the pixel format value. Currently bpp is coming
from pipe config to calculate txbyteclkhs. Fix it in this patch.
V2: dsi_pixel_format_bpp is used to retrieve the bpp from pixel_format
[Review: Jani]
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Mika Kahola <mika.kahola@intel.com> # BYT
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455203007-10850-1-git-send-email-ramalingam.c@intel.com
We need to use post-decrement to get the dma_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if dma_map_page
failed already at i==0.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Because we record connector_mask using 1 << drm_connector_index now
the connector_mask should stay the same even when other connectors
are removed. This was not the case with MST, in that case when removing
a connector all other connectors may change their index.
This is fixed by waiting until the first get_connector_state to allocate
connector_state, and force reallocation when state is too small.
As a side effect connector arrays no longer have to be preallocated,
and can be allocated on first use which means a less allocations in
the page flip only path.
Changes since v1:
- Whitespace. (Ville)
- Call ida_remove when destroying the connector. (Ville)
- u32 alloc -> int. (Ville)
Fixes: 14de6c44d1 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.")
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJWxNLgAAoJELXWKTbR/J7oxPQP/2XgTgdqKBRm+5z/rCJDM82c
bC6GOuwa/1DiQgaEB+TcQJI5fUgQQy3j9iH7GrPd1INDpa8Uph0ykc8ksLfzT/dD
xMXjB7eQuJzmQ731TbSEJ05y3ZJB1A5yoJocaPYH8V1VRi+LE2XmhQNzjkgT3CFU
4Ie8Myrq6wPDWXMhHnsYXD9xzaIC3MjQBnISarze3PqtZK6XzvkzfuE6h03wUCRD
AbZp8BiyxoXbC+NHbMiXo1gQ4rXF47nJWRRBGG1I567XKSeBCswk6oeiwOwk6D/T
YtUKUmNqnAGAhmhnxVaEx/YsciHEyybi43GWw/AFGixJl7i08+erW7zXi6TkHkKL
StOs63X6mIgZVTEfdb+mqqv67+qdGOuQJLvfk8Q1ZC0eoq6lcDq5itpI9jHVn35s
FODMLmpjpl8MC6XtXJr0wYSw1lZbPD6QOYMfBZvljO0M0W46kadc0Mzw+MPeeg5L
aLPaL+0wvqt0qfQmzJQ3HmWtXsWfgqvpd8ohuBfbdMN6rOZtL35mGc1Akx7c8B2O
LKplwxLZ928aLTuFT+xOaiGp3ywFkLoq4bRmy0eyiAPU9KWON577UIZ566D6/yU4
iOp33T/r5345UxklQ1oTqnOuHzoqVeXQXUaQudFc+BVCuN3XVVvb8mT72ACgQPMR
e5SnfHyp3LZhPmXQMChr
=Z9VX
-----END PGP SIGNATURE-----
Merge tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux into drm-next
This pull request brings in overlay plane support for vc4.
* tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux:
drm/vc4: Add support for YUV planes.
drm/vc4: Add support a few more RGB display plane formats.
drm/vc4: Add support for scaling of display planes.
drm/vc4: Fix which value is being used for source image size.
drm/vc4: Add more display planes to each CRTC.
drm/vc4: Make the CRTCs cooperate on allocating display lists.
drm/vc4: Add a proper short-circut path for legacy cursor updates.
drm/vc4: Move the plane clipping/scaling setup to a separate function.
drm/vc4: Add missing __iomem annotation to hw_dlist.
drm/vc4: Improve comments on vc4_plane_state members.
V3D integration due to build breakage) and waits for idle in the
presence of signals (which X likes to do a lot).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJWxNTWAAoJELXWKTbR/J7oJl4P/AouaCmV5G3P0x+s/qiWY7ZY
ppSFTyNI5sw25m4Ag/5hIqMkSbgj72o7lacpNk2Jt3qudOVDNzLeujjabHHvA6pK
FOXq1IadYdidsnhgWr7GB1aB9tSsSzLEfNw/2JKilzGQUlkebQuGK1cLFZSowcRy
dYo4RaFJJ4ucFAIf2rkdhemfPRLfPSB2P6DUZURMprFO1xj/m7eOfiVgcLDPUtBS
WvuDEFL+7YVP92tlxwlPQ7Gmz5DgnSoIn9aS8j0YDlRTPZ9bXsMz/VEjIKK90Ea4
qV+UE+DPkay8632fKdDaLzajyCqGoi7RW0XQFxSdfHGrJm2C8miMlg39ht7ylpVv
djwatw/BO/wDh9NWUftkq0ByUA8OqGelTq+jlR5EwEkNN3WoGjsh7+VPd+4Fdkoc
tH+YQOMX/2DE6v3y1hePqzGSeAn+HmggYWOqsevmZ0Q8xKLM2xEdIZ6USTZMFRXH
SkUvE9miJqMuroRCtB8k/9QSbLzCGla1liC01XvOTU2AqoJe1WBHJOB3Oj1HcFhK
oipWy28O9A4YByobQvG6SdadfbGfaViWWTidcchxj/USiPqqBTyi/CPQMKhpOpA5
PcQgXLGPeolwjUYobhGJmTfyPjILkprYNFXuFmoYkLtqHsRxhezfIQvylXLD1GrO
UPfH0YAYypTi1w+O8t2N
=fLU7
-----END PGP SIGNATURE-----
Merge tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux into drm-fixes
This pull request fixes GPU reset (which was disabled shortly after
V3D integration due to build breakage) and waits for idle in the
presence of signals (which X likes to do a lot).
* tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux:
drm/vc4: Use runtime PM to power cycle the device when the GPU hangs.
drm/vc4: Enable runtime PM.
drm/vc4: Fix spurious GPU resets due to BO reuse.
drm/vc4: Drop error message on seqno wait timeouts.
drm/vc4: Fix -ERESTARTSYS error return from BO waits.
drm/vc4: Return an ERR_PTR from BO creation instead of NULL.
drm/vc4: Fix the clear color for the first tile rendered.
drm/vc4: Validate that WAIT_BO padding is cleared.
Just two small fixes in the ttm_tt_populate error handling; one for radeon,
one for amdgpu.
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: use post-decrement in error handling
drm/amdgpu: use post-decrement in error handling
First radeon and amdgpu pull request for 4.6. Highlights:
- ACP support for APUs with i2s audio
- CS ioctl optimizations
- GPU scheduler optimizations
- GPUVM optimizations
- Initial GPU reset support (not enabled yet)
- New powerplay sysfs interface for manually selecting clocks
- Powerplay fixes
- Virtualization fixes
- Removal of hw semaphore support
- Lots of other misc fixes and cleanups
* 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux: (118 commits)
drm/amdgpu: Don't call interval_tree_remove in amdgpu_mn_destroy
drm/amdgpu: Fix race condition in amdgpu_mn_unregister
drm/amdgpu: cleanup gem init/finit
drm/amdgpu: rework GEM info printing
drm/amdgpu: print the GPU offset as well in gem_info
drm/amdgpu: optionally print the pin count in gem_info as well
drm/amdgpu: print the BO size only once in amdgpu_gem_info
drm/amdgpu: print pid as integer
drm/amdgpu: remove page flip work queue v3
drm/amdgpu: stop blocking for page filp fences
drm/amdgpu: stop calling amdgpu_gpu_reset from the flip code
drm/amdgpu: remove fence reset detection leftovers
drm/amdgpu: Fix race condition in MMU notifier release
drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled
drm/amdgpu/vi: move uvd tiling config setup into uvd code
drm/amdgpu/vi: move sdma tiling config setup into sdma code
drm/amdgpu/cik: move uvd tiling config setup into uvd code
drm/amdgpu/cik: move sdma tiling config setup into sdma code
drm/amdgpu/gfx7: rework gpu_init()
drm/amdgpu/gfx: clean up harvest configuration (v2)
...
Misc stuff all over:
- more mode_fixup removal from Carlos, there's another final pile still
left.
- final bits of vgaswitcheroo from Lukas for apple gmux, we're still
discussing an api cleanup patch to make it a bit more abuse-safe as a
follow-up
- dp aux interface for userspace for tools&tests from Rafael Antognolli
- actual interface parts for dma-buf flushing for userspace mmap
- few small bits all over
- vgaswitcheroo support for apple gmux from Lukas Wunner
- checks for ->mode_fixup in non-atomic helpers from Carlos Palminha, plus
removing dummy funcs from drivers. Carlos promised to follow up with
more, since there's lots more silly dummy functions around.
- dma-buf patches from Tiago, except the ioctl itself (that needed a
respin to address review from David Herrmann)
- encoder mask for atomic from Maarten
- bunch of random things all over.
* tag 'topic/drm-misc-2016-02-18' of git://anongit.freedesktop.org/drm-intel: (57 commits)
drm/udl: Use module_usb_driver
drm: fixes crct set_mode when crtc mode_fixup is null.
drm/tilcdc: removed optional dummy encoder mode_fixup function.
drm/sti: removed optional dummy encoder mode_fixup function.
drm/rockchip: removed optional dummy encoder mode_fixup function.
drm/qxl: removed optional dummy encoder mode_fixup function.
drm/mgag200: removed optional dummy encoder mode_fixup function.
drm/msm/mdp: removed optional dummy encoder mode_fixup function.
drm/imx: removed optional dummy encoder mode_fixup function.
drm/gma500: removed optional dummy encoder mode_fixup function.
drm/radeon: removed optional dummy encoder mode_fixup function.
drm/cirrus: removed optional dummy encoder mode_fixup function.
drm/bochs: removed optional dummy encoder mode_fixup function.
drm/ast: removed optional dummy encoder mode_fixup function.
drm/amdgpu: removed optional dummy encoder mode_fixup function.
drm/exynos: removed optional dummy encoder mode_fixup function.
drm/udl: removed optional dummy encoder mode_fixup function.
drm/virtio: removed optional dummy encoder mode_fixup function.
drm/fb_helper: Use add_one_connector in add_all_connectors.
drm/fb_helper: Use correct allocation count for arrays.
...
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com
Instead of restoring dpms and a flag for whether a temp fb is allocated duplicate
an atomic state before the new state is committed, and commit it the old state
in intel_release_load_detect_pipe.
Changes since v1:
- Use a real atomic state. (Ville)
Changes since v2:
- Do not preserve shared_dpll any more, no need to do so. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-2-git-send-email-maarten.lankhorst@linux.intel.com
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
rbtree_postorder_for_each_entry_safe can skip over some entries if
the tree is rebalanced in interval_tree_remove. interval_tree_remove
is also redundant when the tree is just about to be freed.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Exchange locking order of adev->mn_lock and mm_sem, so that
rmn->mm->mmap_sem can be taken safely, protected by adev->mn_lock,
when amdgpu_mn_destroy runs concurrently.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
With a reliable frontbuffer tracking and all instability corner cases
on Haswell and Broadwell solved let's re-enabled PSR by default on
these platforms.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away. If this is the case
PSR is the culprit so after that please check if i915.enable_psr=2
or i915.enable_psr=3 solves your issue and please let us know.
There are many panels out there and not all implementations apparently
work as we would expect.
In case you needed to force it on standby or disabled or in case of any
PSR related bug please report it at bugs.freedesktop.org.
In a bugzilla entry for PSR is desirable:
- dmesg (drm.debug=0xe)
- output of /sys/kernel/debug/dri/0/i915_edp_psr_status
- Platform information. Vendor, model, id, pci id.
- Graphical environment: Gnome, KDE, openbox, etc...
- Details how to reproduce.
- Also good if you could run PSR test cases of Intel-gpu-tools
- Please mention if forcing main link standby or main link off helps you.
There are Intel-gpu-tools test cases that can be helpful to
determine if PSR is working as expected:
kms_psr_sink_crc and kms_psr_frontbuffer_tracking.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455278893-1307-2-git-send-email-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With a reliable frontbuffer tracking and all instability corner cases
solved for this platform let's re-enabled PSR by default.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away,
please report it at bugs.freedesktop.org.
In a bugzilla entry for PSR is desirable:
- dmesg (drm.debug=0xe)
- output of /sys/kernel/debug/dri/0/i915_edp_psr_status
- Platform information. Vendor, model, id, pci id.
- Graphical environment: Gnome, KDE, openbox, etc...
- Details how to reproduce.
- Also good if you could run PSR test cases of Intel-gpu-tools
- Please mention if forcing main link standby or main link off helps you.
There are Intel-gpu-tools test cases that can be helpful to
determine if PSR is working as expected:
kms_psr_sink_crc and kms_psr_frontbuffer_tracking.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will give us flexibility to enable PSR by default independently so
issues and corner cases in one platform won't affect others were we have
it working properly.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise a pde_shift big enough to overflow a u32 will be truncated before
assignment
Note: We never asked for ranges spanning a 4G boundary, so this issue
doesn't cause a real problem.
Signed-off-by: Alan Cox <alan@linux.intel.com>
[danvet: Add note why this isn't a real problem.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160217142043.4947.60447.stgit@localhost.localdomain
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
While at it also add the missing reference around the HW access in
i915_interrupt_info().
v2:
- update the commit message mentioning that this also fixes the
HW access in the interrupt info debugfs entry (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Revieved-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold. In such cases we get either the wakeref
not held, or an unclaimed register access error message. To fix this in
a future-proof way that's independent of other locks wrap any such
access with a get_ref_if_enabled()/put_ref() pair.
Kudos to Ville and Joonas for the ideas of this new interface.
v2:
- init the power_domains ptr when declaring it everywhere (Joonas)
v3:
- don't report the device to be powered if runtime PM is disabled
CC: Mika Kuoppala <mika.kuoppala@intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
Macro module_usb_driver is used for drivers whose init and exit paths
only register and unregister to usb API. So remove boilerplate code to
make code simpler by using module_usb_driver.
This change was made with the help of the following Coccinelle
semantic patch:
//<smpl>
@a@
identifier f, x;
@@
-static f(...) { return usb_register(&x); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { usb_deregister(&x); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_usb_driver;
@@
-module_exit(e);
+module_usb_driver(x);
//</smpl>
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160217121327.GA29682@amitoj-Inspiron-3542
userptr requires mmu-notifier for full unprivileged support. Most
systems have mmu-notifier support already enabled as a requirement for
virtualisation support, but we should make the option for i915 to take
advantage of mmu-notifiers explicit (and enable by default so that
regular userspace can take advantage of passing client memory to the
GPU.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452503961-14837-3-git-send-email-chris@chris-wilson.co.uk
Looks like g4x hpd live status bits actually agree with the spec. At
least they do on the machine I have, and apparently on Nick Bowler's
g4x as well.
So gm45 may be the only platform where they don't agree. At least
that seems to be the case based on the (somewhat incomplete)
logs/dumps in [1], and Daniel has also tested this on his gm45
sometime in the past.
So let's change the bits to match the spec on g4x. That actually makes
the g4x bits identical to vlv/chv so we can just share the code
between those platforms, leaving gm45 as the special case.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=52361
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nick Bowler <nbowler@draconx.ca>
References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html
Reported-by: Nick Bowler <nbowler@draconx.ca>
Cc: stable@vger.kernel.org
Fixes: 237ed86c69 ("drm/i915: Check live status before reading edid")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0780cd36c7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The qxl_gem_prime_mmap() function returns ENOSYS instead of -ENOSYS
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the display resume path, move the calls to drm_vblank_on()
after the point when the display engine is running again.
Since changes were made to drm_update_vblank_count() in Linux 4.4+
to emulate hw vblank counters via vblank timestamping, the function
drm_vblank_on() now needs working high precision vblank timestamping
and therefore working scanout position queries at time of call.
These don't work before the display engine gets restarted, causing
miscalculation of vblank counter increments and thereby large forward
jumps in vblank count at display resume. These jumps can cause client
hangs on resume, or desktop hangs in the case of composited desktops.
Fix this Linux 4.4 regression by reordering calls accordingly.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.
This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.
v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit cd19e52aee
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.
Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 3.18+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.
This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.
This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.
Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:
Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be active at the moment,
as the current implementation of the timestamp caching and updating is
not safe against concurrent readers for calls to store_vblank() with a
bump of anything but +1. A bump != 1 would very likely return corrupted
timestamps to userspace, because the same slot in the cache could
be concurrently written by store_vblank() and read by one of those
readers in a non-atomic fashion and without the read-retry logic
detecting this collision.
Concurrent readers can exist while drm_update_vblank_count() is called
from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
irq callers. However, all those calls are happening with the vbl_lock
locked thereby preventing a drm_vblank_get(), so the vblank refcount
can't increase while drm_update_vblank_count() is executing. Therefore
a zero vblank refcount during execution of that function signals that
is safe for arbitrary counter bumps if called from outside vblank irq,
whereas a non-zero count is not safe.
Whenever the function is called from vblank irq, we have to assume concurrent
readers could show up any time during its execution, even if the refcount
is currently zero, as vblank irqs are usually only enabled due to the
presence of readers, and because when it is called from vblank irq it
can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
Therefore also restrict bumps to +1 when the function is called from vblank
irq.
Such bumps of more than +1 can happen at other times than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.
A better solution would be to rewrite the timestamp caching to use
full seqlocks to allow concurrent writes and reads for arbitrary
vblank counter increments.
v2: Add code comment that this is essentially a hack and should
be replaced by a full seqlock implementation for caching of
timestamps.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.
At least with the legacy drm helpers it is not unusual to
get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
were observed on radeon-kms during dpms-off -> dpms-on transition.
We don't no-op calls from atomic modesetting drivers, as they
should do a proper job of tracking hw state.
Fixes large jumps of the software maintained vblank counter due to
the hardware vblank counter resetting to zero during dpms off or
modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
instead of drm_vblank_pre/post_modeset().
This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.
v2: Don't no-op on atomic modesetting drivers, per suggestion
of Daniel Vetter.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoids integer overflows on 32bit machines when calculating
reloc_info size, as reported by Alan Cox.
Cc: stable@vger.kernel.org
Cc: gnomes@lxorguk.ukuu.org.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Summary:
- fix compilation warnings on ARM64bit.
- fix mic driver initialization.
. MIC is a part of KMS so it converts it to use component framework
like other KMS drivers did.
- fix wrong driver state and disable clock order on DECON driver.
- fix incorrect use of dma_mmap_attrs function.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos/decon: fix disable clocks order
drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
drm/exynos: dsi: restore support for drm bridge
drm/exynos: mic: make all functions static
drm/exynos: mic: convert to component framework
drm/exynos: mic: use devm_clk interface
drm/exynos: fix types for compilation on 64bit architectures
drm/exynos: ipp: fix incorrect format specifiers in debug messages
drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS
This reverts commit cfcfa086d4.
This causes the tiling properties to break in some unexpected ways,
Revert it for now.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove the double housekeeping and use something sane to
forcefuly delete BOs on unload.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Splitting it into KB/MB is just confusing.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Not sure why somebody thought that this is a long.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Just use the system queue now that we don't block any more.
v2: handle DAL as well.
v3: agd: split DAL changes out
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Mykola Lysenko <mykola.lysenko@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Just register an callback and reschedule the work item if necessary.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
wait_event() never returns before the fence was signaled.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
The release notifier can get called a second time from
mmu_notifier_unregister depending on a race between
__mmu_notifier_release and amdgpu_mn_destroy. Use
mmu_notifier_unregister_no_release to avoid this.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This gets us functional GPU reset again, like we had until a refactor
at merge time. Tested with a little patch to stuff in a broken binner
job every 100 frames.
Signed-off-by: Eric Anholt <eric@anholt.net>
This may actually get us a feature that the closed driver didn't have:
turning off the GPU in between rendering jobs, while the V3D device is
still opened by the client.
There may be some tuning to be applied here to use autosuspend so that
we don't bounce the device's power so much, but in steady-state
GPU-bound rendering we keep the power on (since we keep multiple jobs
outstanding) and even if we power cycle on every job we can still
manage at least 680 fps.
More importantly, though, runtime PM will allow us to power off the
device to do a GPU reset.
v2: Switch #ifdef to CONFIG_PM not CONFIG_PM_SLEEP (caught by kbuild
test robot)
Signed-off-by: Eric Anholt <eric@anholt.net>
We were tracking the "where are the head pointers pointing" globally,
so if another job reused the same BOs and execution was at the same
point as last time we checked, we'd stop and trigger a reset even
though the GPU had made progress.
Signed-off-by: Eric Anholt <eric@anholt.net>
These ioctls end up getting exposed to fairly directly to GL users,
and having normal user operations print DRM errors is obviously wrong.
The message was originally to give us some idea of what happened when
a hang occurred, but we have a DRM_INFO from reset for that.
Signed-off-by: Eric Anholt <eric@anholt.net>
This caused the wait ioctls to claim that waiting had completed when
we actually got interrupted by a signal before it was done. Fixes
broken rendering throttling that produced serious lag in X window
dragging.
Signed-off-by: Eric Anholt <eric@anholt.net>
Apparently in hardware (as opposed to simulation), the clear colors
need to be uploaded before the render config, otherwise they won't
take effect. Fixes igt's vc4_wait_bo/used-bo-* subtests.
Signed-off-by: Eric Anholt <eric@anholt.net>
This supports 420 and 422 subsampling with 2 or 3 planes, tested with
modetest. It doesn't set up chroma subsampling position (which it
appears KMS doesn't deal with yet).
The LBM memory is overallocated in many cases, but apparently the docs
aren't quite correct and I'll probably need to look at the hardware
source to really figure it out.
Signed-off-by: Eric Anholt <eric@anholt.net>
This implements a simple policy for choosing scaling modes
(trapezoidal for decimation, PPF for magnification), and a single PPF
filter (Mitchell/Netravali's recommendation).
Signed-off-by: Eric Anholt <eric@anholt.net>
This doesn't matter yet since we only allow 1:1 scaling, but the
comment clearly says we should be using the source size.
Signed-off-by: Eric Anholt <eric@anholt.net>
Previously we only did the primary and cursor plane, but overlay
planes are useful and just require this setup to add, since all planes
go into the HVS display list in the same way.
Signed-off-by: Eric Anholt <eric@anholt.net>
So far, we've only ever lit up one CRTC, so this has been fine. To
extend to more displays or more planes, we need to make sure we don't
run our display lists into each other.
Signed-off-by: Eric Anholt <eric@anholt.net>
Previously, on every modeset we would allocate new display list
memory, recompute changed planes, write all of them to the new memory,
and pointed scanout at the new list (which will latch approximately at
the next line of scanout). We let
drm_atomic_helper_wait_for_vblanks() decide whether we needed to wait
for a vblank after a modeset before cleaning up the old state and
letting the next modeset proceed, and on legacy cursor updates we
wouldn't wait. If you moved the cursor fast enough, we could
potentially wrap around the display list memory area and overwrite the
existing display list while it was still being scanned out, resulting
in the HVS scanning out garbage or just halting.
Instead of making cursor updates wait for scanout to move to the new
display list area (which introduces significant cursor lag in X), we
just rewrite our current display list.
Signed-off-by: Eric Anholt <eric@anholt.net>
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The check for active_crtcs == 0 was performed by the callers, when changing
the patches I forgot to remove those hunks.
This resulted in skylake scalers still not having the correct cdclk to
calculate scaling when all crtc's were dpms off.
Fixes: 1a617b7765 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455614711-9045-1-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Instead of duplicating the functionality now that we no longer need
to preserve dpll state we can move to using the upstream suspend helper.
Changes since v1:
- Call hw readout with all mutexes held.
- Rework intel_display_suspend to only assign modeset_restore_state
on success.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56C2E686.5060803@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We will soon modify the vanilla get_user_pages() so it can no
longer be used on mm/tasks other than 'current/current->mm',
which is by far the most common way it is called. For now,
we allow the old-style calls, but warn when they are used.
(implemented in previous patch)
This patch switches all callers of:
get_user_pages()
get_user_pages_unlocked()
get_user_pages_locked()
to stop passing tsk/mm so they will no longer see the warnings.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: jack@suse.cz
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20160212210156.113E9407@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For protection keys, we need to understand whether protections
should be enforced in software or not. In general, we enforce
protections when working on our own task, but not when on others.
We call these "current" and "remote" operations.
This patch introduces a new get_user_pages() variant:
get_user_pages_remote()
Which is a replacement for when get_user_pages() is called on
non-current tsk/mm.
We also introduce a new gup flag: FOLL_REMOTE which can be used
for the "__" gup variants to get this new behavior.
The uprobes is_trap_at_addr() location holds mmap_sem and
calls get_user_pages(current->mm) on an instruction address. This
makes it a pretty unique gup caller. Being an instruction access
and also really originating from the kernel (vs. the app), I opted
to consider this a 'remote' access where protection keys will not
be enforced.
Without protection keys, this patch should not change any behavior.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: jack@suse.cz
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20160212210154.3F0E51EA@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This behavior of checking for a shmem backed GEM object was introduced here:
commit 4c914c0c7c
Author: Brad Volkin <bradley.d.volkin@intel.com>
Date: Tue Feb 18 10:15:45 2014 -0800
drm/i915: Refactor shmem pread setup
It is possible for an object to not be a shmem backed GEM object (for example
userptr objects). An example of how we hit this failure can be found through
copy_batch() in the command parser because we allocate a userptr object for the
batch which contains privileged instructions. Userptr calls
drm_gem_private_object_init() which explicitly sets the filp to none.
NOTE: I manually retyped this from a test machine. So I haven't even compiled
this exact patch.
v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455047053-2644-1-git-send-email-benjamin.widawsky@intel.com
intel_digital_port_connected() lacks one 'else'. There's no
actual harm in not having it since each branch has an unconditional
return, so it can't accidentally end up in taking two branches instead
of just the one. But let's be consistent and add the 'else' anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455201868-31527-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Looks like g4x hpd live status bits actually agree with the spec. At
least they do on the machine I have, and apparently on Nick Bowler's
g4x as well.
So gm45 may be the only platform where they don't agree. At least
that seems to be the case based on the (somewhat incomplete)
logs/dumps in [1], and Daniel has also tested this on his gm45
sometime in the past.
So let's change the bits to match the spec on g4x. That actually makes
the g4x bits identical to vlv/chv so we can just share the code
between those platforms, leaving gm45 as the special case.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=52361
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nick Bowler <nbowler@draconx.ca>
References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html
Reported-by: Nick Bowler <nbowler@draconx.ca>
Cc: stable@vger.kernel.org
Fixes: 237ed86c69 ("drm/i915: Check live status before reading edid")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Code does read-modify-write but the read was outside the lock.
It is fine since the caller holds struct mutex, but if we
correct this we open up the opportunity for decreasing the
mutex duration time since the call to ironlake_enable_drps
does not need it any longer since it is covered by the
mchdev_lock lock.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1455186452-13691-2-git-send-email-tvrtko.ursulin@linux.intel.com
It does not look like this code needs to wait atomically?
Higher in the call chain it calls the GEM API and I do
not see that the section is under any spin locks or such.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
RPS lock must be taken before the struct_mutex to avoid
locking inversion. So stop grabbing it for the whole
powersave initialization and instead only take it during
the sections which need it.
Also, struct_mutex is not needed any more since dedicated
RPS lock was added in:
commit 4fc688ce79
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Nov 2 11:14:01 2012 -0700
drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex
Based on prototype patch by Chris Wilson and a subsequent
mailing list discussion involving Ville, Imre, Chris and
Daniel.
v2: More details in the commit.
v3: Use drm_gem_object_unreference_unlocked. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.
v3:
Some callers of i915_gem_object_create_stolen_for_preallocated
already hold the lock so move the mutex into the other caller
as well.
v4:
Changed to lockdep_assert_held. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
We know this never runs from interrupt context so
don't need to use the flags variant.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atomic resume was preserving the dpll state because it was required
for clearing pll state correctly. If we look at the old_crtc_state
for pll to clear this is not needed and the hack can be removed.
Changes since v1:
- Rename dpll variable to old_dpll. (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455022343-15222-1-git-send-email-maarten.lankhorst@linux.intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Decon requires that clocks should be disabled in reverse order. Otherwise
system hangs.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
dma_mmap_attrs() should be called with cpu address returned by
dma_alloc_attrs(). Existing code however passed pages array base as cpu
address. This worked only by a pure luck on ARM architecture. This patch
fixes this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
BIT_IRQS_ENABLED was never set because of incorrect test in
decon_vlank_enable() function, what resulted in lack of enabling vblank
support. This patch fixes this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Patch ebf3fd403b ("drm/exynos: add
pm_runtime to DECON 5433") removed some code from decon_enable()
function, but it left set_bit(BIT_SUSPENDED, &ctx->flags) call, which
was earlier called only in error path. This patch removes it, what
finally lets driver to go out of suspended state.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes issue introduced by commit
cf67cc9a29 ("drm/exynos: remove struct
exynos_drm_display"), which removed assigning of drm bridge to drm
encoder. Lack of it caused that no bridge callbacks were called on
encoder enable/disable actions.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
There is no point exposing all internal functions to global kernel name
space, so make all internals functions static.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
MIC is SoC component and important part of kms pipeline on Exynos5433,
so convert it to use component framework like other KMS/CRTC drivers.
MIC driver is already listed on KMS component driver list in Exynos DRM
core, so without this conversion, initialization of Exynos DRM core
fails on Exynos 5433 SoC.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Drivers should use devm_clk* interface instead of of_clk* functions.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes compilation warnings (on 64bit architectures) and bugs
related to casting pointers through 32bit integers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Drivers should use %p for printing pointers instead of hardcoding them
as hexadecimal integers. This patch fixes compilation warnings on 64bit
architectures.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Because PLAT_SAMSUNG isn't include exynos SoCs for arm64, but
ARCH_EXYNOS can do it. And it also needs to add ARCH_S3C64XX instead of
PLAT_SAMSUNG.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fix some spelling typos found in Documentation/Docbook
gpu/ch04s03.html. This file was generated from comments within
source, so I have to fix typos in i915_gem_fence.c.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
upon a full ring to advance). Don't emit an error for this.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454086145-16160-3-git-send-email-chris@chris-wilson.co.uk
i915 display fixes mostly.
* tag 'drm-intel-fixes-2016-02-12' of git://anongit.freedesktop.org/drm-intel:
drm/i915: fix error path in intel_setup_gmbus()
drm/i915/skl: Fix typo in DPLL_CFGCR1 definition
drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)
drm/i915/dp: reduce missing TPS3 support errors to debug logging
drm/i915/dp: abstract training pattern selection
drm/i915/dsi: skip gpio element execution when not supported
drm/i915/dsi: don't pass arbitrary data to sideband
drm/i915/dsi: defend gpio table against out of bounds access
drm/i915/bxt: Don't save/restore eDP panel power during suspend (v3)
drm/i915: Allow i915_gem_object_get_page() on userptr as well
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the drm_connector.
This also removes the need to add a sysfs link for the i2c device under
the connector, as it will already be there.
v9:
- As a side effect, drm_dp_aux_unregister() must be called before
intel_connector_unregister(), as both the aux.dev and the i2c adapter
dev are children of the drm_connector device now. Calling
drm_dp_aux_unregister() before prevents them from being destroyed
twice.
v10:
- move aux_fini() to connector_unregister(), instead of moving
drm_dp_aux_unregister() outside of connector_register().
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-4-git-send-email-rafael.antognolli@intel.com
Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON
if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister()
is called after drm_connector_unregister(). radeon is the only driver
affected by this besides i915. (amdgpu calls drm_dp_aux_unregister()
before drm_connector_unregister().)
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Split the sw and hw parts into separate functions.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Read back harvest configuration from registers and simplify
calculations. No need to program the raster config registers.
These are programmed as golden registers and the user mode
drivers program them as well.
v2: rebase on Tom's patches
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Don't use pointer arithmetic and fix the indentation.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to remove the kernel context and use a better
priority for the submissions.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to remove the kernel context and use a better
priority for the submissions.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to remove the global kernel context.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Distribute the load on both rings.
v2: use a loop for the initialization
v3: agd: rebase on upstream
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Updates from different VMs can be processed independently.
v2: agd: rebase on upstream
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Avoid a lock inversion problem by just using the mmap_sem to
protect the entries of the intervall tree.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reduce for loop with bitmask to simple complement and mask
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Replaces switch statements with direct assignments to
reduce line count significantly.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
v3: Addressed below comments
1. Tracking time from where last powercycle is initiated.
2. Used ktime_get_bootime() wrapper for boottime clock.
3. Used ktime_ms_delta() to get time difference.
v4: Updated v3 change log in detail.
v5: Removed static from panel_power_on_time(Stéphane).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453513144-14135-1-git-send-email-abhay.kumar@intel.com
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.
Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.
v2:
- lseek is used to select the register to read/write
- read/write are used instead of ioctl
- no blocking_notifier is used, just a direct callback
v3:
- use drm_dp_aux_dev prefix for public functions
- chardev is named drm_dp_auxN
- read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
time
- remove notifier list from the implementation
- option on menuconfig is now a boolean
- add inline stub functions to avoid breakage when this option is disabled
v4:
- fix build system changes - actually disable this module when not selected.
v5:
- Use kref to avoid device closing while still in use
- Don't use list, use an idr for storing aux_dev
- Remove "connector" attribute
- set aux.dev to the connector drm_connector device, instead of
drm_device
v6:
- Use atomic_t for usage count
- Use a mutex instead of spinlock for idr lock
- Destroy chardev immediately on unregister
- other minor suggestions from Ville
v7:
- style fixes
- error handling fixes
v8:
- more error handling fixes
v9:
- remove module_init and module_exit, and add drm_dp_aux_dev_init/exit
to drm_kms_helper_init/exit.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-3-git-send-email-rafael.antognolli@intel.com
The module_init and module_exit functions will start here, and call the
subsequent init's and exit's.
v10:
- Keep __init on drm_fb_helper init function.
- Move MODULE_* macros to the common file.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-2-git-send-email-rafael.antognolli@intel.com
After the drm_device_is_unplugged() was removed, the 'dev' variable is now
unused, and we get a warning for that:
drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap':
drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable]
This removes the variable as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e9f8250f2f ("drm/msm: remove the drm_device_is_unplugged check")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455181810-3910161-1-git-send-email-arnd@arndb.de
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-7-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-6-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-5-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort MST.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-4-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
V2:
- removed computation for max dot clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
- check for stereo mode added
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-3-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort.
V2:
- removed computation for max DOT clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk renamed as max_dotclk
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-2-git-send-email-mika.kahola@intel.com
While running some tests on the scheduler patches with rpm enabled I
came across a corruption in the ringbuffer, which was root-caused to
the GPU being suspended while commands were being emitted to the
ringbuffer. The access to memory was failing because the GPU needs to
be awake when accessing stolen memory (where my ringbuffer was located).
Since we have this constraint it looks like a sensible idea to check
that we hold a refcount when we access the rungbuffer.
v2: move the check from ring_begin to ringbuffer iomap time (Chris)
v3: update comment (Chris)
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453909429-11024-1-git-send-email-daniele.ceraolospurio@intel.com
For dumb buffers, we need to transfer them to the host when updating a
plane.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes drawing updates when updating planes with atomic API.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When using the atomic API, plane->fb is not set when calling
virtio_gpu_plane_atomic_update. Use plane->state->fb instead.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull upstream HDLCD driver.
* git://linux-arm.org/linux-ld:
MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.
drm: Add support for ARM's HDLCD controller.
In case CONFIG_DRM_AMD_POWERPLAY is defined and amdgpu.powerplay=0.
some functions in powrplay can also be called by DAL. and the input parameter is *adev.
if just check point not NULL was not enough and will lead to NULL point error.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Eric Yang <eric.yang2@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use min required system clock calculated by dal
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Rokhvarg <David.Rokhvarg@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amd_pp_dal_clock_info to amd_pp_simple_clock_info.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Prior actual MMIO flip we need to acquire DAL mutex to guard
our target state which get modified on reset mode.
Assign page flip status before actual flip to handle
the possible race condition with interrupt.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need this in userspace for interpreting some of the perf ctrs.
Note possibly not quite sufficient if we had some frequency mgmt
approach other than race-to-idle. Not really sure what the best
thing to do if we did. Although displaying results as a percentage
of max frequence seems sensible(ish) if we did.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No need to keep that for every IB.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need the IB test for GPU resets as well and
the scheduler should be stoped then.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need the IB test for GPU resets as well and
the scheduler should be stoped then.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That's probably a better matching name.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add a job_alloc_with_ib helper and proper job submission.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is no point in sending them through the scheduler.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We can't submit to multiple rings at the same time anyway.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The padding depends on the firmware version and we need that for BO moves as
well, not only for VM updates.
v2: new approach of making pad_ib a ring function
v3: fix typo in macro name
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Don't keep that around twice.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
And use them in the CS instead of allocating IBs and jobs separately.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Specifying no IBs on command submission is invalid, stop crashing
badly when somebody tries it.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Just a leftover from semaphores.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Just leftovers from the semaphores.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Instead of when we try to bind it check the usermm when
we try to use it in the IOCTLs.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
When the radeon driver resets a gpu, it attempts to test whether all the
rings can successfully handle an IB. If these rings fail to respond, the
process will wait forever. Another gpu reset can't happen at this point,
as the current reset holds a lock required to do so. Instead, make all
the IB tests run with a timeout, so the system can attempt to recover
in this case.
While this doesn't fix the underlying issue with card resets failing, it
gives the system a higher chance of recovering. These timeouts have been
confirmed to help both a Tathi and Hawaii card recover after a gpu reset.
This also adds a new function, radeon_fence_wait_timeout, that behaves like
fence_wait_timeout. It is used instead of fence_wait_timeout as it continues
to work during a reset. radeon_fence_wait is changed to be implemented
using this function.
V2:
- Changed the timeout to 1s, as the default 10s from radeon_wait_timeout was
too long. A timeout of 100ms was tested and found to be too short.
- Changed radeon_fence_wait_timeout to behave more like fence_wait_timeout.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Matthew Dawson <matthew@mjdsystems.ca>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move that out of the main IOCTL function.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
