* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: David Miller @ 2011-02-16 23:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 16 Feb 2011 23:21:20 +0000
> On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> Just tested arkfb and s3fb and they seem to still work fine (on x86)
>> with these changes.
>
> Hmm, that's odd. The exact same driver with the updates crashes on sparc
> hardware. So far, I've not been able to figure out why it does.
We know why it does, because sparc systems do not initialize the VGA
hardware in the BIOS the way a PC will.
That's the whole gist of the most recent thread we had where we were
trying to diagnose your crashes.
We simply haven't figured out the magic that will get this to work.
So it's perfectly fine and expected that platforms where these drivers
worked before, still work fine.
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Alex Buell @ 2011-02-16 23:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
> > Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Just tested arkfb and s3fb and they seem to still work fine (on x86)
> with these changes.
Hmm, that's odd. The exact same driver with the updates crashes on sparc
hardware. So far, I've not been able to figure out why it does.
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Ondrej Zary @ 2011-02-16 23:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Wednesday 12 January 2011 00:48:46 David Miller wrote:
> This patch set makes sure that FB drivers for PCI devices utilizing
> the svgalib interfaces work on multi-domain PCI architectures.
>
> Basically this amounts to making sure that the vgastate->vgabase
> __iomem pointer makes it way into every interfaces and gets used
> by all of the I/O access calls.
>
> All of arkfb, s3fb, and vt8623fb have been converted.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Just tested arkfb and s3fb and they seem to still work fine (on x86) with
these changes.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Daniel Morsing @ 2011-02-16 19:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, Bryan Wu, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1297871886.14556.21.camel@deskari>
On Wed, 2011-02-16 at 17:58 +0200, Tomi Valkeinen wrote:
> On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:
> > On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:
>
> > > And I found:
> > >
> > > http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
> > >
> > > It looks like 24bpp display.
> > >
> >
> > Ok I looked through the datasheet and it looks to me that i got
> > the .config field right. Only thing that's vague from that sheet is
> > which pixel clock edge the v-sync and h-sync are driven low and the
> > color distortion is still there with either option.
> >
> > > What kind of color distortion do you see? Perhaps the problem is
> > > somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> > > signal setting in .config field. This info should be in the panel
> > > datasheet, but it usually takes some deciphering to understand it =).
> > >
> > > Tomi
> > >
> >
> > I'm seeing a light cyan tint to everything when running at 24bpp. Using
> > 16 datalines causes a heavy blue tint.
>
> But with 24 datalines and 16 bpp it works? Sounds strange =).
>
> One thing to check are the pinmuxings (or pad configuration, as it's
> called in omap3 trm).
>
> Are you using 2.6.37 or newer kernel?
>
> Is this also happening with other devkit8000 devices, so it's not just a
> broken device?
>
> Have you tried with an image with full red, green and blue areas, to see
> if only certain colors are affected?
>
> And the last option is of course get a scope and see what's going on in
> the datalines.
>
> Tomi
>
>
Ok I've done some more testing, the result being that I'm a bit of an
idiot.
The cyan tint only appears on console text. Running any sort of program
that actually used the display worked as intended. Setting the bpp as 16
actually made all the colors muted when you actually used the display,
so it is clearly the wrong "solution".
Since no one actually uses a hardware tty on a device like this, the
issue is kinda pointless. So I'm gonna resend the panel adding patch
without the bpp hack and with the correct name.
Regards,
Daniel Morsing
^ permalink raw reply
* Re: [PATCH 0/6] sisfb: XGI Z9 POST
From: Aaro Koskinen @ 2011-02-16 17:41 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
In-Reply-To: <1297635088-13224-1-git-send-email-aaro.koskinen@iki.fi>
Hi,
On Mon, 14 Feb 2011, Aaro Koskinen wrote:
> Here's some patches to get POST working with XGI Z9. I have tested them
> with the following card:
>
> http://www.roboard.com/Files/RB-100/MiniPCI-VGA-Z9s_UM_v1r1A.pdf
>
> I'm using the card on an ARM board where the bootloader knows nothing
> about VGA or VGA BIOS, so having POST support in the kernel driver
> is mandatory. With these patches the memory size is correct detected,
> R/W test passes and it's possible to use e.g. framebuffer console.
>
> Aaro Koskinen (6):
> sisfb: POST should fail if R/W test fails
> sisfb: move XGI POST RAM type detection into a subroutine
> sisfb: add subroutine for detecting XGI Z9
> sisfb: add RAM type detection for XGI Z9
> sisfb: move XGI POST DDR2 bootup code into subroutines
> sisfb: add support for XGI Z9 DDR2 POST
Hmm, I think these patches can be ignored, at least for a while.
I realized that xgifb driver is now in staging, and it has much wider
support for XGI chips. So, we should work on getting that driver into
an acceptable form. And after that, it should be even possible to drop
XGI support from sisfb.
A.
^ permalink raw reply
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Tomi Valkeinen @ 2011-02-16 15:58 UTC (permalink / raw)
To: Daniel Morsing
Cc: Tony Lindgren, Bryan Wu, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1297870958.8777.21.camel@morsing>
On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:
> On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:
> > And I found:
> >
> > http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
> >
> > It looks like 24bpp display.
> >
>
> Ok I looked through the datasheet and it looks to me that i got
> the .config field right. Only thing that's vague from that sheet is
> which pixel clock edge the v-sync and h-sync are driven low and the
> color distortion is still there with either option.
>
> > What kind of color distortion do you see? Perhaps the problem is
> > somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> > signal setting in .config field. This info should be in the panel
> > datasheet, but it usually takes some deciphering to understand it =).
> >
> > Tomi
> >
>
> I'm seeing a light cyan tint to everything when running at 24bpp. Using
> 16 datalines causes a heavy blue tint.
But with 24 datalines and 16 bpp it works? Sounds strange =).
One thing to check are the pinmuxings (or pad configuration, as it's
called in omap3 trm).
Are you using 2.6.37 or newer kernel?
Is this also happening with other devkit8000 devices, so it's not just a
broken device?
Have you tried with an image with full red, green and blue areas, to see
if only certain colors are affected?
And the last option is of course get a scope and see what's going on in
the datalines.
Tomi
^ permalink raw reply
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Daniel Morsing @ 2011-02-16 15:42 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, Bryan Wu, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1297866996.988.69.camel@deskari>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2195 bytes --]
On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:
> On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:
> > Hi Tomi
> >
> > On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> > > Hi,
> > >
> > > On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > > > The panel added is the 4.3 inch display that is sold with the
> > > > Devkit8000.
> > >
> > > Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> > > board file. Why do you want to use 16 bpp format for that?
> > >
> > > Tomi
> > >
> >
> > Running the panel at 24 bpp or specifying 16 datalines causes color
> > distortion.
> >
> > The only way I've been able to run the panel without color distortion,
> > is with 24 datalines and 16 bpp.
> >
> > I'm not well versed in displays, so I might be making a mistake
> > somewhere. The BSP for the devkit8000 doesn't include a datasheet for
> > the panel, so I can't look into what's causing this weirdness.
>
> I don't think I'll add a feature which doesn't make sense, to fix a
> problem we don't understand =).
>
> A datasheet I found mentions
>
> "One 4.3” TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
> Model)"
>
> And I found:
>
> http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
>
> It looks like 24bpp display.
>
Ok I looked through the datasheet and it looks to me that i got
the .config field right. Only thing that's vague from that sheet is
which pixel clock edge the v-sync and h-sync are driven low and the
color distortion is still there with either option.
> What kind of color distortion do you see? Perhaps the problem is
> somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> signal setting in .config field. This info should be in the panel
> datasheet, but it usually takes some deciphering to understand it =).
>
> Tomi
>
I'm seeing a light cyan tint to everything when running at 24bpp. Using
16 datalines causes a heavy blue tint.
Regards,
Daniel Morsing
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] omap3: devkit8000: Add and use 4.3 inch display
From: Thomas Weber @ 2011-02-16 14:42 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,
> };
> 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 */
> {
> {
can you try these settings.
I have these settings from other users of the 4.3 inch display.
I think only the pixel clock is a little bit slower.
//.name = "4.3inch_LCD",
.x_res = 480,
.y_res = 272,
.hsw = 41, /* hsync_len (4) - 1 */
.hfp = 2, /* right_margin (4) - 1 */
.hbp = 2, /* left_margin (40) - 1 */
.vsw = 10, /* vsync_len (2) - 1 */
.vfp = 2, /* lower_margin */
.vbp = 2, /* upper_margin (8) - 1 */
.pixel_clock = 9600,
Regards,
Thomas
^ permalink raw reply
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Tomi Valkeinen @ 2011-02-16 14:36 UTC (permalink / raw)
To: Daniel Morsing
Cc: Tony Lindgren, Bryan Wu, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1297865193.8777.8.camel@morsing>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1650 bytes --]
On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:
> Hi Tomi
>
> On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > > The panel added is the 4.3 inch display that is sold with the
> > > Devkit8000.
> >
> > Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> > board file. Why do you want to use 16 bpp format for that?
> >
> > Tomi
> >
>
> Running the panel at 24 bpp or specifying 16 datalines causes color
> distortion.
>
> The only way I've been able to run the panel without color distortion,
> is with 24 datalines and 16 bpp.
>
> I'm not well versed in displays, so I might be making a mistake
> somewhere. The BSP for the devkit8000 doesn't include a datasheet for
> the panel, so I can't look into what's causing this weirdness.
I don't think I'll add a feature which doesn't make sense, to fix a
problem we don't understand =).
A datasheet I found mentions
"One 4.3” TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
Model)"
And I found:
http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
It looks like 24bpp display.
What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/7] Add i.MX5 framebuffer driver
From: Sascha Hauer @ 2011-02-16 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297865452-32181-1-git-send-email-s.hauer@pengutronix.de>
This patch adds framebuffer support to the Freescale i.MX SoCs
equipped with an IPU v3, so far these are the i.MX51/53.
This driver has been tested on the i.MX51 babbage board with
both DVI and analog VGA in different resolutions and color depths.
It has also been tested on a custom i.MX51 board using a fixed
resolution panel.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/video/Kconfig | 11 +
drivers/video/Makefile | 1 +
drivers/video/mx5fb.c | 925 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 937 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mx5fb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ffdb37a..70f8490 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2344,6 +2344,17 @@ config FB_MX3
far only synchronous displays are supported. If you plan to use
an LCD display with your i.MX31 system, say Y here.
+config FB_MX5
+ tristate "MX5 Framebuffer support"
+ depends on FB && MFD_IMX_IPU_V3
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ help
+ This is a framebuffer device for the i.MX51 LCD Controller. If you
+ plan to use an LCD display with your i.MX51 system, say Y here.
+
config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
depends on FB
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index f4921ab..64f6913 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_FB_BFIN_LQ035Q1) += bfin-lq035q1-fb.o
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_MX5) += mx5fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
obj-$(CONFIG_MFD_IMX_IPU_V3) += imx-ipu-v3/
diff --git a/drivers/video/mx5fb.c b/drivers/video/mx5fb.c
new file mode 100644
index 0000000..af11f86
--- /dev/null
+++ b/drivers/video/mx5fb.c
@@ -0,0 +1,925 @@
+/*
+ * Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * Framebuffer Framebuffer Driver for SDC
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/dma-mapping.h>
+#include <linux/console.h>
+#include <linux/mfd/imx-ipu-v3.h>
+#include <asm/uaccess.h>
+#include <mach/ipu-v3.h>
+
+#define DRIVER_NAME "imx-ipuv3-fb"
+
+struct imx_ipu_fb_info {
+ int ipu_channel_num;
+ struct ipu_channel *ipu_ch;
+ int dc;
+ int di_no;
+ u32 ipu_di_pix_fmt;
+ u32 ipu_in_pix_fmt;
+
+ u32 pseudo_palette[16];
+
+ struct ipu_dp *dp;
+ struct dmfc_channel *dmfc;
+ struct ipu_di *di;
+ struct fb_info *slave;
+ struct fb_info *master;
+ bool enabled;
+
+ /* overlay specific fields */
+ int ovlxres, ovlyres;
+ int usage;
+};
+
+static int imx_ipu_fb_set_fix(struct fb_info *info)
+{
+ struct fb_fix_screeninfo *fix = &info->fix;
+ struct fb_var_screeninfo *var = &info->var;
+
+ fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+
+ fix->type = FB_TYPE_PACKED_PIXELS;
+ fix->accel = FB_ACCEL_NONE;
+ fix->visual = FB_VISUAL_TRUECOLOR;
+ fix->xpanstep = 1;
+ fix->ypanstep = 1;
+
+ return 0;
+}
+
+static int imx_ipu_fb_map_video_memory(struct fb_info *fbi)
+{
+ int size;
+
+ size = fbi->var.yres_virtual * fbi->fix.line_length;
+
+ if (fbi->screen_base) {
+ if (fbi->fix.smem_len >= size)
+ return 0;
+ else
+ return -ENOMEM;
+ }
+
+ fbi->screen_base = dma_alloc_writecombine(fbi->device,
+ size,
+ (dma_addr_t *)&fbi->fix.smem_start,
+ GFP_DMA);
+ if (fbi->screen_base = 0) {
+ dev_err(fbi->device, "Unable to allocate framebuffer memory (%d)\n",
+ fbi->fix.smem_len);
+ fbi->fix.smem_len = 0;
+ fbi->fix.smem_start = 0;
+ return -ENOMEM;
+ }
+
+ fbi->fix.smem_len = size;
+ fbi->screen_size = fbi->fix.smem_len;
+
+ dev_dbg(fbi->device, "allocated fb @ paddr=0x%08lx, size=%d\n",
+ fbi->fix.smem_start, fbi->fix.smem_len);
+
+ /* Clear the screen */
+ memset((char *)fbi->screen_base, 0, fbi->fix.smem_len);
+
+ return 0;
+}
+
+static void imx_ipu_fb_enable(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ if (mxc_fbi->enabled)
+ return;
+
+ ipu_di_enable(mxc_fbi->di);
+ ipu_dmfc_enable_channel(mxc_fbi->dmfc);
+ ipu_idmac_enable_channel(mxc_fbi->ipu_ch);
+ ipu_dc_enable_channel(mxc_fbi->dc);
+ ipu_dp_enable_channel(mxc_fbi->dp);
+ mxc_fbi->enabled = 1;
+}
+
+static void imx_ipu_fb_disable(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ if (!mxc_fbi->enabled)
+ return;
+
+ ipu_dp_disable_channel(mxc_fbi->dp);
+ ipu_dc_disable_channel(mxc_fbi->dc);
+ ipu_idmac_disable_channel(mxc_fbi->ipu_ch);
+ ipu_dmfc_disable_channel(mxc_fbi->dmfc);
+ ipu_di_disable(mxc_fbi->di);
+
+ mxc_fbi->enabled = 0;
+}
+
+static int calc_vref(struct fb_var_screeninfo *var)
+{
+ unsigned long htotal, vtotal;
+
+ htotal = var->xres + var->right_margin + var->hsync_len + var->left_margin;
+ vtotal = var->yres + var->lower_margin + var->vsync_len + var->upper_margin;
+
+ if (!htotal || !vtotal)
+ return 60;
+
+ return PICOS2KHZ(var->pixclock) * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct fb_var_screeninfo *var, unsigned int vref)
+{
+ return var->xres * var->yres * vref;
+}
+
+static int imx_ipu_fb_set_par(struct fb_info *fbi)
+{
+ int ret;
+ struct ipu_di_signal_cfg sig_cfg;
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+ u32 out_pixel_fmt;
+ int interlaced = 0;
+ struct fb_var_screeninfo *var = &fbi->var;
+ int enabled = mxc_fbi->enabled;
+
+ dev_dbg(fbi->device, "Reconfiguring framebuffer %dx%d-%d\n",
+ fbi->var.xres, fbi->var.yres, fbi->var.bits_per_pixel);
+
+ if (enabled)
+ imx_ipu_fb_disable(fbi);
+
+ fbi->fix.line_length = var->xres_virtual * var->bits_per_pixel / 8;
+
+ ret = imx_ipu_fb_map_video_memory(fbi);
+ if (ret)
+ return ret;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ memset(&sig_cfg, 0, sizeof(sig_cfg));
+ out_pixel_fmt = mxc_fbi->ipu_di_pix_fmt;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ sig_cfg.interlaced = 1;
+ 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;
+ if (var->sync & FB_SYNC_VERT_HIGH_ACT)
+ sig_cfg.Vsync_pol = 1;
+ if (!(var->sync & FB_SYNC_CLK_LAT_FALL))
+ sig_cfg.clk_pol = 1;
+ if (var->sync & FB_SYNC_DATA_INVERT)
+ sig_cfg.data_pol = 1;
+ if (!(var->sync & FB_SYNC_OE_LOW_ACT))
+ sig_cfg.enable_pol = 1;
+ if (var->sync & FB_SYNC_CLK_IDLE_EN)
+ sig_cfg.clkidle_en = 1;
+
+ dev_dbg(fbi->device, "pixclock = %lu.%03lu MHz\n",
+ PICOS2KHZ(var->pixclock) / 1000,
+ PICOS2KHZ(var->pixclock) % 1000);
+
+ sig_cfg.width = var->xres;
+ sig_cfg.height = var->yres;
+ sig_cfg.pixel_fmt = out_pixel_fmt;
+ sig_cfg.h_start_width = var->left_margin;
+ sig_cfg.h_sync_width = var->hsync_len;
+ sig_cfg.h_end_width = var->right_margin;
+ sig_cfg.v_start_width = var->upper_margin;
+ sig_cfg.v_sync_width = var->vsync_len;
+ sig_cfg.v_end_width = var->lower_margin;
+ sig_cfg.v_to_h_sync = 0;
+
+ if (mxc_fbi->dp) {
+ ret = ipu_dp_setup_channel(mxc_fbi->dp, mxc_fbi->ipu_in_pix_fmt,
+ out_pixel_fmt, 1);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing display processor failed with %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ ret = ipu_dc_init_sync(mxc_fbi->dc, mxc_fbi->di_no, interlaced,
+ out_pixel_fmt, fbi->var.xres);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing display controller failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_di_init_sync_panel(mxc_fbi->di,
+ PICOS2KHZ(var->pixclock) * 1000UL,
+ &sig_cfg);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing panel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ fbi->mode = (struct fb_videomode *)fb_match_mode(var, &fbi->modelist);
+ var->xoffset = var->yoffset = 0;
+
+ if (fbi->var.vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ ret = ipu_idmac_init_channel_buffer(mxc_fbi->ipu_ch,
+ mxc_fbi->ipu_in_pix_fmt,
+ var->xres, var->yres,
+ fbi->fix.line_length,
+ IPU_ROTATE_NONE,
+ fbi->fix.smem_start,
+ 0,
+ 0, 0, interlaced);
+ if (ret) {
+ dev_dbg(fbi->device, "init channel buffer failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_init_channel(mxc_fbi->dmfc, var->xres);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing dmfc channel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_alloc_bandwidth(mxc_fbi->dmfc, calc_bandwidth(var, calc_vref(var)));
+ if (ret) {
+ dev_dbg(fbi->device, "allocating dmfc bandwidth failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ if (enabled)
+ imx_ipu_fb_enable(fbi);
+
+ return ret;
+}
+
+/*
+ * These are the bitfields for each
+ * display depth that we support.
+ */
+struct imxfb_rgb {
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp;
+};
+
+static struct imxfb_rgb def_rgb_8 = {
+ .red = { .offset = 5, .length = 3, },
+ .green = { .offset = 2, .length = 3, },
+ .blue = { .offset = 0, .length = 2, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_16 = {
+ .red = { .offset = 11, .length = 5, },
+ .green = { .offset = 5, .length = 6, },
+ .blue = { .offset = 0, .length = 5, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_24 = {
+ .red = { .offset = 16, .length = 8, },
+ .green = { .offset = 8, .length = 8, },
+ .blue = { .offset = 0, .length = 8, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_32 = {
+ .red = { .offset = 16, .length = 8, },
+ .green = { .offset = 8, .length = 8, },
+ .blue = { .offset = 0, .length = 8, },
+ .transp = { .offset = 24, .length = 8, },
+};
+
+/*
+ * Check framebuffer variable parameters and adjust to valid values.
+ *
+ * @param var framebuffer variable parameters
+ *
+ * @param info framebuffer information pointer
+ */
+static int imx_ipu_fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ struct imx_ipu_fb_info *mxc_fbi = info->par;
+ struct imxfb_rgb *rgb;
+
+ /* we don't support xpan, force xres_virtual to be equal to xres */
+ var->xres_virtual = var->xres;
+
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
+ switch (var->bits_per_pixel) {
+ case 8:
+ rgb = &def_rgb_8;
+ break;
+ case 16:
+ rgb = &def_rgb_16;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_RGB565;
+ break;
+ case 24:
+ rgb = &def_rgb_24;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
+ break;
+ case 32:
+ rgb = &def_rgb_32;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR32;
+ break;
+ default:
+ var->bits_per_pixel = 24;
+ rgb = &def_rgb_24;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
+ }
+
+ var->red = rgb->red;
+ var->green = rgb->green;
+ var->blue = rgb->blue;
+ var->transp = rgb->transp;
+
+ return 0;
+}
+
+static inline unsigned int chan_to_field(u_int chan, struct fb_bitfield *bf)
+{
+ chan &= 0xffff;
+ chan >>= 16 - bf->length;
+ return chan << bf->offset;
+}
+
+static int imx_ipu_fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+ u_int trans, struct fb_info *fbi)
+{
+ unsigned int val;
+ int ret = 1;
+
+ /*
+ * If greyscale is true, then we convert the RGB value
+ * to greyscale no matter what visual we are using.
+ */
+ if (fbi->var.grayscale)
+ red = green = blue = (19595 * red + 38470 * green +
+ 7471 * blue) >> 16;
+ switch (fbi->fix.visual) {
+ case FB_VISUAL_TRUECOLOR:
+ /*
+ * 16-bit True Colour. We encode the RGB value
+ * according to the RGB bitfield information.
+ */
+ if (regno < 16) {
+ u32 *pal = fbi->pseudo_palette;
+
+ val = chan_to_field(red, &fbi->var.red);
+ val |= chan_to_field(green, &fbi->var.green);
+ val |= chan_to_field(blue, &fbi->var.blue);
+
+ pal[regno] = val;
+ ret = 0;
+ }
+ break;
+
+ case FB_VISUAL_STATIC_PSEUDOCOLOR:
+ case FB_VISUAL_PSEUDOCOLOR:
+ break;
+ }
+
+ return ret;
+}
+
+static void imx_ipu_fb_enable_overlay(struct fb_info *fbi);
+static void imx_ipu_fb_disable_overlay(struct fb_info *fbi);
+
+static int imx_ipu_fb_blank(int blank, struct fb_info *info)
+{
+ struct imx_ipu_fb_info *mxc_fbi = info->par;
+
+ dev_dbg(info->device, "blank = %d\n", blank);
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ if (mxc_fbi->slave)
+ imx_ipu_fb_disable_overlay(mxc_fbi->slave);
+ imx_ipu_fb_disable(info);
+ break;
+ case FB_BLANK_UNBLANK:
+ imx_ipu_fb_enable(info);
+ if (mxc_fbi->slave)
+ imx_ipu_fb_enable_overlay(mxc_fbi->slave);
+ break;
+ }
+
+ return 0;
+}
+
+static int imx_ipu_fb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ struct imx_ipu_fb_info *mxc_fbi = info->par;
+ unsigned long base;
+ int ret;
+
+ if (info->var.yoffset = var->yoffset)
+ return 0; /* No change, do nothing */
+
+ base = var->yoffset * var->xres_virtual * var->bits_per_pixel / 8;
+ base += info->fix.smem_start;
+
+ ret = ipu_wait_for_interrupt(IPU_IRQ_EOF(mxc_fbi->ipu_channel_num), 100);
+ if (ret)
+ return ret;
+
+ if (ipu_idmac_update_channel_buffer(mxc_fbi->ipu_ch, 0, base)) {
+ dev_err(info->device,
+ "Error updating SDC buf to address=0x%08lX\n", base);
+ }
+
+ info->var.yoffset = var->yoffset;
+
+ return 0;
+}
+
+static struct fb_ops imx_ipu_fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_set_par = imx_ipu_fb_set_par,
+ .fb_check_var = imx_ipu_fb_check_var,
+ .fb_setcolreg = imx_ipu_fb_setcolreg,
+ .fb_pan_display = imx_ipu_fb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_blank = imx_ipu_fb_blank,
+};
+
+/*
+ * Overlay functions
+ */
+static void imx_ipu_fb_enable_overlay(struct fb_info *ovl)
+{
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+
+ if (mxc_ovl->enabled)
+ return;
+
+ ipu_dmfc_enable_channel(mxc_ovl->dmfc);
+ ipu_idmac_enable_channel(mxc_ovl->ipu_ch);
+ ipu_dp_enable_fg(mxc_ovl->dp);
+ mxc_ovl->enabled = 1;
+}
+
+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;
+}
+
+#define NONSTD_TO_XPOS(x) (((x) >> 0) & 0xfff)
+#define NONSTD_TO_YPOS(x) (((x) >> 12) & 0xfff)
+#define NONSTD_TO_ALPHA(x) (((x) >> 24) & 0xff)
+
+static int imx_ipu_fb_check_var_overlay(struct fb_var_screeninfo *var,
+ struct fb_info *ovl)
+{
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+ struct fb_info *fbi_master = mxc_ovl->master;
+ struct fb_var_screeninfo *var_master = &fbi_master->var;
+ int ret;
+ static int xpos, ypos;
+
+ xpos = NONSTD_TO_XPOS(var->nonstd);
+ ypos = NONSTD_TO_YPOS(var->nonstd);
+
+ ret = imx_ipu_fb_check_var(var, ovl);
+ if (ret)
+ return ret;
+
+ if (var->xres + xpos > var_master->xres)
+ return -EINVAL;
+ if (var->yres + ypos > var_master->yres)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int imx_ipu_fb_set_par_overlay(struct fb_info *ovl)
+{
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+ struct fb_var_screeninfo *var = &ovl->var;
+ struct fb_info *fbi_master = mxc_ovl->master;
+ struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
+ struct fb_var_screeninfo *var_master = &fbi_master->var;
+ int ret;
+ int interlaced = 0;
+ int xpos, ypos, alpha;
+ int resolution_change;
+
+ dev_dbg(ovl->device, "Reconfiguring framebuffer %dx%d-%d\n",
+ ovl->var.xres, ovl->var.yres, ovl->var.bits_per_pixel);
+
+ resolution_change = mxc_ovl->ovlxres != var->xres ||
+ mxc_ovl->ovlyres != var->yres;
+
+ if (mxc_ovl->enabled && resolution_change)
+ imx_ipu_fb_disable_overlay(ovl);
+
+ ovl->fix.line_length = var->xres_virtual *
+ var->bits_per_pixel / 8;
+
+ xpos = NONSTD_TO_XPOS(var->nonstd);
+ ypos = NONSTD_TO_YPOS(var->nonstd);
+ alpha = NONSTD_TO_ALPHA(var->nonstd);
+
+ if (resolution_change) {
+ ret = imx_ipu_fb_map_video_memory(ovl);
+ if (ret)
+ return ret;
+ }
+
+ if (!resolution_change && mxc_ovl->enabled)
+ ipu_wait_for_interrupt(IPU_IRQ_EOF(mxc_fbi_master->ipu_channel_num), 100);
+
+ ipu_dp_set_window_pos(mxc_ovl->dp, xpos, ypos);
+ ipu_dp_set_global_alpha(mxc_ovl->dp, 1, alpha, 1);
+
+ var->xoffset = var->yoffset = 0;
+
+ if (resolution_change) {
+ if (var->vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ ret = ipu_idmac_init_channel_buffer(mxc_ovl->ipu_ch,
+ mxc_ovl->ipu_in_pix_fmt,
+ var->xres, var->yres,
+ ovl->fix.line_length,
+ IPU_ROTATE_NONE,
+ ovl->fix.smem_start,
+ 0,
+ 0, 0, interlaced);
+ if (ret) {
+ dev_dbg(ovl->device, "init channel buffer failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_init_channel(mxc_ovl->dmfc, var->xres);
+ if (ret) {
+ dev_dbg(ovl->device, "initializing dmfc channel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_alloc_bandwidth(mxc_ovl->dmfc, calc_bandwidth(var, calc_vref(var_master)));
+ if (ret) {
+ dev_dbg(ovl->device, "allocating dmfc bandwidth failed with %d\n",
+ ret);
+ return ret;
+ }
+ mxc_ovl->ovlxres = var->xres;
+ mxc_ovl->ovlyres = var->yres;
+ }
+
+ if (mxc_fbi_master->enabled)
+ imx_ipu_fb_enable_overlay(ovl);
+
+ return ret;
+}
+
+static int imx_overlayfb_open(struct fb_info *ovl, int user)
+{
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+
+ if (mxc_ovl->usage++ = 0)
+ printk("enable ovl\n");
+
+ return 0;
+}
+
+static int imx_overlayfb_release(struct fb_info *ovl, int user)
+{
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+
+ if (--mxc_ovl->usage = 0) {
+ printk("disable ovl\n");
+
+ if (ovl->screen_base)
+ dma_free_writecombine(ovl->device, ovl->fix.smem_len,
+ ovl->screen_base, ovl->fix.smem_start);
+ ovl->fix.smem_len = 0;
+ ovl->fix.smem_start = 0;
+ ovl->screen_base = NULL;
+ mxc_ovl->ovlxres = 0;
+ mxc_ovl->ovlyres = 0;
+ }
+
+ return 0;
+}
+
+static struct fb_ops imx_ipu_fb_overlay_ops = {
+ .owner = THIS_MODULE,
+ .fb_set_par = imx_ipu_fb_set_par_overlay,
+ .fb_check_var = imx_ipu_fb_check_var_overlay,
+ .fb_setcolreg = imx_ipu_fb_setcolreg,
+ .fb_pan_display = imx_ipu_fb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_open = imx_overlayfb_open,
+ .fb_release = imx_overlayfb_release,
+};
+
+static struct fb_info *imx_ipu_fb_init_fbinfo(struct device *dev, struct fb_ops *ops)
+{
+ struct fb_info *fbi;
+ struct imx_ipu_fb_info *mxc_fbi;
+
+ fbi = framebuffer_alloc(sizeof(struct imx_ipu_fb_info), dev);
+ if (!fbi)
+ return NULL;
+
+ BUG_ON(fbi->par = NULL);
+ mxc_fbi = fbi->par;
+
+ fbi->var.activate = FB_ACTIVATE_NOW;
+
+ fbi->fbops = ops;
+ fbi->flags = FBINFO_FLAG_DEFAULT;
+ fbi->pseudo_palette = mxc_fbi->pseudo_palette;
+
+ fb_alloc_cmap(&fbi->cmap, 16, 0);
+
+ return fbi;
+}
+
+static int imx_ipu_fb_init_overlay(struct platform_device *pdev,
+ struct fb_info *fbi_master, int ipu_channel)
+{
+ struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
+ struct fb_info *ovl;
+ struct imx_ipu_fb_info *mxc_ovl;
+ int ret;
+
+ ovl = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_overlay_ops);
+ if (!ovl)
+ return -ENOMEM;
+
+ mxc_ovl = ovl->par;
+ mxc_ovl->ipu_ch = ipu_idmac_get(ipu_channel);
+ mxc_ovl->dmfc = ipu_dmfc_get(ipu_channel);
+ mxc_ovl->di = NULL;
+ mxc_ovl->dp = mxc_fbi_master->dp;
+ mxc_ovl->master = fbi_master;
+ mxc_fbi_master->slave = ovl;
+
+ imx_ipu_fb_check_var(&ovl->var, ovl);
+ imx_ipu_fb_set_fix(ovl);
+
+ ret = register_framebuffer(ovl);
+ if (ret) {
+ framebuffer_release(ovl);
+ return ret;
+ }
+
+ ipu_dp_set_global_alpha(mxc_ovl->dp, 0, 0, 1);
+ ipu_dp_set_color_key(mxc_ovl->dp, 1, 0x434343);
+
+ return 0;
+}
+
+static void imx_ipu_fb_exit_overlay(struct platform_device *pdev,
+ struct fb_info *fbi_master, int ipu_channel)
+{
+ struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
+ struct fb_info *ovl = mxc_fbi_master->slave;
+ struct imx_ipu_fb_info *mxc_ovl = ovl->par;
+
+ if (mxc_ovl->enabled)
+ imx_ipu_fb_disable_overlay(ovl);
+
+ unregister_framebuffer(ovl);
+
+ ipu_idmac_put(mxc_ovl->ipu_ch);
+ ipu_dmfc_free_bandwidth(mxc_ovl->dmfc);
+ ipu_dmfc_put(mxc_ovl->dmfc);
+
+ framebuffer_release(ovl);
+}
+
+static int imx_ipu_fb_find_mode(struct fb_info *fbi)
+{
+ int ret;
+ struct fb_videomode *mode_array;
+ struct fb_modelist *modelist;
+ struct fb_var_screeninfo *var = &fbi->var;
+ int i = 0;
+
+ list_for_each_entry(modelist, &fbi->modelist, list)
+ i++;
+
+ mode_array = kmalloc(sizeof (struct fb_modelist) * i, GFP_KERNEL);
+ if (!mode_array)
+ return -ENOMEM;
+
+ i = 0;
+ list_for_each_entry(modelist, &fbi->modelist, list)
+ mode_array[i++] = modelist->mode;
+
+ ret = fb_find_mode(&fbi->var, fbi, NULL, mode_array, i, NULL, 16);
+ if (ret = 0)
+ return -EINVAL;
+
+ dev_dbg(fbi->device, "found %dx%d-%d hs:%d:%d:%d vs:%d:%d:%d\n",
+ var->xres, var->yres, var->bits_per_pixel,
+ var->hsync_len, var->left_margin, var->right_margin,
+ var->vsync_len, var->upper_margin, var->lower_margin);
+
+ kfree(mode_array);
+
+ return 0;
+}
+
+static int __devinit imx_ipu_fb_probe(struct platform_device *pdev)
+{
+ struct fb_info *fbi;
+ struct imx_ipu_fb_info *mxc_fbi;
+ struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
+ int ret = 0, i;
+
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+ fbi = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_ops);
+ if (!fbi)
+ return -ENOMEM;
+
+ mxc_fbi = fbi->par;
+
+ mxc_fbi->ipu_channel_num = plat_data->ipu_channel_bg;
+ mxc_fbi->dc = plat_data->dc_channel;
+ mxc_fbi->ipu_di_pix_fmt = plat_data->interface_pix_fmt;
+ mxc_fbi->di_no = plat_data->display;
+
+ mxc_fbi->ipu_ch = ipu_idmac_get(plat_data->ipu_channel_bg);
+ if (IS_ERR(mxc_fbi->ipu_ch)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_ipu;
+ }
+
+ mxc_fbi->dmfc = ipu_dmfc_get(plat_data->ipu_channel_bg);
+ if (IS_ERR(mxc_fbi->ipu_ch)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_dmfc;
+ }
+
+ if (plat_data->dp_channel >= 0) {
+ mxc_fbi->dp = ipu_dp_get(plat_data->dp_channel);
+ if (IS_ERR(mxc_fbi->dp)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_dp;
+ }
+ }
+
+ mxc_fbi->di = ipu_di_get(plat_data->display);
+ if (IS_ERR(mxc_fbi->di)) {
+ ret = PTR_ERR(mxc_fbi->di);
+ goto failed_request_di;
+ }
+
+ fbi->var.yres_virtual = fbi->var.yres;
+
+ INIT_LIST_HEAD(&fbi->modelist);
+ for (i = 0; i < plat_data->num_modes; i++)
+ fb_add_videomode(&plat_data->modes[i], &fbi->modelist);
+
+ if (plat_data->flags & IMX_IPU_FB_USE_MODEDB) {
+ for (i = 0; i < num_fb_modes; i++)
+ fb_add_videomode(&fb_modes[i], &fbi->modelist);
+ }
+
+ imx_ipu_fb_find_mode(fbi);
+
+ imx_ipu_fb_check_var(&fbi->var, fbi);
+ imx_ipu_fb_set_fix(fbi);
+ ret = register_framebuffer(fbi);
+ if (ret < 0)
+ goto failed_register;
+
+ imx_ipu_fb_set_par(fbi);
+ imx_ipu_fb_blank(FB_BLANK_UNBLANK, fbi);
+
+ if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
+ imx_ipu_fb_init_overlay(pdev, fbi, plat_data->ipu_channel_fg);
+
+ platform_set_drvdata(pdev, fbi);
+
+ return 0;
+
+failed_register:
+ ipu_di_put(mxc_fbi->di);
+failed_request_di:
+ if (plat_data->dp_channel >= 0)
+ ipu_dp_put(mxc_fbi->dp);
+failed_request_dp:
+ ipu_dmfc_put(mxc_fbi->dmfc);
+failed_request_dmfc:
+ ipu_idmac_put(mxc_fbi->ipu_ch);
+failed_request_ipu:
+ fb_dealloc_cmap(&fbi->cmap);
+ framebuffer_release(fbi);
+
+ return ret;
+}
+
+static int __devexit imx_ipu_fb_remove(struct platform_device *pdev)
+{
+ struct fb_info *fbi = platform_get_drvdata(pdev);
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+ struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
+
+ if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
+ imx_ipu_fb_exit_overlay(pdev, fbi, plat_data->ipu_channel_fg);
+
+ imx_ipu_fb_blank(FB_BLANK_POWERDOWN, fbi);
+
+ dma_free_writecombine(fbi->device, fbi->fix.smem_len,
+ fbi->screen_base, fbi->fix.smem_start);
+
+ if (&fbi->cmap)
+ fb_dealloc_cmap(&fbi->cmap);
+
+ unregister_framebuffer(fbi);
+
+ if (plat_data->dp_channel >= 0)
+ ipu_dp_put(mxc_fbi->dp);
+ ipu_dmfc_free_bandwidth(mxc_fbi->dmfc);
+ ipu_dmfc_put(mxc_fbi->dmfc);
+ ipu_di_put(mxc_fbi->di);
+ ipu_idmac_put(mxc_fbi->ipu_ch);
+
+ framebuffer_release(fbi);
+
+ return 0;
+}
+
+static struct platform_driver imx_ipu_fb_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ },
+ .probe = imx_ipu_fb_probe,
+ .remove = __devexit_p(imx_ipu_fb_remove),
+};
+
+static int __init imx_ipu_fb_init(void)
+{
+ return platform_driver_register(&imx_ipu_fb_driver);
+}
+
+static void __exit imx_ipu_fb_exit(void)
+{
+ platform_driver_unregister(&imx_ipu_fb_driver);
+}
+
+module_init(imx_ipu_fb_init);
+module_exit(imx_ipu_fb_exit);
+
+MODULE_AUTHOR("Freescale Semiconductor, Inc.");
+MODULE_DESCRIPTION("i.MX framebuffer driver");
+MODULE_LICENSE("GPL");
+MODULE_SUPPORTED_DEVICE("fb");
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/7] fb: export fb mode db table
From: Sascha Hauer @ 2011-02-16 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297865452-32181-1-git-send-email-s.hauer@pengutronix.de>
The different modes can be useful for drivers. Currently there is
no way to expose the modes to sysfs, so export them.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: Paul Mundt <lethal@linux-sh.org>
---
drivers/video/modedb.c | 8 ++++++--
include/linux/fb.h | 3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 48c3ea8..942b44d 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -36,8 +36,7 @@ EXPORT_SYMBOL_GPL(fb_mode_option);
* Standard video mode definitions (taken from XFree86)
*/
-static const struct fb_videomode modedb[] = {
-
+const struct fb_videomode modedb[] = {
/* 640x400 @ 70 Hz, 31.5 kHz hsync */
{ NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2, 0,
FB_VMODE_NONINTERLACED },
@@ -291,6 +290,11 @@ static const struct fb_videomode modedb[] = {
0, FB_VMODE_NONINTERLACED },
};
+const struct fb_videomode *fb_modes = modedb;
+EXPORT_SYMBOL(fb_modes);
+const int num_fb_modes = ARRAY_SIZE(modedb);
+EXPORT_SYMBOL(num_fb_modes);
+
#ifdef CONFIG_FB_MODE_HELPERS
const struct fb_videomode cea_modes[64] = {
/* #1: 640x480p@59.94/60Hz */
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 68ba85a..41b0ce1 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -1154,6 +1154,9 @@ extern const char *fb_mode_option;
extern const struct fb_videomode vesa_modes[];
extern const struct fb_videomode cea_modes[64];
+extern const struct fb_videomode *fb_modes;
+extern const int num_fb_modes;
+
struct fb_modelist {
struct list_head list;
struct fb_videomode mode;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Daniel Morsing @ 2011-02-16 14:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, Bryan Wu, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1297861914.988.1.camel@deskari>
Hi Tomi
On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> Hi,
>
> On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > The panel added is the 4.3 inch display that is sold with the
> > Devkit8000.
>
> Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> board file. Why do you want to use 16 bpp format for that?
>
> Tomi
>
Running the panel at 24 bpp or specifying 16 datalines causes color
distortion.
The only way I've been able to run the panel without color distortion,
is with 24 datalines and 16 bpp.
I'm not well versed in displays, so I might be making a mistake
somewhere. The BSP for the devkit8000 doesn't include a datasheet for
the panel, so I can't look into what's causing this weirdness.
Regards,
Daniel Morsing
^ permalink raw reply
* Re: [PATCH] mx3fb: Fix parameter to sdc_init_panel
From: Guennadi Liakhovetski @ 2011-02-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102141306.43739.alexander.stein@systec-electronic.com>
On Mon, 14 Feb 2011, Alexander Stein wrote:
> On Monday 14 February 2011, 08:57:04 Guennadi Liakhovetski wrote:
> > On Mon, 14 Feb 2011, Alexander Stein wrote:
> > > On Thursday 10 February 2011, 14:01:17 Alexander Stein wrote:
> > > > On Thursday 10 February 2011, 13:48:23 Guennadi Liakhovetski wrote:
> > > > > > I don't know which display you used, but I guess your right_margin
> > > > > > (and lower_margin) needs to be adjusted.
> > > > >
> > > > > Ok, agree. But then you need to adjust all current users and have
> > > > > them tested... Otherwise, of course, you can just adjust your
> > > > > platform panel data to work with the current calculations, even
> > > > > though in principle your patch seems to be doing the right thing
> > > > > (tm), according to the manual. But if applied as is without fixing
> > > > > all the users, it can very well break them...
> > > >
> > > > Ok, I've just seen there are some model defines in mx3fb.c which would
> > > > also be affected.
> > > > I'll try to find all mx3fb users and fix their videomodes and repost a
> > > > new patch.
> > >
> > > Uh, this seems next to impossible for me to handle it my own. I checked
> > > some users of the mx3fb but I cant say which ones will be affected and
> > > which ones not (e.g. without any hsync/vsync, on data enable).
> > > I've not idea how to fix it then.
> >
> > Well, you can, of course, adjust parameters for your platform to be able
> > to run with this incorrect parameter definition...
>
> This is just an ugly work-around. Depending on the settings you may even get
> an overflow resulting in a not-working display at all.
Sure, I know, that this is a work-around. But I don't see options apart
from
1. fix the driver and maybe a couple of platforms, that we have at hand
and hope, that others will fix theirs or shout loud enough, when they
discover, that their platforms are broken
2. fix the driver and all users and try to get as many of them as we can
to test our fixes
3. leave the driver and work around the bug in all new platforms
Choose your poison;)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi
From: Tomi Valkeinen @ 2011-02-16 13:11 UTC (permalink / raw)
To: Daniel Morsing
Cc: Tony Lindgren, Tomi Valkeinen, Bryan Wu,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1297530130-10355-1-git-send-email-daniel.morsing@gmail.com>
Hi,
On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> This series adds a mechanism for specifying a recommended bpp for
> generic dss2 dpi panels and adds a panel that uses this feature.
>
> The panel added is the 4.3 inch display that is sold with the
> Devkit8000.
Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?
Tomi
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Arnd Bergmann @ 2011-02-16 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikhcphz_8TS4L+z2heayqnJbK1NEW8DzqTm=YKp@mail.gmail.com>
On Tuesday 15 February 2011, Clark, Rob wrote:
> I'd been experimenting a bit on the side w/ the DRM driver framework (
> http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
> ), but had to add a good chunk of mostly boilerplate code to our xorg
> driver in order just to test it. Maybe some generic support for KMS
> in xf86-video-fbdev would have made this easier to develop the kernel
> part without in parallel having to implement the userspace part. I'm
> not sure if this is the sort of thing the linaro-wg has in mind?
I'm not sure what the the linaro multimedia wg thinks of this, but the
kernel code you linked looks like it's doing exactly the right thing.
Arnd
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-16 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297850199-1688-1-git-send-email-s.hauer@pengutronix.de>
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
+
+#define LCDC_CTRL 0x00
+#define LCDC_CTRL1 0x10
+#define LCDC_MX28_CTRL2 0x20
+#define LCDC_MX23_TRANSFER_COUNT 0x20
+#define LCDC_MX28_TRANSFER_COUNT 0x30
+#define LCDC_MX28_CUR_BUF 0x40
+#define LCDC_MX28_NEXT_BUF 0x50
+#define LCDC_MX23_CUR_BUF 0x30
+#define LCDC_MX23_NEXT_BUF 0x40
+#define LCDC_TIMING 0x60
+#define LCDC_VDCTRL0 0x70
+#define LCDC_VDCTRL1 0x80
+#define LCDC_VDCTRL2 0x90
+#define LCDC_VDCTRL3 0xa0
+#define LCDC_VDCTRL4 0xb0
+#define LCDC_DVICTRL0 0xc0
+#define LCDC_DVICTRL1 0xd0
+#define LCDC_DVICTRL2 0xe0
+#define LCDC_DVICTRL3 0xf0
+#define LCDC_DVICTRL4 0x100
+#define LCDC_MX28_DATA 0x180
+#define LCDC_MX23_DATA 0x1b0
+#define LCDC_MX28_DEBUG0 0x1d0
+#define LCDC_MX23_DEBUG0 0x1f0
+
+#define CTRL_SFTRST (1 << 31)
+#define CTRL_CLKGATE (1 << 30)
+#define CTRL_BYPASS_COUNT (1 << 19)
+#define CTRL_VSYNC_MODE (1 << 18)
+#define CTRL_DOTCLK_MODE (1 << 17)
+#define CTRL_DATA_SELECT (1 << 16)
+#define CTRL_SET_BUS_WIDTH(x) (((x) & 0x3) << 10)
+#define CTRL_GET_BUS_WIDTH(x) (((x) >> 10) & 0x3)
+#define CTRL_SET_WORD_LENGTH(x) (((x) & 0x3) << 8)
+#define CTRL_GET_WORD_LENGTH(x) (((x) >> 8) & 0x3)
+#define CTRL_MASTER (1 << 5)
+#define CTRL_DF16 (1 << 3)
+#define CTRL_DF18 (1 << 2)
+#define CTRL_DF24 (1 << 1)
+#define CTRL_RUN (1 << 0)
+
+#define CTRL1_FIFO_CLEAR (1 << 21)
+#define CTRL1_SET_BYTE_PACKAGING(x) (((x) & 0xf) << 16)
+#define CTRL1_GET_BYTE_PACKAGING(x) (((x) >> 16) & 0xf)
+
+#define TRANSFER_COUNT_SET_VCOUNT(x) (((x) & 0xffff) << 16)
+#define TRANSFER_COUNT_GET_VCOUNT(x) (((x) >> 16) & 0xffff)
+#define TRANSFER_COUNT_SET_HCOUNT(x) ((x) & 0xffff)
+#define TRANSFER_COUNT_GET_HCOUNT(x) ((x) & 0xffff)
+
+
+#define VDCTRL0_ENABLE_PRESENT (1 << 28)
+#define VDCTRL0_VSYNC_ACT_HIGH (1 << 27)
+#define VDCTRL0_HSYNC_ACT_HIGH (1 << 26)
+#define VDCTRL0_DOTCLK_ACTIVE_HIGH (1 << 25)
+#define VDCTRL0_POL_ACTIVE_HIGH (1 << 24)
+#define VDCTRL0_VSYNC_PERIOD_UNIT (1 << 21)
+#define VDCTRL0_VSYNC_PULSE_WIDTH_UNIT (1 << 20)
+#define VDCTRL0_HALF_LINE (1 << 19)
+#define VDCTRL0_HALF_LINE_MODE (1 << 18)
+#define VDCTRL0_SET_VSYNC_PULSE_WIDTH(x) ((x) & 0x3ffff)
+#define VDCTRL0_GET_VSYNC_PULSE_WIDTH(x) ((x) & 0x3ffff)
+
+#define VDCTRL2_SET_HSYNC_PERIOD(x) ((x) & 0x3ffff)
+#define VDCTRL2_GET_HSYNC_PERIOD(x) ((x) & 0x3ffff)
+
+#define VDCTRL3_MUX_SYNC_SIGNALS (1 << 29)
+#define VDCTRL3_VSYNC_ONLY (1 << 28)
+#define SET_HOR_WAIT_CNT(x) (((x) & 0xfff) << 16)
+#define GET_HOR_WAIT_CNT(x) (((x) >> 16) & 0xfff)
+#define SET_VERT_WAIT_CNT(x) ((x) & 0xffff)
+#define GET_VERT_WAIT_CNT(x) ((x) & 0xffff)
+
+#define VDCTRL4_SET_DOTCLK_DLY(x) (((x) & 0x7) << 29) /* i.MX28 only */
+#define VDCTRL4_GET_DOTCLK_DLY(x) (((x) >> 29) & 0x7) /* i.MX28 only */
+#define VDCTRL4_SYNC_SIGNALS_ON (1 << 18)
+#define SET_DOTCLK_H_VALID_DATA_CNT(x) ((x) & 0x3ffff)
+
+#define DEBUG0_HSYNC (1 < 26)
+#define DEBUG0_VSYNC (1 < 25)
+
+#define MIN_XRES 120
+#define MIN_YRES 120
+
+#define RED 0
+#define GREEN 1
+#define BLUE 2
+#define TRANSP 3
+
+enum mxsfb_devtype {
+ MXSFB_MX23,
+ MXSFB_MX28,
+};
+
+/* CPU dependent register offsets */
+struct mxsfb_devdata {
+ unsigned transfer_count;
+ unsigned cur_buf;
+ unsigned next_buf;
+ unsigned debug0;
+ unsigned hs_wdth_mask;
+ unsigned hs_wdth_shift;
+};
+
+struct mxsfb_info {
+ struct fb_info fb_info;
+ struct platform_device *pdev;
+ struct clk *clk;
+ void __iomem *base; /* registers */
+ unsigned allocated_size;
+ int enabled;
+ unsigned ld_intf_width;
+ unsigned dotclk_delay;
+ const struct mxsfb_devdata *devdata;
+ int mapped;
+};
+
+static const struct mxsfb_devdata mxsfb_devdata[] = {
+ [MXSFB_MX23] = {
+ .transfer_count = LCDC_MX23_TRANSFER_COUNT,
+ .cur_buf = LCDC_MX23_CUR_BUF,
+ .next_buf = LCDC_MX23_NEXT_BUF,
+ .debug0 = LCDC_MX23_DEBUG0,
+ .hs_wdth_mask = 0xff,
+ .hs_wdth_shift = 24,
+ },
+ [MXSFB_MX28] = {
+ .transfer_count = LCDC_MX28_TRANSFER_COUNT,
+ .cur_buf = LCDC_MX28_CUR_BUF,
+ .next_buf = LCDC_MX28_NEXT_BUF,
+ .debug0 = LCDC_MX28_DEBUG0,
+ .hs_wdth_mask = 0x3fff,
+ .hs_wdth_shift = 18,
+ },
+};
+
+#define to_imxfb_host(x) (container_of(x, struct mxsfb_info, fb_info))
+
+/* mask and shift depends on architecture */
+static inline u32 set_hsync_pulse_width(struct mxsfb_info *host, unsigned val)
+{
+ return (val & host->devdata->hs_wdth_mask) <<
+ host->devdata->hs_wdth_shift;
+}
+
+static inline u32 get_hsync_pulse_width(struct mxsfb_info *host, unsigned val)
+{
+ return (val >> host->devdata->hs_wdth_shift) &
+ host->devdata->hs_wdth_mask;
+}
+
+static const struct fb_bitfield def_rgb565[] = {
+ [RED] = {
+ .offset = 11,
+ .length = 5,
+ },
+ [GREEN] = {
+ .offset = 5,
+ .length = 6,
+ },
+ [BLUE] = {
+ .offset = 0,
+ .length = 5,
+ },
+ [TRANSP] = { /* no support for transparency */
+ .length = 0,
+ }
+};
+
+static const struct fb_bitfield def_rgb666[] = {
+ [RED] = {
+ .offset = 16,
+ .length = 6,
+ },
+ [GREEN] = {
+ .offset = 8,
+ .length = 6,
+ },
+ [BLUE] = {
+ .offset = 0,
+ .length = 6,
+ },
+ [TRANSP] = { /* no support for transparency */
+ .length = 0,
+ }
+};
+
+static const struct fb_bitfield def_rgb888[] = {
+ [RED] = {
+ .offset = 16,
+ .length = 8,
+ },
+ [GREEN] = {
+ .offset = 8,
+ .length = 8,
+ },
+ [BLUE] = {
+ .offset = 0,
+ .length = 8,
+ },
+ [TRANSP] = { /* no support for transparency */
+ .length = 0,
+ }
+};
+
+static inline unsigned chan_to_field(unsigned chan, struct fb_bitfield *bf)
+{
+ chan &= 0xffff;
+ chan >>= 16 - bf->length;
+ return chan << bf->offset;
+}
+
+static int mxsfb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ const struct fb_bitfield *rgb = NULL;
+
+ if (var->xres < MIN_XRES)
+ var->xres = MIN_XRES;
+ if (var->yres < MIN_YRES)
+ var->yres = MIN_YRES;
+
+ var->xres_virtual = var->xres;
+
+ var->yres_virtual = var->yres;
+
+ switch (var->bits_per_pixel) {
+ case 16:
+ /* always expect RGB 565 */
+ rgb = def_rgb565;
+ break;
+ case 32:
+ switch (host->ld_intf_width) {
+ case STMLCDIF_8BIT:
+ pr_debug("Unsupported LCD bus width mapping\n");
+ break;
+ case STMLCDIF_16BIT:
+ case STMLCDIF_18BIT:
+ /* 24 bit to 18 bit mapping */
+ rgb = def_rgb666;
+ break;
+ case STMLCDIF_24BIT:
+ /* real 24 bit */
+ rgb = def_rgb888;
+ break;
+ }
+ break;
+ default:
+ pr_debug("Unsupported colour depth: %u\n", var->bits_per_pixel);
+ return -EINVAL;
+ }
+
+ /*
+ * Copy the RGB parameters for this display
+ * from the machine specific parameters.
+ */
+ var->red = rgb[RED];
+ var->green = rgb[GREEN];
+ var->blue = rgb[BLUE];
+ var->transp = rgb[TRANSP];
+
+ return 0;
+}
+
+static void mxsfb_enable_controller(struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ u32 reg;
+
+ dev_dbg(&host->pdev->dev, "%s\n", __func__);
+
+ clk_enable(host->clk);
+ clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
+
+ /* if it was disabled, re-enable the mode again */
+ writel(CTRL_DOTCLK_MODE, host->base + LCDC_CTRL + REG_SET);
+
+ /* enable the SYNC signals first, then the DMA engine */
+ reg = readl(host->base + LCDC_VDCTRL4);
+ reg |= VDCTRL4_SYNC_SIGNALS_ON;
+ writel(reg, host->base + LCDC_VDCTRL4);
+
+ writel(CTRL_RUN, host->base + LCDC_CTRL + REG_SET);
+
+ host->enabled = 1;
+}
+
+static void mxsfb_disable_controller(struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ unsigned loop;
+ u32 reg;
+
+ dev_dbg(&host->pdev->dev, "%s\n", __func__);
+
+ /*
+ * Even if we disable the controller here, it will still continue
+ * until its FIFOs are running out of data
+ */
+ writel(CTRL_DOTCLK_MODE, host->base + LCDC_CTRL + REG_CLR);
+
+ loop = 1000;
+ while (loop) {
+ reg = readl(host->base + LCDC_CTRL);
+ if (!(reg & CTRL_RUN))
+ break;
+ loop--;
+ }
+
+ writel(VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4 + REG_CLR);
+
+ clk_disable(host->clk);
+
+ host->enabled = 0;
+}
+
+static int mxsfb_set_par(struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ u32 ctrl, vdctrl0, vdctrl4;
+ int line_size, fb_size;
+ int reenable = 0;
+
+ line_size = fb_info->var.xres * (fb_info->var.bits_per_pixel >> 3);
+ fb_size = fb_info->var.yres_virtual * line_size;
+
+ if (fb_size > fb_info->fix.smem_len)
+ return -ENOMEM;
+
+ fb_info->fix.line_length = line_size;
+
+ /*
+ * It seems, you can't re-program the controller if it is still running.
+ * This may lead into shifted pictures (FIFO issue?).
+ * So, first stop the controller and drain its FIFOs
+ */
+ if (host->enabled) {
+ reenable = 1;
+ mxsfb_disable_controller(fb_info);
+ }
+
+ /* clear the FIFOs */
+ writel(CTRL1_FIFO_CLEAR, host->base + LCDC_CTRL1 + REG_SET);
+
+ ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER |
+ CTRL_SET_BUS_WIDTH(host->ld_intf_width);;
+
+ switch (fb_info->var.bits_per_pixel) {
+ case 16:
+ dev_dbg(&host->pdev->dev, "Setting up RGB565 mode\n");
+ ctrl |= CTRL_SET_WORD_LENGTH(0);
+ writel(CTRL1_SET_BYTE_PACKAGING(0xf), host->base + LCDC_CTRL1);
+ break;
+ case 32:
+ dev_dbg(&host->pdev->dev, "Setting up RGB888/666 mode\n");
+ ctrl |= CTRL_SET_WORD_LENGTH(3);
+ switch (host->ld_intf_width) {
+ case STMLCDIF_8BIT:
+ dev_dbg(&host->pdev->dev,
+ "Unsupported LCD bus width mapping\n");
+ return -EINVAL;
+ case STMLCDIF_16BIT:
+ case STMLCDIF_18BIT:
+ /* 24 bit to 18 bit mapping */
+ ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
+ * each colour component
+ */
+ break;
+ case STMLCDIF_24BIT:
+ /* real 24 bit */
+ break;
+ }
+ /* do not use packed pixels = one pixel per word instead */
+ writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
+ break;
+ default:
+ dev_dbg(&host->pdev->dev, "Unhandled color depth of %u\n",
+ fb_info->var.bits_per_pixel);
+ return -EINVAL;
+ }
+
+ writel(ctrl, host->base + LCDC_CTRL);
+
+ writel(TRANSFER_COUNT_SET_VCOUNT(fb_info->var.yres) |
+ TRANSFER_COUNT_SET_HCOUNT(fb_info->var.xres),
+ host->base + host->devdata->transfer_count);
+
+ vdctrl0 = VDCTRL0_ENABLE_PRESENT | /* always in DOTCLOCK mode */
+ VDCTRL0_VSYNC_PERIOD_UNIT |
+ VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
+ VDCTRL0_SET_VSYNC_PULSE_WIDTH(fb_info->var.vsync_len);
+ if (fb_info->var.sync & FB_SYNC_HOR_HIGH_ACT)
+ vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
+ if (fb_info->var.sync & FB_SYNC_VERT_HIGH_ACT)
+ vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
+ if (fb_info->var.sync & FB_SYNC_DATA_ENABLE_HIGH_ACT)
+ vdctrl0 |= VDCTRL0_POL_ACTIVE_HIGH;
+
+ writel(vdctrl0, host->base + LCDC_VDCTRL0);
+
+ /* frame length in lines */
+ writel(fb_info->var.upper_margin + fb_info->var.vsync_len +
+ fb_info->var.lower_margin + fb_info->var.yres,
+ host->base + LCDC_VDCTRL1);
+
+ /* line length in units of clocks or pixels */
+ writel(set_hsync_pulse_width(host, fb_info->var.hsync_len) |
+ VDCTRL2_SET_HSYNC_PERIOD(fb_info->var.left_margin +
+ fb_info->var.hsync_len + fb_info->var.right_margin +
+ fb_info->var.xres),
+ host->base + LCDC_VDCTRL2);
+
+ writel(SET_HOR_WAIT_CNT(fb_info->var.left_margin +
+ fb_info->var.hsync_len) |
+ SET_VERT_WAIT_CNT(fb_info->var.upper_margin +
+ fb_info->var.vsync_len),
+ host->base + LCDC_VDCTRL3);
+
+ vdctrl4 = SET_DOTCLK_H_VALID_DATA_CNT(fb_info->var.xres);
+ if (cpu_is_mx28())
+ vdctrl4 |= VDCTRL4_SET_DOTCLK_DLY(host->dotclk_delay);
+ writel(vdctrl4, host->base + LCDC_VDCTRL4);
+
+ writel(fb_info->fix.smem_start +
+ fb_info->fix.line_length * fb_info->var.yoffset,
+ host->base + host->devdata->next_buf);
+
+ if (reenable)
+ mxsfb_enable_controller(fb_info);
+
+ return 0;
+}
+
+static int mxsfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+ u_int transp, struct fb_info *fb_info)
+{
+ unsigned int val;
+ int ret = -EINVAL;
+
+ /*
+ * If greyscale is true, then we convert the RGB value
+ * to greyscale no matter what visual we are using.
+ */
+ if (fb_info->var.grayscale)
+ red = green = blue = (19595 * red + 38470 * green +
+ 7471 * blue) >> 16;
+
+ switch (fb_info->fix.visual) {
+ case FB_VISUAL_TRUECOLOR:
+ /*
+ * 12 or 16-bit True Colour. We encode the RGB value
+ * according to the RGB bitfield information.
+ */
+ if (regno < 16) {
+ u32 *pal = fb_info->pseudo_palette;
+
+ val = chan_to_field(red, &fb_info->var.red);
+ val |= chan_to_field(green, &fb_info->var.green);
+ val |= chan_to_field(blue, &fb_info->var.blue);
+
+ pal[regno] = val;
+ ret = 0;
+ }
+ break;
+
+ case FB_VISUAL_STATIC_PSEUDOCOLOR:
+ case FB_VISUAL_PSEUDOCOLOR:
+ break;
+ }
+
+ return ret;
+}
+
+static int mxsfb_blank(int blank, struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ if (host->enabled)
+ mxsfb_disable_controller(fb_info);
+ break;
+
+ case FB_BLANK_UNBLANK:
+ if (!host->enabled)
+ mxsfb_enable_controller(fb_info);
+ break;
+ }
+ return 0;
+}
+
+static int mxsfb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *fb_info)
+{
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ unsigned offset;
+
+ if (var->xoffset != 0)
+ return -EINVAL;
+
+ offset = fb_info->fix.line_length * var->yoffset;
+
+ /* update on next VSYNC */
+ writel(fb_info->fix.smem_start + offset,
+ host->base + host->devdata->next_buf);
+
+ return 0;
+}
+
+static struct fb_ops mxsfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = mxsfb_check_var,
+ .fb_set_par = mxsfb_set_par,
+ .fb_setcolreg = mxsfb_setcolreg,
+ .fb_blank = mxsfb_blank,
+ .fb_pan_display = mxsfb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static int __devinit mxsfb_restore_mode(struct mxsfb_info *host)
+{
+ struct fb_info *fb_info = &host->fb_info;
+ unsigned line_count;
+ unsigned period;
+ unsigned long pa, fbsize;
+ int bits_per_pixel, ofs;
+ u32 transfer_count, vdctrl0, vdctrl2, vdctrl3, vdctrl4, ctrl;
+ struct fb_videomode vmode;
+
+ /* Only restore the mode when the controller is running */
+ ctrl = readl(host->base + LCDC_CTRL);
+ if (!(ctrl & CTRL_RUN))
+ return -EINVAL;
+
+ vdctrl0 = readl(host->base + LCDC_VDCTRL0);
+ vdctrl2 = readl(host->base + LCDC_VDCTRL2);
+ vdctrl3 = readl(host->base + LCDC_VDCTRL3);
+ vdctrl4 = readl(host->base + LCDC_VDCTRL4);
+
+ transfer_count = readl(host->base + host->devdata->transfer_count);
+
+ vmode.xres = TRANSFER_COUNT_GET_HCOUNT(transfer_count);
+ vmode.yres = TRANSFER_COUNT_GET_VCOUNT(transfer_count);
+
+ switch (CTRL_GET_WORD_LENGTH(ctrl)) {
+ case 0:
+ bits_per_pixel = 16;
+ break;
+ case 3:
+ bits_per_pixel = 32;
+ case 1:
+ default:
+ return -EINVAL;
+ }
+
+ fb_info->var.bits_per_pixel = bits_per_pixel;
+
+ vmode.pixclock = KHZ2PICOS(clk_get_rate(host->clk) / 1000U);
+ vmode.hsync_len = get_hsync_pulse_width(host, vdctrl2);
+ vmode.left_margin = GET_HOR_WAIT_CNT(vdctrl3) - vmode.hsync_len;
+ vmode.right_margin = VDCTRL2_GET_HSYNC_PERIOD(vdctrl2) - vmode.hsync_len -
+ vmode.left_margin - vmode.xres;
+ vmode.vsync_len = VDCTRL0_GET_VSYNC_PULSE_WIDTH(vdctrl0);
+ period = readl(host->base + LCDC_VDCTRL1);
+ vmode.upper_margin = GET_VERT_WAIT_CNT(vdctrl3) - vmode.vsync_len;
+ vmode.lower_margin = period - vmode.vsync_len - vmode.upper_margin - vmode.yres;
+
+ vmode.vmode = FB_VMODE_NONINTERLACED;
+
+ vmode.sync = 0;
+ if (vdctrl0 & VDCTRL0_HSYNC_ACT_HIGH)
+ vmode.sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vdctrl0 & VDCTRL0_VSYNC_ACT_HIGH)
+ vmode.sync |= FB_SYNC_VERT_HIGH_ACT;
+
+ pr_debug("Reconstructed video mode:\n");
+ pr_debug("%dx%d, hsync: %u left: %u, right: %u, vsync: %u, upper: %u, lower: %u\n",
+ vmode.xres, vmode.yres,
+ vmode.hsync_len, vmode.left_margin, vmode.right_margin,
+ vmode.vsync_len, vmode.upper_margin, vmode.lower_margin);
+ pr_debug("pixclk: %ldkHz\n", PICOS2KHZ(vmode.pixclock));
+
+ fb_add_videomode(&vmode, &fb_info->modelist);
+
+ host->ld_intf_width = CTRL_GET_BUS_WIDTH(ctrl);
+ host->dotclk_delay = VDCTRL4_GET_DOTCLK_DLY(vdctrl4);
+
+ fb_info->fix.line_length = vmode.xres * (bits_per_pixel >> 3);
+
+ pa = readl(host->base + host->devdata->cur_buf);
+ fbsize = fb_info->fix.line_length * vmode.yres;
+ if (pa < fb_info->fix.smem_start)
+ return -EINVAL;
+ if (pa + fbsize > fb_info->fix.smem_start + fb_info->fix.smem_len)
+ return -EINVAL;
+ ofs = pa - fb_info->fix.smem_start;
+ if (ofs) {
+ memmove(fb_info->screen_base, fb_info->screen_base + ofs, fbsize);
+ writel(fb_info->fix.smem_start, host->base + host->devdata->next_buf);
+ }
+
+ line_count = fb_info->fix.smem_len / fb_info->fix.line_length;
+ fb_info->fix.ypanstep = 1;
+
+ clk_enable(host->clk);
+ host->enabled = 1;
+
+ return 0;
+}
+
+static int __devinit mxsfb_init_fbinfo(struct mxsfb_info *host)
+{
+ struct fb_info *fb_info = &host->fb_info;
+ struct fb_var_screeninfo *var = &fb_info->var;
+ struct mxsfb_platform_data *pdata = host->pdev->dev.platform_data;
+ dma_addr_t fb_phys;
+ void *fb_virt;
+ unsigned fb_size = pdata->fb_size;
+
+ fb_info->fbops = &mxsfb_ops;
+ fb_info->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST;
+ strlcpy(fb_info->fix.id, "mxs", sizeof(fb_info->fix.id));
+ fb_info->fix.type = FB_TYPE_PACKED_PIXELS;
+ fb_info->fix.ypanstep = 1;
+ fb_info->fix.visual = FB_VISUAL_TRUECOLOR,
+ fb_info->fix.accel = FB_ACCEL_NONE;
+
+ var->bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
+ var->nonstd = 0;
+ var->activate = FB_ACTIVATE_NOW;
+ var->accel_flags = 0;
+ var->vmode = FB_VMODE_NONINTERLACED;
+
+ host->dotclk_delay = pdata->dotclk_delay;
+ host->ld_intf_width = pdata->ld_intf_width;
+
+ /* Memory allocation for framebuffer */
+ if (pdata->fb_phys) {
+ if (!fb_size)
+ return -EINVAL;
+
+ fb_phys = pdata->fb_phys;
+
+ if (!request_mem_region(fb_phys, fb_size, host->pdev->name))
+ return -ENOMEM;
+
+ fb_virt = ioremap(fb_phys, fb_size);
+ if (!fb_virt) {
+ release_mem_region(fb_phys, fb_size);
+ return -ENOMEM;
+ }
+ host->mapped = 1;
+ } else {
+ if (!fb_size)
+ fb_size = SZ_2M; /* default */
+ fb_virt = alloc_pages_exact(fb_size, GFP_DMA);
+ if (!fb_info->screen_base)
+ return -ENOMEM;
+
+ fb_phys = virt_to_phys(fb_virt);
+ }
+
+ fb_info->fix.smem_start = fb_phys;
+ fb_info->screen_base = fb_virt;
+ fb_info->screen_size = fb_info->fix.smem_len = fb_size;
+
+ if (mxsfb_restore_mode(host))
+ memset(fb_virt, 0, fb_size);
+
+ return 0;
+}
+
+static void __devexit mxsfb_free_videomem(struct mxsfb_info *host)
+{
+ struct fb_info *fb_info = &host->fb_info;
+
+ if (host->mapped) {
+ iounmap(fb_info->screen_base);
+ release_mem_region(fb_info->fix.smem_start,
+ fb_info->screen_size);
+ } else {
+ free_pages_exact(fb_info->screen_base, fb_info->fix.smem_len);
+ }
+}
+
+static int __devinit mxsfb_probe(struct platform_device *pdev)
+{
+ struct mxsfb_platform_data *pdata = pdev->dev.platform_data;
+ struct resource *res;
+ struct mxsfb_info *host;
+ struct fb_info *fb_info;
+ struct fb_modelist *modelist;
+ int i, ret;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platformdata. Giving up\n");
+ return -ENODEV;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Cannot get memory IO resource\n");
+ return -ENODEV;
+ }
+
+ if (!request_mem_region(res->start, resource_size(res), pdev->name))
+ return -EBUSY;
+
+ fb_info = framebuffer_alloc(sizeof(struct mxsfb_info), &pdev->dev);
+ if (!fb_info) {
+ dev_err(&pdev->dev, "Failed to allocate fbdev\n");
+ ret = -ENOMEM;
+ goto error_alloc_info;
+ }
+
+ host = to_imxfb_host(fb_info);
+
+ host->base = ioremap(res->start, resource_size(res));
+ if (!host->base) {
+ dev_err(&pdev->dev, "ioremap failed\n");
+ ret = -ENOMEM;
+ goto error_ioremap;
+ }
+
+ host->pdev = pdev;
+ platform_set_drvdata(pdev, host);
+
+ host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
+
+ host->clk = clk_get(&host->pdev->dev, NULL);
+ if (IS_ERR(host->clk)) {
+ ret = PTR_ERR(host->clk);
+ goto error_getclock;
+ }
+
+ fb_info->pseudo_palette = kmalloc(sizeof(u32) * 16, GFP_KERNEL);
+ if (!fb_info->pseudo_palette) {
+ ret = -ENOMEM;
+ goto error_pseudo_pallette;
+ }
+
+ INIT_LIST_HEAD(&fb_info->modelist);
+
+ ret = mxsfb_init_fbinfo(host);
+ if (ret != 0)
+ goto error_init_fb;
+
+ for (i = 0; i < pdata->mode_count; i++)
+ fb_add_videomode(&pdata->mode_list[i], &fb_info->modelist);
+
+ modelist = list_first_entry(&fb_info->modelist,
+ struct fb_modelist, list);
+ fb_videomode_to_var(&fb_info->var, &modelist->mode);
+
+ /* init the color fields */
+ mxsfb_check_var(&fb_info->var, fb_info);
+
+ platform_set_drvdata(pdev, fb_info);
+
+ ret = register_framebuffer(fb_info);
+ if (ret != 0) {
+ dev_err(&pdev->dev,"Failed to register framebuffer\n");
+ goto error_register;
+ }
+
+ if (!host->enabled) {
+ writel(0, host->base + LCDC_CTRL);
+ mxsfb_set_par(fb_info);
+ mxsfb_enable_controller(fb_info);
+ }
+
+ return 0;
+
+error_register:
+ if (host->enabled)
+ clk_disable(host->clk);
+ fb_destroy_modelist(&fb_info->modelist);
+error_init_fb:
+ kfree(fb_info->pseudo_palette);
+error_pseudo_pallette:
+ clk_put(host->clk);
+error_getclock:
+ iounmap(host->base);
+error_ioremap:
+ framebuffer_release(fb_info);
+error_alloc_info:
+ release_mem_region(res->start, resource_size(res));
+
+ return ret;
+}
+
+static int __devexit mxsfb_remove(struct platform_device *pdev)
+{
+ struct fb_info *fb_info = platform_get_drvdata(pdev);
+ struct mxsfb_info *host = to_imxfb_host(fb_info);
+ struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ if (host->enabled)
+ mxsfb_disable_controller(fb_info);
+
+ unregister_framebuffer(fb_info);
+ kfree(fb_info->pseudo_palette);
+ mxsfb_free_videomem(host);
+ iounmap(host->base);
+ clk_put(host->clk);
+
+ framebuffer_release(fb_info);
+ release_mem_region(res->start, resource_size(res));
+
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static struct platform_device_id mxsfb_devtype[] = {
+ {
+ .name = "imx23-fb",
+ .driver_data = MXSFB_MX23,
+ }, {
+ .name = "imx28-fb",
+ .driver_data = MXSFB_MX28,
+ }, {
+ },
+};
+MODULE_DEVICE_TABLE(platform, mxsfb_devtype);
+
+static struct platform_driver mxsfb_driver = {
+ .probe = mxsfb_probe,
+ .remove = __devexit_p(mxsfb_remove),
+ .id_table = mxsfb_devtype,
+ .driver = {
+ .name = DRIVER_NAME,
+ },
+};
+
+static int __init mxsfb_init(void)
+{
+ return platform_driver_register(&mxsfb_driver);
+}
+
+static void __exit mxsfb_exit(void)
+{
+ platform_driver_unregister(&mxsfb_driver);
+}
+
+module_init(mxsfb_init);
+module_exit(mxsfb_exit);
+
+MODULE_DESCRIPTION("Freescale mxs framebuffer driver");
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_LICENSE("GPL");
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3]drivers:video:aty:radeon_base Fix typo occationally to occasionally
From: Justin P. Mattock @ 2011-02-16 6:55 UTC (permalink / raw)
To: trivial; +Cc: linux-fbdev, linux-kernel, dri-devel, Justin P. Mattock
The below patch fixes a typo occationally to occasionally.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 2 +-
drivers/video/aty/radeon_base.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index cf0638c..a883902 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -888,7 +888,7 @@ static void radeon_set_pll(struct drm_crtc *crtc, struct drm_display_mode *mode)
}
if (rdev->flags & RADEON_IS_MOBILITY) {
- /* A temporal workaround for the occational blanking on certain laptop panels.
+ /* A temporal workaround for the occasional blanking on certain laptop panels.
This appears to related to the PLL divider registers (fail to lock?).
It occurs even when all dividers are the same with their old settings.
In this case we really don't need to fiddle with PLL registers.
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 3c1e13e..32f8cf6 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1248,7 +1248,7 @@ static void radeon_write_pll_regs(struct radeonfb_info *rinfo, struct radeon_reg
/* Workaround from XFree */
if (rinfo->is_mobility) {
- /* A temporal workaround for the occational blanking on certain laptop
+ /* A temporal workaround for the occasional blanking on certain laptop
* panels. This appears to related to the PLL divider registers
* (fail to lock?). It occurs even when all dividers are the same
* with their old settings. In this case we really don't need to
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* [PATCH 7/9] tmio-fb: use mfd_data instead of driver_data
From: Andres Salomon @ 2011-02-15 22:25 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Mark Brown, linux-kernel, Andrew Morton, linux-fbdev
In-Reply-To: <1297808729-21110-1-git-send-email-dilinger@queued.net>
Use mfd_data for passing information from mfd drivers to mfd
clients. The mfd_cell's driver_data field is being phased out.
Clients that were using driver_data now access .mfd_data
via mfd_get_data(). This changes tmio-fb only; mfd drivers with
other cells are not modified.
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/mfd/tc6393xb.c | 2 +-
drivers/video/tmiofb.c | 15 +++++++--------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
index ecb045b..3d62ded 100644
--- a/drivers/mfd/tc6393xb.c
+++ b/drivers/mfd/tc6393xb.c
@@ -694,7 +694,7 @@ static int __devinit tc6393xb_probe(struct platform_device *dev)
}
tc6393xb_cells[TC6393XB_CELL_NAND].mfd_data = tcpd->nand_data;
- tc6393xb_cells[TC6393XB_CELL_FB].driver_data = tcpd->fb_data;
+ tc6393xb_cells[TC6393XB_CELL_FB].mfd_data = tcpd->fb_data;
ret = mfd_add_devices(&dev->dev, dev->id,
tc6393xb_cells, ARRAY_SIZE(tc6393xb_cells),
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index 6302882..7e57d3b 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -250,8 +250,7 @@ static irqreturn_t tmiofb_irq(int irq, void *__info)
*/
static int tmiofb_hw_stop(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
- struct tmio_fb_data *data = cell->driver_data;
+ struct tmio_fb_data *data = mfd_get_data(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
@@ -313,7 +312,7 @@ static int tmiofb_hw_init(struct platform_device *dev)
static void tmiofb_hw_mode(struct platform_device *dev)
{
struct mfd_cell *cell = mfd_get_cell(dev);
- struct tmio_fb_data *data = cell->driver_data;
+ struct tmio_fb_data *data = mfd_get_data(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct fb_videomode *mode = info->mode;
struct tmiofb_par *par = info->par;
@@ -559,8 +558,8 @@ static int tmiofb_ioctl(struct fb_info *fbi,
static struct fb_videomode *
tmiofb_find_mode(struct fb_info *info, struct fb_var_screeninfo *var)
{
- struct mfd_cell *cell = mfd_get_cell(to_platform_device(info->device));
- struct tmio_fb_data *data = cell->driver_data;
+ struct tmio_fb_data *data + mfd_get_data(to_platform_device(info->device));
struct fb_videomode *best = NULL;
int i;
@@ -580,8 +579,8 @@ static int tmiofb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct fb_videomode *mode;
- struct mfd_cell *cell = mfd_get_cell(to_platform_device(info->device));
- struct tmio_fb_data *data = cell->driver_data;
+ struct tmio_fb_data *data + mfd_get_data(to_platform_device(info->device));
mode = tmiofb_find_mode(info, var);
if (!mode || var->bits_per_pixel > 16)
@@ -682,7 +681,7 @@ static struct fb_ops tmiofb_ops = {
static int __devinit tmiofb_probe(struct platform_device *dev)
{
struct mfd_cell *cell = mfd_get_cell(dev);
- struct tmio_fb_data *data = cell->driver_data;
+ struct tmio_fb_data *data = mfd_get_data(dev);
struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
struct resource *vram = platform_get_resource(dev, IORESOURCE_MEM, 2);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] video: add missing framebuffer_release in error path
From: David Miller @ 2011-02-15 18:53 UTC (permalink / raw)
To: axel.lin; +Cc: linux-kernel, lethal, linux-fbdev
In-Reply-To: <1297762502.4049.2.camel@phoenix>
From: Axel Lin <axel.lin@gmail.com>
Date: Tue, 15 Feb 2011 17:35:02 +0800
> This patch fixes a memory leak in the error path.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Vasily Khoruzhick @ 2011-02-15 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimapyDg0G0k2GfTdQ6RcUs9oUxXmHGMWoDhaZED@mail.gmail.com>
On Tuesday 15 February 2011 17:12:10 Eric Miao wrote:
> On Tue, Feb 15, 2011 at 9:51 PM, Vasily Khoruzhick <anarsoul@gmail.com>
wrote:
> > On Tuesday 15 February 2011 15:36:07 you wrote:
> >> Then maybe in this way? (I'd rather keep this bit in overlay specific
> >> code, and make it valid not only to pxa27x)
> >>
> >> @@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
> >> pxafb_info *fbi)
> >>
> >> /* place overlay(s) on top of base */
> >> fbi->lccr0 |= LCCR0_OUC;
> >> + lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
> >> +
> >> pr_info("PXA Overlay driver loaded successfully!\n");
> >> return 0;
> >
> > I tried it, it doesn't work that way (I got garbage on screen). Maybe
> > it's not right time to modify LCCR0 reg?
>
> I guess that's because OUC bit needs to be set when the panel is
> not enabled. But re-enabling here is a bit hackish as well.
>
> I don't mind move the code a bit, but can we separate this change
> into another patch from the rest?
Ok, will send patches tonight
> Thanks
> - eric
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Eric Miao @ 2011-02-15 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102151551.20080.anarsoul@gmail.com>
On Tue, Feb 15, 2011 at 9:51 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> On Tuesday 15 February 2011 15:36:07 you wrote:
>
>> Then maybe in this way? (I'd rather keep this bit in overlay specific
>> code, and make it valid not only to pxa27x)
>>
>> @@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
>> pxafb_info *fbi)
>>
>> /* place overlay(s) on top of base */
>> fbi->lccr0 |= LCCR0_OUC;
>> + lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
>> +
>> pr_info("PXA Overlay driver loaded successfully!\n");
>> return 0;
>
> I tried it, it doesn't work that way (I got garbage on screen). Maybe it's not
> right time to modify LCCR0 reg?
>
I guess that's because OUC bit needs to be set when the panel is
not enabled. But re-enabling here is a bit hackish as well.
I don't mind move the code a bit, but can we separate this change
into another patch from the rest?
Thanks
- eric
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-15 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102091731.07794.arnd@arndb.de>
On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 09 February 2011, Sascha Hauer wrote:
>
>> The driver patch itself is Cced to linux-fbdev, only the introductory
>> mail is not.
>
> Ok, I see.
>
>> > Did you consider making the driver a KMS driver instead of
>> > a frame buffer? I think the recommendation these days is
>> > to start out with KMS for new drivers, which will be somewhat
>> > simpler and give you a frame buffer device as well. I don't
>> > think that there is a need to change over any drivers from
>> > fb to kms though, since you've already done the work.
>>
>> I tried doing so for the i.MX51 which supports multiple displays on dvi
>> and vga outputs and thus could make good use of KMS and friends. Anyway,
>> I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI
>> and needs many many callbacks to implement. Additionally the userspace
>> tools expect a nvidia/amd/intel driver and do not have a generic
>> fallback. I think this stuff is good for implementing a full blown
>> graphics driver, but is lacking support for simple framebuffer grapics.
>> I'd love to go this way but it still requires a lot of work.
>
> Ok. This sounds like a lot of upfront work indeed, to make KMS more
> generic, though I think a number of driver would benefit from it
> eventually. It could be something for the Linaro graphics working
> group to look at in the following 11.11 release, depending on how
> many other people are interested in getting there.
>
fwiw, it seems to me like xorg could have some more common code to
deal with the KMS part of DRM.. the various userspace xorg drivers end
up having a lot of very similar code to deal with enumerating
CRTCs/outputs and modes, handle hotplug, etc.
I'd been experimenting a bit on the side w/ the DRM driver framework (
http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
), but had to add a good chunk of mostly boilerplate code to our xorg
driver in order just to test it. Maybe some generic support for KMS
in xf86-video-fbdev would have made this easier to develop the kernel
part without in parallel having to implement the userspace part. I'm
not sure if this is the sort of thing the linaro-wg has in mind?
BR,
-R
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Vasily Khoruzhick @ 2011-02-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinu2LT4t=f=Y0ZBmT6=nsoiQ9HVVTYmzgLMpDXR@mail.gmail.com>
On Tuesday 15 February 2011 15:36:07 you wrote:
> Then maybe in this way? (I'd rather keep this bit in overlay specific
> code, and make it valid not only to pxa27x)
>
> @@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
> pxafb_info *fbi)
>
> /* place overlay(s) on top of base */
> fbi->lccr0 |= LCCR0_OUC;
> + lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
> +
> pr_info("PXA Overlay driver loaded successfully!\n");
> return 0;
I tried it, it doesn't work that way (I got garbage on screen). Maybe it's not
right time to modify LCCR0 reg?
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Eric Miao @ 2011-02-15 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102151358.47203.anarsoul@gmail.com>
On Tue, Feb 15, 2011 at 7:58 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> On Tuesday 15 February 2011 13:51:06 Eric Miao wrote:
>> >> > 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]);
>> >>
>> >> My original intention was to simplify the code a bit by ignoring
>> >> LCCR0_SDS, as FDADR1 would not take effect if not enabled even
>> >> if it's being read/written.
>> >
>> > It leads to potential race condition when you try to reconfigure main
>> > plane and overlay1 simultaneously.
>>
>> You are right on this.
>>
>> >> > +#ifdef CONFIG_FB_PXA_OVERLAY
>> >> > + if (cpu_is_pxa27x())
>> >> > + fbi->lccr0 |= LCCR0_OUC;
>> >> > +#endif
>> >> > +
>> >>
>> >> I seem to remember LCCR0_OUC is still valid on pxa3xx, did you
>> >> do some test on pxa3xx as well?
>> >
>> > Sorry, I have no any pxa3xx boards.
>>
>> That's all right, I can give it a test later. The point is, why
>> did you move the code here from pxafb_overlay_init()?
>
> Because otherwise correct plane order (overlays on top) will be selected only
> on next main plane reconfigure.
>
Then maybe in this way? (I'd rather keep this bit in overlay specific
code, and make it valid not only to pxa27x)
@@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
pxafb_info *fbi)
/* place overlay(s) on top of base */
fbi->lccr0 |= LCCR0_OUC;
+ lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
+
pr_info("PXA Overlay driver loaded successfully!\n");
return 0;
> Regards
> Vasily
>
^ permalink raw reply
* Re: [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Vasily Khoruzhick @ 2011-02-15 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimR_6fYuJHuVC8TD5agjyCoUWiKQmEunhZHSQE5@mail.gmail.com>
On Tuesday 15 February 2011 13:51:06 Eric Miao wrote:
> >> > 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]);
> >>
> >> My original intention was to simplify the code a bit by ignoring
> >> LCCR0_SDS, as FDADR1 would not take effect if not enabled even
> >> if it's being read/written.
> >
> > It leads to potential race condition when you try to reconfigure main
> > plane and overlay1 simultaneously.
>
> You are right on this.
>
> >> > +#ifdef CONFIG_FB_PXA_OVERLAY
> >> > + if (cpu_is_pxa27x())
> >> > + fbi->lccr0 |= LCCR0_OUC;
> >> > +#endif
> >> > +
> >>
> >> I seem to remember LCCR0_OUC is still valid on pxa3xx, did you
> >> do some test on pxa3xx as well?
> >
> > Sorry, I have no any pxa3xx boards.
>
> That's all right, I can give it a test later. The point is, why
> did you move the code here from pxafb_overlay_init()?
Because otherwise correct plane order (overlays on top) will be selected only
on next main plane reconfigure.
Regards
Vasily
^ 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