| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
v2:
* add Fixes tag (Dan)
Signed-off-by: Thomas Zimmermann <[email protected]>
Fixes: 88017bda96a5 ("ep93xx video driver")
Cc: <[email protected]> # v2.6.32+
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fix cases were output helpers are called with struct fb_info.dev.
Use fb_info() and fb_err() instead.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: [email protected]
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: <[email protected]> # v3.12+
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: [email protected]
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
Cc: Laurent Pinchart <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: <[email protected]> # v3.12+
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v3.12+
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The hdmi_datamap enum is no longer in use. Also reindent enable_audio's
call params.
Signed-off-by: Adrián Larumbe <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ca42985814e9be33b7f8e3a33cea9e18505299e3.1687702042.git.adrian.larumbe@collabora.com
|
|
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.
Signed-off-by: Adrián Larumbe <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/6e6a217c180584a67ed7992c785764ba54af9151.1687702042.git.adrian.larumbe@collabora.com
|
|
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.
Signed-off-by: Adrián Larumbe <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/6230bfae2cd97cf6527fc62ba5c850464919ccf8.1687702042.git.adrian.larumbe@collabora.com
|
|
Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd().
Both are only used internally within the PRIME code.
v2:
* reword docs as functions are now unexported (Simon)
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Simon Ser <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Simon Ser <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Acked-by: Jeffrey Hugo <[email protected]> # qaic
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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()
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://lore.kernel.org/dri-devel/[email protected]/ # 1
Reviewed-by: Simon Ser <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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: [email protected] # 5.19+
Signed-off-by: Liu Ying <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Suggested-by: Melissa Wen <[email protected]>
Signed-off-by: Maíra Canal <[email protected]>
Reviewed-by: Arthur Grillo <[email protected]>
Signed-off-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Maíra Canal <[email protected]>
Reviewed-by: Arthur Grillo <[email protected]>
Signed-off-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Maíra Canal <[email protected]>
Reviewed-by: Arthur Grillo <[email protected]>
Signed-off-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616165517.v2.1.I7b8f60b3fbfda068f9bf452d584dc934494bfbfa@changeid
|
|
User-space may query an existing object not included in a lease.
Make it easier to debug such situations by logging a debug message.
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This adds more information to the hotplug uevent and lets user-space
know that it's about a particular connector only.
Signed-off-by: Simon Ser <[email protected]>
Cc: Dmitry Baryshkov <[email protected]>
Cc: Paul Cercueil <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rename drm_sysfs_connector_status_event() to
drm_sysfs_connector_property_event(). Indeed, "status" is a bit
vague: it can easily be confused with the connected/disconnected
status of the connector. This function has nothing to do with
connected/disconnected: it merely sends a notification that a
connector's property has changed (e.g. HDCP, privacy screen, etc).
Signed-off-by: Simon Ser <[email protected]>
Cc: Manasi Navare <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Harry Wentland <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Only the stuff inside the brackets should be indented.
Signed-off-by: Simon Ser <[email protected]>
Cc: Harry Wentland <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sebastian Wick <[email protected]>
Cc: Joshua Ashton <[email protected]>
Cc: Pekka Paalanen <[email protected]>
Reviewed-by: Pekka Paalanen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
smatch reports
drivers/gpu/drm/mgag200/mgag200_drv.c:23:5: warning: symbol
'mgag200_modeset' was not declared. Should it be static?
This variable is only used in its defining file, so it should be static
Signed-off-by: Tom Rix <[email protected]>
Reviewed-by: Jocelyn Falempe <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Jocelyn Falempe <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Before this patch, booting to Linux VT and doing a simple:
echo 2 > /sys/class/graphics/fb0/blank
echo 0 > /sys/class/graphics/fb0/blank
would result in failures to re-enable the panel. Mode set callback is
called only once during boot in this scenario, while calls to
enable/disable callbacks are balanced afterwards. The driver doesn't
work unless userspace calls modeset before enabling the CRTC/connector.
This patch moves enabling of the DSI host from mode_set into pre_enable
callback, and removes some old hacks where this bridge driver is
directly calling into other bridge driver's callbacks.
pre_enable_prev_first flag is set on the panel's bridge so that panel
drivers will get their prepare function called between DSI host's
pre_enable and enable callbacks, so that they get a chance to
perform panel setup while DSI host is already enabled in command
mode. Otherwise panel's prepare would be called before DSI host
is enabled, and any DSI communication used in prepare callback
would fail.
With all these changes, the enable/disable sequence is now well
balanced, and host's and panel's callbacks are called in proper order
documented in the drm_panel API documentation without needing the old
hacks. (Mainly that panel->prepare is called when DSI host is ready to
allow the panel driver to send DSI commands and vice versa during
disable.)
Tested on Pinephone Pro. Trace of the callbacks follows.
Before:
[ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable
echo 2 > /sys/class/graphics/fb0/blank
[ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable
[ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare
echo 0 > /sys/class/graphics/fb0/blank
[ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable
[ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
echo 2 > /sys/class/graphics/fb0/blank
[ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable
[ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110
[ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare
[ 431.169357] pclk_mipi_dsi0 already disabled
echo 0 > /sys/class/graphics/fb0/blank
[ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable
[ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
-----------------------------------------------------------------------
After:
[ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable
echo 2 > /sys/class/graphics/fb0/blank
[ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable
[ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare
echo 0 > /sys/class/graphics/fb0/blank
[ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable
(But depends on functionality intorduced in Linux 6.3, so this patch will
not build on older kernels when applied to older stable branches.)
Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge")
Signed-off-by: Ondrej Jirman <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter")
convert back to (the new) .probe() to be able to eventually drop
.probe_new() from struct i2c_driver.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add support for handling the HS/VS sync signals polarity in the bridge
driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity
sync signals and the image is shifted to the left, up, and wobbly.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The register content and behavior is very similar to TC358764 VP_CTRL.
All the bits except for unknown bit 6 also seem to match, even though
the datasheet is just not available. Add a comment and reuse the bit
definitions.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This bridge seems to need the HSE packet, otherwise the image is
shifted up and corrupted at the bottom. This makes the bridge
work with Samsung DSIM on i.MX8MM and i.MX8MP.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Switch the bridge driver over to atomic ops. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Move the register programming part, which actually enables the bridge and
makes it push data out of its DPI side, into the enable callback. The DSI
host like DSIM may not be able to transmit commands in pre_enable, moving
the register programming into enable assures it can transmit commands.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
None of these four bits are bitfields, use BIT() macro and treat
them as bits. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by: Daniel Vetter <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked for both importers and exporters by the dma-buf
core, which caused a deadlock problem for DRM drivers in a case of
self-imported dma-bufs which required to take the lock from the DRM
exporter side.
Acked-by: Christian König <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares DRM
drivers for the locking policy update.
Reviewed-by: Emil Velikov <[email protected]>
Acked-by: Christian König <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares udmabuf
for the locking policy update.
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|