lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu,  8 Mar 2018 16:24:00 +0100
From:   Jacopo Mondi <jacopo+renesas@...ndi.org>
To:     architt@...eaurora.org, a.hajda@...sung.com,
        Laurent.pinchart@...asonboard.com, airlied@...ux.ie,
        horms@...ge.net.au, magnus.damm@...il.com, geert@...ux-m68k.org,
        niklas.soderlund@...natech.se, sergei.shtylyov@...entembedded.com,
        robh+dt@...nel.org, mark.rutland@....com
Cc:     Jacopo Mondi <jacopo+renesas@...ndi.org>,
        dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] drm: Add LVDS decoder bridge

Hello,
   this small series add a driver for transparent LVDS decoders, as
Thine THC63LVD1024 device.

The R-Car Gen3 V3M Eagle board feature such a converter, that has been so far
not described as part of the display output pipeline. Now that a driver has
been added, the Eagle DTS file has been updated to include the transparent
decoder chip.

So far so good, but currently the current DRM Bridge API do not provide support
to query a mode from another bridge as it is possible to do on panel devices.
In our case the LVDS decoder is connected to the output of R-Car DU lvds encoder
(drivers/gpu/drm/rcar-du/rcar_lvds.c). As its 'mode_set' function shows, LVDS
modes cannot be propagated from bridge to another bridge, but are instead
inferred from the bus_format field of the panel's connector.

It is my intention to propose an API extension to allow formats to be propagated
through bridges, but knowing the DRM/KMS subsystem very superficially I would
appreciate any pointer from more experienced developers.

For Renesas side:
The series is based on Laurent's drm/next/du branch with patches on top for:
- Sergei: Enable PFC, I2c, GPIOs for r8a77970
- Sergei: Add support for r8a77970 in DU and add display device nodes in
  r8a77970 DTSI
- Niklas: Connect DU LVDS output to HDMI bridge adv7511w in Eagle DTS
- Sergei: fix video output on R8A77970

A base branch with these patches applied is available at
git://jmondi.org/linux v3m/v4.16-rc3/base

Tested on Eagle board, making sure DU probes and testing all available output
modes (of which only a few are actually working, I suspect due to faulty mode
propagation through DRM bridges).

Thanks
   j

Jacopo Mondi (3):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add LVDS decoder driver
  arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  59 +++++
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts     |  31 ++-
 drivers/gpu/drm/bridge/Kconfig                     |   8 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/lvds-decoder.c              | 239 +++++++++++++++++++++
 5 files changed, 336 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c

--
2.7.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ