- 11 Jan, 2023 3 commits
-
-
Javier Martinez Canillas authored
There are macros for these already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macros defined in the driver. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230107191822.3787147-2-javierm@redhat.com
-
Abel Vesa authored
Add an eDP panel entry for IVO M133NW4J. Due to lack of documentation, use the delay_200_500_p2e100 timings like some other IVO entries for now. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Abel Vesa authored
The actual name is R133NW4K-R0. Fixes: 0f9fa5f5 ("drm/panel-edp: add IVO M133NW4J-R3 panel entry") Signed-off-by:
Steev Klimaszewski <steev@kali.org> Reviewed-by:
-
- 10 Jan, 2023 22 commits
-
-
Siddh Raman Pant authored
drm_print.h says DRM_DEBUG_LEASE is deprecated in favor of drm_dbg_lease(). Signed-off-by:
Siddh Raman Pant <code@siddh.me> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Siddh Raman Pant authored
drm_print.h says DRM_DEBUG_ATOMIC is deprecated in favor of drm_dbg_atomic(). Signed-off-by:
-
Siddh Raman Pant authored
drm_print.h says DRM_DEBUG_PRIME is deprecated in favor of drm_dbg_prime(). Signed-off-by:
-
Uwe Kleine-König authored
The driver core takes care about removing driver data, so this can be dropped from the driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by:
-
Uwe Kleine-König authored
dcss_drv_platform_remove() is only called for a device after dcss_drv_platform_probe() returned 0. In that case dev_set_drvdata() was called with a non-NULL value and so dev_get_drvdata() won't return NULL. Signed-off-by:
-
Maíra Canal authored
The structs drm_debugfs_info and drm_debugfs_entry don't have descriptions for their parameters, which is causing the following warnings: include/drm/drm_debugfs.h:93: warning: Function parameter or member 'name' not described in 'drm_debugfs_info' include/drm/drm_debugfs.h:93: warning: Function parameter or member 'show' not described in 'drm_debugfs_info' include/drm/drm_debugfs.h:93: warning: Function parameter or member 'driver_features' not described in 'drm_debugfs_info' include/drm/drm_debugfs.h:93: warning: Function parameter or member 'data' not described in 'drm_debugfs_info' include/drm/drm_debugfs.h:105: warning: Function parameter or member 'dev' not described in 'drm_debugfs_entry' include/drm/drm_debugfs.h:105: warning: Function parameter or member 'file' not described in 'drm_debugfs_entry' include/drm/drm_debugfs.h:105: warning: Function parameter or member 'list' not described in 'drm_debugfs_entry' Therefore, fix the warnings by adding descriptions to all struct parameters. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230105193039.287677-2-mcanal@igalia.com
-
Maíra Canal authored
Currently, debugfs functions are using symbolic macros as permission bits, but checkpatch reinforces permission bits in the octal form, as they are more readable and easier to understand [1]. Moreover, using the symbolic macro S_IFREG is redundant. Therefore, use octal permission bits in all debugfs functions. [1] https://docs.kernel.org/dev-tools/checkpatch.html#permissionsSuggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Javier Martinez Canillas authored
Add myself as maintainer for the driver and devicetree bindings schema. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230102230733.3506624-4-javierm@redhat.com
-
Kamil Trzciński authored
The driver is for panels based on the Himax HX8394 controller, such as the HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface. Signed-off-by:
Kamil Trzciński <ayufan@ayufan.eu> Co-developed-by:
Ondrej Jirman <megi@xff.cz> Signed-off-by:
Tom Fitzhenry <tom@tom-fitzhenry.me.uk> Tested-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
-
Javier Martinez Canillas authored
Add device tree bindings for panels based on the Himax HX8394 controller, such as the HannStar HSD060BHW4 720x1440 TFT LCD panel that is connected through a MIPI-DSI video interface. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Simon Ser authored
The code 'b' is used for dma-buf IOCTLs. Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221128133853.355645-1-contact@emersion.fr
-
Uwe Kleine-König authored
The driver doesn't make use of any symbol provided by <linux/i2c.h>. So drop the include. Signed-off-by:
-
Uwe Kleine-König authored
The listed address doesn't work any more: puck.chen@hisilicon.com host mx5.hisilicon.com [124.71.93.234] SMTP error from remote mail server after RCPT TO:<puck.chen@hisilicon.com>: 551 5.1.1 <puck.chen@hisilicon.com>: Recipient address rejected: Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command) Signed-off-by: -
Uwe Kleine-König authored
While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even though only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
Ignoring errors from devm_clk_get() is wrong. To handle not all platforms having an axi clk use devm_clk_get_optional() instead and do proper error handling. Also the clk API handles NULL as a dummy clk (which is also returned by devm_clk_get_optional() if there is no clk) so there is no need to check for NULL before calling clk_prepare_enable() or its counter part. Signed-off-by:
-
Marek Szyprowski authored
devm_regulator_get_enable_optional() function returns 0 on success, so use it for the check if function succeeded instead of the -ENODEV value. Fixes: 429e8706 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
- 09 Jan, 2023 15 commits
-
-
Neil Armstrong authored
Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel found on the Qualcomm SM8550 MTP board. By default the the panel is configured to work with DSI compressed streams, but can work in uncompressed video mode since 1080x2400 in RGB888 fits in the 4 DSI lanes bandwidth. While display compression is preferred for performance and power reasons, let's start with the uncompressed video mode support and add the DSC support later on. Reviewed-by:
-
Neil Armstrong authored
Document the 1080x2400 Visionox VTDR6130 AMOLED DSI Panel bindings. Reviewed-by:
-
Mateusz Kwiatkowski authored
The VEC is able to output progressive analog modes, but the driver has never set the proper bit to do so. Signed-off-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-15-1f8e0770798b@cerno.techSigned-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Dave Stevenson authored
The back porch timings were correct, only the sync offset was wrong. Correct timing is now reported for 1080i and 576i, but the h offset is incorrect for 480i for non-obvious reasons. Fixes: fb10dc45 ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-14-1f8e0770798b@cerno.techSigned-off-by:
-
Mateusz Kwiatkowski authored
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Changes to vc4_crtc.c have also been made, to make the PixelValve vertical timings accurately correspond to the DRM modeline in interlaced modes. The resulting VERTA/VERTB register values have been verified against the reference values set by the Raspberry Pi firmware. Signed-off-by: -
Dave Stevenson authored
The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx modes, so add comments to make this obvious. Signed-off-by:
-
Dave Stevenson authored
The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats, but the table of supported formats didn't include them. Add them in. In theory they are supported for T-format as well as linear, but without a way to test them just add them as linear for now. Signed-off-by:
-
Dave Stevenson authored
pixel_order is used for the earlier versions of the HVS, so is redundant on the 10:10:10:2 and 10bit YUV formats that are only supported on HVS5. Remove the assignment from the table to avoid confusion. Signed-off-by:
-
Dave Stevenson authored
vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5 was non-zero, except 0 is a valid value for the pixel_order. Specify pixel_order_hvs5 for all formats and remove the conditional. Signed-off-by:
-
Maxime Ripard authored
atomic_flush will be called for each CRTC even if they aren't enabled. The whole code we have there will thus run without a properly affected channel, which can then result in all sorts of weird behaviour. Reviewed-by:
-
Dave Stevenson authored
HVS5 supports the 210101010 RGB[A|X] formats, but they were missing from the DRM to HVS mapping list, so weren't available. Add them in. Signed-off-by:
-
Dave Stevenson authored
Same as the xRGB8888 formats, HVS5 has managed to swap the colour channels for the xRGB1555 formats as well. Add the relevant config for pixel_order_hvs5. Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by:
-
Dave Stevenson authored
Adds the zpos property to all planes, and creates the dlist by placing the fragments in the correct order based on zpos. Signed-off-by:
-
Dave Stevenson authored
HVS5 has moved the interrupt enable bits around within the DISPCTRL register, therefore the configuration has to be updated to account for this. Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by:
-
Dave Stevenson authored
The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX has been repurposed on HVS5 to configure whether a display can win back-to-back arbitration wins for the COB. This is not desirable, therefore only select this bit on HVS4, and explicitly clear it on HVS5. Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by:
-
