* Re: [PATCH 18/37] Remove unneeded version.h includes from drivers/video/
From: Mike Frysinger @ 2011-06-23 22:51 UTC (permalink / raw)
To: Jesper Juhl
Cc: LKML, trivial, Michael Hennerich, Richard Purdie, Paul Mundt,
device-drivers-devel, linux-fbdev
In-Reply-To: <alpine.LNX.2.00.1106240032560.17688@swampdragon.chaosbits.net>
On Thu, Jun 23, 2011 at 18:35, Jesper Juhl wrote:
> drivers/video/backlight/adp8860_bl.c | 1 -
> drivers/video/backlight/adp8870_bl.c | 1 -
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* Re: [PATCH 1/5 v3] fbdev: sh_mobile_meram: Add enable/disble hooks for LCDC
From: Paul Mundt @ 2011-06-24 5:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1308728992-9660-2-git-send-email-dhobsong@igel.co.jp>
On Wed, Jun 22, 2011 at 04:49:48PM +0900, Damian Hobson-Garcia wrote:
> +static int sh_mobile_meram_pm_get_sync(struct sh_mobile_meram_info *pdata)
> +{
> + if (!pdata || !pdata->pdev)
> + return -EINVAL;
> +
> + dev_dbg(&pdata->pdev->dev, "Enabling sh_mobile_meram clock.");
> + pm_runtime_get_sync(&pdata->pdev->dev);
> + return 0;
> +}
> +
On Wed, Jun 22, 2011 at 04:49:49PM +0900, Damian Hobson-Garcia wrote:
> @@ -259,6 +259,11 @@ static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> pm_runtime_get_sync(priv->dev);
> if (priv->dot_clk)
> clk_enable(priv->dot_clk);
> + if (priv->meram_dev && priv->meram_dev->ops) {
> + struct sh_mobile_meram_info *mdev;
> + mdev = priv->meram_dev;
> + mdev->ops->meram_pm_get_sync(mdev);
> + }
> }
> }
>
I'm not sure that I really see the point in the callbacks. The callbacks
would make sense in the case where you're dealing with opaque types that
you don't wish to have knowledge of in the other drivers, but when all
you're doing is fetching the pointer and wrapping verbatim in to the
runtime pm calls, it just seems like a pointless layer of indirection.
You could easily just do this as:
if (priv->meram_dev)
pm_runtime_get_sync(&priv->meram_dev->pdev->dev);
and be done with it.
This will also save you from having to add additional callbacks should
you decide that you suddenly require async behaviour or so in other
cases, too.
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Paul Mundt @ 2011-06-24 6:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Florian Tobias Schandinat, Laurent Pinchart, linux-fbdev,
linux-media, dri-devel
In-Reply-To: <BANLkTikMLE=F4OLTRhQ6LYR=d1x6xukJXA@mail.gmail.com>
On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
> <FlorianSchandinat@gmx.de> wrote:
> > On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
> >> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
> >>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
> >>> be non-zero), I don't think there are any conflicts with existing values
> >>> of
> >>> nonstd. To make it even safer and easier to parse, you could set bit 31
> >>> of
> >>> nonstd as a FOURCC indicator.
> >>
> >> I would then create a union between nonstd and fourcc, and document nonstd
> >> as
> >> being used for the legacy API only. Most existing drivers use a couple of
> >> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
> >> uses
> >> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
> >> 0xff000000 != 0 could be used as a FOURCC mode test.
> >>
> >> This assumes that FOURCCs will never have their last character set to
> >> '\0'. Is
> >> that a safe assumption for the future ?
> >
> > Yes, I think. The information I found indicates that space should be used
> > for padding, so a \0 shouldn't exist.
> > I think using only the nonstd field and requiring applications to check the
> > capabilities would be possible, although not fool proof ;)
>
> So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
> any of them is set.
>
> Nicely backwards compatible, as sane drivers should reject nonstd values they
> don't support (apps _will_ start filling in FOURCC values ignoring capabilities,
> won't they?).
>
That seems like a reasonable case, but if we're going to do that then
certainly the nonstd bit encoding needs to be documented and treated as a
hard ABI.
I'm not so sure about the if any bit in the upper byte is set assume
FOURCC case though, there will presumably be other users in the future
that will want bits for themselves, too. What exactly was the issue with
having a FOURCC capability bit in the upper byte?
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_meram: Correct pointer check for YCbCr chroma plane
From: Paul Mundt @ 2011-06-24 7:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1308728785-9588-1-git-send-email-dhobsong@igel.co.jp>
On Wed, Jun 22, 2011 at 04:46:25PM +0900, Damian Hobson-Garcia wrote:
> The check was intended to test if we have a valid pointer to write into,
> but it mistakenly checks the pointer contents instead.
>
> Since a valid pointer is mandatory for the chroma data if a YCbCr format
> is used, the pointer check has been removed.
>
> Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> ---
> Sorry, forgot to sign off the previous version. Resend
> drivers/video/sh_mobile_meram.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] gx1fb: Fix section mismatch warnings
From: Paul Mundt @ 2011-06-24 8:01 UTC (permalink / raw)
To: Randy Dunlap
Cc: Sedat Dilek, linux-geode, linux-fbdev, linux-kernel, Sedat Dilek
In-Reply-To: <20110616123119.6ca873fa.randy.dunlap@oracle.com>
On Thu, Jun 16, 2011 at 12:31:19PM -0700, Randy Dunlap wrote:
> Fix a chain of section mismatches in geode driver, beginning with:
>
> WARNING: drivers/video/geode/gx1fb.o(.data+0x70): Section mismatch in reference from the variable gx1fb_driver to the function .init.text:gx1fb_probe()
> The variable gx1fb_driver references
> the function __init gx1fb_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Making the changes that Paul pointed out resulted in a few more
> changes being needed, so they are all included here.
On Thu, Jun 16, 2011 at 12:32:40PM -0700, Randy Dunlap wrote:
> Fix section mismatch warning in sm501fb:
>
> WARNING: drivers/video/sm501fb.o(.text+0x21d6): Section mismatch in reference from the function sm501fb_init_fb() to the variable .devinit.data:sm501_default_mode
> The function sm501fb_init_fb() references
> the variable __devinitdata sm501_default_mode.
> This is often because sm501fb_init_fb lacks a __devinitdata
> annotation or the annotation of sm501_default_mode is wrong.
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH] hecubafb: add module_put on error path in hecubafb_probe()
From: Paul Mundt @ 2011-06-24 8:02 UTC (permalink / raw)
To: Pavel Shved; +Cc: linux-fbdev, linux-kernel, ldv-project
In-Reply-To: <1308327913-23220-3-git-send-email-shved@ispras.ru>
On Fri, Jun 17, 2011 at 08:25:12PM +0400, Pavel Shved wrote:
> In hecubafb_probe(), after a successful try_module_get, vzalloc may
> fail and make the hecubafb_probe return, but the module is not put on
> this error path.
>
> This patch adds an exit point that calls module_put in such situation.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Pavel Shved <shved@ispras.ru>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ARM: amba: Link fb device to its parent
From: Paul Mundt @ 2011-06-24 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308602657-28783-1-git-send-email-loic.minier@linaro.org>
On Mon, Jun 20, 2011 at 10:44:17PM +0200, Lo??c Minier wrote:
> Some pieces of userspace like debian-installer expect to find the fb0
> driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
> this was broken with amba-clcd as it sets up fb_info manually and missed
> the .device parent pointer.
>
> Signed-off-by: Lo??c Minier <loic.minier@linaro.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Paul Mundt <lethal@linux-sh.org>
> ---
> drivers/video/amba-clcd.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
While this is titled as an ARM patch it's certainly fbdev-specific. I'll
apply it barring any objections from Russell.
^ permalink raw reply
* Re: [PATCH] This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuff
From: Paul Mundt @ 2011-06-24 8:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1308834989-28712-1-git-send-email-william.katsak@alcatel-lucent.com>
On Thu, Jun 23, 2011 at 09:16:29AM -0400, William Katsak wrote:
> The situation in which the problem occurred was with a Plugable UGA-2K-A
> connected to a Samsung EX2220X display. The driver indicates that
> 1920x1080 is a valid mode (the first mode available, in fact), but
> proceeds to set the framebuffer size to 1600x1200.
>
> The patch corrects what seems to be a logic error, regarding unsetting
> the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid.
> The existing code unset the flag if ANY mode was invalid.
>
> Signed-off-by: William Katsak <william.katsak@alcatel-lucent.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove check for pixel clock ranges
From: Paul Mundt @ 2011-06-24 8:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, agust, yorksun
In-Reply-To: <1308860426-17920-1-git-send-email-timur@freescale.com>
On Thu, Jun 23, 2011 at 03:20:26PM -0500, Timur Tabi wrote:
> The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
> MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
> the pixel clock. These values, however, are true only for one platform
> clock rate (533MHz) and only for the MPC8610. So the actual range for
> the pixel clock is chip-specific, which means the current values are almost
> always wrong. The chance of an out-of-range pixel clock being used are also
> remote.
>
> Rather than try to detect an out-of-range clock in the DIU driver, we depend
> on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
> to clamp the pixel clock to a supported value.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] video: Fix speficied typo
From: Paul Mundt @ 2011-06-24 8:15 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <0b04217b5939dd9c5164913e9d2f9fde98e26e5c.1308868289.git.joe@perches.com>
On Thu, Jun 23, 2011 at 03:35:19PM -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/controlfb.c | 2 +-
> drivers/video/platinumfb.c | 2 +-
> drivers/video/pm2fb.c | 2 +-
> drivers/video/pm3fb.c | 2 +-
> drivers/video/s3fb.c | 2 +-
> drivers/video/skeletonfb.c | 2 +-
> drivers/video/valkyriefb.c | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 18/37] Remove unneeded version.h includes from drivers/video/
From: Paul Mundt @ 2011-06-24 8:17 UTC (permalink / raw)
To: Jesper Juhl
Cc: LKML, trivial, Michael Hennerich, Richard Purdie,
device-drivers-devel, linux-fbdev
In-Reply-To: <alpine.LNX.2.00.1106240032560.17688@swampdragon.chaosbits.net>
On Fri, Jun 24, 2011 at 12:35:17AM +0200, Jesper Juhl wrote:
> It was pointed out by 'make versioncheck' that some includes of
> linux/version.h are not needed in drivers/video/.
> This patch removes them.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> drivers/video/backlight/adp8860_bl.c | 1 -
> drivers/video/backlight/adp8870_bl.c | 1 -
> drivers/video/pxa3xx-gcu.c | 2 --
> drivers/video/xilinxfb.c | 1 -
> 4 files changed, 0 insertions(+), 5 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ARM: amba: Link fb device to its parent
From: Russell King - ARM Linux @ 2011-06-24 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110624080721.GC24184@linux-sh.org>
On Fri, Jun 24, 2011 at 05:07:21PM +0900, Paul Mundt wrote:
> On Mon, Jun 20, 2011 at 10:44:17PM +0200, Lo??c Minier wrote:
> > Some pieces of userspace like debian-installer expect to find the fb0
> > driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
> > this was broken with amba-clcd as it sets up fb_info manually and missed
> > the .device parent pointer.
> >
> > Signed-off-by: Lo??c Minier <loic.minier@linaro.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Paul Mundt <lethal@linux-sh.org>
> > ---
> > drivers/video/amba-clcd.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> While this is titled as an ARM patch it's certainly fbdev-specific. I'll
> apply it barring any objections from Russell.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* Re: [PATCH] ARM: amba: Link fb device to its parent
From: Nicolas Pitre @ 2011-06-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110624080721.GC24184@linux-sh.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1000 bytes --]
On Fri, 24 Jun 2011, Paul Mundt wrote:
> On Mon, Jun 20, 2011 at 10:44:17PM +0200, Lo??c Minier wrote:
> > Some pieces of userspace like debian-installer expect to find the fb0
> > driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
> > this was broken with amba-clcd as it sets up fb_info manually and missed
> > the .device parent pointer.
> >
> > Signed-off-by: Lo??c Minier <loic.minier@linaro.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Paul Mundt <lethal@linux-sh.org>
> > ---
> > drivers/video/amba-clcd.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> While this is titled as an ARM patch it's certainly fbdev-specific. I'll
> apply it barring any objections from Russell.
BTW this should be "Loïc Minier" not "Lo??c Minier" The original email
was fine with proper UTF-8 in that regard. Maybe you should have a look
at your MUA config so the resulting patch log going into git is not
dammaged.
Nicolas
^ permalink raw reply
* [PATCH] backlight: l4f00242t03: Use gpio_request_one to simplify error handling
From: Fabio Estevam @ 2011-06-24 18:26 UTC (permalink / raw)
To: linux-fbdev
Using gpio_request_one can make the error handling simpler.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/backlight/l4f00242t03.c | 17 +++++------------
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/l4f00242t03.c b/drivers/video/backlight/l4f00242t03.c
index 98ad3e5..d6b0812 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -178,29 +178,22 @@ static int __devinit l4f00242t03_probe(struct spi_device *spi)
priv->spi = spi;
- ret = gpio_request(pdata->reset_gpio, "lcd l4f00242t03 reset");
+ ret = gpio_request_one(pdata->reset_gpio, GPIOF_OUT_INIT_HIGH,
+ "lcd l4f00242t03 reset");
if (ret) {
dev_err(&spi->dev,
"Unable to get the lcd l4f00242t03 reset gpio.\n");
goto err;
}
- ret = gpio_direction_output(pdata->reset_gpio, 1);
- if (ret)
- goto err2;
-
- ret = gpio_request(pdata->data_enable_gpio,
- "lcd l4f00242t03 data enable");
+ ret = gpio_request_one(pdata->data_enable_gpio, GPIOF_OUT_INIT_LOW,
+ "lcd l4f00242t03 data enable");
if (ret) {
dev_err(&spi->dev,
"Unable to get the lcd l4f00242t03 data en gpio.\n");
goto err2;
}
-
- ret = gpio_direction_output(pdata->data_enable_gpio, 0);
- if (ret)
- goto err3;
-
+
if (pdata->io_supply) {
priv->io_reg = regulator_get(NULL, pdata->io_supply);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-06-24 18:55 UTC (permalink / raw)
To: Paul Mundt
Cc: Florian Tobias Schandinat, Laurent Pinchart, linux-fbdev,
linux-media, dri-devel
In-Reply-To: <20110624061926.GA26504@linux-sh.org>
On Fri, Jun 24, 2011 at 08:19, Paul Mundt <lethal@linux-sh.org> wrote:
> On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
>> <FlorianSchandinat@gmx.de> wrote:
>> > On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
>> >> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
>> >>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
>> >>> be non-zero), I don't think there are any conflicts with existing values
>> >>> of
>> >>> nonstd. To make it even safer and easier to parse, you could set bit 31
>> >>> of
>> >>> nonstd as a FOURCC indicator.
>> >>
>> >> I would then create a union between nonstd and fourcc, and document nonstd
>> >> as
>> >> being used for the legacy API only. Most existing drivers use a couple of
>> >> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
>> >> uses
>> >> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
>> >> 0xff000000 != 0 could be used as a FOURCC mode test.
>> >>
>> >> This assumes that FOURCCs will never have their last character set to
>> >> '\0'. Is
>> >> that a safe assumption for the future ?
>> >
>> > Yes, I think. The information I found indicates that space should be used
>> > for padding, so a \0 shouldn't exist.
>> > I think using only the nonstd field and requiring applications to check the
>> > capabilities would be possible, although not fool proof ;)
>>
>> So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
>> any of them is set.
>>
>> Nicely backwards compatible, as sane drivers should reject nonstd values they
>> don't support (apps _will_ start filling in FOURCC values ignoring capabilities,
>> won't they?).
>>
> That seems like a reasonable case, but if we're going to do that then
> certainly the nonstd bit encoding needs to be documented and treated as a
> hard ABI.
>
> I'm not so sure about the if any bit in the upper byte is set assume
> FOURCC case though, there will presumably be other users in the future
> that will want bits for themselves, too. What exactly was the issue with
> having a FOURCC capability bit in the upper byte?
That indeed gives less issues (as long as you don't stuff 8-bit ASCII
in the MSB)
and more bits for tradiditional nonstd users.
BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
us? It's not like all drivers will support whatever random FOURCC mode
you give them,
so you have to check whether it's supported by doing a set_var first.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Florian Tobias Schandinat @ 2011-06-24 19:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Paul Mundt, Laurent Pinchart, linux-fbdev, linux-media, dri-devel
In-Reply-To: <BANLkTi=RCx9Bifpw9BvqNAB0J+1ENkRK4A@mail.gmail.com>
On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> On Fri, Jun 24, 2011 at 08:19, Paul Mundt<lethal@linux-sh.org> wrote:
>> On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
>>> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
>>> <FlorianSchandinat@gmx.de> wrote:
>>>> On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
>>>>> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
>>>>>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
>>>>>> be non-zero), I don't think there are any conflicts with existing values
>>>>>> of
>>>>>> nonstd. To make it even safer and easier to parse, you could set bit 31
>>>>>> of
>>>>>> nonstd as a FOURCC indicator.
>>>>>
>>>>> I would then create a union between nonstd and fourcc, and document nonstd
>>>>> as
>>>>> being used for the legacy API only. Most existing drivers use a couple of
>>>>> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
>>>>> uses
>>>>> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
>>>>> 0xff000000 != 0 could be used as a FOURCC mode test.
>>>>>
>>>>> This assumes that FOURCCs will never have their last character set to
>>>>> '\0'. Is
>>>>> that a safe assumption for the future ?
>>>>
>>>> Yes, I think. The information I found indicates that space should be used
>>>> for padding, so a \0 shouldn't exist.
>>>> I think using only the nonstd field and requiring applications to check the
>>>> capabilities would be possible, although not fool proof ;)
>>>
>>> So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
>>> any of them is set.
>>>
>>> Nicely backwards compatible, as sane drivers should reject nonstd values they
>>> don't support (apps _will_ start filling in FOURCC values ignoring capabilities,
>>> won't they?).
>>>
>> That seems like a reasonable case, but if we're going to do that then
>> certainly the nonstd bit encoding needs to be documented and treated as a
>> hard ABI.
>>
>> I'm not so sure about the if any bit in the upper byte is set assume
>> FOURCC case though, there will presumably be other users in the future
>> that will want bits for themselves, too. What exactly was the issue with
>> having a FOURCC capability bit in the upper byte?
>
> That indeed gives less issues (as long as you don't stuff 8-bit ASCII
> in the MSB)
> and more bits for tradiditional nonstd users.
The only disadvantage I can see is that it requires adding this bit in the
application and stripping it when interpreting it. But I think the 24 lower bits
should be enough for driver specific behavior (as the current values really can
only be interpreted per driver).
> BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
> us? It's not like all drivers will support whatever random FOURCC mode
> you give them,
> so you have to check whether it's supported by doing a set_var first.
Because any solution purely based on the nonstd field is insane. The abuse of
that field is just too widespread. Drivers that use nonstd usually only check
whether it is zero or nonzero and others will just interpret parts of nonstd and
ignore the rest. They will happily accept FOURCC values in the nonstd and just
doing the wrong thing. Even if we would fix those the problems applications will
run into with older kernels will remain.
Greetings,
Florian Tobias Schandinat
^ permalink raw reply
* WESTERN UNION 5000.00USD URGENT PICK UP
From: WESTERN UNION MONEY TRANSFER @ 2011-06-25 15:37 UTC (permalink / raw)
To: info
--
How are you doing today?
I write to inform you that we have already sent you $5000.00USD dollars through Western union as we have been given the mandate to transfer your full benefited sum of $1,800,000.00USD via our office here (Western Union) by the United nations in conjunction with the Nigeria Government as a compensation.
I called to give you the information through phone as internet hackers were many but i cannot reach you yesterday even this morning.So,I decided to email you the MTCN and sender name so that can pick up this $5000.00USD to enable us send another $5000.00USD by tomorrow as you knows we will be sending you only $5000.00USD per day.
Kindly pick up this information and hurry up to the nearest western union money office that is close to you and pick up this first payment that has been sent to you now and as soon as you are done with the pick up kindly get back to us in order for us to send you another payment by tomorrow,as you know that we shall be sending you $5000USD par day.
Manager :Mrs.Anita Daniel
Email: w.westernmoneytransfer@yahoo.com.hk
Email me once you picked up this $5000.00USD today.
Here is the western union information to pick up the $5000.00USD,
Payment Information.
MTCN :_______________853-435-9544
Sender's Name:_________Rose Micheal
Text Question:__________What
Answer:_______________Blue
Amount Sent___________$5000.00USD
Country:_______________Nigeria
With due respect please get back to us urgently after the pick of the money and
if you have any problem you can as well contact us immediately.
Thanks
Mrs. Anita Daniel.
western union Office.
^ permalink raw reply
* Re: [PATCH] ARM: amba: Link fb device to its parent
From: Paul Mundt @ 2011-06-26 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1106240949590.2142@xanadu.home>
On Fri, Jun 24, 2011 at 09:57:06AM -0400, Nicolas Pitre wrote:
> On Fri, 24 Jun 2011, Paul Mundt wrote:
>
> > On Mon, Jun 20, 2011 at 10:44:17PM +0200, Lo??c Minier wrote:
> > > Some pieces of userspace like debian-installer expect to find the fb0
> > > driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
> > > this was broken with amba-clcd as it sets up fb_info manually and missed
> > > the .device parent pointer.
> > >
> > > Signed-off-by: Lo??c Minier <loic.minier@linaro.org>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Paul Mundt <lethal@linux-sh.org>
> > > ---
> > > drivers/video/amba-clcd.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > While this is titled as an ARM patch it's certainly fbdev-specific. I'll
> > apply it barring any objections from Russell.
>
> BTW this should be "Lo?c Minier" not "Lo??c Minier" The original email
> was fine with proper UTF-8 in that regard. Maybe you should have a look
> at your MUA config so the resulting patch log going into git is not
> dammaged.
>
My MUA ignores UTF-8 intentionally, but this has no bearing on the status
in my git tree.
^ permalink raw reply
* Re: [PATCH] udlfb.c dlfb_ops_ioctl - missing copy_from_user's - NEEDS TESTING
From: Bernie Thompson @ 2011-06-26 18:12 UTC (permalink / raw)
To: linux-fbdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 4378 bytes --]
On Mon, Apr 4, 2011 at 5:02 PM, Dr. David Alan Gilbert
<linux@treblig.org> wrote:
> Â Â Fix __user casting in dlfb_ops_ioctl and a missing copy_from_user, and a missing &
>
> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
> ---
>
> NOTE! I don't have the hardware to test this; but Bernie suggested I put the
> patch together anyway; build and Sparse tested only -** Â don't **
> merge without a test by a udl dev
>
This patch was merged into the udlfb development branch and has gotten several
weeks of testing now, without problems. We'd like to see it get merged. Thanks!
> Patch is against ecb78ab6f30106ab72a575a25b1cdfd1633b7ca2 on Linus's tree
> a few days after 39-rc1
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index 2c8364e..ef7801a 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -751,14 +751,13 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
> Â {
>
> Â Â Â Â struct dlfb_data *dev = info->par;
> - Â Â Â struct dloarea *area = NULL;
>
> Â Â Â Â if (!atomic_read(&dev->usb_active))
> Â Â Â Â Â Â Â Â return 0;
>
> Â Â Â Â /* TODO: Update X server to get this from sysfs instead */
> Â Â Â Â if (cmd = DLFB_IOCTL_RETURN_EDID) {
> - Â Â Â Â Â Â Â char *edid = (char *)arg;
> + Â Â Â Â Â Â Â void __user *edid = (void __user *)arg;
> Â Â Â Â Â Â Â Â if (copy_to_user(edid, dev->edid, dev->edid_size))
> Â Â Â Â Â Â Â Â Â Â Â Â return -EFAULT;
> Â Â Â Â Â Â Â Â return 0;
> @@ -766,6 +765,11 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
>
> Â Â Â Â /* TODO: Help propose a standard fb.h ioctl to report mmap damage */
> Â Â Â Â if (cmd = DLFB_IOCTL_REPORT_DAMAGE) {
> + Â Â Â Â Â Â Â struct dloarea area;
> +
> + Â Â Â Â Â Â Â if (copy_from_user(&area, (void __user *)arg,
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â sizeof(struct dloarea)))
> + Â Â Â Â Â Â Â Â Â Â Â return -EFAULT;
>
> Â Â Â Â Â Â Â Â /*
> Â Â Â Â Â Â Â Â * If we have a damage-aware client, turn fb_defio "off"
> @@ -777,21 +781,19 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
> Â Â Â Â Â Â Â Â if (info->fbdefio)
> Â Â Â Â Â Â Â Â Â Â Â Â info->fbdefio->delay = DL_DEFIO_WRITE_DISABLE;
>
> - Â Â Â Â Â Â Â area = (struct dloarea *)arg;
> -
> - Â Â Â Â Â Â Â if (area->x < 0)
> - Â Â Â Â Â Â Â Â Â Â Â area->x = 0;
> + Â Â Â Â Â Â Â if (area.x < 0)
> + Â Â Â Â Â Â Â Â Â Â Â area.x = 0;
>
> - Â Â Â Â Â Â Â if (area->x > info->var.xres)
> - Â Â Â Â Â Â Â Â Â Â Â area->x = info->var.xres;
> + Â Â Â Â Â Â Â if (area.x > info->var.xres)
> + Â Â Â Â Â Â Â Â Â Â Â area.x = info->var.xres;
>
> - Â Â Â Â Â Â Â if (area->y < 0)
> - Â Â Â Â Â Â Â Â Â Â Â area->y = 0;
> + Â Â Â Â Â Â Â if (area.y < 0)
> + Â Â Â Â Â Â Â Â Â Â Â area.y = 0;
>
> - Â Â Â Â Â Â Â if (area->y > info->var.yres)
> - Â Â Â Â Â Â Â Â Â Â Â area->y = info->var.yres;
> + Â Â Â Â Â Â Â if (area.y > info->var.yres)
> + Â Â Â Â Â Â Â Â Â Â Â area.y = info->var.yres;
>
> - Â Â Â Â Â Â Â dlfb_handle_damage(dev, area->x, area->y, area->w, area->h,
> + Â Â Â Â Â Â Â dlfb_handle_damage(dev, area.x, area.y, area.w, area.h,
> Â Â Â Â Â Â Â Â Â Â Â Â Â info->screen_base);
> Â Â Â Â }
>
> @@ -839,7 +841,7 @@ static int dlfb_ops_open(struct fb_info *info, int user)
> Â Â Â Â * preventing other clients (X) from working properly. Usually
> Â Â Â Â * not what the user wants. Fail by default with option to enable.
> Â Â Â Â */
> - Â Â Â if ((user = 0) & (!console))
> + Â Â Â if ((user = 0) && (!console))
> Â Â Â Â Â Â Â Â return -EBUSY;
>
> Â Â Â Â /* If the USB device is gone, we don't accept new opens */
> --
> Â -----Open up your eyes, open up your mind, open up your code -------
> / Dr. David Alan Gilbert   |    Running GNU/Linux    | Happy  \
> \ gro.gilbert @ treblig.org | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | In Hex /
>  \ _________________________|_____ http://www.treblig.org  |_______/
>
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* [PATCH] video: da8xx-fb: Interrupt configuration of revised LCDC IP
From: Manjunathappa, Prakash @ 2011-06-27 5:07 UTC (permalink / raw)
To: linux-fbdev
Interrupt configuration support for revised LCDC IP of DA850 in
upcoming SOC from TI.
The revised LCDC IP differs in interrupt configuration; registers
for setting and clearing interrupts, raw and masked status registers
to depict raw and enabled interrupts status.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/video/da8xx-fb.c | 153 +++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 144 insertions(+), 9 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index fcdac87..0e02665 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -35,6 +35,9 @@
#define DRIVER_NAME "da8xx_lcdc"
+#define LCD_VERSION_1 1
+#define LCD_VERSION_2 2
+
/* LCD Status Register */
#define LCD_END_OF_FRAME1 BIT(9)
#define LCD_END_OF_FRAME0 BIT(8)
@@ -49,7 +52,9 @@
#define LCD_DMA_BURST_4 0x2
#define LCD_DMA_BURST_8 0x3
#define LCD_DMA_BURST_16 0x4
-#define LCD_END_OF_FRAME_INT_ENA BIT(2)
+#define LCD_V1_END_OF_FRAME_INT_ENA BIT(2)
+#define LCD_V2_END_OF_FRAME0_INT_ENA BIT(8)
+#define LCD_V2_END_OF_FRAME1_INT_ENA BIT(9)
#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0)
/* LCD Control Register */
@@ -65,12 +70,18 @@
#define LCD_MONO_8BIT_MODE BIT(9)
#define LCD_RASTER_ORDER BIT(8)
#define LCD_TFT_MODE BIT(7)
-#define LCD_UNDERFLOW_INT_ENA BIT(6)
-#define LCD_PL_ENABLE BIT(4)
+#define LCD_V1_UNDERFLOW_INT_ENA BIT(6)
+#define LCD_V2_UNDERFLOW_INT_ENA BIT(5)
+#define LCD_V1_PL_INT_ENA BIT(4)
+#define LCD_V2_PL_INT_ENA BIT(6)
#define LCD_MONOCHROME_MODE BIT(1)
#define LCD_RASTER_ENABLE BIT(0)
#define LCD_TFT_ALT_ENABLE BIT(23)
#define LCD_STN_565_ENABLE BIT(24)
+#define LCD_V2_DMA_CLK_EN BIT(2)
+#define LCD_V2_LIDD_CLK_EN BIT(1)
+#define LCD_V2_CORE_CLK_EN BIT(0)
+#define LCD_V2_LPP_B10 26
/* LCD Raster Timing 2 Register */
#define LCD_AC_BIAS_TRANSITIONS_PER_INT(x) ((x) << 16)
@@ -82,6 +93,7 @@
#define LCD_INVERT_FRAME_CLOCK BIT(20)
/* LCD Block */
+#define LCD_PID_REG 0x0
#define LCD_CTRL_REG 0x4
#define LCD_STAT_REG 0x8
#define LCD_RASTER_CTRL_REG 0x28
@@ -94,6 +106,17 @@
#define LCD_DMA_FRM_BUF_BASE_ADDR_1_REG 0x4C
#define LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG 0x50
+/* Interrupt Registers available only in Version 2 */
+#define LCD_RAW_STAT_REG 0x58
+#define LCD_MASKED_STAT_REG 0x5c
+#define LCD_INT_ENABLE_SET_REG 0x60
+#define LCD_INT_ENABLE_CLR_REG 0x64
+#define LCD_END_OF_INT_IND_REG 0x68
+
+/* Clock registers available only on Version 2 */
+#define LCD_CLK_ENABLE_REG 0x6c
+#define LCD_CLK_RESET_REG 0x70
+
#define LCD_NUM_BUFFERS 2
#define WSI_TIMEOUT 50
@@ -105,6 +128,8 @@
static resource_size_t da8xx_fb_reg_base;
static struct resource *lcdc_regs;
+static unsigned int lcd_revision;
+static irq_handler_t lcdc_irq_handler;
static inline unsigned int lcdc_read(unsigned int addr)
{
@@ -240,6 +265,7 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
u32 end;
u32 reg_ras;
u32 reg_dma;
+ u32 reg_int;
/* init reg to clear PLM (loading mode) fields */
reg_ras = lcdc_read(LCD_RASTER_CTRL_REG);
@@ -252,7 +278,14 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
end = par->dma_end;
reg_ras |= LCD_PALETTE_LOAD_MODE(DATA_ONLY);
- reg_dma |= LCD_END_OF_FRAME_INT_ENA;
+ if (lcd_revision = LCD_VERSION_1) {
+ reg_dma |= LCD_V1_END_OF_FRAME_INT_ENA;
+ } else {
+ reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) |
+ LCD_V2_END_OF_FRAME0_INT_ENA |
+ LCD_V2_END_OF_FRAME1_INT_ENA;
+ lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG);
+ }
reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE;
lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
@@ -264,7 +297,14 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
end = start + par->palette_sz - 1;
reg_ras |= LCD_PALETTE_LOAD_MODE(PALETTE_ONLY);
- reg_ras |= LCD_PL_ENABLE;
+
+ if (lcd_revision = LCD_VERSION_1) {
+ reg_ras |= LCD_V1_PL_INT_ENA;
+ } else {
+ reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) |
+ LCD_V2_PL_INT_ENA;
+ lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG);
+ }
lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
@@ -348,6 +388,7 @@ static void lcd_cfg_vertical_sync(int back_porch, int pulse_width,
static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
{
u32 reg;
+ u32 reg_int;
reg = lcdc_read(LCD_RASTER_CTRL_REG) & ~(LCD_TFT_MODE |
LCD_MONO_8BIT_MODE |
@@ -375,7 +416,13 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
}
/* enable additional interrupts here */
- reg |= LCD_UNDERFLOW_INT_ENA;
+ if (lcd_revision = LCD_VERSION_1) {
+ reg |= LCD_V1_UNDERFLOW_INT_ENA;
+ } else {
+ reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) |
+ (LCD_V2_UNDERFLOW_INT_ENA);
+ lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG);
+ }
lcdc_write(reg, LCD_RASTER_CTRL_REG);
@@ -415,12 +462,14 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
/* Pixels per line = (PPL + 1)*16 */
/*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
width &= 0x3f0;
+
reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
reg &= 0xfffffc00;
reg |= ((width >> 4) - 1) << 4;
lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
/* Set the Panel Height */
+
reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
@@ -511,6 +560,9 @@ static void lcd_reset(struct da8xx_fb_par *par)
/* DMA has to be disabled */
lcdc_write(0, LCD_DMA_CTRL_REG);
lcdc_write(0, LCD_RASTER_CTRL_REG);
+
+ if (lcd_revision = LCD_VERSION_2)
+ lcdc_write(0, LCD_INT_ENABLE_SET_REG);
}
static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
@@ -523,6 +575,11 @@ static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE & 0x1), LCD_CTRL_REG);
+
+ if (lcd_revision = LCD_VERSION_2)
+ lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
+ LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
@@ -583,7 +640,63 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
return 0;
}
-static irqreturn_t lcdc_irq_handler(int irq, void *arg)
+/* IRQ handler for version 2 of LCDC */
+static irqreturn_t lcdc_irq_handler_rev02(int irq, void *arg)
+{
+ struct da8xx_fb_par *par = arg;
+ u32 stat = lcdc_read(LCD_MASKED_STAT_REG);
+ u32 reg_int;
+
+ if ((stat & LCD_SYNC_LOST) && (stat & LCD_FIFO_UNDERFLOW)) {
+ lcd_disable_raster();
+ lcdc_write(stat, LCD_MASKED_STAT_REG);
+ lcd_enable_raster();
+ } else if (stat & LCD_PL_LOAD_DONE) {
+ /*
+ * Must disable raster before changing state of any control bit.
+ * And also must be disabled before clearing the PL loading
+ * interrupt via the following write to the status register. If
+ * this is done after then one gets multiple PL done interrupts.
+ */
+ lcd_disable_raster();
+
+ lcdc_write(stat, LCD_MASKED_STAT_REG);
+
+ /* Disable PL completion inerrupt */
+ reg_int = lcdc_read(LCD_INT_ENABLE_CLR_REG) |
+ (LCD_V2_PL_INT_ENA);
+ lcdc_write(reg_int, LCD_INT_ENABLE_CLR_REG);
+
+ /* Setup and start data loading mode */
+ lcd_blit(LOAD_DATA, par);
+ } else {
+ lcdc_write(stat, LCD_MASKED_STAT_REG);
+
+ if (stat & LCD_END_OF_FRAME0) {
+ lcdc_write(par->dma_start,
+ LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+ lcdc_write(par->dma_end,
+ LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+ par->vsync_flag = 1;
+ wake_up_interruptible(&par->vsync_wait);
+ }
+
+ if (stat & LCD_END_OF_FRAME1) {
+ lcdc_write(par->dma_start,
+ LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+ lcdc_write(par->dma_end,
+ LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+ par->vsync_flag = 1;
+ wake_up_interruptible(&par->vsync_wait);
+ }
+ }
+
+ lcdc_write(0, LCD_END_OF_INT_IND_REG);
+ return IRQ_HANDLED;
+}
+
+/* IRQ handler for version 1 LCDC */
+static irqreturn_t lcdc_irq_handler_rev01(int irq, void *arg)
{
struct da8xx_fb_par *par = arg;
u32 stat = lcdc_read(LCD_STAT_REG);
@@ -606,7 +719,7 @@ static irqreturn_t lcdc_irq_handler(int irq, void *arg)
/* Disable PL completion inerrupt */
reg_ras = lcdc_read(LCD_RASTER_CTRL_REG);
- reg_ras &= ~LCD_PL_ENABLE;
+ reg_ras &= ~LCD_V1_PL_INT_ENA;
lcdc_write(reg_ras, LCD_RASTER_CTRL_REG);
/* Setup and start data loading mode */
@@ -945,6 +1058,22 @@ static int __devinit fb_probe(struct platform_device *device)
if (ret)
goto err_clk_put;
+ /* Determine LCD IP Version */
+ switch (lcdc_read(LCD_PID_REG)) {
+ case 0x4C100102:
+ lcd_revision = LCD_VERSION_1;
+ break;
+ case 0x4F200800:
+ lcd_revision = LCD_VERSION_2;
+ break;
+ default:
+ dev_warn(&device->dev, "Unknown PID Reg value 0x%x, "
+ "defaulting to LCD revision 1\n",
+ lcdc_read(LCD_PID_REG));
+ lcd_revision = LCD_VERSION_1;
+ break;
+ }
+
for (i = 0, lcdc_info = known_lcd_panels;
i < ARRAY_SIZE(known_lcd_panels);
i++, lcdc_info++) {
@@ -1085,7 +1214,13 @@ static int __devinit fb_probe(struct platform_device *device)
}
#endif
- ret = request_irq(par->irq, lcdc_irq_handler, 0, DRIVER_NAME, par);
+ if (lcd_revision = LCD_VERSION_1)
+ lcdc_irq_handler = lcdc_irq_handler_rev01;
+ else
+ lcdc_irq_handler = lcdc_irq_handler_rev02;
+
+ ret = request_irq(par->irq, lcdc_irq_handler, 0,
+ DRIVER_NAME, par);
if (ret)
goto irq_freq;
return 0;
--
1.7.1
^ permalink raw reply related
* [PATCH] video: da8xx-fb: Increased resolution configuration of revised LCDC IP
From: Manjunathappa, Prakash @ 2011-06-27 5:08 UTC (permalink / raw)
To: linux-fbdev
Revised LCDC IP of DA850 supports 2048*2048 resolution. Below are the
encoding details:
Width:
Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
Where pplmsb:1bit=>Raster Timing0[3], ppllsb:6bits=>Raster Timing0[9:4].
And encoded value can range from 16 to 2048 in multiples of 16.
Height:
Lines Per Panel = {lpp_b10, lpp}
Where lpp:10bits=>Raster Timing1[9:0], lpp_b10:1bit=>Raster Timing2[26].
And encoded value can range from 1 to 2048, programmable range is 0 to
2047.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/video/da8xx-fb.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0e02665..367d839 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -460,20 +460,44 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
/* Set the Panel Width */
/* Pixels per line = (PPL + 1)*16 */
- /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
- width &= 0x3f0;
+ if (lcd_revision = LCD_VERSION_1) {
+ /*
+ * 0x3F in bits 4..9 gives max horizontal resolution = 1024
+ * pixels.
+ */
+ width &= 0x3f0;
+ } else {
+ /*
+ * 0x7F in bits 3..9 gives max horizontal resolution = 2048
+ * pixels.
+ */
+ width &= 0x7f0;
+ }
reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
reg &= 0xfffffc00;
- reg |= ((width >> 4) - 1) << 4;
+ if (lcd_revision = LCD_VERSION_1) {
+ reg |= ((width >> 4) - 1) << 4;
+ } else {
+ width = ((width >> 4) - 1);
+ reg |= ((width & 0x3f) << 4) | ((width & 0x40) >> 3);
+ }
lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
/* Set the Panel Height */
+ /* Set bits 9:0 of Lines Per Pixel */
reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
+ /* Set bit 10 of Lines Per Pixel */
+ if (lcd_revision = LCD_VERSION_2) {
+ reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
+ reg |= (((height - 1) & 0x40) << 20);
+ lcdc_write(reg, LCD_RASTER_TIMING_2_REG);
+ }
+
/* Set the Raster Order of the Frame Buffer */
reg = lcdc_read(LCD_RASTER_CTRL_REG) & ~(1 << 8);
if (raster_order)
--
1.7.1
^ permalink raw reply related
* [PATCH V7 1/5] ARM: EXYNOS4: Change clock name for FIMD
From: Jingoo Han @ 2011-06-27 10:49 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev,
Jonghun Han
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jingoo Han
This patch changes clock name for FIMD from "fimd" to "lcd".
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/clock.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 871f9d5..12e6853 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -433,12 +433,12 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit = (1 << 3),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 0,
.enable = exynos4_clk_ip_lcd0_ctrl,
.ctrlbit = (1 << 0),
}, {
- .name = "fimd",
+ .name = "lcd",
.id = 1,
.enable = exynos4_clk_ip_lcd1_ctrl,
.ctrlbit = (1 << 0),
--
1.7.1
^ permalink raw reply related
* [PATCH V7 2/5] ARM: EXYNOS4: Add FIMD resource definition
From: Jingoo Han @ 2011-06-27 10:50 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jonghun Han, Jingoo Han
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds resource definitions for EXYNOS4 FIMD.
IRQ and SFR definitions are added.
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/include/mach/irqs.h | 8 ++++++++
arch/arm/mach-exynos4/include/mach/map.h | 5 +++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-exynos4/include/mach/irqs.h
index 5d03730..2cd2090 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -73,6 +73,14 @@
#define IRQ_SYSMMU_MFC_M1_0 COMBINER_IRQ(5, 6)
#define IRQ_SYSMMU_PCIE_0 COMBINER_IRQ(5, 7)
+#define IRQ_FIMD0_FIFO COMBINER_IRQ(11, 0)
+#define IRQ_FIMD0_VSYNC COMBINER_IRQ(11, 1)
+#define IRQ_FIMD0_SYSTEM COMBINER_IRQ(11, 2)
+
+#define IRQ_FIMD1_FIFO COMBINER_IRQ(12, 0)
+#define IRQ_FIMD1_VSYNC COMBINER_IRQ(12, 1)
+#define IRQ_FIMD1_SYSTEM COMBINER_IRQ(12, 2)
+
#define IRQ_PDMA0 COMBINER_IRQ(21, 0)
#define IRQ_PDMA1 COMBINER_IRQ(21, 1)
diff --git a/arch/arm/mach-exynos4/include/mach/map.h b/arch/arm/mach-exynos4/include/mach/map.h
index 0009e77..94006f7 100644
--- a/arch/arm/mach-exynos4/include/mach/map.h
+++ b/arch/arm/mach-exynos4/include/mach/map.h
@@ -93,6 +93,9 @@
#define EXYNOS4_PA_MIPI_CSIS0 0x11880000
#define EXYNOS4_PA_MIPI_CSIS1 0x11890000
+#define EXYNOS4_PA_FIMD0 0x11C00000
+#define EXYNOS4_PA_FIMD1 0x12000000
+
#define EXYNOS4_PA_HSMMC(x) (0x12510000 + ((x) * 0x10000))
#define EXYNOS4_PA_SATA 0x12560000
@@ -140,6 +143,8 @@
#define S5P_PA_FIMC3 EXYNOS4_PA_FIMC3
#define S5P_PA_MIPI_CSIS0 EXYNOS4_PA_MIPI_CSIS0
#define S5P_PA_MIPI_CSIS1 EXYNOS4_PA_MIPI_CSIS1
+#define S5P_PA_FIMD0 EXYNOS4_PA_FIMD0
+#define S5P_PA_FIMD1 EXYNOS4_PA_FIMD1
#define S5P_PA_ONENAND EXYNOS4_PA_ONENAND
#define S5P_PA_ONENAND_DMA EXYNOS4_PA_ONENAND_DMA
#define S5P_PA_SDRAM EXYNOS4_PA_SDRAM
--
1.7.1
^ permalink raw reply related
* [PATCH V7 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD
From: Jingoo Han @ 2011-06-27 10:50 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jonghun Han, Jingoo Han
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds platform device s5p_device_fimd0 for EXYNOS4 FIMD0.
EXYNOS4 has two FIMDs(FIMD0, FIMD1). FIMD1 will be added later.
Some definitions used to enable EXYNOS4 FIMD0 are added.
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mach-exynos4/Kconfig | 9 ++++
arch/arm/mach-exynos4/Makefile | 1 +
arch/arm/mach-exynos4/cpu.c | 4 +-
arch/arm/mach-exynos4/include/mach/regs-fb.h | 21 ++++++++
arch/arm/mach-exynos4/setup-fimd0.c | 48 ++++++++++++++++++
arch/arm/plat-s5p/Kconfig | 5 ++
arch/arm/plat-s5p/Makefile | 1 +
arch/arm/plat-s5p/dev-fimd0.c | 67 ++++++++++++++++++++++++++
arch/arm/plat-samsung/include/plat/devs.h | 1 +
arch/arm/plat-samsung/include/plat/fb-core.h | 15 ++++++
arch/arm/plat-samsung/include/plat/fb.h | 15 ++++++
11 files changed, 186 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-exynos4/include/mach/regs-fb.h
create mode 100644 arch/arm/mach-exynos4/setup-fimd0.c
create mode 100644 arch/arm/plat-s5p/dev-fimd0.c
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 1435fc3..2024f50 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -25,6 +25,11 @@ config EXYNOS4_DEV_AHCI
help
Compile in platform device definitions for AHCI
+config EXYNOS4_SETUP_FIMD0
+ bool
+ help
+ Common setup code for FIMD0.
+
config EXYNOS4_DEV_PD
bool
help
@@ -103,6 +108,7 @@ menu "EXYNOS4 Machines"
config MACH_SMDKC210
bool "SMDKC210"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
@@ -112,6 +118,7 @@ config MACH_SMDKC210
select S3C_DEV_HSMMC3
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_SDHCI
help
@@ -120,6 +127,7 @@ config MACH_SMDKC210
config MACH_SMDKV310
bool "SMDKV310"
select CPU_EXYNOS4210
+ select S5P_DEV_FIMD0
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
@@ -130,6 +138,7 @@ config MACH_SMDKV310
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_KEYPAD
select EXYNOS4_SETUP_SDHCI
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 60fe5ec..96472f1 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
+obj-$(CONFIG_EXYNOS4_SETUP_FIMD0) += setup-fimd0.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C2) += setup-i2c2.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C3) += setup-i2c3.o
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 9babe44..778a5b0 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -19,9 +19,10 @@
#include <plat/cpu.h>
#include <plat/clock.h>
+#include <plat/devs.h>
+#include <plat/fb-core.h>
#include <plat/exynos4.h>
#include <plat/sdhci.h>
-#include <plat/devs.h>
#include <plat/fimc-core.h>
#include <mach/regs-irq.h>
@@ -132,6 +133,7 @@ void __init exynos4_map_io(void)
s3c_fimc_setname(1, "exynos4-fimc");
s3c_fimc_setname(2, "exynos4-fimc");
s3c_fimc_setname(3, "exynos4-fimc");
+ s5p_fb_setname(0, "exynos4-fb"); /* FIMD0 */
}
void __init exynos4_init_clocks(int xtal)
diff --git a/arch/arm/mach-exynos4/include/mach/regs-fb.h b/arch/arm/mach-exynos4/include/mach/regs-fb.h
new file mode 100644
index 0000000..f320105
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/regs-fb.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2010 Ben Dooks <ben-linux@fluff.org>
+ *
+ * Dummy framebuffer to allow build for the moment.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef __ASM_ARCH_MACH_REGS_FB_H
+#define __ASM_ARCH_MACH_REGS_FB_H __FILE__
+
+#include <plat/regs-fb-v4.h>
+
+static inline unsigned int s3c_fb_pal_reg(unsigned int window, int reg)
+{
+ return 0x2400 + (window * 256 * 4) + reg;
+}
+
+#endif /* __ASM_ARCH_MACH_REGS_FB_H */
diff --git a/arch/arm/mach-exynos4/setup-fimd0.c b/arch/arm/mach-exynos4/setup-fimd0.c
new file mode 100644
index 0000000..be58294
--- /dev/null
+++ b/arch/arm/mach-exynos4/setup-fimd0.c
@@ -0,0 +1,48 @@
+/* linux/arch/arm/mach-exynos4/setup-fimd0.c
+ *
+ * Copyright (c) 2009-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Base Exynos4 FIMD 0 configuration
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+#include <linux/clk.h>
+
+#include <plat/fb.h>
+#include <plat/gpio-cfg.h>
+
+#include <mach/regs-clock.h>
+#include <mach/regs-fb.h>
+#include <mach/map.h>
+
+void exynos4_fimd0_gpio_setup_24bpp(void)
+{
+ unsigned int reg = 0;
+
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF0(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF1(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF2(0), 8, S3C_GPIO_SFN(2));
+ s3c_gpio_cfgrange_nopull(EXYNOS4_GPF3(0), 4, S3C_GPIO_SFN(2));
+
+ /*
+ * Set DISPLAY_CONTROL register for Display path selection.
+ *
+ * DISPLAY_CONTROL[1:0]
+ * ---------------------
+ * 00 | MIE
+ * 01 | MDINE
+ * 10 | FIMD : selected
+ * 11 | FIMD
+ */
+ reg = __raw_readl(S3C_VA_SYS + 0x0210);
+ reg |= (1 << 1);
+ __raw_writel(reg, S3C_VA_SYS + 0x0210);
+}
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index e98f5c5..46de16e 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -70,6 +70,11 @@ config S5P_DEV_FIMC3
help
Compile in platform device definitions for FIMC controller 3
+config S5P_DEV_FIMD0
+ bool
+ help
+ Compile in platform device definitions for FIMD controller 0
+
config S5P_DEV_ONENAND
bool
help
diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
index e234cc4..eec7e24 100644
--- a/arch/arm/plat-s5p/Makefile
+++ b/arch/arm/plat-s5p/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_S5P_DEV_FIMC0) += dev-fimc0.o
obj-$(CONFIG_S5P_DEV_FIMC1) += dev-fimc1.o
obj-$(CONFIG_S5P_DEV_FIMC2) += dev-fimc2.o
obj-$(CONFIG_S5P_DEV_FIMC3) += dev-fimc3.o
+obj-$(CONFIG_S5P_DEV_FIMD0) += dev-fimd0.o
obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o
obj-$(CONFIG_S5P_DEV_CSIS0) += dev-csis0.o
obj-$(CONFIG_S5P_DEV_CSIS1) += dev-csis1.o
diff --git a/arch/arm/plat-s5p/dev-fimd0.c b/arch/arm/plat-s5p/dev-fimd0.c
new file mode 100644
index 0000000..9e7176c
--- /dev/null
+++ b/arch/arm/plat-s5p/dev-fimd0.c
@@ -0,0 +1,67 @@
+/* linux/arch/arm/plat-s5p/dev-fimd0.c
+ *
+ * Copyright (c) 2009-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Core file for Samsung Display Controller (FIMD) driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/platform_device.h>
+#include <linux/fb.h>
+#include <linux/gfp.h>
+#include <linux/dma-mapping.h>
+
+#include <mach/irqs.h>
+#include <mach/map.h>
+
+#include <plat/fb.h>
+#include <plat/devs.h>
+#include <plat/cpu.h>
+
+static struct resource s5p_fimd0_resource[] = {
+ [0] = {
+ .start = S5P_PA_FIMD0,
+ .end = S5P_PA_FIMD0 + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_FIMD0_VSYNC,
+ .end = IRQ_FIMD0_VSYNC,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = IRQ_FIMD0_FIFO,
+ .end = IRQ_FIMD0_FIFO,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .start = IRQ_FIMD0_SYSTEM,
+ .end = IRQ_FIMD0_SYSTEM,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 fimd0_dmamask = DMA_BIT_MASK(32);
+
+struct platform_device s5p_device_fimd0 = {
+ .name = "s5p-fb",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s5p_fimd0_resource),
+ .resource = s5p_fimd0_resource,
+ .dev = {
+ .dma_mask = &fimd0_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+void __init s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd)
+{
+ s3c_set_platdata(pd, sizeof(struct s3c_fb_platdata),
+ &s5p_device_fimd0);
+}
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 4af108f..370bd2b 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -45,6 +45,7 @@ extern struct platform_device s3c64xx_device_ac97;
extern struct platform_device s3c_device_ts;
extern struct platform_device s3c_device_fb;
+extern struct platform_device s5p_device_fimd0;
extern struct platform_device s3c_device_ohci;
extern struct platform_device s3c_device_lcd;
extern struct platform_device s3c_device_wdt;
diff --git a/arch/arm/plat-samsung/include/plat/fb-core.h b/arch/arm/plat-samsung/include/plat/fb-core.h
index bca383e..6abcbf1 100644
--- a/arch/arm/plat-samsung/include/plat/fb-core.h
+++ b/arch/arm/plat-samsung/include/plat/fb-core.h
@@ -26,4 +26,19 @@ static inline void s3c_fb_setname(char *name)
#endif
}
+/* Re-define device name depending on support. */
+static inline void s5p_fb_setname(int id, char *name)
+{
+ switch (id) {
+#ifdef CONFIG_S5P_DEV_FIMD0
+ case 0:
+ s5p_device_fimd0.name = name;
+ break;
+#endif
+ default:
+ printk(KERN_ERR "%s: invalid device id(%d)\n", __func__, id);
+ break;
+ }
+}
+
#endif /* __ASM_PLAT_FB_CORE_H */
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index cb3ca3a..01f10e4 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -74,6 +74,14 @@ struct s3c_fb_platdata {
extern void s3c_fb_set_platdata(struct s3c_fb_platdata *pd);
/**
+ * s5p_fimd0_set_platdata() - Setup the FB device with platform data.
+ * @pd: The platform data to set. The data is copied from the passed structure
+ * so the machine data can mark the data __initdata so that any unused
+ * machines will end up dumping their data at runtime.
+ */
+extern void s5p_fimd0_set_platdata(struct s3c_fb_platdata *pd);
+
+/**
* s3c64xx_fb_gpio_setup_24bpp() - S3C64XX setup function for 24bpp LCD
*
* Initialise the GPIO for an 24bpp LCD display on the RGB interface.
@@ -94,4 +102,11 @@ extern void s5pc100_fb_gpio_setup_24bpp(void);
*/
extern void s5pv210_fb_gpio_setup_24bpp(void);
+/**
+ * exynos4_fimd0_gpio_setup_24bpp() - Exynos4 setup function for 24bpp LCD0
+ *
+ * Initialise the GPIO for an 24bpp LCD display on the RGB interface 0.
+ */
+extern void exynos4_fimd0_gpio_setup_24bpp(void);
+
#endif /* __PLAT_S3C_FB_H */
--
1.7.1
^ permalink raw reply related
* [PATCH V7 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
From: Jingoo Han @ 2011-06-27 10:50 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev,
Jonghun Han
Cc: Anand Kumar N, Thomas Abraham, Sylwester Nawrocki,
Marek Szyprowski, Kyungmin Park, Inki Dae, ARM Linux, Ben Dooks,
Jingoo Han
This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4
and adds lcd clock gating support.
FIMD driver needs two clocks for FIMD IP and LCD pixel clock. Previously,
both clocks are provided by using bus clock such as HCLK. However, EXYNOS4
can not select HCLK for LCD pixel clock because the EXYNOS4 FIMD IP does not
have the CLKSEL bit of VIDCON0. So, FIMD driver should provide the lcd clock
using SCLK_FIMD as LCD pixel clock for EXYNOS4.
The driver selects enabling lcd clock according to has_clksel which means
the CLKSEL bit of VIDCON0. If there is has_clksel, the driver will not
enable the lcd clock using SCLK_FIMD because bus clock using HCLK is used
a LCD pixel clock.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/Kconfig | 2 +-
drivers/video/s3c-fb.c | 88 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 549b960..963b8b7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2027,7 +2027,7 @@ config FB_TMIO_ACCELL
config FB_S3C
tristate "Samsung S3C framebuffer support"
- depends on FB && S3C_DEV_FB
+ depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 4aecf21..cb0d3ea 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -81,6 +81,7 @@ struct s3c_fb;
* @palette: Address of palette memory, or 0 if none.
* @has_prtcon: Set if has PRTCON register.
* @has_shadowcon: Set if has SHADOWCON register.
+ * @has_clksel: Set if VIDCON0 register has CLKSEL bit.
*/
struct s3c_fb_variant {
unsigned int is_2443:1;
@@ -98,6 +99,7 @@ struct s3c_fb_variant {
unsigned int has_prtcon:1;
unsigned int has_shadowcon:1;
+ unsigned int has_clksel:1;
};
/**
@@ -186,6 +188,7 @@ struct s3c_fb_vsync {
* @dev: The device that we bound to, for printing, etc.
* @regs_res: The resource we claimed for the IO registers.
* @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
+ * @lcd_clk: The clk (sclk) feeding pixclk.
* @regs: The mapped hardware registers.
* @variant: Variant information for this hardware.
* @enabled: A bitmask of enabled hardware windows.
@@ -200,6 +203,7 @@ struct s3c_fb {
struct device *dev;
struct resource *regs_res;
struct clk *bus_clk;
+ struct clk *lcd_clk;
void __iomem *regs;
struct s3c_fb_variant variant;
@@ -336,10 +340,15 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
*/
static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
{
- unsigned long clk = clk_get_rate(sfb->bus_clk);
+ unsigned long clk;
unsigned long long tmp;
unsigned int result;
+ if (sfb->variant.has_clksel)
+ clk = clk_get_rate(sfb->bus_clk);
+ else
+ clk = clk_get_rate(sfb->lcd_clk);
+
tmp = (unsigned long long)clk;
tmp *= pixclk;
@@ -1354,13 +1363,24 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel) {
+ sfb->lcd_clk = clk_get(dev, "sclk_fimd");
+ if (IS_ERR(sfb->lcd_clk)) {
+ dev_err(dev, "failed to get lcd clock\n");
+ ret = PTR_ERR(sfb->lcd_clk);
+ goto err_bus_clk;
+ }
+
+ clk_enable(sfb->lcd_clk);
+ }
+
pm_runtime_enable(sfb->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "failed to find registers\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs_res = request_mem_region(res->start, resource_size(res),
@@ -1368,7 +1388,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
if (!sfb->regs_res) {
dev_err(dev, "failed to claim register region\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs = ioremap(res->start, resource_size(res));
@@ -1450,7 +1470,13 @@ err_ioremap:
err_req_region:
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
-err_clk:
+err_lcd_clk:
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ }
+
+err_bus_clk:
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
@@ -1481,6 +1507,11 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
iounmap(sfb->regs);
+ if (!sfb->variant.has_clksel) {
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ }
+
clk_disable(sfb->bus_clk);
clk_put(sfb->bus_clk);
@@ -1510,6 +1541,9 @@ static int s3c_fb_suspend(struct device *dev)
s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
}
+ if (!sfb->variant.has_clksel)
+ clk_disable(sfb->lcd_clk);
+
clk_disable(sfb->bus_clk);
return 0;
}
@@ -1524,6 +1558,9 @@ static int s3c_fb_resume(struct device *dev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel)
+ clk_enable(sfb->lcd_clk);
+
/* setup gpio and output polarity controls */
pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
@@ -1569,6 +1606,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
}
+ if (!sfb->variant.has_clksel)
+ clk_disable(sfb->lcd_clk);
+
clk_disable(sfb->bus_clk);
return 0;
}
@@ -1583,6 +1623,9 @@ static int s3c_fb_runtime_resume(struct device *dev)
clk_enable(sfb->bus_clk);
+ if (!sfb->variant.has_clksel)
+ clk_enable(sfb->lcd_clk);
+
/* setup gpio and output polarity controls */
pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
@@ -1755,6 +1798,7 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx = {
},
.has_prtcon = 1,
+ .has_clksel = 1,
},
.win[0] = &s3c_fb_data_64xx_wins[0],
.win[1] = &s3c_fb_data_64xx_wins[1],
@@ -1785,6 +1829,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 = {
},
.has_prtcon = 1,
+ .has_clksel = 1,
},
.win[0] = &s3c_fb_data_s5p_wins[0],
.win[1] = &s3c_fb_data_s5p_wins[1],
@@ -1815,6 +1860,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
},
.has_shadowcon = 1,
+ .has_clksel = 1,
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+ .win[3] = &s3c_fb_data_s5p_wins[3],
+ .win[4] = &s3c_fb_data_s5p_wins[4],
+};
+
+static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+
+ .has_shadowcon = 1,
},
.win[0] = &s3c_fb_data_s5p_wins[0],
.win[1] = &s3c_fb_data_s5p_wins[1],
@@ -1843,6 +1919,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
[0] = 0x400,
[1] = 0x800,
},
+ .has_clksel = 1,
},
.win[0] = &(struct s3c_fb_win_variant) {
.palette_sz = 256,
@@ -1870,6 +1947,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "s5pv210-fb",
.driver_data = (unsigned long)&s3c_fb_data_s5pv210,
}, {
+ .name = "exynos4-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos4,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
},
--
1.7.1
^ permalink raw reply related
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