1. 26 Nov, 2018 1 commit
    • Lyude Paul's avatar
      drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() · 97b2a318
      Lyude Paul authored
      Currently on driver bringup with KASAN enabled, meson triggers an OOB
      memory access as shown below:
      
      [  117.904528] ==================================================================
      [  117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
      [  117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
      [  117.904601]
      [  118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
      [  118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [  118.099768] Call trace:
      [  118.102181]  dump_backtrace+0x0/0x3e8
      [  118.105796]  show_stack+0x14/0x20
      [  118.109083]  dump_stack+0x130/0x1c4
      [  118.112539]  print_address_description+0x60/0x25c
      [  118.117214]  kasan_report+0x1b4/0x368
      [  118.120851]  __asan_report_load4_noabort+0x18/0x20
      [  118.125566]  meson_viu_set_osd_lut+0x7a0/0x890
      [  118.129953]  meson_viu_init+0x10c/0x290
      [  118.133741]  meson_drv_bind_master+0x474/0x748
      [  118.138141]  meson_drv_bind+0x10/0x18
      [  118.141760]  try_to_bring_up_master+0x3d8/0x768
      [  118.146249]  component_add+0x214/0x570
      [  118.149978]  meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
      [  118.155404]  platform_drv_probe+0x98/0x138
      [  118.159455]  really_probe+0x2a0/0xa70
      [  118.163070]  driver_probe_device+0x1b4/0x2d8
      [  118.167299]  __driver_attach+0x200/0x280
      [  118.171189]  bus_for_each_dev+0x10c/0x1a8
      [  118.175144]  driver_attach+0x38/0x50
      [  118.178681]  bus_add_driver+0x330/0x608
      [  118.182471]  driver_register+0x140/0x388
      [  118.186361]  __platform_driver_register+0xc8/0x108
      [  118.191117]  meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
      [  118.198022]  do_one_initcall+0x12c/0x3bc
      [  118.201883]  do_init_module+0x1fc/0x638
      [  118.205673]  load_module+0x4b4c/0x6808
      [  118.209387]  __se_sys_init_module+0x2e8/0x3c0
      [  118.213699]  __arm64_sys_init_module+0x68/0x98
      [  118.218100]  el0_svc_common+0x104/0x210
      [  118.221893]  el0_svc_handler+0x48/0xb8
      [  118.225594]  el0_svc+0x8/0xc
      [  118.228429]
      [  118.229887] The buggy address belongs to the variable:
      [  118.235007]  eotf_33_linear_mapping+0x84/0xc0
      [  118.239301]
      [  118.240752] Memory state around the buggy address:
      [  118.245522]  ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.252695]  ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
      [  118.267000]                                ^
      [  118.271222]  ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      [  118.278393]  ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
      [  118.285542] ==================================================================
      [  118.292699] Disabling lock debugging due to kernel taint
      
      It seems that when looping through the OSD EOTF LUT maps, we use the
      same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
      which means that we'll stop out of bounds on the EOTF maps.
      
      But, this whole thing is already confusing enough to read through as-is,
      so let's just replace all of the hardcoded sizes with
      OSD_(OETF/EOTF)_LUT_SIZE / 2.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Acked-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      97b2a318
  2. 04 Apr, 2017 1 commit
  3. 01 Dec, 2016 1 commit
    • Neil Armstrong's avatar
      drm: Add support for Amlogic Meson Graphic Controller · bbbe775e
      Neil Armstrong authored
      The Amlogic Meson Display controller is composed of several components :
      
      DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
         | vd1   _______     _____________    _________________     |               |
      D  |-------|      |----|            |   |                |    |   HDMI PLL    |
      D  | vd2   | VIU  |    | Video Post |   | Video Encoders |<---|-----VCLK      |
      R  |-------|      |----| Processing |   |                |    |               |
         | osd2  |      |    |            |---| Enci ----------|----|-----VDAC------|
      R  |-------| CSC  |----| Scalers    |   | Encp ----------|----|----HDMI-TX----|
      A  | osd1  |      |    | Blenders   |   | Encl ----------|----|---------------|
      M  |-------|______|----|____________|   |________________|    |               |
      ___|__________________________________________________________|_______________|
      
      VIU: Video Input Unit
      ---------------------
      
      The Video Input Unit is in charge of the pixel scanout from the DDR memory.
      It fetches the frames addresses, stride and parameters from the "Canvas" memory.
      This part is also in charge of the CSC (Colorspace Conversion).
      It can handle 2 OSD Planes and 2 Video Planes.
      
      VPP: Video Post Processing
      --------------------------
      
      The Video Post Processing is in charge of the scaling and blending of the
      various planes into a single pixel stream.
      There is a special "pre-blending" used by the video planes with a dedicated
      scaler and a "post-blending" to merge with the OSD Planes.
      The OSD planes also have a dedicated scaler for one of the OSD.
      
      VENC: Video Encoders
      --------------------
      
      The VENC is composed of the multiple pixel encoders :
       - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
       - ENCP : Progressive Video Encoder for HDMI
       - ENCL : LCD LVDS Encoder
      The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
      tree and provides the scanout clock to the VPP and VIU.
      The ENCI is connected to a single VDAC for Composite Output.
      The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
      
      This driver is a DRM/KMS driver using the following DRM components :
       - GEM-CMA
       - PRIME-CMA
       - Atomic Modesetting
       - FBDev-CMA
      
      For the following SoCs :
       - GXBB Family (S905)
       - GXL Family (S905X, S905D)
       - GXM Family (S912)
      
      The current driver only supports the CVBS PAL/NTSC output modes, but the
      CRTC/Planes management should support bigger modes.
      But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
      a second time.
      
      The Device Tree bindings makes use of the endpoints video interface definitions
      to connect to the optional CVBS and in the future the HDMI Connector nodes.
      
      HDMI Support is planned for a next release.
      Acked-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      bbbe775e