1. 14 Feb, 2018 1 commit
    • Liviu Dudau's avatar
      drm/arm: mali-dp: Fix sending the vblank event to userspace · b41d28d8
      Liviu Dudau authored
      Currently the Mali DP version of atomic_commit_hw_done sets the
      'go' bit (config_valid) before arming the vblank event to be sent
      to userspace. As the comments for drm_crtc_arm_vblank_event() warn,
      that is a sure recipe for sending the vblank event at the wrong
      vblank interrupt. The correct way of handling this (as hinted by
      the comments) is to send the vblank event from the IRQ handler
      and only set the 'go' bit in the atomic_commit_hw_done() hook.
      
      Currently the malidp_atomic_commit_hw_done() function still sends
      the vblank event if the CRTC is disabled, due to IRQs being turned
      off before the last commit which turns off the CRTC. That will be
      sorted out in a future patch that will re-order the de-activation
      of IRQs.
      Reported-by: default avatarAlexandru-Cosmin Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      b41d28d8
  2. 12 Feb, 2018 39 commits
    • Liviu Dudau's avatar
      drm/arm: hdlcd: Reject states with active CRTC but no primary fb. · d87d488b
      Liviu Dudau authored
      HDLCD cannot turn off its primary plane and as such it should not
      accept states where the CRTC is active but no primary fb is provided.
      
      Discovered while playing with modetest and the HDLCD behind an active
      SMMU which complained loudly that the driver was reading from invalid
      memory.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      d87d488b
    • Laurent Pinchart's avatar
      drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes on removal · 746fa913
      Laurent Pinchart authored
      The plane cleanup handler currently calls drm_plane_helper_disable(),
      which is a legacy helper function. Replace it with a call to
      drm_atomic_helper_shutdown() at removal time.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      746fa913
    • Laurent Pinchart's avatar
      drm: arm: malidp: Don't destroy planes manually in error handlers · 68e9c985
      Laurent Pinchart authored
      The top-level error handler calls drm_mode_config_cleanup() which will
      destroy all planes. There's no need to destroy them manually in lower
      error handlers.
      
      As plane cleanup is now handled entirely by drm_mode_config_cleanup(),
      we must ensure that the plane .destroy() handler frees allocated memory
      for the plane object that was freed by malidp_de_planes_destroy(). Do so
      by replacing the call to devm_kfree() in the .destroy() handler by
      kfree(). devm_kfree() is currently a no-op as the plane memory is
      allocated with kzalloc(), not devm_kzalloc().
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      68e9c985
    • Laurent Pinchart's avatar
      drm: arm: hdlcd: Use drm_atomic_helper_shutdown() to disable planes on removal · 55c7e85f
      Laurent Pinchart authored
      The plane cleanup handler currently calls drm_plane_helper_disable(),
      which is a legacy helper function. Replace it with a call to
      drm_atomic_helper_shutdown() at removal time. The plane .destroy()
      handler now consisting only of a call to drm_plane_cleanup(), replace it
      with direct calls to that function.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      55c7e85f
    • Laurent Pinchart's avatar
      drm: arm: hdlcd: Don't destroy plane manually in hdlcd_setup_crtc() · a6cf5674
      Laurent Pinchart authored
      The top-level error handler calls drm_mode_config_cleanup() which will
      destroy all planes. There's no need to destroy them manually in lower
      error handlers.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      a6cf5674
    • Ayan Halder's avatar
      drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha · 385398fe
      Ayan Halder authored
      Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
      display color formats that do not contain alpha bits per pixel
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      385398fe
    • Ayan Halder's avatar
      drm: add drm_format_alpha_bits · 988ef354
      Ayan Halder authored
      drm_format_info does not describe the number of bits used for the alpha
      channel. That information is useful in a central place like drm_fourcc.c
      where it can be queried by the drivers that want to determine if 'alpha
      blending' is to be enabled or not.
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      988ef354
    • Ayan Halder's avatar
      drm: mali-dp: Fix bug on scaling with rotation · d77ef08e
      Ayan Halder authored
      In the case, when the user wants to scale and rotate a layer by 90/270
      degrees, the scaling engine input dimensions' parameters ie width and
      height needs to be swapped with respect to the layer's input dimensions.
      This means scaling engine input height should be set to layer's input
      width and scaling engine input width should be set to
      layer's input height.
      Signed-off-by: default avatarAyan Halder <ayan.halder@arm.com>
      d77ef08e
    • Liviu Dudau's avatar
      drm/mali-dp: Don't enable scaling engine for planes that only rotate. · 7a904042
      Liviu Dudau authored
      Currently the scaling engine gets enabled for a plane where the input
      size differs from the composition size. As rotation is done natively
      by the plane's hardware layer, we don't need the scaling engine to be
      enabled.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      7a904042
    • Noralf Trønnes's avatar
      drm/arm/hdlcd: Use drm_fb_cma_fbdev_init/fini() · 994a15ed
      Noralf Trønnes authored
      Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
      the fact that drm_device holds a pointer to the drm_fb_helper structure.
      This means that the driver doesn't have to keep track of that.
      Also use the drm_fb_helper functions directly.
      
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Brian Starkey <brian.starkey@arm.com>
      Signed-off-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Acked-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      994a15ed
    • Noralf Trønnes's avatar
      drm/arm/hdlcd: Use drm_mode_config_helper_suspend/resume() · 2fe6fc36
      Noralf Trønnes authored
      Replace driver's code with the generic helpers that do the same thing
      including the NULL check.
      
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Brian Starkey <brian.starkey@arm.com>
      Signed-off-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      2fe6fc36
    • Dan Carpenter's avatar
      drm: mali-dp: Uninitialized variable in malidp_se_check_scaling() · 9e63d3d5
      Dan Carpenter authored
      We use "mc" without initializing it if scaling is not necessary.
      
      Fixes: 28ce675b ("drm: mali-dp: Add plane upscaling support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      9e63d3d5
    • Liviu Dudau's avatar
      drm/mali-dp: Align pitch size to be multiple of bus burst read size. · 297c8f5e
      Liviu Dudau authored
      Mali DP hardware needs pitch line sizes aligned to the bus burst
      size for reads, so take that into consideration when allocating dumb
      buffers. If the layer is rotated then the stride size requirement is
      even larger for some hardware versions, so allocate for the worst case
      scenario. Update the ->dumb_create() hook to a driver specific function
      that sets the correct pitch size.
      Reported-by: default avatarAyan Halder <ayan.halder@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      297c8f5e
    • Liviu Dudau's avatar
      drm/mali-dp: Rotated planes need a larger pitch size. · 756b9571
      Liviu Dudau authored
      Rotated planes need a pitch size that is aligned to 8 bytes
      for older DP500 and DP550 and at least 64 bytes for DP650. Replace
      the malidp_hw_pitch_valid() function with one that calculates
      the correct pitch alignment to take into account rotation.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      756b9571
    • Liviu Dudau's avatar
      drm/fb-helper: Restore first connection behaviour on deferred setup · dee7e03b
      Liviu Dudau authored
      Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
      if no output is connected at framebuffer setup time, we get a default
      1024x768 mode that is going to be used when we first connect a monitor.
      After the commit, on first connection after deferred setup, we probe
      the monitor and get the preferred resolution, but no mode get set
      because the drm_fb_helper_hotplug_event() function returns early
      when the setup has been deferred. That is different from what happens
      on a second re-connect of the monitor, when the native mode get set.
      
      Create a more consistent behaviour by checking in the
      drm_fb_helper_hotplug_event() function if the deferred setup is still
      active. If not, that means we now have a valid framebuffer that can be
      used for setting the correct mode.
      
      Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup")
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <Liviu.Dudau@arm.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      dee7e03b
    • Liviu Dudau's avatar
      drm: mali-dp: Add support for memory writeback to DP500. · c5632218
      Liviu Dudau authored
      For testing purposes only.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      c5632218
    • Robin Murphy's avatar
      iommu/arm-smmu: Favour v7S format if possible · 074b428f
      Robin Murphy authored
      Allow stage 1 contexts to default to short-descriptor format if
      supported and all DRAM is 32-bit-addressable.
      Signed-off-by: Robin Murphy's avatarRobin Murphy <robin.murphy@arm.com>
      074b428f
    • Robin Murphy's avatar
      iommu/dma: Extended DMA domain debug info · 35d2b57a
      Robin Murphy authored
      Keep track of the allocation details too.
      Signed-off-by: Robin Murphy's avatarRobin Murphy <robin.murphy@arm.com>
      35d2b57a
    • Robin Murphy's avatar
      iommu/dma: Add DMA domain debug info · 93753c40
      Robin Murphy authored
      Dump IOVA usage via debugfs.
      Signed-off-by: Robin Murphy's avatarRobin Murphy <robin.murphy@arm.com>
      93753c40
    • Liviu Dudau's avatar
      a976e678
    • Liviu Dudau's avatar
      arm64: juno: Add node for SMMUv3 device serving Mali-DP on FPGA · de26ec73
      Liviu Dudau authored
      Also enable the SMMU in front of the HDLCD device.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      de26ec73
    • Liviu Dudau's avatar
    • Liviu Dudau's avatar
      arm64: juno: Add support for the FPGA V2F-1XV7 Coretile running Mali-DP instances. · 6b709c68
      Liviu Dudau authored
      Add support for the FPGA V2F-1XV7 Coretile that can be loaded with
      a Mali-DP instance.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <Liviu.Dudau@arm.com>
      6b709c68
    • Mihail Atanassov's avatar
      drm: mali-dp: Add YUV->RGB conversion support for video layers · 6bdbe450
      Mihail Atanassov authored
      Internally Mali DP uses an RGB pipeline so video layers that support
      YUV input buffers need to convert the input data to RGB. The YUV
      buffers can have various encodings and this patch introduces support
      for BT.601, BT.709 and BT.2020 encodings, both limited and full ranges.
      
      This patch adds support for specifying the color encoding of the
      input buffers for the planes that are backed by the video layers
      and programs the YUV2RGB coefficients into hardware based on the
      selected encoding.
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      [updated to use standard properties]
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      6bdbe450
    • Jyri Sarha's avatar
      drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane · f50af236
      Jyri Sarha authored
      Add a standard optional properties to support different non RGB color
      encodings in DRM planes. COLOR_ENCODING select the supported non RGB
      color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
      the value ranges within the selected color encoding. The properties
      are stored to drm_plane object to allow different set of supported
      encoding for different planes on the device.
      Signed-off-by: default avatarJyri Sarha <jsarha@ti.com>
      f50af236
    • Brian Starkey's avatar
      drm: mali-dp: Add writeback connector · 76a775b3
      Brian Starkey authored
      Mali-DP has a memory writeback engine which can be used to write the
      composition result to a memory buffer. Expose this functionality as a
      DRM writeback connector on supported hardware.
      
      Changes since v1:
       Daniel Vetter:
       - Don't require a modeset when writeback routing changes
       - Make writeback connector always disconnected
      
      Changes since v2:
       - Rebase onto new drm_writeback_connector
       - Add reset callback, allocating subclassed state
       Daniel Vetter:
       - Squash out-fence support into this commit
       Gustavo Padovan:
       - Don't signal fence directly from driver (and drop malidp_mw_job)
      
      Changes since v3:
       - Modifications to fit with Mali-DP commit tail changes
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      [rebased and fixed conflicts]
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      76a775b3
    • Brian Starkey's avatar
      drm: mali-dp: Add RGB writeback formats for DP550/DP650 · 16aebb7c
      Brian Starkey authored
      Add a layer bit for the SE memory-write, and add it to the pixel format
      matrix for DP550/DP650.
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      [rebased and fixed conflicts]
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      16aebb7c
    • Liviu Dudau's avatar
      drm: mali-dp: Add support for writeback on DP550/DP650 · 92060ad8
      Liviu Dudau authored
      Mali-DP display processors are able to write the composition result to a
      memory buffer via the SE.
      
      Add entry points in the HAL for enabling/disabling this feature, and
      implement support for it on DP650 and DP550. DP500 acts differently and
      so is omitted from this change.
      
      Changes since v3:
       - Fix missing vsync interrupt for DP550
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      [rebased and fixed conflicts]
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      92060ad8
    • Brian Starkey's avatar
      drm: writeback: Add out-fences for writeback connectors · 5f367c6b
      Brian Starkey authored
      Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
      enable userspace to get a fence which will signal once the writeback is
      complete. It is not allowed to request an out-fence without a
      framebuffer attached to the connector.
      
      A timeline is added to drm_writeback_connector for use by the writeback
      out-fences.
      
      In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
      is set to -1.
      
      Changes from v2:
       - Rebase onto Gustavo Padovan's v9 explicit sync series
       - Change out_fence_ptr type to s32 __user *
       - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
       - Store fence in drm_writeback_job
       Gustavo Padovan:
       - Move out_fence_ptr out of connector_state
       - Signal fence from drm_writeback_signal_completion instead of
         in driver directly
      
      Changes from v3:
       - Rebase onto 7e9081c5 drm/fence: fix memory overwrite when setting out_fence fd
         (change out_fence_ptr to s32 __user *, for real this time.)
       - Update documentation around WRITEBACK_OUT_FENCE_PTR
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      [rebased and fixed conflicts]
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      5f367c6b
    • Brian Starkey's avatar
      drm: Add writeback connector type · e4c69224
      Brian Starkey authored
      Writeback connectors represent writeback engines which can write the
      CRTC output to a memory framebuffer. Add a writeback connector type and
      related support functions.
      
      Drivers should initialize a writeback connector with
      drm_writeback_connector_init() which takes care of setting up all the
      writeback-specific details on top of the normal functionality of
      drm_connector_init().
      
      Writeback connectors have a WRITEBACK_FB_ID property, used to set the
      output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
      supported writeback formats to userspace.
      
      When a framebuffer is attached to a writeback connector with the
      WRITEBACK_FB_ID property, it is used only once (for the commit in which
      it was included), and userspace can never read back the value of
      WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
      attached to a CRTC.
      
      Changes since v1:
       - Added drm_writeback.c + documentation
       - Added helper to initialize writeback connector in one go
       - Added core checks
       - Squashed into a single commit
       - Dropped the client cap
       - Writeback framebuffers are no longer persistent
      
      Changes since v2:
       Daniel Vetter:
       - Subclass drm_connector to drm_writeback_connector
       - Relax check to allow CRTC to be set without an FB
       - Add some writeback_ prefixes
       - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
       Gustavo Padovan:
       - Add drm_writeback_job to handle writeback signalling centrally
      
      Changes since v3:
       - Rebased
       - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      [rebased and fixed conflicts]
      Signed-off-by: default avatarMihail Atanassov <mihail.atanassov@arm.com>
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      e4c69224
    • Liviu Dudau's avatar
      drm/i2c: tda998x: Fix lockdep warning about possible circular dependency · 681b1933
      Liviu Dudau authored
      When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
      I get the following warning from the system:
      
      [   25.990733] ======================================================
      [   25.998637] WARNING: possible circular locking dependency detected
      [   26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
      [   26.014246] ------------------------------------------------------
      [   26.022142] kworker/1:2/140 is trying to acquire lock:
      [   26.029001]  (&priv->audio_mutex){+.+.+.}, at: [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
      [   26.041100]
      [   26.041100] but task is already holding lock:
      [   26.050436]  (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm]
      [   26.061531]
      [   26.061531] which lock already depends on the new lock.
      [   26.061531]
      [   26.075063]
      [   26.075063] the existing dependency chain (in reverse order) is:
      [   26.086031]
      [   26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
      [   26.095657]        __lock_acquire+0x18a0/0x19b8
      [   26.101918]        lock_acquire+0xd0/0x2b0
      [   26.107731]        __ww_mutex_lock.constprop.3+0x90/0xe78
      [   26.114817]        ww_mutex_lock+0x54/0xe0
      [   26.120672]        drm_modeset_lock+0x64/0xf8 [drm]
      [   26.127253]        drm_helper_probe_single_connector_modes+0x7c/0x6b8 [drm_kms_helper]
      [   26.136829]        tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
      [   26.144797]        drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
      [   26.152429]        drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
      [   26.161097]        drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
      [   26.169857]        drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
      [   26.177559]        hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
      [   26.184310]        try_to_bring_up_master+0x180/0x1e0
      [   26.191043]        component_master_add_with_match+0xb0/0x108
      [   26.198458]        hdlcd_probe+0x58/0x80 [hdlcd]
      [   26.204735]        platform_drv_probe+0x60/0xc0
      [   26.210913]        driver_probe_device+0x23c/0x2e8
      [   26.217350]        __driver_attach+0xd4/0xd8
      [   26.223256]        bus_for_each_dev+0x5c/0xa8
      [   26.229232]        driver_attach+0x30/0x40
      [   26.234917]        bus_add_driver+0x1d8/0x248
      [   26.240831]        driver_register+0x6c/0x118
      [   26.246715]        __platform_driver_register+0x54/0x60
      [   26.253461]        0xffff000000e1b018
      [   26.258644]        do_one_initcall+0x44/0x138
      [   26.264503]        do_init_module+0x64/0x1d4
      [   26.270238]        load_module+0x1f90/0x2590
      [   26.275957]        SyS_finit_module+0xb0/0xc8
      [   26.281765]        __sys_trace_return+0x0/0x4
      [   26.281767]
      [   26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
      [   26.281778]        __lock_acquire+0x18a0/0x19b8
      [   26.281782]        lock_acquire+0xd0/0x2b0
      [   26.281877]        drm_modeset_acquire_init+0xa8/0xe0 [drm]
      [   26.281921]        drm_helper_probe_single_connector_modes+0x48/0x6b8 [drm_kms_helper]
      [   26.281929]        tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
      [   26.281970]        drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
      [   26.282009]        drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
      [   26.282049]        drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
      [   26.282088]        drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
      [   26.282095]        hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
      [   26.282099]        try_to_bring_up_master+0x180/0x1e0
      [   26.282104]        component_master_add_with_match+0xb0/0x108
      [   26.282110]        hdlcd_probe+0x58/0x80 [hdlcd]
      [   26.282114]        platform_drv_probe+0x60/0xc0
      [   26.282117]        driver_probe_device+0x23c/0x2e8
      [   26.282121]        __driver_attach+0xd4/0xd8
      [   26.282124]        bus_for_each_dev+0x5c/0xa8
      [   26.282127]        driver_attach+0x30/0x40
      [   26.282130]        bus_add_driver+0x1d8/0x248
      [   26.282134]        driver_register+0x6c/0x118
      [   26.282138]        __platform_driver_register+0x54/0x60
      [   26.282141]        0xffff000000e1b018
      [   26.282145]        do_one_initcall+0x44/0x138
      [   26.282149]        do_init_module+0x64/0x1d4
      [   26.282152]        load_module+0x1f90/0x2590
      [   26.282156]        SyS_finit_module+0xb0/0xc8
      [   26.282159]        __sys_trace_return+0x0/0x4
      [   26.282161]
      [   26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
      [   26.282172]        print_circular_bug+0x80/0x2e0
      [   26.282176]        __lock_acquire+0x15a8/0x19b8
      [   26.282180]        lock_acquire+0xd0/0x2b0
      [   26.282184]        __mutex_lock+0x78/0x8e0
      [   26.282188]        mutex_lock_nested+0x3c/0x50
      [   26.282196]        tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
      [   26.282237]        drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper]
      [   26.282251]        malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
      [   26.282292]        commit_tail+0x4c/0x80 [drm_kms_helper]
      [   26.282333]        drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
      [   26.282427]        drm_atomic_commit+0x54/0x70 [drm]
      [   26.282467]        restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
      [   26.282507]        restore_fbdev_mode+0x38/0x188 [drm_kms_helper]
      [   26.282547]        drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper]
      [   26.282586]        drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper]
      [   26.282625]        drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper]
      [   26.282665]        drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper]
      [   26.282704]        drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper]
      [   26.282716]        malidp_output_poll_changed+0x24/0x30 [mali_dp]
      [   26.282757]        drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper]
      [   26.282797]        output_poll_execute+0x1a0/0x1f0 [drm_kms_helper]
      [   26.282803]        process_one_work+0x280/0x790
      [   26.282808]        worker_thread+0x48/0x450
      [   26.282812]        kthread+0x138/0x140
      [   26.282815]        ret_from_fork+0x10/0x40
      [   26.282817]
      [   26.282817] other info that might help us debug this:
      [   26.282817]
      [   26.282819] Chain exists of:
      [   26.282819]   &priv->audio_mutex --> crtc_ww_class_acquire --> crtc_ww_class_mutex
      [   26.282819]
      [   26.282830]  Possible unsafe locking scenario:
      [   26.282830]
      [   26.282832]        CPU0                    CPU1
      [   26.282834]        ----                    ----
      [   26.282835]   lock(crtc_ww_class_mutex);
      [   26.282840]                                lock(crtc_ww_class_acquire);
      [   26.282845]                                lock(crtc_ww_class_mutex);
      [   26.282850]   lock(&priv->audio_mutex);
      [   26.282854]
      [   26.282854]  *** DEADLOCK ***
      [   26.282854]
      [   26.282858] 5 locks held by kworker/1:2/140:
      [   26.282859]  #0:  ("events"){.+.+.+}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790
      [   26.282871]  #1:  ((&(&dev->mode_config.output_poll_work)->work)){+.+.+.}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790
      [   26.282883]  #2:  (&helper->lock){+.+.+.}, at: [<ffff000000c0631c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0xd0 [drm_kms_helper]
      [   26.282929]  #3:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffff000000c02d80>] restore_fbdev_mode_atomic+0x38/0x220 [drm_kms_helper]
      [   26.282976]  #4:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm]
      [   26.283077]
      [   26.283077] stack backtrace:
      [   26.283082] CPU: 1 PID: 140 Comm: kworker/1:2 Not tainted 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17
      [   26.283084] Hardware name: ARM Juno development board (r0) (DT)
      [   26.283127] Workqueue: events output_poll_execute [drm_kms_helper]
      [   26.283131] Call trace:
      [   26.283137] [<ffff00000808a778>] dump_backtrace+0x0/0x268
      [   26.283142] [<ffff00000808aabc>] show_stack+0x24/0x30
      [   26.283146] [<ffff000008aa36a8>] dump_stack+0xbc/0xf4
      [   26.283151] [<ffff00000812f454>] print_circular_bug+0x1d4/0x2e0
      [   26.283155] [<ffff000008132480>] __lock_acquire+0x15a8/0x19b8
      [   26.283159] [<ffff000008133008>] lock_acquire+0xd0/0x2b0
      [   26.283163] [<ffff000008aba060>] __mutex_lock+0x78/0x8e0
      [   26.283168] [<ffff000008aba904>] mutex_lock_nested+0x3c/0x50
      [   26.283176] [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
      [   26.283217] [<ffff000000c00050>] drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper]
      [   26.283230] [<ffff000000f1bd0c>] malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
      [   26.283271] [<ffff000000c0045c>] commit_tail+0x4c/0x80 [drm_kms_helper]
      [   26.283312] [<ffff000000c00630>] drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
      [   26.283406] [<ffff000000eb1604>] drm_atomic_commit+0x54/0x70 [drm]
      [   26.283447] [<ffff000000c02f38>] restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
      [   26.283487] [<ffff000000c03cf0>] restore_fbdev_mode+0x38/0x188 [drm_kms_helper]
      [   26.283526] [<ffff000000c06324>] drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper]
      [   26.283566] [<ffff000000c0619c>] drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper]
      [   26.283606] [<ffff000000c0627c>] drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper]
      [   26.283645] [<ffff000000c062c4>] drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper]
      [   26.283685] [<ffff000000c07124>] drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper]
      [   26.283697] [<ffff000000f1b44c>] malidp_output_poll_changed+0x24/0x30 [mali_dp]
      [   26.283738] [<ffff000000bf5264>] drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper]
      [   26.283779] [<ffff000000bf5480>] output_poll_execute+0x1a0/0x1f0 [drm_kms_helper]
      [   26.283784] [<ffff0000080f85a8>] process_one_work+0x280/0x790
      [   26.283788] [<ffff0000080f8b00>] worker_thread+0x48/0x450
      [   26.283792] [<ffff000008100430>] kthread+0x138/0x140
      [   26.283796] [<ffff000008083710>] ret_from_fork+0x10/0x40
      
      This looks like it has been introduced by 'commit 02efac0f ("drm/i2c:
      tda998x: remove complexity from tda998x_audio_get_eld()")'.
      
      Fix the warning by dropping the use of local audio_mutex and switch to
      taking the modeset connection_mutex in tda998x_audio_get_eld() for
      avoidance of race conditions with drm_helper_probe_single_connector_modes()
      updating the ELD data.
      
      v2: Change to taking the modeset connection_mutex rather than changing
      the time when audio_mutex lock was taken, as suggested by Russell King.
      v3: Drop the bespoke drm_modeset_acquire_ctx, it is not needed.
      (suggested by Daniel Vetter)
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <Liviu.Dudau@arm.com>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Fixes: 02efac0f ("drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld()")
      681b1933
    • Liviu Dudau's avatar
      iommu/ipmmu-vmsa: Simplify driver probing. · d6bb1f29
      Liviu Dudau authored
      The IPMMU driver still uses initcalls to do its initialisation, while
      other IOMMU drivers have moved to probe deferal mechanism. Update
      the IPMMU driver so that it can use modern driver probing which allows
      for it to be compiled together with other IOMMU drivers and not
      trying at boot time to replace bus masters for platforms that don't
      use IPMMU.
      Signed-off-by: Liviu Dudau's avatarLiviu Dudau <liviu.dudau@arm.com>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: Magnus Damm <damm+renesas@opensource.se>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      d6bb1f29
    • Stephen Rothwell's avatar
      c7434d8b
    • Stephen Rothwell's avatar
      Merge branch 'akpm/master' · b0916f8b
      Stephen Rothwell authored
      b0916f8b
    • Pavel Tatashin's avatar
      sparc64: NG4 memset 32 bits overflow · 3d16b357
      Pavel Tatashin authored
      Early in boot Linux patches memset and memcpy to branch to platform
      optimized versions of these routines.  The NG4 (Niagra 4) versions are
      currently used on all platforms starting from T4.  Recently, there were M7
      optimized routines added into UEK4 but not into mainline yet.  So, even
      with M7 optimized routines NG4 are still going to be used on T4, T5, M5,
      and M6 processors.
      
      While investigating how to improve initialization time of dentry_hashtable
      which is 8G long on M6 ldom with 7T of main memory, I noticed that
      memset() does not reset all the memory in this array, after studying the
      code, I realized that NG4memset() branches use %icc register instead of
      %xcc to check compare, so if value of length is over 32-bit long, which is
      true for 8G array, these routines fail to work properly.
      
      The fix is to replace all %icc with %xcc in these routines.  (Alternative
      is to use %ncc, but this is misleading, as the code already has sparcv9
      only instructions, and cannot be compiled on 32-bit).
      
      This is important to fix this bug, because even older T4-4 can have 2T of
      memory, and there are large memory proportional data structures in kernel
      which can be larger than 4G in size.  The failing of memset() is silent
      and corruption is hard to detect.
      
      Link: http://lkml.kernel.org/r/1488432825-92126-2-git-send-email-pasha.tatashin@oracle.comSigned-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Reviewed-by: default avatarBabu Moger <babu.moger@oracle.com>
      Cc: Babu Moger <babu.moger@amd.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      3d16b357
    • Andi Kleen's avatar
      drivers/media/platform/sti/delta/delta-ipc.c: fix read buffer overflow · 9740750a
      Andi Kleen authored
      The single caller passes a string to delta_ipc_open, which copies with a
      fixed size larger than the string.  So it copies some random data after
      the original string the ro segment.
      
      If the string was at the end of a page it may fault.
      
      Just copy the string with a normal strcpy after clearing the field.
      
      Found by a LTO build (which errors out)
      because the compiler inlines the functions and can resolve
      the string sizes and triggers the compile time checks in memcpy.
      
      In function `memcpy',
          inlined from `delta_ipc_open.constprop' at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0,
          inlined from `delta_mjpeg_ipc_open' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0,
          inlined from `delta_mjpeg_decode' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0:
      /home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to `__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
          __read_overflow2();
      
      Link: http://lkml.kernel.org/r/20171222001212.1850-1-andi@firstfloor.orgSigned-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Hugues FRUCHET <hugues.fruchet@st.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      9740750a
    • Dan Carpenter's avatar
      ipc/mqueue: add missing error code in init_mqueue_fs() · 8a39ae5a
      Dan Carpenter authored
      We should propogate the error code here but we accidentally return
      success.
      
      Link: http://lkml.kernel.org/r/20180109092919.ndrvscdllrmzz6jo@mwanda
      Fixes: 946086abeddf ("mqueue: switch to on-demand creation of internal mount")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      8a39ae5a
    • Stephen Rothwell's avatar
      Merge branch 'akpm-current/current' · 2b409c72
      Stephen Rothwell authored
      2b409c72
    • Stephen Rothwell's avatar
      237283a5