Takashi Iwai [Wed, 11 Mar 2020 07:35:40 +0000 (08:35 +0100)]
drm: sysfs: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Takashi Iwai [Wed, 11 Mar 2020 07:34:52 +0000 (08:34 +0100)]
drm/ttm: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/357174/ Signed-off-by: Christian König <christian.koenig@amd.com>
Heiko Stuebner [Tue, 21 Jan 2020 22:48:28 +0000 (23:48 +0100)]
drm/rockchip: rgb: don't count non-existent devices when determining subdrivers
rockchip_drm_endpoint_is_subdriver() may also return error codes.
For example if the target-node is in the disabled state, so no
platform-device is getting created for it.
In that case current code would count that as external rgb device,
which in turn would make probing the rockchip-drm device fail.
So only count the target as rgb device if the function actually
returns 0.
We actually expect this to return a 0 on success, or negative error code
on failure. In order to do that, we check whether or not we managed to
write the whole GUID and then return 0 if so, otherwise return a
negative error code. Also, let's add an error message here so it's a
little more obvious when this fails in the middle of a link address
probe.
This should fix issues with certain MST hubs seemingly stopping for no
reason in the middle of the link address probe process.
Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings") Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Sean Paul <sean@poorly.run> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Lyude Paul [Fri, 6 Mar 2020 23:49:21 +0000 (18:49 -0500)]
drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()
Noticed this while having some problems with hubs sometimes not being
detected on the first plug. Every single dpcd read or write function
returns the number of bytes transferred on success or a negative error
code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on
success.
There's not really any good reason for this difference that I can tell,
and having the two functions give differing behavior means that
drm_dp_dpcd_write() will end up returning 0 on success for MST devices,
but the number of bytes transferred for everything else.
So, fix that and update the kernel doc.
Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 2f221a5efed4 ("drm/dp_mst: Add MST support to DP DPCD R/W functions") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
drm/panel-simple: Fix dotclock for Ortustech COM37H3M
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
There are two variants of the COM37H3M panel.
The older one's COM37H3M05DTC data sheet specifies:
MIN TYP MAX
CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode)
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv -- 650 -- H
HSYNC frequency fHSYNC -- 39.3 -- kHz
HSYNC cycle time th -- 570 -- CLK
The newer one's COM37H3M99DTC data sheet says:
MIN TYP MAX
CLK frequency fCLK 18 19.8 27 MHz
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv 646 650 700 H
HSYNC frequency fHSYNC -- 39.0 50.0 kHz
HSYNC cycle time th 504 508 630 CLK
So we choose a parameter set that lies within the specs
of both variants. We start at .vrefresh = 60,
choose .htotal = 570 and .vtotal = 650 and end up
in a clock of 22.230 MHz.
drm/mm: Remove redundant assignment in drm_mm_reserve_node
In Pete Goodliffe words, "You can improve a system by adding new code. You
can also improve a system by removing code" - In this case, commit
"202b52b7fbf70" added new code to initialize end of the node. So, there
is no need for duplicated initialization, and this patch simply removes it.
Neil Armstrong [Wed, 4 Mar 2020 10:40:52 +0000 (11:40 +0100)]
drm/meson: Add YUV420 output support
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.
This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.
This patch enables the bridge bus format negociation, and handles
the YUV420 case if selected by the negociation.
Neil Armstrong [Wed, 4 Mar 2020 10:40:51 +0000 (11:40 +0100)]
drm/meson: vclk: add support for YUV420 setup
This patch adds clocking support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.
This patch adds the TMDS PHY clock value in all the video clock setup
in order to better support these specific uses cases and switch
to the Common Clock framework for clocks handling in the future.
Neil Armstrong [Wed, 4 Mar 2020 10:40:50 +0000 (11:40 +0100)]
drm/meson: venc: add support for YUV420 setup
This patch adds encoding support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.
Neil Armstrong [Wed, 4 Mar 2020 10:40:48 +0000 (11:40 +0100)]
drm/meson: meson_dw_hdmi: add bridge and switch to drm_bridge_funcs
Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local
bridge, connecting it to the dw-hdmi bridge, then implement the
atomic_get_input_bus_fmts/atomic_get_output_bus_fmts.
Neil Armstrong [Wed, 4 Mar 2020 10:40:46 +0000 (11:40 +0100)]
drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200a
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Neil Armstrong [Wed, 4 Mar 2020 10:40:45 +0000 (11:40 +0100)]
drm/bridge: synopsys: dw-hdmi: add bus format negociation
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.
The interface of the panel is LVDS, not parallel.
The color depth is RGB888, not RGB565.
The panel has additional features, making it not so simple.
The only user (upstream) of this panel is appropriately using panel-lvds.
drm/vboxvideo/vboxvideo.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
Dafna Hirschfeld [Tue, 21 Jan 2020 15:43:14 +0000 (16:43 +0100)]
dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified on ARM and ARM64 with:
make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Changes since v2:
- add a missing ">" sign in maintainers list
- change the licens to GPL-2.0-only
- add "additionalProperties: false"
- change the commit message to conform that it was tested on both ARM and ARM64
Changes since v1:
- fixed worng sign-off
- fixed the path of the $id property to be the path of the yaml file
Daniel Vetter [Tue, 25 Feb 2020 16:58:35 +0000 (17:58 +0100)]
drm/pci: Unexport drm_get_pci_dev
Only user left is the shadow attach for legacy drivers.
v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include
drm_get_pci_dev() (Thomas)
Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch
drm_fb_helper tasks are completed now hence remove them from
todo list.
Changes since v1:
* remove entire drm_fb_helper tasks from todo list. Daniel's
"64914da24ea9 drm/fbdev-helper: don't force restores" already fixes
first one (Daniel)
drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector functions
drm_fb_helper_single_add_all_connectors(),
drm_fb_helper_add_one_connector()
and drm_fb_helper_remove_one_connector() don't keep an array of
connectors anymore and are just dummy. Now we have no callers to these
functions hence remove them.
drm: Remove drm_fb_helper add, add all and remove connector calls
drm_fb_helper_{add,remove}_one_connector() and
drm_fb_helper_single_add_all_connectors() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
This removal is done using below sementic patch and unused variable
compilation warnings are fixed manually.
Lukas Bulwahn [Wed, 4 Mar 2020 12:07:11 +0000 (13:07 +0100)]
MAINTAINERS: adjust to reservation.h renaming
Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
renamed include/linux/reservation.h to include/linux/dma-resv.h, but
missed the reference in the MAINTAINERS entry.
Since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches F: include/linux/reservation.h
Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
Co-developed-by: Sebastian Duda <sebastian.duda@fau.de> Signed-off-by: Sebastian Duda <sebastian.duda@fau.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/356414/ Signed-off-by: Christian König <christian.koenig@amd.com>
Randy Dunlap [Fri, 6 Mar 2020 01:26:10 +0000 (17:26 -0800)]
drm: unbreak the DRM menu, broken by DRM_EXPORT_FOR_TESTS
Unbreak the DRM menu. This Kconfig symbol does not depend on DRM,
so the menu is broken at that point.
Move the symbol to a location in the Kconfig file so that it does
not break the dependency continuity.
Fixes: 6349120ddcbf ("drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY under a separate Kconfig") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/04221997-79ba-f8a2-4f2d-3c3d9f5219bc@infradead.org
Chris Wilson [Fri, 7 Feb 2020 15:17:20 +0000 (15:17 +0000)]
drm/mm: Break long searches in fragmented address spaces
We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully fragmented our search can be trapped for a long, long
time. For non-preemptible kernels, we need to break up long CPU bound
sections by manually checking for cond_resched(); similarly we should
also bail out if we have been told to terminate. (In an ideal world, we
would break for any signal, but we need to trade off having to perform
the search again after ERESTARTSYS, which again may form a trap of
making no forward progress.)
Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207151720.2812125-1-chris@chris-wilson.co.uk
drm/bridge/mhl.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
drm/vc4/vc4_drv.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
drm/gma500/intel_bios.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
drm/vblank: Fix documentation of VBLANK timestamp helper
Per-CRTC VBLANK information used to be addressed by device and pipe
index. A call drm_crtc_vblank_helper_get_vblank_timestamp_internal()
receives a pointer to the CRTC instead. Fix the documentation.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: f1e2b6371c12 ("drm: Add get_scanout_position() to struct drm_crtc_helper_funcs") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200303073135.10605-1-tzimmermann@suse.de
drm/simple-kms: Fix documentation for drm_simple_encoder_init()
Brings the documentation of drm_simple_encoder_init() in sync with the
function's signature. Also add a paragraph clarifying the management of
the encoder's memory.
v2:
* document memory management
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200304145312.26458-1-tzimmermann@suse.de
Heiko Stuebner [Sat, 29 Feb 2020 15:15:06 +0000 (16:15 +0100)]
drm/panel: add panel driver for Elida KD35T133 panels
Panel driver for the KD35T133 display from Elida, used for example
in the rk3326-based Odroid Go Advance handheld.
changes in v3:
- add missing return value assignment (Francesco)
- re-sort header includes (Sam)
changes in v2:
- rename dsi_generic_write_seq macro to dsi_dcs_write_seq to honor
the underlying mipi_dsi_dcs_write (Robin)
James Hughes [Mon, 17 Feb 2020 15:31:45 +0000 (15:31 +0000)]
drm/v3d: Replace wait_for macros to remove use of msleep
The wait_for macro's for Broadcom V3D driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi). This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.
This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.
v2: Split from the vc4 patch so that we can confidently apply to
stable (by anholt)
James Hughes [Mon, 17 Feb 2020 15:31:45 +0000 (15:31 +0000)]
drm/vc4: Replace wait_for macros to remove use of msleep
The wait_for macro's for Broadcom VC4 driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi). This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.
This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.
v2: Split from the v3d patch in case this tickles modesetting bugs (by
anholt)
Ramalingam C [Wed, 12 Feb 2020 10:29:38 +0000 (15:59 +0530)]
drm/hdcp: optimizing the srm handling
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functional testing.
v4:
fix htmldoc [lkp]
video: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
yu kuai [Mon, 20 Jan 2020 06:33:27 +0000 (14:33 +0800)]
video: fbdev: atyfb: remove set but not used variable 'mach64RefFreq'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/mach64_gx.c: In function ‘aty_var_to_pll_8398’:
drivers/video/fbdev/aty/mach64_gx.c:621:36: warning: variable
‘mach64RefFreq’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:19:45 +0000 (20:19 +0800)]
video: fbdev: kyrofb: remove set but not used variable 'ulScaleRight'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/kyro/STG4000OverlayDevice.c: In function
‘SetOverlayViewPort’:
drivers/video/fbdev/kyro/STG4000OverlayDevice.c:334:19: warning:
variable ‘ulScaleRight’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:30 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'bytpp'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1660:32: warning:
variable ‘bytpp’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:29 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable '‘cSync’'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:48: warning: variable
‘cSync’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:28 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'vSyncPol'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:38: warning: variable
‘vSyncPol’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:27 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'hSyncPol'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:6: warning: variable
‘hSyncPol’ set but not used [-Wunused-but-set-variable]
* Add missing __iomem annotations where needed.
* Make w100fb_probe() static.
* Return NULL pointer (instead of using plain integer) in
w100_get_xtal_tabl().
This patch makes the internal encoder implementation of the simple
KMS helpers available to drivers.
These simple-encoder helpers initialize an encoder with an empty
implementation. This covers the requirements of most of the existing
DRM drivers. A call to drm_simple_encoder_create() allocates and
initializes an encoder instance, a call to drm_simple_encoder_init()
initializes a pre-allocated instance.
v3:
* remove drm_simple_encoder_create(); not required yet
* provide more precise documentation
v2:
* move simple encoder to KMS helpers
* remove name argument; simplifies implementation
* don't allocate with devm_ interfaces; unsafe with DRM
Sam Ravnborg [Sun, 16 Feb 2020 18:15:13 +0000 (19:15 +0100)]
drm/panel: simple: add panel-dpi support
The panel-dpi compatible is a fallback that
allows the DT to specify the timing.
When matching panel-dpi expect the device tree to include the
timing information for the display-panel.
Background for this change:
There are a lot of panels and new models hits the market very often.
It is a lost cause trying to chase them all and users of new panels
will often find them in situations that the panel they ues are not
supported by the kernel.
On top of this a lot of panels are customized based on customer
specifications.
Including the panel timing in the device tree allows for a simple
way to describe the actual HW and use this description in a generic
way in the kernel.
This allows uses of proprietary panels, or panels which are not
included in the kernel, to specify the timing in the device tree
together with all the other HW descriptions.
And thus, using the device tree it is then easy to add support
for an otherwise unknown panel.
The current support expect panels that do not require any
delays for prepare/enable/disable/unprepare.
Oleksandr Suvorov replied:
I've just tested this patch on Apalis iMX6Q and Colibri iMX7D using
panel settings from the following patch:
https://lore.kernel.org/linux-arm-kernel/20200115123401.2264293-4-oleksandr.suvorov@toradex.com/
Sam Ravnborg [Sun, 16 Feb 2020 18:15:12 +0000 (19:15 +0100)]
dt-bindings: display: add data-mapping to panel-dpi
Add data-mapping property that can be used to specify
the media format used for the connection betwwen the
display controller (connector) and the panel.
Sam Ravnborg [Sun, 16 Feb 2020 18:15:11 +0000 (19:15 +0100)]
dt-bindings: display: convert panel-dpi to DT schema
With panel-timing converted, now convert the single
remaining .txt user in panel/ of panel-timing to DT schema.
v2:
- Drop Thierry as maintainer, as this is not a general panel binding
and I have no acks.
- Drop requirement for a panel- specific binding - "panel-dpi" is enough
- Updated example
v3:
- added yaml document terminator "..."
- always require a specific binding - panel-dpi (based on feedback from Rob)
- use "power-supply" for the supply property, and made it mandatory
"power-supply" is the standard property for panels
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-4-sam@ravnborg.org
Sam Ravnborg [Sun, 16 Feb 2020 18:15:10 +0000 (19:15 +0100)]
dt-bindings: display: convert display-timings to DT schema
Add display-timings.yaml - that references panel-timings.yaml.
display-timings.yaml will be used for display bindings
when they are converted to meta-schema format.
For now the old display-timing.txt points to the new
display-timings.yaml - and all users are left as-is.
v2:
- Updated native-mode description
v3:
- Simpler "^timing" pattern (Rob)
- timing node is of type object (Rob)
- added display-timings to panel-common.yaml
- added yaml document terminator "..."
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-3-sam@ravnborg.org
Sam Ravnborg [Sun, 16 Feb 2020 18:15:09 +0000 (19:15 +0100)]
dt-bindings: display: add panel-timing.yaml
Add meta-schema variant of panel-timing and
reference it from panel-common.yaml.
Part of this came form other files with other
licenses - original commits:
commit cc3f414cf2e4 ("video: add of helper for display timings/videomode")
commit 86f46565dff3 ("dt-bindings: display: display-timing: Add property to configure sync drive edge")
commit 9cad9c95d7e8 ("Documentation: DocBook DRM framework documentation")
The original authors acked the license change to:
(GPL-2.0-only OR BSD-2-Clause)
v2:
- Got OK from original authors for re-license
Huge thanks for the quick replies!
- Typo fixes (Oleksandr)
- Drop -array variant when not needed (Maxime)
- Replace oneOf:... with enum (Maxime)
- Drop type from clock-frequency (Rob)
- Drop "|" when not needed (Rob)
v3:
- Added comment to acks that are only for the license change
- Add yaml document terminator "..."
- Updated description (removed reference to native-mode)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [license change] Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> [license change] Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> [license change] Acked-by: Philipp Zabel <p.zabel@pengutronix.de> [license change] Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-2-sam@ravnborg.org
Linus Walleij [Sun, 23 Feb 2020 12:18:41 +0000 (13:18 +0100)]
drm/panel: Add driver for Novatek NT35510-based panels
This adds a driver for panels based on the Novatek NT35510
display driver IC, such as the Hydis HVA40WV1 panel found
in the Samsung GT-S7710.
The NT35510 can be used with both internal and external
backlight (such as GPIO backlight) so we support both:
if no external backlight is found, we register a subdriver
for the internal backlight.
Linus Walleij [Sun, 23 Feb 2020 12:18:40 +0000 (13:18 +0100)]
drm/panel: Add DT bindings for Novatek NT35510-based panels
This adds device tree bindings for the Novatek NT35510-based
family of panels. Since several such panels are in existence
we define bindings common for all, and define the compatible
string for one certain panel (Hydis HVA40WV1).
As other panels are discovered and investigated, we can add
more compatibles to the binding using oneOf constructions.
Emmanuel Vadot [Sat, 15 Feb 2020 18:09:10 +0000 (19:09 +0100)]
drm/client: Dual licence the file in GPL-2 and MIT
Contributors for this file are :
Chris Wilson <chris@chris-wilson.co.uk>
Denis Efremov <efremov@linux.com>
Jani Nikula <jani.nikula@intel.com>
Maxime Ripard <mripard@kernel.org>
Noralf Trønnes <noralf@tronnes.org>
Sam Ravnborg <sam@ravnborg.org>
Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Denis Efremov <efremov@linux.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200215180911.18299-2-manu@FreeBSD.org
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scrambled display and a flood of sync lost errors,
when a plane was active in two layers at the same time, or a missing
plane, in case when a layer was accidentally disabled.
The rewrite takes a more straight forward approach when HW is
concerned. The plane positioning registers are in the CRTC (or
actually OVR) register space and it is more natural to configure them
in a one go when configuring the CRTC. To do this we need make sure we
have all the planes on the updated CRTCs in the new atomic state. The
untouched planes on CRTCs that need plane position update are added to
the atomic state in tidss_atomic_check().
Dave Airlie [Fri, 28 Feb 2020 06:21:14 +0000 (16:21 +1000)]
Merge tag 'drm-misc-next-2020-02-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.7
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- bridge: huge rework to get rid of omap_dss custom display drivers
Driver Changes:
- hisilicon: some fixes related to modes it can deal with / default to
- virtio: shmem and gpu context fixes and enhancements
- sun4i: Support for LVDS on the A33
Christian König [Wed, 19 Feb 2020 12:32:43 +0000 (13:32 +0100)]
dma-buf: make move_notify mandatory if importer_ops are provided
This makes the move_notify callback mandatory when the importer_ops are
provided. Since amdgpu is now migrated it doesn't make much sense
anymore to allow this.
Christian König [Tue, 3 Jul 2018 14:42:26 +0000 (16:42 +0200)]
dma-buf: add dynamic DMA-buf handling v15
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change
v15: add EXPERIMENTAL flag, some more code comments
projects / mirror_ubuntu-kernels.git / log