* Re: [PATCH 5/5] s3fb: use new start address register
From: Ondrej Zajicek @ 2011-03-03 8:50 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103012018.45635.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
On Tue, Mar 01, 2011 at 08:18:43PM +0100, Ondrej Zary wrote:
> Use "new" start address register 0x69 (bits 16-20) instead of "old" 0x31
> (bits 16-17) and 0x51 (bits 18-19). This is needed for panning to work
> correctly on Trio3D/2X cards (and does no harm on other ones).
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5]: s3fb: enable DTPC
From: Ondrej Zajicek @ 2011-03-03 8:50 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103012018.37764.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Tue, Mar 01, 2011 at 08:18:35PM +0100, Ondrej Zary wrote:
> Enable Data Transfer Position Control (DTPC). This is needed at least on
> Virge/DX to correctly display at higher pixclocks.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] s3fb: fix 15/16bpp modes with over 115MHz
From: Ondrej Zajicek @ 2011-03-03 8:50 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103012018.30651.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On Tue, Mar 01, 2011 at 08:18:27PM +0100, Ondrej Zary wrote:
> Enable pixel multiplexing in 15/16bpp modes when pixclock is over 115MHz
> on Trio3D (86C365) cards to fix artifacts on the left side of screen.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] s3fb: add support for 86C365 Trio3D
From: Ondrej Zajicek @ 2011-03-03 8:49 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103012018.19557.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Tue, Mar 01, 2011 at 08:18:17PM +0100, Ondrej Zary wrote:
> Add support for S3 Trio3D (86C365) cards to s3fb driver. Tested with one 4MB card.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] s3fb: maximize virtual vertical size for fast
From: Ondrej Zajicek @ 2011-03-03 8:49 UTC (permalink / raw)
To: Ondrej Zary; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <201103012018.11283.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Tue, Mar 01, 2011 at 08:18:08PM +0100, Ondrej Zary wrote:
> Maximize virtual vertical framebuffer size during init to allow fast scrolling
> (accelerated by panning).
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] [ARM] msm_fb: Fix framebuffer console
From: Carl Vanderlip @ 2011-03-02 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299100671-11665-1-git-send-email-carlv@codeaurora.org>
On Wed, 2011-03-02 at 13:17 -0800, Carl Vanderlip wrote:
> From: Arve Hjønnevåg <arve@android.com>
>
> Don't allow non panning updates to bypass the wait for the panel to turn
on.
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
Arve,
This patch did not have a SOB from you. Would you sign off on this patch?
-Carl V.
^ permalink raw reply
* [PATCH 4/4] [ARM] msm: mdp: Set the correct pack pattern for XRGB/ARGB
From: Carl Vanderlip @ 2011-03-02 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299100542-11120-1-git-send-email-carlv@codeaurora.org>
From: Dima Zavin <dima@android.com>
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
---
drivers/video/msm/mdp_hw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/msm/mdp_hw.h b/drivers/video/msm/mdp_hw.h
index 9e1e92e..d804774 100644
--- a/drivers/video/msm/mdp_hw.h
+++ b/drivers/video/msm/mdp_hw.h
@@ -489,7 +489,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
MDP_GET_PACK_PATTERN(0, CLR_R, CLR_G, CLR_B, 8)
#define PPP_PACK_PATTERN_MDP_RGB_888 PPP_PACK_PATTERN_MDP_RGB_565
#define PPP_PACK_PATTERN_MDP_XRGB_8888 \
- MDP_GET_PACK_PATTERN(CLR_ALPHA, CLR_R, CLR_G, CLR_B, 8)
+ MDP_GET_PACK_PATTERN(CLR_B, CLR_G, CLR_R, CLR_ALPHA, 8)
#define PPP_PACK_PATTERN_MDP_ARGB_8888 PPP_PACK_PATTERN_MDP_XRGB_8888
#define PPP_PACK_PATTERN_MDP_RGBA_8888 \
MDP_GET_PACK_PATTERN(CLR_ALPHA, CLR_B, CLR_G, CLR_R, 8)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 3/4] [ARM] msm_fb: Fix framebuffer console
From: Carl Vanderlip @ 2011-03-02 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299100542-11120-1-git-send-email-carlv@codeaurora.org>
From: Arve Hjønnevåg <arve@android.com>
Don't allow non panning updates to bypass the wait for the panel to turn on.
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
---
drivers/video/msm/msm_fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
index fe5efe5..ec35130 100644
--- a/drivers/video/msm/msm_fb.c
+++ b/drivers/video/msm/msm_fb.c
@@ -219,8 +219,8 @@ restart:
sleeping = msmfb->sleeping;
/* on a full update, if the last frame has not completed, wait for it */
- if (pan_display && (msmfb->frame_requested != msmfb->frame_done ||
- sleeping = UPDATING)) {
+ if ((pan_display && msmfb->frame_requested != msmfb->frame_done) ||
+ sleeping = UPDATING) {
int ret;
spin_unlock_irqrestore(&msmfb->update_lock, irq_flags);
ret = wait_event_interruptible_timeout(msmfb->frame_wq,
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 2/4] [ARM] msm: mdp: Add support for RGBX 8888 image format.
From: Carl Vanderlip @ 2011-03-02 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299100542-11120-1-git-send-email-carlv@codeaurora.org>
From: Dima Zavin <dima@android.com>
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
---
drivers/video/msm/mdp_hw.h | 9 ++++++++-
drivers/video/msm/mdp_ppp.c | 1 +
include/linux/msm_mdp.h | 1 +
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/video/msm/mdp_hw.h b/drivers/video/msm/mdp_hw.h
index 4e3deb4..9e1e92e 100644
--- a/drivers/video/msm/mdp_hw.h
+++ b/drivers/video/msm/mdp_hw.h
@@ -449,6 +449,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
#define PPP_CFG_MDP_XRGB_8888(dir) PPP_CFG_MDP_ARGB_8888(dir)
#define PPP_CFG_MDP_RGBA_8888(dir) PPP_CFG_MDP_ARGB_8888(dir)
#define PPP_CFG_MDP_BGRA_8888(dir) PPP_CFG_MDP_ARGB_8888(dir)
+#define PPP_CFG_MDP_RGBX_8888(dir) PPP_CFG_MDP_ARGB_8888(dir)
#define PPP_CFG_MDP_Y_CBCR_H2V2(dir) (PPP_##dir##_C2R_8BIT | \
PPP_##dir##_C0G_8BIT | \
@@ -494,6 +495,8 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
MDP_GET_PACK_PATTERN(CLR_ALPHA, CLR_B, CLR_G, CLR_R, 8)
#define PPP_PACK_PATTERN_MDP_BGRA_8888 \
MDP_GET_PACK_PATTERN(CLR_ALPHA, CLR_R, CLR_G, CLR_B, 8)
+#define PPP_PACK_PATTERN_MDP_RGBX_8888 \
+ MDP_GET_PACK_PATTERN(CLR_ALPHA, CLR_B, CLR_G, CLR_R, 8)
#define PPP_PACK_PATTERN_MDP_Y_CBCR_H2V1 \
MDP_GET_PACK_PATTERN(0, 0, CLR_CB, CLR_CR, 8)
#define PPP_PACK_PATTERN_MDP_Y_CBCR_H2V2 PPP_PACK_PATTERN_MDP_Y_CBCR_H2V1
@@ -509,6 +512,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
#define PPP_CHROMA_SAMP_MDP_ARGB_8888(dir) PPP_OP_##dir##_CHROMA_RGB
#define PPP_CHROMA_SAMP_MDP_RGBA_8888(dir) PPP_OP_##dir##_CHROMA_RGB
#define PPP_CHROMA_SAMP_MDP_BGRA_8888(dir) PPP_OP_##dir##_CHROMA_RGB
+#define PPP_CHROMA_SAMP_MDP_RGBX_8888(dir) PPP_OP_##dir##_CHROMA_RGB
#define PPP_CHROMA_SAMP_MDP_Y_CBCR_H2V1(dir) PPP_OP_##dir##_CHROMA_H2V1
#define PPP_CHROMA_SAMP_MDP_Y_CBCR_H2V2(dir) PPP_OP_##dir##_CHROMA_420
#define PPP_CHROMA_SAMP_MDP_Y_CRCB_H2V1(dir) PPP_OP_##dir##_CHROMA_H2V1
@@ -523,6 +527,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
[MDP_ARGB_8888] = PPP_##name##_MDP_ARGB_8888,\
[MDP_RGBA_8888] = PPP_##name##_MDP_RGBA_8888,\
[MDP_BGRA_8888] = PPP_##name##_MDP_BGRA_8888,\
+ [MDP_RGBX_8888] = PPP_##name##_MDP_RGBX_8888,\
[MDP_Y_CBCR_H2V1] = PPP_##name##_MDP_Y_CBCR_H2V1,\
[MDP_Y_CBCR_H2V2] = PPP_##name##_MDP_Y_CBCR_H2V2,\
[MDP_Y_CRCB_H2V1] = PPP_##name##_MDP_Y_CRCB_H2V1,\
@@ -536,6 +541,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
[MDP_ARGB_8888] = PPP_##name##_MDP_ARGB_8888(dir),\
[MDP_RGBA_8888] = PPP_##name##_MDP_RGBA_8888(dir),\
[MDP_BGRA_8888] = PPP_##name##_MDP_BGRA_8888(dir),\
+ [MDP_RGBX_8888] = PPP_##name##_MDP_RGBX_8888(dir),\
[MDP_Y_CBCR_H2V1] = PPP_##name##_MDP_Y_CBCR_H2V1(dir),\
[MDP_Y_CBCR_H2V2] = PPP_##name##_MDP_Y_CBCR_H2V2(dir),\
[MDP_Y_CRCB_H2V1] = PPP_##name##_MDP_Y_CRCB_H2V1(dir),\
@@ -547,7 +553,8 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct mdp_blit_req *req,
(img = MDP_YCRYCB_H2V1))
#define IS_RGB(img) ((img = MDP_RGB_565) | (img = MDP_RGB_888) | \
(img = MDP_ARGB_8888) | (img = MDP_RGBA_8888) | \
- (img = MDP_XRGB_8888) | (img = MDP_BGRA_8888))
+ (img = MDP_XRGB_8888) | (img = MDP_BGRA_8888) | \
+ (img = MDP_RGBX_8888))
#define HAS_ALPHA(img) ((img = MDP_ARGB_8888) | (img = MDP_RGBA_8888) | \
(img = MDP_BGRA_8888))
diff --git a/drivers/video/msm/mdp_ppp.c b/drivers/video/msm/mdp_ppp.c
index 4ff001f..2b6564e 100644
--- a/drivers/video/msm/mdp_ppp.c
+++ b/drivers/video/msm/mdp_ppp.c
@@ -69,6 +69,7 @@ static uint32_t bytes_per_pixel[] = {
[MDP_ARGB_8888] = 4,
[MDP_RGBA_8888] = 4,
[MDP_BGRA_8888] = 4,
+ [MDP_RGBX_8888] = 4,
[MDP_Y_CBCR_H2V1] = 1,
[MDP_Y_CBCR_H2V2] = 1,
[MDP_Y_CRCB_H2V1] = 1,
diff --git a/include/linux/msm_mdp.h b/include/linux/msm_mdp.h
index d11fe0f..fe722c1 100644
--- a/include/linux/msm_mdp.h
+++ b/include/linux/msm_mdp.h
@@ -32,6 +32,7 @@ enum {
MDP_Y_CBCR_H2V1, /* Y and CrCb, pseduo planar w/ Cr is in MSB */
MDP_RGBA_8888, /* ARGB 888 */
MDP_BGRA_8888, /* ABGR 888 */
+ MDP_RGBX_8888, /* RGBX 888 */
MDP_IMGTYPE_LIMIT /* Non valid image type after this enum */
};
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/4] video: msmfb: Put the partial update magic value into the fix_screen struct.
From: Carl Vanderlip @ 2011-03-02 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299100542-11120-1-git-send-email-carlv@codeaurora.org>
From: Dima Zavin <dima@android.com>
This can then be tested by userspace to see if the capability is supported.
Userspace cannot rely on that value being left in var_screen, since userspace
itself can change it.
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
---
drivers/video/msm/msm_fb.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
index 5436aeb..fe5efe5 100644
--- a/drivers/video/msm/msm_fb.c
+++ b/drivers/video/msm/msm_fb.c
@@ -469,6 +469,18 @@ static void setup_fb_info(struct msmfb_info *msmfb)
fb_info->var.yoffset = 0;
if (msmfb->panel->caps & MSMFB_CAP_PARTIAL_UPDATES) {
+ /*
+ * Set the param in the fixed screen, so userspace can't
+ * change it. This will be used to check for the
+ * capability.
+ */
+ fb_info->fix.reserved[0] = 0x5444;
+ fb_info->fix.reserved[1] = 0x5055;
+
+ /*
+ * This preloads the value so that if userspace doesn't
+ * change it, it will be a full update
+ */
fb_info->var.reserved[0] = 0x54445055;
fb_info->var.reserved[1] = 0;
fb_info->var.reserved[2] = (uint16_t)msmfb->xres |
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 0/4] Initial patches for MSM display update
From: Carl Vanderlip @ 2011-03-02 21:15 UTC (permalink / raw)
To: linux-arm-kernel
These are the first series of a set of patches to update the MSM display
drivers to support newer MDP versions and display modes (while also providing
a base for future display development). The original source for these patches
is the Google Android kernel tree located here:
http://android.git.kernel.org/kernel/msm.git
Arve Hjønnevåg (1):
[ARM] msm_fb: Fix framebuffer console
Dima Zavin (3):
video: msmfb: Put the partial update magic value into the fix_screen
struct.
[ARM] msm: mdp: Add support for RGBX 8888 image format.
[ARM] msm: mdp: Set the correct pack pattern for XRGB/ARGB
drivers/video/msm/mdp_hw.h | 11 +++++++++--
drivers/video/msm/mdp_ppp.c | 1 +
drivers/video/msm/msm_fb.c | 16 ++++++++++++++--
include/linux/msm_mdp.h | 1 +
4 files changed, 25 insertions(+), 4 deletions(-)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: (WARNING) possible deadlock in del_timer_sync, called from
From: Steven Rostedt @ 2011-03-02 18:12 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: linux-fbdev, linux-kernel, Thomas Gleixner
In-Reply-To: <4D6BB403.9000908@ladisch.de>
On Mon, Feb 28, 2011 at 03:41:07PM +0100, Clemens Ladisch wrote:
> While using the FB console, I tried to change the console log level
> with SysRq, and got this warning that del_timer_sync() is used in
> an interrupt handler:
Ug, del_timer_sync() can be called from interrupt context:
printk -> vt_console_print -> hide_cursor -> fbcon_cursor
-> fbcon_del_cursor_time -> del_timer_sync()
printk is allowed to be called from interrupt context. This is indeed a
true bug.
-- Steve
>
> SysRq :
> ------------[ cut here ]------------
> WARNING: at kernel/timer.c:983 del_timer_sync+0x93/0xae()
> Hardware name: System Product Name
> Modules linked in: soundcore firewire_ohci firewire_core ohci_hcd ehci_hcd
> Pid: 0, comm: kworker/0:1 Not tainted 2.6.38-rc6+ #235
> Call Trace:
> <IRQ> [<ffffffff8103a6df>] ? warn_slowpath_common+0x80/0x98
> [<ffffffff8103a70c>] ? warn_slowpath_null+0x15/0x17
> [<ffffffff810452a7>] ? del_timer_sync+0x93/0xae
> [<ffffffff81045214>] ? del_timer_sync+0x0/0xae
> [<ffffffff8120725a>] ? fbcon_del_cursor_timer+0x32/0x3d
> [<ffffffff812077f0>] ? fbcon_cursor+0x9a/0x152
> [<ffffffff8125fd84>] ? hide_cursor+0x2c/0x7d
> [<ffffffff8126022b>] ? vt_console_print+0xd9/0x2f7
> [<ffffffff8103a891>] ? __call_console_drivers+0x67/0x79
> [<ffffffff8103a8fc>] ? _call_console_drivers+0x59/0x5d
> [<ffffffff8103ae3e>] ? console_unlock+0x160/0x1ce
> [<ffffffff8103b44a>] ? vprintk+0x358/0x38e
> [<ffffffff81466199>] ? printk+0x3c/0x3e
> [<ffffffff812594ce>] ? __handle_sysrq+0x23/0x157
> [<ffffffff812594f0>] ? __handle_sysrq+0x45/0x157
> [<ffffffff81259758>] ? sysrq_filter+0x116/0x17b
> [<ffffffff8139b9c5>] ? input_pass_event+0xbe/0x111
> [<ffffffff8139b907>] ? input_pass_event+0x0/0x111
> [<ffffffff8139cfb4>] ? input_handle_event+0x42a/0x439
> [<ffffffff8139d0e9>] ? input_event+0x5b/0x7a
> [<ffffffff813a37f3>] ? atkbd_interrupt+0x50f/0x5e0
> [<ffffffff8139735c>] ? serio_interrupt+0x40/0x7c
> [<ffffffff81398647>] ? i8042_interrupt+0x289/0x2a3
> [<ffffffff8107ae98>] ? handle_IRQ_event+0x20/0xa8
> [<ffffffff8107cd68>] ? handle_edge_irq+0x103/0x14f
> [<ffffffff81004a2b>] ? handle_irq+0x83/0x8c
> [<ffffffff81004067>] ? do_IRQ+0x48/0xaf
> [<ffffffff81469a93>] ? ret_from_intr+0x0/0x13
> <EOI> [<ffffffff8105d49e>] ? tick_broadcast_oneshot_control+0x1a/0xfb
> [<ffffffff810098cc>] ? default_idle+0x27/0x43
> [<ffffffff810098ce>] ? default_idle+0x29/0x43
> [<ffffffff810098cc>] ? default_idle+0x27/0x43
> [<ffffffff81009a33>] ? c1e_idle+0xcd/0xf4
> [<ffffffff810012e5>] ? cpu_idle+0x5f/0x96
> [<ffffffff81462b7c>] ? start_secondary+0x1e3/0x1e5
> ---[ end trace 80565a42945fc993 ]---
> Changing Loglevel
> Loglevel set to 3
>
>
> To add insult to injury, my cursor is configured not to blink.
>
>
> Regards,
> Clemens
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Alan Cox @ 2011-03-02 11:27 UTC (permalink / raw)
To: Corbin Simpson
Cc: Geert Uytterhoeven, matsu, linux-fbdev, taki, linux-sh,
Magnus Damm, dri-devel, Damian, Guennadi Liakhovetski
In-Reply-To: <AANLkTikFPdZ1ER=Cb59LL2CwBTA2NExSiVaTPzbGsE_o@mail.gmail.com>
On Tue, 1 Mar 2011 13:31:19 -0800
Corbin Simpson <mostawesomedude@gmail.com> wrote:
> I am slightly curious about this as well; I have a device with only YUV
> scanout and was considering KMS, but don't know what the best approach is.
The problem with hiding behind a fake RGB frame buffer is you've then
completely stuffed any framebuffer based apps that could use YUV happily
(eg framebuffer video playback).
Far better to make the kernel tell the truth in these cases. You'll need
to add some tweaks to the fb code for it and a YUV boot penguin.[1]
If you want to run X on it then you can use shadowfb on the X side to do
your YUV/RGB adaptation.
Alan
--
[1] Am I the only one who thinks the fb code also needs an imagine of an
embarassed penguin that has wet itself to go with oops output ?
^ permalink raw reply
* Re: [PATCH] tmio: silence warnings introduced by mfd changes
From: Samuel Ortiz @ 2011-03-02 10:34 UTC (permalink / raw)
To: Andres Salomon
Cc: Stephen Rothwell, linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Chris Ball,
David Woodhouse, David Brownell, Greg Kroah-Hartman
In-Reply-To: <20110301123220.705d3368@debxo>
Hi Andres,
On Tue, Mar 01, 2011 at 12:32:20PM -0800, Andres Salomon wrote:
> On Tue, 1 Mar 2011 10:53:22 -0800
> Andres Salomon <dilinger@queued.net> wrote:
>
> > On Tue, 1 Mar 2011 15:42:30 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi Samuel,
> > >
> > > After merging the mfd tree, today's linux-next build (x86_64
> > > allmodconfig) produced these warnings:
> > >
> > > drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
> > > drivers/video/tmiofb.c:270: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_hw_mode': drivers/video/tmiofb.c:314: warning:
> > > initialization discards qualifiers from pointer target type
> > > drivers/video/tmiofb.c:314: warning: unused variable 'cell'
> > > drivers/video/tmiofb.c: In function 'tmiofb_probe':
> > > drivers/video/tmiofb.c:683: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_remove': drivers/video/tmiofb.c:811: warning:
> > > initialization discards qualifiers from pointer target type
> > > drivers/video/tmiofb.c: In function 'tmiofb_suspend':
> > > drivers/video/tmiofb.c:941: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_resume': drivers/video/tmiofb.c:973: warning:
> > > initialization discards qualifiers from pointer target type
> > >
> > > Introduced by commits 2a79bb1d72f5ac22dff96de340d90d512f852ecb
> > > ("mfd: mfd_cell is now implicitly available to tc6393xb drivers")
> > > and b6361637190e6cb7acb84509499942ada69e7136 ("fb: Use mfd_data
> > > instead of driver_data for tmio-fb").
> > >
> >
> > Oops, this should fix that.
> >
> >
> >
>
>
> Actually, I noticed that I screwed this up for the other tmio drivers
> as well. Here's a patch that addresses them all (you can
> ignore the previous patch).
Patch applied, thanks for fixing that.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH] omapfb: Fix linker error in
From: Tomi Valkeinen @ 2011-03-02 7:58 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1298968837-13584-1-git-send-email-jhnikula@gmail.com>
On Tue, 2011-03-01 at 02:40 -0600, Jarkko Nikula wrote:
> There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
> set. This can be triggered on OMAP2 builds when OMAP3 or OMAP4 are not set.
>
> drivers/built-in.o: In function `sdp2430_panel_disable':
> drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
> drivers/built-in.o: In function `sdp2430_panel_enable':
> drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'
>
> Fix this by selecting the TWL4030_CORE for MACH_OMAP_2430SDP when building
> with CONFIG_FB_OMAP as there is no own Kconfig entry for lcd_2430 and it is
> compiled always when both MACH_OMAP_2430SDP and FB_OMAP are set.
Thanks, applied.
Tomi
^ permalink raw reply
* [PATCH v2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-03-02 6:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298526433-6621-1-git-send-email-dhobsong@igel.co.jp>
Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats
(bpp = 12, 16, and 24) respectively.
When double-buffering both Y planes appear before the C planes (Y-Y-C-C),
as opposed to Y-C-Y-C.
Set .nonstd in struct sh_mobile_lcdc_chan_cfg to enable YUV mode, and use
.bpp to distiguish between the 3 modes.
The value of .nonstd is copied to bits 16-31 of LDDFR in the LCDC and
should be set accordingly.
.nonstd must be set to 0 for RGB mode.
Due to the encoding of YUV data, the framebuffer will clear to green
instead of black.
In YUV 420 mode, panning is only possible in 2 line increments.
Additionally in YUV 420 mode the vertical resolution of the framebuffer
must be an even number.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
Changed from v1
* Drop the use of SH_FB_YUV defines everywhere
* Delete the now unnecessary <linux/sh_mobile_fb.h>
* Delete the second patch in the series (now only this patch remains)
drivers/video/sh_mobile_lcdcfb.c | 141
++++++++++++++++++++++++++++++--------
drivers/video/sh_mobile_lcdcfb.h | 2 +-
include/video/sh_mobile_lcdc.h | 1 +
3 files changed, 115 insertions(+), 29 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c
index bf12e53..173973b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -67,6 +67,7 @@ static unsigned long lcdc_offs_mainlcd[NR_CH_REGS] = {
[LDSM1R] = 0x428,
[LDSM2R] = 0x42c,
[LDSA1R] = 0x430,
+ [LDSA2R] = 0x434,
[LDMLSR] = 0x438,
[LDHCNR] = 0x448,
[LDHSYNR] = 0x44c,
@@ -151,6 +152,7 @@ static bool banked(int reg_nr)
case LDDFR:
case LDSM1R:
case LDSA1R:
+ case LDSA2R:
case LDMLSR:
case LDHCNR:
case LDHSYNR:
@@ -463,6 +465,7 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
struct sh_mobile_lcdc_board_cfg *board_cfg;
unsigned long tmp;
int bpp = 0;
+ unsigned long ldddsr;
int k, m;
int ret = 0;
@@ -541,16 +544,21 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
}
/* word and long word swap */
- switch (bpp) {
- case 16:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 6);
- break;
- case 24:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 7);
- break;
- case 32:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 4);
- break;
+ ldddsr = lcdc_read(priv, _LDDDSR);
+ if (priv->ch[0].info->var.nonstd)
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ else {
+ switch (bpp) {
+ case 16:
+ lcdc_write(priv, _LDDDSR, ldddsr | 6);
+ break;
+ case 24:
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ break;
+ case 32:
+ lcdc_write(priv, _LDDDSR, ldddsr | 4);
+ break;
+ }
}
for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
@@ -561,21 +569,40 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
/* set bpp format in PKF[4:0] */
tmp = lcdc_read_chan(ch, LDDFR);
- tmp &= ~0x0001001f;
- switch (ch->info->var.bits_per_pixel) {
- case 16:
- tmp |= 0x03;
- break;
- case 24:
- tmp |= 0x0b;
- break;
- case 32:
- break;
+ tmp &= ~0x0003031f;
+ if (ch->info->var.nonstd) {
+ tmp |= (ch->info->var.nonstd << 16);
+ switch (ch->info->var.bits_per_pixel) {
+ case 12:
+ break;
+ case 16:
+ tmp |= (0x1 << 8);
+ break;
+ case 24:
+ tmp |= (0x2 << 8);
+ break;
+ }
+ } else {
+ switch (ch->info->var.bits_per_pixel) {
+ case 16:
+ tmp |= 0x03;
+ break;
+ case 24:
+ tmp |= 0x0b;
+ break;
+ case 32:
+ break;
+ }
}
lcdc_write_chan(ch, LDDFR, tmp);
/* point out our frame buffer */
lcdc_write_chan(ch, LDSA1R, ch->info->fix.smem_start);
+ if (ch->info->var.nonstd)
+ lcdc_write_chan(ch, LDSA2R,
+ ch->info->fix.smem_start +
+ ch->info->var.xres *
+ ch->info->var.yres_virtual);
/* set line size */
lcdc_write_chan(ch, LDMLSR, ch->info->fix.line_length);
@@ -804,9 +831,15 @@ static int sh_mobile_fb_pan_display(struct
fb_var_screeninfo *var,
struct sh_mobile_lcdc_priv *priv = ch->lcdc;
unsigned long ldrcntr;
unsigned long new_pan_offset;
+ unsigned long base_addr_y, base_addr_c;
+ unsigned long c_offset;
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * (info->var.bits_per_pixel / 8));
+ if (!var->nonstd)
+ new_pan_offset = (var->yoffset * info->fix.line_length) +
+ (var->xoffset * (info->var.bits_per_pixel / 8));
+ else
+ new_pan_offset = (var->yoffset * info->fix.line_length) +
+ (var->xoffset);
if (new_pan_offset = ch->pan_offset)
return 0; /* No change, do nothing */
@@ -814,7 +847,26 @@ static int sh_mobile_fb_pan_display(struct
fb_var_screeninfo *var,
ldrcntr = lcdc_read(priv, _LDRCNTR);
/* Set the source address for the next refresh */
- lcdc_write_chan_mirror(ch, LDSA1R, ch->dma_handle + new_pan_offset);
+ base_addr_y = ch->dma_handle + new_pan_offset;
+ if (var->nonstd) {
+ /* Set y offset */
+ c_offset = (var->yoffset *
+ info->fix.line_length *
+ (info->var.bits_per_pixel - 8)) / 8;
+ base_addr_c = ch->dma_handle + var->xres * var->yres_virtual +
+ c_offset;
+ /* Set x offset */
+ if (info->var.bits_per_pixel = 24)
+ base_addr_c += 2 * var->xoffset;
+ else
+ base_addr_c += var->xoffset;
+ } else
+ base_addr_c = 0;
+
+ lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
+ if (base_addr_c)
+ lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
+
if (lcdc_chan_is_sublcd(ch))
lcdc_write(ch->lcdc, _LDRCNTR, ldrcntr ^ LDRCNTR_SRS);
else
@@ -885,7 +937,10 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
- info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
+ if (info->var.nonstd)
+ info->fix.line_length = mode1.xres;
+ else
+ info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
/*
* fb_set_var() calls the notifier change internally, only if
@@ -980,8 +1035,22 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_check_var = sh_mobile_check_var,
};
-static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp)
+static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp,
+ int nonstd)
{
+ if (nonstd) {
+ switch (bpp) {
+ case 12:
+ case 16:
+ case 24:
+ var->bits_per_pixel = bpp;
+ var->nonstd = nonstd;
+ return 0;
+ default:
+ return -EINVAL;
+ }
+ }
+
switch (bpp) {
case 16: /* PKF[4:0] = 00011 - RGB 565 */
var->red.offset = 11;
@@ -1260,6 +1329,14 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
k < cfg->num_cfg && lcd_cfg;
k++, lcd_cfg++) {
unsigned long size = lcd_cfg->yres * lcd_cfg->xres;
+ /* NV12 buffers must have even number of lines */
+ if ((cfg->nonstd) && cfg->bpp = 12 &&
+ (lcd_cfg->yres & 0x1)) {
+ dev_err(&pdev->dev, "yres must be multiple of 2"
+ " for YCbCr420 mode.\n");
+ error = -EINVAL;
+ goto err1;
+ }
if (size > max_size) {
max_cfg = lcd_cfg;
@@ -1274,7 +1351,11 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
max_cfg->xres, max_cfg->yres);
info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * (cfg->bpp / 8) * 2;
+ info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
+
+ /* Only pan in 2 line steps for NV12 */
+ if (cfg->nonstd && cfg->bpp = 12)
+ info->fix.ypanstep = 2;
if (!mode) {
mode = &default_720p;
@@ -1292,7 +1373,7 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
- error = sh_mobile_lcdc_set_bpp(var, cfg->bpp);
+ error = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
if (error)
break;
@@ -1316,7 +1397,11 @@ static int __devinit
sh_mobile_lcdc_probe(struct platform_device *pdev)
}
info->fix.smem_start = ch->dma_handle;
- info->fix.line_length = var->xres * (cfg->bpp / 8);
+ if (var->nonstd)
+ info->fix.line_length = var->xres;
+ else
+ info->fix.line_length = var->xres * (cfg->bpp / 8);
+
info->screen_base = buf;
info->device = &pdev->dev;
ch->display_var = *var;
diff --git a/drivers/video/sh_mobile_lcdcfb.h
b/drivers/video/sh_mobile_lcdcfb.h
index 9ecee2f..c953cb0 100644
--- a/drivers/video/sh_mobile_lcdcfb.h
+++ b/drivers/video/sh_mobile_lcdcfb.h
@@ -8,7 +8,7 @@
/* per-channel registers */
enum { LDDCKPAT1R, LDDCKPAT2R, LDMT1R, LDMT2R, LDMT3R, LDDFR, LDSM1R,
- LDSM2R, LDSA1R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
+ LDSM2R, LDSA1R, LDSA2R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR,
LDVSYNR, LDPMR,
LDHAJR,
NR_CH_REGS };
diff --git a/include/video/sh_mobile_lcdc.h
b/include/video/sh_mobile_lcdc.h
index daabae5..650ff17 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
struct sh_mobile_lcdc_board_cfg board_cfg;
struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
+ int nonstd;
};
struct sh_mobile_lcdc_info {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-03-02 6:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
On 2011/03/01 17:59, Magnus Damm wrote:
> On Thu, Feb 24, 2011 at 12:38 PM, Damian<dhobsong@igel.co.jp> wrote:
>> Ok, I see what you're saying. But if the SH_FB_YUV flag is disappearing, I
>> guess it makes sense to ditch the second patch in this series as well, since
>> that's just further abstraction (albeit locally).
>
> Yep, I think so. Thanks for your help!
Ok, then I will resubmit only the first patch of the series as
[PATCH v2] fbdev: sh_mobile_lcdc: Add YUV input support
Thanks,
Damian
>
> / magnus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* [PATCH] tmio: silence warnings introduced by mfd changes
From: Andres Salomon @ 2011-03-01 20:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Samuel Ortiz, linux-next, linux-kernel, linux-fbdev, linux-usb,
linux-mtd, linux-mmc, Ian Molton, Chris Ball, David Woodhouse,
David Brownell, Greg Kroah-Hartman
In-Reply-To: <20110301105322.48754094@debxo>
On Tue, 1 Mar 2011 10:53:22 -0800
Andres Salomon <dilinger@queued.net> wrote:
> On Tue, 1 Mar 2011 15:42:30 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Samuel,
> >
> > After merging the mfd tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
> > drivers/video/tmiofb.c:270: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_hw_mode': drivers/video/tmiofb.c:314: warning:
> > initialization discards qualifiers from pointer target type
> > drivers/video/tmiofb.c:314: warning: unused variable 'cell'
> > drivers/video/tmiofb.c: In function 'tmiofb_probe':
> > drivers/video/tmiofb.c:683: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_remove': drivers/video/tmiofb.c:811: warning:
> > initialization discards qualifiers from pointer target type
> > drivers/video/tmiofb.c: In function 'tmiofb_suspend':
> > drivers/video/tmiofb.c:941: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_resume': drivers/video/tmiofb.c:973: warning:
> > initialization discards qualifiers from pointer target type
> >
> > Introduced by commits 2a79bb1d72f5ac22dff96de340d90d512f852ecb
> > ("mfd: mfd_cell is now implicitly available to tc6393xb drivers")
> > and b6361637190e6cb7acb84509499942ada69e7136 ("fb: Use mfd_data
> > instead of driver_data for tmio-fb").
> >
>
> Oops, this should fix that.
>
>
>
Actually, I noticed that I screwed this up for the other tmio drivers
as well. Here's a patch that addresses them all (you can
ignore the previous patch).
From: Andres Salomon <dilinger@queued.net>
This silences warnings such as
drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
drivers/video/tmiofb.c:270: warning: initialization discards qualifiers from pointer target type
These were added by me in commit 2a79bb1d.
Signed-off-by: Andres Salomon <dilinger@queued.net>
moo
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/mmc/host/tmio_mmc.c | 8 ++++----
drivers/mtd/nand/tmio_nand.c | 8 ++++----
drivers/usb/host/ohci-tmio.c | 8 ++++----
drivers/video/tmiofb.c | 11 +++++------
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 4d34fbd..39918cc 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -1191,7 +1191,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {
#ifdef CONFIG_PM
static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
int ret;
@@ -1206,7 +1206,7 @@ static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
static int tmio_mmc_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
int ret = 0;
@@ -1229,7 +1229,7 @@ out:
static int __devinit tmio_mmc_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_mmc_data *pdata;
struct resource *res_ctl;
struct tmio_mmc_host *host;
@@ -1344,7 +1344,7 @@ out:
static int __devexit tmio_mmc_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
platform_set_drvdata(dev, NULL);
diff --git a/drivers/mtd/nand/tmio_nand.c b/drivers/mtd/nand/tmio_nand.c
index 2383b8f..38fb167 100644
--- a/drivers/mtd/nand/tmio_nand.c
+++ b/drivers/mtd/nand/tmio_nand.c
@@ -319,7 +319,7 @@ static int tmio_nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
static int tmio_hw_init(struct platform_device *dev, struct tmio_nand *tmio)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int ret;
if (cell->enable) {
@@ -363,7 +363,7 @@ static int tmio_hw_init(struct platform_device *dev, struct tmio_nand *tmio)
static void tmio_hw_stop(struct platform_device *dev, struct tmio_nand *tmio)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
tmio_iowrite8(FCR_MODE_POWER_OFF, tmio->fcr + FCR_MODE);
if (cell->disable)
@@ -515,7 +515,7 @@ static int tmio_remove(struct platform_device *dev)
#ifdef CONFIG_PM
static int tmio_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
if (cell->suspend)
cell->suspend(dev);
@@ -526,7 +526,7 @@ static int tmio_suspend(struct platform_device *dev, pm_message_t state)
static int tmio_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
/* FIXME - is this required or merely another attack of the broken
* SHARP platform? Looks suspicious.
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index eeed164..3558491 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -185,7 +185,7 @@ static struct platform_driver ohci_hcd_tmio_driver;
static int __devinit ohci_hcd_tmio_drv_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct resource *regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
struct resource *config = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *sram = platform_get_resource(dev, IORESOURCE_MEM, 2);
@@ -274,7 +274,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
usb_remove_hcd(hcd);
tmio_stop_hc(dev);
@@ -293,7 +293,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
#ifdef CONFIG_PM
static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
@@ -326,7 +326,7 @@ static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t s
static int ohci_hcd_tmio_drv_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index 7e57d3b..9710bf8 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -267,7 +267,7 @@ static int tmiofb_hw_stop(struct platform_device *dev)
*/
static int tmiofb_hw_init(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
const struct resource *nlcr = &cell->resources[0];
@@ -311,7 +311,6 @@ static int tmiofb_hw_init(struct platform_device *dev)
*/
static void tmiofb_hw_mode(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct fb_videomode *mode = info->mode;
@@ -680,7 +679,7 @@ static struct fb_ops tmiofb_ops = {
static int __devinit tmiofb_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -808,7 +807,7 @@ err_ioremap_ccr:
static int __devexit tmiofb_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
struct tmiofb_par *par;
@@ -938,7 +937,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
#ifdef CONFIG_FB_TMIO_ACCELL
struct tmiofb_par *par = info->par;
#endif
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
@@ -970,7 +969,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
static int tmiofb_resume(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Geert Uytterhoeven @ 2011-03-01 20:22 UTC (permalink / raw)
To: Magnus Damm
Cc: Damian, Guennadi Liakhovetski, linux-sh, linux-fbdev, taki, matsu,
dri-devel
In-Reply-To: <AANLkTikpL3m_8YVMiRRRULmB_Px9asdK-Fto07WeyJgG@mail.gmail.com>
On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> Please ditch the SH_FB_YUV constant all together. No need to build
>>> some abstraction on top of a hackish interface. Just check if nonstd
>>> is non-zero in the driver and assume that means YUV for now. That's
>>> good enough.
>>
>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new FB_VISUAL_*
>> type instead, which indicates the fb_var_screeninfo.{red,green,blue} fields are
>> YCbCr instead of RGB.
>> Depending on the frame buffer organization, you also need new FB_TYPE_*/FB_AUX_*
>> types.
>
> I'm all for extending the common code instead of hiding code in
> drivers. But I wonder how much overlap there is with V4L2 for
> instance. I remember adding support for some NVxx formats for V4L2
> some years ago. It's mainly used for Video input on Renesas SoCs
> though:
>
> http://kerneltrap.org/mailarchive/git-commits-head/2008/12/31/4560474
>
> So I was hoping that something like the above could be added to fbdev
> too, but it looks like more code is needed.
>
> Do you have any idea on how to tie in the valid range of each color
> channel? The LCDC hardware block can select between 0->255 range or
> 16->235/240 for the YUV channels. In V4L2 this is handled by
> v4l2_colorspace, the 0->255 maps directly to V4L2_COLORSPACE_JPEG.
Unfortunately not. Unlike for the YCbCr visual, I don't see a field we
can easily
(ab)use for that. Except if it's limited to standard 16-235/240 Y vs.
full 0-255 Y,
for which we could just have 2 different visual types.
> And how does all this relate to KMS? I'd prefer to keep this code in
> one place if possible.
Good question!
I'm still puzzled about this KMS thing. If the name "Kernel Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Furthermore, everybody states that "future X/desktop" will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
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 5/5] s3fb: use new start address register
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Use "new" start address register 0x69 (bits 16-20) instead of "old" 0x31
(bits 16-17) and 0x51 (bits 18-19). This is needed for panning to work
correctly on Trio3D/2X cards (and does no harm on other ones).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-03-01 18:38:58.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-03-01 18:39:35.000000000 +0100
@@ -123,7 +123,7 @@ static const struct vga_regset s3_v_sync
static const struct vga_regset s3_v_sync_end_regs[] = {{0x11, 0, 3}, VGA_REGSET_END};
static const struct vga_regset s3_line_compare_regs[] = {{0x18, 0, 7}, {0x07, 4, 4}, {0x09, 6, 6}, {0x5E, 6, 6}, VGA_REGSET_END};
-static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
+static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x69, 0, 4}, VGA_REGSET_END};
static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7}, {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
static const struct vga_regset s3_dtpc_regs[] = {{0x3B, 0, 7}, {0x5D, 6, 6}, VGA_REGSET_END};
--
Ondrej Zary
^ permalink raw reply
* [PATCH 4/5]: s3fb: enable DTPC
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Enable Data Transfer Position Control (DTPC). This is needed at least on
Virge/DX to correctly display at higher pixclocks.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-28 17:28:27.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-28 18:53:00.000000000 +0100
@@ -126,6 +126,8 @@
static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7}, {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
+static const struct vga_regset s3_dtpc_regs[] = {{0x3B, 0, 7}, {0x5D, 6, 6}, VGA_REGSET_END};
+
static const struct svga_timing_regs s3_timing_regs = {
s3_h_total_regs, s3_h_display_regs, s3_h_blank_start_regs,
s3_h_blank_end_regs, s3_h_sync_start_regs, s3_h_sync_end_regs,
@@ -485,6 +487,7 @@
struct s3fb_info *par = info->par;
u32 value, mode, hmul, offset_value, screen_size, multiplex, dbytes;
u32 bpp = info->var.bits_per_pixel;
+ u32 htotal, hsstart;
if (bpp != 0) {
info->fix.ypanstep = 1;
@@ -604,7 +607,9 @@
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
par->chip = CHIP_368_TRIO3D_2X ||
- par->chip = CHIP_365_TRIO3D) {
+ par->chip = CHIP_365_TRIO3D ||
+ par->chip = CHIP_375_VIRGE_DX ||
+ par->chip = CHIP_385_VIRGE_GX) {
dbytes = info->var.xres * ((bpp+7)/8);
vga_wcrt(par->state.vgabase, 0x91, (dbytes + 7) / 8);
vga_wcrt(par->state.vgabase, 0x90, (((dbytes + 7) / 8) >> 8) | 0x80);
@@ -612,6 +617,16 @@
vga_wcrt(par->state.vgabase, 0x66, 0x81);
}
+ if (par->chip = CHIP_356_VIRGE_GX2 ||
+ par->chip = CHIP_357_VIRGE_GX2P ||
+ par->chip = CHIP_359_VIRGE_GX2P ||
+ par->chip = CHIP_360_TRIO3D_1X ||
+ par->chip = CHIP_362_TRIO3D_2X ||
+ par->chip = CHIP_368_TRIO3D_2X)
+ vga_wcrt(par->state.vgabase, 0x34, 0x00);
+ else /* enable Data Transfer Position Control (DTPC) */
+ vga_wcrt(par->state.vgabase, 0x34, 0x10);
+
svga_wcrt_mask(par->state.vgabase, 0x31, 0x00, 0x40);
multiplex = 0;
hmul = 1;
@@ -745,9 +760,14 @@
hmul, info->node);
/* Set interlaced mode start/end register */
- value = info->var.xres + info->var.left_margin + info->var.right_margin + info->var.hsync_len;
- value = ((value * hmul) / 8) - 5;
- vga_wcrt(par->state.vgabase, 0x3C, (value + 1) / 2);
+ htotal = info->var.xres + info->var.left_margin + info->var.right_margin + info->var.hsync_len;
+ htotal = ((htotal * hmul) / 8) - 5;
+ vga_wcrt(par->state.vgabase, 0x3C, (htotal + 1) / 2);
+
+ /* Set Data Transfer Position */
+ hsstart = ((info->var.xres + info->var.right_margin) * hmul) / 8;
+ value = clamp((htotal + hsstart + 1) / 2, hsstart + 4, htotal + 1);
+ svga_wcrt_multi(par->state.vgabase, s3_dtpc_regs, value);
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
--
Ondrej Zary
^ permalink raw reply
* [PATCH 3/5] s3fb: fix 15/16bpp modes with over 115MHz pixclocks on 86C365 Trio3D
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Enable pixel multiplexing in 15/16bpp modes when pixclock is over 115MHz
on Trio3D (86C365) cards to fix artifacts on the left side of screen.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:48:41.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-22 23:31:16.000000000 +0100
@@ -675,6 +675,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
@@ -691,6 +700,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
--
Ondrej Zary
^ permalink raw reply
* [PATCH 2/5] s3fb: add support for 86C365 Trio3D
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Add support for S3 Trio3D (86C365) cards to s3fb driver. Tested with one 4MB card.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:11:18.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 20:31:34.000000000 +0100
@@ -64,6 +64,8 @@ static const struct svga_fb_format s3fb_
static const struct svga_pll s3_pll = {3, 129, 3, 33, 0, 3,
35000, 240000, 14318};
+static const struct svga_pll s3_trio3d_pll = {3, 129, 3, 31, 0, 4,
+ 230000, 460000, 14318};
static const int s3_memsizes[] = {4096, 0, 3072, 8192, 2048, 6144, 1024, 512};
@@ -72,7 +74,8 @@ static const char * const s3_names[] = {
"S3 Plato/PX", "S3 Aurora64VP", "S3 Virge",
"S3 Virge/VX", "S3 Virge/DX", "S3 Virge/GX",
"S3 Virge/GX2", "S3 Virge/GX2P", "S3 Virge/GX2P",
- "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X"};
+ "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X",
+ "S3 Trio3D"};
#define CHIP_UNKNOWN 0x00
#define CHIP_732_TRIO32 0x01
@@ -93,6 +96,7 @@ static const char * const s3_names[] = {
#define CHIP_360_TRIO3D_1X 0x10
#define CHIP_362_TRIO3D_2X 0x11
#define CHIP_368_TRIO3D_2X 0x12
+#define CHIP_365_TRIO3D 0x13
#define CHIP_XXX_TRIO 0x80
#define CHIP_XXX_TRIO64V2_DXGX 0x81
@@ -341,7 +345,8 @@ static void s3_set_pixclock(struct fb_in
u8 regval;
int rv;
- rv = svga_compute_pll(&s3_pll, 1000000000 / pixclock, &m, &n, &r, info->node);
+ rv = svga_compute_pll((par->chip = CHIP_365_TRIO3D) ? &s3_trio3d_pll : &s3_pll,
+ 1000000000 / pixclock, &m, &n, &r, info->node);
if (rv < 0) {
printk(KERN_ERR "fb%d: cannot set requested pixclock, keeping old value\n", info->node);
return;
@@ -598,7 +603,8 @@ static int s3fb_set_par(struct fb_info *
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
dbytes = info->var.xres * ((bpp+7)/8);
vga_wcrt(par->state.vgabase, 0x91, (dbytes + 7) / 8);
vga_wcrt(par->state.vgabase, 0x90, (((dbytes + 7) / 8) >> 8) | 0x80);
@@ -1012,13 +1018,15 @@ static int __devinit s3_pci_probe(struct
regval = vga_rcrt(par->state.vgabase, 0x36);
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
switch ((regval & 0xE0) >> 5) {
case 0: /* 8MB -- only 4MB usable for display */
case 1: /* 4MB with 32-bit bus */
case 2: /* 4MB */
info->screen_size = 4 << 20;
break;
+ case 4: /* 2MB on 365 Trio3D */
case 6: /* 2MB */
info->screen_size = 2 << 20;
break;
@@ -1233,6 +1241,7 @@ static struct pci_device_id s3_devices[]
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A11), .driver_data = CHIP_357_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A12), .driver_data = CHIP_359_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A13), .driver_data = CHIP_36X_TRIO3D_1X_2X},
+ {PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8904), .driver_data = CHIP_365_TRIO3D},
{0, 0, 0, 0, 0, 0, 0}
};
--
Ondrej Zary
^ permalink raw reply
* [PATCH 1/5] s3fb: maximize virtual vertical size for fast scrolling
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Maximize virtual vertical framebuffer size during init to allow fast scrolling
(accelerated by panning).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 19:11:28.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 19:17:04.000000000 +0100
@@ -1060,6 +1060,14 @@ static int __devinit s3_pci_probe(struct
goto err_find_mode;
}
+ /* maximize virtual vertical size for fast scrolling */
+ info->var.yres_virtual = info->fix.smem_len * 8 /
+ (info->var.bits_per_pixel * info->var.xres_virtual);
+ if (info->var.yres_virtual < info->var.yres) {
+ dev_err(info->device, "virtual vertical size smaller than real\n");
+ goto err_find_mode;
+ }
+
rc = fb_alloc_cmap(&info->cmap, 256, 0);
if (rc < 0) {
dev_err(info->device, "cannot allocate colormap\n");
--
Ondrej Zary
^ permalink raw reply
* [PATCH 0/5] s3fb: various changes
From: Ondrej Zary @ 2011-03-01 19:17 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
This patch set adds new hardware support, fixes some display problems and also
improves performance of s3fb driver.
Everything was tested on various Trio32, Trio64V+, Trio64V2/DX, Virge,
Virge/DX, Trio3D and Trio3D/2X cards.
It assumes that David Miller's "Make SVGA oriented FBs work on multi-domain
PCI" patch set is applied.
Signed-off-by: David S. Miller <davem@davemloft.net>
--
Ondrej Zary
^ 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