efi: Do not include <linux/screen_info.h> from EFI header
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
v2:
* update loongarch (Jingfeng)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230706104852.27451-2-tzimmermann@suse.de
Firmware file name and version are very important for debugging
customer issues - print them as INFO level message instead
of DEBUG message that is turned off by default.
Ben Skeggs [Thu, 25 May 2023 00:30:57 +0000 (10:30 +1000)]
drm/nouveau/nvkm: fini object children in reverse order
Turns out, we're currently tearing down the disp core channel *before*
the satellite channels (wndw, etc) during suspend.
This makes RM return NV_ERR_NOT_SUPPORTED on attempting to reallocate
the core channel on resume for some reason, but we probably shouldn't
be doing it on HW either.
Tear down children in the reverse of allocation order instead.
John Stultz [Fri, 30 Jun 2023 16:20:33 +0000 (16:20 +0000)]
MAINTAINERS: Remove Laura Abbott from DMA-BUF HEAPS FRAMEWORK
Laura's email address has not been valid for quite awhile now,
so wanted to clean up the reviewer list here.
I reached out to Laura who said it made sense to drop her from
the list, so this patch does that.
I do want to recognize Laura's long time contribution to this
area and her previous ION maintainership, as this couldn't
have gone upstream without her prior efforts. Many thanks!
Cc: Laura Abbott <labbott@kernel.org> Cc: T.J. Mercier <tjmercier@google.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: John Stultz <jstultz@google.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: kernel-team@android.com Acked-by: Laura Abbott <labbott@kernel.org> Signed-off-by: John Stultz <jstultz@google.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630162111.3051783-1-jstultz@google.com
Sui Jingfeng [Thu, 15 Jun 2023 14:36:12 +0000 (22:36 +0800)]
drm: Add kms driver for loongson display controller
Loongson display controller IP has been integrated in both Loongson north
bridge chipset (ls7a1000/ls7a2000) and Loongson SoCs (ls2k1000/ls2k2000).
It has even been included in Loongson's BMC products. It has two display
pipes, and each display pipe supports a primary plane and a cursor plane.
For the DC in the LS7a1000, each display pipe has a DVO output interface,
which is able to support 1920x1080@60Hz. For the DC in the LS7A2000, each
display pipe is equipped with a built-in HDMI encoder, which is compliant
with the HDMI 1.4 specification. The first display pipe is also equipped
with a transparent VGA encoder, which is parallel with the HDMI encoder.
To get a decent performance for writing framebuffer data to the VRAM, the
write combine support should be enabled.
v1 -> v2:
1) Use hpd status reg when polling for ls7a2000.
2) Fix all warnings that emerged when compiling with W=1.
v2 -> v3:
1) Add COMPILE_TEST to Kconfig and make the driver off by default
2) Alphabetical sorting headers (Thomas)
3) Untangle register access functions as much as possible (Thomas)
4) Switch to TTM-based memory manager (Thomas)
5) Add the chip ID detection function which can be used to distinguish
chip models
6) Revise the built-in HDMI phy driver, nearly all main stream mode below
4K@30Hz is tested, and this driver supports clone(mirror) display mode
and extend(joint) display mode.
v3 -> v4:
1) Quickly fix a small mistake.
v4 -> v5:
1) Add per display pipe debugfs support to the builtin HDMI encoder.
v5 -> v6:
1) Remove stray code which didn't get used, say lsdc_of_get_reserved_ram
2) Fix all typos I could found, make sentences and code more readable
3) Untangle lsdc_hdmi*_connector_detect() function according to the pipe
4) Rename this driver as loongson.
v6 -> v7:
1) Add prime support for buffer self-sharing, sharing buffer with
drm/etnaviv is also tested and it works with limitations.
2) Implement buffer object tracking with list_head.
3) Add S3(sleep to RAM) support
4) Rewrite lsdc_bo_move since TTM core stop allocating resources
during BO creation. Patch V1 ~ V6 of this series no longer work.
Thus, we send V7.
v7 -> v8:
1) Zero a compile warning on a 32-bit platform, compile with W=1
2) Revise lsdc_bo_gpu_offset() and make minor cleanups.
3) Pageflip tested on the virtual terminal with the following commands:
It works like a charm, when running the pageflip test with dual screens
configuration, another two additional BOs were created by the modetest,
VRAM usage up to 40+ MB, well we have at least 64MB, still enough.
v8 -> v9:
1) Select I2C and I2C_ALGOBIT in Kconfig, should depend on MMU.
2) Using pci_get_domain_bus_and_slot to get the GPU device.
v9 -> v10:
1) Revise lsdc_drm_freeze() to implement S3 correctly. We realized that
the pinned BO could not be moved, the VRAM lost power when sleeping
to RAM. Thus, the data in the buffer who is pinned in VRAM will get
lost when resumed. Yet it's not a big problem because this driver
relies on the CPU to update the front framebuffer. We can see the
garbage data when resume from S3, but the screen will show the right
image as I move the cursor. This is due to the CPU repaint. v10 of
this patch makes S3 perfect by unpin all of the BOs in VRAM, evict
them all to system RAM in lsdc_drm_freeze().
v10 -> v11:
1) On a double-screen case, The buffer object backing the single giant
framebuffer is referenced by two GEM objects; hence, it will be
pinned at least twice by prepare_fb() function. This causes its pin
count > 1. V10 of this patch only unpins VRAM BOs once when suspend,
which is not correct on double-screen case. V11 of this patch unpin
the BOs until its pin count reaches zero when suspend. Then, we make
the S3 support complete finally. With v11, I can't see any garbage
data when resume.
2) Fix vblank wait timeout when disable CRTC.
3) Test against IGT, at least fbdev test and kms_flip test passed.
4) Rewrite pixel PLL update function, magic numbers eliminated (Emil)
5) Drop a few common hardware features description in lsdc_desc (Emil)
6) Drop lsdc_mode_config_mode_valid(), instead add restrictions in dumb
create function. (Emil)
7) Untangle the ls7a1000 case and ls7a2000 case completely (Thomas)
v11 -> v12:
none
v12 -> v13:
1) Add benchmarks to figure out the bandwidth of the hardware platform.
Usage:
# cd /sys/kernel/debug/dri/0/
# cat benchmark
2) VRAM is filled with garbage data if uninitialized, add a buffer
clearing procedure (lsdc_bo_clear), clear the BO on creation time.
3) Update copyrights and adjust coding style (Huacai)
v13 -> v14:
1) Trying to add async update support for cursor plane.
v14 -> v15:
1) Add lsdc_vga_set_decode() funciton, which allow us remove multi-video
cards workaround, now it allow drm/loongson, drm/amdgpu, drm/etnaviv
co-exist in the system, more is also possible (Emil and Xuerui)
2) Fix typos and grammar mistakes as much as possible (Xuerui)
3) Unify copyrights as GPL-2.0+ (Xuerui)
4) Fix a bug introduce since V13, TTM may import BO from other drivers,
we shouldn't clear it on such a case.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: loongson-kernel@lists.loongnix.cn Tested-by: Liu Peibao <liupeibao@loongson.cn> Tested-by: Li Yi <liyi@loongson.cn> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230615143613.1236245-2-15330273260@189.cn
Marek Vasut [Thu, 15 Jun 2023 20:15:11 +0000 (22:15 +0200)]
drm: bridge: samsung-dsim: Drain command transfer FIFO before transfer
Wait until the command transfer FIFO is empty before loading in the next
command. The previous behavior where the code waited until command transfer
FIFO was not full suffered from transfer corruption, where the last command
in the FIFO could be overwritten in case the FIFO indicates not full, but
also does not have enough space to store another transfer yet.
Jeffrey Hugo [Wed, 28 Jun 2023 18:05:34 +0000 (12:05 -0600)]
MAINTAINERS: Remove Liam Mark from DMA-BUF HEAPS FRAMEWORK
@codeaurora.org email addresses are no longer valid and will bounce.
I reached out to Liam about updating his entry under DMA-BUF HEAPS
FRAMEWORK with an @codeaurora.org address. His response:
"I am not a maintainer anymore, that should be removed."
Liam currently does not have an email address that can be used to remove
this entry, so I offered to submit a cleanup on his behalf with Liam's
consent.
Ralph Campbell [Wed, 21 Jun 2023 06:19:03 +0000 (23:19 -0700)]
drm/edid: Add quirk for OSVR HDK 2.0
The OSVR virtual reality headset HDK 2.0 uses a different EDID
vendor and device identifier than the HDK 1.1 - 1.4 headsets.
Add the HDK 2.0 vendor and device identifier to the quirks table so
that window managers do not try to display the desktop screen on the
headset display.
Detection of the configuration mode and the chipset model are
linked to each other. One uses values from the other; namely the
PCI device revision and the SCU revision. Merge this code into
a single function.
drm/ast: Move widescreen and tx-chip detection into separate helpers
Split ast_detect_chip() into three functions and call them one by
one. The new functions detect the transmitter chip and widescreen
support. This will allow for further refactoring.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> # AST2600 Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> # AST2400 Link: https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-14-tzimmermann@suse.de
ASpeed distinguishes among various generations of the AST graphics
chipset with various models. [1] The most-recent model AST 2600 is
of the 7th generation, the AST 2500 is of the 6th generation, and so
on.
The ast driver simply picks one of the models as representative for
the whole generation. In several places, individual models of the
same generation need to be handled differently, which then requires
additional code for detecting the model.
Introduce different generations of the Aspeed chipset. In the source
code, refer to the generation instead of the representation model where
possible. The few places that require per-model handling are now clearly
marked.
In the enum ast_chip, we arrange each model's value such that it
encodes the generation. This allows for an easy test. The actual values
are ordered, but not of interest to the driver.
drm/ast: Set up release action right after enabling MMIO
Ast sets up a managed release of the MMIO access flags. Move this
code next to the MMIO access code, so that it runs if other errors
occur during the device initialization.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> # AST2400 Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> # AST2600 Link: https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-9-tzimmermann@suse.de
drm/ast: Enable and unlock device access early during init
POST and memory management contains code to enable access to the
device's memory spaces. This is too late. Consolidate this code at
the beginning of the device initialization.
drm/ast: Set PCI config before accessing I/O registers
Access to I/O registers is required to detect and set up the
device. Enable the rsp PCI config bits before. While at it,
convert the magic number to macro constants.
Enabling the PCI config bits was done after trying to detect
the device. It was probably too late at this point.
v2:
* use standard 16-bit PCI r/w access (Jingfeng)
According to the chip detection in ast_detect_chip(), AST2300 and
later always have a PCI revision of 0x20 or higher. Therefore the
code in ast_set_def_ext_reg() can not use the else branch when
selecing the EXT register values. Remove the dead branch and the
related values.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.5+ Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> # AST2600 Link: https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmermann@suse.de
Thomas Hellström [Mon, 26 Jun 2023 09:14:48 +0000 (11:14 +0200)]
drm/ttm: Don't shadow the operation context
ttm_bo_swapout() shadows the ttm operation context which may cause
major confusion in driver callbacks when swapping out !TTM_PL_SYSTEM
memory. Fix this by reusing the operation context argument to
ttm_bo_swapout().
Cc: "Christian König" <christian.koenig@amd.com> Cc: Roger He <Hongbo.He@amd.com> Cc: <dri-devel@lists.freedesktop.org> Cc: <intel-gfx@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230626091450.14757-3-thomas.hellstrom@linux.intel.com
fbdev: Make support for userspace interfaces configurable
Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
device optional. If the new option has not been selected, fbdev
does not create files in devfs, sysfs or procfs.
Most modern Linux systems run a DRM-based graphics stack that uses
the kernel's framebuffer console, but has otherwise deprecated fbdev
support. Yet fbdev userspace interfaces are still present.
The option makes it possible to use the fbdev subsystem as console
implementation without support for userspace. This closes potential
entry points to manipulate kernel or I/O memory via framebuffers. It
also prevents the execution of driver code via ioctl or sysfs, both
of which might allow malicious software to exploit bugs in the fbdev
code.
A small number of fbdev drivers require struct fbinfo.dev to be
initialized, usually for the support of sysfs interface. Make these
drivers depend on FB_DEVICE. They can later be fixed if necessary.
v3:
* effect -> affect in Kconfig help (Daniel)
v2:
* set FB_DEVICE default to y (Geert)
* comment on {get,put}_device() (Sam)
* Kconfig fixes (Sam)
* add TODO item about FB_DEVICE dependencies (Sam)
Init the class "graphics" before the rest of fbdev. Later steps, such
as the sysfs code, depend on the class. Also arrange the module's exit
code in reverse order.
Unexport the global variable fb_class, which is only shared internally
within the fbdev core module.
Move fbdev's procfs code into a separate file and contain it in
init and cleanup helpers. For the cleanup, replace remove_proc_entry()
with proc_remove(). It is equivalent in functionality, but looks
more like an inverse of proc_create_seq().
Move the logic to create and destroy fbdev devices into the new
helpers fb_device_create() and fb_device_destroy().
There was a call to fb_cleanup_device() in do_unregister_framebuffer()
that was too late. The device had already been removed at this point.
Move the call into fb_device_destroy().
Declare the helpers in the new internal header file fb_internal.h, as
they are only used within the fbdev core module.
fbdev/core: Pass Linux device to pm_vt_switch_*() functions
Pass the Linux device to pm_vt_switch_*() instead of the virtual
fbdev device. Prepares fbdev for making struct fb_info.dev optional.
The type of device that is passed to the PM functions does not matter
much. It is only a token within the internal list of known devices.
The PM functions do not refer to any of the device's properties or its
type.
fbdev/tdfxfb: Set i2c adapter parent to hardware device
Use the 3dfx hardware device from the Linux device hierarchy as
parent device of the i2c adapter. Aligns the driver with the rest
of the codebase and prepares fbdev for making struct fb_info.dev
optional.
fbdev/smscufx: Detect registered fb_info from refcount
Detect registered instances of fb_info by reading the reference
counter from struct fb_info.read. Avoids looking at the dev field
and prepares fbdev for making struct fb_info.dev optional.
fbdev/sh7760fb: Use hardware device with dev_() output during probe
Call output helpers in the probe function with the hardware device.
The virtual fbdev device has not been initialized at that point. Also
prepares fbdev for making struct fb_info.dev optional.
fbdev/sh7760fb: Alloc DMA memory from hardware device
Pass the hardware device to the DMA helpers dma_alloc_coherent() and
dma_free_coherent(). The fbdev device that is currently being used is
a software device and does not provide DMA memory. Also update the
related dev_*() output statements similarly.
fbdev/rivafb: Use hardware device as backlight parent
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
fbdev/radeonfb: Use hardware device as backlight parent
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
fbdev/radeonfb: Reorder backlight and framebuffer cleanup
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the cleanup calls for both data
structures. The init calls are already in the correct order.
fbdev/nvidiafb: Use hardware device as backlight parent
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
fbdev/metronomefb: Use hardware device for dev_err()
Replace the use of the fbdev software device, stored in struct
fb_info.dev, with the hardware device from struct fb_info.device
in load_waveform(). The device is only used for printing errors
with dev_err().
This change aligns load_waveform() with the rest of the driver and
prepares fbdev for making struct fb_info.dev optional.
fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
Do not assing the Linux device to struct fb_info.dev. The call to
register_framebuffer() initializes the field to the fbdev device.
Drivers should not override its value.
Fixes a bug where the driver incorrectly decreases the hardware
device's reference counter and leaks the fbdev device.
fbdev/ep93xx-fb: Alloc DMA memory from hardware device
Pass the hardware device to the DMA helpers dma_alloc_wc(), dma_mmap_wc()
and dma_free_coherent(). The fbdev device that is currently being used is
a software device and does not provide DMA memory.
fbdev/broadsheetfb: Call device_remove_file() with hardware device
Call device_remove_file() with the same device that has been used
for device_create_file(), which is the hardware device stored in
struct fb_info.device. Prepares fbdev for making struct fb_info.dev
optional.
fbdev/aty128fb: Use hardware device as backlight parent
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
fbdev/atyfb: Use hardware device as backlight parent
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
backlight/lv5207lp: Rename struct lv5207lp_platform_data.fbdev to 'dev'
Rename struct lv5207lp_platform_data.fbdev to 'dev', as it stores a
pointer to the Linux platform device; not the fbdev device. Makes
the code easier to understand.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: linux-sh@vger.kernel.org Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-7-tzimmermann@suse.de
backlight/lv5207lp: Compare against struct fb_info.device
Struct lv5207lp_platform_data refers to a platform device within
the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
Fixes: 82e5c40d88f9 ("backlight: Add Sanyo LV5207LP backlight driver") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: linux-sh@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.12+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-6-tzimmermann@suse.de
backlight/gpio_backlight: Rename field 'fbdev' to 'dev'
Rename the field 'fbdev' in struct gpio_backlight_platform_data and
struct gpio_backlight to 'dev', as they store pointers to the Linux
platform device; not the fbdev device. Makes the code easier to
understand.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: linux-sh@vger.kernel.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-5-tzimmermann@suse.de
backlight/gpio_backlight: Compare against struct fb_info.device
Struct gpio_backlight_platform_data refers to a platform device within
the Linux device hierarchy. The test in gpio_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver") Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: linux-sh@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.12+ Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-4-tzimmermann@suse.de
backlight/bd6107: Rename struct bd6107_platform_data.fbdev to 'dev'
Rename struct bd6107_platform_data.fbdev to 'dev', as it stores a
pointer to the Linux platform device; not the fbdev device. Makes
the code easier to understand.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-3-tzimmermann@suse.de
backlight/bd6107: Compare against struct fb_info.device
Struct bd6107_platform_data refers to a platform device within
the Linux device hierarchy. The test in bd6107_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
Fixes: 67b43e590415 ("backlight: Add ROHM BD6107 backlight driver") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.12+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-2-tzimmermann@suse.de
Adrián Larumbe [Sun, 25 Jun 2023 14:17:16 +0000 (15:17 +0100)]
drm/bridge: dw-hdmi: truly enforce 420-only formats when drm mode demands it
The current output bus format selection logic is enforcing YUV420 even
when the drm mode allows for other bus formats as well.
Fix it by adding check for 420-only drm modes.
Adrián Larumbe [Sun, 25 Jun 2023 14:17:15 +0000 (15:17 +0100)]
drm/bridge: dw-hdmi: change YUV420 selection logic at clock setup
Right now clocking value selection code is prioritising RGB, YUV444 modes
over YUV420 for HDMI2 sinks. However, because of the bus format selection
procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always
be picked during the drm bridge chain check stage.
Later on dw_hdmi_setup will configure a colour space based on the bus
format that doesn't match the pixel value we had calculated as described
above.
Fix it by bringing back dw-hdmi bus format check when picking the right
pixel clock.
drm: Clear fd/handle callbacks in struct drm_driver
Clear all assignments of struct drm_driver's fd/handle callbacks to
drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These
functions are called by default. Add a TODO item to convert vmwgfx
to the defaults as well.
v2:
* remove TODO item (Zack)
* also update amdgpu's amdgpu_partition_driver
Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by
default if no PRIME import/export helpers have been set. Both functions
are the default for almost all drivers.
DRM drivers implement struct drm_driver.gem_prime_import_sg_table
to import dma-buf objects from other drivers. Having the function
drm_gem_prime_fd_to_handle() functions set by default allows each
driver to import dma-buf objects to itself, even without support for
other drivers.
For drm_gem_prime_handle_to_fd() it is similar: using it by default
allows each driver to export to itself, even without support for other
drivers.
This functionality enables userspace to share per-driver buffers
across process boundaries via PRIME (e.g., wlroots requires this
functionality). The patch generalizes a pattern that has previously
been implemented by GEM VRAM helpers [1] to work with any driver.
For example, gma500 can now run the wlroots-based sway compositor.
v2:
* clean up docs and TODO comments (Simon, Zack)
* clean up style in drm_getcap()
Liu Ying [Mon, 12 Jun 2023 09:23:59 +0000 (17:23 +0800)]
drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()
When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),
overlay plane's framebuffer pointer is NULL. So, dereferencing it would
cause a kernel Oops(NULL pointer dereferencing). Fix the issue by
disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.
Fixes: cb285a5348e7 ("drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr()") Cc: stable@vger.kernel.org # 5.19+ Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230612092359.784115-1-victor.liu@nxp.com
All convertions from the ARGB16161616 format follow the same structure.
Instead of repeting the same structure for each supported format, create
a function to encapsulate the common logic and isolate the pixel
conversion functions in a callback function.
Maíra Canal [Mon, 15 May 2023 13:52:04 +0000 (10:52 -0300)]
drm/vkms: Enable ARGB8888 support for writeback
The VKMS already has a function to convert ARGB16161616 to ARGB8888, so
it is possible to use this function to provide the writeback support for
the ARGB8888 format. Therefore, add the ARGB8888 format to the writeback
format list.
Maíra Canal [Mon, 15 May 2023 13:52:03 +0000 (10:52 -0300)]
drm/vkms: Reduce critical section
The spinlock composer_lock protects the variables crc_pending,
wb_pending, frame_start and frame_end, which are variables that are used
by the composer worker. There is no need to protect the wb_frame_info
information with a spinlock. Therefore, reduce the critical section of
the lock by removing the assignments to the wb_frame_info from the
critical section.
Douglas Anderson [Fri, 16 Jun 2023 23:55:17 +0000 (16:55 -0700)]
drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID
In order to read the EDID from an eDP panel, you not only need to
power on the bridge chip itself but also the panel. In the ps8640
driver, this was made to work by having the bridge chip manually power
the panel on by calling pre_enable() on everything connectorward on
the bridge chain. This worked OK, but...
...when trying to do the same thing on ti-sn65dsi86, feedback was that
this wasn't a great idea. As a result, we designed the "DP AUX"
bus. With the design we ended up with the panel driver itself was in
charge of reading the EDID. The panel driver could power itself on and
the bridge chip was able to power itself on because it implemented the
DP AUX bus.
Despite the fact that we came up with a new scheme, implemented in on
ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept
the old code around. This was because the new scheme required a DT
change. Previously the panel was a simple "platform_device" and in DT
at the top level. With the new design the panel needs to be listed in
DT under the DP controller node. The old code allowed us to properly
fetch EDIDs with ps8640 with the old DTs.
Unfortunately, the old code stopped working as of commit 102e80d1fa2c
("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There
are cases at bootup where connector->state->state is NULL and the
kernel crashed at:
* drm_atomic_bridge_chain_pre_enable
* drm_atomic_get_old_bridge_state
* drm_atomic_get_old_private_obj_state
The crash went away at commit 4fb912e5e190 ("drm/bridge: Introduce
pre_enable_prev_first to alter bridge init order") which added a NULL
check. However, even though we were no longer crashing the end result
was that we weren't actually powering the panel on when we thought we
were. Things could end up working (despite warning splats) if
userspace was persistent and tried to get the mode again, but it
wasn't great.
A bit of digging was done to see if there was an easy fix but there
was nothing obvious. Instead, the only device using ps8640 the "old"
way had its DT updated so that the panel was no longer a simple
"platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek:
mt8173-elm: Move display to ps8640 auxiliary bus") and commit 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model
number in DT").
Let's delete the old broken code so nobody gets tempted to copy it or
figure out how it works (since it doesn't).
NOTE: from a device tree "purist" point of view, we're supposed to
keep old device trees working and this patch is technically "against
policy". Reasons I'm still proposing it anyway:
1. Officially, old mt8173-elm device trees worked via the "little
white lie" approach. The DT would list an arbitrary/representative
panel that would be used for power sequencing. The mode information
in the panel driver would then be ignored / overridden by the EDID
reading code in ps8640. I don't feel too terrible breaking DTs that
contained the wrong "compatible" string to begin with. NOTE that
any old device trees that _didn't_ lie about their compatible will
still work because the mode information will come from the
hardcoded panels in panel-edp.
2. The only users of the old code were Chromebooks and Chromebooks
don't bake their DTs into the BIOS (they are bundled with the
kernel). Thus we don't need to worry about breaking someone using
an old DT with a new kernel.
3. The old code was broken anyway. If someone wants to fix the old
code instead of deleting it then they have my blessing, but without
a proper fix the old code isn't useful.
projects / mirror_ubuntu-kernels.git / log