On Wed, Feb 20, 2019 at 10:05 PM Maxime Ripard <maxime.rip...@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.kocialkow...@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.rip...@bootlin.com > > > > > <mailto:maxime.rip...@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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
