1. 19 3月, 2013 1 次提交
  2. 05 3月, 2013 1 次提交
  3. 02 2月, 2013 1 次提交
  4. 31 1月, 2013 1 次提交
  5. 12 1月, 2013 2 次提交
    • T
      ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support · a0694861
      Tony Lindgren 提交于
      Flip on multiplatform support for omap2+.
      
      No changes to omap2plus_defconfig needed, but please note
      that you may need to update your custom config files to
      make sure you have:
      
      CONFIG_ARCH_MULTIPLATFORM=y
      CONFIG_ARCH_MULTI_V7=y
      CONFIG_ARCH_OMAP2PLUS=y
      
      And may need CONFIG_ARCH_MULTI_V6=y if booting omap2 boards.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a0694861
    • T
      ARM: OMAP2+: Disable code that currently does not work with multiplaform · a62a6e98
      Tony Lindgren 提交于
      We still need to fix up few places for multiplatform support,
      but that can proceed separately. Fix the issue by making the
      problem drivers depends !ARCH_MULTIPLATFORM for now.
      
      The remaining pieces that are not multiplatform compatible
      for omap2+ SoCs are:
      
      1. Some drivers are using custom omap_dm_timer calls
      
      There are two drivers that are directly usign omap hardware
      timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
      drivers/staging/tidspbridge/core/dsp-clock.c. These can be
      fixed for multiplatform by allowing a minimal set of hardware
      timers to be accessed, and for some functionality by using the
      hrtimer framework.
      
      2. Hardware OMAP4_ERRATA_I688 needs to be fixed up
      
      This can't be enabled for multiplatform configurations in
      it's current form. It may be possible to fix it up to do
      instruction replacement early on during init. Luckily it
      looks like this errata does not seem to get hit with
      mainline kernel code alone at least currently.
      
      3. Legacy header needed for omap-sham.c
      
      Looks like it still needs mach/irqs.h for omap1 that
      does not exist for multiplatform systems. Just ifdef
      it for now.
      
      4. Mailbox is waiting to get moved to drivers
      
      Disable it for now to avoid adding a dependency to the
      mailbox patches.
      
      Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
      Cc: Sean Young <sean@mess.org>
      Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      [tony@atomide.com: updated to disable mailbox]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a62a6e98
  6. 15 12月, 2012 1 次提交
    • J
      ARM: OMAP2+: Fix realtime_counter_init warning in timer.c · 34cceb74
      Jon Hunter 提交于
      In commit fa6d79d2 (ARM: OMAP: Add initialisation for the real-time
      counter), the function realtime_counter_init() was added. However, if
      the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
      the following compiler warning is observed.
      
        CC      arch/arm/mach-omap2/timer.o
        arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
        defined but not used [-Wunused-function]
      
      Commit fa6d79d2 also introduced the kernel configuration option
      CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
      a stub function for realtime_counter_init() is defined.
      
      For non-OMAP5 devices, there is no realtime counter and so
      realtime_counter_init() function and stub function are not used for
      these devices. Therefore, fix this warning by only allowing the kernel
      configuration option CONFIG_SOC_HAS_REALTIME_COUNTER to be enabled for
      OMAP5 devices.
      
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by Santosh Shilimkar <santosh.shilimkar@ti.com>
      34cceb74
  7. 13 11月, 2012 1 次提交
  8. 23 10月, 2012 1 次提交
  9. 20 10月, 2012 1 次提交
  10. 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
  11. 19 9月, 2012 3 次提交
  12. 11 9月, 2012 1 次提交
  13. 31 8月, 2012 1 次提交
  14. 23 8月, 2012 1 次提交
    • A
      ARM: omap: allow building omap44xx without SMP · c7a9b09b
      Arnd Bergmann 提交于
      The new omap4 cpuidle implementation currently requires
      ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
      
      This patch makes it possible to build a non-SMP kernel
      for that platform. This is not normally desired for
      end-users but can be useful for testing.
      
      Without this patch, building rand-0y2jSKT results in:
      
      drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
      drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
      
      It's not clear if this patch is the best solution for
      the problem at hand. I have made sure that we can now
      build the kernel in all configurations, but that does
      not mean it will actually work on an OMAP44xx.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      c7a9b09b
  15. 07 8月, 2012 1 次提交
    • S
      OMAP2+: Fix random config build break with !ARM_CPU_SUSPEND · acb11fe8
      Santosh Shilimkar 提交于
      The random config builds with PM and !ARM_CPU_SUSPEND breaks with below
      error on omap2plus_defconfig.
      
      arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
      arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend'
      
      This is because recently merged OMAP5 platform shares the common files
      with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND
      the sleep code is meaningless.
      
      Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from
      Russell King in an off-list discussion.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Kevin Hilman <khilman@ti.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      acb11fe8
  16. 26 7月, 2012 1 次提交
    • S
      ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP cpuidle. · dd3ad97c
      Santosh Shilimkar 提交于
      OMAP4 CPUDILE driver is converted mainly based on notes from the
      coupled cpuidle patch series.
      
      The changes include :
      - Register both CPUs and C-states to cpuidle driver.
      - Set struct cpuidle_device.coupled_cpus
      - Set struct cpuidle_device.safe_state to non coupled state.
      - Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
        state that affects multiple cpus.
      - Separate ->enter hooks for coupled & simple idle.
      - CPU0 wait loop for CPU1 power transition.
      - CPU1 wakeup mechanism for the idle exit.
      - Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.
      
      Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
      on the intermediate version of this patch.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      dd3ad97c
  17. 09 7月, 2012 1 次提交
  18. 05 7月, 2012 2 次提交
    • V
      ARM: OMAP2+: Remove unnecessary ifdef around __omap2_set_globals · ecc46cfd
      Vaibhav Hiremath 提交于
      The function __omap2_set_globals() can be common across all
      platforms/architectures, even in case of omap4, internally it
      calls same set of functions as in __omap2_set_globals() function
      (except for sdrc).
      This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
      so that we can reuse same function across omap2/3/4...
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ecc46cfd
    • V
      ARM: OMAP2+: am33xx: Make am33xx as a separate class · 1c213ba1
      Vaibhav Hiremath 提交于
      Initially, we decided to make am33xx family of device to fall
      under omap3 class (cpu_is_omap34xx() = true), since it carries
      Cortex-A8 core. But while adding complete baseport support
      (like, clock, power and hwmod) support, it is observed that,
      we are creating more and more problems by treating am33xx device
      as omap3 family, as nothing matches between them
      (except cortex-A8 mpu).
      
      So,  after long discussion we have came to the conclusion that,
      we should not consider am33xx device as omap3 family, instead
      create separate class (SOC_AM33XX) under OMAP2PLUS.
      This means, for am33xx device, cpu_is_omap34xx() will return false,
      and only cpu_is_am33xx() will be true.
      
      Please refer to the link below, for mailing-list discussion on this -
      
      http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      [tony@atomide.com: fixed typo, updated for soc_is changes]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1c213ba1
  19. 29 6月, 2012 1 次提交
    • K
      ARM: OMAP2+: fix CONFIG_CPU_IDLE dependency on CONFIG_PM · e0246e8e
      Kevin Hilman 提交于
      commit 164e0cbf (ARM: OMAP3/4: consolidate cpuidle Makefile) added
      an OMAP-specific dependency from CPU_IDLE to CONFIG_PM.  This causes
      some randconfig warnings when CONFIG_PM has unmet dependencies:
      
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      
      Fix this by making the dependency on CONFIG_PM_RUNTIME (which in turn
      will enable CONFIG_PM.)
      Reported-by: NTony Lindgren <tony@atomide.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0246e8e
  20. 20 6月, 2012 1 次提交
    • D
      ARM: OMAP3/4: consolidate cpuidle Makefile · 164e0cbf
      Daniel Lezcano 提交于
      The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
      even if the cpuidle option is not set in the kernel.
      
      This patch fixes this by creating a section in the Makefile where these
      files are compiled only if the CONFIG_CPU_IDLE option is set.
      
      This modification breaks an implicit dependency between CPU_IDLE and PM as
      they belong to the same block in the Makefile. This is fixed in the Kconfig
      by selecting explicitely PM is CPU_IDLE is set.
      
      The linux coding style recommend to use no-op functions in the headers
      when the subsystem is disabled instead of adding big section in C files.
      
      This patch fix this also.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Reviewed-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      164e0cbf
  21. 04 6月, 2012 2 次提交
    • T
      ARM: OMAP2: Remove legacy USB FS support · fe57ab06
      Tony Lindgren 提交于
      The FS (Full Speed) USB controller is available on 2420 and 2430,
      but not being used.
      
      Out of the 2420 based boards only Nokia N8X0 are seeing active
      development and they have external HS (High Speed) TUSB controller.
      On omap 2430sdp there is MUSB HS controller, so there's no need
      to use the legacy USB FS controller.
      
      That leaves only H4 and Apollon boards that could use the FS USB
      controller. As both H4 and Apollon boards are old proprietary
      development boards, it's unlikely that we have any active
      developers working on those boards using the USB.
      
      So remove the FS USB support for omap2 machines. Patches are
      welcome if somebody wants to instead fix it all up to the
      current standards.
      
      Cc: linux-usb@vger.kernel.org
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fe57ab06
    • T
      ARM: OMAP3: There is no FS USB controller on omap3 · a22ab1c4
      Tony Lindgren 提交于
      We should not select ARCH_OMAP_OTG as the hardware does not
      have the legacy FS (Full Speed) USB interface.
      
      Cc: linux-usb@vger.kernel.org
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a22ab1c4
  22. 11 5月, 2012 2 次提交
  23. 10 5月, 2012 1 次提交
  24. 06 3月, 2012 2 次提交
  25. 25 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP · c295fb63
      Tony Lindgren 提交于
      If we don't have ARCH_OMAP2, 3 or 4 selected randconfig will always
      fail with multiple errors as the CPU and MACHINE are not set.
      
      Fix this by changing arch/arm/Makefile to build mach-omap2 based on
      ARCH_OMAP2PLUS. And let's introduce SOC_OMAP and SOC_OMAP_NOOP that
      allow randconfig to generate buildable .config files.
      
      Note that we can also remove few uncecssary ARCH_OMAP2PLUS lines
      as they are all within if ARCH_OMAP2PLUS block.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c295fb63
  26. 24 2月, 2012 1 次提交
  27. 15 2月, 2012 1 次提交
  28. 23 1月, 2012 1 次提交
    • W
      ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs · a092f2b1
      Will Deacon 提交于
      To ensure correct alignment of cacheline-aligned data, the maximum
      cacheline size needs to be known at compile time.
      
      Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
      that there will be future ARMv7 implementations with the same line size)
      then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
      size. For CPUs with smaller caches, this will result in some harmless
      padding but will help with single zImage work and avoid hitting subtle
      bugs with misaligned data structures.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a092f2b1
  29. 21 1月, 2012 2 次提交
  30. 13 1月, 2012 1 次提交
    • R
      ARM: Add arm_memblock_steal() to allocate memory away from the kernel · 716a3dc2
      Russell King 提交于
      Several platforms are now using the memblock_alloc+memblock_free+
      memblock_remove trick to obtain memory which won't be mapped in the
      kernel's page tables.  Most platforms do this (correctly) in the
      ->reserve callback.  However, OMAP has started to call these functions
      outside of this callback, and this is extremely unsafe - memory will
      not be unmapped, and could well be given out after memblock is no
      longer responsible for its management.
      
      So, provide arm_memblock_steal() to perform this function, and ensure
      that it panic()s if it is used inappropriately.  Convert everyone
      over, including OMAP.
      
      As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
      with this change.  Mark this option as BROKEN and make it depend on
      BROKEN.  OMAP needs to be fixed, or 137d105d (ARM: OMAP4: Fix
      errata i688 with MPU interconnect barriers.) reverted until such
      time it can be fixed correctly.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      716a3dc2
  31. 19 12月, 2011 2 次提交