* [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 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 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
* [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
* [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
* [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
* [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/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
* [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
* [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: 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
* [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] 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 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
* [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 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
* [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: 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: 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
* [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/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
* [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 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 3/4 v11] arm highbank: add support for pl320 IPC
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>
The pl320 IPC allows for interprocessor communication between the highbank A9
and the EnergyCore Management Engine. The pl320 implements a straightforward
mailbox protocol.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
---
Changes from v10
Removed deependency on Omar Ramirez Luna's mailbox code. Now the
patch creates the directory itself.
Changes from v9
Used to be the 4th patch in the series.
Changes from v6, v7, v8
None.
Changes from v5
Renamed ipc_transmit() to pl320_ipc_transmit().
Properly exported pl320_ipc_{un}register_notifier().
Changes from v4
Moved pl320-ipc.c from arch/arm/mach-highbank to drivers/mailbox.
Moved header information to include/linux/mailbox.h.
Added Kconfig options to reflect the new code location.
Change drivers/mailbox/Makefile to build the omap mailboxes only
when they are configured.
Removed ipc_call_fast and renamed ipc_call_slow ipc_transmit.
Changes from v3, v2
None.
Changes from v1
Removed erroneous changes for cpufreq Kconfig.
arch/arm/mach-highbank/Kconfig | 2 +
drivers/mailbox/Kconfig | 18 ++++
drivers/mailbox/Makefile | 1 +
drivers/mailbox/pl320-ipc.c | 199 +++++++++++++++++++++++++++++++++++++++++
include/linux/mailbox.h | 18 ++++
5 files changed, 238 insertions(+)
create mode 100644 drivers/mailbox/Kconfig
create mode 100644 drivers/mailbox/Makefile
create mode 100644 drivers/mailbox/pl320-ipc.c
create mode 100644 include/linux/mailbox.h
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 551c97e..2388085 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -11,5 +11,7 @@ config ARCH_HIGHBANK
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
select HAVE_SMP
+ select MAILBOX
+ select PL320_MBOX
select SPARSE_IRQ
select USE_OF
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
new file mode 100644
index 0000000..9489554
--- /dev/null
+++ b/drivers/mailbox/Kconfig
@@ -0,0 +1,18 @@
+menuconfig MAILBOX
+ bool "Mailbox Hardware Support"
+ help
+ Mailbox is a framework to control hardware communication between
+ on-chip processors through queued messages and interrupt driven
+ signals. Say Y if your platform supports hardware mailboxes.
+
+if MAILBOX
+config PL320_MBOX
+ bool "ARM PL320 Mailbox"
+ help
+ An implementation of the ARM PL320 Interprocessor Communication
+ Mailbox (IPCM), tailored for the Calxeda Highbank. It is used to
+ send short messages between Highbank's A9 cores and the EnergyCore
+ Management Engine, primarily for cpufreq. Say Y here if you want
+ to use the PL320 IPCM support.
+
+endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
new file mode 100644
index 0000000..543ad6a
--- /dev/null
+++ b/drivers/mailbox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
new file mode 100644
index 0000000..68c0d50
--- /dev/null
+++ b/drivers/mailbox/pl320-ipc.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright 2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/types.h>
+#include <linux/err.h>
+#include <linux/delay.h>
+#include <linux/export.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/spinlock.h>
+#include <linux/device.h>
+#include <linux/amba/bus.h>
+
+#include <linux/mailbox.h>
+
+#define IPCMxSOURCE(m) ((m) * 0x40)
+#define IPCMxDSET(m) (((m) * 0x40) + 0x004)
+#define IPCMxDCLEAR(m) (((m) * 0x40) + 0x008)
+#define IPCMxDSTATUS(m) (((m) * 0x40) + 0x00C)
+#define IPCMxMODE(m) (((m) * 0x40) + 0x010)
+#define IPCMxMSET(m) (((m) * 0x40) + 0x014)
+#define IPCMxMCLEAR(m) (((m) * 0x40) + 0x018)
+#define IPCMxMSTATUS(m) (((m) * 0x40) + 0x01C)
+#define IPCMxSEND(m) (((m) * 0x40) + 0x020)
+#define IPCMxDR(m, dr) (((m) * 0x40) + ((dr) * 4) + 0x024)
+
+#define IPCMMIS(irq) (((irq) * 8) + 0x800)
+#define IPCMRIS(irq) (((irq) * 8) + 0x804)
+
+#define MBOX_MASK(n) (1 << (n))
+#define IPC_TX_MBOX 1
+#define IPC_RX_MBOX 2
+
+#define CHAN_MASK(n) (1 << (n))
+#define A9_SOURCE 1
+#define M3_SOURCE 0
+
+static void __iomem *ipc_base;
+static int ipc_irq;
+static DEFINE_MUTEX(ipc_m1_lock);
+static DECLARE_COMPLETION(ipc_completion);
+static ATOMIC_NOTIFIER_HEAD(ipc_notifier);
+
+static inline void set_destination(int source, int mbox)
+{
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDSET(mbox));
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMSET(mbox));
+}
+
+static inline void clear_destination(int source, int mbox)
+{
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDCLEAR(mbox));
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMCLEAR(mbox));
+}
+
+static void __ipc_send(int mbox, u32 *data)
+{
+ int i;
+ for (i = 0; i < 7; i++)
+ __raw_writel(data[i], ipc_base + IPCMxDR(mbox, i));
+ __raw_writel(0x1, ipc_base + IPCMxSEND(mbox));
+}
+
+static u32 __ipc_rcv(int mbox, u32 *data)
+{
+ int i;
+ for (i = 0; i < 7; i++)
+ data[i] = __raw_readl(ipc_base + IPCMxDR(mbox, i));
+ return data[1];
+}
+
+/* blocking implmentation from the A9 side, not usuable in interrupts! */
+int pl320_ipc_transmit(u32 *data)
+{
+ int ret;
+
+ mutex_lock(&ipc_m1_lock);
+
+ init_completion(&ipc_completion);
+ __ipc_send(IPC_TX_MBOX, data);
+ ret = wait_for_completion_timeout(&ipc_completion,
+ msecs_to_jiffies(1000));
+ if (ret == 0) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ ret = __ipc_rcv(IPC_TX_MBOX, data);
+out:
+ mutex_unlock(&ipc_m1_lock);
+ return ret;
+}
+EXPORT_SYMBOL(pl320_ipc_transmit);
+
+irqreturn_t ipc_handler(int irq, void *dev)
+{
+ u32 irq_stat;
+ u32 data[7];
+
+ irq_stat = __raw_readl(ipc_base + IPCMMIS(1));
+ if (irq_stat & MBOX_MASK(IPC_TX_MBOX)) {
+ __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
+ complete(&ipc_completion);
+ }
+ if (irq_stat & MBOX_MASK(IPC_RX_MBOX)) {
+ __ipc_rcv(IPC_RX_MBOX, data);
+ atomic_notifier_call_chain(&ipc_notifier, data[0], data + 1);
+ __raw_writel(2, ipc_base + IPCMxSEND(IPC_RX_MBOX));
+ }
+
+ return IRQ_HANDLED;
+}
+
+int pl320_ipc_register_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&ipc_notifier, nb);
+}
+EXPORT_SYMBOL(pl320_ipc_register_notifier);
+
+int pl320_ipc_unregister_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(&ipc_notifier, nb);
+}
+EXPORT_SYMBOL(pl320_ipc_unregister_notifier);
+
+static int __init pl320_probe(struct amba_device *adev,
+ const struct amba_id *id)
+{
+ int ret;
+
+ ipc_base = ioremap(adev->res.start, resource_size(&adev->res));
+ if (ipc_base == NULL)
+ return -ENOMEM;
+
+ __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
+
+ ipc_irq = adev->irq[0];
+ ret = request_irq(ipc_irq, ipc_handler, 0, dev_name(&adev->dev), NULL);
+ if (ret < 0)
+ goto err;
+
+ /* Init slow mailbox */
+ __raw_writel(CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxSOURCE(IPC_TX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE),
+ ipc_base + IPCMxDSET(IPC_TX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE) | CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxMSET(IPC_TX_MBOX));
+
+ /* Init receive mailbox */
+ __raw_writel(CHAN_MASK(M3_SOURCE),
+ ipc_base + IPCMxSOURCE(IPC_RX_MBOX));
+ __raw_writel(CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxDSET(IPC_RX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE) | CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxMSET(IPC_RX_MBOX));
+
+ return 0;
+err:
+ iounmap(ipc_base);
+ return ret;
+}
+
+static struct amba_id pl320_ids[] = {
+ {
+ .id = 0x00041320,
+ .mask = 0x000fffff,
+ },
+ { 0, 0 },
+};
+
+static struct amba_driver pl320_driver = {
+ .drv = {
+ .name = "pl320",
+ },
+ .id_table = pl320_ids,
+ .probe = pl320_probe,
+};
+
+static int __init ipc_init(void)
+{
+ return amba_driver_register(&pl320_driver);
+}
+module_init(ipc_init);
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
new file mode 100644
index 0000000..911cb28
--- /dev/null
+++ b/include/linux/mailbox.h
@@ -0,0 +1,18 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+int pl320_ipc_transmit(u32 *data);
+int pl320_ipc_register_notifier(struct notifier_block *nb);
+int pl320_ipc_unregister_notifier(struct notifier_block *nb);
+
--
1.7.11.7
^ permalink raw reply related
* [PATCH 4/4] cpufreq, highbank: add support for highbank cpufreq
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>
Highbank processors depend on the external ECME to perform voltage
management based on a requested frequency. Communication between the
A9 cores and the ECME happens over the pl320 IPC channel.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
---
Changes from v10
Now finds a cpu node by searching under /cpus and looking for something
with an operating-points descriptor. This applies to both
highbank-cpufreq and cpufreq-cpu0.
Changes from v9
Added Mike Turquette's reviewed by.
Used to be the 6th patch in the series.
Changes from v8
Added Shawn Guo's reviewed by.
Removed some magic numbers.
Changed failure returns in clk_notify from NOTIFY_STOP to NOTIFY_BAD.
Changes from v7
Removed old attribution to cpufreq-cpu0.
Added some description in the documentation.
Made cpu_dev, cpu_clk into local variables.
Removed __devinit.
Removed some unneeded includes.
Added a brace to clarify some nested if logic.
Changes from v6
Removed devicetree bindings documentation.
Restructured driver to use clk notifications.
Core driver logic is now cpufreq-clk0.
Changes from v5
Changed ipc_transmit() to pl320_ipc_transmit().
Changes from v4
Removed erroneous changes to arch/arm/Kconfig.
Removed unnecessary changes to drivers/cpufreq/Kconfig.arm
Alphabetized additions to arch/arm/mach-highbank/Kconfig
Changed ipc call and header to match new ipc location in
drivers/mailbox.
Changes from v3
None.
Changes from v2
Changed transition latency binding in code to match documentation.
Changes from v1
Added highbank specific Kconfig changes.
arch/arm/boot/dts/highbank.dts | 10 ++++
arch/arm/mach-highbank/Kconfig | 2 +
drivers/cpufreq/Kconfig.arm | 15 +++++
drivers/cpufreq/Makefile | 3 +-
drivers/cpufreq/cpufreq-cpu0.c | 6 +-
drivers/cpufreq/highbank-cpufreq.c | 112 +++++++++++++++++++++++++++++++++++++
6 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 drivers/cpufreq/highbank-cpufreq.c
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index 5927a8d..6aad34a 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -37,6 +37,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
cpu at 901 {
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 2388085..44b12f9 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -1,5 +1,7 @@
config ARCH_HIGHBANK
bool "Calxeda ECX-1000/2000 (Highbank/Midway)" if ARCH_MULTI_V7
+ select ARCH_HAS_CPUFREQ
+ select ARCH_HAS_OPP
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_GIC
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index a0b3661..ffe55b8 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -83,3 +83,18 @@ config ARM_SPEAR_CPUFREQ
default y
help
This adds the CPUFreq driver support for SPEAr SOCs.
+
+config ARM_HIGHBANK_CPUFREQ
+ tristate "Calxeda Highbank-based"
+ depends on ARCH_HIGHBANK
+ select CPU_FREQ_TABLE
+ select GENERIC_CPUFREQ_CPU0
+ select PM_OPP
+ select REGULATOR
+
+ default m
+ help
+ This adds the CPUFreq driver for Calxeda Highbank SoC
+ based boards.
+
+ If in doubt, say N.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..31e6f19 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,8 +50,9 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
-obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
+obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
+obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
##################################################################################
# PowerPC platform drivers
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 52bf36d..90e9d73 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -179,7 +179,11 @@ static int cpu0_cpufreq_driver_init(void)
struct device_node *np;
int ret;
- np = of_find_node_by_path("/cpus/cpu at 0");
+ for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
+ if (of_get_property(np, "operating-points", NULL))
+ break;
+ }
+
if (!np) {
pr_err("failed to find cpu0 node\n");
return -ENOENT;
diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
new file mode 100644
index 0000000..a5bad89
--- /dev/null
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2012 Calxeda, Inc.
+ *
+ * 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.
+ *
+ * This driver provides the clk notifier callbacks that are used when
+ * the cpufreq-cpu0 driver changes to frequency to alert the highbank
+ * EnergyCore Management Engine (ECME) about the need to change
+ * voltage. The ECME interfaces with the actual voltage regulators.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/mailbox.h>
+
+#define HB_CPUFREQ_CHANGE_NOTE 0x80000001
+#define HB_CPUFREQ_IPC_LEN 7
+#define HB_CPUFREQ_VOLT_RETRIES 15
+
+static int hb_voltage_change(unsigned int freq)
+{
+ int i;
+ u32 msg[HB_CPUFREQ_IPC_LEN];
+
+ msg[0] = HB_CPUFREQ_CHANGE_NOTE;
+ msg[1] = freq / 1000000;
+ for (i = 2; i < HB_CPUFREQ_IPC_LEN; i++)
+ msg[i] = 0;
+
+ return pl320_ipc_transmit(msg);
+}
+
+static int hb_cpufreq_clk_notify(struct notifier_block *nb,
+ unsigned long action, void *hclk)
+{
+ struct clk_notifier_data *clk_data = hclk;
+ int i = 0;
+
+ if (action == PRE_RATE_CHANGE) {
+ if (clk_data->new_rate > clk_data->old_rate)
+ while (hb_voltage_change(clk_data->new_rate))
+ if (i++ > HB_CPUFREQ_VOLT_RETRIES)
+ return NOTIFY_BAD;
+ } else if (action == POST_RATE_CHANGE) {
+ if (clk_data->new_rate < clk_data->old_rate)
+ while (hb_voltage_change(clk_data->new_rate))
+ if (i++ > HB_CPUFREQ_VOLT_RETRIES)
+ return NOTIFY_BAD;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block hb_cpufreq_clk_nb = {
+ .notifier_call = hb_cpufreq_clk_notify,
+};
+
+static int hb_cpufreq_driver_init(void)
+{
+ struct device *cpu_dev;
+ struct clk *cpu_clk;
+ struct device_node *np;
+ int ret;
+
+ for_each_child_of_node(of_find_node_by_path("/cpus"), np)
+ if (of_get_property(np, "operating-points", NULL))
+ break;
+
+ if (!np) {
+ pr_err("failed to find highbank cpufreq node\n");
+ return -ENOENT;
+ }
+
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err("failed to get highbank cpufreq device\n");
+ ret = -ENODEV;
+ goto out_put_node;
+ }
+
+ cpu_dev->of_node = np;
+
+ cpu_clk = clk_get(cpu_dev, NULL);
+ if (IS_ERR(cpu_clk)) {
+ ret = PTR_ERR(cpu_clk);
+ pr_err("failed to get cpu0 clock: %d\n", ret);
+ goto out_put_node;
+ }
+
+ ret = clk_notifier_register(cpu_clk, &hb_cpufreq_clk_nb);
+ if (ret) {
+ pr_err("failed to register clk notifier: %d\n", ret);
+ goto out_put_node;
+ }
+
+out_put_node:
+ of_node_put(np);
+ return ret;
+}
+module_init(hb_cpufreq_driver_init);
+
+MODULE_AUTHOR("Mark Langsdorf <mark.langsdorf@calxeda.com>");
+MODULE_DESCRIPTION("Calxeda Highbank cpufreq driver");
+MODULE_LICENSE("GPL");
--
1.7.11.7
^ 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