1. 21 8月, 2012 1 次提交
    • G
      gpu/mfd/usb: Fix USB randconfig problems · 8f057d7b
      Guenter Roeck 提交于
      Fix config warning:
      
      warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies
      (USB_SUPPORT && USB_ARCH_HAS_HCD)
      
      and build error:
      ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined!
      
      by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB.
      
      This exposes:
      drivers/video/Kconfig:36:error: recursive dependency detected!
      drivers/video/Kconfig:36:       symbol FB is selected by DRM_KMS_HELPER
      drivers/gpu/drm/Kconfig:28:     symbol DRM_KMS_HELPER is selected by DRM_UDL
      drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
      drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
      drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C
      drivers/i2c/Kconfig:5:  symbol I2C is selected by FB_DDC
      drivers/video/Kconfig:86:       symbol FB_DDC is selected by FB_CYBER2000_DDC
      drivers/video/Kconfig:385:      symbol FB_CYBER2000_DDC depends on FB_CYBER2000
      drivers/video/Kconfig:373:      symbol FB_CYBER2000 depends on FB
      
      which is due to drivers/usb/Kconfig:
      config USB_ARCH_HAS_OHCI
      	...
      	default y if ARCH_PNX4008 && I2C
      
      Fix by dropping I2C from the above dependency; logic is that this is not a
      platform dependency but a configuration dependency: the _architecture_ still
      supports USB even is I2C is not selected.
      
      This exposes:
      drivers/video/Kconfig:36:error: recursive dependency detected!
      drivers/video/Kconfig:36:       symbol FB is selected by DRM_KMS_HELPER
      drivers/gpu/drm/Kconfig:28:     symbol DRM_KMS_HELPER is selected by DRM_UDL
      drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
      drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
      drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB
      drivers/mfd/Kconfig:396:        symbol MFD_TC6393XB depends on GPIOLIB
      drivers/gpio/Kconfig:35:        symbol GPIOLIB is selected by FB_VIA
      drivers/video/Kconfig:1560:     symbol FB_VIA depends on FB
      
      which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on
      it.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f057d7b
  2. 27 7月, 2012 2 次提交
    • L
      mfd: Ensure AB8500 platform data is passed through db8500-prcmu to MFD Core · 3c1534c7
      Lee Jones 提交于
      When booting via platform code the AB8500 platform data is now passed
      in though the DB8500. However, if pdata_size is not set it will not be
      subsequently passed onto subordinate devices. This patch correctly
      populates pdata_size.
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      3c1534c7
    • S
      mfd: Arizone core should select MFD_CORE · c481c048
      Samuel Ortiz 提交于
      Otherwise, with:
      
      CONFIG_MFD_ARIZONA=y
      CONFIG_MFD_ARIZONA_I2C=m
      CONFIG_MFD_CORE=m
      
      We get:
      
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3ab0): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3fdc): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3fff): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x4059): undefined reference to `mfd_remove_devices'
      drivers/built-in.o: In function `arizona_dev_exit':
      (.devexit.text+0x9): undefined reference to `mfd_remove_devices'
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      c481c048
  3. 25 7月, 2012 8 次提交
  4. 23 7月, 2012 1 次提交
    • T
      pwm: Conflict with legacy PWM API · eac7a92f
      Thierry Reding 提交于
      In order to avoid duplicate symbols with legacy PWM API implementations,
      the new PWM framework needs to conflict with any of the existing legacy
      implementations. This is done in two ways: for implementations provided
      by drivers, a conflict is added to the driver to ensure it will have to
      be ported to the PWM subsystem before it can coexist with other PWM
      providers. For architecture-specific code, the conflict is added to the
      PWM symbol to avoid confusion when a previously picked platform or
      machine can no longer be selected because of the PWM subsystem being
      included.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      eac7a92f
  5. 19 7月, 2012 3 次提交
  6. 17 7月, 2012 1 次提交
  7. 16 7月, 2012 13 次提交
  8. 15 7月, 2012 1 次提交
  9. 14 7月, 2012 1 次提交
  10. 13 7月, 2012 1 次提交
  11. 10 7月, 2012 3 次提交
  12. 09 7月, 2012 5 次提交