* 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
* [PATCH 0/4] delete useless variable
From: Julia Lawall @ 2014-01-13 15:22 UTC (permalink / raw)
To: brcm80211-dev-list
Cc: kernel-janitors, linux-wireless, netdev, linux-kernel,
linux-fbdev, devel
These patches delete declarations and initializations of variables that are
only assigned to constants but never used otherwise.
The complete semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
type T;
identifier i,i2;
position p;
@@
T i@p;
...
i = i2
@@
type r.T;
identifier r.i;
constant c;
position p != r.p;
@@
-T i@p;
<... when != i
-i = c;
...>
// </smpl>
^ permalink raw reply
* [PATCH 2/4] i810: delete useless variable
From: Julia Lawall @ 2014-01-13 15:22 UTC (permalink / raw)
To: Antonino Daplas
Cc: kernel-janitors, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
In-Reply-To: <1389629847-5330-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Delete a variable that is at most only assigned to a constant, but never
used otherwise.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
type T;
identifier i;
constant c;
@@
-T i;
<... when != i
-i = c;
...>
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/i810/i810_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
index 038192a..bb674e4 100644
--- a/drivers/video/i810/i810_main.c
+++ b/drivers/video/i810/i810_main.c
@@ -2011,9 +2011,7 @@ static int i810fb_init_pci(struct pci_dev *dev,
struct fb_info *info;
struct i810fb_par *par = NULL;
struct fb_videomode mode;
- int i, err = -1, vfreq, hfreq, pixclock;
-
- i = 0;
+ int err = -1, vfreq, hfreq, pixclock;
info = framebuffer_alloc(sizeof(struct i810fb_par), &dev->dev);
if (!info)
^ permalink raw reply related
* [PATCH v2] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
From: Ivaylo Dimitrov @ 2014-01-13 16:33 UTC (permalink / raw)
To: tomi.valkeinen
Cc: archit, plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Ivaylo Dimitrov
In-Reply-To: <52D3C3EB.6000104@ti.com>
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 | 31 ++++++++++++++++++++++---------
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 67e413e..66e0849 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
@@ -2194,22 +2199,30 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk,
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);
+ *five_taps = in_height > 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);
+ 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) ||
!*core_clk || *core_clk > dispc_core_clk_rate());
@@ -2226,7 +2239,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
* [PATCH v6] video: add OpenCores VGA/LCD framebuffer driver
From: Stefan Kristiansson @ 2014-01-13 19:38 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 superfluous 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
Changes in v6
- Reorganize header files in alphabetical order
- Remove superfluous casts to (void __iomem *)
---
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..7f9dc9b
--- /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/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+#include <linux/slab.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 = fbdev->fb_virt;
+ fbdev->info.pseudo_palette = fbdev->pseudo_palette;
+
+ /* Clear framebuffer */
+ memset_io(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
* [PATCH] hyperv_fb: Add screen refresh after pause/resume operation
From: Haiyang Zhang @ 2014-01-13 23:38 UTC (permalink / raw)
To: FlorianSchandinat, akpm, linux-fbdev
Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
This is necessary because after VM is pause/resumed, some portion of
the screen may need refresh.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/video/hyperv_fb.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 130708f..bbcc8c0 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -218,6 +218,7 @@ struct hvfb_par {
struct delayed_work dwork;
bool update;
+ bool xrefresh;
u32 pseudo_palette[16];
u8 init_buf[MAX_VMBUS_PKT_SIZE];
@@ -369,7 +370,7 @@ static void synthvid_recv_sub(struct hv_device *hdev)
synthvid_send_situ(hdev);
}
- par->update = msg->feature_chg.is_dirt_needed;
+ par->xrefresh = par->update = msg->feature_chg.is_dirt_needed;
if (par->update)
schedule_delayed_work(&par->dwork, HVFB_UPDATE_DELAY);
}
@@ -522,6 +523,13 @@ static void hvfb_update_work(struct work_struct *w)
{
struct hvfb_par *par = container_of(w, struct hvfb_par, dwork.work);
struct fb_info *info = par->info;
+ char *argv[] = {"/usr/bin/xrefresh", "-display", ":0.0", NULL};
+ char *envp[] = {"HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
+
+ if (par->xrefresh) {
+ par->xrefresh = false;
+ call_usermodehelper(argv[0], argv, envp, UMH_NO_WAIT);
+ }
if (par->fb_ready)
synthvid_update(info);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v6] video: add OpenCores VGA/LCD framebuffer driver
From: Tomi Valkeinen @ 2014-01-14 8:04 UTC (permalink / raw)
To: Stefan Kristiansson; +Cc: linux-kernel, linux-fbdev, plagnioj
In-Reply-To: <1389641890-2679-1-git-send-email-stefan.kristiansson@saunalahti.fi>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On 2014-01-13 21:38, 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>
I'll queue this for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] i810: delete useless variable
From: Tomi Valkeinen @ 2014-01-14 8:06 UTC (permalink / raw)
To: Julia Lawall
Cc: Antonino Daplas, kernel-janitors,
Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <1389629847-5330-3-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
On 2014-01-13 18:17, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Delete a variable that is at most only assigned to a constant, but never
> used otherwise.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> type T;
> identifier i;
> constant c;
> @@
>
> -T i;
> <... when != i
> -i = c;
> ...>
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/i810/i810_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
> index 038192a..bb674e4 100644
> --- a/drivers/video/i810/i810_main.c
> +++ b/drivers/video/i810/i810_main.c
> @@ -2011,9 +2011,7 @@ static int i810fb_init_pci(struct pci_dev *dev,
> struct fb_info *info;
> struct i810fb_par *par = NULL;
> struct fb_videomode mode;
> - int i, err = -1, vfreq, hfreq, pixclock;
> -
> - i = 0;
> + int err = -1, vfreq, hfreq, pixclock;
>
> info = framebuffer_alloc(sizeof(struct i810fb_par), &dev->dev);
> if (!info)
>
Thanks, queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
From: Tomi Valkeinen @ 2014-01-14 8:11 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: archit, plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <1389630782-1764-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On 2014-01-13 18:33, 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>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH v2 0/4] video: mmp: add device tree suppport
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
This patch set is to add device tree support for mmp_disp.
patch 1/2 are to remove clk_name configure in mach_info before.
patch 3/4 are to add device tree support.
change of v2:
add patch to remove config of clk_name in mach_info
use phandle to get path.
runtime decision of dt usage.
clean up to use node name directly.
Zhou Zhu (4):
arm: mmp: remove not used disp clk_name in ttc_dkb
video: mmp: no need to get clk_name from mach_info
video: mmp: add devm_mmp_get_path_by_phandle for DT
video: mmp: add device tree support
Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
arch/arm/mach-mmp/ttc_dkb.c | 1 -
drivers/video/mmp/core.c | 35 +++++
drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
drivers/video/mmp/hw/mmp_ctrl.c | 154 ++++++++++++++++-----
include/video/mmp_disp.h | 3 +-
6 files changed, 268 insertions(+), 58 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/4] arm: mmp: remove not used disp clk_name in ttc_dkb
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
remove clk_name of mmp_disp mach_info in ttc_dkb.
This field is not used by driver now.
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
arch/arm/mach-mmp/ttc_dkb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index cfadd97..9437166 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -204,7 +204,6 @@ static struct mmp_mach_path_config dkb_disp_config[] = {
static struct mmp_mach_plat_info dkb_disp_info = {
.name = "mmp-disp",
- .clk_name = "disp0",
.path_num = 1,
.paths = dkb_disp_config,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/4] video: mmp: no need to get clk_name from mach_info
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
As the display controller has only one clock, no need to
get clk_name from mach_info
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
drivers/video/mmp/hw/mmp_ctrl.c | 4 ++--
include/video/mmp_disp.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 8621a9f..b65913e 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -521,9 +521,9 @@ static int mmphw_probe(struct platform_device *pdev)
}
/* get clock */
- ctrl->clk = devm_clk_get(ctrl->dev, mi->clk_name);
+ ctrl->clk = devm_clk_get(ctrl->dev, NULL);
if (IS_ERR(ctrl->clk)) {
- dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
+ dev_err(ctrl->dev, "unable to get clk for %s\n", ctrl->name);
ret = -ENOENT;
goto failed;
}
diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
index 9fd9398..05a3a60 100644
--- a/include/video/mmp_disp.h
+++ b/include/video/mmp_disp.h
@@ -344,7 +344,6 @@ struct mmp_mach_path_config {
struct mmp_mach_plat_info {
const char *name;
- const char *clk_name;
int path_num;
struct mmp_mach_path_config *paths;
};
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox