1. 16 8月, 2016 1 次提交
  2. 29 6月, 2016 1 次提交
  3. 13 4月, 2016 1 次提交
    • R
      ARM: dts: am437x: Provide NAND ready pin · 99a41011
      Roger Quadros 提交于
      On these boards NAND ready pin status is avilable over
      GPMC_WAIT0 pin.
      
      For NAND we don't use GPMC wait pin monitoring but
      get the NAND Ready/Busy# status using GPIOlib.
      GPMC driver provides the WAIT0 pin status over GPIOlib.
      
      Read speed increases from 16516 KiB/ to 18813 KiB/s
      and write speed was unchanged at 9941 KiB/s.
      
      Measured using mtd_speedtest.ko.
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      99a41011
  4. 12 4月, 2016 1 次提交
  5. 31 3月, 2016 1 次提交
  6. 27 2月, 2016 2 次提交
  7. 20 2月, 2016 1 次提交
  8. 28 1月, 2016 1 次提交
  9. 01 12月, 2015 1 次提交
  10. 13 10月, 2015 1 次提交
  11. 14 7月, 2015 5 次提交
  12. 01 4月, 2015 1 次提交
  13. 15 3月, 2015 1 次提交
    • M
      ARM: omap: convert wakeupgen to stacked domains · 7136d457
      Marc Zyngier 提交于
      OMAP4/5 has been (ab)using the gic_arch_extn to provide
      wakeup from suspend, and it makes a lot of sense to convert
      this code to use stacked domains instead.
      
      This patch does just this, updating the DT files to actually
      reflect what the HW provides.
      
      BIG FAT WARNING: because the DTs were so far lying by not
      exposing the WUGEN HW block, kernels with this patch applied
      won't have any suspend-resume facility when booted with old DTs,
      and old kernels with updated DTs won't even boot.
      
      On a platform with this patch applied, the system looks like
      this:
      
      root@bacon-fat:~# cat /proc/interrupts
                  CPU0       CPU1
       16:          0          0     WUGEN  37  gp_timer
       19:     233799     155916       GIC  27  arch_timer
       23:          0          0     WUGEN   9  l3-dbg-irq
       24:          1          0     WUGEN  10  l3-app-irq
       27:        282          0     WUGEN  13  omap-dma-engine
       44:          0          0  4ae10000.gpio  13  DMA
      294:          0          0     WUGEN  20  gpmc
      297:        506          0     WUGEN  56  48070000.i2c
      298:          0          0     WUGEN  57  48072000.i2c
      299:          0          0     WUGEN  61  48060000.i2c
      300:          0          0     WUGEN  62  4807a000.i2c
      301:          8          0     WUGEN  60  4807c000.i2c
      308:       2439          0     WUGEN  74  OMAP UART2
      312:        362          0     WUGEN  83  mmc2
      313:        502          0     WUGEN  86  mmc0
      314:         13          0     WUGEN  94  mmc1
      350:          0          0      PRCM  pinctrl, pinctrl
      406:   35155709          0       GIC 109  ehci_hcd:usb1
      407:          0          0     WUGEN   7  palmas
      409:          0          0     WUGEN 119  twl6040
      410:          0          0   twl6040   5  twl6040_irq_ready
      411:          0          0   twl6040   0  twl6040_irq_th
      IPI0:          0          1  CPU wakeup interrupts
      IPI1:          0          0  Timer broadcast interrupts
      IPI2:      95334     902334  Rescheduling interrupts
      IPI3:          0          0  Function call interrupts
      IPI4:        479        648  Single function call interrupts
      IPI5:          0          0  CPU stop interrupts
      IPI6:          0          0  IRQ work interrupts
      IPI7:          0          0  completion interrupts
      Err:          0
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/1426088629-15377-8-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
      7136d457
  14. 08 1月, 2015 1 次提交
  15. 22 11月, 2014 1 次提交
  16. 11 11月, 2014 1 次提交
  17. 30 10月, 2014 1 次提交
    • T
      ARM: dts: Fix wrong GPMC size mappings for omaps · e2c5eb78
      Tony Lindgren 提交于
      The GPMC binding is obviously very confusing as the values
      are all over the place. People seem to confuse the GPMC partition
      size for the chip select, and the device IO size within the GPMC
      partition easily.
      
      The ranges entry contains the GPMC partition size. And the
      reg entry contains the size of the IO registers of the
      device connected to the GPMC.
      
      Let's fix the issue according to the following table:
      
      Device          GPMC partition size     Device IO size
      connected       in the ranges entry     in the reg entry
      
      NAND            0x01000000 (16MB)       4
      16550           0x01000000 (16MB)       8
      smc91x          0x01000000 (16MB)       0xf
      smc911x         0x01000000 (16MB)       0xff
      OneNAND         0x01000000 (16MB)       0x20000 (128KB)
      16MB NOR        0x01000000 (16MB)       0x01000000 (16MB)
      32MB NOR        0x02000000 (32MB)       0x02000000 (32MB)
      64MB NOR        0x04000000 (64MB)       0x04000000 (64MB)
      128MB NOR       0x08000000 (128MB)      0x08000000 (128MB)
      256MB NOR       0x10000000 (256MB)      0x10000000 (256MB)
      
      Let's also add comments to the fixed entries while at it.
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e2c5eb78
  18. 05 9月, 2014 3 次提交
  19. 29 7月, 2014 1 次提交
  20. 09 7月, 2014 1 次提交
  21. 16 6月, 2014 1 次提交
  22. 03 6月, 2014 1 次提交
  23. 20 5月, 2014 1 次提交
  24. 15 5月, 2014 1 次提交
  25. 07 5月, 2014 3 次提交
  26. 06 5月, 2014 1 次提交
  27. 06 3月, 2014 1 次提交
  28. 03 3月, 2014 4 次提交