Sam Ravnborg [Wed, 8 Apr 2020 19:50:55 +0000 (21:50 +0200)]
dt-bindings: display: convert samsung,ld9040 to DT Schema
v2:
- drop use of spi-slave.yaml (Maxime)
- added unevaluatedProperties (Maxime)
- added type to width/height properties (Rob)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200408195109.32692-23-sam@ravnborg.org
Sam Ravnborg [Wed, 8 Apr 2020 19:50:46 +0000 (21:50 +0200)]
dt-bindings: display: convert kingdisplay,kd035g6-54nt to DT Schema
v2:
- Drop use of spi-slave.yaml (Maxime)
- Introduce unevaluatedProperties (Maxime)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200408195109.32692-14-sam@ravnborg.org
Sam Ravnborg [Wed, 8 Apr 2020 19:50:44 +0000 (21:50 +0200)]
dt-bindings: display: convert innolux,p120zdg-bf1 to DT Schema
v3:
- Fix stray spaces
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Sandeep Panda <spanda@codeaurora.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200408195109.32692-12-sam@ravnborg.org
Sam Ravnborg [Wed, 8 Apr 2020 19:50:41 +0000 (21:50 +0200)]
dt-bindings: display: convert ilitek,ili9881c to DT Schema
Updating this binding identified an issue in the example in
the allwinner,sun6i-a31-mipi-dsi binding.
Fix the example so no new warnings are introduced.
v2:
- fix example in allwinner,sun6i-a31-mipi-dsi (Rob)
Sam Ravnborg [Wed, 8 Apr 2020 19:50:37 +0000 (21:50 +0200)]
dt-bindings: display: convert samsung,s6e63m0 to DT Schema
The binding for this panel is a SPI slave.
v2:
- Drop use of spi-slave (Maxime)
- Introude unevaluatedProperties (Maxime)
- Drop reg entry in example (Rob)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Jonathan Bakker <xc-racer2@live.ca> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200408195109.32692-5-sam@ravnborg.org
drm: bridge: adv7511: Extend list of audio sample rates
ADV7511 support sample rates up to 192kHz. CTS and N parameters should
be computed accordingly so this commit extend the list up to maximum
supported sample rate.
John Stultz [Thu, 9 Apr 2020 00:43:06 +0000 (00:43 +0000)]
drm: kirin: Revert change to add register connect helper functions
Daniel noted[1] that commit d606dc9a6323 ("drm: kirin: Add
register connect helper functions in drm init") was unnecessary
and incorrect, as drm_dev_register does register connectors for
us.
Thus, this patch reverts the change as suggested by Daniel.
Sam Ravnborg [Wed, 8 Apr 2020 18:29:26 +0000 (20:29 +0200)]
fbdev: mx3fb: const pointer to ipu_di_signal_cfg
Laurent Pinchart <laurent.pinchart@ideasonboard.com> and
Jani Nikula <jani.nikula@intel.com> both
suggested to make the pointer to struct ipu_di_signal_cfg const.
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element in a dma-fence-chain.
Report a NULL fence and success if the seqno has already been signaled.
Chris Wilson [Thu, 9 Apr 2020 11:00:59 +0000 (12:00 +0100)]
dma-buf: Prettify typecasts for dma-fence-chain
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Lyude Paul [Fri, 3 Apr 2020 19:58:29 +0000 (15:58 -0400)]
drm/dp_mst: Print errors on ACT timeouts
Although it's not unexpected for drm_dp_check_act_status() to fail due
to DPCD read failures (as the hub may have just been unplugged
suddenly), timeouts are a bit more worrying as they either mean we need
a longer timeout value, or we aren't setting up payload allocations
properly. So, let's start printing errors on timeouts.
Lyude Paul [Fri, 3 Apr 2020 19:47:15 +0000 (15:47 -0400)]
drm/dp_mst: Increase ACT retry timeout to 3s
Currently we only poll for an ACT up to 30 times, with a busy-wait delay
of 100µs between each attempt - giving us a timeout of 2900µs. While
this might seem sensible, it would appear that in certain scenarios it
can take dramatically longer then that for us to receive an ACT. On one
of the EVGA MST hubs that I have available, I observed said hub
sometimes taking longer then a second before signalling the ACT. These
delays mostly seem to occur when previous sideband messages we've sent
are NAKd by the hub, however it wouldn't be particularly surprising if
it's possible to reproduce times like this simply by introducing branch
devices with large LCTs since payload allocations have to take effect on
every downstream device up to the payload's target.
So, instead of just retrying 30 times we poll for the ACT for up to 3ms,
and additionally use usleep_range() to avoid a very long and rude
busy-wait. Note that the previous retry count of 30 appears to have been
arbitrarily chosen, as I can't find any mention of a recommended timeout
or retry count for ACTs in the DisplayPort 2.0 specification. This also
goes for the range we were previously using for udelay(), although I
suspect that was just copied from the recommended delay for link
training on SST devices.
Changes since v1:
* Use readx_poll_timeout() instead of open-coding timeout loop - Sean
Paul
Changes since v2:
* Increase poll interval to 200us - Sean Paul
* Print status in hex when we timeout waiting for ACT - Sean Paul
Lyude Paul [Fri, 3 Apr 2020 18:08:32 +0000 (14:08 -0400)]
drm/dp_mst: Reformat drm_dp_check_act_status() a bit
Just add a bit more line wrapping, get rid of some extraneous
whitespace, remove an unneeded goto label, and move around some variable
declarations. No functional changes here.
Signed-off-by: Lyude Paul <lyude@redhat.com>
[this isn't a fix, but it's needed for the fix that comes after this] Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <sean@poorly.run> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com
Thomas Zimmermann [Tue, 31 Mar 2020 08:12:38 +0000 (10:12 +0200)]
drm/vram-helpers: Merge code into a single file
Most of the documentation was in an otherwise empty file, which was
probably just left from a previous clean-up effort. So move code and
documentation into a single file.
Thomas Zimmermann [Tue, 31 Mar 2020 09:27:40 +0000 (11:27 +0200)]
drm/vram-helpers: Set plane fence for display update
Calling the VRAM helper's prepare_fb() helper now sets the plane's
fence object. This will be useful for PRIME support. VRAM helpers
don't support buffer sharing ATM, so for now there are no drivers
requiring this change.
v2:
* removed a TODO comment about buffer synchronization
Chris Wilson [Wed, 8 Apr 2020 21:24:07 +0000 (22:24 +0100)]
drm: Don't return 0 from a void drm_fbdev_generic_setup
drm_fbdev_generic_setup() was changed to be a void return, but the stub
was left returning 0.
./include/drm/drm_fb_helper.h: In function ‘drm_fbdev_generic_setup’:
./include/drm/drm_fb_helper.h:450:9: warning: ‘return’ with a value, in function returning void [-Wreturn-type]
./include/drm/drm_fb_helper.h:448:1: note: declared here
448 | drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
Fixes: 1aed9509b29a ("drm/fb-helper: Remove return value from drm_fbdev_generic_setup()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200408212407.4309-1-chris@chris-wilson.co.uk
The arm64 gcc-9 release warns about a change in the calling
conventions:
drivers/video/fbdev/mx3fb.c: In function 'sdc_init_panel':
drivers/video/fbdev/mx3fb.c:506:12: note: parameter passing for argument of type 'struct ipu_di_signal_cfg' changed in GCC 9.1
506 | static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel,
| ^~~~~~~~~~~~~~
drivers/video/fbdev/mx3fb.c: In function '__set_par':
drivers/video/fbdev/mx3fb.c:848:7: note: parameter passing for argument of type 'struct ipu_di_signal_cfg' changed in GCC 9.1
Change the file to just pass the struct by reference, which is
unambiguous and avoids the warning.
Thomas Zimmermann [Wed, 8 Apr 2020 08:26:41 +0000 (10:26 +0200)]
drm/fb-helper: Remove return value from drm_fbdev_generic_setup()
Generic fbdev emulation is a DRM client. Drivers should invoke the
setup function, but not depend on its success. Hence remove the return
value.
v3:
* document stricter requirements for call sequence
v2:
* warn if fbdev device has not been registered yet
* document the new behavior
* convert the existing warning to the new dev_ interface
Thomas Zimmermann [Wed, 8 Apr 2020 08:26:40 +0000 (10:26 +0200)]
drm/vboxvideo: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
Thomas Zimmermann [Wed, 8 Apr 2020 08:26:37 +0000 (10:26 +0200)]
drm/mgag200: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
Thomas Zimmermann [Wed, 8 Apr 2020 08:26:32 +0000 (10:26 +0200)]
drm/ast: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
drm/ttm: clean up ttm_trace_dma_map/ttm_trace_dma_unmap (v2)
ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore.
v2: remove the file completely
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/360432/
Jason Yan [Fri, 3 Apr 2020 02:16:09 +0000 (10:16 +0800)]
video: fbdev: matroxfb: remove dead code and set but not used variable
Fix the following gcc warning:
drivers/video/fbdev/matrox/g450_pll.c:336:15: warning: variable
‘pixel_vco’ set but not used [-Wunused-but-set-variable]
unsigned int pixel_vco;
^~~~~~~~~
In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'assigned-clocks' and
'assigned-clock-rates' for rk3399 and 'power-domains' for most
Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'.
Lyude Paul [Mon, 6 Apr 2020 20:06:42 +0000 (16:06 -0400)]
drm/dp_mst: Remove drm_dp_mst_has_audio()
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there's no use in keeping this function around as all it
does is validate the port pointer before checking the audio status.
Note - drm_dp_mst_port->has_audio is technically protected by
drm_device->mode_config.connection_mutex, since it's only ever updated
from drm_dp_mst_get_edid(). Additionally, we change the declaration for
port in struct intel_connector to be properly typed, so we can directly
access it.
Changes since v1:
* Change type of intel_connector->port in a separate patch - Sean Paul
Lyude Paul [Mon, 6 Apr 2020 20:06:41 +0000 (16:06 -0400)]
drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port
The only reason for having this cast as void * before was because we
originally needed to use drm_dp_mst_get_port_validated() and friends in
order to (attempt to) safely access MST ports. However, we've since
improved how reference counting works with ports and mstbs such that we
can now rely on drm_dp_mst_port structs remaining in memory for as long
as the driver needs. This means we don't really need to cast this as
void* anymore, and can just access the struct directly.
We'll also need this for the next commit, so that we can remove
drm_dp_mst_port_has_audio().
Sam Ravnborg [Mon, 6 Apr 2020 19:47:44 +0000 (21:47 +0200)]
drm/vblank: Add intro to documentation
Lyude Paul wrote a very good intro to vblank here:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.camel@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Add this to the intro chapter in drm_vblank.c so others
can benefit from it too.
v2:
- Reworded to improve readability (Thomas)
v3:
- Added nice ascii drawing from Lyude (Lyude)
- Added referende to high-precision timestamp (Daniel)
- Improved grammar (Thomas)
- Combined it all and made kernel-doc happy
- Dropped any a-b, r-b do to the amount of changes
v4:
- Add intro to vblank interrupt (Liviu)
- Add historical reference for blanking (Alex)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Co-developed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200406194746.26433-2-sam@ravnborg.org
Sam Ravnborg [Mon, 6 Apr 2020 19:47:45 +0000 (21:47 +0200)]
drm: writeback: document callbacks
Document the callbacks:
drm_connector_helper_funcs.prepare_writeback_job
drm_connector_helper_funcs.cleanup_writeback_job
The documentation was pulled from the changelong introducing the
callbacks, originally written by Laurent.
Adding the missing documentation fixes the following warnings:
drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'prepare_writeback_job' not described in 'drm_connector_helper_funcs'
drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'cleanup_writeback_job' not described in 'drm_connector_helper_funcs'
v2:
- Fix formatting (Daniel)
- Drop changelog text and add reference (Daniel)
- Improve grammar. and use "operation" (Laurent)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200406194746.26433-3-sam@ravnborg.org
Lyude Paul [Fri, 3 Apr 2020 20:03:25 +0000 (16:03 -0400)]
drm/dp_mst: Don't drop NAKs for down responses
It looks like that when we introduced the ability to handle multiple
down requests at once, we accidentally started dropping NAK replies -
causing sideband messages which got NAK'd to seemingly timeout and cause
all sorts of weirdness.
So, fix this by making sure we don't return from
drm_dp_mst_handle_down_rep() early, but instead treat NAKs like any
other message.
Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Wayne Lin <waynelin@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200403200325.885628-1-lyude@redhat.com Reviewed-by: Sean Paul <sean@poorly.run>
Lyude Paul [Mon, 6 Apr 2020 19:33:52 +0000 (15:33 -0400)]
drm/dp_mst: Fix NULL deref in drm_dp_get_one_sb_msg()
While we don't need this function to store an mstb anywhere for UP
requests since we process them asynchronously, we do need to make sure
that we don't try to write to **mstb for UP requests otherwise we'll
cause a NULL pointer deref:
Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <waynelin@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200406193352.1245985-1-lyude@redhat.com Reviewed-by: Sean Paul <sean@poorly.run>
Sam Ravnborg [Sat, 28 Mar 2020 13:20:25 +0000 (14:20 +0100)]
drm/bridge: fix kernel-doc warning in panel.c
Add missing documentation to fix following warning:
panel.c:303: warning: Function parameter or member 'bridge' not described in 'drm_panel_bridge_connector'
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Mihail Atanassov <Mihail.Atanassov@arm.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-7-sam@ravnborg.org
Lyude Paul [Tue, 31 Mar 2020 20:57:36 +0000 (16:57 -0400)]
drm/amd/amdgpu_dm/mst: Stop printing extra messages in dm_dp_add_mst_connector()
You can already trace the creation and destruction of connectors using
DRM, and we definitely don't need to be printing info messages on
connector hotplugs as well. So, get rid of these.
Pankaj Bharadiya started cleaning up the MST connector callbacks a while
ago, as I pointed out that they are the same across every driver and
don't serve much purpose. There was one callback that was left over
though from amdgpu, that we delayed removing due to not being completely
sure as to whether or not it was needed.
So, I've read through said callback and can confirm it's not at all
needed. Pretty much all of the work that is done in
dm_dp_destroy_mst_connector() can be done in
dm_dp_mst_connector_destroy(). Additionally, I've removed some bits that
didn't actually do anything:
* Removed DRM_INFO message we were printing, this shouldn't be info
level and there's more appropriate drm debugging flags that should be
used instead
* Removed amdgpu_dm_update_freesync_caps() - reading into this function,
it doesn't actually do anything important and I'm not sure why it was
ever being called here
* Stop clearing aconnector->dc_sink - this also doesn't do anything
* Stop clearing link settings in dc_link - this also doesn't do anything
* Also, use shorter variable
Tian Tao [Fri, 6 Mar 2020 03:43:01 +0000 (11:43 +0800)]
drm/hisilicon: Enforce 128-byte stride alignment to fix the hardware limitation
because the hardware limitation,The initial color depth must set to 32bpp
and must set the FB Offset of the display hardware to 128Byte alignment,
which is used to solve the display problem at 800x600 and 1440x900
resolution under 16bpp.
projects / users / jedix / linux-maple.git / log