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

[H. Nikolaus Schaller]

> Am 09.03.2020 um 14:00 schrieb Ville Syrjälä <ville.syrjala at linux.intel.com>:
> 
> 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.

Ok, will do asap.

BR and thanks,
Nikolaus