Hi,
On 19 May 2015 at 19:43, Gustavo Padovan gustavo@padovan.org wrote:
2015-05-19 Tobias Jakobi tjakobi@math.uni-bielefeld.de:
so Daniel helped me track down this issue. It came from an incorrect 'clock-frequency' entry in my DTS. The freq was 500000. Daniel recommended 70600000 which works 'fine' (and according to modetest produces a 59Hz mode). I say 'fine' because I can't confirm that FIMD is actually working. I just see that with that change I no longer get any div-by-zeros in the kernel.
That is good to hear! So maybe we are now ready to have the atomic modesetting patches merged in. I'll send a new version with the last fix to avoid crashes with null CRTC.
Indeed. Though as he says below:
So fimd_calc_clkdiv needs some sanitizing for 'ideal_clk' at least.
It would be nice to: a) reject any mode with an impossible clock in mode_valid (filter connector modes) + mode_fixup (explicit request) b) WARN_ON and return during FIMD commit if clk_div ends up being zero
What still bothers me though is the fact that FIMD actually gets enabled. I'm just calling 'modetest -M exynos', so it's just doing probing. Why does that trigger dpms?
That comes from restore_fbdev_mode() when modetest closes the file descriptor, but I'm not sure why a update happens at this time.
It comes from lastclose: when the last client exits, DRM tries to restore the mode that fbcon was using. Quite why it didn't fail before this point (i.e. when doing it initially), I'm not quite sure, but oh well.
Cheers, Daniel