Am 09.03.2020 um 14:00 schrieb Ville Syrjälä ville.syrjala@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@goldelico.com:
Hi,
Am 03.03.2020 um 16:03 schrieb Ville Syrjälä ville.syrjala@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