* 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
* 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: [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: 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 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
* [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 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] 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] 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
* 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] 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: 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 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 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
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