Hi, On 19 May 2015 at 19:43, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote: > 2015-05-19 Tobias Jakobi <tjakobi@xxxxxxxxxxxxxxxxxxxxx>: >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
