The API has been updated, but the header was not.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_irq.c:115: warning: Function parameter or member 'crtc' not described in 'omap_irq_enable_vblank'
drivers/gpu/drm/omapdrm/omap_irq.c:115: warning: Excess function parameter 'dev' description in 'omap_irq_enable_vblank'
drivers/gpu/drm/omapdrm/omap_irq.c:115: warning: Excess function parameter 'pipe' description in 'omap_irq_enable_vblank'
drivers/gpu/drm/omapdrm/omap_irq.c:142: warning: Function parameter or member 'crtc' not described in 'omap_irq_disable_vblank'
drivers/gpu/drm/omapdrm/omap_irq.c:142: warning: Excess function parameter 'dev' description in 'omap_irq_disable_vblank'
drivers/gpu/drm/omapdrm/omap_irq.c:142: warning: Excess function parameter 'pipe' description in 'omap_irq_disable_vblank'
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105144517.1826692-5-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or member 'dmm' not described in 'dmm_txn_init'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or member 'tcm' not described in 'dmm_txn_init'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:353: warning: Function parameter or member 'txn' not described in 'dmm_txn_append'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:353: warning: Function parameter or member 'area' not described in 'dmm_txn_append'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:353: warning: Function parameter or member 'pages' not described in 'dmm_txn_append'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:353: warning: Function parameter or member 'npages' not described in 'dmm_txn_append'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:353: warning: Function parameter or member 'roll' not described in 'dmm_txn_append'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:399: warning: Function parameter or member 'txn' not described in 'dmm_txn_commit'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:399: warning: Function parameter or member 'wait' not described in 'dmm_txn_commit'
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rob Clark <rob@ti.com>
Cc: Andy Gross <andy.gross@ti.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106214949.2042120-10-lee.jones@linaro.org
On arm32:
drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_read_screen_base’:
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
...
drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro ‘min’
2041 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_write_screen_base’:
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
...
drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro ‘min’
2115 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
Indeed, on 32-bit size_t is "unsigned int", not "unsigned long".
Fixes: 222ec45f4c ("drm/fb_helper: Support framebuffers in I/O memory")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110090119.2667326-1-geert+renesas@glider.be
As GEM object functions are now mandatory, DRM drivers based on CMA
helpers either set them in their implementation of gem_create_object,
or use the default via drm_gem_cma_create_object_default_funcs().
Simplify this by setting the default CMA object functions for all
objects that don't have any functions of their own. Follows the pattern
of similar code in SHMEM and VRAM helpers. The function
drm_gem_cma_create_object_default_funcs() is redundant and therefore
being removed.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106131632.6796-1-tzimmermann@suse.de
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
internally by DRM's fbdev helper.
For drivers that employ a shadow buffer, fbdev's blit function retrieves
the framebuffer address as struct dma_buf_map, and uses dma_buf_map
interfaces to access the buffer.
The bochs driver on sparc64 uses a workaround to flag the framebuffer as
I/O memory and avoid a HW exception. With the introduction of struct
dma_buf_map, this is not required any longer. The patch removes the rsp
code from both, bochs and fbdev.
v7:
* use min_t(size_t,) (kernel test robot)
* return the number of bytes read/written, if any (fbdev testcase)
v5:
* implement fb_read/fb_write internally (Daniel, Sam)
v4:
* move dma_buf_map changes into separate patch (Daniel)
* TODO list: comment on fbdev updates (Daniel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-11-tzimmermann@suse.de
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modified with
dma_buf_map interfaces.
v6:
* don't call page_to_phys() on framebuffers in I/O memory;
warn instead (Daniel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-9-tzimmermann@suse.de
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
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: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-6-tzimmermann@suse.de
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: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1604822519-65607-1-git-send-email-alex.shi@linux.alibaba.com
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: Sam Ravnborg <sam@ravnborg.org>
[Fix checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-2-mr.nuke.me@gmail.com
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: Douglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102181144.3469197-5-swboyd@chromium.org
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 <lee.jones@linaro.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106214949.2042120-5-lee.jones@linaro.org
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: 3f649ab728 ("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
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 6ce711f275 ("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
