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]
Message-Id: <20171017042349.31743-1-wens@csie.org>
Date:   Tue, 17 Oct 2017 12:23:42 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>,
        David Airlie <airlied@...ux.ie>
Cc:     Chen-Yu Tsai <wens@...e.org>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: [PATCH 0/7] drm/sun4i: More cleanups

Hi,

Here's another bunch of cleanups for sun4i-drm. Most of these were
found while working on A10/A20 DRM and HDMI support. To be clear,
nothing was broken before these patches.

Changes since v1:

  - Expanded commit message for patch 5 explaining the details of
    memory address difference, wrap-around, and why only a few
    devices were affected.

Patch 1 trims the sun4i-drm probe sequence by not adding repeating
components. The component can deal with duplicates, but it leads
to excessive debug logs which is confusing for developers not in
the know.

Patch 2 moves regmap creation to a point where access is actually
possible, i.e. clocks enabled and reset controls deasserted.

Patch 3 moves to the new drm_fb_cma_get_gem_addr() helper instead
of open coding the same thing.

Patch 4 expands the comment explaining why we clear the backend
registers explicitly.

Patch 5 fixes the buffer address programmed into the backend layer
registers. This issue only hits devices with more than 1GB RAM.

Patch 6 documents some newly discovered but unused register bits
in the HDMI controller.

Patch 7 delays setting of the PAD_CTRL1 register in the HDMI controller
to the mode_set function. The main reason to do this is that between
probe time and when the display is actually setup, the controller itself
toggles some of the bits in this register. In particular, on the A10
it toggles the invert bits documented in the previous patch. This
causes the color to be completed inverted.

Please have a look.

Regards
ChenYu

Chen-Yu Tsai (7):
  drm/sun4i: don't add components that are already in the queue
  drm/sun4i: backend: Create regmap after access is possible
  drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display
    memory
  drm/sun4i: backend: Add comment explaining why registers are cleared
  drm/sun4i: backend: Offset layer buffer address by DRAM starting
    address
  drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits
  drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

 drivers/gpu/drm/sun4i/sun4i_backend.c  | 45 ++++++++++++++++++----------------
 drivers/gpu/drm/sun4i/sun4i_drv.c      | 16 ++++++++++++
 drivers/gpu/drm/sun4i/sun4i_hdmi.h     |  5 ++++
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 26 ++++++++++++--------
 4 files changed, 61 insertions(+), 31 deletions(-)

-- 
2.14.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ