[PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

Ville Syrjälä ville.syrjala at linux.intel.com
Mon Mar 9 13:00:35 UTC 2020


On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
> 
> > Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> > 
> > Hi,
> > 
> >> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala at linux.intel.com>:
> >> 
> >>> I haven't looked into the driver code, but would it be
> >>> possible to specify .clock = 0 (or leave it out) to
> >>> calculate it bottom up? This would avoid such inconsistencies.
> >> 
> >> I'm going to remove .vrefresh entirely from the struct.
> >> It'll just be calculated from the other timings as needed.
> > 
> > Ok!
> > 
> > Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
> > 
> > I'll give it a try and let you know.
> 
> Ok, here is a new parameter set within data sheet limits for both
> panel variants:
> 
> static const struct drm_display_mode ortustech_com37h3m_mode  = {
> 	.clock = 22153,
> 	.hdisplay = 480,
> 	.hsync_start = 480 + 40,
> 	.hsync_end = 480 + 40 + 10,
> 	.htotal = 480 + 40 + 10 + 40,
> 	.vdisplay = 640,
> 	.vsync_start = 640 + 4,
> 	.vsync_end = 640 + 4 + 2,
> 	.vtotal = 640 + 4 + 2 + 4,
> 	.vrefresh = 60,
> 	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> };
> 
> I have tested on our omap3 based board and didn't find an issue
> so you can insert into your patch.

Migth be better if you send that so we get proper attribution and
you can explain the change properly in the commit message.

-- 
Ville Syrjälä
Intel


More information about the dri-devel mailing list