* [PATCH 4/4] fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
The drivers/video/sh_mobile_meram.h header contains unused definitions
and declarations. Move the only used macro to sh_mobile_meram.c, and
remove the header.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 2 +-
drivers/video/sh_mobile_meram.c | 5 +++--
drivers/video/sh_mobile_meram.h | 33 ---------------------------------
3 files changed, 4 insertions(+), 36 deletions(-)
delete mode 100644 drivers/video/sh_mobile_meram.h
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index d0f768e..93e10ef 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -24,10 +24,10 @@
#include <linux/backlight.h>
#include <linux/gpio.h>
#include <video/sh_mobile_lcdc.h>
+#include <video/sh_mobile_meram.h>
#include <asm/atomic.h>
#include "sh_mobile_lcdcfb.h"
-#include "sh_mobile_meram.h"
#define SIDE_B_OFFSET 0x1000
#define MIRROR_OFFSET 0x2000
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 7ba6dce..f632970 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -16,8 +16,7 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
-
-#include "sh_mobile_meram.h"
+#include <video/sh_mobile_meram.h>
/* meram registers */
#define MEVCR1 0x4
@@ -82,6 +81,8 @@
((yszm1) << MExxBSIZE_YSZM1_SHIFT) | \
((xszm1) << MExxBSIZE_XSZM1_SHIFT))
+#define SH_MOBILE_MERAM_ICB_NUM 32
+
static unsigned long common_regs[] = {
MEVCR1,
MEQSEL1,
diff --git a/drivers/video/sh_mobile_meram.h b/drivers/video/sh_mobile_meram.h
deleted file mode 100644
index 1615204..0000000
--- a/drivers/video/sh_mobile_meram.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifndef __sh_mobile_meram_h__
-#define __sh_mobile_meram_h__
-
-#include <linux/mutex.h>
-#include <video/sh_mobile_meram.h>
-
-/*
- * MERAM private
- */
-
-#define MERAM_ICB_Y 0x1
-#define MERAM_ICB_C 0x2
-
-/* MERAM cache size */
-#define SH_MOBILE_MERAM_ICB_NUM 32
-
-#define SH_MOBILE_MERAM_CACHE_OFFSET(p) ((p) >> 16)
-#define SH_MOBILE_MERAM_CACHE_SIZE(p) ((p) & 0xffff)
-
-int sh_mobile_meram_alloc_icb(const struct sh_mobile_meram_cfg *cfg,
- int xres,
- int yres,
- unsigned int base_addr,
- int yuv_mode,
- int *marker_icb,
- int *out_pitch);
-
-void sh_mobile_meram_free_icb(int marker_icb);
-
-#define SH_MOBILE_MERAM_START(ind, ab) \
- (0xC0000000 | ((ab & 0x1) << 23) | ((ind & 0x1F) << 24))
-
-#endif /* !__sh_mobile_meram_h__ */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3/4] fbdev: sh_mobile_meram: Fix MExxCTL register save on runtime PM suspend
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
To reset the ICB on resume the MExxCTL register needs to be OR'ed with
MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF, no set to that value. Fix this.
This fixes corruption at the bottom of the display when resuming from
runtime PM.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 25a7118..7ba6dce 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -549,7 +549,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
meram_read_icb(priv->base, j, icb_regs[k]);
/* Reset ICB on resume */
if (icb_regs[k] = MExxCTL)
- priv->icb_saved_regs[j * ICB_REGS_SIZE + k] + priv->icb_saved_regs[j * ICB_REGS_SIZE + k] | MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF;
}
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/4] fbdev: sh_mobile_meram: Validate ICB configuration outside mutex
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
Validate as much of the requested ICB configuration as possible outside
of the mutex-protected region when registering ICBs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 85577cf..25a7118 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -410,24 +410,22 @@ static int sh_mobile_meram_register(struct sh_mobile_meram_info *pdata,
xres, yres, (!pixelformat) ? "yuv" : "rgb",
base_addr_y, base_addr_c);
- mutex_lock(&priv->lock);
-
/* we can't handle wider than 8192px */
if (xres > 8192) {
dev_err(&pdev->dev, "width exceeding the limit (> 8192).");
- error = -EINVAL;
- goto err;
- }
-
- if (priv->used_meram_cache_regions + 2 > SH_MOBILE_MERAM_ICB_NUM) {
- dev_err(&pdev->dev, "no more ICB available.");
- error = -EINVAL;
- goto err;
+ return -EINVAL;
}
/* do we have at least one ICB config? */
if (cfg->icb[0].marker_icb < 0 || cfg->icb[0].cache_icb < 0) {
dev_err(&pdev->dev, "at least one ICB is required.");
+ return -EINVAL;
+ }
+
+ mutex_lock(&priv->lock);
+
+ if (priv->used_meram_cache_regions + 2 > SH_MOBILE_MERAM_ICB_NUM) {
+ dev_err(&pdev->dev, "no more ICB available.");
error = -EINVAL;
goto err;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/4] fbdev: sh_mobile_meram: Replace hardcoded register values with macros
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
Instead of hardcoding register values through the driver, define macros
for individual register bits using the register name and the bit name,
and use the macros.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 97 ++++++++++++++++++++++++++++----------
1 files changed, 71 insertions(+), 26 deletions(-)
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 39f28a1..85577cf 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -20,22 +20,67 @@
#include "sh_mobile_meram.h"
/* meram registers */
-#define MExxCTL 0x0
-#define MExxBSIZE 0x4
-#define MExxMNCF 0x8
-#define MExxSARA 0x10
-#define MExxSARB 0x14
-#define MExxSBSIZE 0x18
-
-#define MERAM_MExxCTL_VAL(ctl, next_icb, addr) \
- ((ctl) | (((next_icb) & 0x1f) << 11) | (((addr) & 0x7ff) << 16))
-#define MERAM_MExxBSIZE_VAL(a, b, c) \
- (((a) << 28) | ((b) << 16) | (c))
-
-#define MEVCR1 0x4
-#define MEACTS 0x10
-#define MEQSEL1 0x40
-#define MEQSEL2 0x44
+#define MEVCR1 0x4
+#define MEVCR1_RST (1 << 31)
+#define MEVCR1_WD (1 << 30)
+#define MEVCR1_AMD1 (1 << 29)
+#define MEVCR1_AMD0 (1 << 28)
+#define MEQSEL1 0x40
+#define MEQSEL2 0x44
+
+#define MExxCTL 0x400
+#define MExxCTL_BV (1 << 31)
+#define MExxCTL_BSZ_SHIFT 28
+#define MExxCTL_MSAR_MASK (0x7ff << MExxCTL_MSAR_SHIFT)
+#define MExxCTL_MSAR_SHIFT 16
+#define MExxCTL_NXT_MASK (0x1f << MExxCTL_NXT_SHIFT)
+#define MExxCTL_NXT_SHIFT 11
+#define MExxCTL_WD1 (1 << 10)
+#define MExxCTL_WD0 (1 << 9)
+#define MExxCTL_WS (1 << 8)
+#define MExxCTL_CB (1 << 7)
+#define MExxCTL_WBF (1 << 6)
+#define MExxCTL_WF (1 << 5)
+#define MExxCTL_RF (1 << 4)
+#define MExxCTL_CM (1 << 3)
+#define MExxCTL_MD_READ (1 << 0)
+#define MExxCTL_MD_WRITE (2 << 0)
+#define MExxCTL_MD_ICB_WB (3 << 0)
+#define MExxCTL_MD_ICB (4 << 0)
+#define MExxCTL_MD_FB (7 << 0)
+#define MExxCTL_MD_MASK (7 << 0)
+#define MExxBSIZE 0x404
+#define MExxBSIZE_RCNT_SHIFT 28
+#define MExxBSIZE_YSZM1_SHIFT 16
+#define MExxBSIZE_XSZM1_SHIFT 0
+#define MExxMNCF 0x408
+#define MExxMNCF_KWBNM_SHIFT 28
+#define MExxMNCF_KRBNM_SHIFT 24
+#define MExxMNCF_BNM_SHIFT 16
+#define MExxMNCF_XBV (1 << 15)
+#define MExxMNCF_CPL_YCBCR444 (1 << 12)
+#define MExxMNCF_CPL_YCBCR420 (2 << 12)
+#define MExxMNCF_CPL_YCBCR422 (3 << 12)
+#define MExxMNCF_CPL_MSK (3 << 12)
+#define MExxMNCF_BL (1 << 2)
+#define MExxMNCF_LNM_SHIFT 0
+#define MExxSARA 0x410
+#define MExxSARB 0x414
+#define MExxSBSIZE 0x418
+#define MExxSBSIZE_HDV (1 << 31)
+#define MExxSBSIZE_HSZ16 (0 << 28)
+#define MExxSBSIZE_HSZ32 (1 << 28)
+#define MExxSBSIZE_HSZ64 (2 << 28)
+#define MExxSBSIZE_HSZ128 (3 << 28)
+#define MExxSBSIZE_SBSIZZ_SHIFT 0
+
+#define MERAM_MExxCTL_VAL(next, addr) \
+ ((((next) << MExxCTL_NXT_SHIFT) & MExxCTL_NXT_MASK) | \
+ (((addr) << MExxCTL_MSAR_SHIFT) & MExxCTL_MSAR_MASK))
+#define MERAM_MExxBSIZE_VAL(rcnt, yszm1, xszm1) \
+ (((rcnt) << MExxBSIZE_RCNT_SHIFT) | \
+ ((yszm1) << MExxBSIZE_YSZM1_SHIFT) | \
+ ((xszm1) << MExxBSIZE_XSZM1_SHIFT))
static unsigned long common_regs[] = {
MEVCR1,
@@ -72,8 +117,7 @@ struct sh_mobile_meram_priv {
* MERAM/ICB access functions
*/
-#define MERAM_ICB_OFFSET(base, idx, off) \
- ((base) + (0x400 + ((idx) * 0x20) + (off)))
+#define MERAM_ICB_OFFSET(base, idx, off) ((base) + (off) + (idx) * 0x20)
static inline void meram_write_icb(void __iomem *base, int idx, int off,
unsigned long val)
@@ -308,17 +352,18 @@ static int meram_init(struct sh_mobile_meram_priv *priv,
/*
* Set MERAM for framebuffer
*
- * 0x70f: WD = 0x3, WS=0x1, CM=0x1, MDû mode
* we also chain the cache_icb and the marker_icb.
* we also split the allocated MERAM buffer between two ICBs.
*/
meram_write_icb(priv->base, icb->cache_icb, MExxCTL,
- MERAM_MExxCTL_VAL(0x70f, icb->marker_icb,
- icb->meram_offset));
+ MERAM_MExxCTL_VAL(icb->marker_icb, icb->meram_offset) |
+ MExxCTL_WD1 | MExxCTL_WD0 | MExxCTL_WS | MExxCTL_CM |
+ MExxCTL_MD_FB);
meram_write_icb(priv->base, icb->marker_icb, MExxCTL,
- MERAM_MExxCTL_VAL(0x70f, icb->cache_icb,
- icb->meram_offset +
- icb->meram_size / 2));
+ MERAM_MExxCTL_VAL(icb->cache_icb, icb->meram_offset +
+ icb->meram_size / 2) |
+ MExxCTL_WD1 | MExxCTL_WD0 | MExxCTL_WS | MExxCTL_CM |
+ MExxCTL_MD_FB);
return 0;
}
@@ -507,7 +552,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
/* Reset ICB on resume */
if (icb_regs[k] = MExxCTL)
priv->icb_saved_regs[j * ICB_REGS_SIZE + k] - 0x70;
+ MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF;
}
}
return 0;
@@ -592,7 +637,7 @@ static int __devinit sh_mobile_meram_probe(struct platform_device *pdev)
/* initialize ICB addressing mode */
if (pdata->addr_mode = SH_MOBILE_MERAM_MODE1)
- meram_write_reg(priv->base, MEVCR1, 1 << 29);
+ meram_write_reg(priv->base, MEVCR1, MEVCR1_AMD1);
pm_runtime_enable(&pdev->dev);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/4] sh_mobile_meram cleanups and fixes
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
Hi everybody,
This patch series follows the sh_mobile_lcdc patches I've posted to the list.
As with the previous series, I've started with a readability patch that made
me find a bug. Patches 1/4, 2/4 and 4/4 are cleanups, and patch 3/4 fix the
bug. Please see individual patch descriptions for details.
Laurent Pinchart (4):
fbdev: sh_mobile_meram: Replace hardcoded register values with macros
fbdev: sh_mobile_meram: Validate ICB configuration outside mutex
fbdev: sh_mobile_meram: Fix MExxCTL register save on runtime PM
suspend
fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h
drivers/video/sh_mobile_lcdcfb.c | 2 +-
drivers/video/sh_mobile_meram.c | 122 ++++++++++++++++++++++++++------------
drivers/video/sh_mobile_meram.h | 33 ----------
3 files changed, 84 insertions(+), 73 deletions(-)
delete mode 100644 drivers/video/sh_mobile_meram.h
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [Bugme-new] [Bug 39842] New: savagefb.h CARD SERIES definition
From: John Stanley @ 2011-07-29 12:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110728162752.3a4602e4.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]
Replying to all.. I have also attached the one-line patch.
thanks,
John
On 07/28/2011 07:27 PM, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Sat, 23 Jul 2011 10:20:41 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=39842
>>
>> Summary: savagefb.h CARD SERIES definition typo
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 3.0.0
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Video(Other)
>> AssignedTo: drivers_video-other@kernel-bugs.osdl.org
>> ReportedBy: jpsinthemix@verizon.net
>> Regression: Yes
>>
>>
>> I have an old T22 Thinkpad with integrated Savage/IX-MV video. As of linux-3.0,
>> the video is non-functional; the PC either hard hangs immediately or has
>> totally garbled video, and then hard hangs, as soon as I attempt to edit a file
>> or cat a file with more than a screen-full of text. The foregoing details are
>> actually not important any more as in looking at the code changes I discovered
>> a typo in linux-3.0.0/drivers/video/savage/savagefb.h and have applied the
>> following patch to fix the issue:
>>
>> --- linux-3.0.0.old/drivers/video/savage/savagefb.h 2011-07-21
>> 22:17:23.000000000 -0400
>> +++ linux-3.0.0.new/drivers/video/savage/savagefb.h 2011-07-23
>> 05:13:33.801215293 -0400
>> @@ -55,7 +55,7 @@
>>
>> #define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D)&&
>> (chip<=S3_SAVAGE_MX))
>>
>> -#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) ||
>> (chip<=S3_PROSAVAGEDDR))
>> +#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4)&&
>> (chip<=S3_PROSAVAGEDDR))
>>
>> #define S3_SAVAGE_MOBILE_SERIES(chip) ((chip==S3_SAVAGE_MX) ||
>> (chip==S3_SUPERSAVAGE))
>>
>>
>> P.S. Many, many thanks for lifting the 800x600 resolution limit! I've been
>> using a patch/hack to bump the limit to 1024x768 for an very long time...
>> John
> Please resend that fix as a formal signed-off-patch as a reply-to-all
> to this email? Documentation/SubmittingPatches has some tips.
>
> Thanks.
>
>
[-- Attachment #2: 01-linux-3.0.0-savagefb-card-series-fix.patch --]
[-- Type: text/plain, Size: 539 bytes --]
--- linux-3.0.0.old/drivers/video/savage/savagefb.h 2011-07-21 22:17:23.000000000 -0400
+++ linux-3.0.0.new/drivers/video/savage/savagefb.h 2011-07-23 05:13:33.801215293 -0400
@@ -55,7 +55,7 @@
#define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE_MX))
-#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) || (chip<=S3_PROSAVAGEDDR))
+#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) && (chip<=S3_PROSAVAGEDDR))
#define S3_SAVAGE_MOBILE_SERIES(chip) ((chip==S3_SAVAGE_MX) || (chip==S3_SUPERSAVAGE))
^ permalink raw reply
* Re: [Bugme-new] [Bug 39842] New: savagefb.h CARD SERIES definition
From: Andrew Morton @ 2011-07-28 23:27 UTC (permalink / raw)
To: linux-fbdev
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 23 Jul 2011 10:20:41 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id9842
>
> Summary: savagefb.h CARD SERIES definition typo
> Product: Drivers
> Version: 2.5
> Kernel Version: 3.0.0
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Video(Other)
> AssignedTo: drivers_video-other@kernel-bugs.osdl.org
> ReportedBy: jpsinthemix@verizon.net
> Regression: Yes
>
>
> I have an old T22 Thinkpad with integrated Savage/IX-MV video. As of linux-3.0,
> the video is non-functional; the PC either hard hangs immediately or has
> totally garbled video, and then hard hangs, as soon as I attempt to edit a file
> or cat a file with more than a screen-full of text. The foregoing details are
> actually not important any more as in looking at the code changes I discovered
> a typo in linux-3.0.0/drivers/video/savage/savagefb.h and have applied the
> following patch to fix the issue:
>
> --- linux-3.0.0.old/drivers/video/savage/savagefb.h 2011-07-21
> 22:17:23.000000000 -0400
> +++ linux-3.0.0.new/drivers/video/savage/savagefb.h 2011-07-23
> 05:13:33.801215293 -0400
> @@ -55,7 +55,7 @@
>
> #define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) &&
> (chip<=S3_SAVAGE_MX))
>
> -#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) ||
> (chip<=S3_PROSAVAGEDDR))
> +#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) &&
> (chip<=S3_PROSAVAGEDDR))
>
> #define S3_SAVAGE_MOBILE_SERIES(chip) ((chip=S3_SAVAGE_MX) ||
> (chip=S3_SUPERSAVAGE))
>
>
> P.S. Many, many thanks for lifting the 800x600 resolution limit! I've been
> using a patch/hack to bump the limit to 1024x768 for an very long time...
> John
Please resend that fix as a formal signed-off-patch as a reply-to-all
to this email? Documentation/SubmittingPatches has some tips.
Thanks.
^ permalink raw reply
* Re: [PATCH] fb: avoid possible deadlock caused by fb_set_suspend
From: Francis Moreau @ 2011-07-28 22:10 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: lethal, linux-fbdev, torvalds, bonbons, linux-kernel,
Herton Ronaldo Krzesinski, stable
In-Reply-To: <4E271B72.3070909@gmx.de>
On Wed, Jul 20, 2011 at 8:16 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> what are your plans for the patch below? Do you queue it for 3.1?
Looks like someone else fixed it slightly differently:
http://permalink.gmane.org/gmane.linux.kernel.stable/15187
--
Francis
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-28 10:51 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Florian Tobias Schandinat, Geert Uytterhoeven, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <Pine.LNX.4.64.1107280943470.20737@axis700.grange>
Hi Guennadi,
Thanks for the review.
On Thursday 28 July 2011 10:31:24 Guennadi Liakhovetski wrote:
> On Mon, 11 Jul 2011, Laurent Pinchart wrote:
> > On Friday 24 June 2011 21:45:57 Florian Tobias Schandinat wrote:
> > > On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> > > > On Fri, Jun 24, 2011 at 08:19, Paul Mundt 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 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).
> >
> > I'm also not keen on adding/stripping the MSB. It would be easier for
> > applications to use FOURCCs directly.
> >
> > > > 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.
> >
> > I agree with Florian here. Many drivers currently check whether nonstd !> > 0. Who knows what kind of values applications feed them ?
>
> FWIW, I prefer the original Laurent's proposal, with a slight uncertainty
> about whether we need the .capability field, or whether the try-and-check
> approach is sufficient.
Try-and-check would be better, but unfortunately I don't think it would work.
Existing drivers will either ignore the new FB_VMODE_FOURCC flag or fail. I
expect many drivers that ignore it to still accept it blindly, and not clear
it, so applications won't be able to find out whether the flag is supported.
> As for struct fb_var_screeninfo fields to support switching to a FOURCC
> mode, I also prefer an explicit dedicated flag to specify switching to it.
> Even though using FOURCC doesn't fit under the notion of a videomode, using
> one of .vmode bits is too tempting, so, I would actually take the plunge and
> use FB_VMODE_FOURCC.
Another option would be to consider any grayscale > 1 value as a FOURCC. I've
briefly checked the in-tree drivers: they only assign grayscale with 0 or 1,
and check whether grayscale is 0 or different than 0. If a userspace
application only sets grayscale > 1 when talking to a driver that supports the
FOURCC-based API, we could get rid of the flag.
What can't be easily found out is whether existing applications set grayscale
to a > 1 value. They would break when used with FOURCC-aware drivers if we
consider any grayscale > 1 value as a FOURCC. Is that a risk we can take ?
> As for the actual location of the fourcc code, I would leave .nonstd
> alone: who knows, maybe drivers will need both, whereas using grayscale
> and fourcc certainly doesn't make any sense. And I personally don't see a
> problem with using a union: buggy applications are, well, buggy...
I agree with this.
> Actually, since in FOURCC mode we don't need any of
>
> __u32 bits_per_pixel; /* guess what */
> __u32 grayscale; /* != 0 Graylevels instead of colors */
>
> struct fb_bitfield red; /* bitfield in fb mem if true color, */
> struct fb_bitfield green; /* else only length is significant */
> struct fb_bitfield blue;
> struct fb_bitfield transp; /* transparency */
>
> so, we could put them all in the union for the case, if we need anything
> else for the fourcc configuration in the future.
Good point. It might make sense to exclude bits_per_pixel from the union
though, as that's interesting information for applications. The red, green,
blue and transp fields are less useful.
> > I'd like to reach an agreement on the API, and implement it. I'm fine
> > with either grayscale or nonstd to store the FOURCC (with a slight
> > preference for grayscale), and with either a vmode flag or using the
> > most significant byte of the grayscale/nonstd field to detect FOURCC
> > mode. I believe FB_CAP_FOURCC (or something similar) is needed.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Guennadi Liakhovetski @ 2011-07-28 8:31 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Florian Tobias Schandinat, Geert Uytterhoeven, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <201107111732.52156.laurent.pinchart@ideasonboard.com>
On Mon, 11 Jul 2011, Laurent Pinchart wrote:
> On Friday 24 June 2011 21:45:57 Florian Tobias Schandinat wrote:
> > On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> > > On Fri, Jun 24, 2011 at 08:19, Paul Mundt 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 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).
>
> I'm also not keen on adding/stripping the MSB. It would be easier for
> applications to use FOURCCs directly.
>
> > > 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.
>
> I agree with Florian here. Many drivers currently check whether nonstd != 0.
> Who knows what kind of values applications feed them ?
FWIW, I prefer the original Laurent's proposal, with a slight uncertainty
about whether we need the .capability field, or whether the try-and-check
approach is sufficient. As for struct fb_var_screeninfo fields to support
switching to a FOURCC mode, I also prefer an explicit dedicated flag to
specify switching to it. Even though using FOURCC doesn't fit under the
notion of a videomode, using one of .vmode bits is too tempting, so, I
would actually take the plunge and use FB_VMODE_FOURCC.
As for the actual location of the fourcc code, I would leave .nonstd
alone: who knows, maybe drivers will need both, whereas using grayscale
and fourcc certainly doesn't make any sense. And I personally don't see a
problem with using a union: buggy applications are, well, buggy...
Actually, since in FOURCC mode we don't need any of
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
so, we could put them all in the union for the case, if we need anything
else for the fourcc configuration in the future.
> I'd like to reach an agreement on the API, and implement it. I'm fine with
> either grayscale or nonstd to store the FOURCC (with a slight preference for
> grayscale), and with either a vmode flag or using the most significant byte of
> the grayscale/nonstd field to detect FOURCC mode. I believe FB_CAP_FOURCC (or
> something similar) is needed.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v2] backlight/platform_lcd: change set power function parameter
From: Donggeun Kim @ 2011-07-27 9:12 UTC (permalink / raw)
To: linux-fbdev
Cc: rpurdie, lethal, linux-kernel, kyungmin.park, dh09.lee, dg77.kim
The set_power function in platdata for platform_lcd driver
has originally two parameters.
The first parameter type is struct plat_lcd_data * and
the second parameter type is unsigned int .
In some cases, it is needed to get pointer typed 'struct device'
in order to call regulator_* functions.
This patch allows users to define a set_power function
which control regulators related to platform_lcd device.
Currently, variables in struct plat_lcd_data are not used
in several set_power functions which are defined at arch/arm/ directory.
Changes since v1 :
* Remove compile warning message by including another heeder file
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/backlight/platform_lcd.c | 2 +-
include/video/platform_lcd.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index 302330a..cf23a3f 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -49,7 +49,7 @@ static int platform_lcd_set_power(struct lcd_device *lcd, int power)
if (power = FB_BLANK_POWERDOWN || plcd->suspended)
lcd_power = 0;
- plcd->pdata->set_power(plcd->pdata, lcd_power);
+ plcd->pdata->set_power(lcd, lcd_power);
plcd->power = power;
return 0;
diff --git a/include/video/platform_lcd.h b/include/video/platform_lcd.h
index ad3bdfe..5d7e943 100644
--- a/include/video/platform_lcd.h
+++ b/include/video/platform_lcd.h
@@ -10,12 +10,13 @@
* published by the Free Software Foundation.
*
*/
+#include <linux/lcd.h>
struct plat_lcd_data;
struct fb_info;
struct plat_lcd_data {
- void (*set_power)(struct plat_lcd_data *, unsigned int power);
+ void (*set_power)(struct lcd_device *, unsigned int power);
int (*match_fb)(struct plat_lcd_data *, struct fb_info *);
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH RESEND] video: s3c-fb: Add support EXYNOS4 FIMD
From: Jingoo Han @ 2011-07-26 9:48 UTC (permalink / raw)
To: linux-fbdev
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
* RE: [PATCH v3] video: da8xx-fb: Increased resolution configuration
From: Manjunathappa, Prakash @ 2011-07-26 4:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310963333-29806-1-git-send-email-prakash.pm@ti.com>
Hi Paul,
Could you please accept this patch as there are no comments?
Thanks,
Prakash
On Mon, Jul 18, 2011 at 09:58:53, Manjunathappa, Prakash wrote:
> Revised LCD controller in upcoming TI SoC which is an updated version of
> LCDC IP that was found on TI's DA850 SoC 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.
>
> Patch is verified on emulation platform of upcoming SoC for updated
> feature and on DA850 platform to make sure nothing existing breaks.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> Since v2:
> Corrected comment describing horizontal resolution bits and removed unnecessary
> outer parenthesis.
> Since v1:
> 1)Fixed the bug in configuration of lpp_b10 in Raster Timing2[26] register.
> 2)Reframed commit message.
>
> drivers/video/da8xx-fb.c | 31 ++++++++++++++++++++++++++++---
> 1 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 620f1c3..94b611a 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -460,18 +460,43 @@ 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 4..10 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) & 0x400) << 16;
> + 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
* [PATCH RESEND 1/7] video: s3c-fb: Add S5P64X0 specific
From: Ajay Kumar @ 2011-07-25 14:11 UTC (permalink / raw)
To: linux-fbdev
This patch:
Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
Also, register "s5p64x0-fb" type driver_data.
Existing s3c_fb_driverdata definitions in s3c-fb.c
supports 5 or 2 windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
acked-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 4aecf21..0fda252 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
},
};
+static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
+ .variant = {
+ .nr_windows = 3,
+ .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,
+ },
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+};
+
static struct platform_device_id s3c_fb_driver_ids[] = {
{
.name = "s3c-fb",
@@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
}, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
+ }, {
+ .name = "s5p64x0-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_s5p64x0,
},
{},
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-25 10:30 UTC (permalink / raw)
To: dri-devel
Cc: Florian Tobias Schandinat, linux-fbdev, Paul Mundt,
Geert Uytterhoeven, linux-media
In-Reply-To: <201107111732.52156.laurent.pinchart@ideasonboard.com>
Ping ?
As stated in my previous mail, I'd like to reach an agreement on the API, and
implement it. I'm fine with either grayscale or nonstd to store the FOURCC
(with a slight preference for grayscale), and with either a vmode flag or
using the most significant byte of the grayscale/nonstd field to detect FOURCC
mode. I believe FB_CAP_FOURCC (or something similar) is needed.
Paul, Geert, Florian, what are your opinions ?
On Monday 11 July 2011 17:32:51 Laurent Pinchart wrote:
> On Friday 24 June 2011 21:45:57 Florian Tobias Schandinat wrote:
> > On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> > > On Fri, Jun 24, 2011 at 08:19, Paul Mundt 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 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).
>
> I'm also not keen on adding/stripping the MSB. It would be easier for
> applications to use FOURCCs directly.
>
> > > 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.
>
> I agree with Florian here. Many drivers currently check whether nonstd !> 0. Who knows what kind of values applications feed them ?
>
> I'd like to reach an agreement on the API, and implement it. I'm fine with
> either grayscale or nonstd to store the FOURCC (with a slight preference
> for grayscale), and with either a vmode flag or using the most significant
> byte of the grayscale/nonstd field to detect FOURCC mode. I believe
> FB_CAP_FOURCC (or something similar) is needed.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] drivers:video:remove the dup include file prefetch.h
From: Wanlong Gao @ 2011-07-24 4:18 UTC (permalink / raw)
To: linux-fbdev
linux/prefetch.h has been incuded more than once.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/video/udlfb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 816a4fd..087fc99 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -29,7 +29,6 @@
#include <linux/slab.h>
#include <linux/prefetch.h>
#include <linux/delay.h>
-#include <linux/prefetch.h>
#include <video/udlfb.h>
#include "edid.h"
--
1.7.4.1
^ permalink raw reply related
* Congratulation!!!
From: BBC NATIONAL PROMO @ 2011-07-22 1:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1311297573.4e28d0251878b@www.bitsnet.com.br>
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,500,000 pounds in the
British Broadcasting corporation (BBC) Online Promo Held on this month of July
2011, and you are to acknowledge the receipt of this mail with the
details below to.
CLAIMS DIRECTOR BBC ONLINE PROMOTION.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Congratulation!!!
From: BBC NATIONAL PROMO @ 2011-07-22 1:19 UTC (permalink / raw)
To: linux-fbdev
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,500,000 pounds in the
British Broadcasting corporation (BBC) Online Promo Held on this month of July
2011, and you are to acknowledge the receipt of this mail with the
details below to.
CLAIMS DIRECTOR BBC ONLINE PROMOTION.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* RE: [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
From: JinGoo Han @ 2011-07-22 1:06 UTC (permalink / raw)
To: Paul Mundt
Cc: Kukjin Kim, linux-samsung-soc@vger.kernel.org,
linux-fbdev@vger.kernel.org, Jong-Hun Han, Ben Dooks, JinGoo Han
In-Reply-To: <1311202461-18235-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: 8342 bytes --]
Hi Paul,
Other patches were commited to 'linux-arm-soc.git'.
Please, commit this patch '[PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD' to 'fbdev-2.6'.
Thanks,
Jingoo Han
Jingoo Han wrote:
> -----Original Message-----
> Subject: [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
>
> 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
ÿôèº{.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 V8 0/5] ARM: EXYNOS4: Add support EXYNOS4 FIMD
From: Kukjin Kim @ 2011-07-21 7:53 UTC (permalink / raw)
To: 'Jingoo Han', 'Paul Mundt', linux-samsung-soc,
linux-fbdev
Cc: 'Jonghun Han', 'Ben Dooks'
In-Reply-To: <1311202438-18105-1-git-send-email-jg1.han@samsung.com>
Jingoo Han wrote:
>
> The patches are created against "for-next" branch of Kukjin Kim's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> This was originally submitted by Jonghun Han <jonghun.han@samsung.com>
> http://www.spinics.net/lists/arm-kernel/msg101781.html
>
> This patch adds support FIMD(Fully Interactive Mobile Display) on Exynos4.
> The 4th patch is update for s3c-fb and others are for platform data
>
> NOTE: The common part for SMDKV310 will be updated later.
>
> v2: change clock name of exynos4 FIMD: "fimd" -> "lcd"
> use 'has_clksel' variable in order to distinguish FIMD version
> add 'lcd_clk' that can be used for only lcd pixel clock
> add callback 'enable_clk()' to enable parent clock 'sclk_fimd'.
> v3: remove the callback from the platform data structure
> v4: move clk_enable(sfb->lcd_clk) under the if statement
> v5: add clk_enable/disable(sfb->lcd_clk) to
s3c_fb_runtime_suspend/resume().
> v6: rename dev-fimd-24bpp.c to dev-fimd0.c
> add 'exynos4_fimd0_setup_clock()' to dev-fimd0.c to setup parent
clock.
> v7: remove parent clock setting from machine directory
> use 'gpio_request_one()' to simply the gpio setting step
> v8: updated minor fixes
>
> o To Kukjin Kim
> [PATCH V8 1/5] ARM: EXYNOS4: Change clock name for FIMD
> [PATCH V8 2/5] ARM: EXYNOS4: Add resource definition for FIMD
> [PATCH V8 3/5] ARM: EXYNOS4: Add platform device and helper functions for
> FIMD
> [PATCH V8 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and
> LTE480WV platform-lcd on SMDKC210
>
Hi Jingoo,
As I replied in your 1st patch, will fix it when I apply this series.
Others, looks ok to me.
As you said, we need to implement handling of common part on each boards
next time :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> o To Paul Mundt
> [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4
^ permalink raw reply
* RE: [PATCH V8 1/5] ARM: EXYNOS4: Change clock name for FIMD
From: Kukjin Kim @ 2011-07-21 7:16 UTC (permalink / raw)
To: 'Jingoo Han', 'Paul Mundt', linux-samsung-soc,
linux-fbdev
Cc: 'Jonghun Han', 'Ben Dooks'
In-Reply-To: <1311202444-18137-1-git-send-email-jg1.han@samsung.com>
Jingoo Han wrote:
>
> This patch changes clock for FIMD from 'fimd' to 'lcd'.
> Also, devname for FIMD is changed from 's5pv310-fb' to 'exynos4-fb'.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> arch/arm/mach-exynos4/clock.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
> index 98b5cc4..778a202 100644
> --- a/arch/arm/mach-exynos4/clock.c
> +++ b/arch/arm/mach-exynos4/clock.c
> @@ -405,13 +405,13 @@ static struct clk init_clocks_off[] = {
> .enable = exynos4_clk_ip_cam_ctrl,
> .ctrlbit = (1 << 3),
> }, {
> - .name = "fimd",
> - .devname = "s5pv310-fb.0",
> + .name = "lcd",
> + .devname = "exynos4-fb.0",
> .enable = exynos4_clk_ip_lcd0_ctrl,
> .ctrlbit = (1 << 0),
> }, {
> - .name = "fimd",
> - .devname = "s5pv310-fb.1",
> + .name = "lcd",
As I remember, some guys discussed about the clock name before.
Please refer to the following diagram. Before EXYNOS4210 clk 'lcd' was used
for FIMD IP core clock and source of the LCD pixel clock. But the mux used
to select source of LCD pixel clock is removed. So 'lcd' clock is only used
for core clock of FIMD IP. It isn't used for LCD pixel clock.
As a result clock name was changed from lcd to fimd in the EXYNOS4210
datasheet.
Before EXYNOS4
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'lcd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | +-+-+ +----+ |
|u|-+ | | +-+core| |
|x| | | | +----+ |
|/ | | | |\ |
| | +-|m| +---+ |
| | |u|--+div| |
+------+---|x| +---+ |
2.SCLK_FIMD | |/ | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
EXYNOS4210
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'fimd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | | +----+ |
|u|-+ | +---+core| |
|x| | | +----+ |
|/ | | |
| | +---+ |
| | +--+div| |
+------+-----+ +---+ |
2.SCLK_FIMD | | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
To change devname is ok to me. So will apply only it.
If any problems, please let me know :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> + .devname = "exynos4-fb.1",
> .enable = exynos4_clk_ip_lcd1_ctrl,
> .ctrlbit = (1 << 0),
> }, {
> @@ -909,7 +909,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimd",
> - .devname = "s5pv310-fb.0",
> + .devname = "exynos4-fb.0",
> .enable = exynos4_clksrc_mask_lcd0_ctrl,
> .ctrlbit = (1 << 0),
> },
> @@ -919,7 +919,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimd",
> - .devname = "s5pv310-fb.1",
> + .devname = "exynos4-fb.1",
> .enable = exynos4_clksrc_mask_lcd1_ctrl,
> .ctrlbit = (1 << 0),
> },
> --
> 1.7.1
^ permalink raw reply
* Re: [GIT PULL] viafb updates for 3.1
From: Paul Mundt @ 2011-07-21 6:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4E26F2D1.5040205@gmx.de>
On Wed, Jul 20, 2011 at 03:22:57PM +0000, Florian Tobias Schandinat wrote:
> please pull the viafb updates below. It contains only 2 fixes.
>
Pulled, thanks.
^ permalink raw reply
* [PATCH V8 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and LTE480WV platform-lcd on SMDKC21
From: Jingoo Han @ 2011-07-20 22:54 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Jonghun Han, Ben Dooks, Jingoo Han
This patch adds support EXYNOS4 FIMD0 and LTE480WV LCD pannel
on SMDKC210 board.
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 | 71 +++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-smdkc210.c b/arch/arm/mach-exynos4/mach-smdkc210.c
index e645f7a..31cfcd6 100644
--- a/arch/arm/mach-exynos4/mach-smdkc210.c
+++ b/arch/arm/mach-exynos4/mach-smdkc210.c
@@ -9,7 +9,9 @@
*/
#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>
@@ -19,11 +21,15 @@
#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/regs-fb-v4.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>
@@ -111,6 +117,67 @@ 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_one(EXYNOS4_GPD0(1), GPIOF_OUT_INIT_HIGH, "GPD0");
+ 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_one(EXYNOS4_GPD0(1), GPIOF_OUT_INIT_LOW, "GPD0");
+ 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 +232,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,
};
@@ -210,6 +279,8 @@ static void __init smdkc210_machine_init(void)
s3c_sdhci2_set_platdata(&smdkc210_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkc210_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(&smdkc210_lcd0_pdata);
+
platform_add_devices(smdkc210_devices, ARRAY_SIZE(smdkc210_devices));
}
--
1.7.1
^ permalink raw reply related
* [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
From: Jingoo Han @ 2011-07-20 22:54 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Jonghun Han, 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
* [PATCH V8 3/5] ARM: EXYNOS4: Add platform device and helper functions for FIMD
From: Jingoo Han @ 2011-07-20 22:54 UTC (permalink / raw)
To: Kukjin Kim, Paul Mundt, linux-samsung-soc, linux-fbdev
Cc: Jonghun Han, Ben Dooks, 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 | 3 +
arch/arm/mach-exynos4/setup-fimd0.c | 43 ++++++++++++++++
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 ++++++
10 files changed, 160 insertions(+), 0 deletions(-)
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 a4fb109..83518b5 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -26,6 +26,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
@@ -104,6 +109,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
@@ -113,6 +119,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
@@ -121,6 +128,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
@@ -132,6 +140,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 c3c70ab..b1077f4 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -40,6 +40,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 910ade6..85a0b96 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -23,6 +23,7 @@
#include <plat/exynos4.h>
#include <plat/sdhci.h>
#include <plat/devs.h>
+#include <plat/fb-core.h>
#include <plat/fimc-core.h>
#include <plat/iic-core.h>
@@ -149,6 +150,8 @@ void __init exynos4_map_io(void)
s3c_i2c0_setname("s3c2440-i2c");
s3c_i2c1_setname("s3c2440-i2c");
s3c_i2c2_setname("s3c2440-i2c");
+
+ s5p_fb_setname(0, "exynos4-fb");
}
void __init exynos4_init_clocks(int xtal)
diff --git a/arch/arm/mach-exynos4/setup-fimd0.c b/arch/arm/mach-exynos4/setup-fimd0.c
new file mode 100644
index 0000000..ca7ae71
--- /dev/null
+++ b/arch/arm/mach-exynos4/setup-fimd0.c
@@ -0,0 +1,43 @@
+/* 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/fb.h>
+#include <linux/gpio.h>
+
+#include <plat/gpio-cfg.h>
+#include <plat/regs-fb-v4.h>
+
+#include <mach/map.h>
+
+void exynos4_fimd0_gpio_setup_24bpp(void)
+{
+ unsigned int reg;
+
+ 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 7f9ff2a..7537ad5 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -71,6 +71,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..f728bb5
--- /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 e3b31c2..81143b7 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -49,6 +49,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
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