On Tue, Nov 26, 2024 at 01:09:10PM +0100, Maxime Ripard wrote: > On Tue, Nov 26, 2024 at 12:34:26PM +0100, Sean Nyekjaer wrote: > > Hi, > > > > On Tue, Nov 26, 2024 at 09:38:55AM +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Tue, Nov 26, 2024 at 08:36:00AM +0100, Sean Nyekjaer wrote: > > > > On Mon, Nov 25, 2024 at 05:00:56PM +0100, Maxime Ripard wrote: > > > > > On Mon, Nov 25, 2024 at 02:49:26PM +0100, Sean Nyekjaer wrote: [...] > > > > > > > > > > Thanks a lot for doing that! > > > > > > > > > > I wonder about the naming though (and prototype). I doesn't really > > > > > validates a mode, but rather makes sure that a given rate is a good > > > > > approximation of a pixel clock. So maybe something like > > > > > drm_mode_check_pixel_clock? > > > > > > > > Naming is hard :) I will use drm_mode_check_pixel_clock() for V2. > > > > > > > > Would it make sense to have the pixel clock requirement as a input > > > > parameter? For HDMI it is 0.5% > > > > > > This code was only used for panels so far. It reuses the same tolerance > > > than HDMI because we couldn't come up with anything better, but it > > > should totally apply to other things. > > > > > > > and in my case the LVDS panel 10%. > > > > > > 10% is a lot, and I'm not sure we'll want that. The framerate being > > > anywhere between 54 and 66 fps will trip a lot of applications too. > > > > > > Why do you need such a big tolerance? > > > > I don't need it, it was just from the datasheet for the LVDS panel :) > > So you mean the panel accepts a pixel clock within +/- 10%? Yes :) > > That makes sense, but then we should also adjust the mode timings to > match so we still keep 60fps. There's much more to *that* than the > helpers you try to create though, so let's keep it aside for now. Ok > > Maxime /Sean
