mbox series

[00/33] drm/panel: Fix dotclocks

Message ID 20200302203452.17977-1-ville.syrjala@linux.intel.com (mailing list archive)
Headers show
Series drm/panel: Fix dotclocks | expand

Message

Ville Syrjälä March 2, 2020, 8:34 p.m. UTC
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

A lot of the panel drivers put bogus looking values into
mode.clock. This series replaces the bogus values with
mode.vrefresh*mode.htotal*mode.vtotal.

Now, that may not be the right choice in all cases. There
are quite a few cases where the error looks very minor and
it may be that mode.vrefresh was just miscalculated. But
other cases show huge discepancies. Either way I want to
know which way we should go.

I need to get these sorted one way or the other to
land the drm_display_mode diet patches.

Entire series available here:
git://github.com/vsyrjala/linux.git mode_clock_vs_vrefresh

Ville Syrjälä (33):
  drm/panel-novatek-nt35510: Fix dotclock
  drm/panel-arm-versatile: Fix dotclock
  drm/panel-feixin-k101-im2ba02: Fix dotclock
  drm/panel-ilitek-ili9322: Fix dotclocks
  drm/panel-leadtek-ltk500hd1829: Fix dotclock
  drm/panel-lg-lg4573: Fix dotclock
  drm/panel-sitronix-st7789v: Fix dotclock
  drm/panel-sony-acx424akp: Fix dotclocks
  drm/panel-simple: Fix dotclock for AUO G101EVN010
  drm/panel-simple: Fix dotclock for AUO G104SN02 V2
  drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7
  drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16
  drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG
  drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA
  drm/panel-simple: Fix dotclock for EDT ET035012DM6
  drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP
  drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T
  drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5
  drm/panel-simple: Fix dotclock for Innolux AT070TN92
  drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD
  drm/panel-simple: Fix dotclock for Logic PD Type 28
  drm/panel-simple: Fix dotclock for Netron DY E231732
  drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI
    TFT
  drm/panel-simple: Fix dotclock for Ortustech COM37H3M
  drm/panel-simple: Fix dotclock for PDA 91-00156-A0
  drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40
  drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03
  drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
  drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN
  drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion
  drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01
  drm/panel-simple: Fix dotclock for LG LH500WX1-SD03
  drm/panel-simple: Fix dotclock for LG ACX467AKM-7

 drivers/gpu/drm/panel/panel-arm-versatile.c   |  6 +--
 .../gpu/drm/panel/panel-feixin-k101-im2ba02.c |  2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c  | 14 +++---
 .../drm/panel/panel-leadtek-ltk500hd1829.c    |  2 +-
 drivers/gpu/drm/panel/panel-lg-lg4573.c       |  2 +-
 drivers/gpu/drm/panel/panel-novatek-nt35510.c |  2 +-
 drivers/gpu/drm/panel/panel-simple.c          | 50 +++++++++----------
 .../gpu/drm/panel/panel-sitronix-st7789v.c    |  2 +-
 drivers/gpu/drm/panel/panel-sony-acx424akp.c  |  4 +-
 9 files changed, 42 insertions(+), 42 deletions(-)

Comments

Sam Ravnborg March 2, 2020, 9:47 p.m. UTC | #1
Hi Ville.

On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> A lot of the panel drivers put bogus looking values into
> mode.clock. This series replaces the bogus values with
> mode.vrefresh*mode.htotal*mode.vtotal.

I think you got it wrong....
The few I sampled I would rather say that the clock
specified was the one that was possible with the present
HW and the refresh rate was then set to what was attempted.

Example:
chunghwa_claa101wb01_mode

clock is 69300 - which looks like a value you could configure
in HW. It not not a nive round value.
refresh is 60, which looks like the refresh value that was attempted.

So unless there is a big difference between the
calcualted refresh (based on the specifed clock),
and the specified clock it should be assumed that clock is OK.
And it is OK to drop refresh.

This is my take on it - but you based your patches on refresh.
So maybe you have a better rationale to do so?

Also, let's await feedback from the people cc'ed on the pathces.

	Sam
Ville Syrjälä March 3, 2020, 2:50 p.m. UTC | #2
On Mon, Mar 02, 2020 at 10:47:13PM +0100, Sam Ravnborg wrote:
> Hi Ville.
> 
> On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > A lot of the panel drivers put bogus looking values into
> > mode.clock. This series replaces the bogus values with
> > mode.vrefresh*mode.htotal*mode.vtotal.
> 
> I think you got it wrong....
> The few I sampled I would rather say that the clock
> specified was the one that was possible with the present
> HW and the refresh rate was then set to what was attempted.
> 
> Example:
> chunghwa_claa101wb01_mode
> 
> clock is 69300 - which looks like a value you could configure
> in HW. It not not a nive round value.
> refresh is 60, which looks like the refresh value that was attempted.
> 
> So unless there is a big difference between the
> calcualted refresh (based on the specifed clock),
> and the specified clock it should be assumed that clock is OK.
> And it is OK to drop refresh.
> 
> This is my take on it - but you based your patches on refresh.
> So maybe you have a better rationale to do so?

No. I just blindly converted everything and posted the patches
so people can tell me which way to go.