* Re: [PATCH] video: amba-clcd: Make CLCD driver available on more platforms
From: Tomi Valkeinen @ 2014-01-10 11:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1386868390-12231-1-git-send-email-broonie@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
On 2013-12-12 19:13, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> The CLCD driver is used on ARM reference models for ARMv8 so add ARM64
> to the list of dependencies. The driver also has no build time dependencies
> on ARM (stubs are provided for ARM-specific DMA functions in the code) so
> make it available with COMPILE_TEST in order to maximise build coverage.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
> ---
> drivers/video/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4f2e1b35eb38..e6c7fb1a389b 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -312,7 +312,8 @@ config FB_PM2_FIFO_DISCONNECT
>
> config FB_ARMCLCD
> tristate "ARM PrimeCell PL110 support"
> - depends on FB && ARM && ARM_AMBA
> + depends on ARM || ARM64 || COMPILE_TEST
> + depends on FB && ARM_AMBA
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch 1/2] video: mmp: delete a stray mutex_unlock()
From: Tomi Valkeinen @ 2014-01-10 11:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20131114081918.GB8150@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
On 2013-11-14 10:19, Dan Carpenter wrote:
> We aren't holding the disp_lock so we shouldn't release it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
> index 84de263..c8d4265 100644
> --- a/drivers/video/mmp/core.c
> +++ b/drivers/video/mmp/core.c
> @@ -173,7 +173,7 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
> + sizeof(struct mmp_overlay) * info->overlay_num;
> path = kzalloc(size, GFP_KERNEL);
> if (!path)
> - goto failed;
> + return NULL;
>
> /* path set */
> mutex_init(&path->access_ok);
> @@ -219,11 +219,6 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
>
> mutex_unlock(&disp_lock);
> return path;
> -
> -failed:
> - kfree(path);
> - mutex_unlock(&disp_lock);
> - return NULL;
> }
> EXPORT_SYMBOL_GPL(mmp_register_path);
>
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch 2/2] video: mmp: Using plain integer as NULL pointer
From: Tomi Valkeinen @ 2014-01-10 11:31 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
On 2013-11-14 10:19, Dan Carpenter wrote:
> Sparse complains here:
>
> drivers/video/mmp/core.c:33:16:
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
> index c8d4265..b563b92 100644
> --- a/drivers/video/mmp/core.c
> +++ b/drivers/video/mmp/core.c
> @@ -30,7 +30,7 @@ static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
> {
> if (path && overlay_id < path->overlay_num)
> return &path->overlays[overlay_id];
> - return 0;
> + return NULL;
> }
>
> static int path_check_status(struct mmp_path *path)
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch v2] tgafb: potential NULL dereference in init
From: Tomi Valkeinen @ 2014-01-10 11:33 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On 2013-12-16 11:49, Dan Carpenter wrote:
> Static checkers complain that there are paths where "tga_type_name" can
> be NULL. I've re-arranged the code slightly so that's impossible.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v1: had introduced a "dereferencing uninitialized variable" bug. Thanks
> to Geert Uytterhoeven for catching that.
>
> diff --git a/drivers/video/tgafb.c b/drivers/video/tgafb.c
> index f28674fea909..afd8887fd656 100644
> --- a/drivers/video/tgafb.c
> +++ b/drivers/video/tgafb.c
> @@ -1496,10 +1496,9 @@ tgafb_init_fix(struct fb_info *info)
> if (tga_bus_tc)
> tga_type_name = "Digital ZLX-E3";
> break;
> - default:
> - tga_type_name = "Unknown";
> - break;
> }
> + if (!tga_type_name)
> + tga_type_name = "Unknown";
>
> strlcpy(info->fix.id, tga_type_name, sizeof(info->fix.id));
>
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video/logo: Remove MIPS-specific include section
From: Tomi Valkeinen @ 2014-01-10 11:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard, Ralf Baechle, linux-fbdev,
linux-mips
In-Reply-To: <1383554550-20901-1-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On 2013-11-04 10:42, Geert Uytterhoeven wrote:
> Since commit 41702d9a4fffa9e25b2ad9d4af09b3013fa155e1 ("logo.c: get rid of
> mips_machgroup") there's no longer a need to include <asm/bootinfo.h> on
> MIPS.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> drivers/video/logo/logo.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
> index 080c35b34bbb..b670cbda38e3 100644
> --- a/drivers/video/logo/logo.c
> +++ b/drivers/video/logo/logo.c
> @@ -17,10 +17,6 @@
> #include <asm/setup.h>
> #endif
>
> -#ifdef CONFIG_MIPS
> -#include <asm/bootinfo.h>
> -#endif
> -
> static bool nologo;
> module_param(nologo, bool, 0);
> MODULE_PARM_DESC(nologo, "Disables startup logo");
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v4] video: add OpenCores VGA/LCD framebuffer driver
From: Tomi Valkeinen @ 2014-01-10 12:08 UTC (permalink / raw)
To: Stefan Kristiansson, linux-kernel, linux-fbdev; +Cc: plagnioj
In-Reply-To: <1385739911-6541-1-git-send-email-stefan.kristiansson@saunalahti.fi>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
Hi,
On 2013-11-29 17:45, Stefan Kristiansson wrote:
> This adds support for the VGA/LCD core available from OpenCores:
> http://opencores.org/project,vga_lcd
>
> The driver have been tested together with both OpenRISC and
> ARM (socfpga) processors.
>
> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
If I'm not mistaken, this driver has been designed so that there can
only be one VGA/LCD core device on the system.
It would be better to get rid of those static structs, and have the
driver data per device as it should. That way the driver works even with
multiple VGA/LCD cores (although the video mode module option is a bit
odd in that case).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv5][ 1/5] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_*
From: Tomi Valkeinen @ 2014-01-10 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383915693-9422-1-git-send-email-denis@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
On 2013-11-08 15:01, Denis Carikli wrote:
> Without that fix, drivers using the fb_videomode_from_videomode
> function will not be able to get certain information because
> some DISPLAY_FLAGS_* have no corresponding FB_SYNC_*.
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ffac70a..cf2ad5d 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -45,6 +45,9 @@ struct device_node;
> #define FB_SIGNAL_SYNC_ON_GREEN 8
> #define FB_SIGNAL_SERRATION_ON 16
>
> +#define FB_SYNC_DE_HIGH_ACT 64 /* data enable active high flag */
> +#define FB_SYNC_PIXDAT_HIGH_ACT 128 /* drive data on positive edge */
> +
> #define FB_MISC_PRIM_COLOR 1
> #define FB_MISC_1ST_DETAIL 2 /* First Detailed Timing is preferred */
> struct fb_chroma {
I don't think this is better than the previous version where
FB_SYNC_DE_HIGH_ACT and FB_SYNC_PIXDAT_HIGH_ACT were in
include/uapi/linux/fb.h. Now those flag defines are not visible to the
userspace, but the actual flags are still visible from the var->sync field.
It's true what Russell replied to the previous version, that the
userspace has no idea how to handle those new flags. But then again, for
LCDs, the userspace has no idea how to handle, say, hsync polarity either.
In any case, splitting the FB_SYNC_ defines into uapi and
kernel-internal header files, but still giving the kernel-internal
values to userspace is surely wrong.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv5][ 1/5] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_*
From: Russell King - ARM Linux @ 2014-01-10 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CFE994.8070701@ti.com>
On Fri, Jan 10, 2014 at 02:37:40PM +0200, Tomi Valkeinen wrote:
> I don't think this is better than the previous version where
> FB_SYNC_DE_HIGH_ACT and FB_SYNC_PIXDAT_HIGH_ACT were in
> include/uapi/linux/fb.h. Now those flag defines are not visible to the
> userspace, but the actual flags are still visible from the var->sync field.
>
> It's true what Russell replied to the previous version, that the
> userspace has no idea how to handle those new flags. But then again, for
> LCDs, the userspace has no idea how to handle, say, hsync polarity either.
>
> In any case, splitting the FB_SYNC_ defines into uapi and
> kernel-internal header files, but still giving the kernel-internal
> values to userspace is surely wrong.
The difference between the sync states and these other flags is that
the sync states are part of the mode definition - as per the CEA-861
documentation.
However, that does not extend to LCD panels, which generally need to
have one set of timings, with the various control signals at certain
polarities - and those control signal polarities are a property of
the panel itself, not of the displayed mode. So, if you know that
you have LCD panel X, and it needs control signals with a certain
polarity, that is how you configure the hardware _irrespective_ of
what userspace says that the sync states should be.
The sync states specified by userspace should of course be used for
the sync pulses being sent to a VGA display or HDMI sink.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Re: [PATCH v4] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-10 16:16 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-kernel, linux-fbdev, plagnioj
In-Reply-To: <52CFE2BB.8090004@ti.com>
On Fri, Jan 10, 2014 at 02:08:27PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-11-29 17:45, Stefan Kristiansson wrote:
> > This adds support for the VGA/LCD core available from OpenCores:
> > http://opencores.org/project,vga_lcd
> >
> > The driver have been tested together with both OpenRISC and
> > ARM (socfpga) processors.
> >
> > Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>
> If I'm not mistaken, this driver has been designed so that there can
> only be one VGA/LCD core device on the system.
>
> It would be better to get rid of those static structs, and have the
> driver data per device as it should. That way the driver works even with
> multiple VGA/LCD cores (although the video mode module option is a bit
> odd in that case).
>
You're right, it's a completely realistic scenario with several
VGA/LCD cores in the system, so the one device only restriction is bad.
And looking closer at the static structs, I see that the ocfb_var and ocfb_fix
doesn't surve any purpose at all, so they can just be removed.
And the information in ocfb_par can easily be obtained directly from ocfb_dev
instead, so by setting info.par to point at that, the ocfb_par struct can also
be removed completely.
Thanks, that suggestion makes the implementation cleaner as well.
I'll post an updated patch with the changes.
Stefan
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] fbcon: Avoid corrupting active workqueue entries
From: Daniel Vetter @ 2014-01-10 17:25 UTC (permalink / raw)
To: Chris Wilson
Cc: linux-fbdev, intel-gfx, dri-devel, Tomi Valkeinen, stable,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1387290459-26440-1-git-send-email-chris@chris-wilson.co.uk>
On Tue, Dec 17, 2013 at 02:27:39PM +0000, Chris Wilson wrote:
> We attempt to reschedule an active work which can itself corrupt the
> workqueue lists, and we may then free the work item whilst the task is
> still pending. Both of these may lead to a system deadlock and an
> unresponsive machine without any outputs for a panic to even be shown.
>
> [ 7.372961] WARNING: at kernel/workqueue.c:1365 __queue_work+0x216/0x292()
> [ 7.372964] Modules linked in: coretemp arc4 kvm_intel kvm iwldvm crc32c_intel mac80211 ghash_clmulni_intel cryptd joydev hid_lenovo_tpkbd lib80211 iTCO_wdt iwlwifi iTCO_vendor_support i915(+) btusb snd_hda_codec_hdmi bluetooth evdev snd_hda_intel usbhid snd_hda_codec pcspkr hid cfg80211 microcode snd_hwdep i2c_i801 snd_pcm drm_kms_helper lpc_ich drm mfd_core snd_page_alloc rfkill snd_timer snd soundcore mei_me i2c_algo_bit video mei acpi_cpufreq mperf i2c_core button processor ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci libahci libata scsi_mod thermal fan ehci_pci ehci_hcd thermal_sys usbcore usb_common
> [ 7.373068] CPU: 0 PID: 660 Comm: ps Not tainted 3.10.9+ #55
> [ 7.373071] Hardware name: /D33217CK, BIOS GKPPT10H.86A.0025.2012.1011.1534 10/11/2012
> [ 7.373075] ffffffff81596a1e ffff88045f203d38 ffffffff813eaef6 ffff88045f203d78
> [ 7.373083] ffffffff81041027 ffff88045f203d78 0000000000000000 ffff88045f217f00
> [ 7.373091] ffff88044a89c800 ffff88042b473aa0 0000000000000000 ffff88045f203d88
> [ 7.373098] Call Trace:
> [ 7.373101] <IRQ> [<ffffffff813eaef6>] dump_stack+0x19/0x1b
> [ 7.373115] [<ffffffff81041027>] warn_slowpath_common+0x62/0x7b
> [ 7.373121] [<ffffffff81041055>] warn_slowpath_null+0x15/0x17
> [ 7.373127] [<ffffffff8105aa82>] __queue_work+0x216/0x292
> [ 7.373133] [<ffffffff8105ab65>] queue_work_on+0x4c/0x7c
> [ 7.373140] [<ffffffff8123cebb>] ? fbcon_add_cursor_timer+0xfb/0xfb
> [ 7.373146] [<ffffffff8123cee1>] cursor_timer_handler+0x26/0x42
> [ 7.373153] [<ffffffff8104ee1f>] call_timer_fn+0xcc/0x1ea
> [ 7.373160] [<ffffffff8104ed53>] ? detach_if_pending+0x7a/0x7a
> [ 7.373166] [<ffffffff8123cebb>] ? fbcon_add_cursor_timer+0xfb/0xfb
> [ 7.373172] [<ffffffff8104f27b>] run_timer_softirq+0x19c/0x1e4
> [ 7.373178] [<ffffffff8104874e>] ? __do_softirq+0x9e/0x2a7
> [ 7.373183] [<ffffffff810487e9>] __do_softirq+0x139/0x2a7
> [ 7.373189] [<ffffffff81048a7a>] irq_exit+0x56/0x9b
> [ 7.373196] [<ffffffff8102af31>] smp_apic_timer_interrupt+0x77/0x85
> [ 7.373203] [<ffffffff813f5ff2>] apic_timer_interrupt+0x72/0x80
> [ 7.373206] <EOI> [<ffffffff8113ea70>] ? spin_lock+0x9/0xb
> [ 7.373217] [<ffffffff8120d8c1>] ? do_raw_spin_trylock+0x42/0x42
> [ 7.373223] [<ffffffff813ef2e0>] ? _raw_spin_unlock+0x23/0x36
> [ 7.373229] [<ffffffff8113ea7b>] spin_unlock+0x9/0xb
> [ 7.373235] [<ffffffff8113fd25>] dput+0xd9/0xf8
> [ 7.373241] [<ffffffff8113685e>] path_put+0x13/0x20
> [ 7.373247] [<ffffffff8113a6f3>] do_last+0x925/0xa0d
> [ 7.373253] [<ffffffff81137fa4>] ? inode_permission+0x40/0x42
> [ 7.373259] [<ffffffff8113a89c>] path_openat+0xc1/0x325
> [ 7.373265] [<ffffffff8113ae0c>] do_filp_open+0x33/0x81
> [ 7.373271] [<ffffffff811455bd>] ? __alloc_fd+0x169/0x17b
> [ 7.373279] [<ffffffff8112d78f>] do_sys_open+0x67/0xf4
> [ 7.373285] [<ffffffff8112d839>] SyS_open+0x1d/0x1f
> [ 7.373290] [<ffffffff813f5369>] system_call_fastpath+0x16/0x1b
> [ 7.373294] ---[ end trace 78bba0b9776072a9 ]---
> [ 7.538936] fbcon: inteldrmfb (fb0) is primary device
> [ 7.539446] Console: switching consoles 2-6 to frame buffer device
> [ 7.539463] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
> [ 7.539468] i915 0000:00:02.0: registered panic notifier
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?idr765
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: stable@vger.kernel.org
> ---
> drivers/video/console/fbcon.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index cd8a8027f8ae..f474976f6b34 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -397,6 +397,8 @@ static void fb_flashcursor(struct work_struct *work)
> ops->cursor(vc, info, mode, softback_lines, get_color(vc, info, c, 1),
> get_color(vc, info, c, 0));
> console_unlock();
> +
> + mod_timer(&ops->cursor_timer, jiffies + HZ/5);
> }
>
> static void cursor_timer_handler(unsigned long dev_addr)
> @@ -405,7 +407,6 @@ static void cursor_timer_handler(unsigned long dev_addr)
> struct fbcon_ops *ops = info->fbcon_par;
>
> queue_work(system_power_efficient_wq, &info->queue);
> - mod_timer(&ops->cursor_timer, jiffies + HZ/5);
> }
>
> static void fbcon_add_cursor_timer(struct fb_info *info)
> @@ -417,6 +418,8 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
> !fbcon_cursor_noblink) {
> if (!info->queue.func)
> INIT_WORK(&info->queue, fb_flashcursor);
> + else
> + flush_work(&info->queue);
>
> init_timer(&ops->cursor_timer);
> ops->cursor_timer.function = cursor_timer_handler;
> @@ -433,6 +436,7 @@ static void fbcon_del_cursor_timer(struct fb_info *info)
>
> if (info->queue.func = fb_flashcursor &&
> ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
> + flush_work(&info->queue);
> del_timer_sync(&ops->cursor_timer);
I think this is still racy - we'd need to loop the flush work and
del_timer until they're both dead, otherwise it could get re-armed.
Probably better to convert this to a delayed_work and just use
cancel_delayed_work_sync.
-Daniel
> ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
> }
> --
> 1.8.5.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-10 20:13 UTC (permalink / raw)
To: linux-kernel, linux-fbdev; +Cc: tomi.valkeinen, plagnioj, Stefan Kristiansson
This adds support for the VGA/LCD core available from OpenCores:
http://opencores.org/project,vga_lcd
The driver have been tested together with both OpenRISC and
ARM (socfpga) processors.
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
---
Changes in v2:
- Add Microblaze as an example user and fix a typo in Xilinx Zynq
Changes in v3:
- Use devm_kzalloc instead of kzalloc
- Remove superflous MODULE #ifdef
Changes in v4:
- Remove 'default n' in Kconfig
- Simplify ioremap/request_mem_region by using devm_ioremap_resource
- Remove release_mem_region
Changes in v5:
- Remove static structs to support multiple devices
---
drivers/video/Kconfig | 16 ++
drivers/video/Makefile | 1 +
drivers/video/ocfb.c | 440 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 457 insertions(+)
create mode 100644 drivers/video/ocfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 84b685f..8e41a1e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -979,6 +979,22 @@ config FB_PVR2
(<file:drivers/video/pvr2fb.c>). Please see the file
<file:Documentation/fb/pvr2fb.txt>.
+config FB_OPENCORES
+ tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
+ depends on FB
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ This enables support for the OpenCores VGA/LCD core.
+
+ The OpenCores VGA/LCD core is typically used together with
+ softcore CPUs (e.g. OpenRISC or Microblaze) or hard processor
+ systems (e.g. Altera socfpga or Xilinx Zynq) on FPGAs.
+
+ The source code and specification for the core is available at
+ <http://opencores.org/project,vga_lcd>
+
config FB_S1D13XXX
tristate "Epson S1D13XXX framebuffer support"
depends on FB
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..ae17ddf 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -150,6 +150,7 @@ obj-$(CONFIG_FB_NUC900) += nuc900fb.o
obj-$(CONFIG_FB_JZ4740) += jz4740_fb.o
obj-$(CONFIG_FB_PUV3_UNIGFX) += fb-puv3.o
obj-$(CONFIG_FB_HYPERV) += hyperv_fb.o
+obj-$(CONFIG_FB_OPENCORES) += ocfb.o
# Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA) += uvesafb.o
diff --git a/drivers/video/ocfb.c b/drivers/video/ocfb.c
new file mode 100644
index 0000000..28faa3e
--- /dev/null
+++ b/drivers/video/ocfb.c
@@ -0,0 +1,440 @@
+/*
+ * OpenCores VGA/LCD 2.0 core frame buffer driver
+ *
+ * Copyright (C) 2013 Stefan Kristiansson, stefan.kristiansson@saunalahti.fi
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/mm.h>
+#include <linux/dma-mapping.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+
+/* OCFB register defines */
+#define OCFB_CTRL 0x000
+#define OCFB_STAT 0x004
+#define OCFB_HTIM 0x008
+#define OCFB_VTIM 0x00c
+#define OCFB_HVLEN 0x010
+#define OCFB_VBARA 0x014
+#define OCFB_PALETTE 0x800
+
+#define OCFB_CTRL_VEN 0x00000001 /* Video Enable */
+#define OCFB_CTRL_HIE 0x00000002 /* HSync Interrupt Enable */
+#define OCFB_CTRL_PC 0x00000800 /* 8-bit Pseudo Color Enable*/
+#define OCFB_CTRL_CD8 0x00000000 /* Color Depth 8 */
+#define OCFB_CTRL_CD16 0x00000200 /* Color Depth 16 */
+#define OCFB_CTRL_CD24 0x00000400 /* Color Depth 24 */
+#define OCFB_CTRL_CD32 0x00000600 /* Color Depth 32 */
+#define OCFB_CTRL_VBL1 0x00000000 /* Burst Length 1 */
+#define OCFB_CTRL_VBL2 0x00000080 /* Burst Length 2 */
+#define OCFB_CTRL_VBL4 0x00000100 /* Burst Length 4 */
+#define OCFB_CTRL_VBL8 0x00000180 /* Burst Length 8 */
+
+#define PALETTE_SIZE 256
+
+#define OCFB_NAME "OC VGA/LCD"
+
+static char *mode_option;
+
+static const struct fb_videomode default_mode = {
+ /* 640x480 @ 60 Hz, 31.5 kHz hsync */
+ NULL, 60, 640, 480, 39721, 40, 24, 32, 11, 96, 2,
+ 0, FB_VMODE_NONINTERLACED
+};
+
+struct ocfb_dev {
+ struct fb_info info;
+ void __iomem *regs;
+ /* flag indicating whether the regs are little endian accessed */
+ int little_endian;
+ /* Physical and virtual addresses of framebuffer */
+ phys_addr_t fb_phys;
+ void __iomem *fb_virt;
+ u32 pseudo_palette[PALETTE_SIZE];
+};
+
+#ifndef MODULE
+static int __init ocfb_setup(char *options)
+{
+ char *curr_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((curr_opt = strsep(&options, ",")) != NULL) {
+ if (!*curr_opt)
+ continue;
+ mode_option = curr_opt;
+ }
+
+ return 0;
+}
+#endif
+
+static inline u32 ocfb_readreg(struct ocfb_dev *fbdev, loff_t offset)
+{
+ if (fbdev->little_endian)
+ return ioread32(fbdev->regs + offset);
+ else
+ return ioread32be(fbdev->regs + offset);
+}
+
+static void ocfb_writereg(struct ocfb_dev *fbdev, loff_t offset, u32 data)
+{
+ if (fbdev->little_endian)
+ iowrite32(data, fbdev->regs + offset);
+ else
+ iowrite32be(data, fbdev->regs + offset);
+}
+
+static int ocfb_setupfb(struct ocfb_dev *fbdev)
+{
+ unsigned long bpp_config;
+ struct fb_var_screeninfo *var = &fbdev->info.var;
+ struct device *dev = fbdev->info.device;
+ u32 hlen;
+ u32 vlen;
+
+ /* Disable display */
+ ocfb_writereg(fbdev, OCFB_CTRL, 0);
+
+ /* Register framebuffer address */
+ fbdev->little_endian = 0;
+ ocfb_writereg(fbdev, OCFB_VBARA, fbdev->fb_phys);
+
+ /* Detect endianess */
+ if (ocfb_readreg(fbdev, OCFB_VBARA) != fbdev->fb_phys) {
+ fbdev->little_endian = 1;
+ ocfb_writereg(fbdev, OCFB_VBARA, fbdev->fb_phys);
+ }
+
+ /* Horizontal timings */
+ ocfb_writereg(fbdev, OCFB_HTIM, (var->hsync_len - 1) << 24 |
+ (var->right_margin - 1) << 16 | (var->xres - 1));
+
+ /* Vertical timings */
+ ocfb_writereg(fbdev, OCFB_VTIM, (var->vsync_len - 1) << 24 |
+ (var->lower_margin - 1) << 16 | (var->yres - 1));
+
+ /* Total length of frame */
+ hlen = var->left_margin + var->right_margin + var->hsync_len +
+ var->xres;
+
+ vlen = var->upper_margin + var->lower_margin + var->vsync_len +
+ var->yres;
+
+ ocfb_writereg(fbdev, OCFB_HVLEN, (hlen - 1) << 16 | (vlen - 1));
+
+ bpp_config = OCFB_CTRL_CD8;
+ switch (var->bits_per_pixel) {
+ case 8:
+ if (!var->grayscale)
+ bpp_config |= OCFB_CTRL_PC; /* enable palette */
+ break;
+
+ case 16:
+ bpp_config |= OCFB_CTRL_CD16;
+ break;
+
+ case 24:
+ bpp_config |= OCFB_CTRL_CD24;
+ break;
+
+ case 32:
+ bpp_config |= OCFB_CTRL_CD32;
+ break;
+
+ default:
+ dev_err(dev, "no bpp specified\n");
+ break;
+ }
+
+ /* maximum (8) VBL (video memory burst length) */
+ bpp_config |= OCFB_CTRL_VBL8;
+
+ /* Enable output */
+ ocfb_writereg(fbdev, OCFB_CTRL, (OCFB_CTRL_VEN | bpp_config));
+
+ return 0;
+}
+
+static int ocfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ struct ocfb_dev *fbdev = (struct ocfb_dev *)info->par;
+ u32 color;
+
+ if (regno >= info->cmap.len) {
+ dev_err(info->device, "regno >= cmap.len\n");
+ return 1;
+ }
+
+ if (info->var.grayscale) {
+ /* grayscale = 0.30*R + 0.59*G + 0.11*B */
+ red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
+ }
+
+ red >>= (16 - info->var.red.length);
+ green >>= (16 - info->var.green.length);
+ blue >>= (16 - info->var.blue.length);
+ transp >>= (16 - info->var.transp.length);
+
+ if (info->var.bits_per_pixel = 8 && !info->var.grayscale) {
+ regno <<= 2;
+ color = (red << 16) | (green << 8) | blue;
+ ocfb_writereg(fbdev, OCFB_PALETTE + regno, color);
+ } else {
+ ((u32 *)(info->pseudo_palette))[regno] + (red << info->var.red.offset) |
+ (green << info->var.green.offset) |
+ (blue << info->var.blue.offset) |
+ (transp << info->var.transp.offset);
+ }
+
+ return 0;
+}
+
+static int ocfb_init_fix(struct ocfb_dev *fbdev)
+{
+ struct fb_var_screeninfo *var = &fbdev->info.var;
+ struct fb_fix_screeninfo *fix = &fbdev->info.fix;
+
+ strcpy(fix->id, OCFB_NAME);
+
+ fix->line_length = var->xres * var->bits_per_pixel/8;
+ fix->smem_len = fix->line_length * var->yres;
+ fix->type = FB_TYPE_PACKED_PIXELS;
+
+ if (var->bits_per_pixel = 8 && !var->grayscale)
+ fix->visual = FB_VISUAL_PSEUDOCOLOR;
+ else
+ fix->visual = FB_VISUAL_TRUECOLOR;
+
+ return 0;
+}
+
+static int ocfb_init_var(struct ocfb_dev *fbdev)
+{
+ struct fb_var_screeninfo *var = &fbdev->info.var;
+
+ var->accel_flags = FB_ACCEL_NONE;
+ var->activate = FB_ACTIVATE_NOW;
+ var->xres_virtual = var->xres;
+ var->yres_virtual = var->yres;
+
+ switch (var->bits_per_pixel) {
+ case 8:
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ var->red.offset = 0;
+ var->red.length = 8;
+ var->green.offset = 0;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ break;
+
+ case 16:
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->blue.offset = 0;
+ var->blue.length = 5;
+ break;
+
+ case 24:
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ break;
+
+ case 32:
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ break;
+ }
+
+ return 0;
+}
+
+static struct fb_ops ocfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_setcolreg = ocfb_setcolreg,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static int ocfb_probe(struct platform_device *pdev)
+{
+ int ret = 0;
+ struct ocfb_dev *fbdev;
+ struct resource *res;
+ int fbsize;
+
+ fbdev = devm_kzalloc(&pdev->dev, sizeof(*fbdev), GFP_KERNEL);
+ if (!fbdev)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, fbdev);
+
+ fbdev->info.fbops = &ocfb_ops;
+ fbdev->info.device = &pdev->dev;
+ fbdev->info.par = fbdev;
+
+ /* Video mode setup */
+ if (!fb_find_mode(&fbdev->info.var, &fbdev->info, mode_option,
+ NULL, 0, &default_mode, 16)) {
+ dev_err(&pdev->dev, "No valid video modes found\n");
+ return -EINVAL;
+ }
+ ocfb_init_var(fbdev);
+ ocfb_init_fix(fbdev);
+
+ /* Request I/O resource */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "I/O resource request failed\n");
+ return -ENXIO;
+ }
+ res->flags &= ~IORESOURCE_CACHEABLE;
+ fbdev->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(fbdev->regs))
+ return PTR_ERR(fbdev->regs);
+
+ /* Allocate framebuffer memory */
+ fbsize = fbdev->info.fix.smem_len;
+ fbdev->fb_virt = dma_alloc_coherent(&pdev->dev, PAGE_ALIGN(fbsize),
+ &fbdev->fb_phys, GFP_KERNEL);
+ if (!fbdev->fb_virt) {
+ dev_err(&pdev->dev,
+ "Frame buffer memory allocation failed\n");
+ return -ENOMEM;
+ }
+ fbdev->info.fix.smem_start = fbdev->fb_phys;
+ fbdev->info.screen_base = (void __iomem *)fbdev->fb_virt;
+ fbdev->info.pseudo_palette = fbdev->pseudo_palette;
+
+ /* Clear framebuffer */
+ memset_io((void __iomem *)fbdev->fb_virt, 0, fbsize);
+
+ /* Setup and enable the framebuffer */
+ ocfb_setupfb(fbdev);
+
+ if (fbdev->little_endian)
+ fbdev->info.flags |= FBINFO_FOREIGN_ENDIAN;
+
+ /* Allocate color map */
+ ret = fb_alloc_cmap(&fbdev->info.cmap, PALETTE_SIZE, 0);
+ if (ret) {
+ dev_err(&pdev->dev, "Color map allocation failed\n");
+ goto err_dma_free;
+ }
+
+ /* Register framebuffer */
+ ret = register_framebuffer(&fbdev->info);
+ if (ret) {
+ dev_err(&pdev->dev, "Framebuffer registration failed\n");
+ goto err_dealloc_cmap;
+ }
+
+ return 0;
+
+err_dealloc_cmap:
+ fb_dealloc_cmap(&fbdev->info.cmap);
+
+err_dma_free:
+ dma_free_coherent(&pdev->dev, PAGE_ALIGN(fbsize), fbdev->fb_virt,
+ fbdev->fb_phys);
+
+ return ret;
+}
+
+static int ocfb_remove(struct platform_device *pdev)
+{
+ struct ocfb_dev *fbdev = platform_get_drvdata(pdev);
+
+ unregister_framebuffer(&fbdev->info);
+ fb_dealloc_cmap(&fbdev->info.cmap);
+ dma_free_coherent(&pdev->dev, PAGE_ALIGN(fbdev->info.fix.smem_len),
+ fbdev->fb_virt, fbdev->fb_phys);
+
+ /* Disable display */
+ ocfb_writereg(fbdev, OCFB_CTRL, 0);
+
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static struct of_device_id ocfb_match[] = {
+ { .compatible = "opencores,ocfb", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ocfb_match);
+
+static struct platform_driver ocfb_driver = {
+ .probe = ocfb_probe,
+ .remove = ocfb_remove,
+ .driver = {
+ .name = "ocfb_fb",
+ .of_match_table = ocfb_match,
+ }
+};
+
+/*
+ * Init and exit routines
+ */
+static int __init ocfb_init(void)
+{
+#ifndef MODULE
+ char *option = NULL;
+
+ if (fb_get_options("ocfb", &option))
+ return -ENODEV;
+ ocfb_setup(option);
+#endif
+ return platform_driver_register(&ocfb_driver);
+}
+
+static void __exit ocfb_exit(void)
+{
+ platform_driver_unregister(&ocfb_driver);
+}
+
+module_init(ocfb_init);
+module_exit(ocfb_exit);
+
+MODULE_AUTHOR("Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>");
+MODULE_DESCRIPTION("OpenCores VGA/LCD 2.0 frame buffer driver");
+MODULE_LICENSE("GPL v2");
+module_param(mode_option, charp, 0);
+MODULE_PARM_DESC(mode_option, "Video mode ('<xres>x<yres>[-<bpp>][@refresh]')");
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2014-01-11 9:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Aaro Koskinen
In-Reply-To: <52CFD1ED.7010302@ti.com>
On 10.01.2014 12:56, Tomi Valkeinen wrote:
> On 2014-01-05 15:13, Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>>
>> Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
>> unlock in acx565akm_enable but introduces another problem - if
>> acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
>> that by unlocking the mutex on early return. Also add mutex protection in
>> acx565akm_panel_power_off and remove an unused variable
>>
>
> I think this is just getting more messy. How about we more or less revert the c37dd677988ca50bc8bc60ab5ab053720583c168 and fix it like this:
>
I am fine with whatever patch you may come with, as long as it fixes the
issue.
>
> diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
> index 714ee92dfb9f..8e97d06921ff 100644
> --- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
> +++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
The patch does not apply cleanly on top of rc7, however I applied it by
hand. So far it seems it fixes the issue brought by
c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
mutex_lock/mutex_unlock are complementary in every code path (at least
not explicitly, I guess maemo is doing it for us anyway :) ).
So, shall I send a patch incorporating your code changes, or you will do it?
Regards,
Ivo
^ permalink raw reply
* [PATCH] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
From: Ivaylo Dimitrov @ 2014-01-11 12:42 UTC (permalink / raw)
To: tomi.valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Ivaylo Dimitrov
From: Ivaylo Dimitrov <freemangordon@abv.bg>
commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle
synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
on OMAP3. However, it misses the logic found in Nokia kernels that is
needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
well as the logic to fallback to 3 taps if 5 taps clock results in too
tight horizontal timings. Without that patch "horizontal timing too tight"
errors are seen when a video with resolution above 640x350 is tried to be
played. The patch is a forward-ported logic found in Nokia N900 and N9/50
kernels.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
---
drivers/video/omap2/dss/dispc.c | 36 +++++++++++++++++++++++++-----------
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 67e413e..9d1aa25 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1999,7 +1999,8 @@ static void calc_tiler_rotation_offset(u16 screen_width, u16 width,
*/
static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *t, u16 pos_x,
- u16 width, u16 height, u16 out_width, u16 out_height)
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ bool five_taps)
{
const int ds = DIV_ROUND_UP(height, out_height);
unsigned long nonactive;
@@ -2019,6 +2020,10 @@ static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
if (blank <= limits[i])
return -EINVAL;
+ /* FIXME add checks for 3-tap filter once the limitations are known */
+ if (!five_taps)
+ return 0;
+
/*
* Pixel data should be prepared before visible display point starts.
* So, atleast DS-2 lines must have already been fetched by DISPC
@@ -2191,24 +2196,33 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk,
const int maxsinglelinewidth dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ *five_taps = height > out_height;
+
do {
in_height = DIV_ROUND_UP(height, *decim_y);
in_width = DIV_ROUND_UP(width, *decim_x);
- *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
- in_width, in_height, out_width, out_height, color_mode);
-
- error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
- pos_x, in_width, in_height, out_width,
- out_height);
if (in_width > maxsinglelinewidth)
if (in_height > out_height &&
in_height < out_height * 2)
*five_taps = false;
- if (!*five_taps)
+again:
+ if (*five_taps)
+ *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
+ in_width, in_height, out_width,
+ out_height, color_mode);
+ else
*core_clk = dispc.feat->calc_core_clk(pclk, in_width,
- in_height, out_width, out_height,
- mem_to_mem);
+ in_height, out_width, out_height,
+ mem_to_mem);
+
+ error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
+ pos_x, in_width, in_height, out_width,
+ out_height, *five_taps);
+ if (error && *five_taps) {
+ *five_taps = false;
+ goto again;
+ }
error = (error || in_width > maxsinglelinewidth * 2 ||
(in_width > maxsinglelinewidth && *five_taps) ||
@@ -2226,7 +2240,7 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk,
} while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error);
if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width,
- height, out_width, out_height)){
+ height, out_width, out_height, *five_taps)) {
DSSERR("horizontal timing too tight\n");
return -EINVAL;
}
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Ivaylo Dimitrov @ 2014-01-11 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDB141E@DBDE04.ent.ti.com>
On 09.01.2014 10:08, Hiremath, Vaibhav wrote:
>
> No, that's what is causing issue to me. Can you try predefined address flow?
>
> Thanks,
> Vaibhav
>
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.13.0-rc7+ (maemo@maemo-desktop) (gcc version 4.7.2
20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11
17:06:39 EET 2014
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr\x10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Nokia RX-51 board
omapfb: reserved 0x00800000 bytes at 0x8f100000
Memory policy: Data cache writeback
On node 0 totalpages: 61696
free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000
Normal zone: 512 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 61696 pages, LIFO batch:15
CPU: All CPU(s) started in SVC mode.
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 61184
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw
mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M@0x8F100000
omapfb.mode=lcd:848x480-16
There are no (UNDERFLOW) errors on OMAP3 when predefined address is
used, I am still able to play every video I try.
Ivo
^ permalink raw reply
* Re: FOSDEM14: Graphics DevRoom: Deadline approaching fast.
From: Luc Verhaegen @ 2014-01-11 15:09 UTC (permalink / raw)
To: mesa-dev, xorg-devel, dri-devel, xorg, wayland-devel,
xorg-announce, mir-devel, directfb-dev, linux-fbdev, linux-media
In-Reply-To: <20140107012200.GA3446@skynet.be>
On Tue, Jan 07, 2014 at 02:22:00AM +0100, Luc Verhaegen wrote:
> Hi,
>
> There are still 5 slots open for the FOSDEM graphics DevRoom, and the
> deadline is this friday, the 10th. Get a move on.
>
> If you have requested an account reset with me before, but if you then
> haven't bothered filing a talk, you do NOT have a slot. Please file a
> talk ASAP to still secure a place.
>
> For more information on how to file for a devroom, read the email sent
> back in october:
> http://lists.x.org/archives/xorg-devel/2013-October/038185.html
>
> Luc Verhaegen.
There are still 3 slots open. This is your final chance to get a talk in
the FOSDEM 2014 graphics DevRoom.
Monday night (13th), the schedule will be locked down and no further
talks or events will be accepted.
Luc Verhaegen.
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Jingoo Han @ 2014-01-13 1:24 UTC (permalink / raw)
To: 'Stefan Kristiansson'
Cc: 'Tomi Valkeinen',
'Jean-Christophe Plagniol-Villard', linux-kernel,
linux-fbdev, 'Jingoo Han'
In-Reply-To: <1389384793-4710-1-git-send-email-stefan.kristiansson@saunalahti.fi>
On Saturday, January 11, 2014 5:13 AM, Stefan Kristiansson wrote:
>
> This adds support for the VGA/LCD core available from OpenCores:
> http://opencores.org/project,vga_lcd
>
> The driver have been tested together with both OpenRISC and
> ARM (socfpga) processors.
>
> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> ---
> Changes in v2:
> - Add Microblaze as an example user and fix a typo in Xilinx Zynq
>
> Changes in v3:
> - Use devm_kzalloc instead of kzalloc
> - Remove superflous MODULE #ifdef
>
> Changes in v4:
> - Remove 'default n' in Kconfig
> - Simplify ioremap/request_mem_region by using devm_ioremap_resource
> - Remove release_mem_region
>
> Changes in v5:
> - Remove static structs to support multiple devices
> ---
> drivers/video/Kconfig | 16 ++
> drivers/video/Makefile | 1 +
> drivers/video/ocfb.c | 440 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 457 insertions(+)
> create mode 100644 drivers/video/ocfb.c
It looks good.
However, I added some minor comments. :-)
Sorry for late response.
[.....]
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/mm.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/fb.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
Would you re-order these headers alphabetically?
It enhances the readability.
[.....]
> +struct ocfb_dev {
> + struct fb_info info;
> + void __iomem *regs;
> + /* flag indicating whether the regs are little endian accessed */
> + int little_endian;
> + /* Physical and virtual addresses of framebuffer */
> + phys_addr_t fb_phys;
> + void __iomem *fb_virt;
> + u32 pseudo_palette[PALETTE_SIZE];
> +};
Here, 'fb_virt' is already defined as 'void __iomem *'.
[.....]
> + fbdev->info.fix.smem_start = fbdev->fb_phys;
> + fbdev->info.screen_base = (void __iomem *)fbdev->fb_virt;
Please remove unnecessary casting as below, because 'fb_virt' is already
defined as 'void __iomem *'.
+ fbdev->info.screen_base = fbdev->fb_virt;
> + fbdev->info.pseudo_palette = fbdev->pseudo_palette;
> +
> + /* Clear framebuffer */
> + memset_io((void __iomem *)fbdev->fb_virt, 0, fbsize);
Same here.
+ memset_io(fbdev->fb_virt, 0, fbsize);
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-13 6:19 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Tomi Valkeinen',
'Jean-Christophe Plagniol-Villard', linux-kernel,
linux-fbdev
In-Reply-To: <000301cf0ffe$4054e8d0$c0feba70$%han@samsung.com>
On Mon, Jan 13, 2014 at 10:24:49AM +0900, Jingoo Han wrote:
> On Saturday, January 11, 2014 5:13 AM, Stefan Kristiansson wrote:
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/errno.h>
> > +#include <linux/string.h>
> > +#include <linux/slab.h>
> > +#include <linux/delay.h>
> > +#include <linux/mm.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/fb.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of.h>
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
>
OK
> [.....]
>
> > +struct ocfb_dev {
> > + struct fb_info info;
> > + void __iomem *regs;
> > + /* flag indicating whether the regs are little endian accessed */
> > + int little_endian;
> > + /* Physical and virtual addresses of framebuffer */
> > + phys_addr_t fb_phys;
> > + void __iomem *fb_virt;
> > + u32 pseudo_palette[PALETTE_SIZE];
> > +};
>
> Here, 'fb_virt' is already defined as 'void __iomem *'.
>
> [.....]
>
> > + fbdev->info.fix.smem_start = fbdev->fb_phys;
> > + fbdev->info.screen_base = (void __iomem *)fbdev->fb_virt;
>
> Please remove unnecessary casting as below, because 'fb_virt' is already
> defined as 'void __iomem *'.
>
> + fbdev->info.screen_base = fbdev->fb_virt;
>
> > + fbdev->info.pseudo_palette = fbdev->pseudo_palette;
> > +
> > + /* Clear framebuffer */
> > + memset_io((void __iomem *)fbdev->fb_virt, 0, fbsize);
>
> Same here.
>
> + memset_io(fbdev->fb_virt, 0, fbsize);
>
Nice catch, will do.
Stefan
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Tomi Valkeinen @ 2014-01-13 8:21 UTC (permalink / raw)
To: Stefan Kristiansson; +Cc: linux-kernel, linux-fbdev, plagnioj
In-Reply-To: <1389384793-4710-1-git-send-email-stefan.kristiansson@saunalahti.fi>
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
On 2014-01-10 22:13, Stefan Kristiansson wrote:
> This adds support for the VGA/LCD core available from OpenCores:
> http://opencores.org/project,vga_lcd
>
> The driver have been tested together with both OpenRISC and
> ARM (socfpga) processors.
>
> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> +/*
> + * Init and exit routines
> + */
> +static int __init ocfb_init(void)
> +{
> +#ifndef MODULE
> + char *option = NULL;
> +
> + if (fb_get_options("ocfb", &option))
> + return -ENODEV;
> + ocfb_setup(option);
> +#endif
> + return platform_driver_register(&ocfb_driver);
> +}
I see this is how fb_get_options is used elsewhere also, but shouldn't
fb_get_options be called with a name that's somehow device specific? I
haven't used it in omapfb, so maybe I'm missing how it is supposed to
work, but if I'm not mistaken, if you have two ocfb devices on your
board, there's no way to specify individual modes for them. Even the
Documentation/fb/modedb.txt gives an example of a "VGA-1" which sounds
to me that it has been designed to be used with some kind of device id.
Although even if the above code handled the different devices, when
loading this as a module would still not work right as that code is not
called at all in the module case. Ah, well. I guess this is legacy
stuff, and it's just the way it works.
The subject says this is a VGA/LCD driver. Usually with LCD, the LCD
video timings are passed via device tree or platform data, as there's
just one possible set of timings for a board. Is that something that
you've thought about, or is the user always supposed to give the timings
explicitly via kernel cmdline?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
From: Tomi Valkeinen @ 2014-01-13 9:43 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Archit Taneja
In-Reply-To: <1389444125-5000-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
Hi,
On 2014-01-11 14:42, Ivaylo Dimitrov wrote:
> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>
> commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle
> synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
> on OMAP3. However, it misses the logic found in Nokia kernels that is
> needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
> well as the logic to fallback to 3 taps if 5 taps clock results in too
> tight horizontal timings. Without that patch "horizontal timing too tight"
> errors are seen when a video with resolution above 640x350 is tried to be
> played. The patch is a forward-ported logic found in Nokia N900 and N9/50
> kernels.
>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
I had a quick test with this. Without the patch, on beagle-xm, my scaler
test immediately gives "horizontal timing too tight". With the patch, no
errors and the scaling seems to work. So looks good. I'll look at the
patch a bit more, but I think this is 3.14 material.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-13 10:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-kernel, linux-fbdev, plagnioj
In-Reply-To: <52D3A1FC.4090706@ti.com>
On Mon, Jan 13, 2014 at 10:21:16AM +0200, Tomi Valkeinen wrote:
> On 2014-01-10 22:13, Stefan Kristiansson wrote:
> > This adds support for the VGA/LCD core available from OpenCores:
> > http://opencores.org/project,vga_lcd
> >
> > The driver have been tested together with both OpenRISC and
> > ARM (socfpga) processors.
> >
> > Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>
> > +/*
> > + * Init and exit routines
> > + */
> > +static int __init ocfb_init(void)
> > +{
> > +#ifndef MODULE
> > + char *option = NULL;
> > +
> > + if (fb_get_options("ocfb", &option))
> > + return -ENODEV;
> > + ocfb_setup(option);
> > +#endif
> > + return platform_driver_register(&ocfb_driver);
> > +}
>
> I see this is how fb_get_options is used elsewhere also, but shouldn't
> fb_get_options be called with a name that's somehow device specific? I
> haven't used it in omapfb, so maybe I'm missing how it is supposed to
> work, but if I'm not mistaken, if you have two ocfb devices on your
> board, there's no way to specify individual modes for them. Even the
> Documentation/fb/modedb.txt gives an example of a "VGA-1" which sounds
> to me that it has been designed to be used with some kind of device id.
>
> Although even if the above code handled the different devices, when
> loading this as a module would still not work right as that code is not
> called at all in the module case. Ah, well. I guess this is legacy
> stuff, and it's just the way it works.
>
Yes, I can't really figure out how that would be handled neither.
> The subject says this is a VGA/LCD driver. Usually with LCD, the LCD
> video timings are passed via device tree or platform data, as there's
> just one possible set of timings for a board. Is that something that
> you've thought about, or is the user always supposed to give the timings
> explicitly via kernel cmdline?
>
The VGA/LCD in the subject comes from the name of the core,
the core itself presents a "vga-type" interface, but it can basically
be hooked up to any type of display (with a bit of glue-logic in some cases).
That said - the reason why I went for the mode_options solution in the
first place, is that when I initially wrote this driver
(>2 years ago, time flies...) the display-timing device-tree bindings weren't
invented yet, so it seemed like the most viable option without coming up
with custom device-tree bindings.
It's completely possible that this design choice should be revised now,
and I wouldn't mind converting this driver to make use of the display-timing
dt properties if you think that's a good idea?
Stefan
^ permalink raw reply
* Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Tomi Valkeinen @ 2014-01-13 10:20 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Aaro Koskinen
In-Reply-To: <52D1113C.8020807@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
On 2014-01-11 11:39, Ivaylo Dimitrov wrote:
> The patch does not apply cleanly on top of rc7, however I applied it by
> hand. So far it seems it fixes the issue brought by
> c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
> mutex_lock/mutex_unlock are complementary in every code path (at least
> not explicitly, I guess maemo is doing it for us anyway :) ).
Ok, thanks.
> So, shall I send a patch incorporating your code changes, or you will do
> it?
I can handle it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Tomi Valkeinen @ 2014-01-13 10:43 UTC (permalink / raw)
To: Stefan Kristiansson; +Cc: linux-kernel, linux-fbdev, plagnioj
In-Reply-To: <20140113102006.GA30877@chokladfabriken.org>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
On 2014-01-13 12:20, Stefan Kristiansson wrote:
> The VGA/LCD in the subject comes from the name of the core,
> the core itself presents a "vga-type" interface, but it can basically
> be hooked up to any type of display (with a bit of glue-logic in some cases).
>
> That said - the reason why I went for the mode_options solution in the
> first place, is that when I initially wrote this driver
> (>2 years ago, time flies...) the display-timing device-tree bindings weren't
> invented yet, so it seemed like the most viable option without coming up
> with custom device-tree bindings.
>
> It's completely possible that this design choice should be revised now,
> and I wouldn't mind converting this driver to make use of the display-timing
> dt properties if you think that's a good idea?
I don't have a strong opinion on this. It looks to me that even if the
current driver is merged, it would be easy to add device tree
display-timing later, and still keep full backward compatibility.
Then again, you already have DT support in the driver, and if it's clear
that the DT based videomode selection is better, then I'd just go
straight to that one without intermediate steps.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Geert Uytterhoeven @ 2014-01-13 10:54 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Stefan Kristiansson, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <52D3C36E.9020107@ti.com>
On Mon, Jan 13, 2014 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2014-01-13 12:20, Stefan Kristiansson wrote:
>> The VGA/LCD in the subject comes from the name of the core,
>> the core itself presents a "vga-type" interface, but it can basically
>> be hooked up to any type of display (with a bit of glue-logic in some cases).
>>
>> That said - the reason why I went for the mode_options solution in the
>> first place, is that when I initially wrote this driver
>> (>2 years ago, time flies...) the display-timing device-tree bindings weren't
>> invented yet, so it seemed like the most viable option without coming up
>> with custom device-tree bindings.
>>
>> It's completely possible that this design choice should be revised now,
>> and I wouldn't mind converting this driver to make use of the display-timing
>> dt properties if you think that's a good idea?
>
> I don't have a strong opinion on this. It looks to me that even if the
> current driver is merged, it would be easy to add device tree
> display-timing later, and still keep full backward compatibility.
>
> Then again, you already have DT support in the driver, and if it's clear
> that the DT based videomode selection is better, then I'd just go
> straight to that one without intermediate steps.
With a VGA connector, it's handy to be able to specify the video mode on
the kernel command line, instead of having to put it in the DT.
With hardwired LCDs with fixed timing, it's different.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
From: Archit Taneja @ 2014-01-13 10:58 UTC (permalink / raw)
To: Ivaylo Dimitrov, tomi.valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <1389444125-5000-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Hi,
On Saturday 11 January 2014 06:12 PM, Ivaylo Dimitrov wrote:
> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>
> commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle
> synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
> on OMAP3. However, it misses the logic found in Nokia kernels that is
> needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
> well as the logic to fallback to 3 taps if 5 taps clock results in too
> tight horizontal timings. Without that patch "horizontal timing too tight"
> errors are seen when a video with resolution above 640x350 is tried to be
> played. The patch is a forward-ported logic found in Nokia N900 and N9/50
> kernels.
>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> ---
> drivers/video/omap2/dss/dispc.c | 36 +++++++++++++++++++++++++-----------
> 1 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 67e413e..9d1aa25 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1999,7 +1999,8 @@ static void calc_tiler_rotation_offset(u16 screen_width, u16 width,
> */
> static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
> const struct omap_video_timings *t, u16 pos_x,
> - u16 width, u16 height, u16 out_width, u16 out_height)
> + u16 width, u16 height, u16 out_width, u16 out_height,
> + bool five_taps)
> {
> const int ds = DIV_ROUND_UP(height, out_height);
> unsigned long nonactive;
> @@ -2019,6 +2020,10 @@ static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
> if (blank <= limits[i])
> return -EINVAL;
>
> + /* FIXME add checks for 3-tap filter once the limitations are known */
> + if (!five_taps)
> + return 0;
> +
> /*
> * Pixel data should be prepared before visible display point starts.
> * So, atleast DS-2 lines must have already been fetched by DISPC
> @@ -2191,24 +2196,33 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk,
> const int maxsinglelinewidth > dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
>
> + *five_taps = height > out_height;
> +
We should consider the decimated height when calculating the five taps.
I suggest the change below:
> do {
> in_height = DIV_ROUND_UP(height, *decim_y);
> in_width = DIV_ROUND_UP(width, *decim_x);
> - *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
> - in_width, in_height, out_width, out_height, color_mode);
> -
> - error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
> - pos_x, in_width, in_height, out_width,
> - out_height);
>
set "*five_taps = in_height > out_height;" here. The rest of the code
remains the same.
> if (in_width > maxsinglelinewidth)
> if (in_height > out_height &&
> in_height < out_height * 2)
> *five_taps = false;
> - if (!*five_taps)
> +again:
> + if (*five_taps)
> + *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
> + in_width, in_height, out_width,
> + out_height, color_mode);
> + else
> *core_clk = dispc.feat->calc_core_clk(pclk, in_width,
> - in_height, out_width, out_height,
> - mem_to_mem);
> + in_height, out_width, out_height,
> + mem_to_mem);
> +
> + error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
> + pos_x, in_width, in_height, out_width,
> + out_height, *five_taps);
> + if (error && *five_taps) {
> + *five_taps = false;
> + goto again;
> + }
>
> error = (error || in_width > maxsinglelinewidth * 2 ||
> (in_width > maxsinglelinewidth && *five_taps) ||
> @@ -2226,7 +2240,7 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk,
> } while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error);
>
> if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width,
> - height, out_width, out_height)){
> + height, out_width, out_height, *five_taps)) {
> DSSERR("horizontal timing too tight\n");
> return -EINVAL;
> }
>
Thanks,
Archit
^ permalink raw reply
* Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-13 11:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Tomi Valkeinen, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <CAMuHMdU0AU80HqxOx_hhX8dP9xrJoNO+UhAZ=Ov4y64Hs7y5rw@mail.gmail.com>
On Mon, Jan 13, 2014 at 11:54:30AM +0100, Geert Uytterhoeven wrote:
> On Mon, Jan 13, 2014 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 2014-01-13 12:20, Stefan Kristiansson wrote:
OB> >> The VGA/LCD in the subject comes from the name of the core,
> >> the core itself presents a "vga-type" interface, but it can basically
> >> be hooked up to any type of display (with a bit of glue-logic in some cases).
> >>
> >> That said - the reason why I went for the mode_options solution in the
> >> first place, is that when I initially wrote this driver
> >> (>2 years ago, time flies...) the display-timing device-tree bindings weren't
> >> invented yet, so it seemed like the most viable option without coming up
> >> with custom device-tree bindings.
> >>
> >> It's completely possible that this design choice should be revised now,
> >> and I wouldn't mind converting this driver to make use of the display-timing
> >> dt properties if you think that's a good idea?
> >
> > I don't have a strong opinion on this. It looks to me that even if the
> > current driver is merged, it would be easy to add device tree
> > display-timing later, and still keep full backward compatibility.
> >
> > Then again, you already have DT support in the driver, and if it's clear
> > that the DT based videomode selection is better, then I'd just go
> > straight to that one without intermediate steps.
>
> With a VGA connector, it's handy to be able to specify the video mode on
> the kernel command line, instead of having to put it in the DT.
>
> With hardwired LCDs with fixed timing, it's different.
>
Right, so either way, we probably want to keep the kernel command line option.
I think the main motivation for switching to the dt based video mode
selection at this stage would be to avoid having the kernel command line
option around, so I think I would like to move forward with the current
implementation with the possibility to improve it with display-timing bindings
later on.
Stefan
^ 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