Re: [PATCH] ARM: EXYNOS4: Add PWM backlight support on Samsung SMDKV310
Hi, Banajit.
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Banajit Goswami
> Sent: Wednesday, June 22, 2011 3:41 PM
> To: linux-samsung-soc@vger.kernel.org
> Cc: kgene@samsung.com; ben-li...@fluff.org; linux-arm-
> ker...@lists.infradead.org; Banajit Goswami
> Subject: [PATCH] ARM: EXYNOS4: Add PWM backlight support on Samsung
> SMDKV310
>
> This patch adds support for LCD backlight using PWM timer for
> Samsung SMDKV310 board.
>
> Signed-off-by: Banajit Goswami
> ---
> arch/arm/mach-exynos4/Kconfig |1 +
> arch/arm/mach-exynos4/mach-smdkv310.c | 43
> +
> 2 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 1435fc3..9ab53bc 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -128,6 +128,7 @@ config MACH_SMDKV310
> select S3C_DEV_HSMMC2
> select S3C_DEV_HSMMC3
> select SAMSUNG_DEV_KEYPAD
> + select SAMSUNG_DEV_PWM
> select EXYNOS4_DEV_PD
> select EXYNOS4_DEV_SYSMMU
> select EXYNOS4_SETUP_I2C1
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index 7e3ee6c..b097ef6 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -29,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -172,6 +174,45 @@ static struct i2c_board_info i2c_devs1[] __initdata =
> {
> {I2C_BOARD_INFO("wm8994", 0x1a),},
> };
>
> +static int smdkv310_backlight_init(struct device *dev)
> +{
> + int ret = 0;
> +
> + ret = gpio_request(EXYNOS4_GPD0(1), "Backlight");
> + if (ret) {
> + printk(KERN_ERR "failed to request GPD for PWM-OUT0\n");
> + return ret;
> + }
> +
> + /* Configure GPIO pin with EXYNOS4_GPD_0_1_TOUT_0 */
> + s3c_gpio_cfgpin(EXYNOS4_GPD0(1), S3C_GPIO_SFN(2));
> +
> + return 0;
> +}
> +
> +static void smdkv310_backlight_exit(struct device *dev)
> +{
> + s3c_gpio_cfgpin(EXYNOS4_GPD0(1), S3C_GPIO_OUTPUT);
> + gpio_free(EXYNOS4_GPD0(1));
> +}
> +
> +static struct platform_pwm_backlight_data smdkv310_backlight_data = {
> + .pwm_id = 1,
> + .max_brightness = 255,
> + .dft_brightness = 255,
> + .pwm_period_ns = 78770,
Please use 1000 as pwm_period_ns instead of 78770 as follows:
- .pwm_period_ns = 78770,
+ .pwm_period_ns = 1000,
The value '78770' makes noise related to resonance at LCD board.
I will explain how I get the value of PWM period.
The SMDK boards use LT3591 as backlight LED driver of LTE480WV LCD
According to the LT3591 datasheet, the switching frequency should
be 1MHz. So, PWM period is calculated by following formula:
PWM period = 1/switching frequency
= 1/1MHz
= 1000 ns
You can find LT3591 datasheet easily on the Internet. Please refer to it
for more information.
Good luck.
> + .init = smdkv310_backlight_init,
> + .exit = smdkv310_backlight_exit,
> +};
> +
> +static struct platform_device smdkv310_backlight_device = {
> + .name = "pwm-backlight",
> + .dev= {
> + .parent = &s3c_device_timer[1].dev,
> + .platform_data = &smdkv310_backlight_data,
> + },
> +};
> +
> static struct platform_device *smdkv310_devices[] __initdata = {
> &s3c_device_hsmmc0,
> &s3c_device_hsmmc1,
> @@ -195,6 +236,8 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
> &samsung_asoc_dma,
> &smdkv310_smsc911x,
> &smdkv310_pcm_device,
> + &s3c_device_timer[1],
> + &smdkv310_backlight_device,
> };
>
> static void __init smdkv310_smsc911x_init(void)
> --
> 1.6.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] Fixes for breakage resulting from syscore_ops patch on s3c24xx
Abdoulaye Walsimou GAYE wrote: > > Heiko Stübner wrote: > > The syscore_ops patch from Rafael J. Wysocki introduced some small > > glitches for the S3C24XX cpus resulting in compile errors. > > > > Heiko Stuebner (3): > >Fix missing struct for s3c2410_dma_chan in s3c2410_dma_suspend_chan > >Move s3c24xx_irq_syscore_ops to plat-s3c24xx/irq.c > >remove the now empty mach-s3c2410/irq.c > > > > arch/arm/mach-s3c2410/Makefile |1 - > > arch/arm/mach-s3c2410/irq.c| 34 -- > > arch/arm/plat-s3c24xx/dma.c|2 +- > > arch/arm/plat-s3c24xx/irq.c|6 ++ > > 4 files changed, 7 insertions(+), 36 deletions(-) > > delete mode 100644 arch/arm/mach-s3c2410/irq.c > > > > I submitted same patches days ago [1], but without more explanations > than "ARM: s3c24xx: fix build errors introduced by bb072c3cf21d1", so > > Acked-by : Abdoulaye Walsimou Gaye > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/117812/focus=117814 Hello Abdoulaye Walsimou Gaye, Oops, sorry that I missed your patch at that time :( I found your patch just now... As you know, I can't add your ack on this... Anyway thanks for your effort and time. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 2/5] ARM: EXYNOS4: Add FIMD resource definition
From: Jonghun Han This patch adds resource definitions for EXYNOS4 FIMD. IRQ and SFR definitions are added. Signed-off-by: Jonghun Han Signed-off-by: Jingoo Han --- 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_0COMBINER_IRQ(5, 6) #define IRQ_SYSMMU_PCIE_0 COMBINER_IRQ(5, 7) +#define IRQ_FIMD0_FIFO COMBINER_IRQ(11, 0) +#define IRQ_FIMD0_VSYNCCOMBINER_IRQ(11, 1) +#define IRQ_FIMD0_SYSTEM COMBINER_IRQ(11, 2) + +#define IRQ_FIMD1_FIFO COMBINER_IRQ(12, 0) +#define IRQ_FIMD1_VSYNCCOMBINER_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 0009e77..94006f7 100644 --- a/arch/arm/mach-exynos4/include/mach/map.h +++ b/arch/arm/mach-exynos4/include/mach/map.h @@ -93,6 +93,9 @@ #define EXYNOS4_PA_MIPI_CSIS0 0x1188 #define EXYNOS4_PA_MIPI_CSIS1 0x1189 +#define EXYNOS4_PA_FIMD0 0x11C0 +#define EXYNOS4_PA_FIMD1 0x1200 + #define EXYNOS4_PA_HSMMC(x)(0x1251 + ((x) * 0x1)) #define EXYNOS4_PA_SATA0x1256 @@ -140,6 +143,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.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 1/5] ARM: EXYNOS4: Change clock name for FIMD
This patch changes clock name for FIMD from "fimd" to "lcd".
Signed-off-by: Jingoo Han
---
arch/arm/mach-exynos4/clock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 871f9d5..12e6853 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -433,12 +433,12 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit= (1 << 3),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 0,
.enable = exynos4_clk_ip_lcd0_ctrl,
.ctrlbit= (1 << 0),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 1,
.enable = exynos4_clk_ip_lcd1_ctrl,
.ctrlbit= (1 << 0),
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
From: Jonghun Han
This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
Signed-off-by: Jonghun Han
Signed-off-by: Jingoo Han
---
arch/arm/mach-exynos4/mach-smdkc210.c | 114 +
arch/arm/mach-exynos4/mach-smdkv310.c | 114 +
2 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c
b/arch/arm/mach-exynos4/mach-smdkc210.c
index e645f7a..360a50a 100644
--- a/arch/arm/mach-exynos4/mach-smdkc210.c
+++ b/arch/arm/mach-exynos4/mach-smdkc210.c
@@ -9,26 +9,33 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
+
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
@@ -111,6 +118,69 @@ 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),
@@ -165,6 +235,8 @@ static struct platform_device *smdkc210_devices[]
__initdata = {
&exynos4_device_pd[PD_GPS],
&exynos4_device_sysmmu,
&samsung_asoc_dma,
+ &s5p_device_fimd0,
+ &smdkc210_lcd_lte480wv,
&smdkc210_smsc911x,
};
@@ -191,6 +263,44 @@ static void __init smdkc210_smsc911x_init(void)
(0x1 << S5P_SROM_BCX__TACS__SHIFT), S5P_SROM_BC1);
}
+static int __init smdkc210_fimd0_setup_clock(void)
+{
+ struct clk *sclk = NULL;
+ struct clk *mout_mpll = NULL;
+
+ u32 rate = 0;
+
+ sclk = clk_get(&s5p_device_fimd0.dev, "sclk_fimd");
+ if (IS_ERR(sclk)) {
+ printk(KERN_ERR "failed to get sclk for fimd\n");
+ goto err_clk2;
+ }
+
+ mout_mpll = clk_get(NULL, "mout_mpll");
+ if (IS_ERR(mout_mpll)) {
+ printk(KERN_ERR "failed to get mout_mpll\n");
+ goto err_clk1;
+ }
+
+ clk_set_parent(sclk, mout_mpll);
+ if (!rate)
+ rate = 13400;
+
+ clk_set_rate(sclk, rate);
+
+ clk_put(sclk);
+ clk_put(mout_mpll);
+
+ return 0;
+
+err_clk1:
+ clk_put(mout_mpll);
+err_clk2:
+ clk_put(sclk);
+
+ return -EINVAL;
+}
+
static void __init smdkc210_map_io(void)
{
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -210,7 +320,11 @@ 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_device
[PATCH V5 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD
From: Jonghun Han
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
Signed-off-by: Jingoo Han
---
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 | 15 ++
11 files changed, 185 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..8428ac7 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
@@ -120,6 +127,7 @@ config MACH_SMDKC210
config MACH_SMDKV310
bool "SMDKV310"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
@@ -130,6 +138,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
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 9babe44..778a5b0 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -19,9 +19,10 @@
#include
#include
+#include
+#include
#include
#include
-#include
#include
#include
@@ -132,6 +133,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 000..f320105
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/regs-fb.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2010 Ben Dooks
+ *
+ * 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
+
+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 000..3ca8555
--- /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-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
[PATCH V5 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4
and adds lcd clock gating support.
FIMD driver needs two clocks for FIMD IP and LCD pixel clock. Previously,
both clocks are provided by using bus clock such as HCLK. However, EXYNOS4
can not select HCLK for LCD pixel clock because the EXYNOS4 FIMD IP does not
have the CLKSEL bit of VIDCON0. So, FIMD driver should provide the lcd clock
using SCLK_FIMD as LCD pixel clock for EXYNOS4.
The driver selects enabling lcd clock according to has_clksel which means
the CLKSEL bit of VIDCON0. If there is has_clksel, the driver will not
enable the lcd clock using SCLK_FIMD because bus clock using HCLK is used
a LCD pixel clock.
Signed-off-by: Jingoo Han
---
drivers/video/Kconfig |2 +-
drivers/video/s3c-fb.c | 88 +--
2 files changed, 85 insertions(+), 5 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 4aecf21..cb0d3ea 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -81,6 +81,7 @@ struct s3c_fb;
* @palette: Address of palette memory, or 0 if none.
* @has_prtcon: Set if has PRTCON register.
* @has_shadowcon: Set if has SHADOWCON register.
+ * @has_clksel: Set if VIDCON0 register has CLKSEL bit.
*/
struct s3c_fb_variant {
unsigned intis_2443:1;
@@ -98,6 +99,7 @@ struct s3c_fb_variant {
unsigned inthas_prtcon:1;
unsigned inthas_shadowcon:1;
+ unsigned inthas_clksel:1;
};
/**
@@ -186,6 +188,7 @@ struct s3c_fb_vsync {
* @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.
+ * @lcd_clk: The clk (sclk) feeding pixclk.
* @regs: The mapped hardware registers.
* @variant: Variant information for this hardware.
* @enabled: A bitmask of enabled hardware windows.
@@ -200,6 +203,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_variantvariant;
@@ -336,10 +340,15 @@ 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;
unsigned long long tmp;
unsigned int result;
+ if (sfb->variant.has_clksel)
+ clk = clk_get_rate(sfb->bus_clk);
+ else
+ clk = clk_get_rate(sfb->lcd_clk);
+
tmp = (unsigned long long)clk;
tmp *= pixclk;
@@ -1354,13 +1363,24 @@ static int __devinit s3c_fb_probe(struct
platform_device *pdev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel) {
+ sfb->lcd_clk = clk_get(dev, "sclk_fimd");
+ if (IS_ERR(sfb->lcd_clk)) {
+ dev_err(dev, "failed to get lcd clock\n");
+ ret = PTR_ERR(sfb->lcd_clk);
+ goto err_bus_clk;
+ }
+
+ clk_enable(sfb->lcd_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),
@@ -1368,7 +1388,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));
@@ -1450,7 +1470,13 @@ err_ioremap:
err_req_region:
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-err_clk:
+err_lcd_clk:
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ }
+
+err_bus_clk:
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
@@ -1481,6 +1507,11 @@ static int __devexit s3c_fb_remove(struct
platform_device *pdev)
iounmap(sfb->regs);
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+
[PATCH V5 0/5] ARM: EXYNOS4: Add support EXYNOS4 FIMD
This patch series is based on the latest git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git This was originally submitted by Jonghun Han http://www.spinics.net/lists/arm-kernel/msg101781.html This patch adds support FIMD(Fully Interactive Mobile Display) on Exynos4. The 4th patch is update for s3c-fb and others are for platform data. v2: change clock name of exynos4 FIMD: "fimd" -> "lcd" use 'has_clksel' variable in order to distinguish FIMD version add 'lcd_clk' that can be used for only lcd pixel clock add callback 'enable_clk()' to enable parent clock 'sclk_fimd'. v3: remove the callback from the platform data structure v4: move clk_enable(sfb->lcd_clk) under the if statement v5: add clk_enable/disable(sfb->lcd_clk) to s3c_fb_runtime_suspend/resume(). o To Kukjin Kim [PATCH V5 1/5] ARM: EXYNOS4: Change clock name for FIMD [PATCH V5 2/5] ARM: EXYNOS4: Add FIMD resource definition [PATCH V5 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd o To Paul Mundt [PATCH V5 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
[PATCH] ARM: EXYNOS4: Add PWM backlight support on Samsung SMDKV310
This patch adds support for LCD backlight using PWM timer for
Samsung SMDKV310 board.
Signed-off-by: Banajit Goswami
---
arch/arm/mach-exynos4/Kconfig |1 +
arch/arm/mach-exynos4/mach-smdkv310.c | 43 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 1435fc3..9ab53bc 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -128,6 +128,7 @@ config MACH_SMDKV310
select S3C_DEV_HSMMC2
select S3C_DEV_HSMMC3
select SAMSUNG_DEV_KEYPAD
+ select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
select EXYNOS4_SETUP_I2C1
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 7e3ee6c..b097ef6 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,6 +30,7 @@
#include
#include
#include
+#include
#include
@@ -172,6 +174,45 @@ static struct i2c_board_info i2c_devs1[] __initdata = {
{I2C_BOARD_INFO("wm8994", 0x1a),},
};
+static int smdkv310_backlight_init(struct device *dev)
+{
+ int ret = 0;
+
+ ret = gpio_request(EXYNOS4_GPD0(1), "Backlight");
+ if (ret) {
+ printk(KERN_ERR "failed to request GPD for PWM-OUT0\n");
+ return ret;
+ }
+
+ /* Configure GPIO pin with EXYNOS4_GPD_0_1_TOUT_0 */
+ s3c_gpio_cfgpin(EXYNOS4_GPD0(1), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+static void smdkv310_backlight_exit(struct device *dev)
+{
+ s3c_gpio_cfgpin(EXYNOS4_GPD0(1), S3C_GPIO_OUTPUT);
+ gpio_free(EXYNOS4_GPD0(1));
+}
+
+static struct platform_pwm_backlight_data smdkv310_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 255,
+ .dft_brightness = 255,
+ .pwm_period_ns = 78770,
+ .init = smdkv310_backlight_init,
+ .exit = smdkv310_backlight_exit,
+};
+
+static struct platform_device smdkv310_backlight_device = {
+ .name = "pwm-backlight",
+ .dev= {
+ .parent = &s3c_device_timer[1].dev,
+ .platform_data = &smdkv310_backlight_data,
+ },
+};
+
static struct platform_device *smdkv310_devices[] __initdata = {
&s3c_device_hsmmc0,
&s3c_device_hsmmc1,
@@ -195,6 +236,8 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
&samsung_asoc_dma,
&smdkv310_smsc911x,
&smdkv310_pcm_device,
+ &s3c_device_timer[1],
+ &smdkv310_backlight_device,
};
static void __init smdkv310_smsc911x_init(void)
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] Exynos4 NURI: support for NTC thermistor
On Tue, Jun 21, 2011 at 7:50 PM, Mark Brown
wrote:
> On Tue, Jun 21, 2011 at 11:07:13AM +0900, MyungJoo Ham wrote:
>
>> +#include
>
> This doesn't appear to be in mainline.
Right, not just yet. I should've added comment about the patch just
being applied to "next".
I've added it as it was told to be applied to "next" in lm-sensors by
Guenter Roeck yesterday.
http://comments.gmane.org/gmane.linux.drivers.sensors/26475
Should I surround them with "#ifdef CONFIG_NTC_THERMISTOR"?
>
>> +/* NTC Thermistor */
>> +static struct platform_device nuri_ncp15wb473_thermistor;
>> +static int read_thermistor_uV(void)
>
> Blank line between these two.
>
got it.
>> +{
>> + static struct s3c_adc_client *adc;
>> + int val;
>> + s64 converted;
>> +
>> + if (!adc) {
>> + adc = s3c_adc_register(&nuri_ncp15wb473_thermistor,
>> + NULL, NULL, 0);
>> + if (IS_ERR_OR_NULL(adc)) {
>> + pr_err("%s: Cannot get adc.\n", __func__);
>> + return adc ? PTR_ERR(adc) : -ENODEV;
>> + }
>> + }
>
> Why not do this in an initcall or in the device registration? This
> looks like working around a limitation of the ntc_thermistor driver
> which should be fixed as part of a mainline merge for that.
Um... I think I can put this away to a common plat-samsung/dev-ntc.c
as I've seen many S5PC110/S5PV210/Exynos4 devices using NTC attached
to the CPU's ADC ports.
However, I won't be able to put that part into the NTC driver because
using S3C-ADC is plat-samsung specific method and NTC thermistor
itself is a general thermistor device not specific to S3C. Maybe, I
can do so after we've got a common ADC framework.
>
>> +
>> + if (IS_ERR_OR_NULL(adc))
>> + return adc ? PTR_ERR(adc) : -ENODEV;
>> +
>> + val = s3c_adc_read(adc, 6);
>> +
>> + converted = 330LL * (s64) val;
>> + converted >>= 12;
>> +
>> + pr_emerg("%s: %d -> %llduV\n", __func__, val, converted);
>
> This looks like debug that was left in by mistake.
>
Oh.. yes.. thanks. I need to remove that.
--
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] ARM: Exynos4: Universal C210 machine update
Marek Szyprowski wrote: > > Hello, > > This is a short patch series that updates device definitions for > Universal C210 board. The series is based on kgene/for-next kernel tree. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > Marek Szyprowski (3): > ARM: Exynos4: Universal_C210: add FIMC device > ARM: Exynos4: Universal_C210: add MCS Touchkey device > ARM: Exynos4: Universal_C210: add qt602240 touch screen device > > arch/arm/mach-exynos4/Kconfig |7 ++ > arch/arm/mach-exynos4/mach-universal_c210.c | 108 > +++ > 2 files changed, 115 insertions(+), 0 deletions(-) > > -- Hi Marek, OK, applied whole series. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
On Tue, Jun 21, 2011 at 4:03 PM, wrote:
> From: Praveen Paneri
>
> A generic method to initialize and exit OTG PHY which can be
> used for all the samsung SoCs.
> OTG platdata structure added in platform to pass required
> platform specific functions and data to the driver.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s5p64x0/Makefile | 1 +
> arch/arm/mach-s5p64x0/include/mach/map.h | 4 +
> arch/arm/mach-s5p64x0/setup-otg-phy.c | 89
> ++
> arch/arm/plat-s5p/include/plat/otg.h | 29 ++
> 4 files changed, 123 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/setup-otg-phy.c
> create mode 100644 arch/arm/plat-s5p/include/plat/otg.h
>
> diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
> index ae6bf6f..611fb3a 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -28,3 +28,4 @@ obj-y += dev-audio.o
> obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
>
> obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
> +obj-$(CONFIG_S3C_DEV_DWC_OTG) += setup-otg-phy.o
> diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h
> b/arch/arm/mach-s5p64x0/include/mach/map.h
> index 95c9125..717c279 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/map.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/map.h
> @@ -44,6 +44,8 @@
> #define S5P64X0_PA_SPI1 0xEC50
>
> #define S5P64X0_PA_HSOTG 0xED10
> +#define S5P64X0_PA_USB_HSPHY 0xED20
> +#define S5P64X0_VA_USB_HSPHY S3C_ADDR_CPU(0x0010)
>
> #define S5P64X0_PA_HSMMC(x) (0xED80 + ((x) * 0x10))
>
> @@ -71,6 +73,8 @@
> #define S5P_PA_TIMER S5P64X0_PA_TIMER
>
> #define SAMSUNG_PA_ADC S5P64X0_PA_ADC
> +#define S3C_PA_USB_HSOTG S5P64X0_PA_HSOTG
> +#define S3C_VA_USB_HSPHY S5P64X0_VA_USB_HSPHY
>
> /* UART */
>
> diff --git a/arch/arm/mach-s5p64x0/setup-otg-phy.c
> b/arch/arm/mach-s5p64x0/setup-otg-phy.c
> new file mode 100644
> index 000..c351554
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/setup-otg-phy.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics Co.Ltd
> + * Author: Praveen Paneri
> + * based on arch/arm/mach-exynos4/setup-usb-phy.c
> + * written by Joonyoung Shim
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct clk *otg_clk;
> +static int s5p64x0_otg_phy_init(struct platform_device *pdev)
> +{
> + int err;
> +
> + otg_clk = clk_get(&pdev->dev, "otg");
> + if (IS_ERR(otg_clk)) {
> + dev_err(&pdev->dev, "Failed to get otg clock\n");
> + return PTR_ERR(otg_clk);
> + }
> +
> + err = clk_enable(otg_clk);
> + if (err) {
> + clk_put(otg_clk);
> + return err;
> + }
> +
> + if (gpio_is_valid(S5P6440_GPN(1))) {
> + err = gpio_request(S5P6440_GPN(1), "GPN");
> + if (err)
> + printk(KERN_ERR "failed to request GPN1\n");
> + gpio_direction_output(S5P6440_GPN(1), 1);
> + }
What's the GPN(1)? I think it's board specific pins. so please replace
it at board file.
> +
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> + writel(0x0, S3C_PHYPWR); /* Power up */
> + writel(S3C_PHYCLK_CLKSEL_12M, S3C_PHYCLK);
> + writel(S3C_RSTCON_PHY, S3C_RSTCON);
> +
> + udelay(50);
> + writel(0x0, S3C_RSTCON);
> + udelay(50);
> +
> + return 0;
> +}
> +
> +static int s5p64x0_otg_phy_exit(struct platform_device *pdev)
> +{
> + writel(readl(S3C_PHYPWR)|(0x1F<<1), S3C_PHYPWR);
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> +
> + gpio_free(S5P6440_GPN(1));
ditto
> +
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
> +
> + return 0;
> +}
> +
> +int s5p_usb_phy_init(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_init(pdev);
> +
> + return -EINVAL;
> +}
> +
> +int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_exit(pdev);
> +
> + return -EINVAL;
> +}
> diff --git a/arch/arm/plat-s5p/include/plat/otg.h
> b/arch/arm/plat-s5p/include/plat/otg.h
> new file mode 100644
> index 000..3111dcc
> --- /dev/null
> +++ b/arch/arm/
[PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
From: Jonghun Han
This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
Signed-off-by: Jonghun Han
Signed-off-by: Jingoo Han
---
arch/arm/mach-exynos4/mach-smdkc210.c | 114 +
arch/arm/mach-exynos4/mach-smdkv310.c | 114 +
2 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c
b/arch/arm/mach-exynos4/mach-smdkc210.c
index e645f7a..360a50a 100644
--- a/arch/arm/mach-exynos4/mach-smdkc210.c
+++ b/arch/arm/mach-exynos4/mach-smdkc210.c
@@ -9,26 +9,33 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
+
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
@@ -111,6 +118,69 @@ 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),
@@ -165,6 +235,8 @@ static struct platform_device *smdkc210_devices[]
__initdata = {
&exynos4_device_pd[PD_GPS],
&exynos4_device_sysmmu,
&samsung_asoc_dma,
+ &s5p_device_fimd0,
+ &smdkc210_lcd_lte480wv,
&smdkc210_smsc911x,
};
@@ -191,6 +263,44 @@ static void __init smdkc210_smsc911x_init(void)
(0x1 << S5P_SROM_BCX__TACS__SHIFT), S5P_SROM_BC1);
}
+static int __init smdkc210_fimd0_setup_clock(void)
+{
+ struct clk *sclk = NULL;
+ struct clk *mout_mpll = NULL;
+
+ u32 rate = 0;
+
+ sclk = clk_get(&s5p_device_fimd0.dev, "sclk_fimd");
+ if (IS_ERR(sclk)) {
+ printk(KERN_ERR "failed to get sclk for fimd\n");
+ goto err_clk2;
+ }
+
+ mout_mpll = clk_get(NULL, "mout_mpll");
+ if (IS_ERR(mout_mpll)) {
+ printk(KERN_ERR "failed to get mout_mpll\n");
+ goto err_clk1;
+ }
+
+ clk_set_parent(sclk, mout_mpll);
+ if (!rate)
+ rate = 13400;
+
+ clk_set_rate(sclk, rate);
+
+ clk_put(sclk);
+ clk_put(mout_mpll);
+
+ return 0;
+
+err_clk1:
+ clk_put(mout_mpll);
+err_clk2:
+ clk_put(sclk);
+
+ return -EINVAL;
+}
+
static void __init smdkc210_map_io(void)
{
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -210,7 +320,11 @@ 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_device
[PATCH V4 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4
and adds lcd clock gating support.
FIMD driver needs two clocks for FIMD IP and LCD pixel clock. Previously,
both clocks are provided by using bus clock such as HCLK. However, EXYNOS4
can not select HCLK for LCD pixel clock because the EXYNOS4 FIMD IP does not
have the CLKSEL bit of VIDCON0. So, FIMD driver should provide the lcd clock
using SCLK_FIMD as LCD pixel clock for EXYNOS4.
The driver selects enabling lcd clock according to has_clksel which means
the CLKSEL bit of VIDCON0. If there is has_clksel, the driver will not
enable the lcd clock using SCLK_FIMD because bus clock using HCLK is used
a LCD pixel clock.
Signed-off-by: Jingoo Han
---
drivers/video/Kconfig |2 +-
drivers/video/s3c-fb.c | 82 +--
2 files changed, 79 insertions(+), 5 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 4aecf21..d480452 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -81,6 +81,7 @@ struct s3c_fb;
* @palette: Address of palette memory, or 0 if none.
* @has_prtcon: Set if has PRTCON register.
* @has_shadowcon: Set if has SHADOWCON register.
+ * @has_clksel: Set if VIDCON0 register has CLKSEL bit.
*/
struct s3c_fb_variant {
unsigned intis_2443:1;
@@ -98,6 +99,7 @@ struct s3c_fb_variant {
unsigned inthas_prtcon:1;
unsigned inthas_shadowcon:1;
+ unsigned inthas_clksel:1;
};
/**
@@ -186,6 +188,7 @@ struct s3c_fb_vsync {
* @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.
+ * @lcd_clk: The clk (sclk) feeding pixclk.
* @regs: The mapped hardware registers.
* @variant: Variant information for this hardware.
* @enabled: A bitmask of enabled hardware windows.
@@ -200,6 +203,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_variantvariant;
@@ -336,10 +340,15 @@ 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;
unsigned long long tmp;
unsigned int result;
+ if (sfb->variant.has_clksel)
+ clk = clk_get_rate(sfb->bus_clk);
+ else
+ clk = clk_get_rate(sfb->lcd_clk);
+
tmp = (unsigned long long)clk;
tmp *= pixclk;
@@ -1354,13 +1363,24 @@ static int __devinit s3c_fb_probe(struct
platform_device *pdev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel) {
+ sfb->lcd_clk = clk_get(dev, "sclk_fimd");
+ if (IS_ERR(sfb->lcd_clk)) {
+ dev_err(dev, "failed to get lcd clock\n");
+ ret = PTR_ERR(sfb->lcd_clk);
+ goto err_bus_clk;
+ }
+
+ clk_enable(sfb->lcd_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),
@@ -1368,7 +1388,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));
@@ -1450,7 +1470,13 @@ err_ioremap:
err_req_region:
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-err_clk:
+err_lcd_clk:
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ }
+
+err_bus_clk:
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
@@ -1481,6 +1507,11 @@ static int __devexit s3c_fb_remove(struct
platform_device *pdev)
iounmap(sfb->regs);
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+
[PATCH V4 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD
From: Jonghun Han
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
Signed-off-by: Jingoo Han
---
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 | 15 ++
11 files changed, 185 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..8428ac7 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
@@ -120,6 +127,7 @@ config MACH_SMDKC210
config MACH_SMDKV310
bool "SMDKV310"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
@@ -130,6 +138,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
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 9babe44..778a5b0 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -19,9 +19,10 @@
#include
#include
+#include
+#include
#include
#include
-#include
#include
#include
@@ -132,6 +133,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 000..f320105
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/regs-fb.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2010 Ben Dooks
+ *
+ * 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
+
+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 000..3ca8555
--- /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-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
[PATCH V4 2/5] ARM: EXYNOS4: Add FIMD resource definition
From: Jonghun Han This patch adds resource definitions for EXYNOS4 FIMD. IRQ and SFR definitions are added. Signed-off-by: Jonghun Han Signed-off-by: Jingoo Han --- 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_0COMBINER_IRQ(5, 6) #define IRQ_SYSMMU_PCIE_0 COMBINER_IRQ(5, 7) +#define IRQ_FIMD0_FIFO COMBINER_IRQ(11, 0) +#define IRQ_FIMD0_VSYNCCOMBINER_IRQ(11, 1) +#define IRQ_FIMD0_SYSTEM COMBINER_IRQ(11, 2) + +#define IRQ_FIMD1_FIFO COMBINER_IRQ(12, 0) +#define IRQ_FIMD1_VSYNCCOMBINER_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 0009e77..94006f7 100644 --- a/arch/arm/mach-exynos4/include/mach/map.h +++ b/arch/arm/mach-exynos4/include/mach/map.h @@ -93,6 +93,9 @@ #define EXYNOS4_PA_MIPI_CSIS0 0x1188 #define EXYNOS4_PA_MIPI_CSIS1 0x1189 +#define EXYNOS4_PA_FIMD0 0x11C0 +#define EXYNOS4_PA_FIMD1 0x1200 + #define EXYNOS4_PA_HSMMC(x)(0x1251 + ((x) * 0x1)) #define EXYNOS4_PA_SATA0x1256 @@ -140,6 +143,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.1
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Wednesday 22 June 2011 08:01 AM, MyungJoo Ham wrote: On Tue, Jun 21, 2011 at 2:33 PM, Tushar Behera wrote: On Tuesday 21 June 2011 07:37 AM, MyungJoo Ham wrote: Signed-off-by: MyungJoo Ham Signed-off-by: Kyungmin Park -- Changes from v1. Thanks so much for your valuable comments, Mark. - Removed unnecessary initialization data - Add __initdata where necessary - Corrected a regulator name for ADC --- arch/arm/mach-exynos4/mach-nuri.c | 622 - 1 files changed, 621 insertions(+), 1 deletions(-) Will it be possible to move PMIC specific defines to a common file and make appropriate calls in the board-specific file? In that way, we can re-use this PMIC code on some other boards (e.g. Insignal low-cost board Origen featuring Exynos4210 also features MAX8997). Yes, we have tried creating PMIC defines at a seperated file in our local repositories (still doing so in those repositories). However, that ended up creating multiple PMIC defines (one PMIC define file for each board); the connections between LDO# and devices are different. In that case, we can first post the Origen board support and PMIC code on the ML, then we would see if we can consolidate. That looks more logical as per Mark's suggestion also. -- Tushar Behera -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 1/5] ARM: EXYNOS4: Change clock name for FIMD
This patch changes clock name for FIMD from "fimd" to "lcd".
Signed-off-by: Jingoo Han
---
arch/arm/mach-exynos4/clock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 871f9d5..12e6853 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -433,12 +433,12 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit= (1 << 3),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 0,
.enable = exynos4_clk_ip_lcd0_ctrl,
.ctrlbit= (1 << 0),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 1,
.enable = exynos4_clk_ip_lcd1_ctrl,
.ctrlbit= (1 << 0),
--
1.7.1
[PATCH V4 0/5] ARM: EXYNOS4: Add support EXYNOS4 FIMD
This patch series is based on the latest git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git This was originally submitted by Jonghun Han http://www.spinics.net/lists/arm-kernel/msg101781.html This patch adds support FIMD(Fully Interactive Mobile Display) on Exynos4. The 4th patch is update for s3c-fb and others are for platform data. v2: change clock name of exynos4 FIMD: "fimd" -> "lcd" use 'has_clksel' variable in order to distinguish FIMD version add 'lcd_clk' that can be used for only lcd pixel clock add callback 'enable_clk()' to enable parent clock 'sclk_fimd'. v3: remove the callback from the platform data structure v4: move clk_enable(sfb->lcd_clk) under the if statement o To Kukjin Kim [PATCH V4 1/5] ARM: EXYNOS4: Change clock name for FIMD [PATCH V4 2/5] ARM: EXYNOS4: Add FIMD resource definition [PATCH V4 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd o To Paul Mundt [PATCH V4 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
Re: [PATCH v2 1/5] Samsung SoC ADC: use regulator (VDD for ADC).
On Tue, Jun 21, 2011 at 7:43 PM, Mark Brown
wrote:
> On Tue, Jun 21, 2011 at 10:58:43AM +0900, MyungJoo Ham wrote:
>
>> + ret = regulator_enable(adc->vdd);
>> + if (!ret)
>> + goto err_ioremap;
>> +
>
> This test looks the wrong way round? regulator_enable() should return 0
> on success but this will treat that as an error.
Whoops.. thanks for pointing that out!
>
>> static int s3c_adc_resume(struct platform_device *pdev)
>> {
>> struct adc_device *adc = platform_get_drvdata(pdev);
>> + int ret;
>>
>> + ret = regulator_enable(adc->vdd);
>> clk_enable(adc->clk);
>> enable_irq(adc->irq);
>>
>> writel(adc->prescale | S3C2410_ADCCON_PRSCEN,
>> adc->regs + S3C2410_ADCCON);
>>
>> - return 0;
>> + return ret;
>
> Seems better to return as soon as we notice the error, no point in
> starting anything else up if we don't have power.
>
Ok. I see.
--
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tue, Jun 21, 2011 at 8:49 PM, Tushar Behera wrote: > On Tuesday 21 June 2011 04:40 PM, Mark Brown wrote: >> >> On Tue, Jun 21, 2011 at 11:03:12AM +0530, Tushar Behera wrote: >> >>> Will it be possible to move PMIC specific defines to a common file >>> and make appropriate calls in the board-specific file? >> >>> In that way, we can re-use this PMIC code on some other boards (e.g. >>> Insignal low-cost board Origen featuring Exynos4210 also features >>> MAX8997). >> >> If the board is similar enough in design to be sharing the PMIC code >> that sounds like it should be sharing a lot more of the board setup >> code. > > Origen board details can be found at http://www.origenboard.org/ > > Under 'Documents' section, there are some schematics for the board. > > As for other peripherals, I am not sure how much similar this is w.r.t. NURI > (I don't have NURI board schematics). Well, I cannot find enough information to match PMIC device data from the schematics in that 'Documents' section. It appears that they provide every information but the PMIC-related. > > -- > Tushar Behera > -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tue, Jun 21, 2011 at 2:33 PM, Tushar Behera wrote: > On Tuesday 21 June 2011 07:37 AM, MyungJoo Ham wrote: >> >> Signed-off-by: MyungJoo Ham >> Signed-off-by: Kyungmin Park >> >> -- >> Changes from v1. Thanks so much for your valuable comments, Mark. >> - Removed unnecessary initialization data >> - Add __initdata where necessary >> - Corrected a regulator name for ADC >> --- >> arch/arm/mach-exynos4/mach-nuri.c | 622 >> - >> 1 files changed, 621 insertions(+), 1 deletions(-) >> > Will it be possible to move PMIC specific defines to a common file and make > appropriate calls in the board-specific file? > > In that way, we can re-use this PMIC code on some other boards (e.g. > Insignal low-cost board Origen featuring Exynos4210 also features MAX8997). > Yes, we have tried creating PMIC defines at a seperated file in our local repositories (still doing so in those repositories). However, that ended up creating multiple PMIC defines (one PMIC define file for each board); the connections between LDO# and devices are different. > > -- > Tushar Behera > -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 0/5] USB: DWC OTG: Add dwc_otg driver for S5P6440 samsung SoC.
Hello, On Tuesday, June 21, 2011 2:36 PM Praveen Paneri wrote: > On Tue, Jun 21, 2011 at 4:21 PM, PRAVEEN PANERI > wrote: > Hi, > > > > Hello, > > > > On Tuesday, June 21, 2011 9:04 AM p.pan...@samsung.com wrote: > > > > > From: Praveen Paneri > > > > > > These patches modify DWC OTG driver for ARM and add it for ARM based > SoCs. > > > Currently it has been tested for Samsung's S5P6440. The development is > > > still > > > under process so these are not the best set of patches. They are just > for > > > review > > > and not for merge. Intent of these patches is to show required > > > modifications > > > to make dwc_otg patches work on ARM. > > > > What are the differences between DWC OTG hardware and OTG hardware found > > in s3c64xx/s5pc100/s5pv210 and Exynos4 SoCs series? I've did a brief look > > at register definitions and most of them looks same. Can this driver be > > merged with s3c-hsotg.c driver? > Yes they are same because they all use the same OTG IP. This driver > provides > functionalities of both host and gadget while s3c-hsotg.c is only a > gadget driver. I'm perfectly aware that s3c-hsotg is just for UDC functionality. I just wanted to ask if this driver can replace s3c-hsotg.c driver completely? > If you think this can be merged in s3c-hsotg to make that work in > smiler fashion > then go ahead but will that work on platforms other than ARM? You can always create so called variants of the driver that exports different functionality depending on the platform data the driver has been bound to. Usually it is used to distinguish different models of the hardware that has a lot in common. For example please refer to driver/media/video/s5p-fimc/fimc-core.c and fimc_driver_ids array in the bottom of the code. > > > > > Following features are tested for basic functions on SMDK6440 > > > board after modifications: > > > OTG HOST: HID and mass-storage > > > OTG DEVICE: mass-storage and adb > > > > Does it mean that HID or mass-storage (both host or gadget drivers) needs > > modifications to get them working with this DWC OTG driver? > > Why would we need any other driver if DWC OTG driver is working both > as host and gadget? You got me wrong. I wanted to ask if one needs to tweak in mass storage driver to get it working with DWC OTG driver? I'm asking because I've already seen a lot of scary code on some public Android trees, where mass storage was hacked to workaround bugs (or flaws) in the OTG driver. Have you tried your DWC OTG driver with some more demanding gadget drivers? One of such is g_multi which exports 3 usb functions (RNDIS, ACM serial and Mass Storage) in a composite device. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
On Tue, Jun 21, 2011 at 05:56:05PM +0530, Praveen Paneri wrote: > Hi, > > On Tue, Jun 21, 2011 at 4:20 PM, PRAVEEN PANERI wrote: Err, that attributation is wrong. > > On Tue, Jun 21, 2011 at 12:33:46PM +0530, p.pan...@samsung.com wrote: > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > > linux/gpio.h please. > will change it You should question why your mailer decided to remove the contents after the "#include" when quoting. Maybe you need to get a better mailer, fix some configuration setting, or complain to google that gmail is messing with emails in ways it shouldn't. However, I doubt that gmail itself is as broken as it appears to be above... but whatever it is, it needs fixing. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/5] USB: DWC OTG: Add dwc_otg driver for S5P6440 samsung SoC.
Hi, On Tue, Jun 21, 2011 at 4:21 PM, PRAVEEN PANERI wrote: Hi, > > Hello, > > On Tuesday, June 21, 2011 9:04 AM p.pan...@samsung.com wrote: > > > From: Praveen Paneri > > > > These patches modify DWC OTG driver for ARM and add it for ARM based SoCs. > > Currently it has been tested for Samsung's S5P6440. The development is > > still > > under process so these are not the best set of patches. They are just for > > review > > and not for merge. Intent of these patches is to show required > > modifications > > to make dwc_otg patches work on ARM. > > What are the differences between DWC OTG hardware and OTG hardware found > in s3c64xx/s5pc100/s5pv210 and Exynos4 SoCs series? I've did a brief look > at register definitions and most of them looks same. Can this driver be > merged with s3c-hsotg.c driver? Yes they are same because they all use the same OTG IP. This driver provides functionalities of both host and gadget while s3c-hsotg.c is only a gadget driver. If you think this can be merged in s3c-hsotg to make that work in smiler fashion then go ahead but will that work on platforms other than ARM? > > > Following features are tested for basic functions on SMDK6440 > > board after modifications: > > OTG HOST: HID and mass-storage > > OTG DEVICE: mass-storage and adb > > Does it mean that HID or mass-storage (both host or gadget drivers) needs > modifications to get them working with this DWC OTG driver? Why would we need any other driver if DWC OTG driver is working both as host and gadget? > > (snipped) > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center paneri -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
Hi, On Tue, Jun 21, 2011 at 4:20 PM, PRAVEEN PANERI wrote: > > On Tue, Jun 21, 2011 at 12:33:46PM +0530, p.pan...@samsung.com wrote: > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > linux/gpio.h please. will change it Thanks Paneri > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/5] ARM: SAMSUNG: Adding IO mapping for OTG PHY.
Hi,
On Tue, Jun 21, 2011 at 4:48 PM, Banajit Goswami
wrote:
> Hi Praveen,
>
> On Tue, Jun 21, 2011 at 12:33 PM, wrote:
>>
>> From: Praveen Paneri
>>
>> Adding virtual addresses for OTG PHY.
>>
>> Signed-off-by: Praveen Paneri
>> ---
>> arch/arm/mach-s5p64x0/cpu.c | 5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-s5p64x0/cpu.c b/arch/arm/mach-s5p64x0/cpu.c
>> index a5c0095..8dc6f20 100644
>> --- a/arch/arm/mach-s5p64x0/cpu.c
>> +++ b/arch/arm/mach-s5p64x0/cpu.c
>> @@ -57,6 +57,11 @@ static struct map_desc s5p64x0_iodesc[] __initdata = {
>> .pfn = __phys_to_pfn(S5P64X0_PA_VIC1),
>> .length = SZ_16K,
>> .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S3C_VA_USB_HSPHY,
>> + .pfn = __phys_to_pfn(S5P64X0_PA_USB_HSPHY),
>> + .length = SZ_1M,
>
> Do we really need 1M for this??
Accepted, will give lesser length in subsequent versions.
>
>> + .type = MT_DEVICE,
>> },
>> };
>>
>> --
>> 1.7.0.4
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Praveen Paneri
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hello.
On 21-06-2011 15:49, Felipe Balbi wrote:
From: Praveen Paneri
Adding dwc driver name in existing platform device
to probe DWC OTG driver.
Introduced otg_set_platdata function to pass platform data
Added selectable config option to add DWC OTG driver for different
machines.
Signed-off-by: Praveen Paneri
[...]
diff --git a/arch/arm/plat-samsung/dev-usb-hsotg.c
b/arch/arm/plat-samsung/dev-usb-hsotg.c
index 33a844a..7e6228b 100644
--- a/arch/arm/plat-samsung/dev-usb-hsotg.c
+++ b/arch/arm/plat-samsung/dev-usb-hsotg.c
[...]
@@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
struct platform_device s3c_device_usb_hsotg = {
+#ifdef CONFIG_S3C_DEV_USB_HSOTG
.name = "s3c-hsotg",
+#endif
+#ifdef CONFIG_S3C_DEV_DWC_OTG
+ .name = "dwc_otg",
+#endif
I'd done it as:
+#if defined(CONFIG_S3C_DEV_USB_HSOTG)
.name = "s3c-hsotg",
+#elif defined(CONFIG_S3C_DEV_DWC_OTG)
+ .name = "dwc_otg",
+#endif
no... don't do that. How many times do I have to repeat ? No ifdefs!! we
want both drivers to be able to be compiled as modules, so add both
platform devices.
Sorry, hadn't seen your mail when replying.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] USB: DWC OTG: Modification in DWC OTG driver for ARM based SoCs.
Hi,
On Tue, Jun 21, 2011 at 4:18 PM, PRAVEEN PANERI wrote:
>
> Hi,
>
> On Tue, Jun 21, 2011 at 12:33:43PM +0530, p.pan...@samsung.com wrote:
> > From: Praveen Paneri
> >
> > This patch modifies DWC OTG for ARM based SoCs. Currently it has
> > been tested for Samsung S5P6440. Can easily be built for others
> > as well.
> >
> > Following features are tested for basic functions on SMDK6440
> > board after modifications:
> > OTG HOST: HID and mass-storage
> > OTG DEVICE: mass-storage and adb
> >
> > Signed-off-by: Praveen Paneri
>
> this is wrong is so many levels... We shouldn't be adding ifdefs to
> allow the driver to be compiled for multiple architectures. The correct
> way to handle this, is to phase out the core driver from the SoC- or
> PCI-specific parts and make that a glue layer that bridges to the core
> driver.
As I said this is just to show the changes required in this driver
to port it for ARM. Interest is in having single driver for both host and
gadget and make use of the OTG feature as it has been provided by
the IP.
Will implement it in a better possible way.
Thanks
Paneri
>
> I'm writing the driver for a similar core, the DWC USB3, take a look at
> my dwc3 branch [1] to see how this should be done.
>
> > diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
> > index ffbe6dd..b0dcae9 100644
> > --- a/drivers/usb/dwc/apmppc.c
> > +++ b/drivers/usb/dwc/apmppc.c
> > @@ -50,9 +50,6 @@
> > * this file system to perform diagnostics on the driver components or the
> > * device.
> > */
> > -
> > -#include
> > -
> > #include "driver.h"
> >
> > #define DWC_DRIVER_VERSION "1.05"
> > @@ -110,6 +107,9 @@ static int __devexit dwc_otg_driver_remove(struct
> > platform_device *ofdev)
> > {
> > struct device *dev = &ofdev->dev;
> > struct dwc_otg_device *dwc_dev = dev_get_drvdata(dev);
> > +#ifdef CONFIG_CPU_S5P6440
> > + struct s5p_otg_platdata *pdata = ofdev->dev.platform_data;
> > +#endif
>
> NAK
>
> > @@ -152,6 +152,11 @@ static int __devexit dwc_otg_driver_remove(struct
> > platform_device *ofdev)
> >
> > /* Clear the drvdata pointer. */
> > dev_set_drvdata(dev, NULL);
> > +#ifdef CONFIG_CPU_S5P6440
> > + /* OTG Phy off */
> > + if (pdata && pdata->phy_exit)
> > + pdata->phy_exit(ofdev, S5P_USB_PHY_DEVICE);
> > +#endif
>
> NAK
>
> > @@ -169,12 +174,14 @@ static int __devinit dwc_otg_driver_probe(struct
> > platform_device *ofdev)
> > int retval;
> > struct dwc_otg_device *dwc_dev;
> > struct device *dev = &ofdev->dev;
> > +#ifdef CONFIG_CPU_S5P6440
> > + struct s5p_otg_platdata *pdata = ofdev->dev.platform_data;
> > +#endif
>
> NAK
>
> > @@ -182,15 +189,24 @@ static int __devinit dwc_otg_driver_probe(struct
> > platform_device *ofdev)
> > goto fail_dwc_dev;
> > }
> >
> > +#ifdef CONFIG_CPU_S5P6440
> > + /* OTG Phy init */
> > + if (pdata && pdata->phy_init)
> > + pdata->phy_init(ofdev, S5P_USB_PHY_DEVICE);
> > +#endif
> > /* Retrieve the memory and IRQ resources. */
> > +#ifdef CONFIG_ARM
> > + dwc_dev->irq = ofdev->resource[1].start;
> > +#else
> > dwc_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> > +#endif
>
> NAK
>
> > +#ifndef CONFIG_ARM
>
> NAK
>
> > @@ -200,8 +216,14 @@ static int __devinit dwc_otg_driver_probe(struct
> > platform_device *ofdev)
> > dev_dbg(dev, "OTG - ioresource_mem start0x%llx: end:0x%llx\n",
> > (unsigned long long)res.start, (unsigned long long)res.end);
> >
> > +
> > dwc_dev->phys_addr = res.start;
> > dwc_dev->base_len = res.end - res.start + 1;
> > +#else
> > + dwc_dev->phys_addr = ofdev->resource[0].start;
> > + dwc_dev->base_len = ofdev->resource[0].end -
> > + ofdev->resource[0].start + 1;
> > +#endif
>
> NAK
>
> > @@ -296,6 +318,7 @@ static int __devinit dwc_otg_driver_probe(struct
> > platform_device *ofdev)
> > dwc_dev->hcd = NULL;
> > goto fail_hcd;
> > }
> > +#ifndef CONFIG_ARM
>
> NAK
>
> > @@ -316,6 +339,7 @@ static int __devinit dwc_otg_driver_probe(struct
> > platform_device *ofdev)
> > dwc_dev->hcd->cp_irq_installed = 1;
> > }
> > }
> > +#endif
>
> NAK
>
> > diff --git a/drivers/usb/dwc/cil.h b/drivers/usb/dwc/cil.h
> > index 80b7da5..c1a11f1 100644
> > --- a/drivers/usb/dwc/cil.h
> > +++ b/drivers/usb/dwc/cil.h
> > @@ -37,6 +37,15 @@
> > #if !defined(__DWC_CIL_H__)
> > #define __DWC_CIL_H__
> > #include
> > +#ifdef CONFIG_ARM
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#else
> > +#include
> > +#endif
>
> I can't even say how ugly this is.
>
> > diff --git a/drivers/usb/dwc/param.c b/drivers/usb/dwc/param.c
> > index 523f0db..b48c510 100644
> > --- a/drivers/usb/dwc/param.c
> > +++ b/drivers/usb/dwc/param.c
> > @@ -116,8 +116,12 @@ static int set_valid_tx_fifo_sizes(struct core_if
> > *core_if)
> > * This function is called during module intialization to verify that
> > * the module parameters are in a valid state.
> > */
> > -int __devinit check_parameters(struct core_if *core_if)
> > +int __devinit check_parameters(struct core_if *core
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tue, Jun 21, 2011 at 05:19:14PM +0530, Tushar Behera wrote: > On Tuesday 21 June 2011 04:40 PM, Mark Brown wrote: >> If the board is similar enough in design to be sharing the PMIC code >> that sounds like it should be sharing a lot more of the board setup >> code. > Origen board details can be found at http://www.origenboard.org/ > Under 'Documents' section, there are some schematics for the board. > As for other peripherals, I am not sure how much similar this is w.r.t. > NURI (I don't have NURI board schematics). Right, and we can't really make the assessment about sharing the code if we can't do a contrast and compare between the two schematics (or look at the resulting code). -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hi,
On Tue, Jun 21, 2011 at 05:20:25PM +0530, Praveen Paneri wrote:
> > > @@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
> > > static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
> > >
> > > struct platform_device s3c_device_usb_hsotg = {
> > > +#ifdef CONFIG_S3C_DEV_USB_HSOTG
> > > .name = "s3c-hsotg",
> > > +#endif
> > > +#ifdef CONFIG_S3C_DEV_DWC_OTG
> > > + .name = "dwc_otg",
> > > +#endif
> >
> > no, don't do that. See we're going through a big re-factor on the gadget
> > framework to allow multiple UDC drivers to be compiled as modules. The
> > idea is to be able to have distro-like kernels for embedded too.
> It can be build as a module but need to make necessary modifications in
> platform code. Will modify according to the gadget framework.
can't you do runtime detection of which platform you're running on ?
Then you add one or the other platform_device. But ifdeferry won't help
you in the long run.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hi,
On Tue, Jun 21, 2011 at 4:17 PM, PRAVEEN PANERI wrote:
>
> Hi,
>
> On Tue, Jun 21, 2011 at 12:33:44PM +0530, p.pan...@samsung.com wrote:
> > From: Praveen Paneri
> >
> > Adding dwc driver name in existing platform device
> > to probe DWC OTG driver.
> > Introduced otg_set_platdata function to pass platform data
> > Added selectable config option to add DWC OTG driver for different
> > machines.
> >
> > Signed-off-by: Praveen Paneri
> > ---
> > arch/arm/plat-samsung/Kconfig |6 ++
> > arch/arm/plat-samsung/Makefile|1 +
> > arch/arm/plat-samsung/dev-usb-hsotg.c | 20
> > 3 files changed, 27 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> > index 4d79519..58ed8b1 100644
> > --- a/arch/arm/plat-samsung/Kconfig
> > +++ b/arch/arm/plat-samsung/Kconfig
> > @@ -227,6 +227,12 @@ config S3C_DEV_USB_HSOTG
> > help
> > Compile in platform device definition for USB high-speed OtG
> >
> > +config S3C_DEV_DWC_OTG
> > + bool
> > + help
> > + Compile in platform device definition for DWC OTG. This
> > + will make it selectable for different machines.
> > +
> > config S3C_DEV_WDT
> > bool
> > default y if ARCH_S3C2410
> > diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
> > index 53eb15b..785ca79 100644
> > --- a/arch/arm/plat-samsung/Makefile
> > +++ b/arch/arm/plat-samsung/Makefile
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o
> > obj-y += dev-uart.o
> > obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
> > obj-$(CONFIG_S3C_DEV_USB_HSOTG) += dev-usb-hsotg.o
> > +obj-$(CONFIG_S3C_DEV_DWC_OTG) += dev-usb-hsotg.o
> > obj-$(CONFIG_S3C_DEV_WDT) += dev-wdt.o
> > obj-$(CONFIG_S3C_DEV_NAND) += dev-nand.o
> > obj-$(CONFIG_S3C_DEV_ONENAND) += dev-onenand.o
> > diff --git a/arch/arm/plat-samsung/dev-usb-hsotg.c
> > b/arch/arm/plat-samsung/dev-usb-hsotg.c
> > index 33a844a..7e6228b 100644
> > --- a/arch/arm/plat-samsung/dev-usb-hsotg.c
> > +++ b/arch/arm/plat-samsung/dev-usb-hsotg.c
> > @@ -20,6 +20,8 @@
> > #include
> >
> > #include
> > +#include
> > +#include
> >
> > static struct resource s3c_usb_hsotg_resources[] = {
> > [0] = {
> > @@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
> > static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
> >
> > struct platform_device s3c_device_usb_hsotg = {
> > +#ifdef CONFIG_S3C_DEV_USB_HSOTG
> > .name = "s3c-hsotg",
> > +#endif
> > +#ifdef CONFIG_S3C_DEV_DWC_OTG
> > + .name = "dwc_otg",
> > +#endif
>
> no, don't do that. See we're going through a big re-factor on the gadget
> framework to allow multiple UDC drivers to be compiled as modules. The
> idea is to be able to have distro-like kernels for embedded too.
It can be build as a module but need to make necessary modifications in
platform code. Will modify according to the gadget framework.
Thanks for the comment.
paneri
>
> Take a look at my gadget branch [1] and see how the gadget controllers
> are modified to start allowing that.
>
> I also have patch to the Kconfig allowing all controllers to be enabled
> as modules, I just need some more time to figure out one warning on the
> renenesas controller.
>
> IOW, it's best to add both platform devices. Or move to device tree.
>
> --
> balbi
>
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hi,
On Tue, Jun 21, 2011 at 03:47:04PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 21-06-2011 11:03, p.pan...@samsung.com wrote:
>
> >From: Praveen Paneri
>
> >Adding dwc driver name in existing platform device
> >to probe DWC OTG driver.
> >Introduced otg_set_platdata function to pass platform data
> >Added selectable config option to add DWC OTG driver for different
> >machines.
>
> >Signed-off-by: Praveen Paneri
> [...]
>
> >diff --git a/arch/arm/plat-samsung/dev-usb-hsotg.c
> >b/arch/arm/plat-samsung/dev-usb-hsotg.c
> >index 33a844a..7e6228b 100644
> >--- a/arch/arm/plat-samsung/dev-usb-hsotg.c
> >+++ b/arch/arm/plat-samsung/dev-usb-hsotg.c
> [...]
> >@@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
> > static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
> >
> > struct platform_device s3c_device_usb_hsotg = {
> >+#ifdef CONFIG_S3C_DEV_USB_HSOTG
> > .name = "s3c-hsotg",
> >+#endif
> >+#ifdef CONFIG_S3C_DEV_DWC_OTG
> >+.name = "dwc_otg",
> >+#endif
>
>I'd done it as:
>
> +#if defined(CONFIG_S3C_DEV_USB_HSOTG)
> .name = "s3c-hsotg",
> +#elif defined(CONFIG_S3C_DEV_DWC_OTG)
> + .name = "dwc_otg",
> +#endif
no... don't do that. How many times do I have to repeat ? No ifdefs!! we
want both drivers to be able to be compiled as modules, so add both
platform devices.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tuesday 21 June 2011 04:40 PM, Mark Brown wrote: On Tue, Jun 21, 2011 at 11:03:12AM +0530, Tushar Behera wrote: Will it be possible to move PMIC specific defines to a common file and make appropriate calls in the board-specific file? In that way, we can re-use this PMIC code on some other boards (e.g. Insignal low-cost board Origen featuring Exynos4210 also features MAX8997). If the board is similar enough in design to be sharing the PMIC code that sounds like it should be sharing a lot more of the board setup code. Origen board details can be found at http://www.origenboard.org/ Under 'Documents' section, there are some schematics for the board. As for other peripherals, I am not sure how much similar this is w.r.t. NURI (I don't have NURI board schematics). -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hello.
On 21-06-2011 11:03, p.pan...@samsung.com wrote:
From: Praveen Paneri
Adding dwc driver name in existing platform device
to probe DWC OTG driver.
Introduced otg_set_platdata function to pass platform data
Added selectable config option to add DWC OTG driver for different
machines.
Signed-off-by: Praveen Paneri
[...]
diff --git a/arch/arm/plat-samsung/dev-usb-hsotg.c
b/arch/arm/plat-samsung/dev-usb-hsotg.c
index 33a844a..7e6228b 100644
--- a/arch/arm/plat-samsung/dev-usb-hsotg.c
+++ b/arch/arm/plat-samsung/dev-usb-hsotg.c
[...]
@@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
struct platform_device s3c_device_usb_hsotg = {
+#ifdef CONFIG_S3C_DEV_USB_HSOTG
.name = "s3c-hsotg",
+#endif
+#ifdef CONFIG_S3C_DEV_DWC_OTG
+ .name = "dwc_otg",
+#endif
I'd done it as:
+#if defined(CONFIG_S3C_DEV_USB_HSOTG)
.name = "s3c-hsotg",
+#elif defined(CONFIG_S3C_DEV_DWC_OTG)
+ .name = "dwc_otg",
+#endif
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: exynos4: Add a new Exynos4 device tree enabled machine
On 20 June 2011 22:25, Grant Likely wrote:
>> +
>> +static const struct of_dev_auxdata exynos4_auxdata_lookup[] __initconst = {
>> + OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(2),
>> + "s3c-sdhci.2", &s3c_hsmmc2_def_platdata),
>> + OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(0),
>> + "s3c-sdhci.0", &s3c_hsmmc0_def_platdata),
>> + OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART0,
>> + "s5pv210-uart.0", NULL),
>> + OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART1,
>> + "s5pv210-uart.1", NULL),
>> + {},
>> +};
>> +static void __init exynos4_dt_machine_init(void)
>> +{
>> + s3c_sdhci0_set_platdata(&smdkv310_hsmmc0_pdata);
>> + s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
>
> Are these two lines still necessary?
Yes, but these are temporary. The data from smdkv310_hsmmc0_pdata is
copied to s3c_hsmmc2_def_platdata which is then used as platform data.
I will remove them in the next version of the patch.
Thanks,
Thomas.
>
> Otherwise, the patch looks good to me.
>
> g.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: EXYNOS4: Add EPLL clock operations
S5PV210 and EXYNOS4 uses similar PLL(PLL46XX) for EPLL.
So, The EPLL set rate function is duplicated.
Note: Moved common code to plat-s5p, as commented by Kukjin Kim.
Signed-off-by: Naveen Krishna Chatradhi
---
arch/arm/mach-exynos4/clock.c|1 +
arch/arm/mach-s5pv210/clock.c| 78 +-
arch/arm/plat-s5p/clock.c| 77 +
arch/arm/plat-s5p/include/plat/pll.h |3 +
4 files changed, 82 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index feeb27e..7687087 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1294,6 +1294,7 @@ void __init_or_cpufreq exynos4_setup_clocks(void)
__raw_readl(S5P_VPLL_CON1), pll_4650);
clk_fout_apll.ops = &exynos4_fout_apll_ops;
+ clk_fout_epll.ops = &pll46xx_epll_ops;
clk_fout_mpll.rate = mpll;
clk_fout_epll.rate = epll;
clk_fout_vpll.rate = vpll;
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index ae72f87..dd77c2c 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -979,82 +979,6 @@ static struct clksrc_clk *sysclks[] = {
&clk_sclk_spdif,
};
-static u32 epll_div[][6] = {
- { 4800, 0, 48, 3, 3, 0 },
- { 9600, 0, 48, 3, 2, 0 },
- { 14400, 1, 72, 3, 2, 0 },
- { 19200, 0, 48, 3, 1, 0 },
- { 28800, 1, 72, 3, 1, 0 },
- { 3275, 1, 65, 3, 4, 35127 },
- { 32768000, 1, 65, 3, 4, 35127 },
- { 45158400, 0, 45, 3, 3, 10355 },
- { 4500, 0, 45, 3, 3, 10355 },
- { 45158000, 0, 45, 3, 3, 10355 },
- { 49125000, 0, 49, 3, 3, 9961 },
- { 49152000, 0, 49, 3, 3, 9961 },
- { 67737600, 1, 67, 3, 3, 48366 },
- { 67738000, 1, 67, 3, 3, 48366 },
- { 7380, 1, 73, 3, 3, 47710 },
- { 73728000, 1, 73, 3, 3, 47710 },
- { 3600, 1, 32, 3, 4, 0 },
- { 6000, 1, 60, 3, 3, 0 },
- { 7200, 1, 72, 3, 3, 0 },
- { 8000, 1, 80, 3, 3, 0 },
- { 8400, 0, 42, 3, 2, 0 },
- { 5000, 0, 50, 3, 3, 0 },
-};
-
-static int s5pv210_epll_set_rate(struct clk *clk, unsigned long rate)
-{
- unsigned int epll_con, epll_con_k;
- unsigned int i;
-
- /* Return if nothing changed */
- if (clk->rate == rate)
- return 0;
-
- epll_con = __raw_readl(S5P_EPLL_CON);
- epll_con_k = __raw_readl(S5P_EPLL_CON1);
-
- epll_con_k &= ~PLL46XX_KDIV_MASK;
- epll_con &= ~(1 << 27 |
- PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT |
- PLL46XX_PDIV_MASK << PLL46XX_PDIV_SHIFT |
- PLL46XX_SDIV_MASK << PLL46XX_SDIV_SHIFT);
-
- for (i = 0; i < ARRAY_SIZE(epll_div); i++) {
- if (epll_div[i][0] == rate) {
- epll_con_k |= epll_div[i][5] << 0;
- epll_con |= (epll_div[i][1] << 27 |
- epll_div[i][2] << PLL46XX_MDIV_SHIFT |
- epll_div[i][3] << PLL46XX_PDIV_SHIFT |
- epll_div[i][4] << PLL46XX_SDIV_SHIFT);
- break;
- }
- }
-
- if (i == ARRAY_SIZE(epll_div)) {
- printk(KERN_ERR "%s: Invalid Clock EPLL Frequency\n",
- __func__);
- return -EINVAL;
- }
-
- __raw_writel(epll_con, S5P_EPLL_CON);
- __raw_writel(epll_con_k, S5P_EPLL_CON1);
-
- printk(KERN_WARNING "EPLL Rate changes from %lu to %lu\n",
- clk->rate, rate);
-
- clk->rate = rate;
-
- return 0;
-}
-
-static struct clk_ops s5pv210_epll_ops = {
- .set_rate = s5pv210_epll_set_rate,
- .get_rate = s5p_epll_get_rate,
-};
-
void __init_or_cpufreq s5pv210_setup_clocks(void)
{
struct clk *xtal_clk;
@@ -1075,7 +999,7 @@ void __init_or_cpufreq s5pv210_setup_clocks(void)
/* Set functions for clk_fout_epll */
clk_fout_epll.enable = s5p_epll_enable;
- clk_fout_epll.ops = &s5pv210_epll_ops;
+ clk_fout_epll.ops = &pll46xx_epll_ops;
printk(KERN_DEBUG "%s: registering clocks\n", __func__);
diff --git a/arch/arm/plat-s5p/clock.c b/arch/arm/plat-s5p/clock.c
index 02af235..2a4678d 100644
--- a/arch/arm/plat-s5p/clock.c
+++ b/arch/arm/plat-s5p/clock.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
#include
@@ -203,6 +204,82 @@ struct clk_ops s5p_sclk_spdif_ops = {
.get_rate = s5p_spdif_get_rate,
};
+static u32 epll_div[][6] = {
+ { 4800, 0, 48, 3, 3, 0 },
+ { 9600, 0, 48, 3, 2, 0 },
+ { 14400, 1, 72, 3, 2, 0 },
+ { 19200, 0, 48, 3, 1, 0 },
+ { 28800, 1, 72, 3, 1, 0 },
+ { 3275, 1, 65, 3, 4, 35127 },
[PATCH v2 2/3] ARM: EXYNOS4: Add sclk_spdif clocks.
Add the sclk_spdif clock is of type 'struct clksrc_clk' clock.
Also, add clk_spdifextclk clocks of type 'struct clk' clock.
Signed-off-by: Naveen Krishna Chatradhi
---
arch/arm/mach-exynos4/clock.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 937335a..feeb27e 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -64,6 +64,11 @@ static struct clk clk_audiocdclk2 = {
.name = "audiocdclk",
};
+static struct clk clk_spdifextclk = {
+ .name = "spdif_extclk",
+ .id = -1,
+};
+
static int exynos4_clksrc_mask_top_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_CLKSRC_MASK_TOP, clk, enable);
@@ -550,6 +555,11 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1 << 21),
}, {
+ .name = "spdif",
+ .id = -1,
+ .enable = exynos4_clk_ip_peril_ctrl,
+ .ctrlbit= (1 << 26),
+ }, {
.name = "ac97",
.id = -1,
.enable = exynos4_clk_ip_peril_ctrl,
@@ -801,6 +811,30 @@ static struct clk init_clocks[] = {
}
};
+static struct clk *clkset_sclk_spdif_list[] = {
+ [0] = &clk_sclk_audio0.clk,
+ [1] = &clk_sclk_audio1.clk,
+ [2] = &clk_sclk_audio2.clk,
+ [3] = &clk_spdifextclk,
+};
+
+static struct clksrc_sources clkset_sclk_spdif = {
+ .sources= clkset_sclk_spdif_list,
+ .nr_sources = ARRAY_SIZE(clkset_sclk_spdif_list),
+};
+
+static struct clksrc_clk clk_sclk_spdif = {
+ .clk= {
+ .name = "sclk_spdif",
+ .id = -1,
+ .enable = exynos4_clksrc_mask_peril1_ctrl,
+ .ctrlbit= (1 << 8),
+ .ops= &s5p_sclk_spdif_ops,
+ },
+ .sources = &clkset_sclk_spdif,
+ .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 8, .size = 2 },
+};
+
static struct clk *clkset_group_list[] = {
[0] = &clk_ext_xtal_mux,
[1] = &clk_xusbxti,
@@ -1206,6 +1240,7 @@ static struct clksrc_clk *sysclks[] = {
&clk_sclk_audio0,
&clk_sclk_audio1,
&clk_sclk_audio2,
+ &clk_sclk_spdif,
};
static int xtal_rate;
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: Samsung: Move duplicate code
Move the duplicated code for SPDIF ops from S5PV210 and S5PC100.
So, the same can be used in EXYNOS4.
Signed-off-by: Naveen Krishna Chatradhi
---
Note: Moved common code to plat-s5p, as suggested by Kukjin Kim.
arch/arm/mach-s5pc100/clock.c | 37 +---
arch/arm/mach-s5pv210/clock.c | 37 +---
arch/arm/plat-s5p/clock.c | 35 ++
arch/arm/plat-s5p/include/plat/s5p-clock.h |5
4 files changed, 42 insertions(+), 72 deletions(-)
diff --git a/arch/arm/mach-s5pc100/clock.c b/arch/arm/mach-s5pc100/clock.c
index cd248e6..ff5cbb3 100644
--- a/arch/arm/mach-s5pc100/clock.c
+++ b/arch/arm/mach-s5pc100/clock.c
@@ -910,47 +910,12 @@ struct clksrc_sources clk_src_sclk_spdif = {
.nr_sources = ARRAY_SIZE(clk_sclk_spdif_list),
};
-static int s5pc100_spdif_set_rate(struct clk *clk, unsigned long rate)
-{
- struct clk *pclk;
- int ret;
-
- pclk = clk_get_parent(clk);
- if (IS_ERR(pclk))
- return -EINVAL;
-
- ret = pclk->ops->set_rate(pclk, rate);
- clk_put(pclk);
-
- return ret;
-}
-
-static unsigned long s5pc100_spdif_get_rate(struct clk *clk)
-{
- struct clk *pclk;
- int rate;
-
- pclk = clk_get_parent(clk);
- if (IS_ERR(pclk))
- return -EINVAL;
-
- rate = pclk->ops->get_rate(clk);
- clk_put(pclk);
-
- return rate;
-}
-
-static struct clk_ops s5pc100_sclk_spdif_ops = {
- .set_rate = s5pc100_spdif_set_rate,
- .get_rate = s5pc100_spdif_get_rate,
-};
-
static struct clksrc_clk clk_sclk_spdif = {
.clk= {
.name = "sclk_spdif",
.ctrlbit= (1 << 11),
.enable = s5pc100_sclk1_ctrl,
- .ops= &s5pc100_sclk_spdif_ops,
+ .ops= &s5p_sclk_spdif_ops,
},
.sources = &clk_src_sclk_spdif,
.reg_src = { .reg = S5P_CLK_SRC3, .shift = 24, .size = 2 },
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index b5c95e6..ae72f87 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -686,47 +686,12 @@ static struct clksrc_sources clkset_sclk_spdif = {
.nr_sources = ARRAY_SIZE(clkset_sclk_spdif_list),
};
-static int s5pv210_spdif_set_rate(struct clk *clk, unsigned long rate)
-{
- struct clk *pclk;
- int ret;
-
- pclk = clk_get_parent(clk);
- if (IS_ERR(pclk))
- return -EINVAL;
-
- ret = pclk->ops->set_rate(pclk, rate);
- clk_put(pclk);
-
- return ret;
-}
-
-static unsigned long s5pv210_spdif_get_rate(struct clk *clk)
-{
- struct clk *pclk;
- int rate;
-
- pclk = clk_get_parent(clk);
- if (IS_ERR(pclk))
- return -EINVAL;
-
- rate = pclk->ops->get_rate(clk);
- clk_put(pclk);
-
- return rate;
-}
-
-static struct clk_ops s5pv210_sclk_spdif_ops = {
- .set_rate = s5pv210_spdif_set_rate,
- .get_rate = s5pv210_spdif_get_rate,
-};
-
static struct clksrc_clk clk_sclk_spdif = {
.clk= {
.name = "sclk_spdif",
.enable = s5pv210_clk_mask0_ctrl,
.ctrlbit= (1 << 27),
- .ops= &s5pv210_sclk_spdif_ops,
+ .ops= &s5p_sclk_spdif_ops,
},
.sources = &clkset_sclk_spdif,
.reg_src = { .reg = S5P_CLK_SRC6, .shift = 12, .size = 2 },
diff --git a/arch/arm/plat-s5p/clock.c b/arch/arm/plat-s5p/clock.c
index 8d081d9..02af235 100644
--- a/arch/arm/plat-s5p/clock.c
+++ b/arch/arm/plat-s5p/clock.c
@@ -168,6 +168,41 @@ unsigned long s5p_epll_get_rate(struct clk *clk)
return clk->rate;
}
+int s5p_spdif_set_rate(struct clk *clk, unsigned long rate)
+{
+ struct clk *pclk;
+ int ret;
+
+ pclk = clk_get_parent(clk);
+ if (IS_ERR(pclk))
+ return -EINVAL;
+
+ ret = pclk->ops->set_rate(pclk, rate);
+ clk_put(pclk);
+
+ return ret;
+}
+
+unsigned long s5p_spdif_get_rate(struct clk *clk)
+{
+ struct clk *pclk;
+ int rate;
+
+ pclk = clk_get_parent(clk);
+ if (IS_ERR(pclk))
+ return -EINVAL;
+
+ rate = pclk->ops->get_rate(clk);
+ clk_put(pclk);
+
+ return rate;
+}
+
+struct clk_ops s5p_sclk_spdif_ops = {
+ .set_rate = s5p_spdif_set_rate,
+ .get_rate = s5p_spdif_get_rate,
+};
+
static struct clk *s5p_clks[] __initdata = {
&clk_ext_xtal_mux,
&clk_48m,
diff --git a/arch/arm/plat-s5p/include/plat/s5p-clock.h
b/arch/arm/plat-s5p/include/plat/s5p-clock.h
index 2b6dcff..769b5bd 100644
--- a/arch/arm/plat-s5p/include/plat/s5p-clock.h
+++ b/arch/arm/plat-s5p/include/plat/s5p-clock.h
@@ -47,4 +47,9 @@ extern int s5p_gatectrl(void __iomem *reg, str
[PATCH V2 0/3] ARM: Add SPDIF support for EXYNOS4
o To Kukjin Kim, Sangbeom Kim, Jassi Brar and Seungwhan Youn [PATCH v2 1/3] ARM: Samsung: Move duplicate code o This is a prerequisite for 2/3 and 3/3 patches thus mentioned as "v2". [PATCH v2 2/3] ARM: EXYNOS4: Add sclk_spdif clocks. o v1 patch is https://patchwork.kernel.org/patch/867882/ [PATCH v2 3/3] ARM: EXYNOS4: Add EPLL clock operations o v1 patch is https://patchwork.kernel.org/patch/867872/ Best Regards, Naveen Krishna Chatradhi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver
On Mon, Jun 20, 2011 at 10:43:50AM -0600, Grant Likely wrote: > I think I've commented on this before, but I do try to avoid direct > coding registers into the DT. That said, sometimes there really isn't > a nice human-friendly way of encoding things and direct register > values is the best approach. Hrm, that's going to mean a *lot* of code doing parsing, especially if we also follow through and also have proper parsers for all the bitfields and don't just push the magic numbers down a level. In principal I agree with you that that's what we should be doing but in practice it seems like an awful lot of effort on all sides. I'm not against it but if we're going to go down this road I think we need to put some work into helpers to cut down on the parsing code. The obvious one is a helper which maps a table of strings into numbers for things like selecting multi-function pin functions. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver
Hi Grant,
On 20 June 2011 22:13, Grant Likely wrote:
>
> For custom properties, you should prefix the property name with 'samsung,'.
>
> This looks very much like directly encoding the Linux flags into the
> device tree. The binding should be completely contained within
> itself, and not refer to OS implementation details. It is fine to use
> the same values that Linux happens to use, but they need to still be
> explicitly documented as to what they mean. Also, a 'flags' property
> usually isn't very friendly to mere-mortals when the explicit
> behaviour can be enabled with the presence of a named property. For
> example; something like a "samsung,uart-has-rtscts" to enable rts/cts.
I will ensure that the next version of the patch do not have any linux
specific bindings.
>
>> +
>> +- has_fracval : Set to 1, if the controller supports fractional part of
>> + for the baud divisor, otherwise, set to 0.
>
> Boolean stuff often doesn't need a value. If the property is present,
> it is a '1'. If it isn't, then it is a '0'.
>
>> +
>> +- ucon_default : Default board specific setting of UCON register.
>> +
>> +- ulcon_default : Default board specific setting of ULCON register.
>> +
>> +- ufcon_default : Default board specific setting of UFCON register.
>
> I think I've commented on this before, but I do try to avoid direct
> coding registers into the DT. That said, sometimes there really isn't
> a nice human-friendly way of encoding things and direct register
> values is the best approach.
Instead of default register values, is it acceptable to include custom
properties like "samsung,txfifo-trig-level" and then convert it to
corresponding register settings?
>
>> +
>> +- uart_clksrc : One or more child nodes representing the clock sources that
>> + could be used to derive the buad rate. Each of these child nodes
>> + has four required properties.
>> +
>> + - name : Name of the parent clock.
>> + - divisor : divisor from the clock to the uart controller.
>> + - min_baud : Minimum baud rate for which this clock can be used.
>> + Set to zero, if there is no limitation.
>> + - max_buad : Maximum baud rate for which this clock can be used.
>
> typo: s/buad/baud/
>
>> + Set to zero, if there is no limitation.
>
> This looks to be directly encoding the current Linux implementation
> details into the device tree (it is a direct copy of the config
> structure members), and it doesn't use the common clock binding. It's
> fine to use sub nodes for each clock attachment, particularly because
> it looks like the uart is able to apply it's own divisor to the clock
> input, but I would definitely encode the data using the existing
> struct clock binding.
>
>> +
>> +Optional properties:
>> +- fifosize: Size of the tx/rx fifo used in the controller. If not specified,
>> + the default value of the fifosize is 16.
>> diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
>> index 3b2021a..9aacbda 100644
>> --- a/drivers/tty/serial/s5pv210.c
>> +++ b/drivers/tty/serial/s5pv210.c
>> @@ -18,6 +18,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -131,15 +132,39 @@ static struct s3c24xx_uart_info *s5p_uart_inf[] = {
>> /* device management */
>> static int s5p_serial_probe(struct platform_device *pdev)
>> {
>> - return s3c24xx_serial_probe(pdev, s5p_uart_inf[pdev->id]);
>> + const void *prop;
>> + unsigned int port = pdev->id;
>> + unsigned int fifosize = 16;
>> + static unsigned int probe_index;
>> +
>> + if (pdev->dev.of_node) {
>> + prop = of_get_property(pdev->dev.of_node, "fifosize", NULL);
>> + if (prop)
>> + fifosize = be32_to_cpu(*(u32 *)prop);
>
> Okay, this is getting ugly (not your fault, but this pattern has
> become too common. Can you craft and post a patch that adds the
> following functions to drivers/of/base.c and include/linux/of.h
>
> /* offset in cells, not bytes */
> int dt_decode_u32(struct *property, int offset, u32 *out_val)
> {
> if (!property || !property->value)
> return -EINVAL;
> if ((offset + 1) * 4 > property->length)
> return -EINVAL;
> *out_val = of_read_number(property->value + (offset * 4), 1);
> return 0;
> }
> int dt_decode_u64(struct *property, int offset, u64 *out_val)
> {
> ...
> }
> int dt_decode_string(struct *property, int index, char **out_string);
> {
> ...
> }
>
> Plus a set of companion functions:
> int dt_getprop_u32(struct device_node *np, char *propname, int offset,
> u32 *out_val)
> {
> return dt_decode_u32(of_find_property(np, propname, NULL),
> offset, out_val);
> }
> int dt_getprop_u64(struct *device_node, char *propname, int offset,
> u64 *out_val);
> {
> ...
> }
> int dt_getprop_string(struct *device_node, char *propname, int index,
> char **out_string);
> {
> ..
Re: [RFC][PATCH 3/5] ARM: SAMSUNG: Adding IO mapping for OTG PHY.
Hi Praveen,
On Tue, Jun 21, 2011 at 12:33 PM, wrote:
>
> From: Praveen Paneri
>
> Adding virtual addresses for OTG PHY.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s5p64x0/cpu.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s5p64x0/cpu.c b/arch/arm/mach-s5p64x0/cpu.c
> index a5c0095..8dc6f20 100644
> --- a/arch/arm/mach-s5p64x0/cpu.c
> +++ b/arch/arm/mach-s5p64x0/cpu.c
> @@ -57,6 +57,11 @@ static struct map_desc s5p64x0_iodesc[] __initdata = {
> .pfn = __phys_to_pfn(S5P64X0_PA_VIC1),
> .length = SZ_16K,
> .type = MT_DEVICE,
> + }, {
> + .virtual = (unsigned long)S3C_VA_USB_HSPHY,
> + .pfn = __phys_to_pfn(S5P64X0_PA_USB_HSPHY),
> + .length = SZ_1M,
Do we really need 1M for this??
> + .type = MT_DEVICE,
> },
> };
>
> --
> 1.7.0.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tue, Jun 21, 2011 at 11:03:12AM +0530, Tushar Behera wrote: > Will it be possible to move PMIC specific defines to a common file > and make appropriate calls in the board-specific file? > In that way, we can re-use this PMIC code on some other boards (e.g. > Insignal low-cost board Origen featuring Exynos4210 also features > MAX8997). If the board is similar enough in design to be sharing the PMIC code that sounds like it should be sharing a lot more of the board setup code. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] serial: samsung: Keep a copy of platform data in driver's private data
Hi Grant,
On 20 June 2011 21:24, Grant Likely wrote:
> On Mon, Jun 20, 2011 at 5:02 AM, Thomas Abraham
> wrote:
>> The driver depends on pdev->dev.platform_data to retrive information
>> about the platform data even after the initialization. To add device
>> tree support, this has to be changed in way that the platform data
>> is avialable from driver's private data. This patch adds support
>> for keeping a copy of the plaform data in s3c24xx_uart_info and using
>> it when needed after the initialization.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/tty/serial/s5pv210.c | 12 ++--
>> drivers/tty/serial/samsung.c | 24
>> drivers/tty/serial/samsung.h | 4 +++-
>> 3 files changed, 33 insertions(+), 7 deletions(-)
>
> Hi Thomas.
>
> Don't forget you need to cc Alan Cox and the linux-serial mailing list
> for tty driver patches.
Ok. I will do that when I submit the next version of the patch.
>
> Comments below...
>
>>
>> diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
>> index d6b2423..3b2021a 100644
>> --- a/drivers/tty/serial/s5pv210.c
>> +++ b/drivers/tty/serial/s5pv210.c
>> @@ -27,9 +27,13 @@
>> + if (cfg) {
>> + memcpy((void *)&info->cfg, cfg, sizeof(struct
>> s3c2410_uartcfg));
>
> "info->cfg = *cfg;" should be sufficient.
>
>> + info->cfg.clocks = kzalloc(sizeof(struct
>> s3c24xx_uart_clksrc) *
>> + cfg->clocks_size, GFP_KERNEL);
>> + if (!info->cfg.clocks)
>> + return -ENOMEM;
>> + memcpy(info->cfg.clocks, cfg->clocks,
>> + sizeof(struct s3c24xx_uart_clksrc) *
>> cfg->clocks_size);
>> + }
>
> ewwh. There has to be a better way to do this. Part of the point of
> putting a copy of pdata into the private data structure is to simplify
> the driver so that kzallocing wouldn't be necessary. With that clock
> table, the driver actually gets more complex because both DT and
> non-DT paths now need to kzalloc a clock array.
>
> From what I can tell, the list of clocks on all mainlined platforms is
> a static array of one or two entries; min & max baud are always set to
> 0, and names are one of:
> - uclk & pclk
> - uclk
> - uclk1
> - fclk (with divisor either 10 or 0)
> - pclk_low & uclk1
>
> You could also make the clock structure a static array of 2 elements
> in the private data structure. That would simplify both this code and
> the followon DT patch.
>
> Also, peaking forward at what the 2nd patch does, I think that it
> might just be a little premature to try and decode the clock info from
> the DT. But I'll address that issue when replying to the second
> patch.
Thanks for the suggestion. I had not thought about these issues. One
possible option in this case is using Sylwester's suggestion of
changing exynos4 clkdev support to be similar to the omap clkdev
support. That way, an additional level of indirection is possible. The
uart driver could than be modified to lookup clock with generic names
like "uart_clksrc0", "uart_clksrc1" and "uart_clksrc2". With this,
there will be no need to pass clock names to the uart driver. I will
check if this can be done.
>
>> +
>> + cfg = &info->cfg;
>> if (cfg->hwport > CONFIG_SERIAL_SAMSUNG_UARTS) {
>> printk(KERN_ERR "%s: port %d bigger than %d\n", __func__,
>> cfg->hwport, CONFIG_SERIAL_SAMSUNG_UARTS);
>> + kfree(info->cfg.clocks);
>> return -ERANGE;
>> }
>>
>> @@ -1181,11 +1195,13 @@ EXPORT_SYMBOL_GPL(s3c24xx_serial_probe);
>> int __devexit s3c24xx_serial_remove(struct platform_device *dev)
>> {
>> struct uart_port *port = s3c24xx_dev_to_port(&dev->dev);
>> + struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
>>
>> if (port) {
>> s3c24xx_serial_cpufreq_deregister(to_ourport(port));
>> device_remove_file(&dev->dev, &dev_attr_clock_source);
>> uart_remove_one_port(&s3c24xx_uart_drv, port);
>> + kfree(info->cfg.clocks);
>> }
>>
>> return 0;
>> diff --git a/drivers/tty/serial/samsung.h b/drivers/tty/serial/samsung.h
>> index a69d9a5..4f2f6f5 100644
>> --- a/drivers/tty/serial/samsung.h
>> +++ b/drivers/tty/serial/samsung.h
>> @@ -24,6 +24,9 @@ struct s3c24xx_uart_info {
>>
>> unsigned int has_divslot:1;
>>
>> + /* copy of platform data */
>
> I'd change this to "copy of /configuration/ data" since the data
> doesn't necessarily come from the platform_data pointer anymore.
Ok. I will change this. Thanks for reviewing the patches.
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Exynos4 NURI: configure regulators and PMIC
On Tue, Jun 21, 2011 at 11:07:10AM +0900, MyungJoo Ham wrote: > Signed-off-by: MyungJoo Ham > Signed-off-by: Kyungmin Park This looks good, though you should also be able to make the supply lists into __initdata. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] Exynos4 NURI: support for NTC thermistor
On Tue, Jun 21, 2011 at 11:07:13AM +0900, MyungJoo Ham wrote:
> +#include
This doesn't appear to be in mainline.
> +/* NTC Thermistor */
> +static struct platform_device nuri_ncp15wb473_thermistor;
> +static int read_thermistor_uV(void)
Blank line between these two.
> +{
> + static struct s3c_adc_client *adc;
> + int val;
> + s64 converted;
> +
> + if (!adc) {
> + adc = s3c_adc_register(&nuri_ncp15wb473_thermistor,
> + NULL, NULL, 0);
> + if (IS_ERR_OR_NULL(adc)) {
> + pr_err("%s: Cannot get adc.\n", __func__);
> + return adc ? PTR_ERR(adc) : -ENODEV;
> + }
> + }
Why not do this in an initcall or in the device registration? This
looks like working around a limitation of the ntc_thermistor driver
which should be fixed as part of a mainline merge for that.
> +
> + if (IS_ERR_OR_NULL(adc))
> + return adc ? PTR_ERR(adc) : -ENODEV;
> +
> + val = s3c_adc_read(adc, 6);
> +
> + converted = 330LL * (s64) val;
> + converted >>= 12;
> +
> + pr_emerg("%s: %d -> %llduV\n", __func__, val, converted);
This looks like debug that was left in by mistake.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] Samsung SoC ADC: use regulator (VDD for ADC).
On Tue, Jun 21, 2011 at 10:58:43AM +0900, MyungJoo Ham wrote:
> + ret = regulator_enable(adc->vdd);
> + if (!ret)
> + goto err_ioremap;
> +
This test looks the wrong way round? regulator_enable() should return 0
on success but this will treat that as an error.
> static int s3c_adc_resume(struct platform_device *pdev)
> {
> struct adc_device *adc = platform_get_drvdata(pdev);
> + int ret;
>
> + ret = regulator_enable(adc->vdd);
> clk_enable(adc->clk);
> enable_irq(adc->irq);
>
> writel(adc->prescale | S3C2410_ADCCON_PRSCEN,
> adc->regs + S3C2410_ADCCON);
>
> - return 0;
> + return ret;
Seems better to return as soon as we notice the error, no point in
starting anything else up if we don't have power.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 0/5] USB: DWC OTG: Add dwc_otg driver for S5P6440 samsung SoC.
Hello, On Tuesday, June 21, 2011 9:04 AM p.pan...@samsung.com wrote: > From: Praveen Paneri > > These patches modify DWC OTG driver for ARM and add it for ARM based SoCs. > Currently it has been tested for Samsung's S5P6440. The development is > still > under process so these are not the best set of patches. They are just for > review > and not for merge. Intent of these patches is to show required > modifications > to make dwc_otg patches work on ARM. What are the differences between DWC OTG hardware and OTG hardware found in s3c64xx/s5pc100/s5pv210 and Exynos4 SoCs series? I've did a brief look at register definitions and most of them looks same. Can this driver be merged with s3c-hsotg.c driver? > Following features are tested for basic functions on SMDK6440 > board after modifications: > OTG HOST: HID and mass-storage > OTG DEVICE: mass-storage and adb Does it mean that HID or mass-storage (both host or gadget drivers) needs modifications to get them working with this DWC OTG driver? (snipped) Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
On Tue, Jun 21, 2011 at 12:33:46PM +0530, p.pan...@samsung.com wrote: > +#include > +#include > +#include > +#include > +#include > +#include > +#include linux/gpio.h please. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
Hi,
On Tue, Jun 21, 2011 at 12:33:46PM +0530, p.pan...@samsung.com wrote:
> From: Praveen Paneri
>
> A generic method to initialize and exit OTG PHY which can be
> used for all the samsung SoCs.
> OTG platdata structure added in platform to pass required
> platform specific functions and data to the driver.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s5p64x0/Makefile |1 +
> arch/arm/mach-s5p64x0/include/mach/map.h |4 +
> arch/arm/mach-s5p64x0/setup-otg-phy.c| 89
> ++
> arch/arm/plat-s5p/include/plat/otg.h | 29 ++
> 4 files changed, 123 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/setup-otg-phy.c
> create mode 100644 arch/arm/plat-s5p/include/plat/otg.h
>
> diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
> index ae6bf6f..611fb3a 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -28,3 +28,4 @@ obj-y += dev-audio.o
> obj-$(CONFIG_S3C64XX_DEV_SPI)+= dev-spi.o
>
> obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
> +obj-$(CONFIG_S3C_DEV_DWC_OTG)+= setup-otg-phy.o
> diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h
> b/arch/arm/mach-s5p64x0/include/mach/map.h
> index 95c9125..717c279 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/map.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/map.h
> @@ -44,6 +44,8 @@
> #define S5P64X0_PA_SPI1 0xEC50
>
> #define S5P64X0_PA_HSOTG 0xED10
> +#define S5P64X0_PA_USB_HSPHY 0xED20
> +#define S5P64X0_VA_USB_HSPHY S3C_ADDR_CPU(0x0010)
>
> #define S5P64X0_PA_HSMMC(x) (0xED80 + ((x) * 0x10))
>
> @@ -71,6 +73,8 @@
> #define S5P_PA_TIMER S5P64X0_PA_TIMER
>
> #define SAMSUNG_PA_ADC S5P64X0_PA_ADC
> +#define S3C_PA_USB_HSOTG S5P64X0_PA_HSOTG
> +#define S3C_VA_USB_HSPHYS5P64X0_VA_USB_HSPHY
>
> /* UART */
>
> diff --git a/arch/arm/mach-s5p64x0/setup-otg-phy.c
> b/arch/arm/mach-s5p64x0/setup-otg-phy.c
drivers should not live in arch/arm/*, why don't you move this to
drivers/usb/otg where the PHYs are staying right now ?
> new file mode 100644
> index 000..c351554
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/setup-otg-phy.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics Co.Ltd
> + * Author: Praveen Paneri
> + * based on arch/arm/mach-exynos4/setup-usb-phy.c
> + * written by Joonyoung Shim
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct clk *otg_clk;
> +static int s5p64x0_otg_phy_init(struct platform_device *pdev)
> +{
> + int err;
> +
> + otg_clk = clk_get(&pdev->dev, "otg");
> + if (IS_ERR(otg_clk)) {
> + dev_err(&pdev->dev, "Failed to get otg clock\n");
> + return PTR_ERR(otg_clk);
> + }
> +
> + err = clk_enable(otg_clk);
> + if (err) {
> + clk_put(otg_clk);
> + return err;
> + }
> +
> + if (gpio_is_valid(S5P6440_GPN(1))) {
> + err = gpio_request(S5P6440_GPN(1), "GPN");
> + if (err)
> + printk(KERN_ERR "failed to request GPN1\n");
> + gpio_direction_output(S5P6440_GPN(1), 1);
> + }
> +
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> + writel(0x0, S3C_PHYPWR); /* Power up */
> + writel(S3C_PHYCLK_CLKSEL_12M, S3C_PHYCLK);
> + writel(S3C_RSTCON_PHY, S3C_RSTCON);
> +
> + udelay(50);
> + writel(0x0, S3C_RSTCON);
> + udelay(50);
> +
> + return 0;
> +}
> +
> +static int s5p64x0_otg_phy_exit(struct platform_device *pdev)
> +{
> + writel(readl(S3C_PHYPWR)|(0x1F<<1), S3C_PHYPWR);
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> +
> + gpio_free(S5P6440_GPN(1));
> +
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
> +
> + return 0;
> +}
> +
> +int s5p_usb_phy_init(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_init(pdev);
> +
> + return -EINVAL;
> +}
> +
> +int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_exit(pdev);
> +
> + return -EINVAL;
> +}
no way to make this a real driver instead of set a exported functions ??
--
balbi
signature.asc
Description: Digital signature
Re: [RFC][PATCH 1/5] USB: DWC OTG: Modification in DWC OTG driver for ARM based SoCs.
Hi,
On Tue, Jun 21, 2011 at 12:33:43PM +0530, p.pan...@samsung.com wrote:
> From: Praveen Paneri
>
> This patch modifies DWC OTG for ARM based SoCs. Currently it has
> been tested for Samsung S5P6440. Can easily be built for others
> as well.
>
> Following features are tested for basic functions on SMDK6440
> board after modifications:
> OTG HOST: HID and mass-storage
> OTG DEVICE: mass-storage and adb
>
> Signed-off-by: Praveen Paneri
this is wrong is so many levels... We shouldn't be adding ifdefs to
allow the driver to be compiled for multiple architectures. The correct
way to handle this, is to phase out the core driver from the SoC- or
PCI-specific parts and make that a glue layer that bridges to the core
driver.
I'm writing the driver for a similar core, the DWC USB3, take a look at
my dwc3 branch [1] to see how this should be done.
> diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
> index ffbe6dd..b0dcae9 100644
> --- a/drivers/usb/dwc/apmppc.c
> +++ b/drivers/usb/dwc/apmppc.c
> @@ -50,9 +50,6 @@
> * this file system to perform diagnostics on the driver components or the
> * device.
> */
> -
> -#include
> -
> #include "driver.h"
>
> #define DWC_DRIVER_VERSION "1.05"
> @@ -110,6 +107,9 @@ static int __devexit dwc_otg_driver_remove(struct
> platform_device *ofdev)
> {
> struct device *dev = &ofdev->dev;
> struct dwc_otg_device *dwc_dev = dev_get_drvdata(dev);
> +#ifdef CONFIG_CPU_S5P6440
> + struct s5p_otg_platdata *pdata = ofdev->dev.platform_data;
> +#endif
NAK
> @@ -152,6 +152,11 @@ static int __devexit dwc_otg_driver_remove(struct
> platform_device *ofdev)
>
> /* Clear the drvdata pointer. */
> dev_set_drvdata(dev, NULL);
> +#ifdef CONFIG_CPU_S5P6440
> + /* OTG Phy off */
> + if (pdata && pdata->phy_exit)
> + pdata->phy_exit(ofdev, S5P_USB_PHY_DEVICE);
> +#endif
NAK
> @@ -169,12 +174,14 @@ static int __devinit dwc_otg_driver_probe(struct
> platform_device *ofdev)
> int retval;
> struct dwc_otg_device *dwc_dev;
> struct device *dev = &ofdev->dev;
> +#ifdef CONFIG_CPU_S5P6440
> + struct s5p_otg_platdata *pdata = ofdev->dev.platform_data;
> +#endif
NAK
> @@ -182,15 +189,24 @@ static int __devinit dwc_otg_driver_probe(struct
> platform_device *ofdev)
> goto fail_dwc_dev;
> }
>
> +#ifdef CONFIG_CPU_S5P6440
> + /* OTG Phy init */
> + if (pdata && pdata->phy_init)
> + pdata->phy_init(ofdev, S5P_USB_PHY_DEVICE);
> +#endif
> /* Retrieve the memory and IRQ resources. */
> +#ifdef CONFIG_ARM
> + dwc_dev->irq = ofdev->resource[1].start;
> +#else
> dwc_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> +#endif
NAK
> +#ifndef CONFIG_ARM
NAK
> @@ -200,8 +216,14 @@ static int __devinit dwc_otg_driver_probe(struct
> platform_device *ofdev)
> dev_dbg(dev, "OTG - ioresource_mem start0x%llx: end:0x%llx\n",
> (unsigned long long)res.start, (unsigned long long)res.end);
>
> +
> dwc_dev->phys_addr = res.start;
> dwc_dev->base_len = res.end - res.start + 1;
> +#else
> + dwc_dev->phys_addr = ofdev->resource[0].start;
> + dwc_dev->base_len = ofdev->resource[0].end -
> + ofdev->resource[0].start + 1;
> +#endif
NAK
> @@ -296,6 +318,7 @@ static int __devinit dwc_otg_driver_probe(struct
> platform_device *ofdev)
> dwc_dev->hcd = NULL;
> goto fail_hcd;
> }
> +#ifndef CONFIG_ARM
NAK
> @@ -316,6 +339,7 @@ static int __devinit dwc_otg_driver_probe(struct
> platform_device *ofdev)
> dwc_dev->hcd->cp_irq_installed = 1;
> }
> }
> +#endif
NAK
> diff --git a/drivers/usb/dwc/cil.h b/drivers/usb/dwc/cil.h
> index 80b7da5..c1a11f1 100644
> --- a/drivers/usb/dwc/cil.h
> +++ b/drivers/usb/dwc/cil.h
> @@ -37,6 +37,15 @@
> #if !defined(__DWC_CIL_H__)
> #define __DWC_CIL_H__
> #include
> +#ifdef CONFIG_ARM
> +#include
> +#include
> +#include
> +#include
> +#include
> +#else
> +#include
> +#endif
I can't even say how ugly this is.
> diff --git a/drivers/usb/dwc/param.c b/drivers/usb/dwc/param.c
> index 523f0db..b48c510 100644
> --- a/drivers/usb/dwc/param.c
> +++ b/drivers/usb/dwc/param.c
> @@ -116,8 +116,12 @@ static int set_valid_tx_fifo_sizes(struct core_if
> *core_if)
> * This function is called during module intialization to verify that
> * the module parameters are in a valid state.
> */
> -int __devinit check_parameters(struct core_if *core_if)
> +int __devinit check_parameters(struct core_if *core_if,
> + struct platform_device *ofdev)
> {
> +#ifdef CONFIG_CPU_S5P6440
> + struct s5p_otg_platdata *pdata = ofdev->dev.platform_data;
> +#endif
NAK.
> @@ -145,6 +149,23 @@ int __devinit check_parameters(struct core_if *core_if)
>*/
> dwc_otg_module_params.enable_dyn
Re: [RFC][PATCH 2/5] ARM: SAMSUNG: Changing the build condition of OTG platform device for samsung.
Hi,
On Tue, Jun 21, 2011 at 12:33:44PM +0530, p.pan...@samsung.com wrote:
> From: Praveen Paneri
>
> Adding dwc driver name in existing platform device
> to probe DWC OTG driver.
> Introduced otg_set_platdata function to pass platform data
> Added selectable config option to add DWC OTG driver for different
> machines.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/plat-samsung/Kconfig |6 ++
> arch/arm/plat-samsung/Makefile|1 +
> arch/arm/plat-samsung/dev-usb-hsotg.c | 20
> 3 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 4d79519..58ed8b1 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -227,6 +227,12 @@ config S3C_DEV_USB_HSOTG
> help
> Compile in platform device definition for USB high-speed OtG
>
> +config S3C_DEV_DWC_OTG
> + bool
> + help
> + Compile in platform device definition for DWC OTG. This
> + will make it selectable for different machines.
> +
> config S3C_DEV_WDT
> bool
> default y if ARCH_S3C2410
> diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
> index 53eb15b..785ca79 100644
> --- a/arch/arm/plat-samsung/Makefile
> +++ b/arch/arm/plat-samsung/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_S3C_DEV_FB)+= dev-fb.o
> obj-y+= dev-uart.o
> obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
> obj-$(CONFIG_S3C_DEV_USB_HSOTG) += dev-usb-hsotg.o
> +obj-$(CONFIG_S3C_DEV_DWC_OTG)+= dev-usb-hsotg.o
> obj-$(CONFIG_S3C_DEV_WDT)+= dev-wdt.o
> obj-$(CONFIG_S3C_DEV_NAND) += dev-nand.o
> obj-$(CONFIG_S3C_DEV_ONENAND)+= dev-onenand.o
> diff --git a/arch/arm/plat-samsung/dev-usb-hsotg.c
> b/arch/arm/plat-samsung/dev-usb-hsotg.c
> index 33a844a..7e6228b 100644
> --- a/arch/arm/plat-samsung/dev-usb-hsotg.c
> +++ b/arch/arm/plat-samsung/dev-usb-hsotg.c
> @@ -20,6 +20,8 @@
> #include
>
> #include
> +#include
> +#include
>
> static struct resource s3c_usb_hsotg_resources[] = {
> [0] = {
> @@ -37,7 +39,12 @@ static struct resource s3c_usb_hsotg_resources[] = {
> static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);
>
> struct platform_device s3c_device_usb_hsotg = {
> +#ifdef CONFIG_S3C_DEV_USB_HSOTG
> .name = "s3c-hsotg",
> +#endif
> +#ifdef CONFIG_S3C_DEV_DWC_OTG
> + .name = "dwc_otg",
> +#endif
no, don't do that. See we're going through a big re-factor on the gadget
framework to allow multiple UDC drivers to be compiled as modules. The
idea is to be able to have distro-like kernels for embedded too.
Take a look at my gadget branch [1] and see how the gadget controllers
are modified to start allowing that.
I also have patch to the Kconfig allowing all controllers to be enabled
as modules, I just need some more time to figure out one warning on the
renenesas controller.
IOW, it's best to add both platform devices. Or move to device tree.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/5] ARM: EXYNOS4: Change clock name for FIMD
On 06/21/2011 06:18 AM, JinGoo Han wrote: >>> --+---++ >>> exynos4 | ACLK_160 (fimd) | O | SCLK_FIMD (sclk_fimd)| >>> --++---+ >> ^^^ >> In mach-exynos4/clock.c this clock is described as ACLK_133 (lcd) > I cannot find it. > Let me know where 'fimd' is described as ACLK_133. > Anyway, according to datasheet, this clock is described as ACLK_160. My apologies, I had been looking not at the mainline source, just some internal tree. And that's right it is described as ACLK_160 in the datasheet. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
Hi Jingoo Han, On Tuesday 21 June 2011 09:38 AM, JinGoo Han wrote: > Hi, Tushar Behera. > >> -Original Message- >> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- >> ow...@vger.kernel.org] On Behalf Of Tushar Behera >> Sent: Tuesday, June 21, 2011 12:47 PM >> To: Jingoo Han >> Cc: Kukjin Kim; Paul Mundt; linux-samsung-soc@vger.kernel.org; Jonghun Han; >> Anand Kumar N; Thomas Abraham; Sylwester Nawrocki; Marek Szyprowski; >> Kyungmin Park; Inki Dae; ARM Linux; Ben Dooks >> Subject: Re: [PATCH v2 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 >> FIMD and LTE480WV platform-lcd >> >> Hi, >> >> On Friday 17 June 2011 06:32 PM, Jingoo Han wrote: >>> From: Jonghun Han >>> >>> This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel. >>> >>> Signed-off-by: Jonghun Han >>> Signed-off-by: Jingoo Han >>> --- >>>arch/arm/mach-exynos4/mach-smdkc210.c | 74 >> + >>>arch/arm/mach-exynos4/mach-smdkv310.c | 74 >> + >>>2 files changed, 148 insertions(+), 0 deletions(-) >>> >> >> There are variants of SMDKV310 boards that don't use LTE480WV LCD panel. >> Won't it be better to provide an option of selecting the LCD panel >> through config file and adding the panel code accordingly? >> >> Also, the panel code can be consolidated at a single location and used >> in appropriate machine files. >> > Do you have a patch about that? As of now, I don't have any patch for this. > If you make a patch about your suggestion, please submit it. I don't have a SMDKV310 with LTE480WV LCD panel, so I might still not be able to test that patch. -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
