Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this?
I expected to see a mode_valid callback in crtc or somewhere similar. What I've got right now is a drm connector and encoder, which are describing a silicon image hdmi transmitter, and an embedded crtc connected to it. While the transmitter is fairly capable the crtc in the SoC is not (it has a maximum pixel clock limitation of 133MHz which means I have to kill off modes above that like 1080p@60. There are other things I may need to limit too).
How do I coordinate such things from the drm_driver or crtc level up to the connector/encoder without making the connector/encoder intimately knowledgeable about the underlying crtc? Currently my only resort is to put the limits in platform data for the connector/encoder and use the mode_valid I already have to parse and discard modes which are plainly not going to be able to be clocked.
On Wed, 2012-02-15 at 22:43 -0600, Matt Sealey wrote:
Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this?
I think this is an API bug. The crtc really should get a chance to do this. If nothing else it would simplify existing drivers, since eg Intel gen3 wouldn't have to replicate the width>2048 check across every output type.
- ajax
On Thu, Feb 16, 2012 at 9:51 AM, Adam Jackson ajax@redhat.com wrote:
On Wed, 2012-02-15 at 22:43 -0600, Matt Sealey wrote:
Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this?
I think this is an API bug. The crtc really should get a chance to do this. If nothing else it would simplify existing drivers, since eg Intel gen3 wouldn't have to replicate the width>2048 check across every output type.
Yay I found a bug?!
Okay so a crtc helper func for mode_valid would probably be the way to go..
Now the big question; the only user of mode_valid that I see is drm_helper_probe_single_connector_modes which has no "access" to the crtc or crtc helpers right now. It does checking on maximums and interlace/doublescan, should these eventually be passed to the crtc for verification instead of having the connector actually do this?
It seems like a rather huge, messy API bug to fix at first glance..
dri-devel@lists.freedesktop.org