* 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 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 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] 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] 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] 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] 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] 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] 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/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 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 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
* [PATCH 2/2] video: Fix speficied typo
From: Joe Perches @ 2011-06-23 22:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <6002eb70809bb1c87c84f32ab4a4f034d2d1ffb5.1308868289.git.joe@perches.com>
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(-)
diff --git a/drivers/video/controlfb.c b/drivers/video/controlfb.c
index 9075bea..7b2c40a 100644
--- a/drivers/video/controlfb.c
+++ b/drivers/video/controlfb.c
@@ -550,7 +550,7 @@ static void control_set_hardware(struct fb_info_control *p, struct fb_par_contro
/*
- * Parse user speficied options (`video=controlfb:')
+ * Parse user specified options (`video=controlfb:')
*/
static void __init control_setup(char *options)
{
diff --git a/drivers/video/platinumfb.c b/drivers/video/platinumfb.c
index f27ae16..6694923 100644
--- a/drivers/video/platinumfb.c
+++ b/drivers/video/platinumfb.c
@@ -490,7 +490,7 @@ static int platinum_var_to_par(struct fb_var_screeninfo *var,
/*
- * Parse user speficied options (`video=platinumfb:')
+ * Parse user specified options (`video=platinumfb:')
*/
static int __init platinumfb_setup(char *options)
{
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index f4f8ce8..dc7bfa9 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -1773,7 +1773,7 @@ MODULE_DEVICE_TABLE(pci, pm2fb_id_table);
#ifndef MODULE
/**
- * Parse user speficied options.
+ * Parse user specified options.
*
* This is, comma-separated options following `video=pm2fb:'.
*/
diff --git a/drivers/video/pm3fb.c b/drivers/video/pm3fb.c
index 8221b5b..6632ee5 100644
--- a/drivers/video/pm3fb.c
+++ b/drivers/video/pm3fb.c
@@ -1525,7 +1525,7 @@ static int __init pm3fb_setup(char *options)
{
char *this_opt;
- /* Parse user speficied options (`video=pm3fb:') */
+ /* Parse user specified options (`video=pm3fb:') */
if (!options || !*options)
return 0;
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 0f9af1a..946a949 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1505,7 +1505,7 @@ static struct pci_driver s3fb_pci_driver = {
.resume = s3_pci_resume,
};
-/* Parse user speficied options */
+/* Parse user specified options */
#ifndef MODULE
static int __init s3fb_setup(char *options)
diff --git a/drivers/video/skeletonfb.c b/drivers/video/skeletonfb.c
index 89158bc..30f7a81 100644
--- a/drivers/video/skeletonfb.c
+++ b/drivers/video/skeletonfb.c
@@ -989,7 +989,7 @@ static struct platform_device *xxxfb_device;
*/
int __init xxxfb_setup(char *options)
{
- /* Parse user speficied options (`video=xxxfb:') */
+ /* Parse user specified options (`video=xxxfb:') */
}
#endif /* MODULE */
diff --git a/drivers/video/valkyriefb.c b/drivers/video/valkyriefb.c
index 6b52bf6..3f5a041 100644
--- a/drivers/video/valkyriefb.c
+++ b/drivers/video/valkyriefb.c
@@ -555,7 +555,7 @@ static int __init valkyrie_init_info(struct fb_info *info,
/*
- * Parse user speficied options (`video=valkyriefb:')
+ * Parse user specified options (`video=valkyriefb:')
*/
int __init valkyriefb_setup(char *options)
{
--
1.7.6.rc1
^ permalink raw reply related
* [PATCH 18/37] Remove unneeded version.h includes from
From: Jesper Juhl @ 2011-06-23 22:35 UTC (permalink / raw)
To: LKML
Cc: trivial, Michael Hennerich, Richard Purdie, Paul Mundt,
device-drivers-devel, linux-fbdev
In-Reply-To: <alpine.LNX.2.00.1106232344480.17688@swampdragon.chaosbits.net>
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(-)
diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
index d2a96a4..24a6dfd 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
index 05a8832..383c4c3 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
index 0283c70..d8de557 100644
--- a/drivers/video/pxa3xx-gcu.c
+++ b/drivers/video/pxa3xx-gcu.c
@@ -31,8 +31,6 @@
*/
#include <linux/module.h>
-#include <linux/version.h>
-
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/miscdevice.h>
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 77dea01..fcb6cd9 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -23,7 +23,6 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
--
1.7.5.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] fsl-diu-fb: remove check for pixel clock ranges
From: Timur Tabi @ 2011-06-23 20:20 UTC (permalink / raw)
To: lethal, linux-fbdev, agust, yorksun, linuxppc-dev
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>
---
drivers/video/fsl-diu-fb.c | 16 ----------------
include/linux/fsl-diu-fb.h | 6 ------
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..0acc7d6 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -555,8 +555,6 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
static int fsl_diu_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
- unsigned long htotal, vtotal;
-
pr_debug("check_var xres: %d\n", var->xres);
pr_debug("check_var yres: %d\n", var->yres);
@@ -635,20 +633,6 @@ static int fsl_diu_check_var(struct fb_var_screeninfo *var,
break;
}
- /* If the pixclock is below the minimum spec'd value then set to
- * refresh rate for 60Hz since this is supported by most monitors.
- * Refer to Documentation/fb/ for calculations.
- */
- if ((var->pixclock < MIN_PIX_CLK) || (var->pixclock > MAX_PIX_CLK)) {
- htotal = var->xres + var->right_margin + var->hsync_len +
- var->left_margin;
- vtotal = var->yres + var->lower_margin + var->vsync_len +
- var->upper_margin;
- var->pixclock = (vtotal * htotal * 6UL) / 100UL;
- var->pixclock = KHZ2PICOS(var->pixclock);
- pr_debug("pixclock set for 60Hz refresh = %u ps\n",
- var->pixclock);
- }
var->height = -1;
var->width = -1;
diff --git a/include/linux/fsl-diu-fb.h b/include/linux/fsl-diu-fb.h
index 781d467..daa9952 100644
--- a/include/linux/fsl-diu-fb.h
+++ b/include/linux/fsl-diu-fb.h
@@ -24,12 +24,6 @@
* See mpc8610fb_set_par(), map_video_memory(), and unmap_video_memory()
*/
#define MEM_ALLOC_THRESHOLD (1024*768*4+32)
-/* Minimum value that the pixel clock can be set to in pico seconds
- * This is determined by platform clock/3 where the minimum platform
- * clock is 533MHz. This gives 5629 pico seconds.
- */
-#define MIN_PIX_CLK 5629
-#define MAX_PIX_CLK 96096
#include <linux/types.h>
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 1/3] printk: Release console_sem after logbuf_lock
From: Pavel Machek @ 2011-06-23 19:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Hugh Dickins, Andrew Morton, Ingo Molnar, Linus Torvalds,
Thomas Gleixner, linux-kernel, efault, Arne Jansen, PaulMundt,
linux-fbdev
In-Reply-To: <1307709030.3941.134.camel@twins>
vvOn Fri 2011-06-10 14:30:30, Peter Zijlstra wrote:
>On Fri, 2011-06-10 at 13:28 +0200, Peter Zijlstra wrote:
> > On Thu, 2011-06-09 at 16:57 -0700, Hugh Dickins wrote:
> > >
> > > All console-related activity curently happens under spin_lock_irqsave(&console_lock).
> > > This causes interrutps to be blocked for 1-2 milliseconds with vgacon, and for
> > > hundreds of milliseconds with fbdevs. This results in network overruns, audio
> > > dropouts, dropped characters on serial ports and other such nice things.
> >
> > Hmm, with these proposed patches we're actually back to that. I wonder
> > if fbdev is still that crappy..
>
> So I tried adding a fbcon to my test box (not that it actually has a
> display, but who cares) and disabled lockdep (otherwise that's all I can
> catch on the latency tracer) to see if I could see whopping horrid
> latencies there, but I'm afraid I either failed to set things up
> properly or my fbcon isn't sucky enough.
>
> What I did was enable:
>
> CONFIG_FB=y
> CONFIG_FB_SIS=y
> CONFIG_FB_SIS_315=y (the board has XGI z7)
sis will be accelerated. Try vesafb; scrolling should be horrible.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-06-23 16:08 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Laurent Pinchart, linux-fbdev, linux-media, dri-devel
In-Reply-To: <4E018189.3020305@gmx.de>
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:
>>> On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote:
>>>> +The FOURCC-based API replaces format descriptions by four character
>>>> codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a
>>>> format +without explicitly describing it. This is the only API that
>>>> supports YUV +formats. Drivers are also encouraged to implement the
>>>> FOURCC-based API for RGB +and grayscale formats.
>>>> +
>>>> +Drivers that support the FOURCC-based API report this capability by
>>>> setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities
>>>> field. +
>>>> +FOURCC definitions are located in the linux/videodev2.h header.
>>>> However,
>>>> and +despite starting with the V4L2_PIX_FMT_prefix, they are not
>>>> restricted to V4L2 +and don't require usage of the V4L2 subsystem.
>>>> FOURCC documentation is +available in
>>>> Documentation/DocBook/v4l/pixfmt.xml.
>>>> +
>>>> +To select a format, applications set the FB_VMODE_FOURCC bit in the
>>>> +fb_var_screeninfo vmode field, and set the fourcc field to the desired
>>>> FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields
>>>> must be set to +0 by applications and ignored by drivers. Note that the
>>>> grayscale and fourcc +fields share the same memory location. Application
>>>> must thus not set the +grayscale field to 0.
>>>
>>> These are the only parts I don't like: (ab)using the vmode field (this
>>> isn't really a vmode flag), and the union of grayscale and fourcc (avoid
>>> unions where possible).
>>
>> I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a
>> FOURCC
>> mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very
>> happy
>> with that, and proposed using the vmode field instead.
>>
>> Given that there's virtually no fbdev documentation, whether the vmode
>> field
>> and/or nonstd field are good fit for a FOURCC mode indicator is subject to
>> interpretation.
>
> The reason for my suggestion is that the vmode field is accepted to contain
> only flags and at least to me there is no hard line what is part of the
> video mode and what is not. In contrast the nonstd field is already used in
> a lot of different (incompatible) ways. I think if we only use the nonstd
> field for handling FOURCC it is likely that some problems will appear.
>
>>> What about storing the FOURCC value in nonstd instead?
>>
>> Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format
>> setting will be a standard fbdev API, I'm not very keen on storing it in
>> the
>> nonstd field without a union.
>>
>>> 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?).
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
* [PATCH] This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuffer r
From: William Katsak @ 2011-06-23 13:16 UTC (permalink / raw)
To: linux-fbdev
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>
---
drivers/video/udlfb.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 52b0f3e..816a4fd 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1233,8 +1233,12 @@ static int dlfb_setup_modes(struct dlfb_data *dev,
if (dlfb_is_valid_mode(&info->monspecs.modedb[i], info))
fb_add_videomode(&info->monspecs.modedb[i],
&info->modelist);
- else /* if we've removed top/best mode */
- info->monspecs.misc &= ~FB_MISC_1ST_DETAIL;
+ else {
+ if (i = 0)
+ /* if we've removed top/best mode */
+ info->monspecs.misc
+ &= ~FB_MISC_1ST_DETAIL;
+ }
}
default_vmode = fb_find_best_display(&info->monspecs,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-23 11:39 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org
In-Reply-To: <4E0323A5.7080706@freescale.com>
On Thu, 23 Jun 2011 11:29:42 +0000
Tabi Timur-B04825 <B04825@freescale.com> wrote:
...
> > test-app:http://pastebin.com/J2RvKb6n
>
> What's the "VIU"?
Video-IN unit on mpc5121e (for capturing ITU656 video stream data).
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Tabi Timur-B04825 @ 2011-06-23 11:29 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
lethal@linux-sh.org, sun york-R58495
In-Reply-To: <20110623132604.1a6d0d71@wker>
Anatolij Gustschin wrote:
> I do not have the code of the real applications since I didn't wrote
> it. All I can share is the test and sample code that I used when working
> on driver fixes:
>
> test-app:http://pastebin.com/J2RvKb6n
What's the "VIU"?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-23 11:26 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-dev, linux-fbdev, lethal, Timur Tabi, yorksun
In-Reply-To: <929D3CED81F34E43887A393170D66FB90484A280@GBRSUN01MS002.eu.xerox.net>
On Wed, 22 Jun 2011 11:39:49 +0100
"Jenkins, Clive" <Clive.Jenkins@xerox.com> wrote:
...
> > > Removing the ioctl interface also allows us to clean up the header
> file and
> > > remove other unusued stuff.
> >
> > No! We are using ioctl interface of this driver in many video
> > rendering applications on overlay planes on huge number of boards.
> > So, please don't remove it.
...
> Can you make available your application code by posting a link to it?
I do not have the code of the real applications since I didn't wrote
it. All I can share is the test and sample code that I used when working
on driver fixes:
test-app: http://pastebin.com/J2RvKb6n
HTH,
Anatolij
^ permalink raw reply
* Re: Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
From: JinGoo Han @ 2011-06-23 11:08 UTC (permalink / raw)
To: K, Mythri P
Cc: JinGoo Han, Kukjin Kim, Paul Mundt,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
Jong-Hun Han, ANAND KUMAR N, Sylwester Nawrocki, THOMAS P ABRAHAM,
Marek Szyprowski, Kyungmin Park, In-Ki Dae, ARM Linux, Ben Dooks
In-Reply-To: <11291403.110251308714504687.JavaMail.weblogic@epml08>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3800 bytes --]
Hi, Mythri.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Thursday, June 23, 2011 6:04 PM
> To: jg1.han@samsung.com
> Cc: Kukjin Kim; Paul Mundt; linux-samsung-soc@vger.kernel.org; linux-
> fbdev@vger.kernel.org; Jong-Hun Han; ANAND KUMAR N; Sylwester Nawrocki;
> THOMAS P ABRAHAM; Marek Szyprowski; Kyungmin Park; In-Ki Dae; ARM Linux;
> Ben Dooks
> Subject: Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
> FIMD and LTE480WV platform-lcd
>
> 2011/6/22 JinGoo Han <jg1.han@samsung.com>:
> > From: Jonghun Han <jonghun.han@samsung.com>
> >
> > This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
> >
> > Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm/mach-exynos4/mach-smdkc210.c | 114
> +++++++++++++++++++++++++++++++++
> > arch/arm/mach-exynos4/mach-smdkv310.c | 114
> +++++++++++++++++++++++++++++++++
> > 2 files changed, 228 insertions(+), 0 deletions(-)
> >
> <<snip>>
> > +static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
> > + unsigned int power)
> > +{
> > + if (power) {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 1);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + /* fire nRESET on power up */
> > + gpio_request(EXYNOS4_GPX0(6), "GPX0");
> > +
> > + gpio_direction_output(EXYNOS4_GPX0(6), 1);
> > + mdelay(100);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 0);
> > + mdelay(10);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 1);
> > + mdelay(10);
> > +
> > + gpio_free(EXYNOS4_GPX0(6));
> > + } else {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 0);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + }
> > +}
> > +
>
> have you considered using gpio_request_one instead ? It simplifies the
> three step API.
You're right. It seems to be very helpful.
I will apply it and send V7 patches, soon.
Thank you for your reply.
>
> <<snip>>
>
> > + if (power) {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 1);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + /* fire nRESET on power up */
> > + gpio_request(EXYNOS4_GPX0(6), "GPX0");
> > +
> > + gpio_direction_output(EXYNOS4_GPX0(6), 1);
> > + mdelay(100);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 0);
> > + mdelay(10);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 1);
> > + mdelay(10);
> > +
> > + gpio_free(EXYNOS4_GPX0(6));
> > + } else {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 0);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + }
> > +}
>
> same comment as above.
>
> <<snip>>
>
>
>
> --
> Thanks and regards,
> Mythri.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH V4 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD
From: K, Mythri P @ 2011-06-23 9:15 UTC (permalink / raw)
To: jg1.han
Cc: Kukjin Kim, Paul Mundt, linux-samsung-soc@vger.kernel.org,
linux-fbdev@vger.kernel.org, Jong-Hun Han, ANAND KUMAR N,
Sylwester Nawrocki, THOMAS P ABRAHAM, Marek Szyprowski,
Kyungmin Park, In-Ki Dae, ARM Linux, Ben Dooks
In-Reply-To: <11291403.110251308714504687.JavaMail.weblogic@epml08>
2011/6/22 JinGoo Han <jg1.han@samsung.com>:
> From: Jonghun Han <jonghun.han@samsung.com>
>
> This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
>
> Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> arch/arm/mach-exynos4/mach-smdkc210.c | 114 +++++++++++++++++++++++++++++++++
> arch/arm/mach-exynos4/mach-smdkv310.c | 114 +++++++++++++++++++++++++++++++++
> 2 files changed, 228 insertions(+), 0 deletions(-)
>
<<snip>>
> +static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
> + unsigned int power)
> +{
> + if (power) {
> +#if !defined(CONFIG_BACKLIGHT_PWM)
> + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> + gpio_direction_output(EXYNOS4_GPD0(1), 1);
> + gpio_free(EXYNOS4_GPD0(1));
> +#endif
> + /* fire nRESET on power up */
> + gpio_request(EXYNOS4_GPX0(6), "GPX0");
> +
> + gpio_direction_output(EXYNOS4_GPX0(6), 1);
> + mdelay(100);
> +
> + gpio_set_value(EXYNOS4_GPX0(6), 0);
> + mdelay(10);
> +
> + gpio_set_value(EXYNOS4_GPX0(6), 1);
> + mdelay(10);
> +
> + gpio_free(EXYNOS4_GPX0(6));
> + } else {
> +#if !defined(CONFIG_BACKLIGHT_PWM)
> + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> + gpio_direction_output(EXYNOS4_GPD0(1), 0);
> + gpio_free(EXYNOS4_GPD0(1));
> +#endif
> + }
> +}
> +
have you considered using gpio_request_one instead ? It simplifies the
three step API.
<<snip>>
> + if (power) {
> +#if !defined(CONFIG_BACKLIGHT_PWM)
> + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> + gpio_direction_output(EXYNOS4_GPD0(1), 1);
> + gpio_free(EXYNOS4_GPD0(1));
> +#endif
> + /* fire nRESET on power up */
> + gpio_request(EXYNOS4_GPX0(6), "GPX0");
> +
> + gpio_direction_output(EXYNOS4_GPX0(6), 1);
> + mdelay(100);
> +
> + gpio_set_value(EXYNOS4_GPX0(6), 0);
> + mdelay(10);
> +
> + gpio_set_value(EXYNOS4_GPX0(6), 1);
> + mdelay(10);
> +
> + gpio_free(EXYNOS4_GPX0(6));
> + } else {
> +#if !defined(CONFIG_BACKLIGHT_PWM)
> + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> + gpio_direction_output(EXYNOS4_GPD0(1), 0);
> + gpio_free(EXYNOS4_GPD0(1));
> +#endif
> + }
> +}
same comment as above.
<<snip>>
--
Thanks and regards,
Mythri.
^ permalink raw reply
* Re: RE: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
From: JinGoo Han @ 2011-06-23 6:44 UTC (permalink / raw)
To: Marek Szyprowski
Cc: JinGoo Han, Kukjin Kim, 'Paul Mundt',
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
Jong-Hun Han, ANAND KUMAR N, THOMAS P ABRAHAM, Sylwester Nawrocki,
'Kyungmin Park', In-Ki Dae, 'ARM Linux',
'Ben Dooks'
In-Reply-To: <1308724904-31521-1-git-send-email-jg1.han@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 6516 bytes --]
Hi, Marek.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Marek Szyprowski
> Sent: Wednesday, June 22, 2011 6:47 PM
> To: 'Jingoo Han'; 'Kukjin Kim'; 'Paul Mundt'; linux-samsung-
> soc@vger.kernel.org; linux-fbdev@vger.kernel.org; 'Jonghun Han'
> Cc: 'Anand Kumar N'; 'Thomas Abraham'; Sylwester Nawrocki; 'Kyungmin Park';
> 'Inki Dae'; 'ARM Linux'; 'Ben Dooks'; 'Jonghun Han'
> Subject: RE: [PATCH V5 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4
> FIMD and LTE480WV platform-lcd
>
> Hello,
>
> On Wednesday, June 22, 2011 8:42 AM Jingoo Han wrote:
>
> > From: Jonghun Han <jonghun.han@samsung.com>
> >
> > This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel.
> >
> > Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm/mach-exynos4/mach-smdkc210.c | 114
> > +++++++++++++++++++++++++++++++++
> > arch/arm/mach-exynos4/mach-smdkv310.c | 114
> > +++++++++++++++++++++++++++++++++
> > 2 files changed, 228 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c b/arch/arm/mach-
> > exynos4/mach-smdkc210.c
> > index e645f7a..360a50a 100644
> > --- a/arch/arm/mach-exynos4/mach-smdkc210.c
> > +++ b/arch/arm/mach-exynos4/mach-smdkc210.c
> > @@ -9,26 +9,33 @@
> > */
> >
> > #include <linux/serial_core.h>
> > +#include <linux/delay.h>
> > #include <linux/gpio.h>
> > +#include <linux/lcd.h>
> > #include <linux/mmc/host.h>
> > #include <linux/platform_device.h>
> > #include <linux/smsc911x.h>
> > #include <linux/io.h>
> > #include <linux/i2c.h>
> > +#include <linux/clk.h>
> >
> > #include <asm/mach/arch.h>
> > #include <asm/mach-types.h>
> >
> > +#include <video/platform_lcd.h>
> > +
> > #include <plat/regs-serial.h>
> > #include <plat/regs-srom.h>
> > #include <plat/exynos4.h>
> > #include <plat/cpu.h>
> > #include <plat/devs.h>
> > +#include <plat/fb.h>
> > #include <plat/sdhci.h>
> > #include <plat/iic.h>
> > #include <plat/pd.h>
> >
> > #include <mach/map.h>
> > +#include <mach/regs-fb.h>
> >
> > /* Following are default values for UCON, ULCON and UFCON UART
> registers
> > */
> > #define SMDKC210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> > @@ -111,6 +118,69 @@ static struct s3c_sdhci_platdata
> smdkc210_hsmmc3_pdata
> > __initdata = {
> > .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> > };
> >
> > +static void lcd_lte480wv_set_power(struct plat_lcd_data *pd,
> > + unsigned int power)
> > +{
> > + if (power) {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 1);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + /* fire nRESET on power up */
> > + gpio_request(EXYNOS4_GPX0(6), "GPX0");
> > +
> > + gpio_direction_output(EXYNOS4_GPX0(6), 1);
> > + mdelay(100);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 0);
> > + mdelay(10);
> > +
> > + gpio_set_value(EXYNOS4_GPX0(6), 1);
> > + mdelay(10);
> > +
> > + gpio_free(EXYNOS4_GPX0(6));
> > + } else {
> > +#if !defined(CONFIG_BACKLIGHT_PWM)
> > + gpio_request(EXYNOS4_GPD0(1), "GPD0");
> > + gpio_direction_output(EXYNOS4_GPD0(1), 0);
> > + gpio_free(EXYNOS4_GPD0(1));
> > +#endif
> > + }
> > +}
> > +
> > +static struct plat_lcd_data smdkc210_lcd_lte480wv_data = {
> > + .set_power = lcd_lte480wv_set_power,
> > +};
> > +
> > +static struct platform_device smdkc210_lcd_lte480wv = {
> > + .name = "platform-lcd",
> > + .dev.parent = &s5p_device_fimd0.dev,
> > + .dev.platform_data = &smdkc210_lcd_lte480wv_data,
> > +};
> > +
> > +static struct s3c_fb_pd_win smdkc210_fb_win0 = {
> > + .win_mode = {
> > + .left_margin = 13,
> > + .right_margin = 8,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 800,
> > + .yres = 480,
> > + },
> > + .max_bpp = 32,
> > + .default_bpp = 24,
> > +};
> > +
> > +static struct s3c_fb_platdata smdkc210_lcd0_pdata __initdata = {
> > + .win[0] = &smdkc210_fb_win0,
> > + .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> > + .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> > + .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> > +};
> > +
> > static struct resource smdkc210_smsc911x_resources[] = {
> > [0] = {
> > .start = EXYNOS4_PA_SROM_BANK(1),
> > @@ -165,6 +235,8 @@ static struct platform_device *smdkc210_devices[]
> > __initdata = {
> > &exynos4_device_pd[PD_GPS],
> > &exynos4_device_sysmmu,
> > &samsung_asoc_dma,
> > + &s5p_device_fimd0,
> > + &smdkc210_lcd_lte480wv,
> > &smdkc210_smsc911x,
> > };
> >
> > @@ -191,6 +263,44 @@ static void __init smdkc210_smsc911x_init(void)
> > (0x1 << S5P_SROM_BCX__TACS__SHIFT), S5P_SROM_BC1);
> > }
> >
> > +static int __init smdkc210_fimd0_setup_clock(void)
> > +{
> > + struct clk *sclk = NULL;
> > + struct clk *mout_mpll = NULL;
> > +
> > + u32 rate = 0;
> > +
> > + sclk = clk_get(&s5p_device_fimd0.dev, "sclk_fimd");
> > + if (IS_ERR(sclk)) {
> > + printk(KERN_ERR "failed to get sclk for fimd\n");
> > + goto err_clk2;
> > + }
> > +
> > + mout_mpll = clk_get(NULL, "mout_mpll");
> > + if (IS_ERR(mout_mpll)) {
> > + printk(KERN_ERR "failed to get mout_mpll\n");
> > + goto err_clk1;
> > + }
> > +
> > + clk_set_parent(sclk, mout_mpll);
> > + if (!rate)
> > + rate = 134000000;
> > +
> > + clk_set_rate(sclk, rate);
> > +
> > + clk_put(sclk);
> > + clk_put(mout_mpll);
> > +
> > + return 0;
> > +
> > +err_clk1:
> > + clk_put(mout_mpll);
> > +err_clk2:
> > + clk_put(sclk);
> > +
> > + return -EINVAL;
> > +}
> > +
>
> I'm not sure if mach-smdk*.c is the right place for the above code.
> IMHO all the code that configures very low level, board specific
> parameters
> (like clocks and their relations) should be performed in boot loarder.
I agree with your suggestion.
I will remove the parent clock setting from the machine as fimc does.
I will send V7 patches, soon.
I really appreciate your review. Thank you.
>
> (snipped)
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* Re: Some questions about DRM(Direct Rendering Manager)
From: daeinki @ 2011-06-23 1:55 UTC (permalink / raw)
To: Rob Clark
Cc: linux-fbdev, Kukjin Kim, Kyungmin Park, dri-devel, Paul Mundt,
jesse.barnes, InKi Dae, linux-arm-kernel
In-Reply-To: <BANLkTinv1uGUPBX4RE2DGw4Ca_P5x0g+DA@mail.gmail.com>
Hi Rob Clark,
I'm sorry for that my mean didn't convey to you so I condensed that into
brief again.
I know drm_fb_helper_single_fb_probe() calls register_framebuffer(),
My question is that it's right way to call only drm_fb_helper_set_par()
if fb_helper->funcs->fb_probe() returns nonzero.
In this case, if fb_helper->funcs->fb_probe() returns zero then
register_framebuffer() isn't called and this means linux framebuffer
isn't used anymore.
one more question, otherwise if it uses drm based framebuffer,
register_framebuffer() should be called necessarily at booting time?
Thank you.
Rob Clark 쓴 글:
> fwiw, drm_fb_helper_single_fb_probe() calls register_framebuffer() (if
> that was the question?)
>
> BR,
> -R
>
> 2011/6/22 InKi Dae <daeinki@gmail.com>:
>> It adds dri-devel@lists.freedesktop.org to this mail thread.
>> Thank you.
>>
>> 2011년 6월 22일 오후 3:04, daeinki <inki.dae@samsung.com>님의 말:
>>> below is additional comments.
>>>
>>> daeinki 쓴 글:
>>>> Hi all,
>>>>
>>>> I'm writing Samsung SoC based DRM framework and this one includes FIMD
>>>> and HDMI driver as hardware dependent modules. and for now, encoder,
>>>> connector, crtc and fb module has been materialized almost. but I'm
>>>> contending with framebuffer setting issue(created fb_info should be
>>>> registered to linux framebuffer through register_framebuffer() or not)as
>>>> default framebuffer at booting time.
>>>>
>>>> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's
>>>> fb_probe callback is called and this one creates new framebuffer and
>>>> returns a value more then 0 if true. internally, this process creates an
>>>> fb_info object and drm_framebuffer and then drm_framebuffer would be
>>>> added to mode_config.fb_list of the drm_device.
>>>>
>>> it's my mistake. return value is 0 if true, nonzero otherwise.
>>>
>>>> a value returned, new_fb is used to decide that it calls
>>>> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am
>>>> confused it's a good way to call register_framebuffer() otherwise
>>>> drm_fb_helper_set_par(). if register_framebuffer() is called then I
>>>> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be
>>>> called somewhere subsequently to apply this one to real hardware because
>>>> previous process is just for maintaining data logically.(not set up data
>>>> to h/w)
>>>>
>>>> it's a right way to call register_framebuffer() and then
>>>> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just
>>>> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring
>>>> register_framebuffer()? and what is the purpose of using
>>>> register_framebuffer()?
>>>>
>>> I understood that if fb_probe() callback is fail then fb_info object is
>>> registered to linux framebuffer through register_framebuffer()
>>> otherwise(if true) hardware configuration would be completed by
>>> drm_fb_helper_set_par() so the reason of using register_framebuffer() is
>>> that the case of failing fb_probe() callback, it is for drawing on only
>>> linux framebuffer. is it right?
>>>
>>>> In my case, first, register_framebuffer() is called and then if desired
>>>> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id,
>>>> it gets mode_set of drm_fb_helper->crtc_info[n] and then it calls
>>>> drm_crtc_helper_set_config(mode_set). at this time, all the hardware
>>>> configurations would be completed.
>>>>
>>>> thank you in advance.
>>>>
>>>> Best Regards
>>>> Inki Dae.
>>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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