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

[Jagan Teki <jagan@amarulasolutions.com>]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel