On 1/7/25 6:38 AM, Liu Ying wrote:
On 01/06/2025, Marek Vasut wrote:
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
The output_port set to 1 makes the DW HDMI driver core look up the
next bridge in DT
On 1/6/25 8:05 AM, Laurent Pinchart wrote:
On Mon, Jan 06, 2025 at 03:48:52AM +0100, Marek Vasut wrote:
On 1/6/25 12:22 AM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Sun, Jan 05, 2025 at 08:06:03PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around
On 1/6/25 12:22 AM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Sun, Jan 05, 2025 at 08:06:03PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around broken i.MX8MP DTs which enable
HDMI but do not contain the HDMI connector node. This flag allows such
DTs
attach")
This makes LT9611 work with i.MX8M Plus.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil A
attach")
This makes LT9611 work with i.MX8M Mini.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil A
ld make systems
with DTs without HDMI connector node work, but such DTs should be updated and
the HDMI connector node should be added.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
C
emote-endpoint = <&hdmi_tx_out>;
};
};
};
};
&hdmi_tx {
...
ports {
port@1 {
hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
};
};
```
Signed-off-by: Marek Vasut
---
Cc:
On 1/2/25 5:55 AM, Dmitry Baryshkov wrote:
On Tue, Dec 31, 2024 at 08:28:49PM +0100, Marek Vasut wrote:
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
The output_port set to 1 makes the DW HDMI driver core
On 1/2/25 6:58 PM, Dmitry Baryshkov wrote:
[...]
@@ -97,13 +100,36 @@ static int lcdif_attach_bridge(struct lcdif_drm_private
*lcdif)
return ret;
}
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder,
On 1/1/25 11:36 PM, Laurent Pinchart wrote:
On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
On 12/31/24 9:31 PM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around
On 12/31/24 9:31 PM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around broken i.MX8MP DTs which enable
HDMI but do not contain the HDMI connector node. This flag allows such
DTs
: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Pengutronix Kernel Team
Cc: Robert Foss
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Simona
attach")
This makes LT9611 work with i.MX8M Plus.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil A
ld make systems
with DTs without HDMI connector node work, but such DTs should be updated and
the HDMI connector node should be added.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
C
attach")
This makes LT9611 work with i.MX8M Mini.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil A
On 12/30/24 8:04 AM, Ying Liu wrote:
On 12/26/2024, Marek Vasut wrote:
On 12/24/24 5:21 AM, Dmitry Baryshkov wrote:
On Tue, Dec 24, 2024 at 02:46:14AM +0100, Marek Vasut wrote:
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get
On 12/30/24 8:18 AM, Liu Ying wrote:
[...]
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 264e74f455547..07fb6901996ae 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -30,6 +30,7 @@ config DRM_IMX_LCDIF
select DRM_CLIEN
On 12/30/24 7:57 AM, Liu Ying wrote:
[...]
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 9a480c6abb856..d8e9fbf75edbb 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -27,6 +27,7 @@ config DRM_IMX8MP_DW_HDM
On 12/30/24 8:29 AM, Liu Ying wrote:
[...]
@@ -139,21 +140,35 @@ static int mxsfb_attach_bridge(struct mxsfb_drm_private
*mxsfb)
if (!bridge)
return -ENODEV;
- ret = drm_bridge_attach(&mxsfb->encoder, bridge, NULL, 0);
+ ret = drm_bridge_attach(&mxsfb->encoder
On 12/24/24 5:21 AM, Dmitry Baryshkov wrote:
On Tue, Dec 24, 2024 at 02:46:14AM +0100, Marek Vasut wrote:
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
The output_port set to 1 makes the DW HDMI driver
attach")
This makes LT9611 work with i.MX8M Plus.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil A
attach")
This makes LT9611 work with i.MX8M Mini.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Pengutronix Kernel
0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge
DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
attach")
This makes LT9611 work with i.MX8M Mini.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Pengutronix Kernel
attach")
This makes LT9611 work with i.MX8M Plus.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Pengutronix Kernel
0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge
DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Add Multi-Inno Technology MI1010Z1T-1CP11 10.1" 1024x600 LVDS panel support.
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: David Airlie
Cc: Jessica Zhang
Cc: Krzysztof Kozlowski
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: S
Add Multi-Inno Technology MI1010Z1T-1CP11 10.1" 1024x600 LVDS panel
compatible string.
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: David Airlie
Cc: Jessica Zhang
Cc: Krzysztof Kozlowski
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Rav
On 11/25/24 2:33 AM, Marek Vasut wrote:
Add Multi-Inno Technology MI0700A2T-30 7" 800x480 LVDS panel support.
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: David Airlie
Cc: Jessica Zhang
Cc: Krzysztof Kozlowski
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc
On 12/9/24 9:46 AM, Nikolaus Voss wrote:
Hi,
and store the panel's timing in EDID EEPROM.
Oh, that is a new one. Does the EDID EEPROM store the entirety of
'struct display_timing {}' somehow , or is that a custom format ?
Well, sort of ;-). VESA has taken care of this 30 years ago
(https://e
On 12/9/24 10:27 AM, Nikolaus Voss wrote:
On 07.12.2024 12:46, Marek Vasut wrote:
On 12/4/24 11:40 AM, Nikolaus Voss wrote:
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
Can you please share the content of /sys/kernel
On 12/4/24 11:55 AM, Nikolaus Voss wrote:
Hi Marek,
Hi,
I doubt that pixel clock tree cannot find appropriate division
ratios
for some pixel clock rates, especially for dual-link LVDS on i.MX8MP
and i.MX93 platforms, because PLL clock rate should be 7x faster
than
pixel clock rate and 2x f
On 12/4/24 11:40 AM, Nikolaus Voss wrote:
Hi,
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
Can you please share the content of /sys/kernel/debug/clk/clk_summary ?
Sure. Without my patch:
video_pll1_ref_sel
On 12/3/24 8:20 AM, Nikolaus Voss wrote:
On 03.12.2024 04:12, Marek Vasut wrote:
On 12/3/24 3:22 AM, Liu Ying wrote:
[...]
I doubt that pixel clock tree cannot find appropriate division ratios
for some pixel clock rates, especially for dual-link LVDS on i.MX8MP
and i.MX93 platforms, because
On 12/3/24 8:09 PM, Nikolaus Voss wrote:
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
Can you please share the content of /sys/kernel/debug/clk/clk_summary ?
LDB and matching LCDIF should use the same PLL on MX8MP , el
On 12/3/24 3:22 AM, Liu Ying wrote:
[...]
I doubt that pixel clock tree cannot find appropriate division ratios
for some pixel clock rates, especially for dual-link LVDS on i.MX8MP
and i.MX93 platforms, because PLL clock rate should be 7x faster than
pixel clock rate and 2x faster than "ldb" cl
On 12/2/24 6:03 PM, Nikolaus Voss wrote:
On 02.12.2024 13:56, Marek Vasut wrote:
On 12/2/24 7:32 AM, Liu Ying wrote:
On 11/27/2024, Nikolaus Voss wrote:
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
(at least on imx8mp
On 12/2/24 7:32 AM, Liu Ying wrote:
On 11/27/2024, Nikolaus Voss wrote:
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
(at least on imx8mp), this constraint cannot be satisfied for
any pixel clock, which leads to flickerin
On 11/26/24 4:56 PM, Maxime Ripard wrote:
On Tue, Nov 26, 2024 at 12:48:20AM +0100, Marek Vasut wrote:
On 11/22/24 2:32 PM, Dmitry Baryshkov wrote:
On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
The Pixel PLL is not very capable and may come up with wildly inaccurate
clock
On 11/25/24 2:17 PM, Maxime Ripard wrote:
On Fri, Nov 22, 2024 at 03:32:57PM +0200, Dmitry Baryshkov wrote:
On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
The Pixel PLL is not very capable and may come up with wildly inaccurate
clock. Since DPI panels are often tolerant to
On 11/22/24 2:32 PM, Dmitry Baryshkov wrote:
On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
The Pixel PLL is not very capable and may come up with wildly inaccurate
clock. Since DPI panels are often tolerant to slightly higher pixel clock
without being operated outside of
Add Multi-Inno Technology MI0700A2T-30 7" 800x480 LVDS panel support.
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: David Airlie
Cc: Jessica Zhang
Cc: Krzysztof Kozlowski
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Simona V
Add Multi-Inno Technology MI0700A2T-30 7" 800x480 LVDS panel
compatible string.
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: David Airlie
Cc: Jessica Zhang
Cc: Krzysztof Kozlowski
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Ravnbor
The DSI host must be enabled for the panel to be initialized in
prepare(). Set the prepare_prev_first flag to guarantee this.
This fixes the panel operation on NXP i.MX8MP SoC / Samsung DSIM
DSI host.
Fixes: 849b2e3ff969 ("drm/panel: Add Sitronix ST7701 panel driver")
Signed-off-by: M
On 11/22/24 4:39 AM, Ying Liu wrote:
On 11/22/24, Marek Vasut wrote:
On 11/20/24 7:38 AM, Ying Liu wrote:
[...]
If the DP monitors support typical video modes like 1080p60 with
148.5MHz pixel clock rate, I assume these typical video modes work
still ok with this patch at least. Please help
On 11/20/24 7:38 AM, Ying Liu wrote:
[...]
If the DP monitors support typical video modes like 1080p60 with
148.5MHz pixel clock rate, I assume these typical video modes work
still ok with this patch at least. Please help confirm this, since if the
alternative solution(*) doesn't stand, we wou
I'll stop this thread, let's continue the discussion in one place in:
[PATCH v7 2/7] Revert "clk: imx: clk-imx8mp: Allow media_disp pixel
clock reconfigure parent rate"
On 11/19/24 9:18 AM, Ying Liu wrote:
[...]
The TC9595 can drive an DP output, for that the clock which have to be
set on the LCDIF cannot be predicted, as that information comes from the
monitor EDID/DPCD. That is why the LCDIF has to be able to configure the
Video PLL1 clock to accurate clock
On 11/18/24 4:54 AM, Ying Liu wrote:
Hi Marek,
Hi,
media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
display controller, while media_disp2_pix clock is the pixel clock of
the second i.MX8MP LCDIFv3 display controller. The two display
controllers connect with Samsung MIPI
On 11/18/24 4:19 PM, Maxime Ripard wrote:
On Mon, Oct 28, 2024 at 03:49:42PM +0100, Marek Vasut wrote:
On 10/28/24 2:52 PM, Maxime Ripard wrote:
On Mon, Oct 28, 2024 at 01:36:58PM +0100, Marek Vasut wrote:
On 10/28/24 10:25 AM, Maxime Ripard wrote:
On Sat, Oct 26, 2024 at 06:10:01AM +0200
On 11/14/24 10:27 AM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Samstag, 26. Oktober 2024, 06:10:42 CET schrieb Marek Vasut:
The driver configures mostly Pixel PLL from the clock cached in
local copy of the mode. Make sure the driver uses adjusted mode
which contains the updated Pixel PLL
On 11/14/24 7:57 AM, Liu Ying wrote:
This reverts commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155.
media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
display controller, while media_disp2_pix clock is the pixel clock of
the second i.MX8MP LCDIFv3 display controller. The two d
clock, the frequency
without this patch is 65 MHz which is out of the panel specification of
68.9..73.4 MHz, while with this patch it is 71.5 MHz which is well within
the specification and far more accurate.
Keep the change isolated to DPI output.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Add drm_bridge_get_panel() function to extract drm_panel pointer from
panel_bridge. This can be used by bridges in the middle to look up and
access drm_panel at the end, and e.g. extract display_timings from it.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Jernej
On 10/29/24 8:16 PM, Fabio Estevam wrote:
From: Fabio Estevam
mx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:
compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.
['fsl,imx6sl-lcdif'
On 10/28/24 2:52 PM, Herve Codina wrote:
Hi Marek,
Hi,
On Sat, 26 Oct 2024 00:53:51 +0200
Marek Vasut wrote:
On 10/24/24 11:55 AM, Herve Codina wrote:
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
from errors by itself. A full restart of the bridge is needed
On 10/28/24 2:52 PM, Maxime Ripard wrote:
On Mon, Oct 28, 2024 at 01:36:58PM +0100, Marek Vasut wrote:
On 10/28/24 10:25 AM, Maxime Ripard wrote:
On Sat, Oct 26, 2024 at 06:10:01AM +0200, Marek Vasut wrote:
Horizontal Timing Control0 Register 1/2 (HTIM01/HTIM02) Register
bitfields description
On 10/28/24 10:25 AM, Maxime Ripard wrote:
On Sat, Oct 26, 2024 at 06:10:01AM +0200, Marek Vasut wrote:
Horizontal Timing Control0 Register 1/2 (HTIM01/HTIM02) Register
bitfields description state "These bits must be multiple of even
pixel". It is not possible to simply align every b
On 10/28/24 9:02 AM, Herve Codina wrote:
Hi Marek,
Hi,
On Sat, 26 Oct 2024 00:53:51 +0200
Marek Vasut wrote:
On 10/24/24 11:55 AM, Herve Codina wrote:
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
from errors by itself. A full restart of the bridge is needed in
, while with this patch it is 71.5 MHz which is well within
the specification and far more accurate.
Keep the change isolated to DPI output.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc
n. Instead, attempt to re-align the timings
such that the hardware requirement is fulfilled without changing
the line width if at all possible.
Warn the user in case a panel with odd active pixel width or full
line width is used, this is not possible to support with this one
bridge.
Signed-off-by: M
On 10/24/24 11:55 AM, Herve Codina wrote:
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
from errors by itself. A full restart of the bridge is needed in those
cases to have the bridge output LVDS signals again.
I have seen the bridge being flaky sometimes, do you have
, while with this patch it is 71.5 MHz which is well within
the specification and far more accurate.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert
The driver configures mostly Pixel PLL from the clock cached in
local copy of the mode. Make sure the driver uses adjusted mode
which contains the updated Pixel PLL settings negotiated in
tc_dpi_atomic_check()/tc_edp_atomic_check().
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: David
On 10/22/24 7:59 AM, Liu Ying wrote:
[...]
Anyway, I don't think it is necessary to manage the clk_set_rate()
function calls between this driver and mxsfb_kms or lcdif_kms
because "video_pll1" clock rate is supposed to be assigned in DT...
I disagree with this part. I believe the assignment o
On 10/22/24 8:13 AM, Liu Ying wrote:
[...]
This patch would cause the below in-flight LDB bridge driver
patch[1] fail to do display mode validation upon display modes
read from LVDS to HDMI converter IT6263's DDC I2C bus.
Why ?
Mode validation is affected only for dual LVDS link mode.
For s
On 10/21/24 1:48 PM, Maxime Ripard wrote:
On Sun, Oct 20, 2024 at 04:49:29AM +0200, Marek Vasut wrote:
On 10/19/24 11:49 PM, Kieran Bingham wrote:
Quoting Marek Vasut (2024-10-12 21:37:59)
On 10/11/24 5:10 AM, Liu Ying wrote:
Hi,
This Video PLL1 configuration since moved to &media_blk_
On 10/21/24 1:10 PM, Kieran Bingham wrote:
Quoting Marek Vasut (2024-10-20 03:49:29)
On 10/19/24 11:49 PM, Kieran Bingham wrote:
Quoting Marek Vasut (2024-10-12 21:37:59)
On 10/11/24 5:10 AM, Liu Ying wrote:
Hi,
This Video PLL1 configuration since moved to &media_blk_ctrl {} , but i
On 10/19/24 11:49 PM, Kieran Bingham wrote:
Quoting Marek Vasut (2024-10-12 21:37:59)
On 10/11/24 5:10 AM, Liu Ying wrote:
Hi,
This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is
still in the imx8mp.dtsi . Therefore, to make your panel work at the correct
des
On 10/18/24 11:00 AM, Liu Ying wrote:
On 10/18/2024, Marek Vasut wrote:
On 10/18/24 8:48 AM, Liu Ying wrote:
Add a HDMI connector to connect with i.MX8MP HDMI TX output.
This is a preparation for making the i.MX8MP LCDIF driver use
drm_bridge_connector which requires the
On 10/18/24 8:48 AM, Liu Ying wrote:
Add a HDMI connector to connect with i.MX8MP HDMI TX output.
This is a preparation for making the i.MX8MP LCDIF driver use
drm_bridge_connector which requires the DRM_BRIDGE_ATTACH_NO_CONNECTOR
flag. With that flag, the DW HDMI bridge core driver would
try to
< 0 || tc->pre_emphasis[1] > 2)
{
dev_err(dev, "Incorrect Pre-Emphasis setting, use
either 0=0dB 1=3.5dB 2=6dB\n");
+ of_node_put(node);
return -EINVAL;
Right, thanks!
Reviewed-by: Marek Vasut
On 10/11/24 8:49 AM, Liu Ying wrote:
On 10/11/2024, Marek Vasut wrote:
On 10/10/24 9:15 AM, Liu Ying wrote:
On 10/09/2024, Marek Vasut wrote:
The LDB serializer clock operate at either x7 or x14 rate of the input
Isn't it either x7 or 3.5x?
Is it 3.5 for the dual-link LVDS ?
On 10/11/24 8:18 AM, Liu Ying wrote:
On 10/11/2024, Marek Vasut wrote:
On 10/10/24 7:22 AM, Liu Ying wrote:
On 10/09/2024, Marek Vasut wrote:
The media_ldb_root_clk supply LDB serializer. These clock are usually
shared with the LCDIFv3 pixel clock and supplied by the Video PLL on
i.MX8MP, but
On 10/11/24 5:10 AM, Liu Ying wrote:
Hi,
This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is
still in the imx8mp.dtsi . Therefore, to make your panel work at the correct
desired pixel clock frequency instead of some random one inherited from
imx8mp.dtsi, add the follo
On 10/12/24 9:35 AM, Liu Ying wrote:
Add a panel-timing node to panel-lvds node to override any fixed
display modes written in a panel driver. This way, 74.25MHz clock
frequency specified in panel-timing node may accommodate 7-fold
519.75MHz "media_ldb" clock which is derived from 1.0395GHz
"vid
On 10/12/24 9:35 AM, Liu Ying wrote:
Add a panel-timing node to panel node to override any fixed display
modes written in a panel driver. This way, 68.9MHz clock frequency
specified in panel-timing node may accommodate 7-fold 482.3MHz
"media_ldb" clock which is derived from 964.6MHz "video_pll1"
On 10/10/24 9:15 AM, Liu Ying wrote:
On 10/09/2024, Marek Vasut wrote:
The LDB serializer clock operate at either x7 or x14 rate of the input
Isn't it either x7 or 3.5x?
Is it 3.5 for the dual-link LVDS ?
I don't have such a panel right now to test.
[...]
diff --git a/drive
On 10/10/24 7:22 AM, Liu Ying wrote:
On 10/09/2024, Marek Vasut wrote:
The media_ldb_root_clk supply LDB serializer. These clock are usually
shared with the LCDIFv3 pixel clock and supplied by the Video PLL on
i.MX8MP, but the LDB clock run at either x7 or x14 rate of the LCDIFv3
pixel clock
On 10/10/24 7:31 AM, Liu Ying wrote:
Hi,
This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is
still in the imx8mp.dtsi . Therefore, to make your panel work at the correct
desired pixel clock frequency instead of some random one inherited from
imx8mp.dtsi, add the follo
On 10/9/24 5:58 PM, Isaac Scott wrote:
[...]
media_mipi_phy1_ref 0 0 0
23036364
0 0 5 N deviceless
no_co
media_mipi_phy1_ref_root 0 0 0
23036364 0 0 5 N
32ec.blk
On 10/9/24 1:40 PM, Abel Vesa wrote:
On 24-10-09 00:38:19, Marek Vasut wrote:
The media_ldb_root_clk supply LDB serializer. These clock are usually
shared with the LCDIFv3 pixel clock and supplied by the Video PLL on
i.MX8MP, but the LDB clock run at either x7 or x14 rate of the LCDIFv3
pixel
On 10/9/24 11:55 AM, Isaac Scott wrote:
On Tue, 2024-10-08 at 23:48 +0200, Marek Vasut wrote:
On 10/8/24 12:07 PM, Isaac Scott wrote:
On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut
On 10/9/24 12:27 PM, Isaac Scott wrote:
On Wed, 2024-10-09 at 00:38 +0200, Marek Vasut wrote:
The LDB serializer clock operate at either x7 or x14 rate of the
input
LCDIFv3 scanout engine clock. Make sure the serializer clock and
their
upstream Video PLL are configured early in .mode_set to the
accurate serializer clock.
Signed-off-by: Marek Vasut
---
Cc: Abel Vesa
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Isaac Scott
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Michael Turquette
Cc: Neil Armstrong
Cc: Peng Fan
0 5
media_disp2_pix 1 1 0 7110 0 0 5
media_disp2_pix_root_clk 1 1 0 7110 0 0 5
Signed-off-by: Marek Vasut
---
Cc: Abel Vesa
Cc: Andrzej Hajda
Cc: David Airlie
Cc: Fabio Estevam
Cc: Isaac Scott
Cc: Jernej Skrabec
Cc: Jonas Karlman
On 10/8/24 12:07 PM, Isaac Scott wrote:
On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
On 6/24/24 11:19 AM, Alexander Stein wrote:
Am Freitag, 31. Mai 2024, 22:27:21 CEST
On 10/8/24 12:07 PM, Isaac Scott wrote:
On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
On 6/24/24 11:19 AM, Alexander Stein wrote:
Am Freitag, 31. Mai 2024, 22:27:21 CEST
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
On 6/24/24 11:19 AM, Alexander Stein wrote:
Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
In case an upstream bridge modified the required clock frequency
in its
On 9/27/24 9:33 PM, Nicolas Dufresne wrote:
Le mercredi 25 septembre 2024 à 22:45 +0200, Marek Vasut a écrit :
On 9/25/24 7:58 PM, Nicolas Dufresne wrote:
[...]
+static irqreturn_t ipu_mem2mem_vdic_nfb4eof_interrupt(int irq, void *dev_id)
+{
+ struct ipu_mem2mem_vdic_priv *priv
On 9/26/24 1:14 PM, Philipp Zabel wrote:
Hi,
Hi,
On Mi, 2024-09-25 at 22:14 +0200, Marek Vasut wrote:
The userspace could distribute the frames between the two devices in an
alternating manner, can it not ?
This doesn't help with latency, or when converting a single large
frame.
Fo
On 9/26/24 1:16 PM, Philipp Zabel wrote:
On Mi, 2024-09-25 at 22:45 +0200, Marek Vasut wrote:
[...]
The driver is not taking ownership of prev_buf, only curr_buf is guaranteed to
exist until v4l2_m2m_job_finish() is called. Usespace could streamoff, allocate
new buffers, and then an old freed
On 9/25/24 7:58 PM, Nicolas Dufresne wrote:
Hi,
[...]
+static struct v4l2_pix_format *
+ipu_mem2mem_vdic_get_format(struct ipu_mem2mem_vdic_priv *priv,
+ enum v4l2_buf_type type)
+{
+ return &priv->fmt[V4L2_TYPE_IS_OUTPUT(type) ? V4L2_M2M_SRC :
V4L2_M2M_DST];
+
On 9/25/24 5:07 PM, Philipp Zabel wrote:
Hi,
On Di, 2024-09-24 at 17:28 +0200, Marek Vasut wrote:
On 9/6/24 11:01 AM, Philipp Zabel wrote:
[...]
Instead of presenting two devices to userspace, it would be better to
have a single video device that can distribute work to both IPUs.
Why do
On 9/25/24 6:43 PM, Philipp Zabel wrote:
On Di, 2024-09-24 at 12:47 +0200, Marek Vasut wrote:
On 9/4/24 11:05 AM, Philipp Zabel wrote:
On Mi, 2024-07-24 at 02:19 +0200, Marek Vasut wrote:
The 'code' parameter only ever selects between YUV 4:2:0 and 4:2:2
subsampling, turn it into
On 9/25/24 12:57 AM, Rob Herring wrote:
On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote:
On 9/23/24 3:57 PM, Lukasz Majewski wrote:
Up till now the fsl,lcdif.yaml was requiring the "port" property as a
must have to specify the display interface on iMX devices.
However
Instead, it would be better
to have two scaler nodes in userspace.
[...]
+++ b/drivers/staging/media/imx/imx-media-mem2mem-vdic.c
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * i.MX VDIC mem2mem de-interlace driver
+ *
+ * Copyright (c) 2024 Marek Vasut
+ *
+ * Based
On 7/30/24 6:05 PM, Nicolas Dufresne wrote:
Hi,
sorry for the abysmal delay.
Le mercredi 24 juillet 2024 à 02:19 +0200, Marek Vasut a écrit :
Introduce dedicated memory-to-memory IPUv3 VDI deinterlacer driver.
Currently the IPUv3 can operate VDI in DIRECT mode, from sensor to
memory. This
On 9/4/24 11:05 AM, Philipp Zabel wrote:
On Mi, 2024-07-24 at 02:19 +0200, Marek Vasut wrote:
The 'code' parameter only ever selects between YUV 4:2:0 and 4:2:2
subsampling, turn it into boolean to select exactly that and update
related code accordingly.
Signed-off-by: Marek Va
On 9/23/24 3:57 PM, Lukasz Majewski wrote:
Up till now the fsl,lcdif.yaml was requiring the "port" property as a
must have to specify the display interface on iMX devices.
However, it shall also be possible to specify the display only with
passing its timing parameters (h* and v* ones) via "disp
1 - 100 of 1229 matches
Mail list logo
