* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-27 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127110857.GA23687@schnuecks.de>
On 01/27/2013 12:08 PM, Simon Baatz wrote:
> On Sun, Jan 27, 2013 at 11:52:41AM +0100, Sebastian Hesselbarth wrote:
>> Jason posted a patch set that makes mv643xx DT compatible. IMHO this
>> patch is obsolete when we have DT support for mv643xx.
>> kirkwood_ge00/01_init will not be called with DT support at all.
>
> I know. This is to fix a regression in 3.8 (which currently does not
> boot with my "modularized" config).
Well, patching kirkwood_ge00/01_init() will also affect non-DT code
so there is a great potential to break something else.
If it is a DT-only issue please move the "always enable ge clocks"
fix to kirkwood_clk_legacy_init() as it only called by DT enabled
boards.
If there is no other issue than keeping the clocks running because
of not loosing the MAC address, I prefer not to fix it at all.
Looks like modular gbe on kirkwood is just unsupported on 3.8.
Sebastian
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Sebastian Hesselbarth @ 2013-01-27 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127105654.GA23127@schnuecks.de>
On 01/27/2013 11:56 AM, Simon Baatz wrote:
> On Sun, Jan 27, 2013 at 11:15:59AM +0100, Sebastian Hesselbarth wrote:
>>
>>> I think we should do the following for 3.8:
>>>
>>> - Get the clocks by device name in kirkwood_ge0x_init()
>>> - Only set CLK_IGNORE_UNUSED for "runit" in clk-gating-ctrl.c. (I can
>>> do this by simply adding another case to the existing "ddr"
>>> exception, which makes the patch much less intrusive)
>>
>> I agree that we should have .flags for clk-gating-ctrl but that
>> can live without any DT properties as we already have SoC specific
>> structs there (and Keymile's kirkwood doesn't hang on clk gating
>> control register accesses)
>
> Oh, I just posted the patch with the simple if, not the .flags. As
> said, the .flags create much noise. But I don't mind changing that
> back or posting the .flags change separately for 3.9.
I prefer .flags even with the noise the patch will cause. It is a
fix and there is no reason why we should fix that fix later just because
of the amount of changes it will cause.
> I think for "runit" it makes sense to keep it that way (i.e. not in
> DT properties). But the ge clocks are really depending on the number
> of interfaces on the particular board. Having a way not to keep them
> running for all boards just not to forget the MAC addresses for those
> boards who use them would be nice.
Except for loosing the MAC address, I disagree. From a "clock gating"
point-of-view all kirkwoods (except that crippled one on keymile board)
are the same. Even if there is no/one/two ethernet _jacks_ on a specific
board you still want to disable all _unused_ ethernet modules inside the
SoC.
We should find a way to retain the MAC address and in the meantime we
can add a "always prepare ge clocks" workaround in
kirkwood_clk_legacy_init().
>> If there is any hang issue with gated ge clk on kirkwood, the
>> solution is not to just disable the clock gate but make any
>> code that accesses ge registers prepare the clock.
>
> Indeed, there are two issue here. The ge interface forgets its MAC
> address (set by the boot loader) when the clock is gated.
>
> In the ge driver, accesses are in the wrong order or there is a
> missing delay between the enabling and the hardware access. Andrew
> digged into this at the time. But even if that would work, the
> interface would not be usable without a valid MAC address.
Again, then it is about fixing the driver not the clock gating.
I understand that it will render the interface unusable but then a
modular kirkwood kernel is just not supported in the current
state.
Sebastian
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-27 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510506F9.3070500@gmail.com>
Hi Sebastian,
On Sun, Jan 27, 2013 at 11:52:41AM +0100, Sebastian Hesselbarth wrote:
> Jason posted a patch set that makes mv643xx DT compatible. IMHO this
> patch is obsolete when we have DT support for mv643xx.
> kirkwood_ge00/01_init will not be called with DT support at all.
I know. This is to fix a regression in 3.8 (which currently does not
boot with my "modularized" config).
As said in my other mail to Jason, we will need something more clever
in 3.9.
- Simon
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Simon Baatz @ 2013-01-27 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5104FE5F.2040804@gmail.com>
Hi Sebastian,
On Sun, Jan 27, 2013 at 11:15:59AM +0100, Sebastian Hesselbarth wrote:
>
> >I think we should do the following for 3.8:
> >
> >- Get the clocks by device name in kirkwood_ge0x_init()
> >- Only set CLK_IGNORE_UNUSED for "runit" in clk-gating-ctrl.c. (I can
> >do this by simply adding another case to the existing "ddr"
> >exception, which makes the patch much less intrusive)
>
> I agree that we should have .flags for clk-gating-ctrl but that
> can live without any DT properties as we already have SoC specific
> structs there (and Keymile's kirkwood doesn't hang on clk gating
> control register accesses)
Oh, I just posted the patch with the simple if, not the .flags. As
said, the .flags create much noise. But I don't mind changing that
back or posting the .flags change separately for 3.9.
I think for "runit" it makes sense to keep it that way (i.e. not in
DT properties). But the ge clocks are really depending on the number
of interfaces on the particular board. Having a way not to keep them
running for all boards just not to forget the MAC addresses for those
boards who use them would be nice.
>
> >>and in any other board:
> >>
> >>gate_clk: clock-gating-control at 2011c {
> >> /* don't lose eth0 mac address */
> >> ungateable =<0>;
> >>};
>
> If there is any hang issue with gated ge clk on kirkwood, the
> solution is not to just disable the clock gate but make any
> code that accesses ge registers prepare the clock.
Indeed, there are two issue here. The ge interface forgets its MAC
address (set by the boot loader) when the clock is gated.
In the ge driver, accesses are in the wrong order or there is a
missing delay between the enabling and the hardware access. Andrew
digged into this at the time. But even if that would work, the
interface would not be usable without a valid MAC address.
- Simon
^ permalink raw reply
* [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
From: Sebastian Hesselbarth @ 2013-01-27 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359283223-23082-3-git-send-email-gmbnomis@gmail.com>
On 01/27/2013 11:40 AM, Simon Baatz wrote:
> Commit f479db "ARM: Kirkwood: Ensure runit clock always ticks."
> made sure that the runit clock always ticks on Kirkwood.
>
> When moving the clock gating to clk-gating-ctrl.c for Kirkwood DT
> devices, this change was disabled. Set the CLK_IGNORE_UNUSED flag for
> "runit" to ensure that it always ticks.
>
> Signed-off-by: Simon Baatz<gmbnomis@gmail.com>
> ---
> drivers/clk/mvebu/clk-gating-ctrl.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index 8fa5408..da5f807 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -97,8 +97,11 @@ static void __init mvebu_clk_gating_setup(
> * isn't taken by any driver, but should anyway be
> * kept enabled, so we mark it as IGNORE_UNUSED for
> * now.
> + * Do the same for the "runit" clock on Kirkwood;
> + * gating this clock causes an immediate lockup.
> */
> - if (!strcmp(descr[n].name, "ddr"))
> + if (!strcmp(descr[n].name, "ddr")
> + || !strcmp(descr[n].name, "runit"))
> flags |= CLK_IGNORE_UNUSED;
>
> ctrl->gates[n] = clk_register_gate(NULL, descr[n].name, parent,
Simon,
I'd rather have .flags passed by the SoC specific struct as you did in
v1.
Sebastian
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-27 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359283223-23082-2-git-send-email-gmbnomis@gmail.com>
On 01/27/2013 11:40 AM, Simon Baatz wrote:
> Commit 1611f87 (ARM: Kirkwood: switch to DT clock providers) broke the
> functions to initialize the ethernet interfaces (kirkwood_ge00_init() and
> kirkwood_ge01_init()). In the DT case, the functions could not enable the
> correct clocks.
>
> Fix this by looking up the clocks through the device name.
>
> Signed-off-by: Simon Baatz<gmbnomis@gmail.com>
> ---
> arch/arm/mach-kirkwood/common.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
> index bac21a5..2c97847 100644
> --- a/arch/arm/mach-kirkwood/common.c
> +++ b/arch/arm/mach-kirkwood/common.c
> ...
> tclk = clk_register_fixed_rate(NULL, "tclk", NULL,
> @@ -288,12 +287,15 @@ void __init kirkwood_ehci_init(void)
> ****************************************************************************/
> void __init kirkwood_ge00_init(struct mv643xx_eth_platform_data *eth_data)
> {
> + struct clk *ge0;
> orion_ge00_init(eth_data,
> GE00_PHYS_BASE, IRQ_KIRKWOOD_GE00_SUM,
> IRQ_KIRKWOOD_GE00_ERR, 1600);
> /* The interface forgets the MAC address assigned by u-boot if
> the clock is turned off, so claim the clk now. */
> - clk_prepare_enable(ge0);
> + ge0 = clk_get_sys(MV643XX_ETH_NAME ".0", NULL);
> + if (!IS_ERR(ge0))
> + clk_prepare_enable(ge0);
> }
Simon,
Jason posted a patch set that makes mv643xx DT compatible. IMHO this
patch is obsolete when we have DT support for mv643xx.
kirkwood_ge00/01_init will not be called with DT support at all.
I agree that loosing the MAC address _is_ an issue but there must
be another way to retain it during gated ge clocks than not gate the
clocks at all.
I can think of some ways to retain it but don't know what is the most
common with linux:
- make u-boot pass it through cmdline and let mv643xx get it from there
- have kirkwood's common code grab it before clk gates kick in
I will do some tests on dove if it also suffers from loosing it's MAC
on gated clock.
Sebastian
^ permalink raw reply
* [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
From: Simon Baatz @ 2013-01-27 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359283223-23082-1-git-send-email-gmbnomis@gmail.com>
Commit f479db "ARM: Kirkwood: Ensure runit clock always ticks."
made sure that the runit clock always ticks on Kirkwood.
When moving the clock gating to clk-gating-ctrl.c for Kirkwood DT
devices, this change was disabled. Set the CLK_IGNORE_UNUSED flag for
"runit" to ensure that it always ticks.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
drivers/clk/mvebu/clk-gating-ctrl.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
index 8fa5408..da5f807 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -97,8 +97,11 @@ static void __init mvebu_clk_gating_setup(
* isn't taken by any driver, but should anyway be
* kept enabled, so we mark it as IGNORE_UNUSED for
* now.
+ * Do the same for the "runit" clock on Kirkwood;
+ * gating this clock causes an immediate lockup.
*/
- if (!strcmp(descr[n].name, "ddr"))
+ if (!strcmp(descr[n].name, "ddr")
+ || !strcmp(descr[n].name, "runit"))
flags |= CLK_IGNORE_UNUSED;
ctrl->gates[n] = clk_register_gate(NULL, descr[n].name, parent,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-27 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359283223-23082-1-git-send-email-gmbnomis@gmail.com>
Commit 1611f87 (ARM: Kirkwood: switch to DT clock providers) broke the
functions to initialize the ethernet interfaces (kirkwood_ge00_init() and
kirkwood_ge01_init()). In the DT case, the functions could not enable the
correct clocks.
Fix this by looking up the clocks through the device name.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
arch/arm/mach-kirkwood/common.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index bac21a5..2c97847 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -218,11 +218,10 @@ static struct clk __init *kirkwood_register_gate_fn(const char *name,
bit_idx, 0, &gating_lock, fn_en, fn_dis);
}
-static struct clk *ge0, *ge1;
void __init kirkwood_clk_init(void)
{
- struct clk *runit, *sata0, *sata1, *usb0, *sdio;
+ struct clk *runit, *ge0, *ge1, *sata0, *sata1, *usb0, *sdio;
struct clk *crypto, *xor0, *xor1, *pex0, *pex1, *audio;
tclk = clk_register_fixed_rate(NULL, "tclk", NULL,
@@ -288,12 +287,15 @@ void __init kirkwood_ehci_init(void)
****************************************************************************/
void __init kirkwood_ge00_init(struct mv643xx_eth_platform_data *eth_data)
{
+ struct clk *ge0;
orion_ge00_init(eth_data,
GE00_PHYS_BASE, IRQ_KIRKWOOD_GE00_SUM,
IRQ_KIRKWOOD_GE00_ERR, 1600);
/* The interface forgets the MAC address assigned by u-boot if
the clock is turned off, so claim the clk now. */
- clk_prepare_enable(ge0);
+ ge0 = clk_get_sys(MV643XX_ETH_NAME ".0", NULL);
+ if (!IS_ERR(ge0))
+ clk_prepare_enable(ge0);
}
@@ -302,10 +304,13 @@ void __init kirkwood_ge00_init(struct mv643xx_eth_platform_data *eth_data)
****************************************************************************/
void __init kirkwood_ge01_init(struct mv643xx_eth_platform_data *eth_data)
{
+ struct clk *ge1;
orion_ge01_init(eth_data,
GE01_PHYS_BASE, IRQ_KIRKWOOD_GE01_SUM,
IRQ_KIRKWOOD_GE01_ERR, 1600);
- clk_prepare_enable(ge1);
+ ge1 = clk_get_sys(MV643XX_ETH_NAME ".1", NULL);
+ if (!IS_ERR(ge1))
+ clk_prepare_enable(ge1);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/2] Do not gate ge0/1 and runit clocks on Kirkwood
From: Simon Baatz @ 2013-01-27 10:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
kernel 3.8-rc5 will hang on kirkwood DT if the Ethernet driver is built
as a module or when no driver claiming the runit clock is built in.
(Usually, at least the serial driver is built in, but it won't request
the clock if "clock-frequency" is given in DT.) In the past, we fixed
this by keeping the clocks ticking.
These two patches re-enable the ethernet fix for DT and declare the
"runit" clock as not to gated even if unused.
Changes:
v2:
- Do not turn on ge[01] clocks unconditionally. Instead, fix the
previous way we handled this on kirkwood.
Simon Baatz (2):
ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
clk: mvebu: Do not gate runit clock on Kirkwood
arch/arm/mach-kirkwood/common.c | 13 +++++++++----
drivers/clk/mvebu/clk-gating-ctrl.c | 5 ++++-
2 files changed, 13 insertions(+), 5 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Sebastian Hesselbarth @ 2013-01-27 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127013131.GA2400@schnuecks.de>
On 01/27/2013 02:31 AM, Simon Baatz wrote:
> On Sat, Jan 26, 2013 at 06:50:37PM -0500, Jason Cooper wrote:
>> Another facet of this problem is the keymile board. It has to enable
>> the clocks for sata in order to boot. (ref: board-km_kirkwood.c).
The statement in board-km_kirkwood.c is just not true. Andrew and I did
some tests with Valentin Longchamps back when we introduced DT clk
gating. Keymile board hangs not because of the accesses to clk gating
ctrl registers but the phy gating that accessed the sata registers
that are missing on the Kirkwood used on that board.
Phy gates have not been used since DT clk gating at all. If we
reintroduce them in a DT compatible way we can still disable them
for keymile board in DT.
> I think we should do the following for 3.8:
>
> - Get the clocks by device name in kirkwood_ge0x_init()
> - Only set CLK_IGNORE_UNUSED for "runit" in clk-gating-ctrl.c. (I can
> do this by simply adding another case to the existing "ddr"
> exception, which makes the patch much less intrusive)
I agree that we should have .flags for clk-gating-ctrl but that
can live without any DT properties as we already have SoC specific
structs there (and Keymile's kirkwood doesn't hang on clk gating
control register accesses)
>> and in any other board:
>>
>> gate_clk: clock-gating-control at 2011c {
>> /* don't lose eth0 mac address */
>> ungateable =<0>;
>> };
If there is any hang issue with gated ge clk on kirkwood, the
solution is not to just disable the clock gate but make any
code that accesses ge registers prepare the clock.
Sebastian
^ permalink raw reply
* [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Blue Swirl @ 2013-01-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127082007.GA31120@redhat.com>
On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote:
>>
>> On 25.01.2013, at 20:04, Blue Swirl wrote:
>>
>> > On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel <anup.patel@linaro.org> wrote:
>> >> Hi All,
>> >>
>> >> How about having a generic Virtio-based machine for emulating a virtual
>> >> desktop ?
>> >
>> > I have also thought about this, current virtio design is not very
>> > clean. On the downside, pure no-legacy approach might not work well if
>> > you want the host to give control of a host device to guest (VFIO like
>> > pass through using IOMMUs).
>> >
>> >> I know folks have already thought about this and probably also tried
>> >> something or other on this front but, it will be good to know the downsides.
>> >>
>> >> Virtio-desktop can be a separate specification describing a virtual desktop.
>> >> Of-course we cannot avoid few architecture dependent virtual devices in but
>> >> the Virtio-desktop specification will try to keep minimum possible
>> >> architecture dependent devices.
>> >>
>> >> As per our thoughts, a Virtio-desktop will have two kinds of devices:
>> >> 1. Architecture dependent devices: This devices will be emulated in-kernel
>> >> by architecture specific code of KVM or Xen or Some other hypervisor.
>> >> a) Virtualized CPU
>> >> b) Virtualized PIC (i.e. in-kernel architecture specific emulation of
>> >> irqchip)
>> >> c) Virtualized Timer (i.e. in-kernel architecture specific emulation of
>> >> timer chip)
>> >
>> > I think reusing PIC and timer design is not the most optimal. What a
>> > PV aware OS really wants is to wake up because of an external event or
>> > at some specific point of time (or after a specific delay) and easy
>> > way to manage the VM clock without timer tick counting. With a
>> > tickless approach, it would need the timer events as rarely as
>> > possible.
>> >
>> > Perhaps a better approach would be to introduce a way for the guest to
>> > subscribe to a list of external events (including time), which would
>> > be fed to it via something like reverse hypercall (or just use legacy
>> > interrupts). Preferably it should be possible to pass any events
>> > through a stack of guests to the end consumer guest and even
>> > applications in a guest.
>>
>> This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware.
>>
> Same with irq chip. Implementing PV irqchip today is going backwards.
I'm not sure this should be the conclusion. Obviously throwing more
hardware at virtualization makes it faster and the x86 host will
probably also benefit from faster interrupt handling as a side
benefit, so emulating the PIC etc. makes sense for now and also in
short term (some years from now).
But long term, if you could direct the hardware design efforts of
major companies and standardization bodies to any direction, is fast
emulation of 30 year old technology what would create the fastest
architecture in the future? For example, maybe the PIC+LAPIC should be
replaced in long term by something that can vector the interrupts to
different VCPUs directly, each at different privilege levels?
>
>> PV is bad. We only do it when we have to. Not doing PV where we don't have to is exactly the reason KVM is superior to Xen.
>>
> Exactly. Implementing PV for something that does not require PV (for
> performance reasons mostly) is trading tested guest code, to untested,
> and unwritten, one.
HW acceleration of Xen would just need faster IPC, but that has
probably reached max performance ages ago.
The legacy driver benefit is a good point, though more so for short term.
>
> --
> Gleb.
^ permalink raw reply
* [PATCH v3 3/3] arm: kirkwood: Enable cpufreq and ondemand on kirkwood_defconfig
From: Andrew Lunn @ 2013-01-27 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359281244-31455-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>
---
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 v3 2/3] arm: kirkwood: Instantiate cpufreq driver
From: Andrew Lunn @ 2013-01-27 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359281244-31455-1-git-send-email-andrew@lunn.ch>
Register a platform driver structure for the cpufreq driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
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 v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359281244-31455-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>
---
drivers/clk/mvebu/clk-gating-ctrl.c | 1 +
drivers/cpufreq/Kconfig.arm | 6 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/kirkwood-cpufreq.c | 264 +++++++++++++++++++++++++++++++++++
4 files changed, 272 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..d08e679
--- /dev/null
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -0,0 +1,264 @@
+/*
+ * 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;
+ default:
+ WARN_ON(1);
+ }
+
+ /* 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_freq",
+ .owner = THIS_MODULE,
+ .attr = kirkwood_cpufreq_attr,
+};
+
+static int kirkwood_cpufreq_probe(struct platform_device *pdev)
+{
+ struct device_node *np = of_find_compatible_node(
+ NULL, NULL, "marvell,kirkwood-core-clock");
+
+ struct of_phandle_args clkspec;
+ struct resource *res;
+ int err;
+
+ 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 -ENOMEM;
+ }
+
+ clkspec.np = np;
+ 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;
+
+ np = of_find_compatible_node(NULL, NULL,
+ "marvell,kirkwood-gating-clock");
+ clkspec.np = np;
+ 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);
+
+ 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);
+
+ 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 v3 0/3] Kirkwoode cpufreq driver
From: Andrew Lunn @ 2013-01-27 10:07 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 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 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpok1w2RB1ncyNTcd04XTNFfnq_S98YEcxNjpWGWMVA7TaQ@mail.gmail.com>
On Sun, Jan 27, 2013 at 09:21:42AM +0530, Viresh Kumar wrote:
> Hi Andrew,
>
> Few more comments from my side :(
No problems...
>
> On 26 January 2013 21:13, Andrew Lunn <andrew@lunn.ch> wrote:
> > diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/clk.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)
> > +
> > +
> > +#include <linux/clk-private.h>
>
> Any specific reason for keeping it together with other #includes?
Ah, yes, there is a good reason. I added this in for debugging
purposes. I needed to look inside the clk cookie, which required this
include file. But because it was for debug only, to be removed later,
i kept it separate, easier to find and remove. I just forgot to remove
it :-(
> > + if (freqs.old != freqs.new) {
> > + local_irq_disable();
> > +
> > + /* Disable interrupts to the CPU */
> > + reg = readl_relaxed(priv.base);
> > + reg |= CPU_SW_INT_BLK;
> > + writel(reg, priv.base);
> > +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);
>
> This routine does have error cases, like: wrong value of "state"
> variable, so returning int from it might make sense. Though i believe
> state can't be anything else then STATE_CPU_FREQ or STATE_DDR_FREQ.
> In which case, switch must be modified?
As you say, state cannot be anything else that the two expected
values. I've just been taught that switch statements should always
have a default clause. I also thought that a BUG() is too strong, no
need to kill the machine. It is better to spam the kernel log so it
gets noticed. I can swap to a WARN_ON(1). I don't really think this is
an error that needs to be reported back to the framework. Its an
implementation problem, not a runtime problem. So i would prefer to
keep to void.
> > +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> > +{
> > + cpufreq_frequency_table_put_attr(policy->cpu);
> > + return 0;
> > +}
>
> Hmm.. Exit is normally called in two cases. Either cpufreq driver is
> unregistered
> or cpu is removed. In that case i am not sure if this routine makes sense? As
> we have a uniprocessor SoC here.
The current Kconfig entry does not allow it to be compiled as a
module. But the code does allow for it. With the current trend of
making the ARM kernel multiplatform, its likely that cpufreq drivers
will become modular so that only the appropriate driver gets loaded in
a multiplatform kernel. The question then becomes, is it O.K. not
being able to unload the module?
Andrew
^ permalink raw reply
* [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Gleb Natapov @ 2013-01-27 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C549A8FA-7BD7-4C9C-B2B7-AE960F402645@suse.de>
On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote:
>
> On 25.01.2013, at 20:04, Blue Swirl wrote:
>
> > On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel <anup.patel@linaro.org> wrote:
> >> Hi All,
> >>
> >> How about having a generic Virtio-based machine for emulating a virtual
> >> desktop ?
> >
> > I have also thought about this, current virtio design is not very
> > clean. On the downside, pure no-legacy approach might not work well if
> > you want the host to give control of a host device to guest (VFIO like
> > pass through using IOMMUs).
> >
> >> I know folks have already thought about this and probably also tried
> >> something or other on this front but, it will be good to know the downsides.
> >>
> >> Virtio-desktop can be a separate specification describing a virtual desktop.
> >> Of-course we cannot avoid few architecture dependent virtual devices in but
> >> the Virtio-desktop specification will try to keep minimum possible
> >> architecture dependent devices.
> >>
> >> As per our thoughts, a Virtio-desktop will have two kinds of devices:
> >> 1. Architecture dependent devices: This devices will be emulated in-kernel
> >> by architecture specific code of KVM or Xen or Some other hypervisor.
> >> a) Virtualized CPU
> >> b) Virtualized PIC (i.e. in-kernel architecture specific emulation of
> >> irqchip)
> >> c) Virtualized Timer (i.e. in-kernel architecture specific emulation of
> >> timer chip)
> >
> > I think reusing PIC and timer design is not the most optimal. What a
> > PV aware OS really wants is to wake up because of an external event or
> > at some specific point of time (or after a specific delay) and easy
> > way to manage the VM clock without timer tick counting. With a
> > tickless approach, it would need the timer events as rarely as
> > possible.
> >
> > Perhaps a better approach would be to introduce a way for the guest to
> > subscribe to a list of external events (including time), which would
> > be fed to it via something like reverse hypercall (or just use legacy
> > interrupts). Preferably it should be possible to pass any events
> > through a stack of guests to the end consumer guest and even
> > applications in a guest.
>
> This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware.
>
Same with irq chip. Implementing PV irqchip today is going backwards.
> PV is bad. We only do it when we have to. Not doing PV where we don't have to is exactly the reason KVM is superior to Xen.
>
Exactly. Implementing PV for something that does not require PV (for
performance reasons mostly) is trading tested guest code, to untested,
and unwritten, one.
--
Gleb.
^ permalink raw reply
* [PATCH RESEND] ARM: dts: max77686: Add DTS file for max77686 PMIC
From: Mark Brown @ 2013-01-27 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADoNuNeF_fw1uuMt89=gZm-A2R6FHGpr-kCgFkOY0xXpA9+Jzw@mail.gmail.com>
On Sat, Jan 26, 2013 at 03:06:53PM +0900, Dongjin Kim wrote:
> Hello Mark,
>
> Yes, this is not ARM-specific chip at all. Just wanted to be reviewed
> by you and others if the format is ok before integrating to my board
> file. I had sent similar one before,
> https://patchwork.kernel.org/patch/1287711, and you advised that was
> too board specific. And plan to integrate like OMAP boards have with
> twl6030.dtsi and twl6040.dtsi.
> If would be nice if somewhere you specify a directory for such device files.
I think we need to create one, not quite sure where though. drivers/of
perhaps but that's a bit non-idiomatic, or possibly something top level.
firmware might do too.
-------------- 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/20130127/6cbc0e71/attachment.sig>
^ permalink raw reply
* [PATCH v2 16/22] PCI, arm: Kill pci_root_buses
From: Yinghai Lu @ 2013-01-27 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359265003-16166-1-git-send-email-yinghai@kernel.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/kernel/bios32.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 9b72261..d0befe4 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -57,13 +57,10 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
void pcibios_report_status(u_int status_mask, int warn)
{
- struct list_head *l;
+ struct pci_host_bridge *host_bridge = NULL;
- list_for_each(l, &pci_root_buses) {
- struct pci_bus *bus = pci_bus_b(l);
-
- pcibios_bus_report_status(bus, status_mask, warn);
- }
+ for_each_pci_host_bridge(host_bridge)
+ pcibios_bus_report_status(host_bridge->bus, status_mask, warn);
}
/*
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-27 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359215039-2848-2-git-send-email-andrew@lunn.ch>
Hi Andrew,
Few more comments from my side :(
On 26 January 2013 21:13, Andrew Lunn <andrew@lunn.ch> wrote:
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/clk.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)
> +
> +
> +#include <linux/clk-private.h>
Any specific reason for keeping it together with other #includes?
> +static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
> +{
> +
Can remove extra blank line.
> + if (freqs.old != freqs.new) {
> + local_irq_disable();
> +
> + /* Disable interrupts to the CPU */
> + reg = readl_relaxed(priv.base);
> + reg |= CPU_SW_INT_BLK;
> + writel(reg, priv.base);
Any specific reason for calling writel() instead of writel_relaxed()?
relaxed one would take less time and would be much more efficient.
same for all other writel's too.
> +};
> +
> +static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy)
> +{
> + return cpufreq_frequency_table_verify(policy, &kirkwood_freq_table[0]);
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);
This routine does have error cases, like: wrong value of "state"
variable, so returning int from it might make sense. Though i believe
state can't be anything else then STATE_CPU_FREQ or STATE_DDR_FREQ.
In which case, switch must be modified?
> + return 0;
> +}
> +
> +/*
> + * Module init and exit code
> + */
Can be converted to a single line comment if you want. :)
> +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> +{
> + cpufreq_frequency_table_put_attr(policy->cpu);
> + return 0;
> +}
Hmm.. Exit is normally called in two cases. Either cpufreq driver is
unregistered
or cpu is removed. In that case i am not sure if this routine makes sense? As
we have a uniprocessor SoC here.
@Rafael?
> +static struct freq_attr *kirkwood_cpufreq_attr[] = {
> + &cpufreq_freq_attr_scaling_available_freqs,
> + NULL,
> +};
> +
> +
Can remove extra blank line.
^ permalink raw reply
* [PATCH] mc13892: sanity check num_regulators parsed vs. registered
From: Mark Brown @ 2013-01-27 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358792745-1737-1-git-send-email-matt@genesi-usa.com>
On Mon, Jan 21, 2013 at 12:25:45PM -0600, Matt Sealey wrote:
> Imagine a situation where a device tree has a few regulators in an
> appropriate node:
Applied, thanks. Always use subject lines appropriate for the
subsystem.
-------------- 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/20130127/6a882d3b/attachment.sig>
^ permalink raw reply
* [PATCH] mc13892-regulator: correct/refine handling of the SWxHI bit
From: Mark Brown @ 2013-01-27 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358789920-1341-1-git-send-email-matt@genesi-usa.com>
On Mon, Jan 21, 2013 at 11:38:40AM -0600, Matt Sealey wrote:
> MC13892 PMIC supports a "HI" bit for 3 of it's 4 buck switcher outputs,
> which enables a higher set of voltage ranges.
Applied, thanks.
-------------- 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/20130127/406ba013/attachment.sig>
^ permalink raw reply
* [PATCH 4/6] davinci: regulator: tps6507x: add device tree support.
From: Mark Brown @ 2013-01-27 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-5-git-send-email-manishv.b@ti.com>
On Thu, Jan 24, 2013 at 04:25:18PM +0530, Vishwanathrao Badarkhe, Manish wrote:
> Add device tree based initialization support for
> TI's tps6507x regulators.
Applied, thanks. Please always use subject lines appropriate for the
subsystem you are submitting against - this is not a DaVinci change.
-------------- 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/20130127/470ff820/attachment.sig>
^ permalink raw reply
* [PATCH 11/19] regmap: regmap: avoid spurious warning in regmap_read_debugfs
From: Mark Brown @ 2013-01-27 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301261145.36158.arnd@arndb.de>
On Sat, Jan 26, 2013 at 11:45:35AM +0000, Arnd Bergmann wrote:
> Gcc warns about the case where regmap_read_debugfs tries to walk an
> empty map->debugfs_off_cache list, which would results in uninitialized
> variable getting returned, if we hadn't checked the same condition
> just before that.
Applied, thanks.
-------------- 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/20130127/52b0ef7a/attachment.sig>
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Simon Baatz @ 2013-01-27 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126235037.GV1758@titan.lakedaemon.net>
On Sat, Jan 26, 2013 at 06:50:37PM -0500, Jason Cooper wrote:
> Simon,
>
> On Sat, Jan 26, 2013 at 08:01:04PM +0100, Simon Baatz wrote:
> > Commits f479db "ARM: Kirkwood: Ensure runit clock always ticks." and
> > 128789 "ARM: Kirkwood: Fix clk problems modular ethernet driver"
> > ensured that the ge and runit clocks always tick on Kirkwood. This
> > prevents the device from locking up and from forgetting the MAC addresses
> > which are usually set by the boot loader.
> >
> > When moving the clock gating control to this driver for DT devices, these
> > changes were disabled. Ensure that the respective clocks have the
> > CLK_IGNORE_UNUSED flag set.
> >
> >
> > In the past, we fixed this by keeping the clocks ticking (which
> > probably is not be the nicest solution for the ge clocks).
>
> I have to admit, I'm not really keen on this. Most of these boards only
> have one ethernet port, so at least one port would be energized
> unnecessarily.
Me neither, the patch was intended to get 3.8 to work with
modularized drivers. It was not intended to be the final solution.
However, I think I found a better way for 3.8, see below.
>
> Another facet of this problem is the keymile board. It has to enable
> the clocks for sata in order to boot. (ref: board-km_kirkwood.c).
I did not notice it before, but looking at this, I realized why there
is the problem with the ge[01] clocks: kirkwood_ge0[01]_init() in common.c
depends on clk pointers that are only initialized in the non-DT case
(kirkwood_clk_init()) but not in the DT case
(kirkwood_legacy_clk_init() in board-dt.c).
I think we should do the following for 3.8:
- Get the clocks by device name in kirkwood_ge0x_init()
- Only set CLK_IGNORE_UNUSED for "runit" in clk-gating-ctrl.c. (I can
do this by simply adding another case to the existing "ddr"
exception, which makes the patch much less intrusive)
For 3.9 with a DT converted ethernet driver, we will need something
more clever.
If you agree, I can prepare patches for 3.8.
> Perhaps there is some way we could declare certain gate clocks to be
> non-gateable in the dts? runit comes to mind, sata for keymile, and the
> relevant ge[01] per board. After all, it is a characteristic of the
> board. ;-)
>
I like this idea. That fits my 'more clever' from above ;-)
> eg in kirkwood-km_kirkwood.dts:
>
> gate_clk: clock-gating-control at 2011c {
> /*
> * need both sata clks enabled in order to boot
> * even though we have no sata
> */
> ungateable = <14 15>;
> };
>
> and in any other board:
>
> gate_clk: clock-gating-control at 2011c {
> /* don't lose eth0 mac address */
> ungateable = <0>;
> };
>
> where in kirkwood.dtsi we had:
>
> gate_clk: clock-gating-control at 2011c {
> compatible = "marvell,kirkwood-gating-clock";
> reg = <0x2011c 0x4>;
> clocks = <&core_clk 0>;
> #clock-cells = <1>;
> ungateable = <7>; /* never gate runit */
> };
>
> or, s/ungateable/ignore_unused/g
Yes, probably better.
- Simon
^ 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