This series fixed the issues related to work DSI on 2-lane panel which is reported on previous version[1][2][3]
This supposed to be a clean series, where it support Allwinner A64 MIPI-DSI support for 4-lane, 2-lane DSI panels.
This series fixed all previous series comments along with checkpatch warnings/error.
Changes for v5: - collect Rob, Acked-by - droped "Fix VBP size calculation" patch - updated vblk timing calculation. - droped techstar, bananapi dsi panel drivers which may require bridge or other setup. it's under discussion. Changes for v4: - droppoed untested CCU_FEATURE_FIXED_POSTDIV check code in nkm min, max rate patches - create two patches for "Add Allwinner A64 MIPI DSI support" one for has_mod_clk quirk and other one for A64 support - use existing driver code construct for hblk computation - dropped "Increase hfp packet overhead" patch [2], though BSP added this but we have no issues as of now. (no issues on panel side w/o this change) - create separate function for vblk computation - enable vcc-dsi regulator in dsi_runtime_resume - collect Rob, Acked-by - update MAINTAINERS file for panel drivers - cleanup commit messages - fixed checkpatch warnings/errors
[3] https://patchwork.kernel.org/cover/10680247/ [2] https://patchwork.kernel.org/patch/10657541/ [1] https://patchwork.kernel.org/patch/10657619/
Note: the respetive dts consumer for dsi will send once the panel driver finalized or in burst mode patch series.
Any inputs, Jagan.
Jagan Teki (17): clk: sunxi-ng: Add check for minimal rate to NKM PLLs drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support dt-bindings: sun6i-dsi: Add compatible for A64 MIPI DSI drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param transfer drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value drm/sun4i: sun6i_mipi_dsi: Fix DSI hblk timing calculation drm/sun4i: sun6i_mipi_dsi: Add DSI hblk packet overhead drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value drm/sun4i: sun6i_mipi_dsi: Set proper vblk timing calculation drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator dt-bindings: sun6i-dsi: Add VCC-DSI supply property clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback) arm64: dts: allwinner: a64: Add DSI pipeline
.../bindings/display/sunxi/sun6i-dsi.txt | 5 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++++++ drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 + drivers/clk/sunxi-ng/ccu_nkm.c | 5 + drivers/clk/sunxi-ng/ccu_nkm.h | 1 + drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 118 ++++++++++++++---- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 8 ++ 7 files changed, 159 insertions(+), 24 deletions(-)
Some NKM PLLs doesn't work well when their output clock rate is set below certain rate.
So, add support for minimal rate for relevant PLLs.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Acked-by: Stephen Boyd sboyd@kernel.org --- drivers/clk/sunxi-ng/ccu_nkm.c | 5 +++++ drivers/clk/sunxi-ng/ccu_nkm.h | 1 + 2 files changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c index 841840e35e61..096ff4f4839a 100644 --- a/drivers/clk/sunxi-ng/ccu_nkm.c +++ b/drivers/clk/sunxi-ng/ccu_nkm.c @@ -125,6 +125,11 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux, if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV) rate *= nkm->fixed_post_div;
+ if (rate < nkm->min_rate) { + rate = nkm->min_rate; + return rate; + } + ccu_nkm_find_best(*parent_rate, rate, &_nkm);
rate = *parent_rate * _nkm.n * _nkm.k / _nkm.m; diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h index cc6efb70a102..ff5bd00f429f 100644 --- a/drivers/clk/sunxi-ng/ccu_nkm.h +++ b/drivers/clk/sunxi-ng/ccu_nkm.h @@ -35,6 +35,7 @@ struct ccu_nkm { struct ccu_mux_internal mux;
unsigned int fixed_post_div; + unsigned int min_rate;
struct ccu_common common; };
Mod clock is not mandatory for all Allwinner MIPI DSI controllers, it is connected as CLK_DSI_SCLK for A31 and not available in A64.
So add has_mod_clk quirk and process the clk accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 39 ++++++++++++++++++-------- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 5 ++++ 2 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index e3b34a345546..561de393ea23 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -10,6 +10,7 @@ #include <linux/component.h> #include <linux/crc-ccitt.h> #include <linux/of_address.h> +#include <linux/of_device.h> #include <linux/pm_runtime.h> #include <linux/regmap.h> #include <linux/reset.h> @@ -981,6 +982,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev) dsi->host.ops = &sun6i_dsi_host_ops; dsi->host.dev = dev;
+ dsi->variant = of_device_get_match_data(dev); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); base = devm_ioremap_resource(dev, res); if (IS_ERR(base)) { @@ -1001,17 +1004,20 @@ static int sun6i_dsi_probe(struct platform_device *pdev) return PTR_ERR(dsi->reset); }
- dsi->mod_clk = devm_clk_get(dev, "mod"); - if (IS_ERR(dsi->mod_clk)) { - dev_err(dev, "Couldn't get the DSI mod clock\n"); - return PTR_ERR(dsi->mod_clk); + if (dsi->variant->has_mod_clk) { + dsi->mod_clk = devm_clk_get(dev, "mod"); + if (IS_ERR(dsi->mod_clk)) { + dev_err(dev, "Couldn't get the DSI mod clock\n"); + return PTR_ERR(dsi->mod_clk); + } }
/* * In order to operate properly, that clock seems to be always * set to 297MHz. */ - clk_set_rate_exclusive(dsi->mod_clk, 297000000); + if (dsi->variant->has_mod_clk) + clk_set_rate_exclusive(dsi->mod_clk, 297000000);
dphy_node = of_parse_phandle(dev->of_node, "phys", 0); ret = sun6i_dphy_probe(dsi, dphy_node); @@ -1043,7 +1049,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev) pm_runtime_disable(dev); sun6i_dphy_remove(dsi); err_unprotect_clk: - clk_rate_exclusive_put(dsi->mod_clk); + if (dsi->variant->has_mod_clk) + clk_rate_exclusive_put(dsi->mod_clk); return ret; }
@@ -1056,7 +1063,8 @@ static int sun6i_dsi_remove(struct platform_device *pdev) mipi_dsi_host_unregister(&dsi->host); pm_runtime_disable(dev); sun6i_dphy_remove(dsi); - clk_rate_exclusive_put(dsi->mod_clk); + if (dsi->variant->has_mod_clk) + clk_rate_exclusive_put(dsi->mod_clk);
return 0; } @@ -1066,7 +1074,8 @@ static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev) struct sun6i_dsi *dsi = dev_get_drvdata(dev);
reset_control_deassert(dsi->reset); - clk_prepare_enable(dsi->mod_clk); + if (dsi->variant->has_mod_clk) + clk_prepare_enable(dsi->mod_clk);
/* * Enable the DSI block. @@ -1094,7 +1103,8 @@ static int __maybe_unused sun6i_dsi_runtime_suspend(struct device *dev) { struct sun6i_dsi *dsi = dev_get_drvdata(dev);
- clk_disable_unprepare(dsi->mod_clk); + if (dsi->variant->has_mod_clk) + clk_disable_unprepare(dsi->mod_clk); reset_control_assert(dsi->reset);
return 0; @@ -1106,9 +1116,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = { NULL) };
+static const struct sun6i_dsi_variant sun6i_a31_dsi = { + .has_mod_clk = true, +}; + static const struct of_device_id sun6i_dsi_of_table[] = { - { .compatible = "allwinner,sun6i-a31-mipi-dsi" }, - { } + { + .compatible = "allwinner,sun6i-a31-mipi-dsi", + .data = &sun6i_a31_dsi, + }, + { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h index dbbc5b3ecbda..597b62227019 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h @@ -20,6 +20,10 @@ struct sun6i_dphy { struct reset_control *reset; };
+struct sun6i_dsi_variant { + bool has_mod_clk; +}; + struct sun6i_dsi { struct drm_connector connector; struct drm_encoder encoder; @@ -35,6 +39,7 @@ struct sun6i_dsi { struct sun4i_drv *drv; struct mipi_dsi_device *device; struct drm_panel *panel; + const struct sun6i_dsi_variant *variant; };
static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
The MIPI DSI controller on Allwinner A64 is similar to Allwinner A31 without support of DSI mod clock(CLK_DSI_SCLK)
So, alter has_mod_clk bool via driver data for respective SoC's compatible.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 561de393ea23..50f535ae57e9 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -1120,11 +1120,18 @@ static const struct sun6i_dsi_variant sun6i_a31_dsi = { .has_mod_clk = true, };
+static const struct sun6i_dsi_variant sun50i_a64_dsi = { +}; + static const struct of_device_id sun6i_dsi_of_table[] = { { .compatible = "allwinner,sun6i-a31-mipi-dsi", .data = &sun6i_a31_dsi, }, + { + .compatible = "allwinner,sun50i-a64-mipi-dsi", + .data = &sun50i_a64_dsi, + }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
The MIPI DSI controller on Allwinner A64 is similar to Allwinner A31 without support of DSI mod clock.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Reviewed-by: Rob Herring robh@kernel.org --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 6a6cf5de08b0..9fa6e7a758ad 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dsi + * allwinner,sun50i-a64-mipi-dsi - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the DSI encoder
Short transfer write support for DCS and Generic transfer types share similar way to process command sequence in DSI block so add generic write 2 param transfer type macro so-that the panels which are requesting similar transfer type may process properly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 50f535ae57e9..cdd44a1307b3 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -871,6 +871,7 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host *host, switch (msg->type) { case MIPI_DSI_DCS_SHORT_WRITE: case MIPI_DSI_DCS_SHORT_WRITE_PARAM: + case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM: ret = sun6i_dsi_dcs_write_short(dsi, msg); break;
TCON DRQ set bits for non-burst DSI mode can computed via horizontal front porch instead of front porch + sync timings.
BSP code form BPI-M64-bsp is computing TCON DRQ set bits for non-burts as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
=> panel->lcd_ht - panel->lcd_x - panel->lcd_hbp => (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x) - panel->lcd_x - panel->hbp => timmings->hor_front_porch => mode->hsync_start - mode->hdisplay
So, update the DRQ set bits accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index cdd44a1307b3..c9b0222ebcd4 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -367,9 +367,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi, struct mipi_dsi_device *device = dsi->device; u32 val = 0;
- if ((mode->hsync_end - mode->hdisplay) > 20) { + if ((mode->hsync_start - mode->hdisplay) > 20) { /* Maaaaaagic */ - u16 drq = (mode->hsync_end - mode->hdisplay) - 20; + u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
drq *= mipi_dsi_pixel_format_to_bpp(device->format); drq /= 32;
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) - panel->lcd_y - (panel->lcd_vbp) => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index c9b0222ebcd4..cb41fea4f3ee 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -358,7 +358,17 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi, static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi, struct drm_display_mode *mode) { - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1; + u32 vfp = mode->vsync_start - mode->vdisplay; + u32 start_delay; + + start_delay = mode->vtotal - vfp + 1; + if (start_delay > mode->vtotal) + start_delay -= mode->vtotal; + + if (!start_delay) + start_delay = 1; + + return start_delay; }
static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
So, just like I asked in your v4, twice,
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.h...
Since the documentation is quite sparse, and a MIPI-DSI analyzer is way too expensive, I'd really like to have at least what each of these commits are actually fixing, and what symptoms each of these were causing, and not just "the BSP does it".
Maxime
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
So, just like I asked in your v4, twice,
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.h...
I don't know how can I comment here. Not quite clearly understand your setup, because I have verified 3 different panels from different vendors one with 2-lane, another with 4-lane and one with video format and another one is burstmode format. I even verified with the clock rate and register details.
Please suggest me, what can look further on this.
Hi Maxime,
On Tue, Dec 11, 2018 at 10:30 PM Jagan Teki jagan@amarulasolutions.com wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
So, just like I asked in your v4, twice,
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.h...
I don't know how can I comment here. Not quite clearly understand your setup, because I have verified 3 different panels from different vendors one with 2-lane, another with 4-lane and one with video format and another one is burstmode format. I even verified with the clock rate and register details.
Please suggest me, what can look further on this.
From the BSP point-of-view I couldn't find have any difference in
start_delay computation between A64, and A33[1]. In fact the driver initialization code is same, here is A64 dsi driver[2].
1) The only difference that I observe is dsi_gen_wr in BSP [3], the A33 is right shifting message tx length to 0, 8 for first and next packet where as A64 did the same by adding +1 before. Please try to check that If your panel is using long write. and 2) Also every dsi transaction in A33 occupy some delay code in dsi_gen_wr[4], please check the same. and 3) Also If possible please check your panel timings or initialization sequence, because I don't have any panel with A33. 4) other than these I have didn't notice any differences atleast from my knowledge, Please suggest me where can I look further.
[1] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/... [2] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/... [3] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/... [4] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/...
On Tue, Dec 11, 2018 at 10:30:08PM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
So, just like I asked in your v4, twice,
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.h...
I don't know how can I comment here. Not quite clearly understand your setup, because I have verified 3 different panels from different vendors one with 2-lane, another with 4-lane and one with video format and another one is burstmode format. I even verified with the clock rate and register details.
Please suggest me, what can look further on this.
You had a reason to do these patches in the first place, yet you never mention it anywhere in your commit logs. it would address the first part of my comment.
And I can help you nail down whatever is going on here, but I would need the panel datasheet for that. It is my second point.
Maxime
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
I'm thinking your display should work in the same behavior since the dsi controller making this route.
On Fri, Dec 21, 2018 at 2:26 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
I'm thinking your display should work in the same behavior since the dsi controller making this route.
Any further comments on this?
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
Maxime
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
Maxime
On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
Video start delay can be computed by subtracting total vertical timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y - panel->lcd_y - panel->lcd_vbp => timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Let me know for any more details.
Jagan.
On Wed, Jan 09, 2019 at 06:57:57PM +0530, Jagan Teki wrote:
On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > Video start delay can be computed by subtracting total vertical > timing with front porch timing and with adding 1 delay line for TCON. > > BSP code form BPI-M64-bsp is computing video start delay as > (from linux-sunxi/ > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > - panel->lcd_y - (panel->lcd_vbp) > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > - panel->lcd_y - panel->lcd_vbp > => timmings->ver_front_porch > > So, update the start delay computation accordingly. > > Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Even though it's a bit better now on my A33 board and I don't have the white stripes on the bottom of the display, there's still some flickering with your patches applied.
Bisecting it seems to point at that patch, but reverting it doesn't make the issue go away, so it's not really clear which one exactly is at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
Maxime
On Sat, Jan 12, 2019 at 10:13 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Wed, Jan 09, 2019 at 06:57:57PM +0530, Jagan Teki wrote:
On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote: > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > > Video start delay can be computed by subtracting total vertical > > timing with front porch timing and with adding 1 delay line for TCON. > > > > BSP code form BPI-M64-bsp is computing video start delay as > > (from linux-sunxi/ > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > > - panel->lcd_y - (panel->lcd_vbp) > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > > - panel->lcd_y - panel->lcd_vbp > > => timmings->ver_front_porch > > > > So, update the start delay computation accordingly. > > > > Signed-off-by: Jagan Teki jagan@amarulasolutions.com > > Even though it's a bit better now on my A33 board and I don't have the > white stripes on the bottom of the display, there's still some > flickering with your patches applied. > > Bisecting it seems to point at that patch, but reverting it doesn't > make the issue go away, so it's not really clear which one exactly is > at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
Maxime
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> Again, I cannot help you without the datasheet for the panels you're > trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
1. Patch for same panel timings are already in Mainline that was tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
Jagan.
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > Again, I cannot help you without the datasheet for the panels you're > > trying to submit. > > The panel bound with Sitronix ST7701 IC > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
- Patch for same panel timings are already in Mainline that was
tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
fyi, the panel datasheet attached in above mail has timing information.
On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote:
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > Again, I cannot help you without the datasheet for the panels you're > > > trying to submit. > > > > The panel bound with Sitronix ST7701 IC > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
- Patch for same panel timings are already in Mainline that was
tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
fyi, the panel datasheet attached in above mail has timing information.
Do you have a page number?
maxime
On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote:
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > Again, I cannot help you without the datasheet for the panels you're > > > > trying to submit. > > > > > > The panel bound with Sitronix ST7701 IC > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > It's the controller, not the panel > > As I said before, the datasheet of that panel doesn't have any > information except electrical characteristics and used IC which is > ST7701. > > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 > please find the attachment for the same. > > Here is some more details of the same. > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/... > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... > matches timings for > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a... > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
- Patch for same panel timings are already in Mainline that was
tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
fyi, the panel datasheet attached in above mail has timing information.
Do you have a page number?
Page 4 5.2 Interface Timings
On Tue, Jan 22, 2019 at 05:21:08PM +0530, Jagan Teki wrote:
On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote:
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > Again, I cannot help you without the datasheet for the panels you're > > > > > trying to submit. > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > It's the controller, not the panel > > > > As I said before, the datasheet of that panel doesn't have any > > information except electrical characteristics and used IC which is > > ST7701. > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 > > please find the attachment for the same. > > > > Here is some more details of the same. > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/... > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... > > matches timings for > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a... > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#... > > Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
- Patch for same panel timings are already in Mainline that was
tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
fyi, the panel datasheet attached in above mail has timing information.
Do you have a page number?
Page 4 5.2 Interface Timings
Which datasheet are we talking about here?
The only one I've seen is the Sitronix IC's and the page 4 is the summary.
Maxime
On Thu, Jan 17, 2019 at 10:02:12AM +0530, Jagan Teki wrote:
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > Again, I cannot help you without the datasheet for the panels you're > > trying to submit. > > The panel bound with Sitronix ST7701 IC > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...
So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then?
I don't understand your point, or may be I confused with many links that I attached in previous mail.
- Patch for same panel timings are already in Mainline that was
tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3]
Do you think the above two points are not valid sources?
I'm saying that the only valid source is the datasheet or a DSI analyzer.
Maxmie
Current driver is calculating hbp maximum value by subtracting hsync_start with hdisplay which is front porch value, but the hbp refers to back porch.
Back porch value is calculating by subtracting htotal with hsync_end as per drm_mode timings, and BSP code from BPI-M64-bsp is eventually following the same.
BPI-M64-bsp is computing hbp as (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2); => (panel->lcd_hbp - timmings->hor_sync_time) => (timmings->hor_back_porch + timmings->hor_sync_time - timmings->hor_sync_time) => timmings->hor_back_porch => mode->htotal - mode->hsync_end
So, update the MIPI-DSI hbp value accordingly.
Tested on 2-lane, 4-lane DSI LCD panels.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index cb41fea4f3ee..81151d7633f9 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -482,7 +482,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD 6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD);
/* * The frontporch is set using a blanking packet (4 bytes +
hblk is adding line with all porch timing values, or timings values from htotal without sync time.
Current driver is subtracting htotal with hsa, but the hsa is bounded with packet overhead. For real hblk calculation needed by subtracting htotal with back and front porch values and BSP code BPI-M64-bsp is eventually following the same.
BPI-M64-bsp is computing hbp as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2); => (timmings->hor_total_time - timmings->hor_sync_time) => (mode->htotal - (mode->hsync_end - mode->hsync_start))
So, update the DSI hblk timing accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 81151d7633f9..4c95b3384ed9 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -495,7 +495,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, /* * hblk seems to be the line + porches length. */ - hblk = mode->htotal * Bpp - hsa; + hblk = (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp;
/* * And I'm not entirely sure what vblk is about. The driver in
Add 10 bytes packet overhead for hblk where blank is set using a blanking packet like (4 bytes + 4 bytes + payload + 2 bytes)
This is according to BSP code from BPI-M64-bsp (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2);
So, add 10 bytes packet overhead for DSI hblk.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 4c95b3384ed9..07eba9ec469b 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -494,8 +494,13 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
/* * hblk seems to be the line + porches length. + * The blank is set using a blanking packet (4 bytes + 4 bytes + + * payload + 2 bytes). So minimal size is 10 bytes */ - hblk = (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp; +#define HBLK_PACKET_OVERHEAD 10 + hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * + Bpp - HBLK_PACKET_OVERHEAD);
/* * And I'm not entirely sure what vblk is about. The driver in
Current driver is calculating hfp maximum value by subtracting htotal with hsync_end which is front back value, but the hpp refers to front porch.
Front porch value is calculating by subtracting hsync_start with hdisplay as per drm_mode timings, and BSP code from BPI-M64-bsp is eventually following the same.
BPI-M64-bsp is computing hfp as (from linux-sunxi/ drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2); dsi_hact = x * dsi_pixel_bits[format]/8; dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2); dsi_hfp = dsi_hblk - (4+dsi_hact+2) - (4+dsi_hbp+2);
Example, u32 fmt = dsi_pixel_bits[format]/8; => ((ht-hspw)*fmt - 10) - (6 + x * fmt) - (6 + (hbp-hspw)*fmt - 6) => (ht - hspw - x - (hbp - hspw)) * fmt - 16 => (ht - x - hbp) * fmt - 16 => (ht - x - (timmings->hor_total_time - timmings->hor_front_porch - x) * fmt - 16 => (timmings->hor_total_time - x - timmings->hor_total_time + timmings->hor_front_porch + x) * fmt - 16 => timmings->hor_front_porch * fmt - 16
So, update the DSI hfp timing accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 07eba9ec469b..d8947be92f9d 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -490,7 +490,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD 6 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp - + HFP_PACKET_OVERHEAD);
/* * hblk seems to be the line + porches length.
Unlike hblk, the vblk timings should follow an equation to compute the desired value for lane 4 devices and rest of devices it would be 0.
BSP code from BPI-M64-bsp is computing vblk as for 4-lane devices (from linux-sunxi drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
tmp = (ht*dsi_pixel_bits[format]/8)*vt-(4+dsi_hblk+2); dsi_vblk = (lane-tmp%lane);
So, update the vblk timing calculation accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 29 +++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index d8947be92f9d..cbcef7bf7681 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -355,6 +355,27 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi, SUN6I_DSI_INST_JUMP_CFG_NUM(1)); };
+static u16 sun6i_dsi_get_timings_vblk(struct sun6i_dsi *dsi, + struct drm_display_mode *mode, u16 hblk) +{ + struct mipi_dsi_device *device = dsi->device; + unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8; + int tmp; + + if (device->lanes != 4) + return 0; + + /* + * The vertical blank is set using a blanking packet (4 bytes + + * payload + 2 bytes). Its minimal size is therefore 6 bytes + */ +#define VBLK_PACKET_OVERHEAD 6 + tmp = (mode->htotal * Bpp) * mode->vtotal - + (hblk + VBLK_PACKET_OVERHEAD); + + return (device->lanes - tmp % device->lanes); +} + static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi, struct drm_display_mode *mode) { @@ -503,13 +524,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - HBLK_PACKET_OVERHEAD);
- /* - * And I'm not entirely sure what vblk is about. The driver in - * Allwinner BSP is using a rather convoluted calculation - * there only for 4 lanes. However, using 0 (the !4 lanes - * case) even with a 4 lanes screen seems to work... - */ - vblk = 0; + vblk = sun6i_dsi_get_timings_vblk(dsi, mode, hblk);
/* How many bytes do we need to send all payloads? */ bytes = max_t(size_t, max(max(hfp, hblk), max(hsa, hbp)), vblk);
Some boards have VCC-DSI pin connected to voltage regulator which may not be turned on by default.
Add support for such boards by adding voltage regulator handling code to MIPI DSI driver.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++++++++++++++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 3 +++ 2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index cbcef7bf7681..a87b65fff0e0 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -1023,6 +1023,12 @@ static int sun6i_dsi_probe(struct platform_device *pdev) return PTR_ERR(base); }
+ dsi->regulator = devm_regulator_get(dev, "vcc-dsi"); + if (IS_ERR(dsi->regulator)) { + dev_err(dev, "Couldn't get VCC-DSI supply\n"); + return PTR_ERR(dsi->regulator); + } + dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base, &sun6i_dsi_regmap_config); if (IS_ERR(dsi->regs)) { @@ -1104,6 +1110,13 @@ static int sun6i_dsi_remove(struct platform_device *pdev) static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev) { struct sun6i_dsi *dsi = dev_get_drvdata(dev); + int err; + + err = regulator_enable(dsi->regulator); + if (err) { + dev_err(dsi->dev, "failed to enable VCC-DSI supply: %d\n", err); + return err; + }
reset_control_deassert(dsi->reset); if (dsi->variant->has_mod_clk) @@ -1138,6 +1151,7 @@ static int __maybe_unused sun6i_dsi_runtime_suspend(struct device *dev) if (dsi->variant->has_mod_clk) clk_disable_unprepare(dsi->mod_clk); reset_control_assert(dsi->reset); + regulator_disable(dsi->regulator);
return 0; } diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h index 597b62227019..0df60f84bab3 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h @@ -13,6 +13,8 @@ #include <drm/drm_encoder.h> #include <drm/drm_mipi_dsi.h>
+#include <linux/regulator/consumer.h> + struct sun6i_dphy { struct clk *bus_clk; struct clk *mod_clk; @@ -32,6 +34,7 @@ struct sun6i_dsi { struct clk *bus_clk; struct clk *mod_clk; struct regmap *regs; + struct regulator *regulator; struct reset_control *reset; struct sun6i_dphy *dphy;
Most of the Allwinner MIPI DSI controllers are supply with VCC-DSI pin. which need to supply for some of the boards to trigger the power.
So, document the supply property so-that the required board can eable it via device tree.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Reviewed-by: Rob Herring robh@kernel.org --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 9fa6e7a758ad..adc7cdf129dd 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -28,6 +28,9 @@ Required properties: first port should be the input endpoint, usually coming from the associated TCON.
+Optional properties: + - vcc-dsi-supply: the VCC-DSI power supply of the DSI encoder + Any MIPI-DSI device attached to this should be described according to the bindings defined in ../mipi-dsi-bus.txt
Minimum PLL used for MIPI is 500MHz, as per manual, but lowering the min rate by 300MHz can result proper working nkms divider with the help of desired dclock rate from panel driver.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Acked-by: Stephen Boyd sboyd@kernel.org --- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 181b599dc163..b623c8150b4f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -183,6 +183,7 @@ static struct ccu_nkm pll_mipi_clk = { .n = _SUNXI_CCU_MULT(8, 4), .k = _SUNXI_CCU_MULT_MIN(4, 2, 2), .m = _SUNXI_CCU_DIV(0, 4), + .min_rate = 300000000, /* Actual rate is 500MHz */ .common = { .reg = 0x040, .hw.init = CLK_HW_INIT("pll-mipi", "pll-video0",
On Mon, Dec 10, 2018 at 09:47:27PM +0530, Jagan Teki wrote:
Minimum PLL used for MIPI is 500MHz, as per manual, but lowering the min rate by 300MHz can result proper working nkms divider with the help of desired dclock rate from panel driver.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Acked-by: Stephen Boyd sboyd@kernel.org
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 181b599dc163..b623c8150b4f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -183,6 +183,7 @@ static struct ccu_nkm pll_mipi_clk = { .n = _SUNXI_CCU_MULT(8, 4), .k = _SUNXI_CCU_MULT_MIN(4, 2, 2), .m = _SUNXI_CCU_DIV(0, 4),
- .min_rate = 300000000, /* Actual rate is 500MHz */
That comment still doesn't make any sense. Is it running at 500MHz or 300?
Also, IIRC you had a patch adding support for maximum boundaries in your previous patch, where did it go?
Maxime
On 11/12/18 10:02 PM, Maxime Ripard wrote:
On Mon, Dec 10, 2018 at 09:47:27PM +0530, Jagan Teki wrote:
Minimum PLL used for MIPI is 500MHz, as per manual, but lowering the min rate by 300MHz can result proper working nkms divider with the help of desired dclock rate from panel driver.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Acked-by: Stephen Boyd sboyd@kernel.org
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 181b599dc163..b623c8150b4f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -183,6 +183,7 @@ static struct ccu_nkm pll_mipi_clk = { .n = _SUNXI_CCU_MULT(8, 4), .k = _SUNXI_CCU_MULT_MIN(4, 2, 2), .m = _SUNXI_CCU_DIV(0, 4),
- .min_rate = 300000000, /* Actual rate is 500MHz */
That comment still doesn't make any sense. Is it running at 500MHz or 300?
It running in 300MHz, actual rate is 500MHz.
Also, IIRC you had a patch adding support for maximum boundaries in your previous patch, where did it go?
Since I don't have any usecase to test I droped it. the same mentioned on the previous version.
On Tue, Dec 11, 2018 at 10:05:43PM +0530, Jagan Teki wrote:
On 11/12/18 10:02 PM, Maxime Ripard wrote:
On Mon, Dec 10, 2018 at 09:47:27PM +0530, Jagan Teki wrote:
Minimum PLL used for MIPI is 500MHz, as per manual, but lowering the min rate by 300MHz can result proper working nkms divider with the help of desired dclock rate from panel driver.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Acked-by: Stephen Boyd sboyd@kernel.org
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 181b599dc163..b623c8150b4f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -183,6 +183,7 @@ static struct ccu_nkm pll_mipi_clk = { .n = _SUNXI_CCU_MULT(8, 4), .k = _SUNXI_CCU_MULT_MIN(4, 2, 2), .m = _SUNXI_CCU_DIV(0, 4),
- .min_rate = 300000000, /* Actual rate is 500MHz */
That comment still doesn't make any sense. Is it running at 500MHz or 300?
It running in 300MHz, actual rate is 500MHz.
If it's running at 300MHz, its actual rate should be 300MHz...
Also, IIRC you had a patch adding support for maximum boundaries in your previous patch, where did it go?
Since I don't have any usecase to test I droped it. the same mentioned on the previous version.
Ok.
Maxime
The MIPI DSI PHY HDMI controller on Allwinner A64 is similar on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Reviewed-by: Rob Herring robh@kernel.org --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index adc7cdf129dd..08f1f57abff5 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -40,6 +40,7 @@ D-PHY Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dphy + * "allwinner,sun50i-a64-mipi-dphy", "allwinner,sun6i-a31-mipi-dphy" - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the DSI encoder * bus: the DSI interface clock
The A64 has a MIPI-DSI block which is similar to A31 without mod clock.
So, add dsi node with A64 compatible, dphy node with A31 compatible and finally connect dsi to tcon0 to make proper DSI pipeline.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index dd5740bc3fc9..dd5c7ad55149 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -344,6 +344,12 @@ #address-cells = <1>; #size-cells = <0>; reg = <1>; + + tcon0_out_dsi: endpoint@1 { + reg = <1>; + remote-endpoint = <&dsi_in_tcon0>; + allwinner,tcon-channel = <1>; + }; }; }; }; @@ -910,6 +916,45 @@ status = "disabled"; };
+ dsi: dsi@1ca0000 { + compatible = "allwinner,sun50i-a64-mipi-dsi"; + reg = <0x01ca0000 0x1000>; + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_MIPI_DSI>; + clock-names = "bus"; + resets = <&ccu RST_BUS_MIPI_DSI>; + phys = <&dphy>; + phy-names = "dphy"; + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + dsi_in_tcon0: endpoint { + remote-endpoint = <&tcon0_out_dsi>; + }; + }; + }; + }; + + dphy: d-phy@1ca1000 { + compatible = "allwinner,sun50i-a64-mipi-dphy", + "allwinner,sun6i-a31-mipi-dphy"; + reg = <0x01ca1000 0x1000>; + clocks = <&ccu CLK_BUS_MIPI_DSI>, + <&ccu CLK_DSI_DPHY>; + clock-names = "bus", "mod"; + resets = <&ccu RST_BUS_MIPI_DSI>; + status = "disabled"; + #phy-cells = <0>; + }; + csi: csi@1cb0000 { compatible = "allwinner,sun50i-a64-csi"; reg = <0x01cb0000 0x1000>;
On Mon, Dec 10, 2018 at 09:47:29PM +0530, Jagan Teki wrote:
The A64 has a MIPI-DSI block which is similar to A31 without mod clock.
So, add dsi node with A64 compatible, dphy node with A31 compatible and finally connect dsi to tcon0 to make proper DSI pipeline.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index dd5740bc3fc9..dd5c7ad55149 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -344,6 +344,12 @@ #address-cells = <1>; #size-cells = <0>; reg = <1>;
tcon0_out_dsi: endpoint@1 {reg = <1>;remote-endpoint = <&dsi_in_tcon0>;allwinner,tcon-channel = <1>;}; }; };@@ -910,6 +916,45 @@ status = "disabled"; };
dsi: dsi@1ca0000 {compatible = "allwinner,sun50i-a64-mipi-dsi";reg = <0x01ca0000 0x1000>;interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;clocks = <&ccu CLK_BUS_MIPI_DSI>;clock-names = "bus";resets = <&ccu RST_BUS_MIPI_DSI>;phys = <&dphy>;phy-names = "dphy";status = "disabled";ports {#address-cells = <1>;#size-cells = <0>;port@0 {#address-cells = <1>;#size-cells = <0>;reg = <0>;dsi_in_tcon0: endpoint {remote-endpoint = <&tcon0_out_dsi>;};
The reg address-cells and size-cells properties will generate DTC warnings when compiled with W=1, please fix them.
Maxime
dri-devel@lists.freedesktop.org
-
Jagan Teki -
Jagan Teki -
Maxime Ripard