Skip to content

L
linux
Switch branch/tag
  1. 08 May, 2022 3 commits
  3. 06 May, 2022 2 commits
  5. 05 May, 2022 31 commits
  7. 04 May, 2022 4 commits
    • Marek Vasut's avatar
      drm/bridge: tc358767: Fix DP bridge mode detection from DT endpoints · 1bb533b6
      Marek Vasut authored 
      Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP
port is optional. In case this port is not described in DT, the bridge
driver operates in DPI-to-DP mode. Make sure the driver treats this as
a valid mode of operation instead of reporting invalid mode.

Fixes: 71f7d9c0 ("drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT")
Signed-off-by: default avatarMarek Vasut <marex@denx.de>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429204625.241591-1-marex@denx.de
      1bb533b6
    • Marek Vasut's avatar
      drm: mxsfb: Implement LCDIF scanout CRC32 support · 05ecc678
      Marek Vasut authored 
      The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
functional safety feature.

Unfortunately, there is zero documentation on how the CRC32 is calculated,
there is no documentation of the polynomial, the init value, nor on which
data is the checksum applied.

By applying brute-force on 8 pixel / 2 line frame, which is the minimum
size LCDIF would work with, it turns out the polynomial is CRC32_POLY_LE
0xedb88320 , init value is 0xffffffff , the input data are bitrev32()
of the entire frame and the resulting CRC has to be also bitrev32()ed.

Doing this calculation in kernel for each frame is unrealistic due to the
CPU demand, so attach the CRC collected from hardware to a frame instead.
The DRM subsystem already has an interface for this purpose and the CRC
can be accessed e.g. via debugfs:
"
$ echo auto > /sys/kernel/debug/dri/1/crtc-0/crc/control
$ cat /sys/kernel/debug/dri/1/crtc-0/crc/data
0x0000408c 0xa4e5cdd8
0x0000408d 0x72f537b4
"
The per-frame CRC can be used by userspace e.g. during automated testing,
to verify that whatever buffer was sent to be scanned out was actually
scanned out of the LCDIF correctly.
Acked-by: default avatarLucas Stach <l.stach@pengutronix.de>
Acked-by: default avatarStefan Agner <stefan@agner.ch>
Signed-off-by: default avatarMarek Vasut <marex@denx.de>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Robby Cai <robby.cai@nxp.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429212313.305556-1-marex@denx.de
      05ecc678
    • Christian König's avatar
      drm/nouveau: remove trace_dma_fence_emit · c81474ee
      Christian König authored 
      Hardware drivers which don't have much difference between emit and init
shouldn't use this trace point.
Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: nouveau@lists.freedesktop.org
Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220503085935.11023-1-christian.koenig@amd.com
      c81474ee
    • Lyude Paul's avatar
      drm/nouveau/subdev/bus: Ratelimit logging for fault errors · 9887bda0
      Lyude Paul authored 
      There's plenty of ways to fudge the GPU when developing on nouveau by
mistake, some of which can result in nouveau seriously spamming dmesg with
fault errors. This can be somewhat annoying, as it can quickly overrun the
message buffer (or your terminal emulator's buffer) and get rid of actually
useful feedback from the driver. While working on my new atomic only MST
branch, I ran into this issue a couple of times.

So, let's fix this by adding nvkm_error_ratelimited(), and using it to
ratelimit errors from faults. This should be fine for developers, since
it's nearly always only the first few faults that we care about seeing.
Plus, you can turn off rate limiting in the kernel if you really need to.
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Reviewed-by: default avatarKarol Herbst <kherbst@redhat.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com
      9887bda0
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7