Re: [Letux-kernel] Status of patch: drm/omap: work-around for omap3 display enable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tomi,

> Am 13.08.2018 um 08:18 schrieb Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
> 
> On 11/08/18 20:44, Andreas Kemnade wrote:
>> Hi,
>> 
>> I noticed that there is still this patch in the letux gta04 kernel sources but it did
>> not appear in mainline:
> 
> I think fc5cc9678e130196012c17b37e555d53d3d3476b ("drm/omap: work-around
> for omap3 display enable") in the mainline.

Yes, it is but seems to be a completely different solution. Hence the first quick fix
did not compete during a git merge/rebase and is still there:

iMac:master hns$ git log --oneline --grep "drm/omap: work-around for omap3 display enable"
77e8280f57fd drm/omap: work-around for omap3 display enable
72d45a76039b Merge tag 'omapdrm-4.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
fc5cc9678e13 drm/omap: work-around for omap3 display enable
iMac:master hns$ 
iMac:master hns$ 
iMac:master hns$ git show fc5cc9678e13
commit fc5cc9678e130196012c17b37e555d53d3d3476b
Author: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
Date:   Wed Aug 23 12:19:02 2017 +0300

    drm/omap: work-around for omap3 display enable
    
    Seems that on omap3 enabling a crtc without any planes causes a sync
    lost flood. This only happens on the first enable, and after that it
    works. This looks like an HW issue and it's unclear why this is
    happening or how to fix it.
    
    This started happening after 897145d0c7010b4e07fa9bc674b1dfb9a2c6fff9
    ("drm/omapdrm: Move commit_modeset_enables() before commit_planes()")
    which, as a work-around, changed omapdrm first to do the modeset enable,
    and plane set only after that. This WA should be fine on all DSS
    versions, but apparently OMAP3 DSS is an exception.
    
    This patch reverts that work-around for OMAP3 DSS.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx>

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
index 9b3c36b48356..cdf5b0601eba 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -84,23 +84,36 @@ static void omap_atomic_commit_tail(struct drm_atomic_state *old_state)
        /* Apply the atomic update. */
        drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
-       /* With the current dss dispc implementation we have to enable
-        * the new modeset before we can commit planes. The dispc ovl
-        * configuration relies on the video mode configuration been
-        * written into the HW when the ovl configuration is
-        * calculated.
-        *
-        * This approach is not ideal because after a mode change the
-        * plane update is executed only after the first vblank
-        * interrupt. The dispc implementation should be fixed so that
-        * it is able use uncommitted drm state information.
-        */
-       drm_atomic_helper_commit_modeset_enables(dev, old_state);
-       omap_atomic_wait_for_completion(dev, old_state);
-
-       drm_atomic_helper_commit_planes(dev, old_state, 0);
-
-       drm_atomic_helper_commit_hw_done(old_state);
+       if (priv->omaprev != 0x3430) {
+               /* With the current dss dispc implementation we have to enable
+                * the new modeset before we can commit planes. The dispc ovl
+                * configuration relies on the video mode configuration been
+                * written into the HW when the ovl configuration is
+                * calculated.
+                *
+                * This approach is not ideal because after a mode change the
+                * plane update is executed only after the first vblank
+                * interrupt. The dispc implementation should be fixed so that
+                * it is able use uncommitted drm state information.
+                */
+               drm_atomic_helper_commit_modeset_enables(dev, old_state);
+               omap_atomic_wait_for_completion(dev, old_state);
+
+               drm_atomic_helper_commit_planes(dev, old_state, 0);
+
+               drm_atomic_helper_commit_hw_done(old_state);
+       } else {
+               /*
+                * OMAP3 DSS seems to have issues with the work-around above,
+                * resulting in endless sync losts if a crtc is enabled without
+                * a plane. For now, skip the WA for OMAP3.
+                */
+               drm_atomic_helper_commit_planes(dev, old_state, 0);
+
+               drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+               drm_atomic_helper_commit_hw_done(old_state);
+       }
 
        /*
         * Wait for completion of the page flips to ensure that old buffers
iMac:master hns$ git show 77e8280f57fd
commit 77e8280f57fd3bd55c30ec26bcc850a4495e784c
Author: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
Date:   Tue Jun 13 12:02:08 2017 +0300

    drm/omap: work-around for omap3 display enable
    
    Seems that on omap3 enabling a crtc without any planes causes a sync
    lost flood. This only happens on the first enable, and after that it
    works. This looks like an HW issue.
    
    It's unclear why this is happening or how to fix it, but as a quick
    work-around, this patch enables i734 errata work-around for omap2 and
    omap3 too. The errata work-around enables and disables the LCD output
    with a plane once when waking up the DSS IP, and it seems to resolve the
    omap3 problem too. It is unclear if omap2 has the same issue, but it
    probably has and the WA should have no side effects so it should be safe
    to enable on omap2 too.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx>

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 7f3ac6b13b56..e559df28cecc 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4286,6 +4286,11 @@ static const struct dispc_features omap24xx_dispc_feats = {
        .no_framedone_tv        =       true,
        .set_max_preload        =       false,
        .last_pixel_inc_missing =       true,
+       /*
+        * HACK: see comment in omap34xx_rev1_0_dispc_feats. OMAP2 probably
+        * has the same issue.
+        */
+       .has_gamma_i734_bug     =       true,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
@@ -4320,6 +4325,13 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
        .no_framedone_tv        =       true,
        .set_max_preload        =       false,
        .last_pixel_inc_missing =       true,
+       /*
+        * HACK: OMAP3 doesn't have i734, but enabling the lcd output without
+        * planes causes synclost flood. This only happens on initial enable,
+        * not after that.
+        * Piggyback on i734 flag until we understand this better.
+        */
+       .has_gamma_i734_bug     =       true,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats = {
@@ -4422,6 +4434,8 @@ static const struct dispc_features am43xx_dispc_feats = {
        .no_framedone_tv        =       true,
        .set_max_preload        =       false,
        .last_pixel_inc_missing =       true,
+       /* HACK: see comment in omap34xx_rev1_0_dispc_feats */
+       .has_gamma_i734_bug     =       true,
 };
 
 static const struct dispc_features omap44xx_dispc_feats = {
iMac:master hns$ 


So can we safely remove 77e8280f57fd or does it anything which is otherwise
important ?

BR and thanks,
Nikolaus





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux