* [PATCH 09/15] ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
index a7505a9..a8e7bd9 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "r8a7740.dtsi"
/ {
model = "armadillo 800 eva";
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/15] ARM: shmobile: Include DTSI of sh73a0 to kzm9g board
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts b/arch/arm/boot/dts/sh73a0-kzm9g.dts
index bcb9119..7b37901 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "sh73a0.dtsi"
/ {
model = "KZM-A9-GT";
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/15] ARM: shmobile: kzm9g: Use DT initialisation of INTC
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index 0a43f31..0a0f302 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -779,7 +779,7 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g")
.map_io = sh73a0_map_io,
.init_early = sh73a0_add_early_devices,
.nr_irqs = NR_IRQS_LEGACY,
- .init_irq = sh73a0_init_irq,
+ .init_irq = sh73a0_init_irq_of,
.handle_irq = gic_handle_irq,
.init_machine = kzm_init,
.init_late = shmobile_init_late,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/15] ARM: shmobile: r8a7740: Use DT initialisation of INTC
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/setup-r8a7740.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 11bb1d9..a8e57ab 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -750,7 +750,7 @@ static const char *r8a7740_boards_compat_dt[] __initdata = {
DT_MACHINE_START(SH7372_DT, "Generic R8A7740 (Flattened Device Tree)")
.map_io = r8a7740_map_io,
.init_early = r8a7740_add_early_devices_dt,
- .init_irq = r8a7740_init_irq,
+ .init_irq = r8a7740_init_irq_of,
.handle_irq = shmobile_handle_irq_intc,
.init_machine = r8a7740_add_standard_devices_dt,
.timer = &shmobile_timer,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 13/15] ARM: shmobile: sh7372: Use DT initialisation of INTC
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/setup-sh7372.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index a07954f..bbe6e2a 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1096,7 +1096,7 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
.map_io = sh7372_map_io,
.init_early = sh7372_add_early_devices_dt,
.nr_irqs = NR_IRQS_LEGACY,
- .init_irq = sh7372_init_irq,
+ .init_irq = sh7372_init_irq_of,
.handle_irq = shmobile_handle_irq_intc,
.init_machine = sh7372_add_standard_devices_dt,
.timer = &shmobile_timer,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 14/15] ARM: shmobile: Add DT table of GIC for sh73a0
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/boot/dts/sh73a0.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index b0c55e1..b250e27 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -806,5 +806,14 @@
};
};
};
+
+ intc: interrupt-controller at f0001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0xf0001000 0x1000>,
+ <0xf0000100 0x100>;
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] ARM: shmobile: sh73a0: Use DT for GIC
From: Simon Horman @ 2012-11-07 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352278244-26702-1-git-send-email-horms@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/intc-sh73a0.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-sh73a0.c
index ee62349..e9b5419 100644
--- a/arch/arm/mach-shmobile/intc-sh73a0.c
+++ b/arch/arm/mach-shmobile/intc-sh73a0.c
@@ -151,6 +151,7 @@ error:
}
static const struct of_device_id irq_of_match[] __initconst = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
{ .compatible = "renesas,sh_intcs", .data = sh73a0_intcs_of_init },
{ .compatible = "renesas,sh_intca_irq_pins",
.data = sh73a0_intca_pins_of_init },
@@ -559,18 +560,18 @@ static irqreturn_t sh73a0_pint1_demux(int irq, void *dev_id)
static void __init sh73a0_init_irq__(bool of)
{
- void __iomem *gic_dist_base = IOMEM(0xf0001000);
- void __iomem *gic_cpu_base = IOMEM(0xf0000100);
void __iomem *intevtsa;
int k, n;
- gic_init(0, 29, gic_dist_base, gic_cpu_base);
- gic_arch_extn.irq_set_wake = sh73a0_set_wake;
-
#ifdef CONFIG_OF
if (of)
of_irq_init(irq_of_match);
+ else
#endif
+ {
+ gic_init(0, 29, IOMEM(0xf0001000), IOMEM(0xf0000100));
+ gic_arch_extn.irq_set_wake = sh73a0_set_wake;
+ }
register_intc_controller(&intcs_desc);
register_intc_controller(&intca_irq_pins_desc);
--
1.7.10.4
^ permalink raw reply related
* [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
From: Mark Brown @ 2012-11-07 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107084733.GD20063@game.jcrosoft.org>
On Wed, Nov 07, 2012 at 09:47:33AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Mark I nack the patch series this patch series does not run on any DT kernel
> as no picntrl is done
> do not apply until this patfh handle the pinctrl
Nicholas seemed to be disagreeing you on that one and his observation
that it won't be an issue until v3.8 anyway seemed totally reasonable.
In any case it doesn't seems like it'll be an issue to get it resolved
before it actually gets merged down to become an issue.
Of course there's also some ongoing discussion on the question of having
to add mindless pinctrl_get_set_default() to all the drivers at all, the
fact that we're having to do that at all seems like a failure to me at
least.
-------------- 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/20121107/2ee5157c/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: mxs: apf28dev: Add I2C, SPI and spidev support
From: Maxime Ripard @ 2012-11-07 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352225793-93208-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Le 06/11/2012 19:16, Gwenhael Goavec-Merou a ?crit :
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> ---
> arch/arm/boot/dts/imx28-apf28dev.dts | 19 +++++++++++++++++++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts b/arch/arm/boot/dts/imx28-apf28dev.dts
> index 1643d25..da7013d 100644
> --- a/arch/arm/boot/dts/imx28-apf28dev.dts
> +++ b/arch/arm/boot/dts/imx28-apf28dev.dts
> @@ -27,6 +27,19 @@
> status = "okay";
> };
>
> + ssp2: ssp at 80014000 {
> + compatible = "fsl,imx28-spi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi2_pins_a>;
> + status = "okay";
> +
> + spidev: spidev at 0 {
> + compatible = "spidev";
> + spi-max-frequency = <40000000>;
> + reg = <0>;
> + };
> + };
This won't work, since the compatible string is not matching in the
spidev driver.
You need to add the compatible string of the spi device that you will
drive with spidev in the spidev driver, and then use this string in your
dts.
See
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/129134.html
and
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/129133.html
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
From: Mark Brown @ 2012-11-07 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107084932.GE20063@game.jcrosoft.org>
On Wed, Nov 07, 2012 at 09:49:32AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> yes the pinctrl is mainline in -next via pinctrl tree
> s code does not work on the DT kernel untill it's done
> NACK stand I refuse this touch the at91 dtsi untiol it's done correctly
...and here's another mail (plus a further private mail on the same
subject) by the time I managed to reply to the first one, the timestamps
say in about ten minutes :/ What I'm seeing here is two of the Atmel
maintainers disagreeing about a patch so I've got to pick one view and
right now applying the patch looks like it moves us further forwards.
Like I say it's not an issue right now and it seems like it should be
trivial to fix. Is anything needed here other than adding the
pinctrl_get_set_default() call, in which case would it not be less
effort all round to just send the patch? If there is more involved then
what is needed?
Thinking about it a little more I'm actually wondering why whatever
pinctrl change made this mandatory didn't go through and update all the
drivers.
-------------- 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/20121107/953f097e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: move 'l2_wt_override' variable to proper place
From: Russell King - ARM Linux @ 2012-11-07 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003f01cdbcad$a024c1e0$e06e45a0$%han@samsung.com>
On Wed, Nov 07, 2012 at 03:03:36PM +0900, Jingoo Han wrote:
> Fixed build warning as below:
>
> arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used [-Wunused-variable]
You're too late with this; it's already been resolved.
^ permalink raw reply
* Build failure: drivers/net/wan/wanxlfw.inc
From: Russell King - ARM Linux @ 2012-11-07 9:41 UTC (permalink / raw)
To: linux-arm-kernel
During a randconfig build last night, the following was observed:
BLD FW drivers/net/wan/wanxlfw.inc
/bin/sh: as68k: command not found
In file included from include/linux/kernel.h:10:0,
from include/linux/skbuff.h:17,
from include/linux/hdlc.h:14,
from drivers/net/wan/wanxlfw.S:37:
include/linux/bitops.h:181:2: error: #error BITS_PER_LONG not 32 or 64
In file included from include/linux/string.h:9:0,
from include/linux/dynamic_debug.h:100,
from include/linux/kernel.h:14,
from include/linux/skbuff.h:17,
from include/linux/hdlc.h:14,
from drivers/net/wan/wanxlfw.S:37:
include/uapi/linux/string.h:7:20: fatal error: string.h: No such file or directocompilation terminated.
make[4]: *** [drivers/net/wan/wanxlfw.inc] Error 127
Obviously the lack of as68k doesn't help, but it looks like something is
broken with the includes too.
Full log and config at:
http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2640
http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2640
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Lorenzo Pieralisi @ 2012-11-07 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509987BD.8090800@ti.com>
On Tue, Nov 06, 2012 at 09:57:17PM +0000, Santosh Shilimkar wrote:
> On Tuesday 06 November 2012 03:12 PM, Nicolas Pitre wrote:
> >
> > ... instead of flush_cache_all(). The later unconditionally flushes
> > the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> > is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> > is used. If L2 has to be flushed as well, it should already be done
> > separately on other architectures anyway.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> >
> > diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> > index ab88ed4f8e..2c61085a10 100644
> > --- a/arch/arm/mm/idmap.c
> > +++ b/arch/arm/mm/idmap.c
> > @@ -104,7 +104,7 @@ early_initcall(init_static_idmap);
> > void setup_mm_for_reboot(void)
> > {
> > /* Clean and invalidate L1. */
> > - flush_cache_all();
> > + flush_cache_louis();
> >
> > /* Switch to the identity mapping. */
> > cpu_switch_mm(idmap_pgd, &init_mm);
> >
> Nice. Just one difference is that the I-cache invalidation won't
> happen with this change. Not that it is needed here but capturing
> that in change-log would be good.
Yes, it does happen. The LoUIS API mirrors the flush_cache_all() API in
this respect, and it has to. The only change is the data cache level at
which it operates.
Lorenzo
^ permalink raw reply
* [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-11-07 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9DC1F1@DBDE01.ent.ti.com>
On 05.11.2012 14:29, Philip, Avinash wrote:
> On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
>> On 05.11.2012 12:03, Philip, Avinash wrote:
>>> On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
>>>> This patch adds basic DT bindings for OMAP GPMC.
>>>>
>>>> The actual peripherals are instanciated from child nodes within the GPMC
>>>> node, and the only type of device that is currently supported is NAND.
>>>>
>>>> Code was added to parse the generic GPMC timing parameters and some
>>>> documentation with examples on how to use them.
>>>>
>>>> Successfully tested on an AM33xx board.
>>>>
>>>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>>> [...]
>>>> +
>>>> + nand at 0,0 {
>>>> + reg = <0 0 0>; /* CS0, offset 0 */
>>>> + nand-bus-width = <16>;
>>>> + nand-ecc-mode = "none";
>>>> +
>>>> + gpmc,sync-clk = <0>;
>>>> + gpmc,cs-on = <0>;
>>>> + gpmc,cs-rd-off = <36>;
>>>> + gpmc,cs-wr-off = <36>;
>>>> + gpmc,adv-on = <6>;
>>>> + gpmc,adv-rd-off = <24>;
>>>> + gpmc,adv-wr-off = <36>;
>>>> + gpmc,we-off = <30>;
>>>> + gpmc,oe-off = <48>;
>>>> + gpmc,access = <54>;
>>>> + gpmc,rd-cycle = <72>;
>>>> + gpmc,wr-cycle = <72>;
>>>> + gpmc,wr-access = <30>;
>>>> + gpmc,wr-data-mux-bus = <0>;
>>>> +
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> +
>>>
>>> Can you take the timings (for example) from arago tree. The timings is tested in am335x-evm
>>> So the timings can be directly used to populate GPMC timings. Timings can found at
>>>
>>> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
>>> h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
>>>
>>> [...]
>>>> +static int gpmc_probe_dt(struct platform_device *pdev)
>>>
>>> Can you take care of the following section mismatch.
>>> WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
>>> from the function gpmc_probe_dt() to the function .init.text:gpmc_nand_init().
>>
>> Sore, both fixed for v4.
>>
>>> [...]
>>>> +
>>>> + val = of_get_nand_ecc_mode(child);
>>>> + if (val >= 0)
>>>> + gpmc_nand_data->ecc_opt = val;
>>>
>>> This will fail for BCH. Index of "soft_bch" is 5 & also don't have selection
>>> option between for BCH4 & BCH8 also.
>>> Can you use the of_property_read_u32 (as done early) to pass the ecc selection
>>> from dt file. This will help selection of BCH4 & BCH8 ecc options.
>>
>> Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
>> bring the enum in sync?
>
> ecc_opt is for selecting different ecc layout and not for selecting ecc mode.
>
> In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
> OMAP_ECC_HAMMING_CODE_HW_ROMCODE
> OMAP_ECC_BCH4_CODE_HW
> OMAP_ECC_BCH8_CODE_HW
>
> So selection of ecc layout data should come from DT not ecc mode.
Ok, I see. I would still like to set them by string rather than magic
numbers that map to enum entries. Valid values would be "none", "hw",
"hw-romcode", "bch4" and "bch8". Are you ok with that?
Thanks,
Daniel
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Will Deacon @ 2012-11-07 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106220458.GP28327@n2100.arm.linux.org.uk>
On Tue, Nov 06, 2012 at 10:04:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 04:12:27PM -0500, Nicolas Pitre wrote:
> >
> > ... instead of flush_cache_all(). The later unconditionally flushes
> > the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> > is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> > is used. If L2 has to be flushed as well, it should already be done
> > separately on other architectures anyway.
>
> Why does the cost at reboot count? It's a relatively slow operation as
> it is anyway, because you have to wait for the system to shut down, call
> the boot loader, etc.
>
> However, the opposite argument is that the state of the L2 _shouldn't_
> matter - except for one small little detail. Dirty data, which could
> get evicted and overwrite something that matters. Generally there won't
> be any dirty data in the L2 cache on normal boot, so this is a situation
> which boot loaders probably don't expect.
Wouldn't the L2 flush in this case be included with the code that turns off
caching? For reboot, that's currently done in __sort_restart -- the cache
flush in setup_mm_for_reboot is just to ensure that the idmap tables are
visible to the hardware walker iirc.
Will
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Russell King - ARM Linux @ 2012-11-07 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061745110.21033@xanadu.home>
On Tue, Nov 06, 2012 at 05:53:20PM -0500, Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Russell King - ARM Linux wrote:
>
> > On Tue, Nov 06, 2012 at 04:12:27PM -0500, Nicolas Pitre wrote:
> > >
> > > ... instead of flush_cache_all(). The later unconditionally flushes
> > > the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> > > is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> > > is used. If L2 has to be flushed as well, it should already be done
> > > separately on other architectures anyway.
> >
> > Why does the cost at reboot count? It's a relatively slow operation as
> > it is anyway, because you have to wait for the system to shut down, call
> > the boot loader, etc.
>
> Because I have a use case with the big.LITTLE switcher where the full
> boot is bypassed but the kernel must be reintered as if the CPU was
> powered up. This is of course something that _could_ happen multiple
> times in a second, and therefore minimizing its unneeded costs is a good
> thing(tm).
>
> > However, the opposite argument is that the state of the L2 _shouldn't_
> > matter - except for one small little detail. Dirty data, which could
> > get evicted and overwrite something that matters. Generally there won't
> > be any dirty data in the L2 cache on normal boot, so this is a situation
> > which boot loaders probably don't expect.
>
> In the use case that concerns me, L2 is retained and I'd well prefer if
> it didn't get flushed at all.
>
> > So all in all, I'm not sure of the wiseness of your change. It's likely
> > to cause regressions.
>
> Could you please tell me if you have such a regression in mind? Of
> course I could carry the few operations performed by
> setup_mm_for_reboot() locally, but that looks like useless code
> duplication.
I think I included all the relevant information in the original email.
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Russell King - ARM Linux @ 2012-11-07 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107095106.GA23305@mudshark.cambridge.arm.com>
On Wed, Nov 07, 2012 at 09:51:06AM +0000, Will Deacon wrote:
> Wouldn't the L2 flush in this case be included with the code that turns off
> caching? For reboot, that's currently done in __sort_restart -- the cache
> flush in setup_mm_for_reboot is just to ensure that the idmap tables are
> visible to the hardware walker iirc.
Good point - but it does raise another issue. Why do we do this flush and
TLB invalidate afterwards in setup_mm_for_reboot() ? It makes sense if
we change existing page tables, but we don't anymore, we're just switching
them, and cpu_switch_mm() will do whatever's necessary to make the new
page tables visible. So I think we can get rid of that flusing in there.
^ permalink raw reply
* [PATCH] Revert "serial: omap: fix software flow control"
From: Andreas Bießmann @ 2012-11-07 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350396562-32579-1-git-send-email-balbi@ti.com>
On 16.10.2012 16:09, Felipe Balbi wrote:
> This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> (serial: omap: fix software flow control).
>
> As Russell has pointed out, that commit isn't fixing
> Software Flow Control at all, and it actually makes
> it even more broken.
>
> It was agreed to revert this commit and use Russell's
> latest UART patches instead.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
since 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 made it into stable (at
least 3.4) I think it would be good decision to also apply this revert
to stable until a working solution exists.
Best regards
Andreas Bie?mann
> ---
>
> Hi Greg,
>
> you might prefer to do the revert yourself, in that case just
> revert commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6.
>
> thanks
>
> arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++--
> drivers/tty/serial/omap-serial.c | 12 ++++++------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index f4a4cd0..1957a85 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -40,10 +40,10 @@
> #define OMAP_UART_WER_MOD_WKUP 0X7F
>
> /* Enable XON/XOFF flow control on output */
> -#define OMAP_UART_SW_TX 0x8
> +#define OMAP_UART_SW_TX 0x04
>
> /* Enable XON/XOFF flow control on input */
> -#define OMAP_UART_SW_RX 0x2
> +#define OMAP_UART_SW_RX 0x04
>
> #define OMAP_UART_SYSC_RESET 0X07
> #define OMAP_UART_TCR_TRIG 0X0F
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 6ede6fd..6d3d26a 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -671,19 +671,19 @@ serial_omap_configure_xonxoff
>
> /*
> * IXON Flag:
> - * Flow control for OMAP.TX
> - * OMAP.RX should listen for XON/XOFF
> + * Enable XON/XOFF flow control on output.
> + * Transmit XON1, XOFF1
> */
> if (termios->c_iflag & IXON)
> - up->efr |= OMAP_UART_SW_RX;
> + up->efr |= OMAP_UART_SW_TX;
>
> /*
> * IXOFF Flag:
> - * Flow control for OMAP.RX
> - * OMAP.TX should send XON/XOFF
> + * Enable XON/XOFF flow control on input.
> + * Receiver compares XON1, XOFF1.
> */
> if (termios->c_iflag & IXOFF)
> - up->efr |= OMAP_UART_SW_TX;
> + up->efr |= OMAP_UART_SW_RX;
>
> serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
> serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
>
^ permalink raw reply
* drivers/staging/ced1401/ced_ioc.c:918 GetTransfer() error: potential null dereference 'tx'. (kzalloc returns null)
From: Fengguang Wu @ 2012-11-07 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509a31bd.DqNZ+8tDIvryTj7L%yuanhan.liu@linux.intel.com>
Hi Arnd,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git testing/defconfig-warnings
head: ee68ab14f293996cc746aeb016fd2c124e2914f0
commit: 47b83e2bd41f9cc656b7b933cefec484f4d12026 Fix potential stack overflow locations
date: 2 hours ago
drivers/staging/ced1401/ced_ioc.c:875 WaitEvent() warn: inconsistent returns mutex:&pdx->io_mutex: locked (853) unlocked (841,875)
+ drivers/staging/ced1401/ced_ioc.c:918 GetTransfer() error: potential null dereference 'tx'. (kzalloc returns null)
drivers/staging/ced1401/ced_ioc.c:1079 CheckSelfTest() warn: check that 'gst.code' doesn't leak information
drivers/staging/ced1401/ced_ioc.c:1515 FreeCircBlock() warn: inconsistent returns mutex:&pdx->io_mutex: locked (1512) unlocked (1424,1515)
--
drivers/staging/wlan-ng/hfa384x_usb.c:3517 hfa384x_usbin_rx() error: potential NULL dereference 'rxmeta'.
drivers/staging/wlan-ng/prism2fw.c:594 mkpdrlist() error: buffer overflow 'pda16' 512 <= 512
drivers/staging/wlan-ng/prism2fw.c:635 mkpdrlist() error: buffer overflow 'pda16' 512 <= 512
+ drivers/staging/wlan-ng/prism2fw.c:773 read_cardpda() error: potential null dereference 'msg'. (kmalloc returns null)
--
drivers/misc/lkdtm.c:268 recursive_loop() warn: 'buf' puts 512 bytes on stack
+ drivers/misc/lkdtm.c:270 recursive_loop() error: __builtin_memset() 'buf' too small (512 vs 1024)
drivers/misc/lkdtm.c:301 lkdtm_do_action() error: buffer overflow 'p' 8 <= 12
drivers/misc/lkdtm.c:320 lkdtm_do_action() error: potential null dereference 'data'. (kmalloc returns null)
drivers/misc/lkdtm.c:320 lkdtm_do_action() error: buffer overflow 'data' 255 <= 256
vim +918 +/tx drivers/staging/ced1401/ced_ioc.c
2eae6bdc Alois Schl?gl 2012-09-17 902 ** GetTransferInfo
2eae6bdc Alois Schl?gl 2012-09-17 903 ** Puts the current state of the 1401 in a TGET_TX_BLOCK.
2eae6bdc Alois Schl?gl 2012-09-17 904 *****************************************************************************/
cd915200 Greg Kroah-Hartman 2012-09-17 905 int GetTransfer(DEVICE_EXTENSION * pdx, TGET_TX_BLOCK __user * pTX)
2eae6bdc Alois Schl?gl 2012-09-17 906 {
cd915200 Greg Kroah-Hartman 2012-09-17 907 int iReturn = U14ERR_NOERROR;
cd915200 Greg Kroah-Hartman 2012-09-17 908 unsigned int dwIdent;
cd915200 Greg Kroah-Hartman 2012-09-17 909
cd915200 Greg Kroah-Hartman 2012-09-17 910 mutex_lock(&pdx->io_mutex);
cd915200 Greg Kroah-Hartman 2012-09-17 911 dwIdent = pdx->StagedId; // area ident for last xfer
cd915200 Greg Kroah-Hartman 2012-09-17 912 if (dwIdent >= MAX_TRANSAREAS)
cd915200 Greg Kroah-Hartman 2012-09-17 913 iReturn = U14ERR_BADAREA;
cd915200 Greg Kroah-Hartman 2012-09-17 914 else {
cd915200 Greg Kroah-Hartman 2012-09-17 915 // Return the best information we have - we don't have physical addresses
47b83e2b Arnd Bergmann 2012-10-16 916 TGET_TX_BLOCK *tx;
47b83e2b Arnd Bergmann 2012-10-16 917 tx = kzalloc(sizeof *tx, GFP_KERNEL);
47b83e2b Arnd Bergmann 2012-10-16 @918 tx->size = pdx->rTransDef[dwIdent].dwLength;
47b83e2b Arnd Bergmann 2012-10-16 919 tx->linear = (long long)((long)pdx->rTransDef[dwIdent].lpvBuff);
47b83e2b Arnd Bergmann 2012-10-16 920 tx->avail = GET_TX_MAXENTRIES; // how many blocks we could return
47b83e2b Arnd Bergmann 2012-10-16 921 tx->used = 1; // number we actually return
47b83e2b Arnd Bergmann 2012-10-16 922 tx->entries[0].physical =
47b83e2b Arnd Bergmann 2012-10-16 923 (long long)(tx->linear + pdx->StagedOffset);
47b83e2b Arnd Bergmann 2012-10-16 924 tx->entries[0].size = tx->size;
47b83e2b Arnd Bergmann 2012-10-16 925
47b83e2b Arnd Bergmann 2012-10-16 926 if (copy_to_user(pTX, tx, sizeof(*tx)))
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Will Deacon @ 2012-11-07 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107095635.GV28327@n2100.arm.linux.org.uk>
On Wed, Nov 07, 2012 at 09:56:35AM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 07, 2012 at 09:51:06AM +0000, Will Deacon wrote:
> > Wouldn't the L2 flush in this case be included with the code that turns off
> > caching? For reboot, that's currently done in __sort_restart -- the cache
> > flush in setup_mm_for_reboot is just to ensure that the idmap tables are
> > visible to the hardware walker iirc.
>
> Good point - but it does raise another issue. Why do we do this flush and
> TLB invalidate afterwards in setup_mm_for_reboot() ? It makes sense if
> we change existing page tables, but we don't anymore, we're just switching
> them, and cpu_switch_mm() will do whatever's necessary to make the new
> page tables visible. So I think we can get rid of that flusing in there.
Hmm, I'm not sure about that. Looking at cpu_v7_switch_mm (the 2-level
version) for example, we set the ASID and then set the new TTBR. There's no
flushing of page tables like we get in set_pte and no TLB flushing either.
Now, given that the idmap_pgd is populated as an early_initcall, I really
doubt we need that flush_cache_all but the TLB invalidate is surely
required?
Will
^ permalink raw reply
* [PATCHv9 2/8] ARM: OMAP4: PM: add errata support
From: Tero Kristo @ 2012-11-07 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d2zq761g.fsf@deeprootsystems.com>
On Tue, 2012-11-06 at 13:52 -0800, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
> > Tero Kristo <t-kristo@ti.com> writes:
> >
> >> Added similar PM errata flag support as omap3 has. This should be used
> >> in similar manner, set the flags during init time, and check the flag
> >> values during runtime.
> >>
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >
> > These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going
> > to queue these up as fixes.
> >
> > However, since they're not technically regressions, it may be too late
> > to get them in for v3.7, but they'll be in for v3.8 for sure.
>
> To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes
> for v3.8 (branch: for_3.8/fixes/pm).
>
> Paul has already queued patch 1, so that leaves patches 4, 5, 7 & 8.
>
> I think we can get this series in for v3.8 if we drop the functional
> pwrst dependency. To test, I dropped patches 5 & 7, and tested on
> 4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE
> is hitting retention just fine in suspend.
>
> If you can respin patch 8 based on the feedback from Felipe, I'll queue
> up patches 4 & 8 for v3.8 as well, then we'll at least have CORE
> retention in suspend in mainline. Then, the rest can be done when
> functional pwrsts are ready.
Yea, I can do that on Friday once I get back home, I am travelling
currently.
>
> Kevin
>
> P.S. do you have any patches to add any OMAP4 CPUidle support for CORE
> retention?
No, cpuidle core ret should work with this set already. Not sure what
happens without the func pwrst patches, I have not tested with that
setup lately. I can try this out on Friday as well.
-Tero
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Tero Kristo @ 2012-11-07 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqxy77li.fsf@deeprootsystems.com>
On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >>
> >> Tero Kristo <t-kristo@ti.com> writes:
> >>
> >> > Hi,
> >> >
> >> > Changes compared to previous version:
> >> > - rebased on top of 3.7-rc1
> >> > - applies on top of latest func pwrst code (v6)
> >> > - added back patch #1 to this set (it wasn't queued yet after all)
> >> > - added patch #7 for fixing a bug in the functional pwrst code
> >> > - added patch #8 for fixing a regression with MUSB PHY power handling
> >> > (not quite sure if this is the correct way to fix this or not)
> >> >
> >> > Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
> >> > suspend.
> >> >
> >> > Branch also available here:
> >> > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> >> > branch: mainline-3.7-rc1-omap4-ret-v9
> >>
> >> I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
> >> several domains not hitting target power state in suspend[1].
> >>
> >> Am I missing some other fixes? Using omap2plus_defconfig, I tried your
> >> branch alone, and merged with v3.7-rc4, and I get the same errors.
>
> [...]
>
> > This looks like a combination of boot loader/kernel problems. My guess
> > is that l3init is probably held on by the USB, and both ivahd / tesla
> > are held on by some DSP/IVA modules which are not idling properly.
> >
> > The last patch in this set should fix the USB problems at least
> > partially, but also the USB DPLL itself might be in wrong state,
> > attached patch might help for that one and get l3init to idle.
> >
> > For DSP I don't have a patch right now, what is the boot loader you are
> > using? (Can you provide git / commit / config info?)
>
> I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
>
> To check the bootloader, I upgraded to the latest mainline tag
> (v2012.10) and the problems are gone on both 4430/Panda and
> 4460/Panda-ES... Interesting.
>
> That suggests that there's still some kernel assumptions/dependencies on
> the bootloader that need to be addressed.
I am not surprised of that, the all so common bootloader madness hits
again. Anyway, I can try with the bootloader tag you used hopefully next
week and see if I can figure out something. The l3init problem can
probably be fixed rather easily if it is because of the USB, but the
tesla / ivahd might be more problematic... last time I saw that problem
I wasn't able to recover from the situation without power on reset...
bootloader took the tesla out of reset and it seemed impossible to put
it back to idle after that. I tried resetting the DSP but it didn't
help. Also, I didn't find a bootmode register similar to what omap3 has.
-Tero
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Will Deacon @ 2012-11-07 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061802240.21033@xanadu.home>
On Tue, Nov 06, 2012 at 11:14:06PM +0000, Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Arnd Bergmann wrote:
>
> > On Tuesday 06 November 2012, Nicolas Pitre wrote:
> > > I really think that it makes no sense at all to support !MMU kernels in
> > > a multi-platform kernel build, even if the set of included platforms
> > > were all !MMU. The kernel has to be linked for the physical address of
> > > the target and not a common invariant virtual address.
> >
> > There are two separate aspects here: One is to run a kernel on !MMU that is
> > built to support multiple platforms. I agree that this is rather pointless
> > and not interesting.
> >
> > The other point is being able to build such a kernel, and this is what Will
> > seems to be interested in more.
>
> What's the point of building a pointless and uninteresting kernel?
>
> Sure, wide build coverage is good. But pointless builds are not.
> Comes a point where Kconfig should serve its purpose i.e. help the user
> make a valid kernel configuration for himself. And I really think that
> multi-platform and !MMU together don't make for a valid configuration
> anymore.
If it's just the physical memory map that gets in the way for multiplatform
!MMU, it's probably worth me pointing out that for PMSAv7 (i.e. R-class
cores) there is a mandated default memory map, which does make this problem
largely disappear.
All said and done, I don't see anybody ever using the option though --
distributions will likely never ship nommu kernels and they typically get
deployed in one place only with an emphasis on keeping the thing small.
Will
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-11-07 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106215044.GB21764@mudshark.cambridge.arm.com>
Hi Will,
thanks for the review on the series.
On Tue, Nov 06, 2012 at 09:50:44PM +0000, Will Deacon wrote:
> On Tue, Oct 16, 2012 at 02:21:45PM +0100, Lorenzo Pieralisi wrote:
> > When booting through a device tree, the kernel cpu logical id map can be
> > initialized using device tree data passed by FW or through an embedded blob.
> >
> > This patch adds a function that parses device tree "cpu" nodes and
> > retrieves the corresponding CPUs hardware identifiers (MPIDR).
> > It sets the possible cpus and the cpu logical map values according to
> > the number of CPUs defined in the device tree and respective properties.
> >
> > The primary CPU is assigned cpu logical number 0 to keep the current
> > convention valid.
> >
> > Current bindings documentation is included in the patch:
> >
> > Documentation/devicetree/bindings/arm/cpus.txt
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> [...]
>
> > +void __init arm_dt_init_cpu_maps(void)
> > +{
> > + struct device_node *dn = NULL;
> > + int i, cpu = 1;
> > +
> > + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
> > + const u32 *hwid;
> > + int len;
> > +
> > + pr_debug(" * %s...\n", dn->full_name);
> > +
> > + hwid = of_get_property(dn, "reg", &len);
> > +
> > + if (!hwid || len != 4) {
> > + pr_err(" * %s missing reg property\n", dn->full_name);
> > + continue;
> > + }
> > + /*
> > + * We want to assign the boot CPU logical id 0.
> > + * Boot CPU checks its own MPIDR and if matches the current
> > + * cpu node "reg" value it sets the logical cpu index to 0
> > + * and stores the physical id accordingly.
> > + * If MPIDR does not match, assign sequential cpu logical
> > + * id (starting from 1) and increments it.
> > + */
> > + i = (be32_to_cpup(hwid) == (read_cpuid_mpidr() & 0xffffff))
> > + ? 0 : cpu++;
> > +
> > + if (!i)
> > + printk(KERN_INFO "Booting Linux on CPU HWID 0x%x\n",
> > + be32_to_cpup(hwid));
>
> I don't think we should bother with this print -- we already print something
> in smp_setup_processor_id, which cannot differ for the boot CPU, If you want
> the full mpidr, we could change that code to include it as well.
Yes, it is duplicate code, I will remove it. Extending the printk in
smp_setup_processor_id() to include the entire MPIDR should be done
though, otherwise we might have printk aliases on system with multiple
clusters.
>
> We might also want some sanity checking that we do indeed end up with
> logical id 0 for the boot CPU. If not, I think we should scream and fall
> back on the simple mapping created earlier.
Well, this basically means that we have to make sure this function is
executed on the boot CPU (and it is as the code stands now), right ?
Since we are reading the MPIDR of the CPU parsing the tree and assign logical
cpu 0 accordingly I think we have this check carried out automatically,
unless for any given reason someone calls this function on a CPU that is
not the boot one (Why ?).
Basically I could add a check like:
if (WARN_ON(smp_processor_id())
return;
to fall back to the previous mapping, but that's overkill IMHO.
Thanks,
Lorenzo
^ permalink raw reply
* [RFC PATCH 4/4] ARM: gic: use a private mapping for CPU target interfaces
From: Will Deacon @ 2012-11-07 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061755260.21033@xanadu.home>
On Tue, Nov 06, 2012 at 10:59:35PM +0000, Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Will Deacon wrote:
> > > arch/arm/common/gic.c | 42 ++++++++++++++++++++++++++++++++++--------
> > > 1 file changed, 34 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> > > index aa52699..1338a55 100644
> > > --- a/arch/arm/common/gic.c
> > > +++ b/arch/arm/common/gic.c
> > > @@ -70,6 +70,13 @@ struct gic_chip_data {
> > > static DEFINE_RAW_SPINLOCK(irq_controller_lock);
> > >
> > > /*
> > > + * The GIC mapping of CPU interfaces does not necessarily match
> > > + * the logical CPU numbering. Let's use a mapping as returned
> > > + * by the GIC itself.
> > > + */
> > > +static u8 gic_cpu_map[8] __read_mostly;
> >
> > Can we have a #define for the number CPUs supported by the GIC? It gets
> > used a fair amount in this patch for loop bounds etc.
>
> Sure. I'll respin the patch.
Cheers Nicolas.
> > > /*
> > > + * Get what the GIC says our CPU mask is.
> > > + */
> > > + BUG_ON(cpu >= 8);
> > > + cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
> >
> > Making the mask a u8 and using readb_relaxed here makes this bit of code
> > clearer to me (and the GIC apparently allows such an access to this
> > register).
>
> Not always. At least RTSM throws an exception if you do so.
> Been there.
That would be a bug in the RTSM then. Have you reported it to support? (if
not, I can chase this one up). I'd rather we just fix the model than work
around it in Linux.
Will
^ 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