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.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
