Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 3月, 2014 1 次提交
  3. 14 1月, 2014 1 次提交
  5. 23 10月, 2013 1 次提交
    • M
      drm: copy mode type in drm_mode_connector_list_update() · 3fbd6439
      由 Marc-André Lureau 提交于 
      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>
      3fbd6439
  7. 01 10月, 2013 3 次提交
  9. 21 8月, 2013 1 次提交
  11. 19 8月, 2013 1 次提交
  13. 11 6月, 2013 2 次提交
  15. 03 6月, 2013 1 次提交
  17. 10 5月, 2013 1 次提交
  19. 26 4月, 2013 1 次提交
  21. 12 3月, 2013 2 次提交
    • T
      videomode: combine videomode dmt_flags and data_flags · 06a33079
      由 Tomi Valkeinen 提交于 
      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>
      06a33079
    • T
      videomode: simplify videomode Kconfig and Makefile · a38884f6
      由 Tomi Valkeinen 提交于 
      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>
      a38884f6
  23. 24 1月, 2013 2 次提交
  25. 07 11月, 2012 1 次提交
  27. 03 10月, 2012 2 次提交
  29. 22 8月, 2012 1 次提交
  31. 15 3月, 2012 1 次提交
  33. 13 2月, 2012 1 次提交
    • D
      drm/modes: do not enforce an odd vtotal for interlaced modes · 8bf42225
      由 Daniel Vetter 提交于 
      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>
      8bf42225
  35. 01 11月, 2011 1 次提交
  37. 25 7月, 2011 1 次提交
    • R
      DRM: clean up and document parsing of video= parameter · 04fee895
      由 Rolf Eike Beer 提交于 
      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>
      04fee895
  39. 04 5月, 2011 1 次提交
  41. 28 4月, 2011 1 次提交
  43. 23 2月, 2011 1 次提交
  45. 18 10月, 2010 1 次提交
  47. 27 8月, 2010 1 次提交
  49. 09 4月, 2010 1 次提交
  51. 06 4月, 2010 2 次提交
    • A
      drm/modes: Fix interlaced mode names · 171fdd89
      由 Adam Jackson 提交于 
      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>
      171fdd89
    • A
      drm/edid: Add secondary GTF curve support · 7a374350
      由 Adam Jackson 提交于 
      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>
      7a374350
  53. 13 1月, 2010 1 次提交
  55. 04 12月, 2009 1 次提交
  57. 25 9月, 2009 1 次提交
    • D
      drm/kms: start adding command line interface using fb. · d50ba256
      由 Dave Airlie 提交于 
      [note this requires an fb patch posted to linux-fbdev-devel already]

This uses the normal video= command line option to control the kms
output setup at boot time. It is used to override the autodetection
done by kms.

video= normally takes a framebuffer as the first parameter, in kms
it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
connector is specified the mode string will apply to all connectors.

The mode specification used will match down the probed modes, and if
no mode is found it will add a CVT mode that matches.

video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
video=VGA-1:1024x768, VGA-1 connector gets mode only.

The same strings as used in current fb modedb.c are used, except I've
added three more letters, e, D, d, e = enable, D = enable Digital,
d = disable, which allow a connector to be forced into a certain state.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      d50ba256
  59. 07 9月, 2009 1 次提交
    • Z
      drm/kms: try to find the std mode in DMT table · 559ee21d
      由 Zhao Yakui 提交于 
      When we need to add the standard timing mode, we will firstly check whether it
can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate.
If it can't be found, then we will use the cvt/gtf to add the required mode.
If it can be found, it will be returned.

At the same time the function of drm_mode_vrefresh is also fixed. It will
return the result of actual refresh_rate plus 0.5.
For example:
When the calculated value is 84.9, then the fresh_rate is 85.
When the calculated value is 70.02, then the fresh_rate is 70.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      559ee21d
  61. 13 8月, 2009 1 次提交
  63. 09 8月, 2009 1 次提交
    • K
      drm: When adding probed modes, preserve duplicate mode types · 38d5487d
      由 Keith Packard 提交于 
      The code which takes probed modes and adds them to a connector eliminates
duplicate modes by comparing them using drm_mode_equal. That function
doesn't consider the type bits, which means that any modes which differ only
in the type field will be lost.

One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
If the mode with that bit is lost, then higher level code will not know
which mode to select, causing a random mode to be used instead.

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.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      38d5487d
  65. 04 8月, 2009 1 次提交