* Re: [PATCH 1/1] sh_mobile_lcdc: Add NV12 input framebuffer support
From: Damian @ 2011-02-22 2:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1297734708-20803-2-git-send-email-dhobsong@igel.co.jp>
On 2011/02/17 14:45, Damian wrote:
Hi again Magnus,
> On 2011/02/17 9:19, Magnus Damm wrote:
> Hi Magnus,
>> Hi Damian,
>>
>> On Tue, Feb 15, 2011 at 10:51 AM, Damian Hobson-Garcia
>> <dhobsong@igel.co.jp> wrote:
>>> Specify .bpp = 12 and .yuv = 1 when configuring the LCDC channel that
>>> you want
>>> to you with NV12 input support.
>>>
>>> Due to the encoding of YUV data, writing 0s to the framebuffer will
>>> clear to
>>> green instead of black.
>>>
>>> There is also no native framebuffer support for YUV formats,
>>> so this mode will not work with most software rendering.
>>>
>>> Signed-off-by: Damian Hobson-Garcia<dhobsong@igel.co.jp>
>>> ---
>>
>> Nice to see patches for YUV mode support!
> And thank you for your comments.
>>
>>> --- a/include/video/sh_mobile_lcdc.h
>>> +++ b/include/video/sh_mobile_lcdc.h
>>> @@ -25,6 +25,8 @@ enum {
>>> SYS24, /* 24bpp */
>>> };
>>>
>>> +#define REN_COLOR_NV12 0x1 /* Non-standard framebuffer color format
>>> - NV12 */
>>> +
>>> enum { LCDC_CHAN_DISABLED = 0,
>>> LCDC_CHAN_MAINLCD,
>>> LCDC_CHAN_SUBLCD };
>>> @@ -77,6 +79,7 @@ struct sh_mobile_lcdc_chan_cfg {
>>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>>> struct sh_mobile_lcdc_board_cfg board_cfg;
>>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
>>> + int yuv;
>>
>> Instead of having "yuv" here I think you should use "nonstd" and make
>> sure the "nonstd" field in struct fb_var_screeninfo is set the same
>> way.
>>
>> Also, the REN_COLOR_NV12 constant can go away IMO.
> Yes, I guess that using the nonstd together with the bits_per_pixel,
> REN_COLOR_NV12 is unnecessary.
>>
>> I believe the best way to deal with this is to map the "nonstd" value
>> directly to bit 16-18 in LDDFR. If "nonstd" is non-zero then you
>> should program bits 8-9 depending on the bpp value. This way both 12,
>> 16 and 20 (?) bit YUV can be supported with compression enabled or
>> not. I believe both sh7724 and sh7372 can be supported too - given
>> that the correct "nonstd" value is provided. But since it's provided
>> by the platform data it is part of the system configuration and we can
>> assume it is correct.
One question/comment about setting the value of nonstd.
Ideally, when an application reads the nonstd field from
fb_var_screeninfo, it would need to be sure that the value corresponds
to a YUV setting instead of some other valid non-zero nonstd value,
right? So maybe defining a bitmask for the YUV bit somewhere accessible
from user space would be beneficial (perhaps a new file,
linux/sh_mobile_fb.h, which might also be a good place to define any
ioctls that might be used in future, for blending for example).
It seems that for both sh7372 and sh7724 that bit would be bit 16 in
LDDFR, which is nice. As for the remaining bits, which are chip
dependent, I was thinking that it would be good to define similar
mask/flags and "or" them all together to build up nonstd. The question
is where to define these. There are separate files for mach/sh7724.h
and mach/sh7372.h, which I though might fit nicely or would it be better
to define flags for both chips in video/sh_mobile_lcdc.h?
> Sounds good. By 20 bit are you referring to the YCbCr 4:4:4 mode? I
> haven't really looked at that but it sounds like it should work. I think
> that its a 24 bit mode though, if I understand correctly 8 bits each for
> Y, Cb, Cr.
>>
>> Please consider reworking the patch to make it more generic. Just
>> adding NV12 support is aiming too low. =)
>>
> I'm also looking at re-arranging the arrangement of the Y and CbCr
> planes so that in a double buffer (or more) situation all of the Y
> planes come first, followed by the CbCr planes, as it makes the panning
> calculations much simpler.
>
> I'll submit these all as a version 2 of this patch.
>> Thanks,
>>
>> / magnus
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* [PATCH] video: da8xx-fb: fix section mismatch warning
From: Axel Lin @ 2011-02-22 1:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Sudhakar Rajashekhara, Paul Mundt, linux-fbdev
This patch includes below fixes:
1. Mark fb_probe as __devinit to fix below section mismatch warning.
WARNING: drivers/video/built-in.o(.data+0x13c): Section mismatch in reference from the variable da8xx_fb_driver to the function .init.text:fb_probe()
The variable da8xx_fb_driver references
the function __init fb_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
2. fb_remove is marked __devexit,
thus add __devexit_p around reference to fb_remove.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/video/da8xx-fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 8d61ef9..246f1c0 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -899,7 +899,7 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
-static int __init fb_probe(struct platform_device *device)
+static int __devinit fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata device->dev.platform_data;
@@ -1165,7 +1165,7 @@ static int fb_resume(struct platform_device *dev)
static struct platform_driver da8xx_fb_driver = {
.probe = fb_probe,
- .remove = fb_remove,
+ .remove = __devexit_p(fb_remove),
.suspend = fb_suspend,
.resume = fb_resume,
.driver = {
--
1.7.2
^ permalink raw reply related
* Re: [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-21 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218122946.GF18085@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 08:29:47PM +0800, Shawn Guo wrote:
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/clk.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/io.h>
> > +#include <mach/fb.h>
> > +#include <mach/hardware.h>
> > +#include <mach/mxs.h>
> > +
> > +#define REG_SET 4
> > +#define REG_CLR 8
> > +
> We already have these defined in mxs.h
I know, but as Wolfram realized this makes the driver architecture
specific. So I decided to duplicate this here and to remove
mach/hardware.h and mach/mxs.h (obviously still present in the last
posted version)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/7] Add a mfd IPUv3 driver
From: Jason Chen @ 2011-02-21 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297865452-32181-2-git-send-email-s.hauer@pengutronix.de>
hi, Sascha,
I have few comments for this patch.
> +#define MX51_IPU_CHANNEL_CSI0 0
> +#define MX51_IPU_CHANNEL_CSI1 1
> +#define MX51_IPU_CHANNEL_CSI2 2
> +#define MX51_IPU_CHANNEL_CSI3 3
> +#define MX51_IPU_CHANNEL_MEM_BG_SYNC 23
> +#define MX51_IPU_CHANNEL_MEM_FG_SYNC 27
> +#define MX51_IPU_CHANNEL_MEM_DC_SYNC 28
> +#define MX51_IPU_CHANNEL_MEM_FG_SYNC_ALPHA 31
> +#define MX51_IPU_CHANNEL_MEM_DC_ASYNC 41
> +#define MX51_IPU_CHANNEL_ROT_ENC_MEM 45
> +#define MX51_IPU_CHANNEL_ROT_VF_MEM 46
> +#define MX51_IPU_CHANNEL_ROT_PP_MEM 47
> +#define MX51_IPU_CHANNEL_ROT_ENC_MEM_OUT 48
> +#define MX51_IPU_CHANNEL_ROT_VF_MEM_OUT 49
> +#define MX51_IPU_CHANNEL_ROT_PP_MEM_OUT 50
> +#define MX51_IPU_CHANNEL_MEM_BG_SYNC_ALPHA 51
Had better use MX5_IPU as prefix because it's same value in MX5X.
> +
> + ipu_idmac_reg = ioremap(ipu_base + IPU_IDMAC_REG_BASE, PAGE_SIZE);
> + if (!ipu_idmac_reg) {
> + ret = -ENOMEM;
> + goto failed_ioremap2;
> + }
> +
> + ret = ipu_mipi_setup();
> + if (ret)
> + goto failed_mipi_setup;
I dont know what's the best way to do it, but I think you had better
consider mx53 platform, so maybe this mipi_setup function and also
below ipu hw reset could be set in platform data.
> +
> + ipu_clk = clk_get(&pdev->dev, "ipu");
> + if (IS_ERR(ipu_clk)) {
> + ret = PTR_ERR(ipu_clk);
> + dev_err(&pdev->dev, "clk_get failed with %d", ret);
> + goto failed_clk_get;
> + }
> +
> + ipu_get();
> +
> + ret = request_irq(irq1, ipu_irq_handler, IRQF_DISABLED, pdev->name,
> + &pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "request irq %d failed with: %d\n", irq1, ret);
> + goto failed_request_irq1;
> + }
> +
> + ret = request_irq(irq2, ipu_irq_handler, IRQF_DISABLED, pdev->name,
> + &pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "request irq %d failed with: %d\n", irq2, ret);
> + goto failed_request_irq2;
> + }
> +
> + ipu_reset();
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Dave Airlie @ 2011-02-21 3:12 UTC (permalink / raw)
To: James Simmons
Cc: Linux Fbdev development list, linaro-dev, Arnd Bergmann,
Sascha Hauer, DRI development list, Jesse Barker, Clark, Rob,
linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102171545470.21278@casper.infradead.org>
On Fri, Feb 18, 2011 at 2:14 AM, James Simmons <jsimmons@infradead.org> wrote:
>
>> I'm still in the learning-as-I-go phase here, so definitely not ready
>> to propose a solution, but it does seem to me like there is room for
>> some sort of kms-helper library here to handle more of the boilerplate
>> xf86-video-* stuff.. I guess I'll have a better picture once I have a
>> chance to add support for the various multi-monitor configurations.
>> But certainly would be interested if anyone already has some ideas.
>
> I have been thinking about this as well. One of the short coming for DRM
> on embedded platforms is the lack of a small well defined library that one
> could use. Right now libkms only handles buffer allocation. The mode
> setting is currently tied to the libdrm library. It would be nice to
> seperate the two out more. Move the mode setting code to libkms and then
> have libdrm be a wrapper around this. This way libdrm can both support
> the legacy drm drivers and the new kms drivers at the same time. It also
> makes a clear seperation. Jakob if you are willing to take this work I
> will gladly seen you patches.
the problem with that is libkms relies on libdrm, so you'd have a
circular dependency.
With the addition of the dumb ioctl to the kernel we can certainly
avoid some of that dependency,
but you guys are missing one important point about libkms, its meant
to be a fallback.
Why?
well because most GPUs in reality have non-generic memory layouts,
they prefer having tiled buffers for different things and different
types of tiling. There is simply no nice way to abstract that out,
since it depends on the userspace libraries that use this. Starting
off with an untiled allocation for the frontbuffer can pretty much
leave you messed up when you plug anything like acceleration in
afterwards.
I have been looking at this from the USB driver pov as well, and we
can probably resurrect the old xf86-video-modesetting driver along
with some code in the X server maybe, mesa also has a libkms fallback
X driver that works quite well if just a bit messy to build (since its
in mesa).
Dave.
^ permalink raw reply
* Fwd: Re: [PATCH] fbcon: Bugfix soft cursor detection in Tile Blitting
From: Henry Nestler @ 2011-02-20 20:50 UTC (permalink / raw)
To: linux-fbdev
Use mask 0x10 for "soft cursor" detection on in function tile_cursor.
(Tile Blitting Operation in framebuffer console).
The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD
and every second mode value as "software cursor". This hides the cursor
for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor"
should hide the cursor.
See also 0x10 in functions add_softcursor, bit_cursor and cw_cursor.
---
Kernel version 2.6.38-rc5
drivers/video/console/tileblit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/tileblit.c b/drivers/video/console/tileblit.c
index 0056a41..15e8e1a 100644
--- a/drivers/video/console/tileblit.c
+++ b/drivers/video/console/tileblit.c
@@ -83,7 +83,7 @@ static void tile_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int softback_lines, int fg, int bg)
{
struct fb_tilecursor cursor;
- int use_sw = (vc->vc_cursor_type & 0x01);
+ int use_sw = (vc->vc_cursor_type & 0x10);
cursor.sx = vc->vc_x;
cursor.sy = vc->vc_y;
^ permalink raw reply related
* [PATCH] s3fb: add support for 86C365 Trio3D
From: Ondrej Zary @ 2011-02-20 19:40 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list, David Miller
Add support for S3 Trio3D (86C365) cards to s3fb driver. Tested with one 4MB card.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:11:18.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 20:31:34.000000000 +0100
@@ -64,6 +64,8 @@ static const struct svga_fb_format s3fb_
static const struct svga_pll s3_pll = {3, 129, 3, 33, 0, 3,
35000, 240000, 14318};
+static const struct svga_pll s3_trio3d_pll = {3, 129, 3, 31, 0, 4,
+ 230000, 460000, 14318};
static const int s3_memsizes[] = {4096, 0, 3072, 8192, 2048, 6144, 1024, 512};
@@ -72,7 +74,8 @@ static const char * const s3_names[] = {
"S3 Plato/PX", "S3 Aurora64VP", "S3 Virge",
"S3 Virge/VX", "S3 Virge/DX", "S3 Virge/GX",
"S3 Virge/GX2", "S3 Virge/GX2P", "S3 Virge/GX2P",
- "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X"};
+ "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X",
+ "S3 Trio3D"};
#define CHIP_UNKNOWN 0x00
#define CHIP_732_TRIO32 0x01
@@ -93,6 +96,7 @@ static const char * const s3_names[] = {
#define CHIP_360_TRIO3D_1X 0x10
#define CHIP_362_TRIO3D_2X 0x11
#define CHIP_368_TRIO3D_2X 0x12
+#define CHIP_365_TRIO3D 0x13
#define CHIP_XXX_TRIO 0x80
#define CHIP_XXX_TRIO64V2_DXGX 0x81
@@ -341,7 +345,8 @@ static void s3_set_pixclock(struct fb_in
u8 regval;
int rv;
- rv = svga_compute_pll(&s3_pll, 1000000000 / pixclock, &m, &n, &r, info->node);
+ rv = svga_compute_pll((par->chip = CHIP_365_TRIO3D) ? &s3_trio3d_pll : &s3_pll,
+ 1000000000 / pixclock, &m, &n, &r, info->node);
if (rv < 0) {
printk(KERN_ERR "fb%d: cannot set requested pixclock, keeping old value\n", info->node);
return;
@@ -598,7 +603,8 @@ static int s3fb_set_par(struct fb_info *
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
dbytes = info->var.xres * ((bpp+7)/8);
vga_wcrt(par->state.vgabase, 0x91, (dbytes + 7) / 8);
vga_wcrt(par->state.vgabase, 0x90, (((dbytes + 7) / 8) >> 8) | 0x80);
@@ -1012,13 +1018,15 @@ static int __devinit s3_pci_probe(struct
regval = vga_rcrt(par->state.vgabase, 0x36);
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
switch ((regval & 0xE0) >> 5) {
case 0: /* 8MB -- only 4MB usable for display */
case 1: /* 4MB with 32-bit bus */
case 2: /* 4MB */
info->screen_size = 4 << 20;
break;
+ case 4: /* 2MB on 365 Trio3D */
case 6: /* 2MB */
info->screen_size = 2 << 20;
break;
@@ -1233,6 +1241,7 @@ static struct pci_device_id s3_devices[]
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A11), .driver_data = CHIP_357_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A12), .driver_data = CHIP_359_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A13), .driver_data = CHIP_36X_TRIO3D_1X_2X},
+ {PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8904), .driver_data = CHIP_365_TRIO3D},
{0, 0, 0, 0, 0, 0, 0}
};
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: PXA: PXAFB: Fix typo in ypos assignment
From: Marek Vasut @ 2011-02-20 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298214147-11578-3-git-send-email-anarsoul@gmail.com>
On Sunday 20 February 2011 16:02:27 Vasily Khoruzhick wrote:
> Sascha Hauer <s.hauer@pengutronix.de> pointed that
> ypos takes value of xpos due to typo.
Looks good,
Acked-by: Marek Vasut <marek.vasut@gmail.com>
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/video/pxafb.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 54a9ab8..80ea7e6 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -766,7 +766,7 @@ static int overlayfb_check_var(struct fb_var_screeninfo
> *var, int xpos, ypos, pfor, bpp;
>
> xpos = NONSTD_TO_XPOS(var->nonstd);
> - ypos = NONSTD_TO_XPOS(var->nonstd);
> + ypos = NONSTD_TO_YPOS(var->nonstd);
> pfor = NONSTD_TO_PFOR(var->nonstd);
>
> bpp = pxafb_var_to_bpp(var);
> @@ -864,7 +864,7 @@ static int overlayfb_set_par(struct fb_info *info)
>
> bpp = pxafb_var_to_bpp(var);
> xpos = NONSTD_TO_XPOS(var->nonstd);
> - ypos = NONSTD_TO_XPOS(var->nonstd);
> + ypos = NONSTD_TO_YPOS(var->nonstd);
> pfor = NONSTD_TO_PFOR(var->nonstd);
>
> ofb->control[0] = OVLxC1_PPL(var->xres) | OVLxC1_LPO(var->yres) |
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: PXA: PXAFB: Fix double-free issue
From: Marek Vasut @ 2011-02-20 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298214147-11578-1-git-send-email-anarsoul@gmail.com>
On Sunday 20 February 2011 16:02:25 Vasily Khoruzhick wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
>
> Release callback tries to free memory even if it was not allocated in
> map_video_memory, fix it.
>
> Added by Vasily Khoruzhick:
>
> - Clear x_res/y_res fields of fb.var on release, to make sure
> our callback will be called on next FBIOPUT_VSCREENINFO ioctl.
> - Disable overlay only if it was enabled.
> - Don't touch FDADR1 if it's not necessary
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> v2: remove unnecessary newlines, add comment about FDADR1
>
> drivers/video/pxafb.c | 49
> ++++++++++++++++++++++++++++++++++--------------- drivers/video/pxafb.h |
> 2 +-
> 2 files changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 825b665..41a499f 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -629,6 +629,9 @@ static void overlay1fb_disable(struct pxafb_layer *ofb)
> {
> uint32_t lccr5 = lcd_readl(ofb->fbi, LCCR5);
>
> + if (!(lcd_readl(ofb->fbi, OVL1C1) & OVLxC1_OEN))
> + return;
> +
Maybe you can even avoid reading LCCR5 above ;-)
> lcd_writel(ofb->fbi, OVL1C1, ofb->control[0] & ~OVLxC1_OEN);
>
> lcd_writel(ofb->fbi, LCSR1, LCSR1_BS(1));
> @@ -687,6 +690,9 @@ static void overlay2fb_disable(struct pxafb_layer *ofb)
> {
> uint32_t lccr5 = lcd_readl(ofb->fbi, LCCR5);
>
> + if (!(lcd_readl(ofb->fbi, OVL2C1) & OVLxC1_OEN))
> + return;
> +
Hm?
> lcd_writel(ofb->fbi, OVL2C1, ofb->control[0] & ~OVLxC1_OEN);
>
> lcd_writel(ofb->fbi, LCSR1, LCSR1_BS(2));
> @@ -720,12 +726,10 @@ static int overlayfb_open(struct fb_info *info, int
> user) if (user = 0)
> return -ENODEV;
>
> - /* allow only one user at a time */
> - if (atomic_inc_and_test(&ofb->usage))
> - return -EBUSY;
> + if (ofb->usage++ = 0)
> + /* unblank the base framebuffer */
> + fb_blank(&ofb->fbi->fb, FB_BLANK_UNBLANK);
>
> - /* unblank the base framebuffer */
> - fb_blank(&ofb->fbi->fb, FB_BLANK_UNBLANK);
> return 0;
> }
>
> @@ -733,12 +737,24 @@ static int overlayfb_release(struct fb_info *info,
> int user) {
> struct pxafb_layer *ofb = (struct pxafb_layer*) info;
>
> - atomic_dec(&ofb->usage);
> - ofb->ops->disable(ofb);
> -
> - free_pages_exact(ofb->video_mem, ofb->video_mem_size);
> - ofb->video_mem = NULL;
> - ofb->video_mem_size = 0;
> + if (--ofb->usage = 0) {
> + ofb->ops->disable(ofb);
> + ofb->fb.var.height = -1;
> + ofb->fb.var.width = -1;
> + ofb->fb.var.xres = ofb->fb.var.xres_virtual = 0;
> + ofb->fb.var.yres = ofb->fb.var.yres_virtual = 0;
> +
> + mutex_lock(&ofb->fb.mm_lock);
> + ofb->fb.fix.smem_start = 0;
> + ofb->fb.fix.smem_len = 0;
> + mutex_unlock(&ofb->fb.mm_lock);
> +
> + if (ofb->video_mem) {
> + free_pages_exact(ofb->video_mem, ofb->video_mem_size);
> + ofb->video_mem = NULL;
> + ofb->video_mem_size = 0;
> + }
> + }
> return 0;
> }
>
> @@ -817,7 +833,8 @@ static int overlayfb_map_video_memory(struct
> pxafb_layer *ofb) if (ofb->video_mem_size >= size)
> return 0;
>
> - free_pages_exact(ofb->video_mem, ofb->video_mem_size);
> + /* don't re-allocate: userspace may have the buffer mapped */
> + return -EINVAL;
> }
>
> ofb->video_mem = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
> @@ -891,7 +908,7 @@ static void __devinit init_pxafb_overlay(struct
> pxafb_info *fbi,
>
> ofb->id = id;
> ofb->ops = &ofb_ops[id];
> - atomic_set(&ofb->usage, 0);
> + ofb->usage = 0;
> ofb->fbi = fbi;
> init_completion(&ofb->branch_done);
> }
> @@ -1368,7 +1385,8 @@ static int pxafb_activate_var(struct
> fb_var_screeninfo *var, (lcd_readl(fbi, LCCR3) != fbi->reg_lccr3) ||
> (lcd_readl(fbi, LCCR4) != fbi->reg_lccr4) ||
> (lcd_readl(fbi, FDADR0) != fbi->fdadr[0]) ||
> - (lcd_readl(fbi, FDADR1) != fbi->fdadr[1]))
> + ((fbi->lccr0 & LCCR0_SDS) &&
> + (lcd_readl(fbi, FDADR1) != fbi->fdadr[1])))
> pxafb_schedule_work(fbi, C_REENABLE);
>
> return 0;
> @@ -1420,7 +1438,8 @@ static void pxafb_enable_controller(struct pxafb_info
> *fbi) lcd_writel(fbi, LCCR0, fbi->reg_lccr0 & ~LCCR0_ENB);
>
> lcd_writel(fbi, FDADR0, fbi->fdadr[0]);
> - lcd_writel(fbi, FDADR1, fbi->fdadr[1]);
> + if (fbi->lccr0 & LCCR0_SDS)
> + lcd_writel(fbi, FDADR1, fbi->fdadr[1]);
> lcd_writel(fbi, LCCR0, fbi->reg_lccr0 | LCCR0_ENB);
> }
>
> diff --git a/drivers/video/pxafb.h b/drivers/video/pxafb.h
> index 2353521..84e3ae1 100644
> --- a/drivers/video/pxafb.h
> +++ b/drivers/video/pxafb.h
> @@ -92,7 +92,7 @@ struct pxafb_layer_ops {
> struct pxafb_layer {
> struct fb_info fb;
> int id;
> - atomic_t usage;
> + uint32_t usage;
> uint32_t control[2];
>
> struct pxafb_layer_ops *ops;
^ permalink raw reply
* [PATCH] s3fb: maximize virtual vertical size for fast scrolling
From: Ondrej Zary @ 2011-02-20 18:37 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list, David Miller
Maximize virtual vertical framebuffer size during init to allow fast scrolling
(accelerated by panning).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 19:11:28.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 19:17:04.000000000 +0100
@@ -1060,6 +1060,14 @@ static int __devinit s3_pci_probe(struct
goto err_find_mode;
}
+ /* maximize virtual vertical size for fast scrolling */
+ info->var.yres_virtual = info->fix.smem_len * 8 /
+ (info->var.bits_per_pixel * info->var.xres_virtual);
+ if (info->var.yres_virtual < info->var.yres) {
+ dev_err(info->device, "virtual vertical size smaller than real\n");
+ goto err_find_mode;
+ }
+
rc = fb_alloc_cmap(&info->cmap, 256, 0);
if (rc < 0) {
dev_err(info->device, "cannot allocate colormap\n");
--
Ondrej Zary
^ permalink raw reply
* [PATCH v2 3/3] ARM: PXA: PXAFB: Fix typo in ypos assignment
From: Vasily Khoruzhick @ 2011-02-20 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298214147-11578-1-git-send-email-anarsoul@gmail.com>
Sascha Hauer <s.hauer@pengutronix.de> pointed that
ypos takes value of xpos due to typo.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/video/pxafb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 54a9ab8..80ea7e6 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -766,7 +766,7 @@ static int overlayfb_check_var(struct fb_var_screeninfo *var,
int xpos, ypos, pfor, bpp;
xpos = NONSTD_TO_XPOS(var->nonstd);
- ypos = NONSTD_TO_XPOS(var->nonstd);
+ ypos = NONSTD_TO_YPOS(var->nonstd);
pfor = NONSTD_TO_PFOR(var->nonstd);
bpp = pxafb_var_to_bpp(var);
@@ -864,7 +864,7 @@ static int overlayfb_set_par(struct fb_info *info)
bpp = pxafb_var_to_bpp(var);
xpos = NONSTD_TO_XPOS(var->nonstd);
- ypos = NONSTD_TO_XPOS(var->nonstd);
+ ypos = NONSTD_TO_YPOS(var->nonstd);
pfor = NONSTD_TO_PFOR(var->nonstd);
ofb->control[0] = OVLxC1_PPL(var->xres) | OVLxC1_LPO(var->yres) |
--
1.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: PXA: PXAFB: Fix plane Z-ordering problem
From: Vasily Khoruzhick @ 2011-02-20 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298214147-11578-1-git-send-email-anarsoul@gmail.com>
pxafb_overlay_init is not right place to change Z-ordering,
move it to main plane initialization.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/video/pxafb.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 41a499f..54a9ab8 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -940,8 +940,6 @@ static int __devinit pxafb_overlay_init(struct pxafb_info *fbi)
/* mask all IU/BS/EOF/SOF interrupts */
lcd_writel(fbi, LCCR5, ~0);
- /* place overlay(s) on top of base */
- fbi->lccr0 |= LCCR0_OUC;
pr_info("PXA Overlay driver loaded successfully!\n");
return 0;
}
@@ -1825,6 +1823,12 @@ static struct pxafb_info * __devinit pxafb_init_fbinfo(struct device *dev)
pxafb_decode_mach_info(fbi, inf);
+#ifdef CONFIG_FB_PXA_OVERLAY
+ /* place overlay(s) on top of base */
+ if (pxafb_overlay_supported())
+ fbi->lccr0 |= LCCR0_OUC;
+#endif
+
init_waitqueue_head(&fbi->ctrlr_wait);
INIT_WORK(&fbi->task, pxafb_task);
mutex_init(&fbi->ctrlr_lock);
--
1.7.4
^ permalink raw reply related
* [PATCH v2 1/3] ARM: PXA: PXAFB: Fix double-free issue
From: Vasily Khoruzhick @ 2011-02-20 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217110321.GF24627@n2100.arm.linux.org.uk>
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Release callback tries to free memory even if it was not allocated in
map_video_memory, fix it.
Added by Vasily Khoruzhick:
- Clear x_res/y_res fields of fb.var on release, to make sure
our callback will be called on next FBIOPUT_VSCREENINFO ioctl.
- Disable overlay only if it was enabled.
- Don't touch FDADR1 if it's not necessary
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
v2: remove unnecessary newlines, add comment about FDADR1
drivers/video/pxafb.c | 49 ++++++++++++++++++++++++++++++++++---------------
drivers/video/pxafb.h | 2 +-
2 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 825b665..41a499f 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -629,6 +629,9 @@ static void overlay1fb_disable(struct pxafb_layer *ofb)
{
uint32_t lccr5 = lcd_readl(ofb->fbi, LCCR5);
+ if (!(lcd_readl(ofb->fbi, OVL1C1) & OVLxC1_OEN))
+ return;
+
lcd_writel(ofb->fbi, OVL1C1, ofb->control[0] & ~OVLxC1_OEN);
lcd_writel(ofb->fbi, LCSR1, LCSR1_BS(1));
@@ -687,6 +690,9 @@ static void overlay2fb_disable(struct pxafb_layer *ofb)
{
uint32_t lccr5 = lcd_readl(ofb->fbi, LCCR5);
+ if (!(lcd_readl(ofb->fbi, OVL2C1) & OVLxC1_OEN))
+ return;
+
lcd_writel(ofb->fbi, OVL2C1, ofb->control[0] & ~OVLxC1_OEN);
lcd_writel(ofb->fbi, LCSR1, LCSR1_BS(2));
@@ -720,12 +726,10 @@ static int overlayfb_open(struct fb_info *info, int user)
if (user = 0)
return -ENODEV;
- /* allow only one user at a time */
- if (atomic_inc_and_test(&ofb->usage))
- return -EBUSY;
+ if (ofb->usage++ = 0)
+ /* unblank the base framebuffer */
+ fb_blank(&ofb->fbi->fb, FB_BLANK_UNBLANK);
- /* unblank the base framebuffer */
- fb_blank(&ofb->fbi->fb, FB_BLANK_UNBLANK);
return 0;
}
@@ -733,12 +737,24 @@ static int overlayfb_release(struct fb_info *info, int user)
{
struct pxafb_layer *ofb = (struct pxafb_layer*) info;
- atomic_dec(&ofb->usage);
- ofb->ops->disable(ofb);
-
- free_pages_exact(ofb->video_mem, ofb->video_mem_size);
- ofb->video_mem = NULL;
- ofb->video_mem_size = 0;
+ if (--ofb->usage = 0) {
+ ofb->ops->disable(ofb);
+ ofb->fb.var.height = -1;
+ ofb->fb.var.width = -1;
+ ofb->fb.var.xres = ofb->fb.var.xres_virtual = 0;
+ ofb->fb.var.yres = ofb->fb.var.yres_virtual = 0;
+
+ mutex_lock(&ofb->fb.mm_lock);
+ ofb->fb.fix.smem_start = 0;
+ ofb->fb.fix.smem_len = 0;
+ mutex_unlock(&ofb->fb.mm_lock);
+
+ if (ofb->video_mem) {
+ free_pages_exact(ofb->video_mem, ofb->video_mem_size);
+ ofb->video_mem = NULL;
+ ofb->video_mem_size = 0;
+ }
+ }
return 0;
}
@@ -817,7 +833,8 @@ static int overlayfb_map_video_memory(struct pxafb_layer *ofb)
if (ofb->video_mem_size >= size)
return 0;
- free_pages_exact(ofb->video_mem, ofb->video_mem_size);
+ /* don't re-allocate: userspace may have the buffer mapped */
+ return -EINVAL;
}
ofb->video_mem = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
@@ -891,7 +908,7 @@ static void __devinit init_pxafb_overlay(struct pxafb_info *fbi,
ofb->id = id;
ofb->ops = &ofb_ops[id];
- atomic_set(&ofb->usage, 0);
+ ofb->usage = 0;
ofb->fbi = fbi;
init_completion(&ofb->branch_done);
}
@@ -1368,7 +1385,8 @@ static int pxafb_activate_var(struct fb_var_screeninfo *var,
(lcd_readl(fbi, LCCR3) != fbi->reg_lccr3) ||
(lcd_readl(fbi, LCCR4) != fbi->reg_lccr4) ||
(lcd_readl(fbi, FDADR0) != fbi->fdadr[0]) ||
- (lcd_readl(fbi, FDADR1) != fbi->fdadr[1]))
+ ((fbi->lccr0 & LCCR0_SDS) &&
+ (lcd_readl(fbi, FDADR1) != fbi->fdadr[1])))
pxafb_schedule_work(fbi, C_REENABLE);
return 0;
@@ -1420,7 +1438,8 @@ static void pxafb_enable_controller(struct pxafb_info *fbi)
lcd_writel(fbi, LCCR0, fbi->reg_lccr0 & ~LCCR0_ENB);
lcd_writel(fbi, FDADR0, fbi->fdadr[0]);
- lcd_writel(fbi, FDADR1, fbi->fdadr[1]);
+ if (fbi->lccr0 & LCCR0_SDS)
+ lcd_writel(fbi, FDADR1, fbi->fdadr[1]);
lcd_writel(fbi, LCCR0, fbi->reg_lccr0 | LCCR0_ENB);
}
diff --git a/drivers/video/pxafb.h b/drivers/video/pxafb.h
index 2353521..84e3ae1 100644
--- a/drivers/video/pxafb.h
+++ b/drivers/video/pxafb.h
@@ -92,7 +92,7 @@ struct pxafb_layer_ops {
struct pxafb_layer {
struct fb_info fb;
int id;
- atomic_t usage;
+ uint32_t usage;
uint32_t control[2];
struct pxafb_layer_ops *ops;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 3/7] Add i.MX5 framebuffer driver
From: Jason Chen @ 2011-02-19 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218095221.GK24426@pengutronix.de>
hi, Sascha,
2011/2/18 Sascha Hauer <s.hauer@pengutronix.de>:
> Hi Jason,
>
> On Fri, Feb 18, 2011 at 05:22:09PM +0800, Jason Chen wrote:
>> hi, Sasha,
>>
>> > + if (var->vmode & FB_VMODE_ODD_FLD_FIRST) /* PAL */
>> > + sig_cfg.odd_field_first = 1;
>> > + if (var->sync & FB_SYNC_EXT)
>> > + sig_cfg.ext_clk = 1;
>> > + if (var->sync & FB_SYNC_HOR_HIGH_ACT)
>> > + sig_cfg.Hsync_pol = 1;
>> Please remove FB_SYNC_EXT support.
>
> No problem, can do. But why? Is it nonfunctional in the hardware
> or is it that the current code just misses more pieces to support
> this?
>
This flag represents external sync, some application will not check
this flag when they reset fb var, for example, X server fb driver will
ignore it, if so, the ipu external clock can not be set correctly.
I think ipu should decide external clock usage by other method. The
latest method in freesacle mainline is decide it automatically -- if
internal clock can not fit target clock rate well, switch it to
external.
>>
>> +static void imx_ipu_fb_disable_overlay(struct fb_info *ovl)
>> +{
>> + struct imx_ipu_fb_info *mxc_ovl = ovl->par;
>> +
>> + if (!mxc_ovl->enabled)
>> + return;
>> +
>> + ipu_dp_disable_fg(mxc_ovl->dp);
>> + ipu_wait_for_interrupt(451, 100);
>> + ipu_idmac_disable_channel(mxc_ovl->ipu_ch);
>> + ipu_dmfc_disable_channel(mxc_ovl->dmfc);
>> + mxc_ovl->enabled = 0;
>> +}
>> Had better has a definition of ipu irq 451.
>
> Ok.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Tomi Valkeinen @ 2011-02-18 16:43 UTC (permalink / raw)
To: Daniel Morsing
Cc: Thomas Weber, Tony Lindgren, Bryan Wu,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1298045888.6421.6.camel@morsing>
On Fri, 2011-02-18 at 10:18 -0600, Daniel Morsing wrote:
> On Fri, 2011-02-18 at 15:07 +0200, Tomi Valkeinen wrote:
> > On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:
> > > On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:
> > > > Hello Daniel,
> > > >
> > > > Am 12.02.2011 18:02, schrieb Daniel Morsing:
> > > > > This patch adds a generic panel entry for the 4.3 inch display that is
> > > > > sold with the devkit8000 and modifies the board file to use this
> > > > > display.
> > > > >
> > > > >
> > > >
> > > > So only the 4.3 inch display can be used with the devkit8000?
> > > > There are also Devkit8000 with 5.6 and 7 inch displays.
> > > >
> > > > Regards,
> > > > Thomas
> > > >
> > >
> > > Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
> > > way to specify a board using a class of displays with separate timing
> > > settings.
> > >
> > > One way to do it would be to add the settings to modedb, but modedb is
> > > really only for standardized display settings. The other way to do it
> > > would be to add a kernel config for which display you have connected to
> > > the board, but I think that is a bad idea, because it makes everything
> > > more complicated and switching out displays would require recompiling
> > > the kernel.
> > >
> > > Maybe Tomi or the fbdev guys have some input on how to best do this?
> >
> > There's no proper way for this currently. And I'm not even sure what
> > would be a good way to do this.
> >
> > Optimally the board code could read some configuration value from eeprom
> > or where-ever, which would tell the configuration of the board. And the
> > board file could then configure the correct display.
> >
> > Another way would be to add a devkit8000 specific kernel parameter,
> > given from bootloader, which would tell the configuration. The board
> > file would use this parameter to configure the correct display.
> >
> > Tomi
> >
> >
>
> How about making it possible to give a generic panel name to the
> omapfb.mode boot parameter? This would also solve the problem for any
> future boards with different non-standard displays.
No, that wouldn't work. omapfb driver would need to somehow know about
the generic panel driver, to be able to set it up in a special way.
Tomi
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Daniel Morsing @ 2011-02-18 16:18 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Thomas Weber, Tony Lindgren, Bryan Wu,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1298034466.24062.99.camel@deskari>
On Fri, 2011-02-18 at 15:07 +0200, Tomi Valkeinen wrote:
> On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:
> > On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:
> > > Hello Daniel,
> > >
> > > Am 12.02.2011 18:02, schrieb Daniel Morsing:
> > > > This patch adds a generic panel entry for the 4.3 inch display that is
> > > > sold with the devkit8000 and modifies the board file to use this
> > > > display.
> > > >
> > > >
> > >
> > > So only the 4.3 inch display can be used with the devkit8000?
> > > There are also Devkit8000 with 5.6 and 7 inch displays.
> > >
> > > Regards,
> > > Thomas
> > >
> >
> > Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
> > way to specify a board using a class of displays with separate timing
> > settings.
> >
> > One way to do it would be to add the settings to modedb, but modedb is
> > really only for standardized display settings. The other way to do it
> > would be to add a kernel config for which display you have connected to
> > the board, but I think that is a bad idea, because it makes everything
> > more complicated and switching out displays would require recompiling
> > the kernel.
> >
> > Maybe Tomi or the fbdev guys have some input on how to best do this?
>
> There's no proper way for this currently. And I'm not even sure what
> would be a good way to do this.
>
> Optimally the board code could read some configuration value from eeprom
> or where-ever, which would tell the configuration of the board. And the
> board file could then configure the correct display.
>
> Another way would be to add a devkit8000 specific kernel parameter,
> given from bootloader, which would tell the configuration. The board
> file would use this parameter to configure the correct display.
>
> Tomi
>
>
How about making it possible to give a generic panel name to the
omapfb.mode boot parameter? This would also solve the problem for any
future boards with different non-standard displays.
Regards,
Daniel Morsing
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Tomi Valkeinen @ 2011-02-18 13:07 UTC (permalink / raw)
To: Daniel Morsing
Cc: Thomas Weber, Tony Lindgren, Bryan Wu,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1298033744.2323.9.camel@morsing>
On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:
> On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:
> > Hello Daniel,
> >
> > Am 12.02.2011 18:02, schrieb Daniel Morsing:
> > > This patch adds a generic panel entry for the 4.3 inch display that is
> > > sold with the devkit8000 and modifies the board file to use this
> > > display.
> > >
> > >
> >
> > So only the 4.3 inch display can be used with the devkit8000?
> > There are also Devkit8000 with 5.6 and 7 inch displays.
> >
> > Regards,
> > Thomas
> >
>
> Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
> way to specify a board using a class of displays with separate timing
> settings.
>
> One way to do it would be to add the settings to modedb, but modedb is
> really only for standardized display settings. The other way to do it
> would be to add a kernel config for which display you have connected to
> the board, but I think that is a bad idea, because it makes everything
> more complicated and switching out displays would require recompiling
> the kernel.
>
> Maybe Tomi or the fbdev guys have some input on how to best do this?
There's no proper way for this currently. And I'm not even sure what
would be a good way to do this.
Optimally the board code could read some configuration value from eeprom
or where-ever, which would tell the configuration of the board. And the
board file could then configure the correct display.
Another way would be to add a devkit8000 specific kernel parameter,
given from bootloader, which would tell the configuration. The board
file would use this parameter to configure the correct display.
Tomi
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Daniel Morsing @ 2011-02-18 12:55 UTC (permalink / raw)
To: Thomas Weber
Cc: Tony Lindgren, Tomi Valkeinen, Bryan Wu, linux-fbdev, linux-omap
In-Reply-To: <4D5E67E7.7040603@gmail.com>
On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:
> Hello Daniel,
>
> Am 12.02.2011 18:02, schrieb Daniel Morsing:
> > This patch adds a generic panel entry for the 4.3 inch display that is
> > sold with the devkit8000 and modifies the board file to use this
> > display.
> >
> >
>
> So only the 4.3 inch display can be used with the devkit8000?
> There are also Devkit8000 with 5.6 and 7 inch displays.
>
> Regards,
> Thomas
>
Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
way to specify a board using a class of displays with separate timing
settings.
One way to do it would be to add the settings to modedb, but modedb is
really only for standardized display settings. The other way to do it
would be to add a kernel config for which display you have connected to
the board, but I think that is a bad idea, because it makes everything
more complicated and switching out displays would require recompiling
the kernel.
Maybe Tomi or the fbdev guys have some input on how to best do this?
Regards,
Daniel Morsing
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Thomas Weber @ 2011-02-18 12:36 UTC (permalink / raw)
To: Daniel Morsing
Cc: Tony Lindgren, Tomi Valkeinen, Bryan Wu, linux-fbdev, linux-omap
In-Reply-To: <1297530130-10355-3-git-send-email-daniel.morsing@gmail.com>
Hello Daniel,
Am 12.02.2011 18:02, schrieb Daniel Morsing:
> This patch adds a generic panel entry for the 4.3 inch display that is
> sold with the devkit8000 and modifies the board file to use this
> display.
>
> Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com>
> ---
> Note that this patch depends on the previous one in the series.
>
> arch/arm/mach-omap2/board-devkit8000.c | 2 +-
> drivers/video/omap2/displays/panel-generic-dpi.c | 26 ++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
> index 9a2a31e..6dab13e 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -148,7 +148,7 @@ static struct regulator_consumer_supply devkit8000_vio_supply > REGULATOR_SUPPLY("vcc", "spi2.0");
>
> static struct panel_generic_dpi_data lcd_panel = {
> - .name = "generic",
> + .name = "devkit_43",
> .platform_enable = devkit8000_panel_enable_lcd,
> .platform_disable = devkit8000_panel_disable_lcd,
> };
So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.
Regards,
Thomas
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index b52a28f..ee9e7ea 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -83,6 +83,32 @@ static struct panel_config generic_dpi_panels[] = {
> .name = "generic",
> },
>
> + /* Devkit8000 4.3 Inch display */
> + {
> + {
> + .x_res = 480,
> + .y_res = 272,
> +
> + .pixel_clock = 10000,
> +
> + .hfp = 2,
> + .hsw = 41,
> + .hbp = 2,
> +
> + .vfp = 2,
> + .vsw = 10,
> + .vbp = 2,
> + },
> + .acbi = 0x0,
> + .acb = 0x0,
> + .recommended_bpp = 16,
> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS,
> + .power_on_delay = 50,
> + .power_off_delay = 100,
> + .name = "devkit_43",
> + },
> +
> /* Sharp LQ043T1DG01 */
> {
> {
^ permalink raw reply
* Re: [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Shawn Guo @ 2011-02-18 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297850199-1688-2-git-send-email-s.hauer@pengutronix.de>
On Wed, Feb 16, 2011 at 10:56:38AM +0100, Sascha Hauer wrote:
> changes since v1:
> - Add a LCDC_ prefix to the register names.
> - use set/clear registers where appropriate
> - protect call to mxsfb_disable_controller() in mxsfb_remove()
> with a (host->enabled) as suggested by Lothar Wassmann
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/include/mach/fb.h | 48 ++
> drivers/video/Kconfig | 9 +
> drivers/video/Makefile | 1 +
> drivers/video/mxsfb.c | 910 +++++++++++++++++++++++++++++++++++
> 4 files changed, 968 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mxs/include/mach/fb.h
> create mode 100644 drivers/video/mxsfb.c
>
> diff --git a/arch/arm/mach-mxs/include/mach/fb.h b/arch/arm/mach-mxs/include/mach/fb.h
> new file mode 100644
> index 0000000..923f397
> --- /dev/null
> +++ b/arch/arm/mach-mxs/include/mach/fb.h
> @@ -0,0 +1,48 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +
> +#ifndef __MACH_FB_H
> +#define __MACH_FB_H
> +
> +#include <linux/fb.h>
> +
> +#define STMLCDIF_8BIT 1 /** pixel data bus to the display is of 8 bit width */
> +#define STMLCDIF_16BIT 0 /** pixel data bus to the display is of 16 bit width */
> +#define STMLCDIF_18BIT 2 /** pixel data bus to the display is of 18 bit width */
> +#define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width */
> +
> +#define FB_SYNC_DATA_ENABLE_HIGH_ACT 64
> +
> +struct mxsfb_platform_data {
> + struct fb_videomode *mode_list;
> + unsigned mode_count;
> +
> + unsigned default_bpp;
> +
> + unsigned dotclk_delay; /* refer manual HW_LCDIF_VDCTRL4 register */
> + unsigned ld_intf_width; /* refer STMLCDIF_* macros */
> +
> + unsigned fb_size; /* Size of the video memory. If zero a
> + * default will be used
> + */
> + unsigned long fb_phys; /* physical address for the video memory. If
> + * zero the framebuffer memory will be dynamically
> + * allocated. If specified,fb_size must also be specified.
> + * fb_phys must be unused by Linux.
> + */
> +};
> +
> +#endif /* __MACH_FB_H */
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 6bafb51b..e0ea23f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2365,6 +2365,15 @@ config FB_JZ4740
> help
> Framebuffer support for the JZ4740 SoC.
>
> +config FB_MXS
> + tristate "MXS LCD framebuffer support"
> + depends on FB && ARCH_MXS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + Framebuffer support for the MXS SoC.
> +
> source "drivers/video/omap/Kconfig"
> source "drivers/video/omap2/Kconfig"
>
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 8c8fabd..9a096ae 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -153,6 +153,7 @@ obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
> obj-$(CONFIG_FB_MX3) += mx3fb.o
> obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> +obj-$(CONFIG_FB_MXS) += mxsfb.o
>
> # the test framebuffer is last
> obj-$(CONFIG_FB_VIRTUAL) += vfb.o
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> new file mode 100644
> index 0000000..ac9939b
> --- /dev/null
> +++ b/drivers/video/mxsfb.c
> @@ -0,0 +1,910 @@
> +/*
> + * Copyright (C) 2010 Juergen Beisert, Pengutronix
> + *
> + * This code is based on:
> + * Author: Vitaly Wool <vital@embeddedalley.com>
> + *
> + * Copyright 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define DRIVER_NAME "mxsfb"
> +
> +/**
> + * @file
> + * @brief LCDIF driver for i.MX23 and i.MX28
> + *
> + * The LCDIF support four modes of operation
> + * - MPU interface (to drive smart displays) -> not supported yet
> + * - VSYNC interface (like MPU interface plus Vsync) -> not supported yet
> + * - Dotclock interface (to drive LC displays with RGB data and sync signals)
> + * - DVI (to drive ITU-R BT656) -> not supported yet
> + *
> + * This driver depends on a correct setup of the pins used for this purpose
> + * (platform specific).
> + *
> + * For the developer: Don't forget to set the data bus width to the display
> + * in the imx_fb_videomode structure. You will else end up with ugly colours.
> + * If you fight against jitter you can vary the clock delay. This is a feature
> + * of the i.MX28 and you can vary it between 2 ns ... 8 ns in 2 ns steps. Give
> + * the required value in the imx_fb_videomode structure.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/io.h>
> +#include <mach/fb.h>
> +#include <mach/hardware.h>
> +#include <mach/mxs.h>
> +
> +#define REG_SET 4
> +#define REG_CLR 8
> +
We already have these defined in mxs.h
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/7] Add a mfd IPUv3 driver
From: Samuel Ortiz @ 2011-02-18 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218094949.GJ24426@pengutronix.de>
Hi Sascha,
On Fri, Feb 18, 2011 at 10:49:49AM +0100, Sascha Hauer wrote:
> On Thu, Feb 17, 2011 at 07:10:24PM +0100, Arnaud Patard wrote:
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index 6bafb51b..ffdb37a 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -26,6 +26,8 @@ source "drivers/gpu/drm/Kconfig"
> > >
> > > source "drivers/gpu/stub/Kconfig"
> > >
> > > +source "drivers/video/imx-ipu-v3/Kconfig"
> > > +
> >
> > I don't see such a Kconfig file in this patch. Got lost while moving
> > from mfd to video ?
>
> Oops, yes still untracked in my repository. Will add in the next series.
>
> >
> >
> > > config VGASTATE
> > > tristate
> > > default n
> > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > index 8c8fabd..f4921ab 100644
> > > --- a/drivers/video/Makefile
> > > +++ b/drivers/video/Makefile
> > > @@ -153,6 +153,7 @@ obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> > > obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
> > > obj-$(CONFIG_FB_MX3) += mx3fb.o
> > > obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> > > +obj-$(CONFIG_MFD_IMX_IPU_V3) += imx-ipu-v3/
> >
> > Now that files are in drivers/video, do we want to keep MFD in the name ?
>
> I asked myself the same question and had no clear answer. Probably
> better to remove the MFD.
Definitely, yes.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Sascha Hauer @ 2011-02-18 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296679619-32666-1-git-send-email-anarsoul@gmail.com>
Hi Vasily,
On Wed, Feb 02, 2011 at 10:46:59PM +0200, Vasily Khoruzhick wrote:
> From: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
>
> Release callback tries to free memory even if it was not allocated in
> map_video_memory. Fix PXA27x/3xx overlay memory management and make overlay
> actually work.
While at pxa overlay support you also might to fix that the xpos field
in var->nonstd is also used for ypos in two places:
ypos = NONSTD_TO_XPOS(var->nonstd);
^^^
I stumbled upon this but was not interested enough that moment to create
a patch.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 3/7] Add i.MX5 framebuffer driver
From: Sascha Hauer @ 2011-02-18 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTina46_CMvB_9cqc4=PvcPxaV_BQ_H_ghJZFFxg8@mail.gmail.com>
Hi Jason,
On Fri, Feb 18, 2011 at 05:22:09PM +0800, Jason Chen wrote:
> hi, Sasha,
>
> > + if (var->vmode & FB_VMODE_ODD_FLD_FIRST) /* PAL */
> > + sig_cfg.odd_field_first = 1;
> > + if (var->sync & FB_SYNC_EXT)
> > + sig_cfg.ext_clk = 1;
> > + if (var->sync & FB_SYNC_HOR_HIGH_ACT)
> > + sig_cfg.Hsync_pol = 1;
> Please remove FB_SYNC_EXT support.
No problem, can do. But why? Is it nonfunctional in the hardware
or is it that the current code just misses more pieces to support
this?
>
> +static void imx_ipu_fb_disable_overlay(struct fb_info *ovl)
> +{
> + struct imx_ipu_fb_info *mxc_ovl = ovl->par;
> +
> + if (!mxc_ovl->enabled)
> + return;
> +
> + ipu_dp_disable_fg(mxc_ovl->dp);
> + ipu_wait_for_interrupt(451, 100);
> + ipu_idmac_disable_channel(mxc_ovl->ipu_ch);
> + ipu_dmfc_disable_channel(mxc_ovl->dmfc);
> + mxc_ovl->enabled = 0;
> +}
> Had better has a definition of ipu irq 451.
Ok.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/7] Add a mfd IPUv3 driver
From: Sascha Hauer @ 2011-02-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871v36pm5r.fsf@lechat.rtp-net.org>
On Thu, Feb 17, 2011 at 07:10:24PM +0100, Arnaud Patard wrote:
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 6bafb51b..ffdb37a 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -26,6 +26,8 @@ source "drivers/gpu/drm/Kconfig"
> >
> > source "drivers/gpu/stub/Kconfig"
> >
> > +source "drivers/video/imx-ipu-v3/Kconfig"
> > +
>
> I don't see such a Kconfig file in this patch. Got lost while moving
> from mfd to video ?
Oops, yes still untracked in my repository. Will add in the next series.
>
>
> > config VGASTATE
> > tristate
> > default n
> > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > index 8c8fabd..f4921ab 100644
> > --- a/drivers/video/Makefile
> > +++ b/drivers/video/Makefile
> > @@ -153,6 +153,7 @@ obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> > obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
> > obj-$(CONFIG_FB_MX3) += mx3fb.o
> > obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> > +obj-$(CONFIG_MFD_IMX_IPU_V3) += imx-ipu-v3/
>
> Now that files are in drivers/video, do we want to keep MFD in the name ?
I asked myself the same question and had no clear answer. Probably
better to remove the MFD.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* RE: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
From: Kukjin Kim @ 2011-02-18 9:38 UTC (permalink / raw)
To: 'daeinki'
Cc: linux-samsung-soc, linux-fbdev, ben-linux, akpm, lethal,
'Jonghun Han', 'Sangbeom Kim'
In-Reply-To: <4D25666C.4060102@samsung.com>
daeinki wrote:
>
> >> I know we had a discussion about your patch below.
> >> after that, did you have some discussion about that?
> >> If not, Paul advised to use clkdev lookup.
> >>
> >> Please, refer to below mail.
> >>
> > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03448.html
> >
> > I think it's different with your approach even though the purpose is
> similar
> > and I know, Mr. Han explained about clock configurable by call.
>
> please, refer to below.
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03445.html
>
> for identify clock types("lcd" for bus clock or "fimd" for sclk_fimd),
> using switch-case seems to be bad. for avoiding this one I suggested
> other way and the way clock type selection from platform data is also
> bad so Paul adviced us to use clk_dev lookup.
>
I don't think that it's bad. As I said, it's just different with your approach.
Paul, could you please let me know your opinion for this?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
> > Paul, how do you think about this?
> >
> > Personally, if we want to support S5PV310 FIMD now, this patch is good to
> > support it and to us now.
> > Of course, I think, we can upgrade it later.
> >
> > Thanks.
> >
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
> >>> -----Original Message-----
> >>> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> >>> owner@vger.kernel.org] On Behalf Of Kukjin Kim
> >>> Sent: Tuesday, January 04, 2011 5:06 PM
> >>> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org
> >>> Cc: ben-linux@fluff.org; akpm@linux-foundation.org; lethal@linux-sh.org;
> >>> Jonghun Han; Sangbeom Kim; InKi Dae; Kukjin Kim
> >>> Subject: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
> >>>
> >>> From: Jonghun Han <jonghun.han@samsung.com>
> >>>
> >>> This patch adds struct s3c_fb_driverdata s3c_fb_data_s5pv310 for S5PV310
> >>> and S5PC210. The clk_type is added to distinguish clock type in it and
> >>> lcd_clk is added in structure s3c_fb to calculate divider for lcd panel.
> >>>
> >>> Please refer to below diagrams about clocks of FIMD IP. FIMD driver
> > needs
> >>> two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel
> > clock
> >>> can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before S5PV310. But
> > from
> >>> S5PV310, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
> >>>
> >>> FIMD_CLK_TYPE0:
> >>> ------------------------------------
> >>> dsys bus
> >>> ----------------+-------------------
> >>> |
> >>> |1.clk 'lcd'
> >>> |
> >>> | FIMD block
> >>> +---+-----------+
> >>> 4.mout_mpll |\ | | |
> >>> --------|m| | +-+-+ +----+ |
> >>> |u|-+ | | +-+core| |
> >>> |x| | | | +----+ |
> >>> |/ | | | |\ |
> >>> | | +-|m| +---+ |
> >>> | | |u|--+div| |
> >>> +------+---|x| +---+ |
> >>> 2.SCLK_FIMD | |/ | |
> >>> | | |
> >>> +----------+----+
> >>> |
> >>> inside of SoC |
> >>> -----------------------+--------------------------
> >>> outside of SoC |
> >>> | 3.LCD pixel clock
> >>> |
> >>> +--------------+
> >>> | LCD module |
> >>> +--------------+
> >>>
> >>> FIMD_CLK_TYPE1:
> >>> ------------------------------------
> >>> dsys bus
> >>> ----------------+-------------------
> >>> |
> >>> |1.clk 'fimd'
> >>> |
> >>> | FIMD block
> >>> +---+-----------+
> >>> 4.mout_mpll |\ | | |
> >>> --------|m| | | +----+ |
> >>> |u|-+ | +---+core| |
> >>> |x| | | +----+ |
> >>> |/ | | |
> >>> | | +---+ |
> >>> | | +--+div| |
> >>> +------+-----+ +---+ |
> >>> 2.SCLK_FIMD | | |
> >>> | | |
> >>> +----------+----+
> >>> |
> >>> inside of SoC |
> >>> -----------------------+--------------------------
> >>> outside of SoC |
> >>> | 3.LCD pixel clock
> >>> |
> >>> +--------------+
> >>> | LCD module |
> >>> +--------------+
> >>>
> >>> Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> >>> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
> >>> Cc: InKi Dae <inki.dae@samsung.com>
> >>> Cc: Ben Dooks <ben-linux@fluff.org>
> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> >>> ---
> >>> Hi Paul,
> >>>
> >>> I and Mr. Han, Jonghun sent below patch several weeks ago.
> >>> But I couldn't find it in your tree...
> >>> (Re-made against on your latest fbdev-2.6.git #master)
> >>>
> >>> I think this should be merged for supporting S5PV310/S5PC210 frame
> > buffer.
> >>> So could you please let me know your opinion or plan about this?
> >>>
> >>> NOTE: Needs following platform device patches for S5PV310/S5PC210 frame
> >>> buffer.
> >>> And I already applied that in my tree as S5P SoCs architecture
> > maintainer.
> >>> 0001-ARM-S5PV310-Add-FIMD-resource-definition.patch
> >>> 0002-ARM-S5PV310-Add-platform-device-and-helper-functio.patch
> >>> 0004-ARM-S5PV310-Add-support-FIMD0-and-LTE480WV-LCD-for.patch
> >>>
> >>> drivers/video/Kconfig | 2 +-
> >>> drivers/video/s3c-fb.c | 125
> >>> +++++++++++++++++++++++++++++++++++++++++++-----
> >>> 2 files changed, 113 insertions(+), 14 deletions(-)
> >
> >
^ 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