- 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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It never fails and no one ever checked anyway.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And clean it up so that there's no kerneldoc warnings. There's still a
lot to do with this one here.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 3fbd6439.

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: NDave Airlie <airlied@redhat.com>

In commit 38d5487d, 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: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.

v2: Use crtc_vtotal and multiply the clock by 2 instead of
    reconstructing it (Ville Syrjälä)
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The last user was removed in

  commit 575dc34e
  Author: Dave Airlie <airlied@redhat.com>
  Date:   Mon Sep 7 18:43:26 2009 +1000

      drm/kms: remove old std mode fallback code.

      The new code adds modes in the helper, which makes more sense
      I disliked the non-driver code adding modes.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This function is unused.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Keeping the modes sorted by vrefresh before the pixel clock makes the
mode list somehow more pleasing to the eye.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Preserve the destination mode's list head in drm_mode_copy. Just
in case someone decides that it's a good idea to overwrite a mode which
happens to be on some list,
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
compare the clock or vrefresh values. drm_mode_equal() is now
implemented by first doing the clock checks, and then calling
drm_mode_equal_no_clocks().

v2: Add missing EXPORT_SYMBOL()
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.

This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY_FLAGS_*.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>

This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:

* Videomode helper functions are not something that should be shown in
  the kernel configuration options. The related code should just be
  included if it's needed, i.e. selected by drivers using videomode.

* There's no need to have separate Kconfig options for videomode and
  display_timing. First of all, the amount of code for both is quite
  small. Second, videomode depends on display_timing, and display_timing
  in itself is not really useful, so both would be included in any case.

* CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS
  describes better what's included.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Add helper to get drm_display_mode from devicetree.
Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: NThierry Reding <thierry.reding@avionic-design.de>
Acked-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NAfzal Mohammed <Afzal@ti.com>
Tested-by: NRob Clark <robclark@gmail.com>
Tested-by: NLeela Krishna Amudala <leelakrishna.a@gmail.com>

Add conversion from videomode to drm_display_mode
Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: NThierry Reding <thierry.reding@avionic-design.de>
Acked-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NAfzal Mohammed <Afzal@ti.com>
Tested-by: NRob Clark <robclark@gmail.com>
Tested-by: NLeela Krishna Amudala <leelakrishna.a@gmail.com>

None of drm_mode_debug_printmodeline(), drm_mode_equal(), drm_mode_width()
or drm_mode_height() change the mode passed in, so make the arguments
const.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h).  They are now #included via drmP.h and drm_crtc.h via a preceding
patch.

Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..."  work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a helper function to copy a display mode. Use it in
drm_mode_duplicate() and nouveau mode_fixup hooks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.

Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_ to be odd. But the even
modelines in CEA are not a spec-bug, there's a figure in CEA-861-E
called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)"
that explains how it's supposed to work. Furthermore intel Bspec
explicitly mentions that both odd and even interlaced vtotal are
supported (VTOTAL register in the south display engine of PCH split
chips).
Acked-by: NAdam Jackson <ajax@redhat.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The video= parameter of the DRM drivers supports some additional flags that
the normal fb drivers do not have. They also allow to limit these flags to
specific outputs. Both things were previously undocumented.

Also the parsing of the line had some oddities:
-A lot of misplaced options were silently ignored or partly rejected instead
 of stopping the parsing immediately
-The 'R' option is documented to follow the 'M' option if specified. It is not
 documented that 'M' is needed to specify 'R' (also this is the case for normal
 fb drivers). In fact the code is correct for normal fb drivers but wrong for
 DRM ones.
 The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
 if 'M' is given at all which is not needed for the DRM drivers.
-the margins option ('m') was parsed but later ignored even if the later
 functions support it.
-specifying multiple enable options at the same time did not lead to an error.
-specifying something bogus for horizontal resolution (i.e. other things as
 digits) did not lead to an error but an invalid resolution was used.

If any errors are encountered the position of the faulting string is now
printed to the user and the complete mode is ignored. This gives much
more consistent error behaviour.

I also removed some useless assignments and changed the local flag variables
to be bool.
Signed-off-by: NRolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The previous commit to move the parsing into the core drm created a
new situation and a soft dependency on the CONFIG_FB. We really don't
want to make this a hard dependency so just wrap the one place that
actually needs an fb symbol.
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In the absence of configuration data for providing the fixed mode for
a panel, I would like to be able to pass such modes along a separate
module paramenter. To do so, I then need to parse a modeline from a
string, which drm is already capable of. Export that capability to the
drivers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... and fixup some methods to accept the constant argument.

Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The patch below updates broken web addresses in the kernel
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Dimitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Acked-by: NBen Pfaff <blp@cs.stanford.edu>
Acked-by: NHans J. Koch <hjk@linutronix.de>
Reviewed-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NAdam Serbinski <adam@serbinksi.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Height in frame size, not field size, and trailed with an 'i'.  Matches
the X server behaviour.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Before CVT-R, some monitors would advertise support for an alternative
GTF formula with lower blanking intervals.  Correctly identify such
monitors, and use the alternative formula when generating modes for
them.

Note that we only do this for "standard" timing descriptors (tuples of
hsize in characters / aspect ratio / vertical refresh).  Range-based
mode lists still only refer to the primary GTF curve.  It would be
possible to do better for the latter case, but monitors are required to
support the primary curve over the entire advertised range, so all it
would win you is a lower pixel clock and therefore possibly better image
quality on analog links.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>