Emil Velikov [Tue, 5 May 2020 16:03:28 +0000 (17:03 +0100)]
drm/panel: use mipi_dsi_dcs_write_buffer where possible
A few of the new panels create a local macro wrapping around
mipi_dsi_dcs_write. At the same time, they don't really care about the
command/payload split.
mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload > 7 bytes.
Avoid that all together by using the _buffer function.
Aside:
panel-xinpeng-xpp055c272.c calls its wrapper "generic" although it
should be "dcs". But that for another day/patch.
Cc: Heiko Stuebner <heiko@sntech.de> Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200505160329.2976059-2-emil.l.velikov@gmail.com
Emil Velikov [Tue, 5 May 2020 16:03:27 +0000 (17:03 +0100)]
drm/dsi: use stack buffer in mipi_dsi_dcs_write()
Currently the function heap allocates when we have any payload. Where in
many case the payload is 1 byte - ouch.
>From casual observation, vast majority of the payloads are smaller than
8 bytes - so use a stack array tx[8] to avoid the senseless kmalloc and
kfree dance.
Nirmoy Das [Wed, 24 Jun 2020 18:26:48 +0000 (20:26 +0200)]
drm/ttm: do not keep GPU dependent addresses
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372937/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Thu, 25 Jun 2020 12:07:23 +0000 (14:07 +0200)]
drm/scheduler: improve job distribution with multiple queues
This patch uses score to select a new drm scheduler for better
loadbalance between multiple drm schedulers instead of num_jobs.
Below are test results after running amdgpu_test for ~10 times.
Before this patch:
sched_name num of many times it got schedule
========= ==================================
sdma0 1463
sdma1 198
comp_1.0.1 280
After this patch:
sched_name num of many times it got schedule
========= ==================================
sdma0 925
sdma1 928
comp_1.0.1 177
comp_1.1.1 44
comp_1.2.1 43
comp_1.3.1 44
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/373000/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Wed, 24 Jun 2020 18:26:44 +0000 (20:26 +0200)]
drm/nouveau: don't use ttm bo->offset v3
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372932/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Wed, 24 Jun 2020 18:26:43 +0000 (20:26 +0200)]
drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372933/ Signed-off-by: Christian König <christian.koenig@amd.com>
Harigovindan P [Tue, 9 Jun 2020 12:04:55 +0000 (17:34 +0530)]
drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
ti-sn65dsi86 bridge is enumerated as a runtime device. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend will not be called
and it kept the bridge regulators and gpios ON which resulted
in platform not entering into XO shutdown.
Add changes to force suspend on the runtime device during pm sleep.
Bhanuprakash Modem [Mon, 22 Jun 2020 14:25:18 +0000 (19:55 +0530)]
drm/debug: Expose connector VRR monitor range via debugfs
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node to i915_vrr_info so we can add
other vrr info for more debug info (Manasi)
* Change the VRR capable to display Yes or No (Manasi)
* Fix indentation checkpatch errors (Manasi)
v3:
* Remove the unnecessary debug print (Manasi)
v4:
* Rebase
v5:
* Rename to vrr_range to match AMD debugfs
v6:
* Rebase (manasi)
v7:
* Fix cmpilation due to rebase
v8:
* Move debugfs node creation logic to DRM (Emil)
* Remove AMD specific logic (Emil)
v9:
* Separate patch for removal of AMD specific logic (Manasi)
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> CC: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200622142519.16214-3-bhanuprakash.modem@intel.com
Nirmoy Das [Wed, 24 Jun 2020 18:26:47 +0000 (20:26 +0200)]
drm/bochs: use drm_gem_vram_offset to get bo offset v2
Switch over to GEM VRAM's implementation to retrieve bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372931/
Nirmoy Das [Wed, 24 Jun 2020 18:26:46 +0000 (20:26 +0200)]
drm/vram-helper: don't use ttm bo->offset v4
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372938/
Nirmoy Das [Wed, 24 Jun 2020 18:26:45 +0000 (20:26 +0200)]
drm/qxl: don't use ttm bo->offset
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar.
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372934/
Nirmoy Das [Wed, 24 Jun 2020 18:26:42 +0000 (20:26 +0200)]
drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-and-tested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372935/
Nirmoy Das [Wed, 24 Jun 2020 18:26:41 +0000 (20:26 +0200)]
drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372930/
Daniel Vetter [Fri, 12 Jun 2020 07:05:35 +0000 (09:05 +0200)]
dma-buf: minor doc touch-ups
Just some tiny edits:
- fix link to struct dma_fence
- give slightly more meaningful title - the polling here is about
implicit fences, explicit fences (in sync_file or drm_syncobj) also
have their own polling
v2: I misplaced the .rst include change corresponding to this patch.
Daniel Vetter [Fri, 12 Jun 2020 16:00:55 +0000 (18:00 +0200)]
drm/mipi-dbi: Remove ->enabled
The atomic helpers try really hard to not lose track of things,
duplicating enabled tracking in the driver is at best confusing.
Double-enabling or disabling is a bug in atomic helpers.
In the fb_dirty function we can just assume that the fb always exists,
simple display pipe helpers guarantee that the crtc is only enabled
together with the output, so we always have a primary plane around.
Now in the update function we need to be a notch more careful, since
that can also get called when the crtc is off. And we don't want to
upload frames when that's the case, so filter that out too.
Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> 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> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-7-daniel.vetter@ffwll.ch
Laurent Pinchart [Tue, 26 May 2020 01:15:00 +0000 (04:15 +0300)]
drm: bridge: dw-hdmi: Make connector creation optional
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() notify to report HPD. This provides the
necessary API to support disabling connector creation, do so by
accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in dw_hdmi_bridge_attach().
Laurent Pinchart [Tue, 26 May 2020 01:14:59 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_connector to internal functions as needed
To prepare for making connector creation optional in the driver, pass
the drm_connector explicitly to the internal functions that require it.
The functions that still access the connector from the dw_hdmi structure
are dw_hdmi_connector_create() and __dw_hdmi_probe(). The former access
is expected, as that's where the internal connector is created. The
latter will be addressed separately.
Laurent Pinchart [Tue, 26 May 2020 01:14:58 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Store current connector in struct dw_hdmi
Store the connector that the bridge is currently wired to in the dw_hdmi
structure. This is currently identical to the connector field, but will
differ once the driver supports disabling connector creation.
Laurent Pinchart [Tue, 26 May 2020 01:14:56 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc()
To prepare for making connector creation optional in the driver, pass
the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer
is passed to the callers where required, particularly to the
dw_hdmi_phy_ops .init() function.
Laurent Pinchart [Tue, 26 May 2020 01:14:55 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Constify mode argument to internal functions
Several internal functions take a drm_display_mode argument to configure
the HDMI encoder or the HDMI PHY. They must not modify the mode, make
the pointer const to enforce that.
Laurent Pinchart [Tue, 26 May 2020 01:14:53 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid()
Replace the drm_connector pointer passed to the .mode_valid() function
with a const drm_display_info pointer, as that's all the function should
need. Use the display info passed to the bridge .mode_valid() operation
instead of retrieving it from the connector, to prepare for make
connector creation optional.
Laurent Pinchart [Tue, 26 May 2020 01:14:52 +0000 (04:14 +0300)]
drm: meson: dw-hdmi: Use dw_hdmi context to replace hack
The meson-dw-hdmi driver needs to access its own context from the
.mode_valid() operation. It currently gets it from the dev_private field
of the drm_device retrieved from the connector, which is a hack. Use the
private data passed to the .mode_valid() operation instead.
Laurent Pinchart [Tue, 26 May 2020 01:14:50 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy()
The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a
context argument. This differs from .mode_valid() that takes a custom
private context pointer, causing possible confusion. Make the
dw_hdmi_plat_data operations more consistent by passing the private
context pointer to .configure_phy() as well.
Laurent Pinchart [Tue, 26 May 2020 01:14:49 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid()
Platform glue drivers for dw_hdmi may need to access device-specific
data from their .mode_valid() implementation. They currently have no
clean way to do so, and one driver hacks around it by accessing the
dev_private data of the drm_device retrieved from the connector.
Add a priv_data void pointer to the dw_hdmi_plat_data structure, and
pass it to the .mode_valid() function.
Laurent Pinchart [Tue, 26 May 2020 01:14:48 +0000 (04:14 +0300)]
drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
When validating a mode, bridges may need to do so in the context of a
display, as specified by drm_display_info. An example is the meson
dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
perform clock calculations.
Bridges that need the display info currently retrieve it from the
drm_connector created by the bridge. This gets in the way of moving
connector creation out of bridge drivers. To make this possible, pass
the drm_display_info to drm_bridge_funcs .mode_valid().
Changes to the bridge drivers have been performed with the following
coccinelle semantic patch and have been compile-tested.
Laurent Pinchart [Tue, 26 May 2020 01:14:47 +0000 (04:14 +0300)]
drm: edid: Constify connector argument to infoframe functions
The drm_hdmi_avi_infoframe_from_display_mode(),
drm_hdmi_vendor_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range() functions take a drm_connector that
they don't modify. Mark it as const.
Laurent Pinchart [Tue, 26 May 2020 01:14:44 +0000 (04:14 +0300)]
drm: bridge: simple-bridge: Delegate operations to next bridge
Instead of poking into the DT node of the next bridge for its DDC bus
and implementing the .get_modes() and .detect() connector operations
manually, retrieve the next bridge in the chain and delegate these
operations to it.
Laurent Pinchart [Tue, 26 May 2020 01:14:43 +0000 (04:14 +0300)]
drm: bridge: Return NULL on error from drm_bridge_get_edid()
The drm_bridge_get_edid() function is documented to return an error
pointer on error. The underlying .get_edid() operation, however, returns
NULL on error, and so do the drm_get_edid() and drm_do_get_edid()
functions upon which .get_edid() is usually implemented. Make
drm_bridge_get_edid() return NULL on error to be consistent.
Laurent Pinchart [Tue, 26 May 2020 01:14:42 +0000 (04:14 +0300)]
drm: bridge: adv7511: Make connector creation optional
Now that the driver supports all the connector-related bridge
operations, make the connector creation optional. This enables usage of
the adv7511 with the DRM bridge connector helper.
Implement the bridge connector-related .get_edid(), .detect() and
.hpd_notify() operations, and report the related bridge capabilities.
Output status detection is implemented using the same backend as for the
DRM connector, but requires making mode retrieval at detection time
optional as no pointer to the connector is available to the bridge
.detect() operation. The reason for the need to retrieve modes at
detection time is unclear to me, and this may benefit from further
refactoring of hot plug handling code.
Hot plug detection is notified through the bridge HPD notification
framework when the bridge is used without creating a connector, and
falls back to the existing implementation otherwise. CEC handling of
disconnection is handled in the new .hpd_notify() operation in the new
code path.
Nirmoy Das [Mon, 22 Jun 2020 13:45:33 +0000 (15:45 +0200)]
drm/mm/selftests: fix wrong return type casting
Function prepare_igt_frag() and get_insert_time() were casting
signed value to unsigned value before returning error.
So error check in igt_frag() would not work with unsigned
return value from get_insert_time() compared against negative
value.
Addresses-Coverity: ("Unsigned compared against 0, no effect") Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reported-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/370636/
Thomas Zimmermann [Wed, 17 Jun 2020 08:03:39 +0000 (10:03 +0200)]
drm/ast: Upcast from DRM device to ast structure via to_ast_private()
All upcasting from struct drm_device to struct ast_private is now
performed via to_ast_private(). Using struct drm_device.dev_private
is deprecated. The ast variable in ast_crtc_helper_atomic_check() is
unused, so removed it.
Thomas Zimmermann [Wed, 17 Jun 2020 08:03:37 +0000 (10:03 +0200)]
drm/ast: Remove unused code paths for AST 1180
The ast driver contains code paths for AST 1180 chips. The chip is not
supported and the rsp code has never been tested. Simplify the driver by
removing the AST 1180 code.
Ricardo Cañuelo [Wed, 17 Jun 2020 09:46:32 +0000 (11:46 +0200)]
drm/bridge: tfp410: fix de-skew value retrieval from DT
The tfp410 has a data de-skew feature that allows the user to compensate
the skew between IDCK and the pixel data and control signals.
In the driver, the setup and hold times are calculated from the de-skew
value. This retrieves the deskew value from the DT using the proper
datatype and range check as described by the binding (u32 from 0 to 7).
This fix results from a change in the ti,tfp410 DT binding.
This changes how the 'ti,deskew' property is defined. It's now an
unsigned value from 0 to 7 instead of a signed value from -4 to 3.
Until the dtc carries the integer sign through to the yaml output it's
easier to define signed types as unsigned.
Dmitry Osipenko [Wed, 17 Jun 2020 22:27:03 +0000 (01:27 +0300)]
drm/panel-simple: Add missing connector type for some panels
The DRM panel bridge core requires connector type to be set up properly,
otherwise it rejects the panel. The missing connector type problem popped
up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
order to test whether panel's rotation property work properly using
panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses
CLAA070WP03XG display panel.
The NVIDIA Tegra DRM driver recently gained DRM bridges support for the
RGB output and now driver wraps directly-connected panels into DRM bridge.
Hence all panels should have connector type set properly now, otherwise
the panel's wrapping fails.
This patch adds missing connector types for the LVDS panels that are found
on NVIDIA Tegra devices:
Manasi Navare [Fri, 19 Jun 2020 21:23:54 +0000 (02:53 +0530)]
drm/dp: DRM DP helper for reading Ignore MSA from DPCD
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v3:
* Fi the typo in commit message (Manasi)
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619212356.19285-2-bhanuprakash.modem@intel.com
Colin Ian King [Thu, 18 Jun 2020 10:04:00 +0000 (11:04 +0100)]
drm/arm: fix unintentional integer overflow on left shift
Shifting the integer value 1 is evaluated using 32-bit arithmetic
and then used in an expression that expects a long value leads to
a potential integer overflow. Fix this by using the BIT macro to
perform the shift to avoid the overflow.
Addresses-Coverity: ("Unintentional integer overflow") Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200618100400.11464-1-colin.king@canonical.com
Ben Davis [Mon, 1 Jun 2020 16:28:17 +0000 (17:28 +0100)]
drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The
format is similar to P010 with 4:2:0 sub-sampling but has no padding
between components. Instead, luminance and chrominance samples are
grouped into 4s so that each group is packed into an integer number
of bytes:
YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 8.
Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
component, but only 10 bits are used and 6 are padded. 'Q' is chosen
as the first letter to denote 3 plane YUV444, (and is the next letter
along from P which is usually 2 plane).
V2: Updated block_w of NV15 to {4, 2, 0}
V3: Updated commit message to include specific modifier name
Dinghao Liu [Fri, 22 May 2020 13:41:09 +0000 (21:41 +0800)]
drm/panfrost: Fix runtime PM imbalance on error
The caller expects panfrost_job_hw_submit() to increase
runtime PM usage counter. The refcount decrement on the
error branch of WARN_ON() will break the counter balance
and needs to be removed.
Steven Price [Fri, 22 May 2020 15:36:53 +0000 (16:36 +0100)]
drm/panfrost: Fix inbalance of devfreq record_busy/idle()
The calls to panfrost_devfreq_record_busy() and
panfrost_devfreq_record_idle() must be balanced to ensure that the
devfreq utilisation is correctly reported. But there are two cases where
this doesn't work correctly.
In panfrost_job_hw_submit() if pm_runtime_get_sync() fails or the
WARN_ON() fires then no call to panfrost_devfreq_record_busy() is made,
but when the job times out the corresponding _record_idle() call is
still made in panfrost_job_timedout(). Move the call up to ensure that
it always happens.
Secondly panfrost_job_timedout() only makes a single call to
panfrost_devfreq_record_idle() even if it is cleaning up multiple jobs.
Move the call inside the loop to ensure that the number of
_record_idle() calls matches the number of _record_busy() calls.
Douglas Anderson [Fri, 12 Jun 2020 19:30:50 +0000 (12:30 -0700)]
drm/bridge: ti-sn65dsi86: Check the regmap return value when setting a GPIO
The ti_sn_bridge_gpio_set() got the return value of
regmap_update_bits() but didn't check it. The function can't return
an error value, but we should at least print a warning if it didn't
work.
This fixes a compiler warning about setting "ret" but not using it.
Douglas Anderson [Fri, 12 Jun 2020 19:30:47 +0000 (12:30 -0700)]
drm/bridge: ti-sn65dsi86: Don't compile GPIO bits if not CONFIG_OF_GPIO
The kernel test robot noted that if "OF" is defined (which is needed
to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get
compile failures because some of the members that we access in "struct
gpio_chip" are only defined "#if defined(CONFIG_OF_GPIO)".
All the GPIO bits in the driver are all nicely separated out. We'll
guard them with the same "#if defined" that the header has and add a
little stub function if OF_GPIO is not defined.
Paul Kocialkowski [Thu, 16 Apr 2020 14:05:26 +0000 (16:05 +0200)]
drm/rockchip: Add per-pixel alpha support for the PX30 VOP
Compared to its predecessors, the PX30 VOP has a different register layout
for enabling per-pixel alpha. Instead of src_alpha_ctl and dst_alpha_ctl,
there is a single alpha control register. This register takes some fields
from src_alpha_ctl, but with a different layout.
Add support for the required fields to the PX30 VOP window descriptions,
which makes per-pixel-alpha formats behave correctly.
I'm not entirely sure of the history here, but I suspect that in one
of the rebases or when applying the patch I moved the hunk from
drm_gem_shmem_prime_import_sg_table(), where it should be, to
drm_gem_shmem_create_with_handle(), which is totally wrong.
Remedy this.
Thanks for Thomas for the crucial hint in debugging this.
Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing") Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616114723.2363268-1-daniel.vetter@ffwll.ch
Emil Velikov [Sun, 17 May 2020 19:36:54 +0000 (20:36 +0100)]
drm/malidp: convert platform driver to use dev_groups
Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files. So take advantage of that
and do not register "by hand" a sysfs file.
Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200517193655.3895087-2-emil.l.velikov@gmail.com
Emil Velikov [Sat, 30 May 2020 12:46:39 +0000 (13:46 +0100)]
drm: vmwgfx: remove drm_driver::master_set() return type
The function always returns zero (success). Ideally we'll remove it all
together - although that's requires a little more work.
For now, we can drop the return type and simplify the drm core code
surrounding it.
v2: remove redundant assignment (Sam)
Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200530124640.4176323-1-emil.l.velikov@gmail.com
Imre Deak [Wed, 10 Jun 2020 13:47:04 +0000 (16:47 +0300)]
drm/dp_mst: Fix flushing the delayed port/mstb destroy work
Atm, a pending delayed destroy work during module removal will be
canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated
workqueue which will be drained of requeued items as well when
destroying it.
v2:
- Check if wq is NULL before calling destroy_workqueue().
Imre Deak [Sun, 7 Jun 2020 21:25:21 +0000 (00:25 +0300)]
drm/dp_mst: Fix the DDC I2C device registration of an MST port
During the initial MST probing an MST port's I2C device will be
registered using the kdev of the DRM device as a parent. Later after MST
Connection Status Notifications this I2C device will be re-registered
with the kdev of the port's connector. This will also move
inconsistently the I2C device's sysfs entry from the DRM device's sysfs
dir to the connector's dir.
Fix the above by keeping the DRM kdev as the parent of the I2C device.
Ideally the connector's kdev would be used as a parent, similarly to
non-MST connectors, however that needs some more refactoring to ensure
the connector's kdev is already available early enough. So keep the
existing (initial) behavior for now.
Imre Deak [Sun, 7 Jun 2020 21:25:20 +0000 (00:25 +0300)]
drm/dp_mst: Fix the DDC I2C device unregistration of an MST port
The WARN below triggers during the removal of an MST port. The problem
is that the parent device's (the connector's kdev) sysfs directory is
removed recursively when the connector is unregistered (even though the
I2C device holds a reference on the parent device). To fix this set
first the Peer Device Type to none which will remove the I2C device.
Note that atm, inconsistently, the parent of the I2C device is initially set to
the DRM kdev and after a Connection Status Notification the parent may be reset
to be the connector's kdev. This problem is addressed by the next patch.
Imre Deak [Thu, 4 Jun 2020 18:45:00 +0000 (21:45 +0300)]
drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than
~540 usec, leading to MST probe failures.
According to the DP Standard 2.0 section 5.1.4:
- DP sinks should generate short pulses in the 500 usec -> 1 msec range
- DP sources should detect short pulses in the 250 usec -> 2 msec range
According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters
should detect and forward short pulses according to how sources should
detect them as specified in the DP Standard (250 usec -> 2 msec).
Based on the above filtering out short pulses with a duration less than
540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 msec if the source doesn't respond, so
use a 50 msec poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP Standard.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
v2:
- Fix the wait event timeout for the no-poll case.
v3 (Ville):
- Fix the short pulse duration limits in the commit log prescribed by the
DP Standard.
- Add code comment explaining why/how polling is used.
- Factor out a helper to schedule the port's hpd irq handler and move it
to the rest of hotplug handlers.
- Document the new MST callback.
- s/update_hpd_irq_state/poll_hpd_irq/
Thomas Zimmermann [Fri, 5 Jun 2020 13:58:03 +0000 (15:58 +0200)]
drm/mgag200: Use managed device initialization
The mgag200 driver now uses managed functions for DRM devices. The
individual helpers for modesetting and memory managed are already
covered, so only device allocation and initialization is left for
conversion.
Thomas Zimmermann [Fri, 5 Jun 2020 13:58:02 +0000 (15:58 +0200)]
drm/mgag200: Embed instance of struct drm_device in struct mga_device
Following current best practice, the instance of struct drm_device is now
embedded in struct mga_device. The respective field has been renamed from
'dev' to 'base' to reflect the relationship. Conversion from DRM device is
done via upcast. Using dev_private is no longer possible.
The patch also open-codes drm_dev_alloc() and DRM device initialization
is now performed by a call to drm_device_init().
Thomas Zimmermann [Fri, 5 Jun 2020 13:58:01 +0000 (15:58 +0200)]
drm/mgag200: Allocate device structures in mgag200_driver_load()
Instances of struct drm_device and struct mga_device are now allocated
next to each other in mgag200_driver_load(). Yet another preparation
before embedding the DRM device instance in struct mga_device.
Thomas Zimmermann [Fri, 5 Jun 2020 13:58:00 +0000 (15:58 +0200)]
drm/mgag200: Separate device initialization into allocation
Embedding the DRM device instance in struct mga_device will require
changes to device allocation. Moving the device initialization into
its own functions gets it out of the way.
Thomas Zimmermann [Fri, 5 Jun 2020 13:57:59 +0000 (15:57 +0200)]
drm/mgag200: Move device init and cleanup to mgag200_drv.c
Moving the initializer and cleanup functions for device instances
to mgag200_drv.c prepares for the conversion to managed code. No
functional changes are made. Remove mgag200_main.c, which is now
empty.
Thomas Zimmermann [Fri, 5 Jun 2020 13:57:55 +0000 (15:57 +0200)]
drm/mgag200: Merge VRAM setup into MM initialization
The VRAM setup in mgag200_drv.c is part of memory management and
should be done in the same place. Merge the code into the memory
management's init function.
projects / users / willy / linux.git / log