Eric Lee / smarc-fsl-linux-kernel

15 Jul, 2019

1 commit

15 Jun, 2019

1 commit

  • a2f405a52   docs: EDID/HOWTO.txt: convert it and rename to howto.rst ... Browse Code »

    Sphinx need to know when a paragraph ends. So, do some adjustments
    at the file for it to be properly parsed.

    At its new index.rst, let's add a :orphan: while this is not linked to
    the main index.rst file, in order to avoid build warnings.

    that's said, I believe that this file should be moved to the
    GPU/DRM documentation.

    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

06 Nov, 2018

2 commits

  • 8bed5a5cf   Docs/EDID: Calculate CRC while building the code ... Browse Code »

    The previous version made it necessary to first generate an
    EDID data set without correct CRC and then to fix the CRC in
    a second step. This patch adds the CRC calculation to the
    makefile in such a way that a correct EDID data set is generated
    in a single build step. Successfully tested with all existing
    and a couple of new data sets.

    Signed-off-by: Christoph Niedermaier
    Reviewed-by: Carsten Emde
    Signed-off-by: Jonathan Corbet

    Christoph Niedermaier
     
  • d2f112a56   Docs/EDID: Fixed erroneous bits of XOFFSET, XPULSE, YOFFSET and YPULSE ... Browse Code »

    The problem was found when EDID data sets for displays other
    than the provided samples were generated. The patch has
    no effect on the provided samples that still match the data
    used in drivers/gpu/drm/drm_edid_load.c.

    The provided samples use small values for XOFFSET, XPULSE,
    YOFFSET and YPULSE, where the error doesn't occur. This fix
    corrects the use of that values in case of high values, because
    the most significant bits were treated incorrectly.

    So in edid.S msbs4 should use bit 8 and 9 of XOFFSET and XPULS.
    For YOFFSET and YPULSE msbs4 should use bit 4 and 5.

    lsbs2 was introduced for a better overview, without
    functional change.

    Removing also the useless value 63 of all files, because
    it is added in the *.S description files and then it is
    subtracted in edid.S.

    Signed-off-by: Christoph Niedermaier
    Reviewed-by: Carsten Emde
    Signed-off-by: Jonathan Corbet

    Christoph Niedermaier
     

30 Mar, 2017

1 commit

  • bd283d2f6   drm: use .hword to represent 16-bit numbers ... Browse Code »

    The size of .word is the size of a word in the given platform, which
    for intel systems is 16-bits but other architectures use different
    sizes. However, .hword emits 16-bit numbers regardless of the
    platform (and despite the name). The quantities specified in EDID are
    platform independent, so they should work in spite of the default
    target of the cc you are using, so use .hword where EDID specifies
    16-bit numbers.

    Cc: Carsten Emde
    Cc: David Airlie
    Acked-by: David Airlie
    Signed-off-by: Javi Merino
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/1490795123-16851-1-git-send-email-javi.merino@kernel.org

    Javi Merino
     

26 May, 2014

1 commit

  • 4cbe1bfa2   drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs ... Browse Code »

    The 800x600 (SVGA) screen resolution was lacking in the set of
    built-in selectable EDID screen resolutions that can be used to
    repair misbehaving monitor firmware.

    This patch adds the related data set and expands the documentation.
    Note that the SVGA bit occupies a different byte to all the existing
    users of the established timing bits forcing a rework of the
    ESTABLISHED_TIMINGS_BITS macro.

    Tested new EDID on an aged (and misbehaving) industrial LCD panel;
    existing EDIDs still pass edid-decode's checksum checks.

    Signed-off-by: Daniel Thompson
    Cc: Randy Dunlap
    Cc: David Airlie
    Cc: Carsten Emde
    Cc: linux-doc@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Daniel Thompson
     

12 Apr, 2013

1 commit

20 Jan, 2013

1 commit

20 Mar, 2012

1 commit

  • da0df92b5   drm: allow loading an EDID as firmware to override broken monitor ... Browse Code »

    Broken monitors and/or broken graphic boards may send erroneous or no
    EDID data. This also applies to broken KVM devices that are unable to
    correctly forward the EDID data of the connected monitor but invent
    their own fantasy data.

    This patch allows to specify an EDID data set to be used instead of
    probing the monitor for it. It contains built-in data sets of frequently
    used screen resolutions. In addition, a particular EDID data set may be
    provided in the /lib/firmware directory and loaded via the firmware
    interface. The name is passed to the kernel as module parameter of the
    drm_kms_helper module either when loaded
    options drm_kms_helper edid_firmware=edid/1280x1024.bin
    or as kernel commandline parameter
    drm_kms_helper.edid_firmware=edid/1280x1024.bin

    It is also possible to restrict the usage of a specified EDID data set
    to a particular connector. This is done by prepending the name of the
    connector to the name of the EDID data set using the syntax
    edid_firmware=[:]
    such as, for example,
    edid_firmware=DVI-I-1:edid/1920x1080.bin
    in which case no other connector will be affected.

    The built-in data sets are
    Resolution Name
    --------------------------------
    1024x768 edid/1024x768.bin
    1280x1024 edid/1280x1024.bin
    1680x1050 edid/1680x1050.bin
    1920x1080 edid/1920x1080.bin

    They are ignored, if a file with the same name is available in the
    /lib/firmware directory.

    The built-in EDID data sets are based on standard timings that may not
    apply to a particular monitor and even crash it. Ideally, EDID data of
    the connected monitor should be used. They may be obtained through the
    drm/cardX/cardX-/edid entry in the /sys/devices PCI directory
    of a correctly working graphics adapter.

    It is even possible to specify the name of an EDID data set on-the-fly
    via the /sys/module interface, e.g.
    echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
    The new screen mode is considered when the related kernel function is
    called for the first time after the change. Such calls are made when the
    X server is started or when the display settings dialog is opened in an
    already running X server.

    Signed-off-by: Carsten Emde
    Signed-off-by: Dave Airlie

    Carsten Emde