> Am 09.03.2020 um 14:00 schrieb Ville Syrjälä <ville.syrj...@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 <h...@goldelico.com>:
>>>
>>> Hi,
>>>
>>>> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä
>>>> <ville.syrj...@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
