* [RE-SEND] [PATCH 1/4] ARM: EXYNOS4: Add FIMD resource definition
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
@ 2011-06-10 8:15 ` Anand Kumar N
2011-06-10 8:15 ` [RE-SEND] [PATCH 2/4] ARM: EXYNOS4: Add platform device and helper functions for FIMD Anand Kumar N
` (4 subsequent siblings)
5 siblings, 0 replies; 18+ messages in thread
From: Anand Kumar N @ 2011-06-10 8:15 UTC (permalink / raw)
To: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, anand.kn
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds resource definitions for EXYNOS4 FIMD.
IRQ and SFR definitions are added.
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/include/mach/irqs.h | 8 ++++++++
arch/arm/mach-exynos4/include/mach/map.h | 5 +++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-exynos4/include/mach/irqs.h
index 5d03730..2cd2090 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -73,6 +73,14 @@
#define IRQ_SYSMMU_MFC_M1_0 COMBINER_IRQ(5, 6)
#define IRQ_SYSMMU_PCIE_0 COMBINER_IRQ(5, 7)
+#define IRQ_FIMD0_FIFO COMBINER_IRQ(11, 0)
+#define IRQ_FIMD0_VSYNC COMBINER_IRQ(11, 1)
+#define IRQ_FIMD0_SYSTEM COMBINER_IRQ(11, 2)
+
+#define IRQ_FIMD1_FIFO COMBINER_IRQ(12, 0)
+#define IRQ_FIMD1_VSYNC COMBINER_IRQ(12, 1)
+#define IRQ_FIMD1_SYSTEM COMBINER_IRQ(12, 2)
+
#define IRQ_PDMA0 COMBINER_IRQ(21, 0)
#define IRQ_PDMA1 COMBINER_IRQ(21, 1)
diff --git a/arch/arm/mach-exynos4/include/mach/map.h b/arch/arm/mach-exynos4/include/mach/map.h
index 57d8074..4e3e1b6 100644
--- a/arch/arm/mach-exynos4/include/mach/map.h
+++ b/arch/arm/mach-exynos4/include/mach/map.h
@@ -95,6 +95,9 @@
#define EXYNOS4_PA_MIPI_CSIS0 0x11880000
#define EXYNOS4_PA_MIPI_CSIS1 0x11890000
+#define EXYNOS4_PA_FIMD0 0x11C00000
+#define EXYNOS4_PA_FIMD1 0x12000000
+
#define EXYNOS4_PA_HSMMC(x) (0x12510000 + ((x) * 0x10000))
#define EXYNOS4_PA_SATA 0x12560000
@@ -142,6 +145,8 @@
#define S5P_PA_FIMC3 EXYNOS4_PA_FIMC3
#define S5P_PA_MIPI_CSIS0 EXYNOS4_PA_MIPI_CSIS0
#define S5P_PA_MIPI_CSIS1 EXYNOS4_PA_MIPI_CSIS1
+#define S5P_PA_FIMD0 EXYNOS4_PA_FIMD0
+#define S5P_PA_FIMD1 EXYNOS4_PA_FIMD1
#define S5P_PA_ONENAND EXYNOS4_PA_ONENAND
#define S5P_PA_ONENAND_DMA EXYNOS4_PA_ONENAND_DMA
#define S5P_PA_SDRAM EXYNOS4_PA_SDRAM
--
1.7.4.1
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RE-SEND] [PATCH 2/4] ARM: EXYNOS4: Add platform device and helper functions for FIMD
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
2011-06-10 8:15 ` [RE-SEND] [PATCH 1/4] ARM: EXYNOS4: Add FIMD resource definition Anand Kumar N
@ 2011-06-10 8:15 ` Anand Kumar N
2011-06-11 12:24 ` Sylwester Nawrocki
2011-06-10 8:15 ` [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD Anand Kumar N
` (3 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Anand Kumar N @ 2011-06-10 8:15 UTC (permalink / raw)
To: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, anand.kn
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds platform device s5p_device_fimd0 for EXYNOS4 FIMD0.
EXYNOS4 has two FIMDs(FIMD0, FIMD1). FIMD1 will be added later.
Some definitions used to enable EXYNOS4 FIMD0 are added.
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/Kconfig | 9 ++++
arch/arm/mach-exynos4/Makefile | 1 +
arch/arm/mach-exynos4/cpu.c | 4 +-
arch/arm/mach-exynos4/include/mach/regs-fb.h | 21 ++++++++
arch/arm/mach-exynos4/setup-fimd0-24bpp.c | 47 ++++++++++++++++++
arch/arm/plat-s5p/Kconfig | 5 ++
arch/arm/plat-s5p/Makefile | 1 +
arch/arm/plat-s5p/dev-fimd0.c | 67 ++++++++++++++++++++++++++
arch/arm/plat-samsung/include/plat/devs.h | 1 +
arch/arm/plat-samsung/include/plat/fb-core.h | 15 ++++++
arch/arm/plat-samsung/include/plat/fb.h | 14 +++++
11 files changed, 184 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-exynos4/include/mach/regs-fb.h
create mode 100644 arch/arm/mach-exynos4/setup-fimd0-24bpp.c
create mode 100644 arch/arm/plat-s5p/dev-fimd0.c
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 1435fc3..9161920 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -25,6 +25,11 @@ config EXYNOS4_DEV_AHCI
help
Compile in platform device definitions for AHCI
+config EXYNOS4_SETUP_FIMD0_24BPP
+ bool
+ help
+ Common setup code for FIMD0 with a 24bpp RGB display helper.
+
config EXYNOS4_DEV_PD
bool
help
@@ -103,6 +108,7 @@ menu "EXYNOS4 Machines"
config MACH_SMDKC210
bool "SMDKC210"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
@@ -112,6 +118,7 @@ config MACH_SMDKC210
select S3C_DEV_HSMMC3
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
+ select EXYNOS4_SETUP_FIMD0_24BPP
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_SDHCI
help
@@ -130,6 +137,7 @@ config MACH_SMDKV310
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
+ select EXYNOS4_SETUP_FIMD0_24BPP
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_KEYPAD
select EXYNOS4_SETUP_SDHCI
@@ -139,6 +147,7 @@ config MACH_SMDKV310
config MACH_ARMLEX4210
bool "ARMLEX4210"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 60fe5ec..aa4d1f4 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
+obj-$(CONFIG_EXYNOS4_SETUP_FIMD0_24BPP) += setup-fimd0-24bpp.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C2) += setup-i2c2.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C3) += setup-i2c3.o
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 1196f39..67a3b3c 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -19,9 +19,10 @@
#include <plat/cpu.h>
#include <plat/clock.h>
+#include <plat/devs.h>
+#include <plat/fb-core.h>
#include <plat/exynos4.h>
#include <plat/sdhci.h>
-#include <plat/devs.h>
#include <plat/fimc-core.h>
#include <mach/regs-irq.h>
@@ -137,6 +138,7 @@ void __init exynos4_map_io(void)
s3c_fimc_setname(1, "exynos4-fimc");
s3c_fimc_setname(2, "exynos4-fimc");
s3c_fimc_setname(3, "exynos4-fimc");
+ s5p_fb_setname(0, "exynos4-fb"); /* FIMD0 */
}
void __init exynos4_init_clocks(int xtal)
diff --git a/arch/arm/mach-exynos4/include/mach/regs-fb.h b/arch/arm/mach-exynos4/include/mach/regs-fb.h
new file mode 100644
index 0000000..f320105
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/regs-fb.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2010 Ben Dooks <ben-linux@fluff.org>
+ *
+ * Dummy framebuffer to allow build for the moment.
+ *
+ * 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.
+*/
+
+#ifndef __ASM_ARCH_MACH_REGS_FB_H
+#define __ASM_ARCH_MACH_REGS_FB_H __FILE__
+
+#include <plat/regs-fb-v4.h>
+
+static inline unsigned int s3c_fb_pal_reg(unsigned int window, int reg)
+{
+ return 0x2400 + (window * 256 * 4) + reg;
+}
+
+#endif /* __ASM_ARCH_MACH_REGS_FB_H */
diff --git a/arch/arm/mach-exynos4/setup-fimd0-24bpp.c b/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
new file mode 100644
index 0000000..18fa84a
--- /dev/null
+++ b/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
@@ -0,0 +1,47 @@
+/* linux/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Base s5pv210 setup information for 24bpp LCD framebuffer
+ *
+ * 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.
+*/
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+
+#include <plat/fb.h>
+#include <plat/gpio-cfg.h>
+
+#include <mach/regs-clock.h>
+#include <mach/regs-fb.h>
+#include <mach/map.h>
+
+void exynos4_fimd0_gpio_setup_24bpp(void)
+{
+ unsigned int reg = 0;
+
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF0(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF1(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF2(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF3(0), 4, S3C_GPIO_SFN(2));
+
+ /*
+ * Set DISPLAY_CONTROL register for Display path selection.
+ *
+ * DISPLAY_CONTROL[1:0]
+ * ---------------------
+ * 00 | MIE
+ * 01 | MDINE
+ * 10 | FIMD : selected
+ * 11 | FIMD
+ */
+ reg = __raw_readl(S3C_VA_SYS + 0x0210);
+ reg |= (1 << 1);
+ __raw_writel(reg, S3C_VA_SYS + 0x0210);
+}
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index e98f5c5..46de16e 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -70,6 +70,11 @@ config S5P_DEV_FIMC3
help
Compile in platform device definitions for FIMC controller 3
+config S5P_DEV_FIMD0
+ bool
+ help
+ Compile in platform device definitions for FIMD controller 0
+
config S5P_DEV_ONENAND
bool
help
diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
index e234cc4..eec7e24 100644
--- a/arch/arm/plat-s5p/Makefile
+++ b/arch/arm/plat-s5p/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_S5P_DEV_FIMC0) += dev-fimc0.o
obj-$(CONFIG_S5P_DEV_FIMC1) += dev-fimc1.o
obj-$(CONFIG_S5P_DEV_FIMC2) += dev-fimc2.o
obj-$(CONFIG_S5P_DEV_FIMC3) += dev-fimc3.o
+obj-$(CONFIG_S5P_DEV_FIMD0) += dev-fimd0.o
obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o
obj-$(CONFIG_S5P_DEV_CSIS0) += dev-csis0.o
obj-$(CONFIG_S5P_DEV_CSIS1) += dev-csis1.o
diff --git a/arch/arm/plat-s5p/dev-fimd0.c b/arch/arm/plat-s5p/dev-fimd0.c
new file mode 100644
index 0000000..b332b5f
--- /dev/null
+++ b/arch/arm/plat-s5p/dev-fimd0.c
@@ -0,0 +1,67 @@
+/* linux/arch/arm/plat-s5p/dev-fimd0.c
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Core file for Samsung Display Controller (FIMD) driver
+ *
+ * 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.
+*/
+
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/platform_device.h>
+#include <linux/fb.h>
+#include <linux/gfp.h>
+#include <linux/dma-mapping.h>
+
+#include <mach/irqs.h>
+#include <mach/map.h>
+
+#include <plat/fb.h>
+#include <plat/devs.h>
+#include <plat/cpu.h>
+
+static struct resource s5p_fimd0_resource[] = {
+ [0] = {
+ .start = S5P_PA_FIMD0,
+ .end = S5P_PA_FIMD0 + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_FIMD0_VSYNC,
+ .end = IRQ_FIMD0_VSYNC,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = IRQ_FIMD0_FIFO,
+ .end = IRQ_FIMD0_FIFO,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .start = IRQ_FIMD0_SYSTEM,
+ .end = IRQ_FIMD0_SYSTEM,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 fimd0_dmamask = DMA_BIT_MASK(32);
+
+struct platform_device s5p_device_fimd0 = {
+ .name = "s5p-fb",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s5p_fimd0_resource),
+ .resource = s5p_fimd0_resource,
+ .dev = {
+ .dma_mask = &fimd0_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+void __init s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd)
+{
+ s3c_set_platdata(pd, sizeof(struct s3c_fb_platdata),
+ &s5p_device_fimd0);
+}
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 4af108f..370bd2b 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -45,6 +45,7 @@ extern struct platform_device s3c64xx_device_ac97;
extern struct platform_device s3c_device_ts;
extern struct platform_device s3c_device_fb;
+extern struct platform_device s5p_device_fimd0;
extern struct platform_device s3c_device_ohci;
extern struct platform_device s3c_device_lcd;
extern struct platform_device s3c_device_wdt;
diff --git a/arch/arm/plat-samsung/include/plat/fb-core.h b/arch/arm/plat-samsung/include/plat/fb-core.h
index bca383e..6abcbf1 100644
--- a/arch/arm/plat-samsung/include/plat/fb-core.h
+++ b/arch/arm/plat-samsung/include/plat/fb-core.h
@@ -26,4 +26,19 @@ static inline void s3c_fb_setname(char *name)
#endif
}
+/* Re-define device name depending on support. */
+static inline void s5p_fb_setname(int id, char *name)
+{
+ switch (id) {
+#ifdef CONFIG_S5P_DEV_FIMD0
+ case 0:
+ s5p_device_fimd0.name = name;
+ break;
+#endif
+ default:
+ printk(KERN_ERR "%s: invalid device id(%d)\n", __func__, id);
+ break;
+ }
+}
+
#endif /* __ASM_PLAT_FB_CORE_H */
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index cb3ca3a..b341c7a 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -74,6 +74,14 @@ struct s3c_fb_platdata {
extern void s3c_fb_set_platdata(struct s3c_fb_platdata *pd);
/**
+ * s5p_fimd0_set_platdata() - Setup the FB device with platform data.
+ * @pd: The platform data to set. The data is copied from the passed structure
+ * so the machine data can mark the data __initdata so that any unused
+ * machines will end up dumping their data at runtime.
+ */
+extern void s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd);
+
+/**
* s3c64xx_fb_gpio_setup_24bpp() - S3C64XX setup function for 24bpp LCD
*
* Initialise the GPIO for an 24bpp LCD display on the RGB interface.
@@ -94,4 +102,10 @@ extern void s5pc100_fb_gpio_setup_24bpp(void);
*/
extern void s5pv210_fb_gpio_setup_24bpp(void);
+/**
+ * exynos4_fimd0_gpio_setup_24bpp() - S5PV310/S5PC210 setup function for 24bpp LCD0
+ *
+ * Initialise the GPIO for an 24bpp LCD display on the RGB interface 0.
+ */
+extern void exynos4_fimd0_gpio_setup_24bpp(void);
#endif /* __PLAT_S3C_FB_H */
--
1.7.4.1
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [RE-SEND] [PATCH 2/4] ARM: EXYNOS4: Add platform device and helper functions for FIMD
2011-06-10 8:15 ` [RE-SEND] [PATCH 2/4] ARM: EXYNOS4: Add platform device and helper functions for FIMD Anand Kumar N
@ 2011-06-11 12:24 ` Sylwester Nawrocki
0 siblings, 0 replies; 18+ messages in thread
From: Sylwester Nawrocki @ 2011-06-11 12:24 UTC (permalink / raw)
To: Anand Kumar N
Cc: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, ben-linux, Sylwester Nawrocki
Hello,
On 06/10/2011 10:15 AM, Anand Kumar N wrote:
> From: Jonghun Han<jonghun.han@samsung.com>
>
> This patch adds platform device s5p_device_fimd0 for EXYNOS4 FIMD0.
> EXYNOS4 has two FIMDs(FIMD0, FIMD1). FIMD1 will be added later.
> Some definitions used to enable EXYNOS4 FIMD0 are added.
>
> Signed-off-by: Jonghun Han<jonghun.han@samsung.com>
> Signed-off-by: Jingoo Han<jg1.han@samsung.com>
> ---
> arch/arm/mach-exynos4/Kconfig | 9 ++++
> arch/arm/mach-exynos4/Makefile | 1 +
> arch/arm/mach-exynos4/cpu.c | 4 +-
> arch/arm/mach-exynos4/include/mach/regs-fb.h | 21 ++++++++
> arch/arm/mach-exynos4/setup-fimd0-24bpp.c | 47 ++++++++++++++++++
> arch/arm/plat-s5p/Kconfig | 5 ++
> arch/arm/plat-s5p/Makefile | 1 +
> arch/arm/plat-s5p/dev-fimd0.c | 67 ++++++++++++++++++++++++++
> arch/arm/plat-samsung/include/plat/devs.h | 1 +
> arch/arm/plat-samsung/include/plat/fb-core.h | 15 ++++++
> arch/arm/plat-samsung/include/plat/fb.h | 14 +++++
> 11 files changed, 184 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/include/mach/regs-fb.h
> create mode 100644 arch/arm/mach-exynos4/setup-fimd0-24bpp.c
> create mode 100644 arch/arm/plat-s5p/dev-fimd0.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 1435fc3..9161920 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -25,6 +25,11 @@ config EXYNOS4_DEV_AHCI
> help
> Compile in platform device definitions for AHCI
>
> +config EXYNOS4_SETUP_FIMD0_24BPP
> + bool
> + help
> + Common setup code for FIMD0 with a 24bpp RGB display helper.
> +
> config EXYNOS4_DEV_PD
> bool
> help
> @@ -103,6 +108,7 @@ menu "EXYNOS4 Machines"
> config MACH_SMDKC210
> bool "SMDKC210"
> select CPU_EXYNOS4210
> + select S5P_DEV_FIMD0
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_I2C1
> @@ -112,6 +118,7 @@ config MACH_SMDKC210
> select S3C_DEV_HSMMC3
> select EXYNOS4_DEV_PD
> select EXYNOS4_DEV_SYSMMU
> + select EXYNOS4_SETUP_FIMD0_24BPP
> select EXYNOS4_SETUP_I2C1
> select EXYNOS4_SETUP_SDHCI
> help
> @@ -130,6 +137,7 @@ config MACH_SMDKV310
> select SAMSUNG_DEV_KEYPAD
> select EXYNOS4_DEV_PD
> select EXYNOS4_DEV_SYSMMU
> + select EXYNOS4_SETUP_FIMD0_24BPP
> select EXYNOS4_SETUP_I2C1
> select EXYNOS4_SETUP_KEYPAD
> select EXYNOS4_SETUP_SDHCI
> @@ -139,6 +147,7 @@ config MACH_SMDKV310
> config MACH_ARMLEX4210
> bool "ARMLEX4210"
> select CPU_EXYNOS4210
> + select S5P_DEV_FIMD0
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 60fe5ec..aa4d1f4 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
> obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
>
> obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
> +obj-$(CONFIG_EXYNOS4_SETUP_FIMD0_24BPP) += setup-fimd0-24bpp.o
Why do we need a separate file for particular configuration ?
Wouldn't it be better to just make it setup-fimd.c ?
> obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
> obj-$(CONFIG_EXYNOS4_SETUP_I2C2) += setup-i2c2.o
> obj-$(CONFIG_EXYNOS4_SETUP_I2C3) += setup-i2c3.o
> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
> index 1196f39..67a3b3c 100644
> --- a/arch/arm/mach-exynos4/cpu.c
> +++ b/arch/arm/mach-exynos4/cpu.c
> @@ -19,9 +19,10 @@
>
> #include<plat/cpu.h>
> #include<plat/clock.h>
> +#include<plat/devs.h>
> +#include<plat/fb-core.h>
> #include<plat/exynos4.h>
> #include<plat/sdhci.h>
> -#include<plat/devs.h>
> #include<plat/fimc-core.h>
>
> #include<mach/regs-irq.h>
> @@ -137,6 +138,7 @@ void __init exynos4_map_io(void)
> s3c_fimc_setname(1, "exynos4-fimc");
> s3c_fimc_setname(2, "exynos4-fimc");
> s3c_fimc_setname(3, "exynos4-fimc");
> + s5p_fb_setname(0, "exynos4-fb"); /* FIMD0 */
> }
>
> void __init exynos4_init_clocks(int xtal)
> diff --git a/arch/arm/mach-exynos4/include/mach/regs-fb.h b/arch/arm/mach-exynos4/include/mach/regs-fb.h
> new file mode 100644
> index 0000000..f320105
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/include/mach/regs-fb.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright 2010 Ben Dooks<ben-linux@fluff.org>
Shouldn't there be also Ben's signed-off-by on this patch?
He is not even added at Cc.
> + *
> + * Dummy framebuffer to allow build for the moment.
> + *
> + * 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.
> +*/
> +
> +#ifndef __ASM_ARCH_MACH_REGS_FB_H
> +#define __ASM_ARCH_MACH_REGS_FB_H __FILE__
> +
> +#include<plat/regs-fb-v4.h>
> +
> +static inline unsigned int s3c_fb_pal_reg(unsigned int window, int reg)
> +{
> + return 0x2400 + (window * 256 * 4) + reg;
> +}
> +
> +#endif /* __ASM_ARCH_MACH_REGS_FB_H */
> diff --git a/arch/arm/mach-exynos4/setup-fimd0-24bpp.c b/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
> new file mode 100644
> index 0000000..18fa84a
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
> @@ -0,0 +1,47 @@
> +/* linux/arch/arm/mach-exynos4/setup-fimd0-24bpp.c
> + *
> + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
2009-2011 ?
> + * http://www.samsung.com
> + *
> + * Base s5pv210 setup information for 24bpp LCD framebuffer
s/s5pv210/Exynos4 ?
> + *
> + * 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.
> +*/
> +
> +#include<linux/kernel.h>
> +#include<linux/types.h>
> +#include<linux/fb.h>
> +#include<linux/gpio.h>
> +
> +#include<plat/fb.h>
> +#include<plat/gpio-cfg.h>
> +
> +#include<mach/regs-clock.h>
> +#include<mach/regs-fb.h>
> +#include<mach/map.h>
> +
> +void exynos4_fimd0_gpio_setup_24bpp(void)
> +{
> + unsigned int reg = 0;
> +
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPF0(0), 8, S3C_GPIO_SFN(2));
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPF1(0), 8, S3C_GPIO_SFN(2));
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPF2(0), 8, S3C_GPIO_SFN(2));
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPF3(0), 4, S3C_GPIO_SFN(2));
> +
> + /*
> + * Set DISPLAY_CONTROL register for Display path selection.
> + *
> + * DISPLAY_CONTROL[1:0]
> + * ---------------------
> + * 00 | MIE
> + * 01 | MDINE
> + * 10 | FIMD : selected
> + * 11 | FIMD
> + */
> + reg = __raw_readl(S3C_VA_SYS + 0x0210);
> + reg |= (1<< 1);
> + __raw_writel(reg, S3C_VA_SYS + 0x0210);
> +}
> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
> index e98f5c5..46de16e 100644
> --- a/arch/arm/plat-s5p/Kconfig
> +++ b/arch/arm/plat-s5p/Kconfig
> @@ -70,6 +70,11 @@ config S5P_DEV_FIMC3
> help
> Compile in platform device definitions for FIMC controller 3
>
> +config S5P_DEV_FIMD0
> + bool
> + help
> + Compile in platform device definitions for FIMD controller 0
> +
> config S5P_DEV_ONENAND
> bool
> help
> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
> index e234cc4..eec7e24 100644
> --- a/arch/arm/plat-s5p/Makefile
> +++ b/arch/arm/plat-s5p/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_S5P_DEV_FIMC0) += dev-fimc0.o
> obj-$(CONFIG_S5P_DEV_FIMC1) += dev-fimc1.o
> obj-$(CONFIG_S5P_DEV_FIMC2) += dev-fimc2.o
> obj-$(CONFIG_S5P_DEV_FIMC3) += dev-fimc3.o
> +obj-$(CONFIG_S5P_DEV_FIMD0) += dev-fimd0.o
> obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o
> obj-$(CONFIG_S5P_DEV_CSIS0) += dev-csis0.o
> obj-$(CONFIG_S5P_DEV_CSIS1) += dev-csis1.o
> diff --git a/arch/arm/plat-s5p/dev-fimd0.c b/arch/arm/plat-s5p/dev-fimd0.c
> new file mode 100644
> index 0000000..b332b5f
> --- /dev/null
> +++ b/arch/arm/plat-s5p/dev-fimd0.c
> @@ -0,0 +1,67 @@
> +/* linux/arch/arm/plat-s5p/dev-fimd0.c
> + *
> + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
2009-2011 ?
> + * http://www.samsung.com
> + *
> + * Core file for Samsung Display Controller (FIMD) driver
> + *
> + * 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.
> +*/
> +
> +#include<linux/kernel.h>
> +#include<linux/string.h>
> +#include<linux/platform_device.h>
> +#include<linux/fb.h>
> +#include<linux/gfp.h>
> +#include<linux/dma-mapping.h>
> +
> +#include<mach/irqs.h>
> +#include<mach/map.h>
> +
> +#include<plat/fb.h>
> +#include<plat/devs.h>
> +#include<plat/cpu.h>
> +
> +static struct resource s5p_fimd0_resource[] = {
> + [0] = {
> + .start = S5P_PA_FIMD0,
> + .end = S5P_PA_FIMD0 + SZ_32K - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = IRQ_FIMD0_VSYNC,
> + .end = IRQ_FIMD0_VSYNC,
> + .flags = IORESOURCE_IRQ,
> + },
> + [2] = {
> + .start = IRQ_FIMD0_FIFO,
> + .end = IRQ_FIMD0_FIFO,
> + .flags = IORESOURCE_IRQ,
> + },
> + [3] = {
> + .start = IRQ_FIMD0_SYSTEM,
> + .end = IRQ_FIMD0_SYSTEM,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static u64 fimd0_dmamask = DMA_BIT_MASK(32);
> +
> +struct platform_device s5p_device_fimd0 = {
> + .name = "s5p-fb",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(s5p_fimd0_resource),
> + .resource = s5p_fimd0_resource,
> + .dev = {
> + .dma_mask =&fimd0_dmamask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + },
> +};
> +
> +void __init s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd)
> +{
> + s3c_set_platdata(pd, sizeof(struct s3c_fb_platdata),
> + &s5p_device_fimd0);
> +}
Is this function really needed? It just calls s3c_set_platdata() and
s5p_device_fimd0 is global anyway.
> diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
> index 4af108f..370bd2b 100644
> --- a/arch/arm/plat-samsung/include/plat/devs.h
> +++ b/arch/arm/plat-samsung/include/plat/devs.h
> @@ -45,6 +45,7 @@ extern struct platform_device s3c64xx_device_ac97;
> extern struct platform_device s3c_device_ts;
>
> extern struct platform_device s3c_device_fb;
> +extern struct platform_device s5p_device_fimd0;
> extern struct platform_device s3c_device_ohci;
> extern struct platform_device s3c_device_lcd;
> extern struct platform_device s3c_device_wdt;
> diff --git a/arch/arm/plat-samsung/include/plat/fb-core.h b/arch/arm/plat-samsung/include/plat/fb-core.h
> index bca383e..6abcbf1 100644
> --- a/arch/arm/plat-samsung/include/plat/fb-core.h
> +++ b/arch/arm/plat-samsung/include/plat/fb-core.h
> @@ -26,4 +26,19 @@ static inline void s3c_fb_setname(char *name)
> #endif
> }
>
> +/* Re-define device name depending on support. */
> +static inline void s5p_fb_setname(int id, char *name)
> +{
> + switch (id) {
> +#ifdef CONFIG_S5P_DEV_FIMD0
> + case 0:
> + s5p_device_fimd0.name = name;
> + break;
> +#endif
> + default:
> + printk(KERN_ERR "%s: invalid device id(%d)\n", __func__, id);
> + break;
> + }
> +}
> +
> #endif /* __ASM_PLAT_FB_CORE_H */
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
> index cb3ca3a..b341c7a 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -74,6 +74,14 @@ struct s3c_fb_platdata {
> extern void s3c_fb_set_platdata(struct s3c_fb_platdata *pd);
>
> /**
> + * s5p_fimd0_set_platdata() - Setup the FB device with platform data.
> + * @pd: The platform data to set. The data is copied from the passed structure
> + * so the machine data can mark the data __initdata so that any unused
> + * machines will end up dumping their data at runtime.
> + */
> +extern void s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd);
No need for "extern" in function declaration.
> +
> +/**
> * s3c64xx_fb_gpio_setup_24bpp() - S3C64XX setup function for 24bpp LCD
> *
> * Initialise the GPIO for an 24bpp LCD display on the RGB interface.
> @@ -94,4 +102,10 @@ extern void s5pc100_fb_gpio_setup_24bpp(void);
> */
> extern void s5pv210_fb_gpio_setup_24bpp(void);
>
> +/**
> + * exynos4_fimd0_gpio_setup_24bpp() - S5PV310/S5PC210 setup function for 24bpp LCD0
> + *
> + * Initialise the GPIO for an 24bpp LCD display on the RGB interface 0.
> + */
> +extern void exynos4_fimd0_gpio_setup_24bpp(void);
Ditto.
> #endif /* __PLAT_S3C_FB_H */
Regards,
Sylwester
^ permalink raw reply [flat|nested] 18+ messages in thread
* [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
2011-06-10 8:15 ` [RE-SEND] [PATCH 1/4] ARM: EXYNOS4: Add FIMD resource definition Anand Kumar N
2011-06-10 8:15 ` [RE-SEND] [PATCH 2/4] ARM: EXYNOS4: Add platform device and helper functions for FIMD Anand Kumar N
@ 2011-06-10 8:15 ` Anand Kumar N
2011-06-11 16:40 ` Sylwester Nawrocki
2011-06-10 8:15 ` [RE-SEND] [PATCH 4/4] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd Anand Kumar N
` (2 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Anand Kumar N @ 2011-06-10 8:15 UTC (permalink / raw)
To: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, anand.kn
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4.
The clk_type is added to distinguish clock type in it and lcd_clk is added
in structure s3c_fb to calculate divider for lcd panel.
Please refer to below diagrams about clocks of FIMD IP. FIMD driver needs
two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel clock
can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before EXYNOS4. But from
EXYNOS4, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
FIMD_CLK_TYPE0:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'lcd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | +-+-+ +----+ |
|u|-+ | | +-+core| |
|x| | | | +----+ |
|/ | | | |\ |
| | +-|m| +---+ |
| | |u|--+div| |
+------+---|x| +---+ |
2.SCLK_FIMD | |/ | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
FIMD_CLK_TYPE1:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'fimd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | +-+-+ +----+ |
|u|-+ | | +-+core| |
|x| | | | +----+ |
|/ | | | |\ |
| | +-|m| +---+ |
| | |u|--+div| |
+------+---|x| +---+ |
2.SCLK_FIMD | |/ | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
FIMD_CLK_TYPE1:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'fimd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | | +----+ |
|u|-+ | +---+core| |
|x| | | +----+ |
|/ | | |
| | +---+ |
| | +--+div| |
+------+-----+ +---+ |
2.SCLK_FIMD | | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
FIMD_CLK_TYPE1:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'fimd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | | +----+ |
|u|-+ | +---+core| |
|x| | | +----+ |
|/ | | |
| | +---+ |
| | +--+div| |
+------+-----+ +---+ |
2.SCLK_FIMD | | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
Change-Id: I52b69285151dc4d67bc0be5d0020ca49ba58f911
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/Kconfig | 2 +-
drivers/video/s3c-fb.c | 131 ++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 117 insertions(+), 16 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 549b960..963b8b7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2027,7 +2027,7 @@ config FB_TMIO_ACCELL
config FB_S3C
tristate "Samsung S3C framebuffer support"
- depends on FB && S3C_DEV_FB
+ depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..7445740 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -66,6 +66,9 @@ struct s3c_fb;
#define VIDOSD_C(win, variant) (OSD_BASE(win, variant) + 0x08)
#define VIDOSD_D(win, variant) (OSD_BASE(win, variant) + 0x0C)
+#define FIMD_CLK_TYPE0 0
+#define FIMD_CLK_TYPE1 1
+
/**
* struct s3c_fb_variant - fb variant information
* @is_2443: Set if S3C2443/S3C2416 style hardware.
@@ -98,6 +101,7 @@ struct s3c_fb_variant {
unsigned int has_prtcon:1;
unsigned int has_shadowcon:1;
+ unsigned int clk_type:1;
};
/**
@@ -185,7 +189,8 @@ struct s3c_fb_vsync {
* @slock: The spinlock protection for this data sturcture.
* @dev: The device that we bound to, for printing, etc.
* @regs_res: The resource we claimed for the IO registers.
- * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
+ * @bus_clk: The clk (hclk) feeding FIMD IP core.
+ * @lcd_clk: The clk (sclk) feeding our interface and possibly pixclk.
* @regs: The mapped hardware registers.
* @variant: Variant information for this hardware.
* @enabled: A bitmask of enabled hardware windows.
@@ -200,6 +205,7 @@ struct s3c_fb {
struct device *dev;
struct resource *regs_res;
struct clk *bus_clk;
+ struct clk *lcd_clk;
void __iomem *regs;
struct s3c_fb_variant variant;
@@ -337,7 +343,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
*/
static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
{
- unsigned long clk = clk_get_rate(sfb->bus_clk);
+ unsigned long clk = clk_get_rate(sfb->lcd_clk);
unsigned long long tmp;
unsigned int result;
@@ -1315,8 +1321,10 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
struct s3c_fb_platdata *pd;
struct s3c_fb *sfb;
struct resource *res;
+ struct clk *mout_mpll = NULL;
int win;
int ret = 0;
+ u32 rate = 134000000;
platid = platform_get_device_id(pdev);
fbdrv = (struct s3c_fb_driverdata *)platid->driver_data;
@@ -1346,22 +1354,62 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
spin_lock_init(&sfb->slock);
- sfb->bus_clk = clk_get(dev, "lcd");
- if (IS_ERR(sfb->bus_clk)) {
- dev_err(dev, "failed to get bus clock\n");
- ret = PTR_ERR(sfb->bus_clk);
+ switch (sfb->variant.clk_type) {
+ case FIMD_CLK_TYPE0:
+ sfb->bus_clk = clk_get(dev, "lcd");
+ if (IS_ERR(sfb->bus_clk)) {
+ dev_err(dev, "failed to get bus clock\n");
+ ret = PTR_ERR(sfb->bus_clk);
+ goto err_sfb;
+ }
+
+ clk_enable(sfb->bus_clk);
+
+ sfb->lcd_clk = sfb->bus_clk;
+ break;
+
+ case FIMD_CLK_TYPE1:
+ sfb->bus_clk = clk_get(&pdev->dev, "fimd");
+ if (IS_ERR(sfb->bus_clk)) {
+ dev_err(&pdev->dev, "failed to get clock for fimd\n");
+ ret = PTR_ERR(sfb->bus_clk);
+ goto err_sfb;
+ }
+ clk_enable(sfb->bus_clk);
+
+ sfb->lcd_clk = clk_get(&pdev->dev, "sclk_fimd");
+ if (IS_ERR(sfb->lcd_clk)) {
+ dev_err(&pdev->dev, "failed to get sclk for fimd\n");
+ ret = PTR_ERR(sfb->lcd_clk);
+ goto err_bus_clk;
+ }
+
+ mout_mpll = clk_get(&pdev->dev, "mout_mpll");
+ if (IS_ERR(mout_mpll)) {
+ dev_err(&pdev->dev, "failed to get mout_mpll\n");
+ ret = PTR_ERR(mout_mpll);
+ goto err_lcd_clk;
+ }
+ clk_set_parent(sfb->lcd_clk, mout_mpll);
+ clk_put(mout_mpll);
+
+ clk_set_rate(sfb->lcd_clk, rate);
+ clk_enable(sfb->lcd_clk);
+ dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", rate);
+ break;
+
+ default:
+ dev_err(dev, "failed to enable clock for FIMD\n");
goto err_sfb;
}
- clk_enable(sfb->bus_clk);
-
pm_runtime_enable(sfb->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "failed to find registers\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs_res = request_mem_region(res->start, resource_size(res),
@@ -1369,7 +1417,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
if (!sfb->regs_res) {
dev_err(dev, "failed to claim register region\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs = ioremap(res->start, resource_size(res));
@@ -1451,9 +1499,15 @@ err_ioremap:
err_req_region:
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-err_clk:
- clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
+err_lcd_clk:
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+
+err_bus_clk:
+ if (sfb->variant.clk_type != FIMD_CLK_TYPE0) {
+ clk_disable(sfb->bus_clk);
+ clk_put(sfb->bus_clk);
+ }
err_sfb:
kfree(sfb);
@@ -1482,8 +1536,20 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
iounmap(sfb->regs);
- clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
+ switch (sfb->variant.clk_type) {
+ case FIMD_CLK_TYPE1:
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ /* fall through to default case */
+ case FIMD_CLK_TYPE0:
+ clk_disable(sfb->bus_clk);
+ clk_put(sfb->bus_clk);
+ break;
+ default:
+ dev_err(sfb->dev, "invalid clock type(%d)\n",
+ sfb->variant.clk_type);
+ break;
+ }
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
@@ -1513,6 +1579,7 @@ static int s3c_fb_suspend(struct device *dev)
}
clk_disable(sfb->bus_clk);
+
return 0;
}
@@ -1825,6 +1892,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
.win[4] = &s3c_fb_data_s5p_wins[4],
};
+static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+
+ .has_shadowcon = 1,
+ .clk_type = FIMD_CLK_TYPE1,
+ },
+ .win[0] = &s3c_fb_data_64xx_wins[0],
+ .win[1] = &s3c_fb_data_64xx_wins[1],
+ .win[2] = &s3c_fb_data_64xx_wins[2],
+ .win[3] = &s3c_fb_data_64xx_wins[3],
+ .win[4] = &s3c_fb_data_64xx_wins[4],
+};
+
/* S3C2443/S3C2416 style hardware */
static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
.variant = {
@@ -1872,6 +1970,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "s5pv210-fb",
.driver_data = (unsigned long)&s3c_fb_data_s5pv210,
}, {
+ .name = "exynos4-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos4,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
},
--
1.7.4.1
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-10 8:15 ` [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD Anand Kumar N
@ 2011-06-11 16:40 ` Sylwester Nawrocki
2011-06-15 6:14 ` Thomas Abraham
0 siblings, 1 reply; 18+ messages in thread
From: Sylwester Nawrocki @ 2011-06-11 16:40 UTC (permalink / raw)
To: Anand Kumar N
Cc: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, Sylwester Nawrocki, linux
Hello,
On 06/10/2011 10:15 AM, Anand Kumar N wrote:
> From: Jonghun Han<jonghun.han@samsung.com>
>
> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4.
> The clk_type is added to distinguish clock type in it and lcd_clk is added
> in structure s3c_fb to calculate divider for lcd panel.
>
> Please refer to below diagrams about clocks of FIMD IP. FIMD driver needs
these ascii diagrams are quite bulky, how about moving them to the cover
letter message ?
> two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel clock
> can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before EXYNOS4. But from
> EXYNOS4, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
>
> FIMD_CLK_TYPE0:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'lcd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | +-+-+ +----+ |
> |u|-+ | | +-+core| |
> |x| | | | +----+ |
> |/ | | | |\ |
> | | +-|m| +---+ |
> | | |u|--+div| |
> +------+---|x| +---+ |
> 2.SCLK_FIMD | |/ | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
>
> FIMD_CLK_TYPE1:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'fimd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | +-+-+ +----+ |
> |u|-+ | | +-+core| |
> |x| | | | +----+ |
> |/ | | | |\ |
> | | +-|m| +---+ |
> | | |u|--+div| |
> +------+---|x| +---+ |
> 2.SCLK_FIMD | |/ | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
>
> FIMD_CLK_TYPE1:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'fimd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | | +----+ |
> |u|-+ | +---+core| |
> |x| | | +----+ |
> |/ | | |
> | | +---+ |
> | | +--+div| |
> +------+-----+ +---+ |
> 2.SCLK_FIMD | | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
>
> FIMD_CLK_TYPE1:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'fimd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | | +----+ |
> |u|-+ | +---+core| |
> |x| | | +----+ |
> |/ | | |
> | | +---+ |
> | | +--+div| |
> +------+-----+ +---+ |
> 2.SCLK_FIMD | | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
Sorry, the 2 above diagrams look almost identical to me.
Is there really any difference between them (except double line
above)?
>
> Change-Id: I52b69285151dc4d67bc0be5d0020ca49ba58f911
What is this (gerrit?) change ID here for ?
> Signed-off-by: Jonghun Han<jonghun.han@samsung.com>
> Signed-off-by: Jingoo Han<jg1.han@samsung.com>
> ---
> drivers/video/Kconfig | 2 +-
> drivers/video/s3c-fb.c | 131 ++++++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 117 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 549b960..963b8b7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2027,7 +2027,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB&& S3C_DEV_FB
> + depends on FB&& (S3C_DEV_FB || S5P_DEV_FIMD0)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 0352afa..7445740 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -66,6 +66,9 @@ struct s3c_fb;
> #define VIDOSD_C(win, variant) (OSD_BASE(win, variant) + 0x08)
> #define VIDOSD_D(win, variant) (OSD_BASE(win, variant) + 0x0C)
>
> +#define FIMD_CLK_TYPE0 0
> +#define FIMD_CLK_TYPE1 1
> +
> /**
> * struct s3c_fb_variant - fb variant information
> * @is_2443: Set if S3C2443/S3C2416 style hardware.
> @@ -98,6 +101,7 @@ struct s3c_fb_variant {
>
> unsigned int has_prtcon:1;
> unsigned int has_shadowcon:1;
> + unsigned int clk_type:1;
Would "has_pixclk_mux" instead of clk_type make more sense ?
If so then you could get rid of the above FIMD_CLK_TYPE* definitions.
> };
>
> /**
> @@ -185,7 +189,8 @@ struct s3c_fb_vsync {
> * @slock: The spinlock protection for this data sturcture.
> * @dev: The device that we bound to, for printing, etc.
> * @regs_res: The resource we claimed for the IO registers.
> - * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
> + * @bus_clk: The clk (hclk) feeding FIMD IP core.
> + * @lcd_clk: The clk (sclk) feeding our interface and possibly pixclk.
> * @regs: The mapped hardware registers.
> * @variant: Variant information for this hardware.
> * @enabled: A bitmask of enabled hardware windows.
> @@ -200,6 +205,7 @@ struct s3c_fb {
> struct device *dev;
> struct resource *regs_res;
> struct clk *bus_clk;
> + struct clk *lcd_clk;
> void __iomem *regs;
> struct s3c_fb_variant variant;
>
> @@ -337,7 +343,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
> */
> static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
> {
> - unsigned long clk = clk_get_rate(sfb->bus_clk);
> + unsigned long clk = clk_get_rate(sfb->lcd_clk);
> unsigned long long tmp;
> unsigned int result;
>
> @@ -1315,8 +1321,10 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> struct s3c_fb_platdata *pd;
> struct s3c_fb *sfb;
> struct resource *res;
> + struct clk *mout_mpll = NULL;
> int win;
> int ret = 0;
> + u32 rate = 134000000;
How about making this the variant property ? Or is it same for all SoCs?
>
> platid = platform_get_device_id(pdev);
> fbdrv = (struct s3c_fb_driverdata *)platid->driver_data;
> @@ -1346,22 +1354,62 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>
> spin_lock_init(&sfb->slock);
>
> - sfb->bus_clk = clk_get(dev, "lcd");
> - if (IS_ERR(sfb->bus_clk)) {
> - dev_err(dev, "failed to get bus clock\n");
> - ret = PTR_ERR(sfb->bus_clk);
> + switch (sfb->variant.clk_type) {
> + case FIMD_CLK_TYPE0:
> + sfb->bus_clk = clk_get(dev, "lcd");
> + if (IS_ERR(sfb->bus_clk)) {
> + dev_err(dev, "failed to get bus clock\n");
> + ret = PTR_ERR(sfb->bus_clk);
> + goto err_sfb;
> + }
> +
> + clk_enable(sfb->bus_clk);
> +
> + sfb->lcd_clk = sfb->bus_clk;
> + break;
> +
> + case FIMD_CLK_TYPE1:
> + sfb->bus_clk = clk_get(&pdev->dev, "fimd");
> + if (IS_ERR(sfb->bus_clk)) {
> + dev_err(&pdev->dev, "failed to get clock for fimd\n");
> + ret = PTR_ERR(sfb->bus_clk);
> + goto err_sfb;
> + }
> + clk_enable(sfb->bus_clk);
> +
> + sfb->lcd_clk = clk_get(&pdev->dev, "sclk_fimd");
> + if (IS_ERR(sfb->lcd_clk)) {
> + dev_err(&pdev->dev, "failed to get sclk for fimd\n");
> + ret = PTR_ERR(sfb->lcd_clk);
> + goto err_bus_clk;
> + }
> +
> + mout_mpll = clk_get(&pdev->dev, "mout_mpll");
> + if (IS_ERR(mout_mpll)) {
> + dev_err(&pdev->dev, "failed to get mout_mpll\n");
> + ret = PTR_ERR(mout_mpll);
> + goto err_lcd_clk;
> + }
> + clk_set_parent(sfb->lcd_clk, mout_mpll);
> + clk_put(mout_mpll);
> +
> + clk_set_rate(sfb->lcd_clk, rate);
> + clk_enable(sfb->lcd_clk);
Please, do not hard code parent clocks in the driver.
> + dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", rate);
> + break;
> +
> + default:
> + dev_err(dev, "failed to enable clock for FIMD\n");
> goto err_sfb;
> }
I'm not really a clock expert, but IMHO there is an issue in Thomas'
migration to clkdev proposal [1] that the device clock connection ids
(con_id) and clock names related to them are identical. Mostly it works
but in situation like this one it is not possible to remap two clocks
of different names onto a single connection id.
For instance, looking at arch/arm/mach-omap2/clock3xxx_data.c:
static struct clk i2c3_fck = {
.name = "i2c3_fck",
^^^^^^^^^^
.ops = &clkops_omap2_dflt_wait,
.parent = &core_96m_fck,
...
};
static struct clk i2c2_fck = {
.name = "i2c2_fck",
^^^^^^^^^^^
.ops = &clkops_omap2_dflt_wait,
...
};
static struct omap_clk omap3xxx_clks[] = {
...
CLK("omap_i2c.3", "fck", &i2c3_fck, CK_3XXX),
^^^^^^^^^^^^^^^^^
CLK("omap_i2c.2", "fck", &i2c2_fck, CK_3XXX),
^^^^^^^^^^^^^^^^^
...
Different clock names (i2c3_fck, i2c3_fck,..) are mapped to single
unified id (fck), which the driver only needs to care about.
The name is common across H/W instances and also SoC variants.
So it doesn't have to be driver's business to resolve clock differences.
The same (con_id) name can be used on distinct SoC versionproviding similar/same peripheral device IP.
It's aeasy to figure out by just comparing omap3xxx_clks[] and
omap44xx_clks arrays.
That said I wouldn't go for a "devname" in struct clk, just create
an additional table matching device names, con_id and struct clk and
use it while registering clk_lookup items into clkdev.
>
> - clk_enable(sfb->bus_clk);
> -
> pm_runtime_enable(sfb->dev);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(dev, "failed to find registers\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs_res = request_mem_region(res->start, resource_size(res),
> @@ -1369,7 +1417,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> if (!sfb->regs_res) {
> dev_err(dev, "failed to claim register region\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs = ioremap(res->start, resource_size(res));
> @@ -1451,9 +1499,15 @@ err_ioremap:
> err_req_region:
> release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
>
> -err_clk:
> - clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
> +err_lcd_clk:
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> +
> +err_bus_clk:
> + if (sfb->variant.clk_type != FIMD_CLK_TYPE0) {
> + clk_disable(sfb->bus_clk);
> + clk_put(sfb->bus_clk);
> + }
>
> err_sfb:
> kfree(sfb);
> @@ -1482,8 +1536,20 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
>
> iounmap(sfb->regs);
>
> - clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
> + switch (sfb->variant.clk_type) {
> + case FIMD_CLK_TYPE1:
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> + /* fall through to default case */
> + case FIMD_CLK_TYPE0:
> + clk_disable(sfb->bus_clk);
> + clk_put(sfb->bus_clk);
> + break;
> + default:
Considering clk_type data type this is unreachable code.
> + dev_err(sfb->dev, "invalid clock type(%d)\n",
> + sfb->variant.clk_type);
> + break;
> + }
...
--
Regards,
Sylwester
[1] http://www.spinics.net/lists/arm-kernel/msg127901.html
http://www.spinics.net/lists/arm-kernel/msg127907.html
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-11 16:40 ` Sylwester Nawrocki
@ 2011-06-15 6:14 ` Thomas Abraham
2011-06-15 8:01 ` Sylwester Nawrocki
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Abraham @ 2011-06-15 6:14 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Anand Kumar N, lethal, kgene.kim, linux-samsung-soc, jg1.han,
jonghun.han, thomas.ab, Sylwester Nawrocki, linux
Hi Sylwester,
On 11 June 2011 22:10, Sylwester Nawrocki <snjw23@gmail.com> wrote:
> Hello,
>
> On 06/10/2011 10:15 AM, Anand Kumar N wrote:
>> From: Jonghun Han<jonghun.han@samsung.com>
>>
>> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4.
>> The clk_type is added to distinguish clock type in it and lcd_clk is added
>> in structure s3c_fb to calculate divider for lcd panel.
<snip>
>> + default:
>> + dev_err(dev, "failed to enable clock for FIMD\n");
>> goto err_sfb;
>> }
>
> I'm not really a clock expert, but IMHO there is an issue in Thomas'
> migration to clkdev proposal [1] that the device clock connection ids
> (con_id) and clock names related to them are identical. Mostly it works
> but in situation like this one it is not possible to remap two clocks
> of different names onto a single connection id.
>
> For instance, looking at arch/arm/mach-omap2/clock3xxx_data.c:
>
> static struct clk i2c3_fck = {
> .name = "i2c3_fck",
> ^^^^^^^^^^
> .ops = &clkops_omap2_dflt_wait,
> .parent = &core_96m_fck,
> ...
> };
> static struct clk i2c2_fck = {
> .name = "i2c2_fck",
> ^^^^^^^^^^^
> .ops = &clkops_omap2_dflt_wait,
> ...
> };
>
> static struct omap_clk omap3xxx_clks[] = {
> ...
> CLK("omap_i2c.3", "fck", &i2c3_fck, CK_3XXX),
> ^^^^^^^^^^^^^^^^^
> CLK("omap_i2c.2", "fck", &i2c2_fck, CK_3XXX),
> ^^^^^^^^^^^^^^^^^
> ...
>
> Different clock names (i2c3_fck, i2c3_fck,..) are mapped to single
> unified id (fck), which the driver only needs to care about.
> The name is common across H/W instances and also SoC variants.
> So it doesn't have to be driver's business to resolve clock differences.
>
> The same (con_id) name can be used on distinct SoC versionproviding similar/same peripheral device IP.
> It's aeasy to figure out by just comparing omap3xxx_clks[] and
> omap44xx_clks arrays.
Sorry, I am not quite sure if I understand the problem here. For
instance, all Samsung SoC's and each instance of i2c device in a SoC,
use the same con_id for the i2c 'struct clock' instance. The con_id is
'i2c'. The i2c driver uses the con_id 'i2c' to lookup the 'struct
clock' instance and it works for all Samsung SoC's and all instances
of i2c device in the SoC.
Is your point different than what I understand? Please help.
Thanks,
Thomas.
>
> That said I wouldn't go for a "devname" in struct clk, just create
> an additional table matching device names, con_id and struct clk and
> use it while registering clk_lookup items into clkdev.
>
>>
>> - clk_enable(sfb->bus_clk);
>> -
>> pm_runtime_enable(sfb->dev);
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> if (!res) {
>> dev_err(dev, "failed to find registers\n");
>> ret = -ENOENT;
>> - goto err_clk;
>> + goto err_lcd_clk;
>> }
>>
>> sfb->regs_res = request_mem_region(res->start, resource_size(res),
>> @@ -1369,7 +1417,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>> if (!sfb->regs_res) {
>> dev_err(dev, "failed to claim register region\n");
>> ret = -ENOENT;
>> - goto err_clk;
>> + goto err_lcd_clk;
>> }
>>
>> sfb->regs = ioremap(res->start, resource_size(res));
>> @@ -1451,9 +1499,15 @@ err_ioremap:
>> err_req_region:
>> release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
>>
>> -err_clk:
>> - clk_disable(sfb->bus_clk);
>> - clk_put(sfb->bus_clk);
>> +err_lcd_clk:
>> + clk_disable(sfb->lcd_clk);
>> + clk_put(sfb->lcd_clk);
>> +
>> +err_bus_clk:
>> + if (sfb->variant.clk_type != FIMD_CLK_TYPE0) {
>> + clk_disable(sfb->bus_clk);
>> + clk_put(sfb->bus_clk);
>> + }
>>
>> err_sfb:
>> kfree(sfb);
>> @@ -1482,8 +1536,20 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
>>
>> iounmap(sfb->regs);
>>
>> - clk_disable(sfb->bus_clk);
>> - clk_put(sfb->bus_clk);
>> + switch (sfb->variant.clk_type) {
>> + case FIMD_CLK_TYPE1:
>> + clk_disable(sfb->lcd_clk);
>> + clk_put(sfb->lcd_clk);
>> + /* fall through to default case */
>> + case FIMD_CLK_TYPE0:
>> + clk_disable(sfb->bus_clk);
>> + clk_put(sfb->bus_clk);
>> + break;
>> + default:
>
> Considering clk_type data type this is unreachable code.
>
>> + dev_err(sfb->dev, "invalid clock type(%d)\n",
>> + sfb->variant.clk_type);
>> + break;
>> + }
> ...
>
> --
> Regards,
> Sylwester
>
> [1] http://www.spinics.net/lists/arm-kernel/msg127901.html
> http://www.spinics.net/lists/arm-kernel/msg127907.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 6:14 ` Thomas Abraham
@ 2011-06-15 8:01 ` Sylwester Nawrocki
2011-06-15 8:06 ` Russell King - ARM Linux
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Sylwester Nawrocki @ 2011-06-15 8:01 UTC (permalink / raw)
To: Thomas Abraham
Cc: Sylwester Nawrocki, Anand Kumar N, lethal, kgene.kim,
linux-samsung-soc, jg1.han, jonghun.han, thomas.ab, linux
Hi Thomas,
On 06/15/2011 08:14 AM, Thomas Abraham wrote:
> Hi Sylwester,
>
> On 11 June 2011 22:10, Sylwester Nawrocki <snjw23@gmail.com> wrote:
>> Hello,
>>
>> On 06/10/2011 10:15 AM, Anand Kumar N wrote:
>>> From: Jonghun Han<jonghun.han@samsung.com>
>>>
>>> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4.
>>> The clk_type is added to distinguish clock type in it and lcd_clk is added
>>> in structure s3c_fb to calculate divider for lcd panel.
>
> <snip>
>
>>> + default:
>>> + dev_err(dev, "failed to enable clock for FIMD\n");
>>> goto err_sfb;
>>> }
>>
>> I'm not really a clock expert, but IMHO there is an issue in Thomas'
>> migration to clkdev proposal [1] that the device clock connection ids
>> (con_id) and clock names related to them are identical. Mostly it works
>> but in situation like this one it is not possible to remap two clocks
>> of different names onto a single connection id.
>>
>> For instance, looking at arch/arm/mach-omap2/clock3xxx_data.c:
>>
>> static struct clk i2c3_fck = {
>> .name = "i2c3_fck",
>> ^^^^^^^^^^
>> .ops = &clkops_omap2_dflt_wait,
>> .parent = &core_96m_fck,
>> ...
>> };
>> static struct clk i2c2_fck = {
>> .name = "i2c2_fck",
>> ^^^^^^^^^^^
>> .ops = &clkops_omap2_dflt_wait,
>> ...
>> };
>>
>> static struct omap_clk omap3xxx_clks[] = {
>> ...
>> CLK("omap_i2c.3", "fck", &i2c3_fck, CK_3XXX),
>> ^^^^^^^^^^^^^^^^^
>> CLK("omap_i2c.2", "fck", &i2c2_fck, CK_3XXX),
>> ^^^^^^^^^^^^^^^^^
>> ...
>>
>> Different clock names (i2c3_fck, i2c3_fck,..) are mapped to single
>> unified id (fck), which the driver only needs to care about.
>> The name is common across H/W instances and also SoC variants.
>> So it doesn't have to be driver's business to resolve clock differences.
>>
>> The same (con_id) name can be used on distinct SoC version providing
>> similar/same peripheral device IP.
>> It's aeasy to figure out by just comparing omap3xxx_clks[] and
>> omap44xx_clks arrays.
>
> Sorry, I am not quite sure if I understand the problem here. For
> instance, all Samsung SoC's and each instance of i2c device in a SoC,
> use the same con_id for the i2c 'struct clock' instance. The con_id is
> 'i2c'. The i2c driver uses the con_id 'i2c' to lookup the 'struct
> clock' instance and it works for all Samsung SoC's and all instances
> of i2c device in the SoC.
>
> Is your point different than what I understand? Please help.
I appreciate your efforts in converting all Samsung platforms to clkdev.
With the above I2C example I was trying to illustrate the additional
level of indirection that is present in case of OMAP clock mappings,
comparing to your implementation.
As long as IP clock names are same among various SoC there is no issue
at all with your clk lookup approach.
But this is already not the case with LCD controller IP.
On S3C series the IP bus clock name is "lcd" while on S5P series it's "fimd".
There is a common framebuffer driver for S3C and S5P SoCs.
It just does not look right to me to be adding in the driver switch/case
for the clock names. I thought clkdev is meant to resolve such differences.
Then how it would be possible to map those clocks into single con_id with
your patches? E.g.
S3C clk | S5P clk | con_id
---------------------------
"lcd" | "fimd" | "lcd" ?
I believe there will come more differences like that in the future.
Regards,
Sylwester
> Thanks,
> Thomas.
>>
>> That said I wouldn't go for a "devname" in struct clk, just create
>> an additional table matching device names, con_id and struct clk and
>> use it while registering clk_lookup items into clkdev.
...
>> [1] http://www.spinics.net/lists/arm-kernel/msg127901.html
>> http://www.spinics.net/lists/arm-kernel/msg127907.html
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 8:01 ` Sylwester Nawrocki
@ 2011-06-15 8:06 ` Russell King - ARM Linux
2011-06-15 9:43 ` Marek Szyprowski
2011-06-15 10:04 ` Thomas Abraham
2 siblings, 0 replies; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-06-15 8:06 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Thomas Abraham, Sylwester Nawrocki, Anand Kumar N, lethal,
kgene.kim, linux-samsung-soc, jg1.han, jonghun.han, thomas.ab
On Wed, Jun 15, 2011 at 10:01:29AM +0200, Sylwester Nawrocki wrote:
> With the above I2C example I was trying to illustrate the additional
> level of indirection that is present in case of OMAP clock mappings,
> comparing to your implementation.
> As long as IP clock names are same among various SoC there is no issue
> at all with your clk lookup approach.
> But this is already not the case with LCD controller IP.
> On S3C series the IP bus clock name is "lcd" while on S5P series it's "fimd".
> There is a common framebuffer driver for S3C and S5P SoCs.
> It just does not look right to me to be adding in the driver switch/case
> for the clock names. I thought clkdev is meant to resolve such differences.
You are not mistaken. clk_get() takes the device and a connection id
to identify the clock _on_ _that_ _device_ to separate individual clock
inputs on the _same_ _device_. It does not take a platform specific
clock name.
The clock API was created long ago to remove this kind of crud from
drivers and keep it local to the platforms. The problem is people seem
to like this crud.
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 8:01 ` Sylwester Nawrocki
2011-06-15 8:06 ` Russell King - ARM Linux
@ 2011-06-15 9:43 ` Marek Szyprowski
2011-06-15 10:04 ` Thomas Abraham
2 siblings, 0 replies; 18+ messages in thread
From: Marek Szyprowski @ 2011-06-15 9:43 UTC (permalink / raw)
To: Sylwester Nawrocki, 'Thomas Abraham'
Cc: 'Sylwester Nawrocki', 'Anand Kumar N', lethal,
kgene.kim, linux-samsung-soc, jg1.han, jonghun.han, thomas.ab,
linux
Hello,
On Wednesday, June 15, 2011 10:01 AM Sylwester Nawrocki wrote:
(snipped)
> > Sorry, I am not quite sure if I understand the problem here. For
> > instance, all Samsung SoC's and each instance of i2c device in a SoC,
> > use the same con_id for the i2c 'struct clock' instance. The con_id is
> > 'i2c'. The i2c driver uses the con_id 'i2c' to lookup the 'struct
> > clock' instance and it works for all Samsung SoC's and all instances
> > of i2c device in the SoC.
> >
> > Is your point different than what I understand? Please help.
>
> I appreciate your efforts in converting all Samsung platforms to clkdev.
>
> With the above I2C example I was trying to illustrate the additional
> level of indirection that is present in case of OMAP clock mappings,
> comparing to your implementation.
> As long as IP clock names are same among various SoC there is no issue
> at all with your clk lookup approach.
> But this is already not the case with LCD controller IP.
> On S3C series the IP bus clock name is "lcd" while on S5P series it's
> "fimd".
> There is a common framebuffer driver for S3C and S5P SoCs.
> It just does not look right to me to be adding in the driver switch/case
> for the clock names. I thought clkdev is meant to resolve such differences.
>
> Then how it would be possible to map those clocks into single con_id with
> your patches? E.g.
>
> S3C clk | S5P clk | con_id
> ---------------------------
> "lcd" | "fimd" | "lcd" ?
>
> I believe there will come more differences like that in the future.
Actually the problem is rather theoretical one. AFAIR in the old days the
s3c-fb driver initially got merged with 'lcd' clock name for unknown reasons.
The documentation always used 'fimd' name, even for S3C case. However, it
was easier to rename 'fimd' clock name to 'lcd' in the platform code (for
s5pc110 and s5pv210) than to get patches merged to unmaintained framebuffer
subsystem to get it renamed to 'fimd' in the driver.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 8:01 ` Sylwester Nawrocki
2011-06-15 8:06 ` Russell King - ARM Linux
2011-06-15 9:43 ` Marek Szyprowski
@ 2011-06-15 10:04 ` Thomas Abraham
2011-06-15 10:08 ` Russell King - ARM Linux
2 siblings, 1 reply; 18+ messages in thread
From: Thomas Abraham @ 2011-06-15 10:04 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Sylwester Nawrocki, Anand Kumar N, lethal, kgene.kim,
linux-samsung-soc, jg1.han, jonghun.han, thomas.ab, linux
On 15 June 2011 13:31, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> Hi Thomas,
>
> On 06/15/2011 08:14 AM, Thomas Abraham wrote:
>> Hi Sylwester,
>>
>> On 11 June 2011 22:10, Sylwester Nawrocki <snjw23@gmail.com> wrote:
>>> Hello,
>>>
>>> On 06/10/2011 10:15 AM, Anand Kumar N wrote:
>>>> From: Jonghun Han<jonghun.han@samsung.com>
>>>>
>>>> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4.
>>>> The clk_type is added to distinguish clock type in it and lcd_clk is added
>>>> in structure s3c_fb to calculate divider for lcd panel.
<snip>
>>
>> Sorry, I am not quite sure if I understand the problem here. For
>> instance, all Samsung SoC's and each instance of i2c device in a SoC,
>> use the same con_id for the i2c 'struct clock' instance. The con_id is
>> 'i2c'. The i2c driver uses the con_id 'i2c' to lookup the 'struct
>> clock' instance and it works for all Samsung SoC's and all instances
>> of i2c device in the SoC.
>>
>> Is your point different than what I understand? Please help.
>
> I appreciate your efforts in converting all Samsung platforms to clkdev.
>
> With the above I2C example I was trying to illustrate the additional
> level of indirection that is present in case of OMAP clock mappings,
> comparing to your implementation.
> As long as IP clock names are same among various SoC there is no issue
> at all with your clk lookup approach.
> But this is already not the case with LCD controller IP.
> On S3C series the IP bus clock name is "lcd" while on S5P series it's "fimd".
> There is a common framebuffer driver for S3C and S5P SoCs.
> It just does not look right to me to be adding in the driver switch/case
> for the clock names. I thought clkdev is meant to resolve such differences.
>
> Then how it would be possible to map those clocks into single con_id with
> your patches? E.g.
>
> S3C clk | S5P clk | con_id
> ---------------------------
> "lcd" | "fimd" | "lcd" ?
Ok. Thanks for clarifying this point. In this case, maybe we could use
the clk_add_alias API. With this API, we can have a instance of clock
by name 'fimd' and then create a clkdev alias by name 'lcd' in the
machine code. The driver can then continue to lookup with 'lcd' as the
con_id.
I understand that this is just a workaround. The real problem lies in
the fact that the clock name have not been consistent across various
SoC's.
Thanks,
Thomas.
>
> I believe there will come more differences like that in the future.
>
> Regards,
> Sylwester
>
>> Thanks,
>> Thomas.
>>>
>>> That said I wouldn't go for a "devname" in struct clk, just create
>>> an additional table matching device names, con_id and struct clk and
>>> use it while registering clk_lookup items into clkdev.
> ...
>>> [1] http://www.spinics.net/lists/arm-kernel/msg127901.html
>>> http://www.spinics.net/lists/arm-kernel/msg127907.html
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 10:04 ` Thomas Abraham
@ 2011-06-15 10:08 ` Russell King - ARM Linux
2011-06-15 10:22 ` Thomas Abraham
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-06-15 10:08 UTC (permalink / raw)
To: Thomas Abraham
Cc: Sylwester Nawrocki, Sylwester Nawrocki, Anand Kumar N, lethal,
kgene.kim, linux-samsung-soc, jg1.han, jonghun.han, thomas.ab
On Wed, Jun 15, 2011 at 03:34:40PM +0530, Thomas Abraham wrote:
> Ok. Thanks for clarifying this point. In this case, maybe we could use
> the clk_add_alias API. With this API, we can have a instance of clock
> by name 'fimd' and then create a clkdev alias by name 'lcd' in the
> machine code. The driver can then continue to lookup with 'lcd' as the
> con_id.
That's additional needless complexity. If you don't embed the clk_lookup
structure in your struct clk but list out the dev/con/clk stuff separately
like OMAP does, you can easily assign the dev/con pairs to multiple
clks without hastle - and then it really doesn't matter what the clk
itself is called.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 10:08 ` Russell King - ARM Linux
@ 2011-06-15 10:22 ` Thomas Abraham
2011-06-16 15:44 ` Sylwester Nawrocki
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Abraham @ 2011-06-15 10:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sylwester Nawrocki, Sylwester Nawrocki, Anand Kumar N, lethal,
kgene.kim, linux-samsung-soc, jg1.han, jonghun.han, thomas.ab
On 15 June 2011 15:38, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Jun 15, 2011 at 03:34:40PM +0530, Thomas Abraham wrote:
>> Ok. Thanks for clarifying this point. In this case, maybe we could use
>> the clk_add_alias API. With this API, we can have a instance of clock
>> by name 'fimd' and then create a clkdev alias by name 'lcd' in the
>> machine code. The driver can then continue to lookup with 'lcd' as the
>> con_id.
>
> That's additional needless complexity. If you don't embed the clk_lookup
> structure in your struct clk but list out the dev/con/clk stuff separately
> like OMAP does, you can easily assign the dev/con pairs to multiple
> clks without hastle - and then it really doesn't matter what the clk
> itself is called.
>
Thanks for your suggestion Russell. The limitation in doing it the
OMAP way is, in all Samsung machine code, all the clock instances are
put into a array and then registered. So there is no separately named
instance for each clock to build a dev/con/clk omap-type table.
Thanks,
Thomas.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD
2011-06-15 10:22 ` Thomas Abraham
@ 2011-06-16 15:44 ` Sylwester Nawrocki
0 siblings, 0 replies; 18+ messages in thread
From: Sylwester Nawrocki @ 2011-06-16 15:44 UTC (permalink / raw)
To: Thomas Abraham
Cc: Russell King - ARM Linux, Anand Kumar N, lethal, kgene.kim,
linux-samsung-soc, jg1.han, jonghun.han, thomas.ab
On 06/15/2011 12:22 PM, Thomas Abraham wrote:
> On 15 June 2011 15:38, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> On Wed, Jun 15, 2011 at 03:34:40PM +0530, Thomas Abraham wrote:
>>> Ok. Thanks for clarifying this point. In this case, maybe we could use
>>> the clk_add_alias API. With this API, we can have a instance of clock
>>> by name 'fimd' and then create a clkdev alias by name 'lcd' in the
>>> machine code. The driver can then continue to lookup with 'lcd' as the
>>> con_id.
>>
>> That's additional needless complexity. If you don't embed the clk_lookup
>> structure in your struct clk but list out the dev/con/clk stuff separately
>> like OMAP does, you can easily assign the dev/con pairs to multiple
>> clks without hastle - and then it really doesn't matter what the clk
>> itself is called.
>>
>
> Thanks for your suggestion Russell. The limitation in doing it the
> OMAP way is, in all Samsung machine code, all the clock instances are
> put into a array and then registered. So there is no separately named
> instance for each clock to build a dev/con/clk omap-type table.
I realize it might be quite a bit of work to convert the clock tables,
perhaps some scripts/trickery could be of help here.
I'm just wondering if this won't have to be done anyway when people
make agreement about common struct clk on ARM.
However there is a little problem that there are two clock arrays in
each Samsung platform, for clock disabled and enabled by default.
Not sure yet how to handle that cleanly.
Cheers,
Sylwester
--
Sylwester Nawrocki
Samsung Poland R&D Center
^ permalink raw reply [flat|nested] 18+ messages in thread
* [RE-SEND] [PATCH 4/4] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
` (2 preceding siblings ...)
2011-06-10 8:15 ` [RE-SEND] [PATCH 3/4] s3c-fb: Add support EXYNOS4 FIMD Anand Kumar N
@ 2011-06-10 8:15 ` Anand Kumar N
2011-06-11 12:19 ` [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Sylwester Nawrocki
2011-06-14 5:10 ` Kukjin Kim
5 siblings, 0 replies; 18+ messages in thread
From: Anand Kumar N @ 2011-06-10 8:15 UTC (permalink / raw)
To: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, anand.kn
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
Change-Id: Ib89dc0fab2283c275f35e465cbfcd710ec0fef56
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/mach-smdkc210.c | 72 +++++++++++++++++++++++++++++++++
arch/arm/mach-exynos4/mach-smdkv310.c | 72 +++++++++++++++++++++++++++++++++
2 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c b/arch/arm/mach-exynos4/mach-smdkc210.c
index ac53e49..6098e15 100644
--- a/arch/arm/mach-exynos4/mach-smdkc210.c
+++ b/arch/arm/mach-exynos4/mach-smdkc210.c
@@ -9,7 +9,9 @@
*/
#include <linux/serial_core.h>
+#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/lcd.h>
#include <linux/mmc/host.h>
#include <linux/platform_device.h>
#include <linux/smsc911x.h>
@@ -19,16 +21,20 @@
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
+#include <video/platform_lcd.h>
+
#include <plat/regs-serial.h>
#include <plat/regs-srom.h>
#include <plat/exynos4.h>
#include <plat/cpu.h>
#include <plat/devs.h>
+#include <plat/fb.h>
#include <plat/sdhci.h>
#include <plat/iic.h>
#include <plat/pd.h>
#include <mach/map.h>
+#include <mach/regs-fb.h>
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -111,6 +117,68 @@ static struct s3c_sdhci_platdata smdkc210_hsmmc3_pdata __initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+ if (power) {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 1);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ /* fire nRESET on power up */
+ gpio_request(EXYNOS4_GPX0(6), "GPX0");
+
+ gpio_direction_output(EXYNOS4_GPX0(6), 1);
+ mdelay(100);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 0);
+ mdelay(10);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 1);
+ mdelay(10);
+
+ gpio_free(EXYNOS4_GPX0(6));
+ } else {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 0);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ }
+}
+
+static struct plat_lcd_data smdkc210_lcd_lte480wv_data = {
+ .set_power = lcd_lte480wv_set_power,
+};
+
+static struct platform_device smdkc210_lcd_lte480wv = {
+ .name = "platform-lcd",
+ .dev.parent = &s5p_device_fimd0.dev,
+ .dev.platform_data = &smdkc210_lcd_lte480wv_data,
+};
+
+static struct s3c_fb_pd_win smdkc210_fb_win0 = {
+ .win_mode = {
+ .left_margin = 13,
+ .right_margin = 8,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+ },
+ .max_bpp = 32,
+ .default_bpp = 24,
+};
+static struct s3c_fb_platdata smdkc210_lcd0_pdata __initdata = {
+ .win[0] = &smdkc210_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct resource smdkc210_smsc911x_resources[] = {
[0] = {
.start = EXYNOS4_PA_SROM_BANK(1),
@@ -152,6 +220,7 @@ static struct i2c_board_info i2c_devs1[] __initdata = {
};
static struct platform_device *smdkc210_devices[] __initdata = {
+ &s5p_device_fimd0,
&s3c_device_hsmmc0,
&s3c_device_hsmmc1,
&s3c_device_hsmmc2,
@@ -171,6 +240,7 @@ static struct platform_device *smdkc210_devices[] __initdata = {
&exynos4_device_pd[PD_GPS],
&exynos4_device_sysmmu,
&samsung_asoc_dma,
+ &smdkc210_lcd_lte480wv,
&smdkc210_smsc911x,
&smdkc210_pcm_device,
};
@@ -217,6 +287,8 @@ static void __init smdkc210_machine_init(void)
s3c_sdhci2_set_platdata(&smdkc210_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkc210_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(&smdkc210_lcd0_pdata);
+
platform_add_devices(smdkc210_devices, ARRAY_SIZE(smdkc210_devices));
}
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c
index 7e3ee6c..25ca91d 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -9,7 +9,9 @@
*/
#include <linux/serial_core.h>
+#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/lcd.h>
#include <linux/mmc/host.h>
#include <linux/platform_device.h>
#include <linux/smsc911x.h>
@@ -20,17 +22,21 @@
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
+#include <video/platform_lcd.h>
+
#include <plat/regs-serial.h>
#include <plat/regs-srom.h>
#include <plat/exynos4.h>
#include <plat/cpu.h>
#include <plat/devs.h>
+#include <plat/fb.h>
#include <plat/keypad.h>
#include <plat/sdhci.h>
#include <plat/iic.h>
#include <plat/pd.h>
#include <mach/map.h>
+#include <mach/regs-fb.h>
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKV310_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -113,6 +119,68 @@ static struct s3c_sdhci_platdata smdkv310_hsmmc3_pdata __initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+ if (power) {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 1);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ /* fire nRESET on power up */
+ gpio_request(EXYNOS4_GPX0(6), "GPX0");
+
+ gpio_direction_output(EXYNOS4_GPX0(6), 1);
+ mdelay(100);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 0);
+ mdelay(10);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 1);
+ mdelay(10);
+
+ gpio_free(EXYNOS4_GPX0(6));
+ } else {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 0);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ }
+}
+
+static struct plat_lcd_data smdkv310_lcd_lte480wv_data = {
+ .set_power = lcd_lte480wv_set_power,
+};
+
+static struct platform_device smdkv310_lcd_lte480wv = {
+ .name = "platform-lcd",
+ .dev.parent = &s5p_device_fimd0.dev,
+ .dev.platform_data = &smdkv310_lcd_lte480wv_data,
+};
+
+static struct s3c_fb_pd_win smdkv310_fb_win0 = {
+ .win_mode = {
+ .left_margin = 13,
+ .right_margin = 8,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+ },
+ .max_bpp = 32,
+ .default_bpp = 24,
+};
+static struct s3c_fb_platdata smdkv310_lcd0_pdata __initdata = {
+ .win[0] = &smdkv310_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct resource smdkv310_smsc911x_resources[] = {
[0] = {
.start = EXYNOS4_PA_SROM_BANK(1),
@@ -173,6 +241,7 @@ static struct i2c_board_info i2c_devs1[] __initdata = {
};
static struct platform_device *smdkv310_devices[] __initdata = {
+ &s5p_device_fimd0,
&s3c_device_hsmmc0,
&s3c_device_hsmmc1,
&s3c_device_hsmmc2,
@@ -193,6 +262,7 @@ static struct platform_device *smdkv310_devices[] __initdata = {
&exynos4_device_sysmmu,
&exynos4_device_pcm0,
&samsung_asoc_dma,
+ &smdkv310_lcd_lte480wv,
&smdkv310_smsc911x,
&smdkv310_pcm_device,
};
@@ -239,6 +309,8 @@ static void __init smdkv310_machine_init(void)
s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkv310_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
+
samsung_keypad_set_platdata(&smdkv310_keypad_data);
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
--
1.7.4.1
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
` (3 preceding siblings ...)
2011-06-10 8:15 ` [RE-SEND] [PATCH 4/4] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd Anand Kumar N
@ 2011-06-11 12:19 ` Sylwester Nawrocki
2011-06-14 2:44 ` Kyungmin Park
2011-06-14 5:10 ` Kukjin Kim
5 siblings, 1 reply; 18+ messages in thread
From: Sylwester Nawrocki @ 2011-06-11 12:19 UTC (permalink / raw)
To: Anand Kumar N
Cc: lethal, kgene.kim, linux-samsung-soc, jg1.han, jonghun.han,
thomas.ab, Sylwester Nawrocki
Hi Anand,
On 06/10/2011 10:15 AM, Anand Kumar N wrote:
> This patch series is based on the latest
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>
> This was originally submitted by Jonghun Han<jonghun.han@samsung.com>
> http://www.spinics.net/lists/arm-kernel/msg101781.html
> This patchset has been not picked up in the mainline due to the unavailibility
> of cldev lookup. So it is being re-submitted rebased to 3.0.0-rc1 and tested
> over the clkdev patches.
As far as I can see there is no functional changes in these patches comparing
to the original ones. AFAIR the idea with clkdev was to create clock to device
mapping for each SoC variant and have driver using unified clock names across
SoC variants. There is nothing close to that in your following patches.
Moreover looking at the S5PC110 datasheet only, the list of possible sclk_fimd
parent clocks is specified as "All possible clock sources". It exactly means:
XXTI, XusbXTI, SCLK_HDMI_27M, SCLK_USBPHY_0, SCLK_USBPHY_1, SCLK_HDMIPHY,
SCLK_M_PLL, SCLK_E_PLL, SCLK_V_PLL. So quite many, whereas you are trying
to forcibly use in the driver SCLK_M_PLL only. As it has been pointed out
setting FIMD clock parent should be moved away to board code/DT/bootloader,
which allows to use the driver in unchanged form in various system
configurations. Let the board designer to make decisions about the clock
configurations.
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD
2011-06-11 12:19 ` [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Sylwester Nawrocki
@ 2011-06-14 2:44 ` Kyungmin Park
0 siblings, 0 replies; 18+ messages in thread
From: Kyungmin Park @ 2011-06-14 2:44 UTC (permalink / raw)
To: Sylwester Nawrocki, Joonyoung Shim, 대인기
Cc: Anand Kumar N, lethal, kgene.kim, linux-samsung-soc, jg1.han,
jonghun.han, thomas.ab, Sylwester Nawrocki
CCed Display developers from other Samsung open source team
On Sat, Jun 11, 2011 at 9:19 PM, Sylwester Nawrocki <snjw23@gmail.com> wrote:
> Hi Anand,
>
> On 06/10/2011 10:15 AM, Anand Kumar N wrote:
>> This patch series is based on the latest
>> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>>
>> This was originally submitted by Jonghun Han<jonghun.han@samsung.com>
>> http://www.spinics.net/lists/arm-kernel/msg101781.html
>> This patchset has been not picked up in the mainline due to the unavailibility
>> of cldev lookup. So it is being re-submitted rebased to 3.0.0-rc1 and tested
>> over the clkdev patches.
>
> As far as I can see there is no functional changes in these patches comparing
> to the original ones. AFAIR the idea with clkdev was to create clock to device
> mapping for each SoC variant and have driver using unified clock names across
> SoC variants. There is nothing close to that in your following patches.
>
> Moreover looking at the S5PC110 datasheet only, the list of possible sclk_fimd
> parent clocks is specified as "All possible clock sources". It exactly means:
> XXTI, XusbXTI, SCLK_HDMI_27M, SCLK_USBPHY_0, SCLK_USBPHY_1, SCLK_HDMIPHY,
> SCLK_M_PLL, SCLK_E_PLL, SCLK_V_PLL. So quite many, whereas you are trying
> to forcibly use in the driver SCLK_M_PLL only. As it has been pointed out
> setting FIMD clock parent should be moved away to board code/DT/bootloader,
> which allows to use the driver in unchanged form in various system
> configurations. Let the board designer to make decisions about the clock
> configurations.
>
> --
> Regards,
> Sylwester
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD
2011-06-10 8:15 [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Anand Kumar N
` (4 preceding siblings ...)
2011-06-11 12:19 ` [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD Sylwester Nawrocki
@ 2011-06-14 5:10 ` Kukjin Kim
5 siblings, 0 replies; 18+ messages in thread
From: Kukjin Kim @ 2011-06-14 5:10 UTC (permalink / raw)
To: 'Anand Kumar N', lethal, linux-samsung-soc, jg1.han,
jonghun.han, thomas.ab
Anand Kumar N wrote:
>
> This patch series is based on the latest
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>
> This was originally submitted by Jonghun Han <jonghun.han@samsung.com>
> http://www.spinics.net/lists/arm-kernel/msg101781.html
> This patchset has been not picked up in the mainline due to the
unavailibility
> of cldev lookup. So it is being re-submitted rebased to 3.0.0-rc1 and
tested
> over the clkdev patches.
>
> This patch adds support FIMD(Fully Interactive Mobile Display) on S5PV310.
> The 3rd patch is update s3c-fb for it and others are for platform data.
>
> o To Kukjin Kim
> [RE-SEND][PATCH 1/4] ARM: S5PV310: Add FIMD resource definition
> [RE-SEND][PATCH 2/4] ARM: S5PV310: Add platform device and helper
functions
> for FIMD
> [RE-SEND][PATCH 4/4] ARM: S5PV310: Add platform data for S5PV310 FIMD and
> LTE480WV platform-lcd
>
> o To Paul Mundt
> [RE-SEND][PATCH 3/4] s3c-fb: Add support S5PV310 FIMD
>
Hi Anand,
Where is your "Signed-off-by"? It must be added...
In addition, what's the "Change-Id" in 3rd and 4th patches? I know what it
is.
I mean why did you add it here for mainline?...
Please make sure that your patch has no problem before submitting.
Jingoo, Jonghun do you agree with this?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply [flat|nested] 18+ messages in thread