| Message ID | 20181121160916.22017-1-sebastian.reichel@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | omapdrm: DSI command mode panel support | expand |
Hi Sebastian, On 21/11/18 18:09, Sebastian Reichel wrote: > Hi, > > Here is another round of the DSI command mode panel patchset > integrating the feedback from PATCHv4. The patches are based > on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches > for OMAP3 support (it needs a workaround for a hardware bug) and > for automatic display rotation. They should get their own series, > once this patchset has landed. Thanks. I can pick 1, 2 and 4 as fixes. I need to look at 3 a bit more, but it might also be a valid fix for the rcs. Although I believe the correct fix would be to implement check_timings for dsi.c, which would return the adjusted timings. Tomi
Hi, On Mon, Nov 26, 2018 at 11:34:30AM +0200, Tomi Valkeinen wrote: > On 21/11/18 18:09, Sebastian Reichel wrote: > > Here is another round of the DSI command mode panel patchset > > integrating the feedback from PATCHv4. The patches are based > > on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches > > for OMAP3 support (it needs a workaround for a hardware bug) and > > for automatic display rotation. They should get their own series, > > once this patchset has landed. > > Thanks. I can pick 1, 2 and 4 as fixes. Feel free to pick up any patches in any order. I can rebase the remaining ones. > I need to look at 3 a bit more, but it might also be a valid fix > for the rcs. Although I believe the correct fix would be to > implement check_timings for dsi.c, which would return the adjusted > timings. I wondered how a proper fix should look like. In the end I just restored the old behaviour of not checking dispc to fix the regression. -- Sebastian
Hi Sebastian, On 21/11/2018 18:09, Sebastian Reichel wrote: > Hi, > > Here is another round of the DSI command mode panel patchset > integrating the feedback from PATCHv4. The patches are based > on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches > for OMAP3 support (it needs a workaround for a hardware bug) and > for automatic display rotation. They should get their own series, > once this patchset has landed. The big omapdrm bridge/panel series from Laurent has been merged to drm-next. I think this series can now be rebased and merged. However, all this needs to be changed to DRM bridge/panel model sooner or later (sooner, please!), but perhaps it's best to first go with the legacy way. Tomi
On Tue, Apr 02, 2019 at 06:36:21PM +0300, Tomi Valkeinen wrote: > On 21/11/2018 18:09, Sebastian Reichel wrote: > > Hi, > > > > Here is another round of the DSI command mode panel patchset > > integrating the feedback from PATCHv4. The patches are based > > on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches > > for OMAP3 support (it needs a workaround for a hardware bug) and > > for automatic display rotation. They should get their own series, > > once this patchset has landed. > > The big omapdrm bridge/panel series from Laurent has been merged to > drm-next. I think this series can now be rebased and merged. > > However, all this needs to be changed to DRM bridge/panel model sooner > or later (sooner, please!), but perhaps it's best to first go with the > legacy way. I would be OK with that, but I'd like to understand what we still need to do to convert DSI support to DRM bridge and panel. Sebastian, if you've looked into it, could you provide some insight ?
Hi Tomi & Laurent, On Tue, Apr 02, 2019 at 06:55:08PM +0300, Laurent Pinchart wrote: > On Tue, Apr 02, 2019 at 06:36:21PM +0300, Tomi Valkeinen wrote: > > On 21/11/2018 18:09, Sebastian Reichel wrote: > > > Hi, > > > > > > Here is another round of the DSI command mode panel patchset > > > integrating the feedback from PATCHv4. The patches are based > > > on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches > > > for OMAP3 support (it needs a workaround for a hardware bug) and > > > for automatic display rotation. They should get their own series, > > > once this patchset has landed. > > > > The big omapdrm bridge/panel series from Laurent has been merged to > > drm-next. I think this series can now be rebased and merged. > > > > However, all this needs to be changed to DRM bridge/panel model sooner > > or later (sooner, please!), but perhaps it's best to first go with the > > legacy way. > > I would be OK with that, but I'd like to understand what we still need > to do to convert DSI support to DRM bridge and panel. Sebastian, if > you've looked into it, could you provide some insight ? I have a rebased & tested version of the patches getting the Droid 4 panel working in this branch (together with 2 patches adding backlight support for testing purposes). I will send it as a patch series in a few minutes. https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/log/?h=omapdrm-5.2-with-dsi I also had a look at converting to DRM bridge/panel model and started working on it in the following branch. It's completley untested and probably not working at all. Also the most recent patches are not yet properly splitted / formated. But they show my idea of how this can be achieved: 1. Add DSI transfer() function 2. Convert custom functions to use transfer() instead 3. Convert to use mipi_dsi_host 4. Get rid of custom DSI related omapdss functions 5. at this point panel conversion can hopefully happen the same way as for the other modules https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/log/?h=omapdrm-5.2-with-dsi-untested-work-branch P.S.: I will continue to work on this, but probably not in the next 4 weeks. I'm currently very busy with non-kernel tasks and still have to review > 200 power-supply patches. -- Sebastian
Hi, Here is another round of the DSI command mode panel patchset integrating the feedback from PATCHv5. The patches are based on Tomi's omapdrm-5.2 tag. It does not contain the patches required for OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once this patchset has landed. Also it does not yet use the DRM panel/bridge things, but IMHO should be merged before. Having this helps means 'git bisect' can be used while converting DSI support to DRM panel/bridge style. Tested on Droid 4: * Framebuffer Console, updated at 1Hz due to blinking cursor * Display blanking * Xorg 1.19 with modesetting driver * Weston 5.0 with DRM backend * kmstest (static image) * No updates send when nothing needs to be sent Known issues: * OMAP3 is untested and most likely broken due to missing workaround(s) for hardware bugs. * Weston 5.0 with fbdev backend does not work, since it uses neither page flip nor dirty ioctl. You need to use the drm backend. Changes since PATCHv5: * Rebased to Tomi's omapdrm-5.2 tag * Simplified omap_framebuffer_dirty() by using drm_for_each_crtc() Changes since PATCHv4: * Apply Acked-/Tested-by received from Tony and Pavel * Fix spelling/optimize commit messages * Use proper multi-line comments * Restructure patch 4: move the whole HDMI block into a static subfunction, that is only called when output type is HDMI. Also drop the incorrect check for DVI. Changes since PATCHv3: * Drop all Tested/Acked-by tags * Drop the rotation patches for now * Rebase to 4.20-rc1 + fixes from Laurent and Tony * Add fixes for DSI regressions introduced in 4.20-rc1 * Store info update manual update mode in omap_crtc_state * Lock modesetting in omap_framebuffer_dirty * Directly loop through CRTCs instead of connectors in dirty function * Properly refresh display during page flips and get Weston working * Add more comments about implementation details Changes since PATCHv2: * Drop omap3 quirk patch (OMAP3 should get its own mini-series) * Rebase to current linux-next * Use existing 'rotation' DT property to set DRM orientation hint * Add Tested-by from Tony Changes since PATCHv1: * Drop patches, that were queued by Tomi * Rebase to current master * Rework the omap3 workaround patch to only affect omap3 * Add orientation DRM property support -- Sebastian Sebastian Reichel (4): drm/omap: use DRM_DEBUG_DRIVER instead of CORE drm/omap: don't check dispc timings for DSI drm/omap: add framedone interrupt support drm/omap: add support for manually updated displays drivers/gpu/drm/omapdrm/omap_crtc.c | 182 ++++++++++++++++++++++++++-- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_fb.c | 19 +++ drivers/gpu/drm/omapdrm/omap_irq.c | 25 ++++ drivers/gpu/drm/omapdrm/omap_irq.h | 1 + 6 files changed, 222 insertions(+), 11 deletions(-)
* Sebastian Reichel <sebastian.reichel@collabora.com> [190403 20:14]: > This adds the required infrastructure for manually updated displays, > such as DSI command mode panels. While those panels often support > partial updates we currently always do a full refresh. > > The display will be refreshed when something calls the dirty callback, > such as libdrm's drmModeDirtyFB(). This is currently being done at least > by the kernel console and Xorg (with modesetting driver) in their > default configuration. Weston does not implement this and the fbdev > backend does not work (display will not update). Weston's DRM backend > uses double buffering and the page flip will also trigger a display > refresh. I've tested this with Linux next and the latest lm3532 patches and it works fine as long as we leave out the backlight = <&lcd_backlight> entry from dts like I replied in the lm3532 tread. So as far as I'm concerned, we're good to go: Tested-by: Tony Lindgren <tony@atomide.com>
On Wed 2019-04-03 17:11:09, Tony Lindgren wrote: > * Sebastian Reichel <sebastian.reichel@collabora.com> [190403 20:14]: > > This adds the required infrastructure for manually updated displays, > > such as DSI command mode panels. While those panels often support > > partial updates we currently always do a full refresh. > > > > The display will be refreshed when something calls the dirty callback, > > such as libdrm's drmModeDirtyFB(). This is currently being done at least > > by the kernel console and Xorg (with modesetting driver) in their > > default configuration. Weston does not implement this and the fbdev > > backend does not work (display will not update). Weston's DRM backend > > uses double buffering and the page flip will also trigger a display > > refresh. > > I've tested this with Linux next and the latest lm3532 > patches and it works fine as long as we leave out the > backlight = <&lcd_backlight> entry from dts like I > replied in the lm3532 tread. So as far as I'm concerned, > we're good to go: > > Tested-by: Tony Lindgren <tony@atomide.com> I've tested this on 5.2-rc1, and it is still neccessary, still needed, and still not merged. How can I help? Can the patches simply be picked up for drm tree? Tested-by: Pavel Machek <pavel@ucw.cz> Pavel