[PATCH 0/8] Some fixes for the rockchip dw_mipi_dsi driver
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
Please take a look.
Thank you and regards, Ondrej Jirman
Ondrej Jirman (8): video: rockchip: vop: Fix whitespace video: dw_mipi_dsi: Fix hsync/vsync settings video: rockchip: dw_mipi_dsi: Fix external phy existnece check video: rockchip: dw_mipi_dsi: Fix error path checks in probe function video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success video: rockchip: dw_mipi_dsi: Fix best_rate calculation video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle video: rockchip: dw_mipi_dsi: Fix GRF access
drivers/video/dw_mipi_dsi.c | 4 +- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++++++++++-------- drivers/video/rockchip/rk_vop.c | 2 +- 3 files changed, 25 insertions(+), 19 deletions(-)
From: Ondrej Jirman megi@xff.cz
Fix confusing use of indentation.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/rk_vop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c index dab9902fda73..c514e2a0e449 100644 --- a/drivers/video/rockchip/rk_vop.c +++ b/drivers/video/rockchip/rk_vop.c @@ -432,7 +432,7 @@ int rk_vop_probe(struct udevice *dev) ret = reset_assert(&ahb_rst); if (ret) { dev_err(dev, "failed to assert ahb reset (ret=%d)\n", ret); - return ret; + return ret; } udelay(20);
Hi Ondrej,
Thanks for you patches.
On 2023/5/23 05:47, megi@xff.cz wrote:
From: Ondrej Jirman megi@xff.cz
Fix confusing use of indentation.
Signed-off-by: Ondrej Jirman megi@xff.cz
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
drivers/video/rockchip/rk_vop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c index dab9902fda73..c514e2a0e449 100644 --- a/drivers/video/rockchip/rk_vop.c +++ b/drivers/video/rockchip/rk_vop.c @@ -432,7 +432,7 @@ int rk_vop_probe(struct udevice *dev) ret = reset_assert(&ahb_rst); if (ret) { dev_err(dev, "failed to assert ahb reset (ret=%d)\n", ret);
- return ret;
return ret;
From: Ondrej Jirman megi@xff.cz
These must be read from timings->flags, like other DSI HOST drivers do.
And they must not be inverted either. Low means low.
Without this fix, panel drivers that set *SYNC_LOW produce corrupted output on screen (shifted horizobnntally and vertivally by back porch distance).
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/dw_mipi_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c index 92e388ac1e42..22fef7e8825f 100644 --- a/drivers/video/dw_mipi_dsi.c +++ b/drivers/video/dw_mipi_dsi.c @@ -538,9 +538,9 @@ static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi, break; }
- if (device->mode_flags & DISPLAY_FLAGS_VSYNC_HIGH) + if (timings->flags & DISPLAY_FLAGS_VSYNC_LOW) val |= VSYNC_ACTIVE_LOW; - if (device->mode_flags & DISPLAY_FLAGS_HSYNC_HIGH) + if (timings->flags & DISPLAY_FLAGS_HSYNC_LOW) val |= HSYNC_ACTIVE_LOW;
dsi_write(dsi, DSI_DPI_VCID, DPI_VCID(dsi->channel));
From: Ondrej Jirman megi@xff.cz
&priv->phy is always true. Compiler warns about this loudly.
Use a propper check for phy device allocation. Without this fix using this driver with SoC that doesn't use external phy (eg. RK3399) doesn't work.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index ca548a60b750..b1b5328595e0 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -344,7 +344,7 @@ static int dsi_phy_init(void *priv_data) struct dw_rockchip_dsi_priv *dsi = dev_get_priv(dev); int ret, i, vco;
- if (&dsi->phy) { + if (dsi->phy.dev) { ret = generic_phy_configure(&dsi->phy, &dsi->phy_opts); if (ret) { dev_err(dsi->dsi_host, @@ -527,7 +527,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, struct display_timing *timings, }
/* for external phy only the mipi_dphy_config is necessary */ - if (&dsi->phy) { + if (dsi->phy.dev) { phy_mipi_dphy_get_default_config(timings->pixelclock.typ * 10 / 8, bpp, lanes, &dsi->phy_opts); @@ -827,7 +827,7 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev) }
/* Get a ref clock only if not using an external phy. */ - if (&priv->phy) { + if (priv->phy.dev) { dev_dbg(dev, "setting priv->ref to NULL\n"); priv->ref = NULL;
From: Ondrej Jirman megi@xff.cz
Wrong return codes were checked in several places. Check the proper ones.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index b1b5328595e0..b7d6b51703c0 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -822,6 +822,7 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev)
priv->pclk = devm_clk_get(dev, "pclk"); if (IS_ERR(priv->pclk)) { + ret = PTR_ERR(priv->pclk); dev_err(dev, "peripheral clock get error %d\n", ret); return ret; } @@ -833,7 +834,8 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev)
} else { priv->ref = devm_clk_get(dev, "ref"); - if (ret) { + if (IS_ERR(priv->ref)) { + ret = PTR_ERR(priv->ref); dev_err(dev, "pll reference clock get error %d\n", ret); return ret; } @@ -841,7 +843,8 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev)
priv->rst = devm_reset_control_get_by_index(device->dev, 0); if (IS_ERR(priv->rst)) { - dev_err(dev, "missing dsi hardware reset\n"); + ret = PTR_ERR(priv->rst); + dev_err(dev, "missing dsi hardware reset %d\n", ret); return ret; }
From: Ondrej Jirman megi@xff.cz
ret is undefined if external phy is not used resulting in bogus error being returned in that scenario.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index b7d6b51703c0..5e8db6bd2e63 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -460,7 +460,7 @@ static int dsi_phy_init(void *priv_data) dw_mipi_dsi_phy_write(dsi, HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL, BIT(5) | ns2bc(dsi, 100));
- return ret; + return 0; }
static void dsi_phy_post_set_mode(void *priv_data, unsigned long mode_flags)
From: Ondrej Jirman megi@xff.cz
pllref_clk is unused after being retrieved. fin needs to be set to dsi->ref clock's rate for the following calculation to work. Otherwise fin is undefined, and calculation return bogus number based on undefined variable.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index 5e8db6bd2e63..6d8b1e6f541a 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -505,7 +505,6 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, struct display_timing *timings, unsigned int _prediv, best_prediv; unsigned long _fbdiv, best_fbdiv; unsigned long min_delta = ULONG_MAX; - unsigned int pllref_clk;
bpp = mipi_dsi_pixel_format_to_bpp(format); if (bpp < 0) { @@ -537,7 +536,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, struct display_timing *timings, return 0; }
- pllref_clk = clk_get_rate(dsi->ref); + fin = clk_get_rate(dsi->ref); fout = target_mbps * USEC_PER_SEC;
/* constraint: 5Mhz <= Fref / N <= 40MHz */
From: Ondrej Jirman megi@xff.cz
If phy is not defined in DT (eg. on rk3399), generic_phy_get_by_name will return -ENODATA. Handle that case correctly.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index 6d8b1e6f541a..fd885ac8ccb6 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -814,9 +814,9 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev) * NULL if it's not initialized. */ ret = generic_phy_get_by_name(dev, "dphy", &priv->phy); - if ((ret) && (ret != -ENODEV)) { + if (ret && ret != -ENODATA) { dev_err(dev, "failed to get mipi dphy: %d\n", ret); - return -EINVAL; + return ret; }
priv->pclk = devm_clk_get(dev, "pclk");
From: Ondrej Jirman megi@xff.cz
Use proper register base and access method to access GRF registers. GRF registers start at a completely different base, and need special access method, that sets the change mask in the 16 MSBs.
Signed-off-by: Ondrej Jirman megi@xff.cz --- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c index fd885ac8ccb6..117c3db21ac1 100644 --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c @@ -18,6 +18,7 @@ #include <panel.h> #include <phy-mipi-dphy.h> #include <reset.h> +#include <syscon.h> #include <video_bridge.h> #include <dm/device_compat.h> #include <dm/lists.h> @@ -30,6 +31,9 @@ #include <dm/device-internal.h> #include <linux/bitops.h>
+#include <asm/arch-rockchip/clock.h> +#include <asm/arch-rockchip/hardware.h> + #define USEC_PER_SEC 1000000L
/* @@ -197,6 +201,7 @@ struct dw_rockchip_dsi_priv { struct mipi_dsi_device device; void __iomem *base; struct udevice *panel; + void __iomem *grf;
/* Optional external dphy */ struct phy phy; @@ -752,16 +757,13 @@ static int dw_mipi_dsi_rockchip_set_bl(struct udevice *dev, int percent) static void dw_mipi_dsi_rockchip_config(struct dw_rockchip_dsi_priv *dsi) { if (dsi->cdata->lanecfg1_grf_reg) - dsi_write(dsi, dsi->cdata->lanecfg1_grf_reg, - dsi->cdata->lanecfg1); + rk_setreg(dsi->grf + dsi->cdata->lanecfg1_grf_reg, dsi->cdata->lanecfg1);
if (dsi->cdata->lanecfg2_grf_reg) - dsi_write(dsi, dsi->cdata->lanecfg2_grf_reg, - dsi->cdata->lanecfg2); + rk_setreg(dsi->grf + dsi->cdata->lanecfg2_grf_reg, dsi->cdata->lanecfg2);
if (dsi->cdata->enable_grf_reg) - dsi_write(dsi, dsi->cdata->enable_grf_reg, - dsi->cdata->enable); + rk_setreg(dsi->grf + dsi->cdata->enable_grf_reg, dsi->cdata->enable); }
static int dw_mipi_dsi_rockchip_bind(struct udevice *dev) @@ -794,6 +796,8 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev) return -EINVAL; }
+ priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF); + i = 0; while (cdata[i].reg) { if (cdata[i].reg == (fdt_addr_t)priv->base) {
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
regards, Ondrej
Please take a look.
Thank you and regards, Ondrej Jirman
Ondrej Jirman (8): video: rockchip: vop: Fix whitespace video: dw_mipi_dsi: Fix hsync/vsync settings video: rockchip: dw_mipi_dsi: Fix external phy existnece check video: rockchip: dw_mipi_dsi: Fix error path checks in probe function video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success video: rockchip: dw_mipi_dsi: Fix best_rate calculation video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle video: rockchip: dw_mipi_dsi: Fix GRF access
drivers/video/dw_mipi_dsi.c | 4 +- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++++++++++-------- drivers/video/rockchip/rk_vop.c | 2 +- 3 files changed, 25 insertions(+), 19 deletions(-)
-- 2.40.1
On Thu, 13 Jul 2023 16:51:36 +0200 Ondřej Jirman megi@xff.cz wrote:
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
I hoped to get a Tested-by for this series to make sure it does not break current users.
-- Anatolij
On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote:
On Thu, 13 Jul 2023 16:51:36 +0200 Ondřej Jirman megi@xff.cz wrote:
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
I hoped to get a Tested-by for this series to make sure it does not break current users.
It's a miracle it even works for the current users, given the wrong way the current code writes to GRF registers, which makes it to have no intended effect, etc.
Anyway, is there some upper limit to wait for Tested-by? 2 months seems excessive. Just so I can remind myself sooner next time. :)
I can understand a few weeks, but 2 months just deters contributions.
kind regards, o.
-- Anatolij
On Thu, 13 Jul 2023 18:03:48 +0200 Ondřej Jirman megi@xff.cz wrote:
On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote:
On Thu, 13 Jul 2023 16:51:36 +0200 Ondřej Jirman megi@xff.cz wrote:
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
I hoped to get a Tested-by for this series to make sure it does not break current users.
It's a miracle it even works for the current users, given the wrong way the current code writes to GRF registers, which makes it to have no intended effect, etc.
Anyway, is there some upper limit to wait for Tested-by? 2 months seems excessive. Just so I can remind myself sooner next time. :)
I can understand a few weeks, but 2 months just deters contributions.
I usually apply new patches during the merge window (we have three months release cycle) and this patch series was sent when the merge window was closed. If patches are bug fixes (like in this case) I prefer to get them tested by someone who has the actual hardware. When there is an Acked-by or Tested-by, then I apply the fixes for -rcX. We already had several cases in the past where simple and obvious timing fixes in the driver broke display support for in tree boards, therefore I'm somewhat reluctant to apply fixes for -rcX without Tested-by.
-- Anatolij
On Mon, Jul 17, 2023 at 06:01:47PM +0200, Anatolij Gustschin wrote:
On Thu, 13 Jul 2023 18:03:48 +0200 Ondřej Jirman megi@xff.cz wrote:
On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote:
On Thu, 13 Jul 2023 16:51:36 +0200 Ondřej Jirman megi@xff.cz wrote:
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
I hoped to get a Tested-by for this series to make sure it does not break current users.
It's a miracle it even works for the current users, given the wrong way the current code writes to GRF registers, which makes it to have no intended effect, etc.
Anyway, is there some upper limit to wait for Tested-by? 2 months seems excessive. Just so I can remind myself sooner next time. :)
I can understand a few weeks, but 2 months just deters contributions.
I usually apply new patches during the merge window (we have three months release cycle) and this patch series was sent when the merge window was closed. If patches are bug fixes (like in this case) I prefer to get them tested by someone who has the actual hardware. When there is an Acked-by or Tested-by, then I apply the fixes for -rcX. We already had several cases in the past where simple and obvious timing fixes in the driver broke display support for in tree boards, therefore I'm somewhat reluctant to apply fixes for -rcX without Tested-by.
Thanks for explanation and for applying the patches.
kind regards, Ondrej
-- Anatolij
I’ve been on holiday and not able to add my Tested-By yet, I do apologize. It will probably be another week and a half before I can, but I will check these out and if they cause problems I’ll let you know/start work on a fix.
Thank you.
On Jul 17, 2023, at 11:01 AM, Anatolij Gustschin agust@denx.de wrote:
On Thu, 13 Jul 2023 18:03:48 +0200 Ondřej Jirman megi@xff.cz wrote:
On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote:
On Thu, 13 Jul 2023 16:51:36 +0200 Ondřej Jirman megi@xff.cz wrote:
Hi,
On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:
From: Ondrej Jirman megi@xff.cz
These are just random fixes for bugs I found while eyeballing the code and porting it to work with RK3399.
It would be nice if somebody merged this. I'd like to add display support for a few boards, and these patches are just fairly obvious bugfixes in new code added in 2023.07 that I hoped would get merged in the bugfix part of the merge window.
I hoped to get a Tested-by for this series to make sure it does not break current users.
It's a miracle it even works for the current users, given the wrong way the current code writes to GRF registers, which makes it to have no intended effect, etc.
Anyway, is there some upper limit to wait for Tested-by? 2 months seems excessive. Just so I can remind myself sooner next time. :)
I can understand a few weeks, but 2 months just deters contributions.
I usually apply new patches during the merge window (we have three months release cycle) and this patch series was sent when the merge window was closed. If patches are bug fixes (like in this case) I prefer to get them tested by someone who has the actual hardware. When there is an Acked-by or Tested-by, then I apply the fixes for -rcX. We already had several cases in the past where simple and obvious timing fixes in the driver broke display support for in tree boards, therefore I'm somewhat reluctant to apply fixes for -rcX without Tested-by.
-- Anatolij
On Mon, 22 May 2023 23:47:00 +0200 megi@xff.cz megi@xff.cz wrote: ...
Ondrej Jirman (8): video: rockchip: vop: Fix whitespace video: dw_mipi_dsi: Fix hsync/vsync settings video: rockchip: dw_mipi_dsi: Fix external phy existnece check video: rockchip: dw_mipi_dsi: Fix error path checks in probe function video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success video: rockchip: dw_mipi_dsi: Fix best_rate calculation video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle video: rockchip: dw_mipi_dsi: Fix GRF access
drivers/video/dw_mipi_dsi.c | 4 +- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++++++++++-------- drivers/video/rockchip/rk_vop.c | 2 +- 3 files changed, 25 insertions(+), 19 deletions(-
Series applied to u-boot-video/master, thanks!
-- Anatolij
On Mon, Jul 17, 2023 at 05:25:45PM +0200, Anatolij Gustschin wrote:
On Mon, 22 May 2023 23:47:00 +0200 megi@xff.cz megi@xff.cz wrote: ...
Ondrej Jirman (8): video: rockchip: vop: Fix whitespace video: dw_mipi_dsi: Fix hsync/vsync settings video: rockchip: dw_mipi_dsi: Fix external phy existnece check video: rockchip: dw_mipi_dsi: Fix error path checks in probe function video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success video: rockchip: dw_mipi_dsi: Fix best_rate calculation video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle video: rockchip: dw_mipi_dsi: Fix GRF access
drivers/video/dw_mipi_dsi.c | 4 +- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++++++++++-------- drivers/video/rockchip/rk_vop.c | 2 +- 3 files changed, 25 insertions(+), 19 deletions(-
Series applied to u-boot-video/master, thanks!
Too late for this to actually MATTER (I was out of town, sorry), but for what it's worth...
Tested-by: Chris Morgan macromorgan@hotmail.com
Thank you.
-- Anatolij
On Tue, Jul 25, 2023 at 01:03:16PM -0500, Chris Morgan wrote:
On Mon, Jul 17, 2023 at 05:25:45PM +0200, Anatolij Gustschin wrote:
On Mon, 22 May 2023 23:47:00 +0200 megi@xff.cz megi@xff.cz wrote: ...
Ondrej Jirman (8): video: rockchip: vop: Fix whitespace video: dw_mipi_dsi: Fix hsync/vsync settings video: rockchip: dw_mipi_dsi: Fix external phy existnece check video: rockchip: dw_mipi_dsi: Fix error path checks in probe function video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success video: rockchip: dw_mipi_dsi: Fix best_rate calculation video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle video: rockchip: dw_mipi_dsi: Fix GRF access
drivers/video/dw_mipi_dsi.c | 4 +- drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++++++++++-------- drivers/video/rockchip/rk_vop.c | 2 +- 3 files changed, 25 insertions(+), 19 deletions(-
Series applied to u-boot-video/master, thanks!
Too late for this to actually MATTER (I was out of town, sorry), but for what it's worth...
Tested-by: Chris Morgan macromorgan@hotmail.com
Thank you.
Great, thanks. :) Good to know I did not break your use case.
kind regards, o.
-- Anatolij
participants (6)
-
Anatolij Gustschin -
Chris Morgan -
Christopher Morgan
-
Kever Yang -
megi＠xff.cz -
Ondřej Jirman