* test
From: jungseung lee @ 2012-11-08 14:35 UTC (permalink / raw)
To: linux-arm-kernel
test
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Arnd Bergmann @ 2012-11-08 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121108142131.GA28327@n2100.arm.linux.org.uk>
On Thursday 08 November 2012, Russell King - ARM Linux wrote:
> On Thu, Nov 08, 2012 at 02:08:41PM +0000, Arnd Bergmann wrote:
> > The newly introduced l2_wt_override should be in the same #ifdef
> > as the code using it, otherwise we get:
> >
> > arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used
>
> This should already be fixed. I think your patch pre-dates 7547/4.
Yes, that's right. I was looking at yesterday's linux-next. It's fixed today.
Thanks,
Arnd
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the l2-mtd and pinctrl trees
From: Arnd Bergmann @ 2012-11-08 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107142916.824003a6c863320fbf379652@canb.auug.org.au>
On Wednesday 07 November 2012, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-nomadik/board-nhk8815.c between commit 1cd2fc449091 ("ARM:
> nomadik: fixup some FSMC merge problems") from the l2-mtd tree, commits
> bb16bd9b9da4 ("pinctrl/nomadik: move the platform data header") from the
> pinctrl and commit 44e47ccf8ab6 ("Merge branch 'next/multiplatform' into
> for-next") from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Hi Stephen,
I think this one turned out wrong, and is missing this part:
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c b/arch/arm/mach-nomadik/board-nhk8815.c
index 5ccdf53..69769b7 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -26,7 +26,6 @@
#include <linux/pinctrl/machine.h>
#include <linux/platform_data/pinctrl-nomadik.h>
#include <linux/platform_data/clocksource-nomadik-mtu.h>
-#include <linux/platform_data/mtd-nomadik-nand.h>
#include <asm/hardware/vic.h>
#include <asm/sizes.h>
#include <asm/mach-types.h>
The mtd-nomadik-nand.h inclusion was removed in the l2-mtd tree, but
moved to a different line in the arm-soc tree. It needs to be removed
because the header is gone now.
Arnd
^ permalink raw reply related
* [GIT PULL] vexpress: fixes for v3.8
From: Pawel Moll @ 2012-11-08 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211081405.23202.arnd@arndb.de>
On Thu, 2012-11-08 at 14:05 +0000, Arnd Bergmann wrote:
> diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
> index 0c6abbf..dc8e882 100644
> --- a/arch/arm/include/debug/vexpress.S
> +++ b/arch/arm/include/debug/vexpress.S
> @@ -21,6 +21,7 @@
> #if defined(CONFIG_DEBUG_VEXPRESS_UART0_DETECT)
>
> .macro addruart,rp,rv,tmp
> + .arch armv7-a
Yes, will you apply it on your side (or fold it into the existing
change) or do you want me to post a patch (or to update the
vexpress-fixes branch?)
Thanks for spotting this!
Pawe?
^ permalink raw reply
* [PATCH 5/7] ARM: at91: remove obsoleted init_consistent_dma_size()
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-08 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352360783-17523-6-git-send-email-m.szyprowski@samsung.com>
On 08:46 Thu 08 Nov , Marek Szyprowski wrote:
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: Nicolas Ferre <nicolas.ferre@atmel.com>
> CC: Andrew Victor <linux@maxim.org.za>
> CC: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/at91sam9g45.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
> index 84af1b5..b7ae124 100644
> --- a/arch/arm/mach-at91/at91sam9g45.c
> +++ b/arch/arm/mach-at91/at91sam9g45.c
> @@ -343,7 +343,6 @@ static struct at91_gpio_bank at91sam9g45_gpio[] __initdata = {
> static void __init at91sam9g45_map_io(void)
> {
> at91_init_sram(0, AT91SAM9G45_SRAM_BASE, AT91SAM9G45_SRAM_SIZE);
> - init_consistent_dma_size(SZ_4M);
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* [RFC PATCH v4 2/2] ASoC: sam9g20-wm8731: convert to dt support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-08 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352361422-13265-2-git-send-email-voice.shen@atmel.com>
On 15:57 Thu 08 Nov , Bo Shen wrote:
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> Change since v3 RFC:
> Remove dai node, remap ssc in place
> without pinctrl added, so don't modify the dtsi file, will be added
> soon
until I see the pinctrl to test this no
This code is untested
> Change since v2:
> No change
> Change since v1:
> Add sam9g20-wm8731 binding document
> ---
> .../bindings/sound/atmel-sam9g20-wm8731-audio.txt | 21 ++++++
> sound/soc/atmel/Kconfig | 3 +-
> sound/soc/atmel/sam9g20_wm8731.c | 71 ++++++++++++++++++--
> 3 files changed, 88 insertions(+), 7 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9g20-wm8731-audio.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9g20-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9g20-wm8731-audio.txt
> new file mode 100644
> index 0000000..adf7e7c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/atmel-sam9g20-wm8731-audio.txt
> @@ -0,0 +1,21 @@
> +* Atmel sam9g20ek audio complex
this is board file or soc?
and use the full soc sor board ame in the documentation
Best Regards,
J.
> +
> +Required properties:
> + - compatible: "atmel,at91sam9g20-audio"
> + - atmel,model: The user-visible name of this sound complex.
> + - atmel,audio-routing: A list of the connections between audio components.
> + - atmel,ssc-controller: The phandle of the SSC controller
> + - atmel,audio-codec: The phandle of the WM8731 audio codec
> +
> +Example:
> +sound {
> + compatible = "atmel,at91sam9g20-audio";
> + atmel,model = "wm8731 @ AT91SAMG20EK";
> +
> + atmel,audio-routing =
> + "Ext Spk", "LHPOUT",
> + "Int MIC", "MICIN";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8731>;
> +};
> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> index 72b09cf..397ec75 100644
> --- a/sound/soc/atmel/Kconfig
> +++ b/sound/soc/atmel/Kconfig
> @@ -16,8 +16,7 @@ config SND_ATMEL_SOC_SSC
>
> config SND_AT91_SOC_SAM9G20_WM8731
> tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation board"
> - depends on ATMEL_SSC && ARCH_AT91SAM9G20 && SND_ATMEL_SOC && \
> - AT91_PROGRAMMABLE_CLOCKS
> + depends on ATMEL_SSC && SND_ATMEL_SOC && AT91_PROGRAMMABLE_CLOCKS
> select SND_ATMEL_SOC_SSC
> select SND_SOC_WM8731
> help
> diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c
> index eef6eed..62c3a3d 100644
> --- a/sound/soc/atmel/sam9g20_wm8731.c
> +++ b/sound/soc/atmel/sam9g20_wm8731.c
> @@ -197,14 +197,30 @@ static struct snd_soc_card snd_soc_at91sam9g20ek = {
>
> static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *codec_np, *cpu_np;
> struct clk *pllb;
> struct snd_soc_card *card = &snd_soc_at91sam9g20ek;
> - int ret;
> -
> - if (!(machine_is_at91sam9g20ek() || machine_is_at91sam9g20ek_2mmc()))
> - return -ENODEV;
> + int ret, id;
> +
> + if (np) {
> + cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
> + if (!cpu_np) {
> + dev_err(&pdev->dev, "codec info missing\n");
> + return -EINVAL;
> + }
> +
> + id = of_alias_get_id(cpu_np, "ssc");
> + of_node_put(cpu_np);
> + } else {
> + if (!(machine_is_at91sam9g20ek() ||
> + machine_is_at91sam9g20ek_2mmc()))
> + return -ENODEV;
> +
> + id = pdev->id;
> + }
>
> - ret = atmel_ssc_set_audio(pdev->id);
> + ret = atmel_ssc_set_audio(id);
> if (ret)
> goto err;
>
> @@ -234,6 +250,42 @@ static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev)
> clk_set_rate(mclk, MCLK_RATE);
>
> card->dev = &pdev->dev;
> +
> + /* Parse device node info */
> + if (np) {
> + ret = snd_soc_of_parse_card_name(card, "atmel,model");
> + if (ret)
> + goto err;
> +
> + ret = snd_soc_of_parse_audio_routing(card,
> + "atmel,audio-routing");
> + if (ret)
> + goto err;
> +
> + /* Parse codec info */
> + at91sam9g20ek_dai.codec_name = NULL;
> + codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
> + if (!codec_np) {
> + dev_err(&pdev->dev, "codec info missing\n");
> + return -EINVAL;
> + }
> + at91sam9g20ek_dai.codec_of_node = codec_np;
> +
> + /* Parse dai and platform info */
> + at91sam9g20ek_dai.cpu_dai_name = NULL;
> + at91sam9g20ek_dai.platform_name = NULL;
> + cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
> + if (!cpu_np) {
> + dev_err(&pdev->dev, "dai and pcm info missing\n");
> + return -EINVAL;
> + }
> + at91sam9g20ek_dai.cpu_of_node = cpu_np;
> + at91sam9g20ek_dai.platform_of_node = cpu_np;
> +
> + of_node_put(codec_np);
> + of_node_put(cpu_np);
> + }
> +
> ret = snd_soc_register_card(card);
> if (ret) {
> printk(KERN_ERR "ASoC: snd_soc_register_card() failed\n");
> @@ -262,10 +314,19 @@ static int __devexit at91sam9g20ek_audio_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id sam9g20ek_wm8731_dt_ids[] = {
> + { .compatible = "atmel,at91sam9g20-audio", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sam9g20ek_wm8731_dt_ids);
> +#endif
> +
> static struct platform_driver at91sam9g20ek_audio_driver = {
> .driver = {
> .name = "at91sam9g20ek-audio",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(sam9g20ek_wm8731_dt_ids),
> },
> .probe = at91sam9g20ek_audio_probe,
> .remove = __devexit_p(at91sam9g20ek_audio_remove),
> --
> 1.7.9.5
>
^ permalink raw reply
* BUG: ARM build failures due to Xen
From: Arnd Bergmann @ 2012-11-08 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106175749.GO28327@n2100.arm.linux.org.uk>
On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> My build system is giving me the following errors against an OMAP4
> randconfig build against the latest Linus' kernel plus arm-soc:
>
> ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[2]: Target `_modpost' not remade because of errors.
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
> make: Target `uImage' not remade because of errors.
> make: Target `modules' not remade because of errors.
>
> Full build results and configuration are here:
>
> http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2627
> http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2627
>
I can reproduce the same thing with mainline v3.7-rc4.
8<------
xen/arm: export privcmd_call
privcmd_call may get called from a module, so it has to be exported.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..ff5e300 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -17,6 +17,9 @@
#include <linux/of_irq.h>
#include <linux/of_address.h>
+/* from hypercall.S */
+EXPORT_SYMBOL_GPL(privcmd_call);
+
struct start_info _xen_start_info;
struct start_info *xen_start_info = &_xen_start_info;
EXPORT_SYMBOL_GPL(xen_start_info);
^ permalink raw reply related
* [GIT PULL] vexpress: fixes for v3.8
From: Arnd Bergmann @ 2012-11-08 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352387647.20549.10.camel@hornet>
On Thursday 08 November 2012, Pawel Moll wrote:
> On Thu, 2012-11-08 at 14:05 +0000, Arnd Bergmann wrote:
> > diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
> > index 0c6abbf..dc8e882 100644
> > --- a/arch/arm/include/debug/vexpress.S
> > +++ b/arch/arm/include/debug/vexpress.S
> > @@ -21,6 +21,7 @@
> > #if defined(CONFIG_DEBUG_VEXPRESS_UART0_DETECT)
> >
> > .macro addruart,rp,rv,tmp
> > + .arch armv7-a
>
> Yes, will you apply it on your side (or fold it into the existing
> change) or do you want me to post a patch (or to update the
> vexpress-fixes branch?)
>
> Thanks for spotting this!
I've applied it manually now and added you Acked-by.
Arnd
^ permalink raw reply
* [PATCH 1/2] leds: Add generic support for memory mapped LEDs
From: Pawel Moll @ 2012-11-08 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351792722-15250-1-git-send-email-pawel.moll@arm.com>
Hi Bryan, Richard,
On Thu, 2012-11-01 at 17:58 +0000, Pawel Moll wrote:
> LEDs are often controlled by writing to memory mapped
> register. This patch adds:
>
> 1. Generic functions for platform code and drivers to create
> class device for LEDs controlled by arbitrary bit masks.
> The control register value is read, modified by logic AND
> and OR operations with respective mask and written back.
>
> 2. A platform driver for simple use case when one or more LED
> are controlled by consecutive bits in a register pointed
> at by the platform device's memory resource. It can be
> particularly useful for MFD cells being part of an other
> device.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
It's just a friendly and polite nag - any thoughts or feelings about
this?
Cheers!
Pawe?
^ permalink raw reply
* [Xen-devel] BUG: ARM build failures due to Xen
From: Ian Campbell @ 2012-11-08 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211081528.31968.arnd@arndb.de>
On Thu, 2012-11-08 at 15:28 +0000, Arnd Bergmann wrote:
> On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> > My build system is giving me the following errors against an OMAP4
> > randconfig build against the latest Linus' kernel plus arm-soc:
> >
> > ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> > make[2]: *** [__modpost] Error 1
> > make[2]: Target `_modpost' not remade because of errors.
> > make[1]: *** [modules] Error 2
> > make: *** [sub-make] Error 2
> > make: Target `uImage' not remade because of errors.
> > make: Target `modules' not remade because of errors.
> >
> > Full build results and configuration are here:
> >
> > http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2627
> > http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2627
> >
>
> I can reproduce the same thing with mainline v3.7-rc4.
> 8<------
> xen/arm: export privcmd_call
Thanks, Konrad posted a fix for this on Tuesday which covers a few other
cases too: http://marc.info/?l=linux-kernel&m=135224075902642&w=2 I
added Russell to my response but forgot to add l-a-k@ too, sorry.
Is one of you going to pick it up and send to mainline?
Ian.
> privcmd_call may get called from a module, so it has to be exported.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 59bcb96..ff5e300 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -17,6 +17,9 @@
> #include <linux/of_irq.h>
> #include <linux/of_address.h>
>
> +/* from hypercall.S */
> +EXPORT_SYMBOL_GPL(privcmd_call);
> +
> struct start_info _xen_start_info;
> struct start_info *xen_start_info = &_xen_start_info;
> EXPORT_SYMBOL_GPL(xen_start_info);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] BUG: ARM build failures due to Xen
From: Stefano Stabellini @ 2012-11-08 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352389245.12977.106.camel@hastur.hellion.org.uk>
On Thu, 8 Nov 2012, Ian Campbell wrote:
> On Thu, 2012-11-08 at 15:28 +0000, Arnd Bergmann wrote:
> > On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> > > My build system is giving me the following errors against an OMAP4
> > > randconfig build against the latest Linus' kernel plus arm-soc:
> > >
> > > ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> > > make[2]: *** [__modpost] Error 1
> > > make[2]: Target `_modpost' not remade because of errors.
> > > make[1]: *** [modules] Error 2
> > > make: *** [sub-make] Error 2
> > > make: Target `uImage' not remade because of errors.
> > > make: Target `modules' not remade because of errors.
> > >
> > > Full build results and configuration are here:
> > >
> > > http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2627
> > > http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2627
> > >
> >
> > I can reproduce the same thing with mainline v3.7-rc4.
> > 8<------
> > xen/arm: export privcmd_call
>
> Thanks, Konrad posted a fix for this on Tuesday which covers a few other
> cases too: http://marc.info/?l=linux-kernel&m=135224075902642&w=2 I
> added Russell to my response but forgot to add l-a-k@ too, sorry.
Konrad, do you have time to respin a patch that exports all the 9
hypercalls?
If not (maybe Konrad is away like me), then I am OK for Konrad's
current patch to be applied as it is.
^ permalink raw reply
* [Xen-devel] BUG: ARM build failures due to Xen
From: Stefano Stabellini @ 2012-11-08 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1211081544510.2689@kaball.uk.xensource.com>
On Thu, 8 Nov 2012, Stefano Stabellini wrote:
> On Thu, 8 Nov 2012, Ian Campbell wrote:
> > On Thu, 2012-11-08 at 15:28 +0000, Arnd Bergmann wrote:
> > > On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> > > > My build system is giving me the following errors against an OMAP4
> > > > randconfig build against the latest Linus' kernel plus arm-soc:
> > > >
> > > > ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> > > > make[2]: *** [__modpost] Error 1
> > > > make[2]: Target `_modpost' not remade because of errors.
> > > > make[1]: *** [modules] Error 2
> > > > make: *** [sub-make] Error 2
> > > > make: Target `uImage' not remade because of errors.
> > > > make: Target `modules' not remade because of errors.
> > > >
> > > > Full build results and configuration are here:
> > > >
> > > > http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2627
> > > > http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2627
> > > >
> > >
> > > I can reproduce the same thing with mainline v3.7-rc4.
> > > 8<------
> > > xen/arm: export privcmd_call
> >
> > Thanks, Konrad posted a fix for this on Tuesday which covers a few other
> > cases too: http://marc.info/?l=linux-kernel&m=135224075902642&w=2 I
> > added Russell to my response but forgot to add l-a-k@ too, sorry.
>
> Konrad, do you have time to respin a patch that exports all the 9
> hypercalls?
This is the patch that I had in mind:
---
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/arm: Fix compile errors when drivers are compiled as modules.
We end up with:
ERROR: "HYPERVISOR_event_channel_op" [drivers/xen/xen-gntdev.ko] undefined!
ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
ERROR: "HYPERVISOR_grant_table_op" [drivers/net/xen-netback/xen-netback.ko] undefined!
and this patch exports said function (which is implemented in hypercall.S).
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..f576092 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -166,3 +166,14 @@ void free_xenballooned_pages(int nr_pages, struct page **pages)
*pages = NULL;
}
EXPORT_SYMBOL_GPL(free_xenballooned_pages);
+
+/* In the hypervisor.S file. */
+EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
+EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
+EXPORT_SYMBOL_GPL(privcmd_call);
^ permalink raw reply related
* [PATCH] arm: zynq: add system level control register manager
From: Josh Cartwright @ 2012-11-08 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031183610.GA2603@thinkbox>
On Wed, Oct 31, 2012 at 07:36:12PM +0100, Daniel Borkmann wrote:
> This patch for the Xilinx Zynq ARM architecture adds management of system
> level control register. The code is taken from the Xilinx-internal Linux
> Git tree and cleaned up a bit for mainline integration. Besides others,
> this patch is needed in order to integrate further drivers for Zynq such as
> the Zynq xemacps networking device driver. The patch is aganst the latest
> arm-soc tree.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
> Cc: Michal Simek <michals@xilinx.com>
> Cc: John Linn <john.linn@xilinx.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
Hey Daniel-
These changes will conflict with my pending clk patchset [1], as I'm
introducing bindings for the SLCR (and its clk interfaces).
It seems like a hefty chunk of the out-of-tree slcr driver is related to
configuring MIO. I think it would be really nice if this driver was
reworked to use the pinctrl subsystem, and also to provide suitable
device tree bindings.
But, at an even higher level, it would be nice to have a coordinated
plan for getting better Zynq support upstream. My implicit plan (so
far) has been:
1. Initial cleanup [get the thing booting] (done)
2. Figure out clk drivers and bindings (pending)
3. Figure out MIO pinctrl support and bindings (?)
4. Adapting out-of-tree peripheral drivers according to 2 & 3 (?)
5. Add support for SMP (?)
Step 4 has a dependency on 2 and 3, of course, the point being that we
get those into a state where we are happy with them before moving all of
the peripherals over. I believe step 5 can be done in parallel to the
others.
Arnd-
At a high level, does this sound like a suitable plan of action? Is
there something else you would like to see from those of us working on
Zynq support?
Thanks,
Josh
1: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/129295.html
^ permalink raw reply
* [PATCH] Add support for generic BCM SoC chipsets
From: Christian Daudt @ 2012-11-08 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In order to start upstreaming Broadcom SoC support, create
a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It
has been made MULTIPLATFORM compatible.
Next steps
----------
Upstream a basic set of drivers - sufficient for a console boot to
ramdisk. These will includer timer, gpio, i2c drivers.
After this basic set, we will proceed with a more comprehensive set
of drivers for the 281XX SoC family.
Signed-off-by: Christian Daudt <csd@broadcom.com>
Reviewed-by: James King <jamesk@broadcom.com>
---
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++
arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++
arch/arm/configs/bcm_defconfig | 114 +++++++++++++++++++++++++++++++++++++++
arch/arm/mach-bcm/Kconfig | 18 +++++++
arch/arm/mach-bcm/Makefile | 13 +++++
arch/arm/mach-bcm/board_bcm.c | 66 +++++++++++++++++++++++
9 files changed, 297 insertions(+)
create mode 100644 arch/arm/boot/dts/capri-brt.dts
create mode 100644 arch/arm/boot/dts/capri.dtsi
create mode 100644 arch/arm/configs/bcm_defconfig
create mode 100644 arch/arm/mach-bcm/Kconfig
create mode 100644 arch/arm/mach-bcm/Makefile
create mode 100644 arch/arm/mach-bcm/board_bcm.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ade7e92..3da77ba 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1022,6 +1022,8 @@ source "arch/arm/mach-mvebu/Kconfig"
source "arch/arm/mach-at91/Kconfig"
+source "arch/arm/mach-bcm/Kconfig"
+
source "arch/arm/mach-clps711x/Kconfig"
source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5f914fc..8523fdb 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -137,6 +137,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
# Machine directory name. This list is sorted alphanumerically
# by CONFIG_* macro name.
machine-$(CONFIG_ARCH_AT91) += at91
+machine-$(CONFIG_ARCH_BCM) += bcm
machine-$(CONFIG_ARCH_BCM2835) += bcm2835
machine-$(CONFIG_ARCH_CLPS711X) += clps711x
machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..25d347a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \
usb_a9263.dtb \
usb_a9g20.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM) += capri-brt.dtb
dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
dove-dove-db.dtb
diff --git a/arch/arm/boot/dts/capri-brt.dts b/arch/arm/boot/dts/capri-brt.dts
new file mode 100644
index 0000000..5db7335
--- /dev/null
+++ b/arch/arm/boot/dts/capri-brt.dts
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+/include/ "capri.dtsi"
+
+/ {
+ model = "Capri BRT board";
+ compatible = "bcm,capri";
+ interrupt-parent = <&gic>;
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>; /* 1 GB */
+ };
+
+ uart at 3e000000 {
+ status = "okay";
+ };
+
+};
diff --git a/arch/arm/boot/dts/capri.dtsi b/arch/arm/boot/dts/capri.dtsi
new file mode 100644
index 0000000..895a928
--- /dev/null
+++ b/arch/arm/boot/dts/capri.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Capri SoC";
+ compatible = "bcm,capri";
+ interrupt-parent = <&gic>;
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ gic: interrupt-controller at 3ff00100 {
+ compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x3ff01000 0x1000>,
+ <0x3ff00100 0x100>;
+ };
+
+ uart at 3e000000 {
+ compatible = "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e000000 0x1000>;
+ clock-frequency = <13000000>;
+ interrupts = <0x0 67 0x4>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ L2: l2-cache {
+ compatible = "arm,pl310-cache";
+ reg = <0x3ff20000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+};
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
new file mode 100644
index 0000000..e3bf2d6
--- /dev/null
+++ b/arch/arm/configs/bcm_defconfig
@@ -0,0 +1,114 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=19
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_EFI_PARTITION=y
+CONFIG_ARCH_BCM=y
+CONFIG_ARM_THUMBEE=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+# CONFIG_COMPACTION is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyS0,115200n8 mem=128M"
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_BLK_DEV is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_SCAN_ASYNC=y
+CONFIG_INPUT_FF_MEMLESS=y
+CONFIG_INPUT_JOYDEV=y
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_UINPUT=y
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_FUSE_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_PRINTK_TIME=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=110
+CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_LL=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC_T10DIF=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
+CONFIG_XZ_DEC=y
+CONFIG_AVERAGE=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
new file mode 100644
index 0000000..d53b48c
--- /dev/null
+++ b/arch/arm/mach-bcm/Kconfig
@@ -0,0 +1,18 @@
+config ARCH_BCM
+ bool "Broadcom SoC" if ARCH_MULTI_V7
+ depends on MMU
+ select CPU_V7
+ select ARM_GIC
+ select GENERIC_GPIO
+ select GPIO_BCM
+ select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_TIME
+ select GENERIC_CLOCKEVENTS
+ select TICK_ONESHOT
+ select ARM_ERRATA_754322
+ select ARM_ERRATA_764369 if SMP
+ select SPARSE_IRQ
+ help
+ This enables support for system based on Broadcom SoCs.
+ It currently supports BCM28145/28150/28155 chips.
+
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
new file mode 100644
index 0000000..bbf4122
--- /dev/null
+++ b/arch/arm/mach-bcm/Makefile
@@ -0,0 +1,13 @@
+#
+# Copyright (C) 2012 Broadcom Corporation
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation version 2.
+#
+# This program is distributed "as is" WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+obj-$(CONFIG_ARCH_BCM) := board_bcm.o
diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
new file mode 100644
index 0000000..a8165a5
--- /dev/null
+++ b/arch/arm/mach-bcm/board_bcm.c
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <asm/io.h>
+
+#include <asm/mach/arch.h>
+#include <asm/hardware/gic.h>
+#include <asm/hardware/cache-l2x0.h>
+
+#include <asm/mach/time.h>
+
+
+
+static const struct of_device_id irq_match[] = {
+ {.compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ {}
+};
+
+static void timer_init(void)
+{
+}
+
+static struct sys_timer timer = {
+ .init = timer_init,
+};
+
+static void __init init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
+static void __init board_init(void)
+{
+ l2x0_of_init(0x78450000, 0xC200ffff);
+
+ /* TODO: Add call to secure monitor to actually enable L2 */
+
+ of_platform_populate(NULL, of_default_bus_match_table, NULL,
+ &platform_bus);
+}
+
+static const char * const capri_dt_compat[] = { "bcm,capri", NULL, };
+
+
+DT_MACHINE_START(CAPRI_DT, "Broadcom Application Processor")
+ .init_irq = init_irq,
+ .timer = &timer,
+ .init_machine = board_init,
+ .dt_compat = capri_dt_compat,
+ .handle_irq = gic_handle_irq,
+MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509B666F.6080507@compulab.co.il>
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
> On 11/07/12 23:36, Jon Hunter wrote:
>> Hi Igor,
>>
>> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
>>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
>>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
>>> setting.
>>> To remove the dependancy, several conversions/additions had to be done:
>>> 1) Timer structures and initialization functions are named by the platform
>>> name and the clock source in use. The decision which timer is
>>> used is done statically from the machine_desc structure. In the
>>> future it should come from DT.
>>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
>>> separate timer structures along with the timer init functions.
>>> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
>>> 3) Since we have all the timers defined inside machine_desc structure
>>> and we no longer need the fallback to gp_timer clock source in case
>>> 32k_timer clock source is unavailable (namely on AM33xx), we no
>>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
>>> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
>>> __omap2_sync32k_clocksource_init() function.
>>>
>>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>>> Cc: Jon Hunter <jon-hunter@ti.com>
>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
>>
>> [snip]
>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 684d2fc..a4ad7a0 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -63,20 +63,8 @@
>>> #define OMAP2_32K_SOURCE "func_32k_ck"
>>> #define OMAP3_32K_SOURCE "omap_32k_fck"
>>> #define OMAP4_32K_SOURCE "sys_32k_ck"
>>> -
>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
>>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
>>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
>>> -#define OMAP3_SECURE_TIMER 12
>>> #define TIMER_PROP_SECURE "ti,timer-secure"
>>> -#else
>>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
>>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
>>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
>>> -#define OMAP3_SECURE_TIMER 1
>>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
>>> -#endif
>>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
>>
>> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
>> "ti,timer-secure" and "ti,timer-alwon" directly?
>>
>> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
>> was to drop this and use the property string directly to remove any
>> abstraction.
>
> Well, I don't understand what do you mean by "any abstraction".
> The purpose of defining those two was to eliminate multiple occurrences
> of the string in the code, so for example if someone decides to change the
> property string for some currently unknown reason - it will be easy and small.
> Defines are a common practice for that, no?
> If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
>>> #define REALTIME_COUNTER_BASE 0x48243200
>>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
>>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
>>>
>>> /* If we are a secure device, remove any secure timer nodes */
>>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
>>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
>>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
>>> if (np)
>>> of_node_put(np);
>>> }
>>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>> return 0;
>>> }
>>>
>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>> /* Setup free-running counter for clocksource */
>>> -static int __init omap2_sync32k_clocksource_init(void)
>>> +static int __init __omap2_sync32k_clocksource_init(void)
>>
>> Not sure I follow why you renamed this function here ...
>
> I didn't want to add unused arguments to this function, so I've made a
> wrapper below to have both the sync32k and the gp functions have the same
> signature (argument list) and be called from a single macro.
> Anyway, see below.
Ok.
>>
>>> {
>>> int ret;
>>> struct device_node *np = NULL;
>>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
>>>
>>> return ret;
>>> }
>>> -#else
>>> -static inline int omap2_sync32k_clocksource_init(void)
>>> -{
>>> - return -ENODEV;
>>> -}
>>> -#endif
>>>
>>> -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>> - const char *fck_source)
>>> +static void __init omap2_gp_clocksource_init(int gptimer_id,
>>> + const char *fck_source)
>>
>> Nit, I personally prefer keeping gptimer, because gp just means
>> "general-purpose" and does not imply a timer per-se.
>
> I've made this change, so we will not get something like:
> omapx_gptimer_timer_init(), but this really does not meter to me,
> so no problem will do for v2.
Thanks.
>>
>>> {
>>> int res;
>>>
>>> @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>> gptimer_id, clksrc.rate);
>>> }
>>>
>>> -static void __init omap2_clocksource_init(int gptimer_id,
>>> - const char *fck_source)
>>> +static void __init omap2_sync32k_clocksource_init(int gptimer_id,
>>> + const char *fck_source)
>>> {
>>> - /*
>>> - * First give preference to kernel parameter configuration
>>> - * by user (clocksource="gp_timer").
>>> - *
>>> - * In case of missing kernel parameter for clocksource,
>>> - * first check for availability for 32k-sync timer, in case
>>> - * of failure in finding 32k_counter module or registering
>>> - * it as clocksource, execution will fallback to gp-timer.
>>> - */
>>> - if (use_gptimer_clksrc == true)
>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>> - else if (omap2_sync32k_clocksource_init())
>>> - /* Fall back to gp-timer code */
>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>> + __omap2_sync32k_clocksource_init();
>>> }
>>
>> ... this just appears to be a wrapper function, but I don't see why this
>> is needed? Do we need this wrapper?
>
> no, not really, just consider the explanation above.
> I will remove the wrapper for v2.
Ok, thanks.
>>
>>> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
>>> @@ -563,52 +531,64 @@ static inline void __init realtime_counter_init(void)
>>> {}
>>> #endif
>>>
>>> -#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
>>> - clksrc_nr, clksrc_src) \
>>> -static void __init omap##name##_timer_init(void) \
>>> +#define OMAP_SYS_TIMER_INIT(n, clksrc_name, clkev_nr, clkev_src, \
>>> + clkev_prop, clksrc_nr, clksrc_src) \
>>> +static void __init omap##n##_##clksrc_name##_timer_init(void) \
>>
>>
>>> { \
>>> omap_dmtimer_init(); \
>>> omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop); \
>>> - omap2_clocksource_init((clksrc_nr), clksrc_src); \
>>> + \
>>> + if (use_gptimer_clksrc) \
>>> + omap2_gp_clocksource_init((clksrc_nr), clksrc_src); \
>>> + else \
>>> + omap2_##clksrc_name##_clocksource_init((clksrc_nr), \
>>> + clksrc_src); \
>>
>> Something here seems a little odd. If "clksrc_name" is "gp", then the
>> if-else parts will call the same function. Or am I missing something here?
>
> Yes, you are right - this is odd.
> What do you think of:
>
> if (use_gptimer_clksrc) {
> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> return;
> }
> omap2_##clksrc_name##_clocksource_init((clksrc_nr), clksrc_src);
Yes, but it still seems a little odd that we could have ...
if (use_gptimer_clksrc) {
omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
return;
}
omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>>
>> I think that I prefer how it works today where we call just
>> omap2_clocksource_init(), and it determines whether to use the gptimer
>> or the 32k-sync.
>
> There is no reliable way to determine which source should be used in runtime
> for boards that do not have the 32k oscillator wired.
Hmmm ... well for OMAP devices the 32kHz clock is mandatory AFAIK. At
least for OMAP devices and I would need to check on the AM33xx but I
would imagine they are the same. Which devices are you referring to
where the 32kHz is optional?
>> For OMAP I think that it is fine to default to the 32k-sync and then if
>> the gptimer is selected, it uses the higher frequency sys_clk as the
>> timer source.
>
> I agree for the 32k-sync as a default, but gptimer will not be selected
> on SoC that have 32k while board does not have the 32k wired.
Ok, again let me know which device(s) this applies too.
>>
>> For AMxxx, devices, sync-32k does not exist, and so I understand it does
>> not work the same.
>>
>> I am wondering if the use_gptimer_clksrc, should become
>> use_sysclk_clksrc, and then ...
>>
>> For OMAP ...
>> use_sysclk_clksrc = 0 --> use sync-32k (default)
>> use_sysclk_clksrc = 1 --> use gptimer with sys_clk
>>
>> For AM33xx ...
>> use_sysclk_clksrc = 0 --> use gptimer with 32khz clock (default)
>> use_sysclk_clksrc = 1 --> use gptimer with sys_clk
>
> Well, this is more or less how it works today, but it does not consider
> the board wiring information that after all defines which source should
> be used. (Not all boards out there are clones of beagles and evms...)
> And the generic code should be flexible enough
> to enable any legal configuration.
My whole thought here was that the 32kHz is always present. If that is
not the case then I would agree this would not work.
>>
>>> }
>>>
>>> -#define OMAP_SYS_TIMER(name) \
>>> -struct sys_timer omap##name##_timer = { \
>>> - .init = omap##name##_timer_init, \
>>> -};
>>> +#define OMAP_SYS_TIMER(n, clksrc) \
>>> +struct sys_timer omap##n##_##clksrc##_timer = { \
>>> + .init = omap##n##_##clksrc##_timer_init, \
>>> +}
>>>
>>> #ifdef CONFIG_ARCH_OMAP2
>>> -OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, "ti,timer-alwon",
>>> - 2, OMAP2_MPU_SOURCE)
>>> -OMAP_SYS_TIMER(2)
>>> +OMAP_SYS_TIMER_INIT(2, sync32k, 1, OMAP2_32K_SOURCE, TIMER_PROP_ALWON,
>>> + 2, OMAP2_MPU_SOURCE);
>>> +OMAP_SYS_TIMER(2, sync32k);
>>> +OMAP_SYS_TIMER_INIT(2, gp, 1, OMAP2_MPU_SOURCE, TIMER_PROP_ALWON,
>>> + 2, OMAP2_MPU_SOURCE);
>>> +OMAP_SYS_TIMER(2, gp);
>>
>> It would be good if we can avoid having two timer_init functions for
>> each OMAP generation.
>
> Yes, but then we will not have the right description of the hardware
> but IMHO workarounds on workarounds on...
>
> There are several clock sources - all can be used,
> why not have them described and ready for use?
Well we really want to simplify this code and so I was thinking that if
a device has a 32k-sync timer AND there is a 32kHz source, then what's
the point in having an option to use a gptimer with a 32kHz source for
that device? I guess I don't see the benefit there, at least for OMAP2-5
devices specifically.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Tony Lindgren @ 2012-11-08 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509B5B84.50605@compulab.co.il>
* Igor Grinberg <grinberg@compulab.co.il> [121107 23:15]:
> On 11/07/12 19:33, Tony Lindgren wrote:
> >
> > I think this should be the default for the timers as that counter
> > does not stop during deeper idle states.
>
> Well, it is the default as you can see from the patch.
> The problem is that for boards that for some reason do not have
> the 32k wired and rely on MPU/GP timer source, the default will not work
> and currently there is no way for board to specify which timer source
> it can use.
Yes. I was just wondering if we can avoid patching all the board
files by doing it the other way around by introducing a new
omap_gp_timer rather than renaming all the existing ones?
> We have discussed this in San Diego (remember?) and you actually proposed
> this way as a solution. Well, may be I took it a bit further than you
> thought, but this is because the board code cannot know which timer source
> should be used at runtime and the fall back described below, does not work.
Yes thanks I agree we should get rid of that Kconfig option for sure.
> >> --- a/arch/arm/mach-omap2/board-2430sdp.c
> >> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
> >> .handle_irq = omap2_intc_handle_irq,
> >> .init_machine = omap_2430sdp_init,
> >> .init_late = omap2430_init_late,
> >> - .timer = &omap2_timer,
> >> + .timer = &omap2_sync32k_timer,
> >> .restart = omap_prcm_restart,
> >> MACHINE_END
> >> --- a/arch/arm/mach-omap2/board-3430sdp.c
> >> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> >> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
> >> .handle_irq = omap3_intc_handle_irq,
> >> .init_machine = omap_3430sdp_init,
> >> .init_late = omap3430_init_late,
> >> - .timer = &omap3_timer,
> >> + .timer = &omap3_sync32k_timer,
> >> .restart = omap_prcm_restart,
> >> MACHINE_END
> > ...
> >
> > Can't we assume that the default timer is omap[234]_sync32k_timer to
> > avoid renaming the timer entries in all the board files?
>
> Hmmm...
> How will this work with the macros defining the sys_timer structure?
> I would also not want to hide the exact timer used under the default name.
Can't you just add a new sys_timer (or a new macro) for GP only setups?
> > Then we just need a new timer entries for the hardware that does
> > not have the sycn32k_timer available?
>
> Well, I tried to make it small patch just for the hardware that needs it,
> but I always found some corner case where, IMHO, this does not work/look good.
Can you explain a bit further?
I guess what I'm after is just to avoid renaming the existing
timers in the board-*.c files and only rename the ones that
need gp timer only.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Will Deacon @ 2012-11-08 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211071505410.21033@xanadu.home>
On Wed, Nov 07, 2012 at 08:10:49PM +0000, Nicolas Pitre wrote:
> Here's my latest version. I made the tlb flush conditional. Please
> review again before I add your ACK.
Ok.
> ---- >8
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Subject: [PATCH] ARM: idmap: use flush_cache_louis() and flush TLBs only when necessary
>
> Flushing the cache is needed for the hardware to see the idmap table
> and therefore can be done at init time. On ARMv7 it is not necessary to
> flush L2 so flush_cache_louis() is used here instead.
>
> There is no point flushing the cache in setup_mm_for_reboot() as the
> caller should, and already is, taking care of this. If switching the
> memory map requires a cache flush, then cpu_switch_mm() already includes
> that operation.
>
> What is not done by cpu_switch_mm() on ASID capable CPUs is TLB flushing
> as the whole point of the ASID is to tag the TLBs and avoid flushing them
> on a context switch. Since we don't have a clean ASID for the identity
> mapping, we need to flush the TLB explicitly in that case. Otherwise
> this is already performed by cpu_switch_mm().
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index ab88ed4f8e..99db769307 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -92,6 +92,9 @@ static int __init init_static_idmap(void)
> (long long)idmap_start, (long long)idmap_end);
> identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
>
> + /* Flush L1 for the hardware to see this page table content */
> + flush_cache_louis();
> +
> return 0;
> }
> early_initcall(init_static_idmap);
> @@ -103,12 +106,15 @@ early_initcall(init_static_idmap);
> */
> void setup_mm_for_reboot(void)
> {
> - /* Clean and invalidate L1. */
> - flush_cache_all();
> -
> /* Switch to the identity mapping. */
> cpu_switch_mm(idmap_pgd, &init_mm);
>
> - /* Flush the TLB. */
> +#ifdef CONFIG_CPU_HAS_ASID
> + /*
> + * We don't have a clean ASID for the identity mapping, which
> + * may clash with virtual addresses of the previous page tables
> + * and therefore potentially in the TLB.
> + */
> local_flush_tlb_all();
> +#endif
I checked all of the switch_mm implementations and it looks like
!CONFIG_CPU_HAS_ASID implies the TLB flush in all cases, so this looks fine
to me.
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* [PATCH 1/7] ARM: omap: remove obsoleted init_consistent_dma_size()
From: Tony Lindgren @ 2012-11-08 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352360783-17523-2-git-send-email-m.szyprowski@samsung.com>
* Marek Szyprowski <m.szyprowski@samsung.com> [121107 23:48]:
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap1/io.c | 1 -
> arch/arm/mach-omap2/io.c | 12 ------------
> arch/arm/plat-omap/common.c | 7 -------
> arch/arm/plat-omap/include/plat/dma.h | 1 -
> 4 files changed, 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
> index 6a5baab..b3d0fb3 100644
> --- a/arch/arm/mach-omap1/io.c
> +++ b/arch/arm/mach-omap1/io.c
> @@ -134,7 +134,6 @@ void __init omap1_init_early(void)
> */
> omap1_clk_init();
> omap1_mux_init();
> - omap_init_consistent_dma_size();
> }
>
> void __init omap1_init_late(void)
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 4234d28..2597846 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -354,11 +354,6 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
> return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
> }
>
> -static void __init omap_common_init_early(void)
> -{
> - omap_init_consistent_dma_size();
> -}
> -
> static void __init omap_hwmod_init_postsetup(void)
> {
> u8 postsetup_state;
...
Thanks we already have a similar patch from Tomi Valkeinen queued in
the omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3 branch, so
this patch can be dropped.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/7] ARM: remove init_consistent_dma_size() stub
From: Tony Lindgren @ 2012-11-08 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352360783-17523-1-git-send-email-m.szyprowski@samsung.com>
* Marek Szyprowski <m.szyprowski@samsung.com> [121107 23:48]:
> Hello,
>
> Commit e9da6e9905e639b0 ("ARM: dma-mapping: remove custom consistent dma
> region") replaced custom consistent memory handling, so setting
> consistent dma memory size is not longer required. This patch series
> cleans sub-architecture platform code to remove all calls to the
> obsolated init_consistent_dma_size() function and finally removes the
> init_consistent_dma_size() stub itself.
>
> Arnd, Olof: could You apply it to arm-soc cleanup branch?
The omap patch in this series is no longer needed as soon as
Arnd and Olof pull in the pending omap pull requests I sent.
Regards,
Tony
^ permalink raw reply
* [PATCH V2 01/14] ARM: OMAP: Add DMTIMER definitions for posted mode
From: Jon Hunter @ 2012-11-08 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509ADAFE.4070109@ti.com>
On 11/07/2012 04:04 PM, Santosh Shilimkar wrote:
> On Wednesday 07 November 2012 01:01 PM, Jon Hunter wrote:
>> For OMAP2+ devices, when using DMTIMERs for system timers
>> (clock-events and
>> clock-source) the posted mode configuration of the timers is used. To
>> allow
>> the compiler to optimise the functions for configuring and reading the
>> system
>> timers, the posted flag variable is hard-coded with the value 1. To
>> make it
>> clear that posted mode is being used add some definitions so that it
>> is more
>> readable.
>>
>> Add separate definitions for the clock-events and clock-source timers
>> so that
>> we can change the posted mode of clock-events and clock-source
>> independently.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>> arch/arm/mach-omap2/timer.c | 26
>> +++++++++++++++++++-------
>> arch/arm/plat-omap/include/plat/dmtimer.h | 4 ++++
>> 2 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 0758bae..28c6078 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -82,6 +82,13 @@
>> #define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
>> #define NUMERATOR_DENUMERATOR_MASK 0xfffff000
>>
>> +/*
>> + * For clock-events timer, always use posted mode to
>> + * minimise CPU overhead for configuring the timer.
>> + */
>> +#define OMAP_CLKEVT_POSTEDMODE OMAP_TIMER_POSTED
>> +#define OMAP_CLKSRC_POSTEDMODE OMAP_TIMER_POSTED
>> +
> I don't see need of above defines. Just use OMAP_TIMER_POSTED directly
> with API. Rest of the patch looks fine.
>
> Apart from above one comment,
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Ok, updated and dropped the additional definitions. Let me know if you
are ok with this.
Cheers
Jon
>From f1c783b5af933374431bcb8acb01d0b5c79d5661 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Thu, 27 Sep 2012 11:49:45 -0500
Subject: [PATCH 1/2] ARM: OMAP: Add DMTIMER definitions for posted mode
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/timer.c | 17 ++++++++++-------
arch/arm/plat-omap/include/plat/dmtimer.h | 4 ++++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0758bae..ad427ba 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -107,7 +107,7 @@ static int omap2_gp_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
__omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_ST,
- 0xffffffff - cycles, 1);
+ 0xffffffff - cycles, OMAP_TIMER_POSTED);
return 0;
}
@@ -117,7 +117,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
{
u32 period;
- __omap_dm_timer_stop(&clkev, 1, clkev.rate);
+ __omap_dm_timer_stop(&clkev, OMAP_TIMER_POSTED, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -125,10 +125,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
period -= 1;
/* Looks like we need to first set the load value separately */
__omap_dm_timer_write(&clkev, OMAP_TIMER_LOAD_REG,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
__omap_dm_timer_load_start(&clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -358,7 +358,8 @@ static bool use_gptimer_clksrc;
*/
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(&clksrc, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
}
static struct clocksource clocksource_gpt = {
@@ -372,7 +373,8 @@ static struct clocksource clocksource_gpt = {
static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
- return __omap_dm_timer_read_counter(&clksrc, 1);
+ return __omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
return 0;
}
@@ -454,7 +456,8 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_TIMER_POSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 348f855..835c3bdf 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE 0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x80000000
#define OMAP_TIMER_ALWON 0x40000000
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
From: Jon Hunter @ 2012-11-08 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509AF21C.7020105@ti.com>
On 11/07/2012 05:43 PM, Santosh Shilimkar wrote:
> On Wednesday 07 November 2012 05:28 PM, Jon Hunter wrote:
>>
>> On 11/07/2012 04:14 PM, Santosh Shilimkar wrote:
>>
>>> Looks sensible considering alternative WAs.
>>>
>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> Thanks. With further thought I think that it would be best to combine
>> patches #2 and #3. Really the main motivation here is the errata
>> workaround and without actually benchmarking the timer read I should
>> not claim the improvement in overhead as stated in patch #2. So I
>> have combined #2 and #3 and updated the changelog/comments
>> appropriately. Let me know if you guys are ok with this.
>>
> Yep. Sounds good.
Updated, removing the additional OMAP_CLKEVT/SRC_POSTEDMODE definitions.
Cheers
Jon
>From 5b55c6c2ca6f41e37f531d8ca0ea80a0e49f3e4d Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Thu, 27 Sep 2012 12:47:43 -0500
Subject: [PATCH 2/2] ARM: OMAP3+: Implement timer workaround for errata i103
and i767
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/timer.c | 35 +++++++++++++----
arch/arm/plat-omap/dmtimer.c | 59 ++++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/dmtimer.h | 19 ++++++++--
3 files changed, 100 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ad427ba..e99b95c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,7 +224,8 @@ void __init omap_dmtimer_init(void)
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int gptimer_id,
const char *fck_source,
- const char *property)
+ const char *property,
+ int posted)
{
char name[10]; /* 10 = sizeof("gptXX_Xck0") */
const char *oh_name;
@@ -310,10 +311,15 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
- timer->posted = 1;
- timer->rate = clk_get_rate(timer->fclk);
+ if (posted)
+ omap_dm_timer_enable_posted(timer);
+ /* Check that the intended posted configuration matches the actual */
+ if (posted != timer->posted)
+ return -EINVAL;
+
+ timer->rate = clk_get_rate(timer->fclk);
timer->reserved = 1;
return res;
@@ -325,7 +331,17 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property);
+ omap_dm_timer_populate_errata(&clkev);
+
+ /*
+ * For clock-event timers we never read the timer counter and
+ * so we are not impacted by errata i103 and i767. Therefore,
+ * we can safely ignore this errata for clock-event timers.
+ */
+ omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
+
+ res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
+ OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = &clkev;
@@ -359,7 +375,7 @@ static bool use_gptimer_clksrc;
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
}
static struct clocksource clocksource_gpt = {
@@ -374,7 +390,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
return __omap_dm_timer_read_counter(&clksrc,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
return 0;
}
@@ -452,12 +468,15 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL);
+ omap_dm_timer_populate_errata(&clksrc);
+
+ res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+ OMAP_TIMER_NONPOSTED);
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index b09e556..4abbbe5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -131,8 +131,8 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
}
__omap_dm_timer_reset(timer, 0, 0);
+ omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);
- timer->posted = 1;
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
@@ -176,6 +176,61 @@ int omap_dm_timer_reserve_systimer(int id)
return 0;
}
+/**
+ * omap_dm_timer_populate_errata - populate errata flags for a timer
+ * @timer: pointer to timer handle
+ *
+ * For a given timer, populate the timer errata flags that are specific to the
+ * OMAP device being used.
+ */
+void omap_dm_timer_populate_errata(struct omap_dm_timer *timer)
+{
+ timer->errata = 0;
+
+ if (cpu_class_is_omap1() || cpu_is_omap24xx())
+ return;
+
+ timer->errata = OMAP_TIMER_ERRATA_I103_I767;
+}
+
+/**
+ * omap_dm_timer_override_errata - override errata flags for a timer
+ * @timer: pointer to timer handle
+ * @errata: errata flags to be ignored
+ *
+ * For a given timer, override a timer errata by clearing the flags specified
+ * by the errata argument. A specific erratum should only be overridden for a
+ * timer if the timer is used in such a way the erratum has no impact.
+ */
+void omap_dm_timer_override_errata(struct omap_dm_timer *timer, u32 errata)
+{
+ timer->errata &= ~errata;
+}
+
+/*
+ * omap_dm_timer_enable_posted - enables write posted mode
+ * @timer: pointer to timer instance handle
+ *
+ * Enables the write posted mode for the timer. When posted mode is enabled
+ * writes to certain timer registers are immediately acknowledged by the
+ * internal bus and hence prevents stalling the CPU waiting for the write to
+ * complete. Enabling this feature can improve performance for writing to the
+ * timer registers.
+ */
+void omap_dm_timer_enable_posted(struct omap_dm_timer *timer)
+{
+ if (timer->posted)
+ return;
+
+ if (timer->errata & OMAP_TIMER_ERRATA_I103_I767)
+ return;
+
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG,
+ OMAP_TIMER_CTRL_POSTED);
+ timer->context.tsicr = OMAP_TIMER_CTRL_POSTED;
+ timer->posted = OMAP_TIMER_POSTED;
+}
+
struct omap_dm_timer *omap_dm_timer_request(void)
{
struct omap_dm_timer *timer = NULL, *t;
@@ -803,6 +858,8 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
timer->irq = irq->start;
timer->pdev = pdev;
+ omap_dm_timer_populate_errata(timer);
+
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
pm_runtime_enable(dev);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 835c3bdf..ef93017 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -36,6 +36,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/platform_device.h>
+#include <plat/cpu.h>
#ifndef __ASM_ARCH_DMTIMER_H
#define __ASM_ARCH_DMTIMER_H
@@ -66,6 +67,16 @@
#define OMAP_TIMER_NEEDS_RESET 0x10000000
#define OMAP_TIMER_HAS_DSP_IRQ 0x08000000
+/*
+ * timer errata flags
+ *
+ * Errata i103/i767 impacts all OMAP3/4/5 devices including AM33xx. This
+ * errata prevents us from using posted mode on these devices, unless the
+ * timer counter register is never read. For more details please refer to
+ * the OMAP3/4/5 errata documents.
+ */
+#define OMAP_TIMER_ERRATA_I103_I767 0x80000000
+
struct omap_timer_capability_dev_attr {
u32 timer_capability;
};
@@ -101,6 +112,9 @@ struct dmtimer_platform_data {
};
int omap_dm_timer_reserve_systimer(int id);
+void omap_dm_timer_populate_errata(struct omap_dm_timer *timer);
+void omap_dm_timer_override_errata(struct omap_dm_timer *timer, u32 errata);
+void omap_dm_timer_enable_posted(struct omap_dm_timer *timer);
struct omap_dm_timer *omap_dm_timer_request(void);
struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap);
@@ -271,6 +285,7 @@ struct omap_dm_timer {
int ctx_loss_count;
int revision;
u32 capability;
+ u32 errata;
struct platform_device *pdev;
struct list_head node;
};
@@ -342,10 +357,6 @@ static inline void __omap_dm_timer_reset(struct omap_dm_timer *timer,
l |= 1 << 2;
__raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
-
- /* Match hardware reset default of posted mode */
- __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
- OMAP_TIMER_CTRL_POSTED, 0);
}
static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] Add support of the PCA9555 to the CFA-10049
From: Maxime Ripard @ 2012-11-08 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This is an attempt to add support for the PCA9555
present in the CFA-10049 board from Crystalfontz.
The driver was supporting neither irqdomains nor dt, so
the first two patches are adding them.
Thanks,
Maxime
Maxime Ripard (3):
gpio: pca953x: Register an IRQ domain
gpio: pca953x: Add compatible strings to gpio-pca953x driver
ARM: dts: cfa10049: Add PCA9555 GPIO expander to the device tree
arch/arm/boot/dts/imx28-cfa10049.dts | 26 +++++++++++++++-
drivers/gpio/gpio-pca953x.c | 55 ++++++++++++++++++++++++++++++----
2 files changed, 74 insertions(+), 7 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/3] gpio: pca953x: Register an IRQ domain
From: Maxime Ripard @ 2012-11-08 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352394113-19513-1-git-send-email-maxime.ripard@free-electrons.com>
The PCA953x used to register no IRQ domain, which made it impossible to
use it as an interrupt-parent from the device tree.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpio/gpio-pca953x.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 9c693ae..5ba7e60 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -16,6 +16,7 @@
#include <linux/gpio.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/i2c.h>
#include <linux/i2c/pca953x.h>
#include <linux/slab.h>
@@ -83,6 +84,7 @@ struct pca953x_chip {
u32 irq_trig_raise;
u32 irq_trig_fall;
int irq_base;
+ struct irq_domain *domain;
#endif
struct i2c_client *client;
@@ -333,14 +335,14 @@ static void pca953x_irq_mask(struct irq_data *d)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- chip->irq_mask &= ~(1 << (d->irq - chip->irq_base));
+ chip->irq_mask &= ~(1 << d->hwirq);
}
static void pca953x_irq_unmask(struct irq_data *d)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- chip->irq_mask |= 1 << (d->irq - chip->irq_base);
+ chip->irq_mask |= 1 << d->hwirq;
}
static void pca953x_irq_bus_lock(struct irq_data *d)
@@ -372,8 +374,7 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
static int pca953x_irq_set_type(struct irq_data *d, unsigned int type)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- u32 level = d->irq - chip->irq_base;
- u32 mask = 1 << level;
+ u32 mask = 1 << d->hwirq;
if (!(type & IRQ_TYPE_EDGE_BOTH)) {
dev_err(&chip->client->dev, "irq %d: unsupported type %d\n",
@@ -454,7 +455,7 @@ static irqreturn_t pca953x_irq_handler(int irq, void *devid)
do {
level = __ffs(pending);
- handle_nested_irq(level + chip->irq_base);
+ handle_nested_irq(irq_find_mapping(chip->domain, level));
pending &= ~(1 << level);
} while (pending);
@@ -499,6 +500,17 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (chip->irq_base < 0)
goto out_failed;
+ chip->domain = irq_domain_add_legacy(client->dev.of_node,
+ chip->gpio_chip.ngpio,
+ chip->irq_base,
+ 0,
+ &irq_domain_simple_ops,
+ NULL);
+ if (!chip->domain) {
+ ret = -ENODEV;
+ goto out_irqdesc_free;
+ }
+
for (lvl = 0; lvl < chip->gpio_chip.ngpio; lvl++) {
int irq = lvl + chip->irq_base;
@@ -521,7 +533,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (ret) {
dev_err(&client->dev, "failed to request irq %d\n",
client->irq);
- goto out_failed;
+ goto out_irqdesc_free;
}
chip->gpio_chip.to_irq = pca953x_gpio_to_irq;
@@ -529,6 +541,8 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return 0;
+out_irqdesc_free:
+ irq_free_descs(chip->irq_base, chip->gpio_chip.ngpio);
out_failed:
chip->irq_base = -1;
return ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] gpio: pca953x: Add compatible strings to gpio-pca953x driver
From: Maxime Ripard @ 2012-11-08 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352394113-19513-1-git-send-email-maxime.ripard@free-electrons.com>
Even though the device tree binding code was already written, the
compatible strings were not yet in the driver.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpio/gpio-pca953x.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 5ba7e60..0c5eaf5 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -765,9 +765,38 @@ static int pca953x_remove(struct i2c_client *client)
return 0;
}
+static const struct of_device_id pca953x_dt_ids[] = {
+ { .compatible = "nxp,pca9534", },
+ { .compatible = "nxp,pca9535", },
+ { .compatible = "nxp,pca9536", },
+ { .compatible = "nxp,pca9537", },
+ { .compatible = "nxp,pca9538", },
+ { .compatible = "nxp,pca9539", },
+ { .compatible = "nxp,pca9554", },
+ { .compatible = "nxp,pca9555", },
+ { .compatible = "nxp,pca9556", },
+ { .compatible = "nxp,pca9557", },
+ { .compatible = "nxp,pca9574", },
+ { .compatible = "nxp,pca9575", },
+
+ { .compatible = "maxim,max7310", },
+ { .compatible = "maxim,max7312", },
+ { .compatible = "maxim,max7313", },
+ { .compatible = "maxim,max7315", },
+
+ { .compatible = "ti,pca6107", },
+ { .compatible = "ti,tca6408", },
+ { .compatible = "ti,tca6416", },
+ { .compatible = "ti,tca6424", },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, pca953x_dt_ids);
+
static struct i2c_driver pca953x_driver = {
.driver = {
.name = "pca953x",
+ .of_match_table = pca953x_dt_ids,
},
.probe = pca953x_probe,
.remove = pca953x_remove,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: cfa10049: Add PCA9555 GPIO expander to the device tree
From: Maxime Ripard @ 2012-11-08 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352394113-19513-1-git-send-email-maxime.ripard@free-electrons.com>
Add the GPIO expander found on the i2c1 bus, behind the muxer to the
device tree.
This gpio expander will be used to get tachymeters values and data ready
interruptions from the nuvoton NAU7802 ADCs.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index bdc80a4..714953b 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -22,8 +22,9 @@
apb at 80000000 {
apbh at 80000000 {
pinctrl at 80018000 {
- pinctrl-names = "default", "default";
+ pinctrl-names = "default", "default", "default";
pinctrl-1 = <&hog_pins_cfa10049>;
+ pinctrl-2 = <&hog_pins_cfa10049_pullup>;
hog_pins_cfa10049: hog-10049 at 0 {
reg = <0>;
@@ -38,6 +39,16 @@
fsl,pull-up = <0>;
};
+ hog_pins_cfa10049_pullup: hog-10049-pullup at 0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x2133 /* MX28_PAD_SSP2_D3__GPIO_2_19 */
+ >;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <1>;
+ };
+
spi3_pins_cfa10049: spi3-cfa10049 at 0 {
reg = <0>;
fsl,pinmux-ids = <
@@ -113,6 +124,19 @@
i2c@3 {
reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9555: pca9555 at 20 {
+ compatible = "nxp,pca9555";
+ interrupt-parent = <&gpio2>;
+ interrupts = <19 0x2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x20>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox