Hi Daniel, On Tue, Feb 14, 2017 at 10:42:53PM +0100, Daniel Vetter wrote: > On Tue, Feb 14, 2017 at 01:03:27PM -0800, John Stultz wrote: > > On Tue, Feb 14, 2017 at 12:22 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote: > > >> > > >> Not following here. What do you mean by "put it into drivers"? Where? > > > > > > In your driver callback for ->mode_valid, call into a shared function to > > > validate CRTC limits. Which you also call from the crtc's ->mode_fixup > > > function. > > > > So bascially have the adv7511 driver's mode_valid() have a special > > callback to the kirin (and freedreno, and whatever other) drm driver > > to check the modes? Or I guess the drm driver that uses that bridge > > should register something w/ the adv7511 code? > > > > Part of my confusion here is that the main issue is that its not just > > one driver I'm dealing with, and they're all really just tied together > > via device tree, so I'm not sure how to special case it in just one of > > the drivers. > > This sounds you want to fix this for bridges, but your patch only adds a > crtc callback? I've had kind of the same issue on sun4i actually. The issue is that a bridge (through EDID) might report that some modes are supported, and the bridge has a chance to say whether or not it can support such resolutions and filter out the ones it cannot. However, components higher in the pipeline cannot do so. In my case, we had an RGB to HDMI that was definitely able to support up to 1080p60. However, our RGB encoder can only generate a pixel clock for up to ~720p60, and this is not really the bridge's fault, so it shouldn't be in the bridge driver. The same bridge attached to a different RGB encoder (even a different SoC from the same family in our case) will run just fine at 1080p. We currently end up letting the user choose a resolution we knew very well had not a chance to work. I came up with a similar solution than John's, but for the encoders (since our clocks are per-encoder), but unfortunately had no time to push it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
