- 09 Nov, 2020 11 commits
-
-
Thomas Zimmermann authored
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Christian König <christian.koenig@amd.com> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), two helpers that convert a GEM object into the TTM BO and forward the call to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object callbacks. v5: * use size_t for storing mapping size (Christian) * ignore premapped memory areas correctly in ttm_bo_vunmap() * rebase onto latest TTM interfaces (Christian) * remove BUG() from ttm_bo_vmap() (Christian) v4: * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel, Christian) Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by:
-
Thomas Zimmermann authored
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove them before changing the interface to use struct drm_buf_map. As a side effect of removing drm_gem_prime_vmap(), the error code changes from ENOMEM to EOPNOTSUPP. Signed-off-by: -
Thomas Zimmermann authored
The function etnaviv_gem_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map. Signed-off-by:
-
Thomas Zimmermann authored
The function drm_gem_cma_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map. Signed-off-by:
-
Thomas Zimmermann authored
The parameters map and is_iomem are always of the same value. Removed them to prepares the function for conversion to struct dma_buf_map. v4: * don't check for !kmap->virtual; will always be false Signed-off-by:
-
Thomas Zimmermann authored
Drop the driver's udev field in favor of struct drm_device.dev. No functional changes made. v3: * upcast dev with udl_to_usb_device() v2: * upcast dev with drm_dev_get_usb_device() Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Thomas Zimmermann authored
Drop the driver's udev field in favor of struct drm_device.dev. No functional changes made. v3: * upcast dev with gm12u320_to_usb_device() v2: * upcast dev with drm_dev_get_usb_device() Signed-off-by:
-
KuoHsiang Chou authored
[Bug] Change the vertical synchroous polary of 1920x1080 @60Hz from Negtive to Positive Signed-off-by:KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Signed-off-by:
-
Alex Shi authored
Couple of variables are actually useless, remove them to save some gcc warning: drivers/video/fbdev/riva/riva_hw.c:250:21: warning: variable ‘mlwm’ set but not used [-Wunused-but-set-variable] drivers/video/fbdev/riva/riva_hw.c:665:15: warning: variable ‘vraw’ set but not used [-Wunused-but-set-variable] drivers/video/fbdev/riva/riva_hw.c:665:9: warning: variable ‘craw’ set but not used [-Wunused-but-set-variable] drivers/video/fbdev/riva/riva_hw.c:659:73: warning: variable ‘align’ set but not used [-Wunused-but-set-variable] drivers/video/fbdev/riva/riva_hw.c:659:50: warning: variable ‘color_key_enable’ set but not used [-Wunused-but-set-variable] Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Stephen Boyd authored
Reading the EDID of this panel shows that these flags should be set. Set them so that we match what is in the EDID. Cc: Douglas Anderson <dianders@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: b0c664cc ("panel: simple: Add BOE NV133FHM-N61") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 08 Nov, 2020 7 commits
-
-
Tom Rix authored
A break is not needed if it is preceded by a return or break Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
-
Biju Das authored
dev_err_probe function simplifies error handling. So use the same in probe function wherever possible. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Biju Das authored
Fix the warning message "missing connector type" by adding connector_type for EDT ETM0700G0DH6 panel. Signed-off-by:
-
Alexandru Gagniuc authored
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct voltage before the reset sequence is initiated. On most boards, this assumption is true at boot-up, so initialization succeeds. However, when we try to initialize the chip with incorrect supply voltages, it will not respond to I2C requests. sii902x_probe() fails with -ENXIO. To resolve this, look for the "iovcc" and "cvcc12" regulators, and make sure they are enabled before starting the reset sequence. If these supplies are not available in devicetree, then they will default to dummy-regulator. In that case everything will work like before. This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode. On this board, the supplies would be set by the second stage bootloader, which does not run in falcon mode. Signed-off-by:
Alexandru Gagniuc <mr.nuke.me@gmail.com> Signed-off-by:
-
Alexandru Gagniuc authored
The sii902x chip family requires IO and core voltages to reach the correct voltage before chip initialization. Add binding for describing the two supplies. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alexandru Gagniuc authored
Separate the hardware initialization code from setting up the data structures and parsing the device tree. The purpose of this change is to provide a single exit point and avoid a waterfall of 'goto's in the subsequent patch. Signed-off-by:
-
Qinglang Miao authored
Add the missing platform_driver_unregister() before return from panel_simple_init in the error handling case when failed to register panel_simple_dsi_driver with CONFIG_DRM_MIPI_DSI enabled. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
- 07 Nov, 2020 7 commits
-
-
Michael Tretter authored
In commit 05193dc3 ("drm/bridge: Make the bridge chain a double-linked list") the bridge has been removed and replaced by a private field. Remove the leftover documentation of the removed field. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Stephen Boyd authored
We should be setting the drm_dp_aux_msg::reply field if a NACK or a SHORT reply happens. Update the error bit handling logic in ti_sn_aux_transfer() to handle these cases and notify upper layers that such errors have happened. This helps the retry logic understand that a timeout has happened, or to shorten the read length if the panel isn't able to handle the longest read possible. Note: I don't have any hardware that exhibits these code paths so this is written based on reading the datasheet for this bridge and inspecting the code and how this is called. Changes in v2: - Move WRITE_STATUS_UPDATE check from case to assignment Changes in v2: - Handle WRITE_STATUS_UPDATE properly Reviewed-by:
-
Stephen Boyd authored
Use the DDC connection to read the EDID from the eDP panel instead of relying on the panel to tell us the modes. Reviewed-by:
-
Stephen Boyd authored
There's no reason we need to wait here to poll a register over i2c. The i2c bus is inherently slow and delays are practically part of the protocol because we have to wait for the device to respond to any request for a register. Let's rely on the sleeping of the i2c controller instead of adding any sort of delay here in the bridge driver. Reviewed-by:
-
Stephen Boyd authored
These register reads and writes are sometimes directly next to each other in the register address space. Let's use regmap bulk read/write APIs to get the data with one transfer instead of multiple i2c transfers. This helps cut down on the number of transfers in the case of something like reading an EDID where we read in blocks of 16 bytes at a time and the last for loop here is sending an i2c transfer for each of those 16 bytes, one at a time. Ouch! Changes in v3: - Undid changes in v2 Changes in v2: - Combined AUX_CMD register write Reviewed-by:
-
Dmitry Baryshkov authored
Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a DSI to HDMI bridge which supports two DSI ports and I2S port as an input and HDMI port as output. Despite name being similar to LT9611, these devices are different enough to warrant separate driver. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output. The LT9611UXC chip is handled by a separate driver, but the bindings used are fully compatible with the LT9611 chip, so let's reuse the lt9611.yaml schema. Signed-off-by:
Vinod Koul <vkoul@kernel.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
- 06 Nov, 2020 13 commits
-
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mga/mga_state.c: In function ‘mga_dma_iload’: drivers/gpu/drm/mga/mga_state.c:945:22: warning: variable ‘buf_priv’ set but not used [-Wunused-but-set-variable] Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: by <jhartmann@precisioninsight.com> Cc: Jeff Hartmann <jhartmann@valinux.com> Cc: Keith Whitwell <keith@tungstengraphics.com> Cc: Gareth Hughes <gareth@valinux.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mga/mga_dma.c:29: warning: Cannot understand * file mga_dma.c drivers/gpu/drm/mga/mga_dma.c:455: warning: Function parameter or member 'dev' not described in 'mga_do_agp_dma_bootstrap' drivers/gpu/drm/mga/mga_dma.c:455: warning: Function parameter or member 'dma_bs' not described in 'mga_do_agp_dma_bootstrap' drivers/gpu/drm/mga/mga_dma.c:629: warning: Function parameter or member 'dev' not described in 'mga_do_pci_dma_bootstrap' drivers/gpu/drm/mga/mga_dma.c:629: warning: Function parameter or member 'dma_bs' not described in 'mga_do_pci_dma_bootstrap' drivers/gpu/drm/mga/mga_dma.c:1150: warning: Function parameter or member 'dev' not described in 'mga_driver_unload' drivers/gpu/drm/mga/mga_dma.c:1159: warning: Function parameter or member 'dev' not described in 'mga_driver_lastclose' Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: by <jhartmann@precisioninsight.com> Cc: Faith <faith@valinux.com> Cc: Jeff Hartmann <jhartmann@valinux.com> Cc: Keith Whitwell <keith@tungstengraphics.com> Cc: Gareth Hughes <gareth@valinux.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/r128/ati_pcigart.c:2: warning: Cannot understand * file ati_pcigart.c Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gareth Hughes <gareth@valinux.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lyude Paul authored
Noticed this when trying to compile with -Wall on a kernel fork. We potentially don't set width here, which causes the compiler to complain about width potentially being uninitialized in drm_cvt_modes(). So, let's fix that. Changes since v1: * Don't emit an error as this code isn't reachable, just mark it as such Changes since v2: * Remove now unused variable Fixes: 3f649ab7 ("treewide: Remove uninitialized_var() usage") Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Link: https://patchwork.freedesktop.org/patch/msgid/20201105235703.1328115-1-lyude@redhat.com
-
Deepak R Varma authored
idr_init() uses base 0 which is an invalid identifier for this driver. The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for ID range and it is #defined to 1. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused / available. References: commit 6ce711f2 ("idr: Make 1-based IDRs more efficient") Signed-off-by:
Deepak R Varma <mh12gx2825@gmail.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201105202135.GA145111@localhost
-
Luben Tuikov authored
Make the definition of struct drm_driver a constant, to follow the latest developments in the DRM layer. Signed-off-by:
Luben Tuikov <luben.tuikov@amd.com> [danvet: Rebase onto devm_drm_dev_alloc patch and drop the freesync ioctl line again that escaped from internal trees.] Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. - arcpgu, because that is stuck behind a pending tiny-fication series from me. - legacy drivers, because legacy requires non-const drm_driver. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) v3: - Improve commit message (Sam) Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201104100425.1922351-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's nice if a big function/ioctl table like this is const. Only downside here is that we need a few more #ifdef to paper over the differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more motivation to sunset that horror show :-) v2: - Fix super important checkpatch warning (Sam) - Update the kerneldoc example too (Sam) Acked-by:
-
Alex Deucher authored
Use the per device drm driver feature flags rather than the global one. This way we can make the drm driver struct const. Signed-off-by:
-
Daniel Vetter authored
This means some very few #ifdef in code, but it allows us to enlist the compiler to make sure this stuff isn't used anymore. More important, only legacy drivers change drm_device (for the legacy_dev_list shadow attach management), therefore this is prep to allow modern drivers to have a const driver struct. Which is nice, because there's a ton of function pointers in there. Acked-by:
-
Daniel Vetter authored
With only the kms driver left, we can fold this in. This means we need to move the ioctl table, which means one additional ioctl must be defined in headers. Also there's a conflict between the radeon_init macro and the module init function, so rename the module functions to avoid that. Reviewed-by:
-
Deepak R Varma authored
idr_init() uses base 0 which is an invalid identifier for this driver. The idr_alloc for this driver uses 1 as start value for ID range. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused / available. References: commit 6ce711f2 ("idr: Make 1-based IDRs more efficient") Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dan Carpenter authored
This is freed both here and in the caller (virtio_gpu_vram_map()) so it's a double free. The correct place is only in the caller. Fixes: 16845c5d ("drm/virtio: implement blob resources: implement vram object") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20201030114808.GD3251003@mwandaSigned-off-by:
-
- 05 Nov, 2020 2 commits
-
-
Lee Jones authored
gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function 'analogix_dp_write_byte_to_dpcd' Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:571:5: warning: no previous prototype for ‘analogix_dp_write_byte_to_dpcd’ [-Wmissing-prototypes] Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jason Yan <yanaijie@huawei.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jingoo Han <jg1.han@samsung.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_SRGB_THROUGH' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_SRGB_ALIGNED' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_SRGB_DUMMY_320X240' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_SRGB_DUMMY_360X240' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_DISABLED_1' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_PRGB_THROUGH' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_PRGB_ALIGNED' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_YUV_640X320_YCBCR' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_YUV_720X360_YCBCR' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_DISABLED_2' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_ITU_R_BT656_720X360_YCBCR' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_ITU_R_BT656_640X320_YCBCR' not described in enum 'ili9322_input' drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value 'ILI9322_INPUT_UNKNOWN' not described in enum 'ili9322_input' Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
