1. 02 Dec, 2014 2 commits
  2. 01 Dec, 2014 2 commits
  3. 26 Nov, 2014 13 commits
  4. 25 Nov, 2014 13 commits
    • Philipp Zabel's avatar
      MAINTAINERS: add maintainer for i.MX DRM driver · 0a3d775f
      Philipp Zabel authored
      Add myself as the maintainer of the i.MX DRM driver.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0a3d775f
    • Philipp Zabel's avatar
      drm: imx: Move imx-drm driver out of staging · 6556f7f8
      Philipp Zabel authored
      The imx-drm driver was put into staging mostly for the following reasons,
      all of which have been addressed or superseded:
       - convert the irq driver to use linear irq domains
       - work out the device tree bindings, this lead to the common of_graph
         bindings being used
       - factor out common helper functions, this mostly resulted in the
         component framework and drm of_graph helpers.
      
      Before adding new fixes, and certainly before adding new features,
      move it into its proper place below drivers/gpu/drm.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6556f7f8
    • Laurent Pinchart's avatar
      Merge tag 'tags/renesas-dt-du-for-v3.19' into drm/next/adv7511-base · a218df07
      Laurent Pinchart authored
      Renesas ARM Based SoC DT DU Updates for v3.19
      
      * Enable DU using DT on marzen/r8a7779, lager/r8a7790 and koelsch/r8a7791
      a218df07
    • Dave Airlie's avatar
      Merge branch 'exynos-drm-next' of... · 0364d4fe
      Dave Airlie authored
      Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
      
        Add Exynos4415 SoC support, some fixups and cleanups.
      
         Summary:
         - Resolve kernel lockup issue incurred by probe request in probe context.
           . For this, it moves all register codes of sub drivers into init function
             and adds component binding support for vidi driver.
         - Add Exynos4415 SoC support.
         - Make each manager and display object to be embedded
           in each driver context.
         - Fix and clean up FIMD and MIPI-DSI drivers.
         - Clean up unnecesary or wrong descriptions.
         - And trivial cleanups.
      
      * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (58 commits)
        drm/exynos: avoid leak if exynos_dpi_probe() fails
        drm/exynos: Fix exynos_dpi_remove() parameter
        drm/exynos: vidi: add component support
        drm/exynos: fix exynos_drm_component_del
        drm/exynos/ipp: fix error return code
        drm/exynos: clean up machine compatible string check
        drm/exynos: move Exynos platform drivers registration to init
        Revert "drm/exynos: fix null pointer dereference issue"
        drm/exynos/dpi: stop using display->ctx pointer
        drm/exynos/dpi: embed display into private context
        drm/exynos/dp: stop using display->ctx pointer
        drm/exynos/dp: embed display into private context
        drm/exynos/vidi: stop using display->ctx pointer
        drm/exynos/vidi: embed display into private context
        drm/exynos/hdmi: stop using display->ctx pointer
        drm/exynos/hdmi: embed display into private context
        drm/exynos/fimd: stop using manager->ctx pointer
        drm/exynos/fimd: embed manager into private context
        drm/exynos/vidi: stop using manager->ctx pointer
        drm/exynos/vidi: embed manager into private context
        ...
      0364d4fe
    • Dan Carpenter's avatar
      amdkfd: delete some dead code · 9cf4a281
      Dan Carpenter authored
      This is dead code.  We don't need to unbind here, we can just return
      directly.
      Reviewed-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      9cf4a281
    • Oded Gabbay's avatar
      amdkfd: Fix memory leak of mqds on dqm fini · 6f9d54fd
      Oded Gabbay authored
      The mqds array members are not freed when dqm is uninitialized.
      Reviewed-by: default avatarBen Goz <Ben.Goz@amd.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      6f9d54fd
    • Dave Airlie's avatar
      Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next · 955289c7
      Dave Airlie authored
      Now that we have the bits needed for mdp5 atomic, here is the followup
      pull request I mentioned.  Main highlights are:
      
      1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
      2) mdp5 atomic conversion
      3) couple atomic helper fixes for issues found during mdp5 atomic
      debug (reviewed by danvet.. but he didn't plane to send an
      atomic-fixes pull request so I agreed to tack them on to mine)
      
      * 'msm-next' of git://people.freedesktop.org/~robclark/linux:
        drm/atomic: shutdown *current* encoder
        drm/atomic: check mode_changed *after* atomic_check
        drm/msm/mdp4: fix mixer setup for multi-crtc + planes
        drm/msm/mdp5: dpms(OFF) cleanups
        drm/msm/mdp5: atomic
        drm/msm: atomic fixes
        drm/msm/mdp5: remove global mdp5_ctl_mgr
        drm/msm/mdp5: don't use void * for opaque types
        drm/msm: add multiple CRTC and overlay support
        drm/msm/mdp5: set rate before enabling clk
        drm/msm/mdp5: introduce mdp5_cfg module
        drm/msm/mdp5: make SMP module dynamically configurable
        drm/msm/hdmi: remove useless kref
        drm/msm/mdp5: get the core clock rate from MDP5 config
        drm/msm/mdp5: use irqdomains
      955289c7
    • Dan Carpenter's avatar
      amdkfd: fix an error handling bug in pqm_create_queue() · e048a0b2
      Dan Carpenter authored
      The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
      error code is incorrect.
      
      Fixes: 45102048 ('amdkfd: Add process queue manager module')
      Reviewed-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      e048a0b2
    • Dan Carpenter's avatar
      amdkfd: fix some error handling in ioctl · 66333cb3
      Dan Carpenter authored
      There is a typo here so the errors from kfd_bind_process_to_device()
      are not detected.
      Reviewed-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      66333cb3
    • Gustavo Padovan's avatar
      drm/exynos: avoid leak if exynos_dpi_probe() fails · 5baf5d44
      Gustavo Padovan authored
      The component must be deleted if the probe fails.
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      5baf5d44
    • Gustavo Padovan's avatar
      drm/exynos: Fix exynos_dpi_remove() parameter · 1c9ff4ab
      Gustavo Padovan authored
      exynos_dpi_remove() should receive a exynos_drm_display but when
      DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
      ia compiler warning.
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      1c9ff4ab
    • Inki Dae's avatar
      drm/exynos: vidi: add component support · 1d50aa9c
      Inki Dae authored
      This patch adds component support for vidi driver.
      
      vidi driver is a kms driver so it doesn't need to be registered
      to exynos_drm_subdrv_list. For this, it changes for the component
      framework to be used for vidi driver.
      
      This patch fixes below error also,
      
      # echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
      [   55.618529] ------------[ cut here ]------------
      [   55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203 exynos_drm_crtc_dpms+0x88/0x17c()
      [   55.631268] Modules linked in:
      [   55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7 #1154
      [   55.641885] [<c0014400>] (unwind_backtrace) from [<c0011570>] (show_stack+0x10/0x14)
      [   55.649597] [<c0011570>] (show_stack) from [<c04764f4>] (dump_stack+0x84/0xc4)
      [   55.656802] [<c04764f4>] (dump_stack) from [<c00218b8>] (warn_slowpath_common+0x6c/0x88)
      [   55.664866] [<c00218b8>] (warn_slowpath_common) from [<c0021970>] (warn_slowpath_null+0x1c/0x24)
      [   55.673632] [<c0021970>] (warn_slowpath_null) from [<c027a780>] (exynos_drm_crtc_dpms+0x88/0x17c)
      [   55.682482] [<c027a780>] (exynos_drm_crtc_dpms) from [<c027a910>] (exynos_drm_crtc_commit+0x14/0x44)
      [   55.691622] [<c027a910>] (exynos_drm_crtc_commit) from [<c025521c>] (drm_crtc_helper_set_mode+0x3d0/0x51c)
      [   55.701233] [<c025521c>] (drm_crtc_helper_set_mode) from [<c0255d68>] (drm_crtc_helper_set_config+0x87c/0x9dc)
      [   55.711230] [<c0255d68>] (drm_crtc_helper_set_config) from [<c026afa8>] (drm_mode_set_config_internal+0x58/0xd4)
      [   55.721380] [<c026afa8>] (drm_mode_set_config_internal) from [<c025c208>] (restore_fbdev_mode+0xcc/0xec)
      [   55.730834] [<c025c208>] (restore_fbdev_mode) from [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
      [   55.741424] [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c025e0a8>] (drm_fb_helper_set_par+0x1c/0x60)
      [   55.752271] [<c025e0a8>] (drm_fb_helper_set_par) from [<c025e174>] (drm_fb_helper_hotplug_event+0x88/0xc4)
      [   55.761906] [<c025e174>] (drm_fb_helper_hotplug_event) from [<c02571c4>] (drm_helper_hpd_irq_event+0xc8/0x134)
      [   55.771898] [<c02571c4>] (drm_helper_hpd_irq_event) from [<c028e27c>] (vidi_store_connection+0x90/0xc8)
      [   55.781268] [<c028e27c>] (vidi_store_connection) from [<c0125f80>] (kernfs_fop_write+0xc0/0x180)
      [   55.790045] [<c0125f80>] (kernfs_fop_write) from [<c00cdf60>] (vfs_write+0xa0/0x1ac)
      [   55.797757] [<c00cdf60>] (vfs_write) from [<c00ce468>] (SyS_write+0x44/0x9c)
      [   55.804790] [<c00ce468>] (SyS_write) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
      [   55.812328] ---[ end trace 3c0fe4386702d4dd ]---
      
      This issue occurs when modeset to vidi is tried in case that drm_vblank_init
      is called prior to crtc creation of vidi driver. In this case, crtc number
      of vidi is invalid so any requests with the crtc number will fail.
      This patch guarantees drm_vblank_init to be called after all kms drivers
      are ready by using component framework.
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      1d50aa9c
    • Inki Dae's avatar
      drm/exynos: fix exynos_drm_component_del · 33e2192f
      Inki Dae authored
      This patch resolves the issue that component object isn't removed
      correctly.
      
      A given component object couldn't be placed to head of drm_component_list
      so all component objects added to the drm_component_list should be checked
      to remove the given component object.
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      33e2192f
  5. 24 Nov, 2014 10 commits
    • Julia Lawall's avatar
      drm/exynos/ipp: fix error return code · be19d933
      Julia Lawall authored
      Propagate the returned error code on failure.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      identifier ret; expression e1,e2;
      @@
      (
      if (\(ret < 0\|ret != 0\))
       { ... return ret; }
      |
      ret = 0
      )
      ... when != ret = e1
          when != &ret
      *if(...)
      {
        ... when != ret = e2
            when forall
       return ret;
      }
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      be19d933
    • Inki Dae's avatar
      drm/exynos: clean up machine compatible string check · 4846e452
      Inki Dae authored
      Use 'for' statemant instead of hard-coded 'if' statement.
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      4846e452
    • Gustavo Padovan's avatar
      drm/exynos: move Exynos platform drivers registration to init · 820687be
      Gustavo Padovan authored
      Registering the Exynos DRM subdevices platform drivers in the probe
      function is causing an infinite loop. Fix this by moving it to the
      exynos_drm_init() function to register the drivers on module init.
      
      Registering drivers in the probe functions causes a deadlock in the parent
      device lock. See Grant Likely explanation on the topic:
      
      "I think the problem is that exynos_drm_init() is registering a normal
      (non-OF) platform device, so the parent will be /sys/devices/platform.
      It immediately gets bound against exynos_drm_platform_driver which
      calls the exynos drm_platform_probe() hook. The driver core obtains
      device_lock() on the device *and on the device parent*.
      
      Inside the probe hook, additional platform_drivers get registered.
      Each time one does, it tries to bind against every platform device in
      the system, which includes the ones created by OF. When it attempts to
      bind, it obtains device_lock() on the device *and on the device
      parent*.
      
      Before the change to move of-generated platform devices into
      /sys/devices/platform, the devices had different parents. Now both
      devices have /sys/devices/platform as the parent, so yes they are
      going to deadlock.
      
      The real problem is registering drivers from within a probe hook. That
      is completely wrong for the above deadlock reason. __driver_attach()
      will deadlock. Those registrations must be pulled out of .probe().
      
      Registering devices in .probe() is okay because __device_attach()
      doesn't try to obtain device_lock() on the parent."
      
       INFO: task swapper/0:1 blocked for more than 120 seconds.
             Not tainted 3.18.0-rc3-next-20141105 #794
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       swapper/0       D c052534c     0     1      0 0x00000000
       [<c052534c>] (__schedule) from [<c0525b34>] (schedule_preempt_disabled+0x14/0x20)
       [<c0525b34>] (schedule_preempt_disabled) from [<c0526d44>] (mutex_lock_nested+0x1c4/0x464
      
       [<c0526d44>] (mutex_lock_nested) from [<c02be908>] (__driver_attach+0x48/0x98)
       [<c02be908>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
       [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
       [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
       [<c02bef94>] (driver_register) from [<c029e99c>] (exynos_drm_platform_probe+0x34/0x234)
       [<c029e99c>] (exynos_drm_platform_probe) from [<c02bfcf0>] (platform_drv_probe+0x48/0xa4)
       [<c02bfcf0>] (platform_drv_probe) from [<c02be680>] (driver_probe_device+0x13c/0x37c)
       [<c02be680>] (driver_probe_device) from [<c02be954>] (__driver_attach+0x94/0x98)
       [<c02be954>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
       [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
       [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
       [<c02bef94>] (driver_register) from [<c029e938>] (exynos_drm_init+0x70/0xa0)
       [<c029e938>] (exynos_drm_init) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
       [<c00089b0>] (do_one_initcall) from [<c074bd90>] (kernel_init_freeable+0x10c/0x1d8)
       [<c074bd90>] (kernel_init_freeable) from [<c051eabc>] (kernel_init+0x8/0xec)
       [<c051eabc>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
       3 locks held by swapper/0/1:
        #0:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
        #1:  (&dev->mutex){......}, at: [<c02be918>] __driver_attach+0x58/0x98
        #2:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
      
      Changelog v2:
      - call platform_driver_register after all kms and non kms drivers are
        registered
      - rebased it to exynos-drm-next
      Signed-off-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      820687be
    • Gustavo Padovan's avatar
      Revert "drm/exynos: fix null pointer dereference issue" · b6713957
      Gustavo Padovan authored
      This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.
      
      Moving subdriver probe to exynos_drm_platform_probe() was making
      exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
      yet. It only gets set in exynos_drm_load.
      
      We need to find a smarter way to fix this issue.
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      b6713957
    • Andrzej Hajda's avatar
      drm/exynos/dpi: stop using display->ctx pointer · 5af3d9bb
      Andrzej Hajda authored
      The patch replaces accesses to display->ctx pointer by container_of
      construct. The field is removed as well as dpi was the last user of it.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      5af3d9bb
    • Andrzej Hajda's avatar
      drm/exynos/dpi: embed display into private context · 4cfde1f2
      Andrzej Hajda authored
      exynos_drm_display is used by internal Exynos DRM framework for
      representing encoder:connector pair. As it should be mapped 1:1 to dpi
      private context it seems more reasonable to embed it directly in that context.
      As a result further code simplification will be possible.
      Moreover it will be possible to handle multiple dpi devices in the system.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      4cfde1f2
    • Andrzej Hajda's avatar
      drm/exynos/dp: stop using display->ctx pointer · 63b3be32
      Andrzej Hajda authored
      The patch replaces accesses to display->ctx pointer by container_of
      construct. It will allow to remove ctx field in the future.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      63b3be32
    • Andrzej Hajda's avatar
      drm/exynos/dp: embed display into private context · 1df6e5fb
      Andrzej Hajda authored
      exynos_drm_display is used by internal Exynos DRM framework for
      representing encoder:connector pair. As it should be mapped 1:1 to dp
      private context it seems more reasonable to embed it directly in that context.
      As a result further code simplification will be possible.
      Moreover it will be possible to handle multiple dp devices in the system.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      1df6e5fb
    • Andrzej Hajda's avatar
      drm/exynos/vidi: stop using display->ctx pointer · 2f26bd72
      Andrzej Hajda authored
      The patch replaces accesses to display->ctx pointer by container_of
      construct. It will allow to remove ctx field in the future.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      2f26bd72
    • Andrzej Hajda's avatar
      drm/exynos/vidi: embed display into private context · 7340426a
      Andrzej Hajda authored
      exynos_drm_display is used by internal Exynos DRM framework for
      representing encoder:connector pair. As it should be mapped 1:1 to vidi
      private context it seems more reasonable to embed it directly in that context.
      As a result further code simplification will be possible.
      Moreover it will be possible to handle multiple vidi devices in the system.
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      7340426a