* [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for
APB DMA controllers and make it compatible with "nvidia,tegra114-apbdma".
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 9ce1a68..74f6a77 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -37,6 +37,43 @@
reg = <0x6000c004 0x14c>;
};
+ apbdma: dma {
+ compatible = "nvidia,tegra114-apbdma";
+ reg = <0x6000a000 0x1400>;
+ interrupts = <0 104 0x04
+ 0 105 0x04
+ 0 106 0x04
+ 0 107 0x04
+ 0 108 0x04
+ 0 109 0x04
+ 0 110 0x04
+ 0 111 0x04
+ 0 112 0x04
+ 0 113 0x04
+ 0 114 0x04
+ 0 115 0x04
+ 0 116 0x04
+ 0 117 0x04
+ 0 118 0x04
+ 0 119 0x04
+ 0 128 0x04
+ 0 129 0x04
+ 0 130 0x04
+ 0 131 0x04
+ 0 132 0x04
+ 0 133 0x04
+ 0 134 0x04
+ 0 135 0x04
+ 0 136 0x04
+ 0 137 0x04
+ 0 138 0x04
+ 0 139 0x04
+ 0 140 0x04
+ 0 141 0x04
+ 0 142 0x04
+ 0 143 0x04>;
+ };
+
gpio: gpio {
compatible = "nvidia,tegra114-gpio", "nvidia,tegra30-gpio";
reg = <0x6000d000 0x1000>;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 2/7] ARM: DT: tegra114: add GPIO DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
Tegra114 has the GPIO controllers with 8 GPIO bank and each bank
supports 32 pins.
Add DT entry for GPIO controller. Tegra114 GPIO controller is
compatible with Tegra30 GPIO controller driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 96a8235..9ce1a68 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -37,6 +37,23 @@
reg = <0x6000c004 0x14c>;
};
+ gpio: gpio {
+ compatible = "nvidia,tegra114-gpio", "nvidia,tegra30-gpio";
+ reg = <0x6000d000 0x1000>;
+ interrupts = <0 32 0x04
+ 0 33 0x04
+ 0 34 0x04
+ 0 35 0x04
+ 0 55 0x04
+ 0 87 0x04
+ 0 89 0x04
+ 0 125 0x04>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
serial at 70006000 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006000 0x40>;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/7] ARM: tegra114: select PINCTRL for Tegra114 SoC
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
Select PINCTRL and PINCTRL_TEGRA114 for enabling Tegra114 pincontrol
driver for Tegra114 SoC.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/mach-tegra/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index eada60f..bde8197 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -51,6 +51,8 @@ config ARCH_TEGRA_114_SOC
select CPU_V7
select ARM_L1_CACHE_SHIFT_6
select ARM_ARCH_TIMER
+ select PINCTRL
+ select PINCTRL_TEGRA114
help
Support for NVIDIA Tegra T114 processor family, based on the
ARM CortexA15MP CPU
--
1.7.1.1
^ permalink raw reply related
* [PATCH 0/7] ARM: DT: tegra114: add dt entry for gpio/pinmux/dma/i2c/serial/kbc
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
This series add DT entry for the NVIDIA's Tegra114 SoCs for the following
controller:
- GPIO controller
- DMA controller.
- Pinmux controller.
- I2c controller.
- KBC controler.
Also add dma requestor and aliases for serial channel.
Laxman Dewangan (7):
ARM: tegra114: select PINCTRL for Tegra114 SoC
ARM: DT: tegra114: add GPIO DT entry
ARM: DT: tegra114: add APB DMA controller DT entry
ARM: DT: tegra114: add pinmux DT entry
ARM: DT: tegra114: Add i2c controller DT entry
ARM: DT: tegra114:add aliases and DMA requestor for serial controller
ARM: DT: tegra114: add KBC controller DT entry
arch/arm/boot/dts/tegra114.dtsi | 139 +++++++++++++++++++++++++++++++++++++-
arch/arm/mach-tegra/Kconfig | 2 +
2 files changed, 137 insertions(+), 4 deletions(-)
^ permalink raw reply
* [v2 1/1] ARM: dma-mapping: Call arm_dma_set_mask() if no ->set_dma_mask()
From: Marek Szyprowski @ 2013-01-29 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359462438-21006-1-git-send-email-hdoyu@nvidia.com>
Hello,
On 1/29/2013 1:27 PM, Hiroshi Doyu wrote:
> struct dma_map_ops iommu_ops doesn't have ->set_dma_mask, which causes
> crash when dma_set_mask() is called from some driver.
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> ---
> arch/arm/include/asm/dma-mapping.h | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 5b579b9..63cc49c 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -14,6 +14,7 @@
> #define DMA_ERROR_CODE (~0)
> extern struct dma_map_ops arm_dma_ops;
> extern struct dma_map_ops arm_coherent_dma_ops;
> +extern int arm_dma_set_mask(struct device *dev, u64 dma_mask);
>
> static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> {
> @@ -32,7 +33,13 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
>
> static inline int dma_set_mask(struct device *dev, u64 mask)
> {
> - return get_dma_ops(dev)->set_dma_mask(dev, mask);
> + struct dma_map_ops *ops = get_dma_ops(dev);
> + BUG_ON(!ops);
> +
> + if (ops->set_dma_mask)
> + return ops->set_dma_mask(dev, mask);
> +
> + return arm_dma_set_mask(dev, mask);
> }
>
> #ifdef __arch_page_to_dma
> @@ -112,8 +119,6 @@ static inline void dma_free_noncoherent(struct device *dev, size_t size,
>
> extern int dma_supported(struct device *dev, u64 mask);
>
> -extern int arm_dma_set_mask(struct device *dev, u64 dma_mask);
> -
> /**
> * arm_dma_alloc - allocate consistent memory for DMA
> * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
It can be done much simpler, please just add '.set_dma_mask =
arm_dma_set_mask,'
to iommu_ops declaration. There is no point complicating the header files.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] ARM: let CPUs not being able to run in ARM mode enter in THUMB mode
From: Dave Martin @ 2013-01-29 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357904397-8476-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-K?nig wrote:
> Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> obviously these cannot enter the kernel in ARM mode. Make an exception
> for them and let them enter in THUMB mode.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> arch/arm/kernel/head-nommu.S | 8 +++++++-
> arch/arm/kernel/head.S | 8 +++++++-
> arch/arm/mm/Kconfig | 6 ++++++
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 3782320..ae7ed46 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -32,15 +32,21 @@
> * numbers for r1.
> *
> */
> - .arm
>
> __HEAD
> +
> +#ifdef CONFIG_THUMBONLY_CPU
> + .thumb
> +ENTRY(stext)
> +#else
> + .arm
> ENTRY(stext)
>
> THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.
> THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> THUMB( .thumb ) @ switch to Thumb now.
> THUMB(1: )
> +#endif
The behaviour is that we start the file is kernel entry state, then
we switch to kernel run state.
The switch is only needed for kernels which run on CPUs supporting
both states, where the run state is not ARM.
So, it would be neater for these entry sequences to look something
like:
HAS_ARM(.arm) @ because -mthumb is default for Thumb kernels anyway
ENTRY(stext)
HAS_ARM(THUMB( @ code to switch to Thumb ))
@ real code starts here, in run state.
Where
#ifdef CONFIG_THUMBONLY_CPU
#define HAS_ARM(x...)
#else
#define HAS_ARM(x...) x
#endif
(I haven't read the whole thread yet, so decisions about what
config variables and macro names should be used may be overridden
by other people...)
Thoughts?
Cheers
---Dave
^ permalink raw reply
* [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Mugunthan V N @ 2013-01-29 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129073626.GB18272@localhost.localdomain>
On 1/29/2013 1:06 PM, Richard Cochran wrote:
> On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
>> @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = {
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> .ndo_poll_controller = cpsw_ndo_poll_controller,
>> #endif
>> +#ifdef VLAN_SUPPORT
>> + .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
>> + .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
>> +#endif
> These are not compile time conditionals in net_device_ops, so I wonder
> (after reading Felipe's comments) whether you can simply keep the VLAN
> code always present.
>
> As long as the driver still compiles and loads, when VLAN is missing
> from the stack, then I don't see why you can't just leave it in,
> without all the ifdefs.
>
> Thanks,
> Richard
This idea seems to be good. I will update the patch in next version.
Regards
Mugunthan V N
^ permalink raw reply
* [v2 1/1] ARM: dma-mapping: Call arm_dma_set_mask() if no ->set_dma_mask()
From: Hiroshi Doyu @ 2013-01-29 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107B301.2060802@samsung.com>
struct dma_map_ops iommu_ops doesn't have ->set_dma_mask, which causes
crash when dma_set_mask() is called from some driver.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/include/asm/dma-mapping.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..63cc49c 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -14,6 +14,7 @@
#define DMA_ERROR_CODE (~0)
extern struct dma_map_ops arm_dma_ops;
extern struct dma_map_ops arm_coherent_dma_ops;
+extern int arm_dma_set_mask(struct device *dev, u64 dma_mask);
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
{
@@ -32,7 +33,13 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
static inline int dma_set_mask(struct device *dev, u64 mask)
{
- return get_dma_ops(dev)->set_dma_mask(dev, mask);
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ BUG_ON(!ops);
+
+ if (ops->set_dma_mask)
+ return ops->set_dma_mask(dev, mask);
+
+ return arm_dma_set_mask(dev, mask);
}
#ifdef __arch_page_to_dma
@@ -112,8 +119,6 @@ static inline void dma_free_noncoherent(struct device *dev, size_t size,
extern int dma_supported(struct device *dev, u64 mask);
-extern int arm_dma_set_mask(struct device *dev, u64 dma_mask);
-
/**
* arm_dma_alloc - allocate consistent memory for DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Russell King - ARM Linux @ 2013-01-29 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129114926.GA14624@bnru10>
On Tue, Jan 29, 2013 at 05:19:27PM +0530, Srinidhi Kasagar wrote:
> On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
> > On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> > > Add 'smc' (Secure Monitor Call) identifier to differentiates
> > > the platforms which implements this.
> >
> > This patch makes no sense.
> >
> > So, if setting 'smc' in the DT description is supposed to mean that
> > the platform has a secure monitor then...
> >
> > > + is_smc = of_property_read_bool(np, "smc");
> > > +
> > > + if (is_smc) {
> > > + /* set the debug interface */
> > > + outer_cache.set_debug = pl310_set_debug;
> > > + }
> >
> > Now, let's look at what pl310_set_debug() does:
> >
> > static void pl310_set_debug(unsigned long val)
> > {
> > writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
>
> You can do this operation (write to DEBUG_CTRL) only if SMC is implemented.
Err... no. You can do it if you're running in secure mode without a
secure monitor, because the security stuff doesn't get in the way.
What other platforms do is up to them, and up to *how* the secure monitor
is implemented, not *if*.
> > }
> >
> > Can you explain where the secure monitor call is there please, because
> > I can't see one. In fact, this is the function used when there _isn't_
> > a secure monitor. So this patch just seems totally wrong to me.
So this is going to be difficult because you only ever answer half an
email? So, I repeat the question above.
^ permalink raw reply
* Section mismatch in drivers/mfd/vexpress-sysreg.c
From: Russell King - ARM Linux @ 2013-01-29 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129115535.GH21504@S2101-09.ap.freescale.net>
On Tue, Jan 29, 2013 at 07:55:37PM +0800, Shawn Guo wrote:
> Pawel,
>
> I'm building v3.8-rc5 and seeing the following section mismatch warning
> in drivers/mfd/vexpress-sysreg.c.
>
> WARNING: drivers/mfd/built-in.o(.text+0x3108): Section mismatch in reference from the function vexpress_sysreg_probe() to the function .init.text:vexpress_sysreg_setup()
> The function vexpress_sysreg_probe() references
> the function __init vexpress_sysreg_setup().
> This is often because vexpress_sysreg_probe lacks a __init
> annotation or the annotation of vexpress_sysreg_setup is wrong.
I've already reported this - it's been around for a while now.
^ permalink raw reply
* [PATCH v2] ARM: imx: clk-imx27: Do not register peripheral clock for SSI
From: Fabio Estevam @ 2013-01-29 12:17 UTC (permalink / raw)
To: linux-arm-kernel
imx ssi block has two types of clocks:
- ipg: bus clock, the clock needed for accessing registers.
- per: peripheral clock, the clock needed for generating the bit rate.
Currently ssi driver only supports slave mode and thus need only to handle
the ipg clock, because the peripheral clock comes from the master codec.
Only register the ipg clock and do not register the peripheral clock for ssi
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Fix typo in email address in the From field
arch/arm/mach-imx/clk-imx27.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 1ffe3b534..303d7bd 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -274,8 +274,6 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[scc_ipg_gate], "scc", NULL);
clk_register_clkdev(clk[cpu_div], "cpu", NULL);
clk_register_clkdev(clk[emi_ahb_gate], "emi_ahb" , NULL);
- clk_register_clkdev(clk[ssi1_baud_gate], "bitrate" , "imx-ssi.0");
- clk_register_clkdev(clk[ssi2_baud_gate], "bitrate" , "imx-ssi.1");
mxc_timer_init(MX27_IO_ADDRESS(MX27_GPT1_BASE_ADDR), MX27_INT_GPT1);
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Russell King - ARM Linux @ 2013-01-29 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <34874167.ghObrToI03@fb07-iapwap2>
On Tue, Jan 29, 2013 at 12:43:20PM +0100, Egon Alter wrote:
> Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux:
> > On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
> > > What's this "with enabled unaligned memory access" thing? You mean "if
> > > the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
> > > that's only x86, which isn't really in the target market for this
> > > patch, yes?
> > >
> > > It's a lot of code for a 50ms boot-time improvement. Does anyone have
> > > any opinions on whether or not the benefits are worth the cost?
> >
> > Well... when I saw this my immediate reaction was "oh no, yet another
> > decompressor for the kernel". We have five of these things already.
> > Do we really need a sixth?
> >
> > My feeling is that we should have:
> > - one decompressor which is the fastest
> > - one decompressor for the highest compression ratio
> > - one popular decompressor (eg conventional gzip)
>
> the problem gets more complicated as the "fastest" decompressor usually
> creates larger images which need more time to load from the storage, e.g. a
> one MB larger image on a 10 MB/s storage (note: bootloaders often configure
> the storage controllers in slow modes) gives 100 ms more boot time, thus
> eating the gain of a "fast decompressor".
Ok.
We already have:
- lzma: 33% smaller than gzip, decompression speed between gzip and bzip2
- xz: 30% smaller than gzip, decompression speed similar to lzma
- bzip2: 10% smaller than gzip, slowest decompression
- gzip: reference implementation
- lzo: 10% bigger than gzip, fastest
And now:
- lz4: 8% bigger than lzo, 16% faster than lzo?
(I make that 16% bigger than gzip)
So, image size wise, on a 2MB compressed gzip image, we're looking at
the difference between LZO at 2.2MB and LZ4 at 2.38MB.
But let's not stop there - the figures given for a 13MB decompressed
image were:
lzo: 6.3MB, 301ms
lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access)
At 10MB/s (your figure), it takes .68s to read 6.8MB as opposed to .63s
for LZO. So, totalling up these figures gives to give the overall figure:
lzo: 301ms + 630ms = 931ms
lz4: 167ms + 680ms = 797ms
Which gives the tradeoff at 10MB/s of 14% faster (but only with efficient
unaligned memory access.) So... this faster decompressor is still the
fastest even with your media transfer rate factored in.
That gives an argument for replacing lzo with lz4...
^ permalink raw reply
* [PATCH] ARM: imx: clk-imx27: Do not register peripheral clock for SSI
From: Fabio Estevam @ 2013-01-29 12:14 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>>
imx ssi block has two types of clocks:
- ipg: bus clock, the clock needed for accessing registers.
- per: peripheral clock, the clock needed for generating the bit rate.
Currently ssi driver only supports slave mode and thus need only to handle
the ipg clock, because the peripheral clock comes from the master codec.
Only register the ipg clock and do not register the peripheral clock for ssi
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/clk-imx27.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 1ffe3b534..303d7bd 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -274,8 +274,6 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[scc_ipg_gate], "scc", NULL);
clk_register_clkdev(clk[cpu_div], "cpu", NULL);
clk_register_clkdev(clk[emi_ahb_gate], "emi_ahb" , NULL);
- clk_register_clkdev(clk[ssi1_baud_gate], "bitrate" , "imx-ssi.0");
- clk_register_clkdev(clk[ssi2_baud_gate], "bitrate" , "imx-ssi.1");
mxc_timer_init(MX27_IO_ADDRESS(MX27_GPT1_BASE_ADDR), MX27_INT_GPT1);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Mugunthan V N @ 2013-01-29 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359452926.4336.1.camel@coredoba.hi.pengutronix.de>
On 1/29/2013 3:18 PM, Jan L?bbe wrote:
> On Tue, 2013-01-29 at 01:42 +0530, Mugunthan V N wrote:
>> --- a/Documentation/devicetree/bindings/net/cpsw.txt
>> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
>> @@ -24,6 +24,8 @@ Required properties:
>> Optional properties:
>> - ti,hwmods : Must be "cpgmac0"
>> - no_bd_ram : Must be 0 or 1
>> +- default_vlan : Specifies Default VLAN for non tagged packets
>> + ALE processing
> This does not seem to be a property of the hardware. Could there be a
> reasonable default for it?
>
> Regards,
> Jan
Jan
In VLAN aware mode, ALE always process only VLAN tagged packets. Even
untagged packets
In hardware you can use any VLAN id for default (non tagged packet)
filtering.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
From: Vishwanathrao Badarkhe, Manish @ 2013-01-29 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbf7TwrjfT2rhqQFGc3yh_Nt117RtzQO2y6g5Ddx5Ay_w@mail.gmail.com>
Hi Linus,
On Tue, Jan 29, 2013 at 16:29:54, Linus Walleij wrote:
> On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish <manishv.b@ti.com> wrote:
>
> > Currently, I2C driver gets probed before pinctrl driver.
> > To achieve I2C pin muxing via pinctrl driver before I2C probe get
> > called, register pinctrl driver in arch_initcall.
> > Also, add module_exit to unregister pinctrl driver.
> >
> > Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>
> So your I2C driver is not returning -EPROBE_DEFER if it cannot find its pins?
Yes. In Davinci I2C driver, it's not implemented to return -EPROBE_DEFER if it
can't find its pins.
Please see below discussion for more details:
https://patchwork2.kernel.org/patch/2031321/
>
> Hm, well I can live with this, if Tony ACKs it.
>
> Yours,
> Linus Walleij
>
Regards,
Manish
^ permalink raw reply
* Section mismatch in drivers/mfd/vexpress-sysreg.c
From: Shawn Guo @ 2013-01-29 11:55 UTC (permalink / raw)
To: linux-arm-kernel
Pawel,
I'm building v3.8-rc5 and seeing the following section mismatch warning
in drivers/mfd/vexpress-sysreg.c.
WARNING: drivers/mfd/built-in.o(.text+0x3108): Section mismatch in reference from the function vexpress_sysreg_probe() to the function .init.text:vexpress_sysreg_setup()
The function vexpress_sysreg_probe() references
the function __init vexpress_sysreg_setup().
This is often because vexpress_sysreg_probe lacks a __init
annotation or the annotation of vexpress_sysreg_setup is wrong.
Shawn
^ permalink raw reply
* [PATCH, RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Alexander Shishkin @ 2013-01-29 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359458548-25071-1-git-send-email-s.hauer@pengutronix.de>
Sascha Hauer <s.hauer@pengutronix.de> writes:
> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>
> This adds two little devicetree helper functions for determining the
> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> the devicetree.
>
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
>
> The properties and their values have been taken from the fsl-mph-dr driver.
> This binding is also documented (though currently not used) for the tegra
> ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> This is a first attempt to parse these bindings at a common place so that
> others can make use of it.
>
> Basically I want to know whether this binding is recommended for new drivers
> since normally the devicetree uses '-' instead of '_', and maybe there are
> other problems with it.
>
> I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> driver also really handles a chipidea core.
As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
probably confirm.
> Should we agree on this I would convert the fsl-mph-dr driver to use these
> helpers.
>
> Sascha
>
> drivers/usb/core/Makefile | 1 +
> drivers/usb/core/of.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/of.h | 22 +++++++++++++
> include/linux/usb/phy.h | 9 ++++++
> 4 files changed, 108 insertions(+)
> create mode 100644 drivers/usb/core/of.c
> create mode 100644 include/linux/usb/of.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 26059b9..5378add 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -10,5 +10,6 @@ usbcore-y += devio.o notify.o generic.o quirks.o devices.o
>
> usbcore-$(CONFIG_PCI) += hcd-pci.o
> usbcore-$(CONFIG_ACPI) += usb-acpi.o
> +usbcore-$(CONFIG_OF) += of.o
>
> obj-$(CONFIG_USB) += usbcore.o
> diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> new file mode 100644
> index 0000000..d000d9f
> --- /dev/null
> +++ b/drivers/usb/core/of.c
> @@ -0,0 +1,76 @@
> +/*
> + * OF helpers for usb devices.
> + *
> + * This file is released under the GPLv2
> + *
> + * Initially copied out of drivers/of/of_net.c
> + */
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/usb/of.h>
> +#include <linux/usb/phy.h>
> +#include <linux/export.h>
> +
> +static const char *usbphy_modes[] = {
> + [USBPHY_INTERFACE_MODE_NA] = "",
> + [USBPHY_INTERFACE_MODE_UTMI] = "utmi",
> + [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
> + [USBPHY_INTERFACE_MODE_ULPI] = "ulpi",
> + [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
> + [USBPHY_INTERFACE_MODE_HSIC] = "hsic",
> +};
> +
> +/**
> + * of_get_usbphy_mode - Get phy mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'phy_type',
> + * and returns the correspondig enum usb_phy_interface
> + */
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> +{
> + const char *phy_type;
> + int err, i;
> +
> + err = of_property_read_string(np, "phy_type", &phy_type);
> + if (err < 0)
> + return USBPHY_INTERFACE_MODE_NA;
> +
> + for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
> + if (!strcasecmp(phy_type, usbphy_modes[i]))
> + return i;
> +
> + return USBPHY_INTERFACE_MODE_NA;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_phy_mode);
> +
> +static const char *usb_dr_modes[] = {
> + [USB_DR_MODE_UNKNOWN] = "",
> + [USB_DR_MODE_HOST] = "host",
> + [USB_DR_MODE_PERIPHERAL] = "peripheral",
> + [USB_DR_MODE_OTG] = "otg",
> +};
> +
> +/**
> + * of_usb_get_dr_mode - Get dual role mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'dr_mode',
> + * and returns the correspondig enum usb_phy_dr_mode
> + */
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
> +{
> + const char *dr_mode;
> + int err, i;
> +
> + err = of_property_read_string(np, "dr_mode", &dr_mode);
> + if (err < 0)
> + return USB_DR_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> + if (!strcasecmp(dr_mode, usb_dr_modes[i]))
> + return i;
> +
> + return USB_DR_MODE_UNKNOWN;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_dr_mode);
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> new file mode 100644
> index 0000000..582ba96
> --- /dev/null
> +++ b/include/linux/usb/of.h
> @@ -0,0 +1,22 @@
> +/*
> + * OF helpers for usb devices.
> + *
> + * This file is released under the GPLv2
> + */
> +
> +#ifndef __LINUX_USB_OF_H
> +#define __LINUX_USB_OF_H
> +
> +#include <linux/usb/phy.h>
> +
> +enum usb_phy_dr_mode {
> + USB_DR_MODE_UNKNOWN,
> + USB_DR_MODE_HOST,
> + USB_DR_MODE_PERIPHERAL,
> + USB_DR_MODE_OTG,
> +};
> +
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np);
> +
> +#endif /* __LINUX_USB_OF_H */
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index a29ae1e..c5154cf 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -12,6 +12,15 @@
> #include <linux/notifier.h>
> #include <linux/usb.h>
>
> +enum usb_phy_interface {
> + USBPHY_INTERFACE_MODE_NA,
> + USBPHY_INTERFACE_MODE_UTMI,
> + USBPHY_INTERFACE_MODE_UTMIW,
> + USBPHY_INTERFACE_MODE_ULPI,
> + USBPHY_INTERFACE_MODE_SERIAL,
> + USBPHY_INTERFACE_MODE_HSIC,
> +};
> +
> enum usb_phy_events {
> USB_EVENT_NONE, /* no events or cable disconnected */
> USB_EVENT_VBUS, /* vbus valid event */
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-29 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129110228.GA20242@lunn.ch>
On 29.01.2013 12:02, Andrew Lunn wrote:
>> Now I activated the debug messages in em28xx. From the messages I
>> see no correlation of the pool exhaustion and lost sync. Also I
>> cannot see any error messages from the em28xx driver.
>> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
>> draining the coherent pool (checked with 'cat
>> /debug/dma-api/num_free_entries', which gave stable numbers), but
>> after half an hour there are only init_isoc messages without
>> corresponding stop_urbs messages and num_free_entries decreased
>> until coherent pool exhaustion.
>
> Hi Soeren
>
> em28xx_stop_urbs() is only called by em28xx_stop_streaming().
>
> em28xx_stop_streaming() is only called by em28xx_stop_feed()
> when 0 == dvb->nfeeds.
>
> em28xx_stop_feed()and em28xx_start_feed() look O.K, dvb->nfeeds is
> protected by a mutex etc.
>
> Now, em28xx_init_isoc() is also called by buffer_prepare(). This uses
> em28xx_alloc_isoc() to do the actual allocation, and that function
> sets up the urb such that on completion the function
> em28xx_irq_callback() is called.
>
> It looks like there might be issues here:
>
> Once the data has been copied out, it resubmits the urb:
>
> urb->status = usb_submit_urb(urb, GFP_ATOMIC);
> if (urb->status) {
> em28xx_isocdbg("urb resubmit failed (error=%i)\n",
> urb->status);
> }
>
> However, if the ubs_submit_urb fails, it looks like the urb is lost.
>
> If you look at other code submitting urbs you have this pattern:
>
> rc = usb_submit_urb(isoc_bufs->urb[i], GFP_ATOMIC);
> if (rc) {
> em28xx_err("submit of urb %i failed (error=%i)\n", i,
> rc);
> em28xx_uninit_isoc(dev, mode);
> return rc;
> }
>
> Do you have your build such that you would see "urb resubmit failed"
> in your logs? Are there any?
I only had "urb resubmit failed" messages _after_ the coherent pool
exhaustion. So I guess something below the usb_submit_urb call is
allocating (too much) memory, sometimes. Or can dvb_demux allocate
memory and blame orion-ehci for it?
Soeren
^ permalink raw reply
* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Srinidhi Kasagar @ 2013-01-29 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129113325.GG2637@n2100.arm.linux.org.uk>
On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
> On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> > Add 'smc' (Secure Monitor Call) identifier to differentiates
> > the platforms which implements this.
>
> This patch makes no sense.
>
> So, if setting 'smc' in the DT description is supposed to mean that
> the platform has a secure monitor then...
>
> > + is_smc = of_property_read_bool(np, "smc");
> > +
> > + if (is_smc) {
> > + /* set the debug interface */
> > + outer_cache.set_debug = pl310_set_debug;
> > + }
>
> Now, let's look at what pl310_set_debug() does:
>
> static void pl310_set_debug(unsigned long val)
> {
> writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
You can do this operation (write to DEBUG_CTRL) only if SMC is implemented.
> }
>
> Can you explain where the secure monitor call is there please, because
> I can't see one. In fact, this is the function used when there _isn't_
> a secure monitor. So this patch just seems totally wrong to me.
regards/srinidhi
^ permalink raw reply
* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Russell King - ARM Linux @ 2013-01-29 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129113853.GA22145@bnru10>
On Tue, Jan 29, 2013 at 05:08:53PM +0530, Srinidhi Kasagar wrote:
> On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
> > On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> > > Add 'smc' (Secure Monitor Call) identifier to differentiates
> > > the platforms which implements this.
> >
> > This patch makes no sense.
> >
> > So, if setting 'smc' in the DT description is supposed to mean that
> > the platform has a secure monitor then...
> >
> > > + is_smc = of_property_read_bool(np, "smc");
> > > +
> > > + if (is_smc) {
> > > + /* set the debug interface */
> > > + outer_cache.set_debug = pl310_set_debug;
> > > + }
> >
> > Now, let's look at what pl310_set_debug() does:
> >
> > static void pl310_set_debug(unsigned long val)
> > {
> > writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
> > }
> >
> > Can you explain where the secure monitor call is there please, because
> > I can't see one. In fact, this is the function used when there _isn't_
> > a secure monitor. So this patch just seems totally wrong to me.
>
> Today, one and only platform is omap. Please check below snapshot:
I don't think you understood my point at all.
OMAP sets outer_cache.set_debug to point at its own function to issue a
SMC to set the debug register.
pl310_set_debug() is not that code; pl310_set_debug() is used on non-OMAP
platforms to write to this register directly.
Your patch disables the whole workaround if 'smc' is not specified in DT
or 'true' is passed into the l2x0 init function.
Therefore, this patch is just rubbish IMHO. I don't think you've taken
the time to understand the code you're modifying, nor have you understood
the point that I made above.
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Egon Alter @ 2013-01-29 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101549.GP23505@n2100.arm.linux.org.uk>
Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux:
> On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
> > What's this "with enabled unaligned memory access" thing? You mean "if
> > the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
> > that's only x86, which isn't really in the target market for this
> > patch, yes?
> >
> > It's a lot of code for a 50ms boot-time improvement. Does anyone have
> > any opinions on whether or not the benefits are worth the cost?
>
> Well... when I saw this my immediate reaction was "oh no, yet another
> decompressor for the kernel". We have five of these things already.
> Do we really need a sixth?
>
> My feeling is that we should have:
> - one decompressor which is the fastest
> - one decompressor for the highest compression ratio
> - one popular decompressor (eg conventional gzip)
the problem gets more complicated as the "fastest" decompressor usually
creates larger images which need more time to load from the storage, e.g. a
one MB larger image on a 10 MB/s storage (note: bootloaders often configure
the storage controllers in slow modes) gives 100 ms more boot time, thus
eating the gain of a "fast decompressor".
Egon
^ permalink raw reply
* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Srinidhi Kasagar @ 2013-01-29 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129113325.GG2637@n2100.arm.linux.org.uk>
On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
> On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> > Add 'smc' (Secure Monitor Call) identifier to differentiates
> > the platforms which implements this.
>
> This patch makes no sense.
>
> So, if setting 'smc' in the DT description is supposed to mean that
> the platform has a secure monitor then...
>
> > + is_smc = of_property_read_bool(np, "smc");
> > +
> > + if (is_smc) {
> > + /* set the debug interface */
> > + outer_cache.set_debug = pl310_set_debug;
> > + }
>
> Now, let's look at what pl310_set_debug() does:
>
> static void pl310_set_debug(unsigned long val)
> {
> writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
> }
>
> Can you explain where the secure monitor call is there please, because
> I can't see one. In fact, this is the function used when there _isn't_
> a secure monitor. So this patch just seems totally wrong to me.
Today, one and only platform is omap. Please check below snapshot:
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -51,6 +51,7 @@
reg = <0x48242000 0x1000>;
cache-unified;
cache-level = <2>;
+ smc;
};
[...]
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -214,7 +214,7 @@ static int __init omap_l2_cache_init(void)
if (of_have_populated_dt())
l2x0_of_init(aux_ctrl, L2X0_AUX_CTRL_MASK);
else
- l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
+ l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK, true);
regards/srinidhi
^ permalink raw reply
* [PATCH] ARM:common: setting saved_state to NULL after kfree
From: Chen Gang @ 2013-01-29 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129111526.GQ23505@n2100.arm.linux.org.uk>
? 2013?01?29? 19:15, Russell King - ARM Linux ??:
> On Tue, Jan 29, 2013 at 07:11:43PM +0800, Chen Gang wrote:
>> > need set NULL before return, just like function sa1111_remove has done.
>> > and better to use sa1111_remove directly, instead of current implementation.
> NAK.
>
> 1. __sa1111_remove() will kfree sachip, so the value of sachip->saved_state
> at this point is meaningless.
yes, just like what you said. it is not a bug
(it seems not necessary to set saved_state to NULL in sa1111_remove, either).
I think, this patch can make the source code simpler and clearer.
so I still suggest to apply it (although it seems a minor patch).
> 2. I don't think you tried to build with your patch in place.
>
>
it is my fault, just like what you said, I did not try to build.
and I should try now.
thanks.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Russell King - ARM Linux @ 2013-01-29 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101328.GA11878@bnru10>
On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> Add 'smc' (Secure Monitor Call) identifier to differentiates
> the platforms which implements this.
This patch makes no sense.
So, if setting 'smc' in the DT description is supposed to mean that
the platform has a secure monitor then...
> + is_smc = of_property_read_bool(np, "smc");
> +
> + if (is_smc) {
> + /* set the debug interface */
> + outer_cache.set_debug = pl310_set_debug;
> + }
Now, let's look at what pl310_set_debug() does:
static void pl310_set_debug(unsigned long val)
{
writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
}
Can you explain where the secure monitor call is there please, because
I can't see one. In fact, this is the function used when there _isn't_
a secure monitor. So this patch just seems totally wrong to me.
^ permalink raw reply
* [PATCH v3 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
From: Bedia, Vaibhav @ 2013-01-29 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107B208.80005@ti.com>
On Tue, Jan 29, 2013 at 16:57:04, Shilimkar, Santosh wrote:
> Vaibhav,
>
> On Tuesday 29 January 2013 04:44 PM, Vaibhav Bedia wrote:
> > Hi,
> >
> > The following patches were earlier posted as part the AM33XX
> > suspend-resume support series [1]. Based on the suggestion
> > from Santosh Shilimkar <santosh.shilimkar@ti.com> i have split
> > out the changes which update the various data files related
> > to AM33XX support.
> >
> > These patches apply on top of v3.8-rc5
> >
> > v1->v2: Address the comments received from Sergei Shtylyov
> > and Peter Korsgaard.
> >
> > v2->v3: Address an additional comment from Peter Korgaard
> > and add his Acked-by to the patches
> >
> Just a suggestion here...
>
> I saw v2 of $subject series just today morning and in just
> few hours, I see v3 as well. You should at least let v2 settle
> down for a while :-)
> Collecting tags and minor update can always be done once you
> gather sufficient comments to warrant a re-spin.
>
OK. v1 has been in the wild for more than 10 days without any
more comments so I went aggressive on v3 :)
Regards,
Vaibhav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox