Hi,
On 2012-11-20 17:54, Steffen Trumtrar wrote:
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Every timing parameter can be specified as a single value or a range
min typ max.
Also, add
On 2012-11-20 17:54, Steffen Trumtrar wrote:
+timings subnode
+---
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical
On 2012-11-20 17:54, Steffen Trumtrar wrote:
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..920cbe3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,7 @@
#include linux/backlight.h
#include linux/slab.h
#include asm/io.h
+#include
On 2012-11-20 17:54, Steffen Trumtrar wrote:
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry
On 2012-11-20 17:54, Steffen Trumtrar wrote:
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry
On 2012-11-20 17:54, Steffen Trumtrar wrote:
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by:
On 2012-11-21 18:11, Steffen Trumtrar wrote:
Hi,
On Wed, Nov 21, 2012 at 01:37:08PM +0200, Tomi Valkeinen wrote:
+#include linux/types.h
What is this needed for? u32? I don't see it defined in types.h
Yes, u32. What would be the right header for that if not types.h?
Yes, it looks like
On 2012-11-21 18:24, Steffen Trumtrar wrote:
On Wed, Nov 21, 2012 at 02:49:30PM +0200, Tomi Valkeinen wrote:
@@ -715,6 +717,11 @@ extern void fb_destroy_modedb(struct fb_videomode
*modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int
rb);
extern unsigned char
Hi Vaibhav,
I'd like to get clarity on the omap_vout maintenance. You've been the
maintainer of omap_vout, but you have lately been quite inactive in this
role, and getting omap_vout patches merged has not been as fluent as it
could be.
Do you still want to continue in this role? Will you have
as this cpu_is_* removal, and I don't have much knowledge of
the omap_vout driver.
Compiled, but not tested.
Tomi
Tomi Valkeinen (2):
[media] omap_vout: use omapdss's version instead of cpu_is_*
[media] omap_vout: remove extra include
drivers/media/platform/omap/omap_vout.c|4
On 2012-10-31 15:13, Laurent Pinchart wrote:
OMAP SoC
So here's first the SoC specific display nodes. OMAP has a DSS (display
subsystem) block, which contains the following elements:
- DISPC (display controller) reads the pixels from memory and outputs
them using specified video
On 2012-03-09 10:03, Hiremath, Vaibhav wrote:
On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
Hi Archit,
On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info() when the physical address for the
Hi,
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
.../devicetree/bindings/video/display-timings.txt | 222
drivers/of/Kconfig |5 +
drivers/of/Makefile
On Mon, 2012-10-08 at 10:07 +0300, Tomi Valkeinen wrote:
Hi,
I don't see you setting disp-default_timing to OF_DEFAULT_TIMING in
case there's no default_timing found.
Or, at least I presume OF_DEFAULT_TIMING is meant to mark non-existing
default timing. The name OF_DEFAULT_TIMING
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
Signed-off-by: Steffen Trumtrar
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver
On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
Hi Tomi,
On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
In general, I might be misunderstanding something, but don't we have to
distinguish between 2
Hi,
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
Hi everybody,
While working on DT bindings for the Renesas Mobile SoC display controller
(a.k.a. LCDC) I quickly realized that display panel implementation based on
board code callbacks would need to be replaced by a
On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
Hi Tomi,
mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
used for non-panel devices (at least in theory). The future mipi-dsi-bus
certainly will.
They are both display busses. So while they could be used
On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
Hi Tomi,
On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
Hi Tomi,
mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
used for non
Hi,
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
Oookay, where to start... ;)
A few cosmetic/general comments first.
I find the file naming a bit strange. You have panel.c, which is the
core framework,
On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the review.
On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote
On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote:
What kind of directory structure do you have in mind ? Panels are already
isolated in drivers/video/panel/ so we could already ditch the panel- prefix
in drivers.
The same directory also contains files for the framework and buses.
On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API?
u8 and u16 both fit in an unsigned long :-) Please see below.
Ah, I see, so the driver would just discard 24 bits or
On Tue, 2011-11-29 at 13:10 +0100, Laurent Pinchart wrote:
To make it perfectly clear, I want to emphasize that I'm not trying to
replace
DRM, FBDEV and V4L2 with a new shared subsystem. What I would like to see in
the (near future) is collaboration and sharing of core features that make
omap_vout crashes on start if a corresponding driver is not loaded for a
display device.
This patch changes omap_vout init sequence to skip devices without a
driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/media/video/omap/omap_vout.c |8
1 files changed, 8
references
the function __init omap_vout_probe()
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/media/video/omap/omap_vout.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
On Tue, 2011-11-08 at 15:15 +, Hiremath, Vaibhav wrote:
I am not sure whether you had tested it, but kernel doesn't boot with V4L2
display enabled in defconfig. I have patch to fix this, will submit shortly -
diff --git a/drivers/media/video/omap/omap_vout.c
On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid
content
to show at this time.
-
On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:
Please look at the patch carefully, it does exactly same thing. I
understand the use-case what Archit explained in the last email but in
this patch context, the use-case change anything here in this patch.
With the current code, the
On Tue, 2011-09-27 at 12:24 +0530, Hiremath, Vaibhav wrote:
If you look at the patch, the patch barely checks for the condition
and
makes sure that the interrupt is either of VSYNC or VSYNC2, else
return. Rest everything is same.
This is what the current code does, in clearer form and
On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote:
On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote:
On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
Remove the code in omap_vout_probe() which calls display-driver-update()
for
all the displays. This isn't correct
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV,
101 - 133 of 133 matches
Mail list logo
