1. 15 Nov, 2012 3 commits
  2. 12 Nov, 2012 2 commits
    • Tony Lindgren's avatar
      Merge tag 'gpmc-generic-timing' of... · 86983087
      Tony Lindgren authored
      Merge tag 'gpmc-generic-timing' of git://gitorious.org/x0148406-public/linux-kernel into omap-for-v3.8/gpmc
      
      These changes provide a generic gpmc timing calculation method,
      migrates existing peripherals that makes use of custom gpmc timing
      calculation method to use the new generic one.
      
      Generic routine has been verified for onenand async timing calculation
      on omap3evm (with a local change to add onenand support). Generic
      timing calculation method were verified for other peripherals by
      simulation. Generic method has to be verified on peripherals supported
      in mainline.
      86983087
    • Arnd Bergmann's avatar
      Merge tag 'ux500-pins-for-arm-soc' of... · 2cf4726c
      Arnd Bergmann authored
      Merge tag 'ux500-pins-for-arm-soc' of http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into next/drivers
      
      From Linus Walleij <linus.walleij@linaro.org>:
      Ux500 pinctrl table update for v3.8, basically accumulated
      updates to pin muxing and biasing from internal deployment
      and regression testing for power performance.
      
      * tag 'ux500-pins-for-arm-soc' of http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
        ARM: ux500: fixup magnetometer pins
        ARM: ux500: add STM pin configuration
        ARM: ux500: 8500: add pinctrl support for uart1 and uart2
        ARM: ux500: cosmetic fixups for uart0
        ARM: ux500: 8500: define SDI sleep states
        ARM: ux500: 8500: update SKE keypad pinctrl table
        ARM: ux500: delete duplicate macro
        ARM: ux500: 8500: add IDLE pin configuration for SPI
        ARM: ux500: 8500: register LCD VSI pinctrl table
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      2cf4726c
  3. 09 Nov, 2012 5 commits
    • Afzal Mohammed's avatar
      ARM: OMAP2+: tusb6010: generic timing calculation · 47acde16
      Afzal Mohammed authored
      Generic gpmc timing calculation helper is available now, use
      it instead of custom timing calculation.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      47acde16
    • Afzal Mohammed's avatar
      ARM: OMAP2+: smc91x: generic timing calculation · ac2d9ae1
      Afzal Mohammed authored
      Generic gpmc timing calculation helper is available now, use
      it instead of custom timing calculation.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      ac2d9ae1
    • Afzal Mohammed's avatar
      ARM: OMAP2+: onenand: generic timing calculation · 4f4426f9
      Afzal Mohammed authored
      Generic gpmc timing calculation helper is available now, use
      it instead of custom timing calculation.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      4f4426f9
    • 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
      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: default avatarAfzal Mohammed <afzal@ti.com>
      246da26d
    • 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>
      559d94b0
  4. 08 Nov, 2012 1 commit
  5. 07 Nov, 2012 1 commit
  6. 06 Nov, 2012 1 commit
  7. 02 Nov, 2012 2 commits
  8. 31 Oct, 2012 13 commits
  9. 26 Oct, 2012 6 commits
  10. 25 Oct, 2012 3 commits
  11. 24 Oct, 2012 3 commits
    • Tony Lindgren's avatar
      Merge branch 'omap-for-v3.8/cleanup-headers-usb' into omap-for-v3.8/cleanup-headers · 6d02643d
      Tony Lindgren authored
      Conflicts:
      	arch/arm/mach-omap1/clock.c
      	arch/arm/mach-omap2/board-2430sdp.c
      	arch/arm/mach-omap2/board-4430sdp.c
      	arch/arm/mach-omap2/board-cm-t35.c
      	arch/arm/mach-omap2/board-igep0020.c
      	arch/arm/mach-omap2/board-ldp.c
      	arch/arm/mach-omap2/board-omap3beagle.c
      	arch/arm/mach-omap2/board-omap3logic.c
      	arch/arm/mach-omap2/board-omap4panda.c
      	arch/arm/mach-omap2/board-overo.c
      	arch/arm/mach-omap2/board-rm680.c
      	arch/arm/mach-omap2/board-rx51.c
      	arch/arm/mach-omap2/twl-common.c
      	arch/arm/mach-omap2/usb-host.c
      	arch/arm/mach-omap2/usb-musb.c
      6d02643d
    • Felipe Balbi's avatar
      ARM: OMAP: move OMAP USB platform data to <linux/platform_data/omap-usb.h> · e8c4a7ac
      Felipe Balbi authored
      In order to make single zImage work for ARM architecture,
      we need to make sure we don't depend on private headers.
      
      Move USB platform_data to <linux/platform_data/omap-usb.h>
      and add a minimal drivers/mfd/usb-omap.h.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Partha Basak <parthab@india.ti.com>
      Cc: Keshava Munegowda <keshava_mgowda@ti.com>
      Cc: linux-usb@vger.kernel.org
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [tony@atomide.com: updated for local mfd/usb-omap.h]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e8c4a7ac
    • Tony Lindgren's avatar
      ARM: OMAP2+: Introduce local usb.h · 54db6eee
      Tony Lindgren authored
      Let's move what we can from plat/usb.h to the local usb.h
      for ARM common zImage support.
      
      This is needed so we can remove plat/usb.h for ARM common
      zImage support.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Partha Basak <parthab@india.ti.com>
      Cc: Keshava Munegowda <keshava_mgowda@ti.com>
      Cc: linux-usb@vger.kernel.org
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      54db6eee