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