- 20 Sep, 2022 6 commits
-
-
Jammy Huang authored
Add 1152x864 into support list. Signed-off-by:
Jammy Huang <jammy_huang@aspeedtech.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220916085058.3386-1-jammy_huang@aspeedtech.com
-
Thomas Zimmermann authored
Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions of non-atomic drivers to default values. The macro is not supposed to be used in new code, but helps with documenting and finding existing users. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
The plane update and disable helpers are only useful for non-atomic drivers. Print a warning if an atomic driver calls them. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Thomas Zimmermann authored
Provide drm_univeral_plane_alloc() to allocate and initialize a plane. Code for non-atomic drivers uses this pattern. Convert them to the new function. The modeset helpers contain a quirk for handling their color formats differently. Set the flag outside plane allocation. The new function is already deprecated to some extend. Drivers should rather use drmm_univeral_plane_alloc() or drm_universal_plane_init(). v2: * kerneldoc fixes (Javier) * grammar fixes in commit message Signed-off-by:
-
Thomas Zimmermann authored
Open-code drm_plane_init() and remove the function from DRM. The implementation of drm_plane_init() is a simple wrapper around a call to drm_universal_plane_init(), so drivers can just use that instead. Signed-off-by:
Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-2-tzimmermann@suse.de
-
Jiapeng Chong authored
drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2216Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 19 Sep, 2022 7 commits
-
-
Christian König authored
That check must now come after grabing the spinlock, not before. Signed-off-by:
Christian König <christian.koenig@amd.com> Fixes: b96fb1e7 ("dma-buf: dma_fence_wait must enable signaling") Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220919120618.113332-1-christian.koenig@amd.com
-
Robert Foss authored
Revert this patch since it depends on devicetree functionality that previously has been reverted in the below commit. commit e798ba33 ("Revert "dt-bindings: Add byteswap order to chrontel ch7033"") This reverts commit ce9564cf. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Robert Foss authored
This commit was accidentally reverted instead of another commit, and therefore needs to be reinstated. This reverts commit 8c9c40ec. Fixes: 8c9c40ec ("Revert "drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP"") Signed-off-by:
-
Yang Yingliang authored
mtk_dp_driver is only used in mtk_dp.c now, change it to static. Fixes: f70ac097 ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Bo-Chen Chen authored
Fix debug message formatting by using %s instead of 0x%x. Fixes: f70ac097 ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Reported-by:
Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Bo-Chen Chen authored
Some definitions in mtk_dp_reg.h are not used, so remove these redundant codes. Signed-off-by:
-
Bo-Chen Chen authored
In order to improve human readability, reduce the indentation by returning early if the dp/edp cable is not plugged in. Signed-off-by:
-
- 18 Sep, 2022 5 commits
-
-
Hans de Goede authored
On machines without an Intel video opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() function after setting up the gma500's native backlight, so that the acpi_video backlight device gets registered on systems where the gma500's native backlight device is not registered. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220917205920.647212-6-hdegoede@redhat.com
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Signed-off-by:
-
Hans de Goede authored
Use backlight_get_brightness() instead of directly referencing bd->props.brightness. This will take backlight_is_blank() into account, properly setting brightness to 0 when screen-blanking has been requested through the backlight sysfs interface. Suggested-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Hans de Goede authored
Change the type for the registered backlight class device from platform to raw/native. The poulsbo/cedarview/oaktrail backlight support is using native GPU backlight control and as such the type should be raw (aka native) as is done by all the other native GPU backlight driver code. Note this will not change much from userspace's point of view. poulsbo/cedarview laptops typically offer both an ACPI-video backlight interface as well as the native GPU backlight interface. The /sys/class/backlight/acpi_video0 has a type of firmware and userspace typically looks for firmware devices before looking for platform devices. The typical standard lookup order is: firmware -> platform -> raw This means that both before and after this change typical userspace backlight consumers (sich as e.g. GNOME) will prefer the firmware acpi_video0 backlight device. This has been tested on a Packard Bell Dot SC (Intel Atom N2600, cedarview) and a Sony Vaio vpc-x11s1e (Intel N540, poulsbo) laptop. Signed-off-by:
-
Hans de Goede authored
Refactor backlight support so that the gma_backlight_enable() / gma_backlight_disable() / gma_backlight_set() functions used by the Opregion handle will also work if no backlight_device gets registered. This is a preparation patch for not registering the gma500's own backlight device when acpi_video should be used, since registering 2 backlight devices for a single display really is undesirable. Since the acpi-video interface often uses the OpRegion we need to keep the OpRegion functional even when dev_priv->backlight_device is NULL. As a result of this refactor the actual backlight_device_register() call is moved to the shared backlight.c code and all #ifdefs related to CONFIG_BACKLIGHT_CLASS_DEVICE are now also limited to backlight.c . No functional changes intended. This has been tested on a Packard Bell Dot SC (Intel Atom N2600, cedarview) and a Sony Vaio vpc-x11s1e (Intel N540, poulsbo) laptop. Changes in v2: - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by marking the 2 variables as __maybe_unused. Signed-off-by:
-
- 17 Sep, 2022 9 commits
-
-
Maya Matuszczyk authored
Yet another x86 gaming handheld. This one has many SKUs with quite a few of DMI strings, so let's just use a catchall, just as with Aya Neo Next. Signed-off-by:
Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by:
-
Hans de Goede authored
The psb_runtime_suspend/resume/thaw/freeze/restore functions are all just 1:1 wrappers around gma_power_suspend/_resume. Drop these wrappers and use the DEFINE_RUNTIME_DEV_PM_OPS() macro to define the dev_pm_ops struct. Signed-off-by:
-
Hans de Goede authored
Rewrite the power.c code. For some reason this was doing locking + refcounting + state (suspended or not) bookkeeping all by itself. But there is no reason for this, this is all taken care of by the runtime-pm core, through pm_runtime_get()/_put(). Besides this not being necessary the DIY code is also quite weird/ buggy in some places. E.g. power_begin() would manually do a resume when not resumed already and force_on=true, followed by a pm_runtime_get(), which will cause a call to gma_power_resume() to get scheduled which would redo the entire resume again. Which can all be replaced by a single pm_runtime_get_sync() call. Note that this is just a cleanup, this does not actually fix the (disabled through #if 0) runtime-pm support. It does now call pm_runtime_enable(), but only after doing a pm_runtime_get() at probe-time, so the device is never runtime suspended. Doing this permanent get() + enable() instead of not calling enable() at all is necessary for the pm_runtime_get_if_in_use() call in gma_power_begin() to work properly. Note this also removes the gma_power_is_on() call a check like this without actually holding a reference is always racy, so it is a bad idea (and therefor has no pm_runtime_foo() equivalent). The 2 code paths which were using gma_power_is_on() are actually both guaranteed to only run when the device is powered-on so the 2 checks can simply be dropped. Signed-off-by:
-
Hans de Goede authored
The gma_crtc_set_config() and psb_unlocked_ioctl() functions are 1:1 wrappers for drm_helpers. Drop these wrappers. Signed-off-by:
-
Hans de Goede authored
The rpm_enabled flag is never set, remove it. Signed-off-by:
-
Hans de Goede authored
runtime_allowed is initialized to 0, so the runtime_allowed == 1 condition is never true making this dead code. Remove it. Signed-off-by:
-
Hans de Goede authored
Fix gnome-shell (and other page-flip users) hanging after suspend/resume because of the gma500's IRQs not working. This fixes 2 problems with the IRQ handling: 1. gma_power_off() calls gma_irq_uninstall() which does a free_irq(), but gma_power_on() called gma_irq_preinstall() + gma_irq_postinstall() which do not call request_irq. Replace the pre- + post-install calls with gma_irq_install() which does prep + request + post. 2. After fixing 1. IRQs still do not work on a Packard Bell Dot SC (Intel Atom N2600, cedarview) netbook. Cederview uses MSI interrupts and it seems that the BIOS re-configures things back to normal APIC based interrupts during S3 suspend. There is some MSI PCI-config registers save/restore code which tries to deal with this, but on the Packard Bell Dot SC this is not sufficient to restore MSI IRQ functionality after a suspend/resume. Replace the PCI-config registers save/restore with pci_disable_msi() on suspend + pci_enable_msi() on resume. Fixing e.g. gnome-shell hanging. Signed-off-by:
-
Jilin Yuan authored
Delete the redundant word 'the'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Signed-off-by:
-
Maya Matuszczyk authored
This device is another x86 gaming handheld, and as (hopefully) there is only one set of DMI IDs it's using DMI_EXACT_MATCH Signed-off-by:
-
- 16 Sep, 2022 6 commits
-
-
Javier Martinez Canillas authored
Provides a default plane state check handler for primary planes that are a fullscreen scanout buffer and whose state scale and position can't change. There are some drivers that duplicate this logic in their helpers, such as simpledrm and ssd130x. Factor out this common code into a plane helper and make drivers use it. Suggested-by:
-
Arvind Yadav authored
Using the parent fence instead of the finished fence to get the job status. This change is to avoid GPU scheduler timeout error which can cause GPU reset. Signed-off-by:
Arvind Yadav <Arvind.Yadav@amd.com> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220914164321.2156-6-Arvind.Yadav@amd.comSigned-off-by:
-
Arvind Yadav authored
dma_fence_wait() should always enable signaling even when the fence is already signaled. Signed-off-by:
-
Arvind Yadav authored
Here's enabling software signaling on fence for selftest. Signed-off-by:
-
Arvind Yadav authored
Here's setting software signaling bit for the stub fence which is always signaled. If this fence signaling bit is not set then the AMD GPU scheduler will cause a GPU reset due to a GPU scheduler cleanup activity timeout. Signed-off-by:
-
Arvind Yadav authored
Remove the signaled bit status check because it is returning early when the fence is already signaled and __dma_fence_enable_signaling is checking the status of signaled bit again. Signed-off-by:
-
- 15 Sep, 2022 3 commits
-
-
Tom Rix authored
cppcheck reports [drivers/gpu/drm/rockchip/rockchip_drm_vop.c:186]: (style) The function 'vop_writel' is never used. vop_writel is static function that is not used, so remove it. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220521190716.1936193-1-trix@redhat.com
-
Hugh Cole-Baker authored
The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its "big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP. Compared to the RK3288, it no longer requires disabling gamma while updating the LUT. On the RK3399, the LUT can be updated at any time as the hardware has two LUT buffers, one can be written while the other is in use. A swap of the buffers is triggered by writing 1 to the update_gamma_lut register. Signed-off-by:
Hugh Cole-Baker <sigmaris@gmail.com> Tested-by:
"Milan P. Stanić" <mps@arvanta.net> Tested-by:
Linus Heckemann <git@sphalerite.org> Signed-off-by:
-
Hugh Cole-Baker authored
The VOP on RK3399 has a different approach from previous versions for setting a gamma lookup table, using an update_gamma_lut register. As this differs from RK3288, give RK3399 its own set of "common" register definitions. Signed-off-by:
-
- 14 Sep, 2022 4 commits
-
-
Maíra Canal authored
With the introduction of KUnit, IGT is no longer the only option to run the DRM unit tests, as the tests can be run through kunit-tool or on real hardware with CONFIG_KUNIT. Therefore, remove the "igt_" prefix from the tests and replace it with the "drm_test_" prefix, making the tests' names independent from the tool used. Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Acked-by:
David Gow <davidgow@google.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220911191756.203118-2-mairacanal@riseup.net
-
Maíra Canal authored
The igt_check_drm_framebuffer_create is based on a loop that executes tests for all createbuffer_tests test cases. This could be better represented by parameterized tests, provided by KUnit. So, convert the igt_check_drm_framebuffer_create into parameterized tests. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Maxime Ripard authored
Merge tag 'backlight-detect-refactor-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into drm-misc-next Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86 Tag (immutable branch) with v6.0-rc1 + the (acpi/x86) backlight detect refactor work. For merging into the acpi, drm-* and pdx86 subsystems. Signed-off-by:
-
Maxime Ripard authored
We need 6.0-rc1 to merge the backlight rework PR. Signed-off-by:
-
