In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/savage/savage_state.c:438:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/savage/savage_state.c:559:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/savage/savage_state.c:697:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129202005.GA25789@embeddedor
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/gpu/drm/via/via_dmablit.c:179:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/via/via_dmablit.c:185:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/via/via_dmablit.c:187:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/via/via_dmablit.c:195:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129201742.GA25660@embeddedor
This is only used by drm_irq_install(), which is an optional helper.
For legacy pci devices this is required (due to interrupt sharing without
msi/msi-x), and just making this the default exactly matches the behaviour
of all existing drivers using the drm_irq_install() helpers. In case that
ever becomes wrong drivers can roll their own irq handling, as many
drivers already do (for other reasons like needing a threaded interrupt
handler, or having an entire pile of different interrupt sources).
v2: Rebase
v3: Improve commit message (Emil)
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129104248.26607-3-daniel.vetter@ffwll.ch
Support Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel, it is a MIPI
dual-DSI panel.
v4-resend:
- Thierry noted missing dt-bindings for v4 but forgot that he
already had applied them one kernel release back in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df
v4:
- address Philipp's comments
- real range for usleep_range and
- poweroff ordering in kingdisplay_panel_prepare
- return value beautification in panel_probe
- update author naming for full name
v3:
- address Thierry's comments
- error handling for init dsi writes in init
- unconditionally remove the panel
- don't use drm_panel_detach
- a bit of variable signednes wiggling
- I did talk to ChromeOS people and the delays really should be as short
as possible, so dropped the 100ms from the delay comments
v2:
- update timing + cmds from chromeos kernel
- new backlight API including switch to devm_of_find_backlight
- fix most of Sean Paul's comments
enable/prepare tracking seems something all panels do
- document origins of the init sequence
- lanes per dsi interface to 4 (two interfaces). Matches how tegra
and pending rockchip dual-dsi handle (dual-)dsi lanes
- spdx header instead of license boilerplate
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030091528.28211-1-heiko@sntech.de
ST7701 designed for small and medium sizes of TFT LCD display, is
capable of supporting up to 480RGBX864 in resolution. It provides
several system interfaces like MIPI/RGB/SPI.
Currently added support for Techstar TS8550B which is ST7701 based
480x854, 2-lane MIPI DSI LCD panel.
Driver now registering mipi_dsi device, but indeed it can extendable
for RGB if any requirement trigger in future.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190124215131.17452-2-jagan@amarulasolutions.com
qdev->monitors_config->max_allowed is effectively set by the
qxl.num_heads module parameter, stored in the qxl_num_crtc variable.
Lets get rid of the indirection and use the variable qxl_num_crtc
directly. The kernel doesn't need to dereference pointers each time it
needs the value, and when reading the code you don't have to trace where
and why qdev->monitors_config->max_allowed is set.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190118122020.27596-16-kraxel@redhat.com
The qxl device supports only a single active framebuffer ("primary
surface" in spice terminology). In multihead configurations are handled
by defining rectangles within the primary surface for each head/crtc.
Userspace which uses the qxl ioctl interface (xorg qxl driver) is aware
of this limitation and will setup framebuffers and crtcs accordingly.
Userspace which uses dumb framebuffers (xorg modesetting driver,
wayland) is not aware of this limitation and tries to use two
framebuffers (one for each crtc) instead.
The qxl kms driver already has the dumb bo separated from the primary
surface, by using a (shared) shadow bo as primary surface. This is
needed to support pageflips without having to re-create the primary
surface. The qxl driver will blit from the dumb bo to the shadow bo
instead.
So we can extend the shadow logic: Maintain a global shadow bo (aka
primary surface), make it big enough that dumb bo's for all crtcs fit in
side-by-side. Adjust the pageflip blits to place the heads next to each
other in the shadow.
With this patch in place multihead qxl works with wayland.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190118122020.27596-15-kraxel@redhat.com
Pass the shadow bo to qxl_io_create_primary() instead of expecting
qxl_io_create_primary to check bo->shadow. Set is_primary flag on the
shadow bo. Move the is_primary tracking into qxl_io_create_primary()
and qxl_io_destroy_primary() functions.
That simplifies primary surface tracking and the workflow in
qxl_primary_atomic_update().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190118122020.27596-14-kraxel@redhat.com
qxl_io_create/destroy_primary: primary_bo tracking [fixup]
The qxl device ties the cursor to the primary surface. Therefore
calling qxl_io_destroy_primary() and qxl_io_create_primary() to switch
the framebuffer causes the cursor information being lost and the driver
must re-apply it.
The correct call order to do that is qxl_io_destroy_primary() +
qxl_io_create_primary() + qxl_primary_apply_cursor().
The old code did qxl_io_destroy_primary() + qxl_primary_apply_cursor() +
qxl_io_create_primary(). Due to qxl_primary_apply_cursor request being
queued in a ringbuffer and qxl_io_create_primary() trapping to the
hypervisor instantly there is a high chance that qxl_io_create_primary()
is processed first even with the wrong call order. But it's racy and
thus not reliable.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190118122020.27596-11-kraxel@redhat.com
Before assigning window data, we should check if the yuv2yuv vop-data
is set at all, because it looks like it can otherwise reference something
wrong, as I saw on my rk3188 today which ended up in a null pointer
dereference in vop_plane_atomic_update when accessing the yuv2yuv data.
Fixes: 1c21aa8f2b ("drm/rockchip: Fix YUV buffers color rendering")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2556882.Heuq80WCVD@phil
