* [PATCH] ARM: add get_user() support for 8 byte types
From: Will Deacon @ 2012-11-12 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352495853-9790-1-git-send-email-rob.clark@linaro.org>
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.
> + __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?
> +#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.
Will
^ permalink raw reply
* [PATCH 01/11] cris: move usec/nsec conversion to do_slow_gettimeoffset
From: Jesper Nilsson @ 2012-11-12 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-3-git-send-email-swarren@wwwdotorg.org>
On Thu, Nov 08, 2012 at 02:01:46PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Move usec to nsec conversion from arch_gettimeoffset() to
> do_slow_gettimeoffset(); in a future patch, do_slow_gettimeoffset()
> will be used directly as the implementation of arch_gettimeoffset(),
> so needs to perform all required calculations.
>
> Cc: Mikael Starvik <starvik@axis.com>
> Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> Cc: linux-cris-kernel at axis.com
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> arch/cris/arch-v10/kernel/time.c | 4 ++--
> arch/cris/kernel/time.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
> index bcffcb6..162892f 100644
> --- a/arch/cris/arch-v10/kernel/time.c
> +++ b/arch/cris/arch-v10/kernel/time.c
> @@ -65,8 +65,8 @@ unsigned long do_slow_gettimeoffset(void)
> */
> count = *R_TIMER0_DATA;
>
> - /* Convert timer value to usec */
> - return (TIMER0_DIV - count) * ((NSEC_PER_SEC/1000)/HZ)/TIMER0_DIV;
> + /* Convert timer value to nsec */
> + return (TIMER0_DIV - count) * (NSEC_PER_SEC/HZ)/TIMER0_DIV;
> }
>
> /* Excerpt from the Etrax100 HSDD about the built-in watchdog:
> diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
> index 277ffc4..b063c92 100644
> --- a/arch/cris/kernel/time.c
> +++ b/arch/cris/kernel/time.c
> @@ -46,7 +46,7 @@ static unsigned long (*do_gettimeoffset)(void) = do_slow_gettimeoffset;
>
> u32 arch_gettimeoffset(void)
> {
> - return do_gettimeoffset() * 1000;
> + return do_gettimeoffset();
> }
> #endif
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A0A44B.6080604@compulab.co.il>
On Mon, Nov 12, 2012 at 12:54:59, Igor Grinberg wrote:
> On 11/12/12 08:38, Hiremath, Vaibhav wrote:
> > On Sun, Nov 11, 2012 at 17:05:07, Igor Grinberg wrote:
> >>
> >>
> >> On 11/08/12 20:34, Jon Hunter wrote:
> >>>
> >>> On 11/08/2012 12:17 PM, Paul Walmsley wrote:
> >>>> On Thu, 8 Nov 2012, Jon Hunter wrote:
> >>>>
> >>>>> On 11/08/2012 11:58 AM, Paul Walmsley wrote:
> >>>>>> On Thu, 8 Nov 2012, Jon Hunter wrote:
> >>>>>>
> >>>>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
> >>>>>>> present. However, I am not sure which devices support this and is
> >>>>>>> applicable too.
> >>>>>>
> >>>>>> Pretty sure Igor is referring to the AM3517/3505. This is very poorly
> >>>>>> documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure
> >>>>>> 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4
> >>>>>> "Clock Specifications".
> >>>>>
> >>>>> But AFAICT, even in that h/w configuration the internal 32k
> >>>>> oscillator will be used
> >>>>
> >>>> Just to clarify, there's no internal 32k oscillator used on the 3517/3505;
> >>>> just a divider from the HF clock.
> >>>
> >>> Ah yes I see that now!
> >>>
> >>>>> and so the gptimer will still have a 32k clock source.
> >>>>
> >>>> That's a good question and you might want to check with Igor on that one,
> >>>> the AM3517 TRM conflicts with the DM as to whether it's available to the
> >>>> GPTIMER or not :-(
> >>>
> >>> Well the external 32k and internal divided down version go through the
> >>> same mux and so that seems to imply either they are both available to
> >>> the gptimer or neither is.
> >>
> >> Yep, but the /800 do not get you the 32768...
> >> and that makes the timer suck.
> >> Of course this can be dealt with in the clock subsystem
> >> (I remember Paul said that he will look into that), but it will take time.
> >>
> >> Also, what about having the sys_clk instead of 32k for higher precision?
> >> Is that possible already (without my patch)?
> >>
> >
> > Yes, it is possible. You can choose it through bootargs.
>
> Is the kernel command line the only way for doing this?
> I personally dislike it, because it brings multiple maintenance problems.
> This must be possible at least through DT.
>
Its standard interface, so carries all the applicable pros and cons.
I am not quite sure about runtime change of clocksoyrce, its pros and cons.
Thanks,
Vaibhav
>
> --
> Regards,
> Igor.
>
^ permalink raw reply
* [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Andrew Lunn @ 2012-11-12 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A0C5D2.7000806@web.de>
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
> On 11.11.2012 18:22, Andrew Lunn wrote:
> > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless
> >> the flags provided by the caller. This causes excessive pruning of
> >> emergency memory pools without any good reason. This patch
> changes the code
> >> to correctly use gfp flags provided by the dmapool caller. This should
> >> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> >> allocations can be served only from the special, very limited
> memory pool.
> >>
> >> Reported-by: Soren Moch <smoch@web.de>
> Please use
> Reported-by: Soeren Moch <smoch@web.de>
>
> >> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >
> > Tested-by: Andrew Lunn <andrew@lunn.ch>
> >
> > I tested this on a Kirkwood QNAP after removing the call to
> > init_dma_coherent_pool_size().
> >
> > Andrew
>
> Tested-by: Soeren Moch <smoch@web.de>
>
> Now I had a chance to test this patch on my Kirkwood guruplug
> system with linux-3.6.6 . It is running much better now, but with the
> original 256K coherent pool size I still see errors after several hours
> of runtime:
>
> Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool
> is too small!
> Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool=
> kernel parameter!
Hi Soeren
Could you tell us what DVB devices you are using.
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 2/5] ARM: kernel: add device tree init map function
From: Mark Rutland @ 2012-11-12 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352471654-20207-3-git-send-email-lorenzo.pieralisi@arm.com>
On Fri, Nov 09, 2012 at 02:34:11PM +0000, Lorenzo Pieralisi wrote:
> When booting through a device tree, the kernel cpu logical id map can be
> initialized using device tree data passed by FW or through an embedded blob.
>
> This patch adds a function that parses device tree "cpu" nodes and
> retrieves the corresponding CPUs hardware identifiers (MPIDR).
> It sets the possible cpus and the cpu logical map values according to
> the number of CPUs defined in the device tree and respective properties.
>
> The device tree HW identifiers are considered valid if all CPU nodes contain
> a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0]
> of the boot CPU.
>
> The primary CPU is assigned cpu logical number 0 to keep the current convention
> valid.
>
> Current bindings documentation is included in the patch:
>
> Documentation/devicetree/bindings/arm/cpus.txt
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++
> arch/arm/include/asm/prom.h | 2 +
> arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++
> 3 files changed, 162 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> new file mode 100644
> index 0000000..83cd98a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -0,0 +1,84 @@
> +* ARM CPUs binding description
> +
> +The device tree allows to describe the layout of CPUs in a system through
> +the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> +defining properties for every cpu.
> +
> +Bindings for CPU nodes follow the ePAPR standard, available from:
> +
> +http://devicetree.org
> +
> +For the ARM architecture every CPU node must contain the following properties:
> +
> +- reg : property matching the CPU MPIDR[23:0] register bits
> +- compatible: must be set to "arm, <cpu-model>"
> + where <cpu-model> is the full processor name as used in the
> + processor Technical Reference Manual, eg:
> + - for a Cortex A9 processor
> + compatible = <arm, cortex-a9>;
> + - for a Cortex A15 processor
> + compatible = <arm, cortex-a15>;
> +
> +List of possible "compatible" string ids:
> +
> +<arm, arm1020>
> +<arm, arm1020e>
> +<arm, arm1022>
> +<arm, arm1026>
> +<arm, arm720>
> +<arm, arm740>
> +<arm, arm7tdmi>
> +<arm, arm920>
> +<arm, arm922>
> +<arm, arm925>
> +<arm, arm926>
> +<arm, arm940>
> +<arm, arm946>
> +<arm, arm9tdmi>
> +<arm, fa526>
> +<arm, feroceon>
> +<arm, mohawk>
> +<arm, sa110>
> +<arm, sa1100>
> +<arm, xsc3>
> +<arm, xscale>
> +<arm, cortex-a5>
> +<arm, cortex-a7>
> +<arm, cortex-a8>
> +<arm, cortex-a9>
> +<arm, cortex-a15>
> +<arm, arm1136>
> +<arm, arm11-mpcore>
> +
Is there any reason for the spaces in the compatible string? No other binding
seems to do this.
Is <STRING> a valid dts format? Should these not be "STRING" instead?
For consistency, it would be nice to have the compatible strings tab-indented
as in Documentation/devicetree/bindings/arm/pmu.txt.
Thanks,
Mark
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-12 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509C050C.6010201@ti.com>
On Fri, Nov 09, 2012 at 00:46:28, Hunter, Jon wrote:
>
> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
> > On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
> >>
> >> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
> >>
> >> [snip]
> >>
> >>> There is no reliable way to determine which source should be used in runtime
> >>> for boards that do not have the 32k oscillator wired.
> >>
> >> So thinking about this some more and given that we are moving away from
> >> board files, if a board does not provide a 32kHz clock source, then this
> >> should be reflected in the device-tree source file for that board.
> >> Hence, at boot time we should be able to determine if a 32kHz clock
> >> source can be used.
> >>
> >
> > Let me feed some more thoughts here :)
> >
> > The way it is being detected currently is based on timer idle status bit.
> > I am worried that, this is the only option we have.
>
> Why not use device-tree to indicate the presence of a 32k clock source?
> This seems like a board level configuration and so device-tree seems to
> be the perfect place for this IMO.
>
I think I agree with you, but for this to happen in clean way, its time to
start populating clock-nodes in DT, don't you think? Something like,
clocks {
rtc_clk: clk at X {
compatible = "crystal-32k, per-32k, xyz";
clock-frequency = <32768>;
};
...
};
Timer {
ref-clock = <&rtc_clk>;
};
What do you think?
Thanks,
Vaibhav
^ permalink raw reply
* [GIT PULL] arm-soc: lpc32xx: platform updates
From: Roland Stigge @ 2012-11-12 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A5992.60009@antcom.de>
Hi Arnd and Olof,
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).
Thanks,
Roland
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
for you to fetch changes up to 84cee34db4d34b9059f4ef66f7d1805e438cc7f3:
ARM: LPC32xx: Add the motor PWM clock (2012-11-12 11:27:40 +0100)
----------------------------------------------------------------
Alban Bedel (1):
ARM: LPC32xx: Add the motor PWM clock
arch/arm/mach-lpc32xx/clock.c | 8 ++++++++
arch/arm/mach-lpc32xx/include/mach/platform.h | 1 +
2 files changed, 9 insertions(+)
^ permalink raw reply
* [PATCH 5/5] OMAP: remove vram allocator
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
OMAP specific vram allocator is no longer in use, and we can remove all
the vram code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/include/plat/vram.h | 43 ---
drivers/video/omap2/Kconfig | 3 -
drivers/video/omap2/Makefile | 1 -
drivers/video/omap2/dss/Kconfig | 12 -
drivers/video/omap2/vram.c | 514 --------------------------------
5 files changed, 573 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vram.h
delete mode 100644 drivers/video/omap2/vram.c
diff --git a/arch/arm/plat-omap/include/plat/vram.h b/arch/arm/plat-omap/include/plat/vram.h
deleted file mode 100644
index 4d65b7d..0000000
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that 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, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRAM_H__
-#define __OMAP_VRAM_H__
-
-#include <linux/types.h>
-
-extern int omap_vram_add_region(unsigned long paddr, size_t size);
-extern int omap_vram_free(unsigned long paddr, size_t size);
-extern int omap_vram_alloc(size_t size, unsigned long *paddr);
-extern int omap_vram_reserve(unsigned long paddr, size_t size);
-extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
- unsigned long *largest_free_block);
-
-#ifdef CONFIG_OMAP2_VRAM
-extern void omap_vram_set_sdram_vram(u32 size, u32 start);
-
-extern void omap_vram_reserve_sdram_memblock(void);
-#else
-static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
-
-static inline void omap_vram_reserve_sdram_memblock(void) { }
-#endif
-
-#endif
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..346d67d 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -1,6 +1,3 @@
-config OMAP2_VRAM
- bool
-
config OMAP2_VRFB
bool
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 5ddef12..5ea7cb9 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_OMAP2_VRAM) += vram.o
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
obj-$(CONFIG_OMAP2_DSS) += dss/
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 80f5390..058a669 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -6,18 +6,6 @@ menuconfig OMAP2_DSS
if OMAP2_DSS
-config OMAP2_VRAM_SIZE
- int "VRAM size (MB)"
- range 0 32
- default 0
- help
- The amount of SDRAM to reserve at boot time for video RAM use.
- This VRAM will be used by omapfb and other drivers that need
- large continuous RAM area for video use.
-
- You can also set this with "vram=<bytes>" kernel argument, or
- in the board file.
-
config OMAP2_DSS_DEBUG_SUPPORT
bool "Debug support"
default y
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
deleted file mode 100644
index f2b15c4..0000000
--- a/drivers/video/omap2/vram.c
+++ /dev/null
@@ -1,514 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that 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, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-/*#define DEBUG*/
-
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/list.h>
-#include <linux/slab.h>
-#include <linux/seq_file.h>
-#include <linux/memblock.h>
-#include <linux/completion.h>
-#include <linux/debugfs.h>
-#include <linux/jiffies.h>
-#include <linux/module.h>
-
-#include <asm/setup.h>
-
-#include <plat/vram.h>
-
-#ifdef DEBUG
-#define DBG(format, ...) pr_debug("VRAM: " format, ## __VA_ARGS__)
-#else
-#define DBG(format, ...)
-#endif
-
-/* postponed regions are used to temporarily store region information at boot
- * time when we cannot yet allocate the region list */
-#define MAX_POSTPONED_REGIONS 10
-
-static bool vram_initialized;
-static int postponed_cnt;
-static struct {
- unsigned long paddr;
- size_t size;
-} postponed_regions[MAX_POSTPONED_REGIONS];
-
-struct vram_alloc {
- struct list_head list;
- unsigned long paddr;
- unsigned pages;
-};
-
-struct vram_region {
- struct list_head list;
- struct list_head alloc_list;
- unsigned long paddr;
- unsigned pages;
-};
-
-static DEFINE_MUTEX(region_mutex);
-static LIST_HEAD(region_list);
-
-static struct vram_region *omap_vram_create_region(unsigned long paddr,
- unsigned pages)
-{
- struct vram_region *rm;
-
- rm = kzalloc(sizeof(*rm), GFP_KERNEL);
-
- if (rm) {
- INIT_LIST_HEAD(&rm->alloc_list);
- rm->paddr = paddr;
- rm->pages = pages;
- }
-
- return rm;
-}
-
-#if 0
-static void omap_vram_free_region(struct vram_region *vr)
-{
- list_del(&vr->list);
- kfree(vr);
-}
-#endif
-
-static struct vram_alloc *omap_vram_create_allocation(struct vram_region *vr,
- unsigned long paddr, unsigned pages)
-{
- struct vram_alloc *va;
- struct vram_alloc *new;
-
- new = kzalloc(sizeof(*va), GFP_KERNEL);
-
- if (!new)
- return NULL;
-
- new->paddr = paddr;
- new->pages = pages;
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- if (va->paddr > new->paddr)
- break;
- }
-
- list_add_tail(&new->list, &va->list);
-
- return new;
-}
-
-static void omap_vram_free_allocation(struct vram_alloc *va)
-{
- list_del(&va->list);
- kfree(va);
-}
-
-int omap_vram_add_region(unsigned long paddr, size_t size)
-{
- struct vram_region *rm;
- unsigned pages;
-
- if (vram_initialized) {
- DBG("adding region paddr %08lx size %d\n",
- paddr, size);
-
- size &= PAGE_MASK;
- pages = size >> PAGE_SHIFT;
-
- rm = omap_vram_create_region(paddr, pages);
- if (rm == NULL)
- return -ENOMEM;
-
- list_add(&rm->list, ®ion_list);
- } else {
- if (postponed_cnt == MAX_POSTPONED_REGIONS)
- return -ENOMEM;
-
- postponed_regions[postponed_cnt].paddr = paddr;
- postponed_regions[postponed_cnt].size = size;
-
- ++postponed_cnt;
- }
- return 0;
-}
-
-int omap_vram_free(unsigned long paddr, size_t size)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
- unsigned start, end;
-
- DBG("free mem paddr %08lx size %d\n", paddr, size);
-
- size = PAGE_ALIGN(size);
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(rm, ®ion_list, list) {
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- start = alloc->paddr;
- end = alloc->paddr + (alloc->pages >> PAGE_SHIFT);
-
- if (start >= paddr && end < paddr + size)
- goto found;
- }
- }
-
- mutex_unlock(®ion_mutex);
- return -EINVAL;
-
-found:
- omap_vram_free_allocation(alloc);
-
- mutex_unlock(®ion_mutex);
- return 0;
-}
-EXPORT_SYMBOL(omap_vram_free);
-
-static int _omap_vram_reserve(unsigned long paddr, unsigned pages)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
- size_t size;
-
- size = pages << PAGE_SHIFT;
-
- list_for_each_entry(rm, ®ion_list, list) {
- unsigned long start, end;
-
- DBG("checking region %lx %d\n", rm->paddr, rm->pages);
-
- start = rm->paddr;
- end = start + (rm->pages << PAGE_SHIFT) - 1;
- if (start > paddr || end < paddr + size - 1)
- continue;
-
- DBG("block ok, checking allocs\n");
-
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- end = alloc->paddr - 1;
-
- if (start <= paddr && end >= paddr + size - 1)
- goto found;
-
- start = alloc->paddr + (alloc->pages << PAGE_SHIFT);
- }
-
- end = rm->paddr + (rm->pages << PAGE_SHIFT) - 1;
-
- if (!(start <= paddr && end >= paddr + size - 1))
- continue;
-found:
- DBG("found area start %lx, end %lx\n", start, end);
-
- if (omap_vram_create_allocation(rm, paddr, pages) == NULL)
- return -ENOMEM;
-
- return 0;
- }
-
- return -ENOMEM;
-}
-
-int omap_vram_reserve(unsigned long paddr, size_t size)
-{
- unsigned pages;
- int r;
-
- DBG("reserve mem paddr %08lx size %d\n", paddr, size);
-
- size = PAGE_ALIGN(size);
- pages = size >> PAGE_SHIFT;
-
- mutex_lock(®ion_mutex);
-
- r = _omap_vram_reserve(paddr, pages);
-
- mutex_unlock(®ion_mutex);
-
- return r;
-}
-EXPORT_SYMBOL(omap_vram_reserve);
-
-static int _omap_vram_alloc(unsigned pages, unsigned long *paddr)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
-
- list_for_each_entry(rm, ®ion_list, list) {
- unsigned long start, end;
-
- DBG("checking region %lx %d\n", rm->paddr, rm->pages);
-
- start = rm->paddr;
-
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- end = alloc->paddr;
-
- if (end - start >= pages << PAGE_SHIFT)
- goto found;
-
- start = alloc->paddr + (alloc->pages << PAGE_SHIFT);
- }
-
- end = rm->paddr + (rm->pages << PAGE_SHIFT);
-found:
- if (end - start < pages << PAGE_SHIFT)
- continue;
-
- DBG("found %lx, end %lx\n", start, end);
-
- alloc = omap_vram_create_allocation(rm, start, pages);
- if (alloc == NULL)
- return -ENOMEM;
-
- *paddr = start;
-
- return 0;
- }
-
- return -ENOMEM;
-}
-
-int omap_vram_alloc(size_t size, unsigned long *paddr)
-{
- unsigned pages;
- int r;
-
- BUG_ON(!size);
-
- DBG("alloc mem size %d\n", size);
-
- size = PAGE_ALIGN(size);
- pages = size >> PAGE_SHIFT;
-
- mutex_lock(®ion_mutex);
-
- r = _omap_vram_alloc(pages, paddr);
-
- mutex_unlock(®ion_mutex);
-
- return r;
-}
-EXPORT_SYMBOL(omap_vram_alloc);
-
-void omap_vram_get_info(unsigned long *vram,
- unsigned long *free_vram,
- unsigned long *largest_free_block)
-{
- struct vram_region *vr;
- struct vram_alloc *va;
-
- *vram = 0;
- *free_vram = 0;
- *largest_free_block = 0;
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(vr, ®ion_list, list) {
- unsigned free;
- unsigned long pa;
-
- pa = vr->paddr;
- *vram += vr->pages << PAGE_SHIFT;
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- free = va->paddr - pa;
- *free_vram += free;
- if (free > *largest_free_block)
- *largest_free_block = free;
- pa = va->paddr + (va->pages << PAGE_SHIFT);
- }
-
- free = vr->paddr + (vr->pages << PAGE_SHIFT) - pa;
- *free_vram += free;
- if (free > *largest_free_block)
- *largest_free_block = free;
- }
-
- mutex_unlock(®ion_mutex);
-}
-EXPORT_SYMBOL(omap_vram_get_info);
-
-#if defined(CONFIG_DEBUG_FS)
-static int vram_debug_show(struct seq_file *s, void *unused)
-{
- struct vram_region *vr;
- struct vram_alloc *va;
- unsigned size;
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(vr, ®ion_list, list) {
- size = vr->pages << PAGE_SHIFT;
- seq_printf(s, "%08lx-%08lx (%d bytes)\n",
- vr->paddr, vr->paddr + size - 1,
- size);
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- size = va->pages << PAGE_SHIFT;
- seq_printf(s, " %08lx-%08lx (%d bytes)\n",
- va->paddr, va->paddr + size - 1,
- size);
- }
- }
-
- mutex_unlock(®ion_mutex);
-
- return 0;
-}
-
-static int vram_debug_open(struct inode *inode, struct file *file)
-{
- return single_open(file, vram_debug_show, inode->i_private);
-}
-
-static const struct file_operations vram_debug_fops = {
- .open = vram_debug_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static int __init omap_vram_create_debugfs(void)
-{
- struct dentry *d;
-
- d = debugfs_create_file("vram", S_IRUGO, NULL,
- NULL, &vram_debug_fops);
- if (IS_ERR(d))
- return PTR_ERR(d);
-
- return 0;
-}
-#endif
-
-static __init int omap_vram_init(void)
-{
- int i;
-
- vram_initialized = 1;
-
- for (i = 0; i < postponed_cnt; i++)
- omap_vram_add_region(postponed_regions[i].paddr,
- postponed_regions[i].size);
-
-#ifdef CONFIG_DEBUG_FS
- if (omap_vram_create_debugfs())
- pr_err("VRAM: Failed to create debugfs file\n");
-#endif
-
- return 0;
-}
-
-arch_initcall(omap_vram_init);
-
-/* boottime vram alloc stuff */
-
-/* set from board file */
-static u32 omap_vram_sdram_start __initdata;
-static u32 omap_vram_sdram_size __initdata;
-
-/* set from kernel cmdline */
-static u32 omap_vram_def_sdram_size __initdata;
-static u32 omap_vram_def_sdram_start __initdata;
-
-static int __init omap_vram_early_vram(char *p)
-{
- omap_vram_def_sdram_size = memparse(p, &p);
- if (*p == ',')
- omap_vram_def_sdram_start = simple_strtoul(p + 1, &p, 16);
- return 0;
-}
-early_param("vram", omap_vram_early_vram);
-
-/*
- * Called from map_io. We need to call to this early enough so that we
- * can reserve the fixed SDRAM regions before VM could get hold of them.
- */
-void __init omap_vram_reserve_sdram_memblock(void)
-{
- u32 paddr;
- u32 size = 0;
-
- /* cmdline arg overrides the board file definition */
- if (omap_vram_def_sdram_size) {
- size = omap_vram_def_sdram_size;
- paddr = omap_vram_def_sdram_start;
- }
-
- if (!size) {
- size = omap_vram_sdram_size;
- paddr = omap_vram_sdram_start;
- }
-
-#ifdef CONFIG_OMAP2_VRAM_SIZE
- if (!size) {
- size = CONFIG_OMAP2_VRAM_SIZE * 1024 * 1024;
- paddr = 0;
- }
-#endif
-
- if (!size)
- return;
-
- size = ALIGN(size, SZ_2M);
-
- if (paddr) {
- if (paddr & ~PAGE_MASK) {
- pr_err("VRAM start address 0x%08x not page aligned\n",
- paddr);
- return;
- }
-
- if (!memblock_is_region_memory(paddr, size)) {
- pr_err("Illegal SDRAM region 0x%08x..0x%08x for VRAM\n",
- paddr, paddr + size - 1);
- return;
- }
-
- if (memblock_is_region_reserved(paddr, size)) {
- pr_err("FB: failed to reserve VRAM - busy\n");
- return;
- }
-
- if (memblock_reserve(paddr, size) < 0) {
- pr_err("FB: failed to reserve VRAM - no memory\n");
- return;
- }
- } else {
- paddr = memblock_alloc(size, SZ_2M);
- }
-
- memblock_free(paddr, size);
- memblock_remove(paddr, size);
-
- omap_vram_add_region(paddr, size);
-
- pr_info("Reserving %u bytes SDRAM for VRAM\n", size);
-}
-
-void __init omap_vram_set_sdram_vram(u32 size, u32 start)
-{
- omap_vram_sdram_start = start;
- omap_vram_sdram_size = size;
-}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] OMAP: common.c: remove init call to vram
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
OMAP specific vram allocator is no longer used, and we can remove init
call to the vram allocator.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/common.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 111315a..d21ed18 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -17,7 +17,6 @@
#include <linux/dma-mapping.h>
#include <plat/common.h>
-#include <plat/vram.h>
#include <linux/platform_data/dsp-omap.h>
#include <plat/dma.h>
@@ -25,7 +24,6 @@
void __init omap_reserve(void)
{
- omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] OMAP: RX51: remove use of vram
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
As omapfb no longer uses omap specific vram allocator we can remove the
vram pre-allocation from rx51 board file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-rx51-video.c | 14 --------------
arch/arm/mach-omap2/board-rx51.c | 3 ---
2 files changed, 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index c22e111..46f4fc9 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,7 +16,6 @@
#include <linux/mm.h>
#include <asm/mach-types.h>
#include <video/omapdss.h>
-#include <plat/vram.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "board-rx51.h"
@@ -87,17 +86,4 @@ static int __init rx51_video_init(void)
}
subsys_initcall(rx51_video_init);
-
-void __init rx51_video_mem_init(void)
-{
- /*
- * GFX 864x480x32bpp
- * VID1/2 1280x720x32bpp double buffered
- */
- omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
- 2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
-}
-
-#else
-void __init rx51_video_mem_init(void) { }
#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 7bbb05d..6e0de6f 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -34,8 +34,6 @@
#define RX51_GPIO_SLEEP_IND 162
-extern void rx51_video_mem_init(void);
-
static struct gpio_led gpio_leds[] = {
{
.name = "sleep_ind",
@@ -112,7 +110,6 @@ static void __init rx51_init(void)
static void __init rx51_reserve(void)
{
- rx51_video_mem_init();
omap_reserve();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
Use dma_alloc_attrs to allocate memory instead of omap specific vram
allocator. After this we can remove the omap vram allocator.
There are some downsides to this change:
1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.
2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.
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".
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.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/Kconfig | 1 -
drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +++---
drivers/video/omap2/omapfb/omapfb-main.c | 69 +++++++++++++++--------------
drivers/video/omap2/omapfb/omapfb.h | 5 +++
4 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 4ea17dc..4cb12ce 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -2,7 +2,6 @@ menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB && OMAP2_DSS && !DRM_OMAP
- select OMAP2_VRAM
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..574c170 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -31,7 +31,6 @@
#include <video/omapdss.h>
#include <plat/vrfb.h>
-#include <plat/vram.h>
#include "omapfb.h"
@@ -853,14 +852,15 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd, unsigned long arg)
break;
case OMAPFB_GET_VRAM_INFO: {
- unsigned long vram, free, largest;
-
DBG("ioctl GET_VRAM_INFO\n");
- omap_vram_get_info(&vram, &free, &largest);
- p.vram_info.total = vram;
- p.vram_info.free = free;
- p.vram_info.largest_free_block = largest;
+ /*
+ * We don't have the ability to get this vram info anymore.
+ * Fill in something that should keep the applications working.
+ */
+ p.vram_info.total = SZ_1M * 64;
+ p.vram_info.free = SZ_1M * 64;
+ p.vram_info.largest_free_block = SZ_1M * 64;
if (copy_to_user((void __user *)arg, &p.vram_info,
sizeof(p.vram_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 16db158..84c1012 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,6 @@
#include <video/omapdss.h>
#include <plat/cpu.h>
-#include <plat/vram.h>
#include <plat/vrfb.h>
#include "omapfb.h"
@@ -1336,24 +1335,25 @@ static void omapfb_free_fbmem(struct fb_info *fbi)
rg = ofbi->region;
- WARN_ON(atomic_read(&rg->map_count));
-
- if (rg->paddr)
- if (omap_vram_free(rg->paddr, rg->size))
- dev_err(fbdev->dev, "VRAM FREE failed\n");
+ if (rg->token == NULL)
+ return;
- if (rg->vaddr)
- iounmap(rg->vaddr);
+ WARN_ON(atomic_read(&rg->map_count));
if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
/* unmap the 0 angle rotation */
if (rg->vrfb.vaddr[0]) {
iounmap(rg->vrfb.vaddr[0]);
- omap_vrfb_release_ctx(&rg->vrfb);
rg->vrfb.vaddr[0] = NULL;
}
+
+ omap_vrfb_release_ctx(&rg->vrfb);
}
+ dma_free_attrs(fbdev->dev, rg->size, rg->token, rg->dma_handle,
+ &rg->attrs);
+
+ rg->token = NULL;
rg->vaddr = NULL;
rg->paddr = 0;
rg->alloc = 0;
@@ -1388,7 +1388,9 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi->fbdev;
struct omapfb2_mem_region *rg;
- void __iomem *vaddr;
+ void *token;
+ DEFINE_DMA_ATTRS(attrs);
+ dma_addr_t dma_handle;
int r;
rg = ofbi->region;
@@ -1403,42 +1405,43 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
size = PAGE_ALIGN(size);
- if (!paddr) {
- DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
- r = omap_vram_alloc(size, &paddr);
- } else {
- DBG("reserving %lu bytes at %lx for fb %d\n", size, paddr,
- ofbi->id);
- r = omap_vram_reserve(paddr, size);
- }
+ WARN_ONCE(paddr,
+ "reserving memory at predefined address not supported\n");
- if (r) {
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
+ dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+
+ DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+
+ token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
+ GFP_KERNEL, &attrs);
+
+ if (token == NULL) {
dev_err(fbdev->dev, "failed to allocate framebuffer\n");
return -ENOMEM;
}
- if (ofbi->rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
-
- if (!vaddr) {
- dev_err(fbdev->dev, "failed to ioremap framebuffer\n");
- omap_vram_free(paddr, size);
- return -ENOMEM;
- }
+ DBG("allocated VRAM paddr %lx, vaddr %p\n",
+ (unsigned long)dma_handle, token);
- DBG("allocated VRAM paddr %lx, vaddr %p\n", paddr, vaddr);
- } else {
+ if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
r = omap_vrfb_request_ctx(&rg->vrfb);
if (r) {
+ dma_free_attrs(fbdev->dev, size, token, dma_handle,
+ &attrs);
dev_err(fbdev->dev, "vrfb create ctx failed\n");
return r;
}
-
- vaddr = NULL;
}
- rg->paddr = paddr;
- rg->vaddr = vaddr;
+ rg->attrs = attrs;
+ rg->token = token;
+ rg->dma_handle = dma_handle;
+
+ rg->paddr = (unsigned long)dma_handle;
+ rg->vaddr = (void __iomem *)token;
rg->size = size;
rg->alloc = 1;
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 5ced9b3..5f72bf9 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -28,6 +28,8 @@
#endif
#include <linux/rwsem.h>
+#include <linux/dma-attrs.h>
+#include <linux/dma-mapping.h>
#include <video/omapdss.h>
@@ -49,6 +51,9 @@ extern bool omapfb_debug;
struct omapfb2_mem_region {
int id;
+ struct dma_attrs attrs;
+ void *token;
+ dma_addr_t dma_handle;
u32 paddr;
void __iomem *vaddr;
struct vrfb vrfb;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>
Use DMA_BIT_MASK() for fb's coherent_dma_mask for clarity.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/fb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index bcbb9d5..218963b 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -29,6 +29,7 @@
#include <linux/memblock.h>
#include <linux/io.h>
#include <linux/omapfb.h>
+#include <linux/dma-mapping.h>
#include <mach/hardware.h>
#include <asm/mach/map.h>
@@ -45,7 +46,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = &omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &omapfb_config,
},
.num_resources = 0,
@@ -81,7 +82,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = &omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &omapfb_config,
},
.num_resources = 0,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
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:
1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.
2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.
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".
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.
Tomi
Tomi Valkeinen (5):
OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask
OMAPFB: use dma_alloc_attrs to allocate memory
OMAP: RX51: remove use of vram
OMAP: common.c: remove init call to vram
OMAP: remove vram allocator
arch/arm/mach-omap2/board-rx51-video.c | 14 -
arch/arm/mach-omap2/board-rx51.c | 3 -
arch/arm/plat-omap/common.c | 2 -
arch/arm/plat-omap/fb.c | 5 +-
arch/arm/plat-omap/include/plat/vram.h | 43 ---
drivers/video/omap2/Kconfig | 3 -
drivers/video/omap2/Makefile | 1 -
drivers/video/omap2/dss/Kconfig | 12 -
drivers/video/omap2/omapfb/Kconfig | 1 -
drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +-
drivers/video/omap2/omapfb/omapfb-main.c | 69 ++--
drivers/video/omap2/omapfb/omapfb.h | 5 +
drivers/video/omap2/vram.c | 514 -----------------------------
13 files changed, 51 insertions(+), 635 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vram.h
delete mode 100644 drivers/video/omap2/vram.c
--
1.7.10.4
^ permalink raw reply
* [PATCH] ARM: implement optimized percpu variable access
From: Will Deacon @ 2012-11-12 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352604040-10014-1-git-send-email-robherring2@gmail.com>
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.
> 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
* [PATCH v3 0/6] ARM: EXYNOS: Add secure firmware support
From: Tomasz Figa @ 2012-11-12 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112095530.GF28327@n2100.arm.linux.org.uk>
On Monday 12 of November 2012 09:55:30 Russell King - ARM Linux wrote:
> On Mon, Nov 12, 2012 at 04:39:28PM +0900, Kukjin Kim wrote:
> > (+ Russell King)
>
> I think there's still an amount of work to do here; it's not a generic
> interface at the moment because it makes some assumptions about how
> things are done (eg, it assumes that there _will_ be a CPU boot
> register; that is not always true.
>
> Moreover, the 'cpu' arguments given seem to be uncertain whether they're
> logical CPU numbers or physical CPU numbers.
>
> Lastly, where is this interface actually documented? It's just a bunch
> of code _without_ _any_ documentation. That means people will interpret
> it differently, and it'll get used differently from platform to
> platform.
>
> Let's have some documentation on this.
Right, I will include documentation in next version of this patchset.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH v3 6/6] ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
From: Tomasz Figa @ 2012-11-12 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112095231.GE28327@n2100.arm.linux.org.uk>
On Monday 12 of November 2012 09:52:31 Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 05:22:40PM +0200, Tomasz Figa wrote:
> > @@ -47,6 +48,8 @@ static inline void __iomem *cpu_boot_reg(int cpu)
> >
> > {
> >
> > void __iomem *boot_reg;
> >
> > + if (!call_firmware_op(cpu_boot_reg, cpu, &boot_reg))
> > + return boot_reg;
> >
> > boot_reg = cpu_boot_reg_base();
>
> That code makes no sense.
Why?
call_firmware_op returning 0 means a success, so boot_reg is filled with
proper boot register address, which should be used.
Otherwise (call_firmware_op returning an error) the legacy boot register
is used.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH v3 4/6] ARM: EXYNOS: Add support for Exynos secure firmware
From: Tomasz Figa @ 2012-11-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112095114.GD28327@n2100.arm.linux.org.uk>
Hi Russel,
On Monday 12 of November 2012 09:51:14 Russell King - ARM Linux wrote:
> > +
> > +static int exynos_cpu_boot(int cpu)
> > +{
> > + exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> > + return 0;
> > +}
>
> Same for this (though, what _exactly_ is 'cpu', is it the physical CPU
> number or the logical CPU number?)
Yes, it's the physical CPU number.
> > +
> > +static int exynos_cpu_boot_reg(int cpu, void __iomem **ptr)
> > +{
> > + *ptr = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
> > + return 0;
> > +}
>
> This is really bad. What's it trying to do? What is the significance
> of the 'ptr' returned? What if a platform doesn't have a boot register?
It returns a pointer to the area where boot code (secondary startup)
address must be stored.
This callback (just as all the firmware callbacks) is optional, if it is
not appropriate for given platform, it will not use it.
However, now when I think of it, it may be better to just add a callback
like set_boot_addr(cpu, addr), which would set boot address of given CPU
without exporting address of its boot register outside firmware code. Are
you OK with this kind of approach?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* Build failure: OMAP4430 failed due to exynos4 pinctrl
From: Kukjin Kim @ 2012-11-12 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112093329.GC28327@n2100.arm.linux.org.uk>
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.
Thanks for pointing out :-)
Please test again with following?...
(+ Linus Walleij)
8<-------------------------------------------------------------
From: Kukjin Kim <kgene.kim@samsung.com>
Subject: [PATCH] pinctrl/samsung: adds dependency for pinctrl-samsung/exynos
The pinctrl-exynos should be built with ARCH_EXYNOS and pinctrl-samsung
should be built with pinctrl-exynos. If not, following error can be
happened.
drivers/built-in.o:(.rodata+0x1a60): undefined reference to
'exynos4210_pin_ctrl'
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
drivers/pinctrl/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
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
config PINCTRL_MVEBU
--
1.7.4.1
8<-------------------------------------------------------------
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply related
* [PATCH 2/2] regulator: gpio-regulator: fix can't find regulator node in dt
From: Frank Li @ 2012-11-12 9:59 UTC (permalink / raw)
To: linux-arm-kernel
Need initilize of_node in regulator config when register regulator,
otherwise regulator driver think it is no-dt device.
in regulator_dev_lookup
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
node == r->dev.of_node)
return r
r->dev.of_noe will be zero if miss config in cfg.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/regulator/gpio-regulator.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
index e467d0a..faa2f71 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -303,6 +303,7 @@ static int __devinit gpio_regulator_probe(struct platform_device *pdev)
cfg.dev = &pdev->dev;
cfg.init_data = config->init_data;
cfg.driver_data = drvdata;
+ cfg.of_node = np;
if (config->enable_gpio >= 0)
cfg.ena_gpio = config->enable_gpio;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] regulator: gpio-regulator: doc: Fix wrong key gpio-enable
From: Frank Li @ 2012-11-12 9:58 UTC (permalink / raw)
To: linux-arm-kernel
Wrong description in binding document.
Doc use "gpio-enable", but code use "enable-gpio"
In drivers/regulator/gpio-regulator.c
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
.../bindings/regulator/gpio-regulator.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 3703be2..f71f808 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Must be "regulator-gpio".
Optional properties:
-- gpio-enable : GPIO to use to enable/disable the regulator.
+- enable-gpio : GPIO to use to enable/disable the regulator.
- gpios : GPIO group used to control voltage.
- states : Selection of available voltages and GPIO configs.
- startup-delay-us : Startup time in microseconds.
@@ -23,7 +23,7 @@ Example:
regulator-max-microvolt = <2600000>;
regulator-boot-on;
- gpio-enable = <&gpio0 23 0x4>;
+ enable-gpio = <&gpio0 23 0x4>;
gpios = <&gpio0 24 0x4
&gpio0 25 0x4>;
states = <1800000 0x3
--
1.7.1
^ permalink raw reply related
* [PATCH v3 0/6] ARM: EXYNOS: Add secure firmware support
From: Russell King - ARM Linux @ 2012-11-12 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <006501cdc0a8$d880c990$89825cb0$%kim@samsung.com>
On Mon, Nov 12, 2012 at 04:39:28PM +0900, Kukjin Kim wrote:
> (+ Russell King)
I think there's still an amount of work to do here; it's not a generic
interface at the moment because it makes some assumptions about how
things are done (eg, it assumes that there _will_ be a CPU boot register;
that is not always true.
Moreover, the 'cpu' arguments given seem to be uncertain whether they're
logical CPU numbers or physical CPU numbers.
Lastly, where is this interface actually documented? It's just a bunch
of code _without_ _any_ documentation. That means people will interpret
it differently, and it'll get used differently from platform to platform.
Let's have some documentation on this.
^ permalink raw reply
* [PATCH v3 6/6] ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
From: Russell King - ARM Linux @ 2012-11-12 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351178560-19188-7-git-send-email-t.figa@samsung.com>
On Thu, Oct 25, 2012 at 05:22:40PM +0200, Tomasz Figa wrote:
> @@ -47,6 +48,8 @@ static inline void __iomem *cpu_boot_reg(int cpu)
> {
> void __iomem *boot_reg;
>
> + if (!call_firmware_op(cpu_boot_reg, cpu, &boot_reg))
> + return boot_reg;
> boot_reg = cpu_boot_reg_base();
That code makes no sense.
^ permalink raw reply
* [PATCH v3 4/6] ARM: EXYNOS: Add support for Exynos secure firmware
From: Russell King - ARM Linux @ 2012-11-12 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351178560-19188-5-git-send-email-t.figa@samsung.com>
On Thu, Oct 25, 2012 at 05:22:38PM +0200, Tomasz Figa wrote:
> +static int exynos_do_idle(void)
> +{
> + exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
> + return 0;
> +}
This looks fine as an API - it has a defined purpose.
> +
> +static int exynos_cpu_boot(int cpu)
> +{
> + exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> + return 0;
> +}
Same for this (though, what _exactly_ is 'cpu', is it the physical CPU
number or the logical CPU number?)
> +
> +static int exynos_cpu_boot_reg(int cpu, void __iomem **ptr)
> +{
> + *ptr = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
> + return 0;
> +}
This is really bad. What's it trying to do? What is the significance
of the 'ptr' returned? What if a platform doesn't have a boot register?
^ permalink raw reply
* [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2012-11-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121111172243.GB821@lunn.ch>
On 11.11.2012 18:22, Andrew Lunn wrote:
> On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
>> the flags provided by the caller. This causes excessive pruning of
>> emergency memory pools without any good reason. This patch changes
the code
>> to correctly use gfp flags provided by the dmapool caller. This should
>> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
>> allocations can be served only from the special, very limited memory
pool.
>>
>> Reported-by: Soren Moch <smoch@web.de>
Please use
Reported-by: Soeren Moch <smoch@web.de>
>> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
>
> I tested this on a Kirkwood QNAP after removing the call to
> init_dma_coherent_pool_size().
>
> Andrew
Tested-by: Soeren Moch <smoch@web.de>
Now I had a chance to test this patch on my Kirkwood guruplug
system with linux-3.6.6 . It is running much better now, but with the
original 256K coherent pool size I still see errors after several hours
of runtime:
Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool is
too small!
Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool=
kernel parameter!
Soeren
>> ---
>> mm/dmapool.c | 27 +++++++--------------------
>> 1 file changed, 7 insertions(+), 20 deletions(-)
>>
>> diff --git a/mm/dmapool.c b/mm/dmapool.c
>> index c5ab33b..86de9b2 100644
>> --- a/mm/dmapool.c
>> +++ b/mm/dmapool.c
>> @@ -62,8 +62,6 @@ struct dma_page { /* cacheable header for
'allocation' bytes */
>> unsigned int offset;
>> };
>>
>> -#define POOL_TIMEOUT_JIFFIES ((100 /* msec */ * HZ) / 1000)
>> -
>> static DEFINE_MUTEX(pools_lock);
>>
>> static ssize_t
>> @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct
dma_pool *pool, gfp_t mem_flags)
>> memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
>> #endif
>> pool_initialise_page(pool, page);
>> - list_add(&page->page_list, &pool->page_list);
>> page->in_use = 0;
>> page->offset = 0;
>> } else {
>> @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool,
gfp_t mem_flags,
>> might_sleep_if(mem_flags & __GFP_WAIT);
>>
>> spin_lock_irqsave(&pool->lock, flags);
>> - restart:
>> list_for_each_entry(page, &pool->page_list, page_list) {
>> if (page->offset < pool->allocation)
>> goto ready;
>> }
>> - page = pool_alloc_page(pool, GFP_ATOMIC);
>> - if (!page) {
>> - if (mem_flags & __GFP_WAIT) {
>> - DECLARE_WAITQUEUE(wait, current);
>>
>> - __set_current_state(TASK_UNINTERRUPTIBLE);
>> - __add_wait_queue(&pool->waitq, &wait);
>> - spin_unlock_irqrestore(&pool->lock, flags);
>> + /* pool_alloc_page() might sleep, so temporarily drop
&pool->lock */
>> + spin_unlock_irqrestore(&pool->lock, flags);
>>
>> - schedule_timeout(POOL_TIMEOUT_JIFFIES);
>> + page = pool_alloc_page(pool, mem_flags);
>> + if (!page)
>> + return NULL;
>>
>> - spin_lock_irqsave(&pool->lock, flags);
>> - __remove_wait_queue(&pool->waitq, &wait);
>> - goto restart;
>> - }
>> - retval = NULL;
>> - goto done;
>> - }
>> + spin_lock_irqsave(&pool->lock, flags);
>>
>> + list_add(&page->page_list, &pool->page_list);
>> ready:
>> page->in_use++;
>> offset = page->offset;
>> @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool,
gfp_t mem_flags,
>> #ifdef DMAPOOL_DEBUG
>> memset(retval, POOL_POISON_ALLOCATED, pool->size);
>> #endif
>> - done:
>> spin_unlock_irqrestore(&pool->lock, flags);
>> return retval;
>> }
>> --
>> 1.7.9.5
>>
^ permalink raw reply
* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: AnilKumar, Chimata @ 2012-11-12 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC04226@DBDE01.ent.ti.com>
On Tue, Nov 06, 2012 at 11:15:34, Bedia, Vaibhav wrote:
> On Mon, Nov 05, 2012 at 15:12:27, AnilKumar, Chimata wrote:
> [...]
> >
> > +#define SHUTDOWN_TIME_SEC 2
> > +#define SECS_IN_MIN 60
> > +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> > +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> > +
> > static void __iomem *rtc_base;
> >
> [...]
> > +
> > + /* Wait few seconds instead of rollover */
> > + do {
> > + omap_rtc_read_time(NULL, &tm);
> > + if (WAIT_AFTER <= tm.tm_sec)
> > + mdelay(WAIT_TIME_MS);
> > + } while (WAIT_AFTER <= tm.tm_sec);
>
> This hardcoded wait for rollover doesn't look good. I see some
> helper functions in rtc-lib.c which probably could be used for
> converting the current time to elapsed seconds, add the delay and
> then convert it back to the time to be programmed in RTC without
> worrying about rollover. Why not use that?
I am not aware of those APIs, can you point some?
>
> > +
> > + /* Add shutdown time to the current value */
> > + tm.tm_sec += SHUTDOWN_TIME_SEC;
> > +
> > + if (tm2bcd(&tm) < 0)
> > + return;
> > +
> > + pr_info("System will go to power_off state in approx. %d secs\n",
> > + SHUTDOWN_TIME_SEC);
> > +
> > + /* Set the ALARM2 time */
> > + rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
> > + rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
> > + rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
> > + rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
> > + rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
> > + rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
> > +
> > + /* Enable alarm2 interrupt */
> > + val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
> > + writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
> > + rtc_base + OMAP_RTC_INTERRUPTS_REG);
> > +
>
> These registers are not present in older versions of the IP so how
> does that get handled?
I think, earlier this feature is not supported/not used.
>
> You also need to describe the connection between the ALARM2 and the
> power off logic in detail.
Sure, I will add.
Thanks
AnilKumar
^ 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