* [PATCH 1/6] OMAPDSS: FEAT: Add FIFO_MERGE feature
From: Tomi Valkeinen @ 2012-01-13 11:46 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: archit, rob, Tomi Valkeinen
In-Reply-To: <1326455193-19716-1-git-send-email-tomi.valkeinen@ti.com>
Add feature flag for fifo merge. OMAP2 doesn't contain fifo merge, later
OMAPs do.
dispc_enable_fifomerge() checks for the flag when called, and gives a
WARN if fifo merge is being enabled when it is not supported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 5 +++++
drivers/video/omap2/dss/dss_features.c | 9 +++++----
drivers/video/omap2/dss/dss_features.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a5ec7f3..d711518 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1054,6 +1054,11 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
void dispc_enable_fifomerge(bool enable)
{
+ if (!dss_has_feature(FEAT_FIFO_MERGE)) {
+ WARN_ON(enable);
+ return;
+ }
+
DSSDBG("FIFO merge %s\n", enable ? "enabled" : "disabled");
REG_FLD_MOD(DISPC_CONFIG, enable ? 1 : 0, 14, 14);
}
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index afcb593..c2456c5 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -370,7 +370,7 @@ static const struct omap_dss_features omap3430_dss_features = {
FEAT_LINEBUFFERSPLIT | FEAT_RESIZECONF |
FEAT_DSI_PLL_FREQSEL | FEAT_DSI_REVERSE_TXCLKESC |
FEAT_VENC_REQUIRES_TV_DAC_CLK | FEAT_CPR | FEAT_PRELOAD |
- FEAT_FIR_COEF_V | FEAT_ALPHA_FIXED_ZORDER,
+ FEAT_FIR_COEF_V | FEAT_ALPHA_FIXED_ZORDER | FEAT_FIFO_MERGE,
.num_mgrs = 2,
.num_ovls = 3,
@@ -394,7 +394,7 @@ static const struct omap_dss_features omap3630_dss_features = {
FEAT_ROWREPEATENABLE | FEAT_LINEBUFFERSPLIT |
FEAT_RESIZECONF | FEAT_DSI_PLL_PWR_BUG |
FEAT_DSI_PLL_FREQSEL | FEAT_CPR | FEAT_PRELOAD |
- FEAT_FIR_COEF_V | FEAT_ALPHA_FIXED_ZORDER,
+ FEAT_FIR_COEF_V | FEAT_ALPHA_FIXED_ZORDER | FEAT_FIFO_MERGE,
.num_mgrs = 2,
.num_ovls = 3,
@@ -419,7 +419,7 @@ static const struct omap_dss_features omap4430_es1_0_dss_features = {
FEAT_DSI_DCS_CMD_CONFIG_VC | FEAT_DSI_VC_OCP_WIDTH |
FEAT_DSI_GNQ | FEAT_HANDLE_UV_SEPARATE | FEAT_ATTR2 |
FEAT_CPR | FEAT_PRELOAD | FEAT_FIR_COEF_V |
- FEAT_ALPHA_FREE_ZORDER,
+ FEAT_ALPHA_FREE_ZORDER | FEAT_FIFO_MERGE,
.num_mgrs = 3,
.num_ovls = 4,
@@ -443,7 +443,8 @@ static const struct omap_dss_features omap4_dss_features = {
FEAT_DSI_DCS_CMD_CONFIG_VC | FEAT_DSI_VC_OCP_WIDTH |
FEAT_DSI_GNQ | FEAT_HDMI_CTS_SWMODE |
FEAT_HANDLE_UV_SEPARATE | FEAT_ATTR2 | FEAT_CPR |
- FEAT_PRELOAD | FEAT_FIR_COEF_V | FEAT_ALPHA_FREE_ZORDER,
+ FEAT_PRELOAD | FEAT_FIR_COEF_V | FEAT_ALPHA_FREE_ZORDER |
+ FEAT_FIFO_MERGE,
.num_mgrs = 3,
.num_ovls = 4,
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index cd833bb..50caee9 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -58,6 +58,7 @@ enum dss_feat_id {
FEAT_FIR_COEF_V = 1 << 25,
FEAT_ALPHA_FIXED_ZORDER = 1 << 26,
FEAT_ALPHA_FREE_ZORDER = 1 << 27,
+ FEAT_FIFO_MERGE = 1 << 28,
};
/* DSS register field id */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/6] OMAPDSS: naive fifomerge support
From: Tomi Valkeinen @ 2012-01-13 11:46 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: archit, rob, Tomi Valkeinen
This patch set implements fifomerge and a naive version for fifo threshold
calculation when fifomerge is in use. The strategy is simple: keep the low
threshold the same for both fifomerge and non-fifomerge cases, but calculate
the high threshold using the combined fifo size when fifomerge is in use.
This should give some power savings, as the usable fifo size is much larger
when only one overlay is in use. It probably won't help fifo underflow cases,
as the low threshold is kept the same.
Tested on OMAP4 Blaze (DSI cmd mode) and OMAP3 Overo (DPI).
Tomi
Tomi Valkeinen (6):
OMAPDSS: FEAT: Add FIFO_MERGE feature
OMAPDSS: APPLY: add fifo merge support funcs
OMAPDSS: APPLY: add fifo-merge support
OMAPDSS: DISPC: print fifo threshold values in bytes
OMAPDSS: DISPC: move fifo threhold calc to dispc.c
OMAPDSS: DISPC: Add naive threshold calc for fifomerge
drivers/video/omap2/dss/apply.c | 221 +++++++++++++++++++++++++++-----
drivers/video/omap2/dss/dispc.c | 51 +++++++-
drivers/video/omap2/dss/display.c | 10 --
drivers/video/omap2/dss/dsi.c | 8 -
drivers/video/omap2/dss/dss.h | 10 +-
drivers/video/omap2/dss/dss_features.c | 9 +-
drivers/video/omap2/dss/dss_features.h | 1 +
7 files changed, 244 insertions(+), 66 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH 3/15] i810: fix module_param bool abuse.
From: Florian Tobias Schandinat @ 2012-01-12 23:36 UTC (permalink / raw)
To: Rusty Russell
Cc: lkml - Kernel Mailing List, Antonino Daplas, linux-fbdev,
Pawel Moll
In-Reply-To: <87sjjk34wx.fsf@rustcorp.com.au>
Hi Rusty,
On 01/12/2012 10:57 PM, Rusty Russell wrote:
> On Mon, 19 Dec 2011 23:16:04 +0000, Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>> On 12/15/2011 03:03 AM, Rusty Russell wrote:
>>> The driver says "module_param(ddc3, bool, 0);". But it's not a used
>>> as a bool, it's used as a count.
>>>
>>> Make it a bool.
>>>
>>> Cc: Antonino Daplas <adaplas@gmail.com>
>>> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>>> Cc: linux-fbdev@vger.kernel.org
>>> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>>
>> Applied.
>
> Hmm, I don't see this in Linus' tree yet, and it's a context-clash
> pre-requisite for part of the general driver bool conversion. I want to
> push today since I have linux.conf.au next week, so I've split the i810
> conversion into a separate patch, below.
Sorry for the delay, but with an OMAP pull and a revert this merge window is not
as quiet as I wished.
> It's been over a week in linux-next, can you push this please?
Sure, I've taken it and also fixed the subject.
Best regards,
Florian Tobias Schandinat
>
> From: Rusty Russell <rusty@rustcorp.com.au>
> Subject: module_param: make bool parameters really bool (drivers/vidio/i810)
>
> module_param(bool) used to counter-intuitively take an int. In
> fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
> trick.
>
> It's time to remove the int/unsigned int option. For this version
> it'll simply give a warning, but it'll break next kernel version.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
> --- a/drivers/video/i810/i810_main.c
> +++ b/drivers/video/i810/i810_main.c
> @@ -135,8 +135,8 @@ static struct pci_driver i810fb_driver > static char *mode_option __devinitdata = NULL;
> static int vram __devinitdata = 4;
> static int bpp __devinitdata = 8;
> -static int mtrr __devinitdata;
> -static int accel __devinitdata;
> +static bool mtrr __devinitdata;
> +static bool accel __devinitdata;
> static int hsync1 __devinitdata;
> static int hsync2 __devinitdata;
> static int vsync1 __devinitdata;
> @@ -144,9 +144,9 @@ static int vsync2 __devinitdata;
> static int xres __devinitdata;
> static int yres;
> static int vyres __devinitdata;
> -static int sync __devinitdata;
> -static int extvga __devinitdata;
> -static int dcolor __devinitdata;
> +static bool sync __devinitdata;
> +static bool extvga __devinitdata;
> +static bool dcolor __devinitdata;
> static bool ddc3 __devinitdata;
>
> /*------------------------------------------------------------*/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 3/15] i810: fix module_param bool abuse.
From: Rusty Russell @ 2012-01-12 23:09 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: lkml - Kernel Mailing List, Antonino Daplas, linux-fbdev,
Pawel Moll
In-Reply-To: <4EEFC5B4.9000704@gmx.de>
On Mon, 19 Dec 2011 23:16:04 +0000, Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> On 12/15/2011 03:03 AM, Rusty Russell wrote:
> > The driver says "module_param(ddc3, bool, 0);". But it's not a used
> > as a bool, it's used as a count.
> >
> > Make it a bool.
> >
> > Cc: Antonino Daplas <adaplas@gmail.com>
> > Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> Applied.
Hmm, I don't see this in Linus' tree yet, and it's a context-clash
pre-requisite for part of the general driver bool conversion. I want to
push today since I have linux.conf.au next week, so I've split the i810
conversion into a separate patch, below.
It's been over a week in linux-next, can you push this please?
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: module_param: make bool parameters really bool (drivers/vidio/i810)
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
--- a/drivers/video/i810/i810_main.c
+++ b/drivers/video/i810/i810_main.c
@@ -135,8 +135,8 @@ static struct pci_driver i810fb_driver static char *mode_option __devinitdata = NULL;
static int vram __devinitdata = 4;
static int bpp __devinitdata = 8;
-static int mtrr __devinitdata;
-static int accel __devinitdata;
+static bool mtrr __devinitdata;
+static bool accel __devinitdata;
static int hsync1 __devinitdata;
static int hsync2 __devinitdata;
static int vsync1 __devinitdata;
@@ -144,9 +144,9 @@ static int vsync2 __devinitdata;
static int xres __devinitdata;
static int yres;
static int vyres __devinitdata;
-static int sync __devinitdata;
-static int extvga __devinitdata;
-static int dcolor __devinitdata;
+static bool sync __devinitdata;
+static bool extvga __devinitdata;
+static bool dcolor __devinitdata;
static bool ddc3 __devinitdata;
/*------------------------------------------------------------*/
^ permalink raw reply
* Re: [PATCH 1/2] atmel_lcdfb: Adjust HFP calculation so it matches the manual.
From: Florian Tobias Schandinat @ 2012-01-11 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F0AF7F8.8040300@atmel.com>
Hi Nicolas, Alexander,
On 01/09/2012 02:21 PM, Nicolas Ferre wrote:
> On 10/05/2011 09:59 AM, Alexander Stein :
>> In the AT91SAM9263 Manual the HFP part in LCDTIM2 is described as follows:
>> * HFP: Horizontal Front Porch
>> Number of idle LCDDOTCK cycles at the end of the line.
>> Idle period is (HFP+2) LCDDOTCK cycles.
>
> Hi Alexander,
>
> Unfortunately this is not true for all the SoC that embed the
> atmel_lcdfb... So I may need to rework this patch but it is certainly
> not applicable in the current form.
>
> Florian, can you please remove it from your git tree?
Done, I reverted this patch for now.
For the other patches, those that are currently in my tree, I will ask Linus to
pull them really soon. For the others I'll take care of them after the merge
window is closed.
Best regards,
Florian Tobias Schandinat
>
> Thanks,
>
> Best regards,
>
>> It is only a minor issue. I also changed all boards using atmel_lcdfb
>> I found to respect the new calculation.
>>
>> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
>> ---
>> arch/arm/mach-at91/board-cap9adk.c | 2 +-
>> arch/arm/mach-at91/board-neocore926.c | 2 +-
>> arch/arm/mach-at91/board-sam9261ek.c | 4 ++-
>> arch/arm/mach-at91/board-sam9263ek.c | 2 +-
>> arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +-
>> arch/arm/mach-at91/board-sam9rlek.c | 2 +-
>> drivers/video/atmel_lcdfb.c | 4 ++--
>> 7 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/board-cap9adk.c b/arch/arm/mach-at91/board-cap9adk.c
>> index 679b0b7..ae962bf 100644
>> --- a/arch/arm/mach-at91/board-cap9adk.c
>> +++ b/arch/arm/mach-at91/board-cap9adk.c
>> @@ -304,7 +304,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 240, .yres = 320,
>> .pixclock = KHZ2PICOS(4965),
>>
>> - .left_margin = 1, .right_margin = 33,
>> + .left_margin = 1, .right_margin = 34,
>> .upper_margin = 1, .lower_margin = 0,
>> .hsync_len = 5, .vsync_len = 1,
>>
>> diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
>> index 9bc6ab3..583878e 100644
>> --- a/arch/arm/mach-at91/board-neocore926.c
>> +++ b/arch/arm/mach-at91/board-neocore926.c
>> @@ -235,7 +235,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 240, .yres = 320,
>> .pixclock = KHZ2PICOS(5000),
>>
>> - .left_margin = 1, .right_margin = 33,
>> + .left_margin = 1, .right_margin = 34,
>> .upper_margin = 1, .lower_margin = 0,
>> .hsync_len = 5, .vsync_len = 1,
>>
>> diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
>> index 5096a0e..8dda83b 100644
>> --- a/arch/arm/mach-at91/board-sam9261ek.c
>> +++ b/arch/arm/mach-at91/board-sam9261ek.c
>> @@ -370,7 +370,7 @@ static struct fb_videomode at91_stn_modes[] = {
>> .xres = 320, .yres = 240,
>> .pixclock = KHZ2PICOS(1440),
>>
>> - .left_margin = 1, .right_margin = 1,
>> + .left_margin = 1, .right_margin = 2,
>> .upper_margin = 0, .lower_margin = 0,
>> .hsync_len = 1, .vsync_len = 1,
>>
>> @@ -431,7 +431,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 240, .yres = 320,
>> .pixclock = KHZ2PICOS(4965),
>>
>> - .left_margin = 1, .right_margin = 33,
>> + .left_margin = 1, .right_margin = 34,
>> .upper_margin = 1, .lower_margin = 0,
>> .hsync_len = 5, .vsync_len = 1,
>>
>> diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
>> index ea8f185..e260070 100644
>> --- a/arch/arm/mach-at91/board-sam9263ek.c
>> +++ b/arch/arm/mach-at91/board-sam9263ek.c
>> @@ -258,7 +258,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 240, .yres = 320,
>> .pixclock = KHZ2PICOS(4965),
>>
>> - .left_margin = 1, .right_margin = 33,
>> + .left_margin = 1, .right_margin = 34,
>> .upper_margin = 1, .lower_margin = 0,
>> .hsync_len = 5, .vsync_len = 1,
>>
>> diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
>> index ad234cc..5e9a5ca 100644
>> --- a/arch/arm/mach-at91/board-sam9m10g45ek.c
>> +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
>> @@ -197,7 +197,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 480, .yres = 272,
>> .pixclock = KHZ2PICOS(9000),
>>
>> - .left_margin = 1, .right_margin = 1,
>> + .left_margin = 1, .right_margin = 2,
>> .upper_margin = 40, .lower_margin = 1,
>> .hsync_len = 45, .vsync_len = 1,
>>
>> diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
>> index 4f14b54..ad9e5c9 100644
>> --- a/arch/arm/mach-at91/board-sam9rlek.c
>> +++ b/arch/arm/mach-at91/board-sam9rlek.c
>> @@ -154,7 +154,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
>> .xres = 240, .yres = 320,
>> .pixclock = KHZ2PICOS(4965),
>>
>> - .left_margin = 1, .right_margin = 33,
>> + .left_margin = 1, .right_margin = 34,
>> .upper_margin = 1, .lower_margin = 0,
>> .hsync_len = 5, .vsync_len = 1,
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 817ab60..816d528 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -393,7 +393,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
>> var->lower_margin = min_t(u32, var->lower_margin,
>> ATMEL_LCDC_VFP);
>> var->right_margin = min_t(u32, var->right_margin,
>> - (ATMEL_LCDC_HFP >> ATMEL_LCDC_HFP_OFFSET) + 1);
>> + (ATMEL_LCDC_HFP >> ATMEL_LCDC_HFP_OFFSET) + 2);
>> var->hsync_len = min_t(u32, var->hsync_len,
>> (ATMEL_LCDC_HPW >> ATMEL_LCDC_HPW_OFFSET) + 1);
>> var->left_margin = min_t(u32, var->left_margin,
>> @@ -578,7 +578,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
>> lcdc_writel(sinfo, ATMEL_LCDC_TIM1, value);
>>
>> /* Horizontal timing */
>> - value = (info->var.right_margin - 1) << ATMEL_LCDC_HFP_OFFSET;
>> + value = (info->var.right_margin - 2) << ATMEL_LCDC_HFP_OFFSET;
>> value |= (info->var.hsync_len - 1) << ATMEL_LCDC_HPW_OFFSET;
>> value |= (info->var.left_margin - 1);
>> dev_dbg(info->device, " * LCDTIM2 = %08lx\n", value);
>
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: Add device tree support
From: Mark Brown @ 2012-01-11 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwRSO9OuiLNddOa+KLSkGwOAp3yHcrQZXSk_k2+oxtEDPQ@mail.gmail.com>
On Wed, Jan 11, 2012 at 04:34:28PM +0530, Thomas Abraham wrote:
> On 10 January 2012 10:22, Mark Brown
> > This isn't terribly informative for the user - which GPIOs and in what
> > order are they specified? Looking at the code it looks like pin mux
> > configuration so just some wording saying it's a list of pins to be used
> > for the framebuffer function.
> Ok. I will modify the sentence to mean that it is list of gpios used
> by framebuffer controller for data/timing interface with the lcd
> panel. Thanks for your review.
You probably want to mention that it's for pin muxing, the reason I
didn't get what it meant on first read was that normally GPIO means
specifically the sort of stuff handled by gpiolib.
^ permalink raw reply
* OMAP DSS2/PM on 3.2 broken?
From: Joe Woodward @ 2012-01-11 13:57 UTC (permalink / raw)
To: linux-fbdev
[origianlly sent to the Linux OMAP mailing list, but forwarded as suggested (see http://marc.info/?l=linux-omap&m\x132611662919592&w=2)]
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected via the DSS2 DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the following:
# echo mem > /sys/power/state
[ 23.186279] PM: Syncing filesystems ... done.
[ 23.194244] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[ 23.219543] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 23.251037] Suspending console(s) (use no_console_suspend to debug)
[ 23.554656] PM: suspend of devices complete after 296.417 msecs
[ 23.561859] PM: late suspend of devices complete after 6.957 msecs
[ 24.464813] Successfully put all powerdomains to target state
[ 24.466674] ------------[ cut here ]------------
[ 24.466857] WARNING: at drivers/video/omap2/dss/dss.c:713 0xc01350f8()
[ 24.467010] Modules linked in:
[ 24.467132] Backtrace:
[ 24.467254] Function entered at [<c0010c3c>] from [<c02c4a60>]
[ 24.467407] r6:c02ffdaa r5:000002c9 r4:00000000 r3:00000000
[ 24.467651] Function entered at [<c02c4a48>] from [<c00344d0>]
[ 24.467803] Function entered at [<c003447c>] from [<c003450c>]
[ 24.467926] r8:00000000 r7:c0390a84 r6:c00288a4 r5:c037b85c
r4:fffffff3
[ 24.468200] r3:00000009
[ 24.468322] Function entered at [<c00344e8>] from [<c01350f8>]
[ 24.468475] Function entered at [<c01350ac>] from [<c013595c>]
[ 24.468597] r4:dec50208 r3:c013594c
[ 24.468780] Function entered at [<c013594c>] from [<c0182724>]
[ 24.468902] r6:c00288a4 r5:c037b85c r4:dec50208 r3:c013594c
[ 24.469177] Function entered at [<c01826f0>] from [<c0028900>]
[ 24.469299] Function entered at [<c00288a4>] from [<c01836f4>]
[ 24.469421] r4:dec50208 r3:00000000
[ 24.469604] Function entered at [<c0183614>] from [<c0183d20>]
[ 24.469726] r9:c02d7044 r8:00000000 r6:dec5025c r5:00000010
r4:dec50208
[ 24.470031] Function entered at [<c0183c54>] from [<c0063aa4>]
[ 24.470153] r8:c02ca888 r7:00000000 r6:00000003 r5:00000000
r4:00000000
[ 24.470458] Function entered at [<c006391c>] from [<c0063c60>]
[ 24.470581] r7:00000004 r6:00000000 r5:c02ca87c r4:00000003
[ 24.471130] Function entered at [<c0063b50>] from [<c0062ad4>]
[ 24.471282] r6:00000003 r5:00000003 r4:c6a87000 r3:0000006d
[ 24.471557] Function entered at [<c0062a2c>] from [<c0117728>]
[ 24.471679] Function entered at [<c011770c>] from [<c00e2ab0>]
[ 24.471832] Function entered at [<c00e29a0>] from [<c0098c98>]
[ 24.471954] Function entered at [<c0098be4>] from [<c0098f14>]
[ 24.472076] r8:00000004 r7:00000000 r6:00000000 r5:000ac750
r4:d8a70dc0
[ 24.472412] Function entered at [<c0098ed0>] from [<c000dcc0>]
[ 24.472534] r8:c000de44 r7:00000004 r6:000ac750 r5:00000004
r4:000a8e38
[ 24.472839] ---[ end trace 9f4f3053f6637dae ]---
[ 24.475006] PM: early resume of devices complete after 8.666 msecs
[ 25.040344] PM: resume of devices complete after 560.943 msecs
[ 25.277801] Restarting tasks ... done.
At which point the screen either restarts, or sometimes flickers and I get the following:
[ 22.578796] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled
[ 23.391571] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled
[ 24.391571] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled
It normally recovers after doing this for a while...
I'm assuming the problems started when DSS2 was adapted to runtime PM by Tomi as the warning comes from dss_runtime_get()?
Anyone have any ideas?
Cheers,
Joe
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: Add device tree support
From: Thomas Abraham @ 2012-01-11 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004401ccd041$c2f66100$48e32300$%han@samsung.com>
Dear Mr. Han,
On 11 January 2012 14:46, Jingoo Han <jg1.han@samsung.com> wrote:
> Hi, Thomas.
>
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Tuesday, January 10, 2012 5:02 AM
>> To: linux-fbdev@vger.kernel.org; devicetree-discuss@lists.ozlabs.org
>> Cc: FlorianSchandinat@gmx.de; grant.likely@secretlab.ca; rob.herring@calxeda.com; linux-arm-
>> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
>> jg1.han@samsung.com; patches@linaro.org
>> Subject: [PATCH] video: s3c-fb: Add device tree support
>>
>> Add device tree based discovery support for Samsung's display controller.
>>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> .../devicetree/bindings/fb/samsung-fb.txt | 103 ++++++++++
>> drivers/video/s3c-fb.c | 209 +++++++++++++++++++-
>> 2 files changed, 304 insertions(+), 8 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/fb/samsung-fb.txt
>>
>> [...]
>>
>> +- samsung,fimd-bpp: Specifies the bits per pixel. Two values should be
>> + specified in the following order.
>> + - max-bpp: maximum required bpp for the overlay.
>> + - default-bpp: bpp supported by the overlay.
>> [...]
>> + fimd-overlay0 {
>> + samsung,fimd-htiming = <64 16 48 1024>;
>> + samsung,fimd-vtiming = <64 16 3 600>;
>> + samsung,fimd-bpp = <24 32>;
>> + };
>> +
>> + fimd-overlay1 {
>> + samsung,fimd-htiming = <64 16 48 200>;
>> + samsung,fimd-vtiming = <64 16 3 100>;
>> + samsung,fimd-bpp = <16 32>;
>> + };
>> + };
> In the above 'samsung-fb.txt', the order is defined as max-bpp and default-bpp.
> However, <24 32> and <16 32> seems to be wrong.
> It should be <32 24> and <32 16>, respectively.
> Max bpp would be 32bpp in s3c-fb.
You are right. I will change the order in the documentation as
default-bpp and then max-bpp. Thanks for correction.
Regards,
Thomas.
>
> Best regards,
> Jingoo Han
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: Add device tree support
From: Thomas Abraham @ 2012-01-11 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120110045219.GA5433@sirena.org.uk>
Hi Mark,
On 10 January 2012 10:22, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Jan 10, 2012 at 01:31:47AM +0530, Thomas Abraham wrote:
>
>> +Required properties:
>
>> +- gpios: The gpios used to interface with the external LCD panel.
>
> This isn't terribly informative for the user - which GPIOs and in what
> order are they specified? Looking at the code it looks like pin mux
> configuration so just some wording saying it's a list of pins to be used
> for the framebuffer function.
Ok. I will modify the sentence to mean that it is list of gpios used
by framebuffer controller for data/timing interface with the lcd
panel. Thanks for your review.
Regards,
Thomas.
^ permalink raw reply
* RE: [PATCH] video: s3c-fb: Add device tree support
From: Jingoo Han @ 2012-01-11 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326139307-25112-1-git-send-email-thomas.abraham@linaro.org>
Hi, Thomas.
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Tuesday, January 10, 2012 5:02 AM
> To: linux-fbdev@vger.kernel.org; devicetree-discuss@lists.ozlabs.org
> Cc: FlorianSchandinat@gmx.de; grant.likely@secretlab.ca; rob.herring@calxeda.com; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
> jg1.han@samsung.com; patches@linaro.org
> Subject: [PATCH] video: s3c-fb: Add device tree support
>
> Add device tree based discovery support for Samsung's display controller.
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> .../devicetree/bindings/fb/samsung-fb.txt | 103 ++++++++++
> drivers/video/s3c-fb.c | 209 +++++++++++++++++++-
> 2 files changed, 304 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/samsung-fb.txt
>
> [...]
>
> +- samsung,fimd-bpp: Specifies the bits per pixel. Two values should be
> + specified in the following order.
> + - max-bpp: maximum required bpp for the overlay.
> + - default-bpp: bpp supported by the overlay.
> [...]
> + fimd-overlay0 {
> + samsung,fimd-htiming = <64 16 48 1024>;
> + samsung,fimd-vtiming = <64 16 3 600>;
> + samsung,fimd-bpp = <24 32>;
> + };
> +
> + fimd-overlay1 {
> + samsung,fimd-htiming = <64 16 48 200>;
> + samsung,fimd-vtiming = <64 16 3 100>;
> + samsung,fimd-bpp = <16 32>;
> + };
> + };
In the above 'samsung-fb.txt', the order is defined as max-bpp and default-bpp.
However, <24 32> and <16 32> seems to be wrong.
It should be <32 24> and <32 16>, respectively.
Max bpp would be 32bpp in s3c-fb.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove
From: Russell King - ARM Linux @ 2012-01-10 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120110140218.GB7180@jl-vm1.vm.bytemark.co.uk>
On Tue, Jan 10, 2012 at 02:02:18PM +0000, Jamie Lokier wrote:
> If you're connecting an RGB555 or RGB444 panel, don't you want the
> software using the framebuffer to know this so it will dither appropriately?
>
> E.g. gradients look "bandy" if drawn in RGB565 then green's LSB is dropped.
This is why you use the bitfield stuff to tell userspace what the
actual properties of the framebuffer are.
(However, there are some userspace programs which ignore that
information and think they know better than the kernel about how a
frame buffer is organised - which is a constant pain in the butt when
you have a display which isn't BGR. But that's really a userspace
bug in those silly programs.)
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-10 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120110130146.GC2057@taskit.de>
>>>>> "Christian" = Christian Glindkamp <christian.glindkamp@taskit.de> writes:
Hi,
>> 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.
Christian> But the AT91SAM9261/AT91SAM9263 do not have a native RGB565
Christian> format if it is configured for 16bit (so it does not read
Christian> 32bit and output 24bit but just 16bit) but uses BGR555 with
Christian> an additional intensity bit in the MSB like the palette
Christian> where you also kept the BGR555 format. How can you get
Christian> correct colors on these processors if this code above is
Christian> removed?
I now had a look at the 9261/9263 datasheets, and don't find any
explicit mention of the bit layout of the 16bit/24bit modes. Just to be
completely sure:
- 16bit mode is IBGR-1555 (independently of little/big/wince mode?)
- 24bit is BGR-888 (packed) or XBGR-8888 (unpacked)
Right?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120110140218.GB7180@jl-vm1.vm.bytemark.co.uk>
>>>>> "Jamie" = Jamie Lokier <jamie@shareable.org> writes:
>> Similar you can connect a 12bit 4:4:4 panel by just connecting it to the
>> MSB LCD pins.
Jamie> If you're connecting an RGB555 or RGB444 panel, don't you want
Jamie> the software using the framebuffer to know this so it will
Jamie> dither appropriately?
Potentially. This is similar to the issues with cheap 18bit laptop
LCDs. We somewhat do this (E.G. default to 565 mode if a 16bit panel is
used), but as the hardware doesn't support anything bwteen 8bit paletted
and RGB565 modes, there's not much else we can do (fbdev doesn't provide
any info about the panel specs).
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove
From: Jamie Lokier @ 2012-01-10 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ty45dt89.fsf@macbook.be.48ers.dk>
Peter Korsgaard wrote:
> 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.
If you're connecting an RGB555 or RGB444 panel, don't you want the
software using the framebuffer to know this so it will dither appropriately?
E.g. gradients look "bandy" if drawn in RGB565 then green's LSB is dropped.
-- Jamie
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2012-01-10 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120110130146.GC2057@taskit.de>
>>>>> "Christian" = Christian Glindkamp <christian.glindkamp@taskit.de> writes:
Hi,
>> 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.
Christian> But the AT91SAM9261/AT91SAM9263 do not have a native RGB565
Christian> format if it is configured for 16bit (so it does not read
Christian> 32bit and output 24bit but just 16bit) but uses BGR555 with
Christian> an additional intensity bit in the MSB like the palette
Christian> where you also kept the BGR555 format. How can you get
Christian> correct colors on these processors if this code above is
Christian> removed?
Ahh, I wasn't aware of that (I'm using 9g45). I guess we need to do
something similar to what I did for the palette handling:
https://github.com/at91linux/linux-at91/commit/7a256fc44c1892ad3166363ba309d9996a49e7b8
E.G. keep the RBG555/BGR555 format for the old devices, and my proposed
change for the new ones. I'll cook something up.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove
From: Christian Glindkamp @ 2012-01-10 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ty45dt89.fsf@macbook.be.48ers.dk>
On 2012-01-09 12:13, Peter Korsgaard wrote:
> >>>>> "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.
But the AT91SAM9261/AT91SAM9263 do not have a native RGB565 format if it
is configured for 16bit (so it does not read 32bit and output 24bit but
just 16bit) but uses BGR555 with an additional intensity bit in the MSB
like the palette where you also kept the BGR555 format. How can you get
correct colors on these processors if this code above is removed?
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: Add device tree support
From: Mark Brown @ 2012-01-10 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326139307-25112-1-git-send-email-thomas.abraham@linaro.org>
On Tue, Jan 10, 2012 at 01:31:47AM +0530, Thomas Abraham wrote:
> +Required properties:
> +- gpios: The gpios used to interface with the external LCD panel.
This isn't terribly informative for the user - which GPIOs and in what
order are they specified? Looking at the code it looks like pin mux
configuration so just some wording saying it's a list of pins to be used
for the framebuffer function.
^ permalink raw reply
* [PATCH] video: s3c-fb: Add device tree support
From: Thomas Abraham @ 2012-01-09 19:59 UTC (permalink / raw)
To: linux-arm-kernel
Add device tree based discovery support for Samsung's display controller.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
.../devicetree/bindings/fb/samsung-fb.txt | 103 ++++++++++
drivers/video/s3c-fb.c | 209 +++++++++++++++++++-
2 files changed, 304 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/samsung-fb.txt
diff --git a/Documentation/devicetree/bindings/fb/samsung-fb.txt b/Documentation/devicetree/bindings/fb/samsung-fb.txt
new file mode 100644
index 0000000..8a27fcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/samsung-fb.txt
@@ -0,0 +1,103 @@
+* Samsung Display Controller (Framebuffer)
+
+The display controller is used to transfer image data from memory to a
+external LCD panel. It supports various color formats such as rgb, yuv
+and I80. It also supports multiple window overlays.
+
+Required properties:
+- compatible: should be one of the following
+ - samsung,exynos4210-fimd: for fimd compatible with Exynos4210 fimd
+ - samsung,s5pv210-fimd: for fimd compatible with s5pv210 fimd
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: Three interrupts should be specified. The format of the
+ interrupt specifier depends on the interrupt controller. The interrupts
+ should be specified in the following order.
+ - VSYNC (Video Frame) interrupt
+ - Video FIFO level interrupt
+ - FIMD System Interrupt
+- gpios: The gpios used to interface with the external LCD panel.
+
+Overlays: Multiple overlays can be specified and child nodes. The order
+of the overlay should be the lowest numbered overlay first.
+- samsung,fimd-htiming: Specifies the horizontal timing for the overlay.
+ The horizontal timing includes four parameters in the following order.
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - X resolution.
+- samsung,fimd-vtiming: Specifies the vertical timing for the overlay.
+ The vertical timing includes four parameters in the following order.
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Y resolution.
+- samsung,fimd-bpp: Specifies the bits per pixel. Two values should be
+ specified in the following order.
+ - max-bpp: maximum required bpp for the overlay.
+ - default-bpp: bpp supported by the overlay.
+- samsung,fimd-virtres: Specifies the resolution of the virtual frame
+ buffer. The resolution contains the X and Y resolution with value
+ of X being the first.
+
+Optional properties:
+- samsung,fimd-vidout-rgb: Video output format is RGB.
+- samsung,fimd-inv-hsync: invert hsync pulse polarity.
+- samsung,fimd-inv-vsync: invert vsync pulse polarity.
+- samsung,fimd-inv-vclk: invert video clock polarity.
+- samsung,fimd-inv-vden: invert video enable signal polarity.
+
+Example:
+
+ fimd@11C00000 {
+ compatible = "samsung,exynos4210-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x11C00000 0x8000>;
+ interrupts = <11 1>, <11 0>, <11 2>;
+
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-hsync;
+ samsung,fimd-inv-vsync;
+ samsung,fimd-inv-vclk;
+
+ gpios = <&gpf0 0 2 0 0>,
+ <&gpf0 1 2 0 0>,
+ <&gpf0 2 2 0 0>,
+ <&gpf0 3 2 0 0>,
+ <&gpf0 4 2 0 0>,
+ <&gpf0 5 2 0 0>,
+ <&gpf0 6 2 0 0>,
+ <&gpf0 7 2 0 0>,
+ <&gpf1 0 2 0 0>,
+ <&gpf1 1 2 0 0>,
+ <&gpf1 2 2 0 0>,
+ <&gpf1 3 2 0 0>,
+ <&gpf1 4 2 0 0>,
+ <&gpf1 5 2 0 0>,
+ <&gpf1 6 2 0 0>,
+ <&gpf1 7 2 0 0>,
+ <&gpf2 0 2 0 0>,
+ <&gpf2 1 2 0 0>,
+ <&gpf2 2 2 0 0>,
+ <&gpf2 3 2 0 0>,
+ <&gpf2 4 2 0 0>,
+ <&gpf2 5 2 0 0>,
+ <&gpf2 6 2 0 0>,
+ <&gpf2 7 2 0 0>,
+ <&gpf3 0 2 0 0>,
+ <&gpf3 1 2 0 0>,
+ <&gpf3 2 2 0 0>,
+ <&gpf3 3 2 0 0>;
+
+ fimd-overlay0 {
+ samsung,fimd-htiming = <64 16 48 1024>;
+ samsung,fimd-vtiming = <64 16 3 600>;
+ samsung,fimd-bpp = <24 32>;
+ };
+
+ fimd-overlay1 {
+ samsung,fimd-htiming = <64 16 48 200>;
+ samsung,fimd-vtiming = <64 16 3 100>;
+ samsung,fimd-bpp = <16 32>;
+ };
+ };
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0753b1c..4517560 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -24,6 +24,8 @@
#include <linux/uaccess.h>
#include <linux/interrupt.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <mach/map.h>
#include <plat/regs-fb-v4.h>
@@ -215,6 +217,7 @@ struct s3c_fb {
int irq_no;
unsigned long irq_flags;
struct s3c_fb_vsync vsync_info;
+ int *gpios;
};
/**
@@ -1315,9 +1318,168 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
writel(reg & ~SHADOWCON_WINx_PROTECT(win), regs + SHADOWCON);
}
+#ifdef CONFIG_OF
+static int s3c_fb_dt_parse_gpios(struct device *dev, struct s3c_fb *sfb,
+ bool request)
+{
+ int nr_gpios, idx, gpio, ret;
+
+ nr_gpios = sfb->pdata->win[0]->max_bpp + 4;
+ sfb->gpios = devm_kzalloc(dev, sizeof(int) * nr_gpios, GFP_KERNEL);
+ if (!sfb->gpios) {
+ dev_err(dev, "unable to allocate private data for gpio\n");
+ return -ENOMEM;
+ }
+
+ for (idx = 0; idx < nr_gpios; idx++) {
+ gpio = of_get_gpio(dev->of_node, idx);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(dev, "invalid gpio[%d]: %d\n", idx, gpio);
+ return -EINVAL;
+ }
+
+ if (!request)
+ continue;
+
+ ret = gpio_request(gpio, "fimd");
+ if (ret) {
+ dev_err(dev, "gpio [%d] request failed\n", gpio);
+ goto gpio_free;
+ }
+ sfb->gpios[idx] = gpio;
+ }
+ return 0;
+
+gpio_free:
+ while (--idx >= 0)
+ gpio_free(sfb->gpios[idx]);
+ return ret;
+}
+
+static void s3c_fb_dt_free_gpios(struct s3c_fb *sfb)
+{
+ unsigned int idx, nr_gpio;
+
+ nr_gpio = sfb->pdata->win[0]->max_bpp + 4;
+ for (idx = 0; idx < nr_gpio; idx++)
+ gpio_free(sfb->gpios[idx]);
+}
+
+static int s3c_fb_dt_parse_pdata(struct device *dev,
+ struct s3c_fb_platdata **pdata)
+{
+ struct device_node *np = dev->of_node, *win_np;
+ struct s3c_fb_platdata *pd;
+ struct s3c_fb_pd_win *win;
+ int wnum = 0;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "no memory for pdata\n");
+ *pdata = NULL;
+ return -ENOMEM;
+ }
+
+ if (of_get_property(np, "samsung,fimd-vidout-rgb", NULL))
+ pd->vidcon0 |= VIDCON0_VIDOUT_RGB;
+ if (of_get_property(np, "samsung,fimd-vidout-tv", NULL))
+ pd->vidcon0 |= VIDCON0_VIDOUT_TV;
+ if (of_get_property(np, "samsung,fimd-inv-hsync", NULL))
+ pd->vidcon1 |= VIDCON1_INV_HSYNC;
+ if (of_get_property(np, "samsung,fimd-inv-vsync", NULL))
+ pd->vidcon1 |= VIDCON1_INV_VSYNC;
+ if (of_get_property(np, "samsung,fimd-inv-vclk", NULL))
+ pd->vidcon1 |= VIDCON1_INV_VCLK;
+ if (of_get_property(np, "samsung,fimd-inv-vden", NULL))
+ pd->vidcon1 |= VIDCON1_INV_VDEN;
+
+ for_each_child_of_node(np, win_np) {
+ struct fb_videomode *vm;
+ u32 data[4];
+
+ win = devm_kzalloc(dev, sizeof(*win), GFP_KERNEL);
+ if (!win) {
+ dev_err(dev, "no memory for window[%d] data\n", wnum);
+ return -ENOMEM;
+ }
+ pd->win[wnum++] = win;
+
+ vm = &win->win_mode;
+ if (of_property_read_u32_array(win_np, "samsung,fimd-htiming",
+ data, 4)) {
+ dev_err(dev, "invalid horizontal timing\n");
+ return -EINVAL;
+ }
+ vm->left_margin = data[0];
+ vm->right_margin = data[1];
+ vm->hsync_len = data[2];
+ vm->xres = data[3];
+
+ if (of_property_read_u32_array(win_np, "samsung,fimd-vtiming",
+ data, 4)) {
+ dev_err(dev, "invalid vertical timing\n");
+ return -EINVAL;
+ }
+ vm->upper_margin = data[0];
+ vm->lower_margin = data[1];
+ vm->vsync_len = data[2];
+ vm->yres = data[3];
+
+ if (of_property_read_u32_array(win_np, "samsung,fimd-bpp",
+ data, 2)) {
+ dev_err(dev, "invalid bpp\n");
+ return -EINVAL;
+ }
+ win->max_bpp = data[0];
+ win->default_bpp = data[1];
+
+ if (!of_property_read_u32_array(win_np, "samsung,fimd-virtres",
+ data, 2)) {
+ win->virtual_x = data[0];
+ win->virtual_y = data[1];
+ }
+ }
+
+ *pdata = pd;
+ return 0;
+}
+#else
+static int s3c_fb_dt_parse_gpios(struct device *dev, struct s3c_fb *sfb,
+ bool request)
+{
+ return 0;
+}
+
+static void s3c_fb_dt_free_gpios(struct s3c_fb *sfb)
+{
+ return 0;
+}
+
+static int s3c_fb_dt_parse_pdata(struct device *dev,
+ struct s3c_fb_platdata **pdata)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
+static const struct of_device_id s3c_fb_dt_match[];
+
+static inline struct s3c_fb_driverdata *s3c_fb_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(s3c_fb_dt_match, pdev->dev.of_node);
+ return (struct s3c_fb_driverdata *)match->data;
+ }
+#endif
+ return (struct s3c_fb_driverdata *)
+ platform_get_device_id(pdev)->driver_data;
+}
+
static int __devinit s3c_fb_probe(struct platform_device *pdev)
{
- const struct platform_device_id *platid;
struct s3c_fb_driverdata *fbdrv;
struct device *dev = &pdev->dev;
struct s3c_fb_platdata *pd;
@@ -1326,15 +1488,21 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
int win;
int ret = 0;
- platid = platform_get_device_id(pdev);
- fbdrv = (struct s3c_fb_driverdata *)platid->driver_data;
+ fbdrv = s3c_fb_get_driver_data(pdev);
if (fbdrv->variant.nr_windows > S3C_FB_MAX_WIN) {
dev_err(dev, "too many windows, cannot attach\n");
return -EINVAL;
}
- pd = pdev->dev.platform_data;
+ if (pdev->dev.of_node) {
+ ret = s3c_fb_dt_parse_pdata(&pdev->dev, &pd);
+ if (ret)
+ return ret;
+ } else {
+ pd = pdev->dev.platform_data;
+ }
+
if (!pd) {
dev_err(dev, "no platform data specified\n");
return -EINVAL;
@@ -1419,7 +1587,12 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
/* setup gpio and output polarity controls */
- pd->setup_gpio();
+ if (dev->of_node) {
+ if (s3c_fb_dt_parse_gpios(dev, sfb, true))
+ goto err_irq;
+ } else {
+ pd->setup_gpio();
+ }
writel(pd->vidcon1, sfb->regs + VIDCON1);
@@ -1452,7 +1625,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
dev_err(dev, "failed to create window %d\n", win);
for (; win >= 0; win--)
s3c_fb_release_win(sfb, sfb->windows[win]);
- goto err_irq;
+ goto err_gpio;
}
}
@@ -1461,6 +1634,9 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
return 0;
+err_gpio:
+ s3c_fb_dt_free_gpios(sfb);
+
err_irq:
free_irq(sfb->irq_no, sfb);
@@ -1520,6 +1696,7 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
+ s3c_fb_dt_free_gpios(sfb);
kfree(sfb);
return 0;
}
@@ -1562,7 +1739,10 @@ static int s3c_fb_resume(struct device *dev)
clk_enable(sfb->lcd_clk);
/* setup gpio and output polarity controls */
- pd->setup_gpio();
+ if (dev->of_node)
+ s3c_fb_dt_parse_gpios(dev, sfb, false);
+ else
+ pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
/* zero all windows before we do anything */
@@ -1627,7 +1807,10 @@ static int s3c_fb_runtime_resume(struct device *dev)
clk_enable(sfb->lcd_clk);
/* setup gpio and output polarity controls */
- pd->setup_gpio();
+ if (dev->of_node)
+ s3c_fb_dt_parse_gpios(dev, sfb, false);
+ else
+ pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
/* zero all windows before we do anything */
@@ -1984,6 +2167,15 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
};
MODULE_DEVICE_TABLE(platform, s3c_fb_driver_ids);
+#ifdef CONFIG_OF
+static const struct of_device_id s3c_fb_dt_match[] = {
+ { .compatible = "samsung,exynos4210-fimd",
+ .data = (void *)&s3c_fb_data_exynos4 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, s3c_fb_dt_match);
+#endif
+
static const struct dev_pm_ops s3cfb_pm_ops = {
.suspend = s3c_fb_suspend,
.resume = s3c_fb_resume,
@@ -1999,6 +2191,7 @@ static struct platform_driver s3c_fb_driver = {
.name = "s3c-fb",
.owner = THIS_MODULE,
.pm = &s3cfb_pm_ops,
+ .of_match_table = of_match_ptr(s3c_fb_dt_match),
},
};
--
1.6.6.rc2
^ permalink raw reply related
* Re: [PATCH v2] atmel_lcdfb: fix usage of CONTRAST_CTR in
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-01-09 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326126237-4355-1-git-send-email-nicolas.ferre@atmel.com>
On 17:23 Mon 09 Jan , Nicolas Ferre wrote:
> From: Hubert Feurstein <h.feurstein@gmail.com>
>
> An error was existing in the saving of CONTRAST_CTR register
> across suspend/resume.
>
> Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: stable <stable@vger.kernel.org>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* [PATCH v2] atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
From: Nicolas Ferre @ 2012-01-09 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1307350251-5767-1-git-send-email-h.feurstein@gmail.com>
From: Hubert Feurstein <h.feurstein@gmail.com>
An error was existing in the saving of CONTRAST_CTR register
across suspend/resume.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
---
drivers/video/atmel_lcdfb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index d7e3712..d99505b 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1102,7 +1102,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
*/
lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
- sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
+ sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
if (sinfo->atmel_lcdfb_power_control)
sinfo->atmel_lcdfb_power_control(0);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 2/2] atmel_lcdfb: Use proper blanking on negative contrast
From: Nicolas Ferre @ 2012-01-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317801598-23757-2-git-send-email-alexander.stein@systec-electronic.com>
On 10/05/2011 09:59 AM, Alexander Stein :
> If used with negative polarity the PWM unit cannot be disabled. This would
> result in a full contrast screen.
> Instead let the PWM unit enabled using 0x0 as compare value which darkens
> the display.
> In result no power saving is possible if inverted contrast polarity
> is used.
Ok, this patch looks correct.
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Florian, you can propagate this one upstream.
Thanks you, best regards,
> ---
> drivers/video/atmel_lcdfb.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 816d528..2bd75b5 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -96,8 +96,11 @@ static int atmel_bl_update_status(struct backlight_device *bl)
> brightness = 0;
>
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
> - lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
> + if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
> brightness ? contrast_ctr : 0);
> + else
> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
>
> bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: fix usage of wrong registers in suspend/resume
From: Nicolas Ferre @ 2012-01-09 15:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1307350251-5767-1-git-send-email-h.feurstein@gmail.com>
On 06/06/2011 03:24 PM, Hubert Feurstein :
> Or it must be this way:
> ---
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 4484c72..c2ceae4 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1085,7 +1085,7 @@ static int atmel_lcdfb_suspend(struct
> platform_device *pdev, pm_message_t mesg)
> */
> lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
>
> - sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
> + sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
> if (sinfo->atmel_lcdfb_power_control)
> sinfo->atmel_lcdfb_power_control(0);
> --
> So which solution was originally intended?
Yes exactly: this solution is the preferred one.
I rebuild the patch with your authorship and send it again.
Thanks Hubert, best regards,
>
> Best regards
> Hubert
>
> 2011/6/6 Hubert Feurstein <h.feurstein@gmail.com>:
>> I assume the intention was to set the contrast value to 0 and not
>> the contrast control register (in atmel_lcdfb_suspend). And in
>> atmel_lcdfb_resume the contrast value should be restored.
>>
>> Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>> ---
>> drivers/video/atmel_lcdfb.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 4484c72..2ed7ec1 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -1086,7 +1086,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
>> lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
>>
>> sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
>> - lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
>> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, 0);
>> if (sinfo->atmel_lcdfb_power_control)
>> sinfo->atmel_lcdfb_power_control(0);
>>
>> @@ -1105,7 +1105,7 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
>> atmel_lcdfb_start(sinfo);
>> if (sinfo->atmel_lcdfb_power_control)
>> sinfo->atmel_lcdfb_power_control(1);
>> - lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
>> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, sinfo->saved_lcdcon);
>>
>> /* Enable FIFO & DMA errors */
>> lcdc_writel(sinfo, ATMEL_LCDC_IER, ATMEL_LCDC_UFLWI
>> --
>> 1.7.1
>>
>>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 1/2] atmel_lcdfb: Adjust HFP calculation so it matches
From: Nicolas Ferre @ 2012-01-09 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317801598-23757-1-git-send-email-alexander.stein@systec-electronic.com>
On 10/05/2011 09:59 AM, Alexander Stein :
> In the AT91SAM9263 Manual the HFP part in LCDTIM2 is described as follows:
> * HFP: Horizontal Front Porch
> Number of idle LCDDOTCK cycles at the end of the line.
> Idle period is (HFP+2) LCDDOTCK cycles.
Hi Alexander,
Unfortunately this is not true for all the SoC that embed the
atmel_lcdfb... So I may need to rework this patch but it is certainly
not applicable in the current form.
Florian, can you please remove it from your git tree?
Thanks,
Best regards,
> It is only a minor issue. I also changed all boards using atmel_lcdfb
> I found to respect the new calculation.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> arch/arm/mach-at91/board-cap9adk.c | 2 +-
> arch/arm/mach-at91/board-neocore926.c | 2 +-
> arch/arm/mach-at91/board-sam9261ek.c | 4 ++-
> arch/arm/mach-at91/board-sam9263ek.c | 2 +-
> arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +-
> arch/arm/mach-at91/board-sam9rlek.c | 2 +-
> drivers/video/atmel_lcdfb.c | 4 ++--
> 7 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-cap9adk.c b/arch/arm/mach-at91/board-cap9adk.c
> index 679b0b7..ae962bf 100644
> --- a/arch/arm/mach-at91/board-cap9adk.c
> +++ b/arch/arm/mach-at91/board-cap9adk.c
> @@ -304,7 +304,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 240, .yres = 320,
> .pixclock = KHZ2PICOS(4965),
>
> - .left_margin = 1, .right_margin = 33,
> + .left_margin = 1, .right_margin = 34,
> .upper_margin = 1, .lower_margin = 0,
> .hsync_len = 5, .vsync_len = 1,
>
> diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
> index 9bc6ab3..583878e 100644
> --- a/arch/arm/mach-at91/board-neocore926.c
> +++ b/arch/arm/mach-at91/board-neocore926.c
> @@ -235,7 +235,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 240, .yres = 320,
> .pixclock = KHZ2PICOS(5000),
>
> - .left_margin = 1, .right_margin = 33,
> + .left_margin = 1, .right_margin = 34,
> .upper_margin = 1, .lower_margin = 0,
> .hsync_len = 5, .vsync_len = 1,
>
> diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
> index 5096a0e..8dda83b 100644
> --- a/arch/arm/mach-at91/board-sam9261ek.c
> +++ b/arch/arm/mach-at91/board-sam9261ek.c
> @@ -370,7 +370,7 @@ static struct fb_videomode at91_stn_modes[] = {
> .xres = 320, .yres = 240,
> .pixclock = KHZ2PICOS(1440),
>
> - .left_margin = 1, .right_margin = 1,
> + .left_margin = 1, .right_margin = 2,
> .upper_margin = 0, .lower_margin = 0,
> .hsync_len = 1, .vsync_len = 1,
>
> @@ -431,7 +431,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 240, .yres = 320,
> .pixclock = KHZ2PICOS(4965),
>
> - .left_margin = 1, .right_margin = 33,
> + .left_margin = 1, .right_margin = 34,
> .upper_margin = 1, .lower_margin = 0,
> .hsync_len = 5, .vsync_len = 1,
>
> diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
> index ea8f185..e260070 100644
> --- a/arch/arm/mach-at91/board-sam9263ek.c
> +++ b/arch/arm/mach-at91/board-sam9263ek.c
> @@ -258,7 +258,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 240, .yres = 320,
> .pixclock = KHZ2PICOS(4965),
>
> - .left_margin = 1, .right_margin = 33,
> + .left_margin = 1, .right_margin = 34,
> .upper_margin = 1, .lower_margin = 0,
> .hsync_len = 5, .vsync_len = 1,
>
> diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
> index ad234cc..5e9a5ca 100644
> --- a/arch/arm/mach-at91/board-sam9m10g45ek.c
> +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
> @@ -197,7 +197,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 480, .yres = 272,
> .pixclock = KHZ2PICOS(9000),
>
> - .left_margin = 1, .right_margin = 1,
> + .left_margin = 1, .right_margin = 2,
> .upper_margin = 40, .lower_margin = 1,
> .hsync_len = 45, .vsync_len = 1,
>
> diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
> index 4f14b54..ad9e5c9 100644
> --- a/arch/arm/mach-at91/board-sam9rlek.c
> +++ b/arch/arm/mach-at91/board-sam9rlek.c
> @@ -154,7 +154,7 @@ static struct fb_videomode at91_tft_vga_modes[] = {
> .xres = 240, .yres = 320,
> .pixclock = KHZ2PICOS(4965),
>
> - .left_margin = 1, .right_margin = 33,
> + .left_margin = 1, .right_margin = 34,
> .upper_margin = 1, .lower_margin = 0,
> .hsync_len = 5, .vsync_len = 1,
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 817ab60..816d528 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -393,7 +393,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> var->lower_margin = min_t(u32, var->lower_margin,
> ATMEL_LCDC_VFP);
> var->right_margin = min_t(u32, var->right_margin,
> - (ATMEL_LCDC_HFP >> ATMEL_LCDC_HFP_OFFSET) + 1);
> + (ATMEL_LCDC_HFP >> ATMEL_LCDC_HFP_OFFSET) + 2);
> var->hsync_len = min_t(u32, var->hsync_len,
> (ATMEL_LCDC_HPW >> ATMEL_LCDC_HPW_OFFSET) + 1);
> var->left_margin = min_t(u32, var->left_margin,
> @@ -578,7 +578,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
> lcdc_writel(sinfo, ATMEL_LCDC_TIM1, value);
>
> /* Horizontal timing */
> - value = (info->var.right_margin - 1) << ATMEL_LCDC_HFP_OFFSET;
> + value = (info->var.right_margin - 2) << ATMEL_LCDC_HFP_OFFSET;
> value |= (info->var.hsync_len - 1) << ATMEL_LCDC_HPW_OFFSET;
> value |= (info->var.left_margin - 1);
> dev_dbg(info->device, " * LCDTIM2 = %08lx\n", value);
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported
From: Nicolas Ferre @ 2012-01-09 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F0A55D7.50707@gmx.de>
On 01/09/2012 03:49 AM, Florian Tobias Schandinat :
> 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.
Here is my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thank you Florian for taking care of it.
Best regards,
>> 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
>>
>
>
--
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