* [PATCH] fb_defio: add first_io callback
From: Heiko Stübner @ 2011-12-31 10:45 UTC (permalink / raw)
To: linux-fbdev
With this optional callback the driver is notified when the first page
is entered into the pagelist and a new deferred_io call is scheduled.
A possible use-case for this is runtime-pm. In the first_io call
pm_runtime_get()
could be called, which starts an asynchronous runtime_resume of the
device. In the deferred_io callback a call to
pm_runtime_barrier()
makes the sure, the device is resumed by then and a
pm_runtime_put()
may put the device back to sleep.
Also, some SoCs may use the runtime-pm system to determine if they
are able to enter deeper idle states. Therefore it is necessary to
keep the use-count from the first written page until the conclusion
of the screen update, to prevent the system from going to sleep before
completing the pending update.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/video/fb_defio.c | 4 ++++
include/linux/fb.h | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index c27e153..070f26f 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -107,6 +107,10 @@ static int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
/* protect against the workqueue changing the page list */
mutex_lock(&fbdefio->lock);
+ /* first write in this cycle, notify the driver */
+ if (fbdefio->first_io && list_empty(&fbdefio->pagelist))
+ fbdefio->first_io(info);
+
/*
* We want the page to remain locked from ->page_mkwrite until
* the PTE is marked dirty to avoid page_mkclean() being called
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..b86cd41 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -602,6 +602,7 @@ struct fb_deferred_io {
struct mutex lock; /* mutex that protects the page list */
struct list_head pagelist; /* list of touched pages */
/* callback */
+ void (*first_io)(struct fb_info *info);
void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
};
#endif
--
1.7.2.3
^ permalink raw reply related
* RE: [PATCH v2] video: da8xx-fb: reset LCDC only if functional clock
From: Manjunathappa, Prakash @ 2012-01-03 5:41 UTC (permalink / raw)
To: linux-fbdev
Hi,
On Thu, Dec 22, 2011 at 14:49:14, Manjunathappa, Prakash wrote:
> LCDC functional clock may or may not be derived from CPU/MPU DPLL, For example, AM335x => Separate independent DPLL for LCDC Davinci => Same DPLL as MPU
>
> So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module as its functional clock does not change with DVFS.
>
> This patch adds check to do reset only if functional clock changes between pre and post notifier callbacks with DVFS.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> drivers/video/da8xx-fb.c | 15 ++++++++++-----
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 6b27751..6146186 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -163,6 +163,7 @@ struct da8xx_fb_par {
> int vsync_timeout;
> #ifdef CONFIG_CPU_FREQ
> struct notifier_block freq_transition;
> + unsigned int lcd_fck_rate;
> #endif
> void (*panel_power_ctrl)(int);
> };
> @@ -895,11 +896,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb,
> struct da8xx_fb_par *par;
>
> par = container_of(nb, struct da8xx_fb_par, freq_transition);
> - if (val = CPUFREQ_PRECHANGE) {
> - lcd_disable_raster();
> - } else if (val = CPUFREQ_POSTCHANGE) {
> - lcd_calc_clk_divider(par);
> - lcd_enable_raster();
> + if (val = CPUFREQ_POSTCHANGE) {
> + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) {
I need to update par->lcd_fck_rate here, I will send v3 of this patch.
Thanks,
Prakash
> + lcd_disable_raster();
> + lcd_calc_clk_divider(par);
> + lcd_enable_raster();
> + }
> }
>
> return 0;
> @@ -1192,6 +1194,9 @@ static int __devinit 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->pxl_clk;
> if (fb_pdata->panel_power_ctrl) {
> par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: [PATCH] OMAPDSS: add OrtusTech COM43H4M10XTC display support
From: Tomi Valkeinen @ 2012-01-03 9:30 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-fbdev, linux-omap, sasha_d
In-Reply-To: <1324940201-16079-1-git-send-email-yanok@emcraft.com>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
On Mon, 2011-12-26 at 23:56 +0100, Ilya Yanok wrote:
> dd data for the OrtusTech COM43H4M10XTC display to the
> generic_dpi_panel driver.
>
> CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> drivers/video/omap2/displays/panel-generic-dpi.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index 593f831..99669ae 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -317,6 +317,26 @@ static struct panel_config generic_dpi_panels[] = {
> OMAP_DSS_LCD_IHS,
> .name = "focaltech_etm070003dh6",
> },
> + /* OrtusTech COM43H4M10XTC */
> + {
> + {
> + .x_res = 480,
> + .y_res = 272,
> +
> + .pixel_clock = 8000,
> +
> + .hsw = 41,
> + .hfp = 8,
> + .hbp = 4,
> +
> + .vsw = 10,
> + .vfp = 4,
> + .vbp = 2,
> + },
> + .config = OMAP_DSS_LCD_TFT,
> +
> + .name = "ortustech_com43h4m10xtc",
> + },
> };
>
Thanks, I'll apply to DSS tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v3] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS
From: Manjunathappa, Prakash @ 2012-01-03 12:52 UTC (permalink / raw)
To: linux-fbdev
LCDC functional clock may or may not be derived from CPU/MPU DPLL,
For example,
AM335x => Separate independent DPLL for LCDC
Davinci => Same DPLL as MPU
So, on platforms where LCDC functional clock is not derived from CPU/MPU
PLL it is not required to reset LCDC module as its functional clock does
not change with DVFS.
This patch adds check to do reset only if functional clock changes
between pre and post notifier callbacks with DVFS.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
Since v2:
Fix, update lcd_fck_rate with current LCD functional clock rate.
Since v1:
Fixed the commit message.
drivers/video/da8xx-fb.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 6b27751..dee1918 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -163,6 +163,7 @@ struct da8xx_fb_par {
int vsync_timeout;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
+ unsigned int lcd_fck_rate;
#endif
void (*panel_power_ctrl)(int);
};
@@ -895,11 +896,13 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb,
struct da8xx_fb_par *par;
par = container_of(nb, struct da8xx_fb_par, freq_transition);
- if (val = CPUFREQ_PRECHANGE) {
- lcd_disable_raster();
- } else if (val = CPUFREQ_POSTCHANGE) {
- lcd_calc_clk_divider(par);
- lcd_enable_raster();
+ if (val = CPUFREQ_POSTCHANGE) {
+ if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) {
+ par->lcd_fck_rate = clk_get_rate(par->lcdc_clk);
+ lcd_disable_raster();
+ lcd_calc_clk_divider(par);
+ lcd_enable_raster();
+ }
}
return 0;
@@ -1192,6 +1195,9 @@ static int __devinit 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->pxl_clk;
if (fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
--
1.7.1
^ permalink raw reply related
* [PATCH] intelfbdrv.c: bailearly is an int module_param
From: Rusty Russell @ 2012-01-04 2:41 UTC (permalink / raw)
To: Maik Broemme; +Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel
In-Reply-To: <20120103131748.GA11575@elgon.mountain>
Dan Carpenter points out that it's an int, not a bool:
intelfbdrv.c:818: if (bailearly = 1)
intelfbdrv.c:828: if (bailearly = 2)
intelfbdrv.c:836: if (bailearly = 3)
intelfbdrv.c:842: if (bailearly = 4)
intelfbdrv.c:851: if (bailearly = 5)
intelfbdrv.c:859: if (bailearly = 6)
intelfbdrv.c:866: bailearly > 6 ? bailearly - 6 : 0);
intelfbdrv.c:874: if (bailearly = 18)
intelfbdrv.c:886: if (bailearly = 19)
intelfbdrv.c:893: if (bailearly = 20)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/video/intelfb/intelfbdrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -263,7 +263,7 @@ module_param(probeonly, bool, 0);
MODULE_PARM_DESC(probeonly, "Do a minimal probe (debug)");
module_param(idonly, bool, 0);
MODULE_PARM_DESC(idonly, "Just identify without doing anything else (debug)");
-module_param(bailearly, bool, 0);
+module_param(bailearly, int, 0);
MODULE_PARM_DESC(bailearly, "Bail out early, depending on value (debug)");
module_param(mode, charp, S_IRUGO);
MODULE_PARM_DESC(mode,
^ permalink raw reply
* Re: [PATCH] video/omap2. dispc_mgr_enable needs runtime PM
From: Tomi Valkeinen @ 2012-01-04 7:50 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20111230123755.384a5b5c@notabene.brown>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
(dropping the Tony and Kevin, as they're probably not interested in
this)
On Fri, 2011-12-30 at 12:37 +1100, NeilBrown wrote:
>
> When dispc_mgr_enable is called during shutdown the device might
> be asleep, which causes problems. So ensure it is awake.
How does this problem happen? dispc_mgr_enable(channel, false) shouldn't
be called if the device is asleep, and thus dispc_mgr_enable() shouldn't
use dispc_runtime_get.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] backlight: Convert pwm_bl to dev_pm_ops
From: Andrew Morton @ 2012-01-04 22:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1325182838-25729-2-git-send-email-broonie@opensource.wolfsonmicro.com>
On Thu, 29 Dec 2011 18:20:38 +0000
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> Should be no functional changes, mainly a reorganisation to support
> future work.
>
> ...
>
> -#define pwm_backlight_suspend NULL
> -#define pwm_backlight_resume NULL
> +#define pwm_backlight_pm_ops NULL
> #endif
>
> static struct platform_driver pwm_backlight_driver = {
> .driver = {
> .name = "pwm-backlight",
> .owner = THIS_MODULE,
> + .pm = &pwm_backlight_pm_ops,
This:
.pm = &NULL,
will not compile.
Please review and test:
From: Andrew Morton <akpm@linux-foundation.org>
Subject: backlight-convert-pwm_bl-to-dev_pm_ops-fix
Fix CONFIG_PM=n build
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/backlight/pwm_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/video/backlight/pwm_bl.c~backlight-convert-pwm_bl-to-dev_pm_ops-fix drivers/video/backlight/pwm_bl.c
--- a/drivers/video/backlight/pwm_bl.c~backlight-convert-pwm_bl-to-dev_pm_ops-fix
+++ a/drivers/video/backlight/pwm_bl.c
@@ -194,15 +194,15 @@ static int pwm_backlight_resume(struct d
static SIMPLE_DEV_PM_OPS(pwm_backlight_pm_ops, pwm_backlight_suspend,
pwm_backlight_resume);
-#else
-#define pwm_backlight_pm_ops NULL
#endif
static struct platform_driver pwm_backlight_driver = {
.driver = {
.name = "pwm-backlight",
.owner = THIS_MODULE,
+#ifdef CONFIG_PM
.pm = &pwm_backlight_pm_ops,
+#endif
},
.probe = pwm_backlight_probe,
.remove = pwm_backlight_remove,
_
^ permalink raw reply
* Re: [PATCH v5 2/2] video: backlight: support s6e8ax0 panel driver
From: Andrew Morton @ 2012-01-05 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EF15F9C.9030807@samsung.com>
On Wed, 21 Dec 2011 13:25:00 +0900
Donghwa Lee <dh09.lee@samsung.com> wrote:
>
> This patch is amoled panel driver based MIPI DSI interface.
> S6E8AX0 means it may includes many other ldi controllers, for example,
> S6E8AA0, S6E8AB0, and so on.
>
> This patch can be modified depending on each panel properites. For example,
> second parameter of panel condition register can be changed depending on
> ldi controller or amoled type.
>
>
> ...
>
> +static unsigned char s6e8ax0_22_gamma_30[] = {
> + 0xFA, 0x01, 0x60, 0x10, 0x60, 0xF5, 0x00, 0xFF, 0xAD, 0xAF,
> + 0xBA, 0xC3, 0xD8, 0xC5, 0x9F, 0xC6, 0x9E, 0xC1, 0xDC, 0xC0,
> + 0x00, 0x61, 0x00, 0x5A, 0x00, 0x74,
> +};
> +
>
> ...
>
> +static unsigned char s6e8ax0_22_gamma_300[] = {
> + 0xFA, 0x01, 0x60, 0x10, 0x60, 0xB5, 0xD3, 0xBD, 0xB1, 0xD2,
> + 0xB0, 0xC0, 0xDC, 0xC0, 0x94, 0xBA, 0x91, 0xAC, 0xC5, 0xA9,
> + 0x00, 0xC2, 0x00, 0xB7, 0x00, 0xED,
> +};
> +
> +static unsigned char *s6e8ax0_22_gamma_table[] = {
> + s6e8ax0_22_gamma_30,
> + s6e8ax0_22_gamma_50,
> + s6e8ax0_22_gamma_60,
> + s6e8ax0_22_gamma_70,
> + s6e8ax0_22_gamma_80,
> + s6e8ax0_22_gamma_90,
> + s6e8ax0_22_gamma_100,
> + s6e8ax0_22_gamma_120,
> + s6e8ax0_22_gamma_130,
> + s6e8ax0_22_gamma_140,
> + s6e8ax0_22_gamma_150,
> + s6e8ax0_22_gamma_160,
> + s6e8ax0_22_gamma_170,
> + s6e8ax0_22_gamma_180,
> + s6e8ax0_22_gamma_190,
> + s6e8ax0_22_gamma_200,
> + s6e8ax0_22_gamma_210,
> + s6e8ax0_22_gamma_220,
> + s6e8ax0_22_gamma_230,
> + s6e8ax0_22_gamma_240,
> + s6e8ax0_22_gamma_250,
> + s6e8ax0_22_gamma_260,
> + s6e8ax0_22_gamma_270,
> + s6e8ax0_22_gamma_280,
> + s6e8ax0_22_gamma_300,
> +};
I suggest making all the above arrays const. Otherwise the compiler
might end up deciding to needlessly allocate space in writeable storage
for them.
If that means that ops->cmd_write() needs constification as well then
let's just do that, for it is the right thing to do.
> +static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
> +{
> + struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
> +
> + unsigned char data_to_send[] = {
> + 0xf8, 0x3d, 0x35, 0x00, 0x00, 0x00, 0x93, 0x00, 0x3c,
> + 0x7d, 0x08, 0x27, 0x7d, 0x3f, 0x00, 0x00, 0x00, 0x20,
> + 0x04, 0x08, 0x6e, 0x00, 0x00, 0x00, 0x02, 0x08, 0x08,
> + 0x23, 0x23, 0xc0, 0xc8, 0x08, 0x48, 0xc1, 0x00, 0xc1,
> + 0xff, 0xff, 0xc8
> + };
Arrays like this certainly should be const. As it stands, the compiler
needs to generate room on the stack and generate a local copy of the
array each time this function is called!
> + ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
> + data_to_send, ARRAY_SIZE(data_to_send));
> +}
> +
> +static void s6e8ax0_display_cond(struct s6e8ax0 *lcd)
> +{
> + struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
> + unsigned char data_to_send[] = {
> + 0xf2, 0x80, 0x03, 0x0d
> + };
> +
> + ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
> + data_to_send, ARRAY_SIZE(data_to_send));
> +}
> +
> +/* Gamma 2.2 Setting (200cd, 7500K, 10MPCD) */
> +static void s6e8ax0_gamma_cond(struct s6e8ax0 *lcd)
> +{
> + struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
> + unsigned int gamma = lcd->bd->props.brightness;
> +
> + ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
> + s6e8ax0_22_gamma_table[gamma],
> + ARRAY_SIZE(s6e8ax0_22_gamma_table));
This seems wrong. ARRAY_SIZE(s6e8ax0_22_gamma_table) does not
represent the size of s6e8ax0_22_gamma_table[gamma]!
> +}
> +
>
> ...
>
> +static int s6e8ax0_update_gamma_ctrl(struct s6e8ax0 *lcd, int brightness)
> +{
> + struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
> +
> + ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
> + s6e8ax0_22_gamma_table[brightness],
> + ARRAY_SIZE(s6e8ax0_22_gamma_table));
Ditto.
> + /* update gamma table. */
> + s6e8ax0_gamma_update(lcd);
> + lcd->gamma = brightness;
> +
> + return 0;
> +}
> +
>
> ...
>
> +static void s6e8ax0_power_on(struct mipi_dsim_lcd_device *dsim_dev, int power)
> +{
> + struct s6e8ax0 *lcd = dev_get_drvdata(&dsim_dev->dev);
> +
> + msleep(lcd->ddi_pd->power_on_delay);
> +
> + /* lcd power on */
> + if (power)
> + s6e8ax0_regulator_enable(lcd);
> + else
> + s6e8ax0_regulator_disable(lcd);
> +
> + msleep(lcd->ddi_pd->reset_delay);
> +
> + /* lcd reset */
> + if (lcd->ddi_pd->reset)
> + lcd->ddi_pd->reset(lcd->ld);
> + msleep(5);
> +}
Maybe we should hold lcd->lock across this function to prevent other
code paths from getting in and fiddling with the hardware while it is
powering on?
>
> ...
>
^ permalink raw reply
* Re: [PATCH 2/2] backlight: Convert pwm_bl to dev_pm_ops
From: Mark Brown @ 2012-01-05 5:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1325182838-25729-2-git-send-email-broonie@opensource.wolfsonmicro.com>
On Wed, Jan 04, 2012 at 02:34:22PM -0800, Andrew Morton wrote:
> Please review and test:
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
but it'll probably take me longer than it's worth to get a test done due
to travel.
^ permalink raw reply
* Re: [PATCH] video/omap2. dispc_mgr_enable needs runtime PM
From: NeilBrown @ 2012-01-05 7:32 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1325663456.1875.14.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]
On Wed, 04 Jan 2012 09:50:56 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
wrote:
> (dropping the Tony and Kevin, as they're probably not interested in
> this)
Thanks.... takes a while to figure who cares about what :-)
>
> On Fri, 2011-12-30 at 12:37 +1100, NeilBrown wrote:
> >
> > When dispc_mgr_enable is called during shutdown the device might
> > be asleep, which causes problems. So ensure it is awake.
>
> How does this problem happen? dispc_mgr_enable(channel, false) shouldn't
> be called if the device is asleep, and thus dispc_mgr_enable() shouldn't
> use dispc_runtime_get.
>
> Tomi
>
The stack trace shows:
[ 101.764556] [<c0205b3c>] (dispc_mgr_enable+0x40/0x2e0) from [<c020c10c>] (dss_mgr_disable+0x14/0x20)
[ 101.774078] [<c020c10c>] (dss_mgr_disable+0x14/0x20) from [<c020e500>] (omapdss_dpi_display_disable+0x1c/0x88)
[ 101.784484] [<c020e500>] (omapdss_dpi_display_disable+0x1c/0x88) from [<c021efa4>] (td028ttec1_panel_suspend+0x1c/0x88)
[ 101.795684] [<c021efa4>] (td028ttec1_panel_suspend+0x1c/0x88) from [<c021f03c>] (td028ttec1_panel_disable+0x2c/0x50)
[ 101.806640] [<c021f03c>] (td028ttec1_panel_disable+0x2c/0x50) from [<c020ab6c>] (dss_disable_device+0x20/0x2c)
[ 101.817047] [<c020ab6c>] (dss_disable_device+0x20/0x2c) from [<c024ad08>] (bus_for_each_dev+0x4c/0x8c)
[ 101.826751] [<c024ad08>] (bus_for_each_dev+0x4c/0x8c) from [<c024ca0c>] (platform_drv_shutdown+0x1c/0x24)
[ 101.836700] [<c024ca0c>] (platform_drv_shutdown+0x1c/0x24) from [<c0248164>] (device_shutdown+0xcc/0x10c)
[ 101.846679] [<c0248164>] (device_shutdown+0xcc/0x10c) from [<c004c134>] (kernel_power_off+0x10/0x4c)
[ 101.856170] [<c004c134>] (kernel_power_off+0x10/0x4c) from [<c004c420>] (sys_reboot+0x124/0x1e0)
[ 101.865325] [<c004c420>] (sys_reboot+0x124/0x1e0) from [<c000e9c0>] (ret_fast_syscall+0x0/0x3c)
td028ttec1_panel_* are in a non-mainline driver that could well be buggy.
.....
yep, that looks likely. The 'disable' routines of other panels only call
omapdss_dpi_display_disable() if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE).
This panel calls it unconditionally. I guess that is the real bug? (and
putting an appropriate test in fixes it).
Thanks for your help.
(If/when I get this td028ttec driver cleaned up, would you be the one I send
it to?)
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] video/omap2. dispc_mgr_enable needs runtime PM
From: Tomi Valkeinen @ 2012-01-05 7:40 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20120105183241.751b8086@notabene.brown>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
On Thu, 2012-01-05 at 18:32 +1100, NeilBrown wrote:
> On Wed, 04 Jan 2012 09:50:56 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
> wrote:
>
> yep, that looks likely. The 'disable' routines of other panels only call
> omapdss_dpi_display_disable() if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE).
> This panel calls it unconditionally. I guess that is the real bug? (and
> putting an appropriate test in fixes it).
Yes, that's the bug then. The enable and disable calls must match.
> Thanks for your help.
>
> (If/when I get this td028ttec driver cleaned up, would you be the one I send
> it to?)
Yep. However, I'm currently working on device tree support for omapdss,
which will affect all panel drivers, and I may reject any new panel
patches until the dev tree stuff is in. But please send anyway =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [GIT PULL] OMAP DSS for v3.3
From: Tomi Valkeinen @ 2012-01-05 8:56 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 9523 bytes --]
Hi Florian,
Here are changes to OMAP display subsystem driver for the merge window.
This merges and works fine with v3.2, and also merges fine with
linux-next. I haven't been able to test with linux-next as there seems
to be other brokenness there.
Tomi
The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:
Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-florian
Archit Taneja (3):
OMAPDSS: DSI: Fix HSDIV related PLL info in dsi_dump_clocks()
OMAPDSS: Panel NEC: Set omap_dss_device states correctly
OMAPDSS: Displays: Make PICODLP driver depend on DPI
Axel Lin (2):
video: omap: Staticise non-exported symbols
video: omap: convert drivers/video/omap/* to use module_platform_driver()
Chandrabhanu Mahapatra (2):
OMAPDSS: DISPC: Update Fir Coefficients
OMAPDSS: DISPC: Update Scaling Clock Logic
Daniel Mack (1):
OMAP: DSS2: Support for UMSH-8173MD TFT panel
Ilya Yanok (2):
OMAPDSS: add FocalTech ETM070003DH6 display support
OMAPDSS: add OrtusTech COM43H4M10XTC display support
Mythri P K (2):
OMAPDSS: HDMI: Move duplicate code from boardfile
OMAPDSS: HDMI: Disable DDC internal pull up
Ricardo Neri (4):
ASoC: OMAP: HDMI: Introduce driver data for audio codec
ASoC: OMAP: HDMI: Correct signature of ASoC functions
OMAPDSS: HDMI: Create function to enable HDMI audio
ASoC: OMAP: HDMI: Move HDMI codec trigger function to generic HDMI driver
Rob Clark (2):
OMAPDSS: fix potential NULL pointer ref in OCP_ERR handling path
OMAPDSS: APPLY: fix NULL pointer deref when mgr is not set
Tomi Valkeinen (90):
OMAPDSS: DSI: flush posted write when entering ULPS
OMAPDSS: DSI: flush posted write in send_bta
OMAPDSS: DISPC: Flush posted writes when enabling outputs
OMAPDSS: DSI: count with number of lanes
OMAPDSS: DSI: Parse lane config
OMAPDSS: DSI: Use new lane config in dsi_set_lane_config
OMAPDSS: DSI: use lane config in dsi_get_lane_mask
OMAPDSS: DSI: use lane config in dsi_cio_wait_tx_clk_esc_reset
OMAPDSS: DSI: use lane config in dsi_cio_enable_lane_override
OMAPDSS: DSI: remove dsi_get_num_lanes_used
OMAPDSS: DSI: fix lane handling when entering ULPS
OMAPDSS: DSI: improve wait_for_bit_change
OMAPDSS: DSI: disable DDR_CLK_ALWAYS_ON when entering ULPS
OMAPDSS: DISPC: add missing prototype
OMAPDSS: Remove old fifomerge hacks
OMAPDSS: remove L4_EXAMPLE code
OMAPDSS: DISPC: make dispc_ovl_set_channel_out() public
OMAPDSS: DISPC: make dispc_ovl_set_fifo_threshold() public
OMAPDSS: remove partial update from the overlay manager
OMAPDSS: remove partial update from DSI
OMAPDSS: remove partial update from panel-taal
OMAPDSS: pass ovl manager to dss_start_update
OMAPDSS: DISPC: handle 0 out_width/out_height in ovl_setup()
OMAPDSS: handle ilace/replication when configuring overlay
OMAPDSS: separate FIFO threshold setup from ovl_setup
OMAPDSS: separate overlay channel from ovl_setup
OMAPDSS: setup manager with dispc_mgr_setup()
OMAPDSS: DISPC: remove unused functions
OMAPDSS: remove unneeded dss_ovl_wait_for_go()
OMAPDSS: add ovl/mgr_manual_update() helpers
OMAPDSS: split omap_dss_mgr_apply() to smaller funcs
OMAPDSS: apply affects only one overlay manager
OMAPDSS: create apply.c
OMAPDSS: hide manager's enable/disable()
OMAPDSS: APPLY: track whether a manager is enabled
OMAPDSS: APPLY: skip isr register and config for manual update displays
OMAPDSS: APPLY: skip isr register and config for disabled displays
OMAPDSS: APPLY: cleanup dss_mgr_start_update
OMAPDSS: store overlays in an array
OMAPDSS: store managers in an array
OMAPDSS: store overlays in a list for each manager
OMAPDSS: APPLY: separate vsync isr register/unregister
OMAPDSS: DISPC: Add dispc_mgr_get_vsync_irq()
OMAPDSS: APPLY: use dispc_mgr_get_vsync_irq()
OMAPDSS: APPLY: configure_* funcs take ovl/manager as args
OMAPDSS: APPLY: rename overlay_cache_data
OMAPDSS: APPLY: rename manager_cache_data
OMAPDSS: APPLY: move spinlock outside the struct
OMAPDSS: APPLY: rename dss_cache to dss_data
OMAPDSS: APPLY: move ovl funcs to apply.c
OMAPDSS: APPLY: move mgr funcs to apply.c
OMAPDSS: remove ovl/mgr check-code temporarily
OMAPDSS: APPLY: add mutex
OMAPDSS: APPLY: add missing uses of spinlock
OMAPDSS: DSI: call mgr_enable/disable for cmd mode displays
OMAPDSS: APPLY: move mgr->enabled to mgr_priv_data
OMAPDSS: APPLY: add busy field to mgr_priv_data
OMAPDSS: APPLY: rewrite overlay enable/disable
OMAPDSS: APPLY: rewrite register writing
OMAPDSS: DISPC: add dispc_mgr_get_framedone_irq
OMAPDSS: APPLY: add updating flag
OMAPDSS: APPLY: clean up isr_handler
OMAPDSS: APPLY: move mgr->info to apply.c
OMAPDSS: APPLY: move ovl->info to apply.c
OMAPDSS: APPLY: move channel-field to extra_info set
OMAPDSS: APPLY: move fifo thresholds to extra_info set
OMAPDSS: APPLY: rename dirty & shadow_dirty
OMAPDSS: APPLY: remove device_changed field
OMAPDSS: APPLY: add dss_apply_ovl_enable()
OMAPDSS: APPLY: skip enable/disable if already enabled/disabled
OMAPDSS: APPLY: add wait_pending_extra_info_updates()
OMAPDSS: APPLY: remove runtime_get
OMAPDSS: Add comments about blocking of ovl/mgr functions
OMAPDSS: APPLY: add dss_ovl_simple_check()
OMAPDSS: APPLY: add dss_mgr_simple_check()
OMAPDSS: APPLY: add checking of ovls/mgrs settings
OMAPDSS: APPLY: add return value to dss_mgr_enable()
OMAPDSS: check the return value of dss_mgr_enable()
OMAPDSS: APPLY: fix extra_info_update_ongoing
OMAPDSS: APPLY: fix need_isr
OMAPDSS: APPLY: clear shadow dirty flags only if GO had been set
OMAPDSS: APPLY: add dss_set_go_bits()
OMAPDSS: APPLY: cleanup extra_info_update_ongoing
OMAPDSS: APPLY: add op->enabling
OMAPDSS: APPLY: simplify dss_mgr_enable
OMAPDSS: APPLY: add dss_setup_fifos
OMAPDSS: APPLY: write fifo thresholds only if changed
OMAPDSS: APPLY: remove unused variables
OMAPDSS: APPLY: move check functions
OMAPDSS: APPLY: move simple_check functions
arch/arm/mach-omap2/board-4430sdp.c | 23 +-
arch/arm/mach-omap2/board-omap4panda.c | 25 +-
arch/arm/mach-omap2/display.c | 39 +
drivers/media/video/omap/omap_vout.c | 33 +-
drivers/video/omap/lcd_ams_delta.c | 15 +-
drivers/video/omap/lcd_h3.c | 16 +-
drivers/video/omap/lcd_htcherald.c | 16 +-
drivers/video/omap/lcd_inn1510.c | 16 +-
drivers/video/omap/lcd_inn1610.c | 16 +-
drivers/video/omap/lcd_osk.c | 16 +-
drivers/video/omap/lcd_palmte.c | 16 +-
drivers/video/omap/lcd_palmtt.c | 15 +-
drivers/video/omap/lcd_palmz71.c | 15 +-
drivers/video/omap2/displays/Kconfig | 2 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 66 +
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 61 +-
drivers/video/omap2/displays/panel-taal.c | 38 +-
drivers/video/omap2/dss/Makefile | 3 +-
drivers/video/omap2/dss/apply.c | 1324 ++++++++++++++++++++
drivers/video/omap2/dss/core.c | 2 +
drivers/video/omap2/dss/dispc.c | 407 +++----
drivers/video/omap2/dss/dispc.h | 11 +
drivers/video/omap2/dss/dispc_coefs.c | 326 +++++
drivers/video/omap2/dss/dpi.c | 7 +-
drivers/video/omap2/dss/dsi.c | 612 +++++-----
drivers/video/omap2/dss/dss.h | 74 +-
drivers/video/omap2/dss/dss_features.c | 11 +
drivers/video/omap2/dss/dss_features.h | 1 +
drivers/video/omap2/dss/hdmi.c | 59 +-
drivers/video/omap2/dss/manager.c | 1221 ++----------------
drivers/video/omap2/dss/overlay.c | 435 +++-----
drivers/video/omap2/dss/rfbi.c | 1 -
drivers/video/omap2/dss/sdi.c | 8 +-
drivers/video/omap2/dss/ti_hdmi.h | 10 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 37 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 3 -
drivers/video/omap2/dss/venc.c | 28 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 42 +-
drivers/video/omap2/omapfb/omapfb-main.c | 14 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 4 +-
drivers/video/omap2/omapfb/omapfb.h | 11 +-
include/video/omapdss.h | 58 +-
42 files changed, 2883 insertions(+), 2254 deletions(-)
create mode 100644 drivers/video/omap2/dss/apply.c
create mode 100644 drivers/video/omap2/dss/dispc_coefs.c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-05 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318517570-28459-1-git-send-email-jacmet@sunsite.dk>
>>>>> "Peter" = Peter Korsgaard <jacmet@sunsite.dk> writes:
Peter> Allow framebuffer to be configured in 16bit mode when panel is
Peter> wired in (the default) BGR configuration, and don't claim to
Peter> support 15bit input modes, which the LCD controller cannot
Peter> handle.
Ping? Nicolas, you added it to your at91-lcd branch - But it doesn't seem
to have gone any further.
Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Peter> ---
Peter> drivers/video/atmel_lcdfb.c | 12 +++---------
Peter> 1 files changed, 3 insertions(+), 9 deletions(-)
Peter> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
Peter> index 7ca3eaf..143f6d9 100644
Peter> --- a/drivers/video/atmel_lcdfb.c
Peter> +++ b/drivers/video/atmel_lcdfb.c
Peter> @@ -418,24 +418,18 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
var-> red.length = var->green.length = var->blue.length
Peter> = var->bits_per_pixel;
Peter> break;
Peter> - case 15:
Peter> case 16:
Peter> if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
Peter> /* RGB:565 mode */
var-> red.offset = 11;
var-> blue.offset = 0;
Peter> - var->green.length = 6;
Peter> - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
Peter> - var->red.offset = 10;
Peter> - var->blue.offset = 0;
Peter> - var->green.length = 5;
Peter> } else {
Peter> - /* BGR:555 mode */
Peter> + /* BGR:565 mode */
var-> red.offset = 0;
Peter> - var->blue.offset = 10;
Peter> - var->green.length = 5;
Peter> + var->blue.offset = 11;
Peter> }
var-> green.offset = 5;
Peter> + var->green.length = 6;
var-> red.length = var->blue.length = 5;
Peter> break;
Peter> case 32:
Peter> --
Peter> 1.7.6.3
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/5] drivers/video: fsl-diu-fb: merge init_fbinfo() into
From: Florian Tobias Schandinat @ 2012-01-09 2:33 UTC (permalink / raw)
To: linux-fbdev
On 12/19/2011 10:26 PM, Timur Tabi wrote:
> Function init_fbinfo() is called only from install_fb(), and it's only a few
> lines long. Plus, it ignores the return code from fb_alloc_cmap(). Merge
> its contents into install_fb() and handle errors properly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied all 5 patches of this series.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/fsl-diu-fb.c | 25 ++++++++-----------------
> 1 files changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index 408272c..411a7b3 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1220,21 +1220,6 @@ static struct fb_ops fsl_diu_ops = {
> .fb_release = fsl_diu_release,
> };
>
> -static int init_fbinfo(struct fb_info *info)
> -{
> - struct mfb_info *mfbi = info->par;
> -
> - info->device = NULL;
> - info->var.activate = FB_ACTIVATE_NOW;
> - info->fbops = &fsl_diu_ops;
> - info->flags = FBINFO_FLAG_DEFAULT;
> - info->pseudo_palette = &mfbi->pseudo_palette;
> -
> - /* Allocate colormap */
> - fb_alloc_cmap(&info->cmap, 16, 0);
> - return 0;
> -}
> -
> static int __devinit install_fb(struct fb_info *info)
> {
> int rc;
> @@ -1244,8 +1229,14 @@ static int __devinit install_fb(struct fb_info *info)
> unsigned int dbsize = ARRAY_SIZE(fsl_diu_mode_db);
> int has_default_mode = 1;
>
> - if (init_fbinfo(info))
> - return -EINVAL;
> + info->var.activate = FB_ACTIVATE_NOW;
> + info->fbops = &fsl_diu_ops;
> + info->flags = FBINFO_DEFAULT;
> + info->pseudo_palette = mfbi->pseudo_palette;
> +
> + rc = fb_alloc_cmap(&info->cmap, 16, 0);
> + if (rc)
> + return rc;
>
> if (mfbi->index = PLANE0) {
> if (mfbi->edid_data) {
^ permalink raw reply
* Re: [PATCH 0/6] video: s3c-fb: Use runtime suspend while blanked
From: Florian Tobias Schandinat @ 2012-01-09 2:35 UTC (permalink / raw)
To: Mark Brown; +Cc: Jingoo Han, linux-kernel, linux-fbdev
In-Reply-To: <20111227141550.GA3331@opensource.wolfsonmicro.com>
On 12/27/2011 02:15 PM, Mark Brown wrote:
> This patch series (the first two of which I posted the other day)
> improves the runtime power management in the s3c-fb driver by moving it
> to keeping the device runtime suspended when the screen is powered down
> by userspace. This saves a trivial amount of power in the framebuffer
> controller and allows the SoC core code to enter system wide idle
> states which offer much more substantial gains.
>
> Currently it's only lightly tested but it certainly seems to the right
> thing for me.
Applied all 6 patches of this series.
Thanks,
Florian Tobias Schandinat
>
> Mark Brown (6):
> video: s3c-fb: Make runtime PM functional again
> video: s3c-fb: Use s3c_fb_enable() to enable the framebuffer
> video: s3c-fb: Disable runtime PM in error paths from probe
> video: s3c-fb: Take a runtime PM reference when unblanked
> video: s3c-fb: Hold runtime PM references when touching registers
> video: s3c-fb: Don't keep device runtime active when open
>
> drivers/video/s3c-fb.c | 127 ++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 92 insertions(+), 35 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH] grvga: fix section mismatch warnings
From: Florian Tobias Schandinat @ 2012-01-09 2:36 UTC (permalink / raw)
To: linux-fbdev
On 12/27/2011 09:57 PM, Sam Ravnborg wrote:
>>From 7368b53b755a66c69b2b5ede30e2effe960ad59a Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Tue, 27 Dec 2011 22:55:49 +0100
> Subject: [PATCH] grvga: fix section mismatch warnings
>
> Fix following section mismatch warnings:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x110): Section mismatch in reference from the function grvga_probe() to the function .init.text:grvga_parse_custom()
> The function __devinit grvga_probe() references
> a function __init grvga_parse_custom().
> If grvga_parse_custom is only used by grvga_probe then
> annotate grvga_parse_custom with a matching annotation.
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x1f8): Section mismatch in reference from the function grvga_probe() to the variable .init.data:grvga_fix
> The function __devinit grvga_probe() references
> a variable __initdata grvga_fix.
> If grvga_fix is only used by grvga_probe then
> annotate grvga_fix with a matching annotation.
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x204): Section mismatch in reference from the function grvga_probe() to the variable .init.data:grvga_fix
> The function __devinit grvga_probe() references
> a variable __initdata grvga_fix.
> If grvga_fix is only used by grvga_probe then
> annotate grvga_fix with a matching annotation.
>
> grvga_fix is used in a function annotated __devinit - so
> match this using a __devinitdata annotation on grvga_fix.
>
> grvga_parse_custom() is used in a function annotated
> __devinit - so match this by annotating grvga_parse_custom()
> with __devinit too.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Kristoffer Glembo <kristoffer@gaisler.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied this patch.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/grvga.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/grvga.c b/drivers/video/grvga.c
> index f37e025..da066c2 100644
> --- a/drivers/video/grvga.c
> +++ b/drivers/video/grvga.c
> @@ -70,7 +70,7 @@ static const struct fb_videomode grvga_modedb[] = {
> }
> };
>
> -static struct fb_fix_screeninfo grvga_fix __initdata = {
> +static struct fb_fix_screeninfo grvga_fix __devinitdata = {
> .id = "AG SVGACTRL",
> .type = FB_TYPE_PACKED_PIXELS,
> .visual = FB_VISUAL_PSEUDOCOLOR,
> @@ -267,7 +267,7 @@ static struct fb_ops grvga_ops = {
> .fb_imageblit = cfb_imageblit
> };
>
> -static int __init grvga_parse_custom(char *options,
> +static int __devinit grvga_parse_custom(char *options,
> struct fb_var_screeninfo *screendata)
> {
> char *this_opt;
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.3
From: Florian Tobias Schandinat @ 2012-01-09 2:40 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1325753792.2045.42.camel@deskari>
Hi Tomi,
On 01/05/2012 08:56 AM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are changes to OMAP display subsystem driver for the merge window.
>
> This merges and works fine with v3.2, and also merges fine with
> linux-next. I haven't been able to test with linux-next as there seems
> to be other brokenness there.
Pulled. I hope the problem with linux-next will be resolved before the final
kernel is released.
Thanks,
Florian Tobias Schandinat
>
> Tomi
>
> The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:
>
> Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)
>
> are available in the git repository at:
> git://gitorious.org/linux-omap-dss2/linux.git for-florian
>
> Archit Taneja (3):
> OMAPDSS: DSI: Fix HSDIV related PLL info in dsi_dump_clocks()
> OMAPDSS: Panel NEC: Set omap_dss_device states correctly
> OMAPDSS: Displays: Make PICODLP driver depend on DPI
>
> Axel Lin (2):
> video: omap: Staticise non-exported symbols
> video: omap: convert drivers/video/omap/* to use module_platform_driver()
>
> Chandrabhanu Mahapatra (2):
> OMAPDSS: DISPC: Update Fir Coefficients
> OMAPDSS: DISPC: Update Scaling Clock Logic
>
> Daniel Mack (1):
> OMAP: DSS2: Support for UMSH-8173MD TFT panel
>
> Ilya Yanok (2):
> OMAPDSS: add FocalTech ETM070003DH6 display support
> OMAPDSS: add OrtusTech COM43H4M10XTC display support
>
> Mythri P K (2):
> OMAPDSS: HDMI: Move duplicate code from boardfile
> OMAPDSS: HDMI: Disable DDC internal pull up
>
> Ricardo Neri (4):
> ASoC: OMAP: HDMI: Introduce driver data for audio codec
> ASoC: OMAP: HDMI: Correct signature of ASoC functions
> OMAPDSS: HDMI: Create function to enable HDMI audio
> ASoC: OMAP: HDMI: Move HDMI codec trigger function to generic HDMI driver
>
> Rob Clark (2):
> OMAPDSS: fix potential NULL pointer ref in OCP_ERR handling path
> OMAPDSS: APPLY: fix NULL pointer deref when mgr is not set
>
> Tomi Valkeinen (90):
> OMAPDSS: DSI: flush posted write when entering ULPS
> OMAPDSS: DSI: flush posted write in send_bta
> OMAPDSS: DISPC: Flush posted writes when enabling outputs
> OMAPDSS: DSI: count with number of lanes
> OMAPDSS: DSI: Parse lane config
> OMAPDSS: DSI: Use new lane config in dsi_set_lane_config
> OMAPDSS: DSI: use lane config in dsi_get_lane_mask
> OMAPDSS: DSI: use lane config in dsi_cio_wait_tx_clk_esc_reset
> OMAPDSS: DSI: use lane config in dsi_cio_enable_lane_override
> OMAPDSS: DSI: remove dsi_get_num_lanes_used
> OMAPDSS: DSI: fix lane handling when entering ULPS
> OMAPDSS: DSI: improve wait_for_bit_change
> OMAPDSS: DSI: disable DDR_CLK_ALWAYS_ON when entering ULPS
> OMAPDSS: DISPC: add missing prototype
> OMAPDSS: Remove old fifomerge hacks
> OMAPDSS: remove L4_EXAMPLE code
> OMAPDSS: DISPC: make dispc_ovl_set_channel_out() public
> OMAPDSS: DISPC: make dispc_ovl_set_fifo_threshold() public
> OMAPDSS: remove partial update from the overlay manager
> OMAPDSS: remove partial update from DSI
> OMAPDSS: remove partial update from panel-taal
> OMAPDSS: pass ovl manager to dss_start_update
> OMAPDSS: DISPC: handle 0 out_width/out_height in ovl_setup()
> OMAPDSS: handle ilace/replication when configuring overlay
> OMAPDSS: separate FIFO threshold setup from ovl_setup
> OMAPDSS: separate overlay channel from ovl_setup
> OMAPDSS: setup manager with dispc_mgr_setup()
> OMAPDSS: DISPC: remove unused functions
> OMAPDSS: remove unneeded dss_ovl_wait_for_go()
> OMAPDSS: add ovl/mgr_manual_update() helpers
> OMAPDSS: split omap_dss_mgr_apply() to smaller funcs
> OMAPDSS: apply affects only one overlay manager
> OMAPDSS: create apply.c
> OMAPDSS: hide manager's enable/disable()
> OMAPDSS: APPLY: track whether a manager is enabled
> OMAPDSS: APPLY: skip isr register and config for manual update displays
> OMAPDSS: APPLY: skip isr register and config for disabled displays
> OMAPDSS: APPLY: cleanup dss_mgr_start_update
> OMAPDSS: store overlays in an array
> OMAPDSS: store managers in an array
> OMAPDSS: store overlays in a list for each manager
> OMAPDSS: APPLY: separate vsync isr register/unregister
> OMAPDSS: DISPC: Add dispc_mgr_get_vsync_irq()
> OMAPDSS: APPLY: use dispc_mgr_get_vsync_irq()
> OMAPDSS: APPLY: configure_* funcs take ovl/manager as args
> OMAPDSS: APPLY: rename overlay_cache_data
> OMAPDSS: APPLY: rename manager_cache_data
> OMAPDSS: APPLY: move spinlock outside the struct
> OMAPDSS: APPLY: rename dss_cache to dss_data
> OMAPDSS: APPLY: move ovl funcs to apply.c
> OMAPDSS: APPLY: move mgr funcs to apply.c
> OMAPDSS: remove ovl/mgr check-code temporarily
> OMAPDSS: APPLY: add mutex
> OMAPDSS: APPLY: add missing uses of spinlock
> OMAPDSS: DSI: call mgr_enable/disable for cmd mode displays
> OMAPDSS: APPLY: move mgr->enabled to mgr_priv_data
> OMAPDSS: APPLY: add busy field to mgr_priv_data
> OMAPDSS: APPLY: rewrite overlay enable/disable
> OMAPDSS: APPLY: rewrite register writing
> OMAPDSS: DISPC: add dispc_mgr_get_framedone_irq
> OMAPDSS: APPLY: add updating flag
> OMAPDSS: APPLY: clean up isr_handler
> OMAPDSS: APPLY: move mgr->info to apply.c
> OMAPDSS: APPLY: move ovl->info to apply.c
> OMAPDSS: APPLY: move channel-field to extra_info set
> OMAPDSS: APPLY: move fifo thresholds to extra_info set
> OMAPDSS: APPLY: rename dirty & shadow_dirty
> OMAPDSS: APPLY: remove device_changed field
> OMAPDSS: APPLY: add dss_apply_ovl_enable()
> OMAPDSS: APPLY: skip enable/disable if already enabled/disabled
> OMAPDSS: APPLY: add wait_pending_extra_info_updates()
> OMAPDSS: APPLY: remove runtime_get
> OMAPDSS: Add comments about blocking of ovl/mgr functions
> OMAPDSS: APPLY: add dss_ovl_simple_check()
> OMAPDSS: APPLY: add dss_mgr_simple_check()
> OMAPDSS: APPLY: add checking of ovls/mgrs settings
> OMAPDSS: APPLY: add return value to dss_mgr_enable()
> OMAPDSS: check the return value of dss_mgr_enable()
> OMAPDSS: APPLY: fix extra_info_update_ongoing
> OMAPDSS: APPLY: fix need_isr
> OMAPDSS: APPLY: clear shadow dirty flags only if GO had been set
> OMAPDSS: APPLY: add dss_set_go_bits()
> OMAPDSS: APPLY: cleanup extra_info_update_ongoing
> OMAPDSS: APPLY: add op->enabling
> OMAPDSS: APPLY: simplify dss_mgr_enable
> OMAPDSS: APPLY: add dss_setup_fifos
> OMAPDSS: APPLY: write fifo thresholds only if changed
> OMAPDSS: APPLY: remove unused variables
> OMAPDSS: APPLY: move check functions
> OMAPDSS: APPLY: move simple_check functions
>
> arch/arm/mach-omap2/board-4430sdp.c | 23 +-
> arch/arm/mach-omap2/board-omap4panda.c | 25 +-
> arch/arm/mach-omap2/display.c | 39 +
> drivers/media/video/omap/omap_vout.c | 33 +-
> drivers/video/omap/lcd_ams_delta.c | 15 +-
> drivers/video/omap/lcd_h3.c | 16 +-
> drivers/video/omap/lcd_htcherald.c | 16 +-
> drivers/video/omap/lcd_inn1510.c | 16 +-
> drivers/video/omap/lcd_inn1610.c | 16 +-
> drivers/video/omap/lcd_osk.c | 16 +-
> drivers/video/omap/lcd_palmte.c | 16 +-
> drivers/video/omap/lcd_palmtt.c | 15 +-
> drivers/video/omap/lcd_palmz71.c | 15 +-
> drivers/video/omap2/displays/Kconfig | 2 +-
> drivers/video/omap2/displays/panel-generic-dpi.c | 66 +
> .../omap2/displays/panel-nec-nl8048hl11-01b.c | 61 +-
> drivers/video/omap2/displays/panel-taal.c | 38 +-
> drivers/video/omap2/dss/Makefile | 3 +-
> drivers/video/omap2/dss/apply.c | 1324 ++++++++++++++++++++
> drivers/video/omap2/dss/core.c | 2 +
> drivers/video/omap2/dss/dispc.c | 407 +++----
> drivers/video/omap2/dss/dispc.h | 11 +
> drivers/video/omap2/dss/dispc_coefs.c | 326 +++++
> drivers/video/omap2/dss/dpi.c | 7 +-
> drivers/video/omap2/dss/dsi.c | 612 +++++-----
> drivers/video/omap2/dss/dss.h | 74 +-
> drivers/video/omap2/dss/dss_features.c | 11 +
> drivers/video/omap2/dss/dss_features.h | 1 +
> drivers/video/omap2/dss/hdmi.c | 59 +-
> drivers/video/omap2/dss/manager.c | 1221 ++----------------
> drivers/video/omap2/dss/overlay.c | 435 +++-----
> drivers/video/omap2/dss/rfbi.c | 1 -
> drivers/video/omap2/dss/sdi.c | 8 +-
> drivers/video/omap2/dss/ti_hdmi.h | 10 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 37 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 3 -
> drivers/video/omap2/dss/venc.c | 28 +-
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 42 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 14 +-
> drivers/video/omap2/omapfb/omapfb-sysfs.c | 4 +-
> drivers/video/omap2/omapfb/omapfb.h | 11 +-
> include/video/omapdss.h | 58 +-
> 42 files changed, 2883 insertions(+), 2254 deletions(-)
> create mode 100644 drivers/video/omap2/dss/apply.c
> create mode 100644 drivers/video/omap2/dss/dispc_coefs.c
>
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported
From: Florian Tobias Schandinat @ 2012-01-09 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zke29yqj.fsf@macbook.be.48ers.dk>
Hi Peter,
On 01/05/2012 11:26 AM, Peter Korsgaard wrote:
>>>>>> "Peter" = Peter Korsgaard <jacmet@sunsite.dk> writes:
>
> Peter> Allow framebuffer to be configured in 16bit mode when panel is
> Peter> wired in (the default) BGR configuration, and don't claim to
> Peter> support 15bit input modes, which the LCD controller cannot
> Peter> handle.
>
> Ping? Nicolas, you added it to your at91-lcd branch - But it doesn't seem
> to have gone any further.
I could also take care of this patch but I'd prefer if it gets an Acked-by of
someone at Atmel (or someone else who knows the hardware) as I cannot really
tell whether it is correct.
Best regards,
Florian Tobias Schandinat
>
> Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> Peter> ---
> Peter> drivers/video/atmel_lcdfb.c | 12 +++---------
> Peter> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> Peter> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> Peter> index 7ca3eaf..143f6d9 100644
> Peter> --- a/drivers/video/atmel_lcdfb.c
> Peter> +++ b/drivers/video/atmel_lcdfb.c
> Peter> @@ -418,24 +418,18 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> var-> red.length = var->green.length = var->blue.length
> Peter> = var->bits_per_pixel;
> Peter> break;
> Peter> - case 15:
> Peter> case 16:
> Peter> if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
> Peter> /* RGB:565 mode */
> var-> red.offset = 11;
> var-> blue.offset = 0;
> Peter> - var->green.length = 6;
> Peter> - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
> Peter> - var->red.offset = 10;
> Peter> - var->blue.offset = 0;
> Peter> - var->green.length = 5;
> Peter> } else {
> Peter> - /* BGR:555 mode */
> Peter> + /* BGR:565 mode */
> var-> red.offset = 0;
> Peter> - var->blue.offset = 10;
> Peter> - var->green.length = 5;
> Peter> + var->blue.offset = 11;
> Peter> }
> var-> green.offset = 5;
> Peter> + var->green.length = 6;
> var-> red.length = var->blue.length = 5;
> Peter> break;
> Peter> case 32:
> Peter> --
> Peter> 1.7.6.3
>
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-09 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F0A55D7.50707@gmx.de>
>>>>> "Florian" = Florian Tobias Schandinat <FlorianSchandinat@gmx.de> writes:
Hi,
Peter> Allow framebuffer to be configured in 16bit mode when panel is
Peter> wired in (the default) BGR configuration, and don't claim to
Peter> support 15bit input modes, which the LCD controller cannot
Peter> handle.
>>
>> Ping? Nicolas, you added it to your at91-lcd branch - But it doesn't seem
>> to have gone any further.
Florian> I could also take care of this patch but I'd prefer if it gets
Florian> an Acked-by of someone at Atmel (or someone else who knows the
Florian> hardware) as I cannot really tell whether it is correct.
I understand. Nicolas, presumably you're ok with it as you added it to
your tree?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported
From: Nicolas Ferre @ 2012-01-09 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318517570-28459-1-git-send-email-jacmet@sunsite.dk>
On 10/13/2011 04:52 PM, Peter Korsgaard :
> Allow framebuffer to be configured in 16bit mode when panel is wired in
> (the default) BGR configuration, and don't claim to support 15bit input
> modes, which the LCD controller cannot handle.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Hi Peter,
Sorry for not having more responsive concerning the two patches that you
posted about atmel_lcdfb driver.
I have a question though about this one...
> ---
> drivers/video/atmel_lcdfb.c | 12 +++---------
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 7ca3eaf..143f6d9 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -418,24 +418,18 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> var->red.length = var->green.length = var->blue.length
> = var->bits_per_pixel;
> break;
> - case 15:
> case 16:
> if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
> /* RGB:565 mode */
> var->red.offset = 11;
> var->blue.offset = 0;
> - var->green.length = 6;
> - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
> - var->red.offset = 10;
> - var->blue.offset = 0;
> - var->green.length = 5;
Maybe I have missed something but I do not know why you are removing
this part of the configuration? A board at least is using this wiring
mode...
> } else {
> - /* BGR:555 mode */
> + /* BGR:565 mode */
> var->red.offset = 0;
> - var->blue.offset = 10;
> - var->green.length = 5;
> + var->blue.offset = 11;
> }
> var->green.offset = 5;
> + var->green.length = 6;
> var->red.length = var->blue.length = 5;
> break;
Maybe we can separate both 15 and 16 cases but I do not know if we can
remove completely the 15 RGB555 mode...
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-09 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F0AC2B1.8010601@atmel.com>
>>>>> "Nicolas" = Nicolas Ferre <nicolas.ferre@atmel.com> writes:
Nicolas> On 10/13/2011 04:52 PM, Peter Korsgaard :
>> Allow framebuffer to be configured in 16bit mode when panel is wired in
>> (the default) BGR configuration, and don't claim to support 15bit input
>> modes, which the LCD controller cannot handle.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Nicolas> Hi Peter,
Nicolas> Sorry for not having more responsive concerning the two
Nicolas> patches that you posted about atmel_lcdfb driver.
No problem.
Nicolas> I have a question though about this one...
>> - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
>> - var->red.offset = 10;
>> - var->blue.offset = 0;
>> - var->green.length = 5;
Nicolas> Maybe I have missed something but I do not know why you are removing
Nicolas> this part of the configuration? A board at least is using this wiring
Nicolas> mode...
Because it is arguable wrong as far as I understand the HW.
There's two parts here:
- 1: Format of framebuffer memory
- 2: Wiring of LCD (RGB/BGR order and number of bits)
From the datasheet, the following framebuffer formats are supported:
1, 2, 4, 8 bits per pixel (palletized), 16, 24 bits per pixel
(non-palletized) for TFT.
So it doesn't really support RGB555 mode. The controller reads up to
32bit of framebuffer data and outputs 24bit on the LCD pins. You CAN
wire up a RGB555 panel by just skipping the LSB green of a RGB565
wiring, but that is independent of the framebufffer format. The
controller/driver doesn't do any RGB/BGR swapping, so the RBG/BGR wiring
settings are just used as a software hint (in FBIOGET_VSCREENINFO) about
the meaning of the individual bits of a pixel in the framebuffer.
Similar you can connect a 12bit 4:4:4 panel by just connecting it to the
MSB LCD pins.
So in conclusion, I think we should just have:
- ATMEL_LCDC_WIRING_RGB
- ATMEL_LCDC_WIRING_BGR
- ATMEL_LCDC_WIRING_RGB565
- ATMEL_LCDC_WIRING_BGR565
These simply define framebuffer bit order (RGB/BGR) and preferred
default bit depth (16/24).
I hope this makes it more clear.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove
From: Russell King - ARM Linux @ 2012-01-09 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F0AC2B1.8010601@atmel.com>
On Mon, Jan 09, 2012 at 11:34:25AM +0100, Nicolas Ferre wrote:
> On 10/13/2011 04:52 PM, Peter Korsgaard :
> > Allow framebuffer to be configured in 16bit mode when panel is wired in
> > (the default) BGR configuration, and don't claim to support 15bit input
> > modes, which the LCD controller cannot handle.
> >
> > Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Hi Peter,
>
> Sorry for not having more responsive concerning the two patches that you
> posted about atmel_lcdfb driver.
>
>
> I have a question though about this one...
>
>
> > ---
> > drivers/video/atmel_lcdfb.c | 12 +++---------
> > 1 files changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> > index 7ca3eaf..143f6d9 100644
> > --- a/drivers/video/atmel_lcdfb.c
> > +++ b/drivers/video/atmel_lcdfb.c
> > @@ -418,24 +418,18 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> > var->red.length = var->green.length = var->blue.length
> > = var->bits_per_pixel;
> > break;
> > - case 15:
> > case 16:
> > if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
> > /* RGB:565 mode */
> > var->red.offset = 11;
> > var->blue.offset = 0;
> > - var->green.length = 6;
> > - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
> > - var->red.offset = 10;
> > - var->blue.offset = 0;
> > - var->green.length = 5;
>
> Maybe I have missed something but I do not know why you are removing
> this part of the configuration? A board at least is using this wiring
> mode...
Oh, this old gem.
var->bits_per_pixel represents the number of bits in the framebuffer per
pixel, and '15' for this means that your frame buffer is organized as:
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
----+-----------------------------+-----------------------------+
A | B | C |
----+-----------------------------+-----------------------------+
whereas what you actually have is:
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-------------------------------+-------------------------------+
| B | C |
+-------------------------------+-------------------------------+
and one bit in each pixel remains unused.
This is because bytes_per_line = xres * 8 / bits_per_pixel.
You describe the RGB555 vs RGB565 via the bitfield values in var->red,
var->green and var->blue. So, RGB(or BGR)565 has var->green.length
with 6, and RGB(or BGR)555 has this as 5. In both cases, bits_per_pixel
is 16 as that's the width of a pixel in the frame buffer.
If the bitfield can't be interpreted by the driver as identifying one
of these combinations, then you're supposed to chose one (and in the
case where it's fixed by hardware, you set the bitfields according to
what the hardware supports.)
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-09 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120109121322.GM21765@n2100.arm.linux.org.uk>
>>>>> "Russell" = Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:
Hi,
Russell> You describe the RGB555 vs RGB565 via the bitfield values in
Russell> var->red, var-> green and var->blue. So, RGB(or BGR)565 has
Russell> var->green.length with 6, and RGB(or BGR)555 has this as 5.
Russell> In both cases, bits_per_pixel is 16 as that's the width of a
Russell> pixel in the frame buffer.
Russell> If the bitfield can't be interpreted by the driver as
Russell> identifying one of these combinations, then you're supposed to
Russell> chose one (and in the case where it's fixed by hardware, you
Russell> set the bitfields according to what the hardware supports.)
Indeed, and as the hardware can only interprete 1/2/4/8 paletted and
16/24 RGB, we shouldn't claim to support 15bit.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported
From: Nicolas Ferre @ 2012-01-09 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ty45dt89.fsf@macbook.be.48ers.dk>
On 01/09/2012 12:13 PM, Peter Korsgaard :
>>>>>> "Nicolas" = Nicolas Ferre <nicolas.ferre@atmel.com> writes:
>
> Nicolas> On 10/13/2011 04:52 PM, Peter Korsgaard :
> >> Allow framebuffer to be configured in 16bit mode when panel is wired in
> >> (the default) BGR configuration, and don't claim to support 15bit input
> >> modes, which the LCD controller cannot handle.
> >>
> >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Nicolas> Hi Peter,
>
> Nicolas> Sorry for not having more responsive concerning the two
> Nicolas> patches that you posted about atmel_lcdfb driver.
>
> No problem.
>
> Nicolas> I have a question though about this one...
>
> >> - } else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
> >> - var->red.offset = 10;
> >> - var->blue.offset = 0;
> >> - var->green.length = 5;
>
> Nicolas> Maybe I have missed something but I do not know why you are removing
> Nicolas> this part of the configuration? A board at least is using this wiring
> Nicolas> mode...
>
> Because it is arguable wrong as far as I understand the HW.
> There's two parts here:
>
> - 1: Format of framebuffer memory
> - 2: Wiring of LCD (RGB/BGR order and number of bits)
>
>>From the datasheet, the following framebuffer formats are supported:
>
> 1, 2, 4, 8 bits per pixel (palletized), 16, 24 bits per pixel
> (non-palletized) for TFT.
>
> So it doesn't really support RGB555 mode. The controller reads up to
> 32bit of framebuffer data and outputs 24bit on the LCD pins. You CAN
> wire up a RGB555 panel by just skipping the LSB green of a RGB565
> wiring, but that is independent of the framebufffer format. The
> controller/driver doesn't do any RGB/BGR swapping, so the RBG/BGR wiring
> settings are just used as a software hint (in FBIOGET_VSCREENINFO) about
> the meaning of the individual bits of a pixel in the framebuffer.
>
> Similar you can connect a 12bit 4:4:4 panel by just connecting it to the
> MSB LCD pins.
Yes. Thanks to Russell and you for the explanation.
I acknowledge your two patches right now.
> So in conclusion, I think we should just have:
>
> - ATMEL_LCDC_WIRING_RGB
> - ATMEL_LCDC_WIRING_BGR
> - ATMEL_LCDC_WIRING_RGB565
> - ATMEL_LCDC_WIRING_BGR565
>
> These simply define framebuffer bit order (RGB/BGR) and preferred
> default bit depth (16/24).
Maybe we can think about a patch that removes the RGB555 variable from
the header (include/video/atmel_lcdc.h) and the board file that is using
it (board-neocore926.c).
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCHv2] atmel_lcdfb: support new-style palette format
From: Nicolas Ferre @ 2012-01-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EBDBAF9.3090805@gmx.de>
On 11/12/2011 01:16 AM, Florian Tobias Schandinat :
> On 10/13/2011 02:45 PM, Peter Korsgaard wrote:
>> The newer Atmel SoCs use normal 16bit 565 BGR/RGB for the palette data,
>> rather than the special intensity + 555 format.
>>
>> Fill out palette data correctly on these devices, and at the same time
>> respect the RGB/BGR wiring mode.
>
> Applied this patch.
>
>
> Thanks,
>
> Florian Tobias Schandinat
Florian, here is my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Can you please send it upstream through your tree?
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>> ---
>> Changes since v1:
>> - ATMEL_LCDC_WIRING_RGB/BGR was swapped
>>
>> drivers/video/atmel_lcdfb.c | 32 ++++++++++++++++++++++++--------
>> 1 files changed, 24 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 63409c1..7ca3eaf 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -682,14 +682,30 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
>>
>> case FB_VISUAL_PSEUDOCOLOR:
>> if (regno < 256) {
>> - val = ((red >> 11) & 0x001f);
>> - val |= ((green >> 6) & 0x03e0);
>> - val |= ((blue >> 1) & 0x7c00);
>> -
>> - /*
>> - * TODO: intensity bit. Maybe something like
>> - * ~(red[10] ^ green[10] ^ blue[10]) & 1
>> - */
>> + if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
>> + || cpu_is_at91sam9rl()) {
>> + /* old style I+BGR:555 */
>> + val = ((red >> 11) & 0x001f);
>> + val |= ((green >> 6) & 0x03e0);
>> + val |= ((blue >> 1) & 0x7c00);
>> +
>> + /*
>> + * TODO: intensity bit. Maybe something like
>> + * ~(red[10] ^ green[10] ^ blue[10]) & 1
>> + */
>> + } else {
>> + /* new style BGR:565 / RGB:565 */
>> + if (sinfo->lcd_wiring_mode =
>> + ATMEL_LCDC_WIRING_RGB) {
>> + val = ((blue >> 11) & 0x001f);
>> + val |= ((red >> 0) & 0xf800);
>> + } else {
>> + val = ((red >> 11) & 0x001f);
>> + val |= ((blue >> 0) & 0xf800);
>> + }
>> +
>> + val |= ((green >> 5) & 0x07e0);
>> + }
>>
>> lcdc_writel(sinfo, ATMEL_LCDC_LUT(regno), val);
>> ret = 0;
>
>
--
Nicolas Ferre
^ 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