1. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      ARM: drivers: remove __dev* attributes. · 351a102d
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      and __devexit from these drivers.
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 09 Nov, 2012 2 commits
    • Afzal Mohammed's avatar
      ARM: OMAP2+: gpmc: generic timing calculation · 246da26d
      Afzal Mohammed authored
      Presently there are three peripherals that gets it timing
      by runtime calculation. Those peripherals can work with
      frequency scaling that affects gpmc clock. But timing
      calculation for them are in different ways.
      Here a generic runtime calculation method is proposed. Input
      to this function were selected so that they represent timing
      variables that are present in peripheral datasheets. Motive
      behind this was to achieve DT bindings for the inputs as is.
      Even though a few of the tusb6010 timings could not be made
      directly related to timings normally found on peripherals,
      expressions used were translated to those that could be
      There are possibilities of improving the calculations, like
      calculating timing for read & write operations in a more
      similar way. Expressions derived here were tested for async
      onenand on omap3evm (as vanilla Kernel does not have omap3evm
      onenand support, local patch was used). Other peripherals,
      tusb6010, smc91x calculations were validated by simulating
      on omap3evm.
      Regarding "we_on" for onenand async, it was found that even
      for muxed address/data, it need not be greater than
      "adv_wr_off", but rather could be derived from write setup
      time for peripheral from start of access time, hence would
      more be in line with peripheral timings. With this method
      it was working fine. If it is required in some cases to
      have "we_on" same as "wr_data_mux_bus" (i.e. greater than
      "adv_wr_off"), another variable could be added to indicate
      it. But such a requirement is not expected though.
      It has been observed that "adv_rd_off" & "adv_wr_off" are
      currently calculated by adding an offset over "oe_on" and
      "we_on" respectively in the case of smc91x. But peripheral
      datasheet does not specify so and so "adv_rd(wr)_off" has
      been derived (to be specific, made ignorant of "oe_on" and
      "we_on") observing datasheet rather than adding an offset.
      Hence this generic routine is expected to work for smc91x
      (91C96 RX51 board). This was verified on smsc911x (9220 on
      OMAP3EVM) - a similar ethernet controller.
      Timings are calculated in ps to prevent rounding errors and
      converted to ns at final stage so that these values can be
      directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
      would be modified to take ps once all custom timing routines
      are replaced by the generic routine, at the same time
      generic timing routine would be modified to provide timings
      in ps. struct gpmc_timings field types are upgraded from
      u16 => u32 so that it can hold ps values.
      Whole of this exercise is being done to achieve driver and
      DT conversion. If timings could not be calculated in a
      peripheral agnostic way, either gpmc driver would have to
      be peripheral gnostic or a wrapper arrangement over gpmc
      driver would be required.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
    • Afzal Mohammed's avatar
      ARM: OMAP2+: gpmc: handle additional timings · 559d94b0
      Afzal Mohammed authored
      Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
      clkactivationtime in gpmc_cs_set_timings(). This is done so
      that boards can configure these parameters of gpmc in Kernel
      instead of relying on bootloader. Also configure bool type
      timings like extradelay.
      This needed change to the existing users that were configuring
      clk activation time and extra delay by directly writing to
      registers. Thanks to Tony for making me aware of users of clk
      activation and being kind enough to test the modified one.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
  3. 18 Oct, 2012 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2 · e4c060db
      Tony Lindgren authored
      We want to remove plat/cpu.h. To do this, let's first split
      it to private soc.h to mach-omap1 and mach-omap2. We have to
      keep plat/cpu.h around until the remaining drivers are fixed,
      so let's include the local soc.h in plat/cpu.h and for drivers
      still including plat/cpu.h.
      Once the drivers are fixed not to include plat/cpu.h, we
      can remove the file.
      This is needed for the ARM common zImage support.
      [tony@atomide.com: updated to not print a warning]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  4. 17 Oct, 2012 3 commits
  5. 15 Oct, 2012 5 commits
  6. 08 Oct, 2012 1 commit
  7. 23 Sep, 2012 2 commits
  8. 22 Sep, 2012 1 commit
    • Rajendra Nayak's avatar
      ARM: omap: clk: add clk_prepare and clk_unprepare · 4d7cb45e
      Rajendra Nayak authored
      As part of Common Clk Framework (CCF) the clk_enable() operation
      was split into a clk_prepare() which could sleep, and a clk_enable()
      which should never sleep. Similarly the clk_disable() was
      split into clk_disable() and clk_unprepare(). This was
      needed to handle complex cases where in a clk gate/ungate
      would require a slow and a fast part to be implemented.
      None of the clocks below seem to be in the 'complex' clocks
      category and are just simple clocks which are enabled/disabled
      through simple register writes.
      Most of the instances also seem to be called in non-atomic
      context which means its safe to move all of those from
      using a clk_enable() to clk_prepare_enable() and clk_disable() to
      For some others, mainly the ones handled through the hwmod framework
      there is a possibility that they get called in either an atomic
      or a non-atomic context.
      The way these get handled below work only as long as clk_prepare
      is implemented as a no-op (which is the case today) since this gets
      called very early at boot while most subsystems are unavailable.
      Hence these are marked with a *HACK* comment, which says we need
      to re-visit these once we start doing something meaningful with
      clk_prepare/clk_unprepare like doing voltage scaling or something
      that involves i2c.
      This is in preparation of OMAP moving to CCF.
      Based on initial changes from Mike Turquette.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
  9. 13 Sep, 2012 2 commits
    • Tony Lindgren's avatar
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren authored
      As the plat and mach includes need to disappear for single zImage work,
      we need to remove plat/hardware.h.
      Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
      The old plat/hardware.h already has omap1 only defines, so it gets moved
      to mach/hardware.h for omap1. For omap2+, we use the local soc.h
      that for now just includes the related SoC headers to keep this patch more
      Note that the local soc.h still includes plat/cpu.h that can be dealt
      with in later patches. Let's also include plat/serial.h from common.h for
      all the board-*.c files. This allows making the include files local later
      on without patching these files again.
      Note that only minimal changes are done in this patch for the
      drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
      patches are needed to eventually remove cpu_is_omap usage in the drivers.
      Also only minimal changes are done to sound/soc/omap/* to remove the
      unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
      no need to include omap44xx.h.
      While at it, also sort some of the includes in the standard way.
      Cc: linux-watchdog@vger.kernel.org
      Cc: alsa-devel@alsa-project.org
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Acked-by: default avatarWim Van Sebroeck <wim@iguana.be>
      Acked-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
    • Tony Lindgren's avatar
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren authored
      As the interrupts should only be defined in the platform_data, and
      eventually coming from device tree, there's no need to define them
      in header files.
      Let's remove the hardcoded references to irqs.h and fix up the includes
      so we don't rely on headers included in irqs.h. Note that we're
      defining OMAP_INTC_START as 0 to the interrupts. This will be needed
      when we enable SPARSE_IRQ. For some drivers we need to add
      #include <plat/cpu.h> for now until these drivers are fixed to
      remove cpu_is_omapxxxx() usage.
      While at it, sort som of the includes the standard way, and add
      the trailing commas where they are missing in the related data
      Note that for drivers/staging/tidspbridge we just define things
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  10. 12 Sep, 2012 1 commit
    • Paul Walmsley's avatar
      ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... · a032d33b
      Paul Walmsley authored
      Resolve the following warnings from smatch:
      arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1?
      arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR()
      arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1
      arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata'
      arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret'
      arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
      arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret'
      arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
      arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627)
      arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13
      arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'.
      arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1
      Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG()
      can be disabled.  The changes in the first version that removed the
      subsequent return() after BUG() states have been dropped.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
  11. 30 Aug, 2012 2 commits
  12. 09 Jul, 2012 1 commit
  13. 14 May, 2012 1 commit
    • Ivan Djelic's avatar
      ARM: OMAP3: gpmc: add BCH ecc api and modes · 8d602cf5
      Ivan Djelic authored
      This patch adds a simple BCH ecc computation api, similar to the
      existing Hamming ecc api. It is intended to be used by the MTD layer.
      It implements the following features:
      - support 4-bit and 8-bit ecc computation
      - do not protect user bytes in spare area, only data area is protected
      - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs
      This last feature is obtained by adding a constant polynomial to
      the hardware computed ecc. It allows to correct bitflips in blank pages
      and is extremely useful to support filesystems such as UBIFS, which expect
      erased pages to contain only 0xFFs.
      This api has been tested on an OMAP3630 board.
      Artem: The OMAP maintainer Tony Lindgren gave us his blessing for merging
      this patch via the MTD tree.
      Signed-off-by: default avatarIvan Djelic <ivan.djelic@parrot.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  14. 10 May, 2012 1 commit
  15. 13 Apr, 2012 1 commit
    • Paul Walmsley's avatar
      ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse · 355f8eee
      Paul Walmsley authored
      arch/arm/mach-omap2/gpmc.c passes a return value from ioremap() as the
      fifth argument to request_irq() without casting it.  This causes
      sparse to generate the following warning:
      arch/arm/mach-omap2/gpmc.c:759:63: warning: incorrect type in argument 5 (different address spaces)
      arch/arm/mach-omap2/gpmc.c:759:63:    expected void *dev
      arch/arm/mach-omap2/gpmc.c:759:63:    got void [noderef] <asn:2>*static [toplevel] [assigned] gpmc_base
      It turns out that it's not necessary to pass this.  gpmc_base is a
      file-scoped static variable, the ISR is located in the same file ... and
      the ISR doesn't even touch the passed-in variable.  So, just replace it with
      NULL in request_irq().
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
  16. 06 Mar, 2012 1 commit
  17. 26 Jan, 2012 1 commit
  18. 29 Mar, 2011 1 commit
  19. 19 Mar, 2011 1 commit
    • Balaji T K's avatar
      ARM: OMAP2+: Fix warnings for GPMC interrupt · 77aded2f
      Balaji T K authored
      Commit db97eb7d
      (omap: gpmc: enable irq mode in gpmc) enabled interrupts for
      GPMC (General Purpose Memory Controller). However, looks like
      this patch only works on omap3. Fix the issues to avoid warnings
      on omap4 during the boot.
      GPMC: number of chip select is 8, CS0 to CS7. One less IRQ
      allocated throws below warning at boot:
      [    0.429290] Trying to install type control for IRQ409
      [    0.429290] Trying to set irq flags for IRQ409
      Resolve following warning messages in boot when irq chip is not set:
      [    0.429229] Trying to install interrupt handler for IRQ402
      [    0.429229] Trying to install interrupt handler for IRQ403
      [    0.429229] Trying to install interrupt handler for IRQ404
      [    0.429260] Trying to install interrupt handler for IRQ405
      [    0.429260] Trying to install interrupt handler for IRQ406
      [    0.429260] Trying to install interrupt handler for IRQ407
      [    0.429290] Trying to install interrupt handler for IRQ408
      Resolve following warning in OMAP4:
      [    0.429290] gpmc: irq-20 could not claim: err -22
      Signed-off-by: default avatarBalaji T K <balajitk@ti.com>
      [tony@atomide.com: combined patches into one, updated comments]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  20. 17 Feb, 2011 2 commits
  21. 21 Dec, 2010 1 commit
  22. 02 Aug, 2010 2 commits
  23. 15 Feb, 2010 1 commit
  24. 03 Feb, 2010 1 commit
  25. 21 Jan, 2010 1 commit
  26. 12 Dec, 2009 1 commit
  27. 18 Nov, 2009 1 commit
  28. 11 Nov, 2009 1 commit