[PATCH v4 00/26] drm/sun4i: Allwinner A64 MIPI-DSI support

[PATCH v4 00/26] drm/sun4i: Allwinner A64 MIPI-DSI support

[Jagan Teki]

This series fixed the issues related to work DSI on 2-lane panel
which is reported on previous version[1].

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 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

[2] https://patchwork.kernel.org/patch/10657541/
[1] https://patchwork.kernel.org/patch/10657619/

Jagan Teki (26):
  clk: sunxi-ng: a64: Fix gate bit of DSI DPHY
  clk: sunxi-ng: Add check for minimal rate to NKM PLLs
  clk: sunxi-ng: Add check for maximum 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 VBP size calculation
  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
  dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB
    bridge
  drm/panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge
  dt-bindings: panel: Add Techstar TS8550B MIPI-DSI panel
  drm/panel: Add Techstar TS8550B MIPI-DSI LCD panel
  clk: sunxi-ng: a64: Add min and max rate for PLL_MIPI
  dt-bindings: sun6i-dsi: Add compatible for A64 DPHY
  arm64: dts: allwinner: a64: Add DSI pipeline
  [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel
  arm64: dts: allwinner: a64-amarula-relic: Enable Techstar TS8550B
    MIPI-DSI panel

 .../display/panel/bananapi,s070wv20-ct16.txt  |  31 +-
 .../display/panel/techstar,ts8550b.txt        |  22 ++
 .../bindings/display/sunxi/sun6i-dsi.txt      |   5 +
 MAINTAINERS                                   |  12 +
 .../allwinner/sun50i-a64-amarula-relic.dts    |  46 +++
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts |  42 +++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  45 +++
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c         |   4 +-
 drivers/clk/sunxi-ng/ccu_nkm.c                |   6 +
 drivers/clk/sunxi-ng/ccu_nkm.h                |   2 +
 drivers/gpu/drm/panel/Kconfig                 |  18 +
 drivers/gpu/drm/panel/Makefile                |   2 +
 .../panel/panel-bananapi-s070wv20-icn6211.c   | 298 ++++++++++++++++
 .../gpu/drm/panel/panel-techstar-ts8550b.c    | 324 ++++++++++++++++++
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c        | 125 +++++--
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h        |   8 +
 16 files changed, 961 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt
 create mode 100644 drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c
 create mode 100644 drivers/gpu/drm/panel/panel-techstar-ts8550b.c

-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 03/26] clk: sunxi-ng: Add check for maximum rate to NKM PLLs

[Jagan Teki]

Some NKM PLLs, frequency can be set above PLL working range.

Add a constraint for maximum supported rate. This way, drivers can
specify which is maximum allowed rate for PLL.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
 drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 6b5ad990f802..b8b66cdd30bf 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -128,6 +128,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
 	if (rate < nkm->min_rate)
 		return nkm->min_rate;
 
+	if (nkm->max_rate && rate > nkm->max_rate)
+		return nkm->max_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 ff5bd00f429f..c82590481188 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -36,6 +36,7 @@ struct ccu_nkm {
 
 	unsigned int		fixed_post_div;
 	unsigned int		min_rate;
+	unsigned int		max_rate;
 
 	struct ccu_common	common;
 };
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 03/26] clk: sunxi-ng: Add check for maximum rate to NKM PLLs

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Tue, Nov 13, 2018 at 04:46:10PM +0530, Jagan Teki wrote:
> Some NKM PLLs, frequency can be set above PLL working range.
> 
> Add a constraint for maximum supported rate. This way, drivers can
> specify which is maximum allowed rate for PLL.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Acked-by: Stephen Boyd <sboyd@kernel.org>

As Vasily reported on a previous version, this should be squashed with
the patch 2.

> ---
>  drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
>  drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index 6b5ad990f802..b8b66cdd30bf 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -128,6 +128,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
>  	if (rate < nkm->min_rate)
>  		return nkm->min_rate;
>  
> +	if (nkm->max_rate && rate > nkm->max_rate)
> +		return nkm->max_rate;
> +

I would expect the test to be the same for the minimum and maximum cases.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 03/26] clk: sunxi-ng: Add check for maximum rate to NKM PLLs

[Jagan Teki]

On Tue, Nov 13, 2018 at 6:57 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Tue, Nov 13, 2018 at 04:46:10PM +0530, Jagan Teki wrote:
> > Some NKM PLLs, frequency can be set above PLL working range.
> >
> > Add a constraint for maximum supported rate. This way, drivers can
> > specify which is maximum allowed rate for PLL.
> >
> > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > Acked-by: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> As Vasily reported on a previous version, this should be squashed with
> the patch 2.

Sorry, I missed it.

>
> > ---
> >  drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
> >  drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > index 6b5ad990f802..b8b66cdd30bf 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > @@ -128,6 +128,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> >       if (rate < nkm->min_rate)
> >               return nkm->min_rate;
> >
> > +     if (nkm->max_rate && rate > nkm->max_rate)
> > +             return nkm->max_rate;
> > +
>
> I would expect the test to be the same for the minimum and maximum cases.

I don't have proper use-case for max rate test, I do verify by using
higher the rate on dclock, but nor sure.  May be I can skip the
max_rate patch?

Apart from this, any idea about this issue where SUN4I_TCON0_DCLK_REG
will only work with div upto 6 on A64 DSI panels[1], did you find the
same issue on A33?

With parent rate 330MHz, the resulting tcon divider for 30MHz [2]
clock is 11 and for the same for 55MHz [3] clock is 6.

[3] https://paste.ubuntu.com/p/drvzfHFMtY/
[2] https://paste.ubuntu.com/p/hz29CTJY2J/
[1] https://elixir.bootlin.com/linux/v4.20-rc2/source/drivers/gpu/drm/sun4i/sun4i_dotclock.c#L125

Re: [PATCH v4 03/26] clk: sunxi-ng: Add check for maximum rate to NKM PLLs

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Thu, Nov 15, 2018 at 08:51:04PM +0530, Jagan Teki wrote:
> > >  drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
> > >  drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > > index 6b5ad990f802..b8b66cdd30bf 100644
> > > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > > @@ -128,6 +128,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> > >       if (rate < nkm->min_rate)
> > >               return nkm->min_rate;
> > >
> > > +     if (nkm->max_rate && rate > nkm->max_rate)
> > > +             return nkm->max_rate;
> > > +
> >
> > I would expect the test to be the same for the minimum and maximum cases.
> 
> I don't have proper use-case for max rate test, I do verify by using
> higher the rate on dclock, but nor sure.  May be I can skip the
> max_rate patch?

So you're sending more patches that you haven't really tested?
Why are you sending them then?

> Apart from this, any idea about this issue where SUN4I_TCON0_DCLK_REG
> will only work with div upto 6 on A64 DSI panels[1], did you find the
> same issue on A33?

IIRC my panel was falling into the case where the divider was 4, so
I've not fallen into that case.

> With parent rate 330MHz, the resulting tcon divider for 30MHz [2]
> clock is 11 and for the same for 55MHz [3] clock is 6.

I'm not sure what the question is?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 03/26] clk: sunxi-ng: Add check for maximum rate to NKM PLLs

[Jagan Teki]

On Tue, Nov 20, 2018 at 4:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Thu, Nov 15, 2018 at 08:51:04PM +0530, Jagan Teki wrote:
> > > >  drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
> > > >  drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
> > > >  2 files changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > > > index 6b5ad990f802..b8b66cdd30bf 100644
> > > > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > > > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > > > @@ -128,6 +128,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> > > >       if (rate < nkm->min_rate)
> > > >               return nkm->min_rate;
> > > >
> > > > +     if (nkm->max_rate && rate > nkm->max_rate)
> > > > +             return nkm->max_rate;
> > > > +
> > >
> > > I would expect the test to be the same for the minimum and maximum cases.
> >
> > I don't have proper use-case for max rate test, I do verify by using
> > higher the rate on dclock, but nor sure.  May be I can skip the
> > max_rate patch?
>
> So you're sending more patches that you haven't really tested?

I didn't understand this question.

> Why are you sending them then?

I think I've mentioned in the first version patch itself, since it's
common code and many other callers might have used for rate
alternative I did it how other ccu dividers does. I have not added
just as simple.
>
> > Apart from this, any idea about this issue where SUN4I_TCON0_DCLK_REG
> > will only work with div upto 6 on A64 DSI panels[1], did you find the
> > same issue on A33?
>
> IIRC my panel was falling into the case where the divider was 4, so
> I've not fallen into that case.

OK, thanks.

[PATCH v4 06/26] dt-bindings: sun6i-dsi: Add compatible for A64 MIPI DSI

[Jagan Teki]

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
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

The horizontal and vertical back porch calculation in BSP
code is simply following the Linux drm comment diagram, in
include/drm/drm_modes.h which is

[hv]back porch = [hv]total - [hv]sync_end

BSP code form BPI-M64-bsp is calculating vertical back porch as
(from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)

timmings->ver_sync_time= panel_info->lcd_vspw;
timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;

vbp = panel->lcd_vbp;
vspw = panel->lcd_vspw;
dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
=>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
=>  timmings->ver_back_porch
=>  mode->vtotal - mode->end

Which evatually same as mode->vtotal - mode->vsync_end so update the
same in SUN6I_DSI_BASIC_SIZE0_VBP

On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
value.

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..eeea977604ac 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -526,8 +526,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
 	regmap_write(dsi->regs, SUN6I_DSI_BASIC_SIZE0_REG,
 		     SUN6I_DSI_BASIC_SIZE0_VSA(mode->vsync_end -
 					       mode->vsync_start) |
-		     SUN6I_DSI_BASIC_SIZE0_VBP(mode->vsync_start -
-					       mode->vdisplay));
+		     SUN6I_DSI_BASIC_SIZE0_VBP(mode->vtotal -
+					       mode->vsync_end));
 
 	regmap_write(dsi->regs, SUN6I_DSI_BASIC_SIZE1_REG,
 		     SUN6I_DSI_BASIC_SIZE1_VACT(mode->vdisplay) |
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Hi,

On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> The horizontal and vertical back porch calculation in BSP
> code is simply following the Linux drm comment diagram, in
> include/drm/drm_modes.h which is
> 
> [hv]back porch = [hv]total - [hv]sync_end
> 
> BSP code form BPI-M64-bsp is calculating vertical back porch as
> (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> 
> timmings->ver_sync_time= panel_info->lcd_vspw;
> timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> 
> vbp = panel->lcd_vbp;
> vspw = panel->lcd_vspw;
> dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> =>  timmings->ver_back_porch
> =>  mode->vtotal - mode->end
> 
> Which evatually same as mode->vtotal - mode->vsync_end so update the
> same in SUN6I_DSI_BASIC_SIZE0_VBP
> 
> On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> value.
> 
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>

I've tested your changes on my A33 board, and this commit will break
it.

It creates vblank timeouts, and visual artifacts at the bottom of the
display.

Later commits seem to fix the issue, but will create some blanking on
the upper third of the display.

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".

Having some datasheet for the panels you had working would help too.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > The horizontal and vertical back porch calculation in BSP
> > code is simply following the Linux drm comment diagram, in
> > include/drm/drm_modes.h which is
> >
> > [hv]back porch = [hv]total - [hv]sync_end
> >
> > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> >
> > timmings->ver_sync_time= panel_info->lcd_vspw;
> > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> >
> > vbp = panel->lcd_vbp;
> > vspw = panel->lcd_vspw;
> > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > =>  timmings->ver_back_porch
> > =>  mode->vtotal - mode->end
> >
> > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > same in SUN6I_DSI_BASIC_SIZE0_VBP
> >
> > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > value.
> >
> > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>
> I've tested your changes on my A33 board, and this commit will break
> it.
>
> It creates vblank timeouts, and visual artifacts at the bottom of the
> display.

Strange, VBP is earlier gives front porch which is anyway wrong.

>
> Later commits seem to fix the issue, but will create some blanking on
> the upper third of the display.
>
> 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".

W/o this 2-lane panel is breaking, same vblank timeout and visual
artifacts at the bottom of the panel. though the commits may reference
BSP, I have at-least tested on 3 different panels for us to prove its
working.

>
> Having some datasheet for the panels you had working would help too.

Unfortunately datasheet doesn't have any required information what we
actually looking for.

Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> > Hi,
> >
> > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > The horizontal and vertical back porch calculation in BSP
> > > code is simply following the Linux drm comment diagram, in
> > > include/drm/drm_modes.h which is
> > >
> > > [hv]back porch = [hv]total - [hv]sync_end
> > >
> > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > >
> > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > >
> > > vbp = panel->lcd_vbp;
> > > vspw = panel->lcd_vspw;
> > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > =>  timmings->ver_back_porch
> > > =>  mode->vtotal - mode->end
> > >
> > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > >
> > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > value.
> > >
> > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >
> > I've tested your changes on my A33 board, and this commit will break
> > it.
> >
> > It creates vblank timeouts, and visual artifacts at the bottom of the
> > display.
> 
> Strange, VBP is earlier gives front porch which is anyway wrong.
> 
> >
> > Later commits seem to fix the issue, but will create some blanking on
> > the upper third of the display.
> >
> > 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".
> 
> W/o this 2-lane panel is breaking, same vblank timeout and visual
> artifacts at the bottom of the panel. though the commits may reference
> BSP, I have at-least tested on 3 different panels for us to prove its
> working.
> 
> > Having some datasheet for the panels you had working would help too.
> 
> Unfortunately datasheet doesn't have any required information what we
> actually looking for.

Not even the timings? How did you get that information then?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > The horizontal and vertical back porch calculation in BSP
> > > > code is simply following the Linux drm comment diagram, in
> > > > include/drm/drm_modes.h which is
> > > >
> > > > [hv]back porch = [hv]total - [hv]sync_end
> > > >
> > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > >
> > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > >
> > > > vbp = panel->lcd_vbp;
> > > > vspw = panel->lcd_vspw;
> > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > =>  timmings->ver_back_porch
> > > > =>  mode->vtotal - mode->end
> > > >
> > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > >
> > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > value.
> > > >
> > > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > >
> > > I've tested your changes on my A33 board, and this commit will break
> > > it.
> > >
> > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > display.
> >
> > Strange, VBP is earlier gives front porch which is anyway wrong.
> >
> > >
> > > Later commits seem to fix the issue, but will create some blanking on
> > > the upper third of the display.
> > >
> > > 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".
> >
> > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > artifacts at the bottom of the panel. though the commits may reference
> > BSP, I have at-least tested on 3 different panels for us to prove its
> > working.
> >
> > > Having some datasheet for the panels you had working would help too.
> >
> > Unfortunately datasheet doesn't have any required information what we
> > actually looking for.
>
> Not even the timings? How did you get that information then?

datasheet has timing values, but this changes need controller
information about VBP register that I don't have. But again existing
VBP is not back porch for real, it's front porch.

Re: Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

On 20/11/18 9:55 PM, Jagan Teki wrote:
> On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>> On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
>>> On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
>>>>> The horizontal and vertical back porch calculation in BSP
>>>>> code is simply following the Linux drm comment diagram, in
>>>>> include/drm/drm_modes.h which is
>>>>>
>>>>> [hv]back porch = [hv]total - [hv]sync_end
>>>>>
>>>>> BSP code form BPI-M64-bsp is calculating vertical back porch as
>>>>> (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
>>>>>
>>>>> timmings->ver_sync_time= panel_info->lcd_vspw;
>>>>> timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
>>>>>
>>>>> vbp = panel->lcd_vbp;
>>>>> vspw = panel->lcd_vspw;
>>>>> dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
>>>>> dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
>>>>> =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
>>>>> =>  timmings->ver_back_porch
>>>>> =>  mode->vtotal - mode->end
>>>>>
>>>>> Which evatually same as mode->vtotal - mode->vsync_end so update the
>>>>> same in SUN6I_DSI_BASIC_SIZE0_VBP
>>>>>
>>>>> On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
>>>>> value.
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>>>>
>>>> I've tested your changes on my A33 board, and this commit will break
>>>> it.
>>>>
>>>> It creates vblank timeouts, and visual artifacts at the bottom of the
>>>> display.
>>>
>>> Strange, VBP is earlier gives front porch which is anyway wrong.
>>>
>>>>
>>>> Later commits seem to fix the issue, but will create some blanking on
>>>> the upper third of the display.
>>>>
>>>> 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".
>>>
>>> W/o this 2-lane panel is breaking, same vblank timeout and visual
>>> artifacts at the bottom of the panel. though the commits may reference
>>> BSP, I have at-least tested on 3 different panels for us to prove its
>>> working.
>>>
>>>> Having some datasheet for the panels you had working would help too.
>>>
>>> Unfortunately datasheet doesn't have any required information what we
>>> actually looking for.
>>
>> Not even the timings? How did you get that information then?
> 
> datasheet has timing values, but this changes need controller
> information about VBP register that I don't have. But again existing
> VBP is not back porch for real, it's front porch.
> 

I'm about to send next version by combining with burst mode changes in
one series. Do you have any further inputs on this. I didn't not see
any breakage with 4-lane devices, but has issue with 2-lane w/o this change.

Re: Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Mon, Nov 26, 2018 at 05:37:09PM +0530, Jagan Teki wrote:
> I'm about to send next version by combining with burst mode changes in
> one series. Do you have any further inputs on this. I didn't not see
> any breakage with 4-lane devices, but has issue with 2-lane w/o this change.

I'd rather focus on one thing for now. When your A64 DSI series will
be in, then you can focus on the burst mode.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3537 bytes --]

On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > > The horizontal and vertical back porch calculation in BSP
> > > > > code is simply following the Linux drm comment diagram, in
> > > > > include/drm/drm_modes.h which is
> > > > >
> > > > > [hv]back porch = [hv]total - [hv]sync_end
> > > > >
> > > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > > >
> > > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > > >
> > > > > vbp = panel->lcd_vbp;
> > > > > vspw = panel->lcd_vspw;
> > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > > =>  timmings->ver_back_porch
> > > > > =>  mode->vtotal - mode->end
> > > > >
> > > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > > >
> > > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > > value.
> > > > >
> > > > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > > >
> > > > I've tested your changes on my A33 board, and this commit will break
> > > > it.
> > > >
> > > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > > display.
> > >
> > > Strange, VBP is earlier gives front porch which is anyway wrong.
> > >
> > > >
> > > > Later commits seem to fix the issue, but will create some blanking on
> > > > the upper third of the display.
> > > >
> > > > 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".
> > >
> > > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > > artifacts at the bottom of the panel. though the commits may reference
> > > BSP, I have at-least tested on 3 different panels for us to prove its
> > > working.
> > >
> > > > Having some datasheet for the panels you had working would help too.
> > >
> > > Unfortunately datasheet doesn't have any required information what we
> > > actually looking for.
> >
> > Not even the timings? How did you get that information then?
> 
> datasheet has timing values, but this changes need controller
> information about VBP register that I don't have. But again existing
> VBP is not back porch for real, it's front porch.

Yet, this breaks the existing setup. So again:

> > > > 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

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

On Tue, Nov 27, 2018 at 3:55 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> > On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > >
> > > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > > > The horizontal and vertical back porch calculation in BSP
> > > > > > code is simply following the Linux drm comment diagram, in
> > > > > > include/drm/drm_modes.h which is
> > > > > >
> > > > > > [hv]back porch = [hv]total - [hv]sync_end
> > > > > >
> > > > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > > > >
> > > > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > > > >
> > > > > > vbp = panel->lcd_vbp;
> > > > > > vspw = panel->lcd_vspw;
> > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > > > =>  timmings->ver_back_porch
> > > > > > =>  mode->vtotal - mode->end
> > > > > >
> > > > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > > > >
> > > > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > > > value.
> > > > > >
> > > > > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > > > >
> > > > > I've tested your changes on my A33 board, and this commit will break
> > > > > it.
> > > > >
> > > > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > > > display.
> > > >
> > > > Strange, VBP is earlier gives front porch which is anyway wrong.
> > > >
> > > > >
> > > > > Later commits seem to fix the issue, but will create some blanking on
> > > > > the upper third of the display.
> > > > >
> > > > > 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".
> > > >
> > > > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > > > artifacts at the bottom of the panel. though the commits may reference
> > > > BSP, I have at-least tested on 3 different panels for us to prove its
> > > > working.
> > > >
> > > > > Having some datasheet for the panels you had working would help too.
> > > >
> > > > Unfortunately datasheet doesn't have any required information what we
> > > > actually looking for.
> > >
> > > Not even the timings? How did you get that information then?
> >
> > datasheet has timing values, but this changes need controller
> > information about VBP register that I don't have. But again existing
> > VBP is not back porch for real, it's front porch.
>
> Yet, this breaks the existing setup. So again:

Was it with 4-lane or 2-lane panel? can you test it with 2-lane panel?
I can see the issue on 2-lane but the 4-lane working fine with this
patch even.

Re: [linux-sunxi] Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3874 bytes --]

On Tue, Nov 27, 2018 at 04:34:35PM +0530, Jagan Teki wrote:
> On Tue, Nov 27, 2018 at 3:55 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> > > On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > > > > The horizontal and vertical back porch calculation in BSP
> > > > > > > code is simply following the Linux drm comment diagram, in
> > > > > > > include/drm/drm_modes.h which is
> > > > > > >
> > > > > > > [hv]back porch = [hv]total - [hv]sync_end
> > > > > > >
> > > > > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > > > > >
> > > > > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > > > > >
> > > > > > > vbp = panel->lcd_vbp;
> > > > > > > vspw = panel->lcd_vspw;
> > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > > > > =>  timmings->ver_back_porch
> > > > > > > =>  mode->vtotal - mode->end
> > > > > > >
> > > > > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > > > > >
> > > > > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > > > > value.
> > > > > > >
> > > > > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > >
> > > > > > I've tested your changes on my A33 board, and this commit will break
> > > > > > it.
> > > > > >
> > > > > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > > > > display.
> > > > >
> > > > > Strange, VBP is earlier gives front porch which is anyway wrong.
> > > > >
> > > > > >
> > > > > > Later commits seem to fix the issue, but will create some blanking on
> > > > > > the upper third of the display.
> > > > > >
> > > > > > 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".
> > > > >
> > > > > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > > > > artifacts at the bottom of the panel. though the commits may reference
> > > > > BSP, I have at-least tested on 3 different panels for us to prove its
> > > > > working.
> > > > >
> > > > > > Having some datasheet for the panels you had working would help too.
> > > > >
> > > > > Unfortunately datasheet doesn't have any required information what we
> > > > > actually looking for.
> > > >
> > > > Not even the timings? How did you get that information then?
> > >
> > > datasheet has timing values, but this changes need controller
> > > information about VBP register that I don't have. But again existing
> > > VBP is not back porch for real, it's front porch.
> >
> > Yet, this breaks the existing setup. So again:
> 
> Was it with 4-lane or 2-lane panel? can you test it with 2-lane panel?
> I can see the issue on 2-lane but the 4-lane working fine with this
> patch even.

It's a 4 lane display.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation

[Jagan Teki]

On Fri, Dec 7, 2018 at 6:51 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Nov 27, 2018 at 04:34:35PM +0530, Jagan Teki wrote:
> > On Tue, Nov 27, 2018 at 3:55 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> > > > On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > >
> > > > > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > > > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > > > > > The horizontal and vertical back porch calculation in BSP
> > > > > > > > code is simply following the Linux drm comment diagram, in
> > > > > > > > include/drm/drm_modes.h which is
> > > > > > > >
> > > > > > > > [hv]back porch = [hv]total - [hv]sync_end
> > > > > > > >
> > > > > > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > > > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > > > > > >
> > > > > > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > > > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > > > > > >
> > > > > > > > vbp = panel->lcd_vbp;
> > > > > > > > vspw = panel->lcd_vspw;
> > > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > > > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > > > > > =>  timmings->ver_back_porch
> > > > > > > > =>  mode->vtotal - mode->end
> > > > > > > >
> > > > > > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > > > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > > > > > >
> > > > > > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > > > > > value.
> > > > > > > >
> > > > > > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > >
> > > > > > > I've tested your changes on my A33 board, and this commit will break
> > > > > > > it.
> > > > > > >
> > > > > > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > > > > > display.
> > > > > >
> > > > > > Strange, VBP is earlier gives front porch which is anyway wrong.
> > > > > >
> > > > > > >
> > > > > > > Later commits seem to fix the issue, but will create some blanking on
> > > > > > > the upper third of the display.
> > > > > > >
> > > > > > > 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".
> > > > > >
> > > > > > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > > > > > artifacts at the bottom of the panel. though the commits may reference
> > > > > > BSP, I have at-least tested on 3 different panels for us to prove its
> > > > > > working.
> > > > > >
> > > > > > > Having some datasheet for the panels you had working would help too.
> > > > > >
> > > > > > Unfortunately datasheet doesn't have any required information what we
> > > > > > actually looking for.
> > > > >
> > > > > Not even the timings? How did you get that information then?
> > > >
> > > > datasheet has timing values, but this changes need controller
> > > > information about VBP register that I don't have. But again existing
> > > > VBP is not back porch for real, it's front porch.
> > >
> > > Yet, this breaks the existing setup. So again:
> >
> > Was it with 4-lane or 2-lane panel? can you test it with 2-lane panel?
> > I can see the issue on 2-lane but the 4-lane working fine with this
> > patch even.
>
> It's a 4 lane display.

Thanks, look like my panel timings seems reverse b/w BP and FP. It
work irrespective of this change after proper update.

[PATCH v4 11/26] drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value

[Jagan Teki]

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 f6e3df8d2490..de0992052a90 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 +
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 01/26] clk: sunxi-ng: a64: Fix gate bit of DSI DPHY

[Jagan Teki]

DSI DPHY gate bit on MIPI DSI clock register is bit 15
not bit 30.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f7d297368eb2..019d67bf97c4 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -581,7 +581,7 @@ static const char * const dsi_dphy_parents[] = { "pll-video0", "pll-periph0" };
 static const u8 dsi_dphy_table[] = { 0, 2, };
 static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(dsi_dphy_clk, "dsi-dphy",
 				       dsi_dphy_parents, dsi_dphy_table,
-				       0x168, 0, 4, 8, 2, BIT(31), CLK_SET_RATE_PARENT);
+				       0x168, 0, 4, 8, 2, BIT(15), CLK_SET_RATE_PARENT);
 
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 			     0x1a0, 0, 3, BIT(31), CLK_SET_RATE_PARENT);
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 01/26] clk: sunxi-ng: a64: Fix gate bit of DSI DPHY

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Tue, Nov 13, 2018 at 04:46:08PM +0530, Jagan Teki wrote:
> DSI DPHY gate bit on MIPI DSI clock register is bit 15
> not bit 30.
> 
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Acked-by: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH v4 02/26] clk: sunxi-ng: Add check for minimal rate to NKM PLLs

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/clk/sunxi-ng/ccu_nkm.c | 3 +++
 drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 841840e35e61..6b5ad990f802 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -125,6 +125,9 @@ 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)
+		return nkm->min_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;
 };
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 04/26] drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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)
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 05/26] drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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);
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 07/26] drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param transfer

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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;
 
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 09/26] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 eeea977604ac..fc4252d96c38 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;
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 10/26] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 fc4252d96c38..f6e3df8d2490 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,
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 12/26] drm/sun4i: sun6i_mipi_dsi: Fix DSI hblk timing calculation

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 de0992052a90..cd657ac4bdae 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
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 13/26] drm/sun4i: sun6i_mipi_dsi: Add DSI hblk packet overhead

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 cd657ac4bdae..1a3cdd5b72a0 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
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 14/26] drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 1a3cdd5b72a0..63b924b89bd7 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.
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 17/26] dt-bindings: sun6i-dsi: Add VCC-DSI supply property

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.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
 
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 17/26] dt-bindings: sun6i-dsi: Add VCC-DSI supply property

[Rob Herring]

On Tue, 13 Nov 2018 16:46:24 +0530, Jagan Teki wrote:
> 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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 

Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

[PATCH v4 18/26] dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge

[Jagan Teki]

Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB
bridge panel, which is available on same PCB with 24-bit RGB interface.

So, this patch adds DSI specific binding details on existing
dt-bindings file.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 .../display/panel/bananapi,s070wv20-ct16.txt  | 31 +++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
index 35bc0c839f49..b7855dc7c66f 100644
--- a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -1,12 +1,39 @@
 Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
 
+S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB interface.
+
+Depending on the variant, the PCB attached to the panel module either
+supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via
+an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel
+itself
+
 Required properties:
-- compatible: should be "bananapi,s070wv20-ct16"
+- compatible:
+  for 24-bit RGB interface, use "bananapi,s070wv20-ct16"
+  for ICN6211 MIPI-DSI to RGB bridge, use "bananapi,s070wv20-ct16-icn6211"
+
+Required properties for RGB:
 - power-supply: see ./panel-common.txt
 
+Required properties for MIPI-DSI to RGB:
+- reg: for DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
 Optional properties:
-- enable-gpios: see ./simple-panel.txt
+- enable-gpios: see ./simple-panel.txt(not available in MIPI-DSI to RGB bridge)
 - backlight: see ./simple-panel.txt
 
 This binding is compatible with the simple-panel binding, which is specified
 in ./simple-panel.txt.
+
+Example:
+panel@0 {
+	compatible = "bananapi,s070wv20-ct16-icn6211";
+	reg = <0>;
+	avdd-supply = <&reg_dc1sw>;
+	dvdd-supply = <&reg_dldo1>;
+	reset-gpios = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+	backlight = <&backlight_dsi>;
+};
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 20/26] dt-bindings: panel: Add Techstar TS8550B MIPI-DSI panel

[Jagan Teki]

Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI
LCD panel. Add dt-bingings for it.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 .../display/panel/techstar,ts8550b.txt        | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt

diff --git a/Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt b/Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt
new file mode 100644
index 000000000000..9d3056dd8bf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt
@@ -0,0 +1,22 @@
+Techstar TS8550B MIPI-DSI LCD Panel
+
+Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel.
+
+Required properties:
+- compatible: must be "techstar,ts8550b"
+- reg: DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+	compatible = "techstar,ts8550b";
+	reg = <0>;
+	avdd-supply = <&reg_dc1sw>;
+	dvdd-supply = <&reg_dldo2>;
+	reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+	backlight = <&backlight>;
+};
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 21/26] drm/panel: Add Techstar TS8550B MIPI-DSI LCD panel

[Jagan Teki]

Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI
LCD panel. Add panel driver for it.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 MAINTAINERS                                   |   6 +
 drivers/gpu/drm/panel/Kconfig                 |   9 +
 drivers/gpu/drm/panel/Makefile                |   1 +
 .../gpu/drm/panel/panel-techstar-ts8550b.c    | 324 ++++++++++++++++++
 4 files changed, 340 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-techstar-ts8550b.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f5bb2ffa1089..3dac08d0b3cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4718,6 +4718,12 @@ S:	Maintained
 F:	drivers/gpu/drm/tinydrm/st7735r.c
 F:	Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 
+DRM DRIVER FOR TECHSTAR TS8550B MIPI-DSI LCD PANELS
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	drivers/gpu/drm/panel/panel-techstar-ts8550b.c
+F:	Documentation/devicetree/bindings/display/panel/techstar,ts8550b.txt
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S:	Orphan / Obsolete
 F:	drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 20b88c275421..d0d4e60f5153 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -195,4 +195,13 @@ config DRM_PANEL_SITRONIX_ST7789V
 	  Say Y here if you want to enable support for the Sitronix
 	  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_TECHSTAR_TS8550B
+	tristate "Techstar TS8550B MIPI-DSI panel driver"
+	depends on OF
+	depends on DRM_MIPI_DSI
+	depends on BACKLIGHT_CLASS_DEVICE
+	help
+	  Say Y if you want to enable support for panels based on the
+	  Techstar TS8550B MIPI-DSI interface.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 04696bb85218..88011f06edb8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TECHSTAR_TS8550B) += panel-techstar-ts8550b.o
diff --git a/drivers/gpu/drm/panel/panel-techstar-ts8550b.c b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
new file mode 100644
index 000000000000..70a5f8ec6908
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019, Amarula Solutions.
+ * Author: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+
+#include <video/mipi_display.h>
+
+struct techstar {
+	struct drm_panel	panel;
+	struct mipi_dsi_device	*dsi;
+
+	struct backlight_device *backlight;
+	struct regulator	*dvdd;
+	struct regulator	*avdd;
+	struct gpio_desc	*reset;
+};
+
+static inline struct techstar *panel_to_techstar(struct drm_panel *panel)
+{
+	return container_of(panel, struct techstar, panel);
+}
+
+static inline int techstar_dcs_write_seq(struct techstar *ctx, const void *seq,
+					size_t len)
+{
+	return mipi_dsi_dcs_write_buffer(ctx->dsi, seq, len);
+};
+
+#define techstar_dcs_write_seq_static(ctx, seq...)		\
+	({							\
+		static const u8 d[] = { seq };			\
+		techstar_dcs_write_seq(ctx, d, ARRAY_SIZE(d));	\
+	})
+
+static void techstar_init_sequence(struct techstar *ctx)
+{
+	techstar_dcs_write_seq_static(ctx, MIPI_DCS_SOFT_RESET, 0x00);
+	msleep(200);
+	techstar_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x11);
+	techstar_dcs_write_seq_static(ctx, 0xD1, 0x11);
+	techstar_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE, 0x00);
+	msleep(200);
+	techstar_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x10);
+	techstar_dcs_write_seq_static(ctx, 0xC0, 0xE9, 0x03);
+	techstar_dcs_write_seq_static(ctx, 0xC1, 0x12, 0x02);
+	techstar_dcs_write_seq_static(ctx, 0xC2, 0x07, 0x06);
+	techstar_dcs_write_seq_static(ctx, 0xB0, 0x00, 0x0E, 0x15, 0x0F, 0x11,
+				     0x08, 0x08, 0x08, 0x08, 0x23, 0x04, 0x13,
+				     0x12, 0x2B, 0x34, 0x1F);
+	techstar_dcs_write_seq_static(ctx, 0xB1, 0x00, 0x0E, 0x95, 0x0F, 0x13,
+				     0x07, 0x09, 0x08, 0x08, 0x22, 0x04, 0x10,
+				     0x0E, 0x2C, 0x34, 0x1F);
+	techstar_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x11);
+	techstar_dcs_write_seq_static(ctx, 0xB0, 0x45);
+	techstar_dcs_write_seq_static(ctx, 0xB1, 0x13);
+	techstar_dcs_write_seq_static(ctx, 0xB2, 0x07);
+	techstar_dcs_write_seq_static(ctx, 0xB3, 0x80);
+	techstar_dcs_write_seq_static(ctx, 0xB5, 0x47);
+	techstar_dcs_write_seq_static(ctx, 0xB7, 0x85);
+	techstar_dcs_write_seq_static(ctx, 0xB8, 0x20);
+	techstar_dcs_write_seq_static(ctx, 0xB9, 0x11);
+	techstar_dcs_write_seq_static(ctx, 0xC1, 0x78);
+	techstar_dcs_write_seq_static(ctx, 0xC2, 0x78);
+	techstar_dcs_write_seq_static(ctx, 0xD0, 0x88);
+	msleep(100);
+	techstar_dcs_write_seq_static(ctx, 0xE0, 0x00, 0x00, 0x02);
+	techstar_dcs_write_seq_static(ctx, 0xE1, 0x0B, 0x00, 0x0D, 0x00, 0x0C,
+				     0x00, 0x0E, 0x00, 0x00, 0x44, 0x44);
+	techstar_dcs_write_seq_static(ctx, 0xE2, 0x33, 0x33, 0x44, 0x44, 0x64,
+				     0x00, 0x66, 0x00, 0x65, 0x00, 0x67, 0x00,
+				     0x00);
+	techstar_dcs_write_seq_static(ctx, 0xE3, 0x00, 0x00, 0x33, 0x33);
+	techstar_dcs_write_seq_static(ctx, 0xE4, 0x44, 0x44);
+	techstar_dcs_write_seq_static(ctx, 0xE5, 0x0C, 0x78, 0x3C, 0xA0, 0x0E,
+				     0x78, 0x3C, 0xA0, 0x10, 0x78, 0x3C, 0xA0,
+				     0x12, 0x78, 0x3C, 0xA0);
+	techstar_dcs_write_seq_static(ctx, 0xE6, 0x00, 0x00, 0x33, 0x33);
+	techstar_dcs_write_seq_static(ctx, 0xE7, 0x44, 0x44);
+	techstar_dcs_write_seq_static(ctx, 0xE8, 0x0D, 0x78, 0x3C, 0xA0, 0x0F,
+				     0x78, 0x3C, 0xA0, 0x11, 0x78, 0x3C, 0xA0,
+				     0x13, 0x78, 0x3C, 0xA0);
+	techstar_dcs_write_seq_static(ctx, 0xEB, 0x02, 0x02, 0x39, 0x39, 0xEE,
+				     0x44, 0x00);
+	techstar_dcs_write_seq_static(ctx, 0xEC, 0x00, 0x00);
+	techstar_dcs_write_seq_static(ctx, 0xED, 0xFF, 0xF1, 0x04, 0x56, 0x72,
+				     0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xF3, 0x27,
+				     0x65, 0x40, 0x1F, 0xFF);
+	techstar_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x00);
+	msleep(10);
+	techstar_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON, 0x00);
+	msleep(200);
+}
+
+static int techstar_prepare(struct drm_panel *panel)
+{
+	struct techstar *ctx = panel_to_techstar(panel);
+	int ret;
+
+	gpiod_set_value(ctx->reset, 0);
+	msleep(20);
+
+	ret = regulator_enable(ctx->dvdd);
+	if (ret)
+		return ret;
+	msleep(20);
+
+	ret = regulator_enable(ctx->avdd);
+	if (ret)
+		return ret;
+	msleep(20);
+
+	gpiod_set_value(ctx->reset, 1);
+	msleep(20);
+
+	gpiod_set_value(ctx->reset, 0);
+	msleep(30);
+
+	gpiod_set_value(ctx->reset, 1);
+	msleep(150);
+
+	techstar_init_sequence(ctx);
+
+	return 0;
+}
+
+static int techstar_enable(struct drm_panel *panel)
+{
+	struct techstar *ctx = panel_to_techstar(panel);
+
+	msleep(120);
+
+	mipi_dsi_dcs_set_display_on(ctx->dsi);
+	backlight_enable(ctx->backlight);
+
+	return 0;
+}
+
+static int techstar_disable(struct drm_panel *panel)
+{
+	struct techstar *ctx = panel_to_techstar(panel);
+
+	backlight_disable(ctx->backlight);
+	return mipi_dsi_dcs_set_display_on(ctx->dsi);
+}
+
+static int techstar_unprepare(struct drm_panel *panel)
+{
+	struct techstar *ctx = panel_to_techstar(panel);
+	int ret;
+
+	ret = mipi_dsi_dcs_set_display_off(ctx->dsi);
+	if (ret < 0)
+		dev_err(panel->dev, "failed to set display off: %d\n", ret);
+
+	ret = mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+	if (ret < 0)
+		dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+
+	msleep(120);
+
+	regulator_disable(ctx->dvdd);
+
+	regulator_disable(ctx->avdd);
+
+	gpiod_set_value(ctx->reset, 0);
+
+	gpiod_set_value(ctx->reset, 1);
+
+	gpiod_set_value(ctx->reset, 0);
+
+	return 0;
+}
+
+static const struct drm_display_mode default_mode = {
+	.clock		= 27500,
+	.vrefresh	= 60,
+
+	.hdisplay	= 480,
+	.hsync_start	= 480 + 38,
+	.hsync_end	= 480 + 38 + 12,
+	.htotal		= 480 + 38 + 12 + 12,
+
+	.vdisplay	= 854,
+	.vsync_start	= 854 + 18,
+	.vsync_end	= 854 + 18 + 8,
+	.vtotal		= 854 + 18 + 8 + 4,
+
+	.width_mm	= 69,
+	.height_mm	= 139,
+};
+
+static int techstar_get_modes(struct drm_panel *panel)
+{
+	struct drm_connector *connector = panel->connector;
+	struct techstar *ctx = panel_to_techstar(panel);
+	struct drm_display_mode *mode;
+
+	mode = drm_mode_duplicate(panel->drm, &default_mode);
+	if (!mode) {
+		dev_err(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
+			default_mode.hdisplay, default_mode.vdisplay,
+			default_mode.vrefresh);
+		return -ENOMEM;
+	}
+
+	drm_mode_set_name(mode);
+
+	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+	drm_mode_probed_add(connector, mode);
+
+	panel->connector->display_info.width_mm = mode->width_mm;
+	panel->connector->display_info.height_mm = mode->height_mm;
+
+	return 1;
+}
+
+static const struct drm_panel_funcs techstar_funcs = {
+	.disable	= techstar_disable,
+	.unprepare	= techstar_unprepare,
+	.prepare	= techstar_prepare,
+	.enable		= techstar_enable,
+	.get_modes	= techstar_get_modes,
+};
+
+static int techstar_dsi_probe(struct mipi_dsi_device *dsi)
+{
+	struct device_node *np;
+	struct techstar *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	mipi_dsi_set_drvdata(dsi, ctx);
+	ctx->dsi = dsi;
+
+	drm_panel_init(&ctx->panel);
+	ctx->panel.dev = &dsi->dev;
+	ctx->panel.funcs = &techstar_funcs;
+
+	ctx->dvdd = devm_regulator_get(&dsi->dev, "dvdd");
+	if (IS_ERR(ctx->dvdd)) {
+		dev_err(&dsi->dev, "Couldn't get dvdd regulator\n");
+		return PTR_ERR(ctx->dvdd);
+	}
+
+	ctx->avdd = devm_regulator_get(&dsi->dev, "avdd");
+	if (IS_ERR(ctx->avdd)) {
+		dev_err(&dsi->dev, "Couldn't get avdd regulator\n");
+		return PTR_ERR(ctx->avdd);
+	}
+
+	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->reset)) {
+		dev_err(&dsi->dev, "Couldn't get our reset GPIO\n");
+		return PTR_ERR(ctx->reset);
+	}
+
+	np = of_parse_phandle(dsi->dev.of_node, "backlight", 0);
+	if (np) {
+		ctx->backlight = of_find_backlight_by_node(np);
+		of_node_put(np);
+
+		if (!ctx->backlight)
+			return -EPROBE_DEFER;
+	}
+
+	ret = drm_panel_add(&ctx->panel);
+	if (ret < 0)
+		return ret;
+
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+	dsi->lanes = 2;
+
+	return mipi_dsi_attach(dsi);
+}
+
+static int techstar_dsi_remove(struct mipi_dsi_device *dsi)
+{
+	struct techstar *ctx = mipi_dsi_get_drvdata(dsi);
+
+	mipi_dsi_detach(dsi);
+	drm_panel_remove(&ctx->panel);
+
+	if (ctx->backlight)
+		put_device(&ctx->backlight->dev);
+
+	return 0;
+}
+
+static const struct of_device_id techstar_of_match[] = {
+	{ .compatible = "techstar,ts8550b" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, techstar_of_match);
+
+static struct mipi_dsi_driver techstar_dsi_driver = {
+	.probe		= techstar_dsi_probe,
+	.remove		= techstar_dsi_remove,
+	.driver = {
+		.name		= "techstar-ts8550b",
+		.of_match_table	= techstar_of_match,
+	},
+};
+module_mipi_dsi_driver(techstar_dsi_driver);
+
+MODULE_AUTHOR("Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>");
+MODULE_DESCRIPTION("Techstar TS8550B MIPI-DSI LCD Panel Driver");
+MODULE_LICENSE("GPL");
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 22/26] clk: sunxi-ng: a64: Add min and max rate for PLL_MIPI

[Jagan Teki]

Manual noted to use PLL_MIPI rate 500MHz to 1.4GHz,
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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 019d67bf97c4..5a3a5b821f8b 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -167,6 +167,8 @@ 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 */
+	.max_rate	= 1400000000UL,
 	.common		= {
 		.reg		= 0x040,
 		.hw.init	= CLK_HW_INIT("pll-mipi", "pll-video0",
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 23/26] dt-bindings: sun6i-dsi: Add compatible for A64 DPHY

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 24/26] arm64: dts: allwinner: a64: Add DSI pipeline

[Jagan Teki]

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-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 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 f3a66f888205..d6f269883759 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -320,6 +320,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>;
+					};
 				};
 			};
 		};
@@ -829,6 +835,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>;
+		};
+
 		hdmi: hdmi@1ee0000 {
 			compatible = "allwinner,sun50i-a64-dw-hdmi",
 				     "allwinner,sun8i-a83t-dw-hdmi";
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Jagan Teki]

This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.

DSI panel connected via board DSI port with,
- DC1SW as AVDD supply
- DCDC1 as DVDD supply
- PD6 gpio for reset pin
- PD5 gpio for backlight enable pin
- PD7 gpio for backlight vdd supply

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index ef1c90401bb2..6cb010e3bbd9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -45,6 +45,7 @@
 #include "sun50i-a64.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "BananaPi-M64";
@@ -56,6 +57,15 @@
 		serial1 = &uart1;
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
+		brightness-levels = <1 2 4 8 16 32 64 128 512>;
+		default-brightness-level = <2>;
+		enable-gpios = <&pio 3 5 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD5 */
+		power-supply = <&reg_vdd_backlight>;
+	};
+
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
@@ -91,6 +101,15 @@
 		};
 	};
 
+	reg_vdd_backlight: vdd-backlight {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd-backlight";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pio 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PD7 */
+		enable-active-high;
+	};
+
 	wifi_pwrseq: wifi_pwrseq {
 		compatible = "mmc-pwrseq-simple";
 		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
@@ -101,6 +120,23 @@
 	status = "okay";
 };
 
+&dphy {
+	status = "okay";
+};
+
+&dsi {
+	status = "okay";
+
+	panel@0 {
+		compatible = "bananapi,s070wv20-ct16-icn6211";
+		reg = <0>;
+		avdd-supply = <&reg_dc1sw>;
+		dvdd-supply = <&reg_dldo1>;
+		reset-gpios = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD6 */
+		backlight = <&backlight>;
+	};
+};
+
 &ehci0 {
 	status = "okay";
 };
@@ -193,6 +229,12 @@
 	status = "okay";
 };
 
+&r_pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&r_pwm_pin>;
+	status = "okay";
+};
+
 &r_rsb {
 	status = "okay";
 
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Andre Przywara]

On Tue, 13 Nov 2018 16:46:32 +0530
Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

Hi,

> This patch add support for Bananapi S070WV20-CT16 DSI panel to
> BPI-M64 board.
> 
> DSI panel connected via board DSI port with,
> - DC1SW as AVDD supply

Are you sure of that? I don't see anything in the schematic to support
this. The only power lines that go to the DSI connector are DCDC1 and
PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
Is there anything I miss?

> - DCDC1 as DVDD supply

That seems right, but doesn't match with what you write below.

> - PD6 gpio for reset pin
> - PD5 gpio for backlight enable pin
> - PD7 gpio for backlight vdd supply
> 
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
>  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42
> +++++++++++++++++++ 1 file changed, 42 insertions(+)
> 
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> ef1c90401bb2..6cb010e3bbd9 100644 ---
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts +++
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts @@ -45,6
> +45,7 @@ #include "sun50i-a64.dtsi" 
>  #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
>  
>  / {
>  	model = "BananaPi-M64";
> @@ -56,6 +57,15 @@
>  		serial1 = &uart1;
>  	};
>  
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
> +		brightness-levels = <1 2 4 8 16 32 64 128 512>;
> +		default-brightness-level = <2>;
> +		enable-gpios = <&pio 3 5 GPIO_ACTIVE_HIGH>; /*
> LCD-BL-EN: PD5 */
> +		power-supply = <&reg_vdd_backlight>;
> +	};
> +
>  	chosen {
>  		stdout-path = "serial0:115200n8";
>  	};
> @@ -91,6 +101,15 @@
>  		};
>  	};
>  
> +	reg_vdd_backlight: vdd-backlight {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vdd-backlight";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&pio 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> PD7 */
> +		enable-active-high;
> +	};
> +
>  	wifi_pwrseq: wifi_pwrseq {
>  		compatible = "mmc-pwrseq-simple";
>  		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> @@ -101,6 +120,23 @@
>  	status = "okay";
>  };
>  
> +&dphy {
> +	status = "okay";
> +};
> +
> +&dsi {
> +	status = "okay";
> +
> +	panel@0 {
> +		compatible = "bananapi,s070wv20-ct16-icn6211";
> +		reg = <0>;
> +		avdd-supply = <&reg_dc1sw>;

As mentioned above, I don't see this on the DSI connector.

> +		dvdd-supply = <&reg_dldo1>;

Mmh, this line is connected to the *SoC*, to drive the DSI data lines
or the DPHY, presumably. So I wouldn't expect it in the panel node, but
rather in the DPHY or DSI node. Although I can't find a power-supply
property in those bindings.

Cheers,
Andre.

> +		reset-gpios = <&pio 3 6 GPIO_ACTIVE_HIGH>; /*
> LCD-RST: PD6 */
> +		backlight = <&backlight>;
> +	};
> +};
> +
>  &ehci0 {
>  	status = "okay";
>  };
> @@ -193,6 +229,12 @@
>  	status = "okay";
>  };
>  
> +&r_pwm {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&r_pwm_pin>;
> +	status = "okay";
> +};
> +
>  &r_rsb {
>  	status = "okay";
>  

Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Jagan Teki]

On Tue, Nov 13, 2018 at 5:52 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Tue, 13 Nov 2018 16:46:32 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi,
>
> > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > BPI-M64 board.
> >
> > DSI panel connected via board DSI port with,
> > - DC1SW as AVDD supply
>
> Are you sure of that? I don't see anything in the schematic to support
> this. The only power lines that go to the DSI connector are DCDC1 and
> PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
> Is there anything I miss?

Thanks for the comment, yes dc1sw is connected in ephy. I have reused
dc1, BSP is attached lcd_power1 to axp81x_dc1sw [1]. I just looking
for someone to comment, may be we can skip this regulator attachment.

>
> > - DCDC1 as DVDD supply
>
> That seems right, but doesn't match with what you write below.

Commit need to fix s/DCDC1/DLDO1

>
> > - PD6 gpio for reset pin
> > - PD5 gpio for backlight enable pin
> > - PD7 gpio for backlight vdd supply
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42
> > +++++++++++++++++++ 1 file changed, 42 insertions(+)
> >
> > diff --git
> > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> > ef1c90401bb2..6cb010e3bbd9 100644 ---
> > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts +++
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts @@ -45,6
> > +45,7 @@ #include "sun50i-a64.dtsi"
> >  #include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/pwm/pwm.h>
> >
> >  / {
> >       model = "BananaPi-M64";
> > @@ -56,6 +57,15 @@
> >               serial1 = &uart1;
> >       };
> >
> > +     backlight: backlight {
> > +             compatible = "pwm-backlight";
> > +             pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
> > +             brightness-levels = <1 2 4 8 16 32 64 128 512>;
> > +             default-brightness-level = <2>;
> > +             enable-gpios = <&pio 3 5 GPIO_ACTIVE_HIGH>; /*
> > LCD-BL-EN: PD5 */
> > +             power-supply = <&reg_vdd_backlight>;
> > +     };
> > +
> >       chosen {
> >               stdout-path = "serial0:115200n8";
> >       };
> > @@ -91,6 +101,15 @@
> >               };
> >       };
> >
> > +     reg_vdd_backlight: vdd-backlight {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "vdd-backlight";
> > +             regulator-min-microvolt = <3300000>;
> > +             regulator-max-microvolt = <3300000>;
> > +             gpio = <&pio 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> > PD7 */
> > +             enable-active-high;
> > +     };
> > +
> >       wifi_pwrseq: wifi_pwrseq {
> >               compatible = "mmc-pwrseq-simple";
> >               reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > @@ -101,6 +120,23 @@
> >       status = "okay";
> >  };
> >
> > +&dphy {
> > +     status = "okay";
> > +};
> > +
> > +&dsi {
> > +     status = "okay";
> > +
> > +     panel@0 {
> > +             compatible = "bananapi,s070wv20-ct16-icn6211";
> > +             reg = <0>;
> > +             avdd-supply = <&reg_dc1sw>;
>
> As mentioned above, I don't see this on the DSI connector.
>
> > +             dvdd-supply = <&reg_dldo1>;
>
> Mmh, this line is connected to the *SoC*, to drive the DSI data lines
> or the DPHY, presumably. So I wouldn't expect it in the panel node, but
> rather in the DPHY or DSI node. Although I can't find a power-supply
> property in those bindings.

Got it, this has to attach via vcc-dsi-supply.

[1] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/bootloader/blobs/bpi-m64-lcd7.dts#L2266

Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Chen-Yu Tsai]

On Wed, Nov 14, 2018 at 2:31 PM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>
> On Tue, Nov 13, 2018 at 5:52 PM Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> >
> > On Tue, 13 Nov 2018 16:46:32 +0530
> > Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >
> > Hi,
> >
> > > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > > BPI-M64 board.
> > >
> > > DSI panel connected via board DSI port with,
> > > - DC1SW as AVDD supply
> >
> > Are you sure of that? I don't see anything in the schematic to support
> > this. The only power lines that go to the DSI connector are DCDC1 and
> > PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
> > Is there anything I miss?
>
> Thanks for the comment, yes dc1sw is connected in ephy. I have reused
> dc1, BSP is attached lcd_power1 to axp81x_dc1sw [1]. I just looking
> for someone to comment, may be we can skip this regulator attachment.

That seems sketchy. The schematics show the connector has feeds from both
the unregulated output IPSOUT (PS) and DCDC1. For designs with RGB LCD
panels, we only see the PS feed. Since the LCD panel can be used in either
RGB or MIPI DSI mode, I highly suspect the DCDC1 supply feeds the bridge
IC.

As for DC1SW, this is likely referenced because it provides power to the
GPIO lines that are used to control the LCD panel. If you don't provide
power, you can't pull them up.

While many of us dislike FEX and the new FEX-derived device tree, they
do provide some information, such as regulator usage. Note that each
regulator output has multiple names, which likely denote specific
usages.

I've asked BPI for schematics on the bridge board. Hopefully we'll
have something in more detail. In the meantime, I suggest leaving
this panel out of your next submission, and focus on getting the bulk
of the dsi driver and dts changes in first.

ChenYu

>
> >
> > > - DCDC1 as DVDD supply
> >
> > That seems right, but doesn't match with what you write below.
>
> Commit need to fix s/DCDC1/DLDO1
>
> >
> > > - PD6 gpio for reset pin
> > > - PD5 gpio for backlight enable pin
> > > - PD7 gpio for backlight vdd supply
> > >
> > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > > ---
> > >  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42
> > > +++++++++++++++++++ 1 file changed, 42 insertions(+)
> > >
> > > diff --git
> > > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> > > ef1c90401bb2..6cb010e3bbd9 100644 ---
> > > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts +++
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts @@ -45,6
> > > +45,7 @@ #include "sun50i-a64.dtsi"
> > >  #include <dt-bindings/gpio/gpio.h>
> > > +#include <dt-bindings/pwm/pwm.h>
> > >
> > >  / {
> > >       model = "BananaPi-M64";
> > > @@ -56,6 +57,15 @@
> > >               serial1 = &uart1;
> > >       };
> > >
> > > +     backlight: backlight {
> > > +             compatible = "pwm-backlight";
> > > +             pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
> > > +             brightness-levels = <1 2 4 8 16 32 64 128 512>;
> > > +             default-brightness-level = <2>;
> > > +             enable-gpios = <&pio 3 5 GPIO_ACTIVE_HIGH>; /*
> > > LCD-BL-EN: PD5 */
> > > +             power-supply = <&reg_vdd_backlight>;
> > > +     };
> > > +
> > >       chosen {
> > >               stdout-path = "serial0:115200n8";
> > >       };
> > > @@ -91,6 +101,15 @@
> > >               };
> > >       };
> > >
> > > +     reg_vdd_backlight: vdd-backlight {
> > > +             compatible = "regulator-fixed";
> > > +             regulator-name = "vdd-backlight";
> > > +             regulator-min-microvolt = <3300000>;
> > > +             regulator-max-microvolt = <3300000>;
> > > +             gpio = <&pio 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> > > PD7 */
> > > +             enable-active-high;
> > > +     };
> > > +
> > >       wifi_pwrseq: wifi_pwrseq {
> > >               compatible = "mmc-pwrseq-simple";
> > >               reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > > @@ -101,6 +120,23 @@
> > >       status = "okay";
> > >  };
> > >
> > > +&dphy {
> > > +     status = "okay";
> > > +};
> > > +
> > > +&dsi {
> > > +     status = "okay";
> > > +
> > > +     panel@0 {
> > > +             compatible = "bananapi,s070wv20-ct16-icn6211";
> > > +             reg = <0>;
> > > +             avdd-supply = <&reg_dc1sw>;
> >
> > As mentioned above, I don't see this on the DSI connector.
> >
> > > +             dvdd-supply = <&reg_dldo1>;
> >
> > Mmh, this line is connected to the *SoC*, to drive the DSI data lines
> > or the DPHY, presumably. So I wouldn't expect it in the panel node, but
> > rather in the DPHY or DSI node. Although I can't find a power-supply
> > property in those bindings.
>
> Got it, this has to attach via vcc-dsi-supply.
>
> [1] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/bootloader/blobs/bpi-m64-lcd7.dts#L2266

Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Chen-Yu Tsai]

On Wed, Nov 14, 2018 at 2:58 PM Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>
> On Wed, Nov 14, 2018 at 2:31 PM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >
> > On Tue, Nov 13, 2018 at 5:52 PM Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> > >
> > > On Tue, 13 Nov 2018 16:46:32 +0530
> > > Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> > >
> > > Hi,
> > >
> > > > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > > > BPI-M64 board.
> > > >
> > > > DSI panel connected via board DSI port with,
> > > > - DC1SW as AVDD supply
> > >
> > > Are you sure of that? I don't see anything in the schematic to support
> > > this. The only power lines that go to the DSI connector are DCDC1 and
> > > PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
> > > Is there anything I miss?
> >
> > Thanks for the comment, yes dc1sw is connected in ephy. I have reused
> > dc1, BSP is attached lcd_power1 to axp81x_dc1sw [1]. I just looking
> > for someone to comment, may be we can skip this regulator attachment.
>
> That seems sketchy. The schematics show the connector has feeds from both
> the unregulated output IPSOUT (PS) and DCDC1. For designs with RGB LCD
> panels, we only see the PS feed. Since the LCD panel can be used in either
> RGB or MIPI DSI mode, I highly suspect the DCDC1 supply feeds the bridge
> IC.
>
> As for DC1SW, this is likely referenced because it provides power to the
> GPIO lines that are used to control the LCD panel. If you don't provide
> power, you can't pull them up.
>
> While many of us dislike FEX and the new FEX-derived device tree, they
> do provide some information, such as regulator usage. Note that each
> regulator output has multiple names, which likely denote specific
> usages.
>
> I've asked BPI for schematics on the bridge board. Hopefully we'll
> have something in more detail. In the meantime, I suggest leaving
> this panel out of your next submission, and focus on getting the bulk
> of the dsi driver and dts changes in first.

I got the schematics, but unfortunately I can't share them publicly.

It looks like VCC-MIPI on the connector is not connected to anything.
All power is provided from IPSOUT, first through a current limiter IC
turned on and off by LCD_PWR_EN, and then through some voltage regulators
to provide the voltages for various parts of the panel, including LCD,
capacitive touch, and the MIPI-DSI bridge. There's even an onboard EEPROM,
though I'm not sure what that's for.

> >
> > >
> > > > - DCDC1 as DVDD supply
> > >
> > > That seems right, but doesn't match with what you write below.
> >
> > Commit need to fix s/DCDC1/DLDO1
> >
> > >
> > > > - PD6 gpio for reset pin

This toggles reset for both the panel itself and for the MIPI-DSI bridge.

> > > > - PD5 gpio for backlight enable pin

This enables the backlight's regulator.

> > > > - PD7 gpio for backlight vdd supply

This enables power to the whole panel module.

Then you also have the two GPIOs for the capacitive touch controller.
And also the I2C bus for the controller, and the EEPROM.


ChenYu

> > > >
> > > > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > > > ---
> > > >  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42
> > > > +++++++++++++++++++ 1 file changed, 42 insertions(+)
> > > >
> > > > diff --git
> > > > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> > > > ef1c90401bb2..6cb010e3bbd9 100644 ---
> > > > a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts +++
> > > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts @@ -45,6
> > > > +45,7 @@ #include "sun50i-a64.dtsi"
> > > >  #include <dt-bindings/gpio/gpio.h>
> > > > +#include <dt-bindings/pwm/pwm.h>
> > > >
> > > >  / {
> > > >       model = "BananaPi-M64";
> > > > @@ -56,6 +57,15 @@
> > > >               serial1 = &uart1;
> > > >       };
> > > >
> > > > +     backlight: backlight {
> > > > +             compatible = "pwm-backlight";
> > > > +             pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
> > > > +             brightness-levels = <1 2 4 8 16 32 64 128 512>;
> > > > +             default-brightness-level = <2>;
> > > > +             enable-gpios = <&pio 3 5 GPIO_ACTIVE_HIGH>; /*
> > > > LCD-BL-EN: PD5 */
> > > > +             power-supply = <&reg_vdd_backlight>;
> > > > +     };
> > > > +
> > > >       chosen {
> > > >               stdout-path = "serial0:115200n8";
> > > >       };
> > > > @@ -91,6 +101,15 @@
> > > >               };
> > > >       };
> > > >
> > > > +     reg_vdd_backlight: vdd-backlight {
> > > > +             compatible = "regulator-fixed";
> > > > +             regulator-name = "vdd-backlight";
> > > > +             regulator-min-microvolt = <3300000>;
> > > > +             regulator-max-microvolt = <3300000>;
> > > > +             gpio = <&pio 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> > > > PD7 */
> > > > +             enable-active-high;
> > > > +     };
> > > > +
> > > >       wifi_pwrseq: wifi_pwrseq {
> > > >               compatible = "mmc-pwrseq-simple";
> > > >               reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > > > @@ -101,6 +120,23 @@
> > > >       status = "okay";
> > > >  };
> > > >
> > > > +&dphy {
> > > > +     status = "okay";
> > > > +};
> > > > +
> > > > +&dsi {
> > > > +     status = "okay";
> > > > +
> > > > +     panel@0 {
> > > > +             compatible = "bananapi,s070wv20-ct16-icn6211";
> > > > +             reg = <0>;
> > > > +             avdd-supply = <&reg_dc1sw>;
> > >
> > > As mentioned above, I don't see this on the DSI connector.
> > >
> > > > +             dvdd-supply = <&reg_dldo1>;
> > >
> > > Mmh, this line is connected to the *SoC*, to drive the DSI data lines
> > > or the DPHY, presumably. So I wouldn't expect it in the panel node, but
> > > rather in the DPHY or DSI node. Although I can't find a power-supply
> > > property in those bindings.
> >
> > Got it, this has to attach via vcc-dsi-supply.
> >
> > [1] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/bootloader/blobs/bpi-m64-lcd7.dts#L2266

Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Jagan Teki]

On Wed, Nov 14, 2018 at 2:52 PM Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>
> On Wed, Nov 14, 2018 at 2:58 PM Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> >
> > On Wed, Nov 14, 2018 at 2:31 PM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> > >
> > > On Tue, Nov 13, 2018 at 5:52 PM Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> > > >
> > > > On Tue, 13 Nov 2018 16:46:32 +0530
> > > > Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > > > > BPI-M64 board.
> > > > >
> > > > > DSI panel connected via board DSI port with,
> > > > > - DC1SW as AVDD supply
> > > >
> > > > Are you sure of that? I don't see anything in the schematic to support
> > > > this. The only power lines that go to the DSI connector are DCDC1 and
> > > > PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
> > > > Is there anything I miss?
> > >
> > > Thanks for the comment, yes dc1sw is connected in ephy. I have reused
> > > dc1, BSP is attached lcd_power1 to axp81x_dc1sw [1]. I just looking
> > > for someone to comment, may be we can skip this regulator attachment.
> >
> > That seems sketchy. The schematics show the connector has feeds from both
> > the unregulated output IPSOUT (PS) and DCDC1. For designs with RGB LCD
> > panels, we only see the PS feed. Since the LCD panel can be used in either
> > RGB or MIPI DSI mode, I highly suspect the DCDC1 supply feeds the bridge
> > IC.
> >
> > As for DC1SW, this is likely referenced because it provides power to the
> > GPIO lines that are used to control the LCD panel. If you don't provide
> > power, you can't pull them up.
> >
> > While many of us dislike FEX and the new FEX-derived device tree, they
> > do provide some information, such as regulator usage. Note that each
> > regulator output has multiple names, which likely denote specific
> > usages.
> >
> > I've asked BPI for schematics on the bridge board. Hopefully we'll
> > have something in more detail. In the meantime, I suggest leaving
> > this panel out of your next submission, and focus on getting the bulk
> > of the dsi driver and dts changes in first.
>
> I got the schematics, but unfortunately I can't share them publicly.
>
> It looks like VCC-MIPI on the connector is not connected to anything.
> All power is provided from IPSOUT, first through a current limiter IC
> turned on and off by LCD_PWR_EN, and then through some voltage regulators
> to provide the voltages for various parts of the panel, including LCD,
> capacitive touch, and the MIPI-DSI bridge. There's even an onboard EEPROM,
> though I'm not sure what that's for.

So there is no concern supply regulators on panel side, only VCC-DSI.

>
> > >
> > > >
> > > > > - DCDC1 as DVDD supply
> > > >
> > > > That seems right, but doesn't match with what you write below.
> > >
> > > Commit need to fix s/DCDC1/DLDO1
> > >
> > > >
> > > > > - PD6 gpio for reset pin
>
> This toggles reset for both the panel itself and for the MIPI-DSI bridge.
>
> > > > > - PD5 gpio for backlight enable pin
>
> This enables the backlight's regulator.
>
> > > > > - PD7 gpio for backlight vdd supply
>
> This enables power to the whole panel module.
>
> Then you also have the two GPIOs for the capacitive touch controller.
> And also the I2C bus for the controller, and the EEPROM.

Thanks, for the details. I have verified w/ vcc-dsi-supply attached to
dldo1 and the panel with reset w/o any supply regulators.

[PATCH v4 26/26] arm64: dts: allwinner: a64-amarula-relic: Enable Techstar TS8550B MIPI-DSI panel

[Jagan Teki]

Amarula A64-Relic board by default bound with Techstar TS8550B
MIPI-DSI panel, add support for it.

DSI panel connected via board DSI port with,
- DC1SW as AVDD supply
- DCDC2 as DVDD supply
- DCDC1 as VCC-DSI supply
- PD24 gpio for reset pin
- PD23 gpio for backlight enable pin

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 .../allwinner/sun50i-a64-amarula-relic.dts    | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 6cb2b7f0c817..ecc0d8094815 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -9,6 +9,7 @@
 #include "sun50i-a64.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "Amarula A64-Relic";
@@ -18,6 +19,14 @@
 		serial0 = &uart0;
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+		brightness-levels = <1 2 4 8 16 32 64 128 512>;
+		default-brightness-level = <2>;
+		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD23 */
+	};
+
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
@@ -30,6 +39,28 @@
 	};
 };
 
+&de {
+	status = "okay";
+};
+
+&dphy {
+	status = "okay";
+};
+
+&dsi {
+	vcc-dsi-supply = <&reg_dldo1>;
+	status = "okay";
+
+	panel@0 {
+		compatible = "techstar,ts8550b";
+		reg = <0>;
+		avdd-supply = <&reg_dc1sw>;
+		dvdd-supply = <&reg_dldo2>;
+		reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+		backlight = <&backlight>;
+	};
+};
+
 &ehci0 {
 	status = "okay";
 };
@@ -72,6 +103,12 @@
 	status = "okay";
 };
 
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm_pin>;
+	status = "okay";
+};
+
 &r_rsb {
 	status = "okay";
 
@@ -107,6 +144,15 @@
 	regulator-name = "vcc-pll-avcc";
 };
 
+&reg_dc1sw {
+	/*
+	 * This regulator also indirectly drives the PD pingroup GPIOs,
+	 * which also controls the power LED.
+	 */
+	regulator-always-on;
+	regulator-name = "vcc-phy";
+};
+
 &reg_dcdc1 {
 	regulator-always-on;
 	regulator-min-microvolt = <3300000>;
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 26/26] arm64: dts: allwinner: a64-amarula-relic: Enable Techstar TS8550B MIPI-DSI panel

[Andre Przywara]

On Tue, 13 Nov 2018 16:46:33 +0530
Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

Hi,

I couldn't find a schematic for this board, but some things in here
look inconsistent:

> Amarula A64-Relic board by default bound with Techstar TS8550B
> MIPI-DSI panel, add support for it.
> 
> DSI panel connected via board DSI port with,
> - DC1SW as AVDD supply
> - DCDC2 as DVDD supply

Are you sure of that? That's typically the CPU power supply. Also I
can't find it below. Should that read DLDO2 instead?

> - DCDC1 as VCC-DSI supply

Can't find this below, either. Is it DLDO1?

> - PD24 gpio for reset pin
> - PD23 gpio for backlight enable pin
> 
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
>  .../allwinner/sun50i-a64-amarula-relic.dts    | 46
> +++++++++++++++++++ 1 file changed, 46 insertions(+)
> 
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts index
> 6cb2b7f0c817..ecc0d8094815 100644 ---
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts +++
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts @@ -9,6
> +9,7 @@ #include "sun50i-a64.dtsi" 
>  #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
>  
>  / {
>  	model = "Amarula A64-Relic";
> @@ -18,6 +19,14 @@
>  		serial0 = &uart0;
>  	};
>  
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> +		brightness-levels = <1 2 4 8 16 32 64 128 512>;
> +		default-brightness-level = <2>;
> +		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /*
> LCD-BL-EN: PD23 */
> +	};
> +
>  	chosen {
>  		stdout-path = "serial0:115200n8";
>  	};
> @@ -30,6 +39,28 @@
>  	};
>  };
>  
> +&de {
> +	status = "okay";
> +};
> +
> +&dphy {
> +	status = "okay";
> +};
> +
> +&dsi {
> +	vcc-dsi-supply = <&reg_dldo1>;

Ah, there we have the SoC DSI power supply I was missing for the
BPi-M64 patch.
But is it DLDO1 or DCDC1, like you wrote above?

> +	status = "okay";
> +
> +	panel@0 {
> +		compatible = "techstar,ts8550b";
> +		reg = <0>;
> +		avdd-supply = <&reg_dc1sw>;
> +		dvdd-supply = <&reg_dldo2>;
> +		reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /*
> LCD-RST: PD24 */
> +		backlight = <&backlight>;
> +	};
> +};
> +
>  &ehci0 {
>  	status = "okay";
>  };
> @@ -72,6 +103,12 @@
>  	status = "okay";
>  };
>  
> +&pwm {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pwm_pin>;
> +	status = "okay";
> +};
> +
>  &r_rsb {
>  	status = "okay";
>  
> @@ -107,6 +144,15 @@
>  	regulator-name = "vcc-pll-avcc";
>  };
>  
> +&reg_dc1sw {
> +	/*
> +	 * This regulator also indirectly drives the PD pingroup
> GPIOs,
> +	 * which also controls the power LED.
> +	 */

Is that true for this board as well or is this just a copy&paste
leftover from the BananaPi-M64? If not, you should loose the
regulator-always-on property.

> +	regulator-always-on;
> +	regulator-name = "vcc-phy";

Shouldn't this be called "vcc-dsi" or so?

Cheers,
Andre.

> +};
> +
>  &reg_dcdc1 {
>  	regulator-always-on;
>  	regulator-min-microvolt = <3300000>;

[PATCH v4 15/26] drm/sun4i: sun6i_mipi_dsi: Set proper vblk timing calculation

[Jagan Teki]

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 | 32 ++++++++++++++++++++------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 63b924b89bd7..703722f7c81b 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -355,6 +355,30 @@ 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;
+	u16 vblk = 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
+	if (device->lanes == 4) {
+		unsigned int Bpp;
+		int tmp;
+
+		Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
+		tmp = (mode->htotal * Bpp) * mode->vtotal -
+		      (hblk + VBLK_PACKET_OVERHEAD);
+		vblk = (device->lanes - tmp % device->lanes);
+	}
+
+	return vblk;
+}
+
 static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
 					   struct drm_display_mode *mode)
 {
@@ -503,13 +527,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);
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 16/26] drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator

[Jagan Teki]

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 703722f7c81b..2ea33db61ae1 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1026,6 +1026,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)) {
@@ -1107,6 +1113,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)
@@ -1141,6 +1154,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;
 
-- 
2.18.0.321.gffc6fa0e3

[PATCH v4 19/26] drm/panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge

[Jagan Teki]

Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB bridge
panel which can be used to connect via DSI port on BPI-M64 board,
so add a driver for it.

The same panel PCB comes with parallel RBG which is supported via
panel-simple driver with "bananapi,s070wv20-ct16" compatible.

BSP dclock of 30MHz is not working with existing sunxi-ng and sun4i
sun4i_dclk_recalc, so updated to 55MHz can result proper working
nkm dividers.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 MAINTAINERS                                   |   6 +
 drivers/gpu/drm/panel/Kconfig                 |   9 +
 drivers/gpu/drm/panel/Makefile                |   1 +
 .../panel/panel-bananapi-s070wv20-icn6211.c   | 298 ++++++++++++++++++
 4 files changed, 314 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a25549205cc1..f5bb2ffa1089 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4601,6 +4601,12 @@ M:	Dave Airlie <airlied@redhat.com>
 S:	Odd Fixes
 F:	drivers/gpu/drm/ast/
 
+DRM DRIVER FOR BANANAPI S070WV20-CT16 ICN6211 MIPI-DSI TO RGB PANELS
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c
+F:	Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
+
 DRM DRIVER FOR BOCHS VIRTUAL GPU
 M:	Gerd Hoffmann <kraxel@redhat.com>
 L:	virtualization@lists.linux-foundation.org
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30a33b3..20b88c275421 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -17,6 +17,15 @@ config DRM_PANEL_ARM_VERSATILE
 	  reference designs. The panel is detected using special registers
 	  in the Versatile family syscon registers.
 
+config DRM_PANEL_BANANAPI_S070WV20_ICN6211
+	tristate "Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge panel driver"
+	depends on OF
+	depends on DRM_MIPI_DSI
+	depends on BACKLIGHT_CLASS_DEVICE
+	help
+	  Say Y if you want to enable support for panels based on the
+	  Bananapi S070WV20-CT16 MIPI-DSI controller.
+
 config DRM_PANEL_LVDS
 	tristate "Generic LVDS panel driver"
 	depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9d13af..04696bb85218 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BANANAPI_S070WV20_ICN6211) += panel-bananapi-s070wv20-icn6211.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
diff --git a/drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c b/drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c
new file mode 100644
index 000000000000..10174495a6c8
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-bananapi-s070wv20-icn6211.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+
+struct s070wv20 {
+	struct drm_panel	panel;
+	struct mipi_dsi_device	*dsi;
+
+	struct backlight_device	*backlight;
+	struct regulator	*dvdd;
+	struct regulator	*avdd;
+	struct gpio_desc	*reset;
+};
+
+static inline struct s070wv20 *panel_to_s070wv20(struct drm_panel *panel)
+{
+	return container_of(panel, struct s070wv20, panel);
+}
+
+struct s070wv20_init_cmd {
+	size_t len;
+	const char *data;
+};
+
+#define S070WV20_INIT_CMD(...) { \
+	.len = sizeof((char[]){__VA_ARGS__}), \
+	.data = (char[]){__VA_ARGS__} }
+
+static const struct s070wv20_init_cmd s070wv20_init_cmds[] = {
+	S070WV20_INIT_CMD(0x7A, 0xC1),
+	S070WV20_INIT_CMD(0x20, 0x20),
+	S070WV20_INIT_CMD(0x21, 0xE0),
+	S070WV20_INIT_CMD(0x22, 0x13),
+	S070WV20_INIT_CMD(0x23, 0x28),
+	S070WV20_INIT_CMD(0x24, 0x30),
+	S070WV20_INIT_CMD(0x25, 0x28),
+	S070WV20_INIT_CMD(0x26, 0x00),
+	S070WV20_INIT_CMD(0x27, 0x0D),
+	S070WV20_INIT_CMD(0x28, 0x03),
+	S070WV20_INIT_CMD(0x29, 0x1D),
+	S070WV20_INIT_CMD(0x34, 0x80),
+	S070WV20_INIT_CMD(0x36, 0x28),
+	S070WV20_INIT_CMD(0xB5, 0xA0),
+	S070WV20_INIT_CMD(0x5C, 0xFF),
+	S070WV20_INIT_CMD(0x2A, 0x01),
+	S070WV20_INIT_CMD(0x56, 0x92),
+	S070WV20_INIT_CMD(0x6B, 0x71),
+	S070WV20_INIT_CMD(0x69, 0x2B),
+	S070WV20_INIT_CMD(0x10, 0x40),
+	S070WV20_INIT_CMD(0x11, 0x98),
+	S070WV20_INIT_CMD(0xB6, 0x20),
+	S070WV20_INIT_CMD(0x51, 0x20),
+	S070WV20_INIT_CMD(0x09, 0x10),
+};
+
+static int s070wv20_prepare(struct drm_panel *panel)
+{
+	struct s070wv20 *ctx = panel_to_s070wv20(panel);
+	struct mipi_dsi_device *dsi = ctx->dsi;
+	unsigned int i;
+	int ret;
+
+	msleep(50);
+
+	gpiod_set_value(ctx->reset, 1);
+	msleep(50);
+
+	gpiod_set_value(ctx->reset, 0);
+	msleep(50);
+
+	gpiod_set_value(ctx->reset, 1);
+	msleep(20);
+
+	for (i = 0; i < ARRAY_SIZE(s070wv20_init_cmds); i++) {
+		const struct s070wv20_init_cmd *cmd = &s070wv20_init_cmds[i];
+
+		ret = mipi_dsi_generic_write(dsi, cmd->data, cmd->len);
+		if (ret < 0)
+			return ret;
+
+		msleep(10);
+	}
+
+	return 0;
+}
+
+static int s070wv20_enable(struct drm_panel *panel)
+{
+	struct s070wv20 *ctx = panel_to_s070wv20(panel);
+
+	msleep(120);
+
+	mipi_dsi_dcs_set_display_on(ctx->dsi);
+	backlight_enable(ctx->backlight);
+
+	return 0;
+}
+
+static int s070wv20_disable(struct drm_panel *panel)
+{
+	struct s070wv20 *ctx = panel_to_s070wv20(panel);
+
+	backlight_disable(ctx->backlight);
+	return mipi_dsi_dcs_set_display_on(ctx->dsi);
+}
+
+static int s070wv20_unprepare(struct drm_panel *panel)
+{
+	struct s070wv20 *ctx = panel_to_s070wv20(panel);
+	int ret;
+
+	ret = mipi_dsi_dcs_set_display_off(ctx->dsi);
+	if (ret < 0)
+		dev_err(panel->dev, "failed to set display off: %d\n", ret);
+
+	ret = mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+	if (ret < 0)
+		dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+
+	msleep(100);
+
+	regulator_disable(ctx->avdd);
+
+	regulator_disable(ctx->dvdd);
+
+	gpiod_set_value(ctx->reset, 0);
+
+	gpiod_set_value(ctx->reset, 1);
+
+	gpiod_set_value(ctx->reset, 0);
+
+	return 0;
+}
+
+static const struct drm_display_mode s070wv20_default_mode = {
+	.clock = 55000,
+	.vrefresh = 60,
+
+	.hdisplay = 800,
+	.hsync_start = 800 + 40,
+	.hsync_end = 800 + 40 + 48,
+	.htotal = 800 + 40 + 48 + 40,
+
+	.vdisplay = 480,
+	.vsync_start = 480 + 13,
+	.vsync_end = 480 + 13 + 3,
+	.vtotal = 480 + 13 + 3 + 29,
+
+	.width_mm	= 86,
+	.height_mm	= 154,
+};
+
+static int s070wv20_get_modes(struct drm_panel *panel)
+{
+	struct drm_connector *connector = panel->connector;
+	struct s070wv20 *ctx = panel_to_s070wv20(panel);
+	struct drm_display_mode *mode;
+
+	mode = drm_mode_duplicate(panel->drm, &s070wv20_default_mode);
+	if (!mode) {
+		dev_err(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
+			s070wv20_default_mode.hdisplay,
+			s070wv20_default_mode.vdisplay,
+			s070wv20_default_mode.vrefresh);
+		return -ENOMEM;
+	}
+
+	drm_mode_set_name(mode);
+
+	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+	drm_mode_probed_add(connector, mode);
+
+	panel->connector->display_info.width_mm = mode->width_mm;
+	panel->connector->display_info.height_mm = mode->height_mm;
+
+	return 1;
+}
+
+static const struct drm_panel_funcs s070wv20_funcs = {
+	.disable = s070wv20_disable,
+	.unprepare = s070wv20_unprepare,
+	.prepare = s070wv20_prepare,
+	.enable = s070wv20_enable,
+	.get_modes = s070wv20_get_modes,
+};
+
+static int s070wv20_dsi_probe(struct mipi_dsi_device *dsi)
+{
+	struct device_node *np;
+	struct s070wv20 *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+	mipi_dsi_set_drvdata(dsi, ctx);
+	ctx->dsi = dsi;
+
+	drm_panel_init(&ctx->panel);
+	ctx->panel.dev = &dsi->dev;
+	ctx->panel.funcs = &s070wv20_funcs;
+
+	ctx->dvdd = devm_regulator_get(&dsi->dev, "dvdd");
+	if (IS_ERR(ctx->dvdd)) {
+		dev_err(&dsi->dev, "Couldn't get dvdd regulator\n");
+		return PTR_ERR(ctx->dvdd);
+	}
+
+	ctx->avdd = devm_regulator_get(&dsi->dev, "avdd");
+	if (IS_ERR(ctx->avdd)) {
+		dev_err(&dsi->dev, "Couldn't get avdd regulator\n");
+		return PTR_ERR(ctx->avdd);
+	}
+
+	ret = regulator_enable(ctx->dvdd);
+	if (ret)
+		return ret;
+
+	msleep(5);
+
+	ret = regulator_enable(ctx->avdd);
+	if (ret)
+		return ret;
+
+	msleep(5);
+
+	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->reset)) {
+		dev_err(&dsi->dev, "Couldn't get our reset GPIO\n");
+		return PTR_ERR(ctx->reset);
+	}
+
+	np = of_parse_phandle(dsi->dev.of_node, "backlight", 0);
+	if (np) {
+		ctx->backlight = of_find_backlight_by_node(np);
+		of_node_put(np);
+
+		if (!ctx->backlight)
+			return -EPROBE_DEFER;
+	}
+
+	ret = drm_panel_add(&ctx->panel);
+	if (ret < 0)
+		return ret;
+
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+	dsi->lanes = 4;
+
+	return mipi_dsi_attach(dsi);
+}
+
+static int s070wv20_dsi_remove(struct mipi_dsi_device *dsi)
+{
+	struct s070wv20 *ctx = mipi_dsi_get_drvdata(dsi);
+
+	mipi_dsi_detach(dsi);
+	drm_panel_remove(&ctx->panel);
+
+	if (ctx->backlight)
+		put_device(&ctx->backlight->dev);
+
+	return 0;
+}
+
+static const struct of_device_id s070wv20_of_match[] = {
+	{ .compatible = "bananapi,s070wv20-ct16-icn6211", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, s070wv20_of_match);
+
+static struct mipi_dsi_driver s070wv20_driver = {
+	.probe = s070wv20_dsi_probe,
+	.remove = s070wv20_dsi_remove,
+	.driver = {
+		.name = "bananapi-s070wv20-ct16-icn6211",
+		.of_match_table = s070wv20_of_match,
+	},
+};
+module_mipi_dsi_driver(s070wv20_driver);
+
+MODULE_AUTHOR("Jagan Teki <jagan@amarulasolutions.com>");
+MODULE_DESCRIPTION("Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0.321.gffc6fa0e3