* [PATCH v2 0/5] ARM: dts: AM33XX: lcdc support
From: Afzal Mohammed @ 2013-01-15 13:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series add DT sources for AM335x SoC as well as AM335x based
boards.
As compared to previous version, in this version, comment has been
added in dt source file about pinmux details so that user can easily
correlate to that mentioned in TRM. Also author of one of the patch
was actually "Manjunathappa, Prakash", here in this series, authorship
has been made proper.
As pinmux is an SoC specific detail rather than IP specific one,
addition of pin control has been done in a separate patch from
the one in which display timings are added. Also it may aid in
debugging in case of any issues.
This has been tested on AM335x based boards like AM335x EVM and
AM335x EVM-SK.
This series is based on v3.8-rc3.
This series has a dependency on,
1. Series v16 "of: add display helper" by,
Steffen Trumtrar <s.trumtrar@pengutronix.de>
2. Series v3 "video: da8xx-fb: runtime timing configuration" by,
me (Afzal Mohammed <afzal@ti.com>)
3. Series v2 "video: da8xx-fb: DT support" by,
me (Afzal Mohammed <afzal@ti.com>)
To test on AM335x, in addition to the above, following changes,
1. Patch "ARM: AM33XX: clock: SET_RATE_PARENT in lcd path" by,
me (Afzal Mohammed <afzal@ti.com>)
2. Patch "da8xx: Allow use by am33xx based devices" by,
Pantelis Antoniou <panto@antoniou-consulting.com>
3. Series "HWMOD fixes for AM33xx PWM submodules and device tree nodes" by,
Philip, Avinash <avinashphilip@ti.com>
would be required
All above dependencies along with those required for testing is available
@git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3.8-rc3
Regards
Afzal
v2: add pinmux comment in dtsi files, correct authorship of one of the
patch.
Afzal Mohammed (4):
ARM: dts: AM33XX: Add lcdc node
ARM: dts: AM33XX: Add am335x-evm lcdc panel timings
ARM: dts: AM33XX: Add am335x-evmsk lcdc panel timings
ARM: dts: AM33XX: Add am335x-evmsk lcdc pincontrol info
Manjunathappa, Prakash (1):
ARM: dts: AM33XX: Add am335x-evm lcdc pincontrol info
arch/arm/boot/dts/am335x-evm.dts | 55 +++++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/am335x-evmsk.dts | 55 +++++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/am33xx.dtsi | 8 ++++++
3 files changed, 116 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
From: Afzal Mohammed @ 2013-01-15 13:46 UTC (permalink / raw)
To: linux-arm-kernel
LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.
And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).
Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
Based on v3.8-rc3
arch/arm/mach-omap2/cclock33xx_data.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..b731216 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,9 +284,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
* TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
* and ALT_CLK1/2)
*/
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, 0x0,
- AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
- AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck,
+ CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
+ AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
+ CLK_DIVIDER_ONE_BASED, NULL);
/* DPLL_PER */
static struct dpll_data dpll_per_dd = {
@@ -932,6 +933,8 @@ int __init am33xx_clk_init(void)
cpu_clkflg = CK_AM33XX;
}
+ lcd_gclk.flags |= CLK_SET_RATE_PARENT;
+
for (c = am33xx_clks; c < am33xx_clks + ARRAY_SIZE(am33xx_clks); c++) {
if (c->cpu & cpu_clkflg) {
clkdev_add(&c->lk);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 10/10] video: da8xx-fb: fb_set_par support
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
fb_set_par helps in runtime configuration of lcd controller like
changing resolution, pixel clock etc. (eg. using fbset utility)
Reconfigure lcd controller based on information passed by framework.
Enable raster back if it was already enabled.
As fb_set_par would get invoked indirectly from probe via fb_set_var,
remove existing lcdc initialization in probe and do lcdc reset in
probe so that reset happens only at the begining.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
v2: disable raster in fb_set_par properly as required, without this
there would be no issue on DA850, but it will cause problem on AM335X
drivers/video/da8xx-fb.c | 60 +++++++++++++++++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0f73c76..720604c 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -243,6 +243,11 @@ static struct fb_videomode known_lcd_panels[] = {
},
};
+static inline bool da8xx_fb_is_raster_enabled(void)
+{
+ return !!(lcdc_read(LCD_RASTER_CTRL_REG) & LCD_RASTER_ENABLE);
+}
+
/* Enable the Raster Engine of the LCD Controller */
static inline void lcd_enable_raster(void)
{
@@ -665,9 +670,6 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
static void da8xx_fb_lcd_reset(void)
{
- /* Disable the Raster if previously Enabled */
- lcd_disable_raster(false);
-
/* DMA has to be disabled */
lcdc_write(0, LCD_DMA_CTRL_REG);
lcdc_write(0, LCD_RASTER_CTRL_REG);
@@ -720,8 +722,6 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- da8xx_fb_lcd_reset();
-
da8xx_fb_calc_config_clk_divider(par, panel);
if (panel->sync & FB_SYNC_CLK_INVERT)
@@ -1201,9 +1201,52 @@ static int da8xx_pan_display(struct fb_var_screeninfo *var,
return ret;
}
+static int da8xxfb_set_par(struct fb_info *info)
+{
+ struct da8xx_fb_par *par = info->par;
+ int ret;
+ bool raster = da8xx_fb_is_raster_enabled();
+
+ if (raster)
+ lcd_disable_raster(true);
+ else
+ lcd_disable_raster(false);
+
+ fb_var_to_videomode(&par->mode, &info->var);
+
+ par->cfg.bpp = info->var.bits_per_pixel;
+
+ info->fix.visual = (par->cfg.bpp <= 8) ?
+ FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
+ info->fix.line_length = (par->mode.xres * par->cfg.bpp) / 8;
+
+ ret = lcd_init(par, &par->cfg, &par->mode);
+ if (ret < 0) {
+ dev_err(par->dev, "lcd init failed\n");
+ return ret;
+ }
+
+ par->dma_start = info->fix.smem_start +
+ info->var.yoffset * info->fix.line_length +
+ info->var.xoffset * info->var.bits_per_pixel / 8;
+ par->dma_end = par->dma_start +
+ info->var.yres * info->fix.line_length - 1;
+
+ lcdc_write(par->dma_start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+ lcdc_write(par->dma_end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+ lcdc_write(par->dma_start, LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+ lcdc_write(par->dma_end, LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+
+ if (raster)
+ lcd_enable_raster();
+
+ return 0;
+}
+
static struct fb_ops da8xx_fb_ops = {
.owner = THIS_MODULE,
.fb_check_var = fb_check_var,
+ .fb_set_par = da8xxfb_set_par,
.fb_setcolreg = fb_setcolreg,
.fb_pan_display = da8xx_pan_display,
.fb_ioctl = fb_ioctl,
@@ -1312,14 +1355,9 @@ static int fb_probe(struct platform_device *device)
}
fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
- fb_var_to_videomode(&par->mode, &da8xx_fb_var);
par->cfg = *lcd_cfg;
- if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
- dev_err(&device->dev, "lcd_init failed\n");
- ret = -EFAULT;
- goto err_release_fb;
- }
+ da8xx_fb_lcd_reset();
/* allocate frame buffer */
par->vram_size = lcdc_info->xres * lcdc_info->yres * lcd_cfg->bpp;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 09/10] video: da8xx-fb: report correct pixclock
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
Update "var" pixclock with the value that is configurable in hardware.
This lets user know the actual pixclock.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index a5341d0..0f73c76 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -686,6 +686,15 @@ static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
return par->lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
}
+static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
+ unsigned pixclock)
+{
+ unsigned div;
+
+ div = da8xx_fb_calc_clk_divider(par, pixclock);
+ return KHZ2PICOS(par->lcd_fck_rate / (1000 * div));
+}
+
static inline void da8xx_fb_config_clk_divider(unsigned div)
{
/* Configure the LCD clock divisor. */
@@ -962,6 +971,8 @@ static int fb_check_var(struct fb_var_screeninfo *var,
if (var->yres + var->yoffset > var->yres_virtual)
var->yoffset = var->yres_virtual - var->yres;
+ var->pixclock = da8xx_fb_round_clk(par, var->pixclock);
+
return err;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 08/10] video: da8xx-fb: store struct device *
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
store struct device pointer so that dev_dbg/err can be used outside
of probe.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7f08644..a5341d0 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -150,6 +150,7 @@ static inline void lcdc_write(unsigned int val, unsigned int addr)
}
struct da8xx_fb_par {
+ struct device *dev;
resource_size_t p_palette_base;
unsigned char *v_palette_base;
dma_addr_t vram_phys;
@@ -1291,6 +1292,7 @@ static int fb_probe(struct platform_device *device)
}
par = da8xx_fb_info->par;
+ par->dev = &device->dev;
par->lcdc_clk = fb_clk;
par->lcd_fck_rate = clk_get_rate(fb_clk);
if (fb_pdata->panel_power_ctrl) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 07/10] video: da8xx-fb: pix clk and clk div handling cleanup
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
Use the new modedb field to store pix clk. Reorganize existing clock
divider functions with names now corresponding to what they do, add
common function prefix.
Fix existing panel modedb pixclock to be in ps instead of Hz. This
needed a change in the way clock divider is calculated. As modedb
pixclock information is now in ps, override on "var" pixclock over
modedb to var conversion is removed.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 48 +++++++++++++++++-----------------------------
1 file changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f1d88ac..7f08644 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -160,7 +160,6 @@ struct da8xx_fb_par {
struct clk *lcdc_clk;
int irq;
unsigned int palette_sz;
- unsigned int pxl_clk;
int blank;
wait_queue_head_t vsync_wait;
int vsync_flag;
@@ -201,7 +200,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = "Sharp_LCD035Q3DG01",
.xres = 320,
.yres = 240,
- .pixclock = 4608000,
+ .pixclock = 217014,
.left_margin = 6,
.right_margin = 8,
.upper_margin = 2,
@@ -216,7 +215,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = "Sharp_LK043T1DG01",
.xres = 480,
.yres = 272,
- .pixclock = 7833600,
+ .pixclock = 127655,
.left_margin = 2,
.right_margin = 2,
.upper_margin = 2,
@@ -231,7 +230,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = "SP10Q010",
.xres = 320,
.yres = 240,
- .pixclock = 7833600,
+ .pixclock = 127655,
.left_margin = 10,
.right_margin = 10,
.upper_margin = 10,
@@ -680,13 +679,14 @@ static void da8xx_fb_lcd_reset(void)
}
}
-static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
+static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
+ unsigned pixclock)
{
- unsigned int lcd_clk, div;
-
- lcd_clk = clk_get_rate(par->lcdc_clk);
- div = lcd_clk / par->pxl_clk;
+ return par->lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
+}
+static inline void da8xx_fb_config_clk_divider(unsigned div)
+{
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE & 0x1), LCD_CTRL_REG);
@@ -694,7 +694,14 @@ static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
if (lcd_revision = LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+}
+
+static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+ struct fb_videomode *mode)
+{
+ unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock);
+ da8xx_fb_config_clk_divider(div);
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
@@ -705,8 +712,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
da8xx_fb_lcd_reset();
- /* Calculate the divider */
- lcd_calc_clk_divider(par);
+ da8xx_fb_calc_config_clk_divider(par, panel);
if (panel->sync & FB_SYNC_CLK_INVERT)
lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
@@ -969,7 +975,7 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb,
if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) {
par->lcd_fck_rate = clk_get_rate(par->lcdc_clk);
lcd_disable_raster(true);
- lcd_calc_clk_divider(par);
+ da8xx_fb_calc_config_clk_divider(par, &par->mode);
if (par->blank = FB_BLANK_UNBLANK)
lcd_enable_raster();
}
@@ -1195,22 +1201,6 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
-/* Calculate and return pixel clock period in pico seconds */
-static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
-{
- unsigned int lcd_clk, div;
- unsigned int configured_pix_clk;
- unsigned long long pix_clk_period_picosec = 1000000000000ULL;
-
- lcd_clk = clk_get_rate(par->lcdc_clk);
- div = lcd_clk / par->pxl_clk;
- configured_pix_clk = (lcd_clk / div);
-
- do_div(pix_clk_period_picosec, configured_pix_clk);
-
- return pix_clk_period_picosec;
-}
-
static int fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata @@ -1303,7 +1293,6 @@ static int fb_probe(struct platform_device *device)
par = da8xx_fb_info->par;
par->lcdc_clk = fb_clk;
par->lcd_fck_rate = clk_get_rate(fb_clk);
- par->pxl_clk = lcdc_info->pixclock;
if (fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
par->panel_power_ctrl(1);
@@ -1368,7 +1357,6 @@ static int fb_probe(struct platform_device *device)
da8xx_fb_var.grayscale lcd_cfg->panel_shade = MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
- da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 06/10] video: da8xx-fb: store clk rate even if !CPUFREQ
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
store lcd clk rate always, i.e. irrespective of whether CPUFREQ is
enabled or not. This can be used to get clk rate directly instead of
enquiring with clock framework with clk handle every time.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d060f14..f1d88ac 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -174,8 +174,8 @@ struct da8xx_fb_par {
unsigned int which_dma_channel_done;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
- unsigned int lcd_fck_rate;
#endif
+ unsigned int lcd_fck_rate;
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
struct fb_videomode mode;
@@ -1302,9 +1302,7 @@ static int fb_probe(struct platform_device *device)
par = da8xx_fb_info->par;
par->lcdc_clk = fb_clk;
-#ifdef CONFIG_CPU_FREQ
par->lcd_fck_rate = clk_get_rate(fb_clk);
-#endif
par->pxl_clk = lcdc_info->pixclock;
if (fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 05/10] video: da8xx-fb: store current display information
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
store current videomode and controller data so that reconfiguring can
be done easily. Reconfiguring would be required in fb_set_par, which
is going to be added soon.
If these details are not stored, the work probe does to retrieve these
information would have to repeated at the place of reconfiguring and
modifying platform data would be necessary to handle controller data
changes like bpp.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 18834fa..d060f14 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -178,6 +178,8 @@ struct da8xx_fb_par {
#endif
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
+ struct fb_videomode mode;
+ struct lcd_ctrl_config cfg;
};
static struct fb_var_screeninfo da8xx_fb_var;
@@ -1310,6 +1312,8 @@ static int fb_probe(struct platform_device *device)
}
fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
+ fb_var_to_videomode(&par->mode, &da8xx_fb_var);
+ par->cfg = *lcd_cfg;
if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
dev_err(&device->dev, "lcd_init failed\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 04/10] video: da8xx-fb: remove unneeded "var" initialization
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
modedb helper now updates "var" information based on the detected
panel, remove the unnecessary initialization.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index a1f6544..18834fa 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,10 +131,6 @@
#define WSI_TIMEOUT 50
#define PALETTE_SIZE 256
-#define LEFT_MARGIN 64
-#define RIGHT_MARGIN 64
-#define UPPER_MARGIN 32
-#define LOWER_MARGIN 32
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
@@ -184,23 +180,7 @@ struct da8xx_fb_par {
u32 pseudo_palette[16];
};
-/* Variable Screen Information */
-static struct fb_var_screeninfo da8xx_fb_var = {
- .xoffset = 0,
- .yoffset = 0,
- .transp = {0, 0, 0},
- .nonstd = 0,
- .activate = 0,
- .height = -1,
- .width = -1,
- .accel_flags = 0,
- .left_margin = LEFT_MARGIN,
- .right_margin = RIGHT_MARGIN,
- .upper_margin = UPPER_MARGIN,
- .lower_margin = LOWER_MARGIN,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED
-};
+static struct fb_var_screeninfo da8xx_fb_var;
static struct fb_fix_screeninfo da8xx_fb_fix = {
.id = "DA8xx FB Drv",
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 03/10] video: da8xx-fb: use modedb helper to update var
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
modedb structure is now used to store panel information, run modedb
helper over it for initial update of "var" information instead of
equating each fields.
While at it, remove redundant update of bits_per_pixel.
Note: pixclock is overridden with proper value using an existing code
as currently modedb is having it in Hz instead of ps, this would be
fixed in a later change and this overide would be removed.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 52977b1..a1f6544 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1329,6 +1329,8 @@ static int fb_probe(struct platform_device *device)
par->panel_power_ctrl(1);
}
+ fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
+
if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
dev_err(&device->dev, "lcd_init failed\n");
ret = -EFAULT;
@@ -1381,25 +1383,9 @@ static int fb_probe(struct platform_device *device)
goto err_release_pl_mem;
}
- /* Initialize par */
- da8xx_fb_info->var.bits_per_pixel = lcd_cfg->bpp;
-
- da8xx_fb_var.xres = lcdc_info->xres;
- da8xx_fb_var.xres_virtual = lcdc_info->xres;
-
- da8xx_fb_var.yres = lcdc_info->yres;
- da8xx_fb_var.yres_virtual = lcdc_info->yres * LCD_NUM_BUFFERS;
-
da8xx_fb_var.grayscale lcd_cfg->panel_shade = MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
-
- da8xx_fb_var.hsync_len = lcdc_info->hsync_len;
- da8xx_fb_var.vsync_len = lcdc_info->vsync_len;
- da8xx_fb_var.right_margin = lcdc_info->right_margin;
- da8xx_fb_var.left_margin = lcdc_info->left_margin;
- da8xx_fb_var.lower_margin = lcdc_info->lower_margin;
- da8xx_fb_var.upper_margin = lcdc_info->upper_margin;
da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/10] video: da8xx-fb: simplify lcd_reset
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
lcd_reset function doesn't require any arguement, remove it.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d00dd17..52977b1 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -681,7 +681,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
}
#undef CNVT_TOHW
-static void lcd_reset(struct da8xx_fb_par *par)
+static void da8xx_fb_lcd_reset(void)
{
/* Disable the Raster if previously Enabled */
lcd_disable_raster(false);
@@ -721,7 +721,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- lcd_reset(par);
+ da8xx_fb_lcd_reset();
/* Calculate the divider */
lcd_calc_clk_divider(par);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 01/10] video: da8xx-fb: fb_check_var enhancement
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
Check whether "struct fb_var_screeninfo" fields are sane, if not
update it to be within allowed limits.
If user sends down buggy "var" values, this will bring those within
allowable limits. And fb_set_par is not supposed to change "var"
values, fb_check_var has to ensure that values are proper.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0810939..d00dd17 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -888,6 +888,9 @@ static int fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
int err = 0;
+ struct da8xx_fb_par *par = info->par;
+ int bpp = var->bits_per_pixel >> 3;
+ unsigned long line_size = var->xres_virtual * bpp;
if (var->bits_per_pixel > 16 && lcd_revision = LCD_VERSION_1)
return -EINVAL;
@@ -955,6 +958,21 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->green.msb_right = 0;
var->blue.msb_right = 0;
var->transp.msb_right = 0;
+
+ if (line_size * var->yres_virtual > par->vram_size)
+ var->yres_virtual = par->vram_size / line_size;
+
+ if (var->yres > var->yres_virtual)
+ var->yres = var->yres_virtual;
+
+ if (var->xres > var->xres_virtual)
+ var->xres = var->xres_virtual;
+
+ if (var->xres + var->xoffset > var->xres_virtual)
+ var->xoffset = var->xres_virtual - var->xres;
+ if (var->yres + var->yoffset > var->yres_virtual)
+ var->yoffset = var->yres_virtual - var->yres;
+
return err;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 00/10] video: da8xx-fb: runtime timing configuration
From: Afzal Mohammed @ 2013-01-15 13:42 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
Hi,
This series makes da8xx-fb driver (device found on DaVinci and AM335x)
capable of handling runtime timing configuration by adding fb_set_par.
The last change adds actual fb_set_par support. Other preceeding
changes makes the way clear for it as well as does certain cleanup's
on the way.
This has been tested on da850 evm as is. This was also tested on
am335x-evm & am335x-evmsk with a series that adds DT support.
This is based on v3.8-rc3, this is the only change in this revision.
The new version of this series is being posted so that this series can
be applied easily (as __dev* are removed, there would be merge
conflicts with v2, which was based on -rc2).
series
Regards
Afzal
v3: rebased over -rc3, no functional changes
v2: disable raster in fb_set_par properly
Afzal Mohammed (10):
video: da8xx-fb: fb_check_var enhancement
video: da8xx-fb: simplify lcd_reset
video: da8xx-fb: use modedb helper to update var
video: da8xx-fb: remove unneeded "var" initialization
video: da8xx-fb: store current display information
video: da8xx-fb: store clk rate even if !CPUFREQ
video: da8xx-fb: pix clk and clk div handling cleanup
video: da8xx-fb: store struct device *
video: da8xx-fb: report correct pixclock
video: da8xx-fb: fb_set_par support
drivers/video/da8xx-fb.c | 185 ++++++++++++++++++++++++++--------------------
1 file changed, 105 insertions(+), 80 deletions(-)
--
1.7.9.5
^ permalink raw reply
* fb: Rework locking to fix lock ordering on takeover
From: Sedat Dilek @ 2013-01-13 15:14 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-fbdev, LKML, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Hi Andrew,
your patch from [1] - as far as I followed - misses a lot of
Reported-by#s and Tested-by#s (Boris, Jiri, etc.).
Just one new R-b I have seen yesterday.
I have the original patch from Alan plus the two follow-ups from you
in my patch-series against v3.8-{rc2,rc3} for quite a while.
So, please feel free to add a Tested-by.
Unfortunately, your patch has introduced some (unwanted) extra chars
like "_*" (comments only).
I appreciate one single (new) patch like this, but please in a proper way.
A disappeared/busy/not-answering maintainer is not an excuse for
handling serious regressions (even here in this case there are fixes
around),
Personally, I am still missing a mei-driver fix [2] and a libata-dev fix [3].
Both issues are not new to the maintainers.
Not sure if shouting louder is the best strategy here.
It would be great to have a place like a "board of arbitration" where
someone can send blames.
And I remember vaguely Rafael had a nice list of issues (w/ reference
to patches!).
This was a real cool helpful innoivation!
I can't remember why Rafael stopped his nice service to the
Linux-kernel community.
Have fun!
Regards,
- Sedat -
[1] https://patchwork.kernel.org/patch/1969391/
[2] http://git.kernel.org/?p=linux/kernel/git/gregkh/char-misc.git;a=commitdiff;h=e6028db0146cf5a68dbd1508225ea49840997880
[3] http://patchwork.ozlabs.org/patch/206897/
[-- Attachment #2: fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch --]
[-- Type: application/octet-stream, Size: 823 bytes --]
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 347bed0..1db1c8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3653,7 +3653,7 @@ int do_take_over_console(const struct consw *csw, int first, int last, int deflt
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- _* but not unregistered it.
+ * but not unregistered it.
*/
if (err == -EBUSY)
err = 0;
@@ -3679,7 +3679,7 @@ int take_over_console(const struct consw *csw, int first, int last, int deflt)
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- _* but not unregistered it.
+ * but not unregistered it.
*/
if (err == -EBUSY)
err = 0;
^ permalink raw reply related
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-13 12:24 UTC (permalink / raw)
To: Bernie Thompson
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <50F2A310.5010006@ahsoftware.de>
Am 13.01.2013 13:05, schrieb Alexander Holler:
> Am 12.01.2013 23:22, schrieb Bernie Thompson:
> I didn't test it extensively, but without the patch the driver isn't
> usable here. Maybe my previous patch which moves damages to a workqueue
To add some more explanations, I'm currently only testing it with a
statically linked udlfb (for fbcon) as that is what I'm mainly using the
device for (with otherwise headless boxes). When udlfb is a module, I
don't see those "schedule while atomic" messages (I don't know why), but
having a console only after the modules got loaded isn't always an option.
Regards,
Alexander
^ permalink raw reply
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-13 12:05 UTC (permalink / raw)
To: Bernie Thompson
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <CAF1V4O8UUgWB1XbS=3EsirBjhP9Lp7JQ8XK8MQxbe3ZkH8pd3Q@mail.gmail.com>
Am 12.01.2013 23:22, schrieb Bernie Thompson:
> Hi Alexander,
>
> On Sat, Jan 12, 2013 at 5:20 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>> When a device was disconnected the driver may hang at waiting for urbs it never
>> will get. Fix this by using a timeout while waiting for the used semaphore.
>
> The code used to be this way, but it used to cause nasty shutdown hangs:
> http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h\x1dd39a65001deb5a84088dfabb788d3274fbb6b6
>
> Which is why the code is the way it is today.
>
> Can you say under what situations you're hitting hangs on device
> disconnect? Have you tested extensively to confirm no shutdown hangs
> with your patch?
>
The driver almost always (2/3) hangs here when the device gets
disconnected. It is easy to see when the device gets attached again as
nothing will happen if the driver (already) hangs (in addition that a
shutdown isn't possible).
I didn't test it extensively, but without the patch the driver isn't
usable here. Maybe my previous patch which moves damages to a workqueue
is the reason that it's more likely that urbs get missing, but the
problem already existed because an urb might get missed on disconnect. I
don't know what problems existed before, maybe people just had a problem
with the BUG_ON(ret). If that _interrupted_ is really needed, it could
make sense to implement a down_timeout_interruptible() for semaphores.
> Stepping back, there was another recent patch from the community to
> udlfb to work around issues of sleeping in the wrong context. The fix
> involved introducing another scheduled workitem. This slows everything
> down when it's in the main path, and isn't really desirable if we can
> avoid it.
Do you mean the one I've recently posted? It is needed, at least for 3.7
(I don't know since when those "schedule while atomic" messages appear).
It might slow down refreshes, but it is needed, at least until someone
gets around those semaphores or removes the spinlocks in upper layers
(as Alan Cox suggested with the "I am crap" helper for printk).
Maybe using a WQ_HIGHPRI for the workqueue with the damages will speed
up things.
More optimizations might be doable too (e.g. combining multiple queued
damages).
> Another option to eliminate all these problems -- long considered but
> never implemented -- is to get rid of all semaphores and potential
> sleeps in udlfb entirely. That would require a strategy to throttle
> rendering in some way other than by waiting in kernel (without some
> throttling strategy, the USB bus can be a bottleneck which can flood
> the system with rendered but untransmitted pixels).
>
> Options might be:
>
> 1) When transfer buffers are full, keep track of dirty rectangles for
> the rest and pick up where we left off the next time we're entered
> (avoiding flooding by potentially having pixels in the dirty regions
> be written over multiple times before we get to rendering them once)
>
> 2 ) If we "bet" on page-fault-based defio dirty pixel detection, we
> could allocate buffers dynamically but increase the scheduling time to
> transfer as our outstanding buffer count grows, and reduce the latency
> only when the buffer count goes down (again, pixels will be
> potentially rendered many times before being transfered once, avoiding
> flooding).
>
> Any other ideas on the specific or general case are welcome. Also
> note that udlfb is being largely superceeded by the udl DRM driver -
> so any decisions here should also be considered in that codebase.
>
> In any case, thanks for giving the DisplayLink USB 2.0 graphics
> drivers attention - it's much appreciated!
Thanks for the sugestions, but I don't feel the need to spend a lot of
time here. I just wanted to use the console with the device and a kernel
3.7.x and neither udlfb nor udl currently worked (and I'm pretty sure
I've used one of them some time before, likely udlfb).
Btw, to see the console again after a disconnect and connect, I'm
currently using the following (necessary) quick&dirty hack:
---------
/* if clients still have us open, will be freed on last close */
- if (dev->fb_count = 0)
+// if (dev->fb_count = 0)
schedule_delayed_work(&dev->free_framebuffer_work, 0);
---------
Without that the framebuffer will never get unregistered (because just
unlinking it doesn't remove the fb-console which counts for one client)
with the result that the new one (after connecting the device again)
will not get the console.
Regards,
Alexander
^ permalink raw reply
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Bernie Thompson @ 2013-01-12 22:22 UTC (permalink / raw)
To: Alexander Holler
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <1357996822-13072-1-git-send-email-holler@ahsoftware.de>
Hi Alexander,
On Sat, Jan 12, 2013 at 5:20 AM, Alexander Holler <holler@ahsoftware.de> wrote:
> When a device was disconnected the driver may hang at waiting for urbs it never
> will get. Fix this by using a timeout while waiting for the used semaphore.
The code used to be this way, but it used to cause nasty shutdown hangs:
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h\x1dd39a65001deb5a84088dfabb788d3274fbb6b6
Which is why the code is the way it is today.
Can you say under what situations you're hitting hangs on device
disconnect? Have you tested extensively to confirm no shutdown hangs
with your patch?
Stepping back, there was another recent patch from the community to
udlfb to work around issues of sleeping in the wrong context. The fix
involved introducing another scheduled workitem. This slows everything
down when it's in the main path, and isn't really desirable if we can
avoid it.
Another option to eliminate all these problems -- long considered but
never implemented -- is to get rid of all semaphores and potential
sleeps in udlfb entirely. That would require a strategy to throttle
rendering in some way other than by waiting in kernel (without some
throttling strategy, the USB bus can be a bottleneck which can flood
the system with rendered but untransmitted pixels).
Options might be:
1) When transfer buffers are full, keep track of dirty rectangles for
the rest and pick up where we left off the next time we're entered
(avoiding flooding by potentially having pixels in the dirty regions
be written over multiple times before we get to rendering them once)
2 ) If we "bet" on page-fault-based defio dirty pixel detection, we
could allocate buffers dynamically but increase the scheduling time to
transfer as our outstanding buffer count grows, and reduce the latency
only when the buffer count goes down (again, pixels will be
potentially rendered many times before being transfered once, avoiding
flooding).
Any other ideas on the specific or general case are welcome. Also
note that udlfb is being largely superceeded by the udl DRM driver -
so any decisions here should also be considered in that codebase.
In any case, thanks for giving the DisplayLink USB 2.0 graphics
drivers attention - it's much appreciated!
Bernie Thompson
http://plugable.com/
^ permalink raw reply
* [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-12 13:20 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Bernie Thompson, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, Alexander Holler, stable
When a device was disconnected the driver may hang at waiting for urbs it never
will get. Fix this by using a timeout while waiting for the used semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/video/udlfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 86d449e..cc4a8d1 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1832,8 +1832,8 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout(&dev->urbs.limit_sem, GET_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
^ permalink raw reply related
* fb_image.data format for cursors?
From: Timur Tabi @ 2013-01-11 23:22 UTC (permalink / raw)
To: linux-fbdev
Is there any documentation for cursor support? I'm trying to add cursor
support to my framebuffer driver, and I'm having a really hard time find a
description of anything.
In particular, what is the format of the image data in the fb_image.data
buffer? For example, if fb_image.width = 12, and fb_image.height = 8,
how is the cursor data packed into the 'data' buffer? That is, what is in
data[0], data[1], etc?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [patch] sisfb: fix 1280x720 resolution support
From: Dan Carpenter @ 2013-01-11 6:52 UTC (permalink / raw)
To: linux-fbdev
It uses the wrong mode index because there is no break statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker fix. Untested.
diff --git a/drivers/video/sis/init.c b/drivers/video/sis/init.c
index f082ae5..0b71c53 100644
--- a/drivers/video/sis/init.c
+++ b/drivers/video/sis/init.c
@@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
switch(VDisplay) {
case 720:
ModeIndex = ModeIndex_1280x720[Depth];
+ break;
case 768:
if(VGAEngine = SIS_300_VGA) {
ModeIndex = ModeIndex_300_1280x768[Depth];
^ permalink raw reply related
* RE: [PATCHv16 0/7] of: add display helper
From: Mohammed, Afzal @ 2013-01-10 4:58 UTC (permalink / raw)
To: Steffen Trumtrar, devicetree-discuss@lists.ozlabs.org
Cc: Rob Herring, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, Laurent Pinchart, Thierry Reding,
Guennady Liakhovetski, linux-media@vger.kernel.org,
Valkeinen, Tomi, Stephen Warren, kernel@pengutronix.de,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala, Nori, Sekhar
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
SGkgU3RlZmZlbiwNCg0KT24gVGh1LCBKYW4gMTAsIDIwMTMgYXQgMDE6NDU6NDEsIFN0ZWZmZW4g
VHJ1bXRyYXIgd3JvdGU6DQoNCj4gSSB0aGluayB0aGUgc2VyaWVzIHdhcyB0ZXN0ZWQgYXQgbGVh
c3Qgd2l0aA0KPiAJLSBpbXg2cTogc2FicmVsaXRlLCBzYWJyZXNkDQo+IAktIGlteDUzOiB0cW1h
NTMvbWJhNTMNCj4gCS0gb21hcDogREE4NTAgRVZNLCBBTTMzNXggRVZNLCBFVk0tU0sNCg0KVG8g
Y2xhcmlmeSwNCg0KVGhpcyBzZXJpZXMgd2FzIHRlc3RlZCB3aXRoIERUIGJvb3QgKG1ha2luZyB1
c2Ugb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KcHJvdmlkZWQgYnkgdGhpcyBzZXJpZXMpIG9uIEFN
MzM1WCBFVk0gJiBBTTMzNVggRVZNLVNLLiBEQTg1MCBFVk0gd2FzDQp0ZXN0ZWQgd2l0aCBub24g
RFQgYm9vdCBhbG9uZyB3aXRoIHRoaXMgc2VyaWVzICh0byBtYWtlIHN1cmUgdGhhdA0Kbm9uLURU
IGJvb3Qgb24gREE4NTAgRVZNIGlzIG5vdCBicm9rZW4sIGFuZCBpdCBuZWVkZWQgdGhlIGFkZGl0
aW9uYWwNCmNoYW5nZSB0aGF0IHdhcyBtZW50aW9uZWQgZWFybGllcikNCg0KU29ycnkgdGhhdCBt
eSBpbml0aWFsIHJlcGx5IGRpZCBub3QgZXhwcmVzcyB3aGF0IEkgd2FudGVkIHRvLg0KDQpSZWdh
cmRzDQpBZnphbA0KDQoNCg=
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Leela Krishna Amudala @ 2013-01-10 2:52 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
Hi Steffen,
On Thu, Jan 10, 2013 at 1:45 AM, Steffen Trumtrar
<s.trumtrar@pengutronix.de> wrote:
>
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
> >
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
I tested V16 patches with Exynos: smdk5250 board and it works fine for me.
> Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
>
> Thanks,
> Steffen
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Marek Vasut @ 2013-01-09 20:59 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
Dear Steffen Trumtrar,
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
MX53QSB and another custom MX53 board.
> Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
>
> Thanks,
> Steffen
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Laurent Pinchart @ 2013-01-09 20:42 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev, Stephen Warren, devicetree-discuss,
Florian Tobias Schandinat, dri-devel, Tomi Valkeinen, Rob Herring,
kernel, Guennady Liakhovetski, linux-media
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
On Wednesday 09 January 2013 21:15:41 Steffen Trumtrar wrote:
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
I've used the sh-mobile-lcdcfb driver.
> Those are the people I know from the top of my head, that use or at least
> did use the patches in one of its iterations. If I forgot anyone, please
> speak up and possibly add your new HW to the list of tested devices.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Thierry Reding @ 2013-01-09 20:37 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, David Airlie,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Clark,
Tomi Valkeinen, Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130109201541.GB4780-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Wed, Jan 09, 2013 at 09:15:41PM +0100, Steffen Trumtrar wrote:
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
> >
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using. Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
I tested earlier versions on Tegra. The latest one was v15 I think.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ 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