Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
> +static void panel_dpi_release(struct display_entity *entity)
> +{
> + struct panel_dpi *panel = to_panel_dpi(entity);
> +
> + kfree(panel);
> +}
> +
> +static int panel_dpi_remove(struct platform_device *pdev)
> +{
> + struct panel_d
On 2012-11-26 18:10, Steffen Trumtrar wrote:
> Hi,
>
> On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
>>> +optional properties:
>>> + - hsync-active: hsync pulse is active low/high/ignored
>>> + - vsync-active: vsync pulse is active low/
Hi,
On 2012-11-26 11:07, Steffen Trumtrar wrote:
> This adds support for reading display timings from DT into a struct
> display_timings. The of_display_timing implementation supports multiple
> subnodes. All children are read into an array, that can be queried.
>
> If no native mode is specified
On 2012-11-26 11:07, Steffen Trumtrar wrote:
> +/*
> + * Subsystem independent description of a videomode.
> + * Can be generated from struct display_timing.
> + */
> +struct videomode {
> + u32 pixelclock; /* pixelclock in Hz */
I don't know if this is of any importance, but the linu
On 2012-11-23 21:56, Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> [...]
>> Display entities are accessed by driver using notifiers. Any driver can
>> register a display entity notifier with the CDF, which then calls the
>> notifier
>> when a matching
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
> From: Laurent Pinchart
>
> Hi everybody,
>
> Here's the second RFC of what was previously known as the Generic Panel
> Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
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 *
On 2012-11-21 18:11, Steffen Trumtrar wrote:
> Hi,
>
> On Wed, Nov 21, 2012 at 01:37:08PM +0200, Tomi Valkeinen wrote:
>>> +#include
>>
>> What is this needed for? u32? I don't see it defined in types.h
>>
>
> Yes, u32. What would be the right
On 2012-11-20 17:54, Steffen Trumtrar wrote:
> Add helper to get drm_display_mode from devicetree.
>
> Signed-off-by: Steffen Trumtrar
> Reviewed-by: Thierry Reding
> Acked-by: Thierry Reding
> Tested-by: Thierry Reding
> Tested-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
> driv
On 2012-11-20 17:54, Steffen Trumtrar wrote:
> Add conversion from videomode to drm_display_mode
>
> Signed-off-by: Steffen Trumtrar
> Reviewed-by: Thierry Reding
> Acked-by: Thierry Reding
> Tested-by: Thierry Reding
> Tested-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
> driver
On 2012-11-20 17:54, Steffen Trumtrar wrote:
> Add helper to get fb_videomode from devicetree.
>
> Signed-off-by: Steffen Trumtrar
> Reviewed-by: Thierry Reding
> Acked-by: Thierry Reding
> Tested-by: Thierry Reding
> Tested-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
> drivers/
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
> #include
> #include
> +#include
No need for this, just add "struct xxx;
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: Ver
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
> .
>
> Also, add helper fu
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 ti
Remove including plat/dma.h which is not needed.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/omap/omap_vout.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index 7b1afc8..a2cc634 100644
--- a
ones
dealing with DSS differences, this is actually more correct than using
cpu_is_* functions. For the check whether VRFB is available or not this
is not really correct, but still works fine.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/omap/omap_vout.c|3 +--
drivers/media
#x27;t
look as trivial 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/
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 s
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 fo
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
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 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
> ---
> drivers
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
Hi,
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
> Signed-off-by: Steffen Trumtrar
> ---
> .../devicetree/bindings/video/display-timings.txt | 222
>
> drivers/of/Kconfig |5 +
> drivers/of/Makefile
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 driver-
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
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 us
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 bit
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 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, L
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> +/*
> -
> + * Bus operations
> + */
> +
> +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
> +{
> + dev->bus->ops->write_comma
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 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 mak
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
---
drivers/media/video/omap/omap_vout.c |8
1 files changed, 8 insertions(+), 0
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
> b/drivers/media/vid
references
the function __init omap_vout_probe()
Signed-off-by: Tomi Valkeinen
---
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
index 9c5c19f..a323c09
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 i
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 slig
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, th
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.
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
101 - 142 of 142 matches
Mail list logo
