1. 31 8月, 2015 2 次提交
  2. 30 8月, 2015 3 次提交
  3. 16 8月, 2015 4 次提交
  4. 22 6月, 2015 1 次提交
  5. 19 6月, 2015 4 次提交
  6. 13 4月, 2015 2 次提交
  7. 11 2月, 2015 1 次提交
  8. 12 1月, 2015 1 次提交
  9. 25 11月, 2014 1 次提交
    • I
      drm/exynos: fix exynos_drm_component_del · 33e2192f
      Inki Dae 提交于
      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: NInki Dae <inki.dae@samsung.com>
      33e2192f
  10. 24 11月, 2014 9 次提交
    • I
      drm/exynos: clean up machine compatible string check · 4846e452
      Inki Dae 提交于
      Use 'for' statemant instead of hard-coded 'if' statement.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      4846e452
    • G
      drm/exynos: move Exynos platform drivers registration to init · 820687be
      Gustavo Padovan 提交于
      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: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      820687be
    • G
      Revert "drm/exynos: fix null pointer dereference issue" · b6713957
      Gustavo Padovan 提交于
      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: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      b6713957
    • K
      drm/exynos: Fix DSI resuming fail because power domain being off · 030794a3
      Krzysztof Kozlowski 提交于
      During system resume from suspend to RAM the Exynos DRM driver forced
      CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming
      of DSI which failed because whole LCD power domain was off and it was
      not allowed to turn on because of system resume in progress.
      
      Forcing mode should not be needed and removing it solves this particular
      problem.
      
      This necessary fix for following scenario reproduced on Exynos DRM:
      1. Power domain is off before suspending the system.
      2. System is suspended to RAM.
      3. Resuming starts. The Exynos DRM driver resume callback is called.
      4. The Exynos DRM driver calls drm_helper_resume_force_mode() which turns
         on the screen by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
      5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
         resumes and this should turn LCD power domain on.
      6. Unfortunately the domain cannot be turned on because system resume is
         in progress and genpd->prepared_count is positive.
      
      Steps to reproduce:
      1. Add runtime PM to Exynos DSI driver.
      2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
      3. Enable the connector and screen (e.g. with modeset-vsync).
      4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
      5. echo mem > /sys/power/state
      6. Resume.
      [   77.712469] PM: early resume of devices complete after 3.854 msecs
      [   77.712739] exynos-dsi 11c80000.dsi: pm_genpd_resume()
      [   77.712758] exynos4-fimc 11800000.fimc: pm_genpd_resume()
      [   77.712774] exynos4-fimc 11810000.fimc: pm_genpd_resume()
      [   77.712787] exynos-drm-fimc 11820000.fimc: pm_genpd_resume()
      [   77.712802] exynos-drm-fimc 11830000.fimc: pm_genpd_resume()
      [   77.712815] s5p-mipi-csis 11880000.csis: pm_genpd_resume()
      [   77.712829] s5p-mipi-csis 11890000.csis: pm_genpd_resume()
      [   77.712843] exynos-fimc-lite 12390000.fimc-lite: pm_genpd_resume()
      [   77.712856] exynos-fimc-lite 123a0000.fimc-lite: pm_genpd_resume()
      [   77.713788] exynos4-fb 11c00000.fimd: pm_genpd_resume()
      [   77.713912] wake disabled for irq 184
      [   77.713923] wake disabled for irq 185
      [   77.714082] wake disabled for irq 173
      [   77.715676] wake disabled for irq 176
      [   77.718540] exynos4-fb 11c00000.fimd: pm_genpd_runtime_resume()
      [   77.718567] exynos4-fb 11c00000.fimd: state restore latency exceeded, new value 1708 ns
      [   77.718636] exynos-dsi 11c80000.dsi: pm_genpd_runtime_resume()
      [   77.892366] exynos-dsi 11c80000.dsi: PLL failed to stabilize
      [   77.892377] exynos-dsi 11c80000.dsi: failed to configure DSI PLL
      [   78.192168] exynos-dsi 11c80000.dsi: timeout waiting for reset
      [   78.211578] exynos-dsi 11c80000.dsi: waiting for bus lanes timed out
      [   78.307173] exynos-dsi 11c80000.dsi: xfer timed out: d1 00 (null)
      [   78.307190] panel_s6e8aa0 11c80000.dsi.0: error -110 reading dcs seq(0xd1)
      [   78.307199] panel_s6e8aa0 11c80000.dsi.0: read id failed
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      030794a3
    • A
      drm/exynos: remove ifdeferry from initialization code · 72390677
      Andrzej Hajda 提交于
      The patch replaces separate calls to driver (de)registration by
      loops over the array of drivers. As a result it significantly
      decreases number of ifdefs. Additionally it moves device registration
      related ifdefs to header file.
      
      Changelog v2:
      - Rebased.
      - Consider non kms driver in respect to infinite loop issue.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      72390677
    • I
      drm/exynos: fix null pointer dereference issue · 421ee18d
      Inki Dae 提交于
      This patch fixes null pointer dereference issue incurred
      when ipp driver is enabled and Exynos drm driver is closed.
      
      Non kms driver should register its own sub driver to setup necessary
      resources, which is done by load(). So null pointer dereference
      occurs when ipp driver is enabled and Exynos drm driver is closed
      because ipp core device is registered after component_master_add_with_match
      call.
      
      This patch makes exynos_drm_device_subdrv_probe() to be called after all non
      kms drivers are registered.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      421ee18d
    • I
      drm/exynos: fix possible infinite loop issue · e9fbdcb4
      Inki Dae 提交于
      This patch fixes possible infinite loop issue by postponing
      registration to non kms drivers after component_master_add_with_match
      call, which can be incurred in all cases that non kms driver is probed
      and then component bind is failed
      
      This patch should be applied on top of below patches,
      	http://comments.gmane.org/gmane.comp.video.dri.devel/117740
      	http://www.spinics.net/lists/linux-samsung-soc/msg38624.htmlSigned-off-by: NInki Dae <inki.dae@samsung.com>
      e9fbdcb4
    • I
      drm/exynos: resolve infinite loop issue on non multi-platform · fbdf093d
      Inki Dae 提交于
      This patch resovles the infinite loop issue incurred
      when Exyno drm driver is enabled but all kms drivers
      are disabled on Exynos board by returning -EPROBE_DEFER
      only in case that there is kms device registered.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      fbdf093d
    • I
      drm/exynos: resolve infinite loop issue on multi-platform · 5cbb37df
      Inki Dae 提交于
      This patch resolves temporarily infinite loop issue incurred
      when Exynos drm driver is enabled and multi-platform kernel
      is used by registering Exynos drm device object only in case
      of Exynos SoC. So this patch will be replaced with more generic
      way later.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      5cbb37df
  11. 10 11月, 2014 3 次提交
  12. 03 11月, 2014 4 次提交
  13. 20 10月, 2014 1 次提交
  14. 20 9月, 2014 3 次提交
    • A
      drm/exynos: switch to universal plane API · 72ed6ccd
      Andrzej Hajda 提交于
      The patch replaces legacy functions
      drm_plane_init() / drm_crtc_init() with
      drm_universal_plane_init() and drm_crtc_init_with_planes().
      It allows to replace fake primary plane with the real one.
      Additionally the patch leaves cleanup of crtcs to core,
      this way planes and crtcs are cleaned in correct order.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      72ed6ccd
    • I
      drm/exynos: use drm generic mmap interface · 832316c7
      Inki Dae 提交于
      This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
      to Exynos drm and instead uses drm generic mmap.
      
      We had used the interface specific to Exynos drm to do mmap directly,
      not to use demand paging which maps each page with physical memory
      at page fault handler. We don't need the specific mmap interface
      because the drm generic mmap which uses vm offset manager stuff can
      also do mmap directly.
      
      This patch makes a userspace region to be mapped with whole physical
      memory region allocated by userspace request when mmap system call is
      requested.
      
      Changelog v2:
      - do not set VM_IO, VM_DONTEXPEND and VM_DONTDUMP. These flags were already
        set by drm_gem_mmap
      - do not include <linux/anon_inodes.h>, which isn't needed anymore.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      832316c7
    • I
      drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl · d931589c
      Inki Dae 提交于
      This interface and relevant codes aren't used anymore.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      d931589c
  15. 19 9月, 2014 1 次提交