- 14 Dec, 2020 2 commits
-
-
Christian König authored
Based on an idea from Dave, but cleaned up a bit. We had multiple fields for essentially the same thing. Now bo->base.size is the original size of the BO in arbitrary units, usually bytes. bo->mem.num_pages is the size in number of pages in the resource domain of bo->mem.mem_type. v2: use the GEM object size instead of the BO size v3: fix printks in some places Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> (v1) Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/406831/
-
Tian Tao authored
it's not necessary to assign a value of 0 to ret here, because if the previous functions were executed correctly, ret would be 0. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/1607653037-37785-1-git-send-email-tiantao6@hisilicon.com
-
- 11 Dec, 2020 4 commits
-
-
Daniel Vetter authored
There's a confusion between the preferred_depth uapi and the generic fbdev helpers. Former wants depth, latter wants bpp, and for XRGB8888 they don't match. Which hit me with vkms, which wants that. All other drivers setting this and using the generic fbdev helpers use 16, where both numbers match, for RGB565. Since fixing this is a bit involved (I think for atomic drivers we should just compute this all internally from the format list of the first primary plane) paper over the issue in vkms by using defaults everywhere. Then userspace will pick XRGB8888, and fbdev helpers will do the same, and we have what we want. Reported-by:
Daniel Vetter <daniel.vetter@intel.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> Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that too. Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by:
-
Thomas Zimmermann authored
The HW cursor's BO used to be mapped permanently into the kernel's address space. GEM's vmap operation will be protected by locks, and we don't want to lock the BO's for an indefinate period of time. Change the cursor code to map the HW BOs only during updates. The vmap operation in VRAM helpers is cheap, as a once estabished mapping is being reused until the BO actually moves. As the HW cursor BOs are permanently pinned, they never move at all. v2: * fix typos in commit description Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
-
Thomas Zimmermann authored
Vmapping the cursor source BO contains an implicit pin operation, so there's no need to do this manually. Signed-off-by:
-
- 10 Dec, 2020 3 commits
-
-
Luben Tuikov authored
Add a missing structure comment for the recently added @list member. Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Fixes: 8935ff00 ("drm/scheduler: "node" --> "list"") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Luben Tuikov <luben.tuikov@amd.com> Reviewed-by:
-
Nirmoy Das authored
BO created with amdgpu_bo_create_reserved() wasn't clean properly before, which causes: [ 21.056218] WARNING: CPU: 0 PID: 7 at drivers/gpu/drm/ttm/ttm_bo.c:518 ttm_bo_release+0x2bf/0x310 [ttm] <snip> [ 21.056430] Call Trace: [ 21.056525] amdgpu_bo_unref+0x1a/0x30 [amdgpu] [ 21.056635] amdgpu_vcn_dec_send_msg+0x1b2/0x270 [amdgpu] [ 21.056740] amdgpu_vcn_dec_get_create_msg.constprop.0+0xd8/0x100 [amdgpu] [ 21.056843] amdgpu_vcn_dec_ring_test_ib+0x27/0x180 [amdgpu] [ 21.056936] amdgpu_ib_ring_tests+0xf1/0x150 [amdgpu] [ 21.057024] amdgpu_device_delayed_init_work_handler+0x11/0x30 [amdgpu] [ 21.057030] process_one_work+0x1df/0x370 [ 21.057033] worker_thread+0x46/0x340 [ 21.057034] ? process_one_work+0x370/0x370 [ 21.057037] kthread+0x11b/0x140 [ 21.057039] ? __kthread_bind_mask+0x60/0x60 [ 21.057043] ret_from_fork+0x22/0x30 Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
-
Sumera Priyadarsini authored
Update the vkms documentation to contain steps to: - setup the vkms driver - run tests using igt Signed-off-by:
Sumera Priyadarsini <sylphrenadin@gmail.com> Reviewed-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201209190453.c6kp5winikr55n3i@adolin
-
- 09 Dec, 2020 3 commits
-
-
Tian Tao authored
delete unused variable ‘priv’ to avoid warning. Signed-off-by:
-
Tian Tao authored
Using drmm_mode_config_init() sets up managed release of modesetting resources. v2: Remove the unused structure member variable mode_config_initialized. Signed-off-by:
-
Tian Tao authored
switch to using devm_add_action_or_reset() instead of devm_add_action. Signed-off-by:
-
- 08 Dec, 2020 26 commits
-
-
Sam Ravnborg authored
Coverity reported: Useless call (USELESS_CALL) side_effect_free: Calling SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its return value, which is ignored. And this is correct - so drop the call. Signed-off-by:Sam Ravnborg <sam@ravnborg.org> Reported-by:
Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Useless call") Acked-by:
-
Sam Ravnborg authored
The controlfb driver has a number of dummy defines for IO operations. They were introduced in commit a07a63b0 ("video: fbdev: controlfb: add COMPILE_TEST support"). The write variants did not use their value parameter in the dummy versions, resulting in set but not used warnings. Fix this by adding "(void)val" to silence the compiler. Signed-off-by:
-
Sam Ravnborg authored
screen_pitch was asssigned a value which was never used. Drop it to fix the warning Signed-off-by:
-
Sam Ravnborg authored
The variable "x" was set but never used. Drop the redundant assignments. Signed-off-by:
-
Sam Ravnborg authored
The goldfish_fb_acpi_match table is only used with ACPI enabled. Ifdef it out unless it is needed. This is a similar fix to what other acpi drivers do. Signed-off-by:
-
Sam Ravnborg authored
Include own header to fix "function not declared" warnings. Signed-off-by:
-
Sam Ravnborg authored
Add missing parameter and drop parameter that is not present Signed-off-by:
-
Sam Ravnborg authored
Fix kernel-doc warnings caused by a wrong parameter name blank_mode => blank Signed-off-by:
-
Sam Ravnborg authored
Fix W=1 warning by deleting unused local variable. v2: - Updated subject (Lee) v3: - Return early in case of an error (Thomas) Signed-off-by:
-
Sam Ravnborg authored
Fix a few W=1 warnings about unused assignments. Drop the unused error code. v2: - Subject updated (Lee) Signed-off-by:
-
Sam Ravnborg authored
Fix kernel-doc warnings reported when using W=1 v2: - Improve subject (Lee) v3: - Add RETURNS documentation (Thomas) v4: - Use Return: not RETURNS (Randy) Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Alexander A. Klimov" <grandmaster@al2klimov.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201206205132.GA1869030@ravnborg.org
-
Sam Ravnborg authored
Fix kernel-doc comments. v2: - Updated subject (Lee) v3: - Add space after ':' (Randy) - Fix name of function in comment Signed-off-by:
-
Paul Cercueil authored
Add support for 24-bit panels that are connected through a 8-bit bus and use delta-RGB, which means a RGB pixel ordering on odd lines, and a GBR pixel ordering on even lines. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
-
Paul Cercueil authored
The LCD controller expects timing values in dot-clock ticks, which is 3x the timing values in pixels when using a 3x8-bit display; but it will count the display area size in pixels either way. Go figure. Signed-off-by:
-
Paul Cercueil authored
The adjusted_mode->crtc_* fields contain the values adjusted for the hardware, and are the ones that should be written to the registers. Signed-off-by:
-
Luben Tuikov authored
The job done callback is called from various places, in two ways: in job done role, and as a fence callback role. Essentialize the callback to an atom function to just complete the job, and into a second function as a prototype of fence callback which calls to complete the job. This is used in latter patches by the completion code. Signed-off-by:
-
Luben Tuikov authored
Rename "ring_mirror_list" to "pending_list", to describe what something is, not what it does, how it's used, or how the hardware implements it. This also abstracts the actual hardware implementation, i.e. how the low-level driver communicates with the device it drives, ring, CAM, etc., shouldn't be exposed to DRM. The pending_list keeps jobs submitted, which are out of our control. Usually this means they are pending execution status in hardware, but the latter definition is a more general (inclusive) definition. Signed-off-by:
-
Luben Tuikov authored
Rename "node" to "list" in struct drm_sched_job, in order to make it consistent with what we see being used throughout gpu_scheduler.h, for instance in struct drm_sched_entity, as well as the rest of DRM and the kernel. Signed-off-by:
-
Tomi Valkeinen authored
Add DP support to display-connector driver. The driver will support HPD via a GPIO and DP PWR. DP PWR will be enabled at probe, which is not optimal, but I'm not sure what would be a good place to enable and disable DP PWR. Perhaps attach/detach, but I don't know if enabling HW is something that attach is supposed to do. In any case, I don't think there's much difference in power consumption between the version in this patch and enabling the regulator later: if the driver probes, supposedly it will attach very soon afterwards, and we need to enable the DP PWR as soon as possible. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130112919.241054-3-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
Add binding for DisplayPort connector. A few notes: * Similar to hdmi-connector, it has hpd-gpios as an optional property, as the HPD could also be handled by, e.g., the DP bridge. * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it is not strictly required: standard DP cables do not even have the pin connected. * Connector type. Full size and mini connectors are identical except for the connector size and form, so I believe there is no functional need for this property. But similar to 'label' property, it might be used to present information about the connector to the userspace. * No eDP. There's really no "eDP connector", as it's always a custom made connection between the DP and the DP panel, although the eDP spec does offer a few suggested pin setups. So possibly there is no need for edp-connector binding, but even if there is, I don't want to guess what it could look like, and could it be part of the dp-connector binding. * No DP++. I'm not familiar with DP++. DP++ might need an i2c bus added to the bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201130112919.241054-2-tomi.valkeinen@ti.com
-
Guido Günther authored
This panel from Shenzhen Yashi Changhua Intelligent Technology Co uses the same driver IC but a different LCD. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Guido Günther authored
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by:
-
Guido Günther authored
The panel uses the same driver IC and has the same resolution but a slightly different default mode. It seems it can work with the same init sequence. Signed-off-by:
-
Guido Günther authored
This can be used to use different modes for differnt panels via OF device match. Signed-off-by:
-
Guido Günther authored
We've seen some (non permanent) burn in and bad white balance on some of the panels. Adding this bit from a vendor supplied sequence fixes it. Fixes: 72967d56 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel") Signed-off-by:
-
Guido Günther authored
Less code and easier probe deferral debugging. Signed-off-by:
-
- 07 Dec, 2020 2 commits
-
-
Simon Ser authored
Fix one missing letter, and one duplicate struct field reference. Signed-off-by:
-
Neil Armstrong authored
This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers. It provides a MIPI DSI interface to the host, a built-in LED backlight and touch controller. The init values was taken from the vendor source tree, comments were added to the know values but most of the init table is undocumented. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
