* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BD496.6080305@ti.com>
On Fri, Feb 01, 2013 at 08:13:34PM +0530, Santosh Shilimkar wrote:
> On Friday 01 February 2013 08:01 PM, Russell King - ARM Linux wrote:
>> Just to further provide some insight into the reasoning:
>>
>> Invalidating data out of a working cache risks data corruption; maybe
>> the data being invalidated is filesystem metadata which was about to
>> be cleaned and written back to storage. That risks filesystem
>> corruption.
>>
>> Invalidating fewer levels than are actually required is different: we
>> may leave dirty cache lines behind which may be evicted, but there's
>> also the chance that the CPU will end up _reading_ from its
>> uninitialized caches and may crash before that happens.
>>
>> So, the risks are:
>> 1. invalidate more levels than are necessary and risk discarding data
>> which other CPUs are using, which may be important data.
>> 2. invalidate less levels than are necessary and risk writing out
>> data from the CPU cache, which may or may not happen _before_ the
>> CPU crashes due to reading invalid data.
>>
>> Out of those two, (2) sounds to me to be the safer approach.
>>
>> Plus, I can't think of a reason why you'd want to put on a SMP system
>> more than one layer of CPU local caches... to do so would seem to me to
>> be an exercise in coherency complexity... So, I suspect that in the
>> real world, we will _never_ see any system which has more than one
>> layer of caches local to the CPU. But we may see a system with a
>> cache architecture similar to the one I drew in my email to Santosh.
>>
> I still scratching my head on why you would even have a CPU design
> with two L2 shared caches for a 4 CPU system.
>
> If you ever design such a system, you need to ensure that
>
> 1. Both L2 are used in exclusive mode
> 2. Both L2 cache has coherency hardware connected to keep them in sync
> for shared data.
>
> For 1, one would just increase the size of L2 and have only 1 memory.
>
> 2 Doesn't bring much advantage unless and until your L3 is too far
> away for access in terms of CPU access cycles.
I don't think you quite understood my diagram. There aren't two separate
L2 data caches (CL1I and CL1D). I'm showing the L2 cache as having a
harvard structure (separate instruction and data) with no coherency
between them - and because they're harvard structured, that means the
unification level must be _below_ that point.
^ permalink raw reply
* [PATCH] ARM: Exynos: enable ARM_HAS_SG_CHAIN
From: Marek Szyprowski @ 2013-02-01 14:49 UTC (permalink / raw)
To: linux-arm-kernel
Exynos DRM driver needs support for scatter-list chaining and all
drivers available on Samsung platform, which use scatter-lists are
already aware of chaining api, so lets enable global support for it.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cb06d7a..939b0d9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -836,6 +836,7 @@ config ARCH_EXYNOS
select ARCH_HAS_CPUFREQ
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_SPARSEMEM_ENABLE
+ select ARM_HAS_SG_CHAIN
select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201143136.GP23505@n2100.arm.linux.org.uk>
On Friday 01 February 2013 08:01 PM, Russell King - ARM Linux wrote:
> Just to further provide some insight into the reasoning:
>
> Invalidating data out of a working cache risks data corruption; maybe
> the data being invalidated is filesystem metadata which was about to
> be cleaned and written back to storage. That risks filesystem
> corruption.
>
> Invalidating fewer levels than are actually required is different: we
> may leave dirty cache lines behind which may be evicted, but there's
> also the chance that the CPU will end up _reading_ from its
> uninitialized caches and may crash before that happens.
>
> So, the risks are:
> 1. invalidate more levels than are necessary and risk discarding data
> which other CPUs are using, which may be important data.
> 2. invalidate less levels than are necessary and risk writing out
> data from the CPU cache, which may or may not happen _before_ the
> CPU crashes due to reading invalid data.
>
> Out of those two, (2) sounds to me to be the safer approach.
>
> Plus, I can't think of a reason why you'd want to put on a SMP system
> more than one layer of CPU local caches... to do so would seem to me to
> be an exercise in coherency complexity... So, I suspect that in the
> real world, we will _never_ see any system which has more than one
> layer of caches local to the CPU. But we may see a system with a
> cache architecture similar to the one I drew in my email to Santosh.
>
I still scratching my head on why you would even have a CPU design
with two L2 shared caches for a 4 CPU system.
If you ever design such a system, you need to ensure that
1. Both L2 are used in exclusive mode
2. Both L2 cache has coherency hardware connected to keep them in sync
for shared data.
For 1, one would just increase the size of L2 and have only 1 memory.
2 Doesn't bring much advantage unless and until your L3 is too far
away for access in terms of CPU access cycles.
Regards
Santosh
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Jon Medhurst (Tixy) @ 2013-02-01 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301311521310.6300@xanadu.home>
On Thu, 2013-01-31 at 15:31 -0500, Nicolas Pitre wrote:
> On Thu, 31 Jan 2013, Russell King - ARM Linux wrote:
>
> > On Thu, Jan 31, 2013 at 12:32:11PM -0500, Nicolas Pitre wrote:
> > > On Thu, 31 Jan 2013, Russell King - ARM Linux wrote:
> > >
> > > > I haven't tried Versatile Express yet as it has the TC2 tile on, and I
> > > > don't yet a boot loader on it which is capable of TFTP (which makes it
> > > > rather useless to me - I've been saying this for a time now but this is
> > > > probably the first time publically.) I'm thinking about putting the
> > > > CA9x4 tile back on because that's a lot more functionally useful to me
> > > > than TC2.
> > >
> > > You might be interested by this then:
> > >
> > > http://lists.linaro.org/pipermail/linaro-dev/2012-October/014136.html
> >
> > Great news. Everyone has been telling me that there's no uboot for TC2,
> > or "we think Linaro might have something but we don't really know".
>
> Note that I cobbled those instructions on my own and the result is not
> officially supported by Linaro. This is obviously not suitable for
> setting up products or demo systems, but for a kernel developer I think
> such a setup is invaluable.
If I remember correctly, you will also only get 1GB of RAM available not
the 2GB most TC2 boards have. (I did take a quick look at hacking U-Boot
to get around that but couldn't get anything to work.)
--
Tixy
^ permalink raw reply
* [PATCH 43 0/3] Kirkwoode cpufreq driver
From: Andrew Lunn @ 2013-02-01 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokjN8kx9Tan=wG4d0tdicWpb6DLN7o+rbX5f9oppJK7bA@mail.gmail.com>
On Fri, Feb 01, 2013 at 08:04:27PM +0530, Viresh Kumar wrote:
> On 1 February 2013 20:01, Andrew Lunn <andrew@lunn.ch> wrote:
> > This patchset adds a cpufreq driver for Marvell Kirkwood SoCs.
> >
> > The changes to kirkwood_defconfig enable it and set the default
> > governor to ondemand.
>
> Wow! [PATCH 43 0/3] :)
> It looks you are adding v4 manually to every patch?
No, I just edited the cover note. For the others i used --subject=...
Andrew
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Mohammed, Afzal @ 2013-02-01 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BD1CA.9020309@ti.com>
Hi Roger,
On Fri, Feb 01, 2013 at 20:01:38, Quadros, Roger wrote:
> but DT boot is not supported for OMAP USB Host. How did you get it to work?
>
> Are you testing the Host connector or the OTG connector?
If you see latest changes on musb_dsps.c, you will be able to find
out.
As beagle bone first instance works only in device, it was tested
using ether gadget.
Regards
Afzal
^ permalink raw reply
* [PATCH 43 0/3] Kirkwoode cpufreq driver
From: Viresh Kumar @ 2013-02-01 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359729096-15371-1-git-send-email-andrew@lunn.ch>
On 1 February 2013 20:01, Andrew Lunn <andrew@lunn.ch> wrote:
> This patchset adds a cpufreq driver for Marvell Kirkwood SoCs.
>
> The changes to kirkwood_defconfig enable it and set the default
> governor to ondemand.
Wow! [PATCH 43 0/3] :)
It looks you are adding v4 manually to every patch? If yes, you need to
use following:
git format-patch A..B --cover-letter --subject-prefix="PATCH V4"
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Lorenzo Pieralisi @ 2013-02-01 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201141914.GO23505@n2100.arm.linux.org.uk>
On Fri, Feb 01, 2013 at 02:19:14PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 02:10:52PM +0000, Lorenzo Pieralisi wrote:
> > On Fri, Feb 01, 2013 at 12:54:17PM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Feb 01, 2013 at 12:11:38PM +0000, Lorenzo Pieralisi wrote:
> > > > Well, on latest processors (A15, A7) caches are invalidated on reset unless
> > > > the chip is programmed to skip that on reset (ie L2 retained).
> > > >
> > > > But it makes sense, for sure it should not be called v7_invalidate_l1,
> > > > but invalidate_louis, and instead of forcing level 0 we should be
> > > > reading LoUIS and invalidate up to that level as we do in the clean and
> > > > invalidate function.
> > >
> > > No. Think about it. c7, c6, 2 _invalidates_ the cache. That means any
> > > data contained within the cache is discarded. Data is not written back.
> > >
> > > If you do this down to the LoUIS, that includes all cache levels in the
> > > inner sharable domain. The inner sharable domain includes the other CPUs
> > > in the system which may already be running (certainly the boot CPU will
> > > be running).
> >
> > On all v7 ARM systems I know of LoUIS correspond to L1 and using LoUIS is a
> > plaster that works for current systems (where by LoUIS I mean all cache
> > levels down to but not inclusive of, LoUIS).
>
> All that I'm saying is that suggesting that v7_invalidate_l1 should go
> down to LoUIS is wrong, in much the same way as _invalidating_ only the
> first level of cache.
>
> However, invalidating the first level of cache only is safer than
> invalidating down to LoUIS.
>
> The only path which needs this is the secondary CPU bringup path; that's
> the only path we have where some platforms give us a CPU which has only
> just come out of reset, and so the caches for that CPU may be in an
> unknown state. And it only happens to a small subset of platforms.
>
> Currently, that small subset of platforms only need the first level of
> cache invalidating. (Most platforms don't need this; most platforms
> this would be a waste of time - and people seem to care about hotplug
> times.)
>
> So, that's what we should do. And v7_invalidate_l1 is a perfectly
> reasonable name for a function to do that for the V7 architecture.
>
> As has been pointed out, there's several duplications of that. That's
> fine, let's move them into the v7 cache code. But... let's not change
> how they work and go through a pointless design exercise for
> invalidating more levels of cache when we know that no platform needs
> it.
>
> If/when we do end up with a platform which requires it, we can deal
> with it then. But let's not lead people down the route of thinking
> that LoUIS is suitable here when it isn't.
Your point is fair Russell, and I agree with that in the context you
provided. Last thing I want to mention is that duplicating code that
loops through sets/ways is not that great, but I also understand that
refactoring the code to share the loop in v7_flush_dcache_all might
do more harm than good and introduce bugs, so let's merge the
invalidate_l1 function as it stands.
Thank you,
Lorenzo
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Roger Quadros @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9FFD5@DBDE01.ent.ti.com>
On 02/01/2013 04:27 PM, Mohammed, Afzal wrote:
> Hi Roger,
>
> On Fri, Feb 01, 2013 at 19:55:14, Quadros, Roger wrote:
>
>> Thanks Afzal :). You mean the non device tree boot right?
>
> No, dt boot, am335x can only dt boot.
but DT boot is not supported for OMAP USB Host. How did you get it to work?
Are you testing the Host connector or the OTG connector?
regards,
-roger
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201141914.GO23505@n2100.arm.linux.org.uk>
On Fri, Feb 01, 2013 at 02:19:14PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 02:10:52PM +0000, Lorenzo Pieralisi wrote:
> > On Fri, Feb 01, 2013 at 12:54:17PM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Feb 01, 2013 at 12:11:38PM +0000, Lorenzo Pieralisi wrote:
> > > > Well, on latest processors (A15, A7) caches are invalidated on reset unless
> > > > the chip is programmed to skip that on reset (ie L2 retained).
> > > >
> > > > But it makes sense, for sure it should not be called v7_invalidate_l1,
> > > > but invalidate_louis, and instead of forcing level 0 we should be
> > > > reading LoUIS and invalidate up to that level as we do in the clean and
> > > > invalidate function.
> > >
> > > No. Think about it. c7, c6, 2 _invalidates_ the cache. That means any
> > > data contained within the cache is discarded. Data is not written back.
> > >
> > > If you do this down to the LoUIS, that includes all cache levels in the
> > > inner sharable domain. The inner sharable domain includes the other CPUs
> > > in the system which may already be running (certainly the boot CPU will
> > > be running).
> >
> > On all v7 ARM systems I know of LoUIS correspond to L1 and using LoUIS is a
> > plaster that works for current systems (where by LoUIS I mean all cache
> > levels down to but not inclusive of, LoUIS).
>
> All that I'm saying is that suggesting that v7_invalidate_l1 should go
> down to LoUIS is wrong, in much the same way as _invalidating_ only the
> first level of cache.
>
> However, invalidating the first level of cache only is safer than
> invalidating down to LoUIS.
>
> The only path which needs this is the secondary CPU bringup path; that's
> the only path we have where some platforms give us a CPU which has only
> just come out of reset, and so the caches for that CPU may be in an
> unknown state. And it only happens to a small subset of platforms.
>
> Currently, that small subset of platforms only need the first level of
> cache invalidating. (Most platforms don't need this; most platforms
> this would be a waste of time - and people seem to care about hotplug
> times.)
>
> So, that's what we should do. And v7_invalidate_l1 is a perfectly
> reasonable name for a function to do that for the V7 architecture.
>
> As has been pointed out, there's several duplications of that. That's
> fine, let's move them into the v7 cache code. But... let's not change
> how they work and go through a pointless design exercise for
> invalidating more levels of cache when we know that no platform needs
> it.
>
> If/when we do end up with a platform which requires it, we can deal
> with it then. But let's not lead people down the route of thinking
> that LoUIS is suitable here when it isn't.
Just to further provide some insight into the reasoning:
Invalidating data out of a working cache risks data corruption; maybe
the data being invalidated is filesystem metadata which was about to
be cleaned and written back to storage. That risks filesystem
corruption.
Invalidating fewer levels than are actually required is different: we
may leave dirty cache lines behind which may be evicted, but there's
also the chance that the CPU will end up _reading_ from its
uninitialized caches and may crash before that happens.
So, the risks are:
1. invalidate more levels than are necessary and risk discarding data
which other CPUs are using, which may be important data.
2. invalidate less levels than are necessary and risk writing out
data from the CPU cache, which may or may not happen _before_ the
CPU crashes due to reading invalid data.
Out of those two, (2) sounds to me to be the safer approach.
Plus, I can't think of a reason why you'd want to put on a SMP system
more than one layer of CPU local caches... to do so would seem to me to
be an exercise in coherency complexity... So, I suspect that in the
real world, we will _never_ see any system which has more than one
layer of caches local to the CPU. But we may see a system with a
cache architecture similar to the one I drew in my email to Santosh.
^ permalink raw reply
* [PATCH v4 3/3] arm: kirkwood: Enable cpufreq and ondemand on kirkwood_defconfig
From: Andrew Lunn @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359729096-15371-1-git-send-email-andrew@lunn.ch>
Now that we have a cpufreq driver for kirkwood, enable it in
kirkwood_defconfig and set the default governer to ondemand.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
To be commited by: Jason Coope
arch/arm/configs/kirkwood_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 93f3794..6ecb7de 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -55,6 +55,9 @@ CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_IDLE=y
CONFIG_NET=y
CONFIG_PACKET=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 2/3] arm: kirkwood: Instantiate cpufreq driver
From: Andrew Lunn @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359729096-15371-1-git-send-email-andrew@lunn.ch>
Register a platform driver structure for the cpufreq driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
To be commited by: Jason Coope
arch/arm/Kconfig | 1 +
arch/arm/mach-kirkwood/board-dt.c | 3 ++-
arch/arm/mach-kirkwood/common.c | 23 +++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 2 ++
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 2 ++
5 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..830975b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -543,6 +543,7 @@ config ARCH_DOVE
config ARCH_KIRKWOOD
bool "Marvell Kirkwood"
+ select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
select CPU_FEROCEON
select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index de4fd2b..fab541d 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -70,7 +70,6 @@ static void __init kirkwood_legacy_clk_init(void)
clkspec.args[0] = CGC_BIT_SDIO;
orion_clkdev_add(NULL, "mvsdio",
of_clk_get_from_provider(&clkspec));
-
}
static void __init kirkwood_of_clk_init(void)
@@ -95,6 +94,8 @@ static void __init kirkwood_dt_init(void)
kirkwood_l2_init();
+ kirkwood_cpufreq_init();
+
/* Setup root of clk tree */
kirkwood_of_clk_init();
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index bac21a5..a3dc21c 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -584,6 +584,29 @@ void __init kirkwood_audio_init(void)
}
/*****************************************************************************
+ * CPU Frequency
+ ****************************************************************************/
+static struct resource kirkwood_cpufreq_resources[] = {
+ [0] = {
+ .start = CPU_CONTROL_PHYS,
+ .end = CPU_CONTROL_PHYS + 3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device kirkwood_cpufreq_device = {
+ .name = "kirkwood-cpufreq",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(kirkwood_cpufreq_resources),
+ .resource = kirkwood_cpufreq_resources,
+};
+
+void __init kirkwood_cpufreq_init(void)
+{
+ platform_device_register(&kirkwood_cpufreq_device);
+}
+
+/*****************************************************************************
* General
****************************************************************************/
/*
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 5ffa57f..9ede04b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -50,6 +50,8 @@ void kirkwood_nand_init(struct mtd_partition *parts, int nr_parts, int delay);
void kirkwood_nand_init_rnb(struct mtd_partition *parts, int nr_parts,
int (*dev_ready)(struct mtd_info *));
void kirkwood_audio_init(void);
+void kirkwood_cpufreq_init(void);
+
void kirkwood_restart(char, const char *);
void kirkwood_clk_init(void);
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index 5c82b7d..d4cbe5e 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -17,6 +17,7 @@
#define CPU_CONFIG_ERROR_PROP 0x00000004
#define CPU_CONTROL (BRIDGE_VIRT_BASE + 0x0104)
+#define CPU_CONTROL_PHYS (BRIDGE_PHYS_BASE + 0x0104)
#define CPU_RESET 0x00000002
#define RSTOUTn_MASK (BRIDGE_VIRT_BASE + 0x0108)
@@ -69,6 +70,7 @@
#define CGC_RUNIT (1 << 7)
#define CGC_XOR0 (1 << 8)
#define CGC_AUDIO (1 << 9)
+#define CGC_POWERSAVE (1 << 11)
#define CGC_SATA0 (1 << 14)
#define CGC_SATA1 (1 << 15)
#define CGC_XOR1 (1 << 16)
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359729096-15371-1-git-send-email-andrew@lunn.ch>
The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
CPU can either use the a high speed cpu clock, or the slower DDR
clock. Add a driver to swap between these two clock sources.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
To be commited by: Rafael J. Wysocki
drivers/clk/mvebu/clk-gating-ctrl.c | 1 +
drivers/cpufreq/Kconfig.arm | 6 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/kirkwood-cpufreq.c | 277 +++++++++++++++++++++++++++++++++++
4 files changed, 285 insertions(+)
create mode 100644 drivers/cpufreq/kirkwood-cpufreq.c
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
index 8fa5408..ebf141d 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -193,6 +193,7 @@ static const struct mvebu_soc_descr __initconst kirkwood_gating_descr[] = {
{ "runit", NULL, 7 },
{ "xor0", NULL, 8 },
{ "audio", NULL, 9 },
+ { "powersave", "cpuclk", 11 },
{ "sata0", NULL, 14 },
{ "sata1", NULL, 15 },
{ "xor1", NULL, 16 },
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index a0b3661..80c8229 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,12 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_KIRKWOOD_CPUFREQ
+ def_bool ARCH_KIRKWOOD && OF
+ help
+ This adds the CPUFreq driver for Marvell Kirkwood
+ SoCs.
+
config ARM_SPEAR_CPUFREQ
bool "SPEAr CPUFreq support"
depends on PLAT_SPEAR
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..39a0ffe 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
new file mode 100644
index 0000000..8923689
--- /dev/null
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -0,0 +1,277 @@
+/*
+ * kirkwood_freq.c: cpufreq driver for the Marvell kirkwood
+ *
+ * Copyright (C) 2013 Andrew Lunn <andrew@lunn.ch>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/cpufreq.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <asm/proc-fns.h>
+
+#define CPU_SW_INT_BLK BIT(28)
+
+static struct priv
+{
+ struct clk *cpu_clk;
+ struct clk *ddr_clk;
+ struct clk *powersave_clk;
+ struct device *dev;
+ void __iomem *base;
+} priv;
+
+#define STATE_CPU_FREQ 0x01
+#define STATE_DDR_FREQ 0x02
+
+/*
+ * Kirkwood can swap the clock to the CPU between two clocks:
+ *
+ * - cpu clk
+ * - ddr clk
+ *
+ * The frequencies are set at runtime before registering this *
+ * table.
+ */
+static struct cpufreq_frequency_table kirkwood_freq_table[] = {
+ {STATE_CPU_FREQ, 0}, /* CPU uses cpuclk */
+ {STATE_DDR_FREQ, 0}, /* CPU uses ddrclk */
+ {0, CPUFREQ_TABLE_END},
+};
+
+static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
+{
+ if (__clk_is_enabled(priv.powersave_clk))
+ return kirkwood_freq_table[1].frequency;
+ return kirkwood_freq_table[0].frequency;
+}
+
+static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
+{
+ struct cpufreq_freqs freqs;
+ unsigned int state = kirkwood_freq_table[index].index;
+ unsigned long reg;
+
+ freqs.old = kirkwood_cpufreq_get_cpu_frequency(0);
+ freqs.new = kirkwood_freq_table[index].frequency;
+ freqs.cpu = 0; /* Kirkwood is UP */
+
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+ dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n",
+ kirkwood_freq_table[index].frequency);
+ dev_dbg(priv.dev, "old frequency was %i KHz\n",
+ kirkwood_cpufreq_get_cpu_frequency(0));
+
+ if (freqs.old != freqs.new) {
+ local_irq_disable();
+
+ /* Disable interrupts to the CPU */
+ reg = readl_relaxed(priv.base);
+ reg |= CPU_SW_INT_BLK;
+ writel_relaxed(reg, priv.base);
+
+ switch (state) {
+ case STATE_CPU_FREQ:
+ clk_disable(priv.powersave_clk);
+ break;
+ case STATE_DDR_FREQ:
+ clk_enable(priv.powersave_clk);
+ break;
+ }
+
+ /* Wait-for-Interrupt, while the hardware changes frequency */
+ cpu_do_idle();
+
+ /* Enable interrupts to the CPU */
+ reg = readl_relaxed(priv.base);
+ reg &= ~CPU_SW_INT_BLK;
+ writel_relaxed(reg, priv.base);
+
+ local_irq_enable();
+ }
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+};
+
+static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy, kirkwood_freq_table);
+}
+
+static int kirkwood_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ unsigned int index = 0;
+
+ if (cpufreq_frequency_table_target(policy, kirkwood_freq_table,
+ target_freq, relation, &index))
+ return -EINVAL;
+
+ kirkwood_cpufreq_set_cpu_state(index);
+
+ return 0;
+}
+
+/* Module init and exit code */
+static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+ int result;
+
+ /* cpuinfo and default policy values */
+ policy->cpuinfo.transition_latency = 5000; /* 5uS */
+ policy->cur = kirkwood_cpufreq_get_cpu_frequency(0);
+
+ result = cpufreq_frequency_table_cpuinfo(policy, kirkwood_freq_table);
+ if (result)
+ return result;
+
+ cpufreq_frequency_table_get_attr(kirkwood_freq_table, policy->cpu);
+
+ return 0;
+}
+
+static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+ cpufreq_frequency_table_put_attr(policy->cpu);
+ return 0;
+}
+
+static struct freq_attr *kirkwood_cpufreq_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
+static struct cpufreq_driver kirkwood_cpufreq_driver = {
+ .get = kirkwood_cpufreq_get_cpu_frequency,
+ .verify = kirkwood_cpufreq_verify,
+ .target = kirkwood_cpufreq_target,
+ .init = kirkwood_cpufreq_cpu_init,
+ .exit = kirkwood_cpufreq_cpu_exit,
+ .name = "kirkwood-cpufreq",
+ .owner = THIS_MODULE,
+ .attr = kirkwood_cpufreq_attr,
+};
+
+static int kirkwood_cpufreq_probe(struct platform_device *pdev)
+{
+ struct device_node *np_core = of_find_compatible_node(
+ NULL, NULL, "marvell,kirkwood-core-clock");
+ struct device_node *np_gating = of_find_compatible_node(
+ NULL, NULL, "marvell,kirkwood-gating-clock");
+ struct of_phandle_args clkspec;
+ struct resource *res;
+ int err;
+
+ if (!np_core || !np_gating) {
+ if (np_core)
+ of_node_put(np_core);
+ if (np_gating)
+ of_node_put(np_gating);
+ return -ENODEV;
+ }
+
+ priv.dev = &pdev->dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Cannot get memory resource\n");
+ return -ENODEV;
+ }
+ priv.base = devm_request_and_ioremap(&pdev->dev, res);
+ if (!priv.base) {
+ dev_err(&pdev->dev, "Cannot ioremap\n");
+ return -EADDRNOTAVAIL;
+ }
+
+ clkspec.np = np_core;
+ clkspec.args_count = 1;
+ clkspec.args[0] = 1;
+
+ priv.cpu_clk = of_clk_get_from_provider(&clkspec);
+ if (IS_ERR(priv.cpu_clk)) {
+ dev_err(priv.dev, "Unable to get cpuclk");
+ return PTR_ERR(priv.cpu_clk);
+ }
+
+ clk_prepare_enable(priv.cpu_clk);
+ kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
+
+ clkspec.args[0] = 3;
+ priv.ddr_clk = of_clk_get_from_provider(&clkspec);
+ if (IS_ERR(priv.ddr_clk)) {
+ dev_err(priv.dev, "Unable to get ddrclk");
+ err = PTR_ERR(priv.ddr_clk);
+ goto out_cpu;
+ }
+
+ clk_prepare_enable(priv.ddr_clk);
+ kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
+
+ clkspec.np = np_gating;
+ clkspec.args[0] = 11;
+ priv.powersave_clk = of_clk_get_from_provider(&clkspec);
+ if (IS_ERR(priv.powersave_clk)) {
+ dev_err(priv.dev, "Unable to get powersave");
+ err = PTR_ERR(priv.powersave_clk);
+ goto out_ddr;
+ }
+ clk_prepare(priv.powersave_clk);
+
+ of_node_put(np_core);
+ np_core = NULL;
+ of_node_put(np_gating);
+ np_gating = NULL;
+
+ err = cpufreq_register_driver(&kirkwood_cpufreq_driver);
+ if (!err)
+ return 0;
+
+ dev_err(priv.dev, "Failed to register cpufreq driver");
+
+ clk_disable_unprepare(priv.powersave_clk);
+out_ddr:
+ clk_disable_unprepare(priv.ddr_clk);
+out_cpu:
+ clk_disable_unprepare(priv.cpu_clk);
+ of_node_put(np_core);
+ of_node_put(np_gating);
+
+ return err;
+}
+
+static int kirkwood_cpufreq_remove(struct platform_device *pdev)
+{
+ cpufreq_unregister_driver(&kirkwood_cpufreq_driver);
+
+ clk_disable_unprepare(priv.powersave_clk);
+ clk_disable_unprepare(priv.ddr_clk);
+ clk_disable_unprepare(priv.cpu_clk);
+
+ return 0;
+}
+
+static struct platform_driver kirkwood_cpufreq_platform_driver = {
+ .probe = kirkwood_cpufreq_probe,
+ .remove = kirkwood_cpufreq_remove,
+ .driver = {
+ .name = "kirkwood-cpufreq",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_platform_driver(kirkwood_cpufreq_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch");
+MODULE_DESCRIPTION("cpufreq driver for Marvell's kirkwood CPU");
+MODULE_ALIAS("platform:kirkwood-cpufreq");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 43 0/3] Kirkwoode cpufreq driver
From: Andrew Lunn @ 2013-02-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds a cpufreq driver for Marvell Kirkwood SoCs.
The changes to kirkwood_defconfig enable it and set the default
governor to ondemand.
Changes since v3:
Check return value of of_find_compatible_node()
Return -EADDRNOTAVAIL when devm_request_and_ioremap() fails.
Remove default: clause.
Made .name consistent.
Changes since v2:
Remove unneeded #include file left over from debugging.
WARN_ON(1) instead of dev_err() for unexpected state
Various blank lines removed.
Reformat comment.
writel -> writel_relaxed
Changes since v1:
tabify Kconfig.arm entry
Sort order of include files
Remove some unnecassary include files
Reformat multiline comment to be coding style conform.
Andrew Lunn (3):
cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
arm: kirkwood: Instantiate cpufreq driver
arm: kirkwood: Enable cpufreq and ondemand on kirkwood_defconfig
arch/arm/Kconfig | 1 +
arch/arm/configs/kirkwood_defconfig | 3 +
arch/arm/mach-kirkwood/board-dt.c | 3 +-
arch/arm/mach-kirkwood/common.c | 23 ++
arch/arm/mach-kirkwood/common.h | 2 +
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 2 +
drivers/clk/mvebu/clk-gating-ctrl.c | 1 +
drivers/cpufreq/Kconfig.arm | 6 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/kirkwood-cpufreq.c | 264 +++++++++++++++++++++
10 files changed, 305 insertions(+), 1 deletion(-)
create mode 100644 drivers/cpufreq/kirkwood-cpufreq.c
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Mohammed, Afzal @ 2013-02-01 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BD04A.4000909@ti.com>
Hi Roger,
On Fri, Feb 01, 2013 at 19:55:14, Quadros, Roger wrote:
> Thanks Afzal :). You mean the non device tree boot right?
No, dt boot, am335x can only dt boot.
Regards
Afzal
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Roger Quadros @ 2013-02-01 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9FF9C@DBDE01.ent.ti.com>
On 02/01/2013 04:21 PM, Mohammed, Afzal wrote:
> Hi Felipe, Roger,
>
> On Wed, Jan 30, 2013 at 18:49:17, Mohammed, Afzal wrote:
>> On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
>>> On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
>
>>>> I would appreciate if someone who knows more about beaglebone can help
>>>> with verification.
>
>>> Right, Afzal if you have the bone could you help Roger validating ?
>
>> I am not in a position to validate it, in the middle of another task.
>
> Ok, I tested this, usb first instance of beagle bone works as in mainline.
>
Thanks Afzal :). You mean the non device tree boot right?
cheers,
-roger
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Mohammed, Afzal @ 2013-02-01 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA95E97@DBDE01.ent.ti.com>
Hi Felipe, Roger,
On Wed, Jan 30, 2013 at 18:49:17, Mohammed, Afzal wrote:
> On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
> > On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
> > > I would appreciate if someone who knows more about beaglebone can help
> > > with verification.
> > Right, Afzal if you have the bone could you help Roger validating ?
> I am not in a position to validate it, in the middle of another task.
Ok, I tested this, usb first instance of beagle bone works as in mainline.
Regards
Afzal
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201141052.GA25172@e102568-lin.cambridge.arm.com>
On Fri, Feb 01, 2013 at 02:10:52PM +0000, Lorenzo Pieralisi wrote:
> On Fri, Feb 01, 2013 at 12:54:17PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 01, 2013 at 12:11:38PM +0000, Lorenzo Pieralisi wrote:
> > > Well, on latest processors (A15, A7) caches are invalidated on reset unless
> > > the chip is programmed to skip that on reset (ie L2 retained).
> > >
> > > But it makes sense, for sure it should not be called v7_invalidate_l1,
> > > but invalidate_louis, and instead of forcing level 0 we should be
> > > reading LoUIS and invalidate up to that level as we do in the clean and
> > > invalidate function.
> >
> > No. Think about it. c7, c6, 2 _invalidates_ the cache. That means any
> > data contained within the cache is discarded. Data is not written back.
> >
> > If you do this down to the LoUIS, that includes all cache levels in the
> > inner sharable domain. The inner sharable domain includes the other CPUs
> > in the system which may already be running (certainly the boot CPU will
> > be running).
>
> On all v7 ARM systems I know of LoUIS correspond to L1 and using LoUIS is a
> plaster that works for current systems (where by LoUIS I mean all cache
> levels down to but not inclusive of, LoUIS).
All that I'm saying is that suggesting that v7_invalidate_l1 should go
down to LoUIS is wrong, in much the same way as _invalidating_ only the
first level of cache.
However, invalidating the first level of cache only is safer than
invalidating down to LoUIS.
The only path which needs this is the secondary CPU bringup path; that's
the only path we have where some platforms give us a CPU which has only
just come out of reset, and so the caches for that CPU may be in an
unknown state. And it only happens to a small subset of platforms.
Currently, that small subset of platforms only need the first level of
cache invalidating. (Most platforms don't need this; most platforms
this would be a waste of time - and people seem to care about hotplug
times.)
So, that's what we should do. And v7_invalidate_l1 is a perfectly
reasonable name for a function to do that for the V7 architecture.
As has been pointed out, there's several duplications of that. That's
fine, let's move them into the v7 cache code. But... let's not change
how they work and go through a pointless design exercise for
invalidating more levels of cache when we know that no platform needs
it.
If/when we do end up with a platform which requires it, we can deal
with it then. But let's not lead people down the route of thinking
that LoUIS is suitable here when it isn't.
^ permalink raw reply
* [PATCH 2/4] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by DT
From: Rob Herring @ 2013-02-01 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201105849.GB21191@e106331-lin.cambridge.arm.com>
On 02/01/2013 04:58 AM, Mark Rutland wrote:
> On Fri, Feb 01, 2013 at 12:34:10AM +0000, Simon Horman wrote:
>> On Fri, Feb 01, 2013 at 09:11:19AM +0900, Simon Horman wrote:
>>> On Thu, Jan 31, 2013 at 12:32:13PM +0000, Mark Rutland wrote:
>>>> Hi Simon,
>>>>
>>>> On Thu, Jan 31, 2013 at 01:50:49AM +0000, Simon Horman wrote:
>>>>> +
>>>>> + gic: interrupt-controller at f0001000 {
>>>>> + compatible = "arm,cortex-a9-gic";
>>>>> + #interrupt-cells = <3>;
>>>>> + #address-cells = <1>;
>>>>
>>>> Why is #address-cells needed here (and without #size-cells)? I see it's in the
>>>> binding document example, but I can't figure out why.
>>>
>>> Its here because I copied the example.
>>> I will see about removing it from here.
>
> Rob, Grant, do either of you know if there's a reason for this that we've
> missed?
>
> The gic doesn't have any direct children, and this doesn't seem to be
> some decvicetree interrupt-controller magic.
If you look at of_irq_map_raw, there are cases that look at
#address-cells. Those appear to be only when you have an interrupt-map
though.
>
> If this is superfluous, how about the patch below?
The docs probably should state #addr-cells is only required with
interrupt-map.
>
> I took a quick look at arch/arm/boot/dts/. Some gic nodes don't have
> #address-cells, some have it but not #size-cells, and some have both. These
> should probably be cleaned up too.
Some boards are using interrupt-map, so they may need #address-cells. So
I'm inclined to leave things alone.
Rob
>
> [...]
>
> Thanks,
> Mark.
>
> ---->8----
>
> From dc734edb8040513785429c11e40a420870dc55a4 Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Fri, 1 Feb 2013 10:18:05 +0000
> Subject: [PATCH] Docs: gic: remove #address-cells from example
>
> The gic has no child nodes, and so doesn't need #address-cells. Having
> the property defined in the example only serves as a source of
> confusion.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 62eb8df..45b99ab 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -54,7 +54,6 @@ Example:
> intc: interrupt-controller at fff11000 {
> compatible = "arm,cortex-a9-gic";
> #interrupt-cells = <3>;
> - #address-cells = <1>;
> interrupt-controller;
> reg = <0xfff11000 0x1000>,
> <0xfff10100 0x100>;
>
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Lorenzo Pieralisi @ 2013-02-01 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201125417.GL23505@n2100.arm.linux.org.uk>
On Fri, Feb 01, 2013 at 12:54:17PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 12:11:38PM +0000, Lorenzo Pieralisi wrote:
> > Well, on latest processors (A15, A7) caches are invalidated on reset unless
> > the chip is programmed to skip that on reset (ie L2 retained).
> >
> > But it makes sense, for sure it should not be called v7_invalidate_l1,
> > but invalidate_louis, and instead of forcing level 0 we should be
> > reading LoUIS and invalidate up to that level as we do in the clean and
> > invalidate function.
>
> No. Think about it. c7, c6, 2 _invalidates_ the cache. That means any
> data contained within the cache is discarded. Data is not written back.
>
> If you do this down to the LoUIS, that includes all cache levels in the
> inner sharable domain. The inner sharable domain includes the other CPUs
> in the system which may already be running (certainly the boot CPU will
> be running).
On all v7 ARM systems I know of LoUIS correspond to L1 and using LoUIS is a
plaster that works for current systems (where by LoUIS I mean all cache
levels down to but not inclusive of, LoUIS).
What you are saying is true for cpu_suspend code and hotplug as well, there we
are cleaning and invalidating down to the LoUIS, which might not be needed
since LoUIS does not mean that all cache levels included are _local_ to the
CPU.
There is no way on ARM systems to detect what cache levels are local to
a CPU, so we decided to use LoUIS for that, as a temporary solution to
avoid cluttering the code with DT bindings that link cache topology and
CPU topology.
And on all ARM systems in the mainline "operating on all levels down to
but not inclusive of LoUIS" is equivalent to cache levels local to a CPU,
if it is not I am missing something and I apologize.
> Are you _really_ sure you want to be invalidating _valid_ data held in
> caches in the inner sharable domain by other CPUs, rather than just the
> cache associated with the CPU which is being brought online?
We know that LoUIS corresponds to cache levels local to a CPU for now and we
know that it will fail as soon as there are caches in the inner shareability
domain that belong to multiple CPUs. Again, that's valid for the clean
and invalidate functions as well (though there it is an optimization
problem, here I agree is a validity issue and more serious).
There is no way to detect cache levels local to a CPU, I tried to do
that before posting the new LoUIS API, and all I can say is that we need
device tree bindings to do that cleanly, architecturally it is just not
detectable.
I am happy to discuss a way forward Russell, your concerns are correct,
we are aware of them and happy to improve the code to make it work
consistently.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740
From: Paul Mundt @ 2013-02-01 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201135633.GH25591@8bytes.org>
On Fri, Feb 01, 2013 at 02:56:33PM +0100, Joerg Roedel wrote:
> On Mon, Jan 21, 2013 at 07:54:25PM +0900, Hideki EIRAKU wrote:
> > Hideki EIRAKU (4):
> > iommu/shmobile: Add iommu driver for Renesas IPMMU modules
> > ARM: mach-shmobile: sh7372: Add IPMMU device
> > ARM: mach-shmobile: sh73a0: Add IPMMU device
> > ARM: mach-shmobile: r8a7740: Add IPMMU device
>
> Paul, Magnus, any opinions on patches 2-4? Can you ACK them when they
> are ok for you?
>
No strong opinions one way or the other, patches 2-4 don't really do
anything of significance.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201132012.GM23505@n2100.arm.linux.org.uk>
On Friday 01 February 2013 06:50 PM, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 06:34:06PM +0530, Santosh Shilimkar wrote:
>> On Friday 01 February 2013 06:18 PM, Russell King - ARM Linux wrote:
>>> On Fri, Feb 01, 2013 at 05:14:11PM +0530, Santosh Shilimkar wrote:
>>>> On Friday 01 February 2013 05:02 PM, Russell King - ARM Linux wrote:
>>>>> On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
>>>>>> Now since we are moving the code under common place, probably we should
>>>>>> update this a function a bit so that it invalidates the CPU cache till
>>>>>> line of unification. Just to be consistent with other flush API.
>>>>>
>>>>> Hmm. Do you really want a CPU being brought up to do that to the PoU,
>>>>> every time that it is brought up? I thought you wanted to get rid of
>>>>> that kind of stuff from the hotplug paths so that a CPU being brought
>>>>> up/taken down doesn't affect the caches for the other CPUs within the
>>>>> inner sharable domain.
>>>>>
>>>> You are right. We already git rid of the flush of all cache levels
>>>> in hotplug and wakeup paths and now it is restricted till the PoU.
>>>>
>>>> Assuming for the current v7 machines, PoU is L2, invalidating the cache
>>>> *till* PoU means only CPU local cache. So the API will in a way
>>>> invalidate only local cache.
>>>
>>> Err, you want to _invalidate_ the caches down to the point of I/D/TLB
>>> unification? Are you really sure you want to do that on a system
>>> here other CPUs are running?
>>>
>>> Even going down to the LoUIS, that point is the point at which the
>>> _other_ CPUs may be sharing caches.
>>>
>>> And invalidating those caches while the other CPUs are running on
>>> secondary CPU startup will be VERY VERY VERY bad.
>>>
>> Absolutly and my intention was never to invalidate all the cache
>> levels. When I said lous, I mean till that point and not including
>> that and next cache levels. May be my terminology isn't accurate.
>
> Confused. Can't find the term "lous" in your previous mails. I'll
> assume you mean LoUIS. I'm saying that's totally wrong because going
> down to that point _includes_ the other CPUs in the system.
>
Sorry for the typo. I mean LoUIS.
> What we should be doing on secondary CPU bringup for CPUs where the
> caches are in an unknown state is invalidating those caches which are
> local to _that_ _CPU_ _only_. That is not "all cache levels down to
> LoUIS".
>
Restricting it to local CPU cache is also my point. My example was bit
narrow with current A9 and A15 designs where there is only L1 and L2
cache and hence not considered the below case.
> Here's an example. CPU0-3 are in the inner sharable domain.
>
> +----------+ +----------+ +----------+ +----------+
> | CPU0 | | CPU1 | | CPU2 | | CPU3 |
> +----------+ +----------+ +----------+ +----------+
> | | | | | | | |
> +--v-+--v-+ +--v-+--v-+ +--v-+--v-+ +--v-+--v-+
> |CL0I|CL0D| |CL0I|CL0D| |CL0I|CL0D| |CL0I|CL0D| <-- cache level 0
> +----+----+ +----+----+ +----+----+ +----+----+
> | | | | | | | |
> | | +---+ +--+ | | | +------------------+
> | | | | | +-------|--------------+ |
> | | | +-------+ | | |
> | | | | +-----------------|-----+ | |
> | | | | +-----------+ | | |
> | +---|--------|--------|--------+ | | |
> +--v--------v--------v--------v--+ +--v--------v--------v--------v--+
> | CL1I | | CL1D | level 1
> +--------------------------------+ +--------------------------------+
> | |
> +----------------v-----------------------------------v---------------+
> | CL2 | level 2
> +--------------------------------------------------------------------+
>
> Therefore, because the point of unification for the inner sharable domain
> is defined as the point at which the I, D and TLB streams (TLB not shown)
> are combined, this happens at CL2, and does *not* include CL2. CL2 is
> where the two paths see the same data.
>
> So, the LoUIS includes caches in level 0 and level 1.
>
Thats right for above example. I haven't seen such design so far
and hence my view was narrow.
> However, CL1 _is_ shared between CPU0-3 - it is part of the inner sharable
> domain. If you invalidate CL1, then you're destroying data held there by
> the other CPUs. So, invalidating down to the LoUIS on secondary CPU
> bringup is _wrong_.
>
As I said above, I didn't considered the case you mentioned here. Thanks
for bring up this example. I am aligned with you on _NO_ on invaliding
cache level from a CPU which is shared across multiple CPUs.
Regards,
Santosh
^ permalink raw reply
* [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740
From: Joerg Roedel @ 2013-02-01 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358765669-14567-1-git-send-email-hdk@igel.co.jp>
On Mon, Jan 21, 2013 at 07:54:25PM +0900, Hideki EIRAKU wrote:
> Hideki EIRAKU (4):
> iommu/shmobile: Add iommu driver for Renesas IPMMU modules
> ARM: mach-shmobile: sh7372: Add IPMMU device
> ARM: mach-shmobile: sh73a0: Add IPMMU device
> ARM: mach-shmobile: r8a7740: Add IPMMU device
Paul, Magnus, any opinions on patches 2-4? Can you ACK them when they
are ok for you?
Joerg
^ permalink raw reply
* [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Joerg Roedel @ 2013-02-01 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358765669-14567-2-git-send-email-hdk@igel.co.jp>
On Mon, Jan 21, 2013 at 07:54:26PM +0900, Hideki EIRAKU wrote:
> This is the Renesas IPMMU driver and IOMMU API implementation.
>
> The IPMMU module supports the MMU function and the PMB function. The
> MMU function provides address translation by pagetable compatible with
> ARMv6. The PMB function provides address translation including
> tile-linear translation. This patch implements the MMU function.
>
> The iommu driver does not register a platform driver directly because:
> - the register space of the MMU function and the PMB function
> have a common register (used for settings flush), so they should ideally
> have a way to appropriately share this register.
> - the MMU function uses the IOMMU API while the PMB function does not.
> - the two functions may be used independently.
>
> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
The patch looks good in general. Just one question inline.
> +static int pgtable_alloc(struct shmobile_iommu_domain_pgtable *pgtable,
> + struct kmem_cache *cache, size_t size)
> +{
> + pgtable->pgtable = kmem_cache_zalloc(cache, GFP_ATOMIC);
> + if (!pgtable->pgtable)
> + return -ENOMEM;
> + pgtable->handle = dma_map_single(NULL, pgtable->pgtable, size,
> + DMA_TO_DEVICE);
> + return 0;
> +}
Why is it necessary to call dma_map_single() for IOMMU page-tables?
usually the dma_* functions call into IOMMU drivers, so why are they
used inside an IOMMU driver?
Regards,
Joerg
^ permalink raw reply
* [PATCH v6 05/12] iommu/exynos: support for device tree
From: Joerg Roedel @ 2013-02-01 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQjnOMav9A43m4=7=N9kzEHTHE_q_ygu8x6mzY6Cus=q0c06A@mail.gmail.com>
Cho,
On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote:
> On Tuesday, January 1, 2013, Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
> > Cc: devicetree-discuss at lists.ozlabs.org
Since patch 7 of this set is already merged, do you mind to re-post the
rest of this patch-set with the latest comments addressed? I can have a
look at it again then and consider it for 3.9.
Thanks,
Joerg
^ 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