Gerd Hoffmann [Tue, 11 Feb 2020 13:52:18 +0000 (14:52 +0100)]
drm/bochs: add drm_driver.release callback.
Call bochs_unload via drm_driver.release to make sure we release stuff
when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
touching hardware after device removal. Tidy up here and there.
v4: add changelog.
v3: use drm_dev_*().
v2: move hardware deinit to pci_remove().
Jani Nikula [Tue, 11 Feb 2020 14:47:53 +0000 (16:47 +0200)]
drm/irq: remove check on dev->dev_private
There is no real reason to require drivers to set and use
dev->dev_private. Indeed, the current recommendation, as documented in
drm_device.h, is to embed struct drm_device in the per-device struct
instead of using dev_private.
Remove the requirement for dev_private to have been set to indicate
driver initialization.
For background, quoting Daniel Vetter:
Now there might be some hilarious races this papers over, but:
- Proper drivers should only call drm_dev_register once everything is
set up, including this stuff here. No race possible with anything else
really.
- Slightly more wobbly drivers, including the legacy ones, all use
drm_global_mutex. This was the former BKL, which means that it was
impossible for soeone to go through the load/unload/reload (between
lastclose and firstopen) paths and also run the ioctl. But the ioctl
had to be made unlocked because blocking there killed X:
The even more legacy DRM_CONTROL ioctl stayed fully locked. But the
file open/close paths are still fully locked, and that's the only
place legacy drivers should call drm_irq_install/uninstall, so should
all still be fully ordered and protected and happy.
Add compatible to panel-simple for Rocktech Displays Limited
RK101II01D-CT 10.1" TFT 1280x800 Pixels with LVDS interface, LED
Backlight, and capacitive touch panel ("goodix,gt928" compatible).
Daniel Vetter [Tue, 4 Feb 2020 15:01:46 +0000 (16:01 +0100)]
drm: Nerf drm_global_mutex BKL for good drivers
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open/close. The only thing left to audit are the various driver
hooks - by keeping the BKL around if any of them are set we have a
very simple cop-out!
Note that one of the biggest prep pieces to get here was making
dev->open_count atomic, which was done in
drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
v2:
- Rebase and fix locking in drm_open() (Chris)
- Indentation fix in drm_release
- Typo fix in the commit message (Sam)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-6-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 4 Feb 2020 15:01:45 +0000 (16:01 +0100)]
drm: Push drm_global_mutex locking in drm_open
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity. Historical
aside: When the kernel-wide BKL was removed, it was replaced by
drm_global_mutex within the scope of the drm subsystem hence why these
two things are (almost) interchangeable as concepts here.
Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visible effect.
v2: Push the locking even further into drm_open(), suggested by Chris.
This gives us more symmetry with drm_release(), and maybe a futuer
avenue where we make drm_global_mutex locking (partially) opt-in like
with drm_release_noglobal().
v3:
- Actually push this stuff correctly, don't unlock twice (Chris)
- Fix typo on commit message, plus explain why BKL = drm_global_mutex
(Sam)
Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-5-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 4 Feb 2020 15:01:44 +0000 (16:01 +0100)]
drm/client: Rename _force to _locked
Plus extend the kerneldoc a bit to explain how this should be used.
With the previous patch to drop the force restore the main user of
this function is not emphasis on the "I hold the internal master lock
already" aspect, so rename the function to match.
Daniel Vetter [Tue, 4 Feb 2020 15:01:43 +0000 (16:01 +0100)]
drm/fbdev-helper: don't force restores
Instead check for master status, in case we've raced.
This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mode directly, without a vt switch).
This is known to break some subtests of kms_fbcon_fbt in igt, but they're
just wrong - it does a graphics/text mode switch for the vt without
updating the master status.
Also add a comment to the drm_client->restore hook that this is expected
going forward from all clients (there's currently just one).
v2: Also drop the force in pan_display
v3: Restore the _force to pan_display, this actually means _locked in that
path. Spotted by Noralf.
Wen Yang [Mon, 8 Apr 2019 02:58:32 +0000 (10:58 +0800)]
drm/omap: fix possible object reference leak
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Zheng Bin [Thu, 23 Jan 2020 07:05:23 +0000 (15:05 +0800)]
drm/omap: use true,false for bool variable
Fixes coccicheck warning:
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:681:1-15: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:732:1-15: WARNING: Assignment of 0/1 to bool variable
Gerd Hoffmann [Fri, 7 Feb 2020 07:46:38 +0000 (08:46 +0100)]
drm/virtio: move virtio_gpu_mem_entry initialization to new function
Introduce new virtio_gpu_object_shmem_init() helper function which will
create the virtio_gpu_mem_entry array, containing the backing storage
information for the host. For the most path this just moves code from
virtio_gpu_object_attach().
Gerd Hoffmann [Fri, 7 Feb 2020 07:46:37 +0000 (08:46 +0100)]
drm/virtio: move mapping teardown to virtio_gpu_cleanup_object()
Stop sending DETACH_BACKING commands, that will happening anyway when
releasing resources via UNREF. Handle guest-side cleanup in
virtio_gpu_cleanup_object(), called when the host finished processing
the UNREF command.
Gerd Hoffmann [Fri, 7 Feb 2020 07:46:36 +0000 (08:46 +0100)]
drm/virtio: resource teardown tweaks
Add new virtio_gpu_cleanup_object() helper function for object cleanup.
Wire up callback function for resource unref, do cleanup from callback
when we know the host stopped using the resource.
Jyri Sarha [Fri, 29 Nov 2019 15:23:42 +0000 (17:23 +0200)]
drm/bridge: sii902x: Select SND_SOC_HDMI_CODEC if SND_SOC is configured
To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
should be selected automatically by the drivers using it.
Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[narmstrong: atomatically -> automatically] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191129152342.29145-1-jsarha@ti.com
Peter Ujfalusi [Fri, 31 Jan 2020 11:15:53 +0000 (13:15 +0200)]
drm/bridge: Add tc358768 driver
Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
Only write is implemented for mipi_dsi_host_ops.transfer.
Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
the set function, drm_helper_connector_dpms(), wouldn't support it
anyway. So keep the pointer to NULL.
Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
the set function, drm_helper_connector_dpms(), wouldn't support it
anyway. So keep the pointer to NULL.
drm/tiny: add support for tft displays based on ilitek,ili9486
This adds support fot ilitek,ili9486 based displays with shift register
in front of controller.
Ozzmaker,Piscreen and Waveshare,rpi-lcd-35 are such displays.
Sam Ravnborg [Thu, 6 Feb 2020 13:33:42 +0000 (14:33 +0100)]
dt-bindings: one file of all simple DSI panels
To complement panel-simple.yaml, create panel-simple-dsi.yaml.
panel-simple-dsi-yaml are for all simple DSP panels with a single
power-supply and optional backlight / enable GPIO.
Migrate panasonic,vvx10f034n00 over to the new file.
The objectives with one file for all the simple DSI panels are:
- Make it simpler to add bindings for simple DSI panels
- Keep the number of bindings file lower
- Keep the binding documentation for simple DSI panels more consistent
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Herring <robh@kernel.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200206133344.724-2-benjamin.gaignard@st.com
Gerd Hoffmann [Fri, 7 Feb 2020 06:46:53 +0000 (07:46 +0100)]
drm/virtio: fix ring free check
If the virtio device supports indirect ring descriptors we need only one
ring entry for the whole command. Take that into account when checking
whenever the virtqueue has enough free entries for our command.
Chia-I Wu [Wed, 5 Feb 2020 18:19:54 +0000 (10:19 -0800)]
drm/virtio: move virtqueue_notify into virtio_gpu_queue_ctrl_sgs
It becomes clear that virtio_gpu_queue_fenced_ctrl_buffer should be
responsible for setting up sgs and virtio_gpu_queue_ctrl_sgs should
be responsible for queuing sgs.
Chia-I Wu [Wed, 5 Feb 2020 18:19:52 +0000 (10:19 -0800)]
drm/virtio: move the check for vqs_ready earlier
When vqs_ready is false, vq should be considered invalid and we
should not check vq->num_free. After this change, a fenced command
queued before the vqs are ready will have fence id 0 and will be
considered done.
Chia-I Wu [Wed, 5 Feb 2020 18:19:46 +0000 (10:19 -0800)]
drm/virtio: remove incorrect ENOSPC check
The handling of virtqueue_add_sgs ENOSPC error is incorrect because
it can result in out-of-order virtqueue_add_sgs and break fences.
We never get ENOSPC anyway because the caller waits until there is
enough space (the other caller that did not wait was removed in
commit f9c849e4e096 ("drm/virtio: Rewrite virtio_gpu_queue_ctrl_buffer
using fenced version.")). Remove the incorrect and unnecessary error
path.
This also adds a WARN_ON(ret) until we properly handle errors.
The implementation of struct drm_mode_config_funcs.mode_valid verifies
that enough video memory is available for a given display mode. This
replaces similar functionality in bochs_connector_mode_valid().
v2:
* remove bochs_connector_mode_valid(), which now serves no purpose
drm/vram: Add helpers to validate a display mode's memory requirements
Devices with low amount of dedicated video memory may not be able
to use all possible display modes, as the framebuffers may not fit
into VRAM. The new helper function drm_vram_helper_mode_valid()
implements a simple test to sort out all display modes that can
not be used in any case. Drivers should call this function from
struct drm_mode_config_funcs.mode_valid.
The functionality was originally implemented by the ast driver, which
is being converted as well.
v2:
* WARN_ON if VRAM memory manager has not been initialized
* documentation fixes
* unexported drm_vram_helper_mode_valid_internal()
Chris Wilson [Sun, 2 Feb 2020 17:16:32 +0000 (17:16 +0000)]
drm: Remove the dma_alloc_coherent wrapper for internal usage
Internally for "consistent" maps, we create a temporary struct
drm_dma_handle in order to use our own dma_alloc_coherent wrapper then
destroy the temporary wrap. Simplify our logic by removing the temporary
wrapper!
Chris Wilson [Sun, 2 Feb 2020 17:16:31 +0000 (17:16 +0000)]
drm: Remove PageReserved manipulation from drm_pci_alloc
drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
facilities, and we have no special reason within the drm layer to behave
differently. In particular, since
Yannick Fertre [Tue, 21 Jan 2020 10:14:10 +0000 (11:14 +0100)]
drm/stm: ltdc: check crtc state before enabling LIE
Following investigations of a hardware bug, the LIE interrupt
can occur while the display controller is not activated.
LIE interrupt (vblank) don't have to be set if the CRTC is not
enabled.
Boris Brezillon [Tue, 28 Jan 2020 13:55:09 +0000 (14:55 +0100)]
drm/imx: pd: Use bus format/flags provided by the bridge when available
Now that bridges can expose the bus format/flags they expect, we can
use those instead of the relying on the display_info provided by the
connector (which is only valid if the encoder is directly connected
to bridge element driving the panel/display).
We also explicitly expose the bus formats supported by our encoder by
filling encoder->output_bus_caps with proper info.
v10:
* Add changelog to the commit message
* Use kmalloc() instead of kcalloc()
* Add a dev_warn() when unsupported flags are requested
v8 -> v9:
* No changes
v7:
* Add an imx_pd_format_supported() helper (suggested by Philipp)
* Simplify imx_pd_bridge_atomic_get_output_bus_fmts() (suggested by Philipp)
* Simplify imx_pd_bridge_atomic_get_input_bus_fmts()
* Explicitly set the duplicate/destro_state() and reset() hooks
v4 -> v6:
* Patch was not part of the series
v3 (all suggested by Philipp):
* Adjust to match core changes
* Propagate output format to input format
* Pick a default value when output_fmt = _FIXED
* Add missing BGR888 and GBR888 fmts to imx_pd_bus_fmts[]
v2:
* Adjust things to match the new bus-format negotiation infra
Boris Brezillon [Tue, 28 Jan 2020 13:55:08 +0000 (14:55 +0100)]
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Boris Brezillon [Tue, 28 Jan 2020 13:55:07 +0000 (14:55 +0100)]
drm/bridge: Add an ->atomic_check() hook
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls back on ->mode_fixup(), so the behavior should stay
the same for existing bridge drivers).
v10:
* Add changelog to the commit message
v8 -> v9:
* No changes
v7:
* Fix a NULL pointer dereference
v5 -> v6:
* No changes
v4:
* Add R-bs
v3:
* No changes
v2:
* Clarify the fact that ->atomic_check() is replacing ->mode_fixup()
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed by: Jernej Skrabec <jernej.skrabec@siol.net> Tested-by: Jonas Karlman <jonas@kwiboo.se> Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-6-boris.brezillon@collabora.com
v3:
* Old state clarification moved to a separate patch
v2:
* Pass the old bridge state
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: renamed state as old_bridge_state in rcar_lvds_atomic_disable]
Reviewed by: Jernej Skrabec <jernej.skrabec@siol.net> Tested-by: Jonas Karlman <jonas@kwiboo.se> Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-5-boris.brezillon@collabora.com
Boris Brezillon [Tue, 28 Jan 2020 13:55:03 +0000 (14:55 +0100)]
drm/bridge: Add a drm_bridge_state object
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from drm_private_obj so we can
re-use some of the existing state initialization/tracking logic.
v10:
* Add changelog to the commit message
v9:
* Clarify the fact that the bridge->atomic_reset() and
{connector,plane,crtc,...}->reset() semantics are different
* Move the drm_atomic_private_obj_init() call back to
drm_bridge_attach()
* Check the presence of ->atomic_duplicate_state instead of
->atomic_reset in drm_atomic_add_encoder_bridges()
* Fix copy&paste errors in the atomic bridge state helpers doc
* Add A-b/R-b tags
v8:
* Move bridge state helpers out of the CONFIG_DEBUGFS section
v7:
* Move helpers, struct-defs, ... to atomic helper files to avoid the
drm -> drm_kms_helper -> drm circular dep
* Stop providing default implementation for atomic state reset,
duplicate and destroy hooks (has to do with the helper/core split)
* Drop all R-b/T-b as helpers have now be moved to other places
v6:
* Made helpers private, removed doc and moved them to satisfy dependencies
* Renamed helpers to _default_
v5:
* Re-introduced the helpers from v4
v4:
* Fix the doc
* Kill default helpers (inlined)
* Fix drm_atomic_get_bridge_state() to check for an ERR_PTR()
* Add Neil's R-b
v3:
* No changes
v2:
* Use drm_for_each_bridge_in_chain()
* Rename helpers to be more consistent with the rest of the DRM API
* Improve/fix the doc
drm/xen: Explicitly disable automatic sending of vblank event
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. This would apply to xen, but xen has
its own vblank logic. To avoid interfering with the atomic helpers,
disable automatic vblank events explicitly.
v5:
* update comment
v4:
* separate commit from core vblank changes
drm/udl: Don't set struct drm_crtc_state.no_vblank explicitly
As udl does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
drm/ast: Don't set struct drm_crtc_state.no_vblank explicitly
As ast does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
drm: Initialize struct drm_crtc_state.no_vblank from device settings
At the end of a commit, atomic helpers can generate a fake VBLANK event
automatically. Originally implemented for writeback connectors, the
functionality can be used by any driver and/or hardware without proper
VBLANK interrupt.
The patch updates the documentation to make this behaviour official:
settings struct drm_crtc_state.no_vblank to true enables automatic
generation of fake VBLANK events.
The new interface drm_dev_has_vblank() returns true if vblanking has
been initialized for a device, or false otherwise. Atomic helpers use
this function when initializing no_vblank in the CRTC state in
drm_atomic_helper_check_modeset(). If vblanking has been initialized
for a device, no_blank is disabled. Otherwise it's enabled. Hence,
atomic helpers will automatically send out fake VBLANK events with any
driver that did not initialize vblanking.
v5:
* more precise documentation and commit message
v4:
* replace drm_crtc_has_vblank() with drm_dev_has_vblank()
* add drm_dev_has_vblank() in this patch
* move driver changes into separate patches
v3:
* squash all related changes patches into this patch
Daniel Vetter [Mon, 27 Jan 2020 10:02:03 +0000 (11:02 +0100)]
drm/auth: Drop master_create/destroy hooks
vmwgfx stopped using them.
With the drm device model that we've slowly evolved over the past few
years master status essentially controls access to display resources,
and nothing else. Since that's a pure access permission check drivers
should have no need at all to track additional state on a per file
basis.
Aside: For cleanup and restoring kernel-internal clients the grand
plan is to move everyone over to drm_client and
drm_master_internal_acquire/release, like the generic fbdev code
already does. That should get rid of most ->lastclose implementations,
and I think also subsumes any processing vmwgfx does in
master_set/drop.
projects / kernel.git / log