* 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
* Re: [PATCH 3/7] Add i.MX5 framebuffer driver
From: Jason Chen @ 2011-02-18 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297865452-32181-4-git-send-email-s.hauer@pengutronix.de>
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.
+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.
Jason Chen
BRs
^ permalink raw reply
* Re: [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Shawn Guo @ 2011-02-18 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218083055.GE24426@pengutronix.de>
On Fri, Feb 18, 2011 at 09:30:55AM +0100, Sascha Hauer wrote:
> On Fri, Feb 18, 2011 at 01:24:20PM +0800, Shawn Guo wrote:
> > Sorry, I did not catch up with v1 of the patch set.
> >
> > I have a overall comment on the driver. There is many occurrences
> > of mx23, mx28 etc. throughout the file. IMHO, this is not a good
> > idea. It may be better to use the IP version to handle the
> > differences. In this way, if we have another SoC coming later
> > using the same LCDIF revision as i.MX28. The driver could
> > immediately fit in without code change, ideally.
> >
> > The only problem with version register is that the offset of LCDIF
> > version register is different on i.MX28 from i.MX23.
>
> Can opener inside can. I love it ;)
>
Well, that's the situation we have to deal with.
> > You still need
> > cpu_is_mx23 to read the correct version.
> >
> > BTW, I would try to use cpu_is_mx23 than cpu_is_mx28, as the 'else'
> > of cpu_is_mx23 could _possibly_ cover later SoC as well as i.MX28.
>
> There is only one cpu_is_mx28 in the driver without else. I can switch
> MXSFB_MX23 and MXSFB_MX28 to MXSFB_V3 and MXSFB_V4 if you like it
> better.
>
Yes, I like it better. With it, if we have a new SoC using LCDIF v4,
the driver needs no change.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-18 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218052418.GA18053@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 01:24:20PM +0800, Shawn Guo wrote:
> Sorry, I did not catch up with v1 of the patch set.
>
> I have a overall comment on the driver. There is many occurrences
> of mx23, mx28 etc. throughout the file. IMHO, this is not a good
> idea. It may be better to use the IP version to handle the
> differences. In this way, if we have another SoC coming later
> using the same LCDIF revision as i.MX28. The driver could
> immediately fit in without code change, ideally.
>
> The only problem with version register is that the offset of LCDIF
> version register is different on i.MX28 from i.MX23.
Can opener inside can. I love it ;)
> You still need
> cpu_is_mx23 to read the correct version.
>
> BTW, I would try to use cpu_is_mx23 than cpu_is_mx28, as the 'else'
> of cpu_is_mx23 could _possibly_ cover later SoC as well as i.MX28.
There is only one cpu_is_mx28 in the driver without else. I can switch
MXSFB_MX23 and MXSFB_MX28 to MXSFB_V3 and MXSFB_V4 if you like it
better.
--
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/2] video: Add i.MX23/28 framebuffer driver
From: Shawn Guo @ 2011-02-18 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297850199-1688-2-git-send-email-s.hauer@pengutronix.de>
Sorry, I did not catch up with v1 of the patch set.
I have a overall comment on the driver. There is many occurrences
of mx23, mx28 etc. throughout the file. IMHO, this is not a good
idea. It may be better to use the IP version to handle the
differences. In this way, if we have another SoC coming later
using the same LCDIF revision as i.MX28. The driver could
immediately fit in without code change, ideally.
The only problem with version register is that the offset of LCDIF
version register is different on i.MX28 from i.MX23. You still need
cpu_is_mx23 to read the correct version.
BTW, I would try to use cpu_is_mx23 than cpu_is_mx28, as the 'else'
of cpu_is_mx23 could _possibly_ cover later SoC as well as i.MX28.
--
Regards,
Shawn
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
> +
> +#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
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-18 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimOUnaHNMg03cHAiNJLuGhGuMWSHt+kibxWfYMH@mail.gmail.com>
I'm in the process of adding xrandr support to our xorg driver..
definitely more built-in support on the X side would make this easier.
BR,
-R
On Thu, Feb 17, 2011 at 8:25 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
> I also noticed that default XRandR1.2+ implementation is missing in X side.
> If we can implement one, it would be beneficial for all ARM platforms. By
> the way, does X driver of TI support XRandR1.2+?
>
> Regards,
> Jammy
>
> On Thu, Feb 17, 2011 at 11:25 PM, Clark, Rob <rob@ti.com> wrote:
>>
>> Hmm, I was thinking more on the xf86 side of things.. ie. to provide
>> default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec
>> functions..
>>
>> BR,
>> -R
>>
>> On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>> >
>> > There is already one KMS abstraction layer (libkms.so) in libdrm, maybe
>> > it can serve as what we needed.
>> >
>> > Regards,
>> > Jammy
>> >
>> > On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob <rob@ti.com> 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.
>> >>
>> >> BR,
>> >> -R
>> >>
>> >> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org>
>> >> wrote:
>> >> > Speaking for the Linaro graphics working group, I think it's great.
>> >> > And, I
>> >> > think you're right, that if enough of the KMS support in xf86-video-*
>> >> > is
>> >> > similar enough (I was only aware of intel and nouveau supporting it
>> >> > properly
>> >> > at current), pulling it out into a common layer would make it easier
>> >> > to
>> >> > support in new drivers (including fbdev).
>> >> >
>> >> > cheers,
>> >> > Jesse
>> >> >
>> >> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> >>
>> >> >> 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
>> >> >>
>> >> >> _______________________________________________
>> >> >> linaro-dev mailing list
>> >> >> linaro-dev@lists.linaro.org
>> >> >> http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> linaro-dev mailing list
>> >> linaro-dev@lists.linaro.org
>> >> http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >
>
>
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-18 4:32 UTC (permalink / raw)
To: Jammy Zhou
Cc: Linux Fbdev development list, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Arnd Bergmann, Sascha Hauer, DRI development list, James Simmons,
Jakob Bornecrantz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <AANLkTimcwr4vpycSQCH9vMaB+umh+yHD_+WD2MJNqMOB-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
I'm all for a more modular drm, although I think the framework of
CRTCs, encoders, and connectors is a nice fit, at least for our hw.
It would be nice to have a better way to expose overlays. And I'm
still thinking about how/if GEM fits in with our various video and
2/3d accelerators.
BR,
-R
On Thu, Feb 17, 2011 at 8:19 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
> To accommodate the fact of independent display controller and GPU components
> in ARM SOC, it will be better if we can separate KMS from DRM both in kernel
> space and user space (i.e, create a new drivers/video/kms directory for
> kernel side, move KMS related code in libdrm to libkms in user space). Then
> we can build xrandr1.2+ support based on KMS for ARM platforms, even if DRM
> is still not supported. Besides, for buffer management part (GEM) in DRM, if
> possible, we can also make it an independent module leaving DRM just a
> wrapper, so that the GEM stuff can be used more flexibly.
>
> Regards,
> Jammy
>
> On Fri, Feb 18, 2011 at 12: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.
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>
^ permalink raw reply
* [PATCH 24/29] tmio-fb: use mfd_data instead of driver_data
From: Andres Salomon @ 2011-02-18 3:07 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Mark Brown, linux-kernel, Andrew Morton, linux-fbdev
In-Reply-To: <1297998456-7615-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
* [PATCH 12/29] tc6393xb: mfd_cell is now implicitly available to drivers
From: Andres Salomon @ 2011-02-18 3:07 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Mark Brown, linux-kernel, David Brownell, Greg Kroah-Hartman,
linux-usb, linux-fbdev
In-Reply-To: <1297998456-7615-1-git-send-email-dilinger@queued.net>
No need to explicitly set the cell's platform_data/data_size.
Modify clients to use mfd_get_cell helper function instead of
accessing platform_data directly.
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/mfd/tc6393xb.c | 19 -------------------
drivers/usb/host/ohci-tmio.c | 8 ++++----
drivers/video/tmiofb.c | 20 +++++++++-----------
3 files changed, 13 insertions(+), 34 deletions(-)
diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
index 9a23863..a71ff5c 100644
--- a/drivers/mfd/tc6393xb.c
+++ b/drivers/mfd/tc6393xb.c
@@ -694,26 +694,7 @@ static int __devinit tc6393xb_probe(struct platform_device *dev)
}
tc6393xb_cells[TC6393XB_CELL_NAND].driver_data = tcpd->nand_data;
- tc6393xb_cells[TC6393XB_CELL_NAND].platform_data - &tc6393xb_cells[TC6393XB_CELL_NAND];
- tc6393xb_cells[TC6393XB_CELL_NAND].data_size - sizeof(tc6393xb_cells[TC6393XB_CELL_NAND]);
-
- tc6393xb_cells[TC6393XB_CELL_MMC].platform_data - &tc6393xb_cells[TC6393XB_CELL_MMC];
- tc6393xb_cells[TC6393XB_CELL_MMC].data_size - sizeof(tc6393xb_cells[TC6393XB_CELL_MMC]);
-
- tc6393xb_cells[TC6393XB_CELL_OHCI].platform_data - &tc6393xb_cells[TC6393XB_CELL_OHCI];
- tc6393xb_cells[TC6393XB_CELL_OHCI].data_size - sizeof(tc6393xb_cells[TC6393XB_CELL_OHCI]);
-
tc6393xb_cells[TC6393XB_CELL_FB].driver_data = tcpd->fb_data;
- tc6393xb_cells[TC6393XB_CELL_FB].platform_data - &tc6393xb_cells[TC6393XB_CELL_FB];
- tc6393xb_cells[TC6393XB_CELL_FB].data_size - sizeof(tc6393xb_cells[TC6393XB_CELL_FB]);
ret = mfd_add_devices(&dev->dev, dev->id,
tc6393xb_cells, ARRAY_SIZE(tc6393xb_cells),
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index 8dabe8e..eeed164 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -185,7 +185,7 @@ static struct platform_driver ohci_hcd_tmio_driver;
static int __devinit ohci_hcd_tmio_drv_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct resource *regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
struct resource *config = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *sram = platform_get_resource(dev, IORESOURCE_MEM, 2);
@@ -274,7 +274,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
usb_remove_hcd(hcd);
tmio_stop_hc(dev);
@@ -293,7 +293,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
#ifdef CONFIG_PM
static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
@@ -326,7 +326,7 @@ static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t s
static int ohci_hcd_tmio_drv_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index dfef88c..6302882 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -250,7 +250,7 @@ static irqreturn_t tmiofb_irq(int irq, void *__info)
*/
static int tmiofb_hw_stop(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = cell->driver_data;
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
@@ -268,7 +268,7 @@ static int tmiofb_hw_stop(struct platform_device *dev)
*/
static int tmiofb_hw_init(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
const struct resource *nlcr = &cell->resources[0];
@@ -312,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 = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = cell->driver_data;
struct fb_info *info = platform_get_drvdata(dev);
struct fb_videomode *mode = info->mode;
@@ -559,8 +559,7 @@ 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 - info->device->platform_data;
+ struct mfd_cell *cell = mfd_get_cell(to_platform_device(info->device));
struct tmio_fb_data *data = cell->driver_data;
struct fb_videomode *best = NULL;
int i;
@@ -581,8 +580,7 @@ static int tmiofb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct fb_videomode *mode;
- struct mfd_cell *cell - info->device->platform_data;
+ struct mfd_cell *cell = mfd_get_cell(to_platform_device(info->device));
struct tmio_fb_data *data = cell->driver_data;
mode = tmiofb_find_mode(info, var);
@@ -683,7 +681,7 @@ static struct fb_ops tmiofb_ops = {
static int __devinit tmiofb_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = cell->driver_data;
struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -811,7 +809,7 @@ err_ioremap_ccr:
static int __devexit tmiofb_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
struct tmiofb_par *par;
@@ -941,7 +939,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
#ifdef CONFIG_FB_TMIO_ACCELL
struct tmiofb_par *par = info->par;
#endif
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
@@ -973,7 +971,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
static int tmiofb_resume(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
- struct mfd_cell *cell = dev->dev.platform_data;
+ struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Eric Miao @ 2011-02-18 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217185609.GB30606@n2100.arm.linux.org.uk>
On Fri, Feb 18, 2011 at 2:56 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 17, 2011 at 07:17:41PM +0100, Marek Vasut wrote:
>> Why are you getting rid of the atomic operations ?
>
> Because they're idiotic. Â Just because something is called "atomic"
> doesn't make it so, and this is one instance where it's absolutely
> useless.
Yep, I completely agree that's useless here.
^ permalink raw reply
* Re: [PATCH 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Russell King - ARM Linux @ 2011-02-17 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102171917.41442.marek.vasut@gmail.com>
On Thu, Feb 17, 2011 at 07:17:41PM +0100, Marek Vasut wrote:
> Why are you getting rid of the atomic operations ?
Because they're idiotic. Just because something is called "atomic"
doesn't make it so, and this is one instance where it's absolutely
useless.
The open and release functions are called with a mutex held. Only
_one_ thread can be inside these at any one time. So what use does
additionally doing an atomic operation within an already thread-safe
environment gain you?
> Besides, "if (ofb->usage++ = 0)" looks suspicious, especially if you later
> declare it as uint32_t.
No. You're not understanding the code. This is equivalent to:
usage = ofb->usage;
ofb->usage = usage + 1;
if (usage = 0)
And if you write it like that, then it is obvious. It's your understanding
of what a post-increment looks like which is suspicious here.
> > @@ -733,12 +739,24 @@ static int overlayfb_release(struct fb_info *info,
> > int user) {
> > struct pxafb_layer *ofb = (struct pxafb_layer*) info;
> >
>
> DTTO, why no atomic?
Because this is already a thread-safe code region.
> > ofb->video_mem = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
> > @@ -891,7 +910,7 @@ static void __devinit init_pxafb_overlay(struct
> > pxafb_info *fbi,
> >
> > ofb->id = id;
> > ofb->ops = &ofb_ops[id];
>
> DTTO
An initializing store by which a machine can write the entire contents in
one instruction _is_ by its very nature atomic.
atomic_t is one of the most over(ab)used types because people just don't
think about the code they're writing. ;(
^ permalink raw reply
* Re: [PATCH 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Marek Vasut @ 2011-02-17 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297928588-10545-1-git-send-email-anarsoul@gmail.com>
On Thursday 17 February 2011 08:43:07 Vasily Khoruzhick wrote:
> From: Russell King - ARM Linux <linux@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.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/video/pxafb.c | 55
> +++++++++++++++++++++++++++++++++--------------- drivers/video/pxafb.h |
> 2 +-
> 2 files changed, 39 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 825b665..c6aad56 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));
> @@ -636,7 +639,8 @@ static void overlay1fb_disable(struct pxafb_layer *ofb)
> lcd_writel(ofb->fbi, FBR1, ofb->fbi->fdadr[DMA_OV1] | 0x3);
>
> if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> - pr_warning("%s: timeout disabling overlay1\n", __func__);
> + pr_warning("%s: timeout disabling overlay1\n",
> + __func__);
>
> lcd_writel(ofb->fbi, LCCR5, lccr5);
> }
> @@ -687,6 +691,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));
> @@ -696,7 +703,8 @@ static void overlay2fb_disable(struct pxafb_layer *ofb)
> lcd_writel(ofb->fbi, FBR4, ofb->fbi->fdadr[DMA_OV2_Cr] | 0x3);
>
> if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> - pr_warning("%s: timeout disabling overlay2\n", __func__);
> + pr_warning("%s: timeout disabling overlay2\n",
> + __func__);
> }
>
> static struct pxafb_layer_ops ofb_ops[] = {
> @@ -720,12 +728,10 @@ static int overlayfb_open(struct fb_info *info, int
> user) if (user = 0)
> return -ENODEV;
>
Why are you getting rid of the atomic operations ?
Besides, "if (ofb->usage++ = 0)" looks suspicious, especially if you later
declare it as uint32_t.
> - /* 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 +739,24 @@ static int overlayfb_release(struct fb_info *info,
> int user) {
> struct pxafb_layer *ofb = (struct pxafb_layer*) info;
>
DTTO, why no atomic?
> - 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 +835,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 +910,7 @@ static void __devinit init_pxafb_overlay(struct
> pxafb_info *fbi,
>
> ofb->id = id;
> ofb->ops = &ofb_ops[id];
DTTO
> - atomic_set(&ofb->usage, 0);
> + ofb->usage = 0;
> ofb->fbi = fbi;
> init_completion(&ofb->branch_done);
> }
> @@ -1368,7 +1387,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 +1440,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;
DTTO, here.
> - atomic_t usage;
> + uint32_t usage;
> uint32_t control[2];
>
> struct pxafb_layer_ops *ops;
^ permalink raw reply
* Re: [PATCH 1/7] Add a mfd IPUv3 driver
From: Arnaud Patard @ 2011-02-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297865452-32181-2-git-send-email-s.hauer@pengutronix.de>
Sascha Hauer <s.hauer@pengutronix.de> writes:
Hi,
> The IPU is the Image Processing Unit found on i.MX51/53 SoCs. It
> features several units for image processing, this patch adds support
> for the units needed for Framebuffer support, namely:
>
> - Display Controller (dc)
> - Display Interface (di)
> - Display Multi Fifo Controller (dmfc)
> - Display Processor (dp)
> - Image DMA Controller (idmac)
>
> This patch is based on the Freescale driver, but follows a different
> approach. The Freescale code implements logical idmac channels and
> the handling of the subunits is hidden in common idmac code pathes
> in big switch/case statements. This patch instead just provides code
> and resource management for the different subunits. The user, in this
> case the framebuffer driver, decides how the different units play
> together.
>
> The IPU has other units missing in this patch:
>
> - CMOS Sensor Interface (csi)
> - Video Deinterlacer (vdi)
> - Sensor Multi FIFO Controler (smfc)
> - Image Converter (ic)
> - Image Rotator (irt)
>
> So expect more files to come in this directory.
>
> 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>
> ---
> arch/arm/plat-mxc/include/mach/ipu-v3.h | 49 +++
> drivers/video/Kconfig | 2 +
> drivers/video/Makefile | 1 +
> drivers/video/imx-ipu-v3/Makefile | 3 +
> drivers/video/imx-ipu-v3/ipu-common.c | 708 +++++++++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-cpmem.c | 612 ++++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dc.c | 364 ++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-di.c | 550 ++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dmfc.c | 355 ++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dp.c | 476 +++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-prv.h | 216 ++++++++++
> include/linux/mfd/imx-ipu-v3.h | 219 ++++++++++
> 12 files changed, 3555 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-mxc/include/mach/ipu-v3.h
> create mode 100644 drivers/video/imx-ipu-v3/Makefile
> create mode 100644 drivers/video/imx-ipu-v3/ipu-common.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-cpmem.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-dc.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-di.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-dmfc.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-dp.c
> create mode 100644 drivers/video/imx-ipu-v3/ipu-prv.h
> create mode 100644 include/linux/mfd/imx-ipu-v3.h
[...]
> 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 ?
> 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 ?
Arnaud
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: James Simmons @ 2011-02-17 16:14 UTC (permalink / raw)
To: Clark, Rob
Cc: Linux Fbdev development list, linaro-dev, Arnd Bergmann,
Sascha Hauer, DRI development list, Jesse Barker,
Jakob Bornecrantz, linux-arm-kernel
In-Reply-To: <AANLkTimMBLhopNq0L-NuJLdX08SrA078VF3tWf9TcEom@mail.gmail.com>
> 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.
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-17 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim3iUNHsaCf7387H-X+XW0YDQsQVa1FwDvo0KvH@mail.gmail.com>
Hmm, I was thinking more on the xf86 side of things.. ie. to provide
default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec
functions..
BR,
-R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>
> There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it can serve as what we needed.
>
> Regards,
> Jammy
>
> On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob <rob@ti.com> 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.
>>
>> BR,
>> -R
>>
>> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org> wrote:
>> > Speaking for the Linaro graphics working group, I think it's great. And, I
>> > think you're right, that if enough of the KMS support in xf86-video-* is
>> > similar enough (I was only aware of intel and nouveau supporting it properly
>> > at current), pulling it out into a common layer would make it easier to
>> > support in new drivers (including fbdev).
>> >
>> > cheers,
>> > Jesse
>> >
>> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >>
>> >> 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
>> >>
>> >> _______________________________________________
>> >> linaro-dev mailing list
>> >> linaro-dev@lists.linaro.org
>> >> http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >
>> >
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Vasily Khoruzhick @ 2011-02-17 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217110321.GF24627@n2100.arm.linux.org.uk>
On Thursday 17 February 2011 13:03:21 Russell King - ARM Linux wrote:
> On Thu, Feb 17, 2011 at 09:43:07AM +0200, Vasily Khoruzhick wrote:
> > From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> >
> > From: Russell King - ARM Linux <linux@arm.linux.org.uk>
>
> No need for two From: lines.
It was added accidently, sorry
> > @@ -636,7 +639,8 @@ static void overlay1fb_disable(struct pxafb_layer
> > *ofb)
> >
> > lcd_writel(ofb->fbi, FBR1, ofb->fbi->fdadr[DMA_OV1] | 0x3);
> >
> > if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> >
> > - pr_warning("%s: timeout disabling overlay1\n", __func__);
> > + pr_warning("%s: timeout disabling overlay1\n",
> > + __func__);
>
> No need for this change.
>
> > @@ -687,6 +691,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;
> > +
>
> You don't describe this change in the change log, and this wasn't in my
> patch.
I did, "- Disable overlay only if it was enabled."
> > @@ -696,7 +703,8 @@ static void overlay2fb_disable(struct pxafb_layer
> > *ofb)
> >
> > lcd_writel(ofb->fbi, FBR4, ofb->fbi->fdadr[DMA_OV2_Cr] | 0x3);
> >
> > if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> >
> > - pr_warning("%s: timeout disabling overlay2\n", __func__);
> > + pr_warning("%s: timeout disabling overlay2\n",
> > + __func__);
>
> No need for this change.
Ok
^ permalink raw reply
* Re: [PATCH 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Russell King - ARM Linux @ 2011-02-17 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297928588-10545-1-git-send-email-anarsoul@gmail.com>
On Thu, Feb 17, 2011 at 09:43:07AM +0200, Vasily Khoruzhick wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
>
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
No need for two From: lines.
> @@ -636,7 +639,8 @@ static void overlay1fb_disable(struct pxafb_layer *ofb)
> lcd_writel(ofb->fbi, FBR1, ofb->fbi->fdadr[DMA_OV1] | 0x3);
>
> if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> - pr_warning("%s: timeout disabling overlay1\n", __func__);
> + pr_warning("%s: timeout disabling overlay1\n",
> + __func__);
No need for this change.
> @@ -687,6 +691,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;
> +
You don't describe this change in the change log, and this wasn't in my
patch.
> @@ -696,7 +703,8 @@ static void overlay2fb_disable(struct pxafb_layer *ofb)
> lcd_writel(ofb->fbi, FBR4, ofb->fbi->fdadr[DMA_OV2_Cr] | 0x3);
>
> if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
> - pr_warning("%s: timeout disabling overlay2\n", __func__);
> + pr_warning("%s: timeout disabling overlay2\n",
> + __func__);
No need for this change.
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Ondrej Zary @ 2011-02-17 8:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Thursday 17 February 2011, Alex Buell wrote:
> On Wed, 2011-02-16 at 15:24 -0800, David Miller wrote:
> > 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.
>
> OK, I'd forgotten that the VGA hardware needs initialising.
Playing with (at least) S3 initialization is on my todo list.
--
Ondrej Zary
^ permalink raw reply
* [PATCH 2/2] ARM: PXA: PXAFB: fix plane Z-ordering problem
From: Vasily Khoruzhick @ 2011-02-17 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297928588-10545-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 c6aad56..590a99a 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -942,8 +942,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;
}
@@ -1827,6 +1825,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 1/2] ARM: PXA: PXAFB: Fix double-free issue.
From: Vasily Khoruzhick @ 2011-02-17 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102151718.00800.anarsoul@gmail.com>
From: Russell King - ARM Linux <linux@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.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/video/pxafb.c | 55 +++++++++++++++++++++++++++++++++---------------
drivers/video/pxafb.h | 2 +-
2 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 825b665..c6aad56 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));
@@ -636,7 +639,8 @@ static void overlay1fb_disable(struct pxafb_layer *ofb)
lcd_writel(ofb->fbi, FBR1, ofb->fbi->fdadr[DMA_OV1] | 0x3);
if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
- pr_warning("%s: timeout disabling overlay1\n", __func__);
+ pr_warning("%s: timeout disabling overlay1\n",
+ __func__);
lcd_writel(ofb->fbi, LCCR5, lccr5);
}
@@ -687,6 +691,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));
@@ -696,7 +703,8 @@ static void overlay2fb_disable(struct pxafb_layer *ofb)
lcd_writel(ofb->fbi, FBR4, ofb->fbi->fdadr[DMA_OV2_Cr] | 0x3);
if (wait_for_completion_timeout(&ofb->branch_done, 1 * HZ) = 0)
- pr_warning("%s: timeout disabling overlay2\n", __func__);
+ pr_warning("%s: timeout disabling overlay2\n",
+ __func__);
}
static struct pxafb_layer_ops ofb_ops[] = {
@@ -720,12 +728,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 +739,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 +835,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 +910,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 +1387,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 +1440,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 1/1] sh_mobile_lcdc: Add NV12 input framebuffer support
From: Damian @ 2011-02-17 5:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1297734708-20803-2-git-send-email-dhobsong@igel.co.jp>
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.
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
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* Re: [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik+ounqcTJ6rhiUqKPGkwcCOKGXdsVADs6zHfPU@mail.gmail.com>
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.
BR,
-R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org> wrote:
> Speaking for the Linaro graphics working group, I think it's great. And, I
> think you're right, that if enough of the KMS support in xf86-video-* is
> similar enough (I was only aware of intel and nouveau supporting it properly
> at current), pulling it out into a common layer would make it easier to
> support in new drivers (including fbdev).
>
> cheers,
> Jesse
>
> On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> 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
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>
^ permalink raw reply
* Re: [PATCH 1/1] sh_mobile_lcdc: Add NV12 input framebuffer support
From: Magnus Damm @ 2011-02-17 0:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1297734708-20803-2-git-send-email-dhobsong@igel.co.jp>
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!
> --- 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.
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.
Please consider reworking the patch to make it more generic. Just
adding NV12 support is aiming too low. =)
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Alex Buell @ 2011-02-16 23:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Wed, 2011-02-16 at 15:24 -0800, David Miller wrote:
> 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.
OK, I'd forgotten that the VGA hardware needs initialising.
--
Tactical Nuclear Kittens
^ permalink raw reply
* 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
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