I want to sort out support for tinydrm in vc4, so I needed to get a
tinydrm-appropriate panel working and this is what I had on hand.
This is derived from a combination of ili9341.c from tinydrm and
fb_hx8357d.c from staging's fbtft.
v2: Write my own register defs from the spec to not need the header
from fbtft. Fix spi device string to enable module autoloading.
(Suggestions by Noralf)
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024184313.2967-3-eric@anholt.net
Reviewed-by: Noralf Trønnes <noralf@tronnes.org> (v1)
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
As described in the general dual-dsi devicetree binding, the panel should
define two input ports and point each of them to one of the used dsi-
controllers, as well as declare one of them as clock-master.
This is used to determine the dual-dsi state and get access to both
controller instances.
v6:
handle master+slave component in dsi-attach
v5:
use driver-internal mechanism to find dual dsi slave
v4:
add component directly in probe when adding empty dsi slave controller
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-8-heiko@sntech.de
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi outputs.
To activate, the implementation-specific code should set the slave
using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().
v2:
- expect real interface number of lanes
- keep links to both master and slave
v3:
- remove unneeded separate variables
- remove unneeded second slave settings
- disable slave before master
- lane-sum calculation comments
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-7-heiko@sntech.de
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge and remove the old separate one.
changes:
v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
fix typo, use of_device_get_match_data(),
change some bind() logic into probe()
add 'dev_set_drvdata()'
v4:
return -EINVAL when can not get best_freq
add a clarifying comment when get vco
add review tag
v5:
keep our power domain enabled while touching GRF
v6:
change func name dw_mipi_encoder_disable to
dw_mipi_dsi_encoder_disable
v7:
none
v8: Heiko
add Archit's Review tag
adapt to recent changes in the original rockchip-dsi driver
beautify grf-handling
split hw-setup (resources, dsi-host) from bind into probe
v2-new: Heiko
add SPDX header instead of license blurb
drop old versioning to not confuse people
v3-new: Heiko
include ordering
moved hwaccess from mode_set to enable callback
move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps)
v4-new: Heiko
rebase against recent rockchip-dsi changes
move to call component_add in the new glue host-attach
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-6-heiko@sntech.de
With the regular means of adding the dsi-component in probe it creates
a race condition with the panel probing, as the panel device only gets
created after the dsi-bus got created.
When the panel-driver is build as a module it currently fails hard as the
panel cannot be probed directly:
dw_mipi_dsi_bind()
__dw_mipi_dsi_probe()
creates dsi bus
creates panel device
triggers panel module load
panel not probed (module not loaded or panel probe slow)
drm_bridge_attach
fails with -EINVAL due to empty panel_bridge
Additionally the panel probing can run concurrently with dsi bringup
making it possible that the panel can already be found but dsi-attach
hasn't finished running.
To solve that cleanly we may want to only create the component after
the panel has finished probing, by calling component_add from the
host-attach dsi callback.
As that is specific to glue drivers, add a new struct for host_ops
so that glue drivers can tell the bridge to call specific functions
after the common host-attach and before the common host-detach run.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-4-heiko@sntech.de
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.
Drivers using the component framework may instead want to call
dw_mipi_dsi_probe separately in their probe function to setup resources
early. That way the dsi bus also gets created earlier and also not
recreated on each bind-try, so that attached panels can load their modules
and be probed way before the bridge-attach in the bind call.
So drop the call to __dw_mipi_dsi_probe and modify the function to take
a struct dw_mipi_dsi instead of the platform-device.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-3-heiko@sntech.de
Move virtio_gpu_resource_id_{get,put} to virtgpu_object.c and make them
static. Allocate and free the id on creation and destroy, drop all
other calls. That way objects have a valid handle for the whole
lifetime of the object.
Also fixes ids leaking. Worst offender are dumb buffers, and I think
some error paths too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-7-kraxel@redhat.com
Track whenever the virtio_gpu_object is already created (i.e. host knows
about it) in a new variable. Add checks to virtio_gpu_object_attach()
to do nothing on objects not created yet.
Make virtio_gpu_ttm_bo_destroy() use the new variable too, instead of
expecting hw_res_handle indicating the object state.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-2-kraxel@redhat.com
HDMI 2.0 monitors may not support SCDC and still be able to accept VICs
above 63. Use multiple EDID capbilities to determine if the SINK is
actually an HDMI 2.0 device. The QD980B HDMI 2.0 Analyzer generates unique
EDIDs during CTS tests that don't contain a HDMI Forum VSDB if the block is
not used during the test. The current HDMI AVI infoframe code only uses the
SCDC supported information in the HDMI Forum VSDB to determine if the sink
is HDMI 2.0. This patch adds a check for YCbCr420 present in the EDID
supported formats as well as the existing SCDC supported check.
HDMI 2.0 CTS HF1-51 test fails on the QD980B.
V2: Make check for display_info->color formats == YCbCR420 and SCDC
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107894
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1540415073-5102-1-git-send-email-clinton.a.taylor@intel.com
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Yannick Fertré <yannick.fertre@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-15-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-6-noralf@tronnes.org
A while back we removed it, yet that lead to regressions. At some later
point, I've attempted to remove it again without fully grasping the
unique (pun intended) situation that virtio is in.
Add a bulky comment to document why the call should stay as-is, for the
next person who's around.
As a Tl;Dr: virtio sits on top of struct virtio_device, which confuses
dev_is_pci(), wrong info gets sent to userspace and X doesn't start.
Driver needs to explicitly call drm_dev_set_unique() to keep it working.
v2: Fix handful of typos (Laszlo)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024144252.16518-1-emil.l.velikov@gmail.com
Fixes the following warnings:
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:306: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
Fixes: 6b7e2d5c30 ("drm: add drm_connector_attach_edid_property()")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024182442.206411-1-sean@poorly.run
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.
This confused me for over 4 hours until I realized there was no magic
behind these pointers. So, let's save everyone else from the trouble.
Signed-off-by: Lyude Paul <lyude@redhat.com>.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023231251.16883-3-lyude@redhat.com
4.19 is out, Lyude asked for a backmerge, and it's been a while. All
very good reasons on their own :-)
Signed-off-by: Sean Paul <seanpaul@chromium.org>
