1. 29 Oct, 2018 1 commit
  2. 03 Oct, 2018 1 commit
  3. 14 Mar, 2018 1 commit
    • Arnd Bergmann's avatar
      drm/panel: rm68200: Add backlight dependency · a8efe516
      Arnd Bergmann authored
      Like many other panel drivers, this one fails to build when backlight
      support is disabled:
      
      drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
      panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight'
      
      This adds the appropriate dependency.
      
      Note that while include/linux/backlight.h provides a stub inline when
      backlight support is not enabled, this isn't enough to deal with the
      case where backlight support is built as a module but the panel driver
      is built-in, in which case linking will still fail as above.
      
      One way to avoid this is to add a dependency such as this:
      
              depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
      
      but that is rather complex and misses the point that the panel support
      is mostly useless without backlight support.
      
      Fixes: 2b7ed18b ("drm/panel: Add support for Raydium RM68200 panel driver")
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      [treding@nvidia.com: clarify the need for the dependency]
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313210015.3344380-1-arnd@arndb.de
      a8efe516
  4. 12 Mar, 2018 1 commit
  5. 07 Feb, 2018 1 commit
  6. 22 Dec, 2017 1 commit
  7. 06 Oct, 2017 1 commit
  8. 18 Aug, 2017 3 commits
  9. 14 Jun, 2017 3 commits
  10. 06 Apr, 2017 2 commits
  11. 04 Apr, 2017 1 commit
  12. 16 Sep, 2016 1 commit
  13. 24 Nov, 2015 1 commit
  14. 23 Nov, 2015 1 commit
  15. 14 Aug, 2015 1 commit
  16. 13 Aug, 2015 1 commit
  17. 02 Apr, 2015 1 commit
  18. 31 Jan, 2015 2 commits
  19. 13 Nov, 2014 1 commit
  20. 14 Jul, 2014 2 commits
    • Russell King's avatar
      drm/panel: make DRM_PANEL_LD9040 depend on SPI · 50d5ed39
      Russell King authored
      Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
      increase in the probability of Kconf reporting circular dependencies
      (we're one "select" away from that right now), make this depend on
      SPI instead.  This is akin to having some driver select DRM.
      
      Having some drivers depend on a subsystem, and other drivers select a
      subsystem is a recipe for circular dependencies, and there's really no
      need for it.
      
      The potential circular dependency (which can be caused today by the
      addition of selecting DRM_PANEL from DRM_IMX_LDB) is:
      
        symbol DMADEVICES is selected by SAMSUNG_DMADEV
        symbol SAMSUNG_DMADEV is selected by S3C64XX_PL080
        symbol S3C64XX_PL080 is selected by SPI_S3C64XX
        symbol SPI_S3C64XX depends on SPI
        symbol SPI is selected by DRM_PANEL_LD9040
        symbol DRM_PANEL_LD9040 depends on DRM_PANEL
        symbol DRM_PANEL is selected by DRM_IMX_LDB
        symbol DRM_IMX_LDB depends on MFD_SYSCON
        symbol MFD_SYSCON is selected by POWER_RESET_KEYSTONE
        symbol POWER_RESET_KEYSTONE depends on POWER_SUPPLY
        symbol POWER_SUPPLY is selected by HID_SONY
        symbol HID_SONY depends on NEW_LEDS
        symbol NEW_LEDS is selected by BACKLIGHT_ADP8860
        symbol BACKLIGHT_ADP8860 depends on BACKLIGHT_CLASS_DEVICE
        symbol BACKLIGHT_CLASS_DEVICE is selected by FB_MX3
        symbol FB_MX3 depends on MX3_IPU
        symbol MX3_IPU depends on DMADEVICES
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      50d5ed39
    • Russell King's avatar
      drm/panel: consolidate unnecessary explicit dependencies · 937ca284
      Russell King authored
      DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
      DRM_PANEL && DRM, whereas DRM_PANEL_SIMPLE relies upon the dependency
      on the menu.
      
      We do not need to use explicit dependencies if we make the menu depend
      on DRM_PANEL && DRM - this will implicitly make each entry in the menu
      depend on DRM_PANEL && DRM without this needing to be explicitly stated
      against every entry.
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      937ca284
  21. 04 Apr, 2014 2 commits
  22. 17 Dec, 2013 2 commits
    • Thierry Reding's avatar
      drm/panel: Add simple panel support · 280921de
      Thierry Reding authored
      Add a driver for simple panels. Such panels can have a regulator that
      provides the supply voltage and a separate GPIO to enable the panel.
      Optionally the panels can have a backlight associated with them so it
      can be enabled or disabled according to the panel's power management
      mode.
      
      Support is added for two panels: An AU Optronics 10.1" WSVGA and a
      Chunghwa Picture Tubes 10.1" WXGA panel.
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      280921de
    • Thierry Reding's avatar
      drm: Add panel support · aead40ea
      Thierry Reding authored
      Add a very simple framework to register and lookup panels. Panel drivers
      can initialize a DRM panel and register it with the framework, allowing
      them to be retrieved and used by display drivers. Currently only support
      for DPMS and obtaining panel modes is provided. However it should be
      sufficient to enable a large number of panels. The framework should also
      be easily extensible to support more sophisticated kinds of panels such
      as DSI.
      
      The framework hasn't been tied into the DRM core, even though it should
      be easily possible to do so if that's what we want. In the current
      implementation, display drivers can simple make use of it to retrieve a
      panel, obtain its modes and control its DPMS mode.
      
      Note that this is currently only tested on systems that boot from a
      device tree. No glue code has been written yet for systems that use
      platform data, but it should be easy to add.
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      aead40ea