* [PATCH] ARM: implement optimized percpu variable access
From: Will Deacon @ 2012-11-12 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A0F390.7060800@gmail.com>
On Mon, Nov 12, 2012 at 01:03:12PM +0000, Rob Herring wrote:
> On 11/12/2012 04:23 AM, Will Deacon wrote:
> >> +static inline void set_my_cpu_offset(unsigned long off)
> >> +{
> >> + asm volatile("mcr p15, 0, %0, c13, c0, 4 @ set TPIDRPRW" : : "r" (off) : "cc" );
> >> +}
> >
> > You don't need the "cc" here.
>
> You would think so, but the compiler drops this instruction if you
> don't. set_cr does the same thing.
Whoa, that sounds suspicious... if the thing is marked volatile GCC
shouldn't optimise it away if it's reachable. Which toolchain are you
using?
Will
^ permalink raw reply
* [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
From: Grazvydas Ignotas @ 2012-11-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> This series changes omapfb to use standard dma_alloc funcs instead of omap
> specific vram allocator. This let's us remove the omap vram allocator, making
> omapfb platform independent.
>
> However, note that using standard dma funcs causes the following downsides:
>
> ...
>
> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
> changed the ioctl to return 64M for all the values, which, I hope, the
> applications will interpret as "there's enough vram".
Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
> 4) "vram" kernel parameter to define how much ram to reserve for video use no
> longer works. The user needs to enable CMA and use "cma" parameter.
That's a significant change, you should update Documentation/ .
What about omapfb.vram, is it still there?
Perhaps we also need to select/depend on CMA?
--
Gra?vydas
^ permalink raw reply
* [RFC PATCH 0/4] ARM: S3C24XX: irq move to drivers and first steps to dt
From: Heiko Stübner @ 2012-11-12 13:46 UTC (permalink / raw)
To: linux-arm-kernel
On the way back from Barcelona I've started the move of the common
s3c24xx irq-code to drivers/irqchip and also modifications to enable
using it in a devicetree context at some point.
So, as I'm also missing the now probably famous tail-lights in this, it
would be cool to have some feedback if I'm moving in the right
direction here or am thinking wrong somewhere.
The whole endeavour is of course not finished yet, but should not
break anything in its current form.
Tested on a s3c2416 based machine.
Heiko Stuebner (4):
ARM: S3C24XX: move s3c24xx-irq to drivers/irqchip
irqchip: s3c24xx: add irq_domains for the interrupt registers
ARM: S3C24XX: irq_data conversion for s3c_irqsub_* functions
ARM: S3C24XX: First part converting irq code to use hwirq
arch/arm/Kconfig | 1 +
arch/arm/mach-s3c24xx/irq-pm.c | 4 +-
arch/arm/mach-s3c24xx/irq-s3c2412.c | 6 +-
arch/arm/mach-s3c24xx/irq-s3c2416.c | 24 ++--
arch/arm/mach-s3c24xx/irq-s3c2440.c | 6 +-
arch/arm/mach-s3c24xx/irq-s3c2443.c | 30 ++--
arch/arm/mach-s3c24xx/irq-s3c244x.c | 6 +-
arch/arm/plat-s3c24xx/Makefile | 1 -
arch/arm/plat-samsung/include/plat/irq.h | 18 ++--
drivers/irqchip/Kconfig | 4 +
drivers/irqchip/Makefile | 1 +
.../irq.c => drivers/irqchip/irq-s3c24xx.c | 147 ++++++++++++--------
12 files changed, 144 insertions(+), 104 deletions(-)
rename arch/arm/plat-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c (84%)
--
1.7.2.3
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Rob Clark @ 2012-11-12 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112104601.GB2346@mudshark.cambridge.arm.com>
On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Nov 09, 2012 at 09:17:33PM +0000, Rob Clark wrote:
>> From: Rob Clark <rob@ti.com>
>>
>> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> get_user() to work for 64bit types (in addition to just put_user()).
>>
>> Signed-off-by: Rob Clark <rob@ti.com>
>> ---
>> arch/arm/include/asm/uaccess.h | 25 ++++++++++++++++++++-----
>> arch/arm/lib/getuser.S | 17 ++++++++++++++++-
>> 2 files changed, 36 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
>> index 7e1f760..2e3fdb2 100644
>> --- a/arch/arm/include/asm/uaccess.h
>> +++ b/arch/arm/include/asm/uaccess.h
>> @@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
>> extern int __get_user_1(void *);
>> extern int __get_user_2(void *);
>> extern int __get_user_4(void *);
>> +extern int __get_user_8(void *);
>>
>> #define __GUP_CLOBBER_1 "lr", "cc"
>> #ifdef CONFIG_CPU_USE_DOMAINS
>> @@ -108,6 +109,7 @@ extern int __get_user_4(void *);
>> #define __GUP_CLOBBER_2 "lr", "cc"
>> #endif
>> #define __GUP_CLOBBER_4 "lr", "cc"
>> +#define __GUP_CLOBBER_8 "lr", "cc"
>>
>> #define __get_user_x(__r2,__p,__e,__l,__s) \
>> __asm__ __volatile__ ( \
>> @@ -122,22 +124,35 @@ extern int __get_user_4(void *);
>> ({ \
>> unsigned long __limit = current_thread_info()->addr_limit - 1; \
>> register const typeof(*(p)) __user *__p asm("r0") = (p);\
>> - register unsigned long __r2 asm("r2"); \
>> register unsigned long __l asm("r1") = __limit; \
>> register int __e asm("r0"); \
>> switch (sizeof(*(__p))) { \
>> - case 1: \
>> + case 1: { \
>> + register unsigned long __r2 asm("r2"); \
>> __get_user_x(__r2, __p, __e, __l, 1); \
>> + x = (typeof(*(p))) __r2; \
>> break; \
>> - case 2: \
>> + } \
>> + case 2: { \
>> + register unsigned long __r2 asm("r2"); \
>> __get_user_x(__r2, __p, __e, __l, 2); \
>> + x = (typeof(*(p))) __r2; \
>> break; \
>> - case 4: \
>> + } \
>> + case 4: { \
>> + register unsigned long __r2 asm("r2"); \
>> __get_user_x(__r2, __p, __e, __l, 4); \
>> + x = (typeof(*(p))) __r2; \
>> + break; \
>> + } \
>> + case 8: { \
>> + register unsigned long long __r2 asm("r2"); \
>
> Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
> asm, so the compiler shouldn't care much. For OABI, I think you may have to
> do some more work to get the two words where you want them.
Is the question whether the compiler is guaranteed to allocate r2 and
r3 in all cases? I'm not quite sure, I confess to usually trying to
avoid inline asm. But from looking at the disassembly (for little
endian EABI build) it seemed to do the right thing.
The only other idea I had was to explicitly declare two 'unsigned
long's and then shift them into a 64bit x, although I'm open to
suggestions if there is a better way.
>> + __get_user_x(__r2, __p, __e, __l, 8); \
>> + x = (typeof(*(p))) __r2; \
>> break; \
>> + } \
>> default: __e = __get_user_bad(); break; \
>> } \
>> - x = (typeof(*(p))) __r2; \
>> __e; \
>> })
>>
>> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
>> index 9b06bb4..d05285c 100644
>> --- a/arch/arm/lib/getuser.S
>> +++ b/arch/arm/lib/getuser.S
>> @@ -18,7 +18,7 @@
>> * Inputs: r0 contains the address
>> * r1 contains the address limit, which must be preserved
>> * Outputs: r0 is the error code
>> - * r2 contains the zero-extended value
>> + * r2, r3 contains the zero-extended value
>> * lr corrupted
>> *
>> * No other registers must be altered. (see <asm/uaccess.h>
>> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
>> mov pc, lr
>> ENDPROC(__get_user_4)
>>
>> +ENTRY(__get_user_8)
>> + check_uaccess r0, 4, r1, r2, __get_user_bad
>
> Shouldn't you be passing 8 here, so that we validate the correct range?
yes, sorry, I'll fix that
>> +#ifdef CONFIG_THUMB2_KERNEL
>> +5: TUSER(ldr) r2, [r0]
>> +6: TUSER(ldr) r3, [r0, #4]
>> +#else
>> +5: TUSER(ldr) r2, [r0], #4
>> +6: TUSER(ldr) r3, [r0]
>> +#endif
>
> This doesn't work for EABI big-endian systems.
Hmm, is that true? Wouldn't put_user() then have the same problem?
I guess __ARMEB__ is the flag for big-endian?
BR,
-R
> Will
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [RFC PATCH 1/4] ARM: S3C24XX: move s3c24xx-irq to drivers/irqchip
From: Heiko Stübner @ 2012-11-12 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121446.30167.heiko@sntech.de>
Removes another part from plat-s3c24xx and also enables further
improvements happening in the correct location.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/Kconfig | 1 +
arch/arm/plat-s3c24xx/Makefile | 1 -
drivers/irqchip/Kconfig | 3 +++
drivers/irqchip/Makefile | 1 +
.../irq.c => drivers/irqchip/irq-s3c24xx.c | 0
5 files changed, 5 insertions(+), 1 deletions(-)
rename arch/arm/plat-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c (100%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 48eea16..7db6b91 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -742,6 +742,7 @@ config ARCH_S3C24XX
select HAVE_S3C_RTC if RTC_CLASS
select NEED_MACH_GPIO_H
select NEED_MACH_IO_H
+ select S3C24XX_IRQ
help
Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443
and S3C2450 SoCs based systems, such as the Simtec Electronics BAST
diff --git a/arch/arm/plat-s3c24xx/Makefile b/arch/arm/plat-s3c24xx/Makefile
index 9f60549c..6472416 100644
--- a/arch/arm/plat-s3c24xx/Makefile
+++ b/arch/arm/plat-s3c24xx/Makefile
@@ -12,7 +12,6 @@ obj- :=
# Core files
-obj-y += irq.o
obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
obj-$(CONFIG_CPU_FREQ_S3C24XX) += cpu-freq.o
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 62ca575..860d45d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -1,3 +1,6 @@
+config S3C24XX_IRQ
+ bool
+
config VERSATILE_FPGA_IRQ
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e2e6eb5..5c20f85 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_S3C24XX_IRQ) += irq-s3c24xx.o
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
diff --git a/arch/arm/plat-s3c24xx/irq.c b/drivers/irqchip/irq-s3c24xx.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/irq.c
rename to drivers/irqchip/irq-s3c24xx.c
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH 2/4] irqchip: s3c24xx: add irq_domains for the interrupt registers
From: Heiko Stübner @ 2012-11-12 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121446.30167.heiko@sntech.de>
Add irqdomains for the three register sets in use for base, external
and sub-interrupts. This also pouplates the hwirq value for further
improvements.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-s3c24xx.c | 14 ++++++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 860d45d..e30feca 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -1,5 +1,6 @@
config S3C24XX_IRQ
bool
+ select IRQ_DOMAIN
config VERSATILE_FPGA_IRQ
bool
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index fe57bbb..cf9d04d 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -25,6 +25,8 @@
#include <linux/device.h>
#include <linux/syscore_ops.h>
+#include <linux/irqdomain.h>
+
#include <asm/irq.h>
#include <asm/mach/irq.h>
@@ -667,6 +669,18 @@ void __init s3c24xx_init_irq(void)
set_irq_flags(irqno, IRQF_VALID);
}
+ /* basic interrupt register */
+ irq_domain_add_legacy(NULL, 32, IRQ_EINT0, 0, &irq_domain_simple_ops,
+ NULL);
+
+ /* extint register, irqs begin at bit4 */
+ irq_domain_add_legacy(NULL, 20, IRQ_EINT4, 4, &irq_domain_simple_ops,
+ NULL);
+
+ /* subint register, 29 to fit subints of all SoCs */
+ irq_domain_add_legacy(NULL, 29, IRQ_S3CUART_RX0, 0,
+ &irq_domain_simple_ops, NULL);
+
irqdbf("s3c2410: registered interrupt handlers\n");
}
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH 3/4] ARM: S3C24XX: irq_data conversion for s3c_irqsub_* functions
From: Heiko Stübner @ 2012-11-12 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121446.30167.heiko@sntech.de>
Don't strip off the rest of the irq_data struct when calling one of
the s3c_irqsub_* functions. This enables using its hwirq field
later on.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/mach-s3c24xx/irq-s3c2412.c | 6 +++---
arch/arm/mach-s3c24xx/irq-s3c2416.c | 24 ++++++++++++------------
arch/arm/mach-s3c24xx/irq-s3c2440.c | 6 +++---
arch/arm/mach-s3c24xx/irq-s3c2443.c | 30 +++++++++++++++---------------
arch/arm/mach-s3c24xx/irq-s3c244x.c | 6 +++---
arch/arm/plat-samsung/include/plat/irq.h | 18 +++++++++---------
drivers/irqchip/irq-s3c24xx.c | 24 ++++++++++++------------
7 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2412.c b/arch/arm/mach-s3c24xx/irq-s3c2412.c
index e65619d..2cee386 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2412.c
@@ -134,17 +134,17 @@ static void s3c2412_irq_demux_cfsdi(unsigned int irq, struct irq_desc *desc)
static void s3c2412_irq_cfsdi_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_CFSDI, SUBMSK_CFSDI);
+ s3c_irqsub_mask(data, INTMSK_CFSDI, SUBMSK_CFSDI);
}
static void s3c2412_irq_cfsdi_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_CFSDI);
+ s3c_irqsub_unmask(data, INTMSK_CFSDI);
}
static void s3c2412_irq_cfsdi_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_CFSDI, SUBMSK_CFSDI);
+ s3c_irqsub_maskack(data, INTMSK_CFSDI, SUBMSK_CFSDI);
}
static struct irq_chip s3c2412_irq_cfsdi = {
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2416.c b/arch/arm/mach-s3c24xx/irq-s3c2416.c
index ff141b0..149d406 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2416.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2416.c
@@ -80,17 +80,17 @@ static void s3c2416_irq_demux_wdtac97(unsigned int irq, struct irq_desc *desc)
static void s3c2416_irq_wdtac97_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_WDTAC97, SUBMSK_WDTAC97);
+ s3c_irqsub_mask(data, INTMSK_WDTAC97, SUBMSK_WDTAC97);
}
static void s3c2416_irq_wdtac97_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_WDTAC97);
+ s3c_irqsub_unmask(data, INTMSK_WDTAC97);
}
static void s3c2416_irq_wdtac97_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_WDTAC97, SUBMSK_WDTAC97);
+ s3c_irqsub_maskack(data, INTMSK_WDTAC97, SUBMSK_WDTAC97);
}
static struct irq_chip s3c2416_irq_wdtac97 = {
@@ -111,17 +111,17 @@ static void s3c2416_irq_demux_lcd(unsigned int irq, struct irq_desc *desc)
static void s3c2416_irq_lcd_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_LCD, SUBMSK_LCD);
+ s3c_irqsub_mask(data, INTMSK_LCD, SUBMSK_LCD);
}
static void s3c2416_irq_lcd_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_LCD);
+ s3c_irqsub_unmask(data, INTMSK_LCD);
}
static void s3c2416_irq_lcd_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_LCD, SUBMSK_LCD);
+ s3c_irqsub_maskack(data, INTMSK_LCD, SUBMSK_LCD);
}
static struct irq_chip s3c2416_irq_lcd = {
@@ -143,17 +143,17 @@ static void s3c2416_irq_demux_dma(unsigned int irq, struct irq_desc *desc)
static void s3c2416_irq_dma_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_DMA, SUBMSK_DMA);
+ s3c_irqsub_mask(data, INTMSK_DMA, SUBMSK_DMA);
}
static void s3c2416_irq_dma_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_DMA);
+ s3c_irqsub_unmask(data, INTMSK_DMA);
}
static void s3c2416_irq_dma_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_DMA, SUBMSK_DMA);
+ s3c_irqsub_maskack(data, INTMSK_DMA, SUBMSK_DMA);
}
static struct irq_chip s3c2416_irq_dma = {
@@ -174,17 +174,17 @@ static void s3c2416_irq_demux_uart3(unsigned int irq, struct irq_desc *desc)
static void s3c2416_irq_uart3_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_UART3, SUBMSK_UART3);
+ s3c_irqsub_mask(data, INTMSK_UART3, SUBMSK_UART3);
}
static void s3c2416_irq_uart3_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_UART3);
+ s3c_irqsub_unmask(data, INTMSK_UART3);
}
static void s3c2416_irq_uart3_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_UART3, SUBMSK_UART3);
+ s3c_irqsub_maskack(data, INTMSK_UART3, SUBMSK_UART3);
}
static struct irq_chip s3c2416_irq_uart3 = {
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2440.c b/arch/arm/mach-s3c24xx/irq-s3c2440.c
index 4a18cde..99fada9 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2440.c
@@ -71,19 +71,19 @@ static void s3c_irq_demux_wdtac97(unsigned int irq,
static void
s3c_irq_wdtac97_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_WDT, 3 << 13);
+ s3c_irqsub_mask(data, INTMSK_WDT, 3 << 13);
}
static void
s3c_irq_wdtac97_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_WDT);
+ s3c_irqsub_unmask(data, INTMSK_WDT);
}
static void
s3c_irq_wdtac97_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_WDT, 3 << 13);
+ s3c_irqsub_maskack(data, INTMSK_WDT, 3 << 13);
}
static struct irq_chip s3c_irq_wdtac97 = {
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2443.c b/arch/arm/mach-s3c24xx/irq-s3c2443.c
index 5e69109..0d9f77a 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2443.c
@@ -77,17 +77,17 @@ static void s3c2443_irq_demux_wdtac97(unsigned int irq, struct irq_desc *desc)
static void s3c2443_irq_wdtac97_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_WDTAC97, SUBMSK_WDTAC97);
+ s3c_irqsub_mask(data, INTMSK_WDTAC97, SUBMSK_WDTAC97);
}
static void s3c2443_irq_wdtac97_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_WDTAC97);
+ s3c_irqsub_unmask(data, INTMSK_WDTAC97);
}
static void s3c2443_irq_wdtac97_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_WDTAC97, SUBMSK_WDTAC97);
+ s3c_irqsub_maskack(data, INTMSK_WDTAC97, SUBMSK_WDTAC97);
}
static struct irq_chip s3c2443_irq_wdtac97 = {
@@ -108,17 +108,17 @@ static void s3c2443_irq_demux_lcd(unsigned int irq, struct irq_desc *desc)
static void s3c2443_irq_lcd_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_LCD, SUBMSK_LCD);
+ s3c_irqsub_mask(data, INTMSK_LCD, SUBMSK_LCD);
}
static void s3c2443_irq_lcd_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_LCD);
+ s3c_irqsub_unmask(data, INTMSK_LCD);
}
static void s3c2443_irq_lcd_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_LCD, SUBMSK_LCD);
+ s3c_irqsub_maskack(data, INTMSK_LCD, SUBMSK_LCD);
}
static struct irq_chip s3c2443_irq_lcd = {
@@ -139,17 +139,17 @@ static void s3c2443_irq_demux_dma(unsigned int irq, struct irq_desc *desc)
static void s3c2443_irq_dma_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_DMA, SUBMSK_DMA);
+ s3c_irqsub_mask(data, INTMSK_DMA, SUBMSK_DMA);
}
static void s3c2443_irq_dma_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_DMA);
+ s3c_irqsub_unmask(data, INTMSK_DMA);
}
static void s3c2443_irq_dma_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_DMA, SUBMSK_DMA);
+ s3c_irqsub_maskack(data, INTMSK_DMA, SUBMSK_DMA);
}
static struct irq_chip s3c2443_irq_dma = {
@@ -170,17 +170,17 @@ static void s3c2443_irq_demux_uart3(unsigned int irq, struct irq_desc *desc)
static void s3c2443_irq_uart3_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_UART3, SUBMSK_UART3);
+ s3c_irqsub_mask(data, INTMSK_UART3, SUBMSK_UART3);
}
static void s3c2443_irq_uart3_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_UART3);
+ s3c_irqsub_unmask(data, INTMSK_UART3);
}
static void s3c2443_irq_uart3_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_UART3, SUBMSK_UART3);
+ s3c_irqsub_maskack(data, INTMSK_UART3, SUBMSK_UART3);
}
static struct irq_chip s3c2443_irq_uart3 = {
@@ -201,17 +201,17 @@ static void s3c2443_irq_demux_cam(unsigned int irq, struct irq_desc *desc)
static void s3c2443_irq_cam_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_CAM, SUBMSK_CAM);
+ s3c_irqsub_mask(data, INTMSK_CAM, SUBMSK_CAM);
}
static void s3c2443_irq_cam_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_CAM);
+ s3c_irqsub_unmask(data, INTMSK_CAM);
}
static void s3c2443_irq_cam_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_CAM, SUBMSK_CAM);
+ s3c_irqsub_maskack(data, INTMSK_CAM, SUBMSK_CAM);
}
static struct irq_chip s3c2443_irq_cam = {
diff --git a/arch/arm/mach-s3c24xx/irq-s3c244x.c b/arch/arm/mach-s3c24xx/irq-s3c244x.c
index 5fe8e58..7a3f53d 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c244x.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c244x.c
@@ -70,19 +70,19 @@ static void s3c_irq_demux_cam(unsigned int irq,
static void
s3c_irq_cam_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_CAM, 3 << 11);
+ s3c_irqsub_mask(data, INTMSK_CAM, 3 << 11);
}
static void
s3c_irq_cam_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_CAM);
+ s3c_irqsub_unmask(data, INTMSK_CAM);
}
static void
s3c_irq_cam_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_CAM, 3 << 11);
+ s3c_irqsub_maskack(data, INTMSK_CAM, 3 << 11);
}
static struct irq_chip s3c_irq_cam = {
diff --git a/arch/arm/plat-samsung/include/plat/irq.h b/arch/arm/plat-samsung/include/plat/irq.h
index e21a89b..3ae54dc 100644
--- a/arch/arm/plat-samsung/include/plat/irq.h
+++ b/arch/arm/plat-samsung/include/plat/irq.h
@@ -25,7 +25,7 @@
extern struct irq_chip s3c_irq_level_chip;
extern struct irq_chip s3c_irq_chip;
-static inline void s3c_irqsub_mask(unsigned int irqno,
+static inline void s3c_irqsub_mask(struct irq_data *data,
unsigned int parentbit,
int subcheck)
{
@@ -35,7 +35,7 @@ static inline void s3c_irqsub_mask(unsigned int irqno,
submask = __raw_readl(S3C2410_INTSUBMSK);
mask = __raw_readl(S3C2410_INTMSK);
- submask |= (1UL << (irqno - IRQ_S3CUART_RX0));
+ submask |= (1UL << (data->irq - IRQ_S3CUART_RX0));
/* check to see if we need to mask the parent IRQ */
@@ -47,7 +47,7 @@ static inline void s3c_irqsub_mask(unsigned int irqno,
}
-static inline void s3c_irqsub_unmask(unsigned int irqno,
+static inline void s3c_irqsub_unmask(struct irq_data *data,
unsigned int parentbit)
{
unsigned long mask;
@@ -56,7 +56,7 @@ static inline void s3c_irqsub_unmask(unsigned int irqno,
submask = __raw_readl(S3C2410_INTSUBMSK);
mask = __raw_readl(S3C2410_INTMSK);
- submask &= ~(1UL << (irqno - IRQ_S3CUART_RX0));
+ submask &= ~(1UL << (data->irq - IRQ_S3CUART_RX0));
mask &= ~parentbit;
/* write back masks */
@@ -65,13 +65,13 @@ static inline void s3c_irqsub_unmask(unsigned int irqno,
}
-static inline void s3c_irqsub_maskack(unsigned int irqno,
+static inline void s3c_irqsub_maskack(struct irq_data *data,
unsigned int parentmask,
unsigned int group)
{
- unsigned int bit = 1UL << (irqno - IRQ_S3CUART_RX0);
+ unsigned int bit = 1UL << (data->irq - IRQ_S3CUART_RX0);
- s3c_irqsub_mask(irqno, parentmask, group);
+ s3c_irqsub_mask(data, parentmask, group);
__raw_writel(bit, S3C2410_SUBSRCPND);
@@ -86,11 +86,11 @@ static inline void s3c_irqsub_maskack(unsigned int irqno,
}
}
-static inline void s3c_irqsub_ack(unsigned int irqno,
+static inline void s3c_irqsub_ack(struct irq_data *data,
unsigned int parentmask,
unsigned int group)
{
- unsigned int bit = 1UL << (irqno - IRQ_S3CUART_RX0);
+ unsigned int bit = 1UL << (data->irq - IRQ_S3CUART_RX0);
__raw_writel(bit, S3C2410_SUBSRCPND);
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index cf9d04d..073e614 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -258,19 +258,19 @@ static struct irq_chip s3c_irq_eint0t4 = {
static void
s3c_irq_uart0_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_UART0, 7);
+ s3c_irqsub_mask(data, INTMSK_UART0, 7);
}
static void
s3c_irq_uart0_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_UART0);
+ s3c_irqsub_unmask(data, INTMSK_UART0);
}
static void
s3c_irq_uart0_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_UART0, 7);
+ s3c_irqsub_maskack(data, INTMSK_UART0, 7);
}
static struct irq_chip s3c_irq_uart0 = {
@@ -285,19 +285,19 @@ static struct irq_chip s3c_irq_uart0 = {
static void
s3c_irq_uart1_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_UART1, 7 << 3);
+ s3c_irqsub_mask(data, INTMSK_UART1, 7 << 3);
}
static void
s3c_irq_uart1_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_UART1);
+ s3c_irqsub_unmask(data, INTMSK_UART1);
}
static void
s3c_irq_uart1_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_UART1, 7 << 3);
+ s3c_irqsub_maskack(data, INTMSK_UART1, 7 << 3);
}
static struct irq_chip s3c_irq_uart1 = {
@@ -312,19 +312,19 @@ static struct irq_chip s3c_irq_uart1 = {
static void
s3c_irq_uart2_mask(struct irq_data *data)
{
- s3c_irqsub_mask(data->irq, INTMSK_UART2, 7 << 6);
+ s3c_irqsub_mask(data, INTMSK_UART2, 7 << 6);
}
static void
s3c_irq_uart2_unmask(struct irq_data *data)
{
- s3c_irqsub_unmask(data->irq, INTMSK_UART2);
+ s3c_irqsub_unmask(data, INTMSK_UART2);
}
static void
s3c_irq_uart2_ack(struct irq_data *data)
{
- s3c_irqsub_maskack(data->irq, INTMSK_UART2, 7 << 6);
+ s3c_irqsub_maskack(data, INTMSK_UART2, 7 << 6);
}
static struct irq_chip s3c_irq_uart2 = {
@@ -339,19 +339,19 @@ static struct irq_chip s3c_irq_uart2 = {
static void
s3c_irq_adc_mask(struct irq_data *d)
{
- s3c_irqsub_mask(d->irq, INTMSK_ADCPARENT, 3 << 9);
+ s3c_irqsub_mask(d, INTMSK_ADCPARENT, 3 << 9);
}
static void
s3c_irq_adc_unmask(struct irq_data *d)
{
- s3c_irqsub_unmask(d->irq, INTMSK_ADCPARENT);
+ s3c_irqsub_unmask(d, INTMSK_ADCPARENT);
}
static void
s3c_irq_adc_ack(struct irq_data *d)
{
- s3c_irqsub_ack(d->irq, INTMSK_ADCPARENT, 3 << 9);
+ s3c_irqsub_ack(d, INTMSK_ADCPARENT, 3 << 9);
}
static struct irq_chip s3c_irq_adc = {
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH 4/4] ARM: S3C24XX: First part converting irq code to use hwirq
From: Heiko Stübner @ 2012-11-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121446.30167.heiko@sntech.de>
Use the newly introduced irq_domains to let the basic ack, mask and unmask
functions use its hwirq field. This also includes the external irq sources
and removes all offset calculations based on the static irq numbers from
these parts.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/mach-s3c24xx/irq-pm.c | 4 +-
arch/arm/plat-samsung/include/plat/irq.h | 8 +-
drivers/irqchip/irq-s3c24xx.c | 109 ++++++++++++++++++------------
3 files changed, 71 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/irq-pm.c b/arch/arm/mach-s3c24xx/irq-pm.c
index 0efb2e2..5aa7e28 100644
--- a/arch/arm/mach-s3c24xx/irq-pm.c
+++ b/arch/arm/mach-s3c24xx/irq-pm.c
@@ -29,12 +29,12 @@
* set bit to 1 in allow bitfield to enable the wakeup settings on it
*/
-unsigned long s3c_irqwake_intallow = 1L << (IRQ_RTC - IRQ_EINT0) | 0xfL;
+unsigned long s3c_irqwake_intallow = 1L << 30 | 0xfL;
unsigned long s3c_irqwake_eintallow = 0x0000fff0L;
int s3c_irq_wake(struct irq_data *data, unsigned int state)
{
- unsigned long irqbit = 1 << (data->irq - IRQ_EINT0);
+ unsigned long irqbit = 1 << (data->hwirq);
if (!(s3c_irqwake_intallow & irqbit))
return -ENOENT;
diff --git a/arch/arm/plat-samsung/include/plat/irq.h b/arch/arm/plat-samsung/include/plat/irq.h
index 3ae54dc..d024d7a 100644
--- a/arch/arm/plat-samsung/include/plat/irq.h
+++ b/arch/arm/plat-samsung/include/plat/irq.h
@@ -35,7 +35,7 @@ static inline void s3c_irqsub_mask(struct irq_data *data,
submask = __raw_readl(S3C2410_INTSUBMSK);
mask = __raw_readl(S3C2410_INTMSK);
- submask |= (1UL << (data->irq - IRQ_S3CUART_RX0));
+ submask |= (1UL << data->hwirq);
/* check to see if we need to mask the parent IRQ */
@@ -56,7 +56,7 @@ static inline void s3c_irqsub_unmask(struct irq_data *data,
submask = __raw_readl(S3C2410_INTSUBMSK);
mask = __raw_readl(S3C2410_INTMSK);
- submask &= ~(1UL << (data->irq - IRQ_S3CUART_RX0));
+ submask &= ~(1UL << data->hwirq);
mask &= ~parentbit;
/* write back masks */
@@ -69,7 +69,7 @@ static inline void s3c_irqsub_maskack(struct irq_data *data,
unsigned int parentmask,
unsigned int group)
{
- unsigned int bit = 1UL << (data->irq - IRQ_S3CUART_RX0);
+ unsigned int bit = 1UL << data->hwirq;
s3c_irqsub_mask(data, parentmask, group);
@@ -90,7 +90,7 @@ static inline void s3c_irqsub_ack(struct irq_data *data,
unsigned int parentmask,
unsigned int group)
{
- unsigned int bit = 1UL << (data->irq - IRQ_S3CUART_RX0);
+ unsigned int bit = 1UL << data->hwirq;
__raw_writel(bit, S3C2410_SUBSRCPND);
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 073e614..804fda1 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -39,18 +39,17 @@
static void
s3c_irq_mask(struct irq_data *data)
{
- unsigned int irqno = data->irq - IRQ_EINT0;
unsigned long mask;
mask = __raw_readl(S3C2410_INTMSK);
- mask |= 1UL << irqno;
+ mask |= 1UL << data->hwirq;
__raw_writel(mask, S3C2410_INTMSK);
}
static inline void
s3c_irq_ack(struct irq_data *data)
{
- unsigned long bitval = 1UL << (data->irq - IRQ_EINT0);
+ unsigned long bitval = 1UL << data->hwirq;
__raw_writel(bitval, S3C2410_SRCPND);
__raw_writel(bitval, S3C2410_INTPND);
@@ -59,7 +58,7 @@ s3c_irq_ack(struct irq_data *data)
static inline void
s3c_irq_maskack(struct irq_data *data)
{
- unsigned long bitval = 1UL << (data->irq - IRQ_EINT0);
+ unsigned long bitval = 1UL << data->hwirq;
unsigned long mask;
mask = __raw_readl(S3C2410_INTMSK);
@@ -79,10 +78,8 @@ s3c_irq_unmask(struct irq_data *data)
if (irqno != IRQ_TIMER4 && irqno != IRQ_EINT8t23)
irqdbf2("s3c_irq_unmask %d\n", irqno);
- irqno -= IRQ_EINT0;
-
mask = __raw_readl(S3C2410_INTMSK);
- mask &= ~(1UL << irqno);
+ mask &= ~(1UL << data->hwirq);
__raw_writel(mask, S3C2410_INTMSK);
}
@@ -105,11 +102,10 @@ struct irq_chip s3c_irq_chip = {
static void
s3c_irqext_mask(struct irq_data *data)
{
- unsigned int irqno = data->irq - EXTINT_OFF;
unsigned long mask;
mask = __raw_readl(S3C24XX_EINTMASK);
- mask |= ( 1UL << irqno);
+ mask |= ( 1UL << data->hwirq);
__raw_writel(mask, S3C24XX_EINTMASK);
}
@@ -120,7 +116,7 @@ s3c_irqext_ack(struct irq_data *data)
unsigned long bit;
unsigned long mask;
- bit = 1UL << (data->irq - EXTINT_OFF);
+ bit = 1UL << data->hwirq;
mask = __raw_readl(S3C24XX_EINTMASK);
@@ -132,10 +128,10 @@ s3c_irqext_ack(struct irq_data *data)
/* not sure if we should be acking the parent irq... */
if (data->irq <= IRQ_EINT7) {
- if ((req & 0xf0) == 0)
+ if ((req & 0xf0) == 0) /* FIXME: use parent irq-domain */
s3c_irq_ack(irq_get_irq_data(IRQ_EINT4t7));
} else {
- if ((req >> 8) == 0)
+ if ((req >> 8) == 0) /* FIXME: use parent irq-domain */
s3c_irq_ack(irq_get_irq_data(IRQ_EINT8t23));
}
}
@@ -143,46 +139,21 @@ s3c_irqext_ack(struct irq_data *data)
static void
s3c_irqext_unmask(struct irq_data *data)
{
- unsigned int irqno = data->irq - EXTINT_OFF;
unsigned long mask;
mask = __raw_readl(S3C24XX_EINTMASK);
- mask &= ~(1UL << irqno);
+ mask &= ~(1UL << data->hwirq);
__raw_writel(mask, S3C24XX_EINTMASK);
}
-int
-s3c_irqext_type(struct irq_data *data, unsigned int type)
+static int s3c_irqext_set_type(void __iomem *gpcon_reg,
+ void __iomem *extint_reg,
+ unsigned long gpcon_offset,
+ unsigned long extint_offset,
+ unsigned int type)
{
- void __iomem *extint_reg;
- void __iomem *gpcon_reg;
- unsigned long gpcon_offset, extint_offset;
unsigned long newvalue = 0, value;
- if ((data->irq >= IRQ_EINT0) && (data->irq <= IRQ_EINT3)) {
- gpcon_reg = S3C2410_GPFCON;
- extint_reg = S3C24XX_EXTINT0;
- gpcon_offset = (data->irq - IRQ_EINT0) * 2;
- extint_offset = (data->irq - IRQ_EINT0) * 4;
- } else if ((data->irq >= IRQ_EINT4) && (data->irq <= IRQ_EINT7)) {
- gpcon_reg = S3C2410_GPFCON;
- extint_reg = S3C24XX_EXTINT0;
- gpcon_offset = (data->irq - (EXTINT_OFF)) * 2;
- extint_offset = (data->irq - (EXTINT_OFF)) * 4;
- } else if ((data->irq >= IRQ_EINT8) && (data->irq <= IRQ_EINT15)) {
- gpcon_reg = S3C2410_GPGCON;
- extint_reg = S3C24XX_EXTINT1;
- gpcon_offset = (data->irq - IRQ_EINT8) * 2;
- extint_offset = (data->irq - IRQ_EINT8) * 4;
- } else if ((data->irq >= IRQ_EINT16) && (data->irq <= IRQ_EINT23)) {
- gpcon_reg = S3C2410_GPGCON;
- extint_reg = S3C24XX_EXTINT2;
- gpcon_offset = (data->irq - IRQ_EINT8) * 2;
- extint_offset = (data->irq - IRQ_EINT16) * 4;
- } else {
- return -1;
- }
-
/* Set the GPIO to external interrupt mode */
value = __raw_readl(gpcon_reg);
value = (value & ~(3 << gpcon_offset)) | (0x02 << gpcon_offset);
@@ -227,6 +198,56 @@ s3c_irqext_type(struct irq_data *data, unsigned int type)
return 0;
}
+int
+s3c_irqext_type(struct irq_data *data, unsigned int type)
+{
+ void __iomem *extint_reg;
+ void __iomem *gpcon_reg;
+ unsigned long gpcon_offset, extint_offset;
+
+ if ((data->hwirq >= 4) && (data->hwirq <= 7)) {
+ gpcon_reg = S3C2410_GPFCON;
+ extint_reg = S3C24XX_EXTINT0;
+ gpcon_offset = (data->hwirq) * 2;
+ extint_offset = (data->hwirq) * 4;
+ } else if ((data->hwirq >= 8) && (data->hwirq <= 15)) {
+ gpcon_reg = S3C2410_GPGCON;
+ extint_reg = S3C24XX_EXTINT1;
+ gpcon_offset = (data->hwirq - 8) * 2;
+ extint_offset = (data->hwirq - 8) * 4;
+ } else if ((data->hwirq >= 16) && (data->hwirq <= 23)) {
+ gpcon_reg = S3C2410_GPGCON;
+ extint_reg = S3C24XX_EXTINT2;
+ gpcon_offset = (data->hwirq - 8) * 2;
+ extint_offset = (data->hwirq - 16) * 4;
+ } else {
+ return -EINVAL;
+ }
+
+ return s3c_irqext_set_type(gpcon_reg, extint_reg, gpcon_offset,
+ extint_offset, type);
+}
+
+int
+s3c_irqext0_type(struct irq_data *data, unsigned int type)
+{
+ void __iomem *extint_reg;
+ void __iomem *gpcon_reg;
+ unsigned long gpcon_offset, extint_offset;
+
+ if ((data->hwirq >= 0) && (data->hwirq <= 3)) {
+ gpcon_reg = S3C2410_GPFCON;
+ extint_reg = S3C24XX_EXTINT0;
+ gpcon_offset = (data->hwirq) * 2;
+ extint_offset = (data->hwirq) * 4;
+ } else {
+ return -EINVAL;
+ }
+
+ return s3c_irqext_set_type(gpcon_reg, extint_reg, gpcon_offset,
+ extint_offset, type);
+}
+
static struct irq_chip s3c_irqext_chip = {
.name = "s3c-ext",
.irq_mask = s3c_irqext_mask,
@@ -242,7 +263,7 @@ static struct irq_chip s3c_irq_eint0t4 = {
.irq_mask = s3c_irq_mask,
.irq_unmask = s3c_irq_unmask,
.irq_set_wake = s3c_irq_wake,
- .irq_set_type = s3c_irqext_type,
+ .irq_set_type = s3c_irqext0_type,
};
/* mask values for the parent registers for each of the interrupt types */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
From: Tomi Valkeinen @ 2012-11-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnOO0yMabku-_3yhi=1bwohbrb=rtFDOuKf1LPCAFv_OqCQ@mail.gmail.com>
On 2012-11-12 15:39, Grazvydas Ignotas wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> ...
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>
> Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
Yes.
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> That's a significant change, you should update Documentation/ .
Ah right. The documentation. I never remember =).
> What about omapfb.vram, is it still there?
Yes.
> Perhaps we also need to select/depend on CMA?
dma_alloc_* funcs work fine without CMA. CMA only makes them work
better. Thus I don't think OMAPFB should depend on CMA, but perhaps CMA
should be enabled by default in omap2plus_defconfig?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121112/e79a30b7/attachment.sig>
^ permalink raw reply
* [RFC 3/6] sched: pack small tasks
From: Vincent Guittot @ 2012-11-12 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109171344.GB16082@e103034-lin>
On 9 November 2012 18:13, Morten Rasmussen <Morten.Rasmussen@arm.com> wrote:
> Hi Vincent,
>
> I have experienced suboptimal buddy selection on a dual cluster setup
> (ARM TC2) if SD_SHARE_POWERLINE is enabled at MC level and disabled at
> CPU level. This seems to be the correct flag settings for a system with
> only cluster level power gating.
>
> To me it looks like update_packing_domain() is not doing the right
> thing. See inline comments below.
Hi Morten,
Thanks for testing the patches.
It seems that I have too optimized the loop and remove some use cases.
>
> On Sun, Oct 07, 2012 at 08:43:55AM +0100, Vincent Guittot wrote:
>> During sched_domain creation, we define a pack buddy CPU if available.
>>
>> On a system that share the powerline at all level, the buddy is set to -1
>>
>> On a dual clusters / dual cores system which can powergate each core and
>> cluster independantly, the buddy configuration will be :
>> | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> Small tasks tend to slip out of the periodic load balance.
>> The best place to choose to migrate them is at their wake up.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> kernel/sched/core.c | 1 +
>> kernel/sched/fair.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> kernel/sched/sched.h | 1 +
>> 3 files changed, 111 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index dab7908..70cadbe 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
>> rcu_assign_pointer(rq->sd, sd);
>> destroy_sched_domains(tmp, cpu);
>>
>> + update_packing_domain(cpu);
>> update_top_cache_domain(cpu);
>> }
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 4f4a4f6..8c9d3ed 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
>> update_sysctl();
>> }
>>
>> +
>> +/*
>> + * Save the id of the optimal CPU that should be used to pack small tasks
>> + * The value -1 is used when no buddy has been found
>> + */
>> +DEFINE_PER_CPU(int, sd_pack_buddy);
>> +
>> +/* Look for the best buddy CPU that can be used to pack small tasks
>> + * We make the assumption that it doesn't wort to pack on CPU that share the
>> + * same powerline. We looks for the 1st sched_domain without the
>> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the lowest
>> + * power per core based on the assumption that their power efficiency is
>> + * better */
>> +void update_packing_domain(int cpu)
>> +{
>> + struct sched_domain *sd;
>> + int id = -1;
>> +
>> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
>> + if (!sd)
>> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
>> + else
>> + sd = sd->parent;
> sd is the highest level where SD_SHARE_POWERLINE is enabled so the sched
> groups of the parent level would represent the power domains. If get it
> right, we want to pack inside the cluster first and only let first cpu
You probably wanted to use sched_group instead of cluster because
cluster is only a special use case, didn't you ?
> of the cluster do packing on another cluster. So all cpus - except the
> first one - in the current sched domain should find its buddy within the
> domain and only the first one should go to the parent sched domain to
> find its buddy.
We don't want to pack in the current sched_domain because it shares
power domain. We want to pack at the parent level
>
> I propose the following fix:
>
> - sd = sd->parent;
> + if (cpumask_first(sched_domain_span(sd)) == cpu
> + || !sd->parent)
> + sd = sd->parent;
We always look for the buddy in the parent level whatever the cpu
position in the mask is.
>
>
>> +
>> + while (sd) {
>> + struct sched_group *sg = sd->groups;
>> + struct sched_group *pack = sg;
>> + struct sched_group *tmp = sg->next;
>> +
>> + /* 1st CPU of the sched domain is a good candidate */
>> + if (id == -1)
>> + id = cpumask_first(sched_domain_span(sd));
>
> There is no guarantee that id is in the sched group pointed to by
> sd->groups, which is implicitly assumed later in the search loop. We
> need to find the sched group that contains id and point sg to that
> instead. I haven't found an elegant way to find that group, but the fix
> below should at least give the right result.
>
> + /* Find sched group of candidate */
> + tmp = sd->groups;
> + do {
> + if (cpumask_test_cpu(id, sched_group_cpus(tmp)))
> + {
> + sg = tmp;
> + break;
> + }
> + } while (tmp = tmp->next, tmp != sd->groups);
> +
> + pack = sg;
> + tmp = sg->next;
I have a new loop which solves your issue and others. I will use it
for the next version
+ while (sd) {
+ struct sched_group *sg = sd->groups;
+ struct sched_group *pack = sg;
+ struct sched_group *tmp;
+
+ /* The 1st CPU of the local group is a good candidate */
+ id = cpumask_first(sched_group_cpus(pack));
+
+ /* loop the sched groups to find the best one */
+ for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
+ if (tmp->sgp->power * pack->group_weight >
+ pack->sgp->power * tmp->group_weight)
+ continue;
+
+ if ((tmp->sgp->power * pack->group_weight ==
+ pack->sgp->power * tmp->group_weight)
+ && (cpumask_first(sched_group_cpus(tmp)) >= id))
+ continue;
+
+ /* we have found a better group */
+ pack = tmp;
+
+ /* Take the 1st CPU of the new group */
+ id = cpumask_first(sched_group_cpus(pack));
+ }
+
+ /* Look for another CPU than itself */
+ if ((id != cpu)
+ || ((sd->parent) && !(sd->parent->flags && SD_LOAD_BALANCE)))
+ break;
+
+ sd = sd->parent;
+ }
Regards,
Vincent
>
> Regards,
> Morten
>
>> +
>> + /* loop the sched groups to find the best one */
>> + while (tmp != sg) {
>> + if (tmp->sgp->power * sg->group_weight <
>> + sg->sgp->power * tmp->group_weight)
>> + pack = tmp;
>> + tmp = tmp->next;
>> + }
>> +
>> + /* we have found a better group */
>> + if (pack != sg)
>> + id = cpumask_first(sched_group_cpus(pack));
>> +
>> + /* Look for another CPU than itself */
>> + if ((id != cpu)
>> + || ((sd->parent) && !(sd->parent->flags && SD_LOAD_BALANCE)))
>> + break;
>> +
>> + sd = sd->parent;
>> + }
>> +
>> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
>> + per_cpu(sd_pack_buddy, cpu) = id;
>> +}
>> +
>> #if BITS_PER_LONG == 32
>> # define WMULT_CONST (~0UL)
>> #else
>> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct *p, int target)
>> return target;
>> }
>>
>> +static inline bool is_buddy_busy(int cpu)
>> +{
>> + struct rq *rq = cpu_rq(cpu);
>> +
>> + /*
>> + * A busy buddy is a CPU with a high load or a small load with a lot of
>> + * running tasks.
>> + */
>> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
>> + rq->avg.runnable_avg_period);
>> +}
>> +
>> +static inline bool is_light_task(struct task_struct *p)
>> +{
>> + /* A light task runs less than 25% in average */
>> + return ((p->se.avg.usage_avg_sum << 2) < p->se.avg.runnable_avg_period);
>> +}
>> +
>> +static int check_pack_buddy(int cpu, struct task_struct *p)
>> +{
>> + int buddy = per_cpu(sd_pack_buddy, cpu);
>> +
>> + /* No pack buddy for this CPU */
>> + if (buddy == -1)
>> + return false;
>> +
>> + /*
>> + * If a task is waiting for running on the CPU which is its own buddy,
>> + * let the default behavior to look for a better CPU if available
>> + * The threshold has been set to 37.5%
>> + */
>> + if ((buddy == cpu)
>> + && ((p->se.avg.usage_avg_sum << 3) < (p->se.avg.runnable_avg_sum * 5)))
>> + return false;
>> +
>> + /* buddy is not an allowed CPU */
>> + if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
>> + return false;
>> +
>> + /*
>> + * If the task is a small one and the buddy is not overloaded,
>> + * we use buddy cpu
>> + */
>> + if (!is_light_task(p) || is_buddy_busy(buddy))
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> /*
>> * sched_balance_self: balance the current task (running on cpu) in domains
>> * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
>> @@ -3098,6 +3204,9 @@ select_task_rq_fair(struct task_struct *p, int sd_flag, int wake_flags)
>> if (p->nr_cpus_allowed == 1)
>> return prev_cpu;
>>
>> + if (check_pack_buddy(cpu, p))
>> + return per_cpu(sd_pack_buddy, cpu);
>> +
>> if (sd_flag & SD_BALANCE_WAKE) {
>> if (cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
>> want_affine = 1;
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index a95d5c1..086d8bf 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -875,6 +875,7 @@ static inline void idle_balance(int cpu, struct rq *rq)
>>
>> extern void sysrq_sched_debug_show(void);
>> extern void sched_init_granularity(void);
>> +extern void update_packing_domain(int cpu);
>> extern void update_max_interval(void);
>> extern void update_group_power(struct sched_domain *sd, int cpu);
>> extern int update_runtime(struct notifier_block *nfb, unsigned long action, void *hcpu);
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>>
>
^ permalink raw reply
* [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
From: Tomi Valkeinen @ 2012-11-12 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnOO0yMabku-_3yhi=1bwohbrb=rtFDOuKf1LPCAFv_OqCQ@mail.gmail.com>
On 2012-11-12 15:39, Grazvydas Ignotas wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> ...
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>
> Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> That's a significant change, you should update Documentation/ .
I've added the following documentation change:
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index a564cee..4484e02 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD
Misc notes
----------
-OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
+OMAP FB allocates the framebuffer memory using the standard dma allocator. You
+can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
+allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
+the global memory area for CMA.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024 at 57 output from DVI.
@@ -301,11 +304,6 @@ framebuffer parameters.
Kernel boot arguments
---------------------
-vram=<size>[,<physaddr>]
- - Amount of total VRAM to preallocate and optionally a physical start
- memory address. For example, "10M". omapfb allocates memory for
- framebuffers from VRAM.
-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121112/64153f68/attachment-0001.sig>
^ permalink raw reply related
* [PATCH] ARM: implement optimized percpu variable access
From: Rob Herring @ 2012-11-12 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112132811.GF2346@mudshark.cambridge.arm.com>
On 11/12/2012 07:28 AM, Will Deacon wrote:
> On Mon, Nov 12, 2012 at 01:03:12PM +0000, Rob Herring wrote:
>> On 11/12/2012 04:23 AM, Will Deacon wrote:
>>>> +static inline void set_my_cpu_offset(unsigned long off)
>>>> +{
>>>> + asm volatile("mcr p15, 0, %0, c13, c0, 4 @ set TPIDRPRW" : : "r" (off) : "cc" );
>>>> +}
>>>
>>> You don't need the "cc" here.
>>
>> You would think so, but the compiler drops this instruction if you
>> don't. set_cr does the same thing.
>
> Whoa, that sounds suspicious... if the thing is marked volatile GCC
> shouldn't optimise it away if it's reachable. Which toolchain are you
> using?
Ubuntu 12.10 ARM cross compiler:
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1)
Rob
^ permalink raw reply
* [GIT PULL v4] Renesas ARM-based SoC for v3.8
From: Bastian Hecht @ 2012-11-12 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106143202.GF27284@quad.lixom.net>
Hello Olof,
unfortunately 3 patches contributed by me are "evil" and need to removed.
Bastian Hecht (4):
ARM: shmobile: emev2: Replace modify_scu_cpu_psr with scu_power_mode
ARM: shmobile: sh73a0: Replace modify_scu_cpu_psr with scu_power_mode
ARM: shmobile: r8a7779: Replace modify_scu_cpu_psr with scu_power_mode
...
The code changes the flags of the wrong cpus - which breaks the whole
bootup of secondary CPUs. So please drop these patches!
Sorry for being too careless in this sensitive area - I'll do better.
Thanks,
Bastian
2012/11/6 Olof Johansson <olof@lixom.net>:
> On Tue, Nov 06, 2012 at 01:57:22PM +0900, Simon Horman wrote:
>> Hi Olof, Hi Arnd,
>>
>> please consider the following SoC enhancements for 3.8.
>>
>> Change since v3:
>> * Remove noise from "ARM: shmobile: Remove SH7367 support"
>>
>> ----------------------------------------------------------------
>> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>>
>> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
>
> Pulled, thanks!
>
>
> -Olof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-12 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VxgbCGzOPVtQq-LYsEPuyyGjRDfB3jHPtvbHr1xLgntXA@mail.gmail.com>
On 11:54 Sat 10 Nov , Joachim Eastwood wrote:
> Hi Jean-Christophe,
>
> On 7 November 2012 12:22, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> > Cc: linux-ide at vger.kernel.org
> > Cc: linux-input at vger.kernel.org
> > Cc: linux-mmc at vger.kernel.org
> > Cc: linux-can at vger.kernel.org
> > Cc: netdev at vger.kernel.org
> > Cc: linux-pcmcia at lists.infradead.org
> > Cc: rtc-linux at googlegroups.com
> > Cc: spi-devel-general at lists.sourceforge.net
> > Cc: linux-serial at vger.kernel.org
> > Cc: linux-usb at vger.kernel.org
> > Cc: linux-fbdev at vger.kernel.org
> > ---
> > HI all,
> >
> > If it's ok with everyone this will go via at91
> > with the patch serie than clean up the include/mach
> >
> > For preparation to switch to arm multiarch kernel
> >
> > Best Regards,
> > J.
> > arch/arm/mach-at91/include/mach/board.h | 55 ----------------------
> > arch/avr32/mach-at32ap/include/mach/board.h | 7 ---
> > drivers/ata/pata_at91.c | 2 +-
> > drivers/input/touchscreen/atmel_tsadcc.c | 2 +-
> > drivers/mmc/host/atmel-mci.c | 2 +-
> > drivers/net/can/at91_can.c | 3 +-
> > drivers/net/ethernet/cadence/at91_ether.c | 2 +-
> > drivers/pcmcia/at91_cf.c | 2 +-
> > drivers/rtc/rtc-at91sam9.c | 2 +-
> > drivers/spi/spi-atmel.c | 2 +-
> > drivers/tty/serial/atmel_serial.c | 2 +-
> > drivers/usb/gadget/at91_udc.c | 2 +-
> > drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> > drivers/usb/host/ohci-at91.c | 2 +-
> > drivers/video/atmel_lcdfb.c | 2 +-
> > include/linux/platform_data/atmel.h | 67 +++++++++++++++++++++++++++
> > 16 files changed, 80 insertions(+), 76 deletions(-)
>
> <snip>
>
> > diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> > index 4e980a7..35fc6edb 100644
> > --- a/drivers/net/ethernet/cadence/at91_ether.c
> > +++ b/drivers/net/ethernet/cadence/at91_ether.c
> > @@ -31,6 +31,7 @@
> > #include <linux/clk.h>
> > #include <linux/gfp.h>
> > #include <linux/phy.h>
> > +#include <linux/platform_data/atmel.h>
> >
> > #include <asm/io.h>
> > #include <asm/uaccess.h>
> > @@ -38,7 +39,6 @@
> >
> > #include <mach/at91rm9200_emac.h>
> > #include <asm/gpio.h>
> > -#include <mach/board.h>
> >
> > #include "at91_ether.h"
>
> The at91_ether driver in net-next does not need to be change since it
> all mach includes has already been removed by other patches and it
> includes linux/platform_data/macb.h directly.
>
> What tree was these patches based on?
> The at91_ether driver changes has been in linux-next for a long while now.
the conflict is minor easy to handle and the cleanup need to go first on arm soc so this is
based on rc3
Best Regards,
J.
^ permalink raw reply
* [PATCH] ARM: dts: add board dts file for Exynos4412 based SMDK board
From: Tomasz Figa @ 2012-11-12 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351954172-13645-1-git-send-email-thomas.abraham@linaro.org>
Hi Thomas,
On Saturday 03 of November 2012 20:19:32 Thomas Abraham wrote:
> Add a minimal board dts file for Samsung Exynos4412 based SMDK board.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> This patch depends the on the following patch posted by Tomasz Figa.
> "ARM: dts: exynos4: Add support for Exynos4x12 SoCs"
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 45
> +++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+), 0
> deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-smdk4412.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f37cf9f..36488a5 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -23,6 +23,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> exynos4210-smdkv310.dtb \
> exynos4210-trats.dtb \
> + exynos4412-smdk4412.dtb \
> exynos5250-smdk5250.dtb
> dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
> dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
> diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts
> b/arch/arm/boot/dts/exynos4412-smdk4412.dts new file mode 100644
> index 0000000..f05bf57
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
> @@ -0,0 +1,45 @@
> +/*
> + * Samsung's Exynos4412 based SMDK board device tree source
> + *
> + * Copyright (c) 2012-2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Device tree source file for Samsung's SMDK4412 board which is based
> on + * Samsung's Exynos4412 SoC.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as +
> * published by the Free Software Foundation.
> +*/
> +
> +/dts-v1/;
> +/include/ "exynos4412.dtsi"
> +
> +/ {
> + model = "Samsung SMDK evaluation board based on Exynos4412";
> + compatible = "samsung,smdk4412", "samsung,exynos4412";
> +
> + memory {
> + reg = <0x40000000 0x40000000>;
> + };
This will not boot, because section size limit is set to 256 MiB.
It might work with CONFIG_ARM_ATAG_DTB_COMPAT enabled, because the memory
configuration from DT is ignored and values from ATAGs are taken instead.
I suggest you to change it to 4 banks of 256 MiB.
> + chosen {
> + bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M
> console=ttySAC1,115200 init=/linuxrc"; + };
> +
> + serial at 13800000 {
> + status = "okay";
> + };
> +
> + serial at 13810000 {
> + status = "okay";
> + };
> +
> + serial at 13820000 {
> + status = "okay";
> + };
> +
> + serial at 13830000 {
> + status = "okay";
> + };
> +};
Otherwise looks fine.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCHv6 0/2] Add support for the OLED in the CFA10036
From: Maxime Ripard @ 2012-11-12 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351674774-2891-1-git-send-email-maxime.ripard@free-electrons.com>
Ping?
Le 31/10/2012 10:12, Maxime Ripard a ?crit :
> Hi everyone,
>
> This patchset adds support for the solomon SSD1307 OLED controller present
> in the CFA-10036 board.
>
> It first adds the framebuffer driver for this controller, and then the
> needed bits to enable it in the cfa10036 dts.
>
> Considering that the driver has been around since almost three months now, and
> I have not received any comments on the framebuffer part, I'd very much like it
> to be included in 3.8 if possible.
>
> Thanks,
> Maxime
>
> Changes from v5:
> * Fixed bogus reset code
>
> Maxime Ripard (2):
> video: Add support for the Solomon SSD1307 OLED Controller
> ARM: dts: mxs: add oled support for the cfa-10036
>
> .../devicetree/bindings/video/ssd1307fb.txt | 24 ++
> arch/arm/boot/dts/imx28-cfa10036.dts | 19 +
> drivers/video/Kconfig | 13 +
> drivers/video/Makefile | 1 +
> drivers/video/ssd1307fb.c | 407 ++++++++++++++++++++
> 5 files changed, 464 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt
> create mode 100644 drivers/video/ssd1307fb.c
>
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 00/11] arch_gettimeoffset and ARM timer rework
From: Arnd Bergmann @ 2012-11-12 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-1-git-send-email-swarren@wwwdotorg.org>
On Thursday 08 November 2012, Stephen Warren wrote:
> It would probably be easiest to merge this whole series through the
> arm-soc tree. Anything else would require some co-ordination.
Fine with me. The patches all look good to me, so let's give people a
little more time to weigh in with Acks and possible objections.
In particular, I hope Russell can comment if he has an opionion on these.
Arnd
^ permalink raw reply
* [PATCH] ARM: implement optimized percpu variable access
From: Rob Herring @ 2012-11-12 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112102354.GA2346@mudshark.cambridge.arm.com>
On 11/12/2012 04:23 AM, Will Deacon wrote:
> Hi Rob,
>
> On Sun, Nov 11, 2012 at 03:20:40AM +0000, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Use the previously unused TPIDRPRW register to store percpu offsets.
>> TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.
>>
>> This saves 2 loads for each percpu variable access which should yield
>> improved performance, but the improvement has not been quantified.
>
> The patch looks largely fine to me (one minor comment below), but we should
> try and see what the performance difference is like on a few cores before
> merging this. Have you tried something like hackbench to see if the
> difference is measurable there? If not, I guess we'll need something more
> targetted.
Looks like it's about a 1.4% improvement on Cortex-A9 (highbank) with
hackbench.
Average of 30 runs of "hackbench -l 1000":
Before: 6.2190666667
After: 6.1347666667
I'll add this data to the commit msg.
Rob
>
>> diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
>> new file mode 100644
>> index 0000000..9eb7372
>> --- /dev/null
>> +++ b/arch/arm/include/asm/percpu.h
>> @@ -0,0 +1,44 @@
>> +/*
>> + * Copyright 2012 Calxeda, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +#ifndef _ASM_ARM_PERCPU_H_
>> +#define _ASM_ARM_PERCPU_H_
>> +
>> +/*
>> + * Same as asm-generic/percpu.h, except that we store the per cpu offset
>> + * in the TPIDRPRW.
>> + */
>> +#if defined(CONFIG_SMP) && (__LINUX_ARM_ARCH__ >= 6)
>> +
>> +static inline void set_my_cpu_offset(unsigned long off)
>> +{
>> + asm volatile("mcr p15, 0, %0, c13, c0, 4 @ set TPIDRPRW" : : "r" (off) : "cc" );
>> +}
>
> You don't need the "cc" here.
>
> Will
>
>
^ permalink raw reply
* [GIT PULL] arm-soc: lpc32xx: platform updates
From: Arnd Bergmann @ 2012-11-12 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A0D053.8020602@antcom.de>
On Monday 12 November 2012, Roland Stigge wrote:
> this is a follow-up update of the previous pull request, adding only one patch
> to the LPC32xx platform (Motor PWM clock by Alban Bedel).
>
> The following changes since commit 91deef8069e7ffafac4467200e1d37af1b2d7c56:
>
> ARM: LPC32xx: Cleanup irq.c (2012-11-07 13:30:50 +0100)
>
> are available in the git repository at:
>
> git://git.antcom.de/linux-2.6.git lpc32xx/core
>
Pulled into next/soc, thanks!
It would be nice if you could start using signed tag for pull requests
and put a little series description into that tag. Ideally signed with
a gpg key that is trusted by other kernel developers, but just having the
changelog is good as well.
Arnd
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Will Deacon @ 2012-11-12 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGtR0WBjoWbb2BF-hJa9sQi2Aa75dfrfb1u5EncaOB7Pyw@mail.gmail.com>
On Mon, Nov 12, 2012 at 01:46:57PM +0000, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Nov 09, 2012 at 09:17:33PM +0000, Rob Clark wrote:
> >> @@ -122,22 +124,35 @@ extern int __get_user_4(void *);
> >> ({ \
> >> unsigned long __limit = current_thread_info()->addr_limit - 1; \
> >> register const typeof(*(p)) __user *__p asm("r0") = (p);\
> >> - register unsigned long __r2 asm("r2"); \
> >> register unsigned long __l asm("r1") = __limit; \
> >> register int __e asm("r0"); \
> >> switch (sizeof(*(__p))) { \
> >> - case 1: \
> >> + case 1: { \
> >> + register unsigned long __r2 asm("r2"); \
> >> __get_user_x(__r2, __p, __e, __l, 1); \
> >> + x = (typeof(*(p))) __r2; \
> >> break; \
> >> - case 2: \
> >> + } \
> >> + case 2: { \
> >> + register unsigned long __r2 asm("r2"); \
> >> __get_user_x(__r2, __p, __e, __l, 2); \
> >> + x = (typeof(*(p))) __r2; \
> >> break; \
> >> - case 4: \
> >> + } \
> >> + case 4: { \
> >> + register unsigned long __r2 asm("r2"); \
> >> __get_user_x(__r2, __p, __e, __l, 4); \
> >> + x = (typeof(*(p))) __r2; \
> >> + break; \
> >> + } \
> >> + case 8: { \
> >> + register unsigned long long __r2 asm("r2"); \
> >
> > Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
> > asm, so the compiler shouldn't care much. For OABI, I think you may have to
> > do some more work to get the two words where you want them.
>
> Is the question whether the compiler is guaranteed to allocate r2 and
> r3 in all cases? I'm not quite sure, I confess to usually trying to
> avoid inline asm. But from looking at the disassembly (for little
> endian EABI build) it seemed to do the right thing.
I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...
> The only other idea I had was to explicitly declare two 'unsigned
> long's and then shift them into a 64bit x, although I'm open to
> suggestions if there is a better way.
Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?
> >> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> >> index 9b06bb4..d05285c 100644
> >> --- a/arch/arm/lib/getuser.S
> >> +++ b/arch/arm/lib/getuser.S
> >> @@ -18,7 +18,7 @@
> >> * Inputs: r0 contains the address
> >> * r1 contains the address limit, which must be preserved
> >> * Outputs: r0 is the error code
> >> - * r2 contains the zero-extended value
> >> + * r2, r3 contains the zero-extended value
> >> * lr corrupted
> >> *
> >> * No other registers must be altered. (see <asm/uaccess.h>
> >> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
> >> mov pc, lr
> >> ENDPROC(__get_user_4)
> >>
> >> +ENTRY(__get_user_8)
> >> + check_uaccess r0, 4, r1, r2, __get_user_bad
> >
> > Shouldn't you be passing 8 here, so that we validate the correct range?
>
> yes, sorry, I'll fix that
>
> >> +#ifdef CONFIG_THUMB2_KERNEL
> >> +5: TUSER(ldr) r2, [r0]
> >> +6: TUSER(ldr) r3, [r0, #4]
> >> +#else
> >> +5: TUSER(ldr) r2, [r0], #4
> >> +6: TUSER(ldr) r3, [r0]
> >> +#endif
> >
> > This doesn't work for EABI big-endian systems.
>
> Hmm, is that true? Wouldn't put_user() then have the same problem?
I dug up the PCS and it seems that we arrange the two halves of the
doubleword to match the ldm/stm memory representation for EABI, so sorry
for the confusion.
> I guess __ARMEB__ is the flag for big-endian?
That's the thing defined by the compiler, yes.
Will
^ permalink raw reply
* Build failure: OMAP4430 failed due to exynos4 pinctrl
From: Arnd Bergmann @ 2012-11-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <007b01cdc0bf$50c9ee70$f25dcb50$%kim@samsung.com>
On Monday 12 November 2012, Kukjin Kim wrote:
> Russell King - ARM Linux wrote:
> >
> > Last night's randconfig for OMAP4430 failed with:
> >
> > drivers/built-in.o:(.rodata+0x1a60): undefined reference to
> > `exynos4210_pin_ctrl'
> >
> > Config and log:
> > http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2693
> > http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2693
>
> Oops, yeah right.
Hmm, I found the same thing earlier and it got lost in my backlog of unsubmitted
patches.
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 7bf914d..18b473b 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -179,11 +179,13 @@ config PINCTRL_COH901
>
> config PINCTRL_SAMSUNG
> bool "Samsung pinctrl driver"
> + depends on PLAT_SAMSUNG
> select PINMUX
> select PINCONF
>
> config PINCTRL_EXYNOS4
> bool "Pinctrl driver data for Exynos4 SoC"
> + depends on PINCTRL_SAMSUNG && ARCH_EXYNOS4
> select PINCTRL_SAMSUNG
This won't work. A driver can't "select" and "depend on"
another symbol at the same time.
This is what I came up with earlier.
Arnd
8<----------------
>From a15cc6277a3a43c8b5c1dd90ca71732b2ffe2b18 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 10 Oct 2012 13:31:45 +0000
Subject: [PATCH] pinctrl: samsung: don't allow enabling pinctrl-samsung
standalone
The main samsung pinctrl module references the specific exynos4210
pinctrl driver, which selects the main driver in Kconfig.
Making the main driver a silent "bool" option avoid this potential
build error if CONFIG_PINCTRL_SAMSUNG=y && CONFIG_PINCTRL_EXYNOS4=n:
drivers/built-in.o:(.rodata+0x4e4): undefined reference to `exynos4210_pin_ctrl'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7bf914d..9f54bd4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -178,7 +178,7 @@ config PINCTRL_COH901
ports of 8 GPIO pins each.
config PINCTRL_SAMSUNG
- bool "Samsung pinctrl driver"
+ bool
select PINMUX
select PINCONF
^ permalink raw reply related
* [PATCH] ARM: implement optimized percpu variable access
From: Will Deacon @ 2012-11-12 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A105E7.6000005@gmail.com>
On Mon, Nov 12, 2012 at 02:21:27PM +0000, Rob Herring wrote:
> On 11/12/2012 04:23 AM, Will Deacon wrote:
> > Hi Rob,
> >
> > On Sun, Nov 11, 2012 at 03:20:40AM +0000, Rob Herring wrote:
> >> From: Rob Herring <rob.herring@calxeda.com>
> >>
> >> Use the previously unused TPIDRPRW register to store percpu offsets.
> >> TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.
> >>
> >> This saves 2 loads for each percpu variable access which should yield
> >> improved performance, but the improvement has not been quantified.
> >
> > The patch looks largely fine to me (one minor comment below), but we should
> > try and see what the performance difference is like on a few cores before
> > merging this. Have you tried something like hackbench to see if the
> > difference is measurable there? If not, I guess we'll need something more
> > targetted.
>
> Looks like it's about a 1.4% improvement on Cortex-A9 (highbank) with
> hackbench.
>
> Average of 30 runs of "hackbench -l 1000":
>
> Before: 6.2190666667
> After: 6.1347666667
>
> I'll add this data to the commit msg.
Wow, that's really cool! I'll take it for a spin on 11MPCore to test the v6
angle...
Will
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Tero Kristo @ 2012-11-12 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqxy77li.fsf@deeprootsystems.com>
On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >>
> >> Tero Kristo <t-kristo@ti.com> writes:
> >>
> >> > Hi,
> >> >
> >> > Changes compared to previous version:
> >> > - rebased on top of 3.7-rc1
> >> > - applies on top of latest func pwrst code (v6)
> >> > - added back patch #1 to this set (it wasn't queued yet after all)
> >> > - added patch #7 for fixing a bug in the functional pwrst code
> >> > - added patch #8 for fixing a regression with MUSB PHY power handling
> >> > (not quite sure if this is the correct way to fix this or not)
> >> >
> >> > Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
> >> > suspend.
> >> >
> >> > Branch also available here:
> >> > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> >> > branch: mainline-3.7-rc1-omap4-ret-v9
> >>
> >> I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
> >> several domains not hitting target power state in suspend[1].
> >>
> >> Am I missing some other fixes? Using omap2plus_defconfig, I tried your
> >> branch alone, and merged with v3.7-rc4, and I get the same errors.
>
> [...]
>
> > This looks like a combination of boot loader/kernel problems. My guess
> > is that l3init is probably held on by the USB, and both ivahd / tesla
> > are held on by some DSP/IVA modules which are not idling properly.
> >
> > The last patch in this set should fix the USB problems at least
> > partially, but also the USB DPLL itself might be in wrong state,
> > attached patch might help for that one and get l3init to idle.
> >
> > For DSP I don't have a patch right now, what is the boot loader you are
> > using? (Can you provide git / commit / config info?)
>
> I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
>
> To check the bootloader, I upgraded to the latest mainline tag
> (v2012.10) and the problems are gone on both 4430/Panda and
> 4460/Panda-ES... Interesting.
>
> That suggests that there's still some kernel assumptions/dependencies on
> the bootloader that need to be addressed.
After a little bit of looking into this, this is pretty similar to what
I was working on quite a while back once I tried to get the core ret
work with mainline kernel. I ended up sending patches against the
boot-loader as there wasn't a readily visible solution to some of the
issues on kernel side => so now if you update the u-boot, it gets fixed.
I am seeing (at least) following subsystems being non-idle with the old
bootloader:
- M3 cortex (stuck in transition)
- DSP (stuck in transition)
- SL2IF (stuck in transition)
- FSUSB (stuck in transition)
...but I am not aware of any way to get these to working properly from
this state without POR. Some of them probably require firmware to be
loaded and letting them out of reset also (M3 / DSP.) Benoit, do you
have any clues?
-Tero
^ permalink raw reply
* [PATCH 0/6] ARM: integrator: SoC bus & cleanup
From: Arnd Bergmann @ 2012-11-12 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352681542-12835-1-git-send-email-linus.walleij@linaro.org>
On Monday 12 November 2012, Linus Walleij wrote:
> This series will:
>
> - Switch the Integrator/AP and /CP to use the SoC bus
> when booting from device tree.
> - Group all devices on the SoC below this bus so as to
> set a good example of how to do this. The bus was
> invented by Lee Jones, let's show how it's to be used
> on a DT:ed SoC.
> - Fetch the special system controller offsets from two
> special device tree nodes for each case and replace
> the static mappings with these at boot.
> - Move some static remaps to the ATAG-only code path
> and delete some static maps that aren't used.
Nice series,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 05/11] ARM: at91: convert timer suspend/resume to clock_event_device
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-7-git-send-email-swarren@wwwdotorg.org>
On 14:01 Thu 08 Nov , Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Move at91's timer suspend/resume functions from struct sys_timer
> at91sam926x_timer into struct clock_event_device pit_clkevt. This
> will allow the sys_timer suspend/resume fields to be removed, and
> eventually lead to a complete removal of struct sys_timer.
>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
look fine
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ 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