* [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
From: Kukjin Kim @ 2011-09-20 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920234502.GU7781@ponder.secretlab.ca>
Grant Likely wrote:
>
> On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote:
> > Since gpio-samsung.c can replace old Samsung GPIO drivers,
> > this patch removes them.
> >
> > Cc: Ben Dooks <ben-linux@fluff.org>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>
> Removing this code before adding the new code means it is not
> bisectable. I'll squash the two patches together when I pick them
> up..
>
OK, no problem and would be better to me if you could create some topic
branch for this series. I'd like to merge it to avoid conflicts with Samsung
stuff.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> > ---
> > arch/arm/plat-samsung/Makefile | 2 -
> > arch/arm/plat-samsung/gpio-config.c | 431
-----------------------------
> > arch/arm/plat-samsung/gpio.c | 167 ------------
> > drivers/gpio/Kconfig | 28 --
> > drivers/gpio/Makefile | 9 -
> > drivers/gpio/gpio-exynos4.c | 385 --------------------------
> > drivers/gpio/gpio-plat-samsung.c | 205 --------------
> > drivers/gpio/gpio-s3c24xx.c | 283 -------------------
> > drivers/gpio/gpio-s3c64xx.c | 289 --------------------
> > drivers/gpio/gpio-s5p64x0.c | 510
-----------------------------------
> > drivers/gpio/gpio-s5pc100.c | 354 ------------------------
> > drivers/gpio/gpio-s5pv210.c | 287 --------------------
> > 12 files changed, 0 insertions(+), 2950 deletions(-)
> > delete mode 100644 arch/arm/plat-samsung/gpio-config.c
> > delete mode 100644 arch/arm/plat-samsung/gpio.c
> > delete mode 100644 drivers/gpio/gpio-exynos4.c
> > delete mode 100644 drivers/gpio/gpio-plat-samsung.c
> > delete mode 100644 drivers/gpio/gpio-s3c24xx.c
> > delete mode 100644 drivers/gpio/gpio-s3c64xx.c
> > delete mode 100644 drivers/gpio/gpio-s5p64x0.c
> > delete mode 100644 drivers/gpio/gpio-s5pc100.c
> > delete mode 100644 drivers/gpio/gpio-s5pv210.c
> >
^ permalink raw reply
* [PATCH 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
From: Kukjin Kim @ 2011-09-20 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920234941.GV7781@ponder.secretlab.ca>
Grant Likely wrote:
>
> On Tue, Aug 30, 2011 at 09:27:27PM +0900, Kukjin Kim wrote:
> > This patch adds support for Samsung GPIOs with one gpio driver.
> > Actually there are drivers/gpio-s3c24xx.c, gpio-s3c64xx.c,
> > gpio-s5p64x0.c, gpio-s5pc100.c, gpio-s5pv210.c, gpio-exynos4.c,
> > gpio-plat-samsung.c, plat-samsung/gpio-config.c and gpio.c to
> > support each Samsung SoCs before.
> > Basically, the gpio-samsung.c has been made by their merging
> > and removing duplicated definitions.
> >
> > Note: gpio-samsung.c includes some SoC dependent codes and it
> > will be replaced next time.
> >
> > Cc: Ben Dooks <ben-linux@fluff.org>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > ---
> > drivers/gpio/Makefile | 1 +
> > drivers/gpio/gpio-samsung.c | 2686
> +++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 2687 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpio/gpio-samsung.c
>
> It's a big driver file, but I'll go ahead and pick this up without too
> much review because at least it is all in the same place now. I'll
> expect further cleanup in future patches.
>
Yes, as you said, I agree this is needed some cleanup. I and my team will do
it next time.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/
From: Kukjin Kim @ 2011-09-20 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920235208.GW7781@ponder.secretlab.ca>
Grant Likely wrote:
>
> On Mon, Sep 19, 2011 at 08:13:12PM +0900, Kukjin Kim wrote:
> > Kukjin Kim wrote:
> > >
> >
> > (snip)...
> >
> > Hi Grant,
> >
> > I didn't get any comments on this series, gpio-samsung patches for
> > consolidation of Samsung gpiolib. Please let me know whether this is ok
to
> > you or not. And I think, if you're ok, this should be sent to upstream
via
> > both gpio tree and arm(samsung) tree to avoid conflicts...
> >
> > As a note, following is its status...
> >
> > Kukjin Kim (9):
> > ARM: SAMSUNG: Move map header file into plat-samsung
> > gpio/s3c24xx: move gpio driver into drivers/gpio/
> > gpio/s3c64xx: move gpio driver into drivers/gpio/
> > gpio/s5p64x0: move gpio driver into drivers/gpio/
> > gpio/samsung: Remove useless old Samsung related GPIO drivers
> > gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
> > ARM: SAMSUNG: Update the name of regarding Samsung GPIO
> > ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs
> > Merge branch 'next/topic-plat-samsung-1' into
next/topic-gpio-samsung
>
> Actually, even though I said I would pick it up, you've already got it
> in a tree, so you can go ahead and merge it with my ack. I don't see
> any major risk of conflicts for the next merge window, so there is no
> need to merge it in the gpio tree also.
>
Hi Grant,
OK, I will do it after adding your ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> >
> > arch/arm/Kconfig | 3 -
> > arch/arm/mach-exynos4/include/mach/pm-core.h | 2 +-
> > arch/arm/mach-s3c2410/Kconfig | 7 -
> > arch/arm/mach-s3c2410/Makefile | 1 -
> > arch/arm/mach-s3c2410/include/mach/gpio-fns.h | 99 +-
> > arch/arm/mach-s3c2410/include/mach/gpio-track.h | 6 +-
> > arch/arm/mach-s3c2410/include/mach/map.h | 52 +-
> > arch/arm/mach-s3c2410/include/mach/pm-core.h | 2 +-
> > arch/arm/mach-s3c2410/s3c2410.c | 4 +-
> > arch/arm/mach-s3c2412/Kconfig | 1 -
> > arch/arm/mach-s3c2412/Makefile | 1 -
> > arch/arm/mach-s3c2412/gpio.c | 2 +-
> > arch/arm/mach-s3c2416/Kconfig | 1 -
> > arch/arm/mach-s3c2416/s3c2416.c | 4 +-
> > arch/arm/mach-s3c2440/Kconfig | 4 -
> > arch/arm/mach-s3c2440/s3c2440.c | 4 +-
> > arch/arm/mach-s3c2440/s3c2442.c | 4 +-
> > arch/arm/mach-s3c2443/Kconfig | 1 -
> > arch/arm/mach-s3c2443/s3c2443.c | 4 +-
> > arch/arm/mach-s3c64xx/Makefile | 1 -
> > arch/arm/mach-s3c64xx/gpiolib.c | 290 ---
> > arch/arm/mach-s3c64xx/include/mach/map.h | 9 +-
> > arch/arm/mach-s3c64xx/include/mach/pm-core.h | 2 +-
> > arch/arm/mach-s5p64x0/Makefile | 2 +-
> > arch/arm/mach-s5p64x0/gpiolib.c | 511 ----
> > arch/arm/mach-s5pv210/include/mach/pm-core.h | 2 +-
> > arch/arm/plat-s3c24xx/Kconfig | 1 -
> > arch/arm/plat-s3c24xx/Makefile | 2 -
> > arch/arm/plat-s3c24xx/gpio.c | 96 -
> > arch/arm/plat-s3c24xx/gpiolib.c | 229 --
> > arch/arm/plat-s3c24xx/include/plat/map.h | 100 -
> > arch/arm/plat-s5p/Kconfig | 3 -
> > arch/arm/plat-s5p/irq-gpioint.c | 10 +-
> > arch/arm/plat-samsung/Kconfig | 27 -
> > arch/arm/plat-samsung/Makefile | 2 -
> > arch/arm/plat-samsung/gpio-config.c | 431 ----
> > arch/arm/plat-samsung/gpio.c | 167 --
> > .../plat-samsung/include/plat/gpio-cfg-helpers.h | 172 +-
> > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 34 +-
> > arch/arm/plat-samsung/include/plat/gpio-core.h | 97 +-
> > arch/arm/plat-samsung/include/plat/gpio-fns.h | 98 +
> > arch/arm/plat-samsung/include/plat/map-s3c.h | 84 +
> > .../include/plat/map-s5p.h | 6 +-
> > arch/arm/plat-samsung/include/plat/pm.h | 10 +-
> > arch/arm/plat-samsung/pm-gpio.c | 72 +-
> > arch/arm/plat-samsung/pm.c | 6 +-
> > drivers/gpio/Kconfig | 16 -
> > drivers/gpio/Makefile | 7 +-
> > drivers/gpio/gpio-exynos4.c | 385 ---
> > drivers/gpio/gpio-plat-samsung.c | 205 --
> > drivers/gpio/gpio-s5pc100.c | 354 ---
> > drivers/gpio/gpio-s5pv210.c | 287 ---
> > drivers/gpio/gpio-samsung.c | 2686
> > ++++++++++++++++++++
> > 53 files changed, 3072 insertions(+), 3534 deletions(-)
> > delete mode 100644 arch/arm/mach-s3c64xx/gpiolib.c
> > delete mode 100644 arch/arm/mach-s5p64x0/gpiolib.c
> > delete mode 100644 arch/arm/plat-s3c24xx/gpio.c
> > delete mode 100644 arch/arm/plat-s3c24xx/gpiolib.c
> > delete mode 100644 arch/arm/plat-s3c24xx/include/plat/map.h
> > delete mode 100644 arch/arm/plat-samsung/gpio-config.c
> > delete mode 100644 arch/arm/plat-samsung/gpio.c
> > create mode 100644 arch/arm/plat-samsung/include/plat/gpio-fns.h
> > create mode 100644 arch/arm/plat-samsung/include/plat/map-s3c.h
> > rename arch/arm/{plat-s5p => plat-samsung}/include/plat/map-s5p.h (94%)
> > delete mode 100644 drivers/gpio/gpio-exynos4.c
> > delete mode 100644 drivers/gpio/gpio-plat-samsung.c
> > delete mode 100644 drivers/gpio/gpio-s5pc100.c
> > delete mode 100644 drivers/gpio/gpio-s5pv210.c
> > create mode 100644 drivers/gpio/gpio-samsung.c
> >
> > Thanks.
> >
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
^ permalink raw reply
* [PATCH 0/19] removal of mach/vmalloc.h and generic optimizations
From: Nicolas Pitre @ 2011-09-21 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1933895.GJBlYra9yP@wuerfel>
On Sun, 18 Sep 2011, Arnd Bergmann wrote:
> On Saturday 17 September 2011 22:46:33 Nicolas Pitre wrote:
> > On Sat, 17 Sep 2011, Arnd Bergmann wrote:
> >
> > > On Friday 16 September 2011 03:07:11 Nicolas Pitre wrote:
> > > > This patch series removes all instances of mach/vmalloc.h in order to
> > > > have a more unified memory map across all ARM architectures. To do so,
> > > > the static mappings are moved inside the vmalloc area. And finally this
> > > > allows for a generic optimization to ioremap where static mappings are
> > > > reused whenever possible, using common code instead of having this
> > > > duplicated in a couple places.
> > > >
> > > > This also provides a net reduction of more than 1200 lines of code.
>
> >
> > > Doing some randconfig tests, I noticed that your series is currently broken
> > > on shmobile, which triggers a
> > >
> > > BUILD_BUG_ON(VMALLOC_END > CONSISTENT_BASE);
> > >
> > > in mem_init(), because the platform has a CONSISTENT_DMA_SIZE of 158MB.
> > > All other platforms have a CONSISTENT_DMA_SIZE of at most 14MB, which
> > > works correctly.
> >
> > Any idea why shmobile requires such an amount of consistent memory?
>
> No, I couldn't find anything in the code or the changelog why this was
> done. Magnus changed it in this commit:
>
> commit 28f0721a79046056ced3b9bd79c319c5c417ec30
> Author: Magnus Damm <damm@opensource.se>
> Date: Wed Apr 28 08:25:30 2010 +0000
>
> ARM: mach-shmobile: Set CONSISTENT_DMA_SIZE to 158 MB
>
> This patch sets CONSISTENT_DMA_SIZE to 158 MB
> for all SH-Mobile ARM processors.
>
> The DMA area is mapped at 0xf6000000 - 0xffdfffff,
> on top of the 256 MB I/O window at 0xe6000000.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>
> Maybe he can give a better explanation and can say whether it's
> actually required. The patch series introducing it contained
> the introduction of the shdma dmaengine driver and some changes
> to video drivers, but I could not tell how they are related
> to this change.
I found that drivers/video/sh_mobile_lcdcfb.c appears to be a heavy user
of dma_alloc_coherent():
buf = dma_alloc_coherent(&pdev->dev, info->fix.smem_len,
&ch->dma_handle, GFP_KERNEL);
...
info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
...
max_size = MAX_XRES * MAX_YRES;
...
#define MAX_XRES 1920
#define MAX_YRES 1080
... and a switch statement on bpp shows it can be up to 32.
So for this particular hypothetical case: 1920 * 1080 * 2 * 32 / 8 = 16MB
We are far from the 158MB figure. Furthermore, the highest allowed
amount is 14MB according to the available documentation, and none of the
other ARM targets use more than that either.
Magnus and/or Paul: please could you explain where this 158MB comes from?
Nicolas
^ permalink raw reply
* [PATCHv2 1/2] ARM: debug: Add UART1 config choices
From: Stephen Boyd @ 2011-09-21 1:23 UTC (permalink / raw)
To: linux-arm-kernel
ARM patch 7072/1 (debug: use kconfig choice for selecting
DEBUG_LL UART) didn't notice that the Kconfigs relied on being
unselected to configure a different serial port. Since there is
no NONE option in a choice menu, explicitly add the other option
so that both serial ports can be selected.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
I plan to put these in the patch tracker if there are no further
comments.
arch/arm/Kconfig.debug | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 60d1846..6dbcb00 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -81,14 +81,27 @@ choice
prompt "Kernel low-level debugging port"
depends on DEBUG_LL
+
+ config DEBUG_FOOTBRIDGE_COM1
+ bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
+ depends on FOOTBRIDGE
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the 8250 at PCI COM1.
+
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the serial port in the DC21285 (Footbridge).
- Saying N will cause the debug messages to appear on the first
- 16550 serial port.
+
+ config DEBUG_CLPS711X_UART1
+ bool "Kernel low-level debugging messages via UART1"
+ depends on ARCH_CLPS711X
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the first serial port on these devices.
config DEBUG_CLPS711X_UART2
bool "Kernel low-level debugging messages via UART2"
@@ -96,8 +109,6 @@ choice
help
Say Y here if you want the debug print routines to direct
their output to the second serial port on these devices.
- Saying N will cause the debug messages to appear on the first
- serial port.
endchoice
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Stephen Boyd @ 2011-09-21 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316568208-4518-1-git-send-email-sboyd@codeaurora.org>
DEBUG_ICEDCC support is just another DEBUG_LL choice and
selecting it along with other DEBUG_LL options doesn't make
much sense. Put it into the DEBUG_LL choice to avoid confusion.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/Kconfig.debug | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6dbcb00..31896f4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -81,6 +81,17 @@ choice
prompt "Kernel low-level debugging port"
depends on DEBUG_LL
+ config DEBUG_ICEDCC
+ bool "Kernel low-level debugging via EmbeddedICE DCC channel"
+ depends on DEBUG_LL
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the EmbeddedICE macrocell's DCC channel using
+ co-processor 14. This is known to work on the ARM9 style ICE
+ channel and on the XScale with the PEEDI.
+
+ It does include a timeout to ensure that the system does not
+ totally freeze when there is nothing connected to read.
config DEBUG_FOOTBRIDGE_COM1
bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
@@ -120,18 +131,6 @@ config EARLY_PRINTK
kernel low-level debugging functions. Add earlyprintk to your
kernel parameters to enable this console.
-config DEBUG_ICEDCC
- bool "Kernel low-level debugging via EmbeddedICE DCC channel"
- depends on DEBUG_LL
- help
- Say Y here if you want the debug print routines to direct their
- output to the EmbeddedICE macrocell's DCC channel using
- co-processor 14. This is known to work on the ARM9 style ICE
- channel and on the XScale with the PEEDI.
-
- It does include a timeout to ensure that the system does not
- totally freeze when there is nothing connected to read.
-
config OC_ETM
bool "On-chip ETM and ETB"
select ARM_AMBA
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [GIT PULL] Samsung boards for v3.2
From: Kukjin Kim @ 2011-09-21 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202230.09426.arnd@arndb.de>
Arnd Bergmann wrote:
>
> On Monday 19 September 2011, Kukjin Kim wrote:
> > Please pull from:
> > git://github.com/kgene/linux-samsung.git next-samsung-board
> >
> > As you see, the next-samsung-board includes new board, SMDK4212. Of
course
> > to support new SoC, EXYNOS4212 is required for it but current
> > arch/arm/mach-exynos4 (ARCH_EXYNOS4) can support it so I merged it into
> > next-samsung-board not next-samsung-soc and to support handling of cupid
> and
> > rev. in Samsung stuff for it. As I remember, you said -soc branch of
arm-soc
> > is for adding new architecture like arch/arm/mach-xxxx.
> >
> > As a note, this includes samsung-fixes-2 which has been already pulled
in
> > your tree too.
>
> Looks good. I had to apply the same atag_offset change to the new board
> file that was done in all other branches as well.
>
Yes, as a note, so I have applied following for it in my -next.
It's ok to me either your handling or following.
commit 61338e607202a7cf9d5f63e69eb538782643ff90
Author: Tushar Behera <tushar.behera@linaro.org>
Date: Mon Sep 19 20:09:01 2011 +0900
ARM: EXYNOS4: convert boot_params to atag_offset
Based on "ARM: introduce atag_offset to replace boot_params"
by Nicolas Pitre (2bb9839e312ed55a6d5824ffa6077ce3d7d63b1e).
Since boot_params variable is deleted from machine_desc, the variable
is modified in the newer board files.
CC: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index c8121fc..421294b 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -209,7 +209,7 @@ static void __init origen_machine_init(void)
MACHINE_START(ORIGEN, "ORIGEN")
/* Maintainer: JeongHyeon Kim <jhkim@insignal.co.kr> */
- .boot_params = S5P_PA_SDRAM + 0x100,
+ .atag_offset = 0x100,
.init_irq = exynos4_init_irq,
.map_io = origen_map_io,
.init_machine = origen_machine_init,
diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c
b/arch/arm/mach-exynos4/mach-smdk4212.c
index 3479a93..8c41ae1 100644
--- a/arch/arm/mach-exynos4/mach-smdk4212.c
+++ b/arch/arm/mach-exynos4/mach-smdk4212.c
@@ -284,7 +284,7 @@ static void __init smdk4212_machine_init(void)
MACHINE_START(SMDK4212, "SMDK4212")
/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
- .boot_params = S5P_PA_SDRAM + 0x100,
+ .atag_offset = 0x100,
.init_irq = exynos4_init_irq,
.map_io = smdk4212_map_io,
.init_machine = smdk4212_machine_init,
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 57cf632..7ce4d8b 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -344,7 +344,7 @@ MACHINE_END
MACHINE_START(SMDKC210, "SMDKC210")
/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
- .boot_params = S5P_PA_SDRAM + 0x100,
+ .atag_offset = 0x100,
.init_irq = exynos4_init_irq,
.map_io = smdkv310_map_io,
.init_machine = smdkv310_machine_init,
> Pulled into next/board. Thanks!
>
Thanks :)
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply related
* [GIT PULL] Samsung cleanup for v3.2
From: Kukjin Kim @ 2011-09-21 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202222.41747.arnd@arndb.de>
Arnd Bergmann wrote:
>
> On Monday 19 September 2011, Kukjin Kim wrote:
> > This is Samsung cleanup for v3.2.
> >
> > Please pull from:
> > git://github.com/kgene/linux-samsung.git next-samsung-cleanup
>
> Pulled into arm-soc/next/cleanup.
>
Thanks :)
> > If any problems, please let me know.
>
> One tiny conflict with Nico's cross-platform series:
>
Yes, I know. I have received same information from Stephen when he merged.
> +
> + MACHINE_START(SMDKC210, "SMDKC210")
> + /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
> - .boot_params = S5P_PA_SDRAM + 0x100,
> ++ .atag_offset = 0x100,
> + .init_irq = exynos4_init_irq,
> + .map_io = smdkv310_map_io,
> + .init_machine = smdkv310_machine_init,
> + .timer = &exynos4_timer,
> + MACHINE_END
>
> I'll handle this in the upstream submission.
>
OK, thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-21 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920230800.GS7781@ponder.secretlab.ca>
On 09/20/2011 06:08 PM, Grant Likely wrote:
> On Tue, Sep 20, 2011 at 03:24:04PM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds ARM gic interrupt controller initialization using device tree
>> data.
>>
>> The initialization function is intended to be called by of_irq_init
>> function like this:
>>
>> const static struct of_device_id irq_match[] = {
>> { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
>> {}
>> };
>>
>> static void __init init_irqs(void)
>> {
>> of_irq_init(irq_match);
>> }
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++++++++++
>> arch/arm/common/gic.c | 89 +++++++++++++++++++++++-
>> arch/arm/include/asm/hardware/gic.h | 12 ++++
>> 3 files changed, 152 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> new file mode 100644
>> index 0000000..52916b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -0,0 +1,55 @@
>> +* ARM Generic Interrupt Controller
>> +
>> +ARM SMP cores are often associated with a GIC, providing per processor
>> +interrupts (PPI), shared processor interrupts (SPI) and software
>> +generated interrupts (SGI).
>> +
>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>> +have PPIs or SGIs.
>> +
>> +Main node required properties:
>> +
>> +- compatible : should be one of:
>> + "arm,cortex-a9-gic"
>> + "arm,arm11mp-gic"
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> + interrupt source. The type shall be a <u32> and the value shall be 3.
>> +
>> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> + interrupts.
>> +
>> + The 2nd cell contains the interrupt number for the interrupt type.
>> + SPI interrupts are in the range [0-987]. PPI interrupts are in the
>> + range [0-15].
>> +
>> + The 3rd cell is the flags, encoded as follows:
>> + bits[3:0] trigger type and level flags.
>> + 1 = low-to-high edge triggered
>> + 2 = high-to-low edge triggered
>> + 4 = active high level-sensitive
>> + 8 = active low level-sensitive
>> + bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
>> + the 8 possible cpus attached to the GIC. A bit set to '1' indicated
>> + the interrupt is wired to that CPU. Only valid for PPI interrupts.
>> +
>> +- reg : Specifies base physical address(s) and size of the GIC registers. The
>> + first region is the GIC distributor register base and size. The 2nd region is
>> + the GIC cpu interface register base and size.
>> +
>> +Optional
>> +- interrupts : Interrupt source of the parent interrupt controller. Only
>> + present on secondary GICs.
>> +
>> +Example:
>> +
>> + intc: interrupt-controller at fff11000 {
>> + compatible = "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + #address-cells = <1>;
>> + interrupt-controller;
>> + reg = <0xfff11000 0x1000>,
>> + <0xfff10100 0x100>;
>> + };
>> +
>
> Ack on the binding.
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index 666b278..84e69a4 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>> @@ -28,6 +28,10 @@
>> #include <linux/smp.h>
>> #include <linux/cpumask.h>
>> #include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/irqdomain.h>
>>
>> #include <asm/irq.h>
>> #include <asm/mach/irq.h>
>> @@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
>> irq_set_chained_handler(irq, gic_handle_cascade_irq);
>> }
>>
>> +static int gic_irq_count(void __iomem *dist_base)
>> +{
>> + int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
>> + gic_irqs = (gic_irqs + 1) * 32;
>> + if (gic_irqs > 1020)
>> + gic_irqs = 1020;
>> + return gic_irqs;
>> +}
>> +
>> static void __init gic_dist_init(struct gic_chip_data *gic,
>> unsigned int irq_start)
>> {
>> @@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
>> * Find out how many interrupts are supported.
>> * The GIC only supports up to 1020 interrupt sources.
>> */
>> - gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
>> - gic_irqs = (gic_irqs + 1) * 32;
>> - if (gic_irqs > 1020)
>> - gic_irqs = 1020;
>> + gic_irqs = gic_irq_count(base);
>>
>> /*
>> * Set all global interrupts to be level triggered, active low.
>> @@ -405,3 +415,74 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>> writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
>> }
>> #endif
>> +
>> +#ifdef CONFIG_OF
>> +static int gic_cnt __initdata = 0;
>> +
>> +int gic_irq_domain_dt_translate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq, unsigned int *out_type)
>> +{
>> + struct gic_chip_data *gic_data = d->priv;
>> +
>> + if (d->of_node != controller)
>> + return -EINVAL;
>> + if (intsize < 3)
>> + return -EINVAL;
>> +
>> + *out_hwirq = intspec[1];
>> + /*
>> + * We've already skipped over SGIs, so PPIs need no translation.
>> + * For SPIs, we need to skip over 16 PPIs on primary GICs.
>> + */
>> + if (!intspec[0] && !gic_data->irq_offset)
>> + *out_hwirq += 16;
>
> I though that the offset was 32 to get from SPI number to Interrrupt
> ID? And that PPI interrupts start at Interrupt ID 16? Or am I
> mistaken about the hwirq number that this driver uses internally?
>
There's basically 2 cases to handle: primary and secondary controllers.
For primary ctrlrs, the domain irq_base is already 16 to skip over SGIs
and legacy ISA interrupts. So PPIs don't need any conversion and SPIs
only need 16 more added. I misspoke previously as it's not quite
independent of virq numbering because entry-macro-gic.S is still fixed
GIC ID = Linux virq (or offset of 32 in Exynos case).
For secondary ctrlrs, the gic code already accounts for 32 offset in ID
to Linux virq with the irq_offset field which is set to Linux virq base
- 32. So in this case, no conversion is needed.
I don't really see a better way without breaking non-DT use of the gic.
Rob
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-21 1:57 UTC (permalink / raw)
To: linux-arm-kernel
we save the l2x0 registers at the first initialization, and restore
them after resuming every time.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
arch/arm/include/asm/outercache.h | 7 +++
arch/arm/mm/cache-l2x0.c | 81 ++++++++++++++++++++++++++++++++----
2 files changed, 79 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index d838743..53426c6 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -34,6 +34,7 @@ struct outer_cache_fns {
void (*sync)(void);
#endif
void (*set_debug)(unsigned long);
+ void (*resume)(void);
};
#ifdef CONFIG_OUTER_CACHE
@@ -74,6 +75,12 @@ static inline void outer_disable(void)
outer_cache.disable();
}
+static inline void outer_resume(void)
+{
+ if (outer_cache.resume)
+ outer_cache.resume();
+}
+
#else
static inline void outer_inv_range(phys_addr_t start, phys_addr_t end)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 0d85d22..4722707 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -32,6 +32,14 @@ static void __iomem *l2x0_base;
static DEFINE_SPINLOCK(l2x0_lock);
static uint32_t l2x0_way_mask; /* Bitmask of active ways */
static uint32_t l2x0_size;
+static u32 l2x0_aux_ctrl;
+static u32 l2x0_tag_latency, l2x0_data_latency, l2x0_filter_start, l2x0_filter_end;
+
+struct l2x0_of_data {
+ void (*setup)(const struct device_node *,__u32 *, __u32 *);
+ void (*save)(void);
+ void (*resume)(void);
+};
static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
{
@@ -280,7 +288,7 @@ static void l2x0_disable(void)
spin_unlock_irqrestore(&l2x0_lock, flags);
}
-static void __init l2x0_unlock(__u32 cache_id)
+static void l2x0_unlock(__u32 cache_id)
{
int lockregs;
int i;
@@ -356,6 +364,8 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
/* l2x0 controller is disabled */
writel_relaxed(aux, l2x0_base + L2X0_AUX_CTRL);
+ l2x0_aux_ctrl = aux;
+
l2x0_inv_all();
/* enable L2X0 */
@@ -445,18 +455,64 @@ static void __init pl310_of_setup(const struct device_node *np,
}
}
+static void __init pl310_save(void)
+{
+ l2x0_tag_latency = readl_relaxed(l2x0_base + L2X0_TAG_LATENCY_CTRL);
+ l2x0_data_latency = readl_relaxed(l2x0_base + L2X0_DATA_LATENCY_CTRL);
+ l2x0_filter_end = readl_relaxed(l2x0_base + L2X0_ADDR_FILTER_END);
+ l2x0_filter_start = readl_relaxed(l2x0_base + L2X0_ADDR_FILTER_START);
+}
+
+static void l2x0_resume(void)
+{
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ /* restore aux ctrl and enable l2 */
+ l2x0_unlock(readl_relaxed(l2x0_base + L2X0_CACHE_ID));
+
+ writel_relaxed(l2x0_aux_ctrl, l2x0_base + L2X0_AUX_CTRL);
+
+ l2x0_inv_all();
+
+ writel_relaxed(1, l2x0_base + L2X0_CTRL);
+ }
+}
+
+static void pl310_resume(void)
+{
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ /* restore pl310 setup */
+ writel_relaxed(l2x0_tag_latency, l2x0_base + L2X0_TAG_LATENCY_CTRL);
+ writel_relaxed(l2x0_data_latency, l2x0_base + L2X0_DATA_LATENCY_CTRL);
+ writel_relaxed(l2x0_filter_end, l2x0_base + L2X0_ADDR_FILTER_END);
+ writel_relaxed(l2x0_filter_start, l2x0_base + L2X0_ADDR_FILTER_START);
+ }
+
+ l2x0_resume();
+}
+
+static const struct l2x0_of_data pl310_data = {
+ pl310_of_setup,
+ pl310_save,
+ pl310_resume,
+};
+
+static const struct l2x0_of_data l2x0_data = {
+ l2x0_of_setup,
+ NULL,
+ l2x0_resume,
+};
+
static const struct of_device_id l2x0_ids[] __initconst = {
- { .compatible = "arm,pl310-cache", .data = pl310_of_setup },
- { .compatible = "arm,l220-cache", .data = l2x0_of_setup },
- { .compatible = "arm,l210-cache", .data = l2x0_of_setup },
+ { .compatible = "arm,pl310-cache", .data = (void *)&pl310_data },
+ { .compatible = "arm,l220-cache", .data = (void *)&l2x0_data },
+ { .compatible = "arm,l210-cache", .data = (void *)&l2x0_data },
{}
};
int __init l2x0_of_init(__u32 aux_val, __u32 aux_mask)
{
struct device_node *np;
- void (*l2_setup)(const struct device_node *np,
- __u32 *aux_val, __u32 *aux_mask);
+ struct l2x0_of_data *data;
np = of_find_matching_node(NULL, l2x0_ids);
if (!np)
@@ -465,13 +521,20 @@ int __init l2x0_of_init(__u32 aux_val, __u32 aux_mask)
if (!l2x0_base)
return -ENOMEM;
+ data = of_match_node(l2x0_ids, np)->data;
+
/* L2 configuration can only be changed if the cache is disabled */
if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
- l2_setup = of_match_node(l2x0_ids, np)->data;
- if (l2_setup)
- l2_setup(np, &aux_val, &aux_mask);
+ if (data->setup)
+ data->setup(np, &aux_val, &aux_mask);
}
+
+ if (data->save)
+ data->save();
+
l2x0_init(l2x0_base, aux_val, aux_mask);
+
+ outer_cache.resume = data->resume;
return 0;
}
#endif
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply related
* [PATCH 0/3] GIC OF bindings
From: David Miller @ 2011-09-21 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robherring2@gmail.com>
Date: Tue, 20 Sep 2011 15:24:01 -0500
> Hopefully, this is the final or near final version of GIC binding support.
>
> Changes from the previous version:
> - SPIs and PPIs are numbered starting at 0. Now the gic has it's own irq
> domain translate function instead of the simple domain one.
> - interrupt cell format has changed based on Grant's proposal.
> - Dropped "ARM: gic: allow irq_start to be 0". Instead, the first 16 irqs
> are skipped and the domain irq_base adjusted accordingly.
> - Added a fix to of_irq_find_parent when the parent == child.
> - Renamed intc_desc.parent to intc_desc.interrupt_parent.
> - Implemented Grant's algorithm for walking the list of interrupt
> controllers. Added a return value to interrupt init functions, so they
> don't get added to the parent list on a init failure.
>
> The changes are significant enough that I did not include previous
> acked/reviewed/tested-by's.
Just out of curiosity where does this "interrupt-parent" property
come from?
On platforms I am familiar with, the parent path is walked to the root
and we stop at device nodes that have "interrupt-map" and
"interrupt-map-mask" properties.
The map and mask are applied to the "reg" property of the device in
question to see which map entry matches, if a match is found the map
entry contains the translated interrupt.
And this process continues over and over all the way to the root to get
the system interrupt that processor actually deals with.
The mechanism shown here seems overly simplistic and not able to handle
the cases handled by existing OF property schemes in use for several
years on real systems.
^ permalink raw reply
* [PATCH] serial: samsung: move handling of fclk/n clock to platform code
From: Thomas Abraham @ 2011-09-21 3:24 UTC (permalink / raw)
To: linux-arm-kernel
s3c2440 uses fclk/n (fclk divided by n) clock as one of the possible clocks used
to generate the baud rate clock. The divider 'n' in this case can be logically
represented outside of the uart controller.
This patch creates a new clock by name "fclk_n" for s3c2440 based platforms to
represent the fclk/n clock in the platform code. This clock provides a get_rate
callback that checks the UCON0/1/2 registers to determine the clock rate. The
samsung uart driver would receive the "fclk_n" clock name as one of the possible
baud rate clock options and the driver need not determine clock rate of fclk/n.
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
In order to add clkdev based clock lookup (moving away from passing clock names
in platform data) for the Samsung UART driver, some portions of this driver
have to be first simplified. In this patch, the complicated handling on fclk/n
clock is removed which would further result in removing of the struct
s3c24xx_uart_clksrc itself and consolidation of the clock handling for
various SoC's supported by the Samsung UART driver.
The addition of clkdev based clock lookup is required to fully add device tree
support for the Samsung driver (no platform data when using device tree based
discovery means no list of clock names for baud rate clock).
This patch has been tested on smdk2440 board and following two patches
applied on top of linux 3.1-rc6.
[PATCH] serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
[PATCH] ARM: SAMSUNG: Remove uart irq handling from plaform code
arch/arm/mach-s3c2440/clock.c | 37 +++++++++++++++++++++++++++++++++++
arch/arm/mach-s3c2440/mach-rx1950.c | 4 +-
arch/arm/mach-s3c2440/mach-rx3715.c | 4 +-
drivers/tty/serial/s3c2440.c | 33 ++----------------------------
drivers/tty/serial/samsung.c | 21 -------------------
5 files changed, 44 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-s3c2440/clock.c b/arch/arm/mach-s3c2440/clock.c
index f9e6bda..8a6cf6a 100644
--- a/arch/arm/mach-s3c2440/clock.c
+++ b/arch/arm/mach-s3c2440/clock.c
@@ -34,6 +34,7 @@
#include <linux/mutex.h>
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/serial_core.h>
#include <mach/hardware.h>
#include <linux/atomic.h>
@@ -43,6 +44,7 @@
#include <plat/clock.h>
#include <plat/cpu.h>
+#include <plat/regs-serial.h>
/* S3C2440 extended clock support */
@@ -108,6 +110,40 @@ static struct clk s3c2440_clk_ac97 = {
.ctrlbit = S3C2440_CLKCON_CAMERA,
};
+static unsigned long s3c2440_fclk_n_getrate(struct clk *clk)
+{
+ unsigned long ucon0, ucon1, ucon2, divisor;
+
+ /* the fun of calculating the uart divisors on the s3c2440 */
+ ucon0 = __raw_readl(S3C24XX_VA_UART0 + S3C2410_UCON);
+ ucon1 = __raw_readl(S3C24XX_VA_UART1 + S3C2410_UCON);
+ ucon2 = __raw_readl(S3C24XX_VA_UART2 + S3C2410_UCON);
+
+ ucon0 &= S3C2440_UCON0_DIVMASK;
+ ucon1 &= S3C2440_UCON1_DIVMASK;
+ ucon2 &= S3C2440_UCON2_DIVMASK;
+
+ if (ucon0 != 0)
+ divisor = (ucon0 >> S3C2440_UCON_DIVSHIFT) + 6;
+ else if (ucon1 != 0)
+ divisor = (ucon1 >> S3C2440_UCON_DIVSHIFT) + 21;
+ else if (ucon2 != 0)
+ divisor = (ucon2 >> S3C2440_UCON_DIVSHIFT) + 36;
+ else
+ /* manual calims 44, seems to be 9 */
+ divisor = 9;
+
+ return clk_get_rate(clk->parent) / divisor;
+}
+
+static struct clk s3c2440_clk_fclk_n = {
+ .name = "fclk_n",
+ .parent = &clk_f,
+ .ops = &(struct clk_ops) {
+ .get_rate = s3c2440_fclk_n_getrate,
+ },
+};
+
static int s3c2440_clk_add(struct sys_device *sysdev)
{
struct clk *clock_upll;
@@ -126,6 +162,7 @@ static int s3c2440_clk_add(struct sys_device *sysdev)
s3c2440_clk_cam.parent = clock_h;
s3c2440_clk_ac97.parent = clock_p;
s3c2440_clk_cam_upll.parent = clock_upll;
+ s3c24xx_register_clock(&s3c2440_clk_fclk_n);
s3c24xx_register_clock(&s3c2440_clk_ac97);
s3c24xx_register_clock(&s3c2440_clk_cam);
diff --git a/arch/arm/mach-s3c2440/mach-rx1950.c b/arch/arm/mach-s3c2440/mach-rx1950.c
index 27ea950..9528b37 100644
--- a/arch/arm/mach-s3c2440/mach-rx1950.c
+++ b/arch/arm/mach-s3c2440/mach-rx1950.c
@@ -69,8 +69,8 @@ static struct map_desc rx1950_iodesc[] __initdata = {
static struct s3c24xx_uart_clksrc rx1950_serial_clocks[] = {
[0] = {
- .name = "fclk",
- .divisor = 0x0a,
+ .name = "fclk_n",
+ .divisor = 1,
.min_baud = 0,
.max_baud = 0,
},
diff --git a/arch/arm/mach-s3c2440/mach-rx3715.c b/arch/arm/mach-s3c2440/mach-rx3715.c
index 1472b1a..a88247e 100644
--- a/arch/arm/mach-s3c2440/mach-rx3715.c
+++ b/arch/arm/mach-s3c2440/mach-rx3715.c
@@ -70,8 +70,8 @@ static struct map_desc rx3715_iodesc[] __initdata = {
static struct s3c24xx_uart_clksrc rx3715_serial_clocks[] = {
[0] = {
- .name = "fclk",
- .divisor = 0,
+ .name = "fclk_n",
+ .divisor = 1,
.min_baud = 0,
.max_baud = 0,
}
diff --git a/drivers/tty/serial/s3c2440.c b/drivers/tty/serial/s3c2440.c
index 1d0c324..4498828 100644
--- a/drivers/tty/serial/s3c2440.c
+++ b/drivers/tty/serial/s3c2440.c
@@ -39,7 +39,7 @@ static int s3c2440_serial_setsource(struct uart_port *port,
ucon |= S3C2440_UCON_UCLK;
else if (strcmp(clk->name, "pclk") == 0)
ucon |= S3C2440_UCON_PCLK;
- else if (strcmp(clk->name, "fclk") == 0)
+ else if (strcmp(clk->name, "fclk_n") == 0)
ucon |= S3C2440_UCON_FCLK;
else {
printk(KERN_ERR "unknown clock source %s\n", clk->name);
@@ -55,7 +55,6 @@ static int s3c2440_serial_getsource(struct uart_port *port,
struct s3c24xx_uart_clksrc *clk)
{
unsigned long ucon = rd_regl(port, S3C2410_UCON);
- unsigned long ucon0, ucon1, ucon2;
switch (ucon & S3C2440_UCON_CLKMASK) {
case S3C2440_UCON_UCLK:
@@ -70,34 +69,8 @@ static int s3c2440_serial_getsource(struct uart_port *port,
break;
case S3C2440_UCON_FCLK:
- /* the fun of calculating the uart divisors on
- * the s3c2440 */
-
- ucon0 = __raw_readl(S3C24XX_VA_UART0 + S3C2410_UCON);
- ucon1 = __raw_readl(S3C24XX_VA_UART1 + S3C2410_UCON);
- ucon2 = __raw_readl(S3C24XX_VA_UART2 + S3C2410_UCON);
-
- printk("ucons: %08lx, %08lx, %08lx\n", ucon0, ucon1, ucon2);
-
- ucon0 &= S3C2440_UCON0_DIVMASK;
- ucon1 &= S3C2440_UCON1_DIVMASK;
- ucon2 &= S3C2440_UCON2_DIVMASK;
-
- if (ucon0 != 0) {
- clk->divisor = ucon0 >> S3C2440_UCON_DIVSHIFT;
- clk->divisor += 6;
- } else if (ucon1 != 0) {
- clk->divisor = ucon1 >> S3C2440_UCON_DIVSHIFT;
- clk->divisor += 21;
- } else if (ucon2 != 0) {
- clk->divisor = ucon2 >> S3C2440_UCON_DIVSHIFT;
- clk->divisor += 36;
- } else {
- /* manual calims 44, seems to be 9 */
- clk->divisor = 9;
- }
-
- clk->name = "fclk";
+ clk->divisor = 1;
+ clk->name = "fclk_n";
break;
}
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 6edafb5..97e45cd 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -569,27 +569,6 @@ static unsigned int s3c24xx_serial_getclk(struct uart_port *port,
if (cfg->clocks_size == 0)
clkp = &tmp_clksrc;
- /* check to see if we're sourcing fclk, and if so we're
- * going to have to update the clock source
- */
-
- if (strcmp(clkp->name, "fclk") == 0) {
- struct s3c24xx_uart_clksrc src;
-
- s3c24xx_serial_getsource(port, &src);
-
- /* check that the port already using fclk, and if
- * not, then re-select fclk
- */
-
- if (strcmp(src.name, clkp->name) == 0) {
- s3c24xx_serial_setsource(port, clkp);
- s3c24xx_serial_getsource(port, &src);
- }
-
- clkp->divisor = src.divisor;
- }
-
s3c24xx_serial_calcbaud(res, port, clkp, baud);
best = res;
resptr = best + 1;
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] mxcuart: add polled io methods
From: Fabio Estevam @ 2011-09-21 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316396718-31886-2-git-send-email-compnerd@compnerd.org>
Hi Saleem,
On Sun, Sep 18, 2011 at 10:45 PM, Saleem Abdulrasool
<compnerd@compnerd.org> wrote:
> ---
> ?drivers/serial/mxc_uart.c | ? 78 +++++++++++++++++++++++++++++++++++++++++++++
> ?1 files changed, 78 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/serial/mxc_uart.c b/drivers/serial/mxc_uart.c
> index 347a746..5769465 100644
> --- a/drivers/serial/mxc_uart.c
> +++ b/drivers/serial/mxc_uart.c
You missed a commit message and your Signed-off-by line.
Have you tried using KGDB after applying your patch?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Grant Likely @ 2011-09-21 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920.224910.1996429830782124690.davem@davemloft.net>
On Tue, Sep 20, 2011 at 8:49 PM, David Miller <davem@davemloft.net> wrote:
> From: Rob Herring <robherring2@gmail.com>
> Date: Tue, 20 Sep 2011 15:24:01 -0500
>
>> Hopefully, this is the final or near final version of GIC binding support.
>>
>> Changes from the previous version:
>> - SPIs and PPIs are numbered starting at 0. Now the gic has it's own irq
>> ? domain translate function instead of the simple domain one.
>> - interrupt cell format has changed based on Grant's proposal.
>> - Dropped "ARM: gic: allow irq_start to be 0". Instead, the first 16 irqs
>> ? are skipped and the domain irq_base adjusted accordingly.
>> - Added a fix to of_irq_find_parent when the parent == child.
>> - Renamed intc_desc.parent to intc_desc.interrupt_parent.
>> - Implemented Grant's algorithm for walking the list of interrupt
>> ? controllers. Added a return value to interrupt init functions, so they
>> ? don't get added to the parent list on a init failure.
>>
>> The changes are significant enough that I did not include previous
>> acked/reviewed/tested-by's.
>
> Just out of curiosity where does this "interrupt-parent" property
> come from?
>
> On platforms I am familiar with, the parent path is walked to the root
> and we stop at device nodes that have "interrupt-map" and
> "interrupt-map-mask" properties.
>
> The map and mask are applied to the "reg" property of the device in
> question to see which map entry matches, if a match is found the map
> entry contains the translated interrupt.
>
> And this process continues over and over all the way to the root to get
> the system interrupt that processor actually deals with.
>
> The mechanism shown here seems overly simplistic and not able to handle
> the cases handled by existing OF property schemes in use for several
> years on real systems.
interrupt-parent has been implemented for years on powerpc. I don't
know if it was ever an Open Firmware thing, but it is in ePAPR [1],
and ARM isn't doing anything novel in that regard.
[1] section 2.4, page 30,
https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
It is true that is cannot handle all situations, but for those
interrupt-map is still available.
g.
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Mitch Bradley @ 2011-09-21 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6t7Mdr+w+aGFPM2-FEAQaYHuG8Za9dybLgMo-5-whLyNQ@mail.gmail.com>
On 9/20/2011 6:14 PM, Grant Likely wrote:
> On Tue, Sep 20, 2011 at 8:49 PM, David Miller<davem@davemloft.net> wrote:
>> From: Rob Herring<robherring2@gmail.com>
>> Date: Tue, 20 Sep 2011 15:24:01 -0500
>>
>>> Hopefully, this is the final or near final version of GIC binding support.
>>>
>>> Changes from the previous version:
>>> - SPIs and PPIs are numbered starting at 0. Now the gic has it's own irq
>>> domain translate function instead of the simple domain one.
>>> - interrupt cell format has changed based on Grant's proposal.
>>> - Dropped "ARM: gic: allow irq_start to be 0". Instead, the first 16 irqs
>>> are skipped and the domain irq_base adjusted accordingly.
>>> - Added a fix to of_irq_find_parent when the parent == child.
>>> - Renamed intc_desc.parent to intc_desc.interrupt_parent.
>>> - Implemented Grant's algorithm for walking the list of interrupt
>>> controllers. Added a return value to interrupt init functions, so they
>>> don't get added to the parent list on a init failure.
>>>
>>> The changes are significant enough that I did not include previous
>>> acked/reviewed/tested-by's.
>>
>> Just out of curiosity where does this "interrupt-parent" property
>> come from?
>>
>> On platforms I am familiar with, the parent path is walked to the root
>> and we stop at device nodes that have "interrupt-map" and
>> "interrupt-map-mask" properties.
>>
>> The map and mask are applied to the "reg" property of the device in
>> question to see which map entry matches, if a match is found the map
>> entry contains the translated interrupt.
>>
>> And this process continues over and over all the way to the root to get
>> the system interrupt that processor actually deals with.
>>
>> The mechanism shown here seems overly simplistic and not able to handle
>> the cases handled by existing OF property schemes in use for several
>> years on real systems.
>
> interrupt-parent has been implemented for years on powerpc. I don't
> know if it was ever an Open Firmware thing, but it is in ePAPR [1],
> and ARM isn't doing anything novel in that regard.
interrupt-parent has been part of the interrupt mapping spec from the
inception of same.
http://www.openfirmware.info/docs/rec.intmap.d09.pdf
>
> [1] section 2.4, page 30,
> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
>
> It is true that is cannot handle all situations, but for those
> interrupt-map is still available.
>
> g.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Richard Zhu @ 2011-09-21 5:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920203037.GE31404@pengutronix.de>
Hi Sascha:
Thanks for your comments.
Best Regard
Richard Zhu
On 21 September 2011 04:30, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Aug 31, 2011 at 11:50:31AM +0800, Richard Zhu wrote:
>> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
>> Tested-By: Hector Oron Martinez <hector.oron@gmail.com>
>> ---
>> ?arch/arm/mach-mx5/clock-mx51-mx53.c ? ? ? ? ? ? | ? 19 ++++
>> ?arch/arm/mach-mx5/devices-imx53.h ? ? ? ? ? ? ? | ? ?4 +
>> ?arch/arm/plat-mxc/Makefile ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/plat-mxc/ahci_sata.c ? ? ? ? ? ? ? ? ? | ?104 +++++++++++++++++++++++
>> ?arch/arm/plat-mxc/devices/Kconfig ? ? ? ? ? ? ? | ? ?4 +
>> ?arch/arm/plat-mxc/devices/Makefile ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/plat-mxc/devices/platform-ahci-imx.c ? | ? 66 ++++++++++++++
>> ?arch/arm/plat-mxc/include/mach/ahci_sata.h ? ? ?| ? 33 +++++++
>> ?arch/arm/plat-mxc/include/mach/devices-common.h | ? 10 ++
>> ?9 files changed, 242 insertions(+), 0 deletions(-)
>> ?create mode 100644 arch/arm/plat-mxc/ahci_sata.c
>> ?create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
>> ?create mode 100644 arch/arm/plat-mxc/include/mach/ahci_sata.h
>>
>> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
>> index 7f20308..e1fadaf 100644
>> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
>> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
>> @@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
>> ? ? ? .secondary = &esdhc4_ipg_clk,
>> ?};
>>
>> diff --git a/arch/arm/plat-mxc/ahci_sata.c b/arch/arm/plat-mxc/ahci_sata.c
>> new file mode 100644
>> index 0000000..4f54816
>> --- /dev/null
>> +++ b/arch/arm/plat-mxc/ahci_sata.c
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>> + */
>> +
>> +/*
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * 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.,
>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/clk.h>
>> +#include <linux/err.h>
>> +#include <linux/device.h>
>> +#include <mach/ahci_sata.h>
>> +
>> +static struct clk *sata_clk, *sata_ref_clk;
>
> These variables make the driver single instance only.
[Richard Zhu] In order to handle the clock enable/disable stuff, these
two variables are mandatory required.
Otherwise, new two struct clk members had to be added into
ahci_platform_data struct. Then the clks can
be transferred by the platform data.
The current is preferred, refer to the second choice.
>
>> +
>> +/* AHCI module Initialization, if return 0, initialization is successful. */
>> +int sata_init(struct device *dev, void __iomem *addr)
>
> A global function with such a generic name is not a good idea.
> Also I wonder how we want to convert this to devicetree when we
> implement this as a platform specific hook. It should be done in the
> driver.
>
[Richard Zhu] The name of these two func can be changed.
But I don't have a good idea to move out these two platform specific
hooks (->init, ->exit).
Refer to you comments, do you means that the ->init and ->exit should
be done in ahci_platform.c driver?
Different platform may have the different ->init and ->exit funcs to
handle it's own initialization and exit.
It would be a problem that handle all kinds of init in one driver
without the hooks.
>> +{
>> + ? ? u32 tmpdata;
>> + ? ? int ret = 0;
>> + ? ? struct clk *clk;
>> +
>> + ? ? sata_clk = clk_get(dev, "ahci");
>> + ? ? if (IS_ERR(sata_clk)) {
>> + ? ? ? ? ? ? dev_err(dev, "no sata clock.\n");
>> + ? ? ? ? ? ? return PTR_ERR(sata_clk);
>> + ? ? }
>> + ? ? ret = clk_enable(sata_clk);
>> + ? ? if (ret) {
>> + ? ? ? ? ? ? dev_err(dev, "can't enable sata clock.\n");
>> + ? ? ? ? ? ? goto put_sata_clk;
>> + ? ? }
>> +
>> + ? ? /* FSL IMX AHCI SATA uses the internal usb phy1 clk on loco */
>
> So this function is loco specific or is the comment wrong?
[Richard Zhu] Comments wrong, they're common codes and should't be
specified by the exact
board, would be changed later.
>
>> + ? ? sata_ref_clk = clk_get(dev, "ahci_phy");
>> + ? ? if (IS_ERR(sata_ref_clk)) {
>> + ? ? ? ? ? ? dev_err(dev, "no sata ref clock.\n");
>> + ? ? ? ? ? ? ret = PTR_ERR(sata_ref_clk);
>> + ? ? ? ? ? ? goto release_sata_clk;
>> + ? ? }
>> + ? ? ret = clk_enable(sata_ref_clk);
>> + ? ? if (ret) {
>> + ? ? ? ? ? ? dev_err(dev, "can't enable sata ref clock.\n");
>> + ? ? ? ? ? ? goto put_sata_ref_clk;
>> + ? ? }
>> +
>> + ? ? /* Get the AHB clock rate, and configure the TIMER1MS reg later */
>> + ? ? clk = clk_get(dev, "ahci_dma");
>> + ? ? if (IS_ERR(clk)) {
>> + ? ? ? ? ? ? dev_err(dev, "no dma clock.\n");
>> + ? ? ? ? ? ? ret = PTR_ERR(clk);
>> + ? ? ? ? ? ? goto release_sata_ref_clk;
>> + ? ? }
>> + ? ? tmpdata = clk_get_rate(clk) / 1000;
>> + ? ? clk_put(clk);
>> +
>> + ? ? writel(tmpdata, addr + HOST_TIMER1MS);
>> +
>> + ? ? tmpdata = readl(addr + HOST_CAP);
>> + ? ? if (!(tmpdata & HOST_CAP_SSS)) {
>> + ? ? ? ? ? ? tmpdata |= HOST_CAP_SSS;
>> + ? ? ? ? ? ? writel(tmpdata, addr + HOST_CAP);
>> + ? ? }
>> +
>> + ? ? if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
>> + ? ? ? ? ? ? writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
>> + ? ? ? ? ? ? ? ? ? ? addr + HOST_PORTS_IMPL);
>> +
>> + ? ? return 0;
>> +
>> +release_sata_ref_clk:
>> + ? ? clk_disable(sata_ref_clk);
>> +put_sata_ref_clk:
>> + ? ? clk_put(sata_ref_clk);
>> +release_sata_clk:
>> + ? ? clk_disable(sata_clk);
>> +put_sata_clk:
>> + ? ? clk_put(sata_clk);
>> +
>> + ? ? return ret;
>> +}
>> +
>> +void sata_exit(struct device *dev)
>> +{
>> + ? ? clk_disable(sata_ref_clk);
>> + ? ? clk_put(sata_ref_clk);
>> +
>> + ? ? clk_disable(sata_clk);
>> + ? ? clk_put(sata_clk);
>> +
>> +}
>> diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
>> index bd294ad..f63887b 100644
>> --- a/arch/arm/plat-mxc/devices/Kconfig
>> +++ b/arch/arm/plat-mxc/devices/Kconfig
>> @@ -76,3 +76,7 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
>>
>> ?config IMX_HAVE_PLATFORM_SPI_IMX
>> ? ? ? bool
>> +
>> +config IMX_HAVE_PLATFORM_AHCI
>> + ? ? bool
>> + ? ? default y if ARCH_MX53
>> diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
>> index b41bf97..e858ad9 100644
>> --- a/arch/arm/plat-mxc/devices/Makefile
>> +++ b/arch/arm/plat-mxc/devices/Makefile
>> @@ -25,3 +25,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) += ?platform-spi_imx.o
>> +obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) += ?platform-ahci-imx.o
>> diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
>> new file mode 100644
>> index 0000000..9e1b460
>> --- /dev/null
>> +++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
>> @@ -0,0 +1,66 @@
>> +/*
>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>> + */
>> +
>> +/*
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * 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.,
>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>> + */
>> +
>> +#include <linux/dma-mapping.h>
>> +#include <asm/sizes.h>
>> +#include <mach/hardware.h>
>> +#include <mach/devices-common.h>
>> +#include <mach/ahci_sata.h>
>> +
>> +#define imx_ahci_imx_data_entry_single(soc, _devid) ? ? ? ? ?\
>> + ? ? { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
>> + ? ? ? ? ? ? .devid = _devid, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>> + ? ? ? ? ? ? .iobase = soc ## _SATA_BASE_ADDR, ? ? ? ? ? ? ? ? ? ? ? \
>> + ? ? ? ? ? ? .irq = soc ## _INT_SATA, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>> + ? ? }
>> +
>> +#ifdef CONFIG_SOC_IMX53
>> +const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
>> + ? ? imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
>> +#endif
>> +
>> +static struct ahci_platform_data default_sata_pdata = {
>> + ? ? .init = sata_init,
>> + ? ? .exit = sata_exit,
>> +};
>> +
>> +struct platform_device *__init imx_add_ahci_imx(
>> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
>> + ? ? ? ? ? ? const struct ahci_platform_data *pdata)
>> +{
>> + ? ? struct resource res[] = {
>> + ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? .start = data->iobase,
>> + ? ? ? ? ? ? ? ? ? ? .end = data->iobase + SZ_4K - 1,
>> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_MEM,
>> + ? ? ? ? ? ? }, {
>> + ? ? ? ? ? ? ? ? ? ? .start = data->irq,
>> + ? ? ? ? ? ? ? ? ? ? .end = data->irq,
>> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_IRQ,
>> + ? ? ? ? ? ? },
>> + ? ? };
>> +
>> + ? ? if (pdata == NULL)
>> + ? ? ? ? ? ? pdata = &default_sata_pdata;
>> +
>> + ? ? return imx_add_platform_device_dmamask(data->devid, 0,
>> + ? ? ? ? ? ? ? ? ? ? res, ARRAY_SIZE(res),
>> + ? ? ? ? ? ? ? ? ? ? pdata, sizeof(*pdata), ?DMA_BIT_MASK(32));
>> +}
>> diff --git a/arch/arm/plat-mxc/include/mach/ahci_sata.h b/arch/arm/plat-mxc/include/mach/ahci_sata.h
>> new file mode 100644
>> index 0000000..ba297e1
>> --- /dev/null
>> +++ b/arch/arm/plat-mxc/include/mach/ahci_sata.h
>> @@ -0,0 +1,33 @@
>> +/*
>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>> + */
>> +
>> +/*
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * 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.,
>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>> + */
>> +
>> +#ifndef __PLAT_MXC_AHCI_SATA_H__
>> +#define __PLAT_MXC_AHCI_SATA_H__
>> +
>> +enum {
>> + ? ? HOST_CAP = 0x00,
>> + ? ? HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
>> + ? ? HOST_PORTS_IMPL = 0x0c,
>> + ? ? HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
>> +};
>> +
>> +extern int sata_init(struct device *dev, void __iomem *addr);
>> +extern void sata_exit(struct device *dev);
>> +#endif /* __PLAT_MXC_AHCI_SATA_H__ */
>> diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
>> index 524538a..f04e063 100644
>> --- a/arch/arm/plat-mxc/include/mach/devices-common.h
>> +++ b/arch/arm/plat-mxc/include/mach/devices-common.h
>> @@ -301,3 +301,13 @@ struct platform_device *__init imx_add_spi_imx(
>> ?struct platform_device *imx_add_imx_dma(void);
>> ?struct platform_device *imx_add_imx_sdma(char *name,
>> ? ? ? resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
>> +
>> +#include <linux/ahci_platform.h>
>> +struct imx_ahci_imx_data {
>> + ? ? const char *devid;
>> + ? ? resource_size_t iobase;
>> + ? ? resource_size_t irq;
>> +};
>> +struct platform_device *__init imx_add_ahci_imx(
>> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
>> + ? ? ? ? ? ? const struct ahci_platform_data *pdata);
>> --
>> 1.7.1
>>
>>
>>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Segher Boessenkool @ 2011-09-21 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920.224910.1996429830782124690.davem@davemloft.net>
> Just out of curiosity where does this "interrupt-parent" property
> come from?
>
> On platforms I am familiar with, the parent path is walked to the root
> and we stop at device nodes that have "interrupt-map" and
> "interrupt-map-mask" properties.
"interrupt-parent" is defined in the Open Firmware "interrupt mapping"
recommended practice, the same place as "interrupt-map" etc. are.
> The mechanism shown here seems overly simplistic and not able to
> handle
> the cases handled by existing OF property schemes in use for several
> years on real systems.
"interrupt-parent" is only meant to be used for the simple cases. It's
quite handy there. It is also required in all "interrupt-controller"
nodes that aren't the root of the interrupt tree.
Segher
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: David Miller @ 2011-09-21 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E796EE4.6070704@firmworks.com>
From: Mitch Bradley <wmb@firmworks.com>
Date: Tue, 20 Sep 2011 18:58:12 -1000
> interrupt-parent has been part of the interrupt mapping spec from the
> inception of same.
>
> http://www.openfirmware.info/docs/rec.intmap.d09.pdf
Thanks for the link.
In my vast collection of Sun OF dumps, I cannot find a single instance
where they've made use of this property, which is why I've never seen
it before.
^ permalink raw reply
* [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
From: Ravi, Deepthy @ 2011-09-21 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109210126.20436.laurent.pinchart@ideasonboard.com>
Hi Laurent,
> ________________________________________
> From: Laurent Pinchart [laurent.pinchart at ideasonboard.com]
> Sent: Wednesday, September 21, 2011 4:56 AM
> To: Ravi, Deepthy
> Cc: mchehab at infradead.org; tony at atomide.com; Hiremath, Vaibhav;
> linux-media at vger.kernel.org; linux at arm.linux.org.uk;
> linux-arm-kernel at lists.infradead.org; kyungmin.park at samsung.com;
> hverkuil at xs4all.nl; m.szyprowski at samsung.com; g.liakhovetski at gmx.de;
> Shilimkar, Santosh; khilman at deeprootsystems.com; david.woodhouse at intel.com;
> akpm at linux-foundation.org; linux-kernel at vger.kernel.org;
> linux-omap at vger.kernel.org; Sakari Ailus
> Subject: Re: [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for
> UYVY8_2X8 and YUYV8_2X8 formats
>
> Hi Deepthy,
>
> Thanks for the patch.
>
> On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
>> Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
>> register for UYVY8_2X8 and YUYV8_2X8 formats.
>>
>> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
>> ---
>> drivers/media/video/omap3isp/ispccdc.c | 11 ++++++++---
>> 1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/video/omap3isp/ispccdc.c
>> b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644
>> --- a/drivers/media/video/omap3isp/ispccdc.c
>> +++ b/drivers/media/video/omap3isp/ispccdc.c
>> @@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct
>> isp_ccdc_device
>> *ccdc,
>>
>> syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK;
>> if (format->code == V4L2_MBUS_FMT_YUYV8_2X8 ||
>> - format->code == V4L2_MBUS_FMT_UYVY8_2X8)
>> - syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
>> + format->code == V4L2_MBUS_FMT_UYVY8_2X8){
>> + if (pdata && pdata->bt656)
>> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
>> + else
>> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
>> + }
>> else if (format->code == V4L2_MBUS_FMT_YUYV8_1X16 ||
>> format->code == V4L2_MBUS_FMT_UYVY8_1X16)
>> syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
>> @@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device
>> *ccdc) syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
>>
>> /* Use PACK8 mode for 1byte per pixel formats. */
>> - if (omap3isp_video_format_info(format->code)->width <= 8)
>> + if ((omap3isp_video_format_info(format->code)->width <= 8) &&
>> + (omap3isp_video_format_info(format->code)->bpp <=
>> 8))
>
> I'm not sure to follow you. This will clear the PACK8 bit for the YUYV8_2X8
> formats. Those formats are 8 bits wide, shouldn't PACK8 be set to store
> samples on 8 bits instead of 16 bits ?
>
> Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode with
> the bridge enabled ? In that case, what would you think about setting the
> CCDC
> input format to YUYV8_1X16 instead ? This would better reflect the reality,
> as
> the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC is then fed with
> YUYV8_1X16.
>
[Deepthy Ravi] Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit bridge enabled. So the data has to be stored as 16 bits per sample. Thats why PACK8 is cleared . I am not sure about using YUYV8_1X16.
>> syn_mode |= ISPCCDC_SYN_MODE_PACK8;
>> else
>> syn_mode &= ~ISPCCDC_SYN_MODE_PACK8;
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Thanks,
Deepthy Ravi
^ permalink raw reply
* [PATCH V2 0/3] Add TVOUT support for SMDKV310
From: Hatim Ali @ 2011-09-21 5:44 UTC (permalink / raw)
To: linux-arm-kernel
This is v2 of the TVOUT patch set for SMDKV310.
v1 is available at below link.
(http://www.spinics.net/lists/arm-kernel/msg138054.html)
Patch 1 has been modified according to the comments received from
Tomasz Stanislawski.
Patches 2 and 3 are RESENDs.
Hatim Ali (3):
ARM: EXYNOS4: Add TVOUT support for SMDKV310
ARM: EXYNOS4: Update consistent DMA size to 8MB
s5p-tv: Add PM_RUNTIME dependency
arch/arm/mach-exynos4/Kconfig | 2 ++
arch/arm/mach-exynos4/include/mach/memory.h | 2 ++
arch/arm/mach-exynos4/mach-smdkv310.c | 25 +++++++++++++++++++++++++
drivers/media/video/s5p-tv/Kconfig | 2 +-
4 files changed, 30 insertions(+), 1 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Hatim Ali @ 2011-09-21 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316583860-32510-1-git-send-email-hatim.rv@samsung.com>
Add support for TVOUT on SMDKV310 board.
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
---
Changes since V1:
Incorporated changes as suggested by Tomasz Stanislawski
- Added GPIO settings for hot-plug detection.
- Added setting hdmi and mixer's parent for TV power domain.
arch/arm/mach-exynos4/Kconfig | 2 ++
arch/arm/mach-exynos4/mach-smdkv310.c | 25 +++++++++++++++++++++++++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 3b594fe..0bf0fe04 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -131,6 +131,7 @@ config MACH_SMDKV310
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
+ select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_MFC
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
@@ -140,6 +141,7 @@ config MACH_SMDKV310
select EXYNOS4_DEV_AHCI
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
+ select S5P_DEV_TV
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_SYSMMU
select EXYNOS4_SETUP_FIMD0
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c
index 7ce4d8b..50de270 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[] __initdata = {
&s3c_device_hsmmc2,
&s3c_device_hsmmc3,
&s3c_device_i2c1,
+ &s5p_device_i2c_hdmiphy,
&s3c_device_rtc,
&s3c_device_wdt,
&exynos4_device_ac97,
@@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[] __initdata = {
&smdkv310_lcd_lte480wv,
&smdkv310_smsc911x,
&exynos4_device_ahci,
+ &s5p_device_hdmi,
+ &s5p_device_mixer,
};
static void __init smdkv310_smsc911x_init(void)
@@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data smdkv310_bl_data = {
.pwm_period_ns = 1000,
};
+static void s5p_tv_setup(void)
+{
+ int ret;
+
+ /* direct HPD to HDMI chip */
+ ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
+
+ if (!ret) {
+ gpio_direction_input(EXYNOS4_GPX3(7));
+ s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
+ 1, S3C_GPIO_SFN(3));
+ } else
+ pr_err("Failed to request gpio for hpd: %d\n", ret);
+
+ /* setup dependencies between TV devices */
+ s5p_device_hdmi.dev.parent = &exynos4_device_pd[PD_TV].dev;
+ s5p_device_mixer.dev.parent = &exynos4_device_pd[PD_TV].dev;
+}
+
static void __init smdkv310_map_io(void)
{
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
+ s5p_tv_setup();
+ s5p_i2c_hdmiphy_set_platdata(NULL);
+
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
}
--
1.7.2.3
^ permalink raw reply related
* [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
From: Hatim Ali @ 2011-09-21 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316583860-32510-1-git-send-email-hatim.rv@samsung.com>
Change the consistent DMA allocation to 8MB to support the
TVOUT driver.
NOTE: Once CMA support is merged into mainline, we will use it for memory
allocation.
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
---
arch/arm/mach-exynos4/include/mach/memory.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/memory.h b/arch/arm/mach-exynos4/include/mach/memory.h
index 374ef2c..7549742 100644
--- a/arch/arm/mach-exynos4/include/mach/memory.h
+++ b/arch/arm/mach-exynos4/include/mach/memory.h
@@ -15,6 +15,8 @@
#define PLAT_PHYS_OFFSET UL(0x40000000)
+#define CONSISTENT_DMA_SIZE SZ_8M
+
/* Maximum of 256MiB in one bank */
#define MAX_PHYSMEM_BITS 32
#define SECTION_SIZE_BITS 28
--
1.7.2.3
^ permalink raw reply related
* [RESEND PATCH 3/3] s5p-tv: Add PM_RUNTIME dependency
From: Hatim Ali @ 2011-09-21 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316583860-32510-1-git-send-email-hatim.rv@samsung.com>
The TVOUT driver requires PM_RUNTIME support for proper clock
enabling.
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
---
drivers/media/video/s5p-tv/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-tv/Kconfig b/drivers/media/video/s5p-tv/Kconfig
index 9c37dee..f2a0977 100644
--- a/drivers/media/video/s5p-tv/Kconfig
+++ b/drivers/media/video/s5p-tv/Kconfig
@@ -8,7 +8,7 @@
config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform (experimental)"
- depends on PLAT_S5P
+ depends on PLAT_S5P && PM_RUNTIME
depends on EXPERIMENTAL
default n
---help---
--
1.7.2.3
^ permalink raw reply related
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Shawn Guo @ 2011-09-21 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316570265-13709-1-git-send-email-Baohua.Song@csr.com>
Hi Barry,
On Tue, Sep 20, 2011 at 06:57:45PM -0700, Barry Song wrote:
> we save the l2x0 registers at the first initialization, and restore
> them after resuming every time.
>
I'm unsure that it will work for cases like imx6q, where L2 cache is
retained and the controller needs to be restored at the very beginning
of the resume entry (running on physical space).
Regards,
Shawn
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> arch/arm/include/asm/outercache.h | 7 +++
> arch/arm/mm/cache-l2x0.c | 81 ++++++++++++++++++++++++++++++++----
> 2 files changed, 79 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-21 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921055223.GA28907@S2100-06.ap.freescale.net>
2011/9/21 Shawn Guo <shawn.guo@freescale.com>:
> Hi Barry,
>
> On Tue, Sep 20, 2011 at 06:57:45PM -0700, Barry Song wrote:
>> we save the l2x0 registers at the first initialization, and restore
>> them after resuming every time.
>>
> I'm unsure that it will work for cases like imx6q, where L2 cache is
> retained and the controller needs to be restored at the very beginning
> of the resume entry (running on physical space).
yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
resume). so how about letting outer_resume support both phy and virt
address restore?
for example, add early resume: outer_early_resume()
Then for your case, you use asm to "bl out_resume", then "b cpu_resume".
For those chips which lose l2 in suspend cycle, people can call it in
C function after cpu_resume.
>
> Regards,
> Shawn
-barry
^ 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