Ricardo Cañuelo [Wed, 17 Jun 2020 09:46:32 +0000 (11:46 +0200)]
drm/bridge: tfp410: fix de-skew value retrieval from DT
The tfp410 has a data de-skew feature that allows the user to compensate
the skew between IDCK and the pixel data and control signals.
In the driver, the setup and hold times are calculated from the de-skew
value. This retrieves the deskew value from the DT using the proper
datatype and range check as described by the binding (u32 from 0 to 7).
This fix results from a change in the ti,tfp410 DT binding.
This changes how the 'ti,deskew' property is defined. It's now an
unsigned value from 0 to 7 instead of a signed value from -4 to 3.
Until the dtc carries the integer sign through to the yaml output it's
easier to define signed types as unsigned.
Dmitry Osipenko [Wed, 17 Jun 2020 22:27:03 +0000 (01:27 +0300)]
drm/panel-simple: Add missing connector type for some panels
The DRM panel bridge core requires connector type to be set up properly,
otherwise it rejects the panel. The missing connector type problem popped
up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
order to test whether panel's rotation property work properly using
panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses
CLAA070WP03XG display panel.
The NVIDIA Tegra DRM driver recently gained DRM bridges support for the
RGB output and now driver wraps directly-connected panels into DRM bridge.
Hence all panels should have connector type set properly now, otherwise
the panel's wrapping fails.
This patch adds missing connector types for the LVDS panels that are found
on NVIDIA Tegra devices:
Manasi Navare [Fri, 19 Jun 2020 21:23:54 +0000 (02:53 +0530)]
drm/dp: DRM DP helper for reading Ignore MSA from DPCD
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v3:
* Fi the typo in commit message (Manasi)
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619212356.19285-2-bhanuprakash.modem@intel.com
Colin Ian King [Thu, 18 Jun 2020 10:04:00 +0000 (11:04 +0100)]
drm/arm: fix unintentional integer overflow on left shift
Shifting the integer value 1 is evaluated using 32-bit arithmetic
and then used in an expression that expects a long value leads to
a potential integer overflow. Fix this by using the BIT macro to
perform the shift to avoid the overflow.
Addresses-Coverity: ("Unintentional integer overflow") Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200618100400.11464-1-colin.king@canonical.com
Ben Davis [Mon, 1 Jun 2020 16:28:17 +0000 (17:28 +0100)]
drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The
format is similar to P010 with 4:2:0 sub-sampling but has no padding
between components. Instead, luminance and chrominance samples are
grouped into 4s so that each group is packed into an integer number
of bytes:
YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 8.
Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
component, but only 10 bits are used and 6 are padded. 'Q' is chosen
as the first letter to denote 3 plane YUV444, (and is the next letter
along from P which is usually 2 plane).
V2: Updated block_w of NV15 to {4, 2, 0}
V3: Updated commit message to include specific modifier name
Dinghao Liu [Fri, 22 May 2020 13:41:09 +0000 (21:41 +0800)]
drm/panfrost: Fix runtime PM imbalance on error
The caller expects panfrost_job_hw_submit() to increase
runtime PM usage counter. The refcount decrement on the
error branch of WARN_ON() will break the counter balance
and needs to be removed.
Steven Price [Fri, 22 May 2020 15:36:53 +0000 (16:36 +0100)]
drm/panfrost: Fix inbalance of devfreq record_busy/idle()
The calls to panfrost_devfreq_record_busy() and
panfrost_devfreq_record_idle() must be balanced to ensure that the
devfreq utilisation is correctly reported. But there are two cases where
this doesn't work correctly.
In panfrost_job_hw_submit() if pm_runtime_get_sync() fails or the
WARN_ON() fires then no call to panfrost_devfreq_record_busy() is made,
but when the job times out the corresponding _record_idle() call is
still made in panfrost_job_timedout(). Move the call up to ensure that
it always happens.
Secondly panfrost_job_timedout() only makes a single call to
panfrost_devfreq_record_idle() even if it is cleaning up multiple jobs.
Move the call inside the loop to ensure that the number of
_record_idle() calls matches the number of _record_busy() calls.
Douglas Anderson [Fri, 12 Jun 2020 19:30:50 +0000 (12:30 -0700)]
drm/bridge: ti-sn65dsi86: Check the regmap return value when setting a GPIO
The ti_sn_bridge_gpio_set() got the return value of
regmap_update_bits() but didn't check it. The function can't return
an error value, but we should at least print a warning if it didn't
work.
This fixes a compiler warning about setting "ret" but not using it.
Douglas Anderson [Fri, 12 Jun 2020 19:30:47 +0000 (12:30 -0700)]
drm/bridge: ti-sn65dsi86: Don't compile GPIO bits if not CONFIG_OF_GPIO
The kernel test robot noted that if "OF" is defined (which is needed
to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get
compile failures because some of the members that we access in "struct
gpio_chip" are only defined "#if defined(CONFIG_OF_GPIO)".
All the GPIO bits in the driver are all nicely separated out. We'll
guard them with the same "#if defined" that the header has and add a
little stub function if OF_GPIO is not defined.
drm/rockchip: Add per-pixel alpha support for the PX30 VOP
Compared to its predecessors, the PX30 VOP has a different register layout
for enabling per-pixel alpha. Instead of src_alpha_ctl and dst_alpha_ctl,
there is a single alpha control register. This register takes some fields
from src_alpha_ctl, but with a different layout.
Add support for the required fields to the PX30 VOP window descriptions,
which makes per-pixel-alpha formats behave correctly.
I'm not entirely sure of the history here, but I suspect that in one
of the rebases or when applying the patch I moved the hunk from
drm_gem_shmem_prime_import_sg_table(), where it should be, to
drm_gem_shmem_create_with_handle(), which is totally wrong.
Remedy this.
Thanks for Thomas for the crucial hint in debugging this.
Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing") Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616114723.2363268-1-daniel.vetter@ffwll.ch
Emil Velikov [Sun, 17 May 2020 19:36:54 +0000 (20:36 +0100)]
drm/malidp: convert platform driver to use dev_groups
Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files. So take advantage of that
and do not register "by hand" a sysfs file.
Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200517193655.3895087-2-emil.l.velikov@gmail.com
Emil Velikov [Sat, 30 May 2020 12:46:39 +0000 (13:46 +0100)]
drm: vmwgfx: remove drm_driver::master_set() return type
The function always returns zero (success). Ideally we'll remove it all
together - although that's requires a little more work.
For now, we can drop the return type and simplify the drm core code
surrounding it.
v2: remove redundant assignment (Sam)
Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200530124640.4176323-1-emil.l.velikov@gmail.com
Imre Deak [Wed, 10 Jun 2020 13:47:04 +0000 (16:47 +0300)]
drm/dp_mst: Fix flushing the delayed port/mstb destroy work
Atm, a pending delayed destroy work during module removal will be
canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated
workqueue which will be drained of requeued items as well when
destroying it.
v2:
- Check if wq is NULL before calling destroy_workqueue().
Imre Deak [Sun, 7 Jun 2020 21:25:21 +0000 (00:25 +0300)]
drm/dp_mst: Fix the DDC I2C device registration of an MST port
During the initial MST probing an MST port's I2C device will be
registered using the kdev of the DRM device as a parent. Later after MST
Connection Status Notifications this I2C device will be re-registered
with the kdev of the port's connector. This will also move
inconsistently the I2C device's sysfs entry from the DRM device's sysfs
dir to the connector's dir.
Fix the above by keeping the DRM kdev as the parent of the I2C device.
Ideally the connector's kdev would be used as a parent, similarly to
non-MST connectors, however that needs some more refactoring to ensure
the connector's kdev is already available early enough. So keep the
existing (initial) behavior for now.
Imre Deak [Sun, 7 Jun 2020 21:25:20 +0000 (00:25 +0300)]
drm/dp_mst: Fix the DDC I2C device unregistration of an MST port
The WARN below triggers during the removal of an MST port. The problem
is that the parent device's (the connector's kdev) sysfs directory is
removed recursively when the connector is unregistered (even though the
I2C device holds a reference on the parent device). To fix this set
first the Peer Device Type to none which will remove the I2C device.
Note that atm, inconsistently, the parent of the I2C device is initially set to
the DRM kdev and after a Connection Status Notification the parent may be reset
to be the connector's kdev. This problem is addressed by the next patch.
Imre Deak [Thu, 4 Jun 2020 18:45:00 +0000 (21:45 +0300)]
drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than
~540 usec, leading to MST probe failures.
According to the DP Standard 2.0 section 5.1.4:
- DP sinks should generate short pulses in the 500 usec -> 1 msec range
- DP sources should detect short pulses in the 250 usec -> 2 msec range
According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters
should detect and forward short pulses according to how sources should
detect them as specified in the DP Standard (250 usec -> 2 msec).
Based on the above filtering out short pulses with a duration less than
540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 msec if the source doesn't respond, so
use a 50 msec poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP Standard.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
v2:
- Fix the wait event timeout for the no-poll case.
v3 (Ville):
- Fix the short pulse duration limits in the commit log prescribed by the
DP Standard.
- Add code comment explaining why/how polling is used.
- Factor out a helper to schedule the port's hpd irq handler and move it
to the rest of hotplug handlers.
- Document the new MST callback.
- s/update_hpd_irq_state/poll_hpd_irq/
The mgag200 driver now uses managed functions for DRM devices. The
individual helpers for modesetting and memory managed are already
covered, so only device allocation and initialization is left for
conversion.
drm/mgag200: Embed instance of struct drm_device in struct mga_device
Following current best practice, the instance of struct drm_device is now
embedded in struct mga_device. The respective field has been renamed from
'dev' to 'base' to reflect the relationship. Conversion from DRM device is
done via upcast. Using dev_private is no longer possible.
The patch also open-codes drm_dev_alloc() and DRM device initialization
is now performed by a call to drm_device_init().
drm/mgag200: Allocate device structures in mgag200_driver_load()
Instances of struct drm_device and struct mga_device are now allocated
next to each other in mgag200_driver_load(). Yet another preparation
before embedding the DRM device instance in struct mga_device.
drm/mgag200: Separate device initialization into allocation
Embedding the DRM device instance in struct mga_device will require
changes to device allocation. Moving the device initialization into
its own functions gets it out of the way.
drm/mgag200: Move device init and cleanup to mgag200_drv.c
Moving the initializer and cleanup functions for device instances
to mgag200_drv.c prepares for the conversion to managed code. No
functional changes are made. Remove mgag200_main.c, which is now
empty.
drm/mgag200: Merge VRAM setup into MM initialization
The VRAM setup in mgag200_drv.c is part of memory management and
should be done in the same place. Merge the code into the memory
management's init function.
Maxime Ripard [Wed, 27 May 2020 15:47:52 +0000 (17:47 +0200)]
drm/vc4: crtc: Rename SoC data structures
Since we're going to introduce pixelvalve data structures for other SoCs
than the BCM2835, let's rename the structures defined in the code to
make it obvious which SoC we're targeting.
Maxime Ripard [Thu, 6 Feb 2020 13:41:41 +0000 (14:41 +0100)]
drm/vc4: plane: Move additional planes creation to driver
So far the plane creation was done when each CRTC was bound, and those
planes were only tied to the CRTC that was registering them.
This causes two main issues:
- The planes in the vc4 hardware are actually not tied to any CRTC, but
can be used with every combination
- More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs.
However, the next generation of hardware will have 5 CRTCs, putting us
well above the maximum of 32 planes currently allowed by DRM.
This patch is the first one in a series of patches that will take down both
of these issues so that we can support the next generation of hardware
while keeping a good amount of planes.
We start by changing the way the planes are registered to first registering
the primary planes for each CRTC in the CRTC bind function as we used to,
but moving the overlay and cursor creation to the main driver bind
function, after all the CRTCs have been bound, and make the planes
associated to all CRTCs.
This will slightly change the ID order of the planes, since the primary
planes of all CRTCs will be first, and then a pattern of 8 overlays, 1
cursor plane for each CRTC.
This shouldn't cause any trouble since the ordering between the planes is
preserved though.
Maxime Ripard [Wed, 27 May 2020 15:47:47 +0000 (17:47 +0200)]
drm/vc4: plane: Move planes creation to its own function
The planes so far were created as part of the CRTC binding code with
each planes created associated only to one CRTC. However, the hardware
in the vc4 doesn't really have such constraint and can be used with any
CRTC.
In order to rework this, let's first move the overlay and cursor planes
creation to a function of its own.
While the device tree and the driver expected a clock-names property, it
wasn't explicitly documented in the previous binding. The documented order
was wrong too, so make sure clock-names is there and in the proper order.
While the device tree and the driver expected a clock-names and a
clock-cells properties, it wasn't explicitly documented in the previous
binding. Make sure it is now.
Maxime Ripard [Wed, 27 May 2020 15:47:36 +0000 (17:47 +0200)]
dt-bindings: display: Convert VC4 bindings to schemas
The BCM283x SoCs have a display pipeline composed of several controllers
with device tree bindings that are supported by Linux.
Now that we have the DT validation in place, let's split into separate
files and convert the device tree bindings for those controllers to
schemas.
This is just a 1:1 conversion though, and some bindings were incomplete so
it results in example validation warnings that are going to be addressed in
the following patches.
drm/udl: Use GEM vmap/mmap function from SHMEM helpers
The udl driver contains an implementation of GEM vmap and mmap
operations that is identical to the common SHMEM helper; except
that udl's code uses cached pages by default.
Convert udl to regular SHMEM helper functions. There's no reason
to have udl behave differently from all other SHMEM drivers. The
udl driver uses the SHMEM helper to enable caching.
v3:
* rebased onto Daniel's shmem untangle series
v2:
* implement .gem_create_object with SHMEM helper
drm/shmem-helper: Add .gem_create_object helper that sets map_cached flag
The helper drm_gem_shmem_create_object_cached() allocates an GEM SHMEM
object and sets the map_cached flag. Useful for drivers that want cached
mappings.
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
drm/hisilicon/kirin: Set .dumb_create to drm_gem_cma_dumb_create()
The kirin drivers uses drm_gem_cma_dumb_create_internal() for its
.dumb_create implementation. The function is meant for internal use
only by drivers that require additional buffer setup.
Kirin does not do an additional setup, so convert it over to
drm_gem_cma_dumb_create().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Cc: Xu YiPing <xuyiping@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-13-tzimmermann@suse.de
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.
Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.
v3:
* convert to DRIVER_OPS macro in a separate patch
projects / mirror_ubuntu-kernels.git / log