Now that our destroy function is the same as the helper, use that
directly.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
User framebuffers are created with either bo->pages or bo->vaddr set,
depending on whether or not an IOMMU is present. On the other hand, the
framebuffer created for fbdev emulation has a vaddr mapping made if
bo->pages is set after creation. This is set up in fbdev probe.
Remove the special case unmapping from the general-purpose framebuffer
destroy, and move it to fbdev teardown.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Since tegra_fb is now the same as drm_framebuffer, we can just replace
the type completely.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Instead of relying on the tiling attached to a buffer object, make sure
to set the proper tiling for linear buffers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This fixes hangs with legacy applications that use the mmap() syscall on
the fbdev device to map framebuffer memory. The fbdev implementation for
mmap() creates a mapping that conflicts with DRM usage and causes a hang
when the memory is accessed through the mapping.
Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The bulk of these changes are preparation work and addition of support
for Tegra186. Currently only HDMI output (the primary output on Jetson
TX2) is supported, but the hardware is also capable of doing DSI and
DisplayPort.
Tegra DRM now also uses the atomic commit helpers instead of the open-
coded variant that was only doing half its job. As a bit of a byproduct
of the Tegra186 support the driver also gained HDMI 2.0 as well as zpos
property support.
Along the way there are also a few patches to clean up a few things and
fix minor issues.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlpXlPQTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoUFKD/4vXdkmMUkWjZM0xrdwsPi6DvQe3uBa
tE4wchelVnNvLJfBnMVJyEPDiNLoq12pJ6Ol8LRX2f5ExnQUwIEd+RSQPgWSUP6+
bITqSAb9LnEEHMfYLXTHFoBSeqV9nGvpYcouupW5R4cdV4/T7k7x1/6QQg6Byoyx
TULTcpCmMFX4FQGrqWHSrPrkw+MDWYiDmekYcrHmrgOtZUfG7DxdWtQpgs2lrstg
m+FZADSVJ9CwuVgwAO4VTDIeKVHW54b5UPYseH1u/uaAoxVPC50XNJk3RLuSPVWg
8d6BpkUoqmWq8w5tmR+/zx0/WobyRAQYljdd1kWFnnn3slNOvVV6bnOSo9u3OatZ
1DGyaeQr9hXQ2CdSx2oImex2Kslb14yJPczFa6GQBfrfPOPKJk8eh1GIF6bWGtQa
+hzWr1BDDd/q2x6jkIFMQel33Z8dNy1+22GcSYpuofuQeMqD4msccfhnTce1/Mhy
h0+fQK2eFWDbtvSj6rao4CtzVDOCi9+b93Hva/kh7Ap2Wn7eUDLmRh/VtnUj7EP7
LYPNYlFC6rWzfTdHV0oYUizXNRx6ZzQFNYXNmRjjfVMzrXeqkpSsZXcYVhd4J3PB
EmZpiWNeqqGUnoxvSUX0AmC3/VSi7dU+E8ecIzyeVMry2cgXSal7gewPirDUICOI
uiYCJaeWxHJBAA==
=FfXI
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.16-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.16-rc1
The bulk of these changes are preparation work and addition of support
for Tegra186. Currently only HDMI output (the primary output on Jetson
TX2) is supported, but the hardware is also capable of doing DSI and
DisplayPort.
Tegra DRM now also uses the atomic commit helpers instead of the open-
coded variant that was only doing half its job. As a bit of a byproduct
of the Tegra186 support the driver also gained HDMI 2.0 as well as zpos
property support.
Along the way there are also a few patches to clean up a few things and
fix minor issues.
* tag 'drm/tegra/for-4.16-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux: (51 commits)
drm/tegra: dc: Properly cleanup overlay planes
drm/tegra: dc: Fix possible_crtcs mask for planes
drm/tegra: dc: Restore YUV overlay support
drm/tegra: dc: Implement legacy blending
drm/tegra: Correct timeout in tegra_syncpt_wait
drm/tegra: gem: Correct iommu_map_sg() error checking
drm/tegra: dc: Link DC1 to DC0 on Tegra20
drm/tegra: Fix non-debugfs builds
drm/tegra: dpaux: Keep reset defaults for hybrid pad parameters
drm/tegra: Mark Tegra186 display hub PM functions __maybe_unused
drm/tegra: Use IOMMU groups
gpu: host1x: Use IOMMU groups
drm/tegra: Implement zpos property
drm/tegra: dc: Remove redundant spinlock
drm/tegra: dc: Use direct offset to plane registers
drm/tegra: dc: Support more formats
drm/tegra: fb: Force alpha formats
drm/tegra: dpaux: Add Tegra186 support
drm/tegra: dpaux: Implement runtime PM
drm/tegra: sor: Support HDMI 2.0 modes
...
This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.
Reverts commit 71835caa00 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Fixes: 7772fdaef9 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra20 and Tegra30 don't actually support the 24-bit RGB formats that
don't have an alpha component. In order to allow the fbdev emulation to
run on those chips, force the 32-bit RGBA formats.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:
- The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
- The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
- Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
- The vendor prefix NV is somewhat ambiguous.
Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.
Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171205182504.41923-12-noralf@tronnes.org
Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
and drm_*_unreference() helpers.
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() and should not be
used by new code. So convert all users of compatibility functions to
use the new APIs.
Generated by: scripts/coccinelle/api/drm-get-put.cocci
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This contains various fixes to the host1x driver as well as a plug for a
leak of kernel pointers to userspace.
A fairly big addition this time around is the Video Image Composer (VIC)
support that can be used to accelerate some 2D and image compositing
operations.
Furthermore the driver now supports FB modifiers, so we no longer rely
on a custom IOCTL to set those.
Finally this contains a few preparatory patches for Tegra186 support
which unfortunately didn't quite make it this time, but will hopefully
be ready for v4.13.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAljmxI8THHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zocZaD/9AaoXn19oEPYiWx+MjIAkhBiYEw+oq
RrJ1uVisZIx8Y+ftVtwURLh3HS7SXg3F3mjJxfJVxqqlGfTCry0eiru1qbAbkwC2
ebStjdBBnAhMws22Dba5R5aHh21b1px/fj9u+jtiqcKgWzB28D+jH6G4ViTzOgXs
TT1inq5SQfpL3e0+ovmVEh7/URdWf5tPQVWVuvOewTdVA2NYRXpAAFKhGWp4vD28
brvGPzYgEzBF1Q8p3f9kczbtwqChZuwnwVeP/9EP+U+gApIlmFC8XTISAuBYHWfT
baJQJ/V5wjM8m3FmsX4YL8VKplhw2/JMINfD37hzjVlqskN5V80KfNlKTe8yAK96
sP0HDg72zlZ0HHOmOESuxyNyLRYkDpuVNKh4my24u77y/VcpihwMRPc8chnpG76h
jh+7qlZZM8XNnVnFJN5HWLiRTUjZ9y3loJ//Wu97JkOr7SuHQ7qzhPDZV/jZepIG
XkSD1dac7ii2huA6zxSFZzylwBvLHyrdj4s7imNckkNSbVNpm204Bzs0Rr2ju0bv
YBe2+yGkurE8ePfONeaAkpFxHkAkdC0b2SlbZf7MgSaant2s/CV9DGgj03ZipC1g
n2juRlDGLw+B1MOU+dWv/cMZmrO3Xg36E0gYgqskYRunqTdVT+Vx70D0rygo7hDd
G7qvllT6oqKJ1g==
=Eqtp
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.12-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.12-rc1
This contains various fixes to the host1x driver as well as a plug for a
leak of kernel pointers to userspace.
A fairly big addition this time around is the Video Image Composer (VIC)
support that can be used to accelerate some 2D and image compositing
operations.
Furthermore the driver now supports FB modifiers, so we no longer rely
on a custom IOCTL to set those.
Finally this contains a few preparatory patches for Tegra186 support
which unfortunately didn't quite make it this time, but will hopefully
be ready for v4.13.
* tag 'drm/tegra/for-4.12-rc1' of git://anongit.freedesktop.org/tegra/linux:
gpu: host1x: Fix host1x driver shutdown
gpu: host1x: Support module reset
gpu: host1x: Sort includes alphabetically
drm/tegra: Add VIC support
dt-bindings: Add bindings for the Tegra VIC
drm/tegra: Add falcon helper library
drm/tegra: Add Tegra DRM allocation API
drm/tegra: Add tiling FB modifiers
drm/tegra: Don't leak kernel pointer to userspace
drm/tegra: Protect IOMMU operations by mutex
drm/tegra: Enable IOVA API when IOMMU support is enabled
gpu: host1x: Add IOMMU support
gpu: host1x: Fix potential out-of-bounds access
iommu/iova: Fix compile error with CONFIG_IOMMU_IOVA=m
iommu: Add dummy implementations for !IOMMU_IOVA
MAINTAINERS: Add related headers to IOMMU section
iommu/iova: Consolidate code for adding new node to iovad domain rbtree
Add FB modifiers to allow user-space to specify that a surface is in one
of the two tiling formats supported by Tegra chips, and add support in
the tegradrm driver to handle them properly. This is necessary for the
display controller to directly display buffers generated by the GPU.
This feature is intended to replace the dedicated IOCTL enabled
by TEGRA_STAGING and to provide a non-staging alternative to that
solution.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
v3: Actually remove release_fbi (Sean, Emil, Chris) ...
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207161603.17611-1-daniel.vetter@ffwll.ch
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
drm_gem_object_lookup() has never required the drm_device for its file
local translation of the user handle to the GEM object. Let's remove the
unused parameter and save some space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Fixup kerneldoc too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Seems I lied in my last drm-misc pull request and suddenly there's a big
pile of random stuff. Boris dug out Thierry's drm-trivial branch and
resubmitted everything since that branch didn't really work out.
On top of that Nicolas' changes to drm_dev_set_unique - this might
conflict with new driver pulls (I double checked and current drm-next
should be fine), so please beware. The -next/-fixes conflict in vmwgfx
will change slightly with this here too.
* tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (36 commits)
drm: use dev_name as default unique name in drm_dev_alloc()
drm: make drm_dev_set_unique() not use a format string
drm/vmwgfx: Constify function pointer structs
drm/udl: Constify function pointer structs
drm/tegra: Constify function pointer structs
drm/rockchip: Constify function pointer structs
drm/nouveau: Constify function pointer structs
drm/mgag200: Constify function pointer structs
drm/imx: Constify function pointer structs
drm/i2c/sil164: Constify function pointer structs
drm/i2c/adv7511: Constify function pointer structs
drm/exynos: Constify function pointer structs
drm/cirrus: Constify function pointer structs
drm/i2c/ch7006: Constify function pointer structs
drm/bridge/nxp-ptn3460: Constify function pointer structs
drm/bridge/dw_hdmi: Constify function pointer structs
drm/bochs: Constify function pointer structs
drm/atmel-hlcdc: Constify function pointer structs
drm/armada: Constify function pointer structs
drm: Constify drm_encoder_slave_funcs
...
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/tegra/tegra-drm.ko:
-.rodata 13672
+.rodata 13684
-.data 1108
+.data 1096
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-26-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the drm_atomic_helper_suspend() and drm_atomic_helper_resume()
helpers to implement subsystem-level suspend/resume.
v2: suspend framebuffer device to avoid concurrency issues
v3: resume fbdev on failure to suspend (Emil Velikov)
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-4-git-send-email-architt@codeaurora.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was introduced by mistake in commit 0f7d9052fb ("drm/tegra: Use
new drm_fb_helper functions"). Remove it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v2:
- Fix up error handling path in tegra_fbdev_probe
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This structure will be extended using non-framebuffer related callbacks
in subsequent patches, so it should move to a more central location.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When fbdev initialization fails, make sure to unreference the GEM
objects properly. Note that we can't do this in the general error
unwinding path because ownership of the GEM object references is
transferred to the framebuffer upon creation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drop a reference instead of directly calling the framebuffer .destroy()
callback at fbdev free time. This is necessary to make sure the object
isn't destroyed if anyone else still has a reference.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.
This was tested by injecting errors at various points during the
initialization sequence and verifying that error cleanup didn't crash
and no memory leaked (using kmemleak).
Reported-by: Stéphane Marchesin <marcheu@chromium.org>
Reported-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra20 and Tegra30 both required the buffer line stride to be aligned
on 8 byte boundaries. Tegra114 and Tegra124 increased the alignment to
64 bytes. Introduce a parameter to specify the alignment requirements
for each display controller and round up the pitch of newly allocated
framebuffers appropriately.
Originally-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra124 supports a block-linear mode in addition to the regular pitch
linear and tiled modes. Add support for these by moving the internal
representation into a structure rather than a simple flag.
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.
Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.
This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.
At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.
Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we don't have enough memory for ->planes then we leak "fb".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
A lot of the modern userspace is capable of working without the legacy
fbdev support. kmscon can be used as a replacement for the framebuffer
console, and KMS X drivers create their own framebuffers.
Most people don't have a system where all of this works yet, though, so
leave support enabled by default.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The fbdev screen memory pointer is annotated __iomem, so cast the kernel
virtual address to that address space to make the warning go away.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The gr3d engine renders images bottom-up. Allow buffers that are used
for 3D content to be marked as such and implement support in the display
controller to present them properly.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The gr2d and gr3d engines work more efficiently on buffers with a tiled
memory layout. Allow created buffers to be marked as tiled so that the
display controller can scan them out properly.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
