- 14 Oct, 2019 6 commits
-
-
Robert Chiras authored
Currently, the MXSFB DRM driver only supports a panel. But, its output display signal can also be redirected to another encoder, like a DSI controller. In this case, that DSI controller may act like a drm_bridge. In order support this use-case too, this patch adds support for drm_bridge in mxsfb. Signed-off-by:
Robert Chiras <robert.chiras@nxp.com> Tested-by:
Guido Günther <agx@sigxcpu.org> Signed-off-by:
Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1567078215-31601-2-git-send-email-robert.chiras@nxp.com
-
Lucas De Marchi authored
Fixes: 83fa9842 ("drm/dp-mst: Drop connection_mutex check") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191011010907.103309-8-lucas.demarchi@intel.com
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/hdmi4_core.c: In function hdmi4_audio_config: drivers/gpu/drm/omapdrm/dss/hdmi4_core.c:689:6: warning: variable err set but not used [-Wunused-but-set-variable] It is not used since commit f5bab222 ("OMAPDSS: HDMI: Add OMAP5 HDMI support") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-5-git-send-email-zhengbin13@huawei.com
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/hdmi5_core.c: In function hdmi5_audio_config: drivers/gpu/drm/omapdrm/dss/hdmi5_core.c:812:6: warning: variable err set but not used [-Wunused-but-set-variable] It is not used since commit f5bab222 ("OMAPDSS: HDMI: Add OMAP5 HDMI support") Reported-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/dsi.c: In function dsi_proto_timings: drivers/gpu/drm/omapdrm/dss/dsi.c:3562:46: warning: variable tclk_trail set but not used [-Wunused-but-set-variable] It is not used since commit 9960aa7c ("drm/omap: move omapdss & displays under omapdrm") Reported-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/omap_fb.c: In function omap_framebuffer_update_scanout: drivers/gpu/drm/omapdrm/omap_fb.c:130:16: warning: variable plane set but not used [-Wunused-but-set-variable] It is not used since commit 2ecceeb5 ("drm/omap: Move buffer pitch/offset to drm_framebuffer") Reported-by:
-
- 13 Oct, 2019 4 commits
-
-
Nickey Yang authored
Some VOP's (such as px30) dclk_pol bit is at the last. So it is necessary to distinguish dclk_pol and pin_pol. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by:
Sandy Huang <hjc@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191010034452.20260-2-nickey.yang@rock-chips.com
-
Ben Dooks authored
The rockchip_gem_alloc_object function is not exported so make it static to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_drm_gem.c:297:28: warning: symbol 'rockchip_gem_alloc_object' was not declared. Should it be static? Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by:
-
Ben Dooks authored
Include rockchip_drm_drv.h for definition of vop_platform_driver to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_vop_reg.c:982:24: warning: symbol 'vop_platform_driver' was not declared. Should it be static? Signed-off-by:
-
Markus Elfring authored
Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
- 11 Oct, 2019 11 commits
-
-
Ville Syrjälä authored
@swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010131159.17346-3-ville.syrjala@linux.intel.comReviewed-by:
Boris Brezillon <boris.brezillon@collabora.com>
-
Tomi Valkeinen authored
On SoCs with DMM/TILER, we have two ways to allocate buffers: normal dma_alloc or via DMM (which basically functions as an IOMMU). DMM can map 128MB at a time, and we only map the DMM buffers when they are used (i.e. not at alloc time). If DMM is present, omapdrm always uses DMM. There are use cases that require lots of big buffers that are being used at the same time by different IPs. At the moment the userspace has a hard maximum of 128MB. This patch adds three new flags that can be used by the userspace to solve the situation: OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory. This can be used to avoid DMM if the userspace knows it needs more than 128M of memory at the same time. OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not much use for this flag at the moment, as on platforms with DMM it is used by default, but it's here for completeness. OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep it pinned. This can be used to 1) get an error at alloc time if DMM space is full, and 2) get rid of the constant pin/unpin operations which may have some effect on performance. If none of the flags are given, the behavior is the same as currently. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-9-jjhiblot@ti.com
-
Tomi Valkeinen authored
Add a helper function omap_gem_validate_flags() which validates the omap_bo flags passed from the userspace. Also drop the dev_err() message, as the userspace can cause that at will. Signed-off-by:
-
Tomi Valkeinen authored
omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some reason. It's not clear what the original purpose of OMAP_BO_SCANOUT is, but presuming it means "scanout buffer, something that can be consumed by DSS", this patch cleans up the above issues. Signed-off-by:
-
Tomi Valkeinen authored
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK instead. Signed-off-by:
-
Tomi Valkeinen authored
Reorder OMAP_BO flags and improve the comments. Signed-off-by:
-
Tomi Valkeinen authored
Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the caller does not need the dma_addr. Signed-off-by:
-
Tomi Valkeinen authored
Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that expects the caller to hold the omap_obj lock. Signed-off-by:
-
Jean-Jacques Hiblot authored
This would give us a WARN_ON() if the pin/unpin calls are unbalanced. Proposed-by:
-
Ezequiel Garcia authored
Add an optional CRTC gamma LUT support, and enable it on RK3288. This is currently enabled via a separate address resource, which needs to be specified in the devicetree. The address resource is required because on some SoCs, such as RK3288, the LUT address is after the MMU address, and the latter is supported by a different driver. This prevents the DRM driver from requesting an entire register space. The current implementation works for RGB 10-bit tables, as that is what seems to work on RK3288. Tested-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191010194351.17940-3-ezequiel@collabora.com
-
Ezequiel Garcia authored
Add the register specifier description for an optional gamma LUT address. Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Rob Herring <robh@kernel.org> Tested-by:
-
- 10 Oct, 2019 11 commits
-
-
Ben Dooks authored
The drm_sched_fence_ops_{scheduled,finished} are not exported from the file so make them static to avoid the following warnings from sparse: drivers/gpu/drm/scheduler/sched_fence.c:131:28: warning: symbol 'drm_sched_fence_ops_scheduled' was not declared. Should it be static? drivers/gpu/drm/scheduler/sched_fence.c:137:28: warning: symbol 'drm_sched_fence_ops_finished' was not declared. Should it be static? Reviewed-by:Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Maarten Lankhorst authored
The rectangles are usually clipped, but it can be useful to have them unclipped, for example for cursor planes. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Change cursor plane to hardware performing clipping. (Ville) Fix dst description that went missing.] Reviewed-by:
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Daniel Vetter authored
Private atomic objects have grown their own locking with commit b962a120 Author: Rob Clark <robdclark@gmail.com> Date: Mon Oct 22 14:31:22 2018 +0200 drm/atomic: integrate modeset lock with private objects which means we're no longer relying on connection_mutex for mst state locking needs. Cc: Lyude Paul <lyude@redhat.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009224113.5432-1-daniel.vetter@ffwll.ch
-
Jonas Karlman authored
This patch enables Dynamic Range and Mastering InfoFrame on H6. Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/HE1PR06MB40119DBC0DAE7BA251DF7074AC9B0@HE1PR06MB4011.eurprd06.prod.outlook.com
-
Jonas Karlman authored
This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and G12A. Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Jonas Karlman authored
This patch enables Dynamic Range and Mastering InfoFrame on RK3328 and RK3399. Cc: Sandy Huang <hjc@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Jonas Karlman authored
Add support for configuring Dynamic Range and Mastering InfoFrame from the hdr_output_metadata connector property. This patch adds a use_drm_infoframe flag to dw_hdmi_plat_data that platform drivers use to signal when Dynamic Range and Mastering infoframes is supported. This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version, and only GXL support DRM InfoFrame. These changes were based on work done by Zheng Yang <zhengyang@rock-chips.com> to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2] [1] https://github.com/rockchip-linux/kernel/tree/develop-4.4 [2] https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5 Cc: Zheng Yang <zhengyang@rock-chips.com> Signed-off-by:
-
Brian Masney authored
According to the downstream Android sources, the anx7808 variants use address 0x78 for TX_P0 and the anx781x variants use address 0x70. Since the datasheets aren't available for these devices, and we only have the downstream kernel sources to look at, let's assume that these addresses are fixed based on the model, and pass the i2c addresses to the driver via the data pointer in the driver's of_match_table. Signed-off-by:
Brian Masney <masneyb@onstation.org> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Ronald Tschalär authored
commit d6abe6df ("drm/bridge: sil_sii8620: do not have a dependency of RC_CORE") changed the driver to select both RC_CORE and INPUT. However, this causes problems with other drivers, in particular an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate commit): drivers/clk/Kconfig:9:error: recursive dependency detected! drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by MFD_INTEL_LPSS drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI drivers/input/keyboard/Kconfig:73: symbol KEYBOARD_APPLESPI depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 drivers/gpu/drm/bridge/Kconfig:83: symbol DRM_SIL_SII8620 depends on DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK According to the docs and general consensus, select should only be used for non user-visible symbols, but both RC_CORE and INPUT are user-visible. Furthermore almost all other references to INPUT throughout the kernel config are depends, not selects. For this reason the first part of this change reverts the commit. In order to address the original reason for the commit, namely that not all boards use the remote controller functionality and hence should not need have to deal with RC_CORE, the second part of this change now makes the remote control support in the driver optional and contingent on RC_CORE being defined. And with this the hard dependency on INPUT also goes away as that is only needed if RC_CORE is defined (which in turn already depends on INPUT). CC: Inki Dae <inki.dae@samsung.com> CC: Andrzej Hajda <a.hajda@samsung.com> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Ronald Tschalär <ronald@innovation.ch> Reviewed-by:
-
Wolfram Sang authored
Move from the deprecated i2c_new_dummy() to devm_i2c_new_dummy_device(). We now get an ERRPTR which we use in error handling and we can skip removal of the created devices. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
- 09 Oct, 2019 8 commits
-
-
Sean Paul authored
Fixes the following warning: ../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments found Fixes: 9ef8a9dc ("drm: Extract drm_atomic_state_helper.[hc]") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> 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:
-
Douglas Anderson authored
I'm embarassed to say that even though I've touched vop_crtc_mode_fixup() twice and I swear I tested it, there's still a stupid glaring bug in it. Specifically, on veyron_minnie (with all the latest display timings) we want to be setting our pixel clock to 66,666,666.67 Hz and we tell userspace that's what we set, but we're actually choosing 66,000,000 Hz. This is confirmed by looking at the clock tree. The problem is that in drm_display_mode_from_videomode() we convert from Hz to kHz with: dmode->clock = vm->pixelclock / 1000; ...and drm_display_mode_from_videomode() is called from panel-simple when we have an "override_mode" like we do on veyron_minnie. See commit 123643e5 ("ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings"). ...so when the device tree specifies a clock of 66666667 for the panel then DRM translates that to 66666000. The clock framework will always pick a clock that is _lower_ than the one requested, so it will refuse to pick 66666667 and we'll end up at 66000000. While we could try to fix drm_display_mode_from_videomode() to round to the nearest kHz and it would fix our problem, it wouldn't help if the clock we actually needed was 60,000,001 Hz. We could alternatively have DRM always round up, but maybe this would break someone else who already baked in the assumption that DRM rounds down. Specifically note that clock drivers are not consistent about whether they round up or round down when you call clk_set_rate(). We know how Rockchip's clock driver works, but (for instance) you can see that on most Qualcomm clocks the default is clk_rcg2_ops which rounds up. Let's solve this by just adding 999 Hz before calling clk_round_rate(). This should be safe and work everywhere. As discussed in more detail in comments in the commit, Rockchip's PLLs are configured in a way that there shouldn't be another PLL setting that is only a few kHz off so we won't get mixed up. NOTE: if this is picked to stable, it's probably easiest to first pick commit 527e4ca3 ("drm/rockchip: Base adjustments of the mode based on prev adjustments") which shouldn't hurt in stable. Fixes: b59b8de3 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by:
-
Steven Price authored
panfrost_core_dump() has never existed in mainline, so remove it and add a TODO entry that core dump support is currently lacking. Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Steven Price authored
Panfrost uses multiple schedulers (one for each slot, so 2 in reality), and on a timeout has to stop all the schedulers to safely perform a reset. However more than one scheduler can trigger a timeout at the same time. This race condition results in jobs being freed while they are still in use. When stopping other slots use cancel_delayed_work_sync() to ensure that any timeout started for that slot has completed. Also use mutex_trylock() to obtain reset_lock. This means that only one thread attempts the reset, the other threads will simply complete without doing anything (the first thread will wait for this in the call to cancel_delayed_work_sync()). While we're here and since the function is already dependent on sched_job not being NULL, let's remove the unnecessary checks. Fixes: aa202367 ("drm/panfrost: Prevent concurrent resets") Tested-by:
-
Steven Price authored
devm_regulator_get() is used to populate pfdev->regulator which ensures that this cannot be NULL (a dummy regulator will be returned if necessary). So remove the check in panfrost_devfreq_target(). Signed-off-by:
-
Simon Ser authored
Currently the property docs don't specify whether it's okay for two planes to have the same zpos value and what user-space should expect in this case. The unspoken, legacy rule used in the past was to make user-space figure out the zpos from object IDs. However some drivers break this rule, that's why the ordering is documented as unspecified in case the zpos property is missing. User-space should rely on the zpos property only. There are some cases in which user-space might read identical zpos values for different planes. For instance, in case the property is mutable, user-space might set two planes' zpos to the same value. This is necessary to support user-space using the legacy DRM API where atomic commits are not possible: user-space needs to update the planes' zpos one by one. Because of this, user-space should handle multiple planes with the same zpos. While at it, remove the assumption that zpos is only for overlay planes. Additionally, update the drm_plane_state.zpos docs to clarify that zpos disambiguation via plane object IDs is a recommendation for drivers, not something user-space can rely on. In other words, when user-space sets the same zpos on two planes, drivers should rely on the plane object ID. v2: clarify drm_plane_state.zpos docs (Daniel) v3: zpos is for all planes (Marius, Daniel) v4: completely reword the drm_plane_state.zpos docs to make it clear the recommendation to use plane IDs is for drivers in case user-space uses duplicate zpos values (Pekka) v5: reword commit message (Pekka, James) v6: remove mention of Arm GPUs having planes which can't overlap, because this isn't uAPI yet (Daniel) Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Pekka Paalanen <ppaalanen@gmail.com> Cc: Marius Vlad <marius.vlad@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: James Qian Wang <james.qian.wang@arm.com> Signed-off-by:
-
zhong jiang authored
I hit the following error when compile the kernel. drivers/gpu/drm/vkms/vkms_composer.o: In function `vkms_composer_worker': vkms_composer.c:(.text+0x5e4): undefined reference to `crc32_le' make: *** [vmlinux] Error 1 Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Lee Shawn C authored
Refer to EDID 1.3 spec, display FEATURE (byte 18h) bit #0 said "If this bit is set to 1, the display supports timings based on the GTF standard using default GTF parameter values". And EDID 1.4 spec shows "If bit 0 is set to 0, then the display is noncontinuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in BASE EDID and certain EXTENSION Blocks. When display feature did not support CVT or GFT2 and monitor's EDID version greater than or equal to "1.2". DRM driver would select GTF as default for standard timing calculation. It may generated some video timing that can't display properly by external monitor. For example. When driver retrieved "0xD1 0xFC" (FHD, 120Hz) and "0xD1 0xE8" (FHD, 100Hz) from "Standard Timings". GTF formula would generate video timing like below. It already over monitor's spec to cause black screen issue. "1920x1080" 120 368881 1920 2072 2288 2656 1080 1081 1084 1157 0x0 0x6 "1920x1080" 100 301992 1920 2072 2280 2640 1080 1081 1084 1144 0x0 0x6 v2: Just confirm GTF flag and omit the revision check. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
-
