mbox series

[v3,0/8] drm/sun4i: dsi: Add burst mode support

Message ID cover.f28d9994585553a089a519392616b0d26ed54af1.1549896081.git-series.maxime.ripard@bootlin.com (mailing list archive)
Headers show
Series drm/sun4i: dsi: Add burst mode support | expand

Message

Maxime Ripard Feb. 11, 2019, 2:41 p.m. UTC
Hi,

Here is a series implementing the burst mode support for DSI.

It's been tested on an A33 board with the panel supported on the last
patch, which should remove all quirks due to a different SoC from the
equation.

Let me know what you think,
Maxime

Changes from v3:
  - Fixed error in Ronbo panel error path

Changes from v2:
  - Change the start delay calculation according to the legacy driver in
    Allwinner's BSP
  - Fixed the edge calculation to add the same parentheses around the
    factors
  - Added a bunch of fixes to timings
  - Added a patch to make hblk computation more accurate, and added a
    comment
  - Renamed the panel to Ronbo and fixed a bunch of things
  - Added the Reviewed-By

Konstantin Sudakov (2):
  drm/sun4i: dsi: Add burst support
  drm/panel: Add Ronbo RB070D30 panel

Maxime Ripard (6):
  drm/sun4i: dsi: Restrict DSI tcon clock divider
  drm/sun4i: dsi: Change the start delay calculation
  drm/sun4i: dsi: Enforce boundaries on the start delay
  drm/sun4i: dsi: Fix front vs back porch calculation
  drm/sun4i: dsi: Fix DRQ calculation
  drm/sun4i: dsi: Rework a bit the hblk calculation

 drivers/gpu/drm/panel/Kconfig                |   9 +-
 drivers/gpu/drm/panel/Makefile               |   1 +-
 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 262 ++++++++++++++++++++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c           |   4 +-
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c       | 183 ++++++++++----
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h       |   2 +-
 6 files changed, 419 insertions(+), 42 deletions(-)
 create mode 100644 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c

base-commit: 7e571a7f2fc622f81f8be4a4d8725551490378b2

Comments

Jagan Teki Feb. 12, 2019, 10:32 a.m. UTC | #1
Hi Maxime,

On Mon, Feb 11, 2019 at 8:12 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> Here is a series implementing the burst mode support for DSI.
>
> It's been tested on an A33 board with the panel supported on the last
> patch, which should remove all quirks due to a different SoC from the
> equation.
>
> Let me know what you think,

I have similar burst changes[1] (from 01/23 to 09/23) which are now
v7, since these were generic changes and been in ML since from last 6
months. request you to pick or work on top.

> Maxime
>
> Changes from v3:
>   - Fixed error in Ronbo panel error path
>
> Changes from v2:
>   - Change the start delay calculation according to the legacy driver in
>     Allwinner's BSP
>   - Fixed the edge calculation to add the same parentheses around the
>     factors
>   - Added a bunch of fixes to timings
>   - Added a patch to make hblk computation more accurate, and added a
>     comment
>   - Renamed the panel to Ronbo and fixed a bunch of things
>   - Added the Reviewed-By
>
> Konstantin Sudakov (2):
>   drm/sun4i: dsi: Add burst support
>   drm/panel: Add Ronbo RB070D30 panel
>
> Maxime Ripard (6):
>   drm/sun4i: dsi: Restrict DSI tcon clock divider
>   drm/sun4i: dsi: Change the start delay calculation
>   drm/sun4i: dsi: Enforce boundaries on the start delay
>   drm/sun4i: dsi: Fix front vs back porch calculation

Same patches are been for a while in ML[2], hope you can consider to pick.

>   drm/sun4i: dsi: Fix DRQ calculation
>   drm/sun4i: dsi: Rework a bit the hblk calculation
>
>  drivers/gpu/drm/panel/Kconfig                |   9 +-
>  drivers/gpu/drm/panel/Makefile               |   1 +-
>  drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 262 ++++++++++++++++++++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c           |   4 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c       | 183 ++++++++++----
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h       |   2 +-
>  6 files changed, 419 insertions(+), 42 deletions(-)
>  create mode 100644 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c

[2] https://patchwork.kernel.org/patch/10793123/
     https://patchwork.kernel.org/patch/10793125/
     https://patchwork.kernel.org/patch/10680309/
[1] https://patchwork.kernel.org/cover/10792981/

Jagan.
Maxime Ripard Feb. 15, 2019, 2:12 p.m. UTC | #2
On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here is a series implementing the burst mode support for DSI.
> 
> It's been tested on an A33 board with the panel supported on the last
> patch, which should remove all quirks due to a different SoC from the
> equation.

I should have sent that mail yesterday, but patches 1-4 and 6-7 were
merged. Patch 5 was discarded since it was not consistent with the
rest of the driver, and 8 had some comments.

Maxime
Jagan Teki Feb. 15, 2019, 2:40 p.m. UTC | #3
On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com>
wrote:

> On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > Here is a series implementing the burst mode support for DSI.
> >
> > It's been tested on an A33 board with the panel supported on the last
> > patch, which should remove all quirks due to a different SoC from the
> > equation.
>
> I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> merged. Patch 5 was discarded since it was not consistent with the
> rest of the driver, and 8 had some comments.
>

Are the applied patches from this series or from my v7 series?

 Would you please point me the branch.



>
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, &lt;<a href="mailto:maxime.ripard@bootlin.com">maxime.ripard@bootlin.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:<br>
&gt; Hi,<br>
&gt; <br>
&gt; Here is a series implementing the burst mode support for DSI.<br>
&gt; <br>
&gt; It&#39;s been tested on an A33 board with the panel supported on the last<br>
&gt; patch, which should remove all quirks due to a different SoC from the<br>
&gt; equation.<br>
<br>
I should have sent that mail yesterday, but patches 1-4 and 6-7 were<br>
merged. Patch 5 was discarded since it was not consistent with the<br>
rest of the driver, and 8 had some comments.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Are the applied patches from this series or from my v7 series?</div><div dir="auto"><br></div><div dir="auto"> Would you please point me the branch.</div><div dir="auto"><br></div><div dir="auto"> </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
Jagan Teki Feb. 15, 2019, 5:07 p.m. UTC | #4
Hi Maxime,

On 15/02/19 8:10 PM, Jagan Teki wrote:
> 
> 
> On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com 
> <mailto:maxime.ripard@bootlin.com>> wrote:
> 
>     On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
>      > Hi,
>      >
>      > Here is a series implementing the burst mode support for DSI.
>      >
>      > It's been tested on an A33 board with the panel supported on the last
>      > patch, which should remove all quirks due to a different SoC from the
>      > equation.
> 
>     I should have sent that mail yesterday, but patches 1-4 and 6-7 were
>     merged. Patch 5 was discarded since it was not consistent with the
>     rest of the driver, and 8 had some comments.
> 
> 
> Are the applied patches from this series or from my v7 series?
> 
>   Would you please point me the branch.
> 

Unfortunately my last mail didn't reach arm mailing list.

Just wanted to know are the applied patches from this series or from my 
v7 series? Would you please point me the repo, I couldn't find it on
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git

Jagan.
Paul Kocialkowski Feb. 18, 2019, 8:26 a.m. UTC | #5
Hi Jagan,

On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> Hi Maxime,
> 
> On 15/02/19 8:10 PM, Jagan Teki wrote:
> > 
> > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com 
> > <mailto:maxime.ripard@bootlin.com>> wrote:
> > 
> >     On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> >      > Hi,
> >      >
> >      > Here is a series implementing the burst mode support for DSI.
> >      >
> >      > It's been tested on an A33 board with the panel supported on the last
> >      > patch, which should remove all quirks due to a different SoC from the
> >      > equation.
> > 
> >     I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> >     merged. Patch 5 was discarded since it was not consistent with the
> >     rest of the driver, and 8 had some comments.
> > 
> > 
> > Are the applied patches from this series or from my v7 series?
> > 
> >   Would you please point me the branch.
> > 
> 
> Unfortunately my last mail didn't reach arm mailing list.
> 
> Just wanted to know are the applied patches from this series or from my 
> v7 series? Would you please point me the repo, I couldn't find it on
> git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git

This series is the one that was applied upstream. You can find the
commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/

The sunxi tree is not used for changes taking place in specific
subsystems that have their own maintainer trees. In this case, changes
to the DRM driver are going through the DRM misc tree (of which Maxime
is also a maintainer).

With this basis merged, you should be able to respin your series in a
lighter form. Hopefully, that'll help get your changes in shape faster!

Cheers,

Paul
Jagan Teki Feb. 18, 2019, 10:31 a.m. UTC | #6
Hi Paul and Maxime,

On Mon, Feb 18, 2019 at 1:56 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi Jagan,
>
> On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On 15/02/19 8:10 PM, Jagan Teki wrote:
> > >
> > > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com
> > > <mailto:maxime.ripard@bootlin.com>> wrote:
> > >
> > >     On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > >      > Hi,
> > >      >
> > >      > Here is a series implementing the burst mode support for DSI.
> > >      >
> > >      > It's been tested on an A33 board with the panel supported on the last
> > >      > patch, which should remove all quirks due to a different SoC from the
> > >      > equation.
> > >
> > >     I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > >     merged. Patch 5 was discarded since it was not consistent with the
> > >     rest of the driver, and 8 had some comments.
> > >
> > >
> > > Are the applied patches from this series or from my v7 series?
> > >
> > >   Would you please point me the branch.
> > >
> >
> > Unfortunately my last mail didn't reach arm mailing list.
> >
> > Just wanted to know are the applied patches from this series or from my
> > v7 series? Would you please point me the repo, I couldn't find it on
> > git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
>
> This series is the one that was applied upstream. You can find the
> commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/

Thanks for sharing the link Paul.

This is really really discouraging.

Don't know whom to ask directly about this, but I am really upset
about this move.

Most of the changes from applied series have similar patches that are
been part of my series of patches. I've been sending this since last
September (which was sent way prior than this series).

How come the same series is recreated and applied with minor changes
while the original series was still in discussion. At least Maxime
should have informed me or he should have rejected my work from
patchwork or atleast NAK in ML?

All these burst changes and random fixes are reviewed in couple of
versions, now the versioning moved to v8[1] [2]. For each and every
versioning I'm trying to fix the previous version comments, code
improvements, commit messages. In fact for each rotation I'm trying to
validate 4 different panels which eventually consume all my 16 hours
in day.

Please let me know to how could we better collaborate?

[2] https://patchwork.kernel.org/cover/10813573/
[1] https://patchwork.kernel.org/cover/10813623/
Maxime Ripard Feb. 20, 2019, 4:35 p.m. UTC | #7
Hi,

On Mon, Feb 18, 2019 at 04:01:09PM +0530, Jagan Teki wrote:
> On Mon, Feb 18, 2019 at 1:56 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> > > On 15/02/19 8:10 PM, Jagan Teki wrote:
> > > >
> > > > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com
> > > > <mailto:maxime.ripard@bootlin.com>> wrote:
> > > >
> > > >     On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > > >      > Hi,
> > > >      >
> > > >      > Here is a series implementing the burst mode support for DSI.
> > > >      >
> > > >      > It's been tested on an A33 board with the panel supported on the last
> > > >      > patch, which should remove all quirks due to a different SoC from the
> > > >      > equation.
> > > >
> > > >     I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > > >     merged. Patch 5 was discarded since it was not consistent with the
> > > >     rest of the driver, and 8 had some comments.
> > > >
> > > >
> > > > Are the applied patches from this series or from my v7 series?
> > > >
> > > >   Would you please point me the branch.
> > > >
> > >
> > > Unfortunately my last mail didn't reach arm mailing list.
> > >
> > > Just wanted to know are the applied patches from this series or from my
> > > v7 series? Would you please point me the repo, I couldn't find it on
> > > git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
> >
> > This series is the one that was applied upstream. You can find the
> > commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/
> 
> Thanks for sharing the link Paul.
> 
> This is really really discouraging.
> 
> Don't know whom to ask directly about this, but I am really upset
> about this move.

I appreciate and understand that, and I feel sorry it ended up like
this.

> Most of the changes from applied series have similar patches that are
> been part of my series of patches. I've been sending this since last
> September (which was sent way prior than this series).

Note that only the burst part has been merged, and the first time you
sent it was in November.

> How come the same series is recreated and applied with minor changes
> while the original series was still in discussion. At least Maxime
> should have informed me or he should have rejected my work from
> patchwork or atleast NAK in ML?

I did, both in private and public. And I've told you on numerous
occasions what was wrong with your series and the way you were pushing
things. But let's break it down:

v8:
  - Chen-Yu and I spent a lot of time (almost two full work days in my
    case, Chen-Yu at least a full evening from what I know) trying to
    make sense of the Allwinner BSP code, and report what was being
    done. This was made public on the mailing lists, and you were in
    cc [1][2]. It happened the week before your submission, yet you
    ignored most of those changes, and I told you so [3], mentionning
    a bunch of other recurring comments I had that were not really
    addressed.
  - This series and the other also had some obvious flaw that had 0
    chance to work properly (which you eventually noticed[4])

v7:
  - Chen-Yu and I were already discussing and pointing out some
    issues, that were not addressed[5]

v6:
  - Reviewing a PLL issue, already mentionned in the v5 and v2 [6]

v5:
  - I mention that the display I have is broken, just like in your v4 [6].
    Just like in the v4, I'm asking for a panel datasheet so
    that I can help you debug this further. This is ignored.
  - I asked for clarifications on that PLL min_rate, just like in the
    previous versions [7]

v4 
 - I mention that the only other DSI display there is is broken
   [8]. I'm again asking for datasheet and better commit logs.

v3
  - Some more ignored comments [9]

A64 DSI v2
  - Asking details on the PLL min_rate, comments ignored [10]
  - Untested code [11]

Burst v2
  - More details asked, obvious flaws [12]

v1
  - Me asking for better commit logs and some justifications [13][14][15]


TL; DR: there's not been any single iteration of those patches where
you wouldn't have ignored some comments made on a previous iteration,
despite for some patches numerous questions around the same points,
and with very significant time invested in this by numerous people
(Chen-Yu, myself and Paul to a lesser extent).

This is what was completely stalling your series, and I'm sure
frustrating both sides. You even acknowledged that in that mail:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/632060.html

Yet, you submitted your v8 versions without taking our comments into
account.

> All these burst changes and random fixes are reviewed in couple of
> versions, now the versioning moved to v8[1] [2]. For each and every
> versioning I'm trying to fix the previous version comments, code
> improvements, commit messages. In fact for each rotation I'm trying to
> validate 4 different panels which eventually consume all my 16 hours
> in day.
> 
> Please let me know to how could we better collaborate?

By listening and addressing the reviews we are making. If you feel
like you're missing something and / or not understanding everything in
a review (which honestly would be pretty understandable with that
sub-par DSI block documentation), then please ask, but ignoring those
comments will just be a waste of time for everyone involved, and will
frustrate everybody (especially when the time spent is this important).

Like I was saying before, I haven't merged any A64 or panel patches,
so this will be a pretty good occasion to test this.

Maxime

1: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/630522.html
2: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/630772.html
3: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/632076.html
4: https://patchwork.freedesktop.org/patch/286191/
5: https://patchwork.freedesktop.org/patch/280045/
6: https://patchwork.freedesktop.org/patch/253495/
7: https://patchwork.freedesktop.org/patch/267373/
8: https://patchwork.freedesktop.org/patch/267362/
9: https://patchwork.freedesktop.org/patch/261779/
10: https://patchwork.freedesktop.org/patch/258921/
11: https://patchwork.kernel.org/patch/10653309/
12: https://patchwork.kernel.org/patch/10653355/
13: https://patchwork.freedesktop.org/patch/262554/
14: https://patchwork.freedesktop.org/patch/253495/
15: https://patchwork.freedesktop.org/patch/253503/
16: https://patchwork.freedesktop.org/patch/253491/
Jagan Teki Feb. 26, 2019, 6:48 a.m. UTC | #8
On Wed, Feb 20, 2019 at 10:05 PM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Mon, Feb 18, 2019 at 04:01:09PM +0530, Jagan Teki wrote:
> > On Mon, Feb 18, 2019 at 1:56 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> > > > On 15/02/19 8:10 PM, Jagan Teki wrote:
> > > > >
> > > > > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, <maxime.ripard@bootlin.com
> > > > > <mailto:maxime.ripard@bootlin.com>> wrote:
> > > > >
> > > > >     On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > > > >      > Hi,
> > > > >      >
> > > > >      > Here is a series implementing the burst mode support for DSI.
> > > > >      >
> > > > >      > It's been tested on an A33 board with the panel supported on the last
> > > > >      > patch, which should remove all quirks due to a different SoC from the
> > > > >      > equation.
> > > > >
> > > > >     I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > > > >     merged. Patch 5 was discarded since it was not consistent with the
> > > > >     rest of the driver, and 8 had some comments.
> > > > >
> > > > >
> > > > > Are the applied patches from this series or from my v7 series?
> > > > >
> > > > >   Would you please point me the branch.
> > > > >
> > > >
> > > > Unfortunately my last mail didn't reach arm mailing list.
> > > >
> > > > Just wanted to know are the applied patches from this series or from my
> > > > v7 series? Would you please point me the repo, I couldn't find it on
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
> > >
> > > This series is the one that was applied upstream. You can find the
> > > commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/
> >
> > Thanks for sharing the link Paul.
> >
> > This is really really discouraging.
> >
> > Don't know whom to ask directly about this, but I am really upset
> > about this move.
>
> I appreciate and understand that, and I feel sorry it ended up like
> this.
>
> > Most of the changes from applied series have similar patches that are
> > been part of my series of patches. I've been sending this since last
> > September (which was sent way prior than this series).
>
> Note that only the burst part has been merged, and the first time you
> sent it was in November.

at least those were prior to the applied series.

>
> > How come the same series is recreated and applied with minor changes
> > while the original series was still in discussion. At least Maxime
> > should have informed me or he should have rejected my work from
> > patchwork or atleast NAK in ML?
>
> I did, both in private and public. And I've told you on numerous
> occasions what was wrong with your series and the way you were pushing
> things. But let's break it down:
>
> v8:
>   - Chen-Yu and I spent a lot of time (almost two full work days in my
>     case, Chen-Yu at least a full evening from what I know) trying to
>     make sense of the Allwinner BSP code, and report what was being
>     done. This was made public on the mailing lists, and you were in
>     cc [1][2]. It happened the week before your submission, yet you

I really missed this, since I don't have any information from you
about sending my burst changes on behalf of other series. This is
something that I couldn't aware in community project where someone
sent the existing changes w/o informing the real author.

>     ignored most of those changes, and I told you so [3], mentionning
>     a bunch of other recurring comments I had that were not really
>     addressed.

On the other hand, I replied about the real reason why I sent this on
[3.1], these changes were generic and doesn't related to clock. You
have been mentioned about the clock but ie not the reason for holding
the generic changes I suppose.

At one point, I felt myself I'm making confusion with big changes, so
I realized and sent the v7 [1] [2] which would eventually break the
changes into sets those are placed generic burst and A64 support. I
don't know I couldn't see any comments.

>   - This series and the other also had some obvious flaw that had 0
>     chance to work properly (which you eventually noticed[4])
>
> v7:
>   - Chen-Yu and I were already discussing and pointing out some
>     issues, that were not addressed[5]
>
> v6:
>   - Reviewing a PLL issue, already mentionned in the v5 and v2 [6]
>
> v5:
>   - I mention that the display I have is broken, just like in your v4 [6].
>     Just like in the v4, I'm asking for a panel datasheet so
>     that I can help you debug this further. This is ignored.
>   - I asked for clarifications on that PLL min_rate, just like in the
>     previous versions [7]
>
> v4
>  - I mention that the only other DSI display there is is broken
>    [8]. I'm again asking for datasheet and better commit logs.
>
> v3
>   - Some more ignored comments [9]
>
> A64 DSI v2
>   - Asking details on the PLL min_rate, comments ignored [10]
>   - Untested code [11]
>
> Burst v2
>   - More details asked, obvious flaws [12]
>
> v1
>   - Me asking for better commit logs and some justifications [13][14][15]
>
>
> TL; DR: there's not been any single iteration of those patches where
> you wouldn't have ignored some comments made on a previous iteration,
> despite for some patches numerous questions around the same points,
> and with very significant time invested in this by numerous people
> (Chen-Yu, myself and Paul to a lesser extent).
>
> This is what was completely stalling your series, and I'm sure
> frustrating both sides. You even acknowledged that in that mail:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/632060.html
>
> Yet, you submitted your v8 versions without taking our comments into
> account.
>
> > All these burst changes and random fixes are reviewed in couple of
> > versions, now the versioning moved to v8[1] [2]. For each and every
> > versioning I'm trying to fix the previous version comments, code
> > improvements, commit messages. In fact for each rotation I'm trying to
> > validate 4 different panels which eventually consume all my 16 hours
> > in day.
> >
> > Please let me know to how could we better collaborate?
>
> By listening and addressing the reviews we are making. If you feel
> like you're missing something and / or not understanding everything in
> a review (which honestly would be pretty understandable with that
> sub-par DSI block documentation), then please ask, but ignoring those
> comments will just be a waste of time for everyone involved, and will
> frustrate everybody (especially when the time spent is this important).

I did address all your comments as per as generic burst changes, which
were supposed to fixed in initial versions. here are the changelog for
your information.

Changes for v8:
- rebase on master
- rework on commit messages
- include drq changes from previous version
Changes for v7:
- rebase on master
- collect Merlijn Wajer Tested-by credits.
Changes for v6:
- fixed all burst mode patches as per previous version comments
- rebase on master
- update proper commit message
- dropped unneeded comments
- order the patches that make review easy
Changes for v5, v4, v3, v2:
- use proper return value for tcon0 probe
- add logic to get tcon0 divider values
- simplify timings code to support burst mode
- fix drq computation return values
- update proper commit messages
- rebase on master

>
> Like I was saying before, I haven't merged any A64 or panel patches,
> so this will be a pretty good occasion to test this.

Honestly I didn't frustrate about this work, and  I couldn't see any
proper reason for your response on why you send similar burst changes
w/o informing or NAK my changes. I assume you may feel confused or
frustrated about my series (which I didn't intentionally do that
sorry), so you mark the changes from your side and applied.

Anyway, thanks for your support, I will re-spin my changes on top
these applied changes.

[3.1] http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/632060.html
[2] https://patchwork.kernel.org/cover/10813623//
[1] https://patchwork.kernel.org/cover/10792981/

Jagan.