1. 15 10月, 2012 11 次提交
  2. 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
  3. 09 10月, 2012 15 次提交
  4. 08 10月, 2012 3 次提交
  5. 06 10月, 2012 1 次提交
  6. 03 10月, 2012 3 次提交
  7. 25 9月, 2012 1 次提交
  8. 24 9月, 2012 5 次提交
    • 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
    • M
      ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD · efc7f49c
      Ming Lei 提交于
      For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
      (CTI) because there are no dedicated interrupts. In order to route the PMU
      events via the CTI IRQs, the following modules must be enabled:
      
              l3_instr, l3_main_3, debugss
      
      Therefore, build the arm-pmu device via these three HWMODs.
      
      However, the CTI support for this platform still needs some work.  Until
      that's finished, temporarily disable the PMU on OMAP4430.
      
      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: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: temporarily disabled OMAP4430 PMU support until a
       better CTI interface can be implemented; added patch description note]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      efc7f49c
    • J
      ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD · ee75d95c
      Jon Hunter 提交于
      Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
      on OMAP2 devices we only need to use MPU sub-system and so we can simply use
      the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
      to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
      device for OMAP3.
      
      The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
      add the PMU interrupt to the MPU HWMOD for these devices.
      
      This change also moves the PMU code out of the mach-omap2/devices.c files into
      its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.
      
      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: fixed checkpatch messages; updated to apply; dropped old-style
       initial filename line in header comments]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ee75d95c
    • J
      ARM: OMAP3: hwmod data: Add debugss HWMOD data · c7dad45f
      Jon Hunter 提交于
      To enable PMU with runtime PM support on OMAP3 devices we need to be able to
      dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
      data for the debug sub-system for OMAP3, we can build the PMU device using the
      debug sub-system HWMOD and control this power domain using runtime PM.
      Reviewed-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply; added L4-EMU address space]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c7dad45f