1. 02 4月, 2013 4 次提交
  2. 14 3月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · 71856843
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      71856843
  3. 05 3月, 2013 1 次提交
  4. 02 2月, 2013 4 次提交
  5. 26 1月, 2013 2 次提交
  6. 16 1月, 2013 1 次提交
  7. 15 1月, 2013 1 次提交
  8. 12 1月, 2013 1 次提交
    • T
      ARM: OMAP2+: Use omap initcalls · b76c8b19
      Tony Lindgren 提交于
      This way the initcalls don't run on other SoCs on multiplatform
      kernels. Otherwise we'll get something like this when booting
      on vexpress:
      
      omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
      ...
      WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
      _init_omap_device: could not find omap_hwmod for mpu
      ...
      omap-dma-engine omap-dma-engine: OMAP DMA engine driver
      ...
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b76c8b19
  9. 04 1月, 2013 1 次提交
    • G
      ARM: drivers: remove __dev* attributes. · 351a102d
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      351a102d
  10. 09 11月, 2012 2 次提交
    • A
      ARM: OMAP2+: gpmc: generic timing calculation · 246da26d
      Afzal Mohammed 提交于
      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
      justified.
      
      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: NAfzal Mohammed <afzal@ti.com>
      246da26d
    • A
      ARM: OMAP2+: gpmc: handle additional timings · 559d94b0
      Afzal Mohammed 提交于
      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: NAfzal Mohammed <afzal@ti.com>
      559d94b0
  11. 19 10月, 2012 1 次提交
    • T
      ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2 · e4c060db
      Tony Lindgren 提交于
      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: NTony Lindgren <tony@atomide.com>
      e4c060db
  12. 18 10月, 2012 3 次提交
  13. 15 10月, 2012 5 次提交
  14. 09 10月, 2012 1 次提交
  15. 24 9月, 2012 2 次提交
  16. 23 9月, 2012 1 次提交
    • R
      ARM: omap: clk: add clk_prepare and clk_unprepare · 4d7cb45e
      Rajendra Nayak 提交于
      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
      clk_disable_unprepare().
      
      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: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d7cb45e
  17. 13 9月, 2012 2 次提交
    • T
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren 提交于
      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
      readable.
      
      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: NWim Van Sebroeck <wim@iguana.be>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc04161
    • T
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren 提交于
      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
      structures.
      
      Note that for drivers/staging/tidspbridge we just define things
      locally.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d7e1eba
  18. 12 9月, 2012 1 次提交
    • P
      ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... · a032d33b
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      a032d33b
  19. 31 8月, 2012 2 次提交
  20. 09 7月, 2012 1 次提交
  21. 14 5月, 2012 1 次提交
    • I
      ARM: OMAP3: gpmc: add BCH ecc api and modes · 8d602cf5
      Ivan Djelic 提交于
      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: NIvan Djelic <ivan.djelic@parrot.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8d602cf5
  22. 11 5月, 2012 1 次提交
  23. 13 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse · 355f8eee
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      355f8eee