* [PATCH] video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
From: Mark Brown @ 2012-04-15 10:39 UTC (permalink / raw)
To: linux-fbdev
Since s3c_fb_missing_pixclock() is called from s3c_fb_set_rgb_timing()
which is used in the suspend/resume paths it can't be marked __devinit
as this could result in it being discarded after boot.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 18c84b8..d8f0018 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1056,7 +1056,7 @@ static struct fb_ops s3c_fb_ops = {
*
* Calculate the pixel clock when none has been given through platform data.
*/
-static void __devinit s3c_fb_missing_pixclock(struct fb_videomode *mode)
+static void s3c_fb_missing_pixclock(struct fb_videomode *mode)
{
u64 pixclk = 1000000000000ULL;
u32 div;
--
1.7.9.1
^ permalink raw reply related
* [PATCH] video/via: Convert to kstrtou8_from_user
From: Peter Huewe @ 2012-04-14 23:24 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linux-kernel, kernel-janitors, Peter Huewe
This patch replaces the code for getting an number from a
userspace buffer by a simple call to kstrou8_from_user.
This makes it easier to read and less error prone.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
drivers/video/via/viafbdev.c | 26 ++++++++++----------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 0c88375..5b0d524 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1276,17 +1276,14 @@ static int viafb_dfph_proc_open(struct inode *inode, struct file *file)
static ssize_t viafb_dfph_proc_write(struct file *file,
const char __user *buffer, size_t count, loff_t *pos)
{
- char buf[20];
+ int err;
u8 reg_val = 0;
- unsigned long length;
if (count < 1)
return -EINVAL;
- length = count > 20 ? 20 : count;
- if (copy_from_user(&buf[0], buffer, length))
- return -EFAULT;
- buf[length - 1] = '\0'; /*Ensure end string */
- if (kstrtou8(buf, 0, ®_val) < 0)
- return -EINVAL;
+ err = kstrtou8_from_user(buffer, count, 0, ®_val);
+ if (err)
+ return err;
+
viafb_write_reg_mask(CR97, VIACR, reg_val, 0x0f);
return count;
}
@@ -1316,17 +1313,14 @@ static int viafb_dfpl_proc_open(struct inode *inode, struct file *file)
static ssize_t viafb_dfpl_proc_write(struct file *file,
const char __user *buffer, size_t count, loff_t *pos)
{
- char buf[20];
+ int err;
u8 reg_val = 0;
- unsigned long length;
if (count < 1)
return -EINVAL;
- length = count > 20 ? 20 : count;
- if (copy_from_user(&buf[0], buffer, length))
- return -EFAULT;
- buf[length - 1] = '\0'; /*Ensure end string */
- if (kstrtou8(buf, 0, ®_val) < 0)
- return -EINVAL;
+ err = kstrtou8_from_user(buffer, count, 0, ®_val);
+ if (err)
+ return err;
+
viafb_write_reg_mask(CR99, VIACR, reg_val, 0x0f);
return count;
}
--
1.7.3.4
^ permalink raw reply related
* [GIT PULL] fbdev fixes for 3.4
From: Florian Tobias Schandinat @ 2012-04-13 17:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org
Hi Linus,
please pull the fixes below. The fix for kyrofb is a bit large but it's just
replacing "unsigned long" by "u32" for 64 bit compatibility.
Thanks,
Florian Tobias Schandinat
The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e:
Linux 3.4-rc2 (2012-04-07 18:30:41 -0700)
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git fbdev-fixes-for-3.4-1
for you to fetch changes up to b78f29ca0516266431688c5eb42d39ce42ec039a:
video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
(2012-04-09 16:05:57 +0000)
----------------------------------------------------------------
fbdev fixes for 3.4
It includes:
- a compile fix for au1*fb
- a fix to make kyrofb usable on x86_64
- a fix for uvesafb to prevent an oops due to NX-protection
----------------------------------------------------------------
Manuel Lauss (1):
fbdev: fix au1*fb builds
Ondrej Zary (1):
kyrofb: fix on x86_64
Wang YanQing (1):
video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
drivers/video/au1100fb.c | 5 +-
drivers/video/au1200fb.c | 2 +-
drivers/video/kyro/STG4000Reg.h | 376 +++++++++++++++++++-------------------
drivers/video/uvesafb.c | 11 +-
4 files changed, 201 insertions(+), 193 deletions(-)
^ permalink raw reply
* [PATCH 1/2] video: msm: Fix section mismatches in mddi.c
From: David Brown @ 2012-04-12 18:45 UTC (permalink / raw)
To: linux-arm-kernel
The change
commit 461cbe77d0a4f887c33a3a95ea68a7daf23b4302
Author: Gregory Bean <gbean@codeaurora.org>
Date: Wed Jul 28 10:22:13 2010 -0700
video: msm: Fix section mismatch in mddi.c.
fixes a section mismatch between the board file and the driver's probe
function, however, it misses the additional mismatches between the
probe function and some routines it calls. Fix these up as well.
Signed-off-by: David Brown <davidb@codeaurora.org>
---
drivers/video/msm/mddi.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
index 4527cbf..b061d70 100644
--- a/drivers/video/msm/mddi.c
+++ b/drivers/video/msm/mddi.c
@@ -420,7 +420,7 @@ static void mddi_resume(struct msm_mddi_client_data *cdata)
mddi_set_auto_hibernate(&mddi->client_data, 1);
}
-static int __init mddi_get_client_caps(struct mddi_info *mddi)
+static int __devinit mddi_get_client_caps(struct mddi_info *mddi)
{
int i, j;
@@ -622,9 +622,9 @@ uint32_t mddi_remote_read(struct msm_mddi_client_data *cdata, uint32_t reg)
static struct mddi_info mddi_info[2];
-static int __init mddi_clk_setup(struct platform_device *pdev,
- struct mddi_info *mddi,
- unsigned long clk_rate)
+static int __devinit mddi_clk_setup(struct platform_device *pdev,
+ struct mddi_info *mddi,
+ unsigned long clk_rate)
{
int ret;
--
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
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Florian Tobias Schandinat @ 2012-04-12 2:22 UTC (permalink / raw)
To: Wang YanQing, linux-fbdev, linux-kernel, spock, alan
In-Reply-To: <20120401005402.GA4375@udknight>
On 04/01/2012 12:54 AM, Wang YanQing wrote:
> This patch fix the oops below that catched in my machine
>
> [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
> [ 81.609384] uvesafb: protected mode interface info at c000:d350
> [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
> [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
> [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
> [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
> [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtualI15
> [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
> [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
> [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
> [ 81.744171] Oops: 0011 [#1] SMP
> [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
> [ 81.744178]
> [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
> [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
> [ 81.744187] EIP is at 0xc00cd3b3
> [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
> [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
> [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 81.744195] Process modprobe (pid: 3497, tiõ7f2000 task÷48c600 task.tiõ7f2000)
> [ 81.744196] Stack:
> [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
> [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
> [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
> [ 81.744210] Call Trace:
> [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
> [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
> [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
> [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
> [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
> [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
> [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
> [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
> [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
> [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
> [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
> [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
> [ 81.744258] [<c129b378>] visual_init+0xb8/0x150
> [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
> [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
> [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
> [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
> [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
> [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
> [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
> [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
> [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
> [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
> [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
> [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
> [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
> [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
> [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
> [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
> [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
> [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
> [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
> [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
> [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
> [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
> [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
> [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
> [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
> [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
> [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
> [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
> [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
> [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
> [ 81.744391] CR2: 00000000c00cd3b3
> [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index 260cca7..26e83d7 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -815,8 +815,15 @@ static int __devinit uvesafb_vbe_init(struct fb_info *info)
> par->pmi_setpal = pmi_setpal;
> par->ypan = ypan;
>
> - if (par->pmi_setpal || par->ypan)
> - uvesafb_vbe_getpmi(task, par);
> + if (par->pmi_setpal || par->ypan) {
> + if (__supported_pte_mask & _PAGE_NX) {
> + par->pmi_setpal = par->ypan = 0;
> + printk(KERN_WARNING "uvesafb: NX protection is actively."
> + "We have better not to use the PMI.\n");
> + } else {
> + uvesafb_vbe_getpmi(task, par);
> + }
> + }
> #else
> /* The protected mode interface is not available on non-x86. */
> par->pmi_setpal = par->ypan = 0;
^ permalink raw reply
* Re: [PATCH] video: pxa3xx-gcu: Simplify the logic to exit while loop in pxa3xx_gcu_wait_idle
From: Florian Tobias Schandinat @ 2012-04-12 2:22 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Daniel Mack, Sven Neumann, Janine Kropp,
Denis Oliver Kropp, linux-fbdev
In-Reply-To: <1332818156.21855.4.camel@phoenix>
On 03/27/2012 03:15 AM, Axel Lin wrote:
> If wait_event_interruptible_timeout returns a positive value, it means
> the condition evaluated is true. Which means priv->shared->hw_running is false.
> And then we will exit the loop.
>
> This patch simplifies the logic to exit the while loop.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/pxa3xx-gcu.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
> index 1d71c08..0b4ae0c 100644
> --- a/drivers/video/pxa3xx-gcu.c
> +++ b/drivers/video/pxa3xx-gcu.c
> @@ -316,12 +316,9 @@ pxa3xx_gcu_wait_idle(struct pxa3xx_gcu_priv *priv)
> ret = wait_event_interruptible_timeout(priv->wait_idle,
> !priv->shared->hw_running, HZ*4);
>
> - if (ret < 0)
> + if (ret != 0)
> break;
>
> - if (ret > 0)
> - continue;
> -
> if (gc_readl(priv, REG_GCRBEXHR) = rbexhr &&
> priv->shared->num_interrupts = num) {
> QERROR("TIMEOUT");
^ permalink raw reply
* Re: [PATCH v3 0/4] video: s3c-fb: Rearrange the elements in platform data
From: Florian Tobias Schandinat @ 2012-04-12 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1332606528-32338-1-git-send-email-thomas.abraham@linaro.org>
On 03/24/2012 04:28 PM, Thomas Abraham wrote:
> Changes since v2:
> - Patch 3/4 is a new patch in this series. The real6410 and mini6410 boards
> use the display controllers window configuration data to represent video
> timing of two different lcd panels. Since the window configuration data
> should be not be used to specify timing of two different panels, this has
> been reworked in such a way that two instance of display controller's
> platform data is setup for the two supported lcd panels. Depending on the
> lcd panel specified using boot parameters, the corresponding platform data
> is registered. This maintains backward compatibility with existing
> functionality of supporting multiple lcd panels at runtime.
>
> Changes since v1:
> - Includes all changes suggested by Jingoo Han.
> - Reworked s3c-fb platform data in all Samsung SoC based board files.
>
> This patchset rearranges the elements in the platform data of the s3c-fb
> driver with the intent of adding device tree support to the driver in
> subsequent patches.
>
> The first patch moves the video timing information from the individual window
> setup data into the platform specific configuration section in the platform
> data. The video timing is independent of the window setup. The resolution of
> the window could be smaller than that of the lcd panel attached. So the video
> timing data is removed from window configuration data.
>
> The second patch removes the need for the 'default_win' element in the
> platform data. This element was used to decide whether the video data
> output from the controller should be enabled or disabled when the window
> specified by 'default_win' is enabled or disabled. With the first patch
> removing the need for atleast one window to be of the same resolution as
> that of the lcd panel, it is now possible to decide when to enable/disable
> the video data output based on the state of each window. If any of the
> window is active, the lcd data output is enabled. Otherwise, the lcd data
> output is disabled. Hence, the 'default_win' parameter from the platform
> data can be removed, which anyways cannot be specified when using
> device tree.
>
> The third patch reworks the display controller's platform data that was
> used to supply video timing information for two different panels on the
> mini6410 and real6410 boards. That was not the correct usage of the window
> data and hence reworks the runtime handling of two different lcd panels.
>
> For all the Samsung SoC based boards, the forth patch reworks the platform
> data of the display controller based on the changes introduced in the first
> two patches.
>
> This patch series is based on
> http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git [for-next]
>
> with all patches merged from
> https://github.com/schandinat/linux-2.6.git [fbdev-next]
>
> and tested one Exynos4210 based Origen board (only compile tested for
> other boards)
>
> Thomas Abraham (4):
> video: s3c-fb: move video interface timing out of window setup data
> video: s3c-fb: remove 'default_win' element from platform data
> ARM: s3c64xx: Decouple lcd type from display controller window data
> ARM: Samsung: Rework platform data of s3c-fb driver
Applied this series.
Thanks,
Florian Tobias Schandinat
>
> arch/arm/mach-exynos/mach-nuri.c | 26 +++---
> arch/arm/mach-exynos/mach-origen.c | 24 +++--
> arch/arm/mach-exynos/mach-smdkv310.c | 28 ++++---
> arch/arm/mach-exynos/mach-universal_c210.c | 26 +++---
> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 +++---
> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 +++---
> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 +++---
> arch/arm/mach-s3c64xx/mach-hmt.c | 24 +++--
> arch/arm/mach-s3c64xx/mach-mini6410.c | 92 +++++++++++--------
> arch/arm/mach-s3c64xx/mach-real6410.c | 90 +++++++++++--------
> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 +++---
> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 +++---
> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 +++---
> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 +++--
> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 +++--
> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 +++---
> arch/arm/mach-s5pv210/mach-aquila.c | 36 ++++----
> arch/arm/mach-s5pv210/mach-goni.c | 26 +++---
> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 +++--
> arch/arm/plat-samsung/include/plat/fb.h | 11 ++-
> drivers/video/s3c-fb.c | 135 +++++++++++++--------------
> 21 files changed, 426 insertions(+), 345 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH] fbdev: fix au1*fb builds
From: Florian Tobias Schandinat @ 2012-04-12 2:18 UTC (permalink / raw)
To: linux-fbdev
On 03/24/2012 10:38 AM, Manuel Lauss wrote:
> Commit 1c16697bf9d5b206cb0d2b905a54de5e077296be
> ("drivers/video/au*fb.c: use devm_ functions) introduced 2 build failures
> in the au1100fb and au1200fb drivers, fix them.
>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/au1100fb.c | 5 +++--
> drivers/video/au1200fb.c | 2 +-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
> index befcbd8..ffbce45 100644
> --- a/drivers/video/au1100fb.c
> +++ b/drivers/video/au1100fb.c
> @@ -499,7 +499,8 @@ static int __devinit au1100fb_drv_probe(struct platform_device *dev)
> au1100fb_fix.mmio_start = regs_res->start;
> au1100fb_fix.mmio_len = resource_size(regs_res);
>
> - if (!devm_request_mem_region(au1100fb_fix.mmio_start,
> + if (!devm_request_mem_region(&dev->dev,
> + au1100fb_fix.mmio_start,
> au1100fb_fix.mmio_len,
> DRIVER_NAME)) {
> print_err("fail to lock memory region at 0x%08lx",
> @@ -516,7 +517,7 @@ static int __devinit au1100fb_drv_probe(struct platform_device *dev)
> fbdev->fb_len = fbdev->panel->xres * fbdev->panel->yres *
> (fbdev->panel->bpp >> 3) * AU1100FB_NBR_VIDEO_BUFFERS;
>
> - fbdev->fb_mem = dmam_alloc_coherent(&dev->dev, &dev->dev,
> + fbdev->fb_mem = dmam_alloc_coherent(&dev->dev,
> PAGE_ALIGN(fbdev->fb_len),
> &fbdev->fb_phys, GFP_KERNEL);
> if (!fbdev->fb_mem) {
> diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c
> index 3e9a773..7ca79f0 100644
> --- a/drivers/video/au1200fb.c
> +++ b/drivers/video/au1200fb.c
> @@ -1724,7 +1724,7 @@ static int __devinit au1200fb_drv_probe(struct platform_device *dev)
> /* Allocate the framebuffer to the maximum screen size */
> fbdev->fb_len = (win->w[plane].xres * win->w[plane].yres * bpp) / 8;
>
> - fbdev->fb_mem = dmam_alloc_noncoherent(&dev->dev, &dev->dev,
> + fbdev->fb_mem = dmam_alloc_noncoherent(&dev->dev,
> PAGE_ALIGN(fbdev->fb_len),
> &fbdev->fb_phys, GFP_KERNEL);
> if (!fbdev->fb_mem) {
^ permalink raw reply
* Re: [PATCH] kyrofb: fix on x86_64
From: Florian Tobias Schandinat @ 2012-04-12 2:18 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Paul Mundt, linux-fbdev, Kernel development list
In-Reply-To: <201203212336.55396.linux@rainbow-software.org>
On 03/21/2012 10:36 PM, Ondrej Zary wrote:
> kyrofb is completely broken on x86_64 because the registers are defined as
> unsigned long. Change them to u32 to make the driver work.
> Tested with Hercules 3D Prophet 4000XT.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Applied.
Thanks,
Florian Tobias Schandinat
>
> diff --git a/drivers/video/kyro/STG4000Reg.h b/drivers/video/kyro/STG4000Reg.h
> index 5d62698..50f4670 100644
> --- a/drivers/video/kyro/STG4000Reg.h
> +++ b/drivers/video/kyro/STG4000Reg.h
> @@ -73,210 +73,210 @@ typedef enum _OVRL_PIX_FORMAT {
> /* Register Table */
> typedef struct {
> /* 0h */
> - volatile unsigned long Thread0Enable; /* 0x0000 */
> - volatile unsigned long Thread1Enable; /* 0x0004 */
> - volatile unsigned long Thread0Recover; /* 0x0008 */
> - volatile unsigned long Thread1Recover; /* 0x000C */
> - volatile unsigned long Thread0Step; /* 0x0010 */
> - volatile unsigned long Thread1Step; /* 0x0014 */
> - volatile unsigned long VideoInStatus; /* 0x0018 */
> - volatile unsigned long Core2InSignStart; /* 0x001C */
> - volatile unsigned long Core1ResetVector; /* 0x0020 */
> - volatile unsigned long Core1ROMOffset; /* 0x0024 */
> - volatile unsigned long Core1ArbiterPriority; /* 0x0028 */
> - volatile unsigned long VideoInControl; /* 0x002C */
> - volatile unsigned long VideoInReg0CtrlA; /* 0x0030 */
> - volatile unsigned long VideoInReg0CtrlB; /* 0x0034 */
> - volatile unsigned long VideoInReg1CtrlA; /* 0x0038 */
> - volatile unsigned long VideoInReg1CtrlB; /* 0x003C */
> - volatile unsigned long Thread0Kicker; /* 0x0040 */
> - volatile unsigned long Core2InputSign; /* 0x0044 */
> - volatile unsigned long Thread0ProgCtr; /* 0x0048 */
> - volatile unsigned long Thread1ProgCtr; /* 0x004C */
> - volatile unsigned long Thread1Kicker; /* 0x0050 */
> - volatile unsigned long GPRegister1; /* 0x0054 */
> - volatile unsigned long GPRegister2; /* 0x0058 */
> - volatile unsigned long GPRegister3; /* 0x005C */
> - volatile unsigned long GPRegister4; /* 0x0060 */
> - volatile unsigned long SerialIntA; /* 0x0064 */
> -
> - volatile unsigned long Fill0[6]; /* GAP 0x0068 - 0x007C */
> -
> - volatile unsigned long SoftwareReset; /* 0x0080 */
> - volatile unsigned long SerialIntB; /* 0x0084 */
> -
> - volatile unsigned long Fill1[37]; /* GAP 0x0088 - 0x011C */
> -
> - volatile unsigned long ROMELQV; /* 0x011C */
> - volatile unsigned long WLWH; /* 0x0120 */
> - volatile unsigned long ROMELWL; /* 0x0124 */
> -
> - volatile unsigned long dwFill_1; /* GAP 0x0128 */
> -
> - volatile unsigned long IntStatus; /* 0x012C */
> - volatile unsigned long IntMask; /* 0x0130 */
> - volatile unsigned long IntClear; /* 0x0134 */
> -
> - volatile unsigned long Fill2[6]; /* GAP 0x0138 - 0x014C */
> -
> - volatile unsigned long ROMGPIOA; /* 0x0150 */
> - volatile unsigned long ROMGPIOB; /* 0x0154 */
> - volatile unsigned long ROMGPIOC; /* 0x0158 */
> - volatile unsigned long ROMGPIOD; /* 0x015C */
> -
> - volatile unsigned long Fill3[2]; /* GAP 0x0160 - 0x0168 */
> -
> - volatile unsigned long AGPIntID; /* 0x0168 */
> - volatile unsigned long AGPIntClassCode; /* 0x016C */
> - volatile unsigned long AGPIntBIST; /* 0x0170 */
> - volatile unsigned long AGPIntSSID; /* 0x0174 */
> - volatile unsigned long AGPIntPMCSR; /* 0x0178 */
> - volatile unsigned long VGAFrameBufBase; /* 0x017C */
> - volatile unsigned long VGANotify; /* 0x0180 */
> - volatile unsigned long DACPLLMode; /* 0x0184 */
> - volatile unsigned long Core1VideoClockDiv; /* 0x0188 */
> - volatile unsigned long AGPIntStat; /* 0x018C */
> + volatile u32 Thread0Enable; /* 0x0000 */
> + volatile u32 Thread1Enable; /* 0x0004 */
> + volatile u32 Thread0Recover; /* 0x0008 */
> + volatile u32 Thread1Recover; /* 0x000C */
> + volatile u32 Thread0Step; /* 0x0010 */
> + volatile u32 Thread1Step; /* 0x0014 */
> + volatile u32 VideoInStatus; /* 0x0018 */
> + volatile u32 Core2InSignStart; /* 0x001C */
> + volatile u32 Core1ResetVector; /* 0x0020 */
> + volatile u32 Core1ROMOffset; /* 0x0024 */
> + volatile u32 Core1ArbiterPriority; /* 0x0028 */
> + volatile u32 VideoInControl; /* 0x002C */
> + volatile u32 VideoInReg0CtrlA; /* 0x0030 */
> + volatile u32 VideoInReg0CtrlB; /* 0x0034 */
> + volatile u32 VideoInReg1CtrlA; /* 0x0038 */
> + volatile u32 VideoInReg1CtrlB; /* 0x003C */
> + volatile u32 Thread0Kicker; /* 0x0040 */
> + volatile u32 Core2InputSign; /* 0x0044 */
> + volatile u32 Thread0ProgCtr; /* 0x0048 */
> + volatile u32 Thread1ProgCtr; /* 0x004C */
> + volatile u32 Thread1Kicker; /* 0x0050 */
> + volatile u32 GPRegister1; /* 0x0054 */
> + volatile u32 GPRegister2; /* 0x0058 */
> + volatile u32 GPRegister3; /* 0x005C */
> + volatile u32 GPRegister4; /* 0x0060 */
> + volatile u32 SerialIntA; /* 0x0064 */
> +
> + volatile u32 Fill0[6]; /* GAP 0x0068 - 0x007C */
> +
> + volatile u32 SoftwareReset; /* 0x0080 */
> + volatile u32 SerialIntB; /* 0x0084 */
> +
> + volatile u32 Fill1[37]; /* GAP 0x0088 - 0x011C */
> +
> + volatile u32 ROMELQV; /* 0x011C */
> + volatile u32 WLWH; /* 0x0120 */
> + volatile u32 ROMELWL; /* 0x0124 */
> +
> + volatile u32 dwFill_1; /* GAP 0x0128 */
> +
> + volatile u32 IntStatus; /* 0x012C */
> + volatile u32 IntMask; /* 0x0130 */
> + volatile u32 IntClear; /* 0x0134 */
> +
> + volatile u32 Fill2[6]; /* GAP 0x0138 - 0x014C */
> +
> + volatile u32 ROMGPIOA; /* 0x0150 */
> + volatile u32 ROMGPIOB; /* 0x0154 */
> + volatile u32 ROMGPIOC; /* 0x0158 */
> + volatile u32 ROMGPIOD; /* 0x015C */
> +
> + volatile u32 Fill3[2]; /* GAP 0x0160 - 0x0168 */
> +
> + volatile u32 AGPIntID; /* 0x0168 */
> + volatile u32 AGPIntClassCode; /* 0x016C */
> + volatile u32 AGPIntBIST; /* 0x0170 */
> + volatile u32 AGPIntSSID; /* 0x0174 */
> + volatile u32 AGPIntPMCSR; /* 0x0178 */
> + volatile u32 VGAFrameBufBase; /* 0x017C */
> + volatile u32 VGANotify; /* 0x0180 */
> + volatile u32 DACPLLMode; /* 0x0184 */
> + volatile u32 Core1VideoClockDiv; /* 0x0188 */
> + volatile u32 AGPIntStat; /* 0x018C */
>
> /*
> - volatile unsigned long Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
> - volatile unsigned long Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
> - volatile unsigned long Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
> - volatile unsigned long Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
> - volatile unsigned long Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
> + volatile u32 Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
> + volatile u32 Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
> + volatile u32 Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
> + volatile u32 Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
> + volatile u32 Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
> */
> - volatile unsigned long Fill4[412]; /* 0x0190 - 0x07FC */
> -
> - volatile unsigned long TACtrlStreamBase; /* 0x0800 */
> - volatile unsigned long TAObjDataBase; /* 0x0804 */
> - volatile unsigned long TAPtrDataBase; /* 0x0808 */
> - volatile unsigned long TARegionDataBase; /* 0x080C */
> - volatile unsigned long TATailPtrBase; /* 0x0810 */
> - volatile unsigned long TAPtrRegionSize; /* 0x0814 */
> - volatile unsigned long TAConfiguration; /* 0x0818 */
> - volatile unsigned long TAObjDataStartAddr; /* 0x081C */
> - volatile unsigned long TAObjDataEndAddr; /* 0x0820 */
> - volatile unsigned long TAXScreenClip; /* 0x0824 */
> - volatile unsigned long TAYScreenClip; /* 0x0828 */
> - volatile unsigned long TARHWClamp; /* 0x082C */
> - volatile unsigned long TARHWCompare; /* 0x0830 */
> - volatile unsigned long TAStart; /* 0x0834 */
> - volatile unsigned long TAObjReStart; /* 0x0838 */
> - volatile unsigned long TAPtrReStart; /* 0x083C */
> - volatile unsigned long TAStatus1; /* 0x0840 */
> - volatile unsigned long TAStatus2; /* 0x0844 */
> - volatile unsigned long TAIntStatus; /* 0x0848 */
> - volatile unsigned long TAIntMask; /* 0x084C */
> -
> - volatile unsigned long Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
> -
> - volatile unsigned long TextureAddrThresh; /* 0x0BFC */
> - volatile unsigned long Core1Translation; /* 0x0C00 */
> - volatile unsigned long TextureAddrReMap; /* 0x0C04 */
> - volatile unsigned long RenderOutAGPRemap; /* 0x0C08 */
> - volatile unsigned long _3DRegionReadTrans; /* 0x0C0C */
> - volatile unsigned long _3DPtrReadTrans; /* 0x0C10 */
> - volatile unsigned long _3DParamReadTrans; /* 0x0C14 */
> - volatile unsigned long _3DRegionReadThresh; /* 0x0C18 */
> - volatile unsigned long _3DPtrReadThresh; /* 0x0C1C */
> - volatile unsigned long _3DParamReadThresh; /* 0x0C20 */
> - volatile unsigned long _3DRegionReadAGPRemap; /* 0x0C24 */
> - volatile unsigned long _3DPtrReadAGPRemap; /* 0x0C28 */
> - volatile unsigned long _3DParamReadAGPRemap; /* 0x0C2C */
> - volatile unsigned long ZBufferAGPRemap; /* 0x0C30 */
> - volatile unsigned long TAIndexAGPRemap; /* 0x0C34 */
> - volatile unsigned long TAVertexAGPRemap; /* 0x0C38 */
> - volatile unsigned long TAUVAddrTrans; /* 0x0C3C */
> - volatile unsigned long TATailPtrCacheTrans; /* 0x0C40 */
> - volatile unsigned long TAParamWriteTrans; /* 0x0C44 */
> - volatile unsigned long TAPtrWriteTrans; /* 0x0C48 */
> - volatile unsigned long TAParamWriteThresh; /* 0x0C4C */
> - volatile unsigned long TAPtrWriteThresh; /* 0x0C50 */
> - volatile unsigned long TATailPtrCacheAGPRe; /* 0x0C54 */
> - volatile unsigned long TAParamWriteAGPRe; /* 0x0C58 */
> - volatile unsigned long TAPtrWriteAGPRe; /* 0x0C5C */
> - volatile unsigned long SDRAMArbiterConf; /* 0x0C60 */
> - volatile unsigned long SDRAMConf0; /* 0x0C64 */
> - volatile unsigned long SDRAMConf1; /* 0x0C68 */
> - volatile unsigned long SDRAMConf2; /* 0x0C6C */
> - volatile unsigned long SDRAMRefresh; /* 0x0C70 */
> - volatile unsigned long SDRAMPowerStat; /* 0x0C74 */
> -
> - volatile unsigned long Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
> -
> - volatile unsigned long RAMBistData; /* 0x0C80 */
> - volatile unsigned long RAMBistCtrl; /* 0x0C84 */
> - volatile unsigned long FIFOBistKey; /* 0x0C88 */
> - volatile unsigned long RAMBistResult; /* 0x0C8C */
> - volatile unsigned long FIFOBistResult; /* 0x0C90 */
> + volatile u32 Fill4[412]; /* 0x0190 - 0x07FC */
> +
> + volatile u32 TACtrlStreamBase; /* 0x0800 */
> + volatile u32 TAObjDataBase; /* 0x0804 */
> + volatile u32 TAPtrDataBase; /* 0x0808 */
> + volatile u32 TARegionDataBase; /* 0x080C */
> + volatile u32 TATailPtrBase; /* 0x0810 */
> + volatile u32 TAPtrRegionSize; /* 0x0814 */
> + volatile u32 TAConfiguration; /* 0x0818 */
> + volatile u32 TAObjDataStartAddr; /* 0x081C */
> + volatile u32 TAObjDataEndAddr; /* 0x0820 */
> + volatile u32 TAXScreenClip; /* 0x0824 */
> + volatile u32 TAYScreenClip; /* 0x0828 */
> + volatile u32 TARHWClamp; /* 0x082C */
> + volatile u32 TARHWCompare; /* 0x0830 */
> + volatile u32 TAStart; /* 0x0834 */
> + volatile u32 TAObjReStart; /* 0x0838 */
> + volatile u32 TAPtrReStart; /* 0x083C */
> + volatile u32 TAStatus1; /* 0x0840 */
> + volatile u32 TAStatus2; /* 0x0844 */
> + volatile u32 TAIntStatus; /* 0x0848 */
> + volatile u32 TAIntMask; /* 0x084C */
> +
> + volatile u32 Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
> +
> + volatile u32 TextureAddrThresh; /* 0x0BFC */
> + volatile u32 Core1Translation; /* 0x0C00 */
> + volatile u32 TextureAddrReMap; /* 0x0C04 */
> + volatile u32 RenderOutAGPRemap; /* 0x0C08 */
> + volatile u32 _3DRegionReadTrans; /* 0x0C0C */
> + volatile u32 _3DPtrReadTrans; /* 0x0C10 */
> + volatile u32 _3DParamReadTrans; /* 0x0C14 */
> + volatile u32 _3DRegionReadThresh; /* 0x0C18 */
> + volatile u32 _3DPtrReadThresh; /* 0x0C1C */
> + volatile u32 _3DParamReadThresh; /* 0x0C20 */
> + volatile u32 _3DRegionReadAGPRemap; /* 0x0C24 */
> + volatile u32 _3DPtrReadAGPRemap; /* 0x0C28 */
> + volatile u32 _3DParamReadAGPRemap; /* 0x0C2C */
> + volatile u32 ZBufferAGPRemap; /* 0x0C30 */
> + volatile u32 TAIndexAGPRemap; /* 0x0C34 */
> + volatile u32 TAVertexAGPRemap; /* 0x0C38 */
> + volatile u32 TAUVAddrTrans; /* 0x0C3C */
> + volatile u32 TATailPtrCacheTrans; /* 0x0C40 */
> + volatile u32 TAParamWriteTrans; /* 0x0C44 */
> + volatile u32 TAPtrWriteTrans; /* 0x0C48 */
> + volatile u32 TAParamWriteThresh; /* 0x0C4C */
> + volatile u32 TAPtrWriteThresh; /* 0x0C50 */
> + volatile u32 TATailPtrCacheAGPRe; /* 0x0C54 */
> + volatile u32 TAParamWriteAGPRe; /* 0x0C58 */
> + volatile u32 TAPtrWriteAGPRe; /* 0x0C5C */
> + volatile u32 SDRAMArbiterConf; /* 0x0C60 */
> + volatile u32 SDRAMConf0; /* 0x0C64 */
> + volatile u32 SDRAMConf1; /* 0x0C68 */
> + volatile u32 SDRAMConf2; /* 0x0C6C */
> + volatile u32 SDRAMRefresh; /* 0x0C70 */
> + volatile u32 SDRAMPowerStat; /* 0x0C74 */
> +
> + volatile u32 Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
> +
> + volatile u32 RAMBistData; /* 0x0C80 */
> + volatile u32 RAMBistCtrl; /* 0x0C84 */
> + volatile u32 FIFOBistKey; /* 0x0C88 */
> + volatile u32 RAMBistResult; /* 0x0C8C */
> + volatile u32 FIFOBistResult; /* 0x0C90 */
>
> /*
> - volatile unsigned long Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
> - volatile unsigned long Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
> + volatile u32 Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
> + volatile u32 Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
> */
>
> - volatile unsigned long Fill7[16]; /* 0x0c94 - 0x0cd0 */
> + volatile u32 Fill7[16]; /* 0x0c94 - 0x0cd0 */
>
> - volatile unsigned long SDRAMAddrSign; /* 0x0CD4 */
> - volatile unsigned long SDRAMDataSign; /* 0x0CD8 */
> - volatile unsigned long SDRAMSignConf; /* 0x0CDC */
> + volatile u32 SDRAMAddrSign; /* 0x0CD4 */
> + volatile u32 SDRAMDataSign; /* 0x0CD8 */
> + volatile u32 SDRAMSignConf; /* 0x0CDC */
>
> /* DWFILL; //GAP 0x0CE0 */
> - volatile unsigned long dwFill_2;
> -
> - volatile unsigned long ISPSignature; /* 0x0CE4 */
> -
> - volatile unsigned long Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
> -
> - volatile unsigned long DACPrimAddress; /* 0x1400 */
> - volatile unsigned long DACPrimSize; /* 0x1404 */
> - volatile unsigned long DACCursorAddr; /* 0x1408 */
> - volatile unsigned long DACCursorCtrl; /* 0x140C */
> - volatile unsigned long DACOverlayAddr; /* 0x1410 */
> - volatile unsigned long DACOverlayUAddr; /* 0x1414 */
> - volatile unsigned long DACOverlayVAddr; /* 0x1418 */
> - volatile unsigned long DACOverlaySize; /* 0x141C */
> - volatile unsigned long DACOverlayVtDec; /* 0x1420 */
> -
> - volatile unsigned long Fill9[9]; /* GAP 0x1424 - 0x1444 */
> -
> - volatile unsigned long DACVerticalScal; /* 0x1448 */
> - volatile unsigned long DACPixelFormat; /* 0x144C */
> - volatile unsigned long DACHorizontalScal; /* 0x1450 */
> - volatile unsigned long DACVidWinStart; /* 0x1454 */
> - volatile unsigned long DACVidWinEnd; /* 0x1458 */
> - volatile unsigned long DACBlendCtrl; /* 0x145C */
> - volatile unsigned long DACHorTim1; /* 0x1460 */
> - volatile unsigned long DACHorTim2; /* 0x1464 */
> - volatile unsigned long DACHorTim3; /* 0x1468 */
> - volatile unsigned long DACVerTim1; /* 0x146C */
> - volatile unsigned long DACVerTim2; /* 0x1470 */
> - volatile unsigned long DACVerTim3; /* 0x1474 */
> - volatile unsigned long DACBorderColor; /* 0x1478 */
> - volatile unsigned long DACSyncCtrl; /* 0x147C */
> - volatile unsigned long DACStreamCtrl; /* 0x1480 */
> - volatile unsigned long DACLUTAddress; /* 0x1484 */
> - volatile unsigned long DACLUTData; /* 0x1488 */
> - volatile unsigned long DACBurstCtrl; /* 0x148C */
> - volatile unsigned long DACCrcTrigger; /* 0x1490 */
> - volatile unsigned long DACCrcDone; /* 0x1494 */
> - volatile unsigned long DACCrcResult1; /* 0x1498 */
> - volatile unsigned long DACCrcResult2; /* 0x149C */
> - volatile unsigned long DACLinecount; /* 0x14A0 */
> -
> - volatile unsigned long Fill10[151]; /*GAP 0x14A4 - 0x16FC */
> -
> - volatile unsigned long DigVidPortCtrl; /* 0x1700 */
> - volatile unsigned long DigVidPortStat; /* 0x1704 */
> + volatile u32 dwFill_2;
> +
> + volatile u32 ISPSignature; /* 0x0CE4 */
> +
> + volatile u32 Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
> +
> + volatile u32 DACPrimAddress; /* 0x1400 */
> + volatile u32 DACPrimSize; /* 0x1404 */
> + volatile u32 DACCursorAddr; /* 0x1408 */
> + volatile u32 DACCursorCtrl; /* 0x140C */
> + volatile u32 DACOverlayAddr; /* 0x1410 */
> + volatile u32 DACOverlayUAddr; /* 0x1414 */
> + volatile u32 DACOverlayVAddr; /* 0x1418 */
> + volatile u32 DACOverlaySize; /* 0x141C */
> + volatile u32 DACOverlayVtDec; /* 0x1420 */
> +
> + volatile u32 Fill9[9]; /* GAP 0x1424 - 0x1444 */
> +
> + volatile u32 DACVerticalScal; /* 0x1448 */
> + volatile u32 DACPixelFormat; /* 0x144C */
> + volatile u32 DACHorizontalScal; /* 0x1450 */
> + volatile u32 DACVidWinStart; /* 0x1454 */
> + volatile u32 DACVidWinEnd; /* 0x1458 */
> + volatile u32 DACBlendCtrl; /* 0x145C */
> + volatile u32 DACHorTim1; /* 0x1460 */
> + volatile u32 DACHorTim2; /* 0x1464 */
> + volatile u32 DACHorTim3; /* 0x1468 */
> + volatile u32 DACVerTim1; /* 0x146C */
> + volatile u32 DACVerTim2; /* 0x1470 */
> + volatile u32 DACVerTim3; /* 0x1474 */
> + volatile u32 DACBorderColor; /* 0x1478 */
> + volatile u32 DACSyncCtrl; /* 0x147C */
> + volatile u32 DACStreamCtrl; /* 0x1480 */
> + volatile u32 DACLUTAddress; /* 0x1484 */
> + volatile u32 DACLUTData; /* 0x1488 */
> + volatile u32 DACBurstCtrl; /* 0x148C */
> + volatile u32 DACCrcTrigger; /* 0x1490 */
> + volatile u32 DACCrcDone; /* 0x1494 */
> + volatile u32 DACCrcResult1; /* 0x1498 */
> + volatile u32 DACCrcResult2; /* 0x149C */
> + volatile u32 DACLinecount; /* 0x14A0 */
> +
> + volatile u32 Fill10[151]; /*GAP 0x14A4 - 0x16FC */
> +
> + volatile u32 DigVidPortCtrl; /* 0x1700 */
> + volatile u32 DigVidPortStat; /* 0x1704 */
>
> /*
> - volatile unsigned long Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
> - volatile unsigned long Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
> + volatile u32 Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
> + volatile u32 Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
> */
>
> - volatile unsigned long Fill11[1598];
> + volatile u32 Fill11[1598];
>
> /* DWFILL; //GAP 0x3000 ALUT 256MB offset */
> - volatile unsigned long Fill_3;
> + volatile u32 Fill_3;
>
> } STG4000REG;
>
>
>
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Alan Cox @ 2012-04-10 14:28 UTC (permalink / raw)
To: Wang YanQing; +Cc: FlorianSchandinat, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120410064918.GA7611@udknight>
> Hi Alan, are you decided to not reply this any?
I'm not aware of anythign that needs adding to this. Any logic about
whether PCI BIOS methods can be called belongs in the PCI layer, as does
the necessary logic for marking ROMs executable if asked by a driver.
uvesafb isn't the only user of PCI methods that may be affected and the
PCI layer is the place that should export the method to decide this.
That will also then work sanely cross platform - since in general on non
x86 boxes the method can simply return "no"
Alan
^ permalink raw reply
* Re: mx3fb overlay support
From: Guennadi Liakhovetski @ 2012-04-10 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJP5LRNwPXx_sQ=uX4AZDz9HvLdF_nRcoVXBkAWmidVpbdby9g@mail.gmail.com>
Hi Alex
On Tue, 10 Apr 2012, alex gershgorin wrote:
> Hi Guennadi,
>
> In mx3fb current version overlay does not supporting,
> I came across a patch 3/4 v4 i.MX31: framebuffer driver that you submitted
> in 2008,
> there was support Overlay, but for some reason in the next versions overlay
> support has been removed.
>
> As you understand this is necessary if we want to use the foreground and
> background Planes.
> in my case, one has to display live video, and other graphics.
>
> I would like to hear your opinion, if may reuse a part of this patch,
> and add overlay support to mx3fb current version.
Maybe this note in the original commit message explains the reason:
"Overlay support is included but has never been tested." ;-)
> if necessary, I am ready to provide any assistance :-)
Sure, please, re-add it, test, fix, any improvements are welcome.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Wang YanQing @ 2012-04-10 6:49 UTC (permalink / raw)
To: Alan Cox, FlorianSchandinat, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120401010530.GA4431@udknight>
On Sun, Apr 01, 2012 at 09:05:30AM +0800, Wang YanQing wrote:
> On Wed, Mar 28, 2012 at 08:52:38AM +0800, Wang YanQing wrote:
> > On Tue, Mar 27, 2012 at 02:32:43PM +0100, Alan Cox wrote:
> > > On Tue, 27 Mar 2012 18:01:36 +0800
> > > Wang YanQing <udknight@gmail.com> wrote:
> > >
> > > >
> > > > Ok! I try to check pcibios_enabled first, but get some opposition by Alan Cox,
> > > > but I want to make thing work and fix the oops, so I choice the simple way to
> > > > check the (__supported_pte_mask & _PAGE_NX) instead of to check this variable plus
> > > > pci kernel boot parameter, pci mmconfig works or not, and more, and more. It is not
> > > > the best method, but it works and maybe all will feel happy.
> > >
> > > Okay let me ask the obvious question - why is it not the best method ?
> > >
> > > Apart from adding a helper in the includes for the arch code of
> > >
> > > static inline is_nx_enabled(void)
> > > {
> > > return !!(__supported_pte_mask & _PAGE_NX);
> > > }
> > >
> > > is there anything else it lacks ?
> > >
> > > Yes ideally we'd set the relevant ROM areas executable, but for a simple
> > > fix is there anything else that's a problem with it ?
> > Ok! Maybe you had missed my previous reply
> > http://permalink.gmane.org/gmane.linux.kernel/1272433
> > It is not the best method, because the check is not enough.
> > I means when NX is actively, the pci bios is NX or not also depend on
> > the code path in pci_arch_init which will be influenced by the acpi on or off, pci kernel boot
> > parameter, even kernel config like pci access method PCI_GOANY, PCI_GOMMCONFIG, or PCI_GODIRECT,
> > but if I check the pcibios_enabled, all the above can be ignored.
> >
> > if uvesafb use the PMI when PCI BIOS is X, it can get the better work efficience then use the redraw
> > method as a fallback when do the panning.
> Alan
>
> I am just curious, I want to know what I describe above is right a little,
> or wrong about all the aspect.
> thanks.
>
Hi Alan, are you decided to not reply this any?
But maybe we are still here to wait for your proposal to
decide the final proper solution to fix the bug in kernel.
Thanks
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-04-09 21:37 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yOU2FDTNRnr=aLVFTGHiVsGNKVoqLqAWQ7Q+Xzg6_B8qQ@mail.gmail.com>
On Mon, 2012-04-09 at 20:18 +0400, Dmitry Eremin-Solenikov wrote:
> > As for the patches, you'll have to wait for Tony to respond (I'll
> poke
> > him locally).
>
> Any news on these patches? A dirty and "not for the upstream yet"
> version
> would be sufficient for me for now.
I'll poke again..
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-04-09 16:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <1332222008.2982.13.camel@pasglop>
On Tue, Mar 20, 2012 at 9:40 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>> >> That is interesting! Are those patches published or otherwise available
>> >> somewhere? We are also very interested in enabling Canyonlands
>> >> with Radeon KMS!
>> >
>> > You will run into additional problems with 460 due to the fact that it's
>> > not cache coherent for DMA. Tony patches don't address that part of the
>> > problem (they were used on a 476 based platform).
>>
>> Hmm. Could you please spill a little bit more of details? Also are those patches
>> for 476 merged or present somewhere?
>
> Well, DMA on 46x isn't cache coherent. The DRM plays interesting games
> with mapping/unmapping pages for DMA by the chip and I don't think we
> have the right hooks to do the appropriate cache flushing on these guys,
> but Tony might be able to comment, I don't know whether he tried or not.
>
> On the other hand 476 has fully cache coherent DMA so the only problem
> there is the >32-bit physical address space.
>
> As for the patches, you'll have to wait for Tony to respond (I'll poke
> him locally).
Any news on these patches? A dirty and "not for the upstream yet" version
would be sufficient for me for now.
>
> Cheers,
> Ben.
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] video: exynos: fix build warning and bad pointer deref in dp driver
From: Olof Johansson @ 2012-04-09 14:07 UTC (permalink / raw)
To: Jingoo Han; +Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel
In-Reply-To: <002601cd1632$c34b24b0$49e16e10$%han@samsung.com>
On Mon, Apr 9, 2012 at 2:25 AM, Jingoo Han <jg1.han@samsung.com> wrote:
>> -----Original Message-----
>> From: Olof Johansson [mailto:olof@lixom.net]
>> Sent: Monday, April 09, 2012 1:16 PM
>>
>> I'm not 100% sure if the fix for 'adjust_request' is correct, since
>> it's uncertain what the original intent was. But it's so clearly an
>> uninitialized pointer dereference that my resolution seems to make sense.
>>
>> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
>> drivers/video/exynos/exynos_dp_core.c:521:21: warning: 'adjust_request' may be used uninitialized in
>> this function [-Wuninitialized]
>> drivers/video/exynos/exynos_dp_core.c:481:6: note: 'adjust_request' was declared here
>> drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function
>> [-Wuninitialized]
>> drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
>
> My compiler cannot detect this warning.
> What is your compiler version?
gcc version 4.6.2 (GCC)
-Olof
^ permalink raw reply
* Re: [PATCH] video: exynos: fix build warning and bad pointer deref in dp driver
From: Olof Johansson @ 2012-04-09 14:05 UTC (permalink / raw)
To: Jingoo Han; +Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel
In-Reply-To: <002301cd162d$51bd6b00$f5384100$%han@samsung.com>
On Mon, Apr 9, 2012 at 1:46 AM, Jingoo Han <jg1.han@samsung.com> wrote:
>> -----Original Message-----
>> From: Olof Johansson [mailto:olof@lixom.net]
>> Sent: Monday, April 09, 2012 1:16 PM
>>
>> I'm not 100% sure if the fix for 'adjust_request' is correct, since
>> it's uncertain what the original intent was. But it's so clearly an
>> uninitialized pointer dereference that my resolution seems to make sense.
>>
>> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
>> drivers/video/exynos/exynos_dp_core.c:521:21: warning: 'adjust_request' may be used uninitialized in
>> this function [-Wuninitialized]
>> drivers/video/exynos/exynos_dp_core.c:481:6: note: 'adjust_request' was declared here
>> drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function
>> [-Wuninitialized]
>> drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
>>
>> Signed-off-by: Olof Johansson <olof@lixom.net>
>> ---
>> drivers/video/exynos/exynos_dp_core.c | 23 +++++++++--------------
>> 1 file changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
>> index 2a4481c..8973e18 100644
>> --- a/drivers/video/exynos/exynos_dp_core.c
>> +++ b/drivers/video/exynos/exynos_dp_core.c
>> @@ -392,24 +392,19 @@ static unsigned int exynos_dp_get_lane_link_training(
>> struct exynos_dp_device *dp,
>> int lane)
>> {
>> - u32 reg;
>> -
>> switch (lane) {
>> case 0:
>> - reg = exynos_dp_get_lane0_link_training(dp);
>> - break;
>> + return exynos_dp_get_lane0_link_training(dp);
>> case 1:
>> - reg = exynos_dp_get_lane1_link_training(dp);
>> - break;
>> + return exynos_dp_get_lane1_link_training(dp);
>> case 2:
>> - reg = exynos_dp_get_lane2_link_training(dp);
>> - break;
>> + return exynos_dp_get_lane2_link_training(dp);
>> case 3:
>> - reg = exynos_dp_get_lane3_link_training(dp);
>> - break;
>> + return exynos_dp_get_lane3_link_training(dp);
>> }
>
> I don't like multi return.
In a small helper function like this there's nothing wrong with it.
Larger functions? Sure.
Adding a default in the switch didn't seem like an improvement to me.
But I'll leave it up to you.
>>
>> - return reg;
>> + WARN_ON(1);
>> + return 0;
>> }
>>
>> static void exynos_dp_reduce_link_rate(struct exynos_dp_device *dp)
>> @@ -489,13 +484,13 @@ static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
>> 6, link_status);
>> lane_count = dp->link_train.lane_count;
>>
>> + adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
>> + - DPCD_ADDR_LANE0_1_STATUS);
>> +
>
> It makes the problem. adjust_request will be different.
>
> OK, I understand what you want to do.
> I will send the version 2 patch which is simpler.
>
> Thank you for sending the patch.
Ok, thanks. As I said, I'm not sure what your intent with the second
(else) code path was.
-Olof
^ permalink raw reply
* RE: [PATCH] video: exynos: fix build warning and bad pointer deref in dp driver
From: Jingoo Han @ 2012-04-09 9:25 UTC (permalink / raw)
To: 'Olof Johansson'
Cc: 'Florian Tobias Schandinat', linux-fbdev, linux-kernel
In-Reply-To: <1333944982-15859-1-git-send-email-olof@lixom.net>
> -----Original Message-----
> From: Olof Johansson [mailto:olof@lixom.net]
> Sent: Monday, April 09, 2012 1:16 PM
>
> I'm not 100% sure if the fix for 'adjust_request' is correct, since
> it's uncertain what the original intent was. But it's so clearly an
> uninitialized pointer dereference that my resolution seems to make sense.
>
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
> drivers/video/exynos/exynos_dp_core.c:521:21: warning: 'adjust_request' may be used uninitialized in
> this function [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:481:6: note: 'adjust_request' was declared here
> drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function
> [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
My compiler cannot detect this warning.
What is your compiler version?
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> drivers/video/exynos/exynos_dp_core.c | 23 +++++++++--------------
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 2a4481c..8973e18 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -392,24 +392,19 @@ static unsigned int exynos_dp_get_lane_link_training(
> struct exynos_dp_device *dp,
> int lane)
> {
> - u32 reg;
> -
> switch (lane) {
> case 0:
> - reg = exynos_dp_get_lane0_link_training(dp);
> - break;
> + return exynos_dp_get_lane0_link_training(dp);
> case 1:
> - reg = exynos_dp_get_lane1_link_training(dp);
> - break;
> + return exynos_dp_get_lane1_link_training(dp);
> case 2:
> - reg = exynos_dp_get_lane2_link_training(dp);
> - break;
> + return exynos_dp_get_lane2_link_training(dp);
> case 3:
> - reg = exynos_dp_get_lane3_link_training(dp);
> - break;
> + return exynos_dp_get_lane3_link_training(dp);
> }
>
> - return reg;
> + WARN_ON(1);
> + return 0;
> }
>
> static void exynos_dp_reduce_link_rate(struct exynos_dp_device *dp)
> @@ -489,13 +484,13 @@ static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
> 6, link_status);
> lane_count = dp->link_train.lane_count;
>
> + adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
> + - DPCD_ADDR_LANE0_1_STATUS);
> +
> if (exynos_dp_clock_recovery_ok(link_status, lane_count) = 0) {
> /* set training pattern 2 for EQ */
> exynos_dp_set_training_pattern(dp, TRAINING_PTN2);
>
> - adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
> - - DPCD_ADDR_LANE0_1_STATUS);
> -
> exynos_dp_get_adjust_train(dp, adjust_request);
>
> buf[0] = DPCD_SCRAMBLING_DISABLED |
> --
> 1.7.9.2.359.gebfc2
^ permalink raw reply
* RE: [PATCH] video: exynos: fix build warning and bad pointer deref in dp driver
From: Jingoo Han @ 2012-04-09 8:46 UTC (permalink / raw)
To: 'Olof Johansson'
Cc: 'Florian Tobias Schandinat', linux-fbdev, linux-kernel
In-Reply-To: <1333944982-15859-1-git-send-email-olof@lixom.net>
> -----Original Message-----
> From: Olof Johansson [mailto:olof@lixom.net]
> Sent: Monday, April 09, 2012 1:16 PM
>
> I'm not 100% sure if the fix for 'adjust_request' is correct, since
> it's uncertain what the original intent was. But it's so clearly an
> uninitialized pointer dereference that my resolution seems to make sense.
>
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
> drivers/video/exynos/exynos_dp_core.c:521:21: warning: 'adjust_request' may be used uninitialized in
> this function [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:481:6: note: 'adjust_request' was declared here
> drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function
> [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> drivers/video/exynos/exynos_dp_core.c | 23 +++++++++--------------
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 2a4481c..8973e18 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -392,24 +392,19 @@ static unsigned int exynos_dp_get_lane_link_training(
> struct exynos_dp_device *dp,
> int lane)
> {
> - u32 reg;
> -
> switch (lane) {
> case 0:
> - reg = exynos_dp_get_lane0_link_training(dp);
> - break;
> + return exynos_dp_get_lane0_link_training(dp);
> case 1:
> - reg = exynos_dp_get_lane1_link_training(dp);
> - break;
> + return exynos_dp_get_lane1_link_training(dp);
> case 2:
> - reg = exynos_dp_get_lane2_link_training(dp);
> - break;
> + return exynos_dp_get_lane2_link_training(dp);
> case 3:
> - reg = exynos_dp_get_lane3_link_training(dp);
> - break;
> + return exynos_dp_get_lane3_link_training(dp);
> }
I don't like multi return.
>
> - return reg;
> + WARN_ON(1);
> + return 0;
> }
>
> static void exynos_dp_reduce_link_rate(struct exynos_dp_device *dp)
> @@ -489,13 +484,13 @@ static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
> 6, link_status);
> lane_count = dp->link_train.lane_count;
>
> + adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
> + - DPCD_ADDR_LANE0_1_STATUS);
> +
It makes the problem. adjust_request will be different.
OK, I understand what you want to do.
I will send the version 2 patch which is simpler.
Thank you for sending the patch.
> if (exynos_dp_clock_recovery_ok(link_status, lane_count) = 0) {
> /* set training pattern 2 for EQ */
> exynos_dp_set_training_pattern(dp, TRAINING_PTN2);
>
> - adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
> - - DPCD_ADDR_LANE0_1_STATUS);
> -
> exynos_dp_get_adjust_train(dp, adjust_request);
>
> buf[0] = DPCD_SCRAMBLING_DISABLED |
> --
> 1.7.9.2.359.gebfc2
^ permalink raw reply
* [PATCH] video: exynos: fix build warning and bad pointer deref in dp driver
From: Olof Johansson @ 2012-04-09 4:16 UTC (permalink / raw)
To: Jingoo Han
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Olof Johansson
I'm not 100% sure if the fix for 'adjust_request' is correct, since
it's uncertain what the original intent was. But it's so clearly an
uninitialized pointer dereference that my resolution seems to make sense.
drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
drivers/video/exynos/exynos_dp_core.c:521:21: warning: 'adjust_request' may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:481:6: note: 'adjust_request' was declared here
drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/video/exynos/exynos_dp_core.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 2a4481c..8973e18 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -392,24 +392,19 @@ static unsigned int exynos_dp_get_lane_link_training(
struct exynos_dp_device *dp,
int lane)
{
- u32 reg;
-
switch (lane) {
case 0:
- reg = exynos_dp_get_lane0_link_training(dp);
- break;
+ return exynos_dp_get_lane0_link_training(dp);
case 1:
- reg = exynos_dp_get_lane1_link_training(dp);
- break;
+ return exynos_dp_get_lane1_link_training(dp);
case 2:
- reg = exynos_dp_get_lane2_link_training(dp);
- break;
+ return exynos_dp_get_lane2_link_training(dp);
case 3:
- reg = exynos_dp_get_lane3_link_training(dp);
- break;
+ return exynos_dp_get_lane3_link_training(dp);
}
- return reg;
+ WARN_ON(1);
+ return 0;
}
static void exynos_dp_reduce_link_rate(struct exynos_dp_device *dp)
@@ -489,13 +484,13 @@ static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
6, link_status);
lane_count = dp->link_train.lane_count;
+ adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
+ - DPCD_ADDR_LANE0_1_STATUS);
+
if (exynos_dp_clock_recovery_ok(link_status, lane_count) = 0) {
/* set training pattern 2 for EQ */
exynos_dp_set_training_pattern(dp, TRAINING_PTN2);
- adjust_request = link_status + (DPCD_ADDR_ADJUST_REQUEST_LANE0_1
- - DPCD_ADDR_LANE0_1_STATUS);
-
exynos_dp_get_adjust_train(dp, adjust_request);
buf[0] = DPCD_SCRAMBLING_DISABLED |
--
1.7.9.2.359.gebfc2
^ permalink raw reply related
* [PATCH 09/10] cobalt_lcdfb: LCD panel framebuffer support for SEAD-3 platform.
From: Steven J. Hill @ 2012-04-07 16:56 UTC (permalink / raw)
To: linux-mips, ralf
Cc: linux-fbdev, Steven J. Hill, Douglas Leung, Chris Dearman
From: "Steven J. Hill" <sjhill@mips.com>
Add support for LCD panel on MIPS SEAD-3 development platform.
Signed-off-by: Douglas Leung <douglas@mips.com>
Signed-off-by: Chris Dearman <chris@mips.com>
Signed-off-by: Steven J. Hill <sjhill@mips.com>
---
drivers/video/Kconfig | 2 +-
drivers/video/cobalt_lcdfb.c | 45 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a8a897a..e921a45 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2210,7 +2210,7 @@ config FB_XILINX
config FB_COBALT
tristate "Cobalt server LCD frame buffer support"
- depends on FB && MIPS_COBALT
+ depends on FB && (MIPS_COBALT || MIPS_SEAD3)
config FB_SH7760
bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
diff --git a/drivers/video/cobalt_lcdfb.c b/drivers/video/cobalt_lcdfb.c
index f56699d..eae46f6 100644
--- a/drivers/video/cobalt_lcdfb.c
+++ b/drivers/video/cobalt_lcdfb.c
@@ -1,7 +1,8 @@
/*
- * Cobalt server LCD frame buffer driver.
+ * Cobalt/SEAD3 LCD frame buffer driver.
*
* Copyright (C) 2008 Yoichi Yuasa <yuasa@linux-mips.org>
+ * Copyright (C) 2012 MIPS Technologies, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -62,6 +63,7 @@
#define LCD_CUR_POS(x) ((x) & LCD_CUR_POS_MASK)
#define LCD_TEXT_POS(x) ((x) | LCD_TEXT_MODE)
+#ifdef CONFIG_MIPS_COBALT
static inline void lcd_write_control(struct fb_info *info, u8 control)
{
writel((u32)control << 24, info->screen_base);
@@ -81,6 +83,47 @@ static inline u8 lcd_read_data(struct fb_info *info)
{
return readl(info->screen_base + LCD_DATA_REG_OFFSET) >> 24;
}
+#else
+
+#define LCD_CTL 0x00
+#define LCD_DATA 0x08
+#define CPLD_STATUS 0x10
+#define CPLD_DATA 0x18
+
+static inline void cpld_wait(struct fb_info *info)
+{
+ do {
+ } while (readl(info->screen_base + CPLD_STATUS) & 1);
+}
+
+static inline void lcd_write_control(struct fb_info *info, u8 control)
+{
+ cpld_wait(info);
+ writel(control, info->screen_base + LCD_CTL);
+}
+
+static inline u8 lcd_read_control(struct fb_info *info)
+{
+ cpld_wait(info);
+ readl(info->screen_base + LCD_CTL);
+ cpld_wait(info);
+ return readl(info->screen_base + CPLD_DATA) & 0xff;
+}
+
+static inline void lcd_write_data(struct fb_info *info, u8 data)
+{
+ cpld_wait(info);
+ writel(data, info->screen_base + LCD_DATA);
+}
+
+static inline u8 lcd_read_data(struct fb_info *info)
+{
+ cpld_wait(info);
+ readl(info->screen_base + LCD_DATA);
+ cpld_wait(info);
+ return readl(info->screen_base + CPLD_DATA) & 0xff;
+}
+#endif
static int lcd_busy_wait(struct fb_info *info)
{
--
1.7.9.6
^ permalink raw reply related
* Re: [PATCH] kyrofb: fix on x86_64
From: Florian Tobias Schandinat @ 2012-04-07 11:48 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Paul Mundt, linux-fbdev, Kernel development list
In-Reply-To: <201204071338.30521.linux@rainbow-software.org>
On 04/07/2012 11:38 AM, Ondrej Zary wrote:
> On Thursday 22 March 2012 01:01:05 Paul Mundt wrote:
>> On Wed, Mar 21, 2012 at 11:36:50PM +0100, Ondrej Zary wrote:
>>> kyrofb is completely broken on x86_64 because the registers are defined
>>> as unsigned long. Change them to u32 to make the driver work.
>>> Tested with Hercules 3D Prophet 4000XT.
>>>
>>> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>>
>> Looks fine to me.
>>
>> Acked-by: Paul Mundt <lethal@linux-sh.org>
>
> When will this go in?
Probably between -rc2 and -rc3. I've already applied this in my private
tree, I just needed a few days off after the last merge window.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] kyrofb: fix on x86_64
From: Ondrej Zary @ 2012-04-07 11:38 UTC (permalink / raw)
To: Paul Mundt
Cc: Florian Tobias Schandinat, linux-fbdev, Kernel development list
In-Reply-To: <20120322000104.GB26543@linux-sh.org>
On Thursday 22 March 2012 01:01:05 Paul Mundt wrote:
> On Wed, Mar 21, 2012 at 11:36:50PM +0100, Ondrej Zary wrote:
> > kyrofb is completely broken on x86_64 because the registers are defined
> > as unsigned long. Change them to u32 to make the driver work.
> > Tested with Hercules 3D Prophet 4000XT.
> >
> > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>
> Looks fine to me.
>
> Acked-by: Paul Mundt <lethal@linux-sh.org>
When will this go in?
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH v3 1/2] backlight: lcd: add driver for raster-type lcd's with gpio controlled panel reset
From: Andrew Morton @ 2012-04-06 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1332751600-11371-2-git-send-email-thomas.abraham@linaro.org>
> Cc: rpurdie@rpsys.net, florianSchandinat@gmx.de, devicetree-discuss@lists.ozlabs.org, linux-fbdev@vger.kernel.org, linux-samsung-soc@vger.kernel.org, grant.likely@secretlab.ca, rob.herring@calxeda.com, kgene.kim@samsung.com, jg1.han@samsung.com, broonie@opensource.wolfsonmicro.com, kyungmin.park@samsung.com, augulis.darius@gmail.com, ben-linux@fluff.org, lars@metafoo.de, patches@linaro.org
Poor me. When someone sends a patch like this, I need to go and hunt
down everyone's real names to nicely add them to the changelog's Cc:
list. I prefer that you do this ;)
You can add Cc:'s to the changelog yourself, of course. Often that
works out better than having me try to work out who might be
interested in the patch.
On Mon, 26 Mar 2012 14:16:39 +0530
Thomas Abraham <thomas.abraham@linaro.org> wrote:
> Add a lcd panel driver for simple raster-type lcd's which uses a gpio
> controlled panel reset. The driver controls the nRESET line of the panel
> using a gpio connected from the host system. The Vcc supply to the panel
> is (optionally) controlled using a voltage regulator. This driver excludes
> support for lcd panels that use a serial command interface or direct
> memory mapped IO interface.
>
>
> ...
>
> +struct lcd_pwrctrl {
> + struct device *dev;
> + struct lcd_device *lcd;
> + struct lcd_pwrctrl_data *pdata;
> + struct regulator *regulator;
> + unsigned int power;
> + bool suspended;
> + bool pwr_en;
Generally kernel code will avoid these unpronounceable abbreviations.
So we do
pwr -> power
en -> enable
ctrl -> control
etc. It results in longer identifiers, but the code is more readable
and, more importantly, more *rememberable*.
> +};
> +
> +static int lcd_pwrctrl_get_power(struct lcd_device *lcd)
> +{
> + struct lcd_pwrctrl *lp = lcd_get_data(lcd);
> + return lp->power;
> +}
> +
> +static int lcd_pwrctrl_set_power(struct lcd_device *lcd, int power)
See, shouldn't that have been lcd_pwrctrl_set_pwr?
If we avoid the abbreviations, such issues do not arise.
> +{
> + struct lcd_pwrctrl *lp = lcd_get_data(lcd);
> + struct lcd_pwrctrl_data *pd = lp->pdata;
> + bool lcd_enable;
> + int lcd_reset, ret = 0;
> +
> + lcd_enable = (power = FB_BLANK_POWERDOWN || lp->suspended) ? 0 : 1;
This isn't how to use `bool'. We can use
lcd_enable = (power = FB_BLANK_POWERDOWN) || lp->suspended;
> + lcd_reset = (pd->invert) ? !lcd_enable : lcd_enable;
> +
> + if (lp->pwr_en = lcd_enable)
> + return 0;
> +
> + if (!IS_ERR_OR_NULL(lp->regulator)) {
> + if (lcd_enable) {
> + if (regulator_enable(lp->regulator)) {
> + dev_info(lp->dev, "regulator enable failed\n");
> + ret = -EPERM;
> + }
> + } else {
> + if (regulator_disable(lp->regulator)) {
> + dev_info(lp->dev, "regulator disable failed\n");
> + ret = -EPERM;
> + }
> + }
> + }
> +
> + gpio_direction_output(lp->pdata->gpio, lcd_reset);
> + lp->power = power;
> + lp->pwr_en = lcd_enable;
Again, this could have been any of
lp->[power|pwr] = [power|pwr];
lp->[power|pwr]_[en|enable] = lcd_[en|enable];
zillions of combinations! If we just avoid the abbreviations, there is
only one combination.
> + return ret;
> +}
> +
>
> ...
>
> +static int __devinit lcd_pwrctrl_probe(struct platform_device *pdev)
> +{
> + struct lcd_pwrctrl *lp;
> + struct lcd_pwrctrl_data *pdata = pdev->dev.platform_data;
> + struct device *dev = &pdev->dev;
> + int err;
> +
> +#ifdef CONFIG_OF
> + if (dev->of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(dev, "memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> + lcd_pwrctrl_parse_dt(dev, pdata);
> + }
> +#endif
> +
> + if (!pdata) {
> + dev_err(dev, "platform data not available\n");
> + return -EINVAL;
> + }
> +
> + lp = devm_kzalloc(dev, sizeof(struct lcd_pwrctrl), GFP_KERNEL);
Nit: I prefer sizeof(*lp) here, so I don't have to scroll back and
check the type of lp.
> + if (!lp) {
> + dev_err(dev, "memory allocation failed for private data\n");
> + return -ENOMEM;
> + }
> +
> + err = gpio_request(pdata->gpio, "LCD-nRESET");
> + if (err) {
> + dev_err(dev, "gpio [%d] request failed\n", pdata->gpio);
> + return err;
> + }
> +
>
> ...
>
The code looks OK to me, but I do think the naming decisions should be
revisited, please.
^ permalink raw reply
* Re: [PATCH v2] video: s3c-fb: Add device tree support
From: Jingoo Han @ 2012-04-06 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1333086797-1625-1-git-send-email-thomas.abraham@linaro.org>
On Fri, Mar 30, 2012 at 2:23, Thomas Abraham <thomas.abraham@linaro.org> wrote:
> Subject: [PATCH v2] video: s3c-fb: Add device tree support
>
> Add device tree based discovery support for Samsung's display controller
> framebuffer driver.
>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> .../devicetree/bindings/fb/samsung-fb.txt | 148 +++++++++++++
> drivers/video/s3c-fb.c | 230 +++++++++++++++++++-
> 2 files changed, 370 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/samsung-fb.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/samsung-fb.txt
> b/Documentation/devicetree/bindings/fb/samsung-fb.txt
> new file mode 100644
> index 0000000..612bd9f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/samsung-fb.txt
> @@ -0,0 +1,148 @@
> +* Samsung Display Controller Framebuffer Controller
> +
> +The display controller is used to transfer image data from memory to a
> +external display device such as an RGB interface LCD panel. It supports
> +various color formats such as rgb and yuv. It also supports multiple window
> +overlays.
> +
> +Required properties:
> +
> + - compatible: should be one of the following
> + - samsung,exynos4210-fimd: for fimd compatible with Exynos4210 fimd
> + - samsung,s5pv210-fimd: for fimd compatible with s5pv210 fimd
> +
> + - reg: physical base address of the controller and length of memory
> + mapped region.
> +
> + - interrupts: Three interrupts should be specified. The format of the
> + interrupt specifier depends on the interrupt controller. The interrupts
> + should be specified in the following order.
> + - VSYNC (Video Frame) interrupt
> + - Video FIFO level interrupt
> + - FIMD System Interrupt
> +
> + - gpios: The gpios used to interface with the external LCD panel. For a
> + panel with rgb interface, the gpio interface consists of video data
> + lines, HSYNC, VSYNC, Pixel Clock and Data Enable. The gpio's used for
> + these interface lines can be listed under this property in any order.
> +
> + - samsung,fimd-display: The fimd controller is interfaced with the a
> + display device such as a lcd panel. This property should specify the
> + phandle of the display device node. For a display device node that
> + represents a RGB type display interface, it is expected to specify the
> + video interface timing using the following properties.
> +
> + - lcd-htiming: Specifies the horizontal timing for the overlay. The
> + horizontal timing includes four parameters in the following order.
> +
> + - horizontal back porch (in number of lcd clocks)
> + - horizontal front porch (in number of lcd clocks)
> + - hsync pulse width (in number of lcd clocks)
> + - Display panels X resolution.
> +
> + - lcd-vtiming: Specifies the vertical timing for the overlay. The
> + vertical timing includes four parameters in the following order.
> +
> + - vertical back porch (in number of lcd lines)
> + - vertical front porch (in number of lcd lines)
> + - vsync pulse width (in number of lcd clocks)
> + - Y resolution.
> +
> + - Overlay/Windows: Multiple overlays/windows can be specified as child
> + nodes. Each window should have the following properties (optional
> + window properties are marked as 'optional').
> +
> + - samsung,fimd-win-id: Specifies the window number of the fimd controller.
> +
> + - samsung,fimd-win-bpp: Specifies the bits per pixel. Two values should
> + be specified in the following order.
> + - default-bpp: bpp supported by the overlay.
> + - max-bpp: maximum required bpp for the overlay.
> +
> + - samsung,fimd-win-res: (OPTIONAL) Specifies the window resolution in
> + pixels. The resolution contains the X and Y pixel values with X being
> + specified first. If this property is not specified, the window
> + resolution is set to be equal to the display panel resolution.
> +
> + - samsung,fimd-win-virtres: (OPTIONAL) Specifies the resolution of the
> + virtual frame buffer for the window. The resolution contains the X
> + and Y resolution in pixels with value of X being the specified first.
> +
> +Optional properties:
> +
> + - samsung,fimd-vidout-rgb: Video output format is RGB.
> + - samsung,fimd-inv-hsync: invert hsync pulse polarity.
> + - samsung,fimd-inv-vsync: invert vsync pulse polarity.
> + - samsung,fimd-inv-vclk: invert video clock polarity.
> + - samsung,fimd-inv-vden: invert video enable signal polarity.
> + - samsung,fimd-frame-rate: Number of video frames per second.
> +
> +Example:
> +
> + The following is an example for the fimd framebuffer controller is split
> + into two portions. The SoC specific portion can be specified in the SoC
> + specific dts file. The board specific portion can be specified in the
> + board specific dts file.
> +
> + - SoC Specific portion
> +
> + fimd@11C00000 {
> + compatible = "samsung,exynos4210-fimd";
> + interrupt-parent = <&combiner>;
> + reg = <0x11C00000 0x8000>;
> + interrupts = <11 1>, <11 0>, <11 2>;
> + };
> +
> + - Board Specific portion
> +
> + fimd@11C00000 {
> + samsung,fimd-display = <&lcd_fimd0>;
> + samsung,fimd-vidout-rgb;
> + samsung,fimd-inv-hsync;
> + samsung,fimd-inv-vsync;
> + samsung,fimd-inv-vclk;
> + samsung,fimd-frame-rate = <60>;
> +
> + gpios = <&gpf0 0 2 0 0>,
> + <&gpf0 1 2 0 0>,
> + <&gpf0 2 2 0 0>,
> + <&gpf0 3 2 0 0>,
> + <&gpf0 4 2 0 0>,
> + <&gpf0 5 2 0 0>,
> + <&gpf0 6 2 0 0>,
> + <&gpf0 7 2 0 0>,
> + <&gpf1 0 2 0 0>,
> + <&gpf1 1 2 0 0>,
> + <&gpf1 2 2 0 0>,
> + <&gpf1 3 2 0 0>,
> + <&gpf1 4 2 0 0>,
> + <&gpf1 5 2 0 0>,
> + <&gpf1 6 2 0 0>,
> + <&gpf1 7 2 0 0>,
> + <&gpf2 0 2 0 0>,
> + <&gpf2 1 2 0 0>,
> + <&gpf2 2 2 0 0>,
> + <&gpf2 3 2 0 0>,
> + <&gpf2 4 2 0 0>,
> + <&gpf2 5 2 0 0>,
> + <&gpf2 6 2 0 0>,
> + <&gpf2 7 2 0 0>,
> + <&gpf3 0 2 0 0>,
> + <&gpf3 1 2 0 0>,
> + <&gpf3 2 2 0 0>,
> + <&gpf3 3 2 0 0>;
> +
> + window0 {
> + samsung,fimd-win-id = <0>;
> + samsung,fimd-win-bpp = <32 24>;
> + samsung,fimd-win-res = <512 300>;
> + samsung,fimd-win-vres = <1024 600>;
> + };
> +
> + window1 {
> + samsung,fimd-win-id = <1>;
> + samsung,fimd-win-bpp = <32 24>;
> + samsung,fimd-win-res = <1024 200>;
> + samsung,fimd-win-vres = <1024 600>;
> + };
> + };
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 18c84b8..b8be668 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -24,6 +24,8 @@
> #include <linux/uaccess.h>
> #include <linux/interrupt.h>
> #include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
>
> #include <mach/map.h>
> #include <plat/regs-fb-v4.h>
> @@ -220,6 +222,7 @@ struct s3c_fb {
> int irq_no;
> unsigned long irq_flags;
> struct s3c_fb_vsync vsync_info;
> + int *gpios;
> };
>
> /**
> @@ -1352,27 +1355,215 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
> writel(reg & ~SHADOWCON_WINx_PROTECT(win), regs + SHADOWCON);
> }
>
> +#ifdef CONFIG_OF
> +static int s3c_fb_dt_parse_gpios(struct device *dev, struct s3c_fb *sfb,
> + bool request)
> +{
> + int nr_gpios, idx, gpio, ret;
> +
> + nr_gpios = sfb->pdata->win[0]->max_bpp + 4;
> + sfb->gpios = devm_kzalloc(dev, sizeof(int) * nr_gpios, GFP_KERNEL);
> + if (!sfb->gpios) {
> + dev_err(dev, "unable to allocate private data for gpio\n");
> + return -ENOMEM;
> + }
> +
> + for (idx = 0; idx < nr_gpios; idx++) {
> + gpio = of_get_gpio(dev->of_node, idx);
> + if (!gpio_is_valid(gpio)) {
> + dev_err(dev, "invalid gpio[%d]: %d\n", idx, gpio);
> + return -EINVAL;
> + }
> +
> + if (!request)
> + continue;
> +
> + ret = gpio_request(gpio, "fimd");
> + if (ret) {
> + dev_err(dev, "gpio [%d] request failed\n", gpio);
> + goto gpio_free;
> + }
> + sfb->gpios[idx] = gpio;
> + }
> + return 0;
> +
> +gpio_free:
> + while (--idx >= 0)
> + gpio_free(sfb->gpios[idx]);
> + return ret;
> +}
> +
> +static void s3c_fb_dt_free_gpios(struct s3c_fb *sfb)
> +{
> + unsigned int idx, nr_gpio;
> +
> + nr_gpio = sfb->pdata->win[0]->max_bpp + 4;
> + for (idx = 0; idx < nr_gpio; idx++)
> + gpio_free(sfb->gpios[idx]);
> +}
> +
> +static struct s3c_fb_platdata *s3c_fb_dt_parse_pdata(struct device *dev)
> +{
> + struct device_node *np = dev->of_node, *win_np;
> + struct device_node *disp_np;
> + struct s3c_fb_platdata *pd;
> + struct s3c_fb_pd_win *win;
> + u32 wnum = 0, data[4];
> +
> + pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
> + if (!pd) {
> + dev_err(dev, "memory allocation for pdata failed\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + pd->vtiming = devm_kzalloc(dev, sizeof(*pd->vtiming), GFP_KERNEL);
> + if (!pd->vtiming) {
> + dev_err(dev, "memory allocation for vtiming failed\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + if (of_get_property(np, "samsung,fimd-vidout-rgb", NULL))
> + pd->vidcon0 |= VIDCON0_VIDOUT_RGB;
> + if (of_get_property(np, "samsung,fimd-vidout-tv", NULL))
> + pd->vidcon0 |= VIDCON0_VIDOUT_TV;
> + if (of_get_property(np, "samsung,fimd-inv-hsync", NULL))
> + pd->vidcon1 |= VIDCON1_INV_HSYNC;
> + if (of_get_property(np, "samsung,fimd-inv-vsync", NULL))
> + pd->vidcon1 |= VIDCON1_INV_VSYNC;
> + if (of_get_property(np, "samsung,fimd-inv-vclk", NULL))
> + pd->vidcon1 |= VIDCON1_INV_VCLK;
> + if (of_get_property(np, "samsung,fimd-inv-vden", NULL))
> + pd->vidcon1 |= VIDCON1_INV_VDEN;
> +
> + disp_np = of_parse_phandle(np, "samsung,fimd-display", 0);
> + if (!disp_np) {
> + dev_err(dev, "unable to find display panel info\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (of_property_read_u32_array(disp_np, "lcd-htiming", data, 4)) {
> + dev_err(dev, "invalid horizontal timing\n");
> + return ERR_PTR(-EINVAL);
> + }
> + pd->vtiming->left_margin = data[0];
> + pd->vtiming->right_margin = data[1];
> + pd->vtiming->hsync_len = data[2];
> + pd->vtiming->xres = data[3];
> +
> + if (of_property_read_u32_array(disp_np, "lcd-vtiming", data, 4)) {
> + dev_err(dev, "invalid vertical timing\n");
> + return ERR_PTR(-EINVAL);
> + }
> + pd->vtiming->upper_margin = data[0];
> + pd->vtiming->lower_margin = data[1];
> + pd->vtiming->vsync_len = data[2];
> + pd->vtiming->yres = data[3];
> +
> + of_property_read_u32_array(np, "samsung,fimd-frame-rate",
> + &pd->vtiming->refresh, 1);
> +
> + for_each_child_of_node(np, win_np) {
> + if (of_property_read_u32_array(win_np, "samsung,fimd-win-id",
> + &wnum, 1)) {
> + dev_err(dev, "window id not specified\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + win = devm_kzalloc(dev, sizeof(*win), GFP_KERNEL);
> + if (!win) {
> + dev_err(dev, "no memory for window[%d] data\n", wnum);
> + return ERR_PTR(-ENOMEM);
> + }
> + pd->win[wnum] = win;
> +
> + if (of_property_read_u32_array(win_np, "samsung,fimd-win-bpp",
> + data, 2)) {
> + dev_err(dev, "invalid window bpp\n");
> + return ERR_PTR(-EINVAL);
> + }
> + win->default_bpp = data[0];
> + win->max_bpp = data[1];
> +
> + if (of_property_read_u32_array(win_np, "samsung,fimd-win-res",
> + data, 2)) {
> + dev_info(dev, "window [%d] resolution not specified. "
> + "Using lcd resolution X[%d] and Y[%d]", wnum,
> + pd->vtiming->xres, pd->vtiming->yres);
> + win->xres = pd->vtiming->xres;
> + win->yres = pd->vtiming->yres;
> + } else {
> + win->xres = data[0];
> + win->yres = data[1];
> + }
> +
> + if (!of_property_read_u32_array(win_np,
> + "samsung,fimd-win-virtres", data, 2)) {
> + win->virtual_x = data[0];
> + win->virtual_y = data[1];
> + }
> + }
> +
> + return pd;
> +}
> +#else
> +static int s3c_fb_dt_parse_gpios(struct device *dev, struct s3c_fb *sfb,
> + bool request)
> +{
> + return 0;
> +}
> +
> +static void s3c_fb_dt_free_gpios(struct s3c_fb *sfb)
> +{
> + return 0;
It makes build warning.
drivers/video/s3c-fb.c: In function 's3c_fb_dt_free_gpios':
drivers/video/s3c-fb.c:1523: warning: 'return' with a value, in function returning void
> +}
> +
> +static int s3c_fb_dt_parse_pdata(struct device *dev,
> + struct s3c_fb_platdata **pdata)
It makes build error when CONFIG_OF is disabled.
Please, do build with disabling CONFIG_OF.
drivers/video/s3c-fb.c: In function 's3c_fb_probe':
drivers/video/s3c-fb.c:1568: error: too few arguments to function 's3c_fb_dt_parse_pdata'
> +{
> + return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static const struct of_device_id s3c_fb_dt_match[];
> +
> +static inline struct s3c_fb_driverdata *s3c_fb_get_driver_data(
> + struct platform_device *pdev)
> +{
> +#ifdef CONFIG_OF
> + if (pdev->dev.of_node) {
> + const struct of_device_id *match;
> + match = of_match_node(s3c_fb_dt_match, pdev->dev.of_node);
> + return (struct s3c_fb_driverdata *)match->data;
> + }
> +#endif
> + return (struct s3c_fb_driverdata *)
> + platform_get_device_id(pdev)->driver_data;
> +}
> +
> static int __devinit s3c_fb_probe(struct platform_device *pdev)
> {
> - const struct platform_device_id *platid;
> struct s3c_fb_driverdata *fbdrv;
> struct device *dev = &pdev->dev;
> - struct s3c_fb_platdata *pd;
> + struct s3c_fb_platdata *pd = pdev->dev.platform_data;
> struct s3c_fb *sfb;
> struct resource *res;
> int win;
> int ret = 0;
> u32 reg;
>
> - platid = platform_get_device_id(pdev);
> - fbdrv = (struct s3c_fb_driverdata *)platid->driver_data;
> + fbdrv = s3c_fb_get_driver_data(pdev);
>
> if (fbdrv->variant.nr_windows > S3C_FB_MAX_WIN) {
> dev_err(dev, "too many windows, cannot attach\n");
> return -EINVAL;
> }
>
> - pd = pdev->dev.platform_data;
> + if (pdev->dev.of_node) {
> + pd = s3c_fb_dt_parse_pdata(&pdev->dev);
> + if (IS_ERR(pd))
> + return PTR_ERR(pd);
> + }
> +
> if (!pd) {
> dev_err(dev, "no platform data specified\n");
> return -EINVAL;
> @@ -1449,7 +1640,12 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>
> /* setup gpio and output polarity controls */
>
> - pd->setup_gpio();
> + if (dev->of_node) {
> + if (s3c_fb_dt_parse_gpios(dev, sfb, true))
> + goto err_lcd_clk;
> + } else {
> + pd->setup_gpio();
> + }
>
> writel(pd->vidcon1, sfb->regs + VIDCON1);
>
> @@ -1499,6 +1695,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> return 0;
>
> err_pm_runtime:
> + s3c_fb_dt_free_gpios(sfb);
> pm_runtime_put_sync(sfb->dev);
>
> err_lcd_clk:
> @@ -1545,6 +1742,7 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
>
> pm_runtime_put_sync(sfb->dev);
> pm_runtime_disable(sfb->dev);
> + s3c_fb_dt_free_gpios(sfb);
>
> return 0;
> }
> @@ -1588,7 +1786,10 @@ static int s3c_fb_resume(struct device *dev)
> clk_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> - pd->setup_gpio();
> + if (dev->of_node)
> + s3c_fb_dt_parse_gpios(dev, sfb, false);
> + else
> + pd->setup_gpio();
> writel(pd->vidcon1, sfb->regs + VIDCON1);
>
> /* set video clock running at under-run */
> @@ -1658,7 +1859,10 @@ static int s3c_fb_runtime_resume(struct device *dev)
> clk_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> - pd->setup_gpio();
> + if (dev->of_node)
> + s3c_fb_dt_parse_gpios(dev, sfb, false);
> + else
> + pd->setup_gpio();
> writel(pd->vidcon1, sfb->regs + VIDCON1);
>
> return 0;
> @@ -2028,6 +2232,15 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
> };
> MODULE_DEVICE_TABLE(platform, s3c_fb_driver_ids);
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id s3c_fb_dt_match[] = {
> + { .compatible = "samsung,exynos4210-fimd",
> + .data = (void *)&s3c_fb_data_exynos4 },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, s3c_fb_dt_match);
> +#endif
> +
> static const struct dev_pm_ops s3cfb_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(s3c_fb_suspend, s3c_fb_resume)
> SET_RUNTIME_PM_OPS(s3c_fb_runtime_suspend, s3c_fb_runtime_resume,
> @@ -2042,6 +2255,7 @@ static struct platform_driver s3c_fb_driver = {
> .name = "s3c-fb",
> .owner = THIS_MODULE,
> .pm = &s3cfb_pm_ops,
> + .of_match_table = of_match_ptr(s3c_fb_dt_match),
> },
> };
>
> --
> 1.6.6.rc2
^ permalink raw reply
* Re: [PATCH 5/5] fbdev: s/#if CONFIG/#ifdef CONFIG/
From: Jiri Kosina @ 2012-04-06 0:00 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Geert Uytterhoeven, linux-kernel, linux-fbdev
In-Reply-To: <4F417B3F.2050307@gmx.de>
On Sun, 19 Feb 2012, Florian Tobias Schandinat wrote:
> On 02/19/2012 03:11 PM, Geert Uytterhoeven wrote:
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>
> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> (I assume you want that to go mainline via Jiri's tree)
As this doesn't seem to be in linux-next through any other tree as of
today, I have picked it up.
Thanks,
--
Jiri Kosina
SUSE Labs
^ 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