kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.
Issue identified with Coccinelle.
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909190213.156302-1-alex.dewar90@gmail.com
It's not supported to specify more than one of those flags.
So it never made sense to make this a flag in the first place.
Nuke the flags and specify directly which memory type to use.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389826/?series=81551&rev=1
Those are going to be removed, stop using them here.
Instead use the GEM flags from the UAPI.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389825/?series=81551&rev=1
Those are going to be removed, stop using them here.
Instead define separate flags for the helper.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389823/?series=81551&rev=1
Clang warns:
drivers/gpu/drm/vc4/vc4_plane.c:901:27: warning: operator '?:' has lower
precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
fb->format->has_alpha ?
~~~~~~~~~~~~~~~~~~~~~ ^
drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
the '|' expression to silence this warning
fb->format->has_alpha ?
~~~~~~~~~~~~~~~~~~~~~ ^
drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
the '?:' expression to evaluate it first
fb->format->has_alpha ?
~~~~~~~~~~~~~~~~~~~~~~^
1 warning generated.
Add the parentheses as that was clearly intended, otherwise
SCALER5_CTL2_ALPHA_PREMULT won't be added to the list.
Fixes: c54619b0bf ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1150
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910171831.4112580-1-natechancellor@gmail.com
Clang warns 100+ times in the vc4 driver along the lines of:
drivers/gpu/drm/vc4/vc4_hdmi_phy.c:518:13: warning: implicit conversion
from enumeration type 'enum vc4_hdmi_field' to different enumeration
type 'enum vc4_hdmi_regs' [-Wenum-conversion]
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL,
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
The HDMI_READ and HDMI_WRITE macros pass in enumerators of type
vc4_hdmi_field but vc4_hdmi_write and vc4_hdmi_read expect a enumerator
of type vc4_hdmi_regs, causing a warning for every instance of this.
Update the parameter type so there is no more mismatch.
Fixes: 311e305fdb ("drm/vc4: hdmi: Implement a register layout abstraction")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1149
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910170401.3857250-1-natechancellor@gmail.com
This function always return '0' and no callers use the return value. So
make it a void function.
This eliminates the following coccicheck warning:
drivers/gpu/drm/i810/i810_dma.c:860:8-11: Unneeded variable: "ret".
Return "0" on line 885
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910140610.1191578-1-yanaijie@huawei.com
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error path of the probe
code.
v2: Drop the misplaced drm_dev_put from zynqmp_dpsub_drm_init (all
other paths leaked on error, this should have been in
zynqmp_dpsub_probe), now that subsumed by the auto-cleanup of
devm_drm_dev_alloc.
Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Hyun Kwon <hyun.kwon@xilinx.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200907082225.150837-1-daniel.vetter@ffwll.ch
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vkms, we don't bind), and also when unregistering
the device (very much the case for vkms). Therefore we can rely on devres
even though vkms isn't a proper platform device driver.
This also somewhat untangles the load code, since the drm and platform device
setup are no longer interleaved, but two distinct steps.
v2: use devres_open/release_group so we can use devm without real
hacks in the driver core or having to create an entire fake bus for
testing drivers. Might want to extract this into helpers eventually,
maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
v3: Only deref vkms_device after checking it (Melissa)
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Cc: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909091833.440548-1-daniel.vetter@ffwll.ch
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vgem, we don't bind), and also when unregistering
the device (very much the case for vgem). Therefore we can rely on devres
even though vgem isn't a proper platform device driver.
This also somewhat untangles the load code, since the drm and platform device
setup are no longer interleaved, but two distinct steps.
v2: use devres_open/release_group so we can use devm without real
hacks in the driver core or having to create an entire fake bus for
testing drivers. Might want to extract this into helpers eventually,
maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
v3: Fix error code handling (Melissa)
Cc: Melissa Wen <melissa.srw@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Clark <robdclark@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909120745.716178-1-daniel.vetter@ffwll.ch
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c correctly wrapping bind&unbind in
separate devres groups, which it does.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904143941.110665-2-daniel.vetter@ffwll.ch
The GPU 'CONFIG' registers used to work around hardware issues are
cleared on reset so need to be programmed every time the GPU is reset.
However panfrost_device_reset() failed to do this.
To avoid this in future instead move the call to
panfrost_gpu_init_quirks() to panfrost_gpu_power_on() so that the
regsiters are always programmed just before the cores are powered.
Fixes: f3ba91228e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909122957.51667-1-steven.price@arm.com
The variant->registers[] has ->num_registers elements so the >
comparison needs to be changes to >= to prevent an out of bounds
access.
Fixes: 311e305fdb ("drm/vc4: hdmi: Implement a register layout abstraction")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910100748.GA79916@mwanda
When compiling for 32bit platforms, the compilation fails with:
ERROR: modpost: "__aeabi_ldivmod"
[drivers/gpu/drm/imx/dcss/imx-dcss.ko] undefined!
ERROR: modpost: "__aeabi_uldivmod"
[drivers/gpu/drm/imx/dcss/imx-dcss.ko] undefined!
This patch adds a dependency on ARM64 since no 32bit SoCs have DCSS, so far.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reported-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910095250.7663-1-laurentiu.palcu@oss.nxp.com
Kbuild warns when this file is built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpu/drm/panel/panel-samsung-s6e63m0.o
Add the missing license/author/description tags.
Fixes: b7b23e4476 ("drm/panel: s6e63m0: Break out SPI transport")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909134137.32284-1-yuehaibing@huawei.com
This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
* 4K@60fps;
* HDR10;
* one graphics and 2 video pipelines;
* on-the-fly decompression of compressed video and graphics;
The reference manual can be found here:
https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
The current patch adds only basic functionality: one primary plane for
graphics, linear, tiled and super-tiled buffers support (no graphics
decompression yet), no HDR10 and no video planes.
Video planes support and HDR10 will be added in subsequent patches once
per-plane de-gamma/CSC/gamma support is in.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200731081836.3048-3-laurentiu.palcu@oss.nxp.com
Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which would
bring in also IPUv3 core driver...
The current patch would allow adding new IPs in the imx/ directory without needing
to set DRM_IMX.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200731081836.3048-2-laurentiu.palcu@oss.nxp.com
Add drm_device argument to drm_prime_pages_to_sg(), so we can
call dma_max_mapping_size() to figure the segment size limit
and call into __sg_alloc_table_from_pages() with the correct
limit.
This fixes virtio-gpu with sev. Possibly it'll fix other bugs
too given that drm seems to totaly ignore segment size limits
so far ...
v2: place max_segment in drm driver not gem object.
v3: move max_segment next to the other gem fields.
v4: just use dma_max_mapping_size().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20200907112425.15610-2-kraxel@redhat.com
Since the agp bind/unbind/destroy are now getting called from drivers
rather than via the func table, drop the bdev parameter.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907204630.1406528-13-airlied@gmail.com
This pattern is cut-n-pasted across 4 drivers, switch it to
a WARN_ON instead, as BUG_ON is considered a bad idea usually.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907204630.1406528-2-airlied@gmail.com
This is used by TTM to communicate the physical address
which should be used with ioremap(), ioremap_wc(). We don't
need to separate the base and offset in any way here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389457/
This is internal to TTM and should not be used by drivers directly.
Drop the call to qxl_ttm_io_mem_reserve() and use mem->start instead.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389456/
This fixes the following warnings while building in W=1 :
dw-mipi-dsi.c:1002:5: warning: no previous prototype for 'dw_mipi_dsi_debugfs_write' [-Wmissing-prototypes]
dw-mipi-dsi.c:1027:5: warning: no previous prototype for 'dw_mipi_dsi_debugfs_show' [-Wmissing-prototypes]
Fixes: e2435d6920 ("drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Angelo Ribeiro <angelo.ribeiro@synopsys.com>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907102711.23748-1-narmstrong@baylibre.com
This patch implements the necessary functions to add writeback support
for vkms. This feature is useful for testing compositors if you don't
have hardware with writeback support.
Change in V4 (Emil and Melissa):
- Move signal completion above drm_crtc_add_crc_entry()
- Make writeback always available
- Use appropriate namespace
- Drop fb check in vkms_wb_atomic_commit
- Make vkms_set_composer visible for writeback code
- Enable composer operation on prepare_job and disable it on cleanup_job
- Drop extra space at the end of the file
- Rebase
Change in V3 (Daniel):
- If writeback is enabled, compose everything into the writeback buffer
instead of CRC private buffer
- Guarantees that the CRC will match exactly what we have in the
writeback buffer.
Change in V2:
- Rework signal completion (Brian)
- Integrates writeback with active_planes (Daniel)
- Compose cursor (Daniel)
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-4-rodrigosiqueiramelo@gmail.com
This commit decouples pixel manipulation from compute_crc() for avoiding
any pixel change during the CRC calculation. This commits represents a
preparation work for making VKMS able to support the writeback feature.
Change in V5 (Melissa):
- Rebase and drop bitmap for alpha
Change in V4 (Emil):
- Move bitmap_clear operation and comments to get_pixel function
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-3-rodrigosiqueiramelo@gmail.com
In the vkms_composer.c, some of the functions related to CRC and compose
have interdependence between each other. This patch reworks some
functions inside vkms_composer to make crc and composer computation
decoupled.
This patch is preparation work for making vkms able to support new
features.
Tested-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-2-rodrigosiqueiramelo@gmail.com
