- Apr 26, 2022
-
-
Marek Vasut authored
Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr() to correctly handle FB offset. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220417020800.336675-2-marex@denx.de
-
Marek Vasut authored
Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up. No functional change. Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
- Apr 25, 2022
-
-
Thomas Zimmermann authored
SCDC is the Status and Control Data Channel for HDMI. Move the SCDC helpers into display/ and split the header into files for core and helpers. Update all affected drivers. No functional changes. To avoid the proliferation of Kconfig options, SCDC is part of DRM's support for HDMI. If necessary, a new option could make SCDC an independent feature. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
Move DRM's HMDI helpers into the display/ subdirectoy and add it to DRM's display helpers. Update all affected drivers. No functional changes. The HDMI helpers were implemented in the EDID and connector code, but are actually unrelated. With the move to the display-helper library, we can remove the dependency on drm_edid.{c,h} in some driver's HDMI source files. Several of the HDMI helpers remain in EDID code because both share parts of their implementation internally. With better refractoring of the EDID code, those HDMI helpers could be moved into the display-helper library as well. v3: * fix Kconfig dependencies (Javier) v2: * reduce HDMI helpers to avoid exporting functions (Jani) * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: -
Thomas Zimmermann authored
Move DRM's HDCP helper library into the display/ subdirectory and add it to DRM's display helpers. Split the header file into core and helpers. Update all affected drivers. No functional changes. v3: * fix Kconfig dependencies v2: * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by:
-
Thomas Zimmermann authored
DSC is the Display Stream Compression standard for DisplayPort. Move the DSC code into display/ and split the header into files for protocol core and DRM helpers. Adapt all users of the code. No functional changes. To avoid the proliferation of Kconfig options, DSC is part of DRM's support for DisplayPort. If necessary, a new option could make DSC an independent feature. Signed-off-by:
-
Thomas Zimmermann authored
Move DisplayPort protocol constants and structures into the new header drm_dp.h, which can be used by DRM core components. The existing header drm_dp_helper.h now only contains helper code for graphics drivers. No functional changes. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Thomas Zimmermann authored
Replace the DP-helper module with a display-helper module. The support for DisplayPort becomes an internal option that drivers have to select. Update all related Kconfig and Makefile rules. Besides the existing code for DisplayPort, the new module will contain helpers for other video-output standards, such as HDMI. Drivers will have to select their required video-output helpers. Linking all display-related code into a single module avoids the proliferation of small kernel modules. The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz, and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace to drm_display_helper. v2: * mention module parameters in commit message (Javier) * distiguish between display module and DP support in Kconfig * update Makefile rules for DP helpers * move Kconfig rules into separate file under display/ Signed-off-by:
-
Thomas Zimmermann authored
Rename dp/ to display/ to account for additional display-related helpers, such as HDMI. Update all related include statements. No functional changes. Various drivers, such as i915 and amdgpu, use similar naming scheme by putting code for video-output standards into a local display/ directory. The new directory's name is aligned with this convention. v2: * update commit message (Javier) Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Give the Makefile a bit more structure by putting rules for core, helpers, drivers, etc next to each other. Signed-off-by:
-
Chunguang Xu authored
Fix typos in comment. Signed-off-by:
Chunguang Xu <brookxu@tencent.com> Signed-off-by:
Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/1650625751-32137-1-git-send-email-brookxu.cn@gmail.com
-
Marek Vasut authored
The DE signal is active high on this display, fill in the missing bus_flags. This aligns panel_desc with its display_timing . Fixes: a5d2ade6 ("drm/panel: simple: Add support for Innolux G070Y2-L01") Signed-off-by:
-
Marek Vasut authored
The check for mandatory DT properties width-mm and height-mm is now part of of_get_drm_panel_display_mode(), drop the redundant check from this driver. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220411004728.68203-2-marex@denx.de
-
Marek Vasut authored
All users of this function require width-mm/height-mm DT property to be present per their DT bindings, make width-mm/height-mm check mandatory. It is generally a good idea to specify panel dimensions, so userspace can configure e.g. scaling accordingly. Signed-off-by:
-
Marek Vasut authored
Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel support. Acked-by:
-
Marek Vasut authored
Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel compatible string. Acked-by:
-
- Apr 23, 2022
-
-
Zack Rusin authored
The buffer objects created by cotables were missing fence reservations. They are created from vmw_validation_res_validate which makes them miss the ttm_eu_reserve_buffers which is called from vmw_validation_bo_reserve. Cotables are the only resources which create a buffer object in the create callback so make sure the code also reserves the slots. Signed-off-by:
Zack Rusin <zackr@vmware.com> Co-developed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Tom Rix authored
Smatch reports this issue gv100.c:46:1: warning: symbol 'gv100_gsp' was not declared. Should it be static? gv100_gsp is only used in gv100.c so change its storage-class specifier to static. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
-
- Apr 22, 2022
-
-
Robert Foss authored
it6505 depends on DRM_DP_AUX_BUS, the kconfig for it6505 should reflect this dependency using 'select'. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Reported-by:
kernel test robot <lkp@intel.com> Suggested-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421131415.1289469-1-robert.foss@linaro.org
-
Javier Martinez Canillas authored
Learning about the DRM subsystem could be quite overwhelming for newcomers but there are lots of useful talks, slides and articles available that can help to understand the needed concepts and ease the learning curve. There are also simple DRM drivers that can be used as example about how a DRM driver should look like. Add sections to the introduction page, that contains references to these. Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
-
José Expósito authored
Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead and also remove sun4i_hdmi.hdmi_monitor as it is no longer necessary. Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220421170725.903361-6-jose.exposito89@gmail.com
-
kernel test robot authored
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c:80:5-8: Unneeded variable: "ret". Return "0" on line 94 drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c:105:5-8: Unneeded variable: "ret". Return "0" on line 112 Remove unneeded variable used to store return value. Generated by: scripts/coccinelle/misc/returnvar.cocci CC: Sandor Yu <Sandor.yu@nxp.com> Reported-by:
Sandor Yu <Sandor.yu@nxp.com> Reviewed-by:
-
- Apr 21, 2022
-
-
Yang Wang authored
simplify programming with existing functions. v2 (chk): minimal coding style cleanup Signed-off-by:
Yang Wang <KevinYang.Wang@amd.com> Reviewed-by:
-
Miaoqian Lin authored
In the error handling path, the clk_prepare_enable() function call should be balanced by a corresponding 'clk_disable_unprepare()' call, as already done in the remove function. Fixes: 3424e3a4 ("drm: bridge: analogix/dp: split exynos dp driver to bridge directory") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
-
Christian König authored
We just need to reserve one BO here, no need for using ttm_eu to reserve multiple BOs. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419141915.122157-2-christian.koenig@amd.com
-
Christian König authored
We just need to reserve one BO here, no need for using ttm_eu to reserve multiple BOs. Signed-off-by:
-
José Expósito authored
The vc4_hdmi_encoder struct was used exclusively to cache the value returned by drm_detect_hdmi_monitor() in order to avoid calling it multiple times. Now that drm_detect_hdmi_monitor() has been replaced with drm_display_info.is_hdmi, there is no need to have an extra struct. Remove vc4_hdmi_encoder. Signed-off-by:
-
José Expósito authored
Once EDID is parsed, the monitor HDMI support information is cached in drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video(). This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value in vc4_hdmi_encoder.hdmi_monitor, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead. This also allows to remove vc4_hdmi_encoder.hdmi_monitor. drm_detect_hdmi_monitor() is called in vc4_hdmi_connector_detect() and vc4_hdmi_connector_get_modes(). In both cases it is safe to rely on drm_display_info.is_hdmi as shown by ftrace: $ sudo trace-cmd record -p function_graph -l "vc4_hdmi_*" -l "drm_*" vc4_hdmi_connector_detect: vc4_hdmi_connector_detect() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ } vc4_hdmi_connector_get_modes: vc4_hdmi_connector_get_modes() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ drm_connector_update_edid_property(); } Signed-off-by: -
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
-
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
-
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. It's exactly the same functionality but the debugfs code is shared with other drivers. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
-
Zack Rusin authored
Use the newly added TTM's ability to automatically create debugfs entries for specified placements. This creates debugfs files that can be read to get information about various TTM resource managers which are used by vmwgfx. Signed-off-by:
-
Zack Rusin authored
Drivers duplicate the code required to add debugfs entries for various ttm resource managers. To fix it add common TTM resource manager debugfs code that each driver can reuse. Specific resource managers can overwrite ttm_resource_manager_func::debug to get more information from those debugfs entries. Signed-off-by:
-
Javier Martinez Canillas authored
The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI. There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory. But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data. For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-6-javierm@redhat.com
-
Javier Martinez Canillas authored
These are declared in the ssd130x-i2c transport driver but the information is not I2C specific, and could be used by other SSD130x transport drivers. Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device info from an array. While being there, also move the SSD130X_DATA and SSD130X_COMMAND control bytes. Since even though they are used by the I2C interface, they could also be useful for other transport protocols such as SPI. Suggested-by:
Chen-Yu Tsai <wens@kernel.org> Signed-off-by:
-
Javier Martinez Canillas authored
The current compatible strings for SSD130x I2C controllers contain an "fb" and "-i2c" suffixes. These have been deprecated and more correct ones were added, that don't encode a subsystem or bus used to interface the devices. Signed-off-by:
-
Javier Martinez Canillas authored
The Solomon SSD130x OLED displays can either have an I2C or SPI interface, add to the schema the properties and examples for OLED devices under SPI. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-3-javierm@redhat.com
-
Javier Martinez Canillas authored
The current compatible strings for SSD130x I2C controllers contain both an "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver and also that are for devices that can be accessed over an I2C bus. But a DT is supposed to describe the hardware and not Linux implementation details. So let's deprecate those compatible strings and add new ones that only contain the vendor and device name, without any of these suffixes. These will just describe the device and can be matched by both I2C and SPI DRM drivers. The required properties should still be enforced for old ones. While being there, just drop the "sinowealth,sh1106-i2c" compatible string since that was never present in a released Linux version. Signed-off-by:
-
- Apr 20, 2022
-
-
Thomas Zimmermann authored
A workaround makes fbdev hot-unplugging work for framebuffers without device. The only user for this feature was offb. As each OF framebuffer now has an associated platform device, the workaround hould no longer be triggered. Update it with a warning and rewrite the comment. Fbdev drivers that trigger the hot-unplug workaround really need to be fixed. Signed-off-by:
-
Thomas Zimmermann authored
Create a platform device for each OF-declared framebuffer and have offb bind to these devices. Allows for real hot-unplugging and other drivers besides offb. Originally, offb created framebuffer devices while initializing its module by parsing the OF device tree. No actual Linux device was set up. This tied OF framebuffers to offb and makes writing other drivers for the OF framebuffers complicated. The absence of a Linux device further prevented real hot-unplugging. Adding a distinct platform device for each OF framebuffer solves both problems. Specifically, a DRM driver can now provide graphics output for modern userspace. Some of the offb init code is now located in the OF initialization. There's now also an implementation of of_platform_default_populate_init(), which was missing before. The OF side creates different devices for either OF display nodes or BootX displays as they require different handling by the driver. The offb drivers picks up each type of device and runs the appropriate fbdev initialization. Tested with OF display nodes on qemu's ppc64le target. v3: * declare variable 'node' with function scope (Rob) v2: * run PPC code as part of existing initialization (Rob) * add a few more error warnings (Javier) Signed-off-by:
-
