- 31 May, 2023 3 commits
-
-
Dmitry Baryshkov authored
In preparation to adding support for the hdmi_pwr supply, rename dp_pwr structure field to the generic connector_pwr. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230531000259.3758235-3-dmitry.baryshkov@linaro.org
-
Dmitry Baryshkov authored
Follow the dp-connector example and add hdmi-pwr supply to drive the 5V pin of the HDMI connector (together with some simple glue logic possibly attached to the connector). Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. panel_edp_remove() always returned zero, so convert it to return void without any loss and then just drop the return from panel_edp_platform_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 30 May, 2023 2 commits
-
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("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:
Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Martyn Welch <martyn.welch@collabora.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Adam Ford authored
In the event a device is connected to the samsung-dsim controller that doesn't support the burst-clock, the driver is able to get the requested pixel clock from the attached device or bridge. In these instances, the samsung,burst-clock-frequency isn't needed, so remove it from the required list. The pll-clock frequency can be set by the device tree entry for samsung,pll-clock-frequency, but in some cases, the pll-clock may have the same clock rate as sclk_mipi clock. If they are equal, this flag is not needed since the driver will use the sclk_mipi rate as a fallback. Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
-
- 26 May, 2023 20 commits
-
-
Liu Ying authored
With all previous preparations done to make it possible for the single LCDIF embedded in i.MX93 SoC to drive multiple displays simultaneously, add i.MX93 LCDIF compatible string as the last step of adding i.MX93 LCDIF support. Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
-
Liu Ying authored
The single LCDIF embedded in i.MX93 SoC may drive multiple displays simultaneously. Look at LCDIF output port's remote port parents to find all enabled first bridges. Add an encoder for each found bridge and attach the bridge to the encoder. This is a preparation for adding i.MX93 LCDIF support. Tested-by:
-
Liu Ying authored
The single LCDIF embedded in i.MX93 SoC may drive multiple displays simultaneously. Check bus format and flags across first bridges in ->atomic_check() to ensure they are consistent. This is a preparation for adding i.MX93 LCDIF support. Acked-by:
-
Liu Ying authored
Instead of determining LCDIF output bus format and bus flags in ->atomic_enable(), do that in ->atomic_check(). This is a preparation for the upcoming patch to check consistent bus format and bus flags across all first downstream bridges in ->atomic_check(). New lcdif_crtc_state structure is introduced to cache bus format and bus flags states in ->atomic_check() so that they can be read in ->atomic_enable(). Tested-by:
-
Liu Ying authored
A valid bridge is already found in lcdif_attach_bridge() and set to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop the unnecessary NULL pointer check in KMS stage. Tested-by:
-
Liu Ying authored
There is one LCDIF embedded in i.MX93 SoC to connect with MIPI DSI controller through LCDIF cross line pattern(controlled by mediamix blk-ctrl) or connect with LVDS display bridge(LDB) directly or connect with a parallel display through parallel display format(also controlled by mediamix blk-ctrl). i.MX93 LCDIF IP is essentially the same to i.MX8MP LCDIF IP. Add device tree binding for i.MX93 LCDIF. Acked-by:
-
Raphael Gallais-Pou authored
In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a container_of() before the pointer check. This could cause a kernel panic. Fix this smatch warning: drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119) Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/Reported-by:
Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/Signed-off-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by:
Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by:
-
Yang Li authored
Convert platform_get_resource(),devm_ioremap_resource() to a single call to devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Acked-by:
-
Neil Armstrong authored
This reverts commit cfaf76d3 which was applied without review due to a bad tool manipulation. Acked-by:
-
Dario Binacchi authored
The previous setting was related to the overall dimension and not to the active display area. In the "PHYSICAL SPECIFICATIONS" section, the datasheet shows the following parameters: ---------------------------------------------------------- | Item | Specifications | unit | ---------------------------------------------------------- | Display area | 98.7 (W) x 57.5 (H) | mm | ---------------------------------------------------------- | Overall dimension | 105.5(W) x 67.2(H) x 4.96(D) | mm | ---------------------------------------------------------- Fixes: 966fea78 ("drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H") Signed-off-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by:
-
Geert Uytterhoeven authored
Add support for the Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
Geert Uytterhoeven authored
Document support for the Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel. Signed-off-by:
-
Adam Ford authored
In the event a device is connected to the samsung-dsim controller that doesn't support the burst-clock, the driver is able to get the requested pixel clock from the attached device or bridge. In these instances, the samsung,burst-clock-frequency isn't needed, so remove it from the required list. The pll-clock frequency can be set by the device tree entry for samsung,pll-clock-frequency, but in some cases, the pll-clock may have the same clock rate as sclk_mipi clock. If they are equal, this flag is not needed since the driver will use the sclk_mipi rate as a fallback. Signed-off-by:
-
Adam Ford authored
The high-speed clock is hard-coded to the burst-clock frequency specified in the device tree. However, when using devices like certain bridge chips without burst mode and varying resolutions and refresh rates, it may be necessary to set the high-speed clock dynamically based on the desired pixel clock for the connected device. This also removes the need to set a clock speed from the device tree for non-burst mode operation, since the pixel clock rate is the rate requested from the attached device like a bridge chip. This should have no impact for people using burst-mode and setting the burst clock rate is still required for those users. If the burst clock is not present, change the error message to dev_info indicating the clock use the pixel clock. Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Adam Ford authored
The DPHY timings are currently hard coded. Since the input clock can be variable, the phy timings need to be variable too. To facilitate this, we need to cache the hs_clock based on what is generated from the PLL. The phy_mipi_dphy_get_default_config_for_hsclk function configures the DPHY timings in pico-seconds, and a small macro converts those timings into clock cycles based on the hs_clk. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by:
Michael Walle <michael@walle.cc> Tested-by:
-
Adam Ford authored
In order to support variable DPHY timings, it's necessary to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config can be used to determine the nominal values for a given resolution and refresh rate. Signed-off-by:
-
Adam Ford authored
Make the pll-clock-frequency optional. If it's present, use it to maintain backwards compatibility with existing hardware. If it is absent, read clock rate of "sclk_mipi" to determine the rate. Since it can be optional, change the message from an error to dev_info. Signed-off-by:
-
Adam Ford authored
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min and max values for M and the frequency range for the VCO_out calculator were incorrect. This information was contradicted in other parts of the mini, nano and plus manuals. After reaching out to my NXP Rep, when confronting him about discrepencies in the Nano manual, he responded with: "Yes it is definitely wrong, the one that is part of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is not correct. I will report this to Doc team, the one customer should be take into account is the Table 13-40 DPHY PLL Parameters and the Note above." These updated values also match what is used in the NXP downstream kernel. To fix this, make new variables to hold the min and max values of m and the minimum value of VCO_out, and update the PMS calculator to use these new variables instead of using hard-coded values to keep the backwards compatibility with other parts using this driver. Fixes: 4d562c70 ("drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support") Signed-off-by:
-
Lucas Stach authored
Scale the blanking packet sizes to match the ratio between HS clock and DPI interface clock. The controller seems to do internal scaling to the number of active lanes, so we don't take those into account. Signed-off-by:
-
Rob Clark authored
Fixes undefined symbol when PROC_FS is not enabled. Reported-by:
Rob Clark <robdclark@chromium.org> Reviewed-by: <alexander.deucher@amd.com> Signed-off-by:
-
- 25 May, 2023 3 commits
-
-
Frieder Schrempf authored
The datasheet describes the following initialization flow including minimum delay times between each step: 1. DSI data lanes need to be in LP-11 and the clock lane in HS mode 2. toggle EN signal 3. initialize registers 4. enable PLL 5. soft reset 6. enable DSI stream 7. check error status register To meet this requirement we need to make sure the host bridge's pre_enable() is called first by using the pre_enable_prev_first flag. Furthermore we need to split enable() into pre_enable() which covers steps 2-5 from above and enable() which covers step 7 and is called after the host bridge's enable(). Signed-off-by:
-
Frieder Schrempf authored
According to the documentation [1] the proper enable flow is: 1. Enable DSI link and keep data lanes in LP-11 (stop state) 2. Disable stop state to bring data lanes into HS mode Currently we do this all at once within enable(), which doesn't allow to meet the requirements of some downstream bridges. To fix this we now enable the DSI in pre_enable() and force it into stop state using the FORCE_STOP_STATE bit in the ESCMODE register until enable() is called where we reset the bit. We currently do this only for i.MX8M as Exynos uses a different init flow where samsung_dsim_init() is called from samsung_dsim_host_transfer(). [1] https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operationSigned-off-by:
-
Alexander Stein authored
This map was created from register map from datasheet (section 5.1.2). Unused registers are stated by address, so they show up in debugfs as well. Signed-off-by:
-
- 24 May, 2023 12 commits
-
-
Rob Clark authored
The restriction about no whitespace, etc, really only applies to the usage of strings in keys. Values can contain anything (other than newline). Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Rob Clark authored
Use the new helper to export stats about memory usage. v2: Drop unintended hunk v3: Rebase Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
-
Rob Clark authored
Add support to dump GEM stats to fdinfo. v2: Fix typos, change size units to match docs, use div_u64 v3: Do it in core v4: more kerneldoc v5: doc fixes v6: Actually use u64, bit more comment docs Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Rob Clark authored
v2: Rebase on drm-misc-next Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
-
Rob Clark authored
Now that we have a common helper, use it. v2: Rebase on drm-misc-next Signed-off-by:
-
Rob Clark authored
Handle a bit of the boiler-plate in a single case, and make it easier to add some core tracked stats. This also ensures consistent behavior across drivers for standardised fields. v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo v3: Rebase on drm-misc-next Reviewed-by:
-
Rob Clark authored
Fix a couple missing ':'s. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
-
Geert Uytterhoeven authored
The LCD Controller supported by the drm-shmob driver is present on SuperH SH-Mobile SoCs, and on Renesas ARM SH/R-Mobile SoCs. Unfortunately its config option is not visible on either, so the user can never enable the support. Fix this by dropping the dependency on ARM (for SuperH), and by widening the dependency range to ARCH_RENESAS (for ARM). Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Geert Uytterhoeven authored
Set up generic fbdev emulation, to enable support for the Linux console. Use 16 as the preferred depth, as that is a good compromise between colorfulness and resource utilization, and the default of the fbdev driver. Suggested-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Geert Uytterhoeven authored
The SH-Mobile DRM driver uses the legacy drm_crtc_init(), which advertizes only the formats in safe_modeset_formats[] (XR24 and AR24) as being supported. Switch to drm_crtc_init_with_planes(), and advertize all supported (A)RGB modes, so we can use RGB565 as the default mode for the console. Signed-off-by:
-
Geert Uytterhoeven authored
DRM_FORMAT_XRGB8888 aka XR24 is the modus francus of DRM, and should be supported by all drivers. The handling for DRM_FORMAT_XRGB8888 is similar to DRM_FORMAT_ARGB8888, just ignore the alpha channel. Signed-off-by:
-
Geert Uytterhoeven authored
Replace the printing of hexadecimal fourcc format codes by pretty-printed format names, using the "%p4cc" format specifier. Signed-off-by:
-
