kernel.git/drivers/gpu/drm/drm_modes.c, branch linux-3.15.y

drm: polish function kerneldoc for drm_modes.[hc]

2014-03-13T11:48:44Z

- Tune down yelling RETURNS. - OCD align all the parameters the same. - Add missing kerneldoc, which also means that we need to include the kerneldoc from the drm_modes.h header now. - Add missing Returns: sections. - General polish and clarification - especially the kerneldoc for the mode creation helpers seems to have been some good specimen of copypasta gone wrong. All actual code changes have all been extracted into prep patches since there was simply too much to polish. v2: More polish for the command line modeline functions. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/modes: drop maxPitch from drm_mode_validate_size

2014-03-13T11:48:43Z

Totally unused and actually redundant with maxX for display mode validation. The fb helper otoh needs to check pitch limits, but that is delegated into drivers instead. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/modes: drop return value from drm_display_mode_from_videomode

2014-03-13T11:48:42Z

It never fails and no one ever checked anyway. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/modes: remove drm_mode_height/width

2014-03-13T11:48:41Z

There's a neat FIXME asking whether this is really need. I'd say really no. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm: extract drm_modes.h for drm_crtc.h functions

2014-03-13T11:48:41Z

I want to also include kerneldoc from the header (for static inline functions and structs), but fishing the right pieces out of a giant header is a real pain. So split things out. Note that it's not a really clean header with sane include orders, but given's drm historical knack for giant headers detangling this is a major task. v2: Also extract struct drm_cmdline_mode. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm: move drm_mode related functions into drm_modes.c

2014-03-13T11:48:40Z

Makes more sense and gives better grouping in the DocBook function reference sections. To make this possible we need to expose two functions from drm_crtc.c though. To avoid further namespace pollution in the system wide headers create a new internal header for such drm internal symbols. I expect that longer-term we'll add tons more, but since my goal here is to polish the kerneldoc that's for another day. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c

2014-03-13T11:48:39Z

There's not really any value in stating that no locking is needed. And even if the comment is useful, a check for the right mutex at the beginning of the function is better since that can't be ingored as easily as a bit of documentation. Note that drm_mode_probed_add in drm_crtc.c is also changed, the next patch will move this into drm_modes.c v2: Don't add locking WARN_ONs where it is not strictly required (i.e. the two functions to validate/prune mode lists). Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/doc: Integrate drm_modes.c kerneldoc

2014-03-13T11:48:38Z

And clean it up so that there's no kerneldoc warnings. There's still a lot to do with this one here. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

Revert "drm: copy mode type in drm_mode_connector_list_update()"

2014-01-14T02:50:49Z

This reverts commit 3fbd6439e4639ecaeaae6c079e0aa497a1ac3482. This caused some strange booting lockup issues on an Intel G33 belonging to Daniel Vetter, very unusual, I was hoping Daniel would track this down, but it looks like instead I'll have to hack a different fix for -next. Signed-off-by: Dave Airlie

drm: copy mode type in drm_mode_connector_list_update()

2013-10-23T13:21:12Z

In commit 38d5487db7f289be1d56ac7df704ee49ed3213b9, Keith explained: This patch simply merges the two mode type bits together; that seems reasonable to me, but perhaps only a subset of the bits should be used? None of these can be user defined as they all come from looking at just the hardware. However, merging the bits means that a flag becomes sticky. It is not possible, for example to update the mode type to remove the DRM_MODE_TYPE_PREFERRED bit. After a brief discussion with Dave Airlie on irc, it was agreed to propose that change, instead of introducing another function to remove a bit from exisiting modes type. Signed-off-by: Marc-André Lureau Signed-off-by: Dave Airlie