On Wed, 2011-09-07 at 15:00 +0900, Inki Dae wrote:
Hello, Rob.
-Original Message-
From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
Clark
Sent: Tuesday, September 06, 2011 1:05 AM
To: Inki Dae
Cc: dri-devel@lists.freedesktop.org;
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
This was a very rough and quite short proposal, but I'm happy to improve
and extend it if it's not totally shot down.
Jesse Barnes has put together
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
2) panel drivers, handles panel specific things. Each panel may support
custom commands and features, for which we need a dedicated driver
On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
I'm not sure a common interface to all of these different
channels makes sense, but surely a DSI library and an aux channel
library would fit nicely alongside the existing DDC library.
DSI and the various other MIPI bits tend to be
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I think it's a bit more complex than that. True, there are MIPI
standards, for the video there are DPI, DBI, DSI, and for the commands
there is DCS
On Tue, 2011-09-20 at 23:20 +0200, Patrik Jakobsson wrote:
Ok, not sure I understand the complexity of DSI. Can overlay composition
occur after/at the DSI stage (through MCS perhaps)? Or is it a matter of
panels requiring special scanout buffer formats that for instance V4L needs
to know
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
Hi,
On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
From: Rob Clark r...@ti.com
Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC
provides support for remapping physically discontiguous buffers for
various DMA initiators (DSS, IVAHD, etc) which do not otherwise
On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
From: Rob Clark r...@ti.com
Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC
On Mon, 2012-02-20 at 15:03 -0600, Rob Clark wrote:
From: Rob Clark r...@ti.com
The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the -detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm
On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Can there be more than one
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I have to say I don't know much about DMM, but my
understanding is that
DMM is a bigger entity, of which TILER
On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hmm, why does the drm core care about it?
Because it is the one generating the bus-id.. see
drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
Anyways
On Wed, 2012-03-07 at 09:59 -0600, Gross, Andy wrote:
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Does this DMM has become synonymous mean that people just started
calling TILER DMM, and thus the name has stuck, or are there technical
reasons to handle
Hi,
On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation. DMM is split into a
separate device using hwmod.
What's the diff with this and the
On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region
On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
On Tue, 2012-03-13
On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
Well, as I said, it's not an issue for me and from my side it can be
improved later.
yeah, when CMA is actually merged, there are a few other things I'd
like to do to, incl converting omapfb over to use CMA and remove
omap_vram.. but I
On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
Well, as I said, it's not an issue for me and from my side it can be
improved later.
yeah, when CMA
Hi,
On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
snip
+static int __init omap_init_drm(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod
On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
Register OMAP DRM/KMS platform
On Thu, 2012-05-24 at 02:35 -0600, Rob Clark wrote:
On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
On Wed, 2012-05
On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
v4l2 camera working w/ tiler buffers on my pandaboard, for example.
Maybe fbdev is an exception to the rule because it has no way for
userspace to pass it a buffer to
On Thu, 2012-05-24 at 10:09 -0500, Gross, Andy wrote:
On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
v4l2 camera working w/ tiler buffers
On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote:
Tomi,
So at this point, are you OK with deferring a split of the DMM until
it necessary to do so (if ever)? I'd like to get this patch in so
that people have a working omapdrm device when they enable the config
options.
Yes, I'm ok
On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
Signed-off-by: Rob Clark r...@ti.com
+/* this should probably be in
Hi,
On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger remaining
issues in the TODO before moving omapdrm out of staging.
The
On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote:
On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
It's not really about being friendly. Omapdss tries to do as little as
possible, while still supporting all its HW features. Shadow registers
are a bit tricky
On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote:
Ok.. this would help. I'll take a look. I do request that
interfaces/panels don't set any mgr/timing related registers. I had
to comment all this stuff out in my prototype. Really we want to set
the timings separately on the crtc (mgr) /
On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
I guess the fact is that DRM concepts do not really match the OMAP DSS
hardware, and we'll have to use whatever gives us least problems.
Actually, I think
On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I guess the fact is that DRM
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 02:49 +0200, Laurent Pinchart wrote:
+/*
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
+{
+
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 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 Fri, 2012-09-07 at 12:59 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
Without these, DVI is broken.
Signed-off-by: Rob Clark r...@ti.com
---
Greg, it looks like the omapdss changes which added these fields, as
well as the interlaced field, where merged in Linux 3.5-rc5. So I
On Wed, 2012-07-04 at 09:56 +0200, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
I have more or less the same generic comment for this as for the
On Wed, 2012-09-19 at 10:20 +0200, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
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
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 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
On 2012-10-29 10:31, Rob Clark wrote:
From: Rob Clark r...@ti.com
Remove usage of plat/cpu.h and get information from platform data
instead. This enables omapdrm to be built with ARCH_MULTIPLATFORM.
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/mach-omap2/drm.c|
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-11-05 16:21, Rob Clark wrote:
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
manager needs to observe all the possible displays used at the same
time...
Right. I was wondering if omapfb/omapdrm could understand
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have
hardware that could use it. For example, omap3 SDP board has a
switchable output to DVI or LCD panel
On 2012-11-07 21:18, Rob Clark wrote:
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hotplugging is not some abstract future scenario, we already
On 2012-11-16 14:19, Greg KH wrote:
On Thu, Nov 15, 2012 at 06:00:58PM -0600, Rob Clark wrote:
This patch changes the omapdrm KMS to bypass the omapdss compat
layer and use the core omapdss API directly. This solves some layering
issues that would cause unpin confusion vs GO bit status,
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,
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
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
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 display
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 linux
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 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/high/ignored
+ - de-active: data-enable pulse
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_dpi *panel
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity The display entity
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The
array
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|4 +
drivers/video/display/Makefile |1 +
On 2012-12-06 12:07, Grant Likely wrote:
On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
On 2012-11-26 11:07, Steffen Trumtrar wrote:
+/*
+ * Subsystem independent description
On 2012-12-07 16:12, Philipp Zabel wrote:
Hi,
Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
So what does the pixelclk-inverted mean? Normally the SoC drives pixel
data on rising edge, and the panel samples it at falling edge? And
vice-versa for inverted? Or the other way
complex busses like DSI.
So in my version I added DSI as a plain video_source, without a real linux bus.
I think this model is a lot simpler, and works better.
Tomi
Tomi Valkeinen (6):
video: add display-core
video: add generic dpi panel
video: add tfp410
video: add generic dvi monitor
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/display/display-core.c | 207 ++
include/video/display.h | 166 +++
2 files changed, 373 insertions(+)
create mode 100644 drivers/video/display/display
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/display/panel-dpi.c | 155 +
include/video/panel-dpi.h | 25 ++
2 files changed, 180 insertions(+)
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/display/chip-tfp410.c | 164 +++
include/video/omap-panel-tfp410.h |4 +
2 files changed, 168 insertions(+)
create mode 100644 drivers/video/display/chip-tfp410.c
diff --git a/drivers
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/display/panel-dvi.c | 164 +
include/video/panel-dvi.h | 18
2 files changed, 182 insertions(+)
create mode 100644 drivers/video/display/panel-dvi.c
create mode 100644
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/display/panel-taal.c | 383 ++
include/video/omap-panel-nokia-dsi.h |4 +-
2 files changed, 385 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/display/panel-taal.c
diff
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/Kconfig |1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig | 26 ++
drivers/video/display/Makefile |5 +
4 files changed, 33 insertions(+)
create mode
On 2012-12-14 02:04, Rob Clark wrote:
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
CMA helpers. Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape). There are also various
On 2012-12-19 15:21, Laurent Pinchart wrote:
Hi Tomi,
On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
Hi,
I have been testing Common Display Framework on OMAP, and making changes
that I've discussed in the posts I've sent in reply to the CDF series from
Laurent. While my CDF
On 2012-12-19 16:57, Jani Nikula wrote:
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (=CDF) for HDMI or DP (or legacy outputs) would be
overengineering it. They are pretty well standardized, and I don't see
there would be a need to write multiple display
On 2012-12-19 17:26, Rob Clark wrote:
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
Hi Laurent -
On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com
wrote:
Hi Jani,
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
I can see
as proposed by Tomi Valkeinen in his
CDF model. However, if the bus can be used for video data transfer in
combination with a different control bus, a video source corresponding to the
data bus will be needed.
I think this is always the case. If a bus can be used for control and
video data, you can
On 2013-02-06 14:11, Jani Nikula wrote:
On Wed, 06 Feb 2013, Tomi Valkeinen tomi.valkei...@ti.com wrote:
6. Miscellaneous
- If the OMAP3 DSS driver is used as a model for the DSI support
implementation, Daniel Vetter requested the DSI bus lock semaphore to be
killed
On 2013-02-06 16:44, Alex Deucher wrote:
On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
What is an encoder? Something that takes a video signal in, and lets the
CPU store the received data to memory? Isn't that a decoder?
Or do you mean something that takes
On 2013-02-04 12:05, Marcus Lorentzon wrote:
As discussed at FOSDEM I will give DSI bus with full feature set a
try.
Please do, but as a reminder I want to raise the issues I see with a DSI
bus:
- A device can be a child of only one bus. So if DSI is used only for
video, the device is a child
On 2013-02-08 14:40, Marcus Lorentzon wrote:
I agree, but I think it should be
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed
while link is enabled. And if there are, they should be identified and
split out into a
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock
On 2013-02-08 16:54, Marcus Lorentzon wrote:
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels
On 2013-02-11 11:31, Marcus Lorentzon wrote:
Ok, so what about a compromise which I think would work for both HWs
... we allow the configure operation during video on, then each HW
driver could decide if this means you have to stop or not to do the
changes required. But then it is also
Hi Marcus,
On 2013-02-12 17:04, Marcus Lorentzon wrote:
Now we have some different types of panels which are attached on a
combination of busses:
a) control:DBI, data:DBI
b) control:I2C/SPI, data:I2C/SPI
c) control:static setup, data:DPI
d) control:I2C/SPI, data:DPI
e) control:DSI,
On 2013-02-13 00:45, Stéphane Marchesin wrote:
So, a part which is completely omitted in this thread is how to handle
suspend/resume ordering. If you have multiple encoders which need to
be turned on/off in a given order at suspend/resume, how do you handle
that given the current scheme where
On 2013-02-18 01:02, Rob Clark wrote:
Hi Dave,
Here is pull request for tilcdc drm driver.. it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in drm-next.
Why is the TFP410 driver integrated into the tilcdc, but the
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better. But I needed something
I may be mistaken, but my understanding is that DT bindings are like
kernel's userspace APIs. After they have been
On 2013-02-18 14:35, Rob Clark wrote:
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better. But I needed something
I may
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
+/* VESA display monitor timing parameters */
+#define VESA_DMT_HSYNC_LOW BIT(0)
+#define VESA_DMT_HSYNC_HIGH BIT(1)
+#define VESA_DMT_VSYNC_LOW BIT(2)
+#define VESA_DMT_VSYNC_HIGH BIT(3)
+
+/*
On 2013-02-18 09:23, Archit Taneja wrote:
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static
1 - 100 of 3370 matches
Mail list logo
