- 08 Apr, 2021 6 commits
-
-
Dan Carpenter authored
The dp->train_set[] for this driver is only two characters, not four so this memsets too much. Fortunately, this ends up corrupting a struct hole and not anything important. Fixes: d76271d2 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/YGLwCBMotnrKZu6P@mwanda
-
Dafna Hirschfeld authored
fix 's/controller/controllers/' in the sentence: Most display controller handle display connectors... Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Oak Zeng authored
If tbo.mem.bus.caching is cached, buffer is intended to be mapped as cached from CPU. Map it with ioremap_cache. This wasn't necessary before as device memory was never mapped as cached from CPU side. It becomes necessary for aldebaran as device memory is mapped cached from CPU. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
Christian Konig <Christian.Koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1614638628-10508-1-git-send-email-Oak.Zeng@amd.comSigned-off-by:
-
Felix Kuehling authored
Move fences that have already signaled should not prevent memory allocations with no_wait_gpu. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
David Stevens authored
Allocate a new private stub fence in drm_syncobj_assign_null_handle, instead of using a static stub fence. When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp obtained when the fence is exported and queried with SYNC_IOC_FILE_INFO should match when the fence's status was changed from the perspective of userspace, which is during the respective ioctl. When a static stub fence started being used in by these ioctls, this behavior changed. Instead, the timestamp returned by SYNC_IOC_FILE_INFO became the first time anything used the static stub fence, which has no meaning to userspace. Signed-off-by:
David Stevens <stevensd@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210408095428.3983055-1-stevensd@google.comReviewed-by:
-
Zhang Jianhua authored
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~~~~~~~~~~~~~~~~~~~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~~~~~~~~~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~ GPIOF_INIT_HIGH Signed-off-by:Zhang Jianhua <zhangjianhua18@huawei.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
- 01 Apr, 2021 7 commits
-
-
Ville Syrjälä authored
drm_vblank_restore() exists because certain power saving states can clobber the hardware frame counter. The way it does this is by guesstimating how many frames were missed purely based on the difference between the last stored timestamp vs. a newly sampled timestamp. If we should call this function before a full frame has elapsed since we sampled the last timestamp we would end up with a possibly slightly different timestamp value for the same frame. Currently we will happily overwrite the already stored timestamp for the frame with the new value. This could cause userspace to observe two different timestamps for the same frame (and the timestamp could even go backwards depending on how much error we introduce when correcting the timestamp based on the scanout position). To avoid that let's not update the stored timestamp at all, and instead we just fix up the last recorded hw vblank counter value such that the already stored timestamp/seq number will match. Thus the next time a vblank irq happens it will calculate the correct diff between the current and stored hw vblank counter values. Sidenote: Another possible idea that came to mind would be to do this correction only if the power really was removed since the last time we sampled the hw frame counter. But to do that we would need a robust way to detect when it has occurred. Some possibilities could involve some kind of hardare power well transition counter, or potentially we could store a magic value in a scratch register that lives in the same power well. But I'm not sure either of those exist, so would need an actual investigation to find out. All of that is very hardware specific of course, so would have to be done in the driver code. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218160305.16711-1-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
If the user specifies zero width/height cmdline mode i915 will blow up as the fbdev path will bypass the regular fb sanity check that would otherwise have refused to create a framebuffer with zero width/height. The reason I thought to try this is so that I can force a specific depth for fbdev without actually having to hardcode the mode on the kernel cmdline. Eg. if I pass video=0x0-8 I will get an 8bpp framebuffer at my monitor's native resolution. Signed-off-by:
-
Julian Braha authored
When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, without depending on or selecting DRM_KMS_HELPER, despite that config option depending on DRM_KMS_HELPER. Signed-off-by:
Julian Braha <julianbraha@gmail.com> Reviewed-by:
-
Carsten Haitzler authored
Another issue found by KASAN. The bit finding is buried inside the dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that calls the bit stuff. These bit functions want an unsigned long pointer as input and just dumbly casting leads to out-of-bounds accesses. This fixes that. Signed-off-by:
Carsten Haitzler <carsten.haitzler@arm.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
James Qian Wang <james.qian.wang@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204131102.68658-1-carsten.haitzler@foss.arm.com
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
-
Hsin-Yi Wang authored
When suspending the driver, anx7625_power_standby() will be called to turn off reset-gpios and enable-gpios. However, power supplies are not disabled. To save power, the driver can get the power supply regulators and turn off them in anx7625_power_standby(). Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Hsin-Yi Wang authored
anx7625 requires 3 power supply regulators. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
- 31 Mar, 2021 8 commits
-
-
Jani Nikula authored
Avoid any confusion with High Dynamic Range. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce083bd2789c7e22a91710726162287db88e3f6c.1617024940.git.jani.nikula@intel.com
-
Jani Nikula authored
The DisplayID specifications explicitly call out 0 as a valid payload length for data blocks. The mere presence of a data block, or the information coded in the block specific data (bits 7:3 in offset 1), may be enough to convey the necessary information. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. Remove excessive debug logging while at it, no other functional changes. The old displayid iterator becomes unused; remove it as well as make drm_find_displayid_extension() static. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Iterating DisplayID blocks across sections (in EDID extensions) is unnecessarily complicated for the caller. Implement DisplayID iterators to go through all blocks in all sections. Usage example: const struct displayid_block *block; struct displayid_iter iter; displayid_iter_edid_begin(edid, &iter); displayid_iter_for_each(block, &iter) { /* operate on block */ } displayid_iter_end(&iter); When DisplayID is stored in EDID extensions, the DisplayID sections map to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID as an EDID Extension. This is implemented here. When DisplayID is stored in its dedicated DDC device 0xA4, according to VESA E-DDC v1.3, different rules apply for the structure. This is not implemented here, as we don't currently use it, but the idea is you'd have a different call for beginning the iteration, for example simply: displayid_iter_begin(displayid, &iter); instead of displayid_iter_edid_begin(), and everything else would be hidden away in the iterator functions. v2: - sizeof(struct displayid_block) -> sizeof(*block) (Ville) - remove __ prefix from displayid_iter_block Reviewed-by: -
Jani Nikula authored
We'll be adding more DisplayID specific functions going forward, so start off by splitting out a few functions to a separate file. We don't bother with exporting the functions; at least for now they should be needed solely within drm.ko. No functional changes. Reviewed-by:
-
Jani Nikula authored
If there's no need to change it, it should be const. There's more to be done, but start off with changes that make follow-up work easier. No functional changes. Reviewed-by:
-
- 29 Mar, 2021 4 commits
-
-
Paul Cercueil authored
Since the encoders have been devm-allocated, they will be freed way before drm_mode_config_cleanup() is called. To avoid use-after-free conditions, we then must ensure that drm_encoder_cleanup() is called before the encoders are freed. v2: Use the new __drmm_simple_encoder_alloc() function v3: Use the new drmm_plain_simple_encoder_alloc() macro v4: Use drmm_plain_encoder_alloc() macro Fixes: c369cb27 ("drm/ingenic: Support multiple panels/bridges") Cc: <stable@vger.kernel.org> # 5.8+ Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-4-paul@crapouillou.net
-
Paul Cercueil authored
This performs the same operation as drmm_encoder_alloc(), but only allocates and returns a struct drm_encoder instance. v4: Rename macro drmm_plain_encoder_alloc() and move to <drm/drm_encoder.h>. Since it's not "simple" anymore it will now take funcs/name arguments as well. Signed-off-by: -
Paul Cercueil authored
If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc054 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable@vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Christian König authored
The shrinker based approach still has some flaws. Especially that we need temporary pages to free up the pages allocated to the driver is problematic in a shrinker. Signed-off-by:
-
- 26 Mar, 2021 8 commits
-
-
Eryk Brol authored
[why] MST topology print was missing fec logging and pdt printed as an int wasn't clear. vcpi and payload info was printed as an arbitrary series of ints which requires user to know the ordering of the prints, making the logs difficult to use. [how] -add fec logging -add pdt parsing into strings -format vcpi and payload info into tables with headings -clean up topology prints Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Eryk Brol <eryk.brol@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325180614.37060-1-eryk.brol@amd.com
-
Christian König authored
The BO might be NULL in this function, use the bdev directly. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Adrien Grassein authored
Lontium LT8912B is a DSI to HDMI bridge. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by:
-
Adrien Grassein authored
Lontium LT8912B is a DSI to HDMI bridge. Signed-off-by:
-
Dafna Hirschfeld authored
Fix the following typos: 1. When mentioning a list of functions, the function drm_atomic_helper_disable_plane is mentioned twice. 2. drop the word 'afterwards': s/afterwards after that/after that/' 3. drop extra 'the': s/but do not the support the full/but do not support the full/ Signed-off-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Wan Jiabing authored
struct dss_device has been declared. Remove the duplicate. And sort these forward declarations alphabetically. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325111028.864628-1-wanjiabing@vivo.com
-
Yang Li authored
fixed the following coccicheck: ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Fixes: 4c1b935f ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by:
-
Arnd Bergmann authored
An old patch added a 'return' statement after each BUG() in this driver, which was necessary at the time, but has become redundant after the BUG() definition was updated to handle this properly. gcc-11 now warns about one such instance, where the 'return' statement was incorrectly indented: drivers/gpu/drm/omapdrm/dss/dispc.c: In function ‘pixinc’: drivers/gpu/drm/omapdrm/dss/dispc.c:2093:9: error: this ‘else’ clause does not guard... [-Werror=misleading-indentation] 2093 | else | ^~~~ drivers/gpu/drm/omapdrm/dss/dispc.c:2095:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’ 2095 | return 0; | ^~~~~~ Address this by removing the return again and changing the BUG() to be unconditional to make this more intuitive. Fixes: c6eee968 ("OMAPDSS: remove compiler warnings when CONFIG_BUG=n") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 25 Mar, 2021 6 commits
-
-
Jagan Teki authored
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone. It has a flexible configuration of MIPI DSI signal input and produce RGB565, RGB666, RGB888 output format. Add bridge driver for it. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Jagan Teki authored
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone. It has a flexible configuration of MIPI DSI signal input and produces RGB565, RGB666, RGB888 output format. Add dt-bingings for it. Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warning: drivers/gpu/drm/bridge/lontium-lt9611uxc.c:858:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
-
Robert Foss authored
4k requires two dsi pipes, so don't report MODE_OK when only a single pipe is configured. But rather report MODE_PANEL to signal that requirements of the panel are not being met. Reported-by:
Peter Collingbourne <pcc@google.com> Suggested-by:
John Stultz <john.stultz@linaro.org> Tested-by:
Anibal Limon <anibal.limon@linaro.org> Tested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Vinod Koul <vkoul@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org
-
Robert Foss authored
Add myself as co-maintainer of DRM Bridge Drivers. Repository commit access has already been granted. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Jernej Škrabec <jernej.skrabec@siol.net> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210325145154.1433060-1-robert.foss@linaro.org
-
Dmitry Vyukov authored
vkms_vblank_simulate() uses WARN_ON for timing-dependent condition (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used to denote kernel bugs. Use pr_warn() instead. Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Reported-by: syzbot+4fc21a003c8332eb0bdd@syzkaller.appspotmail.com Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Acked-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
-
- 24 Mar, 2021 1 commit
-
-
Christian König authored
Instead of having a global lock for potentially less contention. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/424010/
-
