* [PATCH V6 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
From: Jingoo Han @ 2011-06-22 12:18 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev,
Jonghun Han
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jingoo Han
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 <jg1.han@samsung.com>
---
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 int is_2443:1;
@@ -98,6 +99,7 @@ struct s3c_fb_variant {
unsigned int has_prtcon:1;
unsigned int has_shadowcon:1;
+ unsigned int has_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_variant variant;
@@ -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);
+ clk_put(sfb->lcd_clk);
+ }
+
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
@@ -1510,6 +1541,9 @@ static int s3c_fb_suspend(struct device *dev)
s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
}
+ if (!sfb->variant.has_clksel)
+ clk_disable(sfb->lcd_clk);
+
clk_disable(sfb->bus_clk);
return 0;
}
@@ -1524,6 +1558,9 @@ static int s3c_fb_resume(struct device *dev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel)
+ clk_enable(sfb->lcd_clk);
+
/* setup gpio and output polarity controls */
pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
@@ -1569,6 +1606,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
}
+ if (!sfb->variant.has_clksel)
+ clk_disable(sfb->lcd_clk);
+
clk_disable(sfb->bus_clk);
return 0;
}
@@ -1583,6 +1623,9 @@ static int s3c_fb_runtime_resume(struct device *dev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel)
+ clk_enable(sfb->lcd_clk);
+
/* setup gpio and output polarity controls */
pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
@@ -1755,6 +1798,7 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx = {
},
.has_prtcon = 1,
+ .has_clksel = 1,
},
.win[0] = &s3c_fb_data_64xx_wins[0],
.win[1] = &s3c_fb_data_64xx_wins[1],
@@ -1785,6 +1829,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 = {
},
.has_prtcon = 1,
+ .has_clksel = 1,
},
.win[0] = &s3c_fb_data_s5p_wins[0],
.win[1] = &s3c_fb_data_s5p_wins[1],
@@ -1815,6 +1860,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
},
.has_shadowcon = 1,
+ .has_clksel = 1,
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+ .win[3] = &s3c_fb_data_s5p_wins[3],
+ .win[4] = &s3c_fb_data_s5p_wins[4],
+};
+
+static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+
+ .has_shadowcon = 1,
},
.win[0] = &s3c_fb_data_s5p_wins[0],
.win[1] = &s3c_fb_data_s5p_wins[1],
@@ -1843,6 +1919,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
[0] = 0x400,
[1] = 0x800,
},
+ .has_clksel = 1,
},
.win[0] = &(struct s3c_fb_win_variant) {
.palette_sz = 256,
@@ -1870,6 +1947,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "s5pv210-fb",
.driver_data = (unsigned long)&s3c_fb_data_s5pv210,
}, {
+ .name = "exynos4-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos4,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
},
--
1.7.1
^ permalink raw reply related
* [PATCH V6 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
From: Jingoo Han @ 2011-06-22 12:18 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jonghun Han, Jingoo Han
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/mach-smdkc210.c | 76 +++++++++++++++++++++++++++++++++
arch/arm/mach-exynos4/mach-smdkv310.c | 76 +++++++++++++++++++++++++++++++++
2 files changed, 152 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c b/arch/arm/mach-exynos4/mach-smdkc210.c
index e645f7a..714f6ae 100644
--- a/arch/arm/mach-exynos4/mach-smdkc210.c
+++ b/arch/arm/mach-exynos4/mach-smdkc210.c
@@ -9,7 +9,9 @@
*/
#include <linux/serial_core.h>
+#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/lcd.h>
#include <linux/mmc/host.h>
#include <linux/platform_device.h>
#include <linux/smsc911x.h>
@@ -19,16 +21,20 @@
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
+#include <video/platform_lcd.h>
+
#include <plat/regs-serial.h>
#include <plat/regs-srom.h>
#include <plat/exynos4.h>
#include <plat/cpu.h>
#include <plat/devs.h>
+#include <plat/fb.h>
#include <plat/sdhci.h>
#include <plat/iic.h>
#include <plat/pd.h>
#include <mach/map.h>
+#include <mach/regs-fb.h>
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -111,6 +117,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 +234,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,
};
@@ -210,7 +281,12 @@ static void __init smdkc210_machine_init(void)
s3c_sdhci2_set_platdata(&smdkc210_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkc210_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(&smdkc210_lcd0_pdata);
+
platform_add_devices(smdkc210_devices, ARRAY_SIZE(smdkc210_devices));
+
+ exynos4_fimd0_setup_clock(&s5p_device_fimd0.dev, "mout_mpll",
+ 134 * MHZ);
}
MACHINE_START(SMDKC210, "SMDKC210")
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c
index 1526764..31a0945 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -9,7 +9,9 @@
*/
#include <linux/serial_core.h>
+#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/lcd.h>
#include <linux/mmc/host.h>
#include <linux/platform_device.h>
#include <linux/smsc911x.h>
@@ -20,17 +22,21 @@
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
+#include <video/platform_lcd.h>
+
#include <plat/regs-serial.h>
#include <plat/regs-srom.h>
#include <plat/exynos4.h>
#include <plat/cpu.h>
#include <plat/devs.h>
+#include <plat/fb.h>
#include <plat/keypad.h>
#include <plat/sdhci.h>
#include <plat/iic.h>
#include <plat/pd.h>
#include <mach/map.h>
+#include <mach/regs-fb.h>
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKV310_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -113,6 +119,69 @@ static struct s3c_sdhci_platdata smdkv310_hsmmc3_pdata __initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+ if (power) {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 1);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ /* fire nRESET on power up */
+ gpio_request(EXYNOS4_GPX0(6), "GPX0");
+
+ gpio_direction_output(EXYNOS4_GPX0(6), 1);
+ mdelay(100);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 0);
+ mdelay(10);
+
+ gpio_set_value(EXYNOS4_GPX0(6), 1);
+ mdelay(10);
+
+ gpio_free(EXYNOS4_GPX0(6));
+ } else {
+#if !defined(CONFIG_BACKLIGHT_PWM)
+ gpio_request(EXYNOS4_GPD0(1), "GPD0");
+ gpio_direction_output(EXYNOS4_GPD0(1), 0);
+ gpio_free(EXYNOS4_GPD0(1));
+#endif
+ }
+}
+
+static struct plat_lcd_data smdkv310_lcd_lte480wv_data = {
+ .set_power = lcd_lte480wv_set_power,
+};
+
+static struct platform_device smdkv310_lcd_lte480wv = {
+ .name = "platform-lcd",
+ .dev.parent = &s5p_device_fimd0.dev,
+ .dev.platform_data = &smdkv310_lcd_lte480wv_data,
+};
+
+static struct s3c_fb_pd_win smdkv310_fb_win0 = {
+ .win_mode = {
+ .left_margin = 13,
+ .right_margin = 8,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+ },
+ .max_bpp = 32,
+ .default_bpp = 24,
+};
+
+static struct s3c_fb_platdata smdkv310_lcd0_pdata __initdata = {
+ .win[0] = &smdkv310_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct resource smdkv310_smsc911x_resources[] = {
[0] = {
.start = EXYNOS4_PA_SROM_BANK(1),
@@ -187,6 +256,8 @@ static struct platform_device *smdkv310_devices[] __initdata = {
&exynos4_device_pd[PD_GPS],
&exynos4_device_sysmmu,
&samsung_asoc_dma,
+ &s5p_device_fimd0,
+ &smdkv310_lcd_lte480wv,
&smdkv310_smsc911x,
};
@@ -232,9 +303,14 @@ static void __init smdkv310_machine_init(void)
s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkv310_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
+
samsung_keypad_set_platdata(&smdkv310_keypad_data);
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
+
+ exynos4_fimd0_setup_clock(&s5p_device_fimd0.dev, "mout_mpll",
+ 134 * MHZ);
}
MACHINE_START(SMDKV310, "SMDKV310")
--
1.7.1
^ permalink raw reply related
* [PATCH V6 0/5] ARM: EXYNOS4: Add support EXYNOS4 FIMD
From: JinGoo Han @ 2011-06-22 12:21 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc@vger.kernel.org,
"linux-fbdev@vger.kernel.org" <linux-f>
Cc: ANAND KUMAR N, Sylwester Nawrocki, THOMAS P ABRAHAM,
Marek Szyprowski, Kyungmin Park, In-Ki Dae, ARM Linux, Ben Dooks,
JinGoo Han
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1439 bytes --]
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 <jonghun.han@samsung.com>
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().
v6: rename dev-fimd-24bpp.c to dev-fimd0.c
add 'exynos4_fimd0_setup_clock()' to dev-fimd0.c to setup parent clock.
o To Kukjin Kim
[PATCH V6 1/5] ARM: EXYNOS4: Change clock name for FIMD
[PATCH V6 2/5] ARM: EXYNOS4: Add FIMD resource definition
[PATCH V6 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD
[PATCH V6 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd
o To Paul Mundt
[PATCH V6 4/5] video: s3c-fb: Add support EXYNOS4 FIMDÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±ýöÝzÿâØ^nr¡ö¦zË\x1aëh¨èÚ&£ûàz¿äz¹Þú+Ê+zf£¢·h§~Ûiÿÿïêÿêçz_è®\x0fæj:+v¨þ)ߣøm
^ permalink raw reply
* Re: Some questions about DRM(Direct Rendering Manager)
From: Rob Clark @ 2011-06-22 13:07 UTC (permalink / raw)
To: InKi Dae
Cc: linux-fbdev, Kukjin Kim, Kyungmin Park, dri-devel, daeinki,
Paul Mundt, jesse.barnes, linux-arm-kernel
In-Reply-To: <BANLkTim6xvD5U9GJ2pHu-=OrYccRHSj7Fg@mail.gmail.com>
fwiw, drm_fb_helper_single_fb_probe() calls register_framebuffer() (if
that was the question?)
BR,
-R
2011/6/22 InKi Dae <daeinki@gmail.com>:
> It adds dri-devel@lists.freedesktop.org to this mail thread.
> Thank you.
>
> 2011년 6월 22일 오후 3:04, daeinki <inki.dae@samsung.com>님의 말:
>> below is additional comments.
>>
>> daeinki 쓴 글:
>>> Hi all,
>>>
>>> I'm writing Samsung SoC based DRM framework and this one includes FIMD
>>> and HDMI driver as hardware dependent modules. and for now, encoder,
>>> connector, crtc and fb module has been materialized almost. but I'm
>>> contending with framebuffer setting issue(created fb_info should be
>>> registered to linux framebuffer through register_framebuffer() or not)as
>>> default framebuffer at booting time.
>>>
>>> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's
>>> fb_probe callback is called and this one creates new framebuffer and
>>> returns a value more then 0 if true. internally, this process creates an
>>> fb_info object and drm_framebuffer and then drm_framebuffer would be
>>> added to mode_config.fb_list of the drm_device.
>>>
>> it's my mistake. return value is 0 if true, nonzero otherwise.
>>
>>> a value returned, new_fb is used to decide that it calls
>>> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am
>>> confused it's a good way to call register_framebuffer() otherwise
>>> drm_fb_helper_set_par(). if register_framebuffer() is called then I
>>> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be
>>> called somewhere subsequently to apply this one to real hardware because
>>> previous process is just for maintaining data logically.(not set up data
>>> to h/w)
>>>
>>> it's a right way to call register_framebuffer() and then
>>> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just
>>> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring
>>> register_framebuffer()? and what is the purpose of using
>>> register_framebuffer()?
>>>
>> I understood that if fb_probe() callback is fail then fb_info object is
>> registered to linux framebuffer through register_framebuffer()
>> otherwise(if true) hardware configuration would be completed by
>> drm_fb_helper_set_par() so the reason of using register_framebuffer() is
>> that the case of failing fb_probe() callback, it is for drawing on only
>> linux framebuffer. is it right?
>>
>>> In my case, first, register_framebuffer() is called and then if desired
>>> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id,
>>> it gets mode_set of drm_fb_helper->crtc_info[n] and then it calls
>>> drm_crtc_helper_set_config(mode_set). at this time, all the hardware
>>> configurations would be completed.
>>>
>>> thank you in advance.
>>>
>>> Best Regards
>>> Inki Dae.
>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD
From: Anand Kumar N @ 2011-06-22 13:37 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Jingoo Han, Kukjin Kim, Paul Mundt, linux-samsung-soc,
linux-fbdev, Jonghun Han, Thomas Abraham, Sylwester Nawrocki,
Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks
In-Reply-To: <BANLkTimPjo+WefApQLe=HKbYLCwmo_gGRw@mail.gmail.com>
Hi Marek/Jingoo,
On Wed, Jun 22, 2011 at 3:17 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hello,
>
> On Wednesday, June 22, 2011 8:42 AM Jingoo Han wrote:
>
>> From: Jonghun Han <jonghun.han@samsung.com>
(snipped)
Instead of hardcoding the parent clock in platform/bootloader code ,is
it not possible to select/set the
parent clock based on the pixel clk(plat data) having the least delta
with the 9 src clks.with this change I have checked it for WA101S.
These are the changes I am proposing..
arch/arm/mach-exynos4/clock.c
+struct clk *clkset_sclk_fimd0_list[] = {
+ [0] = &clk_sclk_xxti,
+ [1] = &clk_sclk_xusbxti,
+ [2] = &clk_sclk_hdmi27m,
+ [3] = &clk_sclk_usbphy0,
+ [4] = &clk_sclk_usbphy1,
+ [5] = &clk_sclk_hdmiphy,
+ [6] = &clk_mout_mpll.clk,
+ [7] = &clk_mout_epll.clk,
+ [8] = &clk_sclk_vpll.clk,
+};
arch/arm/mach-exynos4/mach-smdkv310.c
+static int fimd_s3c_consider_clock(struct device *sfb,int src
,unsigned int wanted)
+{
+ unsigned long rate = 0;
+ int div =1;
+ struct clk *mout_mpll = NULL;
+
+ if(clkset_sclk_fimd0_list[src]){
+ mout_mpll = clk_get(sfb,clkset_sclk_fimd0_list[src]->name);
+ if (IS_ERR(mout_mpll)) {
+ dev_err(sfb, "failed to clk_get
%s\n",clkset_sclk_fimd0_list[src]->name);
+ }
+
+ rate = clk_get_rate(mout_mpll);
+
+ for (div = 1; div < 256; div *= 2) {
+ if ((rate / div) <= wanted)
+ break;
+ }
+
+
+ }
+ return (wanted - (rate / div));
+}
+
+int exynos4_fimd0_find_clock(struct platform_device *pdev,struct clk
**lcd_clk,unsigned int clock(pixel clock needed for the lcd))
+{
+ int best = 0;
+ int delta = 0;
+ int best_src = 0;
+ int src;
+ struct clk *best_clk_src = NULL;
+ struct clk *clk = NULL;
+
+ if (clock = 0)
+ return 0;
+
+ for (src = 0; src < MAX_NUM_CLKS ;src++) {
+ delta = fimd_s3c_consider_clock(&pdev->dev,src,clock);
+ if (delta < best) {
+ best = delta;
+ best_src = src;
+ }
+ }
+ clk = clk_get(&pdev->dev, "sclk_fimd");
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "failed to get sclk for fimd\n");
+ goto err_clk2;
+ }
+
+ best_clk_src clk_get(&pdev->dev,clkset_sclk_fimd0_list[best_src]->name);
+ if (IS_ERR(best_clk_src)) {
+ dev_err(&pdev->dev, "failed to get best_src\n");
+ goto err_clk1;
+ }
+ clk_set_parent(clk,best_clk_src);
+ *lcd_clk = clk;
+ clk_put(best_clk_src);
+ clk_enable(clk);
+ dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", clock);
+
+err_clk1:
+ clk_put(best_clk_src);
+err_clk2:
+ clk_put(clk);
+
+ return -EINVAL;
+}
I have based these patches on the v1 version of this patch.I can base
these changes
on your latest changes(v6) and send as a patch.
>> +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 = 134000000;
>> +
>> + 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;
>> +}
>> +
>
> I'm not sure if mach-smdk*.c is the right place for the above code.
> IMHO all the code that configures very low level, board specific parameters
> (like clocks and their relations) should be performed in boot loarder.
>
I feel pushing the clock enabling into the bootloader,will create an
unneccesary dependcy for the lcd on the u-boot.
> (snipped)
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
>
regards
anand
^ permalink raw reply
* [PATCH] udlfb - Fix for problem with monitor resolution detection /
From: Katsak, William Alexander (Bill) @ 2011-06-22 17:15 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
Hello,
This is my first contribution on this list, so please let me know if I am off with any procedures or anything.
This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuffer resolution. The problem occured with a Plugable UGA-2K-A connected to a Samsung EX2220X display. In this situation, the driver always allocates a 1600x1200 framebuffer, even after it indicates in its output that 1920x1080 is a valid mode. If my interpretation of the code is correct, the problem was in the block that selects the best mode. The existing code unset the FB_MISC_1ST_DETAIL flag if ANY of the modes is determined to be invalid (on my adapter, 1680x1680 is invalid). This in turn causes the fb_find_best_display() function to disregard the first mode (1920x1080). The comment for the line that unsets the flag implies that this should happen if we have removed the top/best mode...however, this else block is not qualified, and happens if we remove any mode. I simply put in a condition so that we only unset this flag if the first mode is invalid.
Thanks in advance for your feedback.
Bill Katsak
Bell Laboratories
Alcatel-Lucent, Inc.
william.katsak@alcatel-lucent.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: udlfb_resolution_fix.patch --]
[-- Type: text/x-patch; name="udlfb_resolution_fix.patch", Size: 1499 bytes --]
From c3327c41877637e80f9f06a8ce3bdcfe8b4e6fa4 Mon Sep 17 00:00:00 2001
From: William Katsak <william.katsak@alcatel-lucent.com>
Date: Wed, 22 Jun 2011 12:48:11 -0400
Subject: [PATCH] This patch fixes a problem where a DisplayLink device autoselects a
suboptimal framebuffer resolution.
The situation in which the problem occurred was with a Plugable UGA-2K-A
connected to a Samsung EX2220X display. The driver indicates that
1920x1080 is a valid mode (the first mode available, in fact), but
proceeds to set the framebuffer size to 1600x1200.
The patch corrects what seems to be a logic error, regarding unsetting
the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid.
The existing code unset the flag if ANY mode was invalid.
---
drivers/video/udlfb.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 52b0f3e..816a4fd 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1233,8 +1233,12 @@ static int dlfb_setup_modes(struct dlfb_data *dev,
if (dlfb_is_valid_mode(&info->monspecs.modedb[i], info))
fb_add_videomode(&info->monspecs.modedb[i],
&info->modelist);
- else /* if we've removed top/best mode */
- info->monspecs.misc &= ~FB_MISC_1ST_DETAIL;
+ else {
+ if (i == 0)
+ /* if we've removed top/best mode */
+ info->monspecs.misc
+ &= ~FB_MISC_1ST_DETAIL;
+ }
}
default_vmode = fb_find_best_display(&info->monspecs,
--
1.7.3.4
^ permalink raw reply related
* I am Mrs Helen Moore, a devoted Christian. I have chosen you for an inheritance. Please contact me f
From: Sparks, Karen @ 2011-06-22 17:42 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-22 20:11 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
lethal@linux-sh.org, sun york-R58495
In-Reply-To: <4E012586.7050808@freescale.com>
On Tue, 21 Jun 2011 23:13:11 +0000
Tabi Timur-B04825 <B04825@freescale.com> wrote:
> Anatolij Gustschin wrote:
> > No! We are using ioctl interface of this driver in many video
> > rendering applications on overlay planes on huge number of boards.
> > So, please don't remove it.
>
> Ok, I had no idea anyone was using it.
>
> Can you email me details about how you use the ioctl interface? If I can't
> remove it, maybe I can clean it up.
Following DIU specific ioctls are used:
MFB_SET_CHROMA_KEY
MFB_SET_PIXFMT
MFB_GET_PIXFMT
MFB_SET_AOID
MFB_GET_AOID
MFB_GET_ALPHA
MFB_SET_ALPHA
Other ioctls can be removed. I'm not sure if someone
uses FBIOGET_GWINFO. If there are no objections from
other people, it can also be dropped.
^ permalink raw reply
* Re: [PATCH] udlfb - Fix for problem with monitor resolution detection
From: Florian Tobias Schandinat @ 2011-06-22 20:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <76676AFCFD6F05458E27320F9BB714A825120FC640@USNAVSXCHMBSD1.ndc.alcatel-lucent.com>
Hi,
On 06/22/2011 05:15 PM, Katsak, William Alexander (Bill) wrote:
> This is my first contribution on this list, so please let me know if I am off with any procedures or anything.
Please send patches inline to make review easier, preferably using "git
send-email" to avoid broken patches.
> From c3327c41877637e80f9f06a8ce3bdcfe8b4e6fa4 Mon Sep 17 00:00:00 2001
> From: William Katsak<william.katsak@alcatel-lucent.com>
> Date: Wed, 22 Jun 2011 12:48:11 -0400
> Subject: [PATCH] This patch fixes a problem where a DisplayLink device autoselects a
> suboptimal framebuffer resolution.
>
> The situation in which the problem occurred was with a Plugable UGA-2K-A
> connected to a Samsung EX2220X display. The driver indicates that
> 1920x1080 is a valid mode (the first mode available, in fact), but
> proceeds to set the framebuffer size to 1600x1200.
>
> The patch corrects what seems to be a logic error, regarding unsetting
> the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid.
> The existing code unset the flag if ANY mode was invalid.
You're missing a Signed-off-line, see Documentation/SubmittingPatches in your
kernel sources.
Best regards,
Florian Tobias Schandinat
> ---
> drivers/video/udlfb.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index 52b0f3e..816a4fd 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1233,8 +1233,12 @@ static int dlfb_setup_modes(struct dlfb_data *dev,
> if (dlfb_is_valid_mode(&info->monspecs.modedb[i], info))
> fb_add_videomode(&info->monspecs.modedb[i],
> &info->modelist);
> - else /* if we've removed top/best mode */
> - info->monspecs.misc&= ~FB_MISC_1ST_DETAIL;
> + else {
> + if (i = 0)
> + /* if we've removed top/best mode */
> + info->monspecs.misc
> + &= ~FB_MISC_1ST_DETAIL;
> + }
> }
>
> default_vmode = fb_find_best_display(&info->monspecs,
^ permalink raw reply
* Re: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD
From: Sylwester Nawrocki @ 2011-06-22 20:33 UTC (permalink / raw)
To: Anand Kumar N
Cc: Marek Szyprowski, Jingoo Han, Kukjin Kim, Paul Mundt,
linux-samsung-soc, linux-fbdev, Jonghun Han, Thomas Abraham,
Sylwester Nawrocki, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks
In-Reply-To: <BANLkTi=iS3H8xYhouvZZwP5_daxoGSBwLA@mail.gmail.com>
On 06/22/2011 03:25 PM, Anand Kumar N wrote:
> Instead of hardcoding the parent clock in platform/bootloader code ,is
> it not possible to select/set the
> parent clock based on the pixel clk(plat data) having the least delta
> with the 9 src clks.with this change I have checked it for WA101S.
While at first sight this may look as an awesome idea I don't really
believe it is. There might be other criteria that need to be considered,
like continuous clock availability or frequency stability.
That said we could possibly have the driver setting sclk_fimd frequency
based on display planes' properties (this was my initial suggestion)
but sclk_fimd parent should be fixed either by bootloader or board
initialization code.
^ permalink raw reply
* Re: Re: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
From: JinGoo Han @ 2011-06-23 1:09 UTC (permalink / raw)
To: ANAND KUMAR N, Marek Szyprowski
Cc: JinGoo Han, Kukjin Kim, Paul Mundt,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
Jong-Hun Han, THOMAS P ABRAHAM, Sylwester Nawrocki, Kyungmin Park,
In-Ki Dae, ARM Linux, Ben Dooks
In-Reply-To: <1308724904-31521-1-git-send-email-jg1.han@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 6229 bytes --]
Hi, Anand.
> -----Original Message-----
> From: linux-samsung-soc-owner@vger.kernel.org [mailto:linux-samsung-soc-
> owner@vger.kernel.org] On Behalf Of Anand Kumar N
> Sent: Wednesday, June 22, 2011 10:25 PM
> To: Marek Szyprowski
> Cc: Jingoo Han; Kukjin Kim; Paul Mundt; linux-samsung-soc@vger.kernel.org;
> linux-fbdev@vger.kernel.org; Jonghun Han; Thomas Abraham; Sylwester
> Nawrocki; Kyungmin Park; Inki Dae; ARM Linux; Ben Dooks
> Subject: Re: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
> FIMD and LTE480WV platform-lcd
>
> Hi Marek/Jingoo,
>
> On Wed, Jun 22, 2011 at 3:17 PM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
> > Hello,
> >
> > On Wednesday, June 22, 2011 8:42 AM Jingoo Han wrote:
> >
> >> From: Jonghun Han <jonghun.han@samsung.com>
> (snipped)
> Instead of hardcoding the parent clock in platform/bootloader code ,is
> it not possible to select/set the
> parent clock based on the pixel clk(plat data) having the least delta
> with the 9 src clks.with this change I have checked it for WA101S.
> These are the changes I am proposing..
>
> arch/arm/mach-exynos4/clock.c
> +struct clk *clkset_sclk_fimd0_list[] = {
> + [0] = &clk_sclk_xxti,
> + [1] = &clk_sclk_xusbxti,
> + [2] = &clk_sclk_hdmi27m,
> + [3] = &clk_sclk_usbphy0,
> + [4] = &clk_sclk_usbphy1,
> + [5] = &clk_sclk_hdmiphy,
> + [6] = &clk_mout_mpll.clk,
> + [7] = &clk_mout_epll.clk,
> + [8] = &clk_sclk_vpll.clk,
> +};
As Sylwester Nawrocki mentioned, there would be criteria that should be considered
such as continuous clock availability or frequency stability.
For instance, when EPLL '[7] = &clk_mout_epll.clk,' is selected, there is posibility
that EPLL frequency will be changed by other devices.
However, Exynos4 FIMD can use a range of clocks as source clock, 'mout_mpll' is
most useful and can cover almost LCD pixel clock, because 'mout_mpll' is 800 MHz
and max frequency of 'sclk_fimd' can be set as 800MHz.
However, other clocks are very low. For example, HDMI PHY, VPLL are 54MHz,
USB PHY is 48MHz.
> arch/arm/mach-exynos4/mach-smdkv310.c
> +static int fimd_s3c_consider_clock(struct device *sfb,int src
> ,unsigned int wanted)
> +{
> + unsigned long rate = 0;
> + int div =1;
> + struct clk *mout_mpll = NULL;
> +
> + if(clkset_sclk_fimd0_list[src]){
> + mout_mpll = clk_get(sfb,clkset_sclk_fimd0_list[src]->name);
> + if (IS_ERR(mout_mpll)) {
> + dev_err(sfb, "failed to clk_get
> %s\n",clkset_sclk_fimd0_list[src]->name);
> + }
> +
> + rate = clk_get_rate(mout_mpll);
> +
> + for (div = 1; div < 256; div *= 2) {
> + if ((rate / div) <= wanted)
> + break;
> + }
> +
> +
> + }
> + return (wanted - (rate / div));
> +}
> +
> +int exynos4_fimd0_find_clock(struct platform_device *pdev,struct clk
> **lcd_clk,unsigned int clock(pixel clock needed for the lcd))
> +{
> + int best = 0;
> + int delta = 0;
> + int best_src = 0;
> + int src;
> + struct clk *best_clk_src = NULL;
> + struct clk *clk = NULL;
> +
> + if (clock = 0)
> + return 0;
> +
> + for (src = 0; src < MAX_NUM_CLKS ;src++) {
> + delta = fimd_s3c_consider_clock(&pdev->dev,src,clock);
> + if (delta < best) {
> + best = delta;
> + best_src = src;
> + }
> + }
> + clk = clk_get(&pdev->dev, "sclk_fimd");
> + if (IS_ERR(clk)) {
> + dev_err(&pdev->dev, "failed to get sclk for fimd\n");
> + goto err_clk2;
> + }
> +
> + best_clk_src > clk_get(&pdev->dev,clkset_sclk_fimd0_list[best_src]->name);
> + if (IS_ERR(best_clk_src)) {
> + dev_err(&pdev->dev, "failed to get best_src\n");
> + goto err_clk1;
> + }
> + clk_set_parent(clk,best_clk_src);
> + *lcd_clk = clk;
> + clk_put(best_clk_src);
> + clk_enable(clk);
> + dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", clock);
> +
> +err_clk1:
> + clk_put(best_clk_src);
> +err_clk2:
> + clk_put(clk);
> +
> + return -EINVAL;
> +}
> I have based these patches on the v1 version of this patch.I can base
> these changes
> on your latest changes(v6) and send as a patch.
>
> >> +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 = 134000000;
> >> +
> >> + 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;
> >> +}
> >> +
> >
> > I'm not sure if mach-smdk*.c is the right place for the above code.
> > IMHO all the code that configures very low level, board specific
> parameters
> > (like clocks and their relations) should be performed in boot loarder.
> >
>
> I feel pushing the clock enabling into the bootloader,will create an
> unneccesary dependcy for the lcd on the u-boot.
>
> > (snipped)
> >
> > Best regards
> > --
> > Marek Szyprowski
> > Samsung Poland R&D Center
> >
> >
> >
> regards
> anand
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-i
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±ýöÝzÿâØ^nr¡ö¦zË\x1aëh¨èÚ&£ûàz¿äz¹Þú+Ê+zf£¢·h§~Ûiÿÿïêÿêçz_è®\x0fæj:+v¨þ)ߣøm
^ permalink raw reply
* Re: Some questions about DRM(Direct Rendering Manager)
From: daeinki @ 2011-06-23 1:55 UTC (permalink / raw)
To: Rob Clark
Cc: linux-fbdev, Kukjin Kim, Kyungmin Park, dri-devel, Paul Mundt,
jesse.barnes, InKi Dae, linux-arm-kernel
In-Reply-To: <BANLkTinv1uGUPBX4RE2DGw4Ca_P5x0g+DA@mail.gmail.com>
Hi Rob Clark,
I'm sorry for that my mean didn't convey to you so I condensed that into
brief again.
I know drm_fb_helper_single_fb_probe() calls register_framebuffer(),
My question is that it's right way to call only drm_fb_helper_set_par()
if fb_helper->funcs->fb_probe() returns nonzero.
In this case, if fb_helper->funcs->fb_probe() returns zero then
register_framebuffer() isn't called and this means linux framebuffer
isn't used anymore.
one more question, otherwise if it uses drm based framebuffer,
register_framebuffer() should be called necessarily at booting time?
Thank you.
Rob Clark 쓴 글:
> fwiw, drm_fb_helper_single_fb_probe() calls register_framebuffer() (if
> that was the question?)
>
> BR,
> -R
>
> 2011/6/22 InKi Dae <daeinki@gmail.com>:
>> It adds dri-devel@lists.freedesktop.org to this mail thread.
>> Thank you.
>>
>> 2011년 6월 22일 오후 3:04, daeinki <inki.dae@samsung.com>님의 말:
>>> below is additional comments.
>>>
>>> daeinki 쓴 글:
>>>> Hi all,
>>>>
>>>> I'm writing Samsung SoC based DRM framework and this one includes FIMD
>>>> and HDMI driver as hardware dependent modules. and for now, encoder,
>>>> connector, crtc and fb module has been materialized almost. but I'm
>>>> contending with framebuffer setting issue(created fb_info should be
>>>> registered to linux framebuffer through register_framebuffer() or not)as
>>>> default framebuffer at booting time.
>>>>
>>>> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's
>>>> fb_probe callback is called and this one creates new framebuffer and
>>>> returns a value more then 0 if true. internally, this process creates an
>>>> fb_info object and drm_framebuffer and then drm_framebuffer would be
>>>> added to mode_config.fb_list of the drm_device.
>>>>
>>> it's my mistake. return value is 0 if true, nonzero otherwise.
>>>
>>>> a value returned, new_fb is used to decide that it calls
>>>> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am
>>>> confused it's a good way to call register_framebuffer() otherwise
>>>> drm_fb_helper_set_par(). if register_framebuffer() is called then I
>>>> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be
>>>> called somewhere subsequently to apply this one to real hardware because
>>>> previous process is just for maintaining data logically.(not set up data
>>>> to h/w)
>>>>
>>>> it's a right way to call register_framebuffer() and then
>>>> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just
>>>> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring
>>>> register_framebuffer()? and what is the purpose of using
>>>> register_framebuffer()?
>>>>
>>> I understood that if fb_probe() callback is fail then fb_info object is
>>> registered to linux framebuffer through register_framebuffer()
>>> otherwise(if true) hardware configuration would be completed by
>>> drm_fb_helper_set_par() so the reason of using register_framebuffer() is
>>> that the case of failing fb_probe() callback, it is for drawing on only
>>> linux framebuffer. is it right?
>>>
>>>> In my case, first, register_framebuffer() is called and then if desired
>>>> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id,
>>>> it gets mode_set of drm_fb_helper->crtc_info[n] and then it calls
>>>> drm_crtc_helper_set_config(mode_set). at this time, all the hardware
>>>> configurations would be completed.
>>>>
>>>> thank you in advance.
>>>>
>>>> Best Regards
>>>> Inki Dae.
>>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RE: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
From: JinGoo Han @ 2011-06-23 6:44 UTC (permalink / raw)
To: Marek Szyprowski
Cc: JinGoo Han, Kukjin Kim, 'Paul Mundt',
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
Jong-Hun Han, ANAND KUMAR N, THOMAS P ABRAHAM, Sylwester Nawrocki,
'Kyungmin Park', In-Ki Dae, 'ARM Linux',
'Ben Dooks'
In-Reply-To: <1308724904-31521-1-git-send-email-jg1.han@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 6516 bytes --]
Hi, Marek.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Marek Szyprowski
> Sent: Wednesday, June 22, 2011 6:47 PM
> To: 'Jingoo Han'; 'Kukjin Kim'; 'Paul Mundt'; linux-samsung-
> soc@vger.kernel.org; linux-fbdev@vger.kernel.org; 'Jonghun Han'
> Cc: 'Anand Kumar N'; 'Thomas Abraham'; Sylwester Nawrocki; 'Kyungmin Park';
> 'Inki Dae'; 'ARM Linux'; 'Ben Dooks'; 'Jonghun Han'
> Subject: RE: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
> FIMD and LTE480WV platform-lcd
>
> Hello,
>
> On Wednesday, June 22, 2011 8:42 AM Jingoo Han wrote:
>
> > From: Jonghun Han <jonghun.han@samsung.com>
> >
> > This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
> >
> > Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm/mach-exynos4/mach-smdkc210.c | 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 <linux/serial_core.h>
> > +#include <linux/delay.h>
> > #include <linux/gpio.h>
> > +#include <linux/lcd.h>
> > #include <linux/mmc/host.h>
> > #include <linux/platform_device.h>
> > #include <linux/smsc911x.h>
> > #include <linux/io.h>
> > #include <linux/i2c.h>
> > +#include <linux/clk.h>
> >
> > #include <asm/mach/arch.h>
> > #include <asm/mach-types.h>
> >
> > +#include <video/platform_lcd.h>
> > +
> > #include <plat/regs-serial.h>
> > #include <plat/regs-srom.h>
> > #include <plat/exynos4.h>
> > #include <plat/cpu.h>
> > #include <plat/devs.h>
> > +#include <plat/fb.h>
> > #include <plat/sdhci.h>
> > #include <plat/iic.h>
> > #include <plat/pd.h>
> >
> > #include <mach/map.h>
> > +#include <mach/regs-fb.h>
> >
> > /* Following are default values for UCON, ULCON and UFCON UART
> registers
> > */
> > #define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> > @@ -111,6 +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 = 134000000;
> > +
> > + 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;
> > +}
> > +
>
> I'm not sure if mach-smdk*.c is the right place for the above code.
> IMHO all the code that configures very low level, board specific
> parameters
> (like clocks and their relations) should be performed in boot loarder.
I agree with your suggestion.
I will remove the parent clock setting from the machine as fimc does.
I will send V7 patches, soon.
I really appreciate your review. Thank you.
>
> (snipped)
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±ýöÝzÿâØ^nr¡ö¦zË\x1aëh¨èÚ&£ûàz¿äz¹Þú+Ê+zf£¢·h§~Ûiÿÿïêÿêçz_è®\x0fæj:+v¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD
From: K, Mythri P @ 2011-06-23 9:15 UTC (permalink / raw)
To: jg1.han
Cc: Kukjin Kim, Paul Mundt, linux-samsung-soc@vger.kernel.org,
linux-fbdev@vger.kernel.org, Jong-Hun Han, ANAND KUMAR N,
Sylwester Nawrocki, THOMAS P ABRAHAM, Marek Szyprowski,
Kyungmin Park, In-Ki Dae, ARM Linux, Ben Dooks
In-Reply-To: <11291403.110251308714504687.JavaMail.weblogic@epml08>
2011/6/22 JinGoo Han <jg1.han@samsung.com>:
> From: Jonghun Han <jonghun.han@samsung.com>
>
> This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
>
> Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> arch/arm/mach-exynos4/mach-smdkc210.c | 114 +++++++++++++++++++++++++++++++++
> arch/arm/mach-exynos4/mach-smdkv310.c | 114 +++++++++++++++++++++++++++++++++
> 2 files changed, 228 insertions(+), 0 deletions(-)
>
<<snip>>
> +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
> + }
> +}
> +
have you considered using gpio_request_one instead ? It simplifies the
three step API.
<<snip>>
> + 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
> + }
> +}
same comment as above.
<<snip>>
--
Thanks and regards,
Mythri.
^ permalink raw reply
* Re: Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
From: JinGoo Han @ 2011-06-23 11:08 UTC (permalink / raw)
To: K, Mythri P
Cc: JinGoo Han, Kukjin Kim, Paul Mundt,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
Jong-Hun Han, ANAND KUMAR N, Sylwester Nawrocki, THOMAS P ABRAHAM,
Marek Szyprowski, Kyungmin Park, In-Ki Dae, ARM Linux, Ben Dooks
In-Reply-To: <11291403.110251308714504687.JavaMail.weblogic@epml08>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3800 bytes --]
Hi, Mythri.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Thursday, June 23, 2011 6:04 PM
> To: jg1.han@samsung.com
> Cc: Kukjin Kim; Paul Mundt; linux-samsung-soc@vger.kernel.org; linux-
> fbdev@vger.kernel.org; Jong-Hun Han; ANAND KUMAR N; Sylwester Nawrocki;
> THOMAS P ABRAHAM; Marek Szyprowski; Kyungmin Park; In-Ki Dae; ARM Linux;
> Ben Dooks
> Subject: Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
> FIMD and LTE480WV platform-lcd
>
> 2011/6/22 JinGoo Han <jg1.han@samsung.com>:
> > From: Jonghun Han <jonghun.han@samsung.com>
> >
> > This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
> >
> > Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm/mach-exynos4/mach-smdkc210.c | 114
> +++++++++++++++++++++++++++++++++
> > arch/arm/mach-exynos4/mach-smdkv310.c | 114
> +++++++++++++++++++++++++++++++++
> > 2 files changed, 228 insertions(+), 0 deletions(-)
> >
> <<snip>>
> > +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
> > + }
> > +}
> > +
>
> have you considered using gpio_request_one instead ? It simplifies the
> three step API.
You're right. It seems to be very helpful.
I will apply it and send V7 patches, soon.
Thank you for your reply.
>
> <<snip>>
>
> > + 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
> > + }
> > +}
>
> same comment as above.
>
> <<snip>>
>
>
>
> --
> Thanks and regards,
> Mythri.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±ýöÝzÿâØ^nr¡ö¦zË\x1aëh¨èÚ&£ûàz¿äz¹Þú+Ê+zf£¢·h§~Ûiÿÿïêÿêçz_è®\x0fæj:+v¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-23 11:26 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-dev, linux-fbdev, lethal, Timur Tabi, yorksun
In-Reply-To: <929D3CED81F34E43887A393170D66FB90484A280@GBRSUN01MS002.eu.xerox.net>
On Wed, 22 Jun 2011 11:39:49 +0100
"Jenkins, Clive" <Clive.Jenkins@xerox.com> wrote:
...
> > > Removing the ioctl interface also allows us to clean up the header
> file and
> > > remove other unusued stuff.
> >
> > No! We are using ioctl interface of this driver in many video
> > rendering applications on overlay planes on huge number of boards.
> > So, please don't remove it.
...
> Can you make available your application code by posting a link to it?
I do not have the code of the real applications since I didn't wrote
it. All I can share is the test and sample code that I used when working
on driver fixes:
test-app: http://pastebin.com/J2RvKb6n
HTH,
Anatolij
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Tabi Timur-B04825 @ 2011-06-23 11:29 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
lethal@linux-sh.org, sun york-R58495
In-Reply-To: <20110623132604.1a6d0d71@wker>
Anatolij Gustschin wrote:
> I do not have the code of the real applications since I didn't wrote
> it. All I can share is the test and sample code that I used when working
> on driver fixes:
>
> test-app:http://pastebin.com/J2RvKb6n
What's the "VIU"?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-23 11:39 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org
In-Reply-To: <4E0323A5.7080706@freescale.com>
On Thu, 23 Jun 2011 11:29:42 +0000
Tabi Timur-B04825 <B04825@freescale.com> wrote:
...
> > test-app:http://pastebin.com/J2RvKb6n
>
> What's the "VIU"?
Video-IN unit on mpc5121e (for capturing ITU656 video stream data).
^ permalink raw reply
* [PATCH] This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuffer r
From: William Katsak @ 2011-06-23 13:16 UTC (permalink / raw)
To: linux-fbdev
The situation in which the problem occurred was with a Plugable UGA-2K-A
connected to a Samsung EX2220X display. The driver indicates that
1920x1080 is a valid mode (the first mode available, in fact), but
proceeds to set the framebuffer size to 1600x1200.
The patch corrects what seems to be a logic error, regarding unsetting
the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid.
The existing code unset the flag if ANY mode was invalid.
Signed-off-by: William Katsak <william.katsak@alcatel-lucent.com>
---
drivers/video/udlfb.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 52b0f3e..816a4fd 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1233,8 +1233,12 @@ static int dlfb_setup_modes(struct dlfb_data *dev,
if (dlfb_is_valid_mode(&info->monspecs.modedb[i], info))
fb_add_videomode(&info->monspecs.modedb[i],
&info->modelist);
- else /* if we've removed top/best mode */
- info->monspecs.misc &= ~FB_MISC_1ST_DETAIL;
+ else {
+ if (i = 0)
+ /* if we've removed top/best mode */
+ info->monspecs.misc
+ &= ~FB_MISC_1ST_DETAIL;
+ }
}
default_vmode = fb_find_best_display(&info->monspecs,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-06-23 16:08 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Laurent Pinchart, linux-fbdev, linux-media, dri-devel
In-Reply-To: <4E018189.3020305@gmx.de>
On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
>> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
>>> On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote:
>>>> +The FOURCC-based API replaces format descriptions by four character
>>>> codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a
>>>> format +without explicitly describing it. This is the only API that
>>>> supports YUV +formats. Drivers are also encouraged to implement the
>>>> FOURCC-based API for RGB +and grayscale formats.
>>>> +
>>>> +Drivers that support the FOURCC-based API report this capability by
>>>> setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities
>>>> field. +
>>>> +FOURCC definitions are located in the linux/videodev2.h header.
>>>> However,
>>>> and +despite starting with the V4L2_PIX_FMT_prefix, they are not
>>>> restricted to V4L2 +and don't require usage of the V4L2 subsystem.
>>>> FOURCC documentation is +available in
>>>> Documentation/DocBook/v4l/pixfmt.xml.
>>>> +
>>>> +To select a format, applications set the FB_VMODE_FOURCC bit in the
>>>> +fb_var_screeninfo vmode field, and set the fourcc field to the desired
>>>> FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields
>>>> must be set to +0 by applications and ignored by drivers. Note that the
>>>> grayscale and fourcc +fields share the same memory location. Application
>>>> must thus not set the +grayscale field to 0.
>>>
>>> These are the only parts I don't like: (ab)using the vmode field (this
>>> isn't really a vmode flag), and the union of grayscale and fourcc (avoid
>>> unions where possible).
>>
>> I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a
>> FOURCC
>> mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very
>> happy
>> with that, and proposed using the vmode field instead.
>>
>> Given that there's virtually no fbdev documentation, whether the vmode
>> field
>> and/or nonstd field are good fit for a FOURCC mode indicator is subject to
>> interpretation.
>
> The reason for my suggestion is that the vmode field is accepted to contain
> only flags and at least to me there is no hard line what is part of the
> video mode and what is not. In contrast the nonstd field is already used in
> a lot of different (incompatible) ways. I think if we only use the nonstd
> field for handling FOURCC it is likely that some problems will appear.
>
>>> What about storing the FOURCC value in nonstd instead?
>>
>> Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format
>> setting will be a standard fbdev API, I'm not very keen on storing it in
>> the
>> nonstd field without a union.
>>
>>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
>>> be non-zero), I don't think there are any conflicts with existing values
>>> of
>>> nonstd. To make it even safer and easier to parse, you could set bit 31
>>> of
>>> nonstd as a FOURCC indicator.
>>
>> I would then create a union between nonstd and fourcc, and document nonstd
>> as
>> being used for the legacy API only. Most existing drivers use a couple of
>> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
>> uses
>> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
>> 0xff000000 != 0 could be used as a FOURCC mode test.
>>
>> This assumes that FOURCCs will never have their last character set to
>> '\0'. Is
>> that a safe assumption for the future ?
>
> Yes, I think. The information I found indicates that space should be used
> for padding, so a \0 shouldn't exist.
> I think using only the nonstd field and requiring applications to check the
> capabilities would be possible, although not fool proof ;)
So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
any of them is set.
Nicely backwards compatible, as sane drivers should reject nonstd values they
don't support (apps _will_ start filling in FOURCC values ignoring capabilities,
won't they?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] printk: Release console_sem after logbuf_lock
From: Pavel Machek @ 2011-06-23 19:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Hugh Dickins, Andrew Morton, Ingo Molnar, Linus Torvalds,
Thomas Gleixner, linux-kernel, efault, Arne Jansen, PaulMundt,
linux-fbdev
In-Reply-To: <1307709030.3941.134.camel@twins>
vvOn Fri 2011-06-10 14:30:30, Peter Zijlstra wrote:
>On Fri, 2011-06-10 at 13:28 +0200, Peter Zijlstra wrote:
> > On Thu, 2011-06-09 at 16:57 -0700, Hugh Dickins wrote:
> > >
> > > All console-related activity curently happens under spin_lock_irqsave(&console_lock).
> > > This causes interrutps to be blocked for 1-2 milliseconds with vgacon, and for
> > > hundreds of milliseconds with fbdevs. This results in network overruns, audio
> > > dropouts, dropped characters on serial ports and other such nice things.
> >
> > Hmm, with these proposed patches we're actually back to that. I wonder
> > if fbdev is still that crappy..
>
> So I tried adding a fbcon to my test box (not that it actually has a
> display, but who cares) and disabled lockdep (otherwise that's all I can
> catch on the latency tracer) to see if I could see whopping horrid
> latencies there, but I'm afraid I either failed to set things up
> properly or my fbcon isn't sucky enough.
>
> What I did was enable:
>
> CONFIG_FB=y
> CONFIG_FB_SIS=y
> CONFIG_FB_SIS_315=y (the board has XGI z7)
sis will be accelerated. Try vesafb; scrolling should be horrible.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] fsl-diu-fb: remove check for pixel clock ranges
From: Timur Tabi @ 2011-06-23 20:20 UTC (permalink / raw)
To: lethal, linux-fbdev, agust, yorksun, linuxppc-dev
The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
the pixel clock. These values, however, are true only for one platform
clock rate (533MHz) and only for the MPC8610. So the actual range for
the pixel clock is chip-specific, which means the current values are almost
always wrong. The chance of an out-of-range pixel clock being used are also
remote.
Rather than try to detect an out-of-range clock in the DIU driver, we depend
on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
to clamp the pixel clock to a supported value.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/video/fsl-diu-fb.c | 16 ----------------
include/linux/fsl-diu-fb.h | 6 ------
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..0acc7d6 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -555,8 +555,6 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
static int fsl_diu_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
- unsigned long htotal, vtotal;
-
pr_debug("check_var xres: %d\n", var->xres);
pr_debug("check_var yres: %d\n", var->yres);
@@ -635,20 +633,6 @@ static int fsl_diu_check_var(struct fb_var_screeninfo *var,
break;
}
- /* If the pixclock is below the minimum spec'd value then set to
- * refresh rate for 60Hz since this is supported by most monitors.
- * Refer to Documentation/fb/ for calculations.
- */
- if ((var->pixclock < MIN_PIX_CLK) || (var->pixclock > MAX_PIX_CLK)) {
- htotal = var->xres + var->right_margin + var->hsync_len +
- var->left_margin;
- vtotal = var->yres + var->lower_margin + var->vsync_len +
- var->upper_margin;
- var->pixclock = (vtotal * htotal * 6UL) / 100UL;
- var->pixclock = KHZ2PICOS(var->pixclock);
- pr_debug("pixclock set for 60Hz refresh = %u ps\n",
- var->pixclock);
- }
var->height = -1;
var->width = -1;
diff --git a/include/linux/fsl-diu-fb.h b/include/linux/fsl-diu-fb.h
index 781d467..daa9952 100644
--- a/include/linux/fsl-diu-fb.h
+++ b/include/linux/fsl-diu-fb.h
@@ -24,12 +24,6 @@
* See mpc8610fb_set_par(), map_video_memory(), and unmap_video_memory()
*/
#define MEM_ALLOC_THRESHOLD (1024*768*4+32)
-/* Minimum value that the pixel clock can be set to in pico seconds
- * This is determined by platform clock/3 where the minimum platform
- * clock is 533MHz. This gives 5629 pico seconds.
- */
-#define MIN_PIX_CLK 5629
-#define MAX_PIX_CLK 96096
#include <linux/types.h>
--
1.7.3.4
^ permalink raw reply related
* [PATCH 18/37] Remove unneeded version.h includes from
From: Jesper Juhl @ 2011-06-23 22:35 UTC (permalink / raw)
To: LKML
Cc: trivial, Michael Hennerich, Richard Purdie, Paul Mundt,
device-drivers-devel, linux-fbdev
In-Reply-To: <alpine.LNX.2.00.1106232344480.17688@swampdragon.chaosbits.net>
It was pointed out by 'make versioncheck' that some includes of
linux/version.h are not needed in drivers/video/.
This patch removes them.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/video/backlight/adp8860_bl.c | 1 -
drivers/video/backlight/adp8870_bl.c | 1 -
drivers/video/pxa3xx-gcu.c | 2 --
drivers/video/xilinxfb.c | 1 -
4 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
index d2a96a4..24a6dfd 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
index 05a8832..383c4c3 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
index 0283c70..d8de557 100644
--- a/drivers/video/pxa3xx-gcu.c
+++ b/drivers/video/pxa3xx-gcu.c
@@ -31,8 +31,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
-
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/miscdevice.h>
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 77dea01..fcb6cd9 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -23,7 +23,6 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
--
1.7.5.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 2/2] video: Fix speficied typo
From: Joe Perches @ 2011-06-23 22:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <6002eb70809bb1c87c84f32ab4a4f034d2d1ffb5.1308868289.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/video/controlfb.c | 2 +-
drivers/video/platinumfb.c | 2 +-
drivers/video/pm2fb.c | 2 +-
drivers/video/pm3fb.c | 2 +-
drivers/video/s3fb.c | 2 +-
drivers/video/skeletonfb.c | 2 +-
drivers/video/valkyriefb.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/controlfb.c b/drivers/video/controlfb.c
index 9075bea..7b2c40a 100644
--- a/drivers/video/controlfb.c
+++ b/drivers/video/controlfb.c
@@ -550,7 +550,7 @@ static void control_set_hardware(struct fb_info_control *p, struct fb_par_contro
/*
- * Parse user speficied options (`video=controlfb:')
+ * Parse user specified options (`video=controlfb:')
*/
static void __init control_setup(char *options)
{
diff --git a/drivers/video/platinumfb.c b/drivers/video/platinumfb.c
index f27ae16..6694923 100644
--- a/drivers/video/platinumfb.c
+++ b/drivers/video/platinumfb.c
@@ -490,7 +490,7 @@ static int platinum_var_to_par(struct fb_var_screeninfo *var,
/*
- * Parse user speficied options (`video=platinumfb:')
+ * Parse user specified options (`video=platinumfb:')
*/
static int __init platinumfb_setup(char *options)
{
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index f4f8ce8..dc7bfa9 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -1773,7 +1773,7 @@ MODULE_DEVICE_TABLE(pci, pm2fb_id_table);
#ifndef MODULE
/**
- * Parse user speficied options.
+ * Parse user specified options.
*
* This is, comma-separated options following `video=pm2fb:'.
*/
diff --git a/drivers/video/pm3fb.c b/drivers/video/pm3fb.c
index 8221b5b..6632ee5 100644
--- a/drivers/video/pm3fb.c
+++ b/drivers/video/pm3fb.c
@@ -1525,7 +1525,7 @@ static int __init pm3fb_setup(char *options)
{
char *this_opt;
- /* Parse user speficied options (`video=pm3fb:') */
+ /* Parse user specified options (`video=pm3fb:') */
if (!options || !*options)
return 0;
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 0f9af1a..946a949 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1505,7 +1505,7 @@ static struct pci_driver s3fb_pci_driver = {
.resume = s3_pci_resume,
};
-/* Parse user speficied options */
+/* Parse user specified options */
#ifndef MODULE
static int __init s3fb_setup(char *options)
diff --git a/drivers/video/skeletonfb.c b/drivers/video/skeletonfb.c
index 89158bc..30f7a81 100644
--- a/drivers/video/skeletonfb.c
+++ b/drivers/video/skeletonfb.c
@@ -989,7 +989,7 @@ static struct platform_device *xxxfb_device;
*/
int __init xxxfb_setup(char *options)
{
- /* Parse user speficied options (`video=xxxfb:') */
+ /* Parse user specified options (`video=xxxfb:') */
}
#endif /* MODULE */
diff --git a/drivers/video/valkyriefb.c b/drivers/video/valkyriefb.c
index 6b52bf6..3f5a041 100644
--- a/drivers/video/valkyriefb.c
+++ b/drivers/video/valkyriefb.c
@@ -555,7 +555,7 @@ static int __init valkyrie_init_info(struct fb_info *info,
/*
- * Parse user speficied options (`video=valkyriefb:')
+ * Parse user specified options (`video=valkyriefb:')
*/
int __init valkyriefb_setup(char *options)
{
--
1.7.6.rc1
^ permalink raw reply related
* Re: [PATCH 18/37] Remove unneeded version.h includes from drivers/video/
From: Mike Frysinger @ 2011-06-23 22:51 UTC (permalink / raw)
To: Jesper Juhl
Cc: LKML, trivial, Michael Hennerich, Richard Purdie, Paul Mundt,
device-drivers-devel, linux-fbdev
In-Reply-To: <alpine.LNX.2.00.1106240032560.17688@swampdragon.chaosbits.net>
On Thu, Jun 23, 2011 at 18:35, Jesper Juhl wrote:
> drivers/video/backlight/adp8860_bl.c | 1 -
> drivers/video/backlight/adp8870_bl.c | 1 -
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox