1. 25 Mar, 2009 2 commits
  2. 12 Mar, 2009 3 commits
  3. 06 Mar, 2009 1 commit
  4. 05 Mar, 2009 4 commits
  5. 04 Mar, 2009 4 commits
  6. 03 Mar, 2009 3 commits
  7. 02 Mar, 2009 1 commit
  8. 27 Feb, 2009 4 commits
    • David Brownell's avatar
      usb: musb: make Davinci *work* in mainline · 34f32c97
      David Brownell authored
      Now that the musb build fixes for DaVinci got merged (RC3?), kick in
      the other bits needed to get it finally *working* in mainline:
       - Use clk_enable()/clk_disable() ... the "always enable USB clocks"
         code this originally relied on has since been removed.
       - Initialize the USB device only after the relevant I2C GPIOs are
         available, so the host side can properly enable VBUS.
       - Tweak init sequencing to cope with mainline's relatively late init
         of the I2C system bus for power switches, transceivers, and so on.
      Sanity tested on DM6664 EVM for host and peripheral modes; that system
      won't boot with CONFIG_PM enabled, so OTG can't yet be tested.  Also
      verified on OMAP3.
      (Unrelated:  correct the MODULE_PARM_DESC spelling of musb_debug.)
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Felipe Balbi <me@felipebalbi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Werner Almesberger's avatar
      [ARM] S3C64XX: Fix s3c64xx_setrate_clksrc · efeff568
      Werner Almesberger authored
      Some of the rate selection logic in s3c64xx_setrate_clksrc uses what
      appears to be parent clock selection logic. This patch corrects it.
      I also added a check for overly large dividers to prevent them from
      changing unrelated clocks.
      Signed-off-by: default avatarWerner Almesberger <werner@openmoko.org>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
    • Ben Dooks's avatar
      [ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/irq.c · fdca9bf2
      Ben Dooks authored
      Fix the following sparse warnings in arch/arm/plat-s3c64xx/irq.c
      arch/arm/plat-s3c64xx/irq.c:210:23: warning: incorrect type in initializer (different address spaces)
      arch/arm/plat-s3c64xx/irq.c:210:23:    expected void *reg_base
      arch/arm/plat-s3c64xx/irq.c:210:23:    got void [noderef] <asn:2>*regs
      arch/arm/plat-s3c64xx/irq.c:215:2: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/plat-s3c64xx/irq.c:215:2:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/plat-s3c64xx/irq.c:215:2:    got void *
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
    • Ben Dooks's avatar
      [ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/s3c6400-clock.c · 3782d360
      Ben Dooks authored
      Fix the following sparse warnings in s3c6400-clock.c:
      39:12: warning: symbol 'clk_ext_xtal_mux' was not declared. Should it be static?
      66:12: warning: symbol 'clk_fout_apll' was not declared. Should it be static?
      81:19: warning: symbol 'clk_mout_apll' was not declared. Should it be static?
      91:12: warning: symbol 'clk_fout_epll' was not declared. Should it be static?
      106:19: warning: symbol 'clk_mout_epll' was not declared. Should it be static?
      126:19: warning: symbol 'clk_mout_mpll' was not declared. Should it be static?
      148:12: warning: symbol 'clk_dout_mpll' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
  9. 26 Feb, 2009 9 commits
  10. 24 Feb, 2009 2 commits
  11. 22 Feb, 2009 1 commit
  12. 19 Feb, 2009 4 commits
  13. 17 Feb, 2009 1 commit
    • Nicolas Pitre's avatar
      [ARM] 5401/1: Orion: fix edge triggered GPIO interrupt support · fd4b9b36
      Nicolas Pitre authored
      The GPIO interrupts can be configured as either level triggered or edge
      triggered, with a default of level triggered.  When an edge triggered
      interrupt is requested, the gpio_irq_set_type method is called which
      currently switches the given IRQ descriptor between two struct irq_chip
      instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
      happens via __setup_irq() which also calls irq_chip_set_defaults() to
      assign default methods to uninitialized ones.  The problem is that
      irq_chip_set_defaults() is called before the irq_chip reference is
      switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
      case) with uninitialized methods such as chip->startup() causing a kernel
      Many solutions are possible, such as making irq_chip_set_defaults() global
      and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
      before irq_chip_set_defaults() in __setup_irq().  But those require
      modifications to the generic IRQ code which might have adverse effect on
      other architectures, and that would still be a fragile arrangement.
      Manually copying the missing methods from within gpio_irq_set_type()
      would be really ugly and it would break again the day new methods with
      automatic defaults are added.
      A better solution is to have a single irq_chip instance which can deal
      with both edge and level triggered interrupts.  It is also a good idea
      to switch the IRQ handler instead, as the edge IRQ handler allows for
      one edge IRQ event to be queued as the IRQ is actually masked only when
      that second IRQ is received, at which point the hardware can queue an
      additional IRQ event, making edge triggered interrupts a bit more
      Tested-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  14. 16 Feb, 2009 1 commit