* [PATCH 2/4 v11] clk, highbank: Prevent glitches in non-bypass reset mode
From: Mark Langsdorf @ 2013-01-25 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359143205-20279-1-git-send-email-mark.langsdorf@calxeda.com>
The highbank clock will glitch with the current code if the
clock rate is reset without relocking the PLL. Program the PLL
correctly to prevent glitches.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
---
Changes from v6, v7, v8, v9, v10
None.
Changes from v5
Added Mike Turquette's ack.
Changes from v4
None.
Changes from v3
Changelog text and patch name now correspond to the actual patch.
was clk, highbank: remove non-bypass reset mode.
Changes from v2
None.
Changes from v1
Removed erroneous reformating.
drivers/clk/clk-highbank.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/clk-highbank.c b/drivers/clk/clk-highbank.c
index 52fecad..3a0b723 100644
--- a/drivers/clk/clk-highbank.c
+++ b/drivers/clk/clk-highbank.c
@@ -182,8 +182,10 @@ static int clk_pll_set_rate(struct clk_hw *hwclk, unsigned long rate,
reg |= HB_PLL_EXT_ENA;
reg &= ~HB_PLL_EXT_BYPASS;
} else {
+ writel(reg | HB_PLL_EXT_BYPASS, hbclk->reg);
reg &= ~HB_PLL_DIVQ_MASK;
reg |= divq << HB_PLL_DIVQ_SHIFT;
+ writel(reg | HB_PLL_EXT_BYPASS, hbclk->reg);
}
writel(reg, hbclk->reg);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/4 v11] arm: use device tree to get smp_twd clock
From: Mark Langsdorf @ 2013-01-25 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359143205-20279-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Move clk setup to twd_local_timer_common_register and rely on
twd_timer_rate being 0 to force calibration if there is no clock.
Remove common_setup_called as it is no longer needed.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
---
Changes from v10
Reworked to simplify the logic as suggested by Russell King.
Changes from v9
Updated to work with 3.8 kernel.
Changes from v4, v5, v6, v7, v8
None.
Changes from v3
No longer setting *clk to NULL in twd_get_clock().
Changes from v2
Turned the check for the node pointer into an if-then-else statement.
Removed the second, redundant clk_get_rate.
Changes from v1
None.
arch/arm/kernel/smp_twd.c | 53 +++++++++++++++++------------------------------
1 file changed, 19 insertions(+), 34 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 49f335d..ae0c7bb 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -31,7 +31,6 @@ static void __iomem *twd_base;
static struct clk *twd_clk;
static unsigned long twd_timer_rate;
-static bool common_setup_called;
static DEFINE_PER_CPU(bool, percpu_setup_called);
static struct clock_event_device __percpu **twd_evt;
@@ -239,25 +238,28 @@ static irqreturn_t twd_handler(int irq, void *dev_id)
return IRQ_NONE;
}
-static struct clk *twd_get_clock(void)
+static void twd_get_clock(struct device_node *np)
{
- struct clk *clk;
int err;
- clk = clk_get_sys("smp_twd", NULL);
- if (IS_ERR(clk)) {
- pr_err("smp_twd: clock not found: %d\n", (int)PTR_ERR(clk));
- return clk;
+ if (np)
+ twd_clk = of_clk_get(np, 0);
+ else
+ twd_clk = clk_get_sys("smp_twd", NULL);
+
+ if (IS_ERR(twd_clk)) {
+ pr_err("smp_twd: clock not found %d\n", (int) PTR_ERR(twd_clk));
+ return;
}
- err = clk_prepare_enable(clk);
+ err = clk_prepare_enable(twd_clk);
if (err) {
pr_err("smp_twd: clock failed to prepare+enable: %d\n", err);
- clk_put(clk);
- return ERR_PTR(err);
+ clk_put(twd_clk);
+ return;
}
- return clk;
+ twd_timer_rate = clk_get_rate(twd_clk);
}
/*
@@ -280,26 +282,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
}
per_cpu(percpu_setup_called, cpu) = true;
- /*
- * This stuff only need to be done once for the entire TWD cluster
- * during the runtime of the system.
- */
- if (!common_setup_called) {
- twd_clk = twd_get_clock();
-
- /*
- * We use IS_ERR_OR_NULL() here, because if the clock stubs
- * are active we will get a valid clk reference which is
- * however NULL and will return the rate 0. In that case we
- * need to calibrate the rate instead.
- */
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
- twd_calibrate_rate();
-
- common_setup_called = true;
- }
+ twd_calibrate_rate();
/*
* The following is done once per CPU the first time .setup() is
@@ -330,7 +313,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
.stop = twd_timer_stop,
};
-static int __init twd_local_timer_common_register(void)
+static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
@@ -350,6 +333,8 @@ static int __init twd_local_timer_common_register(void)
if (err)
goto out_irq;
+ twd_get_clock(np);
+
return 0;
out_irq:
@@ -373,7 +358,7 @@ int __init twd_local_timer_register(struct twd_local_timer *tlt)
if (!twd_base)
return -ENOMEM;
- return twd_local_timer_common_register();
+ return twd_local_timer_common_register(NULL);
}
#ifdef CONFIG_OF
@@ -405,7 +390,7 @@ void __init twd_local_timer_of_register(void)
goto out;
}
- err = twd_local_timer_common_register();
+ err = twd_local_timer_common_register(np);
out:
WARN(err, "twd_local_timer_of_register failed (%d)\n", err);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 0/4 v11] cpufreq: add support for Calxeda ECX-1000 (highbank)
From: Mark Langsdorf @ 2013-01-25 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351631056-25938-1-git-send-email-mark.langsdorf@calxeda.com>
This patch series adds cpufreq support for the Calxeda
ECX-1000 (highbank) SoCs. The EnergyCore Management Engine (ECME) on
the ECX-1000 manages the voltage for the part and communications with
Linux through a pl320 mailbox. clk notifications are used to control
when to send messages to the ECME.
Previous versions of this patch set include two other patches. One has
been dropped as unworkable and the other turned out to be unnecessary.
--Mark Langsdorf
Calxeda, Inc.
^ permalink raw reply
* [kvmarm] [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Alexander Graf @ 2013-01-25 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAu8pHve_E-jtQAXidxroWHRVi_QKaYs6YeQhHqEap2bd7RMEQ@mail.gmail.com>
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.
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.
Alex
^ permalink raw reply
* [PATCH 0/6] Initial Device Tree support for S3C64xx
From: Kukjin Kim @ 2013-01-25 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1689405.9Ne2g34LZt@flatron>
Tomasz Figa wrote:
>
> On Sunday 13 of January 2013 02:10:52 Tomasz Figa wrote:
> > This series is adds Device Tree support for Samsung S3C64xx SoC series.
> >
> > It fixes several problems preventing from booting an S3C64xx-based
> > system using Device Tree, adds all the infrastructure for Device
> > Tree-based board support, including mach-s3c64xx-dt and dts include
> > files for S3C64xx SoCs, and (very) basic device tree source for
> > FriendlyARM Mini6410 board.
> >
> > Current support is very limited and allows only basic bootup with UART
> > and SDHCI, but should be fine as a start and will be extended in
> > future, hopefully with help of S3C64xx board maintainers.
> >
> > Tomasz Figa (6):
> > ARM: common: vic: Parse interrupt and resume masks from device tree
> > ARM: common: vic: Fix invalid first IRQ number in OF-based
> > registration
> > ARM: s3c64xx: Add support for OF-based VIC initialization
> > ARM: s3c64xx: Add board file for boot using Device Tree
> > ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
> > ARM: dts: Add dts file for S3C6410-based Mini6410 board
> >
> > Documentation/devicetree/bindings/arm/vic.txt | 6 ++
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/s3c6400.dtsi | 33 +++++++++
> > arch/arm/boot/dts/s3c6410-mini6410.dts | 50 ++++++++++++++
> > arch/arm/boot/dts/s3c6410.dtsi | 33 +++++++++
> > arch/arm/boot/dts/s3c64xx.dtsi | 97
> > +++++++++++++++++++++++++++ arch/arm/common/vic.c
> > | 9 ++-
> > arch/arm/mach-s3c64xx/Kconfig | 13 ++++
> > arch/arm/mach-s3c64xx/Makefile | 1 +
> > arch/arm/mach-s3c64xx/common.c | 16 +++++
> > arch/arm/mach-s3c64xx/common.h | 4 ++
> > arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 84
> > +++++++++++++++++++++++ 12 files changed, 345 insertions(+), 2
> > deletions(-)
> > create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
> > create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts
> > create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
> > create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
> > create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
>
> Any other comments on this series?
>
Looks good to me. But would be better if the vic changes could get ack ;-)
Thanks.
- Kukjin
^ permalink raw reply
* [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
From: Kukjin Kim @ 2013-01-25 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3747315.IyCCRDXgbD@flatron>
Tomasz Figa wrote:
[...]
> > Well, the number of CPU types does not grow rapidly. It will be much
> > less than one per SoC -- so keeping the list up to date shouldn't be
> > that much effort.
> >
> > For ARM1176JZF-S, it could make sense for the comatible list to be
> >
> > "arm,arm1176jzf-s", "arm,arm1176"
> >
> > ...since the differences between 1176 variants are software probeable
> > (i.e., whether there is an FPU or not). AFAIK the J, Z apply to all
> > ARM1176, and the -S (synthesisable RTL) is nothing to do with software.
> > The kernel probably only really needs to know "arm,arm1176".
>
> OK. So the conclusion is that I should change the cpus node to following:
>
> cpus {
> cpu {
cpu at 0 { ?
> compatible = "arm,arm1176jzf-s", "arm,arm1176";
> };
> };
>
> Am I right?
>
I think so :-)
- Kukjin
^ permalink raw reply
* [PATCH 0/6] Initial Device Tree support for S3C64xx
From: Tomasz Figa @ 2013-01-25 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358039458-31960-1-git-send-email-tomasz.figa@gmail.com>
On Sunday 13 of January 2013 02:10:52 Tomasz Figa wrote:
> This series is adds Device Tree support for Samsung S3C64xx SoC series.
>
> It fixes several problems preventing from booting an S3C64xx-based
> system using Device Tree, adds all the infrastructure for Device
> Tree-based board support, including mach-s3c64xx-dt and dts include
> files for S3C64xx SoCs, and (very) basic device tree source for
> FriendlyARM Mini6410 board.
>
> Current support is very limited and allows only basic bootup with UART
> and SDHCI, but should be fine as a start and will be extended in
> future, hopefully with help of S3C64xx board maintainers.
>
> Tomasz Figa (6):
> ARM: common: vic: Parse interrupt and resume masks from device tree
> ARM: common: vic: Fix invalid first IRQ number in OF-based
> registration
> ARM: s3c64xx: Add support for OF-based VIC initialization
> ARM: s3c64xx: Add board file for boot using Device Tree
> ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
> ARM: dts: Add dts file for S3C6410-based Mini6410 board
>
> Documentation/devicetree/bindings/arm/vic.txt | 6 ++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/s3c6400.dtsi | 33 +++++++++
> arch/arm/boot/dts/s3c6410-mini6410.dts | 50 ++++++++++++++
> arch/arm/boot/dts/s3c6410.dtsi | 33 +++++++++
> arch/arm/boot/dts/s3c64xx.dtsi | 97
> +++++++++++++++++++++++++++ arch/arm/common/vic.c
> | 9 ++-
> arch/arm/mach-s3c64xx/Kconfig | 13 ++++
> arch/arm/mach-s3c64xx/Makefile | 1 +
> arch/arm/mach-s3c64xx/common.c | 16 +++++
> arch/arm/mach-s3c64xx/common.h | 4 ++
> arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 84
> +++++++++++++++++++++++ 12 files changed, 345 insertions(+), 2
> deletions(-)
> create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
> create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts
> create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
> create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
> create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
Any other comments on this series?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
From: Tomasz Figa @ 2013-01-25 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116105957.GA1963@linaro.org>
Hi,
On Wednesday 16 of January 2013 10:59:57 Dave Martin wrote:
> On Mon, Jan 14, 2013 at 03:05:32PM +0000, Lorenzo Pieralisi wrote:
> > On Mon, Jan 14, 2013 at 02:48:41PM +0000, Mark Rutland wrote:
> > > Hello,
> > >
> > > This all looks good. I just have a couple of comments about the cpus
> > > node.> >
> > > On Sun, Jan 13, 2013 at 01:10:57AM +0000, Tomasz Figa wrote:
> > > > This patch adds basic device tree definitions for Samsung S3C64xx
> > > > SoCs.
> > > >
> > > > Since all the SoCs in the series are very similar, the files are
> > > > created hierarchically - one file for the whole series and then
> > > > separate files for particular SoCs including the common one.
> > > >
> > > > Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> > >
> > > [...]
> > >
> > > > diff --git a/arch/arm/boot/dts/s3c64xx.dtsi
> > > > b/arch/arm/boot/dts/s3c64xx.dtsi new file mode 100644
> > > > index 0000000..55d6e08
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/s3c64xx.dtsi
> > > > @@ -0,0 +1,97 @@
> > > > +/*
> > > > + * Samsung's S3C64xx SoC series common device tree source
> > > > + *
> > > > + * Copyright (c) 2013 Tomasz Figa <tomasz.figa@gmail.com>
> > > > + *
> > > > + * Samsung's S3C64xx SoC series device nodes are listed in this
> > > > file.
> > > > + * Particular SoCs from S3C64xx series can include this file and
> > > > provide + * values for SoCs specfic bindings.
> > > > + *
> > > > + * Note: This file does not include device nodes for all the
> > > > controllers in + * S3C64xx SoCs. As device tree coverage for
> > > > S3C64xx increases, additional + * nodes can be added to this
> > > > file.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > modify + * it under the terms of the GNU General Public License
> > > > version 2 as + * published by the Free Software Foundation.
> > > > + */
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > > +
> > > > +/ {
> > > > + cpus {
> > > > + cpu at 0 {
> > > > + compatible = "arm,arm1176jzf-s";
> > > > + };
> > > > + };
> > >
> > > You can drop the unit address from the cpu node - it's meant to be
> > > there to differentiate multiple nodes (and is supposed to match the
> > > reg property, which the 1176jzf-s can't have, as it doesn't have an
> > > MPIDR).
> >
> > Well, this is a point that I should consider since the kernel docs I
> > wrote are misleading, they require the reg property that can not be
> > there on UP. True, MPIDR does not exist in this case, but I have to
> > document this in the bindings since it is unclear.
> >
> > > Also, "arm,arm1176jzf-s" isn't listed in the binding doc. There was
> > > a question about how to maintain this list [1], but I can't seem to
> > > find a conclusion, if any were reached. It might be worth
> > > appending "arm,arm1176" to the compatible list for the cpu node in
> > > case we want to enable something via dt for all 1176 variations.
> > >
> > > Dave, Lorenzo, any thoughts?
> >
> > Eh, frankly I do not know how to handle this. Either we add a
> > compatible string to the bindings anytime a DT gets merged in the
> > kernel but how to maintain it, it has to be defined. Happy to hear
> > some feedback on this.
>
> Well, the number of CPU types does not grow rapidly. It will be much
> less than one per SoC -- so keeping the list up to date shouldn't be
> that much effort.
>
> For ARM1176JZF-S, it could make sense for the comatible list to be
>
> "arm,arm1176jzf-s", "arm,arm1176"
>
> ...since the differences between 1176 variants are software probeable
> (i.e., whether there is an FPU or not). AFAIK the J, Z apply to all
> ARM1176, and the -S (synthesisable RTL) is nothing to do with software.
> The kernel probably only really needs to know "arm,arm1176".
OK. So the conclusion is that I should change the cpus node to following:
cpus {
cpu {
compatible = "arm,arm1176jzf-s", "arm,arm1176";
};
};
Am I right?
Best regards,
Tomasz
^ permalink raw reply
* [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Blue Swirl @ 2013-01-25 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALrVBktEQM5D-L+60RTzdRgo7jLZ671KxWMUFGnQwQ1bzgjO2A@mail.gmail.com>
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.
> 2. Architecture independent devices: This are Virtio-based devices which are
> usually required by a desktop virtual machine.
> a) Virtio-blk (storage)
> - Already available
> b) Virtio-net (network)
> - Already available
> c) Virtio-fb (display)
> - It seems some work has been already done for Virtio frame buffer but
> I did not find drivers/fb/virtio-fb.c in latest kernel
> (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/42720)
> - Is Virtio-fb work still in-progress ??
> d) Virtio-input (keyboard/mouse/multi-touch)
> - Currently not available
> - It will provide keyboard input events
> - It will provide mouse input events
> - It will provide multi-touch input events
> e) Virtio-power (reset/shutdown/enumeration)
> - It can provides info about the entire virtual machine including CPU,
> PIC, Timer, available Virtio devices, etc.
> - It can also provide CPU and Virtio-device hot-plugging
> - Its primary purpose would be to provide reset and shutdown of CPU and
> Virtio devices.
> - There will be only one instance of this device and its location will
> be fixed for each architecture.
d) and e) would be also covered by the PV event device. Perhaps also a) and b).
I'm not sure how c) would be different from X11 (the original network
protocol using version, not Wayland).
>
> The Virtio-desktop specification may also describe a recommended memory map
> of for each architecture.
Memory management (ballooning and page faults) could also use the
event device. The use of events could also avoid memory to memory
copies (zero copy) by letting the host manage the buffer memory.
>
> Right now, only missing devices seems to be Virtio-fb, Virtio-input, and
> Virtio-power, which some of us are willing to take-up.
>
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.
>
> Best Regards,
> Anup
^ permalink raw reply
* [PATCH v3 0/9] ARM: S3C24XX: rework irq handling for a later dt usage
From: Kukjin Kim @ 2013-01-25 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301190403.50317.heiko@sntech.de>
Heiko St?bner wrote:
>
> Third version of redoing the s3c24xx irqs in a generic way by using a
> declarative approach.
>
> Main change is the different approach to the init. Moved the
> s3c24xx_init_intc function from the dt patchset here, so that both init types
> (dt and non-dt) can use a similar init scheme.
>
> As in the second version, the 1st patch might be hard to read due to the
> rewrite character, but I didn't see a way to do these changes in individual
> steps. So it might be helpful to look at the result after applying this patch.
>
> Runtime-tested on a s3c2416 based board and compile tested for the others.
>
> As also written before, inclusion of the other S3C24XX SoCs to follow once
> the general approach is acceptable.
>
> Applies to the most current for-next (from two hours ago) from linux-
> samsung
>
> Heiko Stuebner (9):
> ARM: S3C24XX: transform irq handling into a declarative form
> ARM: S3C24XX: Move irq syscore-ops to irq-pm
> ARM: S3C24XX: Modify s3c_irq_wake to use the hwirq property
> ARM: S3C24XX: move s3c2416 irq init to common irq code
> ARM: S3C24XX: modify s3c2416 irq init to initialize all irqs
> ARM: S3C24XX: transform s3c2416 irqs into new structure
> ARM: S3C24XX: move s3c2443 irq code to irq.c
> ARM: S3C24XX: modify s3c2443 irq init to initialize all irqs
> ARM: S3C24XX: transform s3c2443 subirqs into new structure
>
> arch/arm/mach-s3c24xx/Makefile | 4 +-
> arch/arm/mach-s3c24xx/common.h | 2 +
> arch/arm/mach-s3c24xx/irq-pm.c | 41 +-
> arch/arm/mach-s3c24xx/irq-s3c2416.c | 348 --------
> arch/arm/mach-s3c24xx/irq-s3c2443.c | 281 -------
> arch/arm/mach-s3c24xx/mach-smdk2416.c | 2 +-
> arch/arm/mach-s3c24xx/mach-smdk2443.c | 2 +-
> arch/arm/mach-s3c24xx/s3c2410.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2412.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2416.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2440.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2442.c | 4 +-
> arch/arm/plat-s3c24xx/Kconfig | 1 +
> arch/arm/plat-s3c24xx/irq.c | 1110 +++++++++++++++-----------
> arch/arm/plat-samsung/include/plat/pm.h | 6 -
> arch/arm/plat-samsung/include/plat/s3c2416.h | 1 +
> arch/arm/plat-samsung/include/plat/s3c2443.h | 2 +
> 17 files changed, 688 insertions(+), 1132 deletions(-)
> delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2416.c
> delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2443.c
>
> --
> 1.7.2.3
Heiko, looks good to me :-)
BTW, can you rebase this against on next/cleanup-s3c24xx branch in my tree?
Thanks.
- Kukjin
^ permalink raw reply
* [PATCH] mfd/vexpress: vexpress_sysreg_setup must not be __init
From: Arnd Bergmann @ 2013-01-25 18:53 UTC (permalink / raw)
To: linux-arm-kernel
The patch 52666298a 'mfd: vexpress-sysreg: Don't skip initialization
on probe' adds a call to vexpress_sysreg_setup from a non-__init
function, so this also has to lose its __init annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: arm at kernel.org
---
drivers/mfd/vexpress-sysreg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 77048b1..558c292 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -313,7 +313,7 @@ static void vexpress_sysreg_config_complete(unsigned long data)
}
-void __init vexpress_sysreg_setup(struct device_node *node)
+void vexpress_sysreg_setup(struct device_node *node)
{
if (WARN_ON(!vexpress_sysreg_base))
return;
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: Fix crash on soft reset
From: Kukjin Kim @ 2013-01-25 18:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Abraham <thomas.ab@samsung.com>
The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Girish K S <ks.giri@samsung.com>
Signed-off-by: Kukjin <kgene.kim@samsung.com>
---
arch/arm/mach-exynos/common.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index ed53a4f..b4d3188 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -294,6 +294,7 @@ void exynos4_restart(char mode, const char *cmd)
void exynos5_restart(char mode, const char *cmd)
{
+ struct device_node *np;
u32 val;
void __iomem *addr;
@@ -301,8 +302,9 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
- val = (0x10 << 20) | (0x1 << 16);
- addr = EXYNOS5440_SWRESET;
+ np = of_find_compatible_node(NULL, NULL, "samsung,exynos5440-clock");
+ addr = of_iomap(np, 0) + 0xcc;
+ val = (0xfff << 20) | (0x1 << 16);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] ARM: SAMSUNG: Gracefully exit on suspend failure
From: Kukjin Kim @ 2013-01-25 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358515116-7280-1-git-send-email-a.kesavan@samsung.com>
Abhilash Kesavan wrote:
>
> As per the Exynos5250 User Manual:
> When there are pending interrupt events, WFI/WFE instruction are
> ignored. To cancel the power-down sequence follow these steps:
> 1) Disable system power-down using CENTRAL_SEQ_CONFIGURATION
> register
> 2) Clear WAKEUP_STAT register
> 3) Enable interrupt service routine for CPU
>
> Code for early wakeup for exynos already exists. Remove the panic
> on suspend failure, clear the wakeup state register and return 1
> from cpu_suspend to indicate a failed suspend (to a user daemon).
>
> Older Samsung SoCs have similar panics and I have removed them all.
> Haven't touched the S3C2410 sleep code.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
Looks OK to me, applied.
Thanks.
- Kukjin
^ permalink raw reply
* [RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion
From: Jason Gunthorpe @ 2013-01-25 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABJ1b_QaTBLgGASTs2yi435jR=LepN-iY97xTLXAu1hZw69Wuw@mail.gmail.com>
On Fri, Jan 25, 2013 at 04:03:29PM +0100, Sebastian Hesselbarth wrote:
> On Fri, Jan 25, 2013 at 1:52 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Once I have the mv643xx_eth binding working reliably, preferably with
> > mvmdio, I'll take a look at removing the last board-*.c files. If the
> > stars align, we'll get it all done for v3.9.
> >
> > The only big thing left will be pcie.
> there is also addr_map that we haven't thought about yet. Is it supposed
> to be configurable through DT or do we leave it as "linux wants it that way"?
FWIW, this was a pain + surprise for us when we started out. The
address map Linux wants is not the same as the device power on
default, and the Linux mapping is hardwired into the kernel :(
I would be happy to see the address map setup be more flexible and
done via DT. It would be a bit of a pain to change, but via DT each
decoded window could be described as a bus with a ranges and an OF
address map driver could directly setup the windows to match those DT
nodes. Something like this, repeated for each window:
// MBUS Decoder window for NAND
nand at f4000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus", "marvell,orion-mbus";
mbus-target = 0xXXXXX;
ranges = <0 0xf4000000 0x10000>;
nand at 0 {
cle = <0>;
ale = <1>;
bank-width = <1>;
chip-delay = <50>;
compatible = "marvell,orion-nand";
reg = <0x0 0x400>;
};
};
// MBUS decoder window for internal registers
internal at f1000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus", "marvell,orion-mbus";
mbus-target = 0xXXXXX;
ranges = <0 0xf1000000 0x100000>;
intc: interrupt-controller at 20204 {
#interrupt-cells = <1>;
compatible = "marvell,orion-intc", "marvell,intc";
interrupt-controller;
reg = <0x20204 0x04>,
<0x20214 0x04>;
};
[... etc ...]
};
Regards,
Jason
^ permalink raw reply
* [PATCH v2] ARM: plat-samsung: using vsnprintf instead of vsprintf for the limit buffer length 256
From: Kukjin Kim @ 2013-01-25 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE0D8B.7010908@asianux.com>
Chen Gang wrote:
>
>
> the buff is 256 limited, so need use vsnprintf instead of vsprintf
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> Cc: Ben Dooks <ben@fluff.org>
> ---
> arch/arm/plat-samsung/pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
> index 1507028..d896add 100644
> --- a/arch/arm/plat-samsung/pm.c
> +++ b/arch/arm/plat-samsung/pm.c
> @@ -51,7 +51,7 @@ void s3c_pm_dbg(const char *fmt, ...)
> char buff[256];
>
> va_start(va, fmt);
> - vsprintf(buff, fmt, va);
> + vsnprintf(buff, sizeof(buff), fmt, va);
> va_end(va);
>
> printascii(buff);
> --
> 1.7.10.4
Applied, thanks.
- Kukjin
^ permalink raw reply
* [PATCH/RFC 2/3] ethernet: add a PHY reset GPIO DT binding to sh_eth
From: Jason Gunthorpe @ 2013-01-25 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1301251127460.17518@axis700.grange>
On Fri, Jan 25, 2013 at 11:34:55AM +0100, Guennadi Liakhovetski wrote:
> > Is there no need to reset the phy at runtime ?
>
> No idea, I'm not developing the driver, I'm just porting one specific
> feature from one API to another with no functional changes (apart from
> postponing setting the GPIO).
Generally Linux relies on resetting the phy via the inband MDIO method,
which is what Linux does. It is pretty much never required to reset
via the hard pin - but you do need to generate a robust reset edge on
the reset pin once after power up.
Jason
^ permalink raw reply
* [RFC PATCH 4/4] net: mvmdio: add getter and setter for PHY addresses
From: Jason Gunthorpe @ 2013-01-25 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359108409-4378-5-git-send-email-florian@openwrt.org>
On Fri, Jan 25, 2013 at 11:06:49AM +0100, Florian Fainelli wrote:
> This patch adds orion_mdio_{set,get}_phy_addr(.., port_number, phy_addr)
> which is a feature available in this MDIO driver to monitor a particular
> PHY address. This brings mvmdio one step closer to what is used in
> mv643x_eth.
This seems really strange.
Are you sure this should be part of the MDIO driver? Based on my docs,
this register is part of the ethernet controller HW, which
autonomously reads from the phy via MDIO.
It seems cleaner to set this register from the ethernet controller
based on the phy it is using and keep the MDIO driver purely for MDIO
bus access.
It is acceptable to overlap the device address ranges, start the
ethernet controller at 72000 and start the MDIO at 72004, the platform
bus code automatically nests them.
Jason
^ permalink raw reply
* [PATCH 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Catalin Marinas @ 2013-01-25 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359130578.32148.1.camel@linux-builds1>
On Fri, Jan 25, 2013 at 04:16:18PM +0000, Dinh Nguyen wrote:
> Hi Catalin,
>
> On Wed, 2013-01-23 at 17:59 +0000, Catalin Marinas wrote:
> > All the calls to gic_secondary_init() pass 0 as the first argument.
> > Since this function is called on each CPU when starting, it can be done
> > in a platform-independent way via a CPU notifier registered by the GIC
> > code.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: David Brown <davidb@codeaurora.org>
> > Cc: Daniel Walker <dwalker@fifo99.com>
> > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Simon Horman <horms@verge.net.au>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: Shiraz Hashim <shiraz.hashim@st.com>
> > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > ---
> >
> > Randomly chosen CPU notifier priority. I can add a definition somewhere
> > though they don't seem to be used much and cause conflicts.
> >
> > arch/arm/mach-exynos/platsmp.c | 8 --------
> > arch/arm/mach-highbank/platsmp.c | 7 -------
> > arch/arm/mach-imx/platsmp.c | 12 ------------
> > arch/arm/mach-msm/platsmp.c | 8 --------
> > arch/arm/mach-omap2/omap-smp.c | 7 -------
> > arch/arm/mach-shmobile/smp-emev2.c | 7 -------
> > arch/arm/mach-shmobile/smp-r8a7779.c | 7 -------
> > arch/arm/mach-shmobile/smp-sh73a0.c | 7 -------
> > arch/arm/mach-socfpga/platsmp.c | 12 ------------
>
> For socfpga, I get this error when I build for sofpga_defconfig:
>
> drivers/gpio/gpio-pl061.c: In function ?pl061_irq_handler?:
> drivers/gpio/gpio-pl061.c:183:2: error: implicit declaration of function
> ?chained_irq_enter? [-Werror=implicit-function-declaration]
> drivers/gpio/gpio-pl061.c:192:2: error: implicit declaration of function
> ?chained_irq_exit? [-Werror=implicit-function-declaration]
Ah, I only grep'ed arch/arm for chained_irq_enter() use. The simplest
for arch/arm is to actually include chained_irq.h into asm/mach/irq.h
since the latter is already included. For code shared with arm64 I'll
just include chained_irq.h explicitly.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Ezequiel Garcia @ 2013-01-25 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125155633.GC16795@e106331-lin.cambridge.arm.com>
Hi Mark,
First of all: thanks for reviewing.
On Fri, Jan 25, 2013 at 12:56 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> I have a couple more comments after looking though this a bit more thoroughly.
>
> On Fri, Jan 25, 2013 at 12:23:11PM +0000, Ezequiel Garcia wrote:
>> This patch adds device tree bindings for OMAP OneNAND devices.
>> Tested on an OMAP3 3430 IGEPv2 board.
>>
>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> ---
>> Changes from v2:
>> * Remove unneeded of_node_put() as reported by Mark Rutland
>>
>> Changes from v1:
>> * Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>>
>> .../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++++++++++++++++++
>> arch/arm/mach-omap2/gpmc.c | 45 ++++++++++++++++++++
>> 2 files changed, 88 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>> new file mode 100644
>> index 0000000..deec9da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>> @@ -0,0 +1,43 @@
>> +Device tree bindings for GPMC connected OneNANDs
>> +
>> +GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
>> +the GPMC controller with a name of "onenand".
>> +
>> +All timing relevant properties as well as generic gpmc child properties are
>> +explained in a separate documents - please refer to
>> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
>
> Which tree can I find this in?
>
GPMC binding was posted by Daniel Mack a while ago.
Tony has recently pushed it to his master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
>> +
>> +Required properties:
>> +
>> + - reg: The CS line the peripheral is connected to
>> +
>> +Optional properties:
>> +
>> + - dma-channel: DMA Channel index
>> +
>> +For inline partiton table parsing (optional):
>> +
>> + - #address-cells: should be set to 1
>> + - #size-cells: should be set to 1
>> +
>> +Example for an OMAP3430 board:
>> +
>> + gpmc: gpmc at 6e000000 {
>> + compatible = "ti,omap3430-gpmc";
>> + ti,hwmods = "gpmc";
>> + reg = <0x6e000000 0x1000000>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> +
>> + onenand at 0 {
>> + reg = <0 0 0>; /* CS0, offset 0 */
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + /* partitions go here */
>> + };
>> + };
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index c6255f7..0636d0a 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -39,6 +39,7 @@
>> #include "omap_device.h"
>> #include "gpmc.h"
>> #include "gpmc-nand.h"
>> +#include "gpmc-onenand.h"
>>
>> #define DEVICE_NAME "omap-gpmc"
>>
>> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
>> }
>> #endif
>>
>> +#ifdef CONFIG_MTD_ONENAND
>> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> + u32 val;
>> + struct omap_onenand_platform_data *gpmc_onenand_data;
>> +
>> + if (of_property_read_u32(child, "reg", &val) < 0) {
>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> + child->full_name);
>> + return -ENODEV;
>> + }
>
> I don't understand the format of the reg property, but it seems odd that you
> only need to read one cell from it. Are the remaining address cell and size
> cell used anywhere?
>
Okey, I'll give a shot and try to explain this myself:
As you can see by Daniel's first patch [1]
the reg property originally contained the chip select only, and
after some discussion in that same thread, and in this one [2]
It was decided to use a reg property that would also describe
the base address and size of the gpmc sub-device,
and use ranges for the address translation.
This was reflected in Daniel's changelog when he submitted
the v2 patch series [3].
[1] http://www.spinics.net/lists/arm-kernel/msg202169.html
[2] http://web.archiveorange.com/archive/v/vEQ2yFI0tmpQJdigvAog
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129426.html
>> +
>> + gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
>> + GFP_KERNEL);
>> + if (!gpmc_onenand_data)
>> + return -ENOMEM;
>> +
>> + gpmc_onenand_data->cs = val;
>> + gpmc_onenand_data->of_node = child;
>> + gpmc_onenand_data->dma_channel = -1;
>> +
>> + if (!of_property_read_u32(child, "dma-channel", &val))
>> + gpmc_onenand_data->dma_channel = val;
>> +
>> + gpmc_onenand_init(gpmc_onenand_data);
>> +
>> + return 0;
>> +}
>
> [...]
>
> Otherwise looks good.
>
Thanks,
--
Ezequiel
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Pavel Machek @ 2013-01-25 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359131057.32148.9.camel@linux-builds1>
On Fri 2013-01-25 10:24:17, Dinh Nguyen wrote:
> Hi Pavel,
> On Fri, 2013-01-25 at 16:49 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > mach-socfpga is another platform that needs to use
> > > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
> >
> > If there are three copies of code, with fourth one needed for next
> > platform, moving it into common code makes sense.
> >
> > But... The code was not identical before the merge. Are you sure that
> > the differences do not hurt? At the very least, it should be mentioned
> > in the changelog.
>
> Indeed, the addition of
>
> mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
>
> was done by commit # 5b2acf384c8a8707d32a98106192ee7187e4446d
>
> This adds invalidate I-Cache as well as D-Cache, which I think should be
> ok for most platforms.
>
> Hopefully, Stephen can test and verify.
Otherwise it works for me... and looks like a good idea.
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCHv1 for soc 5/5] arm: socfpga: Add SMP support for actual socfpga harware
From: Pavel Machek @ 2013-01-25 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-6-git-send-email-dinguyen@altera.com>
Hi!
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Because the CPU1 start address is different for socfpga-vt and
> socfpga-cyclone5, we add code to use the correct CPU1 start addr.
>
> +++ b/arch/arm/configs/socfpga_defconfig
> @@ -21,6 +21,7 @@ CONFIG_ARM_THUMBEE=y
> # CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
> # CONFIG_CACHE_L2X0 is not set
> CONFIG_HIGH_RES_TIMERS=y
> +CONFIG_VMSPLIT_2G=y
> CONFIG_SMP=y
> CONFIG_NR_CPUS=2
> CONFIG_AEABI=y
Is this related to CPU1 start address?
> +++ b/arch/arm/mach-socfpga/headsmp.S
> @@ -13,13 +13,19 @@
> __CPUINIT
> .arch armv7-a
>
> -#define CPU1_START_ADDR 0xffd08010
> -
> ENTRY(secondary_trampoline)
> - movw r0, #:lower16:CPU1_START_ADDR
> - movt r0, #:upper16:CPU1_START_ADDR
> + movw r2, #:lower16:cpu1start_addr
> + movt r2, #:upper16:cpu1start_addr
>
> + ldr r0, [r2]
> ldr r1, [r0]
> bx r1
>
> ENTRY(secondary_trampoline_end)
> +
> +#ifdef CONFIG_SMP
> +ENTRY(v7_secondary_startup)
> + bl v7_invalidate_l1
> + b secondary_startup
> +ENDPROC(v7_secondary_startup)
> +#endif
#ifdef should not be neccessary, as headsmp.S is only compiled when CONFIG_SMP.
> +++ b/arch/arm/mach-socfpga/platsmp.c
> @@ -49,7 +49,8 @@ static int __cpuinit socfpga_boot_secondary(unsigned int cpu, struct task_struct
>
> memcpy(phys_to_virt(0), &secondary_trampoline, trampoline_size);
>
> - __raw_writel(virt_to_phys(secondary_startup), (sys_manager_base_addr+0x10));
> + __raw_writel(virt_to_phys(v7_secondary_startup),
> + (sys_manager_base_addr + (cpu1start_addr & 0x000000ff)));
>
The math is rather interesting here; is (sys_manager_base_addr +
(cpu1start_addr & 0x000000ff)) == cpu1start_addr ?
> @@ -55,6 +56,16 @@ static void __init socfpga_scu_map_io(void)
> iotable_init(&scu_io_desc, 1);
> }
>
> +static void __init init_socfpga_vt(void)
> +{
> + cpu1start_addr = 0xffd08010;
> +}
> +
> +static void __init init_socfpga(void)
> +{
> + cpu1start_addr = 0xffd080c4;
> +}
Should this be put into device tree somewhere?
In addition, this patch seems to break operation in the emulator for
me. In fact, it looks pretty much like emulator crash, with continuous
scroll of
B_TRANSPORT::(R(Addr=0x23092FD0, Count=08 ...
[sorry, it is hard to copy moving messages].
I'm using kernel based on 3.7-rc2. Should I attempt updating?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 3/5] ARM: samsung: fix assembly syntax for new gas
From: Kukjin Kim @ 2013-01-25 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-4-git-send-email-arnd@arndb.de>
Arnd Bergmann wrote:
>
> Recent assembler versions complain about extraneous
> whitespace inside [] brackets. This fixes all of
> these instances for the samsung platforms. We should
> backport this to all kernels that might need to
> be built with new binutils.
>
> arch/arm/kernel/entry-armv.S: Assembler messages:
> arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr
> r2,[ r6,#(0x10)]'
> arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr
> r0,[ r6,#(0x14)]'
> arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr
> r2,[ r6,#(0x10)]'
> arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr
> r0,[ r6,#(0x14)]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected --
> `ldr r7,[ r4 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected --
> `ldr r8,[ r5 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected --
> `ldr r9,[ r6 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected --
> `streq r7,[ r4 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected --
> `streq r8,[ r5 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected --
> `streq r9,[ r6 ]'
> arch/arm/kernel/debug.S: Assembler messages:
> arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr
> r2,[ r2,#((0x0B0)+(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000))))]'
> arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x18)]'
> arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr
> r2,[ r2,#((0x0B0)+(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000))))]'
> arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x18)]'
> arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
> arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr
> pc,[ r0,#((0x0B8)+(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-
> (0x50000000))+(0xF6000000+(0x01000000)))]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected --
> `ldrne r9,[ r1 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected --
> `strne r9,[ r1 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected --
> `ldrne r9,[ r2 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected --
> `strne r9,[ r2 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected --
> `ldrne r9,[ r3 ]'
> arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected --
> `strne r9,[ r3 ]'
> arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x08)]'
> arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x18)]'
> arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x10)]'
> arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x08)]'
> arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x18)]'
> arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr
> r2,[ r3,#(0x10)]'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
[...]
Thanks.
- Kukjin
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-01-25 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359130838.32148.5.camel@linux-builds1>
On Friday 25 January 2013 09:50 PM, Dinh Nguyen wrote:
> Hi Santosh,
>
> On Fri, 2013-01-25 at 13:43 +0530, Santosh Shilimkar wrote:
>> On Friday 25 January 2013 06:30 AM, dinguyen at altera.com wrote:
>>> From: Dinh Nguyen <dinguyen@altera.com>
>>>
>>> mach-socfpga is another platform that needs to use
>>> v7_invalidate_l1 to bringup additional cores. There was a comment that
>>> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>>>
>>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Cc: Sascha Hauer <kernel@pengutronix.de>
>>> Cc: Simon Horman <horms@verge.net.au>
>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>>> Cc: Pavel Machek <pavel@denx.de>
>>> ---
>>> arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
>>> arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
>>> arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
>>> arch/arm/mm/cache-v7.S | 47 +++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 47 insertions(+), 138 deletions(-)
>>>
>> Does yor kernel skips the decompresser. Am just curious about
>> what you describe above since you should see the issue already
>> at decompresser. Your boot loader is expected to clean and
>> invalidating the caches before jumping into the kernel.
>
> This is for bringing up the 2nd core after the main CPU is already
> alive. Indeed, I did see this issue when the main CPU was coming up and
> have changed the bootloader to clean and invalidate the caches.
>
Ahh. I understand it now.
Regards
Santosh
^ permalink raw reply
* [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: Ben Hutchings @ 2013-01-25 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqRKhXRg-SsigWdnfV-RBWSc=OH9ECqQnKHDvmbn8e4a2A@mail.gmail.com>
On Fri, 2013-01-25 at 09:50 +0800, Frank Li wrote:
> 2013/1/25 Ben Hutchings <bhutchings@solarflare.com>:
> > On Thu, 2013-01-24 at 10:16 +0800, Frank Li wrote:
> >> 2013/1/24 Ben Hutchings <bhutchings@solarflare.com>:
> >> > On Thu, 2013-01-17 at 10:55 +0800, Frank Li wrote:
> >> >> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
> >> >> There will be many packages lost because FIFO over run.
> >> >>
> >> >> This patch enable pause frame flow control.
> >> > [...]
> >> >> --- a/drivers/net/ethernet/freescale/fec.c
> >> >> +++ b/drivers/net/ethernet/freescale/fec.c
> >> > [...]
> >> >> +static int fec_enet_set_pauseparam(struct net_device *ndev,
> >> >> + struct ethtool_pauseparam *pause)
> >> >> +{
> >> >> + struct fec_enet_private *fep = netdev_priv(ndev);
> >> >> +
> >> >> + if (pause->tx_pause != pause->rx_pause) {
> >> >> + netdev_info(ndev,
> >> >> + "hardware only support enable/disable both tx and rx");
> >> >> + return -EINVAL;
> >> >> + }
> >> >> +
> >> >> + fep->pause_flag = 0;
> >> >> +
> >> >> + /* tx pause must be same as rx pause */
> >> >> + fep->pause_flag |= pause->rx_pause ? FEC_PAUSE_FLAG_ENABLE : 0;
> >> >> + fep->pause_flag |= pause->autoneg ? FEC_PAUSE_FLAG_AUTONEG : 0;
> >> >> +
> >> >> + if (pause->rx_pause || pause->autoneg) {
> >> >> + fep->phy_dev->supported |= ADVERTISED_Pause;
> >> >> + fep->phy_dev->advertising |= ADVERTISED_Pause;
> >> >> + } else {
> >> >> + fep->phy_dev->supported &= ~ADVERTISED_Pause;
> >> >> + fep->phy_dev->advertising &= ~ADVERTISED_Pause;
> >> >> + }
> >> > [...]
> >> >
> >> > Why is this changing the supported flags, i.e. device capabilities? You
> >> > need to leave those flags alone and reject an attempt to enable pause
> >> > frames on a device that doesn't support them.
> >>
> >> I go through phylib, I have not found good place set ADVERTISED_Pause
> >> capabilities.
> >> genphy_config_init never check Pause capabilities.
> >
> > I agree that phylib can't initialise pause capabilities because those
> > depend on the MAC. But look at which function I'm quoting: this is the
> > ethtool operation, which shouldn't change capabilities.
>
> Where is good place do you think? in probe function?
You're already setting the supported flag in fec_enet_mii_probe(). I
assume (without great familiarity with phylib) that that's the right
place to do it.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2 5/5] clocksource: update and move armada-370-xp-timer documentation to timer directory
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
Timer driver for Armada 370 and Armada XP have gained local timers
support. So it needs new resources information regarding the IRQs
and the registers.
Also move the documentation in the new and more accurate directory
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../bindings/arm/armada-370-xp-timer.txt | 12 ------------
.../bindings/timer/marvell,armada-370-xp-timer.txt | 15 +++++++++++++++
2 files changed, 15 insertions(+), 12 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
deleted file mode 100644
index 6483011..0000000
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Marvell Armada 370 and Armada XP Global Timers
-----------------------------------------------
-
-Required properties:
-- compatible: Should be "marvell,armada-370-xp-timer"
-- interrupts: Should contain the list of Global Timer interrupts
-- reg: Should contain the base address of the Global Timer registers
-- clocks: clock driving the timer hardware
-
-Optional properties:
-- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
- Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
new file mode 100644
index 0000000..3638112
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
@@ -0,0 +1,15 @@
+Marvell Armada 370 and Armada XP Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,armada-370-xp-timer"
+- interrupts: Should contain the list of Global Timer interrupts and
+ then local timer interrupts
+- reg: Should contain location and length for timers register. First
+ pair for the Global Timer registers, second pair for the
+ local/private timers.
+- clocks: clock driving the timer hardware
+
+Optional properties:
+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
+ Mhz fixed mode (available on Armada XP and not on Armada 370)
--
1.7.9.5
^ permalink raw reply related
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