drm/exynos: fimd: vrefresh is zero

[Andrzej Hajda]

Hi Tobias, Daniel,

Little late, but maybe helpful anyway...

On 05/02/2016 11:00 PM, Daniel Vetter wrote:
> On Mon, May 2, 2016 at 10:30 PM, Tobias Jakobi
> <tjakobi at math.uni-bielefeld.de> wrote:
>>> drm_mode_set_crtcinfo() is meant to be used to fill in all the derived
>>> values. We might or might not want to have a default call for that in
>>> atomic helpers actually (before we call down into any of the driver's
>>> check functions for the first time). There's a bunch of flags to control
>>> it, but drivers with special needs could simply call it once more and
>>> overwrite the computed values. No harm done.
>> I had a look at drm_mode_set_crtcinfo() (from 4.6-rc6) but it also
>> doesn't set the vrefresh field. Maybe you mean a different call?
> 
> I was blind - it fills in everything except vrefresh. If you look at
> drivers most of them use vrefresh purely for debug output or as an
> informational field in general. Most hw wants the actual pixelclock
> anyway, so there's not really a need for vrefresh (e.g. i915 only
> computes vrefresh for the internally used panel modes). The value
> itself is directly taken from userspace, so probably just a bug in
> exynos userspace? Of course the driver should still keep working. From
> a quick look you want to remove any use of vrefresh (except debug
> output), and especially you shouldn't recompute the actual pixelclock
> like decon/fimd seem to do (stored into ideal_clock). Instead use
> mode->clock, that's supposed to be the real value.
> -Daniel
> 

Regarding the initial question, mode->vrefresh is set in
drm_helper_probe_single_connector_modes. I guess division by zero could
be caused by lack of clock in timings provided by dts timing node.
As I remember in the past dts timings were passed without provided
clock, in such case driver calculated mode->clock for some default value
of vrefresh (60Hz for fimd if I remember correctly). Later validation
code was added and the clock should be always provided.
DTS files were updated after some time and the recalculation code was
removed from fimd driver. So it is possible you are a victim of this change.

Regarding usage by drivers, from a quick look it seems to be used for
something more than debugging by:
- amdgpu,
- exynos,
- adv7511,
- intel_dp(?),
- mdp5_cmd_encoder(?),
- nouveau,
- omap(?),
- tilcdc.

Regards
Andrzej