On Wed, Jul 08, 2020 at 06:37:51PM -0500, Adam Ford wrote:

On Mon, Jul 6, 2020 at 6:18 AM Adam Ford [off-list ref] wrote:

quoted

On Mon, Jul 6, 2020 at 1:02 AM Tomi Valkeinen [off-list ref] wrote:

quoted

Hi,

On 03/07/2020 22:36, Sam Ravnborg wrote:

quoted

Hi Tomi.

On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:

quoted

On 30/06/2020 21:26, Adam Ford wrote:

quoted

The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number.  Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.

This patch fixes the divider for fbdev driver instead of the drm.

Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")

Cc: <redacted> #4.9+
Signed-off-by: Adam Ford <redacted>
---
Linux 4.4 will need a similar patch, but it doesn't apply cleanly.

The DRM version of this same fix is:
e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 7252d22dd117..bfc5c4c5a26a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c

@@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
   };
   static const struct dss_features omap3630_dss_feats = {
-   .fck_div_max            =       32,
+   .fck_div_max            =       31,
    .dss_fck_multiplier     =       1,
    .parent_clk_name        =       "dpll4_ck",
    .dpi_select_source      =       &dss_dpi_select_source_omap2_omap3,

Reviewed-by: Tomi Valkeinen <redacted>

Will you apply to drm-misc?

This is for fbdev, so I presume Bartlomiej will pick this one.

quoted

Note  following output from "dim fixes":
$ dim fixes f76ee892a99e
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: Tomi Valkeinen <redacted>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rob Clark <redacted>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Bartlomiej Zolnierkiewicz <redacted>
Cc: Jason Yan <yanaijie@huawei.com>
Cc: "Andrew F. Davis" <redacted>
Cc: YueHaibing <redacted>
Cc: <redacted> # v4.5+

Here it says the fix is valid from v4.5 onwards.

Hmm... Adam, you marked the fix to apply to v4.9+, and then you said
v4.4 needs a new patch (that's before the big copy/rename). Did you
check the versions between 4.4 and 4.9? I would guess this one applies
to v4.5+.

I only tried 4.9 because it's listed as an LTS kernel.  The stuff
between 4.4 and 4.9 were EOL, so I didn't go back further.    The 4.5+
is probably more accurate.  I would like to do the same thing for the
4.4 kernel, but I am not sure the proper way to do that.

What is the correct protocol for patching 4.4?  I'd like to do that,
but the patch would be unique to the 4.4.  Should I just submit the
patch directly to stable and cc Tomi?

Yes, and document the heck out of why this is a 4.4-only patch, and why
we can't take whatever happened in newer kernels instead.

thanks,

greg k-h