A "return 0" found its way in the middle of the error path of
nouveau_platform_probe(), remove it as it will make the kernel crash if
we try to unload the module afterwards.
While we are at it, also remove the IOMMU domain if it has been created,
as we should.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvkm_mm_fini() was not called when exiting the driver, resulting in a
memory leak. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK
can trigger a PRI fault and return an error code instead of a TPC mask,
unless PGOB has been disabled first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Before we moved gk110's implementation of this to pmu, the functions were
identical. This commit just switches GK208 to use the new (more complete)
implementation of the power-up sequence.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If a memory allocation fails when using the DMA allocator,
gk20a_instobj_dtor_dma() will be called on the failed instmem object.
At this time, node->handle might not be NULL despite the call to
dma_alloc_attrs() having failed. node->cpuaddr is the right member to
check for such a failure, so use it instead.
Reported-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
User-space use mappable BOs notably for fences, and expects that a
value update by the GPU will be immediatly visible through the
user-space mapping.
ARM has a property that may prevent this from happening though: memory
can be mapped multiple times only if the different mappings share the
same caching properties. However all the lowmem memory is already
identity-mapped into the kernel with cache enabled, so when user-space
requests an uncached mapping, we actually get an "undefined caching
policy" one and this has strange side-effects described on Freedesktop
bug 86690.
To prevent this from happening, allow user-space to explicitly specify
which objects should be coherent, and create such objects with the
TTM_PL_FLAG_UNCACHED flag. This will make TTM allocate memory using the
DMA API, which will fix the identify mapping and allow us to safely map
the objects to user-space uncached.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Let GK20A's instmem take advantage of the IOMMU if it is present. Having
an IOMMU means that instmem is no longer allocated using the DMA API,
but instead obtained through page_alloc and made contiguous to the GPU
by IOMMU mappings.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tegra SoCs have an IOMMU that can be used to present non-contiguous
physical memory as contiguous to the GPU and maximize the use of large
pages in the GPU MMU, leading to performance gains. This patch adds
support for probing such a IOMMU if present and make its properties
available in the nouveau_platform_gpu structure so subsystems can take
advantage of it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
instmem for GK20A is allocated using dma_alloc_coherent(), which
provides us with a coherent CPU mapping that we never use because
instmem objects are accessed through PRAMIN. Switch to
dma_alloc_attrs() which gives us the option to dismiss that CPU mapping
and free up some CPU virtual space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Now that Nouveau can operate even when there is no RAM device, remove
the dummy one used by GK20A.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GK20A does not have dedicated RAM, thus having a RAM device for it does
not make sense. Move the contiguous physical memory allocation to
instmem.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Having a RAM device does not make sense for chips like GK20A which have
no dedicated video memory. The dummy RAM device that we used so far
works as a temporary band-aid, but in the longer term it is desirable
for the driver to be able to work without any kind of VRAM.
This patch adds a few conditionals in places where a RAM device was
assumed to be present and allows some more objects to be allocated from
the TT domain, allowing Nouveau to handle GPUs for which
pfb->ram == NULL.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Notify interrupt is only used for cyclestats. We can just clear it and
avoid an "unknown stat" error that gets printed to dmesg otherwise.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Other methods in this file suggest this is the correct way to retrieve
the engine pointer.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This if statement is correct but it wasn't indented, so it looked like
some code was missing.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Spotted by coccinelle:
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified
Signed-off-by: Martin Peres <martin.peres@free.fr>
Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Another release, another set of regulator updates. Not much of it is
showing up in the code yet but there's been a lot of discussion going on
about how to enhance the regulator API to work better with modern SoCs
which have a microcontroller sitting between Linux and the hardware.
I'm hopeful that'll start to come through into mainline for v4.2 but
it's not quite there for v4.1 - what we do have (along with the usual
small updates is) is:
- Work from Bjorn Andersson on refactoring the configuration of
regulator loading interfaces to be useful for use with
microcontrollers, the existing interfaces were never actually useful
for anything as-is since nobody was willing to put enough data into
public code.
- A summary tree display in debugfs from Heiko Stübner.
- Support for act6000 regulators.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVK+w1AAoJECTWi3JdVIfQeg0H/2ckXZEQWH/yzAz7JgAoSmVr
+y8pvfNLOyOVVulFI0QBOaCAoyJNXNPNqDrkYaTykMIwX4y+weoDqfH/LMiGpnXl
D3aAgdLPSWLTUMteCs9KIHesnOdjKclZUjnbskJgnmeMCW23WcX9T1lBVoLBVdlo
p+oe287rhEwF6j2t63aLwFv8QGpamgVQ/8mXXs8EK7L5E3OO262SwLaXRBAtWk30
Eb68qXrbbkrDunEL6Hjggj5pFi93M4eNfQHpzVmjidvwz1g4JpLtWHW4XpQlXoHJ
G2rlVwNFsyedT1MX2ByKhrIPu5kq5pt0/rjear34G3vuEnQm7vR3aW/38AOxffs=
=t8gT
-----END PGP SIGNATURE-----
Merge tag 'regulator-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Another release, another set of regulator updates. Not much of it is
showing up in the code yet but there's been a lot of discussion going
on about how to enhance the regulator API to work better with modern
SoCs which have a microcontroller sitting between Linux and the
hardware.
I'm hopeful that'll start to come through into mainline for v4.2 but
it's not quite there for v4.1 - what we do have (along with the usual
small updates is) is:
- work from Bjorn Andersson on refactoring the configuration of
regulator loading interfaces to be useful for use with
microcontrollers, the existing interfaces were never actually
useful for anything as-is since nobody was willing to put enough
data into public code.
- a summary tree display in debugfs from Heiko Stübner.
- support for act6000 regulators"
* tag 'regulator-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits)
regulator: max8660: Handle empty regulator data
regulator: output current-limit for all regulators in summary
regulator: add a summary tree in debugfs
regulator: qcom: Tidy up probe()
regulator: qcom: Rework to single platform device
regulator: qcom: Refactor of-parsing code
regulator: qcom: Don't enable DRMS in driver
regulator: max8660: fix assignment of pdata to data that becomes dead
regulator: Defer lookup of supply to regulator_get
mfd: max77693: Remove unused structures
regulator: max77693: Let core parse DT and drop board files support
regulator: Ensure unique regulator debugfs directory names
regulator: stw481x: Remove unused fields from struct stw481x
regulator: palmas: Add has_regen3 check for TPS659038
regulator: constify of_device_id array
regulator: fixes for regulator_set_optimum_mode name change
regulator: Drop temporary regulator_set_optimum_mode wrapper
usb: phy: phy-msm-usb: Rename regulator_set_optimum_mode
usb: phy: ab8500-usb: Rename regulator_set_optimum_mode
ufs: Rename of regulator_set_optimum_mode
...
Similar to the Intel implementation, but instead of just falling back to a
global linear list when we have an overlapping userptr request we accumulate
all overlapping userptrs in a local list.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows selecting CONFIG_MMU_NOTIFIER if it isn't already selected.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some non-const pointers were added since the last constification, fix
them.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Connector states were being allocated in intel_setup_outputs() in loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.
Broken by
commit 944b0c7657
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri Mar 20 16:18:07 2015 +0200
drm/i915: Copy the staged connector config to the legacy atomic state
v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Add media bus formats needed by imx-drm
- Switch to use media bus formats to describe the pixel format
on the internal parallel bus between display interface and
encoders
- Some preparations for TV Output via TVEv2 on i.MX5
- Add drm_panel support to the i.MX LVDS driver, allow to
determine the bus pixel format from the panel descriptor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVGnvrAAoJEFDCiBxwnmDrnXwP/RrkQjc9lluHJXJFN0gSE2vv
+xKhZ4fPAkQECcHUFcSaL3mZiwQr2wym6kMR8j2ivj/EpJjfMsy91M+6yiwrMfyb
Ccp6750LLljvQnUBayjHKMA55p9p+59wihFU26jCLzMB/30fJjqRtvQXwI3I4l2+
ZKOaoeq+EubWfGKe3yVGqZB8p+DS4BvMwnXLrv2IF9ONRE7E24p6beKM1D5PFBPQ
C5ZJ+BusMIyessgd7iNuIKJPkhZWjcgzSqfB3NiHxOB1FMCLpaGC8LcP/XKzqeQn
cKBlAzxGhZucOshS217G6cK5C7ELTSEWP+CbFbIBOHyaiY0pVgW5AfKVUgPQK7+l
50o8xQWQAZvzUIjGMPkhoELEW1mXmGDUksdae9rhr7/e6m/t8xBPvyxgMB70QEsL
q0YL7XJzmLugTeSSABZBG/4GFfiOmaVP8ANUM9Kg6lOAVTS5NiVzlUrEukv4tppo
VMQWBc8ot0woqZUlwlP1OJ2Z8lU2aT3px7BnZVu/VWIrNfJX5H9+Q4w57HqaYeqF
lmuW9R/R/RulQiEVG36g91VYOsfE2bB7QlAums0jxTZu84fhy7BIOhdBzUdC+xO1
yihgSkuNQPXvtIboIuUvQ/qc3G9fDlnlP78OfVdOn6uY+XSWAKiLs914xcQHphT/
ZlVJkXAKk1WzKyVeghL2
=nTVr
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-2015-03-31' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm changes to use media bus formats and LDB drm_panel support
- Add media bus formats needed by imx-drm
- Switch to use media bus formats to describe the pixel format
on the internal parallel bus between display interface and
encoders
- Some preparations for TV Output via TVEv2 on i.MX5
- Add drm_panel support to the i.MX LVDS driver, allow to
determine the bus pixel format from the panel descriptor.
* tag 'imx-drm-next-2015-03-31' of git://git.pengutronix.de/git/pza/linux:
drm/imx: imx-ldb: allow to determine bus format from the connected panel
drm/imx: imx-ldb: reset display clock input when disabling LVDS
drm/imx: imx-ldb: add drm_panel support
drm/imx: consolidate bus format variable names
drm/imx: switch to use media bus formats
Add RGB666_1X24_CPADHI media bus format
Add YUV8_1X24 media bus format
Add BGR888_1X24 and GBR888_1X24 media bus formats
Add LVDS RGB media bus formats
Add RGB444_1X12 and RGB565_1X16 media bus formats
drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2
drm/imx: Add support for interlaced scanout
Convert all drm callers that use of_graph_get_next_endpoint to loop over
of-graph endpoints to the newly introduced for_each_endpoint_of_node
helper macro.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVJPGBAAoJEFDCiBxwnmDrsIIP/05ID1FxnfCCb14sF9cnfM3N
LzZnLiD4mAUVB8H94BPz9M1Zu8aA06VjUt2Ay9DxXJRUhsil8YHoblHXORyABDH/
E9/HAQkTluA39+rRvzv4fNr4oROMICbWpUGsczQf4cAv8fPheoOudXw2ENa26LbK
KMmVwxgqPeDkSCqB/pBb6Nod5rN3m0aOGGAliGK+jb4t5bYx0p7+6VdizmOUR1Ax
lUOXZWlB26Z/iEW5aWqSNAafFCqhZmPYiONk/xlReR83z3ZpvPYbeiKqh9JZ5u9F
YxNLkIRbe73SX9Ss6hnorg17S/ONXE4wDovkUueFxKTCE6l8eUM6gBzo5+0X6Xgz
iAU/aghflS28qmqWEN7uZvEh643A0TvKB2KRVURsS+3INuzn3+RzLRWDfHnUvF4t
EGo9WjjpHTw5PRaE7qvk6VLoSx1ygbPnzSXhPiDqbuaeLoOJuZEVnknOwVNoEzoh
+A3LiJJFmxWql+uM4QSCgjvpC4b9oscCAxS07Rt8BTIGZkkW8lyDDbkb4rdrosaN
MfStFSvDSX/VJOXVcJgJ3Xq1nhusuDnaj8G4PASQGb6IXTbHtauVlLLmjJFgTC94
xEr0EObJIvoNx1JeJw/8IzMWuQSTs3O2waderNyo6cyN6ycDsKtCUPsBv8iYHm+C
3u6YWSyPXsEi8jcqa9SX
=la2O
-----END PGP SIGNATURE-----
Merge tag 'of-graph-drm-2015-04-08' of git://git.pengutronix.de/git/pza/linux into drm-next
drm: Use of-graph helpers to loop over endpoints
Convert all drm callers that use of_graph_get_next_endpoint to loop over
of-graph endpoints to the newly introduced for_each_endpoint_of_node
helper macro.
* tag 'of-graph-drm-2015-04-08' of git://git.pengutronix.de/git/pza/linux:
drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break
drm/rcar-du: use for_each_endpoint_of_node macro
drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id
drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
of: Explicitly include linux/types.h in of_graph.h
dt-bindings: brcm: rationalize Broadcom documentation naming
of/unittest: replace 'selftest' with 'unittest'
Documentation: rename of_selftest.txt to of_unittest.txt
Documentation: update the of_selftest.txt
dt: OF_UNITTEST make dependency broken
MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
of: Add of_graph_get_port_by_id function
of: Add for_each_endpoint_of_node helper macro
of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
Commit adacb228d7 ("drm: Exynos: Respect framebuffer pitch for
FIMD/Mixer") fixed the buffer size calculation by using the FB
pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
struct *_win_data abstraction on planes") added a regression so
fix the buffer size calculation again.
Tested on Chromebook Snow / Peach Pit.
Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on planes")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.
The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.
When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:
exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video
Fixes: 2d2c9a8d0a ("ARM: dts: add display power domain for exynos5250")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
>From the commit "drm/exynos: fix the execution order in FIMD
initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
checking code is removed improperly. This patch fix the regression.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Because the helper function which calls this callback checks whether
it is registered or not. It is not necessary if it does nothing.
So it would be better to remove the function for clarity.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Calculation ratio from exynos_drm plane codes, then each hw drivers can
use it without extra operation. Also this fixes width and height of
source used for actual crtc shown via screen.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It's more reasonable to use src_x and src_y to represent source as
counterpart of destination(crtc). Already we are using src_width and
src_height for width and height of source.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
While the VP (video processor) supports arbitrary scaling
of its input, the mixer just supports a simple 2x (line
doubling) scaling. Expose this functionality and exit
early when an unsupported scaling configuration is
encountered.
This was tested with modetest's DRM plane test (from
the libdrm test suite) on an Odroid-X2 (Exynos4412).
v2: Put if- and return-statement on different lines.
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The messages are redundant since 'check_fb_gem_memory_type'
already prints out exactly the same string when it fails.
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
As for now there is no validation of incoming buffer
enqueue request as far as the gem buffers are being
concerned. This might lead to some undesired cases
when the driver tries to operate on invalid buffers
(wiht no valid gem object handle i.e.).
Add some basic checks to rule out those potential issues.
Signed-off-by: Beata Michalska <b.michalska@samsung.com>
[mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Also all places that were storing zpos positions are now unsigned int.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
v2: check for return of exynos_plane_init()
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.
It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.
v2: remove leftover var alpha
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This saves some typing whenever a iteration over all the connector,
crtc or plane states in the atomic state is written, which happens
quite often.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Latest version of the "CHV DPIO programming notes" no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.
ver2: added same treatment to intel_dp.c based on Ville's testing.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
It's not needed since the worker rechecks that it didn't race. We only
need to cancel synchronously after disabling drrs to make sure the
worker really is gone (e.g. for driver unload). But for normal
operation the stall is just wasted time.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We must acquire the mutex before we can check drrs.dp, otherwise
someone might sneak in with a modeset, clear the pointer after we've
checked it and then the code will Oops.
This issue has been introduced in
commit a93fad0f7f
Author: Vandana Kannan <vandana.kannan@intel.com>
Date: Sat Jan 10 02:25:59 2015 +0530
drm/i915: DRRS calls based on frontbuffer
v2: Don't blow up on uninitialized mutex and work item by checking
whether DRRS is support or not first. Also unconditionally initialize
the mutex/work item to avoid future trouble.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Cc: stable@vger.kernel.org (4.0+ only)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
v2: bump version to make sure userspace backward compatibility
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
three commits, all cc: stable, to address Baytrail
suspend/resume issues.
* tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel:
drm/i915/vlv: remove wait for previous GFX clk disable request
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915/vlv: save/restore the power context base reg
Using the for_each_... macro should make the code a bit shorter and
easier to read. Also, when breaking out of the loop, the endpoint node
reference count needs to be decremented.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Using the for_each_... macro should make the code a bit shorter and
easier to read.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Using the for_each_... macro should make the code bit shorter and
easier to read. This patch also properly decrements the endpoint node
reference count before returning out of the loop.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Using the for_each_... macro should make the code a bit shorter and
easier to read.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Regression in commit 2caa80e72b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Feb 22 11:38:36 2015 +0100
drm: Fix deadlock due to getconnector locking changes
If the drm_connector_find() call returns NULL, we should no longer
call drm_modeset_unlock() to avoid locking imbalance.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix IPU IC downscaler to its hardware limitation of 4:1 and the
IPU DI pixel clock divider integer part to 8-bit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVGnyFAAoJEFDCiBxwnmDrP9IQAI+hF9AwH645S7VS2aWJdepn
It+LSh2lQ0Mn8Q2pQYDuoJAoM2u98H04270lhL5JfSc1uqdiud6J+hzSG/0D8fqu
6ZDMV+yen3edo3B3HXtmAbglv6DGEht5HjEcjKIJ14vV0l+q6AdLPwKVbZkw3hl2
LMeexTDx/rMnWizhiXrAGaYmOTYawXOWM/kj1NbQYCBQfVScsJcmrd11NC6xE5ak
Mvpv4wtwQ5/g/XwDeBZLRF6+WL9dvRdj0gId6JMisCG7mMOXZxHAKArarWqY7FUE
sRtMkvnBmgrZhmkXcBXWN3DgdSC1kSWa6CZqHWDdVDnmcU0cozKsnrAoZdGLfhS9
+ryml/poUA9IEqZTtb/XuzY+gYEyXX5PoLoqdcWXgiEuFgWgdM1CilrmJl+IxyIj
A5/NaA9SUHVqGAF1+5b4nTjFYCl6UuZnLlx+ov3MfK1C4w9c711GUUt24PBv9KFy
eYVOswg+cqWkXfeYiLFAv2BoB8pkhDCLwhySRhCjHYJq9NfTgViwCLCYJ59RTQPs
auz6d9wN19D4rE1eagV4LeTPDZVuoTYcE9RxHGhl32fO1ISq0u0L9xRq5X63CF6k
1LajiyGdD9aJbuAgaywGqmRuGiCasOdgqp6KV68cLRuQ86Dd6R9a8vQ5tw/cWERD
td2rf0B0zduI34/S98oS
=1E75
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2015-03-31' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm limit fixes
Fix IPU IC downscaler to its hardware limitation of 4:1 and the
IPU DI pixel clock divider integer part to 8-bit.
* tag 'imx-drm-fixes-2015-03-31' of git://git.pengutronix.de/git/pza/linux:
gpu: ipu-v3: turns out the IPU can only downsize 4:1
gpu: ipu-v3: limit pixel clock divider to 8-bits
drm/radeon: programm the VCE fw BAR as well
drm/radeon: always dump the ring content if it's available
radeon: Do not directly dereference pointers to BIOS area.
drm/radeon/dpm: fix 120hz handling harder
1) support for "stolen mem" for splash-screen take-over
2) additional hdmi pixel clks
3) various pipe flush related fixes
4) support for snapdragon 410 (8x16)
5) support for DSI and dual-DSI
It includes one small patch to export tile-group functions (which was ack'd
by you), as these are used to explain to userspace dual-dsi configurations
(with left and right tile).
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (24 commits)
drm/msm/mdp5: Enable DSI connector in msm drm driver
drm/msm: Initial add DSI connector support
drm/msm: Add split display interface
drm/msm/mdp5: Move *_modeset_init out of construct_encoder function
drm: export tile-group functions
drm/msm/mdp5: Remove CTL flush dummy bits
drm/msm/mdp5: Update headers (add CTL flush bits)
drm/msm/mdp5: Add hardware configuration for msm8x16
drm/msm/mdp5: Get SMP client list from mdp5_cfg
drm/msm/mdp5: Update headers (remove enum mdp5_client_id)
drm/msm/mdp5: Separate MDP5 domain from MDSS domain
drm/msm/mdp5: Update headers (introduce MDP5 domain)
drm/msm/dsi: Update generated DSI header file
drm/msm/mdp5: Fix PIPE source image size settings
drm/msm/mdp5: Update generated mdp5 header file with DSI support
drm/msm/mdp5: Add pingpong entry to mdp5 config table
drm/msm/mdp5: Make the intf connection in config module
drm/msm/mdp5: Add START signal to kick off certain pipelines
drm/msm/mdp5: Enhance operation mode for pipeline configuration
drm/msm/mdp5: Update generated header files
...
This set of changes adds support for a whole bunch of new panels, mostly
simple ones. There's now also support for panels to provide display
timings rather than fixed modes, which should allow panels to work with
a larger number of display drivers. Eventually drivers should migrate to
this new interface and the fixed modes removed from panels.
There are also a couple of sparse fixes for the PS8622 and PS8625 bridge
drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVHXdzAAoJEN0jrNd/PrOhWKgQAJGdicIa3B8CLohgAfyMI+in
1PxO2vBGgz7T02iFTOzwh5cvh8E7mog9/R5jVCyan22BHdws75FgL6RVMcqbllds
c2ejPHhHlBEzOBtbZeEmvg1twmqKY5ejk1X7rtVHNCNaXVzSlpxYJF2jfK8DmhRF
l7UmjKIpyeDSL+33t+Q0jZynU2mwLfstr/4lwMPPKU6kzz15lIo0gPAnOlagbGD3
L5GOm1+LaDXpxojDtIElzzhzDf1DhmD4nIA3KRGAmKHRxA1u/vZUsW5UNaCvJB0v
eMVFdIk/aFfw4jizlAEute4sMKcXWNBMHmEr7e8Bakr+clie7BcXN9zeZ+B99t7A
+pkRbWNN8Isr4FpGNVz0XdU2BzmJAaQ59ghmZ5ZJtOmZwMWJbJsG7vMw0p2+68w6
bxhrEoT7hQDUicoKhcM6/8jDCqLZdqN0co16NHIL+0/BiUuS9Q1qr3Y7dBFbiU6D
iNKKeniODw8lA+Jv7wxVGbS2f5RvFeLvhgi4MgF78bEj8Mxf2EpB+mJT6WtEcX37
OMcg7xN7C6q2cu4Cpj7txF3gnKwB56lkJsX7xnyajtdHLDcw8Vx4CZprZCyA5gWP
FWpDLkT7l3Fi3jRDoVBw3WRa+rIfSFvLuVf3iLyVuFE5vR0tqJKutYDeaez0cMQM
nQqS1f2MYsKmNJf2DFhx
=0aBn
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.1-rc1
This set of changes adds support for a whole bunch of new panels, mostly
simple ones. There's now also support for panels to provide display
timings rather than fixed modes, which should allow panels to work with
a larger number of display drivers. Eventually drivers should migrate to
this new interface and the fixed modes removed from panels.
There are also a couple of sparse fixes for the PS8622 and PS8625 bridge
drivers.
* tag 'drm/panel/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: Add support for Ampire AM-800480R3TMQW-A1H 800x480 7" panel
of: Add vendor prefix for Ampire Co., Ltd.
drm/panel: Add display timing for HannStar HSD070PWW1
drm/panel: simple: Add display timing support
drm/panel: Add display timing support
drm/panel: Add support for OrtusTech COM43H4M85ULC panel
of: Add vendor prefix for Ortus Technology Co., Ltd.
drm/panel: Add bus format for Giantplus GPG482739QS5 panel
drm/panel: simple: Add support for AUO b101ean01 panel
drm/panel: simple: Add support for Innolux ZJ070NA-01P
drm/panel: simple: Add support for Innolux AT043TN24
drm/panel: simple: Add support for Shelly SCA07010-BFN-LNN
drm/panel: simple: Add support for Samsung LTN140AT29 panel
drm: Remove unused DRM_MODE_OBJECT_BRIDGE
drm/bridge: ptn3460: Fix sparse warnings
drm/bridge: ps8622: Fix sparse warnings
drm/bridge: Add I2C based driver for ps8622/ps8625 bridge
Perhaps the most noteworthy change in this set is the implementation of
a hardware VBLANK counter using host1x syncpoints. The SOR registers can
now be dumped via debugfs, which can be useful while debugging. The IOVA
address space maintained by the driver can also be dumped via debugfs.
Other than than, these changes are mostly cleanup work, such as making
register names more consistent or removing unused code (that was left
over after the atomic mode-setting conversion). There's also a fix for
eDP that makes the driver cope with firmware that already initialized
the display (such as the firmware on the Tegra-based Chromebooks).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVHXUKAAoJEN0jrNd/PrOhjSUQAL9QJZBZmQmit1mroVWmWAx8
1m4/lj0bP3s1uOLzkQUwXJes0/niVie6lGmdZ9WCa3lThPErfvgYqKNpVJOYknMR
iFg3HbEHgqz9T5zGNxp43g2hQrxssGEPAJXg4vE06nyS9YTOe0PZi27z9ynwapNZ
Z+Gl2787mmnQE+PyQUQjT96OJv2ahnTgHtcDNMU0SWh5Dr6tI/vo5l/mHnqFOKnQ
Kt/CCf+eNZ1jWCKqN5WYjxUT8kCMsMPPcnKzwhvrCXf6RqMDhr/rc47PGeak/qKR
0poIA47XlN6lPwul1P2gtyJaMiE7790aPKcgUDdpHJItPxbC9D/A8o8M+TcUqryw
NHdKKEDxoo/yg+2x6ZgFk202UbVevp6cBtP+3nrfUAefPCrrkDX31ej6rWAUs7Zm
POzugFON7q+85kF/yO1IEg1lov3zLIl4tCXNtprXUPFHbaBJJpMYK8joNyg2YZVh
pYrV6AaKEwiVpi2h/kfhk/B32fx/KsufBR7fEPFOcJFQ6Gmi/l6GB+li00+LbrI4
8mDN6ngw7KASj03/RWXKSwGXdHqoMx2vtQPgjlNuGhHSgGzk3hZqapC7X+5WhoAw
bOelbtzFABv8EA+vQN5IXd8SKdMPt4AFVGhk4B9HbZUyQLHln187p1tE1q9jSe/V
D9bxrB3Wlf4Ks6Kl8OqU
=HZO1
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.1-rc1
Perhaps the most noteworthy change in this set is the implementation of
a hardware VBLANK counter using host1x syncpoints. The SOR registers can
now be dumped via debugfs, which can be useful while debugging. The IOVA
address space maintained by the driver can also be dumped via debugfs.
Other than than, these changes are mostly cleanup work, such as making
register names more consistent or removing unused code (that was left
over after the atomic mode-setting conversion). There's also a fix for
eDP that makes the driver cope with firmware that already initialized
the display (such as the firmware on the Tegra-based Chromebooks).
* tag 'drm/tegra/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: sor: Reset during initialization
drm/tegra: gem: Return 64-bit offset for mmap(2)
drm/tegra: hdmi: Name register fields consistently
drm/tegra: hdmi: Resets are synchronous
drm/tegra: dc: Document tegra_dc_state_setup_clock()
drm/tegra: dc: Remove unused callbacks
drm/tegra: dc: Remove unused function
drm/tegra: dc: Use base atomic state helpers
drm/atomic: Add helpers for state-subclassing drivers
drm/tegra: dc: Implement hardware VBLANK counter
gpu: host1x: Export host1x_syncpt_read()
drm/tegra: sor: Dump registers via debugfs
drm/tegra: sor: Registers are 32-bit
drm/tegra: Provide debugfs file for the IOVA space
drm/tegra: dc: Check for valid parent clock
* universal plane support
* refactoring to prepare work atomic modesetting work
* a lot of small fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVHQXYAAoJEPo9qoy8lh71jLUP/jM7MUZNP1uyVLvKX7WbCesT
7hW0ZRWAZUooSlWPiiPucTi23u0O6DmLULj5Vt6UZ6x/qixZAnUUDnjgKTHm6elj
upI0DjWbJyi4qk1+enttL+1SgaY9kwT6yyMaWCWOg1MgiSfN3nTwn4xx+zNn/yzP
RnP4E9XctoSOSanwqE6sp9sP/sfVCY9v3CJUw2c4LxjcVE1YcKiy3okInPs3cLpi
31P/tjSP2jKhQYkHy0EL2bwwYrbWswZl0v9GqmfNGeRLRFEe1J8BvcLk5X+0P3h4
acn1wog11cavnwyUyzSTJ/eswWi+qRcgl+SQmsoZ/4Y9wNCcpdiFokSVbzLaGE9j
fy/rDnjY8Uj9eRbhMNhf3Lzs6aiEcHbmsah1zlH7VLkfEACtEpZAF3az1xVTSiJ1
zMR9l29ZAFe9sq/VDdowNXNYIJxeVXClLetPIr3FKZVYPEOfcaH3mV4xoHTR3Y0C
gNCQXa8S9WuXcnPkcdS1shkLMyFppLpng68Ww1H1DemY635RkZGZN2NUvFiJsD46
xmuOyyDReEO1XoHNtk+fum+Ae144Da5YTMtp7IkRXLNu9ajaD4lXurgGHFH2rn/y
3aM/hkzgO/HUyXBkuNX6VkWnpUsT2D/sDACJRRlQt2CEFB/Tt68f48X/FiCh+Mxq
w1/1XQD8EZIwIgzW18Bg
=81ba
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
omapdrm changes for 4.1
* universal plane support
* refactoring to prepare work atomic modesetting work
* a lot of small fixes
* tag 'omapdrm-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (36 commits)
drm/omap: tiler: add hibernation callback
drm/omap: add hibernation callbacks
drm/omap: keep ref to old_fb
drm/omap: fix race conditon in DMM
drm/omap: fix race condition with dev->obj_list
drm/omap: do not use BUG_ON(!spin_is_locked(x))
drm/omap: only ignore DIGIT SYNC LOST for TV output
drm/omap: fix race with error_irq
drm/omap: use DRM_ERROR_RATELIMITED() for error irqs
drm/omap: stop connector polling during suspend
drm/omap: remove dummy PM functions
drm/omap: tiler: fix race condition with engine->async
drm/omap: fix plane's channel selection
drm/omap: fix TILER on OMAP5
drm/omap: handle incompatible buffer stride and pixel size
drm/omap: fix error handling in omap_framebuffer_create()
drm/omap: fix operation without fbdev
drm/omap: add a comment why locking is missing
drm/omap: add pin refcounting to omap_framebuffer
drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()
...
The tracing infrastructure is adding a macro TRACE_SYSTEM_STRING, and
hit the following build failure:
In file included from include/trace/define_trace.h:90:0,
from drivers/gpu/drm/.//radeon/radeon_trace.h:209,
from drivers/gpu/drm/.//radeon/radeon_trace_points.c:9:
>> include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
#define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name)
Seems that the DRM folks have added their own use to the
TRACE_SYSTEM_STRING, with:
#define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
Although, I can not find its use anywhere. I could simply use another
name, but if this macro is not being used, it should be removed.
Link: http://lkml.kernel.org/r/20150402123736.01eda052@gandalf.local.home
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Looks like it was introduced in:
commit 650ad970a3
Author: Imre Deak <imre.deak@intel.com>
Date: Fri Apr 18 16:35:02 2014 +0300
drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of
but I'm not sure why. It has caused problems for us in the past (see
85250ddff7 "drm/i915/chv: Remove Wait for a previous gfx force-off"
and 8d4eee9cd7 "drm/i915: vlv: increase timeout when forcing on the
GFX clock") and doesn't seem to be required, so let's just drop it.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org # c9c52e24194a: drm/i915/chv: Remove Wait ...
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg. If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have "did it move" sanity check in the PM code to
warn us if something is still amiss.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm/rockchip already has support for disabling all displays on suspend
and enabling them on resume.
Disable automatic VT switching on suspend by the pm console tracking
layer.
Tested on veyron, used `echo mem > sys/power/state`
=> verified no VT switch
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Register connectors with userspace after all components are bound.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
drm_connector_get_name -> connector->name
This patch is necessary to make X11 see screens it seems.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The function disables the dclk at the beginning, so don't simply return
when an error happens, but instead enable the clock again, so that
enable and disable calls are balanced.
ret_clk is introduced to hold the clk_enable result and not mangle the
original error code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Just two small fixes for radeon, both destined for stable.
* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix wait in radeon_mn_invalidate_range_start
drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
Fix display on issue to Exynos5250 based Snow(1366x768) board.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm: Exynos: Respect framebuffer pitch for FIMD/Mixer
one oops fixes and a 0-length allocation fix from next backported.
* tag 'drm-intel-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Reject the colorkey ioctls for primary and cursor planes
drm/i915: Skip allocating shadow batch for 0-length batches
Here's a single drm core fix, cc: stable, that affects i915
users.
* tag 'topic/drm-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
drm/edid: set ELD for firmware and debugfs override EDIDs
This adds support for the AM-800480R3TMQW-A1H 7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The HannStar HSD070PWW1 LVDS panel data sheet lists allowed ranges
additionally to the typical values for pixel clock rate (64.3-82 MHz)
and blanking intervals (54-681 clock cycles horizontally, 3-23 lines
vertically).
This patch replaces this panel's display mode with the display timing
information to describe acceptable timings. Since the HSYNC and VSYNC
are unused, the distribution between front porches, back porches, and
sync pulse lengths was chosen at will.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The simple panel driver's ->get_modes() implementation calculates the
display mode list from the typical timings and the ->get_timings()
implementation returns the timings to the connected encoder for mode
validation and fixup.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
[treding@nvidia.com: select VIDEOMODE_HELPERS]
Signed-off-by: Thierry Reding <treding@nvidia.com>
This adds support for the COM43H4M85ULC 3.7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds the bus_format field to the GPG482739QS5 panel structure.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The AUO b101ean01 panel is a 10.1" 1280x800 panel which can be supported
by the simple panel driver.
Signed-off-by: Huang Lin <hl@rock-chips.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Innolux ZJ070NA-01P is a 7.0" TFT LCD panel with an integrated LED
backlight unit.
This panel is used on the Technexion Toucan.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Innolux AT043TN24 4.3" WQVGA TFT LCD panel.
This panel with backlight is found in PDA 4.3" LCD screen (TM43xx series for
instance).
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Shelly SCA07010-BFN-LNN is a 7.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 7" LCD screen (TM70xx series for
instance).
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This panel is used by the Nyan Blaze board and can be supported by the
simple-panel driver.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
[tomeu.vizoso@collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
As there isn't a way for the firmware on the Nyan Chromebooks to hand
over the display to the kernel, and the kernel isn't redoing the whole
configuration at present.
With this patch, the SOR is brought to a known state and we get correct
display on every boot.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Alexandre Courbot