1. 06 11月, 2012 3 次提交
  2. 24 10月, 2012 1 次提交
  3. 23 10月, 2012 5 次提交
    • 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
    • T
      ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals. · 1d8643dd
      Tony Lindgren 提交于
      On n900 uart1 pins are not not used for uart, instead they are
      used to connect to a cell modem over ssi. Looks like we're
      currently missing these signal names for 3430 for some reason,
      and only have some of them listed for 3630. Obviously the signals
      are there for 3430 if n900 is using them and they are documented
      in some TRMs.
      
      Note that these will eventually be replaced by device tree
      based pinctrl-single.c driver. But for now these are needed
      to verify the SSI pins for devices like Nokia N900.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1d8643dd
    • T
      ARM: OMAP2+: Fix location of select PINCTRL · 24942e8a
      Tony Lindgren 提交于
      Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
      added select PINCTRL, but accdentally added it to a wrong
      location.
      
      We want to select if for ARCH_OMAP2PLUS, not for
      ARCH_OMAP2PLUS_TYPICAL.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      24942e8a
    • 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
  4. 18 10月, 2012 2 次提交
  5. 17 10月, 2012 3 次提交
  6. 14 10月, 2012 1 次提交
    • R
      ARM: config: sort select statements alphanumerically · b1b3f49c
      Russell King 提交于
      As suggested by Andrew Morton:
      
        This is a pet peeve of mine.  Any time there's a long list of items
        (header file inclusions, kconfig entries, array initalisers, etc) and
        someone wants to add a new item, they *always* go and stick it at the
        end of the list.
      
        Guys, don't do this.  Either put the new item into a randomly-chosen
        position or, probably better, alphanumerically sort the list.
      
      lets sort all our select statements alphanumerically.  This commit was
      created by the following perl:
      
      while (<>) {
      	while (/\\\s*$/) {
      		$_ .= <>;
      	}
      	undef %selects if /^\s*config\s+/;
      	if (/^\s+select\s+(\w+).*/) {
      		if (defined($selects{$1})) {
      			if ($selects{$1} eq $_) {
      				print STDERR "Warning: removing duplicated $1 entry\n";
      			} else {
      				print STDERR "Error: $1 differently selected\n".
      					"\tOld: $selects{$1}\n".
      					"\tNew: $_\n";
      				exit 1;
      			}
      		}
      		$selects{$1} = $_;
      		next;
      	}
      	if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
      			  /^endif/ or /^endchoice/)) {
      		foreach $k (sort (keys %selects)) {
      			print "$selects{$k}";
      		}
      		undef %selects;
      	}
      	print;
      }
      if (%selects) {
      	foreach $k (sort (keys %selects)) {
      		print "$selects{$k}";
      	}
      }
      
      It found two duplicates:
      
      Warning: removing duplicated S5P_SETUP_MIPIPHY entry
      Warning: removing duplicated HARDIRQS_SW_RESEND entry
      
      and they are identical duplicates, hence the shrinkage in the diffstat
      of two lines.
      
      We have four testers reporting success of this change (Tony, Stephen,
      Linus and Sekhar.)
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b1b3f49c
  7. 09 10月, 2012 15 次提交
  8. 08 10月, 2012 3 次提交
  9. 06 10月, 2012 1 次提交
  10. 03 10月, 2012 3 次提交
  11. 25 9月, 2012 1 次提交
  12. 24 9月, 2012 2 次提交
    • J
      ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 · 76a5d9bf
      Jon Hunter 提交于
      OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
      interrupts to the MPU HWMOD so we can use these for PMU events on these
      devices. The PMU interrupts need to be the first interrupts in the array of
      interrupts as the ARM PMU driver assumes this.
      
      By using these dedicated interrupts we only need to enable the MPU and DEBUG
      sub-systems for PMU to work. This is different to OMAP4430 that did not have
      dedicated interrupts and required other power domains in addition to the DEBUG
      sub-system to be enabled so we could route the PMU events to the CTI interrupts.
      Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
      the PMU device that is using by OMAP3.
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      76a5d9bf
    • J
      ARM: OMAP2+: PMU: Add runtime PM support · 6a9bce27
      Jon Hunter 提交于
      The original implementation of this patch was done by Ming Lei for PMU on OMAP4
      [1]. Since then the PM runtime calls have been moved into the ARM PMU code and
      this greatly simplifies the changes.
      
      The another differnce since the original version, is that it is no longer
      necessary to call pm_runtime_get/put during the PMU initialisation was we are no
      longer accessing the hardware at this stage.
      
      By adding runtime PM support, we can ensure that the appropriate power and clock
      domains are kept on while PMU is being used.
      
      [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6a9bce27