Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 06 6月, 2013 1 次提交
  3. 03 6月, 2013 1 次提交
  5. 31 5月, 2013 1 次提交
  7. 20 5月, 2013 5 次提交
  9. 18 5月, 2013 1 次提交
    • V
      ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock · a6d25f4c
      由 Vaibhav Hiremath 提交于 
      It is required to enable respective clock-domain before
enabling any clock/module inside that clock-domain.

During common-clock migration, .clkdm_name field got missed
for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm"
unused; so it will be disabled even if childs of this clock-domain
is enabled, which keeps child modules in idle mode.

This fixes the kernel crash observed on AM335xEVM-SK platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -

Crash Log:
==========
[    2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa1ac150
[    2.606434] Internal error: : 1028 [#1] SMP ARM
[    2.611207] Modules linked in:
[    2.614449] CPU: 0    Not tainted  (3.8.4-01382-g1f449cd-dirty #4)
[    2.620973] PC is at _set_gpio_debounce+0x60/0x104
[    2.626025] LR is at clk_enable+0x30/0x3c

Cc: stable@vger.kernel.org # v3.9
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      a6d25f4c
  11. 17 5月, 2013 1 次提交
    • J
      ARM: OMAP: fix __init section mismatch for _enable_preprogram · 0f497039
      由 jean-philippe francois 提交于 
      _enable_preprogram is marked as __init, but is called from _enable
which is not. Without this patch, the board oopses after init. Tested
on custom hardware and on beagle board xM. Otherwise we can get:

Unable to handle kernel paging request at virtual address 000b0012
pgd = cf968000
*pgd=8fb06831, *pte=00000000, *ppte=00000000
PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.9.0 #2)
PC is at _enable_preprogram+0x1c/0x24
LR is at omap_hwmod_enable+0x34/0x60
   psr: 80000093
sp : cf95de08  ip : 00002de5  fp : bec33d4c
r10: 00000000  r9 : 00000002  r8 : b6dd2c78
r7 : 00000004  r6 : 00000000  r5 : a0000013  r4 : cf95c000
r3 : 00000000  r2 : b6dd2c7c  r1 : 00000000  r0 : 000b0012
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8f968019  DAC: 00000015
Process otpcmd (pid: 607, stack limit = 0xcf95c230)
Stack: (0xcf95de08 to 0xcf95e000)
de00:                   00000001 cf91f840 00000000 c001d6fc 00000002 cf91f840
de20: cf8f7e10 c001de54 cf8f7e10 c001de78 c001de68 c01d5e80 00000000 cf8f7e10
de40: cf8f7e10 c01d5f28 cf8f7e10 c0530d30 00000000 c01d6f28 00000000 c0088664
de60: b6ea1000 cfb05284 cf95c000 00000001 cf95c000 60000013 00000001 cf95dee4
de80: cf870050 c01d7308 cf870010 cf870050 00000001 c0278b14 c0526f28 00000000
dea0: cf870050 ffff8e18 00000001 cf95dee4 00000000 c0274f7c cf870050 00000001
dec0: cf95dee4 cf1d8484 000000e0 c0276464 00000008 cf9c0000 00000007 c0276980
dee0: cf9c0000 00000064 00000008 cf1d8404 cf1d8400 c01cc05c 0000270a cf1d8504
df00: 00000023 cf1d8484 00000007 c01cc670 00000bdd 00000001 00000000 cf449e60
df20: cf1dde70 cf1d8400 bec33d18 cf1d8504 c0246f00 00000003 cf95c000 00000000
df40: bec33d4c c01cd078 00000003 cf1d8504 00000081 c01cbcb8 bec33d18 00000003
df60: bec33d18 c00a9034 00002000 c00a9c68 cf92fe00 00000003 c0246f00 cf92fe00
df80: 00000000 c00a9cb0 00000003 00000000 00008e70 00000000 b6f17000 00000036
dfa0: c000e484 c000e300 00008e70 00000000 00000003 c0246f00 bec33d18 bec33d18
dfc0: 00008e70 00000000 b6f17000 00000036 00000000 00000000 b6f6d000 bec33d4c
dfe0: b6ea1bd0 bec33d0c 00008c9c b6ea1bdc 60000010 00000003 00000000 00000000
(_omap_device_enable_hwmods+0x20/0x34)
(omap_device_enable+0x3c/0x50)
(_od_runtime_resume+0x10/0x1c)
(__rpm_callback+0x54/0x98)
(rpm_callback+0x64/0x7c)
(rpm_resume+0x434/0x554)
(__pm_runtime_resume+0x48/0x74)
(omap_i2c_xfer+0x28/0xe8)
(__i2c_transfer+0x3c/0x78)
(i2c_transfer+0x6c/0xc0)
(i2c_master_send+0x38/0x48)
(sha204p_send_command+0x60/0x9c)
(sha204c_send_and_receive+0x5c/0x1e0)
(sha204m_read+0x94/0xa0)
(otp_do_read+0x50/0xa4)
(vfs_ioctl+0x24/0x40)
(do_vfs_ioctl+0x1b0/0x1c0)
(sys_ioctl+0x38/0x54)
(ret_fast_syscall+0x0/0x30)
Code: e1a08002 ea000009 e598003c e592c05c (e7904003)

Cc: stable@vger.kernel.org
Signed-off-by: NJean-Philippe Fran=C3=A7ois <jp.francois@cynove.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
[tony@atomide.com: updated description with oops]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      0f497039
  13. 10 5月, 2013 1 次提交
    • T
      ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c · b1dd11d6
      由 Tony Lindgren 提交于 
      Commit 6770b211 (ARM: OMAP2+: Export SoC information to userspace)
had some broken return value handling as noted by Russell King:

+       soc_dev = soc_device_register(soc_dev_attr);
+       if (IS_ERR_OR_NULL(soc_dev)) {
+               kfree(soc_dev_attr);
+               return;
+       }
+
+       parent = soc_device_to_device(soc_dev);
+       if (!IS_ERR_OR_NULL(parent))
+               device_create_file(parent, &omap_soc_attr);

This is nonsense.  For the first, IS_ERR() is sufficient.  For the second,
tell me what error checking is required in the return value of this
function:

struct device *soc_device_to_device(struct soc_device *soc_dev)
{
        return &soc_dev->dev;
}

when you've already determined that the passed soc_dev is a valid pointer.
If you read the comments against the prototype:

/**
 * soc_device_to_device - helper function to fetch struct device
 * @soc: Previously registered SoC device container
 */
struct device *soc_device_to_device(struct soc_device *soc);

if "soc" is valid, it means the "previously registered SoC device container"
must have succeeded and that can only happen if the struct device has been
registered.  Ergo, there will always be a valid struct device pointer for
any registered SoC device container.  Therefore, if soc_device_register()
succeeds, then the return value from soc_device_to_device() will always be
valid and no error checking of it is required.

Simples.  The rule as ever applies here: get to know the APIs your using
and don't fumble around in the dark hoping that you'll get this stuff
right.

Fix it as noted by Russell.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      b1dd11d6
  15. 09 5月, 2013 5 次提交
  17. 08 5月, 2013 1 次提交
  19. 07 5月, 2013 2 次提交
  21. 04 5月, 2013 2 次提交
    • T
      ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP · eb16d332
      由 Tony Lindgren 提交于 
      Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom
for 8250 serial) fixed unmet direct dependencies for 8250, but failed
to do the same for omap serial. This can cause the following warning:

warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS &&
ARCH_OMAP2PLUS).

We should not select drivers, they should be selected by the
user. Fix the issue by removing the select and adding them to
omap2plus_defconfig instead.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      eb16d332
    • A
      ARM: OMAP: build SMP code only for OMAP4/5 · 572b16db
      由 Arnd Bergmann 提交于 
      The OMAP platform code assumes that SMP is only ever enabled when
CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
necessarirly true in a multiplatform configuration.

arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
 :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
 :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
 :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
 :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
 :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
 :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
 :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>
      572b16db
  23. 03 5月, 2013 2 次提交
    • R
      ARM: OMAP: use consistent error checking · c48cd659
      由 Russell King 提交于 
      Consistently check errors using the usual method used in the kernel
for much of its history.  For instance:

int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
	int div;
	div = gpmc_calc_divider(t->sync_clk);
	if (div < 0)
		return div;
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
{
...
	return gpmc_cs_set_timings(cs, t);

.....
	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
	if (IS_ERR_VALUE(ret))
		return ret;

So, gpmc_cs_set_timings() thinks any negative return value is an error,
but where we check that in higher levels, only a limited range are
errors...

There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
appropriate, and that is in arch/arm/include/asm/syscall.h:

static inline long syscall_get_error(struct task_struct *task,
				     struct pt_regs *regs)
{
	unsigned long error = regs->ARM_r0;
	return IS_ERR_VALUE(error) ? error : 0;
}

because this function really does have to differentiate between error
return values and addresses which look like negative numbers (eg, from
mmap()).

So, here's a patch to remove them from OMAP, except for the above.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c48cd659
    • R
      ARM: cleanup: OMAP hwmod error checking · 857835c6
      由 Russell King 提交于 
      omap_hwmod_lookup() only returns NULL on error, never an error pointer.
Checking the returned pointer using IS_ERR_OR_NULL() is needless
overhead.  Use a simple !ptr check instead.

OMAP devices (oh->od) always have a valid platform device attached (see
omap_device_alloc()) so there's no point validating the platform device
pointer (we will have already oopsed long before if this is not the
case here.)

Lastly, oh->od is only ever NULL or a valid omap device pointer - 'oh'
comes from the statically declared hwmod tables, and the pointer is
only filled in by omap_device_alloc() at a point where the omap device
pointer must be valid.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      857835c6
  25. 30 4月, 2013 2 次提交
  27. 24 4月, 2013 2 次提交
    • A
      ARM: OMAP: remove unused variable · 405f5e5e
      由 Arnd Bergmann 提交于 
      Commit 0583fe47 "ARM: convert arm/arm64 arch timer to use CLKSRC_OF init"
has left the omap5_realtime_timer_init() function with a stale variable and
broken whitespace. This fixes both.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      405f5e5e
    • A
      ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7 · 4b0ed696
      由 Arnd Bergmann 提交于 
      CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
of what we are building for, which is a bug and prevents us from easily
building e.g. an ARMv7-only defconfig.

This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
ARCH_MULTI_V7, to ensure we really only build the platforms for the
CPUs we have enabled in the global multiplatform configuration step.

Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4b0ed696
  29. 23 4月, 2013 3 次提交
  31. 22 4月, 2013 1 次提交
  33. 19 4月, 2013 1 次提交
  35. 15 4月, 2013 1 次提交
  37. 12 4月, 2013 1 次提交
    • R
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init · 0583fe47
      由 Rob Herring 提交于 
      This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.

This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      0583fe47
  39. 11 4月, 2013 1 次提交
  41. 10 4月, 2013 5 次提交
    • N
      cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver · 49ded525
      由 Nishanth Menon 提交于 
      As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
 1. With device tree boot, we use cpufreq-cpu0
 2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
 a) Will only run on platforms that create the platform_device
    "omap-cpufreq".
 b) Since the platform_device is registered only when device tree nodes
    are *not* populated, omap-cpufreq driver does not conflict with
    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
    device tree nodes are present.

Inspired by commit 5553f9e2
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: NRob Herring <robherring2@gmail.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      49ded525
    • S
      ARM: Push selects for TWD/SCU into machine entries · 4c3ffffd
      由 Stephen Boyd 提交于 
      The TWD and SCU configs are selected by default as long as
MSM_SCORPIONMP is false and/or MCT is false. Implementing the
logic this way certainly saves lines in the Kconfig but it
precludes those machines which select MSM_SCORPIONMP or MCT from
participating in the single zImage effort because when those
machines are combined with other SMP capable machines the TWD and
SCU are no longer selected by default.

Push the select out to the machine entries so that we can compile
these machines together and still select the appropriate configs.

Cc: Barry Song <baohua.song@csr.com>
Acked-by: NDavid Brown <davidb@codeaurora.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: NViresh Kumar <viresh.linux@gmail.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4c3ffffd
    • S
      ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support · db4f3dab
      由 Santosh Shilimkar 提交于 
      The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.

Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
      db4f3dab
    • S
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state() · e7457253
      由 Santosh Shilimkar 提交于 
      Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
to check whether the MPU cluster lost context or not before calling
cpu_cluster_pm_exit().  This was initially done an optimization for
corner cases, where if the cluster low power entry fails for some
reason, the cluster context restore gets skipped.  However, since
reading the previous context is expensive (involving slow accesses to
the PRCM), it's better to avoid it and simply check the target cluster
state instead.

Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@linaro.org: minor changelog edits]
Signed-off-by: NKevin Hilman <khilman@linaro.org>
      e7457253
    • S
      ARM: OMAP4: CPUidle: Make C-state description field more precise · eb495d33
      由 Santosh Shilimkar 提交于 
      It is useful to know the CPU power state along with MPUSS power state
in a supported C-state. Since the data is available via sysfs, one can
avoid scrolling the source code for precise construction of C-state.
Reported-by: NNishanth Menon <nm@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
      eb495d33