Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Jagan Teki <jagan@amarulasolutions.com>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: bbrezillon@kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>, Sean Paul <seanpaul@chromium.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Jagan Teki <jagan@openedev.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 0/8] drm/sun4i: dsi: Add burst mode support
Date: Tue, 26 Feb 2019 12:18:54 +0530
Message-ID: <CAMty3ZDoQNnLAP9fBfEsdUb2ZPyfrATaw-2-FDUgyUO=Rdt_CA@mail.gmail.com> (raw)
In-Reply-To: <20190220163533.cehatadivjolo7sk@flea>

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

      reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 14:41 Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 1/8] drm/sun4i: dsi: Restrict DSI tcon clock divider Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 2/8] drm/sun4i: dsi: Change the start delay calculation Maxime Ripard
2019-02-12 15:28   ` Paul Kocialkowski
2019-02-12 15:45     ` Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 3/8] drm/sun4i: dsi: Enforce boundaries on the start delay Maxime Ripard
2019-02-12 15:30   ` Paul Kocialkowski
2019-02-14  9:21     ` Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 4/8] drm/sun4i: dsi: Fix front vs back porch calculation Maxime Ripard
2019-02-12 15:41   ` Paul Kocialkowski
2019-02-11 14:41 ` [PATCH v3 5/8] drm/sun4i: dsi: Fix DRQ calculation Maxime Ripard
2019-02-13 14:33   ` Paul Kocialkowski
2019-02-14  9:23     ` Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 6/8] drm/sun4i: dsi: Rework a bit the hblk calculation Maxime Ripard
2019-02-13 14:41   ` Paul Kocialkowski
2019-02-11 14:41 ` [PATCH v3 7/8] drm/sun4i: dsi: Add burst support Maxime Ripard
2019-02-13 14:36   ` Paul Kocialkowski
2019-02-14  9:15     ` Maxime Ripard
2019-02-11 14:41 ` [PATCH v3 8/8] drm/panel: Add Ronbo RB070D30 panel Maxime Ripard
2019-02-11 15:13   ` Sam Ravnborg
2019-02-13 14:26   ` Paul Kocialkowski
2019-02-14 11:07     ` Re[2]: " Konstantin Sudakov
2019-02-12 10:32 ` [PATCH v3 0/8] drm/sun4i: dsi: Add burst mode support Jagan Teki
2019-02-15 14:12 ` Maxime Ripard
     [not found]   ` <CAMty3ZAA90-fHPADJSE3ht9CiYWA3yBoyEy7wVv9=6C5JiaTVw@mail.gmail.com>
2019-02-15 17:07     ` Jagan Teki
2019-02-18  8:26       ` Paul Kocialkowski
2019-02-18 10:31         ` Jagan Teki
2019-02-20 16:35           ` Maxime Ripard
2019-02-26  6:48             ` Jagan Teki [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMty3ZDoQNnLAP9fBfEsdUb2ZPyfrATaw-2-FDUgyUO=Rdt_CA@mail.gmail.com' \
    --to=jagan@amarulasolutions.com \
    --cc=bbrezillon@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jagan@openedev.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=seanpaul@chromium.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org infradead-linux-arm-kernel@archiver.kernel.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox