aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2024-06-28drm/panel: simple: Add AUO G104STN01 panel entryPaul Gerber1-0/+27
Add support for the AUO G104STN01 10.4" (800x600) LCD-TFT panel. Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240627084446.3197196-3-paul.gerber@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240627084446.3197196-3-paul.gerber@ew.tq-group.com
2024-06-28dt-bindings: display: simple: Add AUO G104STN01 panelPaul Gerber1-0/+2
Add AUO G104STN01 10.4" LCD-TFT LVDS panel compatible string. Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240627084446.3197196-2-paul.gerber@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240627084446.3197196-2-paul.gerber@ew.tq-group.com
2024-06-27drm/bridge: analogix_dp: handle AUX transfer timeoutsLucas Stach2-0/+12
Timeouts on the AUX bus are to be expected in certain normal operating conditions. There is no need to raise an error log or re-initialize the whole AUX state machine. Simply acknowledge the AUX_ERR interrupt and let upper layers know about the timeout. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-14-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: only read AUX status when an error occuredLucas Stach1-4/+5
All AUX error responses raise the AUX_ERR interrupt, so there is no need to read the AUX status register in normal operation. Only read the status when an error occurred and we can expect a different status than OK. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-13-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: simplify and correct PLL lock checksLucas Stach3-35/+18
Move the wait loop into its own function, so it doesn't need to be replicated in multiple locations. Also move the PLL lock checks between setting the link bandwidth, which may cause the PLL to unlock, and the MACRO_RST which needs the PLL to be locked. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-12-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: don't wait for PLL lock too earlyLucas Stach1-13/+1
The PLL will be reconfigured later, which may cause it to go out of lock anyway, so there is no point in waiting for the PLL to lock here. Instead we can continue execution of the link setup, which will properly set the PLL parameters and will wait for the PLL to lock at the appropriate times. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-11-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: move macro reset after link bandwidth settingLucas Stach1-8/+10
Setting the link bandwidth may change the PLL parameters, which will cause the PLL to go out of lock, so make sure to apply the MACRO_RST, which according to the comment is required to be pulsed after the PLL is locked. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-10-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: remove PLL lock check from analogix_dp_config_videoLucas Stach1-5/+0
This check is way too late in the DP enable flow. The PLL must be locked much earlier, before any link training can happen. If the PLL is unlocked at that point in time there is something seriously wrong in the enable flow. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Robet Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-9-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: move basic controller init into runtime PMLucas Stach1-9/+5
Make sure the controller is in a basic working state after runtime resume. Keep the analog function enable in the mode set path as this enables parts of the PHY that are only required to be powered when there is a data stream being sent out. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-8-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: move platform and PHY power handling into runtime PMLucas Stach1-13/+10
Platform and PHY power isn't only required when the actual display data stream is active, but may be required earlier to support AUX channel transactions. Move them into the runtime PM calls, so they are properly managed whenever various other parts of the driver need them to be active. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-7-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: remove clk handling from analogix_dp_set_bridgeLucas Stach1-10/+1
The clock is already managed by runtime PM, which is properly invoked from the analogix_dp_set_bridge function, so there is no need for an additional reference. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-6-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: remove unused analogix_dp_removeLucas Stach4-17/+1
Now that the clock is handled dynamically through analogix_dp_resume/suspend and it isn't statically enabled in the driver probe routine, there is no need for the remove function anymore. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-5-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: handle clock via runtime PMLucas Stach1-33/+44
There is no reason to enable the controller clock in driver probe, as there is no HW initialization done in this function. Instead rely on either runtime PM to handle the controller clock or statically enable it in the driver bind routine, after which real hardware access is required to work. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-4-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: register AUX bus after enabling runtime PMLucas Stach1-8/+11
AUX transactions require the controller to be in working state and take a runtime PM reference. To avoid potential races beween the first transactions on the bus and runtime PM being set up, move the AUX registration behind the runtime PM setup. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-3-l.stach@pengutronix.de
2024-06-27drm/rockchip: analogix_dp: add runtime PM handlingLucas Stach1-9/+4
Hook up the runtime PM suspend/resume paths to make the rockchip glue behave more like the exynos one. The same suspend/resume functions are used for system sleep via the runtime PM force suspend/resume. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-2-l.stach@pengutronix.de
2024-06-27drm/bridge: analogix_dp: remove unused platform power_on_end callbackLucas Stach4-10/+6
This isn't used, but gives the impression of the power on and power off platform calls being non-symmetrical. Remove the unused callback and rename the power_on_start to simply power_on. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-1-l.stach@pengutronix.de
2024-06-27drm/panic: Restrict graphical logo handling to built-inGeert Uytterhoeven1-1/+1
When CONFIG_DRM_PANIC=y, but CONFIG_DRM=m: ld: drivers/gpu/drm/drm_panic.o: in function `drm_panic_setup_logo': drivers/gpu/drm/drm_panic.c:99: multiple definition of `init_module'; drivers/gpu/drm/drm_drv.o:drivers/gpu/drm/drm_drv.c:1079: first defined here Fix this by restricting the graphical logo handling and its device_initcall() to the built-in case. Logos are freed during late kernel initialization, so they are no longer available at module load time anyway. Fixes: 294bbd1f2697 ("drm/panic: Add support for drawing a monochrome graphical logo") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406261341.GYsbLpN1-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/4009fca99a7c05f617cc9899c6d0a5748415595d.1719391132.git.geert+renesas@glider.be
2024-06-27drm/panic: Do not select DRM_KMS_HELPERGeert Uytterhoeven2-2/+0
DRM core code cannot call into DRM helper code, as this would lead to circular references in the modular case. Hence drop the selection of DRM_KMS_HELPER. It was unused anyway, as v10 switched from using the DRM format helpers to its own color format conversion, cfr. commit 9544309775c3 ("drm/panic: Add support for color format conversion"). Remove the unneeded include of <drm/drm_format_helper.h>. Fixes: bf9fb17c6672 ("drm/panic: Add a drm panic handler") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/60155f8c939ed286e324a7c12a1daa69fe49fcf6.1719391132.git.geert+renesas@glider.be
2024-06-27Revert "drm/bridge: tc358767: Set default CLRSIPO count"Marek Vasut1-4/+4
This reverts commit 01338bb82fed40a6a234c2b36a92367c8671adf0. With clock improvements in place, this seems to be no longer necessary. Set the CLRSIPO to default setting recommended by manufacturer. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-5-marex@denx.de
2024-06-27drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1Marek Vasut1-1/+1
The only information in the datasheet regarding this divider is a note in SYS_PLLPARAM register documentation which states that when LSCLK is 270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test confirms using LSCLK_DIV 1 has no adverse effects either. In the worst case, the internal TC358767 clock would run faster. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-4-marex@denx.de
2024-06-27drm/bridge: tc358767: Drop line_pixel_subtractMarek Vasut1-20/+1
This line_pixel_subtract is no longer needed now that the bridge can request and obtain specific pixel clock on input to the bridge, with clock frequency that matches the Pixel PLL frequency. The line_pixel_subtract is now always 0, so drop it entirely. The line_pixel_subtract was not reliable as it never worked when the Pixel PLL and input clock were off just so that the required amount of pixels to subtract would not be whole integer. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-3-marex@denx.de
2024-06-27drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clockMarek Vasut1-0/+24
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and pass it down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-2-marex@denx.de
2024-06-27drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and enablementMarek Vasut1-7/+25
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc() and then configures the Pixel PLL register. This is a preparatory patch for further rework, where tc_pxl_pll_calc() will also be used to find out the exact clock frequency generated by the Pixel PLL. This frequency will be used as adjusted_mode clock frequency and passed down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-1-marex@denx.de
2024-06-27drm/ast: Inline drm_simple_encoder_init()Thomas Zimmermann1-5/+40
The function drm_simple_encoder_init() is a trivial helper and deprecated. Replace it with the regular call to drm_encoder_init(). Resolves the dependency on drm_simple_kms_helper.h. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625131815.14514-1-tzimmermann@suse.de
2024-06-26drm/panel: add Ilitek ILI9806E panel driverMichael Walle4-0/+417
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display controller. Co-developed-by: Gunnar Dibbern <gunnar.dibbern@lht.dlh.de> Signed-off-by: Gunnar Dibbern <gunnar.dibbern@lht.dlh.de> Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626144433.3097793-3-mwalle@kernel.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626144433.3097793-3-mwalle@kernel.org