1. 23 10月, 2012 3 次提交
    • K
      ARM: OMAP3: Beagle: fix OPP customization and initcall ordering · 65bf7ca0
      Kevin Hilman 提交于
      After commit 24d7b40a (ARM: OMAP2+:
      PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
      using an existing CPU device, not the omap_device for MPU-SS.
      
      First, fix the board file to use get_cpu_device() as required by the
      above commit, otherwise custom OPPs will be added to the wrong device.
      
      Second, the board files OPP init is called from the its init_machine
      method, and the generic CPU devices are not yet created when
      init_machine is run.  Therefore OPP initialization will fail.  To fix,
      use a device_initcall() for the board file's OPP customization, and
      make the device_initcall board-specific by using a machine_is check.
      Reported-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      65bf7ca0
    • K
      ARM: OMAP2: UART: fix console UART mismatched runtime PM status · 44b1d42a
      Kevin Hilman 提交于
      The runtime PM framework assumes that the hardware state of devices
      when initialized is disabled.  For all omap_devices, we idle/disable
      device by default.  However, the console uart uses a "no idle" option
      during omap_device init in order to allow earlyprintk usage to work
      seamlessly during boot.
      
      Because the hardware is left partially enabled after init (whatever
      the bootloader settings were), the omap_device should later be fully
      initialized (including mux) and the runtime PM framework should be
      told that the device is active, and not disabled so that the hardware
      state is in sync with runtime PM state.
      
      To fix, after the device has been created/registered, call
      omap_device_enable() to finialize init and use pm_runtime_set_active()
      to tell the runtime PM core the device is enabled.
      
      Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
      3730/Beagle-xM, 4460/PandaES.
      Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Sourav Poddar <sourav.poddar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      44b1d42a
    • P
      ARM: OMAP3: PM: apply part of the erratum i582 workaround · 856c3c5b
      Paul Walmsley 提交于
      On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
      powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
      upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
      PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
      unusable.  This is erratum i582 in the OMAP36xx Silicon Errata
      document.
      
      This patch implements one of several parts of the workaround: the
      addition of the wakeup dependency between the PER and WKUP
      clockdomains, such that PER will wake up at the same time CORE_L3
      does.
      
      This is not a complete workaround.  For it to be complete:
      
      1. the PER powerdomain's next power state must not be set to OSWR or
         OFF if the CORE powerdomain's next power state is set to CSWR or
         ON;
      
      2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
         if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
         PER went OFF while CORE stayed on.  If loopback tests fail, then
         those devices will be unusable until PER and CORE can undergo a
         transition from ON to OSWR/OFF and back ON.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      856c3c5b
  2. 20 10月, 2012 3 次提交
    • M
      arm64: fix alignment padding in assembly code · aeed41a9
      Marc Zyngier 提交于
      An interesting effect of using the generic version of linkage.h
      is that the padding is defined in terms of x86 NOPs, which can have
      even more interesting effects when the assembly code looks like this:
      
      ENTRY(func1)
      	mov	x0, xzr
      ENDPROC(func1)
      	// fall through
      ENTRY(func2)
      	mov	x0, #1
      	ret
      ENDPROC(func2)
      
      Admittedly, the code is not very nice. But having code from another
      architecture doesn't look completely sane either.
      
      The fix is to add arm64's version of linkage.h, which causes the insertion
      of proper AArch64 NOPs.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      aeed41a9
    • C
      xtensa: add missing system calls to the syscall table · 7216cabf
      Chris Zankel 提交于
      Add the following system calls to the syscall table:
      
      fallocate
      sendmmsg
      umount2
      syncfs
      epoll_create1
      inotify_init1
      signalfd4
      dup3
      pipe2
      timerfd_create
      timerfd_settime
      timerfd_gettime
      eventfd2
      preadv
      pwritev
      fanotify_init
      fanotify_mark
      process_vm_readv
      process_vm_writev
      name_to_handle_at
      open_by_handle_at
      sync_file_range
      perf_event_open
      rt_tgsigqueueinfo
      clock_adjtime
      prlimit64
      kcmp
      
      Note that we have to use the 'sys_sync_file_range2' version, so that
      the 64-bit arguments are aligned correctly to the argument registers.
      Signed-off-by: NChris Zankel <chris@zankel.net>
      7216cabf
    • C
      xtensa: minor compiler warning fix · 39070cb8
      Chris Zankel 提交于
      Fix two compiler warnings complaining about truncating a value on
      a 64-bit host, and about declaring an unused variable that is only
      used for a specific configuration.
      Signed-off-by: NChris Zankel <chris@zankel.net>
      39070cb8
  3. 19 10月, 2012 13 次提交
  4. 18 10月, 2012 16 次提交
  5. 17 10月, 2012 5 次提交