Emil Velikov [Mon, 27 May 2019 08:17:35 +0000 (09:17 +0100)]
drm/msm: drop DRM_AUTH usage from the driver
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: freedreno@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-7-emil.l.velikov@gmail.com
Brian Starkey [Tue, 6 Aug 2019 12:46:22 +0000 (13:46 +0100)]
drm/crc-debugfs: Add notes about CRC<->commit interactions
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Changes since v1:
- Clarified that anything that would disable CRCs counts as a full
modeset, and so userspace needs to reconfigure after full modesets
Changes since v2:
- Add these notes
- Rebase onto drm-misc-next (trivial conflict in comment)
Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link:- https://patchwork.freedesktop.org/patch/321974/
Ramalingam C [Thu, 1 Aug 2019 11:41:18 +0000 (17:11 +0530)]
drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320965/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:17 +0000 (17:11 +0530)]
drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
v4:
KDoc is extended bit more [pekka]
v5:
Uevent usage is documented at kdoc of "Content Protection" also
[pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320963/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:16 +0000 (17:11 +0530)]
drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
v4:
Typos and string length suggestions are addressed [Sean]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320961/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:15 +0000 (17:11 +0530)]
drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320959/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:14 +0000 (17:11 +0530)]
drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
v10:
Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
Gerd Hoffmann [Mon, 5 Aug 2019 14:01:11 +0000 (16:01 +0200)]
drm/ttm: set both resv and base.resv pointers
Initialize both ttm_buffer_object->resv and ttm_buffer_object->base.resv
pointers. This allows to move users from the former to the latter. When
all users are moved we can drop ttm_buffer_object->resv.
Gerd Hoffmann [Mon, 5 Aug 2019 14:01:03 +0000 (16:01 +0200)]
drm/ttm: add gem base object
Add drm_gem_object struct to ttm_buffer_object, so ttm objects are a gdm
object superclass. Add a function to check whenever a given bo actually
uses the embedded drm_gem_object.
drm_vblank_enable():
- There is no need here because there can be no sleeping waiters
in the queue, because vblank->enabled == false immediately
terminates any waits.
drm_crtc_accurate_vblank_count():
- This is called from interrupt handlers, at least from
amdgpu_dm.c:dm_pflip_high_irq(). Not sure it needs to wake up
the queue though, the driver should call
drm_(crtc_)_handle_vblank anyway.
drm_vblank_disable_and_save():
- It can be called from an interrupt, via drm_handle_vblank ->
vblank_disable_fn. However, the only place where
drm_vblank_disable_and_save can be called with sleeping waiters
in the queue is in drm_crtc_vblank_off, which wakes up the queue
afterwards (which terminates all waits, because
vblank->enabled == false at this point).
v3:
- Added analysis to changelog from Michel Dänzer
- Moved return result handling inside if (req_seq != seq) (Daniel V)
- Reused more of the former logic - resulting in simpler code
- Dropped Reviewed-by from Sean Paul as this is a new implementation
v2:
- Fix so the case where req_seq equals seq was handled properly
- quick hack to check if IGT became happy
- Only sent to igt, not to dri-devel
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Cc: Sean Paul <sean@poorly.run> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190726210658.GA6299@ravnborg.org
The pads were an earlier workaround for the internal image
pipeline in the Linux fbdev subsystem. As we move to generic
definition of display properties and drivers that no longer
need this to work, deprecate this property.
Komeda HW can support dual-link which splits display frame to two halves
(left/link0, right/link1) and output them by two output links.
Due to the halved pixel rate of each link, the pxlclk of dual-link can be
reduced two times compare with single-link.
For enabling dual-link:
- The DT need to configure two output-links for the pipeline node.
- Komeda enable dual-link when both link0 and link1 have been connected.
Example of how the pipeline node will look like for dual-link setup
drm/komeda: Use drm_display_mode "crtc_" prefixed hardware timings
struct drm_display_mode contains two copies of timings.
- plain timings.
- hardware timings, the ones with "crtc_" prefix.
According to the definition, update komeda to use the hardware timing.
drm/drm_debugfs_crc.c: Document that .verify_crc_source vfunc is required for enabling CRC support.
drm_debugfs_crtc_crc_add() function checks that both .set_crc_source and
.verify_crc_source hooks are provided before enabling debugfs support for
reading per-frame CRC data. Make that explicit in the documentation.
Anders Roxell [Tue, 30 Jul 2019 15:30:56 +0000 (17:30 +0200)]
drm: mali-dp: Mark expected switch fall-through
Now that -Wimplicit-fallthrough is passed to GCC by default, the
following warnings shows up:
../drivers/gpu/drm/arm/malidp_hw.c: In function ‘malidp_format_get_bpp’:
../drivers/gpu/drm/arm/malidp_hw.c:387:8: warning: this statement may fall
through [-Wimplicit-fallthrough=]
bpp = 30;
~~~~^~~~
../drivers/gpu/drm/arm/malidp_hw.c:388:3: note: here
case DRM_FORMAT_YUV420_10BIT:
^~~~
../drivers/gpu/drm/arm/malidp_hw.c: In function ‘malidp_se_irq’:
../drivers/gpu/drm/arm/malidp_hw.c:1311:4: warning: this statement may fall
through [-Wimplicit-fallthrough=]
drm_writeback_signal_completion(&malidp->mw_connector, 0);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/arm/malidp_hw.c:1313:3: note: here
case MW_START:
^~~~
Rework to add a 'break;' in a case that didn't have it so that
the compiler doesn't warn about fall-through.
Cc: stable@vger.kernel.org # v5.2+ Fixes: b8207562abdd ("drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats") Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730153056.3606-1-anders.roxell@linaro.org
Earlier there were no mode_valid() helper for crtc and tilcdc had a
hack to over come this limitation. But now the mode_valid() helper is
there (has been since v4.13), so it is about time to get rid of that
hack.
It causes the following build error:
../drm/radeon/radeon_connectors.c: In function 'radeon_add_legacy_connector':
../drm/radeon/radeon_connectors.c:2433:5: error: 'ddc' undeclared (first use in this function)
ddc = &radeon_connector->ddc_bus->adapter;
^~~
Allow passing ddc adapter pointer to the init function. Even if
drm_connector_init() sometime in the future decides to e.g. memset() all
connector fields to zeros, the newly added function ensures that at its
completion the ddc member of connector is correctly set.
drm: Add ddc link in sysfs created by drm_connector
Add generic code which creates symbolic links in sysfs, pointing to ddc
interface used by a particular video output. For example:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/13880000.i2c/i2c-2
This makes it easy for user to associate a display with its ddc adapter
and use e.g. ddcutil to control the chosen monitor.
This patch adds an i2c_adapter pointer to struct drm_connector. Particular
drivers can then use it instead of using their own private instance. If a
connector contains a ddc, then create a symbolic link in sysfs.
Move the driver to the new haven for tiny DRM drivers.
Cc: Hans de Goede <hdegoede@redhat.com> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725105132.22545-4-noralf@tronnes.org
Daniel Vetter [Thu, 25 Jul 2019 13:26:54 +0000 (15:26 +0200)]
drm/amdgpu: Fill out gem_object->resv
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.
Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.
Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.
Acked-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Michel Dänzer" <michel.daenzer@amd.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Huang Rui <ray.huang@amd.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Evan Quan <evan.quan@amd.com> Cc: Sonny Jiang <sonny.jiang@amd.com> Cc: Amber Lin <Amber.Lin@amd.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Thomas Zimmermann <contact@tzimmermann.org> Cc: Samuel Li <Samuel.Li@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725132655.11951-4-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 25 Jul 2019 13:26:53 +0000 (15:26 +0200)]
drm/nouveau: Fill out gem_object->resv
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.
Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.
Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.
Acked-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725132655.11951-3-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 25 Jul 2019 13:26:52 +0000 (15:26 +0200)]
drm/radeon: Fill out gem_object->resv
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.
Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.
Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.
Acked-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725132655.11951-2-daniel.vetter@ffwll.ch
Christian König [Mon, 22 Jul 2019 12:56:25 +0000 (14:56 +0200)]
drm/syncobj: fix leaking dma_fence in drm_syncobj_query_ioctl
We need to check the context number instead if the previous sequence to detect
an error and if an error is detected we need to drop the reference to the
current fence or otherwise would leak it.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 27b575a9aa2f ("drm/syncobj: add timeline payload query ioctl v6") Link: https://patchwork.freedesktop.org/patch/319123/
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning (Building: arm):
drivers/gpu/drm/sti/sti_hdmi.c: In function ‘hdmi_audio_configure’:
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
drivers/gpu/drm/sti/sti_hdmi.c:852:2: note: here
case 6:
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
drivers/gpu/drm/sti/sti_hdmi.c:854:2: note: here
case 4:
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
drivers/gpu/drm/sti/sti_hdmi.c:856:2: note: here
case 2:
^~~~
Sean Paul [Fri, 26 Jul 2019 14:20:47 +0000 (10:20 -0400)]
drm/mst: Fix sphinx warnings in drm_dp_msg_connector register functions
Fixes the following warnings:
../drivers/gpu/drm/drm_dp_mst_topology.c:1593: warning: Excess function parameter 'drm_connector' description in 'drm_dp_mst_connector_late_register'
../drivers/gpu/drm/drm_dp_mst_topology.c:1613: warning: Excess function parameter 'drm_connector' description in 'drm_dp_mst_connector_early_unregister'
../drivers/gpu/drm/drm_dp_mst_topology.c:1594: warning: Function parameter or member 'connector' not described in 'drm_dp_mst_connector_late_register'
../drivers/gpu/drm/drm_dp_mst_topology.c:1614: warning: Function parameter or member 'connector' not described in 'drm_dp_mst_connector_early_unregister'
Fixes: 562836a269e3 ("drm/dp_mst: Enable registration of AUX devices for MST ports") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190726142057.224121-1-sean@poorly.run
Sean Paul [Tue, 11 Jun 2019 16:08:25 +0000 (12:08 -0400)]
drm/rockchip: Use drm_atomic_helper_commit_tail_rpm
Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- None
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-6-sean@poorly.run
Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-5-sean@poorly.run
Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-11-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-12-sean@poorly.run
Sean Paul [Tue, 11 Jun 2019 16:08:24 +0000 (12:08 -0400)]
drm/rockchip: Don't fully disable vop on self refresh
Instead of fully disabling and re-enabling the vop on self refresh
transitions, only disable the active windows. This will speed up
self refresh exits substantially and is still a power-savings win.
This patch integrates portions of Zain's patch from here:
https://patchwork.kernel.org/patch/9615063/
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- Adjust for preceding vop_win_disable changes
Changes in v5:
- None
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-5-sean@poorly.run
Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-4-sean@poorly.run
Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-10-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-11-sean@poorly.run
Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-11-sean@poorly.run
Sean Paul [Tue, 11 Jun 2019 16:08:22 +0000 (12:08 -0400)]
drm/rockchip: Use the helpers for PSR
Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the new self refresh helpers to do the heavy lifting.
Changes in v2:
- updated to reflect changes made in the helpers
Changes in v3:
- use the new atomic hooks to inspect crtc state instead of needing conn state (Daniel)
Changes in v4:
- Use Laurent's get_new_connector_for_encoder helper (Daniel)
- Exit vop disable early if it's already off
Changes in v5:
- Rebase on latest drm-misc-next
- Resolve conflict with s/edp_vsc_psr/dp_sdp/ rename
- Resolve conflict with drm_atomic.h header inclusion
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-4-sean@poorly.run
Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-3-sean@poorly.run
Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-9-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-9-sean@poorly.run
Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
[seanpaul resolved some conflicts with drmP.h work and Helen's async fixes] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-9-sean@poorly.run
Sean Paul [Tue, 11 Jun 2019 16:08:21 +0000 (12:08 -0400)]
drm/rockchip: Check for fast link training before enabling psr
Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- None
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-3-sean@poorly.run
Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-2-sean@poorly.run
Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-9-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-8-sean@poorly.run
drm/panel: jh057n00900: Move panel DSI init to enable()
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre_enable().
Douglas Anderson [Mon, 22 Jul 2019 18:24:39 +0000 (11:24 -0700)]
video: amba-clcd: Spout an error if of_get_display_timing() gives an error
In the patch ("video: of: display_timing: Don't yell if no timing node
is present") we'll stop spouting an error directly in
of_get_display_timing() if no node is present. Presumably amba-clcd
should take charge of spouting its own error now.
NOTE: we'll print two errors if the node was present but there were
problems parsing the timing node (one in of_parse_display_timing() and
this new one). Since this is a fatal error for the driver's probe
(and presumably someone will be debugging), this should be OK.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722182439.44844-5-dianders@chromium.org
Douglas Anderson [Mon, 22 Jul 2019 18:24:38 +0000 (11:24 -0700)]
drm: panel-lvds: Spout an error if of_get_display_timing() gives an error
In the patch ("video: of: display_timing: Don't yell if no timing node
is present") we'll stop spouting an error directly in
of_get_display_timing() if no node is present. Presumably panel-lvds
should take charge of spouting its own error now.
NOTE: we'll print two errors if the node was present but there were
problems parsing the timing node (one in of_parse_display_timing() and
this new one). Since this is a fatal error for the driver's probe
(and presumably someone will be debugging), this should be OK.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722182439.44844-4-dianders@chromium.org
Douglas Anderson [Mon, 22 Jul 2019 18:24:37 +0000 (11:24 -0700)]
video: of: display_timing: Don't yell if no timing node is present
There may be cases (like in panel-simple.c) where we have a sane
fallback if no timings are specified in the device tree. Let's get
rid of the unconditional pr_err(). We can add error messages in
individual drivers if it makes sense.
NOTE: we'll still print errors if the node is present but there are
problems parsing the timings.
Fixes: b8a2948fa2b3 ("drm/panel: simple: Add ability to override typical timing") Reported-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722182439.44844-3-dianders@chromium.org
Douglas Anderson [Mon, 22 Jul 2019 18:24:36 +0000 (11:24 -0700)]
video: of: display_timing: Add of_node_put() in of_get_display_timing()
From code inspection it can be seen that of_get_display_timing() is
lacking an of_node_put(). Add it.
Fixes: ffa3fd21de8a ("videomode: implement public of_get_display_timing()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722182439.44844-2-dianders@chromium.org
The following function calls may fail and return NULL, so the null check
is added.
of_graph_get_next_endpoint
of_graph_get_remote_port_parent
of_graph_get_remote_port
Update: Thanks to Sam Ravnborg, for suggession on the use of goto to avoid
leaking endpoint.
Steven Price [Wed, 24 Jul 2019 10:56:26 +0000 (11:56 +0100)]
drm/panfrost: Export all GPU feature registers
Midgard/Bifrost GPUs have a bunch of feature registers providing details
of what the hardware supports. Panfrost already reads these, this patch
exports them all to user space so that the jobs created by the user space
driver can be tuned for the particular hardware implementation.
Leo Li [Tue, 23 Jul 2019 23:28:08 +0000 (19:28 -0400)]
drm/amd/display: Implement MST Aux device registration
Implement late_register and early_unregister hooks for MST connectors.
Call drm helpers for MST connector registration, which registers the
AUX devices.
Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723232808.28128-10-sunpeng.li@amd.com
projects / kernel.git / log