- 02 4月, 2013 3 次提交
-
-
由 Jon Hunter 提交于
In commit c59b537d (ARM: OMAP2+: Simplify dmtimer clock aliases), new clock aliases for dmtimers were added to simplify the code. These clock aliases can also be used when configuring the system timers and allow us to remove the current definitions, simplifying the code. Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is no clock alias for "timer_sys_ck" with NULL as the device name. Therefore we still need to use the alias "sys_clkin_ck" for these devices. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Currently, when configuring the clock-events and clock-source timers for OMAP2+ devices, we check whether the timer ID is 12 before attempting to set the parent clock for the timer. This test was added for OMAP3 general purpose devices (no security features enabled) that a 12th timer available but unlike the other timers only has a single functional clock source. Calling clk_set_parent() for this 12th timer would always return an error because there is only one choice for a parent clock. Therefore, this hard-coded timer ID test was added. To avoid this timer ID test, simply check to see if the timer's current parent clock is the desired parent clock and only call clk_set_parent() if this is not the case. Also if clk_get() fails, then use PTR_ERR() to return the error code. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Currently on boot, when displaying the name of the gptimer used for clockevents and clocksource timers, the timer ID is shown. However, when booting with device-tree, the timer ID is not used to select a gptimer but a timer property. Hence, it is possible that the timer selected when booting with device-tree does not match the ID shown. Therefore, instead display the HWMOD name of the gptimer and use the HWMOD name as the name of clockevent and clocksource timer (if a gptimer is used). Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 14 3月, 2013 1 次提交
-
-
由 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>
-
- 24 2月, 2013 9 次提交
-
-
由 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>
-
由 Russell King 提交于
pwrdm_can_ever_lose_context() is only ever called from the OMAP GPIO code, and only with a pointer returned from omap_hwmod_get_pwrdm(). omap_hwmod_get_pwrdm() only ever returns NULL on error, so using IS_ERR_OR_NULL() to validate the passed pointer is silly. Use a simpler !ptr check instead. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Debugfs functions return NULL when they fail, or an error pointer when not configured. The intention behind the error pointer is that it appears as a valid pointer to the caller, and so the caller continues inspite of debugfs not being available. Debugfs failure should only ever be checked with (!ptr) and not the IS_ERR*() functions. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Fix clk_get_sys() error handling; IS_ERR() should be used rather than IS_ERR_OR_NULL() to check for errors. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
regulator_get() does not return NULL as an error value. Even when it does return an error, the code as written falls out the error path while returning zero (indicating no failure.) Fix this, and use the more correct IS_ERR() macro to check for errors. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Use the correct IS_ERR() to determine if clk_get() returned an error. Set timer->fclk to be an error value initially, and check everywhere using IS_ERR(). This keeps the range of valid values for 'struct clk' consistent. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
soc_device_register() never returns NULL, it only ever returns an error pointer or a valid pointer. Use the right function (IS_ERR()) to check this. soc_device_to_device() only ever returns &soc_dev->dev, and so can never return an error or NULL if the pointer passed into it was valid, so there's no point checking its return. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Three's no need to have code initializing this by hand; it's more efficient to initialize the constant structure members directly. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
We don't need to keep reloading the thread into into r10 - we can do this once and keep the value cached in the register. Also, schedule some instructions better so that the pipeline doesn't stall after a load in the neon code. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 08 2月, 2013 4 次提交
-
-
由 Will Deacon 提交于
We have received multiple reports of mmap failures when running with a 2:2 vm split. These manifest as either -EINVAL with a non page-aligned address (ending 0xaaa) or a SEGV, depending on the application. The issue is commonly observed in children of make, which appears to use bottom-up mmap (assumedly because it changes the stack rlimit). Further investigation reveals that this regression was triggered by 394ef640 ("mm: use vm_unmapped_area() on arm architecture"), whereby TASK_UNMAPPED_BASE is no longer page-aligned for bottom-up mmap, causing get_unmapped_area to choke on misaligned addressed. This patch fixes the problem by defining TASK_UNMAPPED_BASE in terms of TASK_SIZE and explicitly aligns the result to 16M, matching the other end of the heap. Acked-by: NNicolas Pitre <nico@linaro.org> Reported-by: NSteve Capper <steve.capper@arm.com> Reported-by: NJean-Francois Moine <moinejf@free.fr> Reported-by: NChristoffer Dall <cdall@cs.columbia.edu> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Realview fails to boot with this warning: BUG: spinlock lockup suspected on CPU#0, init/1 lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0 Backtrace: [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0 [<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98) [<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x198) [<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c/0x44) [<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0xe8/0x11c) [<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_drivers.clone.7+0xdc/0x104) [<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console_unlock+0x2e8/0x454) [<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x594) [<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44) [<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c) [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c) [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_alloc+0xd8/0xf0) [<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+0x24/0x11c) [<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.clone.24+0x7c/0x16c) [<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_area_caller+0x48/0x54) [<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buffer.clone.15+0x38/0xb8) [<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_alloc+0x160/0x2c8) [<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)[<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1a8) [<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_desc+0x28/0x568) [<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_slave_sg+0x258/0x3b0) [<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_refill+0x140/0x288) [<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0xe4/0x120) [<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4c) [<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c) [<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4) [<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4) [<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240) [<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/0xac) [<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0x150) [<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78) [<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c) This happens because the DMA allocation code is not respecting atomic allocations correctly. GFP flags should not be tested for GFP_ATOMIC to determine if an atomic allocation is being requested. GFP_ATOMIC is not a flag but a value. The GFP bitmask flags are all prefixed with __GFP_. The rest of the kernel tests for __GFP_WAIT not being set to indicate an atomic allocation. We need to do the same. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Realview EB with a rev B MPcore tile results in lots of warnings at boot because it can't allocate enough IRQs. Fix this by increasing the number of available IRQs. WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:757 gic_init_bases+0x12c/0x2ec() Cannot allocate irq_descs @ IRQ96, assuming pre-allocated Modules linked in: Backtrace: [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002f5 r5:c042c62c r4:c044ff40 r3:c045f240 [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c) [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029384>] (warn_slowpath_fmt+0x38/0x40) [<c002934c>] (warn_slowpath_fmt+0x0/0x40) from [<c042c62c>] (gic_init_bases+0x12c/0x2ec) [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8) [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24) [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300) [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070) ---[ end trace 1b75b31a2719ed1c ]--- ------------[ cut here ]------------ WARNING: at /home/rmk/git/linux-rmk/kernel/irq/irqdomain.c:234 irq_domain_add_legacy+0x80/0x140() Modules linked in: Backtrace: [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000000ea r5:c0081a38 r4:00000000 r3:c045f240 [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c) [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c) [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0081a38>] (irq_domain_add_legacy+0x80/0x140) [<c00819b8>] (irq_domain_add_legacy+0x0/0x140) from [<c042c64c>] (gic_init_bases+0x14c/0x2ec) [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8) [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24) [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300) [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070) ---[ end trace 1b75b31a2719ed1d ]--- ------------[ cut here ]------------ WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:762 gic_init_bases+0x170/0x2ec() Modules linked in: Backtrace: [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002fa r5:c042c670 r4:00000000 r3:c045f240 [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c) [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c) [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c042c670>] (gic_init_bases+0x170/0x2ec) [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8) [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24) [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300) [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070) ---[ end trace 1b75b31a2719ed1e ]--- Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Punit Agrawal reports: > I was trying to boot 3.8-rc5 on Realview EB 11MPCore using > realview-smp_defconfig as a starting point but the kernel failed to > progress past the log below (config attached). > > Pawel suggested I try reverting 384a2902 - "ARM: gic: use a private > mapping for CPU target interfaces" that you've authored. With this > commit reverted the kernel boots. > > I am not quite sure why the commit breaks 11MPCore but Pawel (cc'd) > might be able to shed light on that. Some early GIC implementations return zero for the first distributor CPU routing register. This means we can't rely on that telling us which CPU interface we're connected to. We know that these platforms implement PPIs for IRQs 29-31 - but we shouldn't assume that these will always be populated. So, instead, scan for a non-zero CPU routing register in the first 32 IRQs and use that as our CPU mask. Reported-by: NPunit Agrawal <punit.agrawal@arm.com> Reviewed-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 05 2月, 2013 1 次提交
-
-
由 Kukjin Kim 提交于
Since pinctrl-exynos can support exynos4 and exynos5 so changed the option name to PINCTRL_EXYNOS for more clarity. Cc: Thomas Abraham <Thomas.abraham@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 01 2月, 2013 3 次提交
-
-
由 Rob Herring 提交于
With commit a0ae0240 (ARM: kernel: add device tree init map function), the cpu id value may include the cluster id and is no longer 0-3, so we need to mask it now to get the right hard cpu index. Signed-off-by: NRob Herring <rob.herring@calxeda.com>
-
由 Rob Herring 提交于
With commit a0ae0240 (ARM: kernel: add device tree init map function), the cpu id value may include the cluster id and is no longer 0-3, so we need to mask it in scu_power_mode to get the local cpu number. Since we are only dealing with the cpu we are running on, the cluster id should not ever be needed. Signed-off-by: NRob Herring <rob.herring@calxeda.com>
-
由 Rob Herring 提交于
Add an empty version of scu_enable for !SMP builds. This fixes compile error for highbank suspend code on !SMP builds. Signed-off-by: NRob Herring <rob.herring@calxeda.com>
-
- 24 1月, 2013 2 次提交
-
-
由 Pawel Moll 提交于
As the kernel is able to cope with multiple clusters, uncomment the A7 cores in the Device Tree for V2P-CA15_A7 tile, making all 5 cores available to the user. Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
由 Lorenzo Pieralisi 提交于
In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a single cpu identifier, affinity levels 1 and 2 must be taken into account as well. This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile secondary cores start up code in order to compare the passed pen_release value with the full-blown affinity mask. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
- 23 1月, 2013 9 次提交
-
-
由 Douglas Gilbert 提交于
Concerning pinctrl_macb0_rmii_mii, values were okay, but not comments. Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Nicolas Ferre 提交于
Reported-by: NJosh Wu <josh.wu@atmel.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Nicolas Ferre 提交于
No need for this cmdline option as we are using DT. Moreover this defconfig is targeted to multiple SoC/boards: this option was nonsense. Reported-by: NJosh Wu <josh.wu@atmel.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Boris BREZILLON 提交于
This patch overrides default macb pinctrl config defined in at91sam9260.dtsi (pinctrl_macb_rmii) with kizbox board config (pinctrl_macb_rmii + pinctrl_macb_rmii_mii_alt). Signed-off-by: NBoris BREZILLON <linux-arm@overkiz.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
Make BGA as the default version as we are supposed to just have to specify when we use the PQFP version. Issue was existing since commit: 3e90772f (ARM: at91: fix at91rm9200 soc subtype handling). Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: stable <stable@vger.kernel.org> [v3.3] Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Joachim Eastwood 提交于
Signed-off-by: NJoachim Eastwood <manabian@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Richard Genoud 提交于
The SCK pins where missing in usarts pinctrl. Signed-off-by: NRichard Genoud <richard.genoud@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Richard Genoud 提交于
The PIN_BANK 3 is for PDxx pins, not PCxx pins. And PIN_BANK 1 is for PBxx, not PIN_BANK 0. Signed-off-by: NRichard Genoud <richard.genoud@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Sebastian Hesselbarth 提交于
The gpio controller on kirkwood can provide interrupts but is missing the #interrupt-cells property. This patch just adds it to both gpio controllers. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
- 22 1月, 2013 4 次提交
-
-
由 Luciano Coelho 提交于
Add the UART2 muxing data to the board file (this used to be, erroneously, done in the bootloader). Cc: stable <stable@vger.kernel.org> [3.7] Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Pantelis Antoniou 提交于
The iterator correctly handles of_node_put() calls. Remove it before continue'ing the loop. Without this patch you get the following with CONFIG_OF_DYNAMIC set: ERROR: Bad of_node_put() on /ocp/timer@44e31000! [<c001329c>] (unwind_backtrace+0x0/0xe0) from [<c03dd8f0>] (of_node_release+0x2c/0xa0)! [<c03dd8f0>] (of_node_release+0x2c/0xa0) from [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90)! [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90) from [<c06d349c>] (omap_get_timer_dt+0x78/0x90)! [<c06d349c>] (omap_get_timer_dt+0x78/0x90) from [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc)! [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)! [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from [<c06cca58>] (time_init+0x20/0x30)! [<c06cca58>] (time_init+0x20/0x30) from [<c06c9690>] (start_kernel+0x1a8/0x2fc)! Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com> Acked-by: NJon Hunter <jon-hunter@ti.com> [tony@atomide.com: updated description per Jon] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Otherwise we will get: WARNING: vmlinux.o(.text+0x1d4f0): Section mismatch in reference from the function omap_init_ocp2scp() to the function .init.text:omap_device_build() The function omap_init_ocp2scp() references the function __init omap_device_build(). This is often because omap_init_ocp2scp lacks a __init annotation or the annotation of omap_device_build is wrong. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Rob Clark 提交于
Fixes compile break with 3.8-rc4. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 19 1月, 2013 4 次提交
-
-
由 Santosh Shilimkar 提交于
Commit 8fb54284 {ARM: mm: Add strongly ordered descriptor support} added XN flag at section level but missed it at PTE level. Fix it by adding the L_PTE_XN to MT_MEMORY_SO PTE descriptor. Reported-by: NRichard Woodruff <r-woodruff2@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Subhash Jadavani reported this partial backtrace: Now consider this call stack from MMC block driver (this is on the ARMv7 based board): [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114) This is caused by incrementing the struct page pointer, and running off the end of the sparsemem page array. Fix this by incrementing by pfn instead, and convert the pfn to a struct page. Cc: <stable@vger.kernel.org> Suggested-by: NJames Bottomley <JBottomley@Parallels.com> Tested-by: NSubhash Jadavani <subhashj@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Jon Hunter 提交于
During the migration to the common clock framework, calls to the functions omap2xxx_clkt_vps_late_init() were not preserved for OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the following error message to be displayed because the appropriate MPU clock frequency (derived from sys_ck_rate) cannot be found. "Could not set MPU rate to 4294MHz" Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the OMAP2420 and OMAP2430 clock initialisation code. Signed-off-by: NJon Hunter <jon-hunter@ti.com> [paul@pwsan.com: dropped the duplicated call to omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon; updated patch description] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Peter Ujfalusi 提交于
McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> [paul@pwsan.com: copy patch description into hwmod data comments] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-