The Allwinner H6 SoC uses a v2.12a DesignWare HDMI controller, with
dedicated CEC and HDCP clocks added; the PHY connected is a standard
DesignWare HDMI PHY.
Jernej Skrabec [Sun, 4 Nov 2018 18:26:54 +0000 (19:26 +0100)]
drm/sun4i: dw-hdmi: Add quirk for setting TMDS clock
It turns out that H6 HDMI BSP kernel driver doesn't change TMDS rate at
all. At this point it is not clear whether it is just not necessary or
it would cause some kind of issues.
Jernej Skrabec [Sun, 4 Nov 2018 18:26:53 +0000 (19:26 +0100)]
drm/sun4i: dw-hdmi: Make mode_valid function configurable
Since it is not possible to access sun8i-dw-hdmi driver private data
inside mode_valid function, make it configurable. That way different
versions of HDMI controllers can set different function, depending on
it's limitations.
Jernej Skrabec [Sun, 4 Nov 2018 18:26:52 +0000 (19:26 +0100)]
drm/sun4i: Not all DW HDMI controllers has scrambled addresses
Currently supported Allwinner SoCs with DW HDMI controller have
scrambled addresses and read lock. However, that is not true in general.
For example, A80 and H6 have normal addresses and normal read access.
Move code for unscrambling addresses and unlocking read access to it's
own function and call it from init function.
Daniel Vetter [Fri, 2 Nov 2018 14:31:07 +0000 (15:31 +0100)]
drm/lease: drop EXPORT_SYMBOL
Leases are entirely implemented within drm.ko, no need to even tempt
drivers into doing nasty things. And if there's really a need, we can
always re-export these again.
drm/selftests: Add tests for drm_internal_framebuffer_create
Add tests that verify that drm_internal_framebuffer_create creates
buffers correctly by creating a dummy drm_device with a mock function
for the fb_create callback.
To decide if a buffer has been created or not it just checks if
fb_create callback has been called for the particular drm_mode_fb_cmd2
that's being tested.
drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled
If we want to be able to write drmselftests for non-static core
functions that are not intended to be used by drivers we need this
functions to be exported.
This adds a macro that is tied of CONFIG_DRM_DEBUG_SELFTEST, and uses
that to export drm_internal_framebuffer_create, in order for
subsequent patches to be able to test it.
drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Changes since v8:
- Fixed build on 32bits arm architectures, with:
Linus Walleij [Fri, 26 Oct 2018 11:13:34 +0000 (13:13 +0200)]
drm/panel: Add simple panel mode for the ARM RTSM
Having failed any attempts at a more generic solution,
I fall back to the very specific solution: define a simple
panel for the ARM RTSM emulated platforms.
I am doing this so we can convert all old users from the
previous fbdev driver to the PL111 DRM driver.
This works fine as far as I can test, provided the
device tree for RTSM AEMv8 is augmented accordingly.
Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181026111334.3365-1-linus.walleij@linaro.org
Noralf Trønnes [Thu, 25 Oct 2018 20:13:39 +0000 (22:13 +0200)]
drm/tilcdc: Use drm_fbdev_generic_setup()
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.
Noralf Trønnes [Thu, 25 Oct 2018 20:13:38 +0000 (22:13 +0200)]
drm/sun4i: Use drm_fbdev_generic_setup()
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.
Noralf Trønnes [Thu, 25 Oct 2018 20:13:37 +0000 (22:13 +0200)]
drm/atmel-hlcdc: Use drm_fbdev_generic_setup()
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.
Noralf Trønnes [Thu, 25 Oct 2018 20:13:33 +0000 (22:13 +0200)]
drm/fsl-dcu: Use drm_fbdev_generic_setup()
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.
Noralf Trønnes [Thu, 25 Oct 2018 20:13:32 +0000 (22:13 +0200)]
drm/arc: Use drm_fbdev_generic_setup()
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.
Chris Wilson [Wed, 31 Oct 2018 12:07:10 +0000 (12:07 +0000)]
drm/syncobj: Mark local add/remove callback functions as static
drivers/gpu/drm/drm_syncobj.c:181:6: warning: no previous prototype for ‘drm_syncobj_add_callback’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_syncobj.c:190:6: warning: no previous prototype for ‘drm_syncobj_remove_callback’ [-Wmissing-prototypes]
Fixing that leads to
drivers/gpu/drm/drm_syncobj.c:181:13: warning: ‘drm_syncobj_add_callback’ defined but not used [-Wunused-function]
so remove the unused drm_syncobj_add_callback() entirely.
Eric Anholt [Wed, 24 Oct 2018 18:43:12 +0000 (11:43 -0700)]
drm: Add an hx8367d tinydrm driver.
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)
This binding is closely modeled after the ili9341 binding, for a
similar product from adafruit. The primary difference is that the
hx8357d doesn't have a reset line that I can find in the schematics.
v2: Document the "reg" property (requested by Rob), fix commit message
typo (Noralf)
Eric Anholt [Thu, 25 Oct 2018 16:26:35 +0000 (09:26 -0700)]
drm/tinydrm: Advertise that we can do only DRM_FORMAT_MOD_LINEAR.
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Heiko Stuebner [Mon, 1 Oct 2018 12:38:45 +0000 (14:38 +0200)]
drm/rockchip: dsi: add dual mipi support
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
Nickey Yang [Mon, 1 Oct 2018 12:38:44 +0000 (14:38 +0200)]
drm/bridge/synopsys: dsi: add dual-dsi support
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
Nickey Yang [Mon, 1 Oct 2018 12:38:43 +0000 (14:38 +0200)]
drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver
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
Heiko Stuebner [Mon, 1 Oct 2018 12:38:41 +0000 (14:38 +0200)]
drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach
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.
Heiko Stuebner [Mon, 1 Oct 2018 12:38:40 +0000 (14:38 +0200)]
drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind
__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.
Heiko Stuebner [Mon, 1 Oct 2018 12:38:39 +0000 (14:38 +0200)]
drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove
Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.
So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-2-heiko@sntech.de
Matthew Wilcox [Wed, 26 Sep 2018 16:00:29 +0000 (09:00 -0700)]
drm/virtio: Handle context ID allocation errors
It is possible to run out of memory while allocating IDs. The current
code would create a context with an invalid ID; change it to return
-ENOMEM to userspace.
Gerd Hoffmann [Fri, 19 Oct 2018 06:18:47 +0000 (08:18 +0200)]
drm/virtio: fix resource id handling
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.
Gerd Hoffmann [Fri, 19 Oct 2018 06:18:42 +0000 (08:18 +0200)]
drm/virtio: track created object state
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.
drm/bridge: analogix_dp: Fix misleading indentation reported by smatch
This patch avoids that building the bridge/analogix source code with
smatch triggers complaints about inconsistent indenting. It also fixes
a typo in DRM_ERROR message, attch is replaced for attach.
Maxime Ripard [Sun, 21 Oct 2018 16:34:46 +0000 (18:34 +0200)]
drm/sun4i: hdmi: Fix double flag assignation
The is_double flag is a boolean currently assigned to the value of the d
variable, that is either 1 or 2. It means that this is_double variable is
always set to true, even though the initial intent was to have it set to
true when d is 2.
Maxime Ripard [Sun, 21 Oct 2018 16:34:45 +0000 (18:34 +0200)]
drm/sun4i: hdmi: Fix unitialized variable
The is_double variable is used to store, and possibly returning to the
calling function, whether it needs to double the rate of the parent clock
or not.
In the case where it does, the variable is affected, but in the case where
it doesn't we return some uninitialized value. Fix this.
Emil Velikov [Fri, 26 Oct 2018 10:05:50 +0000 (11:05 +0100)]
drm/vkms: provide a parent device to drm_dev_init()
Earlier commit updated the vgem driver to improve the topology, by
passing a platform device as parent to drm_dev_init(). Shortly
afterwords we updated the core function to BUG() in order to catch any
buggy drivers passing NULL as parent.
While I missed the vkms driver (as the patch predates vkms by a few
months), the BUG caught the issue within couple of hours.
Swap the drm_dev_init <> platform_device_register_simple order, to
the driver back to life.
Fixes: f08877e79485 ("drm: BUG_ON if passing NULL parent to drm_dev_init") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Deepak Sharma <deepak.sharma@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181026100550.625-1-emil.l.velikov@gmail.com
Clint Taylor [Wed, 24 Oct 2018 21:04:33 +0000 (14:04 -0700)]
drm/i915/hdmi: Detect HDMI 2.0 monitors using multiple EDID capabilities
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
Chris Wilson [Fri, 26 Oct 2018 08:03:02 +0000 (09:03 +0100)]
dma-buf: Update reservation shared_count after adding the new fence
We need to serialise the addition of a new fence into the shared list
such that the fence is visible before we claim it is there. Otherwise a
concurrent reader of the shared fence list will see an uninitialised
fence slot before it is set.
Chunming Zhou [Fri, 26 Oct 2018 06:20:27 +0000 (14:20 +0800)]
drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389 but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
v3:
use a global signaled fence instead of re-allocation.
v4:
Don't need moving lock.
Don't expose func.
v5:
rename func and directly return.
Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
lock debug kernel options enabled.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Christian König <easy2remember.chk@googlemail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> CC: Julia Lawall <julia.lawall@lip6.fr> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/258623/
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.
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.
Emil Velikov [Tue, 23 Oct 2018 16:35:49 +0000 (17:35 +0100)]
drm: BUG_ON if passing NULL parent to drm_dev_init
Previous commit removed the only reason why we were allowing NULL as
a parent device. With that resolved, we can enforce nobody else does
that mistake.
With that we can drop the ugly drm_dev_set_unique workaround.
Deepak Sharma [Tue, 23 Oct 2018 16:35:48 +0000 (17:35 +0100)]
drm/vgem: Fix vgem_init to get drm device available.
Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.
v2: rebase, address checkpatch typo and line over 80 characters
Sean Paul [Wed, 24 Oct 2018 18:24:30 +0000 (14:24 -0400)]
drm: Fix doc warning in drm_connector_attach_edid_property()
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: 6b7e2d5c3032 ("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
Lyude Paul [Tue, 23 Oct 2018 23:12:47 +0000 (19:12 -0400)]
drm/dp_mst: Remove all evil duplicate state pointers
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.
Lyude Paul [Tue, 23 Oct 2018 23:12:46 +0000 (19:12 -0400)]
drm/dp_mst: Deprecate drm_dp_find_vcpi_slots()
Because we have drm_dp_atomic_find_vcpi_slots(), which actually takes
care to update the atomic state of the MST topology, prints valuable
debugging output, and actually takes references to the ports it's
checking! This explains some incorrect usage I've been seeing across the
tree...
Boris Brezillon [Tue, 9 Oct 2018 13:24:46 +0000 (15:24 +0200)]
drm/vc4: Set ->is_yuv to false when num_planes == 1
When vc4_plane_state is duplicated ->is_yuv is left assigned to its
previous value, and we never set it back to false when switching to
a non-YUV format.
Fix that by setting ->is_yuv to false in the 'num_planes == 1' branch
of the vc4_plane_setup_clipping_and_scaling() function.
Boris Brezillon [Fri, 3 Aug 2018 09:22:31 +0000 (11:22 +0200)]
drm/vc4: Fix X/Y positioning of planes using T_TILES modifier
X/Y positioning of T-format buffers is quite tricky and the current
implementation was failing to position a plane using this format
correctly when the CRTC X, Y or both X and Y offsets were negative.
It was also failing when the SRC X/Y offsets were != 0.
Boris Brezillon [Fri, 3 Aug 2018 09:22:30 +0000 (11:22 +0200)]
drm/vc4: Move ->offsets[] adjustment out of setup_clipping_and_scaling()
The offset adjustment depends on the framebuffer modified, so let's
just move this operation in the DRM_FORMAT_MOD_LINEAR case inside
vc4_plane_mode_set().
This we'll be able to fix offset calculation for
DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED and DRM_FORMAT_MOD_BROADCOM_SANDXXX.
Linus Walleij [Tue, 23 Oct 2018 07:46:30 +0000 (09:46 +0200)]
drm/panel: Add driver for Samsung S6D16D0 panel
The Samsung S6D16D0 is a simple comman mode only DSI display
that is used on the ST-Ericsson Ux500 reference design
TVK1281618 user interface board (UIB).
Linus Walleij [Tue, 23 Oct 2018 07:24:22 +0000 (09:24 +0200)]
drm: dsi: Add lane clock rate fields to DSI device
The DSI devices have a maximum operating frequency specified
in their data sheet per the MIPI specification, and DSI hosts
that can scale their frequency need this information to set
their clock dividers right.
As current panel drivers often lack this information, specify
that setting it to zero will make the DSI host use some
reasonable default.
DRM: UDL: get rid of useless vblank initialization
UDL doesn't support vblank functionality so we don't need to
initialize vblank here (we are able to send page flip
completion events even without vblank initialization)
Moreover current drm_vblank_init call with num_crtcs > 0 causes
sending DRM_EVENT_FLIP_COMPLETE event with zero timestamp every
time. This breaks userspace apps (for example weston) which
relies on timestamp value.
Chunming Zhou [Tue, 23 Oct 2018 09:37:45 +0000 (17:37 +0800)]
drm: fix deadlock of syncobj v6
v2:
add a mutex between sync_cb execution and free.
v3:
clearly separating the roles for pt_lock and cb_mutex (Chris)
v4:
the cb_mutex should be taken outside of the pt_lock around
this if() block. (Chris)
v5:
fix a corner case
v6:
tidy drm_syncobj_fence_get_or_add_callback up. (Chris)
Tested by syncobj_basic and syncobj_wait of igt.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.kernel.org/patch/10652893/
Aaron Ma [Fri, 31 Aug 2018 18:19:59 +0000 (02:19 +0800)]
vgaarb: Add support for 64-bit frame buffer address
EFI GOP uses 64-bit frame buffer address when some BIOS
disabled CSM support. vgaarb only stores lfb_base,
this will lead boot framebuffer to wrong device.
Add ext_lfb_base support to use 64-bit fb address.
The idea is to split test implementations in different compilation
units, but have one single place where we define the list of tests,
in this case(drm_modeset_selftests.h).
Manasi Navare [Tue, 9 Oct 2018 00:23:51 +0000 (17:23 -0700)]
drm/dp: Add definitions for eDP Rev 1.4a and 1.4b
VESA eDP 1.4 specification has separate fields defined in
EDP_DPCD_REV for eDP 1.4a and 1.4b eDP revisions.
This patch defines those. Found this when one of my eDP panels
advertises eDP 1.4a (04h) in the EDP_DPCD_REV DPCD field.
Dave Airlie [Fri, 19 Oct 2018 04:28:10 +0000 (14:28 +1000)]
Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637)
- Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla #108264)
- Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla #107489 and #105338)
- MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of Icelake fixes
- Then assorted proactive code fixes caught by CI or developers
projects / linux.git / log