aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-04-08drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()Lyude Paul1-8/+12
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order to retain some of the previous debugging output behavior we had. However, as I was preparing to do this I noticed that the current rate limited macros we have are kind of bogus. It looks like when I wrote these, I didn't notice that we'd always be calling __ratelimit() even if the debugging message we'd be printing would normally be filtered out due to the relevant DRM debugging category being disabled. So, let's fix this by making sure to check drm_debug_enabled() in our ratelimited macros before calling __ratelimit(), and start using drm_dev_printk() in order to print debugging messages since that will save us from doing a redundant drm_debug_enabled() check. And while we're at it, let's move the code for this into another macro that we can reuse for defining new ratelimited DRM debug macros more easily. v2: * Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED() Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Robert Foss <robert.foss@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-8-lyude@redhat.com
2021-04-08drm/tegra: Don't register DP AUX channels before connectorsLyude Paul1-5/+6
As pointed out by the documentation for drm_dp_aux_register(), drm_dp_aux_init() should be used in situations where the AUX channel for a display driver can potentially be registered before it's respective DRM driver. This is the case with Tegra, since the DP aux channel exists as a platform device instead of being a grandchild of the DRM device. Since we're about to add a backpointer to a DP AUX channel's respective DRM device, let's fix this so that we don't potentially allow userspace to use the AUX channel before we've associated it with it's DRM connector. Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-3-lyude@redhat.com
2021-04-08drm/dp: Fixup kernel docs for struct drm_dp_auxLyude Paul1-22/+22
* Make sure that struct members are referred to using @, otherwise they won't be formatted as such * Make sure to refer to other struct types using & so they link back to each struct's definition * Make sure to precede constant values with % so they're formatted correctly Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-2-lyude@redhat.com
2021-04-08drm/sched: add missing member documentationChristian König1-0/+1
Just fix a warning. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: f2f12eb9c32b ("drm/scheduler: provide scheduler score externally") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210401125213.138855-1-christian.koenig@amd.com
2021-04-08gma500: Use DEFINE_SPINLOCK() for spinlockGuobin Huang1-2/+1
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Guobin Huang <huangguobin4@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1617710114-48071-1-git-send-email-huangguobin4@huawei.com
2021-04-08drm/drm_internal.h: Remove repeated struct declarationWan Jiabing1-1/+0
struct drm_gem_object is declared twice. One is declared at 40th line. The blew one is not needed. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210401081704.1000863-1-wanjiabing@vivo.com
2021-04-08drm: xlnx: zynqmp: fix a memset in zynqmp_dp_train()Dan Carpenter1-1/+1
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: d76271d22694 ("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
2021-04-08drm/bridge: fix typo in KconfigDafna Hirschfeld1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210326103216.7918-2-dafna.hirschfeld@collabora.com
2021-04-08drm/ttm: ioremap buffer according to TTM mem caching settingOak Zeng1-0/+14
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.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-04-08drm/ttm: Ignore signaled move fencesFelix Kuehling1-1/+2
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: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210227034524.21763-1-Felix.Kuehling@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-04-08drm/syncobj: use newly allocated stub fencesDavid Stevens3-7/+46
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.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-04-08drm/bridge: lt8912b: Add header file <linux/gpio/consumer.h>Zhang Jianhua1-0/+1
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: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210408093822.207917-1-zhangjianhua18@huawei.com
2021-04-01drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()Ville Syrjälä1-1/+2
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.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-01drm: Refuse to create zero width/height cmdline modesVille Syrjälä1-0/+3
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607162611.23514-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-01drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPERJulian Braha1-0/+1
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: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222215502.24487-1-julianbraha@gmail.com
2021-04-01drm/komeda: Fix bit check to import to value of proper typeCarsten Haitzler3-16/+22
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
2021-04-01drm/komeda: Convert sysfs sprintf/snprintf family to sysfs_emitTian Tao1-3/+3
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: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1617067518-31091-1-git-send-email-tiantao6@hisilicon.com
2021-04-01drm/bridge: anx7625: disable regulators when power offHsin-Yi Wang2-0/+35
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: Robert Foss <robert.foss@linaro.org> Reviewed-by: Xin Ji <xji@analogixsemi.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-2-hsinyi@chromium.org
2021-04-01dt-bindings: drm/bridge: anx7625: Add power suppliesHsin-Yi Wang1-0/+15
anx7625 requires 3 power supply regulators. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-1-hsinyi@chromium.org
2021-03-31drm/displayid: rename displayid_hdr to displayid_headerJani Nikula2-6/+6
Avoid any confusion with High Dynamic Range. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce083bd2789c7e22a91710726162287db88e3f6c.1617024940.git.jani.nikula@intel.com
2021-03-31drm/displayid: allow data blocks with 0 payload lengthJani Nikula1-2/+1
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d562dff99ba7c92accb654a99b433bed471e8507.1617024940.git.jani.nikula@intel.com
2021-03-31drm/edid: use the new displayid iterator for tile infoJani Nikula3-45/+10
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fa4b5c790b5bdd82063545a6f209f8e9d78a63a7.1617024940.git.jani.nikula@intel.com
2021-03-31drm/edid: use the new displayid iterator for finding CEA extensionJani Nikula1-16/+9
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e50f876cecbfee369da887ad19350eee0d89b87f.1617024940.git.jani.nikula@intel.com
2021-03-31drm/edid: use the new displayid iterator for detailed modesJani Nikula1-17/+6
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f6c69c545c553c4a616887540660a4b8aecf0f7f.1617024940.git.jani.nikula@intel.com
2021-03-31drm/displayid: add new displayid section/block iteratorsJani Nikula2-0/+92
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/da3dead1752ab16c061f7bd248ac1a4268f7fefb.1617024940.git.jani.nikula@intel.com
2021-03-31drm/displayid: add separate drm_displayid.cJani Nikula5-57/+73
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/07942d5011891b8e8f77245c78b34f4af97a9315.1617024940.git.jani.nikula@intel.com
2021-03-31drm/edid: make a number of functions, parameters and variables constJani Nikula2-31/+31
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/41722f92ef81cd6adf65f936fcc5301418e1f94b.1617024940.git.jani.nikula@intel.com
2021-03-29drm/ingenic: Register devm action to cleanup encodersPaul Cercueil1-10/+7
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: c369cb27c267 ("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
2021-03-29drm/encoder: Add macro drmm_plain_encoder_alloc()Paul Cercueil1-0/+18
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 <paul@crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-3-paul@crapouillou.net
2021-03-29drm: bridge/panel: Cleanup connector on bridge detachPaul Cercueil1-0/+12
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: 13dfc0540a57 ("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: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@crapouillou.net
2021-03-29drm/ttm: switch back to static allocation limits for nowChristian König3-76/+53
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: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210324134845.2338-1-christian.koenig@amd.com
2021-03-26drm/mst: Enhance MST topology loggingEryk Brol1-11/+48
[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: 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
2021-03-26drm/ttm: fix invalid NULL derefChristian König1-3/+3
The BO might be NULL in this function, use the bdev directly. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Colin Ian King <colin.king@canonical.com> Fixes: a1f091f8ef2b ("drm/ttm: switch to per device LRU lock") Link: https://patchwork.freedesktop.org/patch/msgid/20210325152740.82633-1-christian.koenig@amd.com
2021-03-26drm/bridge: Introduce LT8912B DSI to HDMI bridgeAdrien Grassein4-0/+781
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: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326121955.1266230-3-adrien.grassein@gmail.com
2021-03-26dt-bindings: display: bridge: Add documentation for LT8912BAdrien Grassein2-0/+107
Lontium LT8912B is a DSI to HDMI bridge. Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326121955.1266230-2-adrien.grassein@gmail.com
2021-03-26drm: Fix 3 typos in the inline docDafna Hirschfeld2-9/+8
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: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210326103216.7918-1-dafna.hirschfeld@collabora.com
2021-03-26drm/omap: Remove duplicate declarationWan Jiabing1-5/+4
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325111028.864628-1-wanjiabing@vivo.com
2021-03-26drm/omap: dsi: Add missing IRQF_ONESHOTYang Li1-1/+2
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: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1616492093-68237-1-git-send-email-yang.lee@linux.alibaba.com
2021-03-26drm/omap: fix misleading indentation in pixinc()Arnd Bergmann1-3/+2
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: c6eee968d40d ("OMAPDSS: remove compiler warnings when CONFIG_BUG=n") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322164203.827324-1-arnd@kernel.org
2021-03-25drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridgeJagan Teki4-0/+308
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: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210322103328.66442-2-jagan@amarulasolutions.com
2021-03-25dt-bindings: display: bridge: Add Chipone ICN6211 bindingsJagan Teki2-0/+104
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: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210322103328.66442-1-jagan@amarulasolutions.com
2021-03-25drm: bridge: convert sysfs sprintf/snprintf family to sysfs_emitJiapeng Chong1-1/+1
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 <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1612689000-64577-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-03-25drm/bridge: lt9611: Fix handling of 4k panelsRobert Foss1-1/+7
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: Peter Collingbourne <pcc@google.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Anibal Limon <anibal.limon@linaro.org> Tested-by: Peter Collingbourne <pcc@google.com> Reviewed-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
2021-03-25MAINTAINERS: Update Maintainers of DRM Bridge DriversRobert Foss1-0/+1
Add myself as co-maintainer of DRM Bridge Drivers. Repository commit access has already been granted. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338 Signed-off-by: Robert Foss <robert.foss@linaro.org> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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
2021-03-25drm/vkms: fix misuse of WARN_ONDmitry Vyukov1-1/+2
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: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320132840.1315853-1-dvyukov@google.com
2021-03-24drm/ttm: switch to per device LRU lockChristian König8-56/+43
Instead of having a global lock for potentially less contention. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-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/
2021-03-24drm/ttm: remove swap LRU v3Christian König7-53/+48
Instead evict round robin from each devices SYSTEM and TT domain. v2: reorder num_pages access reported by Dan's script v3: fix rebase fallout, num_pages should be 32bit Signed-off-by: Christian König <christian.koenig@amd.com> Tested-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/424009/
2021-03-24drm/ttm: move swapout logic around v3Christian König7-45/+53
Move the iteration of the global lru into the new function ttm_global_swapout() and use that instead in drivers. v2: consistently return int v3: fix build fail Signed-off-by: Christian König <christian.koenig@amd.com> Tested-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/424008/
2021-03-24drm/tilcdc: fix pixel clock setting warning messageDario Binacchi1-5/+5
The warning message did not printed the LCD pixel clock rate but the LCD clock divisor input rate. As a consequence, the required and real pixel clock rates are now passed to the tilcdc_pclk_diff(). Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20210322213337.26667-4-dariobin@libero.it
2021-03-24drm/tilcdc: fix LCD pixel clock settingDario Binacchi1-2/+3
The tilcdc_pclk_diff() compares the requested pixel clock rate to the real one, so passing it clk_rate instead of clk_rate / clkdiv caused it to fail even if the clk_rate was properly set. Adding the real_pclk_rate variable makes the code more readable. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20210322213337.26667-3-dariobin@libero.it
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.