* [PATCH v2] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Shawn Guo @ 2013-01-29 2:53 UTC (permalink / raw)
To: linux-arm-kernel
As multiplatform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully. For example, when
GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
will be called on all the platforms to initialize cpufreq-cpu0 driver.
To eliminate this undesired the effect, the patch changes cpufreq-cpu0
driver to have it instantiated as a platform_driver. Then it will only
run on platforms that create the platform_device "cpufreq-cpu0".
Along with the change, it also changes cpu_dev to be &pdev->dev,
so that managed functions can start working, and module build gets
supported too.
The existing users of cpufreq-cpu0 driver highbank and am33xx are also
updated accordingly to adapt the changes.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Changes since v1:
* Migrate cpufreq-cpu0 users in the same patch
Rafael,
The patch is based on Mark's highbank-cpufreq series and Nishanth's
"PM / OPP : export symbol consolidation" sereis.
Mark, AnilKumar,
I only compile-tested it on highbank and omap2. Please give it a test
no hardware to make sure cpufreq-cpu0 still works for you. Thanks.
Shawn
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/cclock33xx_data.c | 2 +-
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/io.c | 7 +++++++
drivers/cpufreq/Kconfig | 2 +-
drivers/cpufreq/cpufreq-cpu0.c | 35 ++++++++++++++++++++++-----------
drivers/cpufreq/highbank-cpufreq.c | 5 +++++
7 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 53cb380b..b945480 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -139,6 +139,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
+ .init_late = am33xx_init_late,
.timer = &omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
MACHINE_END
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..acb1620 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -850,7 +850,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "dpll_core_m5_ck", &dpll_core_m5_ck, CK_AM33XX),
CLK(NULL, "dpll_core_m6_ck", &dpll_core_m6_ck, CK_AM33XX),
CLK(NULL, "dpll_mpu_ck", &dpll_mpu_ck, CK_AM33XX),
- CLK("cpu0", NULL, &dpll_mpu_ck, CK_AM33XX),
+ CLK("cpufreq-cpu0.0", NULL, &dpll_mpu_ck, CK_AM33XX),
CLK(NULL, "dpll_mpu_m2_ck", &dpll_mpu_m2_ck, CK_AM33XX),
CLK(NULL, "dpll_ddr_ck", &dpll_ddr_ck, CK_AM33XX),
CLK(NULL, "dpll_ddr_m2_ck", &dpll_ddr_m2_ck, CK_AM33XX),
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 948bcaa..e3355df5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -106,6 +106,7 @@ void omap2430_init_late(void);
void omap3430_init_late(void);
void omap35xx_init_late(void);
void omap3630_init_late(void);
+void am33xx_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
void omap4430_init_late(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..7acfb8a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -535,6 +535,13 @@ void __init omap3630_init_late(void)
omap2_clk_enable_autoidle_all();
}
+void __init am33xx_init_late(void)
+{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+
+ platform_device_register_full(&devinfo);
+}
+
void __init am35xx_init_late(void)
{
omap_mux_late_init();
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index ea512f4..774dc1c 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -180,7 +180,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
If in doubt, say N.
config GENERIC_CPUFREQ_CPU0
- bool "Generic CPU0 cpufreq driver"
+ tristate "Generic CPU0 cpufreq driver"
depends on HAVE_CLK && REGULATOR && PM_OPP && OF
select CPU_FREQ_TABLE
help
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 90e9d73..519c2f7 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,12 +12,12 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/clk.h>
-#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/err.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/opp.h>
+#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
@@ -174,7 +174,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
.attr = cpu0_cpufreq_attr,
};
-static int cpu0_cpufreq_driver_init(void)
+static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
int ret;
@@ -189,23 +189,17 @@ static int cpu0_cpufreq_driver_init(void)
return -ENOENT;
}
- cpu_dev = get_cpu_device(0);
- if (!cpu_dev) {
- pr_err("failed to get cpu0 device\n");
- ret = -ENODEV;
- goto out_put_node;
- }
-
+ cpu_dev = &pdev->dev;
cpu_dev->of_node = np;
- cpu_clk = clk_get(cpu_dev, NULL);
+ cpu_clk = devm_clk_get(cpu_dev, NULL);
if (IS_ERR(cpu_clk)) {
ret = PTR_ERR(cpu_clk);
pr_err("failed to get cpu0 clock: %d\n", ret);
goto out_put_node;
}
- cpu_reg = regulator_get(cpu_dev, "cpu0");
+ cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
if (IS_ERR(cpu_reg)) {
pr_warn("failed to get cpu0 regulator\n");
cpu_reg = NULL;
@@ -266,7 +260,24 @@ out_put_node:
of_node_put(np);
return ret;
}
-late_initcall(cpu0_cpufreq_driver_init);
+
+static int cpu0_cpufreq_remove(struct platform_device *pdev)
+{
+ cpufreq_unregister_driver(&cpu0_cpufreq_driver);
+ opp_free_cpufreq_table(cpu_dev, &freq_table);
+
+ return 0;
+}
+
+static struct platform_driver cpu0_cpufreq_platdrv = {
+ .driver = {
+ .name = "cpufreq-cpu0",
+ .owner = THIS_MODULE,
+ },
+ .probe = cpu0_cpufreq_probe,
+ .remove = cpu0_cpufreq_remove,
+};
+module_platform_driver(cpu0_cpufreq_platdrv);
MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
MODULE_DESCRIPTION("Generic CPU0 cpufreq driver");
diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index 2ea6276..0491f1f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/of.h>
#include <linux/mailbox.h>
+#include <linux/platform_device.h>
#define HB_CPUFREQ_CHANGE_NOTE 0x80000001
#define HB_CPUFREQ_IPC_LEN 7
@@ -65,6 +66,7 @@ static struct notifier_block hb_cpufreq_clk_nb = {
static int hb_cpufreq_driver_init(void)
{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
struct device *cpu_dev;
struct clk *cpu_clk;
struct device_node *np;
@@ -104,6 +106,9 @@ static int hb_cpufreq_driver_init(void)
goto out_put_node;
}
+ /* Instantiate cpufreq-cpu0 */
+ platform_device_register_full(&devinfo);
+
out_put_node:
of_node_put(np);
return ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
From: Mark Brown @ 2013-01-29 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-3-git-send-email-arnd@arndb.de>
On Mon, Jan 28, 2013 at 09:58:17PM +0000, Arnd Bergmann wrote:
> With the new OF DMA binding, it is possible to completely avoid the
> need for platform_data for configuring a DMA channel. In cases where the
> platform has already been converted, calling dma_request_slave_channel
> should get all the necessary information from the device tree.
>
> Like the patch that converts the dw_dma controller, this is completely
> untested and is looking for someone to try it out.
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
I've no ability to test this but it looks good from a code point of view.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/bc0b0d67/attachment.sig>
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Bjorn Helgaas @ 2013-01-29 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128220904.GA21446@obsidianresearch.com>
On Mon, Jan 28, 2013 at 3:09 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Mon, Jan 28, 2013 at 03:03:55PM -0700, Stephen Warren wrote:
>> On 01/28/2013 01:18 PM, Arnd Bergmann wrote:
>> > On Monday 28 January 2013, Thomas Petazzoni wrote:
>> >> From: Thierry Reding <thierry.reding@avionic-design.de>
>> >>
>> >> [Thomas Petazzoni:
>> >> - Simplify capabilities handling.
>> >> - Move to a separate file.
>> >> - Fix mask used when writing a 4 bytes value.]
>> >>
>> >> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
>> >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> >
>> > Not even a description why this is needed?
>> >
>> > This patch (together with patch 8) seems like the most controversial
>> > one of the series, so you should better provide a really good reason
>> > why we would emulate something in software rather than using whatever
>> > hardware is there.
>>
>> At least on Tegra, there is no HW that exposes PCI configuration
>> registers for the host bridge itself. Only the root ports have exposed
>> PCI configuration registers. There was some debate re: whether a host
>> bridge device needed to exist or not. This patch makes such a device
>> exist if it's required.
Host bridges are not actually PCI devices on any architecture. The
upstream side of a host bridge is by definition not on a PCI bus. On
some architectures, it *looks* like the host bridge is a PCI device
because it responds to PCI config accesses and you can get to
configuration registers that way. But it isn't really; you can't
enumerate host bridges by using normal PCI device enumeration because
you have to somehow discover the root bus and the method of doing
config accesses to it. That is all outside the scope of PCI. Even on
the architectures where host bridges appear in PCI config space, the
only reason that works is because we assume a config access mechanism
that works for domain 0. We can't discover bridges in other domains
without help.
> If Linux will discover properly (I strongly suspect it does) without
> the host bridge, then I would say to ditch this...
>
> The PCI-E standard requires a host bridge device, but if Linux doesn't
> require it then there is no reason to emulate one.
I agree that you don't need to emulate anything in the sense of making
config space accessors as this patch does.
However, I think you *should* use pci_scan_root_bus() (maybe you do
already; I haven't read all these patches), which requires that you
know the configuration of the host bridge, i.e., the config access
mechanism, the bus number range below the host bridge, and the I/O and
MMIO apertures through the bridge. The PCI core builds a logical host
bridge structure internally from that information, and that's all
Linux really needs.
Bjorn
^ permalink raw reply
* [PATCH v2] video: Kconfig: Specify the SoCs that make use of FB_IMX
From: Shawn Guo @ 2013-01-29 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121035135.GA2272@S2100-06.ap.freescale.net>
Fabio,
On Mon, Jan 21, 2013 at 11:51:38AM +0800, Shawn Guo wrote:
> On Sat, Jan 19, 2013 at 08:15:37AM -0200, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> >
> > FB_IMX is the framebuffer driver used by MX1, MX21, MX25 and MX27 processors.
> >
> > Pass this information to the Kconfig text to make it clear.
> >
> > Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > Shawn,
> >
> > Could you get this one also via your tree?
> >
> > No response from the fb maintainer for months on this one.
> >
I just dropped the patch as it seems that Andrew starts collecting
FB patches. Please send it to him instead. Sorry.
Shawn
> Ok. Applied.
^ permalink raw reply
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Keun-O Park @ 2013-01-29 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128125023.GA2027@linaro.org>
On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave.martin@linaro.org> wrote:
> On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
>> Hello guys,
>>
>> Could you please review the patch of fixing bug first of returning
>> wrong address when using frame pointer?
>> I am wondering if the first patch is not delivered to the mailing.
>
> I posted a similar patch to alkml a couple of months ago, but I got
> no response and it looks like I forgot about it.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html
Yes, same except initialization of data.addr. :)
This means there might be no one interested in using
ftrace-irqsoff/premptoff in ARM during a couple of months?
>
> [...]
>
>>
>> ~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
>> From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
>> From: sahara <keun-o.park@windriver.com>
>> Date: Thu, 3 Jan 2013 17:12:37 +0900
>> Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx
>>
>> This makes return_address return correct value for ftrace feature.
>> unwind_frame does not update frame->lr but frame->pc for backtrace.
>> And, the initialization for data.addr was missing so that wrong value
>> returned when unwind_frame failed.
>>
>> Signed-off-by: sahara <keun-o.park@windriver.com>
>> ---
>> arch/arm/kernel/return_address.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
>> index 8085417..fafedd8 100644
>> --- a/arch/arm/kernel/return_address.c
>> +++ b/arch/arm/kernel/return_address.c
>> @@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
>> struct return_address_data *data = d;
>>
>> if (!data->level) {
>> - data->addr = (void *)frame->lr;
>> + data->addr = (void *)frame->pc;
>>
>> return 1;
>> } else {
>> @@ -41,7 +41,8 @@ void *return_address(unsigned int level)
>> struct stackframe frame;
>> register unsigned long current_sp asm ("sp");
>>
>> - data.level = level + 1;
>> + data.level = level + 2;
>> + data.addr = NULL;
>
> Can you explain why this is needed? I think I concluded it wasn't
> necessary, but you may be right -- I think if walk_stackframe()
> fails to unwind the next frame just after data.level reaches zero,
> then data.addr can remain unset and return_address() may return
> uninitialised garbage.
That's correct.
Here is the examples of reproducing the problem.
I added one line printk for test in wakeup_flusher_threads() in
fs/fs-writeback.c.
And then after boot up, I synced.
[TEST#1 : print CALLER_ADDR0, 1 and 2]
Without initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac),
CALLER_ADDR1=(ret_fast_syscall+0x0/0x48),
CALLER_ADDR2=(ret_fast_syscall+0x0/0x48)
With initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac),
CALLER_ADDR1=(ret_fast_syscall+0x0/0x48), CALLER_ADDR2=( (null))
[TEST#2 : print CALLER_ADDR0 and 2]
Without initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac), CALLER_ADDR2=(0x872fffb0)
With initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac), CALLER_ADDR2=((null))
As you see, when unwind_fame() fails right after data.level reaches zero,
the routine returns data.addr which has uninitialized garbage value.
-- kpark
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: emev2: Add reg and device_type properties to cpus
From: Simon Horman @ 2013-01-29 2:10 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/emev2.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index eb504a6..2b6d1c0 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -16,10 +16,14 @@
cpus {
cpu at 0 {
+ device_type = "cpu";
compatible = "arm,cortex-a9";
+ reg = <0>;
};
cpu at 1 {
+ device_type = "cpu";
compatible = "arm,cortex-a9";
+ reg = <1>;
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v6 2/2] ARM: davinci: Remoteproc platform device creation data/code
From: Tivy, Robert @ 2013-01-29 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5103EB69.5070101@mvista.com>
Hi Sergei,
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Saturday, January 26, 2013 6:43 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Added a new remoteproc platform device for DA8XX. Contains CMA-based
> > reservation of physical memory block. A new kernel command-line
> > parameter has been added to allow boot-time specification of the
> > physical memory block.
>
> No signoff again.
Thanks, I will fix this.
>
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
> davinci/devices-da8xx.c
> > index fb2f51b..a455e5c 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> [...]
> > @@ -706,6 +706,96 @@ int __init da850_register_mmcsd1(struct
> davinci_mmc_config *config)
> > }
> > #endif
> >
> > +static struct resource da8xx_rproc_resources[] = {
> > + { /* DSP boot address */
> > + .start = DA8XX_SYSCFG0_BASE +
> DA8XX_HOST1CFG_REG,
> > + .end = DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG + 3,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + { /* DSP interrupt registers */
> > + .start = DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG,
> > + .end = DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG + 7,
> > + .flags = IORESOURCE_MEM,
>
> Does it really make sense to pass these as 2 resources -- they have
> the
> same base address?
I didn't want to impart that knowledge on the remoteproc driver. As far as the driver is concerned, there is a boot address register and some interrupt-related registers. That the boot address and interrupt-related registers share the same base address is a device-specific fact.
>
> > +int __init da8xx_register_rproc(void)
> > +{
> > + int ret;
> > +
> > + ret = platform_device_register(&da8xx_dsp);
> > + if (ret) {
> > + pr_err("%s: platform_device_register: %d\n", __func__,
> ret);
>
> Better message would be "can't register DSP device".
Agreed, I will change this.
>
> > +
>
> Empty line hardly needed here.
>
> > + return ret;
>
> Not needed here, just move it outside the {} to replace 'return 0'.
Thanks, I will change this.
Regards,
- Rob
>
> > + }
> > +
> > + return 0;
> > +};
> > +
>
> WBR, Sergei
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Kim Phillips @ 2013-01-29 1:30 UTC (permalink / raw)
To: linux-arm-kernel
Enable the compiler intrinsic for byte swapping on arch ARM. This
allows the compiler to detect and be able to optimize out byte
swappings, e.g. in big endian to big endian moves.
AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
and for the 16-bit version in 4.8.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
based on linux-next. Depends on commit "compiler-gcc{3,4}.h: Use
GCC_VERSION macro" by Daniel Santos <daniel.santos@pobox.com>,
currently in the akpm branch.
RFC because of unfamiliarity with arch ARM, and that at91sam9rl,
at91rm9200, and lpd270 (so far, at least) builds fail with:
include/uapi/linux/swab.h:60: undefined reference to `__bswapsi2'
I'm using eldk-5.2.1/armv7a's arm-linux-gnueabi-gcc (GCC) 4.6.4
20120303 (prerelease)
arch/arm/Kconfig | 1 +
include/linux/compiler-gcc4.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index eda8711..437d11a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+ select ARCH_USE_BUILTIN_BSWAP
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 68b162d..da5f728 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -67,7 +67,8 @@
#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
-#if GCC_VERSION >= 40400
+#if (!defined(__arm__) && GCC_VERSION >= 40400) || \
+ (defined(__arm__) && GCC_VERSION >= 40600)
#define __HAVE_BUILTIN_BSWAP32__
#define __HAVE_BUILTIN_BSWAP64__
#endif
--
1.7.9.7
^ permalink raw reply related
* [PATCH v2] mtd: gpmi: add sanity check for the ECC
From: Huang Shijie @ 2013-01-29 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359093848-22301-2-git-send-email-b32955@freescale.com>
We do the check based on the following two facts:
[1] The mx23/mx28 can only support 20-bits ECC, while the mx6
can supports 40-bits ECC.
[2] The mx23/mx28 can only support the GF13, while the mx6
can supports GF13 and GF14.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
v1 --> v2:
[1] add the Golois Field check.
[2] change the comments.
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 28 ++++++++++++++++++++++++++--
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 4 ++++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 2521678..717881a 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -94,6 +94,25 @@ static inline int get_ecc_strength(struct gpmi_nand_data *this)
return round_down(ecc_strength, 2);
}
+static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
+{
+ struct bch_geometry *geo = &this->bch_geometry;
+
+ /* Do the sanity check. */
+ if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
+ /* The mx23/mx28 only support the GF13. */
+ if (geo->gf_len == 14)
+ return false;
+
+ if (geo->ecc_strength > MXS_ECC_STRENGTH_MAX)
+ return false;
+ } else if (GPMI_IS_MX6Q(this)) {
+ if (geo->ecc_strength > MX6_ECC_STRENGTH_MAX)
+ return false;
+ }
+ return true;
+}
+
int common_nfc_set_geometry(struct gpmi_nand_data *this)
{
struct bch_geometry *geo = &this->bch_geometry;
@@ -123,8 +142,13 @@ int common_nfc_set_geometry(struct gpmi_nand_data *this)
/* We use the same ECC strength for all chunks. */
geo->ecc_strength = get_ecc_strength(this);
- if (!geo->ecc_strength) {
- pr_err("wrong ECC strength.\n");
+ if (!gpmi_check_ecc(this)) {
+ dev_err(this->dev,
+ "We can not support this nand chip."
+ " Its required ecc strength(%d) is beyond our"
+ " capability(%d).\n", geo->ecc_strength,
+ (GPMI_IS_MX6Q(this) ? MX6_ECC_STRENGTH_MAX
+ : MXS_ECC_STRENGTH_MAX));
return -EINVAL;
}
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 3d93a5e..0729477 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -284,6 +284,10 @@ extern int gpmi_read_page(struct gpmi_nand_data *,
#define STATUS_ERASED 0xff
#define STATUS_UNCORRECTABLE 0xfe
+/* BCH's bit correction capability. */
+#define MXS_ECC_STRENGTH_MAX 20 /* mx23 and mx28 */
+#define MX6_ECC_STRENGTH_MAX 40
+
/* Use the platform_id to distinguish different Archs. */
#define IS_MX23 0x0
#define IS_MX28 0x1
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: kyungsik.lee @ 2013-01-29 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128142510.68092e10.akpm@linux-foundation.org>
On 2013-01-29 ?? 7:25, Andrew Morton wrote:
> On Sat, 26 Jan 2013 14:50:43 +0900
> Kyungsik Lee <kyungsik.lee@lge.com> wrote:
>
>> This patchset is for supporting LZ4 compressed kernel and initial ramdisk on
>> the x86 and ARM architectures.
>>
>> According to http://code.google.com/p/lz4/, LZ4 is a very fast lossless
>> compression algorithm and also features an extremely fast decoder.
>>
>> Kernel Decompression APIs are based on implementation by Yann Collet
>> (http://code.google.com/p/lz4/source/checkout).
>> De/compression Tools are also provided from the site above.
>>
>> The initial test result on ARM(v7) based board shows that the size of kernel
>> with LZ4 compressed is 8% bigger than LZO compressed but the decompressing
>> speed is faster(especially under the enabled unaligned memory access).
>>
>> Test: 3.4 based kernel built with many modules
>> Uncompressed kernel size: 13MB
>> lzo: 6.3MB, 301ms
>> lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access)
>>
>> It seems that it___s worth trying LZ4 compressed kernel image or ramdisk
>> for making the kernel boot more faster.
>>
>> ...
>>
>> 20 files changed, 663 insertions(+), 3 deletions(-)
>>
>> ...
>>
> What's this "with enabled unaligned memory access" thing? You mean "if
> the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
> that's only x86, which isn't really in the target market for this
> patch, yes?
Yes, exactly. If the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS,
then it is expected more boot-time improvement by LZ4-decompressor.
Currently there are two architectures which support it in mainline; x86 and powerpc.
And it is expected that ARM arch(v6 or above) also support it since the commit below.
Commit ID: 5010192d5
ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above
by Dave Martin
The test results(167ms) come from the ARM(v7 arch), MSM8960 based board with
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS set.
>
> It's a lot of code for a 50ms boot-time improvement. Does anyone have
> any opinions on whether or not the benefits are worth the cost?
>
Not only for the kernel but also the ramdisk can be compressed with LZ4 so
the boot-time would be more improved. The test case above didn't include
the decompressing time result for LZ4-compressed ramdisk.
So far the implementation is applicable to boot-time improvement for
LZ4-compressed kernel and ramdisk images but the decompressor module is
exported as an interface for other usages like LZO.
With LZ4 compressor(not yet implemented for the kernel), it is expected
that it will be used in many places in kernel such as crypto and fs(squashfs, btrfs).
Thanks,
Kyungsik
^ permalink raw reply
* [PATCH v5 31/45] blackfin/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-29 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOS58YN_r-ahRvPekOo_84bM7z3YcFw1EA7DcTf0NVyEhv7ssA@mail.gmail.com>
On 01/29/2013 06:06 AM, Tejun Heo wrote:
> Hello, Bob.
>
> On Mon, Jan 28, 2013 at 1:09 AM, Bob Liu <lliubbo@gmail.com> wrote:
>> Thanks, will be applied to my blackfin arch tree.
>
> I think we still have some work ahead of us to have this patchset
> ready for inclusion and even then it probably would be best to route
> these patches together, so probably not a very good idea to apply this
> to blackfin right now.
>
Thanks Tejun for pointing that out! I'll address the review comments
soon and respin the patchset.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Shawn Guo @ 2013-01-29 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128220026.GC3047@quad.lixom.net>
On Mon, Jan 28, 2013 at 02:00:26PM -0800, Olof Johansson wrote:
> Hi,
>
> On Tue, Jan 22, 2013 at 10:48:15PM +0800, Shawn Guo wrote:
>
> > Shawn Guo (4):
> > ARM: dts: imx: use nodes label in board dts
>
> Hmm.
>
> This patch is 1000 lines of pure churn. Sure, the style on OMAP is different,
> but there's no clear benefit from it -- it's actually advantageous to see some
> of the bus hierarchies even on the leaf-level board nodes.
>
> Would you mind respinning with this left out, please? If you still want to
> argue it to be included, we can do so, but I'd like to pick up the rest of the
> branch meanwhile. :-)
I will refresh the pull-request to leave it out, but meanwhile I'd like
to argue too, as the approach has been agreed by IMX people and all the
patches I queued on imx/dt are all in this way. And I will move the
patch to imx/dt branch instead, if you're not strongly against the
approach.
The board level dts are mostly used to add/overwrite properties for
nodes defined in soc dts. Therefore, what people who look at board
dts care about is those properties, not really which bus the nodes
are on. We go this way to have board dts focus on the things they
are created for. It's much easer to read and edit those properties.
I'm not sure why it's important to maintain the bus topology in board
dts while we have the full one in soc dts. In the current way, people
sometimes have to reassemble 3 or more levels bus hierarchies for only
overwriting one property for one node.
I'm pretty sure that people who work on board level dts would vote for
this way. It makes their life easier without increasing the
maintainer's burden. So why not?
Shawn
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-29 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128223148.GA10275@schnuecks.de>
On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
> Hi Jason,
>
> On Sun, Jan 27, 2013 at 10:24:31AM -0500, Jason Cooper wrote:
> > On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> > > On 01/27/2013 03:46 PM, Jason Cooper wrote:
> > > >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> > > >>post a follow-up patch to Jason's cleanup patches that will also
> > > >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> > > >>does work just fine here on Dove.
> > > >
> > > >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> > > >boot, it's clocks get gated, then when he loads the driver, there is no
> > > >mac address. Is that correct Simon? I don't think unloading the driver
> > > >after boot will trigger this regression.
> > >
> > > Loading and unloading the driver module hangs because of the missing
> > > clk_prepeare_enable in shared driver part. This should be fixed by the
> > > patch I sent you.
> > >
> > > Dove and Kirkwood have the same gbe internally and I can boot into Dove
> > > without mv643xx_eth, load, unload, reload the module and it always finds
> > > its MAC address.
> > >
> > > I just want Simon to confirm that Kirkwood's gbe is really loosing the
> > > contents of its MAC address registers during gated clocks, which is from
> > > a HW point of view very unlikely.
> >
> > Ok, I just wanted to make sure we understood his problem correctly, and
> > if possible, reproduce it.
> >
> > Simon, can you give us some steps to reproduce this on our side so we
> > can see exactly what's happening?
>
> Nothing special here. My config originally based on a Debian config
> for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
> build as a module and is loaded from an initrd.
> Because all relevant drivers are loaded as modules, I need my
> runit patch to boot at all.
Let's back up. If you config early printk and COMMON_CLK_DEBUG and a
vanilla v3.8-rc5 with your current config, what happens?
Could you also please try kirkwood_defconfig and tell us if it boots?
thx,
Jason.
>
> Here are my findings with various patches: ("non-DT" means booting
> the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
> Development Board???, which works reasonably well)
>
> 3.8-rc5 + runit patch:
>
> DT: Hangs at boot (when loading mv643xx_eth)
> non-DT: Boots ok
>
> 3.8-rc5 + runit patch + ge00/ge01 patch:
>
> DT: Boots ok
> non-DT: Boots ok
>
> 3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> legacy clock names):
>
> DT: Boots, but no MAC
> non-DT: Boots ok
>
> 3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
> load:
>
> DT: Boots, but no MAC
> non-DT: Boots, but no MAC
>
>
> hth,
> Simon
>
>
^ permalink raw reply
* [PATCH 12/15] ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
From: Simon Horman @ 2013-01-29 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128105933.GC7754@e106331-lin.cambridge.arm.com>
On Mon, Jan 28, 2013 at 10:59:33AM +0000, Mark Rutland wrote:
> On Mon, Jan 28, 2013 at 12:48:19AM +0000, Simon Horman wrote:
> > On Fri, Jan 25, 2013 at 10:22:10AM +0000, Mark Rutland wrote:
> > > On Fri, Jan 25, 2013 at 03:55:30AM +0000, Simon Horman wrote:
> > > > This allows the GIC interrupt controller of the sh73a0 SoC to be
> > > > initialised using a flattened device tree blob.
> > > >
> > > > It does not allow the INTC interrupt controller which is also present on
> > > > the sh73a0 SoC to be enabled via device tree. Nor does it handle sharing
> > > > of interrupts between the GIC and INTC interrupt controllers.
> > > >
> > > > This limits the usefulness of this code to applications which only wish to
> > > > access devices which use interrupts that can be handled by the GIC
> > > > interrupt controller. Other applications should, for now, continue using
> > > > non-device tree initialisation of the sh72a0 interrupt controllers.
> > > >
> > > > Includes update to use irqchip_init() by Thierry Reding
> > > >
> > > > Cc: Thierry Reding <thierry.reding@avionic-design.de>
> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > > ---
> > > > arch/arm/boot/dts/sh73a0.dtsi | 33 ++++++++++++++++++++++++++
> > > > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > > > arch/arm/mach-shmobile/intc-sh73a0.c | 9 +++++++
> > > > 3 files changed, 43 insertions(+)
> > > > create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
> > > >
> > > > diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
> > > > new file mode 100644
> > > > index 0000000..7dae1f4
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/sh73a0.dtsi
> > > > @@ -0,0 +1,33 @@
> > > > +/*
> > > > + * Device Tree Source for the SH73A0 SoC
> > > > + *
> > > > + * Copyright (C) 2012 Renesas Solutions Corp.
> > > > + *
> > > > + * This file is licensed under the terms of the GNU General Public License
> > > > + * version 2. This program is licensed "as is" without any warranty of any
> > > > + * kind, whether express or implied.
> > > > + */
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > > +
> > > > +/ {
> > > > + compatible = "renesas,sh73a0";
> > > > +
> > > > + cpus {
> > > > + cpu at 0 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > > > + cpu at 1 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > >
> > > I replied to v1, not realising you'd posted a v2:
> > >
> > > It would be good to have the reg and device_type properties set here for the
> > > logical map.
> >
> > Thanks.
> >
> > I'd prefer to handle this as an incremental patch to be applied after the
> > pull-request in which the patch above appears. The patch below is what
> > I have in mind.
>
> Sure. The patch looks right to me :)
>
> >
> > I also believe that the following files seem to be targets for a similar
> > change. The latter two are for UP boards, could you comment on if reg
> > and device_type are appropriate for them too.
> >
> > arch/arm/boot/dts/emev2.dtsi
>
> Yup, this one should have reg and device_type added.
Thanks, I'll prepare a patch.
> > arch/arm/boot/dts/r8a7740.dtsi
> > arch/arm/boot/dts/sh7372.dtsi
>
> I'm not sure what the deal is with v7 UP hardware. For v6 and below, the lack
> of an MPIDR means there's nothing to describe. On v7 we should have an MPIDR
> with Aff fields at least, so there is something to describe (even if we don't
> use this currently). I don't believe this would cause any problems, and it
> would make the dts look consistent.
>
> I've Cc'd Lorenzo in case he has any thoughts on the matter.
Understood, I'll wait to see if Lorenzo can guide me.
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Jason Cooper @ 2013-01-29 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106E6A6.7010207@web.de>
On Mon, Jan 28, 2013 at 09:59:18PM +0100, Soeren Moch wrote:
> On 23.01.2013 19:10, Andrew Lunn wrote:
> >>>>
> >>>
> >>>Now (in the last hour) stable, occasionally lower numbers:
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> >>>3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3394 3396 3396 3396 3396 3396 3396 3396
> >>>
> >>>Before the last pool exhaustion going down:
> >>>3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> >>>3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> >>>3247 3247 3247 3242 3236 3236
> >>>
> >>Here I stopped vdr (and so closed all dvb_demux devices), the number
> >>was remaining the same 3236, even after restart of vdr (and restart
> >>of streaming).
> >
> >So it does suggest a leak. Probably somewhere on an error path,
> >e.g. its lost video sync.
> >
>
> Now I activated the debug messages in em28xx. From the messages I
> see no correlation of the pool exhaustion and lost sync. Also I
> cannot see any error messages from the em28xx driver.
> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
> draining the coherent pool (checked with 'cat
> /debug/dma-api/num_free_entries', which gave stable numbers), but
> after half an hour there are only init_isoc messages without
> corresponding stop_urbs messages and num_free_entries decreased
> until coherent pool exhaustion.
>
> Any idea where the memory leak is? What is allocating coherent
> buffers for orion-ehci?
Keeping in mind that I am completely unfamiliar with usb dvb, my best
guess is that the problem is in em28xx-core.c:1131
According to your log messages, it is in mode 2, which is
EM28XX_DIGITAL_MODE.
There seem to be good hints in
86d38d1e [media] em28xx: pre-allocate DVB isoc transfer buffers
I added the relevant parties to the To:...
For Gianluca and Mauro, the whole thread may be found at:
http://markmail.org/message/wm4wlgzoudixd4so#query:+page:1+mid:o7phz7cosmwpcsrz+state:results
thx,
Jason.
>
> Soeren
>
>
> Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent
> pool is too small!
> Jan 28 20:54:33 guruvdr kernel: Please increase it with
> coherent_pool= kernel parameter!
>
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: John Stultz @ 2013-01-29 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510615F8.7010203@ti.com>
On 01/27/2013 10:08 PM, Santosh Shilimkar wrote:
> On Tuesday 22 January 2013 08:35 PM, Santosh Shilimkar wrote:
>> On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote:
>>> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
>>>> Sorry for not being clear enough. On OMAP, 32KHz is the only clock
>>>> which
>>>> is always running(even during low power states) and hence the clock
>>>> source and clock event have been clocked using 32KHz clock. As
>>>> mentioned
>>>> by RMK, with 32768 Hz clock and HZ = 100, there will be always an
>>>> error of 0.1 %. This accuracy also impacts the timer tick interval.
>>>> This was the reason, OMAP has been using the HZ = 128.
>>>
>>> Ok. Let's look at this. As far as time-of-day is concerned, this
>>> shouldn't really matter with the clocksource/clockevent based system
>>> that we now have (where *important point* platforms have been converted
>>> over.)
>>>
>>> Any platform providing a clocksource will override the jiffy-based
>>> clocksource. The measurement of time-of-day passing is now based on
>>> the difference in values read from the clocksource, not from the actual
>>> tick rate.
>>>
>>> Anything _not_ providing a clock source will be reliant on jiffies
>>> incrementing, which in turn _requires_ one timer interrupt per jiffies
>>> at a known rate (which is HZ).
>>>
>>> Now, that's the time of day, what about jiffies? Well, jiffies is
>>> incremented based on a certain number of nsec having passed since the
>>> last jiffy update. That means the code copes with dropped ticks and
>>> the like.
>>>
>>> However, if your actual interrupt rate is close to the desired HZ, then
>>> it can lead to some interesting effects (and noise):
>>>
>>> - if the interrupt rate is slightly faster than HZ, then you can end up
>>> with updates being delayed by 2x interrupt rate.
>>> - if the interrupt rate is slightly slower than HZ, you can
>>> occasionally
>>> end up with jiffies incrementing by two.
>>> - if your interrupt rate is dead on HZ, then other system noise can
>>> come
>>> into effect and you may get maybe zero, one or two jiffy increments
>>> per
>>> interrupt.
>>>
>>> (You have to think about time passing in NS, where jiffy updates should
>>> be vs where the timer interrupts happen.) See
>>> tick_do_update_jiffies64()
>>> for the details.
>>>
>>> The timer infrastructure is jiffy based - which includes scheduling
>>> where
>>> the scheduler does not use hrtimers. That means a slight discrepency
>>> between HZ and the actual interrupt rate can cause around 1/HZ jitter.
>>> That's a matter of fact due to how the code works.
>>>
>>> So, actually, I think the accuracy of HZ has much overall effect
>>> _provided_
>>> a platform provides a clocksource to the accuracy of jiffy based timers
>>> nor timekeeping. For those which don't, the accuracy of the timer
>>> interrupt to HZ is very important.
>>>
>>> (This is just based on reading some code and not on practical
>>> experiments - I'd suggest some research of this is done, trying HZ=100
>>> on OMAP's 32kHz timers, checking whether there's any drift, checking
>>> how accurately a single task can be woken from various
>>> select/poll/epoll
>>> delays, and checking whether NTP works.)
>>>
>> Thanks for expanding it. It is really helpful.
>>
>>> And I think further discussion is pointless until such research has
>>> been
>>> done (or someone who _really_ knows the time keeping/timer/sched code
>>> inside out comments.)
>>>
>> Fully agree about experimentation to re-asses the drift.
>> From what I recollect from past, few OMAP customers did
>> report the time drift issue and that is how the switch
>> from 100 --> 128 happened.
>>
>> Anyway I have added the suggested task to my long todo list.
>>
> So I tried to see if any time drift with HZ = 100 on OMAP. I ran the
> setup for 62 hours and 27 mins with time synced up once with NTP server.
> I measure about ~174 millisecond drift which is almost noise considering
> the observed duration was ~224820000 milliseconds.
So 174ms drift doesn't sound great, as < 2ms (often much less - though
that depends on how close the server is) can be expected with NTP.
Although its not clear how you were measuring: Did you see a max 174ms
offset while trying to sync with NTP? Was that offset shortly after
starting NTP or after NTP converged down?
thanks
-john
^ permalink raw reply
* [PATCH v6 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Tivy, Robert @ 2013-01-28 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5103F47C.4020509@mvista.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Saturday, January 26, 2013 7:22 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
>
> > diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> > new file mode 100644
> > index 0000000..c6eb6bf
> > --- /dev/null
> > +++ b/drivers/remoteproc/da8xx_remoteproc.c
> > @@ -0,0 +1,327 @@
> [...]
> > +#define SYSCFG_CHIPSIG_OFFSET 0x174
> > +#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
>
> Wait, you don't even use these #define's -- why they're here at
> all?
>
> WBR, Sergei
I will remove those. They were inadvertently left over from when the driver was mapping SYSCFG0's base address and using those offsets to get to the CHIPSIG registers.
Regards,
- Rob
^ permalink raw reply
* [PATCH 15/19] sunrpc: don't warn for unused variable 'buf'
From: J. Bruce Fields @ 2013-01-28 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301261334.56398.arnd@arndb.de>
On Sat, Jan 26, 2013 at 01:34:56PM +0000, Arnd Bergmann wrote:
> On Saturday 26 January 2013, Russell King - ARM Linux wrote:
> > On Fri, Jan 25, 2013 at 11:45:25PM +0000, Arnd Bergmann wrote:
> > > On Friday 25 January 2013, Myklebust, Trond wrote:
> > > > > -----Original Message-----
> > > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > Marking it as __maybe_unused avoids a harmless gcc warning.
> > > >
> > > > Alternatively, just declare it using the RPC_IFDEBUG() macro.
> > >
> > > Right, makes sense: that's more consistent with other functions
> > > doing the same thing. Thanks for taking a look.
> >
> > NAK.
> >
> > There is already a fix queued up as a result of a previous report I
> > sent, but for some reason (which I didn't question) it was decided
> > not to queue it for -rc.
> >
> > See Bruce's reply on lkml: 20130108212816.GA24572 at fieldses.org
Apologies, I've seen so many "stop sending me post-rc1 patches that
don't fix serious crashes!" flames.
I guess obviousl compile fixes should be an exception--if nothing else
it'd save a lot of duplicated work as this is something like the 3rd
patch I've seen for this.
--b.
>
> Ok, makes sense. Then again, if that fix is queued for 3.9, maybe
> it still makes sense to take the simpler fix into 3.8, and remove
> it in 3.9 along with the other instances of RPC_IFDEBUG.
^ permalink raw reply
* [PATCH 5/5] ARM: ux500: select the DB8540 pin controller
From: Olof Johansson @ 2013-01-28 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381151-28127-1-git-send-email-linus.walleij@stericsson.com>
On Mon, Jan 28, 2013 at 02:52:31PM +0100, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The pin controller is an inherent part of the SoC, without
> it the system will not boot, thus it needs to be selected
> from Kconfig.
>
> Cc: arm at kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Requesting ACK from ARM SoC on this patch.
Acked-by: Olof Johansson <olof@lixom.net>
... but I wonder if this is growing out of hand. Since they will always
be selected (and required) for UX500_SOC_DB8500, why not just make them
silent options that default to y with that as a depend?
-Olof
^ permalink raw reply
* [PATCH 1/5] pinctrl/abx500: add AB8500 sub-driver
From: Olof Johansson @ 2013-01-28 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359380995-27950-1-git-send-email-linus.walleij@stericsson.com>
On Mon, Jan 28, 2013 at 02:49:55PM +0100, Linus Walleij wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> This adds a subdriver for the AB8500 pinctrl portions.
> As the pin controller (also the ABx500 controllers) is an
> inherent part of the SoC and will prevent boot if not
> available, select this from the Ux500 SoC Kconfig.
>
> Cc: arm at kernel.org
> Reviewed-by: Stephen Warren <swarren@nvidia.com>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Requesting an ACK from the ARM SoC maintainers for this patch.
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Jason Gunthorpe @ 2013-01-28 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128233048.2ab6a6d2@skate>
On Mon, Jan 28, 2013 at 11:30:48PM +0100, Thomas Petazzoni wrote:
> Dear Jason Gunthorpe,
>
> On Mon, 28 Jan 2013 15:23:48 -0700, Jason Gunthorpe wrote:
>
> > I'm refering to your earlier question about what PCI IDs to use for
> > the SW emulated devices. If there is no need for the host bridge then
> > you only need 1 PCI ID (for the root port bridge) and you can probably
> > fairly safely re-use the one in the Marvell config space of the HW.
>
> Ah, ok, I see. But isn't a host bridge needed to bind all the
> PCI-to-PCI bridges under a single bus, in order to get the global
> resource assignment I was referring to?
The PCI-E spec requires it, but AFAIK it doesn't actually *do*
anything on Linux, and Linux doesn't require it.
I thought Thierry did this experiment and decided it wasn't necessary:
> The reason is that with the latest bindings the matching of root
> ports to device tree nodes works as-is and nothing else indicates
> that the emulated host bridge is actually required to make any of
> this work. So in order not to introduce unneeded code I've left it
> out for now. If somebody decides that we actually need this host
> bridge (for standards compliance or whatnot) it could easily be
> added back.
Jason
^ permalink raw reply
* [PATCH v2 11/27] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
From: Thomas Petazzoni @ 2013-01-28 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106FB47.9000508@wwwdotorg.org>
Dear Stephen Warren,
On Mon, 28 Jan 2013 15:27:19 -0700, Stephen Warren wrote:
> Oh I see; I was confused by the patch description. The two clocks being
> made child/parent are the two clocks for a port, and this relationship
> is set up for each port; for some reason I thought there was a
> requirement to make one port's clock a child of the other port's clock.
Aah, ok, I understand the confusion now. Re-reading my commit log, I'm
not sure where the confusion comes from, but english is not my native
language, so maybe something that sounds clear to me is not clear in
reality. I'll rephrase the commit log to make sure this confusion is
clarified.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] Nomadik devicetree and cleanups
From: Linus Walleij @ 2013-01-28 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128213135.GA3047@quad.lixom.net>
On Mon, Jan 28, 2013 at 10:31 PM, Olof Johansson <olof@lixom.net> wrote:
> Would you mind rebasing on top of the depends/cleanup branch in arm-soc, sort
> out the breakage (and test it) and resubmit?
So Olof, please try this instead, based on the ARM depends/cleanup HEAD
when I fetched it:
The following changes since commit f8060f5446b1f2782f0a8ca9be2d870ea4198aee:
Merge tag 'gic-vic-to-irqchip' of
git://sources.calxeda.com/kernel/linux into next/cleanup (2013-01-14
19:55:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/nmk-dt-on-cleanups
for you to fetch changes up to dea3eacd087cfa692ea20aafbfaf4827607afe45:
ARM: nomadik: get rid of <mach/hardware.h> (2013-01-28 23:25:40 +0100)
----------------------------------------------------------------
Nomadik Device Tree conversion rebased on ARM SoC cleanup branch
This patch set converts the Nomadik (mach-nomadik) to
Device Tree and delete the old board files, paving the
road for single zImage.
----------------------------------------------------------------
Linus Walleij (11):
ARM: nomadik: move last custom calls to pinctrl
ARM: nomadik: initial devicetree support
ARM: nomadik: move pin maps to cpu file
ARM: nomadik: move remaining PrimeCells to device tree
ARM: nomadik: add FSMC NAND
ARM: nomadik: move GPIO and pinctrl to device tree
ARM: nomadik: convert SMSC91x ethernet to device tree
ARM: nomadik: migrate MMC/SD card support to device tree
ARM: nomadik: add I2C devices to the device tree
ARM: nomadik: delete old board files
ARM: nomadik: get rid of <mach/hardware.h>
.../devicetree/bindings/arm/ste-nomadik.txt | 27 ++
.../devicetree/bindings/mtd/fsmc-nand.txt | 2 +-
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ste-nomadik-s8815.dts | 30 ++
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 256 +++++++++++++++
arch/arm/mach-nomadik/Kconfig | 10 +-
arch/arm/mach-nomadik/Makefile | 6 -
arch/arm/mach-nomadik/board-nhk8815.c | 353 --------------------
arch/arm/mach-nomadik/cpu-8815.c | 358 +++++++++++++++------
arch/arm/mach-nomadik/cpu-8815.h | 4 -
arch/arm/mach-nomadik/i2c-8815nhk.c | 88 -----
arch/arm/mach-nomadik/include/mach/hardware.h | 90 ------
arch/arm/mach-nomadik/include/mach/irqs.h | 2 -
arch/arm/mach-nomadik/include/mach/uncompress.h | 1 -
drivers/mtd/nand/fsmc_nand.c | 1 +
drivers/pinctrl/pinctrl-nomadik.c | 4 +
17 files changed, 588 insertions(+), 647 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/ste-nomadik.txt
create mode 100644 arch/arm/boot/dts/ste-nomadik-s8815.dts
create mode 100644 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
delete mode 100644 arch/arm/mach-nomadik/board-nhk8815.c
delete mode 100644 arch/arm/mach-nomadik/cpu-8815.h
delete mode 100644 arch/arm/mach-nomadik/i2c-8815nhk.c
delete mode 100644 arch/arm/mach-nomadik/include/mach/hardware.h
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-28 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127152431.GX1758@titan.lakedaemon.net>
Hi Jason,
On Sun, Jan 27, 2013 at 10:24:31AM -0500, Jason Cooper wrote:
> On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> > On 01/27/2013 03:46 PM, Jason Cooper wrote:
> > >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> > >>post a follow-up patch to Jason's cleanup patches that will also
> > >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> > >>does work just fine here on Dove.
> > >
> > >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> > >boot, it's clocks get gated, then when he loads the driver, there is no
> > >mac address. Is that correct Simon? I don't think unloading the driver
> > >after boot will trigger this regression.
> >
> > Loading and unloading the driver module hangs because of the missing
> > clk_prepeare_enable in shared driver part. This should be fixed by the
> > patch I sent you.
> >
> > Dove and Kirkwood have the same gbe internally and I can boot into Dove
> > without mv643xx_eth, load, unload, reload the module and it always finds
> > its MAC address.
> >
> > I just want Simon to confirm that Kirkwood's gbe is really loosing the
> > contents of its MAC address registers during gated clocks, which is from
> > a HW point of view very unlikely.
>
> Ok, I just wanted to make sure we understood his problem correctly, and
> if possible, reproduce it.
>
> Simon, can you give us some steps to reproduce this on our side so we
> can see exactly what's happening?
Nothing special here. My config originally based on a Debian config
for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
build as a module and is loaded from an initrd.
Because all relevant drivers are loaded as modules, I need my
runit patch to boot at all.
Here are my findings with various patches: ("non-DT" means booting
the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
Development Board???, which works reasonably well)
3.8-rc5 + runit patch:
DT: Hangs at boot (when loading mv643xx_eth)
non-DT: Boots ok
3.8-rc5 + runit patch + ge00/ge01 patch:
DT: Boots ok
non-DT: Boots ok
3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
legacy clock names):
DT: Boots, but no MAC
non-DT: Boots ok
3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
load:
DT: Boots, but no MAC
non-DT: Boots, but no MAC
hth,
Simon
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Thomas Petazzoni @ 2013-01-28 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128222348.GA21628@obsidianresearch.com>
Dear Jason Gunthorpe,
On Mon, 28 Jan 2013 15:23:48 -0700, Jason Gunthorpe wrote:
> I'm refering to your earlier question about what PCI IDs to use for
> the SW emulated devices. If there is no need for the host bridge then
> you only need 1 PCI ID (for the root port bridge) and you can probably
> fairly safely re-use the one in the Marvell config space of the HW.
Ah, ok, I see. But isn't a host bridge needed to bind all the
PCI-to-PCI bridges under a single bus, in order to get the global
resource assignment I was referring to?
Regarding the PCI IDs, I have started to work with Marvell to see what
is possible. I, unfortunately, haven't received the answer for now.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox