* [PATCH] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
From: Heiko Stübner @ 2012-10-02 12:43 UTC (permalink / raw)
To: linux-arm-kernel
Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
data) introduced separate device names for the different subtypes of the
spi controller but forgot to set these in the relevant machines.
To fix this introduce a s3c64xx_spi_setname function and populate all
Samsung arches with the correct names. The function resides in a new
header, as the s3c64xx-spi.h contains driver platform data and should
therefore at some later point move out of the Samsung include dir.
Tested on a s3c2416-based machine.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Cc: stable at vger.kernel.org
---
arch/arm/mach-exynos/common.c | 5 ++++
arch/arm/mach-s3c24xx/s3c2416.c | 2 +
arch/arm/mach-s3c24xx/s3c2443.c | 4 +++
arch/arm/mach-s5p64x0/common.c | 3 ++
arch/arm/mach-s5pc100/common.c | 3 ++
arch/arm/mach-s5pv210/common.c | 3 ++
arch/arm/plat-samsung/include/plat/spi-core.h | 30 +++++++++++++++++++++++++
7 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/include/plat/spi-core.h
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 4eb39cd..3e02ae6 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -47,6 +47,7 @@
#include <plat/fimc-core.h>
#include <plat/iic-core.h>
#include <plat/tv-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include "common.h"
@@ -346,6 +347,8 @@ static void __init exynos4_map_io(void)
s5p_fb_setname(0, "exynos4-fb");
s5p_hdmi_setname("exynos4-hdmi");
+
+ s3c64xx_spi_setname("exynos4210-spi");
}
static void __init exynos5_map_io(void)
@@ -366,6 +369,8 @@ static void __init exynos5_map_io(void)
s3c_i2c0_setname("s3c2440-i2c");
s3c_i2c1_setname("s3c2440-i2c");
s3c_i2c2_setname("s3c2440-i2c");
+
+ s3c64xx_spi_setname("exynos4210-spi");
}
static void __init exynos4_init_clocks(int xtal)
diff --git a/arch/arm/mach-s3c24xx/s3c2416.c b/arch/arm/mach-s3c24xx/s3c2416.c
index 20507c7..a24960c 100644
--- a/arch/arm/mach-s3c24xx/s3c2416.c
+++ b/arch/arm/mach-s3c24xx/s3c2416.c
@@ -61,6 +61,7 @@
#include <plat/nand-core.h>
#include <plat/adc-core.h>
#include <plat/rtc-core.h>
+#include <plat/spi-core.h>
static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -147,6 +148,7 @@ void __init s3c2416_map_io(void)
/* initialize device information early */
s3c2416_default_sdhci0();
s3c2416_default_sdhci1();
+ s3c64xx_spi_setname("s3c2443-spi");
iotable_init(s3c2416_iodesc, ARRAY_SIZE(s3c2416_iodesc));
}
diff --git a/arch/arm/mach-s3c24xx/s3c2443.c b/arch/arm/mach-s3c24xx/s3c2443.c
index ab648ad..165b6a6 100644
--- a/arch/arm/mach-s3c24xx/s3c2443.c
+++ b/arch/arm/mach-s3c24xx/s3c2443.c
@@ -43,6 +43,7 @@
#include <plat/nand-core.h>
#include <plat/adc-core.h>
#include <plat/rtc-core.h>
+#include <plat/spi-core.h>
static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -100,6 +101,9 @@ void __init s3c2443_map_io(void)
s3c24xx_gpiocfg_default.set_pull = s3c2443_gpio_setpull;
s3c24xx_gpiocfg_default.get_pull = s3c2443_gpio_getpull;
+ /* initialize device information early */
+ s3c64xx_spi_setname("s3c2443-spi");
+
iotable_init(s3c2443_iodesc, ARRAY_SIZE(s3c2443_iodesc));
}
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index 6e6a0a9..111e404 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -44,6 +44,7 @@
#include <plat/sdhci.h>
#include <plat/adc-core.h>
#include <plat/fb-core.h>
+#include <plat/spi-core.h>
#include <plat/gpio-cfg.h>
#include <plat/regs-irqtype.h>
#include <plat/regs-serial.h>
@@ -179,6 +180,7 @@ void __init s5p6440_map_io(void)
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
s3c_fb_setname("s5p64x0-fb");
+ s3c64xx_spi_setname("s5p64x0-spi");
s5p64x0_default_sdhci0();
s5p64x0_default_sdhci1();
@@ -193,6 +195,7 @@ void __init s5p6450_map_io(void)
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
s3c_fb_setname("s5p64x0-fb");
+ s3c64xx_spi_setname("s5p64x0-spi");
s5p64x0_default_sdhci0();
s5p64x0_default_sdhci1();
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index 6219086..cc6e561 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -45,6 +45,7 @@
#include <plat/fb-core.h>
#include <plat/iic-core.h>
#include <plat/onenand-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include <plat/watchdog-reset.h>
@@ -165,6 +166,8 @@ void __init s5pc100_map_io(void)
s3c_onenand_setname("s5pc100-onenand");
s3c_fb_setname("s5pc100-fb");
s3c_cfcon_setname("s5pc100-pata");
+
+ s3c64xx_spi_setname("s5pc100-spi");
}
void __init s5pc100_init_clocks(int xtal)
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 4c9e902..a0c50ef 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -43,6 +43,7 @@
#include <plat/iic-core.h>
#include <plat/keypad-core.h>
#include <plat/tv-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include "common.h"
@@ -196,6 +197,8 @@ void __init s5pv210_map_io(void)
/* setup TV devices */
s5p_hdmi_setname("s5pv210-hdmi");
+
+ s3c64xx_spi_setname("s5pv210-spi");
}
void __init s5pv210_init_clocks(int xtal)
diff --git a/arch/arm/plat-samsung/include/plat/spi-core.h b/arch/arm/plat-samsung/include/plat/spi-core.h
new file mode 100644
index 0000000..0b9428a
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/spi-core.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2012 Heiko Stuebner <heiko@sntech.de>
+ *
+ * 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.
+ */
+
+#ifndef __PLAT_S3C_SPI_CORE_H
+#define __PLAT_S3C_SPI_CORE_H
+
+/* These functions are only for use with the core support code, such as
+ * the cpu specific initialisation code
+ */
+
+/* re-define device name depending on support. */
+static inline void s3c64xx_spi_setname(char *name)
+{
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+ s3c64xx_device_spi0.name = name;
+#endif
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+ s3c64xx_device_spi1.name = name;
+#endif
+#ifdef CONFIG_S3C64XX_DEV_SPI2
+ s3c64xx_device_spi2.name = name;
+#endif
+}
+
+#endif /* __PLAT_S3C_SPI_CORE_H */
--
1.7.2.3
^ permalink raw reply related
* [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
From: Felipe Balbi @ 2012-10-02 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002123856.GX4360@opensource.wolfsonmicro.com>
Hi,
coming late to the discussion, so bear with me
On Tue, Oct 02, 2012 at 01:38:56PM +0100, Mark Brown wrote:
> > This means mfd framework does not have an API to create a device from
> > dt data or so do I think since of_platform_populate() is used. Thats
> > why I suggested the idea of extending mfd_add_devices() (or adding a
> > new API in mfd framework) to create child devices from dt data so that
> > we'll have API's in mfd framework to both create and delete a device.
>
> The trouble that always exists with representing MFD children in DT is
> that unless you've got a usefully reusable IP block which is clearly
> separate from the chip integration you end up essentially just dumping
> the Linux data structures into DT which often doesn't leave you with
> something which describes the hardware.
do you mean to say that children creation should be left into the driver
(outside dt) ? That should be doable, indeed.
BTW, OTOH writing all children into the DT actually describes the HW,
no ? And depending on the device I feel it'd be better to write that
data to DT. Think of twlxxxx (TI's PMICs), we might have completely
unrelated drivers using one of TWL's GPIO lines as an interrupt source.
If that particular children isn't listed in DT, it can't be used as an
interrupt-parent, right ?
--
balbi
-------------- 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/20121002/a5cf6283/attachment.sig>
^ permalink raw reply
* [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
From: Mark Brown @ 2012-10-02 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAe_U6K6nAjsZUOk2rBFweWHtJmcLF7EJDpu9O6FXrq3tzv3yg@mail.gmail.com>
On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote:
> On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown
> > Why would that be helpful? Most platforms don't support DT at all, and
> I'm not sure how to put it correctly. All I'm trying to tell is mfd is
> a framework that exposes a set of API's to create and remove a device
> among others. If a mfd child device is not created using mfd API,
> it'll be unfair to expect that child be removed properly using mfd
> API. Like in this patch, the device is created using
> of_platform_populate (not a mfd API) but is removed using
> mfd_remove_devices (mfd API) [which should result in an abort].
That doesn't sound terribly clever, no, though it's not immediately
clear to me if the non-clever bit is using mfd_remove_devices() or
of_platform_populate().
> This means mfd framework does not have an API to create a device from
> dt data or so do I think since of_platform_populate() is used. Thats
> why I suggested the idea of extending mfd_add_devices() (or adding a
> new API in mfd framework) to create child devices from dt data so that
> we'll have API's in mfd framework to both create and delete a device.
The trouble that always exists with representing MFD children in DT is
that unless you've got a usefully reusable IP block which is clearly
separate from the chip integration you end up essentially just dumping
the Linux data structures into DT which often doesn't leave you with
something which describes the hardware.
^ permalink raw reply
* [PATCH] arm: include linux/sched.h in syscall.h
From: Will Deacon @ 2012-10-02 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5069F8A0.5020801@mentor.com>
Hi Wade,
On Mon, Oct 01, 2012 at 09:10:08PM +0100, Wade Farnsworth wrote:
> task_thread_info() is defined in linux/sched.h. Explicitly include this
> file in arch/arm/include/asm/syscall.h. This fixes an lttng-modules compile error.
Can you be more specific about the error? From your description, it sounds
like it should be fixed in lttng rather than here.
Cheers,
Will
> Signed-off-by: Wade Farnsworth <wade_farnsworth@mentor.com>
> ---
> arch/arm/include/asm/syscall.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
> index c334a23..fce38a6 100644
> --- a/arch/arm/include/asm/syscall.h
> +++ b/arch/arm/include/asm/syscall.h
> @@ -8,6 +8,7 @@
> #define _ASM_ARM_SYSCALL_H
>
> #include <linux/err.h>
> +#include <linux/sched.h>
>
> extern const unsigned long sys_call_table[];
>
> --
> 1.7.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 08/10] ARM: ux500: Stop calling the UIB init function when using Device Tree
From: Lee Jones @ 2012-10-02 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaM1SxcrAn086W+b-oC+k6w=SEhxq0CGqrA_4iXmgfWYA@mail.gmail.com>
On Tue, 02 Oct 2012, Linus Walleij wrote:
> On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > As there will be a Device Tree created for the UIBs, there is no
> > need to call the UIB initiation functions. Each device will be
> > detailed and registered from the Device Tree instead.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by, but...
>
> > - .init_late = ux500_init_late,
> > + .init_late = NULL,
>
> Why even define it?
More to show that we're _intentionally_ not using it.
I'm happy to remove if it offends you? :)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
From: Vinod Koul @ 2012-10-02 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001163955.GO5641@beef>
On Mon, 2012-10-01 at 12:39 -0400, Matt Porter wrote:
> Anything you can show at this point? ;) I'd be happy to drop the
> half-hack
> for a real API. If not, I'm going to carry that to v2 atm.
This is what I had done sometime back. Feel free to update....
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..94ae006 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -86,11 +86,11 @@ enum dma_transaction_type {
* @DMA_DEV_TO_DEV: Slave mode & From Device to Device
*/
enum dma_transfer_direction {
- DMA_MEM_TO_MEM,
- DMA_MEM_TO_DEV,
- DMA_DEV_TO_MEM,
- DMA_DEV_TO_DEV,
- DMA_TRANS_NONE,
+ DMA_MEM_TO_MEM = 0x01,
+ DMA_MEM_TO_DEV = 0x02,
+ DMA_DEV_TO_MEM = 0x04,
+ DMA_DEV_TO_DEV = 0x08,
+ DMA_TRANS_NONE = 0x10,
};
/**
@@ -371,6 +371,41 @@ struct dma_slave_config {
unsigned int slave_id;
};
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY = 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ = 0x0008,
+ DMAENGINE_PQ_VAL = 0x0010,
+ DMAENGINE_MEMSET = 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC = 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG = 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @widths: channel widths supported
+ * @dirn: channel directions supported
+ * @bursts: bitmask of burst lengths supported
+ * @mux: configurable slave id or hard wired
+ * -1 for hard wired, otherwise valid positive slave id (including zero)
+ */
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ enum dma_slave_buswidth widths;
+ enum dma_transfer_direction dirn;
+ unsigned int dma_bursts;
+ int mux;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(&chan->dev->device);
@@ -534,6 +569,7 @@ struct dma_tx_state {
* struct with auxiliary transfer status information, otherwise the call
* will just return a simple status code
* @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the capablities of channel
*/
struct dma_device {
@@ -602,6 +638,9 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+
+ struct dmaengine_chan_caps *(*device_channel_caps)(
+ struct dma_chan *chan);
};
static inline int dmaengine_device_control(struct dma_chan *chan,
--
~Vinod
^ permalink raw reply related
* [PATCH 11/12] pinctrl: samsung: use __devinit section for init code
From: Arnd Bergmann @ 2012-10-02 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZv2b8M2Y4BJpqOX72prLHf4aACbmYk=imevX7h-X65QQ@mail.gmail.com>
On Monday 01 October 2012, Linus Walleij wrote:
> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > The samsung pinctrl driver has a probe function that is
> > __devinit and that calls a lot of other functions that are
> > marked __init, which kbuild complains about.
> >
> > Marking everything __devinit means that the code does not
> > discarded when CONFIG_HOTPLUG is set, which is a little
> > more wasteful, but also more consistent
> >
> > Without this patch, building exynos_defconfig results in:
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> I think the Samsing pinctrl driver has landed into next from some
> branch in ARM SoC so you probably know better than me
> where this thing should be merged...
>
Sorry, I was too late for this one. Can you pick it up now that the
driver is merged?
Arnd
^ permalink raw reply
* [PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table
From: Linus Walleij @ 2012-10-02 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348841814-13645-1-git-send-email-ulf.hansson@stericsson.com>
On Fri, Sep 28, 2012 at 4:16 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Since the cpufreq table is dependant on the prmcu fw, it make sense to
> keep the table there. Moreover since the cpufreq is already a mfd child
> device added by the prcmu this make even more logic.
Better there than elsewhere.
> The next step after these patches will be to implement an "arm_clk" to be
> used from cpufreq to update the opp instead of using the prcmu opp API directly.
> This will then remove the last hard dependency to the prcmu API from cpufreq.
Sounds like a plan.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Is this going to be merged through the cpufreq tree or the MFD tree?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 00/10] Platform data clean-up and UIB device enablement
From: Arnd Bergmann @ 2012-10-02 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349165603-24401-1-git-send-email-lee.jones@linaro.org>
On Tuesday 02 October 2012, Lee Jones wrote:
> In this patch-set we move all Device Tree start-up code from the u8500
> board file and into the more persistent db8500 cpu file. This will aid
> future endeavours to remove platform code completely from Mainline. We
> also enable some of the devices found on the STUIB (User Interface
> board), which attaches to some of ST-Ericsson's reference platforms.
Looks all good to me.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v2 RESEND 2/2] ARM: local timers: add timer support using IO mapped register
From: Dave Martin @ 2012-10-02 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120928171549.GA29991@e102568-lin.cambridge.arm.com>
On Fri, Sep 28, 2012 at 06:15:53PM +0100, Lorenzo Pieralisi wrote:
> On Fri, Sep 28, 2012 at 04:57:46PM +0100, Dave Martin wrote:
> > [ Note: please aim to CC devicetree-discuss at lists.ozlabs.org with any
> > patches or bindings relevant to device tree. ]
> >
> > [ Lorenzo, there's a question for you further down this mail. ]
>
> [...]
>
> > > > > + If using the memory mapped interface, list the interrupts for each core,
> > > > > + starting with core 0.
> > >
> > > I take it that core 0 means physical cpu 0 (i.e. MPIDR.Aff{2,1,0} == 0)?
> >
> > Lorenzo, should we have a standard way of referring to CPUs and topology
> > nodes documented as part of the topology bindings? We certainly need
> > rules of some kind, since when the topology is non-trivial there is no
> > well-defined "first" CPU, nor any single correct order in which to list
> > CPUs.
>
> I think, and that's just my opinion, that whatever solution we go for to
> describe the topology must contain the information needed by all kernel
> subsystems to retrieve HW information. I do not think we should document
> how devices connect to CPU(s)/Cluster(s) in the topology bindings per-se,
> since those are properties that belong to device nodes.
Well, I guess the other approach is to establish a firm precedent, which
means that we need to watch carefully for people proposing new bindings
which refer to the topology in inconsistent ways.
>
> There must be a common way for all devices to link to the topology, though.
>
> The topology must be descriptive enough to cater for all required cases
> and that's what Mark with PMU and all of us are trying to come up with, a solid
> way to represent with DT the topology of current and future ARM systems.
>
> First idea I implemented and related LAK posting:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
>
> Are "cluster" nodes really needed or "cpu" nodes are enough ? I do not
> know, let's get this discussion started, that's all I need.
One thing which now occurs to me on this point it that if we want to describe
the CCI properly in the DT (yes) then we need a way to describe the mapping
between clusters and CCI slave ports. Currently that knowledge just has to
be a hard-coded hack somewhere: it's not probeable at all.
I'm not sure how we do that, or how we describe the cache topology, without
the clusters being explicit in the DT
...unless you already have ideas ?
Cheers
---Dave
> But definitely declaring IRQs in physical CPU id order (and mind, as you say,
> physical CPU ids, ie MPIDR, can be sparsely populated) and initializing them
> *thinking* the order is the logical one is plainly broken.
>
> > The topology may also be sparsely populated (e.g.,
> > Aff[2,1,0] in { (0,0,0), (0,0,1), (0,1,0), (0,1,1), (0,1,2), (0,1,3) })
> >
> > It would be bad if different driver bindings end up solving this in
> > different ways (even non-broken ways)
>
> Yes, I agree and code that relies on any temporary work-around to tackle
> this problem should not be merged before we set in stone proper topology
> bindings.
>
> Lorenzo
>
^ permalink raw reply
* [PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table
From: Jonas Aaberg @ 2012-10-02 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348841814-13645-1-git-send-email-ulf.hansson@stericsson.com>
All patches look good.
Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>
On 09/28/2012 04:16 PM, Ulf HANSSON wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Since the cpufreq table is dependant on the prmcu fw, it make sense to
> keep the table there. Moreover since the cpufreq is already a mfd child
> device added by the prcmu this make even more logic.
>
> The next step after these patches will be to implement an "arm_clk" to be
> used from cpufreq to update the opp instead of using the prcmu opp API directly.
> This will then remove the last hard dependency to the prcmu API from cpufreq.
>
> Ulf Hansson (4):
> ARM: ux500: Remove cpufreq platform device
> mfd: db8500: Provide cpufreq table as platform data
> cpufreq: db8500: Register as a platform driver
> cpufreq: db8500: Fetch cpufreq table from platform data
>
> arch/arm/mach-ux500/cpu-db8500.c | 6 ---
> drivers/cpufreq/db8500-cpufreq.c | 87 +++++++++++++++++++-------------------
> drivers/mfd/db8500-prcmu.c | 22 ++++++++++
> 3 files changed, 66 insertions(+), 49 deletions(-)
>
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Sekhar Nori @ 2012-10-02 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPcSpELdAK6=O8HG9FJXG_t88eymZO1f3wxzFqmR-faUn4jx4g@mail.gmail.com>
On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>> Hi Matt,
>>>
>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>>> This creates a genalloc pool and a hook for the platform code
>>>> to provide the struct gen_pool * in platform data.
>>>>
>>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>>
>>> I am not sure if any of the DaVinci devices have a need to allocate from
>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>>> if there is much point in trying to allocate from there.
>>>
>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>>> allocation on DA850 makes sense for your case? If yes, can you repost
>>> with Ben's patch included in your series instead of this patch? I would
>>> prefer that over creating a new pool for shared RAM.
>>
>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>> pool mostly was so I didn't have to touch the PM code at all. That can
>> continue using the private SRAM API with the ARM RAM as it is now. The
>> idea here was to allow that to be separate since no other bus masters
>> can access the ARM RAM anyway and do something that didn't require
>> regression testing PM. Also, I figured there's really no reason to use
>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>> and working fine for that use case.
>> [...]
>
> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> you said, Sekhar) in any fashion is preferable to moving suspend
> support into shared RAM. There is more of it (128K on L138) but also
> more pressure on allocations there since there are more clients.
There is where I would like to see more information on who the potential
clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
there should be more than enough for PM, Audio and PRU. I haven't
checked the PM code size lately but it should be fairly small and I can
check the actual number if that helps. So, adding a new pool just to
save on those bytes doesn't sound like helping a lot.
> I appreciate that you are trying to preserve prior efforts in
> attempted merging of SRAM support -- thank you for that; however, that
> patch [1] was just an import of Subashish Ghosh's patch [2] -- I
> chose _that_ implementation option then mainly because I imagined it
> would be the least risky to get accepted upstream and not because of
> any particular technical merits.
Its not a question of prior effort since Matt has already put in the
effort too. I am yet unconvinced that we need to add support to manage
two blocks of SoC internal RAM on DA850 in the kernel today. That's all.
Thanks,
Sekhar
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Sekhar Nori @ 2012-10-02 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506AC303.9080906@gmail.com>
On 10/2/2012 4:03 PM, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>
>>> I also agree that ifdef is not a good solution.
>>> It is better to have this information passed as device_data and via DT it can
>>> be decided based on the compatible property for the device.
>>
>> That's not really the problem here - the problem is that the APIs used
>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>> or other platforms. The SRAM code needs to move to a standard API.
>
> What about following Matt Porter's idea and ignore the SRAM code
> entirely and port the entire PCM code to generic dmaengine code first?
> The EDMA driver needs to learn support for cyclic DMA for that, and I
> might give that a try in near future.
>
> Later on, the SRAM ping-pong code can get added back using genalloc
> functions, as Sekhar proposed. That needs to be done by someone who has
> access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 10/10] ARM: ux500: Stop informing the regulator subsystem that we have full constraints
From: Linus Walleij @ 2012-10-02 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349165603-24401-11-git-send-email-lee.jones@linaro.org>
On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The regulator_has_full_constraints() call is not required if we
> are booting with Device Tree as it's assumed in this case.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCH 09/10] ARM: ux500: Add all bu21013 touch screen components to supported Device Trees
From: Linus Walleij @ 2012-10-02 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349165603-24401-10-git-send-email-lee.jones@linaro.org>
On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
> It is possible to connect a BU21013 Touch Screen to all version
> of the HREF which support the ST-UIB. This patch applies all the
> necessary settings to the pre-v60 and v60+ HREF Device Trees.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 08/10] ARM: ux500: Stop calling the UIB init function when using Device Tree
From: Linus Walleij @ 2012-10-02 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349165603-24401-9-git-send-email-lee.jones@linaro.org>
On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
> As there will be a Device Tree created for the UIBs, there is no
> need to call the UIB initiation functions. Each device will be
> detailed and registered from the Device Tree instead.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by, but...
> - .init_late = ux500_init_late,
> + .init_late = NULL,
Why even define it?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 07/10] ARM: ux500: Create a new Device Tree include file for boards supporting STUIBs
From: Linus Walleij @ 2012-10-02 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349165603-24401-8-git-send-email-lee.jones@linaro.org>
On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
> This is a skeleton creation which will be populated with the devices
> found on one of ST-Ericsson's (UIB) User Interface Board.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-02 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002093753.GU4360@opensource.wolfsonmicro.com>
On 02.10.2012 11:37, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>
>> I also agree that ifdef is not a good solution.
>> It is better to have this information passed as device_data and via DT it can
>> be decided based on the compatible property for the device.
>
> That's not really the problem here - the problem is that the APIs used
> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
Daniel
^ permalink raw reply
* [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
From: Marc Zyngier @ 2012-10-02 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002092412.GB8847@mudshark.cambridge.arm.com>
On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon <will.deacon@arm.com>
wrote:
> On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Add the init code for the hypervisor, the virtual machine, and
>> the virtual CPUs.
>>
>> An interrupt handler is also wired to allow the VGIC maintenance
>> interrupts, used to deal with level triggered interrupts and LR
>> underflows.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>> ---
>
> [...]
>
>> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
>> index b52d4c2..fc2a138 100644
>> --- a/arch/arm/kvm/vgic.c
>> +++ b/arch/arm/kvm/vgic.c
>> @@ -20,7 +20,14 @@
>> #include <linux/kvm_host.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +
>> #include <asm/kvm_emulate.h>
>> +#include <asm/hardware/gic.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>>
>> /*
>> * How the whole thing works (courtesy of Christoffer Dall):
>> @@ -61,6 +68,13 @@
>> /* Temporary hacks, need to be provided by userspace emulation */
>> #define VGIC_DIST_BASE 0x2c001000
>> #define VGIC_DIST_SIZE 0x1000
>> +#define VGIC_CPU_BASE 0x2c002000
>> +#define VGIC_CPU_SIZE 0x2000
>
> We really don't want the physical memory map for the guest hardwired in
the
> kernel. Please find a way to parameterise this from userspace.
Yes, this is a known problem. KVM doesn't offer a standard way of passing
the address of an interrupt controller (none of the other architectures
have it memory mapped).
We probably need a separate ioctl for that...
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-02 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001183543.GC22342@obsidianresearch.com>
On Mon, Oct 01, 2012 at 12:35:43PM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 01, 2012 at 06:56:47PM +0100, Dave Martin wrote:
>
> > > > If the kernel is intended to be loadable at a physical address which is
> > > > not statically known, no ELF loader that does not ignore the ELF
> > > > phdr
> > >
> > > In this case you can't really use a standard ELF loader to load the
> > > kernel so, LOAD_OFFSET = 0 is fine. My case is using an ELF loader,
> > > and I have set options for a static physical load address.
> >
> > Generally, people should try to be compatible with the single kernel
> > image effort unless there's a really compelling reason not to.
>
> Well, all the embedded kernels we use are always custom built and
> minimized for the target. So as long as there are options to minimize
> the kernel size/increase performance by taking out the relocation
> stuff, we are going to use them.
>
> All our boards on PPC and ARM use DT kernels now, and we try to flow
> back all the generic stuff as best we can. As someone that makes
> custom boards, I really like DT, it makes things much easier :)
>
> > Wouldn't your firmware be incapable of loading a multiplatform kernel?
>
> Well, no, it boots ELFs, so it can boot anything, with any memory
> layout. A 2nd stage loader would be required to boot standard kernels,
> that loader would be an ELF with 1 section for the 2nd stage, 1
> section for the zImage and 1 section for the initrd, with proper load
> headers.
Don't you already have to treat Linux as a special case though? How
do you know where to load ATAGs, DT and/or initramfs, and how to
initalise the registers? None of that is part of any ELF specification,
and would be inappropriate if you boot any non-linux images.
> Creating such a system is a lot of annoyance, so we never have - it is
> *so much* easier to just boot vmlinux ELF directly.
>
> > Well, that was a bit of a pedantic point I admit, but there are
> > conflicting definitions of what "virtual address" really means in these
> > situations. The original SYSV ABI spec explicitly specifies that
> > e_entry is a virtual address, but is also rather vague about how the
> > paddr fields should be interpreted.
>
> Granted the spec is vauge, but convention for loaders seems to be that
> it is a physical address these days.
>
> It could be a virtual address, and the loader could translate it by
> looking at the phdrs, but I don't see any other arches doing that?
You would just give .head.text a virtual address matching its load
address. But as you say, no other arches bother with this, and it's
not obviously worthwhile.
> > All that AT(ADDR(blah) - LOAD_OFFSET) stuff is cumbersome, but if it's
> > at least consistent with other architectures then it may not such a
> > disaster. It's not universal though: less than 50% of the arches in
> > the kernel currently seem to use this.
>
> I agree it is not nice, but I once did try to make PHDRS work as you
> described, but was never successful. IIRC there were serious linker
> bugs) As you note the AT method is consistent with other arches, and
> the generic vmlinux.lds.h
A quick experiment shows that
PHDRS {
kernel PT_LOAD AT(PHYS_OFFSET + LOAD_OFFSET);
}
/* ... */
SECTIONS {
.head.text {
/* ... */
} :kernel
/* ... */
}
can produce a sensible-looking vmlinux at least with my version of the
tools.
As you observe, GNU ld behaviour in this area tends to be rather patchily
specified, buggy or both. That does argue in favour of reusing the
same techniques already used for other arches, though.
A question does occur to me: do your changes work with XIP_KERNEL?
I'm not very familiar with XIP_KERNEL myself, so I'm currently not
clear on whether there's an impact here.
Beyond this, I think the approach doesn't look unreasonable.
> > > Yes, if you use more loader stages then the load headers are ignored.
> > > Our boot loaders on our boards boot straight ELF vmlinux.gz so they
> > > need correct load headers.
>
> > If your image is compressed anyway though, why are you not using zImage?
>
> We store the kernel in a CRAMFS, the loader pulls it out and
> decompresses it, processes the ELF sections 'on the fly' and jumps to
> it. Using zImage would result in double-decompression, and reallly has
> no benefits to us.
You store vmlinux.gz in a cramfs? Is that a typo, or have you already
compressed the kernel twice?
Cheers
---Dave
^ permalink raw reply
* How many cores does the ARM branch support?
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-02 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002043106.GD21233@work1>
On 06:31 Tue 02 Oct , Michelle Konzack wrote:
> Hello OverGeeks and *,
>
> I have gotten a new gadget which run only with 700MHz but has 32 cores.
> Support 16 GE Interfaces a 50 Gbit universal interface and 4 PCIe ports,
> SATA HDD and much more...
>
> ...and yes, this ARM microcontroller is a telecommunications controller.
>
> However, I have the Evaluation Kit and a PCIe graphiccard and now
> installed Debian ARMEL. Unfortunately I get only 2 cores working...
>
> What must I do to get the other 30 cores?
32 cores on arm? which soc is it
usualy the nr_cpus is set to 2 check it
>
> (without them, my Marvel Discovery MV78200 us 5 times faster)
>
> And is it possibel, to get 100 cores running?
> (this is the bigger version of the microcontroller I have)
>
> I like to transform the 32 and 100 core versions into PanelPCs with the
> ultimate super power... :-D ...even it will be only a gadget for me!
Best Regards,
J.
>
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
>
> --
> ##################### Debian GNU/Linux Consultant ######################
> Development of Intranet and Embedded Systems with Debian GNU/Linux
> Internet Service Provider, Cloud Computing
> <http://www.itsystems.tamay-dogan.net/>
>
> itsystems at tdnet Jabber linux4michelle at jabber.ccc.de
> Owner Michelle Konzack
>
> Gewerbe Strasse 3 Tel office: +49-176-86004575
> 77694 Kehl Tel mobil: +49-177-9351947
> Germany Tel mobil: +33-6-61925193 (France)
>
> USt-ID: DE 278 049 239
>
> Linux-User #280138 with the Linux Counter, http://counter.li.org/
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Sekhar Nori @ 2012-10-02 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001123242.GJ5641@beef>
On 10/1/2012 6:02 PM, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>> This creates a genalloc pool and a hook for the platform code
>>> to provide the struct gen_pool * in platform data.
>>>
>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>
>> I am not sure if any of the DaVinci devices have a need to allocate from
>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>> if there is much point in trying to allocate from there.
>>
>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>> allocation on DA850 makes sense for your case? If yes, can you repost
>> with Ben's patch included in your series instead of this patch? I would
>> prefer that over creating a new pool for shared RAM.
>
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The
But you dont have to touch the PM code. PM code can continue using SRAM
API. I have verified in the past that PM can work using shared RAM.
> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.
I see no reason why PM would break with shared RAM. I have not even seen
reports of shared RAM being short of size so we need to save space by
having PM code in ARM RAM. I can test the changes before the code is
committed and it will get tested in linux-next as well.
> The other thing is that Ben's patch needs to be rewritten to at least
> have the hook I added so we can provide the gen_pool in platform data.
> If you prefer this path still, I can add the needed hook on top of his
> original patch. Ultimately, I only *need* genalloc support for the
> shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> happy with any way to get at it.
Right, I prefer just adding the hook so that genalloc can be used along
with SRAM API.
> Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> remove the private SRAM API usage from the davinci ASoC driver too.
Audio can use the shared RAM too. And once all users of the SRAM API are
gone, only the hook to help pass the gen_pool as platform data needs to
remain.
Thanks,
Sekhar
^ permalink raw reply
* OMAP baseline test results for v3.6-rc7
From: Igor Grinberg @ 2012-10-02 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210012318460.26402@utopia.booyaka.com>
On 10/02/12 01:28, Paul Walmsley wrote:
> On Thu, 27 Sep 2012, Igor Grinberg wrote:
>
>> Have you tried the nohlt boot parameter?
>> It looks like the wfi is killing those SoCs once you use EMAC.
>
> Just tried with nohlt. Didn't help on CM-T3517 with either NFS or MMC
> root, nor with the 3517EVM with NFS root. But I was able to get the
> 3517EVM booting to userspace with MMC root. Looks like the CM-T3517 board
> file is missing the MMC setup code, so would guess that adding that back
> in would help.
It never had the MMC in mainline...
I have some patches for that, based on v3.5,
but it should not be a problem to rebase those on a more recent git.
I will send them in a week or so, and if Tony will agree to merge them,
we will have the MMC on CM-T3517 mainline.
--
Regards,
Igor.
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Mark Brown @ 2012-10-02 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506A9C65.5040309@ti.com>
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> I also agree that ifdef is not a good solution.
> It is better to have this information passed as device_data and via DT it can
> be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
^ permalink raw reply
* [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
From: Will Deacon @ 2012-10-02 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001091426.49503.94722.stgit@ubuntu>
On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> Add the init code for the hypervisor, the virtual machine, and
> the virtual CPUs.
>
> An interrupt handler is also wired to allow the VGIC maintenance
> interrupts, used to deal with level triggered interrupts and LR
> underflows.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
> ---
[...]
> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
> index b52d4c2..fc2a138 100644
> --- a/arch/arm/kvm/vgic.c
> +++ b/arch/arm/kvm/vgic.c
> @@ -20,7 +20,14 @@
> #include <linux/kvm_host.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +
> #include <asm/kvm_emulate.h>
> +#include <asm/hardware/gic.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
>
> /*
> * How the whole thing works (courtesy of Christoffer Dall):
> @@ -61,6 +68,13 @@
> /* Temporary hacks, need to be provided by userspace emulation */
> #define VGIC_DIST_BASE 0x2c001000
> #define VGIC_DIST_SIZE 0x1000
> +#define VGIC_CPU_BASE 0x2c002000
> +#define VGIC_CPU_SIZE 0x2000
We really don't want the physical memory map for the guest hardwired in the
kernel. Please find a way to parameterise this from userspace.
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox