* [RFC PATCH 2/3] mfd: syscon: Support early initialization
From: Michal Simek @ 2014-02-10 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1785585d090175da81b561b17eeef95d991ff0de.1392045742.git.michal.simek@xilinx.com>
On 02/10/2014 04:22 PM, Michal Simek wrote:
> Some platforms need to get system controller
> ready as soon as possible.
> The patch provides early_syscon_initialization
> which create early mapping for all syscon compatible
> devices in early_syscon_probe.
> Regmap is get via syscon_early_regmap_lookup_by_phandle()
>
> Regular device probes attach device to regmap
> via regmap_attach_dev().
>
> For early syscon initialization is necessary to extend
> struct syscon and provide remove function
> which unmap all early init structures.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> drivers/mfd/syscon.c | 126 +++++++++++++++++++++++++++++++++++++++------
> include/linux/mfd/syscon.h | 11 ++++
> 2 files changed, 120 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 71841f9..5935f02 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -20,12 +20,15 @@
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> +#include <linux/slab.h>
> #include <linux/mfd/syscon.h>
>
> static struct platform_driver syscon_driver;
>
> struct syscon {
> + void __iomem *base;
> struct regmap *regmap;
> + struct resource res;
> };
>
> static int syscon_match_node(struct device *dev, void *data)
> @@ -95,6 +98,24 @@ struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
> }
> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
>
> +struct regmap *syscon_early_regmap_lookup_by_phandle(struct device_node *np,
> + const char *property)
> +{
> + struct device_node *syscon_np;
> + struct syscon *syscon;
> +
> + syscon_np = of_parse_phandle(np, property, 0);
> + if (!syscon_np)
> + return ERR_PTR(-ENODEV);
> +
> + syscon = syscon_np->data;
> +
> + of_node_put(syscon_np);
> +
> + return syscon->regmap;
> +}
> +EXPORT_SYMBOL_GPL(syscon_early_regmap_lookup_by_phandle);
> +
> struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> const char *property)
> {
> @@ -128,40 +149,110 @@ static int syscon_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct syscon *syscon;
> struct resource *res;
> - void __iomem *base;
>
> - syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
> + /* Early syscon init */
> + if (pdev->dev.of_node && pdev->dev.of_node->data) {
> + syscon = pdev->dev.of_node->data;
> + res = &syscon->res;
> + regmap_attach_dev(dev, syscon->regmap, &syscon_regmap_config);
> + } else {
> +
> + syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
> + if (!syscon)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENOENT;
> +
> + syscon->base = devm_ioremap(dev, res->start,
> + resource_size(res));
> + if (!syscon->base)
> + return -ENOMEM;
> +
> + syscon_regmap_config.max_register = res->end - res->start - 3;
> + syscon->regmap = devm_regmap_init_mmio(dev, syscon->base,
> + &syscon_regmap_config);
> + if (IS_ERR(syscon->regmap)) {
> + dev_err(dev, "regmap init failed\n");
> + return PTR_ERR(syscon->regmap);
> + }
> + }
> +
> + platform_set_drvdata(pdev, syscon);
> +
> + dev_info(dev, "regmap %pR registered\n", res);
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id syscon_ids[] = {
> + { "syscon", },
> + { }
> +};
> +
> +static int syscon_remove(struct platform_device *pdev)
> +{
> + struct syscon *syscon = platform_get_drvdata(pdev);
> +
> + if (pdev->dev.of_node && pdev->dev.of_node->data) {
> + iounmap(syscon->base);
> + kfree(syscon);
> + }
> +
> + return 0;
> +}
> +
> +static int early_syscon_probe(struct device_node *np)
> +{
> + struct syscon *syscon;
> +
> + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> if (!syscon)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENOENT;
> + if (of_address_to_resource(np, 0, &syscon->res))
> + return -EINVAL;
>
> - base = devm_ioremap(dev, res->start, resource_size(res));
> - if (!base)
> - return -ENOMEM;
> + syscon->base = ioremap(syscon->res.start, resource_size(&syscon->res));
> + if (!syscon->base) {
> + pr_err("%s: Unable to map I/O memory\n", __func__);
> + return PTR_ERR(syscon->base);
> + }
>
> - syscon_regmap_config.max_register = res->end - res->start - 3;
> - syscon->regmap = devm_regmap_init_mmio(dev, base,
> - &syscon_regmap_config);
> + syscon_regmap_config.max_register = syscon->res.end -
> + syscon->res.start - 3;
> + syscon->regmap = regmap_init_mmio(NULL, syscon->base,
> + &syscon_regmap_config);
> if (IS_ERR(syscon->regmap)) {
> - dev_err(dev, "regmap init failed\n");
> + pr_err("regmap init failed\n");
> return PTR_ERR(syscon->regmap);
> }
>
> - platform_set_drvdata(pdev, syscon);
> + np->data = syscon;
>
> - dev_info(dev, "regmap %pR registered\n", res);
> + of_node_put(np);
> +
> + pr_info("%s: regmap %pR registered\n", np->full_name, &syscon->res);
>
> return 0;
> }
>
> -static const struct platform_device_id syscon_ids[] = {
> - { "syscon", },
> - { }
> +static struct of_device_id of_syscon_ids[] = {
> + { .compatible = "syscon" },
> + {},
> };
>
> +void __init early_syscon_init(void)
> +{
> + struct device_node *np;
> +
> + for_each_matching_node_and_match(np, of_syscon_ids, NULL) {
> + if (!early_syscon_probe(np))
just
if (early_syscon_probe(np))
BUG();
here.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/2a67d56a/attachment-0001.sig>
^ permalink raw reply
* [PATCH 14/28] Remove MACH_SMDKC210
From: Paul Bolle @ 2014-02-10 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210141255.GI1757@sirena.org.uk>
On Mon, 2014-02-10 at 14:12 +0000, Mark Brown wrote:
> On Mon, Feb 10, 2014 at 02:31:12PM +0100, Paul Bolle wrote:
> > If so, to be absolutely sure we start from the same point: do you agree
> > that the above line now effectively reads
> > depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)
>
> > because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig
> > symbol MACH_SMDKC210?
>
> Yes, that's correct. Now, like I say think about what the symbol was
> there for in the first place.
So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were
removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for
EXYNOS SoCs"). That commit was part of v3.11. Correct?
Thanks for your patience.
Paul Bolle
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Russell King - ARM Linux @ 2014-02-10 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210151247.GD2794@e103592.cambridge.arm.com>
On Mon, Feb 10, 2014 at 03:12:47PM +0000, Dave Martin wrote:
> Firstly, blindly adding 4 to PC is obviouly not right, partly because we
> might be running an unrelated thread by the time the abort fires, and
> also because the affected instruction might not be 4 bytes in size in a
> Thumb kernel.
Exactly. We ended up on some platforms having special accessors for PCI
where we included a number of 'mov r0, r0' instructions after the accessor
so we could properly cope with them - but this required knowledge that
we were going to only receive an imprecise abort from these accessors
and only for a few cycles after the instruction.
However, that's not true with modern architectures. The point they're
received will _not_ be the load/store which resulted in the abort, and
in the case of a write, they could be many hundreds of cycles later,
especially if the write has been buffered.
So adding four to the PC is definitely a very /bad/ thing to do.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC PATCH 3/3] ARM: zynq: Use early syscon initialization
From: Michal Simek @ 2014-02-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392045742.git.michal.simek@xilinx.com>
Use early syscon initialization to simplify slcr code.
- Remove two slcr inits (zynq_slcr_init, zynq_early_slcr_init)
- Directly use regmap accesses in zynq_slcr_read/write
- Remove zynq_clock_init() and use addresses from syscon
(This is the most problematic part now because clock
doesn't support regmap accesses that's why reading
slcr base is ugly. There are some attempts to get
clk regmap to work - for example:
https://lkml.org/lkml/2013/10/16/112)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Especially look at slcr.c which is much simpler than was before.
clkc.c will be simpler when regmap support is added because then
syscon_early_regmap_lookup_by_phandle() will be called
without zynq_slcr_base search.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 +
arch/arm/mach-zynq/common.c | 6 ++---
arch/arm/mach-zynq/slcr.c | 42 ++---------------------------
drivers/clk/zynq/clkc.c | 57 ++++++++++++----------------------------
4 files changed, 23 insertions(+), 83 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 7284499..e414489 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -135,6 +135,7 @@
compatible = "xlnx,zynq-slcr", "syscon";
reg = <0xF8000000 0x1000>;
ranges;
+ syscon = <&slcr>;
clkc: clkc at 100 {
#clock-cells = <1>;
compatible = "xlnx,ps7-clkc";
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 9d3c88e..78589e3 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -28,6 +28,7 @@
#include <linux/of.h>
#include <linux/irqchip.h>
#include <linux/irqchip/arm-gic.h>
+#include <linux/mfd/syscon.h>
#include <linux/slab.h>
#include <linux/sys_soc.h>
@@ -130,15 +131,14 @@ out:
of_platform_populate(NULL, of_default_bus_match_table, NULL, parent);
platform_device_register(&zynq_cpuidle_device);
-
- zynq_slcr_init();
}
static void __init zynq_timer_init(void)
{
+ early_syscon_init();
+
zynq_early_slcr_init();
- zynq_clock_init();
of_clk_init(NULL);
clocksource_of_init();
}
diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index 594b280..a89b082 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -35,7 +35,6 @@
#define SLCR_PSS_IDCODE_DEVICE_SHIFT 12
#define SLCR_PSS_IDCODE_DEVICE_MASK 0x1F
-static void __iomem *zynq_slcr_base;
static struct regmap *zynq_slcr_regmap;
/**
@@ -48,11 +47,6 @@ static struct regmap *zynq_slcr_regmap;
*/
static int zynq_slcr_write(u32 val, u32 offset)
{
- if (!zynq_slcr_regmap) {
- writel(val, zynq_slcr_base + offset);
- return 0;
- }
-
return regmap_write(zynq_slcr_regmap, offset, val);
}
@@ -66,12 +60,7 @@ static int zynq_slcr_write(u32 val, u32 offset)
*/
static int zynq_slcr_read(u32 *val, u32 offset)
{
- if (zynq_slcr_regmap)
- return regmap_read(zynq_slcr_regmap, offset, val);
-
- *val = readl(zynq_slcr_base + offset);
-
- return 0;
+ return regmap_read(zynq_slcr_regmap, offset, val);
}
/**
@@ -169,24 +158,6 @@ void zynq_slcr_cpu_stop(int cpu)
}
/**
- * zynq_slcr_init - Regular slcr driver init
- *
- * Return: 0 on success, negative errno otherwise.
- *
- * Called early during boot from platform code to remap SLCR area.
- */
-int __init zynq_slcr_init(void)
-{
- zynq_slcr_regmap = syscon_regmap_lookup_by_compatible("xlnx,zynq-slcr");
- if (IS_ERR(zynq_slcr_regmap)) {
- pr_err("%s: failed to find zynq-slcr\n", __func__);
- return -ENODEV;
- }
-
- return 0;
-}
-
-/**
* zynq_early_slcr_init - Early slcr init function
*
* Return: 0 on success, negative errno otherwise.
@@ -202,20 +173,11 @@ int __init zynq_early_slcr_init(void)
pr_err("%s: no slcr node found\n", __func__);
BUG();
}
-
- zynq_slcr_base = of_iomap(np, 0);
- if (!zynq_slcr_base) {
- pr_err("%s: Unable to map I/O memory\n", __func__);
- BUG();
- }
-
- np->data = (__force void *)zynq_slcr_base;
+ zynq_slcr_regmap = syscon_early_regmap_lookup_by_phandle(np, "syscon");
/* unlock the SLCR so that registers can be changed */
zynq_slcr_unlock();
- pr_info("%s mapped to %p\n", np->name, zynq_slcr_base);
-
of_node_put(np);
return 0;
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index c812b93..b2fd160 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -214,6 +214,10 @@ err:
clks[clk1] = ERR_PTR(-ENOMEM);
}
+struct syscon {
+ void __iomem *base;
+};
+
static void __init zynq_clk_setup(struct device_node *np)
{
int i;
@@ -227,6 +231,19 @@ static void __init zynq_clk_setup(struct device_node *np)
const char *periph_parents[4];
const char *swdt_ext_clk_mux_parents[2];
const char *can_mio_mux_parents[NUM_MIO_PINS];
+ struct resource res;
+ void __iomem *zynq_slcr_base;
+
+ struct device_node *slcr = of_get_parent(np);
+ struct syscon *syscon = slcr->data;
+ zynq_slcr_base = syscon->base;
+
+ if (of_address_to_resource(np, 0, &res)) {
+ pr_err("%s: failed to get resource\n", np->name);
+ return;
+ }
+
+ zynq_clkc_base = zynq_slcr_base + res.start;
pr_info("Zynq clock init\n");
@@ -569,43 +586,3 @@ static void __init zynq_clk_setup(struct device_node *np)
}
CLK_OF_DECLARE(zynq_clkc, "xlnx,ps7-clkc", zynq_clk_setup);
-
-void __init zynq_clock_init(void)
-{
- struct device_node *np;
- struct device_node *slcr;
- struct resource res;
-
- np = of_find_compatible_node(NULL, NULL, "xlnx,ps7-clkc");
- if (!np) {
- pr_err("%s: clkc node not found\n", __func__);
- goto np_err;
- }
-
- if (of_address_to_resource(np, 0, &res)) {
- pr_err("%s: failed to get resource\n", np->name);
- goto np_err;
- }
-
- slcr = of_get_parent(np);
-
- if (slcr->data) {
- zynq_clkc_base = (__force void __iomem *)slcr->data + res.start;
- } else {
- pr_err("%s: Unable to get I/O memory\n", np->name);
- of_node_put(slcr);
- goto np_err;
- }
-
- pr_info("%s: clkc starts at %p\n", __func__, zynq_clkc_base);
-
- of_node_put(slcr);
- of_node_put(np);
-
- return;
-
-np_err:
- of_node_put(np);
- BUG();
- return;
-}
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/2103137c/attachment.sig>
^ permalink raw reply related
* [RFC PATCH 2/3] mfd: syscon: Support early initialization
From: Michal Simek @ 2014-02-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392045742.git.michal.simek@xilinx.com>
Some platforms need to get system controller
ready as soon as possible.
The patch provides early_syscon_initialization
which create early mapping for all syscon compatible
devices in early_syscon_probe.
Regmap is get via syscon_early_regmap_lookup_by_phandle()
Regular device probes attach device to regmap
via regmap_attach_dev().
For early syscon initialization is necessary to extend
struct syscon and provide remove function
which unmap all early init structures.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/mfd/syscon.c | 126 +++++++++++++++++++++++++++++++++++++++------
include/linux/mfd/syscon.h | 11 ++++
2 files changed, 120 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 71841f9..5935f02 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -20,12 +20,15 @@
#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
+#include <linux/slab.h>
#include <linux/mfd/syscon.h>
static struct platform_driver syscon_driver;
struct syscon {
+ void __iomem *base;
struct regmap *regmap;
+ struct resource res;
};
static int syscon_match_node(struct device *dev, void *data)
@@ -95,6 +98,24 @@ struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
+struct regmap *syscon_early_regmap_lookup_by_phandle(struct device_node *np,
+ const char *property)
+{
+ struct device_node *syscon_np;
+ struct syscon *syscon;
+
+ syscon_np = of_parse_phandle(np, property, 0);
+ if (!syscon_np)
+ return ERR_PTR(-ENODEV);
+
+ syscon = syscon_np->data;
+
+ of_node_put(syscon_np);
+
+ return syscon->regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_early_regmap_lookup_by_phandle);
+
struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
const char *property)
{
@@ -128,40 +149,110 @@ static int syscon_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct syscon *syscon;
struct resource *res;
- void __iomem *base;
- syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
+ /* Early syscon init */
+ if (pdev->dev.of_node && pdev->dev.of_node->data) {
+ syscon = pdev->dev.of_node->data;
+ res = &syscon->res;
+ regmap_attach_dev(dev, syscon->regmap, &syscon_regmap_config);
+ } else {
+
+ syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
+ if (!syscon)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ syscon->base = devm_ioremap(dev, res->start,
+ resource_size(res));
+ if (!syscon->base)
+ return -ENOMEM;
+
+ syscon_regmap_config.max_register = res->end - res->start - 3;
+ syscon->regmap = devm_regmap_init_mmio(dev, syscon->base,
+ &syscon_regmap_config);
+ if (IS_ERR(syscon->regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(syscon->regmap);
+ }
+ }
+
+ platform_set_drvdata(pdev, syscon);
+
+ dev_info(dev, "regmap %pR registered\n", res);
+
+ return 0;
+}
+
+static const struct platform_device_id syscon_ids[] = {
+ { "syscon", },
+ { }
+};
+
+static int syscon_remove(struct platform_device *pdev)
+{
+ struct syscon *syscon = platform_get_drvdata(pdev);
+
+ if (pdev->dev.of_node && pdev->dev.of_node->data) {
+ iounmap(syscon->base);
+ kfree(syscon);
+ }
+
+ return 0;
+}
+
+static int early_syscon_probe(struct device_node *np)
+{
+ struct syscon *syscon;
+
+ syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
if (!syscon)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENOENT;
+ if (of_address_to_resource(np, 0, &syscon->res))
+ return -EINVAL;
- base = devm_ioremap(dev, res->start, resource_size(res));
- if (!base)
- return -ENOMEM;
+ syscon->base = ioremap(syscon->res.start, resource_size(&syscon->res));
+ if (!syscon->base) {
+ pr_err("%s: Unable to map I/O memory\n", __func__);
+ return PTR_ERR(syscon->base);
+ }
- syscon_regmap_config.max_register = res->end - res->start - 3;
- syscon->regmap = devm_regmap_init_mmio(dev, base,
- &syscon_regmap_config);
+ syscon_regmap_config.max_register = syscon->res.end -
+ syscon->res.start - 3;
+ syscon->regmap = regmap_init_mmio(NULL, syscon->base,
+ &syscon_regmap_config);
if (IS_ERR(syscon->regmap)) {
- dev_err(dev, "regmap init failed\n");
+ pr_err("regmap init failed\n");
return PTR_ERR(syscon->regmap);
}
- platform_set_drvdata(pdev, syscon);
+ np->data = syscon;
- dev_info(dev, "regmap %pR registered\n", res);
+ of_node_put(np);
+
+ pr_info("%s: regmap %pR registered\n", np->full_name, &syscon->res);
return 0;
}
-static const struct platform_device_id syscon_ids[] = {
- { "syscon", },
- { }
+static struct of_device_id of_syscon_ids[] = {
+ { .compatible = "syscon" },
+ {},
};
+void __init early_syscon_init(void)
+{
+ struct device_node *np;
+
+ for_each_matching_node_and_match(np, of_syscon_ids, NULL) {
+ if (!early_syscon_probe(np))
+ BUG();
+ }
+}
+
static struct platform_driver syscon_driver = {
.driver = {
.name = "syscon",
@@ -169,6 +260,7 @@ static struct platform_driver syscon_driver = {
.of_match_table = of_syscon_match,
},
.probe = syscon_probe,
+ .remove = syscon_remove,
.id_table = syscon_ids,
};
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 8789fa3..465c092 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -24,6 +24,10 @@ extern struct regmap *syscon_regmap_lookup_by_pdevname(const char *s);
extern struct regmap *syscon_regmap_lookup_by_phandle(
struct device_node *np,
const char *property);
+extern struct regmap *syscon_early_regmap_lookup_by_phandle(
+ struct device_node *np,
+ const char *property);
+extern void early_syscon_init(void);
#else
static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
{
@@ -46,6 +50,13 @@ static inline struct regmap *syscon_regmap_lookup_by_phandle(
{
return ERR_PTR(-ENOSYS);
}
+
+static struct regmap *syscon_early_regmap_lookup_by_phandle(
+ struct device_node *np,
+ const char *property)
+{
+ return ERR_PTR(-ENOSYS);
+}
#endif
#endif /* __LINUX_MFD_SYSCON_H__ */
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/b29e2420/attachment-0001.sig>
^ permalink raw reply related
* [RFC PATCH 1/3] regmap: Separate regmap dev initialization
From: Michal Simek @ 2014-02-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392045742.git.michal.simek@xilinx.com>
Create special function regmap_attach_dev
which can be called separately out of regmap_init.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/base/regmap/regmap.c | 41 ++++++++++++++++++++++++++++-------------
include/linux/regmap.h | 2 ++
2 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index b897c1a..c766f5f 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -380,6 +380,28 @@ static void regmap_range_exit(struct regmap *map)
kfree(map->selector_work_buf);
}
+int regmap_attach_dev(struct device *dev, struct regmap *map,
+ const struct regmap_config *config)
+{
+ struct regmap **m;
+
+ map->dev = dev;
+
+ regmap_debugfs_init(map, config->name);
+
+ /* Add a devres resource for dev_get_regmap() */
+ m = devres_alloc(dev_get_regmap_release, sizeof(*m), GFP_KERNEL);
+ if (!m) {
+ regmap_debugfs_exit(map);
+ return -ENOMEM;
+ }
+ *m = map;
+ devres_add(dev, m);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(regmap_attach_dev);
+
/**
* regmap_init(): Initialise register map
*
@@ -397,7 +419,7 @@ struct regmap *regmap_init(struct device *dev,
void *bus_context,
const struct regmap_config *config)
{
- struct regmap *map, **m;
+ struct regmap *map;
int ret = -EINVAL;
enum regmap_endian reg_endian, val_endian;
int i, j;
@@ -734,25 +756,18 @@ skip_format_initialization:
}
}
- regmap_debugfs_init(map, config->name);
-
ret = regcache_init(map, config);
if (ret != 0)
goto err_range;
- /* Add a devres resource for dev_get_regmap() */
- m = devres_alloc(dev_get_regmap_release, sizeof(*m), GFP_KERNEL);
- if (!m) {
- ret = -ENOMEM;
- goto err_debugfs;
- }
- *m = map;
- devres_add(dev, m);
+ if (dev)
+ ret = regmap_attach_dev(dev, map, config);
+ if (ret != 0)
+ goto err_regcache;
return map;
-err_debugfs:
- regmap_debugfs_exit(map);
+err_regcache:
regcache_exit(map);
err_range:
regmap_range_exit(map);
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 4149f1a..fa4d079 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -317,6 +317,8 @@ struct regmap *regmap_init(struct device *dev,
const struct regmap_bus *bus,
void *bus_context,
const struct regmap_config *config);
+int regmap_attach_dev(struct device *dev, struct regmap *map,
+ const struct regmap_config *config);
struct regmap *regmap_init_i2c(struct i2c_client *i2c,
const struct regmap_config *config);
struct regmap *regmap_init_spi(struct spi_device *dev,
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/2f6b4e20/attachment.sig>
^ permalink raw reply related
* [RFC PATCH 0/3] Syscon early initialization
From: Michal Simek @ 2014-02-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series come from my discussion with Arnd at KS and then
on some other threads/IRCs(Arnd and Mark) that SoC vendors
are more and more try to add misc functionality to
one memory region. For this purpose syscon driver is in the kernel.
But regular syscon driver is initialized too late
and platforms are trying to create specific code to handle it.
For this purpose the series have been created to provide
early syscon initialization and regmap creation first
and then attaching device.
The last patch is zynq specific patch to clear slcr driver
and clock driver can profit from it too when clk regmap is ready.
Also moving syscon driver from mfs should be consider.
Thanks for your comments,
Michal
Michal Simek (3):
regmap: Separate regmap dev initialization
mfd: syscon: Support early initialization
ARM: zynq: Use early syscon initialization
arch/arm/boot/dts/zynq-7000.dtsi | 1 +
arch/arm/mach-zynq/common.c | 6 +-
arch/arm/mach-zynq/slcr.c | 42 +------------
drivers/base/regmap/regmap.c | 41 +++++++++----
drivers/clk/zynq/clkc.c | 57 ++++++------------
drivers/mfd/syscon.c | 126 +++++++++++++++++++++++++++++++++------
include/linux/mfd/syscon.h | 11 ++++
include/linux/regmap.h | 2 +
8 files changed, 173 insertions(+), 113 deletions(-)
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/69ed2e02/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Dave Martin @ 2014-02-10 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8E81E.70804@codethink.co.uk>
On Mon, Feb 10, 2014 at 02:54:22PM +0000, Ben Dooks wrote:
> On 10/02/14 14:16, Dave Martin wrote:
> >On Fri, Feb 07, 2014 at 05:19:15PM +0100, Fabrice GASNIER wrote:
> >>This patch adds imprecise abort enable/disable macros.
> >>It also enables imprecise aborts when starting kernel.
> >
> >Relying on imprecise aborts for hardware probing would be considered bad
> >hardware and/or software design for ARM-specific stuff.
> >
> >PCI is more generic though, so we may have to put up with this to some
> >extent. Can you point me to the affected probing code? I'm not very
> >familiar with that stuff...
>
> The marvell pcie always had the option of delivering any bus
> errors as imprecise aborts. However it was /annoying/ and therefore
You don't say ;)
> easier just to turn it off and rely on the hardware returning 0xffff
> for any configuration area it couldn't get to.
Does PCI have any way of finding out which parts of the configuration
space are there before you are forced to go poking around in invalid
address space?
I'm guessing there may not be, otherwise this convsersation might not
be happening ... but I don't know too much about PCI.
Maybe some driver-specific probing hook would make sense, so that we
only need to use the russian roulette approach on hardware that forces
us to.
Cheers
---Dave
^ permalink raw reply
* [PATCH v3 1/6] arm64: Add ftrace support
From: Steven Rostedt @ 2014-02-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402101603.21791.arnd@arndb.de>
On Mon, 10 Feb 2014 16:03:21 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 07 February 2014, AKASHI Takahiro wrote:
> > @@ -0,0 +1,23 @@
>
> > +
> > +#ifdef CONFIG_FUNCTION_TRACER
> > +#define MCOUNT_ADDR ((unsigned long)_mcount)
> > +#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
> > +
> > +#ifndef __ASSEMBLY__
> > +extern void _mcount(unsigned long);
> > +#endif /* __ASSEMBLY__ */
> > +#endif /* CONFIG_FUNCTION_TRACER */
>
> We generally like to have as few #ifdef as possible, and I think the
> #ifdef CONFIG_FUNCTION_TRACER here is not needed.
>
> > +#endif /* __ASM_FTRACE_H */
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index 2d4554b..ca921fb 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -5,6 +5,11 @@
> > CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> >
> > +ifdef CONFIG_FUNCTION_TRACER
> > +CFLAGS_REMOVE_ftrace.o = -pg
> > +CFLAGS_REMOVE_insn.o = -pg
> > +endif
>
> Same here. It never hurts to have the CFLAGS_REMOVE_* statements here, since
> you will not want to build these files for profiling.
I agree to this. I will admit, this was probably just a copy from my
code as I did the same in other Makefiles. I think I added the ifdef
statements as more of documenting what the REMOVE was for, when ftrace
was just being added to the kernel, and not well known.
I should probably go back and remove the ifdef's from other Makefiles
too.
A comment about what the -pg is for wouldn't hurt, though:
# For files that should not have any function tracing done to them,
# we must remove the -pg flag.
Something like that.
>
> > diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> > index 338b568..7f0512f 100644
> > --- a/arch/arm64/kernel/arm64ksyms.c
> > +++ b/arch/arm64/kernel/arm64ksyms.c
> > @@ -56,3 +56,7 @@ EXPORT_SYMBOL(clear_bit);
> > EXPORT_SYMBOL(test_and_clear_bit);
> > EXPORT_SYMBOL(change_bit);
> > EXPORT_SYMBOL(test_and_change_bit);
> > +
> > +#ifdef CONFIG_FUNCTION_TRACER
> > +EXPORT_SYMBOL(_mcount);
> > +#endif
>
> This one is clearly needed of course.
>
> > +/*
> > + * Gcc with -pg will put the following code in the beginning of each function:
> > + * mov x0, x30
> > + * bl _mcount
> > + * [function's body ...]
> > + * "bl _mcount" may be replaced to "bl ftrace_caller" or NOP if dynamic
> > + * ftrace is enabled.
>
> Unrelated to your patch, I have run into problems with this on arm32, maybe
> someone on Cc to this mail has an idea what to do about it:
>
> If I build a large "randconfig" kernel or "allyesconfig", the kernel image
> size exceeds 32MB, which means I can no longer link callers with a 26
> bit signed immediate argument like the "bl _mcount" here. For any other
> function calls, "gcc -mlong-calls" can be used to work around this, but
> this particular instance is created by inserting assembly statements
> into the output without considering the long-call options. Is there
> a way to get the kernel to link anyway?
I wonder if we play linker games and move the _mcount and ftrace_caller
and friends into the middle of the kernel? If it is only missing it by
a slight overflow of a 32bit jump, then maybe moving it will work.
>
> > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
> Here, again, you an remove the #ifdef by making the entire file built
> only for CONFIG_FUNCTION_GRAPH_TRACER.
Interesting. Other archs (at least x86 and powerpc) required this file
for function tracing too. Seems this is only needed for function graph
tracer.
-- Steve
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Russell King - ARM Linux @ 2014-02-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210144228.GC2794@e103592.cambridge.arm.com>
On Mon, Feb 10, 2014 at 02:42:28PM +0000, Dave Martin wrote:
> Should we require CPSR.A to me masked in Booting, for all CPUs that have
> it?
If it's not masked at boot, then there can't be an imprecise exception
pending.
That's unlike interrupts, where a device could trigger an interrupt at
any moment (eg, a timer expiring.)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [GIT PULL] ARM: imx: device tree changes for 3.15, take 1
From: Arnd Bergmann @ 2014-02-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140209121640.GA14588@S2101-09.ap.freescale.net>
On Sunday 09 February 2014, Shawn Guo wrote:
> On Thu, Feb 06, 2014 at 02:45:05PM +0100, Arnd Bergmann wrote:
> > On Wednesday 05 February 2014, Shawn Guo wrote:
> > no objections to the stuff you add here, but the way it's organized
> > is not good. Instead of adding the controversial patches first and
> > then reverting them, please redo the series so you don't actually
> > have the patches in the history. I see that you have rebased the
> > patches on 3.14-rc1 already so there really shouldn't be any cross-
> > tree dependencies that make it necessary to keep them in.
>
> Okay. I just spent the weekend to rebuild the branch and reworked quite
> a lot of patches to wipe the pingrp stuff from the history.
Thanks!
> > it would be nice to split it up into smaller units. A good
> > separation would be to have new board support in one pull
> > request and the changes to existing boards in another one.
>
> Some new board support are built on top of the updates to the existing
> files for purpose like sharing common part. And some updates are added
> on top of new board support along time goes. So it's hard to make such
> separation. Considering the amount of imx6 changes these days, I chose
> to split the branch into two, one for imx6 changes and the other for all
> the rest. Such separation does not involve too much interdependency.
Ok, good idea.
Arnd
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Russell King - ARM Linux @ 2014-02-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392045139.6687.31.camel@pizza.hi.pengutronix.de>
On Mon, Feb 10, 2014 at 04:12:19PM +0100, Philipp Zabel wrote:
> Am Montag, den 10.02.2014, 12:28 +0000 schrieb Russell King - ARM Linux:
> > This is the latest revision of my series cleaning up imx-drm and
> > hopefully getting it ready to be moved out of drivers/staging.
> > This series is updated to v3.14-rc2.
> >
> > Since the last round of patches were posted, the component support
> > has been merged into mainline, and thus dropped from this series.
> > Greg has taken the first three patches and merged them into his
> > linux-next tree - however, I include them here for completness.
> >
> > Most of the comments from last time still apply, and I'll look at
> > incorporating some of the other patches that were posted in the
> > coming week.
> >
> > If I can have some acks for this, I'll start sending some of it to
> >
> >
> > Greg - I'd like to at least get the five or six initial imx-hdmi
> > patches to Greg and queued up for the next merge window sooner
> > rather than later, preferably getting most of this ready for that
> > window too.
>
> For the first 9 patches up to (including) "imx-drm: ipu-v3: more
> clocking fixes":
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
>
> As you say, comments about the device tree bindings still apply.
> I'd prefer if the patches that currently use the crtcs property were
> reworked to use the v4l2 style device tree bindings before they hit
> mainline.
I'm trying /not/ to do that much more work on this because there's
other things that need my attention, like a complete rewrite of the
SDHCI mess. I want to get the imx-drm stuff off my plate so I don't
have to worry about it.
So, I'd really like _all_ these patches to go into mainline for v3.15
with the least rework possible so I can spend the next few months
working on rewriting SDHCI.
What I don't want is carrying hundreds of patches across multiple
kernel versions.
Now, mind explaining what "v4l2 style device tree bindings" means? I've
no idea since I'm relatively new to DT.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
From: Russell King - ARM Linux @ 2014-02-10 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210153551.1309f017@armhf>
On Mon, Feb 10, 2014 at 03:35:51PM +0100, Jean-Francois Moine wrote:
> On Mon, 10 Feb 2014 13:12:33 +0000
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > I've NAK'd these patches already - I believe they're based on a
> > mis-understanding of how this should be used. I believe Jean-Francois
> > has only looked at the core, rather than looking at the imx-drm example
> > it was posted with in an attempt to understand it.
> >
> > Omitting the component bind operations is absurd because it makes the
> > component code completely pointless, since there is then no way to
> > control the sequencing of driver initialisation - something which is
> > one of the primary reasons for this code existing in the first place.
>
> I perfectly looked at your example and I use it now in my system.
>
> You did not see what could be done with your component code. For
> example, since november, I have not yet the clock probe_defer in the
> mainline (http://www.spinics.net/lists/arm-kernel/msg306072.html), so,
> there are 3 solutions:
>
> - hope the patch will be some day in the mainline and, today, reboot
> when the system does not start correctly,
>
> - insert a delay in the tda998x and kirkwood probe sequences (delay
> long enough to be sure the si5351 is started, or loop),
>
> - use your component work.
>
> In the last case, it is easy:
>
> - the si5351 driver calls component_add (with empty ops: it has no
> interest in the bind/unbind functions) when it is fully started (i.e.
> registered - that was the subject of my patch),
There is only one word for this:
Ewwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.
Definitely not.
The component stuff is there to sort out the subsystems which expect a
"card" but in DT we supply a set of components. It's not there to sort
out dependencies between different subsystems.
I've no idea why your patch to add the deferred probing hasn't been acked
by Mike yet, but that needs to happen before I take it. Or, split it up
in two so I can take the clkdev part and Mike can take the CCF part.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Dave Martin @ 2014-02-10 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8E5E2.30805@st.com>
On Mon, Feb 10, 2014 at 03:44:50PM +0100, Fabrice Gasnier wrote:
> On 02/10/2014 03:16 PM, Dave Martin wrote:
> >On Fri, Feb 07, 2014 at 05:19:15PM +0100, Fabrice GASNIER wrote:
> >>This patch adds imprecise abort enable/disable macros.
> >>It also enables imprecise aborts when starting kernel.
> >Relying on imprecise aborts for hardware probing would be considered bad
> >hardware and/or software design for ARM-specific stuff.
> >
> >PCI is more generic though, so we may have to put up with this to some
> >extent. Can you point me to the affected probing code? I'm not very
> >familiar with that stuff...
> Hi,
>
> I'm currently re-basing to prepare upstream of such a driver so, no
> code for now on my side,
> but, I saw others that have similar behavior :
> http://www.spinics.net/lists/linux-pci/msg26124.html
> Basically, I think all PCI drivers using hook_fault_code(16+6, ...)
> use similar mechanism.
Hmmm. There seem to be a few problems here.
Firstly, blindly adding 4 to PC is obviouly not right, partly because we
might be running an unrelated thread by the time the abort fires, and
also because the affected instruction might not be 4 bytes in size in a
Thumb kernel.
Secondly, do we ever release the fault code hook? If not, it looks like
we just ignore all imprecise aborts from the moment that driver is
loaded, whatever causes them ... not ideal.
Are the aborts triggered by the PCI common code? Do you know which
precise code triggers the aborts?
I wonder whether it would be possible to arch hooks to do the
problematic probing another way.
Cheers
---Dave
> >
> >>Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> >>---
> >> arch/arm/include/asm/irqflags.h | 33 +++++++++++++++++++++++++++++++++
> >> arch/arm/kernel/smp.c | 1 +
> >> arch/arm/kernel/traps.c | 4 ++++
> >> 3 files changed, 38 insertions(+)
> >>
> >>diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
> >>index 3b763d6..82e3834 100644
> >>--- a/arch/arm/include/asm/irqflags.h
> >>+++ b/arch/arm/include/asm/irqflags.h
> >>@@ -51,6 +51,9 @@ static inline void arch_local_irq_disable(void)
> >> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : : "memory", "cc")
> >> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : : "memory", "cc")
> >>+
> >>+#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory", "cc")
> >>+#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory", "cc")
> >> #else
> >> /*
> >>@@ -130,6 +133,36 @@ static inline void arch_local_irq_disable(void)
> >> : "memory", "cc"); \
> >> })
> >>+/*
> >>+ * Enable Aborts
> >>+ */
> >>+#define local_abt_enable() \
> >>+ ({ \
> >>+ unsigned long temp; \
> >>+ __asm__ __volatile__( \
> >>+ "mrs %0, cpsr @ sta\n" \
> >>+" bic %0, %0, %1\n" \
> >>+" msr cpsr_c, %0" \
> >I suggest you use "cpsie/cpsid a" instead. This requires ARMv6, but the
> >CPSR.A bit only exists on ARMv6 and later anyway. Poking that bit
> >on earlier CPUs may cause unpredictable behaviour, so these macros
> >should be no-ops for v5 and earlier.
> Thanks,
> I'll prepare a new patch that way.
> >
> >>+ : "=r" (temp) \
> >>+ : "r" (PSR_A_BIT) \
> >>+ : "memory", "cc"); \
> >>+ })
> >>+
> >>+/*
> >>+ * Disable Aborts
> >>+ */
> >>+#define local_abt_disable() \
> >>+ ({ \
> >>+ unsigned long temp; \
> >>+ __asm__ __volatile__( \
> >>+ "mrs %0, cpsr @ cla\n" \
> >>+" orr %0, %0, %1\n" \
> >>+" msr cpsr_c, %0" \
> >>+ : "=r" (temp) \
> >>+ : "r" (PSR_A_BIT) \
> >>+ : "memory", "cc"); \
> >>+ })
> >>+
> >> #endif
> >> /*
> >>diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> >>index dc894ab..c2093cb 100644
> >>--- a/arch/arm/kernel/smp.c
> >>+++ b/arch/arm/kernel/smp.c
> >>@@ -377,6 +377,7 @@ asmlinkage void secondary_start_kernel(void)
> >> local_irq_enable();
> >> local_fiq_enable();
> >>+ local_abt_enable();
> >> /*
> >> * OK, it's off to the idle thread for us
> >>diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> >>index 4636d56..ef15709 100644
> >>--- a/arch/arm/kernel/traps.c
> >>+++ b/arch/arm/kernel/traps.c
> >>@@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> >>+
> >>+ /* Enable imprecise aborts */
> >>+ local_abt_enable();
> >It would be good to clean up why aborts are not being consistently
> >enabled on boot.
> I did a bit of analysis and summarized it in this thread. I've not
> been further:
> http://archive.arm.linux.org.uk/lurker/message/20140203.164322.edba427a.en.html
>
> BR,
> Fabrice
> >
> >Really, they should be enabled, except for a brief window during
> >boot when the vectors are not mapped and the abort can't be dispatched.
> >
> >Cheers
> >---Dave
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Philipp Zabel @ 2014-02-10 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210122802.GS26684@n2100.arm.linux.org.uk>
Am Montag, den 10.02.2014, 12:28 +0000 schrieb Russell King - ARM Linux:
> This is the latest revision of my series cleaning up imx-drm and
> hopefully getting it ready to be moved out of drivers/staging.
> This series is updated to v3.14-rc2.
>
> Since the last round of patches were posted, the component support
> has been merged into mainline, and thus dropped from this series.
> Greg has taken the first three patches and merged them into his
> linux-next tree - however, I include them here for completness.
>
> Most of the comments from last time still apply, and I'll look at
> incorporating some of the other patches that were posted in the
> coming week.
>
> If I can have some acks for this, I'll start sending some of it to
>
>
> Greg - I'd like to at least get the five or six initial imx-hdmi
> patches to Greg and queued up for the next merge window sooner
> rather than later, preferably getting most of this ready for that
> window too.
For the first 9 patches up to (including) "imx-drm: ipu-v3: more
clocking fixes":
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
As you say, comments about the device tree bindings still apply.
I'd prefer if the patches that currently use the crtcs property were
reworked to use the v4l2 style device tree bindings before they hit
mainline.
regards
Philipp
^ permalink raw reply
* imx6qdl, weim ranges and gpr1
From: Shawn Guo @ 2014-02-10 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210001547.GA28084@frolo.macqel>
On Mon, Feb 10, 2014 at 01:15:47AM +0100, Philippe De Muyter wrote:
> Hello linux on i.mx6 experts,
>
> on our i.mx6q/dl-based custom hardware we have used the weim interface to
> connect some peripherals. Our weim dts description looks like that:
>
> &weim {
> compatible = "fsl,imx6q-weim";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_weim_sram_1>;
> clocks = <&clks 196>;
> reg = <0x021b8000 0x4000>;
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <0 0 0x08000000 0x04000000>, /* 64Mb for CS0 */
> <1 0 0x0c000000 0x04000000>; /* 64Mb for CS1 */
> status = "okay";
>
> ...
> };
>
> Actually, to achieve this mapping, I must configure some bits in IOMUXC_GPR1,
> like that:
> regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff, 0x1b);
>
> Would it be possible to set the IOMUXC_GPR1 bits automagically, based on the
> dts description ?
It's possible, I think.
> Where should that go, in drivers/bus/imx-weim.c or in
> arch/arm/mach-imx/mach-imx6q.c ?
I prefer to drivers/bus/imx-weim.c.
> Also, I do not know how to retrieve
> the 'ranges' property of the weim description.
Just read it as an array of integers. I will post a patch for it
tomorrow. And please help test it.
Shawn
^ permalink raw reply
* [PATCH v2 14/15] charger: max14577: Configure battery-dependent settings from DTS
From: Krzysztof Kozlowski @ 2014-02-10 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210121405.GH22773@lee--X1>
On Mon, 2014-02-10 at 12:14 +0000, Lee Jones wrote:
> > Remove hard-coded values for:
> > - Fast Charge current,
> > - End Of Charge current,
> > - Fast Charge timer,
> > - Overvoltage Protection Threshold,
> > - Battery Constant Voltage,
> > and use DTS to configure them. This allows using the max14577 charger
> > driver with different batteries.
> >
> > Now the charger driver requires valid configuration data from DTS. In
> > case of wrong configuration data it fails during probe. Patch adds
> > of_compatible to the charger mfd cell in MFD driver core.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Cc: Jenny Tc <jenny.tc@intel.com>
> > ---
> > drivers/mfd/max14577.c | 5 +-
> > drivers/power/max14577_charger.c | 234 +++++++++++++++++++++++++++++-----
> > include/linux/mfd/max14577-private.h | 10 ++
> > include/linux/mfd/max14577.h | 8 ++
> > 4 files changed, 227 insertions(+), 30 deletions(-)
>
> <snip>
>
> > diff --git a/include/linux/mfd/max14577-private.h b/include/linux/mfd/max14577-private.h
> > index a8cd7de3526a..50cf70bec4d4 100644
> > --- a/include/linux/mfd/max14577-private.h
> > +++ b/include/linux/mfd/max14577-private.h
> > @@ -269,6 +269,16 @@ enum maxim_muic_charger_type {
> > #define MAX77836_CHARGER_CURRENT_LIMIT_HIGH_STEP 25000U
> > #define MAX77836_CHARGER_CURRENT_LIMIT_MAX 475000U
> >
> > +/* MAX14577 charger End-Of-Charge current limits (as in MAXIM_CHGCTRL5 register), uA */
>
> Too many chars. Didn't checkpatch.pl complain about this?
I'll fix this.
>
> > +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN 50000U
> > +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_STEP 10000U
> > +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_MAX 200000U
> > +
> > +/* MAX14577/MAX77836 Battery Constant Voltage (as in MAXIM_CHGCTRL3
> > register), uV */
>
> Same here
OK
^ permalink raw reply
* [alsa-devel] [PATCH 0/7] Audio support for Armada 370 DB
From: Thomas Petazzoni @ 2014-02-10 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210145729.GP1757@sirena.org.uk>
Mark,
On Mon, 10 Feb 2014 14:57:29 +0000, Mark Brown wrote:
> > Any comments on the patch series? I'd like these to be included in
> > 3.15, and so far I've only received one simple comment from Jason
> > Cooper regarding the defconfig changes, but no other comments.
>
> Don't send contentless pings, they're more noise in the inbox. In this
> case the fact that you didn't use subject lines matching the subsystem
> means that they tend to get pushed down my list (or more exactly don't
> come up when I search for patches for the subsystems I maintain). If
> your subject lines stand out in git shortlog output for the area you're
> working on that's generally an issue, for example with ASoC you're
> looking for an "ASoC: ".
Sure, sorry. The patches that are of interest to you are prefixed by
"sound: codec" (for the patch touching sound/soc/codecs) and "sound:
soc" (for the patches touching sound/soc/kirkwood).
If you want, I can resend with subject lines containing 'ASoC:',
however maybe it's better if some other comments are made before, to
avoid additional noise.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/6] arm64: Add ftrace support
From: Arnd Bergmann @ 2014-02-10 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391768336-5642-2-git-send-email-takahiro.akashi@linaro.org>
On Friday 07 February 2014, AKASHI Takahiro wrote:
> @@ -0,0 +1,23 @@
> +
> +#ifdef CONFIG_FUNCTION_TRACER
> +#define MCOUNT_ADDR ((unsigned long)_mcount)
> +#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
> +
> +#ifndef __ASSEMBLY__
> +extern void _mcount(unsigned long);
> +#endif /* __ASSEMBLY__ */
> +#endif /* CONFIG_FUNCTION_TRACER */
We generally like to have as few #ifdef as possible, and I think the
#ifdef CONFIG_FUNCTION_TRACER here is not needed.
> +#endif /* __ASM_FTRACE_H */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 2d4554b..ca921fb 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -5,6 +5,11 @@
> CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
> AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>
> +ifdef CONFIG_FUNCTION_TRACER
> +CFLAGS_REMOVE_ftrace.o = -pg
> +CFLAGS_REMOVE_insn.o = -pg
> +endif
Same here. It never hurts to have the CFLAGS_REMOVE_* statements here, since
you will not want to build these files for profiling.
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index 338b568..7f0512f 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -56,3 +56,7 @@ EXPORT_SYMBOL(clear_bit);
> EXPORT_SYMBOL(test_and_clear_bit);
> EXPORT_SYMBOL(change_bit);
> EXPORT_SYMBOL(test_and_change_bit);
> +
> +#ifdef CONFIG_FUNCTION_TRACER
> +EXPORT_SYMBOL(_mcount);
> +#endif
This one is clearly needed of course.
> +/*
> + * Gcc with -pg will put the following code in the beginning of each function:
> + * mov x0, x30
> + * bl _mcount
> + * [function's body ...]
> + * "bl _mcount" may be replaced to "bl ftrace_caller" or NOP if dynamic
> + * ftrace is enabled.
Unrelated to your patch, I have run into problems with this on arm32, maybe
someone on Cc to this mail has an idea what to do about it:
If I build a large "randconfig" kernel or "allyesconfig", the kernel image
size exceeds 32MB, which means I can no longer link callers with a 26
bit signed immediate argument like the "bl _mcount" here. For any other
function calls, "gcc -mlong-calls" can be used to work around this, but
this particular instance is created by inserting assembly statements
into the output without considering the long-call options. Is there
a way to get the kernel to link anyway?
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
Here, again, you an remove the #ifdef by making the entire file built
only for CONFIG_FUNCTION_GRAPH_TRACER.
Arnd
^ permalink raw reply
* [PATCH] clk: Correct handling of NULL clk in __clk_{get, put}
From: Sylwester Nawrocki @ 2014-02-10 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK9yfHxnrM--A_SZSBWzQ2B7zrtU+=n77H61bzq4ddtLrpHMBg@mail.gmail.com>
On 30/01/14 05:50, Sachin Kamat wrote:
> On 10 January 2014 15:34, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>> > On 08/01/14 05:44, Sachin Kamat wrote:
>>> >> Hi Sylwester,
>>> >>
>>> >> On 7 January 2014 17:33, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>>>> >>> Ensure clk->kref is dereferenced only when clk is not NULL.
>>>> >>>
>>>> >>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>>> >>> ---
>>>> >>> Hi Sachin,
>>>> >>>
>>>> >>> please try if this patch fixes the exyno5420 boot crash.
>>> >>
>>> >> Confirmed that this patch works fine on 5420 as well as already
>>> >> working 4210 and 5250 boards.
>>> >> Thanks for the quick fix.
>>> >>
>>> >> Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
>> >
>> > Thanks Sachin. Mike, it seems we need this patch on top of
>> > my clk-unregister branch. Sorry for overlooking this issue.
>> > Could you add the $subject patch to your clk-next tree ?
>
> Gentle ping Mike. Hope we can have this patch in rc-2.
A gentle reminder, this patch is still not in current -rc and is required
to fix booting of some exynos platforms.
Thanks,
Sylwester
^ permalink raw reply
* [alsa-devel] [PATCH 0/7] Audio support for Armada 370 DB
From: Mark Brown @ 2014-02-10 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210152141.1391fb67@skate>
On Mon, Feb 10, 2014 at 03:21:41PM +0100, Thomas Petazzoni wrote:
> Any comments on the patch series? I'd like these to be included in
> 3.15, and so far I've only received one simple comment from Jason
> Cooper regarding the defconfig changes, but no other comments.
Don't send contentless pings, they're more noise in the inbox. In this
case the fact that you didn't use subject lines matching the subsystem
means that they tend to get pushed down my list (or more exactly don't
come up when I search for patches for the subsystems I maintain). If
your subject lines stand out in git shortlog output for the area you're
working on that's generally an issue, for example with ASoC you're
looking for an "ASoC: ".
-------------- 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/20140210/9b87c836/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Ben Dooks @ 2014-02-10 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210141634.GA2794@e103592.cambridge.arm.com>
On 10/02/14 14:16, Dave Martin wrote:
> On Fri, Feb 07, 2014 at 05:19:15PM +0100, Fabrice GASNIER wrote:
>> This patch adds imprecise abort enable/disable macros.
>> It also enables imprecise aborts when starting kernel.
>
> Relying on imprecise aborts for hardware probing would be considered bad
> hardware and/or software design for ARM-specific stuff.
>
> PCI is more generic though, so we may have to put up with this to some
> extent. Can you point me to the affected probing code? I'm not very
> familiar with that stuff...
The marvell pcie always had the option of delivering any bus
errors as imprecise aborts. However it was /annoying/ and therefore
easier just to turn it off and rely on the hardware returning 0xffff
for any configuration area it couldn't get to.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCHv5] omap3: Add basic support for 720MHz part
From: Nishanth Menon @ 2014-02-10 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3626990.QRqYkuhRtF@avalon>
On Mon, Feb 10, 2014 at 6:17 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> On Thu, Feb 6, 2014 at 1:26 PM, Laurent Pinchart wrote:
>> > On Friday 22 June 2012 11:33:51 Laurent Pinchart wrote:
>> >> On Thursday 10 February 2011 08:45:00 Kevin Hilman wrote:
>> >> > Sanjeev Premi <premi@ti.com> writes:
>> >> > > This patch adds support for speed enhanced variant of OMAP35x
>> >> > > processors. These parts allow ARM and IVA running at 720MHz
>> >> > > and 520MHz respectively.
>> >> > >
>> >> > > These parts can be detected at runtime by reading contents of
>> >> > > PRODID.SKUID[3:0] at 0x4830A20C [1].
>> >> > >
>> >> > > This patch specifically does following:
>> >> > > * Add new OPP to omap34xx_opp_def_list[] - disabled by default.
>> >> > > * Detect devices capable of running at new OPP.
>> >> > > * Enable new OPP only if device supports it.
>> >> > > * Check for presence of IVA before attempting to enable the
>> >> > > corresponding OPP.
>> >> > >
>> >> > > [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
>> >> > >
>> >> > > It appears from discussions (on this patch) that a variant of
>> >> > > OMAP3430 supports this OPP but lacks runtime detection. This
>> >> > > OPP can be enabled for these device by either:
>> >> > > 1) Setting the bit corresponding to OMAP3_HAS_720MHZ
>> >> > > in 'omap3_features'. (Refer changes to id.c)
>> >> > >
>> >> > > 2) Removing check for omap3_has_720mhz() before enabling
>> >> > > the OPP. (Refer changes to opp3xxx_data.c)
>> >> > >
>> >> > > 3) Calling opp_enable() for 720MHz/VDD1 and 520MHz/VDD2 in
>> >> > > the board file. (Refer changes to opp3xxx_data.c).
>> >> > > This should, ideally, be done before omap3_opp_init() is
>> >> > > called during device_initcall().
>> >> > >
>> >> > > CAUTION: This should be done for identified parts only.
>> >> > > Else, the device could be damaged permanently.
>> >> > >
>> >> > > Signed-off-by: Sanjeev Premi <premi@ti.com>
>> >> > > Reviewed-by: G, Manjunath Kondaiah <manjugk@ti.com>
>> >> >
>> >> > Acked-by: Kevin Hilman <khilman@ti.com>
>> >>
>> >> This patch seems to never have made it upstream. Is there a reason for
>> >> that
>> >> ?
>> >
>> > Ping ?
>>
>> We'd have to figure out a proper opp modifier logic with device tree.
>> considering that non-dt boot is slowly getting dismantled in mach-omap2, to
>> add new capabilities in non-dt is not really a good idea at this point in
>> time - Further, we do have equivalent requirements in other TI SoCs as well
>
> Good point, but I'm not sure to see where this patch is specific to legacy
> boot. The two functions it modifies, and omap3xxx_check_features() and
> omap3_opp_init(), are called for DT boot as well.
omap3_opp_init() ->omap_init_opp_table returns if of_have_populated_dt().
check_features enable a flag for omap3_opp_init to pick the right OPPs
up -> this is precisely the intent of something like opp modifier
logic.
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Fabrice Gasnier @ 2014-02-10 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210141634.GA2794@e103592.cambridge.arm.com>
On 02/10/2014 03:16 PM, Dave Martin wrote:
> On Fri, Feb 07, 2014 at 05:19:15PM +0100, Fabrice GASNIER wrote:
>> This patch adds imprecise abort enable/disable macros.
>> It also enables imprecise aborts when starting kernel.
> Relying on imprecise aborts for hardware probing would be considered bad
> hardware and/or software design for ARM-specific stuff.
>
> PCI is more generic though, so we may have to put up with this to some
> extent. Can you point me to the affected probing code? I'm not very
> familiar with that stuff...
Hi,
I'm currently re-basing to prepare upstream of such a driver so, no code
for now on my side,
but, I saw others that have similar behavior :
http://www.spinics.net/lists/linux-pci/msg26124.html
Basically, I think all PCI drivers using hook_fault_code(16+6, ...) use
similar mechanism.
>
>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>> ---
>> arch/arm/include/asm/irqflags.h | 33 +++++++++++++++++++++++++++++++++
>> arch/arm/kernel/smp.c | 1 +
>> arch/arm/kernel/traps.c | 4 ++++
>> 3 files changed, 38 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
>> index 3b763d6..82e3834 100644
>> --- a/arch/arm/include/asm/irqflags.h
>> +++ b/arch/arm/include/asm/irqflags.h
>> @@ -51,6 +51,9 @@ static inline void arch_local_irq_disable(void)
>>
>> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : : "memory", "cc")
>> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : : "memory", "cc")
>> +
>> +#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory", "cc")
>> +#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory", "cc")
>> #else
>>
>> /*
>> @@ -130,6 +133,36 @@ static inline void arch_local_irq_disable(void)
>> : "memory", "cc"); \
>> })
>>
>> +/*
>> + * Enable Aborts
>> + */
>> +#define local_abt_enable() \
>> + ({ \
>> + unsigned long temp; \
>> + __asm__ __volatile__( \
>> + "mrs %0, cpsr @ sta\n" \
>> +" bic %0, %0, %1\n" \
>> +" msr cpsr_c, %0" \
> I suggest you use "cpsie/cpsid a" instead. This requires ARMv6, but the
> CPSR.A bit only exists on ARMv6 and later anyway. Poking that bit
> on earlier CPUs may cause unpredictable behaviour, so these macros
> should be no-ops for v5 and earlier.
Thanks,
I'll prepare a new patch that way.
>
>> + : "=r" (temp) \
>> + : "r" (PSR_A_BIT) \
>> + : "memory", "cc"); \
>> + })
>> +
>> +/*
>> + * Disable Aborts
>> + */
>> +#define local_abt_disable() \
>> + ({ \
>> + unsigned long temp; \
>> + __asm__ __volatile__( \
>> + "mrs %0, cpsr @ cla\n" \
>> +" orr %0, %0, %1\n" \
>> +" msr cpsr_c, %0" \
>> + : "=r" (temp) \
>> + : "r" (PSR_A_BIT) \
>> + : "memory", "cc"); \
>> + })
>> +
>> #endif
>>
>> /*
>> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
>> index dc894ab..c2093cb 100644
>> --- a/arch/arm/kernel/smp.c
>> +++ b/arch/arm/kernel/smp.c
>> @@ -377,6 +377,7 @@ asmlinkage void secondary_start_kernel(void)
>>
>> local_irq_enable();
>> local_fiq_enable();
>> + local_abt_enable();
>>
>> /*
>> * OK, it's off to the idle thread for us
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 4636d56..ef15709 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
>>
>> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
>> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
>> +
>> + /* Enable imprecise aborts */
>> + local_abt_enable();
> It would be good to clean up why aborts are not being consistently
> enabled on boot.
I did a bit of analysis and summarized it in this thread. I've not been
further:
http://archive.arm.linux.org.uk/lurker/message/20140203.164322.edba427a.en.html
BR,
Fabrice
>
> Really, they should be enabled, except for a brief window during
> boot when the vectors are not mapped and the abort can't be dispatched.
>
> Cheers
> ---Dave
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Dave Martin @ 2014-02-10 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210135659.GU26684@n2100.arm.linux.org.uk>
On Mon, Feb 10, 2014 at 01:56:59PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 11:17:10AM +0000, Will Deacon wrote:
> > On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
> > > On 02/07/2014 06:09 PM, Will Deacon wrote:
> > > > On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> > > >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> > > >> index 4636d56..ef15709 100644
> > > >> --- a/arch/arm/kernel/traps.c
> > > >> +++ b/arch/arm/kernel/traps.c
> > > >> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> > > >>
> > > >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> > > >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> > > >> +
> > > >> + /* Enable imprecise aborts */
> > > >> + local_abt_enable();
> > > > Surely we want to enable this as early as possible? Now, putting this into
> > > > head.S is ugly, as it duplicating it across all the proc*.S files, so why
> > > > not setup_arch?
> > > Sorry, I'm not sure to understand your last comment.
> > > At least, I need it enabled before probing drivers (PCIe bus)
> > > I've added imprecise abort enable code in traps.c, following Russel
> > > King's advice, please see:
> > > http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
> > > As abort bit is local to a cpu, i've also added it in smp.c, but this
> > > may not be the right place ?
> > >
> > > Please elaborate,
> >
> > I was just suggesting that we move your local_abt_enable() call to
> > setup_arch, since that's called before early_trap_init on the primary CPU.
>
> Why would we want to enable aborts before we've setup the vectors page
> to handle an abort? That's akin to enabling interrupts and hoping there
> isn't one pending...
Should we require CPSR.A to me masked in Booting, for all CPUs that have
it?
By definition, we cannot dispatch those exceptions for a while, until
some vectors have been set up; so it makes sense in the same way that
requiring CPSR.[IF] to be set makes sense.
The kernel should do its best to cope anyway, and immediately mask CPSR.A
on entry if it's a v6 or later kernel. safe_svcmode_maskall was
originally intended to do that, but it got watered down to cope with the
Zaurus issues, so it now looks like most code paths don't mask CPSR.A
there. I'm happy to take another look at it.
Cheers
---Dave
^ 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