[RFC v2 0/5] Common Display Framework

60 messages, 14 authors, 2013-02-02 · open the first message on its own page

[RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:43

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Hi everybody,

Here's the second RFC of what was previously known as the Generic Panel
Framework.

I won't repeat all the background information from the first version here, you
can read it at http://lwn.net/Articles/512363/.

Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.

After discussing the Generic Panel Framework at Linaro Connect we came to the 
conclusion that "panel" is too limiting a name. In addition to panel drivers
we also want to share transmitter and bridge drivers between DRM and FBDEV. I
have thus introduced the concept of a display entity in this version to
represent any hardware block that sources, processes or sinks display-related
video streams. This patch set implements the Common Display Framework (CDF).

Display entities are connected to at least one video data bus, and optionally
to a control bus. The video data busses carry display-related video data out
of sources (such as a CRTC in a display controller) to sinks (such as a panel
or a monitor), optionally going through transmitters, encoders, decoders,
bridges or other similar devices. A CRTC or a panel will usually be connected
to a single data bus, while an encoder or a transmitter will be connected to
two data busses.

While some display entities don't require any configuration (DPI panels are a
good example), many of them are connected to a control bus accessible to the
CPU. Control requests can be sent on a dedicated control bus (such as I2C or
SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To
support both options the CDF display entity model separates the control and
data busses in different APIs.

Display entities are abstract object that must be implemented by a real
device. The device sits on its control bus and is registered with the Linux
device core and matched with his driver using the control bus specific API.
The CDF doesn't create a display entity class or bus, display entity drivers
thus standard Linux kernel drivers using existing busses.

When a display entity driver probes a device it must create an instance of the
display_entity structure, initialize it and register it with the CDF core. The
display entity exposes abstract operations through function pointers, and the
entity driver must implement those operations. They are divided in two groups,
control operations and video operations.

Control operations are called by upper-level drivers, usually in response to a
request originating from userspace. They control the display entity state and
operation. Currently defined control operations are

- set_state(), to control the state of the entity (off, standby or on)
- update(), to trigger a display update (for entities that implement manual
  update, such as manual-update panels that store frames in their internal
  frame buffer)
- get_modes(), to retrieve the video modes supported by the entity
- get_params(), to retrive the data bus parameters at the entity input (sink)
- get_size(), to retrive the entity physical size (applicable to panels only)

Video operations are called by downstream entities on upstream entities (from
a video data bus point of view) to control the video operation. The only
currently defined video operation is

- set_stream(), to start (in continuous or single-shot mode) the video stream

http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver
implemented using the CDF interacts with the other components in the system.
The first page shows the panel driver receiving control request from the
display controller driver at its top side, usually in response to a DRM or
FBDEV API call. It then issues requests on its control bus (several possible
control busses are shown on the diagram, the panel driver uses one of them
only) and calls video operations of the display controller on its left side to
control the video stream.

The second page shows a slightly more complex use case, with a display
controller that includes an LVDS transceiver (shown as two separate entities
on the left hand side), connected to an LVDS to DSI converter that is itself
connected to a DSI panel module. The panel module contains a DSI panel
controller that drives the LCD panel. While this particular example is
probably too theoretical to be found in real devices, it illustrates the
concept of display entities chains.

The CDF models this using a Russian doll's model. From the display controller
point of view only the first external entity (LVDS to DSI converter) is
visible. The display controller thus calls the control operations implemented
by the LVDS to DSI transmitter driver (left-most green arrow). The driver is
aware of the next entity in the chain, and relays the call down, possibly
mangling the request and/or the reply, and accessing the device it handles
through its control bus (not shown here). When the operations reaches the last
entity in the chain the video operations are called upstream to control the
video stream.

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 entity is registered. The reason for this asynchronous
mode of operation, compared to how drivers acquire regulator or clock
resources, is that the display entities can use resources provided by the
display driver. For instance a panel can be a child of the DBI or DSI bus
controlled by the display device, or use a clock provided by that device. We
can't defer the display device probe until the panel is registered and also
defer the panel device probe until the display is registered. As most display
drivers need to handle output devices hotplug (HDMI monitors for instance),
handling other display entities through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each other.
Those circular references would make driver unloading impossible. One possible
solution to this problem would be to simulate an unplug event for the display
entity, to force the display driver to release the dislay entities it uses. We
would need a userspace API for that though. Better solutions would of course
be welcome.

Please note taht most of the display entities on devices I own are jut dumb
panels with no control bus, and are thus not the best candidates to design a
framework that needs to take complex panels' needs into account. This is why I
hope to see you using the CDF with your display device and tell me what needs
to be modified/improved/redesigned.

This patch set includes three sections:

- The first patch adds the generic display entity core
- The third patch adds a MIPI DBI bus, which is a mixed control and data video
  bus using parallel data (similarly to a microprocessor external data bus)
- The second, fourth and fifth patches add drivers for DPI panels (no control
  bus) and two DBI panel controllers.

The patches are available in my git tree at

    git://linuxtv.org/pinchartl/fbdev.git lcdc-panel
    http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel

For convenience I've included Steffen's display helpers patches on which this
series is based (see http://www.spinics.net/lists/dri-devel/msg30664.html for
more information about those), as well as modifications to the sh-mobile-lcdc
driver to use the CDF. You can read the code to see how the driver uses the
CDF to interface panels. Please note that the sh-mobile-lcdc implementation is
still work in progress, its set_stream operation implementation doesn't
enable/disable the video stream yet as it should.

I still need to gather notes from v1 and v2 and create proper documentation
from them. I didn't want to delay these patches any longer given the number of
people who were waiting for them, I will try to do work on documentation next
week.

As already mentioned in v1, I will appreciate all reviews, comments,
criticisms, ideas, remarks, ... If you can find a clever way to solve the
cyclic references issue described above I'll buy you a beer at the next
conference we will both attend. If you think the proposed solution is too
complex, or too simple, I'm all ears.

Laurent Pinchart (5):
  video: Add generic display entity core
  video: panel: Add DPI panel support
  video: display: Add MIPI DBI bus support
  video: panel: Add R61505 panel support
  video: panel: Add R61517 panel support

 drivers/video/Kconfig                |    1 +
 drivers/video/Makefile               |    1 +
 drivers/video/display/Kconfig        |   39 +++
 drivers/video/display/Makefile       |    5 +
 drivers/video/display/display-core.c |  362 ++++++++++++++++++++++
 drivers/video/display/mipi-dbi-bus.c |  228 ++++++++++++++
 drivers/video/display/panel-dpi.c    |  147 +++++++++
 drivers/video/display/panel-r61505.c |  554 ++++++++++++++++++++++++++++++++++
 drivers/video/display/panel-r61517.c |  447 +++++++++++++++++++++++++++
 include/video/display.h              |  155 ++++++++++
 include/video/mipi-dbi-bus.h         |  125 ++++++++
 include/video/panel-dpi.h            |   24 ++
 include/video/panel-r61505.h         |   27 ++
 include/video/panel-r61517.h         |   28 ++
 14 files changed, 2143 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 drivers/video/display/mipi-dbi-bus.c
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 drivers/video/display/panel-r61505.c
 create mode 100644 drivers/video/display/panel-r61517.c
 create mode 100644 include/video/display.h
 create mode 100644 include/video/mipi-dbi-bus.h
 create mode 100644 include/video/panel-dpi.h
 create mode 100644 include/video/panel-r61505.h
 create mode 100644 include/video/panel-r61517.h

-- 
Regards,

Laurent Pinchart

[RFC v2 1/5] video: Add generic display entity core

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:43

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/Kconfig                |    1 +
 drivers/video/Makefile               |    1 +
 drivers/video/display/Kconfig        |    4 +
 drivers/video/display/Makefile       |    1 +
 drivers/video/display/display-core.c |  362 ++++++++++++++++++++++++++++++++++
 include/video/display.h              |  150 ++++++++++++++
 6 files changed, 519 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c5b7bcf..e91f03e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2442,6 +2442,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"
 
 if VT
 	source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b936b00..0a4cfea 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs                           := $(fb-y)
 obj-$(CONFIG_VT)		  += console/
 obj-$(CONFIG_LOGO)		  += logo/
 obj-y				  += backlight/
+obj-y				  += display/
 
 obj-$(CONFIG_EXYNOS_VIDEO)     += exynos/
 
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 0000000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+	tristate "Display Core"
+	---help---
+	  Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 0000000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
diff --git a/drivers/video/display/display-core.c b/drivers/video/display/display-core.c
new file mode 100644
index 0000000..358c089
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,362 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/videomode.h>
+
+#include <video/display.h>
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/* -----------------------------------------------------------------------------
+ * Control operations
+ */
+
+/**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See &enum display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+			     enum display_entity_state state)
+{
+	int ret;
+
+	if (entity->state = state)
+		return 0;
+
+	if (!entity->ops.ctrl || !entity->ops.ctrl->set_state)
+		return 0;
+
+	ret = entity->ops.ctrl->set_state(entity, state);
+	if (ret < 0)
+		return ret;
+
+	entity->state = state;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->update)
+		return 0;
+
+	return entity->ops.ctrl->update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
+ * 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
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int display_entity_get_modes(struct display_entity *entity,
+			     const struct videomode **modes)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->get_modes)
+		return 0;
+
+	return entity->ops.ctrl->get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+/**
+ * display_entity_get_size - Get display entity physical size
+ * @entity: The display entity
+ * @width: Physical width in millimeters
+ * @height: Physical height in millimeters
+ *
+ * When applicable, for instance for display panels, retrieve the display
+ * physical size in millimeters.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_get_size(struct display_entity *entity,
+			    unsigned int *width, unsigned int *height)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->get_size)
+		return -EOPNOTSUPP;
+
+	return entity->ops.ctrl->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+/**
+ * display_entity_get_params - Get display entity interface parameters
+ * @entity: The display entity
+ * @params: Pointer to interface parameters
+ *
+ * Fill the parameters structure pointed to by the params argument with display
+ * entity interface parameters.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_get_params(struct display_entity *entity,
+			      struct display_entity_interface_params *params)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->get_modes)
+		return -EOPNOTSUPP;
+
+	return entity->ops.ctrl->get_params(entity, params);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_params);
+
+/* -----------------------------------------------------------------------------
+ * Video operations
+ */
+
+/**
+ * display_entity_set_stream - Control the video stream state
+ * @entity: The display entity
+ * @state: Display video stream state
+ *
+ * Control the video stream state at the entity video output.
+ *
+ * See &enum display_entity_stream_state for information regarding the stream
+ * states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_stream(struct display_entity *entity,
+			      enum display_entity_stream_state state)
+{
+	if (!entity->ops.video || !entity->ops.video->set_stream)
+		return 0;
+
+	return entity->ops.video->set_stream(entity, state);
+}
+EXPORT_SYMBOL_GPL(display_entity_set_stream);
+
+/* -----------------------------------------------------------------------------
+ * Connections
+ */
+
+/**
+ * display_entity_connect - Connect two entities through a video stream
+ * @source: The video stream source
+ * @sink: The video stream sink
+ *
+ * Set the sink entity source field to the source entity.
+ */
+
+/**
+ * display_entity_disconnect - Disconnect two previously connected entities
+ * @source: The video stream source
+ * @sink: The video stream sink
+ *
+ * Break a connection between two previously connected entities. The source
+ * entity source field is reset to NULL.
+ */
+
+/* -----------------------------------------------------------------------------
+ * Registration and notification
+ */
+
+static void display_entity_release(struct kref *ref)
+{
+	struct display_entity *entity +		container_of(ref, struct display_entity, ref);
+
+	if (entity->release)
+		entity->release(entity);
+}
+
+/**
+ * display_entity_get - get a reference to a display entity
+ * @display_entity: the display entity
+ *
+ * Return the display entity pointer.
+ */
+struct display_entity *display_entity_get(struct display_entity *entity)
+{
+	if (entity = NULL)
+		return NULL;
+
+	kref_get(&entity->ref);
+	return entity;
+}
+EXPORT_SYMBOL_GPL(display_entity_get);
+
+/**
+ * display_entity_put - release a reference to a display entity
+ * @display_entity: the display entity
+ *
+ * Releasing the last reference to a display entity releases the display entity
+ * itself.
+ */
+void display_entity_put(struct display_entity *entity)
+{
+	kref_put(&entity->ref, display_entity_release);
+}
+EXPORT_SYMBOL_GPL(display_entity_put);
+
+static int display_entity_notifier_match(struct display_entity *entity,
+				struct display_entity_notifier *notifier)
+{
+	return notifier->dev = NULL || notifier->dev = entity->dev;
+}
+
+/**
+ * display_entity_register_notifier - register a display entity notifier
+ * @notifier: display entity notifier structure we want to register
+ *
+ * Display entity notifiers are called to notify drivers of display
+ * entity-related events for matching display_entitys.
+ *
+ * Notifiers and display_entitys are matched through the device they correspond
+ * to. If the notifier dev field is equal to the display entity dev field the
+ * notifier will be called when an event is reported. Notifiers with a NULL dev
+ * field act as catch-all and will be called for all display_entitys.
+ *
+ * Supported events are
+ *
+ * - DISPLAY_ENTITY_NOTIFIER_CONNECT reports display entity connection and is
+ *   sent at display entity or notifier registration time
+ * - DISPLAY_ENTITY_NOTIFIER_DISCONNECT reports display entity disconnection and
+ *   is sent at display entity unregistration time
+ *
+ * Registering a notifier sends DISPLAY_ENTITY_NOTIFIER_CONNECT events for all
+ * previously registered display_entitys that match the notifiers.
+ *
+ * Return 0 on success.
+ */
+int display_entity_register_notifier(struct display_entity_notifier *notifier)
+{
+	struct display_entity *entity;
+
+	mutex_lock(&display_entity_mutex);
+	list_add_tail(&notifier->list, &display_entity_notifiers);
+
+	list_for_each_entry(entity, &display_entity_list, list) {
+		if (!display_entity_notifier_match(entity, notifier))
+			continue;
+
+		if (notifier->notify(notifier, entity,
+				     DISPLAY_ENTITY_NOTIFIER_CONNECT))
+			break;
+	}
+	mutex_unlock(&display_entity_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_register_notifier);
+
+/**
+ * display_entity_unregister_notifier - unregister a display entity notifier
+ * @notifier: display entity notifier to be unregistered
+ *
+ * Unregistration guarantees that the notifier will never be called upon return
+ * of this function.
+ */
+void display_entity_unregister_notifier(struct display_entity_notifier *notifier)
+{
+	mutex_lock(&display_entity_mutex);
+	list_del(&notifier->list);
+	mutex_unlock(&display_entity_mutex);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister_notifier);
+
+/**
+ * display_entity_register - register a display entity
+ * @display_entity: display entity to be registered
+ *
+ * Register the display entity and send the DISPLAY_ENTITY_NOTIFIER_CONNECT
+ * event to all matching registered notifiers.
+ *
+ * Return 0 on success.
+ */
+int __must_check __display_entity_register(struct display_entity *entity,
+					   struct module *owner)
+{
+	struct display_entity_notifier *notifier;
+
+	kref_init(&entity->ref);
+	entity->owner = owner;
+	entity->state = DISPLAY_ENTITY_STATE_OFF;
+
+	mutex_lock(&display_entity_mutex);
+	list_add(&entity->list, &display_entity_list);
+
+	list_for_each_entry(notifier, &display_entity_notifiers, list) {
+		if (!display_entity_notifier_match(entity, notifier))
+			continue;
+
+		if (notifier->notify(notifier, entity,
+				     DISPLAY_ENTITY_NOTIFIER_CONNECT))
+			break;
+	}
+	mutex_unlock(&display_entity_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(__display_entity_register);
+
+/**
+ * display_entity_unregister - unregister a display entity
+ * @display_entity: display entity to be unregistered
+ *
+ * Unregister the display entity and send the DISPLAY_ENTITY_NOTIFIER_DISCONNECT
+ * event to all matching registered notifiers.
+ */
+void display_entity_unregister(struct display_entity *entity)
+{
+	struct display_entity_notifier *notifier;
+
+	mutex_lock(&display_entity_mutex);
+	list_for_each_entry(notifier, &display_entity_notifiers, list) {
+		if (!display_entity_notifier_match(entity, notifier))
+			continue;
+
+		notifier->notify(notifier, entity,
+				 DISPLAY_ENTITY_NOTIFIER_DISCONNECT);
+	}
+
+	list_del(&entity->list);
+	mutex_unlock(&display_entity_mutex);
+
+	display_entity_put(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("Display Core");
+MODULE_LICENSE("GPL");
diff --git a/include/video/display.h b/include/video/display.h
new file mode 100644
index 0000000..90d18ca
--- /dev/null
+++ b/include/video/display.h
@@ -0,0 +1,150 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DISPLAY_H__
+#define __DISPLAY_H__
+
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/module.h>
+
+/* -----------------------------------------------------------------------------
+ * Display Entity
+ */
+
+struct display_entity;
+struct videomode;
+
+#define DISPLAY_ENTITY_NOTIFIER_CONNECT		1
+#define DISPLAY_ENTITY_NOTIFIER_DISCONNECT	2
+
+struct display_entity_notifier {
+	int (*notify)(struct display_entity_notifier *, struct display_entity *,
+		      int);
+	struct device *dev;
+	struct list_head list;
+};
+
+/**
+ * enum display_entity_state - State of a display entity
+ * @DISPLAY_ENTITY_STATE_OFF: The entity is turned off completely, possibly
+ *	including its power supplies. Communication with a display entity in
+ *	that state is not possible.
+ * @DISPLAY_ENTITY_STATE_STANDBY: The entity is in a low-power state. Full
+ *	communication with the display entity is supported, including pixel data
+ *	transfer, but the output is kept blanked.
+ * @DISPLAY_ENTITY_STATE_ON: The entity is fully operational.
+ */
+enum display_entity_state {
+	DISPLAY_ENTITY_STATE_OFF,
+	DISPLAY_ENTITY_STATE_STANDBY,
+	DISPLAY_ENTITY_STATE_ON,
+};
+
+/**
+ * enum display_entity_stream_state - State of a video stream
+ * @DISPLAY_ENTITY_STREAM_STOPPED: The video stream is stopped, no frames are
+ *	transferred.
+ * @DISPLAY_ENTITY_STREAM_SINGLE_SHOT: The video stream has been started for
+ *      single shot operation. The source entity will transfer a single frame
+ *      and then stop.
+ * @DISPLAY_ENTITY_STREAM_CONTINUOUS: The video stream is running, frames are
+ *	transferred continuously by the source entity.
+ */
+enum display_entity_stream_state {
+	DISPLAY_ENTITY_STREAM_STOPPED,
+	DISPLAY_ENTITY_STREAM_SINGLE_SHOT,
+	DISPLAY_ENTITY_STREAM_CONTINUOUS,
+};
+
+enum display_entity_interface_type {
+	DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+struct display_entity_interface_params {
+	enum display_entity_interface_type type;
+};
+
+struct display_entity_control_ops {
+	int (*set_state)(struct display_entity *ent,
+			 enum display_entity_state state);
+	int (*update)(struct display_entity *ent);
+	int (*get_modes)(struct display_entity *ent,
+			 const struct videomode **modes);
+	int (*get_params)(struct display_entity *ent,
+			  struct display_entity_interface_params *params);
+	int (*get_size)(struct display_entity *ent,
+			unsigned int *width, unsigned int *height);
+};
+
+struct display_entity_video_ops {
+	int (*set_stream)(struct display_entity *ent,
+			  enum display_entity_stream_state state);
+};
+
+struct display_entity {
+	struct list_head list;
+	struct device *dev;
+	struct module *owner;
+	struct kref ref;
+
+	struct display_entity *source;
+
+	struct {
+		const struct display_entity_control_ops *ctrl;
+		const struct display_entity_video_ops *video;
+	} ops;
+
+	void(*release)(struct display_entity *ent);
+
+	enum display_entity_state state;
+};
+
+int display_entity_set_state(struct display_entity *entity,
+			     enum display_entity_state state);
+int display_entity_update(struct display_entity *entity);
+int display_entity_get_modes(struct display_entity *entity,
+			     const struct videomode **modes);
+int display_entity_get_params(struct display_entity *entity,
+			      struct display_entity_interface_params *params);
+int display_entity_get_size(struct display_entity *entity,
+			    unsigned int *width, unsigned int *height);
+
+int display_entity_set_stream(struct display_entity *entity,
+			      enum display_entity_stream_state state);
+
+static inline void display_entity_connect(struct display_entity *source,
+					  struct display_entity *sink)
+{
+	sink->source = source;
+}
+
+static inline void display_entity_disconnect(struct display_entity *source,
+					     struct display_entity *sink)
+{
+	sink->source = NULL;
+}
+
+struct display_entity *display_entity_get(struct display_entity *entity);
+void display_entity_put(struct display_entity *entity);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+					   struct module *owner);
+void display_entity_unregister(struct display_entity *entity);
+
+int display_entity_register_notifier(struct display_entity_notifier *notifier);
+void display_entity_unregister_notifier(struct display_entity_notifier *notifier);
+
+#define display_entity_register(display_entity) \
+	__display_entity_register(display_entity, THIS_MODULE)
+
+#endif /* __DISPLAY_H__ */
-- 
1.7.8.6

[RFC v2 2/5] video: panel: Add DPI panel support

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:45

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig     |   13 +++
 drivers/video/display/Makefile    |    1 +
 drivers/video/display/panel-dpi.c |  147 +++++++++++++++++++++++++++++++++++++
 include/video/panel-dpi.h         |   24 ++++++
 4 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 include/video/panel-dpi.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..0f9b990 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,16 @@ menuconfig DISPLAY_CORE
 	tristate "Display Core"
 	---help---
 	  Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+	tristate "DPI (Parallel) Display Panels"
+	---help---
+	  Support for simple digital (parallel) pixel interface panels. Those
+	  panels receive pixel data through a parallel bus and have no control
+	  bus.
+
+	  If you are in doubt, say N.
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..47978d4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/panel-dpi.c b/drivers/video/display/panel-dpi.c
new file mode 100644
index 0000000..c56197a
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,147 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <video/display.h>
+#include <video/panel-dpi.h>
+
+struct panel_dpi {
+	struct display_entity entity;
+	const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p)		container_of(p, struct panel_dpi, entity)
+
+static const struct display_entity_interface_params panel_dpi_params = {
+	.type = DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+static int panel_dpi_set_state(struct display_entity *entity,
+			       enum display_entity_state state)
+{
+	switch (state) {
+	case DISPLAY_ENTITY_STATE_OFF:
+	case DISPLAY_ENTITY_STATE_STANDBY:
+		display_entity_set_stream(entity->source,
+					  DISPLAY_ENTITY_STREAM_STOPPED);
+		break;
+
+	case DISPLAY_ENTITY_STATE_ON:
+		display_entity_set_stream(entity->source,
+					  DISPLAY_ENTITY_STREAM_CONTINUOUS);
+		break;
+	}
+
+	return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+			       const struct videomode **modes)
+{
+	struct panel_dpi *panel = to_panel_dpi(entity);
+
+	*modes = panel->pdata->mode;
+	return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+			      unsigned int *width, unsigned int *height)
+{
+	struct panel_dpi *panel = to_panel_dpi(entity);
+
+	*width = panel->pdata->width;
+	*height = panel->pdata->height;
+	return 0;
+}
+
+static int panel_dpi_get_params(struct display_entity *entity,
+				struct display_entity_interface_params *params)
+{
+	*params = panel_dpi_params;
+	return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+	.set_state = panel_dpi_set_state,
+	.get_modes = panel_dpi_get_modes,
+	.get_size = panel_dpi_get_size,
+	.get_params = panel_dpi_get_params,
+};
+
+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 = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+	display_entity_unregister(&panel->entity);
+
+	return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+	const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
+	struct panel_dpi *panel;
+	int ret;
+
+	if (pdata = NULL)
+		return -ENODEV;
+
+	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+	if (panel = NULL)
+		return -ENOMEM;
+
+	panel->pdata = pdata;
+	panel->entity.dev = &pdev->dev;
+	panel->entity.release = panel_dpi_release;
+	panel->entity.ops.ctrl = &panel_dpi_control_ops;
+
+	ret = display_entity_register(&panel->entity);
+	if (ret < 0) {
+		kfree(panel);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, panel);
+
+	return 0;
+}
+
+static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dpi_driver = {
+	.probe = panel_dpi_probe,
+	.remove = panel_dpi_remove,
+	.driver = {
+		.name = "panel_dpi",
+		.owner = THIS_MODULE,
+		.pm = &panel_dpi_dev_pm_ops,
+	},
+};
+
+module_platform_driver(panel_dpi_driver);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("DPI Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dpi.h b/include/video/panel-dpi.h
new file mode 100644
index 0000000..0547b4a
--- /dev/null
+++ b/include/video/panel-dpi.h
@@ -0,0 +1,24 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_DPI_H__
+#define __PANEL_DPI_H__
+
+#include <linux/videomode.h>
+
+struct panel_dpi_platform_data {
+	unsigned long width;		/* Panel width in mm */
+	unsigned long height;		/* Panel height in mm */
+	const struct videomode *mode;
+};
+
+#endif /* __PANEL_DPI_H__ */
-- 
1.7.8.6

[RFC v2 3/5] video: display: Add MIPI DBI bus support

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:45

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig        |    4 +
 drivers/video/display/Makefile       |    1 +
 drivers/video/display/mipi-dbi-bus.c |  228 ++++++++++++++++++++++++++++++++++
 include/video/display.h              |    5 +
 include/video/mipi-dbi-bus.h         |  125 +++++++++++++++++++
 5 files changed, 363 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/mipi-dbi-bus.c
 create mode 100644 include/video/mipi-dbi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 0f9b990..b04c8be 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -5,6 +5,10 @@ menuconfig DISPLAY_CORE
 
 if DISPLAY_CORE
 
+config DISPLAY_MIPI_DBI
+	tristate
+	default n
+
 config DISPLAY_PANEL_DPI
 	tristate "DPI (Parallel) Display Panels"
 	---help---
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 47978d4..00ef1c2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/mipi-dbi-bus.c b/drivers/video/display/mipi-dbi-bus.c
new file mode 100644
index 0000000..bd39a97
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
@@ -0,0 +1,228 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pm.h>
+#include <linux/pm_runtime.h>
+
+#include <video/mipi-dbi-bus.h>
+
+/* -----------------------------------------------------------------------------
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
+{
+	if (width != 8 && width != 16)
+		return -EINVAL;
+
+	dev->data_width = width;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+	return dev->bus->ops->write_command(dev->bus, dev, cmd);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
+
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+			size_t len)
+{
+	return dev->bus->ops->write_data(dev->bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
+
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
+{
+	return dev->bus->ops->read_data(dev->bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
+
+/* -----------------------------------------------------------------------------
+ * Bus type
+ */
+
+static const struct mipi_dbi_device_id *
+mipi_dbi_match_id(const struct mipi_dbi_device_id *id,
+		  struct mipi_dbi_device *dev)
+{
+	while (id->name[0]) {
+		if (strcmp(dev->name, id->name) = 0) {
+			dev->id_entry = id;
+			return id;
+		}
+		id++;
+	}
+	return NULL;
+}
+
+static int mipi_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+	struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+	struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_drv);
+
+	if (drv->id_table)
+		return mipi_dbi_match_id(drv->id_table, dev) != NULL;
+
+	return (strcmp(dev->name, _drv->name) = 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+			     char *buf)
+{
+	struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+	int len = snprintf(buf, PAGE_SIZE, MIPI_DBI_MODULE_PREFIX "%s\n",
+			   dev->name);
+
+	return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute mipi_dbi_dev_attrs[] = {
+	__ATTR_RO(modalias),
+	__ATTR_NULL,
+};
+
+static int mipi_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+	struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+
+	add_uevent_var(env, "MODALIAS=%s%s", MIPI_DBI_MODULE_PREFIX,
+		       dev->name);
+	return 0;
+}
+
+static const struct dev_pm_ops mipi_dbi_dev_pm_ops = {
+	.runtime_suspend = pm_generic_runtime_suspend,
+	.runtime_resume = pm_generic_runtime_resume,
+	.runtime_idle = pm_generic_runtime_idle,
+	.suspend = pm_generic_suspend,
+	.resume = pm_generic_resume,
+	.freeze = pm_generic_freeze,
+	.thaw = pm_generic_thaw,
+	.poweroff = pm_generic_poweroff,
+	.restore = pm_generic_restore,
+};
+
+static struct bus_type mipi_dbi_bus_type = {
+	.name		= "mipi-dbi",
+	.dev_attrs	= mipi_dbi_dev_attrs,
+	.match		= mipi_dbi_match,
+	.uevent		= mipi_dbi_uevent,
+	.pm		= &mipi_dbi_dev_pm_ops,
+};
+
+/* -----------------------------------------------------------------------------
+ * Device and driver (un)registration
+ */
+
+/**
+ * mipi_dbi_device_register - register a DBI device
+ * @dev: DBI device we're registering
+ */
+int mipi_dbi_device_register(struct mipi_dbi_device *dev,
+			      struct mipi_dbi_bus *bus)
+{
+	device_initialize(&dev->dev);
+
+	dev->bus = bus;
+	dev->dev.bus = &mipi_dbi_bus_type;
+	dev->dev.parent = bus->dev;
+
+	if (dev->id != -1)
+		dev_set_name(&dev->dev, "%s.%d", dev->name,  dev->id);
+	else
+		dev_set_name(&dev->dev, "%s", dev->name);
+
+	return device_add(&dev->dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_device_register);
+
+/**
+ * mipi_dbi_device_unregister - unregister a DBI device
+ * @dev: DBI device we're unregistering
+ */
+void mipi_dbi_device_unregister(struct mipi_dbi_device *dev)
+{
+	device_del(&dev->dev);
+	put_device(&dev->dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_device_unregister);
+
+static int mipi_dbi_drv_probe(struct device *_dev)
+{
+	struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_dev->driver);
+	struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+
+	return drv->probe(dev);
+}
+
+static int mipi_dbi_drv_remove(struct device *_dev)
+{
+	struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_dev->driver);
+	struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+
+	return drv->remove(dev);
+}
+
+/**
+ * mipi_dbi_driver_register - register a driver for DBI devices
+ * @drv: DBI driver structure
+ */
+int mipi_dbi_driver_register(struct mipi_dbi_driver *drv)
+{
+	drv->driver.bus = &mipi_dbi_bus_type;
+	if (drv->probe)
+		drv->driver.probe = mipi_dbi_drv_probe;
+	if (drv->remove)
+		drv->driver.remove = mipi_dbi_drv_remove;
+
+	return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_driver_register);
+
+/**
+ * mipi_dbi_driver_unregister - unregister a driver for DBI devices
+ * @drv: DBI driver structure
+ */
+void mipi_dbi_driver_unregister(struct mipi_dbi_driver *drv)
+{
+	driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_driver_unregister);
+
+/* -----------------------------------------------------------------------------
+ * Init/exit
+ */
+
+static int __init mipi_dbi_init(void)
+{
+	return bus_register(&mipi_dbi_bus_type);
+}
+
+static void __exit mipi_dbi_exit(void)
+{
+	bus_unregister(&mipi_dbi_bus_type);
+}
+
+module_init(mipi_dbi_init);
+module_exit(mipi_dbi_exit)
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("MIPI DBI Bus");
+MODULE_LICENSE("GPL");
diff --git a/include/video/display.h b/include/video/display.h
index 90d18ca..75ba270 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -16,6 +16,7 @@
 #include <linux/kref.h>
 #include <linux/list.h>
 #include <linux/module.h>
+#include <video/mipi-dbi-bus.h>
 
 /* -----------------------------------------------------------------------------
  * Display Entity
@@ -68,10 +69,14 @@ enum display_entity_stream_state {
 
 enum display_entity_interface_type {
 	DISPLAY_ENTITY_INTERFACE_DPI,
+	DISPLAY_ENTITY_INTERFACE_DBI,
 };
 
 struct display_entity_interface_params {
 	enum display_entity_interface_type type;
+	union {
+		struct mipi_dbi_interface_params dbi;
+	} p;
 };
 
 struct display_entity_control_ops {
diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h
new file mode 100644
index 0000000..876b69d
--- /dev/null
+++ b/include/video/mipi-dbi-bus.h
@@ -0,0 +1,125 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MIPI_DBI_BUS_H__
+#define __MIPI_DBI_BUS_H__
+
+#include <linux/device.h>
+
+struct mipi_dbi_bus;
+struct mipi_dbi_device;
+
+struct mipi_dbi_bus_ops {
+	int (*write_command)(struct mipi_dbi_bus *bus,
+			     struct mipi_dbi_device *dev, u16 cmd);
+	int (*write_data)(struct mipi_dbi_bus *bus, struct mipi_dbi_device *dev,
+			  const u8 *data, size_t len);
+	int (*read_data)(struct mipi_dbi_bus *bus, struct mipi_dbi_device *dev,
+			 u8 *data, size_t len);
+};
+
+struct mipi_dbi_bus {
+	struct device *dev;
+	const struct mipi_dbi_bus_ops *ops;
+};
+
+#define MIPI_DBI_MODULE_PREFIX		"mipi-dbi:"
+#define MIPI_DBI_NAME_SIZE		32
+
+struct mipi_dbi_device_id {
+	char name[MIPI_DBI_NAME_SIZE];
+	__kernel_ulong_t driver_data	/* Data private to the driver */
+			__aligned(sizeof(__kernel_ulong_t));
+};
+
+enum mipi_dbi_interface_type {
+	MIPI_DBI_INTERFACE_TYPE_A,
+	MIPI_DBI_INTERFACE_TYPE_B,
+};
+
+#define MIPI_DBI_INTERFACE_TE		(1 << 0)
+
+struct mipi_dbi_interface_params {
+	enum mipi_dbi_interface_type type;
+	unsigned int flags;
+
+	unsigned int cs_setup;
+	unsigned int rd_setup;
+	unsigned int rd_latch;
+	unsigned int rd_cycle;
+	unsigned int rd_hold;
+	unsigned int wr_setup;
+	unsigned int wr_cycle;
+	unsigned int wr_hold;
+};
+
+#define MIPI_DBI_FLAG_ALIGN_LEFT	(1 << 0)
+
+struct mipi_dbi_device {
+	const char *name;
+	int id;
+	struct device dev;
+
+	const struct mipi_dbi_device_id *id_entry;
+	struct mipi_dbi_bus *bus;
+
+	unsigned int flags;
+	unsigned int bus_width;
+	unsigned int data_width;
+};
+
+#define to_mipi_dbi_device(d)	container_of(d, struct mipi_dbi_device, dev)
+
+int mipi_dbi_device_register(struct mipi_dbi_device *dev,
+			     struct mipi_dbi_bus *bus);
+void mipi_dbi_device_unregister(struct mipi_dbi_device *dev);
+
+struct mipi_dbi_driver {
+	int(*probe)(struct mipi_dbi_device *);
+	int(*remove)(struct mipi_dbi_device *);
+	struct device_driver driver;
+	const struct mipi_dbi_device_id *id_table;
+};
+
+#define to_mipi_dbi_driver(d)	container_of(d, struct mipi_dbi_driver, driver)
+
+int mipi_dbi_driver_register(struct mipi_dbi_driver *drv);
+void mipi_dbi_driver_unregister(struct mipi_dbi_driver *drv);
+
+static inline void *mipi_dbi_get_drvdata(const struct mipi_dbi_device *dev)
+{
+	return dev_get_drvdata(&dev->dev);
+}
+
+static inline void mipi_dbi_set_drvdata(struct mipi_dbi_device *dev,
+					void *data)
+{
+	dev_set_drvdata(&dev->dev, data);
+}
+
+/* module_mipi_dbi_driver() - Helper macro for drivers that don't do
+ * anything special in module init/exit.  This eliminates a lot of
+ * boilerplate.  Each module may only use this macro once, and
+ * calling it replaces module_init() and module_exit()
+ */
+#define module_mipi_dbi_driver(__mipi_dbi_driver) \
+	module_driver(__mipi_dbi_driver, mipi_dbi_driver_register, \
+			mipi_dbi_driver_unregister)
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd);
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len);
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+			size_t len);
+
+#endif /* __MIPI_DBI_BUS__ */
-- 
1.7.8.6

[RFC v2 4/5] video: panel: Add R61505 panel support

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:46

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R61505 is a SYS-80 bus panel controller from Renesas.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig        |    9 +
 drivers/video/display/Makefile       |    1 +
 drivers/video/display/panel-r61505.c |  554 ++++++++++++++++++++++++++++++++++
 include/video/panel-r61505.h         |   27 ++
 4 files changed, 591 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/panel-r61505.c
 create mode 100644 include/video/panel-r61505.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index b04c8be..c88999c 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -18,4 +18,13 @@ config DISPLAY_PANEL_DPI
 
 	  If you are in doubt, say N.
 
+config DISPLAY_PANEL_R61505
+	tristate "Renesas R61505-based Display Panel"
+	select DISPLAY_MIPI_DBI
+	---help---
+	  Support panels based on the Renesas R61505 panel controller.
+	  Those panels are controlled through a MIPI DBI interface.
+
+	  If you are in doubt, say N.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 00ef1c2..4c68465 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
+obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
diff --git a/drivers/video/display/panel-r61505.c b/drivers/video/display/panel-r61505.c
new file mode 100644
index 0000000..d72d324
--- /dev/null
+++ b/drivers/video/display/panel-r61505.c
@@ -0,0 +1,554 @@
+/*
+ * Renesas R61505-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on SuperH MigoR Quarter VGA LCD Panel
+ * Copyright (C) 2008 Magnus Damm
+ * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd.
+ * Copyright (c) 2007 Ujjwal Pande
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <video/display.h>
+#include <video/mipi-dbi-bus.h>
+#include <video/panel-r61505.h>
+
+#define R61505_DEVICE_CODE			0x0000
+#define R61505_DEVICE_CODE_VALUE		0x1505
+#define R61505_DRIVER_OUTPUT_CONTROL		0x0001
+#define R61505_DRIVER_OUTPUT_CONTROL_SM		(1 << 10)
+#define R61505_DRIVER_OUTPUT_CONTROL_SS		(1 << 8)
+#define R61505_LCD_WAVEFORM			0x0002
+#define R61505_LCD_WAVEFORM_BC0			(1 << 9)
+#define R61505_LCD_WAVEFORM_EOR			(1 << 8)
+#define R61505_ENTRY_MODE			0x0003
+#define R61505_ENTRY_MODE_TRIREG		(1 << 15)
+#define R61505_ENTRY_MODE_DFM			(1 << 14)
+#define R61505_ENTRY_MODE_BGR			(1 << 12)
+#define R61505_ENTRY_MODE_HWM			(1 << 9)
+#define R61505_ENTRY_MODE_ORG			(1 << 7)
+#define R61505_ENTRY_MODE_ID1			(1 << 5)
+#define R61505_ENTRY_MODE_ID0			(1 << 4)
+#define R61505_ENTRY_MODE_AM			(1 << 3)
+#define R61505_RESIZE_CONTROL			0x0004
+#define R61505_RESIZE_CONTROL_RCV(n)		(((n) & 3) << 8)
+#define R61505_RESIZE_CONTROL_RCH(n)		(((n) & 3) << 4)
+#define R61505_RESIZE_CONTROL_RSZ_4		(3 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_2		(1 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_1		(0 << 0)
+#define R61505_DISPLAY_CONTROL1			0x0007
+#define R61505_DISPLAY_CONTROL1_PTDE1		(1 << 13)
+#define R61505_DISPLAY_CONTROL1_PTDE0		(1 << 12)
+#define R61505_DISPLAY_CONTROL1_BASEE		(1 << 8)
+#define R61505_DISPLAY_CONTROL1_VON		(1 << 6)
+#define R61505_DISPLAY_CONTROL1_GON		(1 << 5)
+#define R61505_DISPLAY_CONTROL1_DTE		(1 << 4)
+#define R61505_DISPLAY_CONTROL1_COL		(1 << 3)
+#define R61505_DISPLAY_CONTROL1_D1		(1 << 1)
+#define R61505_DISPLAY_CONTROL1_D0		(1 << 0)
+#define R61505_DISPLAY_CONTROL2			0x0008
+#define R61505_DISPLAY_CONTROL2_FP(n)		(((n) & 0xf) << 8)
+#define R61505_DISPLAY_CONTROL2_BP(n)		(((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL3			0x0009
+#define R61505_DISPLAY_CONTROL3_PTS(n)		(((n) & 7) << 8)
+#define R61505_DISPLAY_CONTROL3_PTG(n)		(((n) & 3) << 3)
+#define R61505_DISPLAY_CONTROL3_ICS(n)		(((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL4			0x000a
+#define R61505_DISPLAY_CONTROL4_FMARKOE		(1 << 3)
+#define R61505_DISPLAY_CONTROL4_FMI_6		(5 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_4		(3 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_2		(1 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_1		(0 << 0)
+#define R61505_EXT_DISPLAY_IF_CONTROL1		0x000c
+#define R61505_EXT_DISPLAY_IF_CONTROL1_ENC(n)	(((n) & 7) << 12)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_RM	(1 << 8)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_DM_VSYNC	(2 << 4)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_DM_RGB	(1 << 4)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_DM_ICLK	(0 << 4)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_RIM_6	(2 << 0)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_RIM_16	(1 << 0)
+#define R61505_EXT_DISPLAY_IF_CONTROL1_RIM_18	(0 << 0)
+#define R61505_FRAME_MARKER_CONTROL		0x000d
+#define R61505_FRAME_MARKER_CONTROL_FMP(n)	(((n) & 0x1ff) << 0)
+#define R61505_EXT_DISPLAY_IF_CONTROL2		0x000f
+#define R61505_POWER_CONTROL1			0x0010
+#define R61505_POWER_CONTROL1_SAP		(1 << 12)
+#define R61505_POWER_CONTROL1_BT(n)		(((n) & 0xf) << 8)
+#define R61505_POWER_CONTROL1_APE		(1 << 7)
+#define R61505_POWER_CONTROL1_AP_100		(3 << 4)
+#define R61505_POWER_CONTROL1_AP_075		(2 << 4)
+#define R61505_POWER_CONTROL1_AP_050		(1 << 4)
+#define R61505_POWER_CONTROL1_AP_HALT		(0 << 4)
+#define R61505_POWER_CONTROL1_DSTB		(1 << 2)
+#define R61505_POWER_CONTROL1_SLP		(1 << 1)
+#define R61505_POWER_CONTROL2			0x0011
+#define R61505_POWER_CONTROL2_DC1_HALT		(6 << 8)
+#define R61505_POWER_CONTROL2_DC1_FOSC_256	(4 << 8)
+#define R61505_POWER_CONTROL2_DC1_FOSC_128	(3 << 8)
+#define R61505_POWER_CONTROL2_DC1_FOSC_64	(2 << 8)
+#define R61505_POWER_CONTROL2_DC1_FOSC_32	(1 << 8)
+#define R61505_POWER_CONTROL2_DC1_FOSC_16	(0 << 8)
+#define R61505_POWER_CONTROL2_DC0_HALT		(6 << 4)
+#define R61505_POWER_CONTROL2_DC0_FOSC_16	(4 << 4)
+#define R61505_POWER_CONTROL2_DC0_FOSC_8	(3 << 4)
+#define R61505_POWER_CONTROL2_DC0_FOSC_4	(2 << 4)
+#define R61505_POWER_CONTROL2_DC0_FOSC_2	(1 << 4)
+#define R61505_POWER_CONTROL2_DC0_FOSC		(0 << 4)
+#define R61505_POWER_CONTROL2_VC_100		(7 << 0)
+#define R61505_POWER_CONTROL2_VC_076		(4 << 0)
+#define R61505_POWER_CONTROL2_VC_089		(1 << 0)
+#define R61505_POWER_CONTROL2_VC_094		(0 << 0)
+#define R61505_POWER_CONTROL3			0x0012
+#define R61505_POWER_CONTROL3_VCMR		(1 << 8)
+#define R61505_POWER_CONTROL3_PSON		(1 << 5)
+#define R61505_POWER_CONTROL3_PON		(1 << 4)
+#define R61505_POWER_CONTROL3_VRH(n)		(((n) & 0xf) << 0)
+#define R61505_POWER_CONTROL4			0x0013
+#define R61505_POWER_CONTROL4_VDV(n)		(((n) & 0xf) << 8)
+#define R61505_POWER_CONTROL5			0x0015
+#define R61505_POWER_CONTROL5_BLDM		(1 << 12)
+#define R61505_POWER_CONTROL6			0x0017
+#define R61505_POWER_CONTROL6_PSE		(1 << 0)
+#define R61505_RAM_ADDR_HORZ			0x0020
+#define R61505_RAM_ADDR_VERT			0x0021
+#define R61505_RAM_DATA				0x0022
+#define R61505_POWER_CONTROL7			0x0029
+#define R61505_POWER_CONTROL7_VCM1(n)		(((n) & 0x1f) << 0)
+#define R61505_GAMMA_CONTROL1			0x0030
+#define R61505_GAMMA_CONTROL2			0x0031
+#define R61505_GAMMA_CONTROL3			0x0032
+#define R61505_GAMMA_CONTROL4			0x0033
+#define R61505_GAMMA_CONTROL5			0x0034
+#define R61505_GAMMA_CONTROL6			0x0035
+#define R61505_GAMMA_CONTROL7			0x0036
+#define R61505_GAMMA_CONTROL8			0x0037
+#define R61505_GAMMA_CONTROL9			0x0038
+#define R61505_GAMMA_CONTROL10			0x0039
+#define R61505_GAMMA_CONTROL11			0x003a
+#define R61505_GAMMA_CONTROL12			0x003b
+#define R61505_GAMMA_CONTROL13			0x003c
+#define R61505_GAMMA_CONTROL14			0x003d
+#define R61505_WINDOW_HORZ_START		0x0050
+#define R61505_WINDOW_HORZ_END			0x0051
+#define R61505_WINDOW_VERT_START		0x0052
+#define R61505_WINDOW_VERT_END			0x0053
+#define R61505_DRIVER_OUTPUT_CONTROL2		0x0060
+#define R61505_DRIVER_OUTPUT_CONTROL2_GS	(1 << 15)
+#define R61505_DRIVER_OUTPUT_CONTROL2_NL(n)	(((n) & 0x3f) << 8)
+#define R61505_DRIVER_OUTPUT_CONTROL2_SCN(n)	(((n) & 0x3f) << 0)
+#define R61505_BASE_IMG_DISPLAY_CONTROL		0x0061
+#define R61505_BASE_IMG_DISPLAY_CONTROL_NDL	(1 << 2)
+#define R61505_BASE_IMG_DISPLAY_CONTROL_VLE	(1 << 1)
+#define R61505_BASE_IMG_DISPLAY_CONTROL_REV	(1 << 0)
+#define R61505_VERTICAL_SCROLL_CONTROL		0x006a
+#define R61505_PANEL_IF_CONTROL1		0x0090
+#define R61505_PANEL_IF_CONTROL1_DIVI(n)	(((n) & 3) << 8)
+#define R61505_PANEL_IF_CONTROL1_RTNI(n)	(((n) & 0x1f) << 0)
+#define R61505_PANEL_IF_CONTROL2		0x0092
+#define R61505_PANEL_IF_CONTROL2_NOWI(n)	(((n) & 7) << 8)
+#define R61505_PANEL_IF_CONTROL3		0x0093
+#define R61505_PANEL_IF_CONTROL3_MCP(n)		(((n) & 7) << 8)
+#define R61505_PANEL_IF_CONTROL4		0x0095
+#define R61505_PANEL_IF_CONTROL5		0x0097
+#define R61505_PANEL_IF_CONTROL6		0x0098
+#define R61505_OSCILLATION_CONTROL		0x00a4
+#define R61505_OSCILLATION_CONTROL_CALB		(1 << 0)
+
+struct r61505 {
+	struct display_entity entity;
+	struct mipi_dbi_device *dbi;
+	const struct panel_r61505_platform_data *pdata;
+};
+
+#define to_panel(p)	container_of(p, struct r61505, entity)
+
+/* -----------------------------------------------------------------------------
+ * Read, write and reset
+ */
+
+static void r61505_write(struct r61505 *panel, u16 reg, u16 data)
+{
+	u8 buffer[2] = { data >> 8, data & 0xff };
+
+	mipi_dbi_write_command(panel->dbi, reg);
+	mipi_dbi_write_data(panel->dbi, buffer, 2);
+}
+
+static u16 r61505_read(struct r61505 *panel, u16 reg)
+{
+	u8 buffer[2];
+	int ret;
+
+	mipi_dbi_write_command(panel->dbi, reg);
+	ret = mipi_dbi_read_data(panel->dbi, buffer, 2);
+	if (ret < 0)
+		return ret;
+
+	return (buffer[0] << 8) | buffer[1];
+}
+
+static void r61505_write_array(struct r61505 *panel,
+				 const u16 *data, unsigned int len)
+{
+	unsigned int i;
+
+	for (i = 0; i < len; i += 2)
+		r61505_write(panel, data[i], data[i + 1]);
+}
+
+static void r61505_reset(struct r61505 *panel)
+{
+	if (panel->pdata->reset < 0)
+		return;
+
+	gpio_set_value(panel->pdata->reset, 0);
+	usleep_range(2000, 2500);
+	gpio_set_value(panel->pdata->reset, 1);
+	usleep_range(1000, 1500);
+}
+
+/* -----------------------------------------------------------------------------
+ * Configuration
+ */
+
+static const unsigned short sync_data[] = {
+	0x0000, 0x0000,
+	0x0000, 0x0000,
+	0x0000, 0x0000,
+	0x0000, 0x0000,
+};
+
+static const unsigned short magic0_data[] = {
+	R61505_DISPLAY_CONTROL2, R61505_DISPLAY_CONTROL2_FP(8) |
+				 R61505_DISPLAY_CONTROL2_BP(8),
+	R61505_PANEL_IF_CONTROL1, R61505_PANEL_IF_CONTROL1_RTNI(26),
+	R61505_DISPLAY_CONTROL1, R61505_DISPLAY_CONTROL1_D0,
+	R61505_POWER_CONTROL6, R61505_POWER_CONTROL6_PSE,
+	0x0019, 0x0000,
+	R61505_POWER_CONTROL1, R61505_POWER_CONTROL1_SAP |
+			       R61505_POWER_CONTROL1_BT(7) |
+			       R61505_POWER_CONTROL1_APE |
+			       R61505_POWER_CONTROL1_AP_100,
+	R61505_POWER_CONTROL2, R61505_POWER_CONTROL2_DC1_FOSC_32 |
+			       R61505_POWER_CONTROL2_DC0_FOSC_2 | 6,
+	R61505_POWER_CONTROL3, R61505_POWER_CONTROL3_VCMR | 0x80 |
+			       R61505_POWER_CONTROL3_PON |
+			       R61505_POWER_CONTROL3_VRH(8),
+	R61505_POWER_CONTROL4, 0x1000 | R61505_POWER_CONTROL4_VDV(4),
+	R61505_POWER_CONTROL7, R61505_POWER_CONTROL7_VCM1(12),
+	R61505_POWER_CONTROL3, R61505_POWER_CONTROL3_VCMR | 0x80 |
+			       R61505_POWER_CONTROL3_PSON |
+			       R61505_POWER_CONTROL3_PON |
+			       R61505_POWER_CONTROL3_VRH(8),
+};
+
+static const unsigned short magic1_data[] = {
+	R61505_GAMMA_CONTROL1, 0x0307,
+	R61505_GAMMA_CONTROL2, 0x0303,
+	R61505_GAMMA_CONTROL3, 0x0603,
+	R61505_GAMMA_CONTROL4, 0x0202,
+	R61505_GAMMA_CONTROL5, 0x0202,
+	R61505_GAMMA_CONTROL6, 0x0202,
+	R61505_GAMMA_CONTROL7, 0x1f1f,
+	R61505_GAMMA_CONTROL8, 0x0303,
+	R61505_GAMMA_CONTROL9, 0x0303,
+	R61505_GAMMA_CONTROL10, 0x0603,
+	R61505_GAMMA_CONTROL11, 0x0202,
+	R61505_GAMMA_CONTROL12, 0x0102,
+	R61505_GAMMA_CONTROL13, 0x0204,
+	R61505_GAMMA_CONTROL14, 0x0000,
+	R61505_DRIVER_OUTPUT_CONTROL, R61505_DRIVER_OUTPUT_CONTROL_SS,
+	R61505_LCD_WAVEFORM, R61505_LCD_WAVEFORM_BC0 |
+			     R61505_LCD_WAVEFORM_EOR,
+	R61505_ENTRY_MODE, R61505_ENTRY_MODE_DFM |
+			   R61505_ENTRY_MODE_BGR |
+			   R61505_ENTRY_MODE_ID1 |
+			   R61505_ENTRY_MODE_AM,
+	R61505_RAM_ADDR_HORZ, 239,
+	R61505_RAM_ADDR_VERT, 0,
+	R61505_RESIZE_CONTROL, R61505_RESIZE_CONTROL_RCV(0) |
+			       R61505_RESIZE_CONTROL_RCH(0) |
+			       R61505_RESIZE_CONTROL_RSZ_1,
+	R61505_DISPLAY_CONTROL3, R61505_DISPLAY_CONTROL3_PTS(0) |
+				 R61505_DISPLAY_CONTROL3_PTG(0) |
+				 R61505_DISPLAY_CONTROL3_ICS(0),
+	R61505_DISPLAY_CONTROL4, R61505_DISPLAY_CONTROL4_FMARKOE |
+				 R61505_DISPLAY_CONTROL4_FMI_1,
+	R61505_EXT_DISPLAY_IF_CONTROL1, R61505_EXT_DISPLAY_IF_CONTROL1_ENC(0) |
+					R61505_EXT_DISPLAY_IF_CONTROL1_DM_ICLK |
+					R61505_EXT_DISPLAY_IF_CONTROL1_RIM_18,
+	R61505_FRAME_MARKER_CONTROL, R61505_FRAME_MARKER_CONTROL_FMP(0),
+	R61505_POWER_CONTROL5, 0x8000,
+};
+
+static const unsigned short magic2_data[] = {
+	R61505_BASE_IMG_DISPLAY_CONTROL, R61505_BASE_IMG_DISPLAY_CONTROL_REV,
+	R61505_PANEL_IF_CONTROL2, R61505_PANEL_IF_CONTROL2_NOWI(1),
+	R61505_PANEL_IF_CONTROL3, R61505_PANEL_IF_CONTROL3_MCP(1),
+	R61505_DISPLAY_CONTROL1, R61505_DISPLAY_CONTROL1_GON |
+				 R61505_DISPLAY_CONTROL1_D0,
+};
+
+static const unsigned short magic3_data[] = {
+	R61505_POWER_CONTROL1, R61505_POWER_CONTROL1_SAP |
+			       R61505_POWER_CONTROL1_BT(6) |
+			       R61505_POWER_CONTROL1_APE |
+			       R61505_POWER_CONTROL1_AP_100,
+	R61505_POWER_CONTROL2, R61505_POWER_CONTROL2_DC1_FOSC_32 |
+			       R61505_POWER_CONTROL2_DC0_FOSC_2 |
+			       R61505_POWER_CONTROL2_VC_089,
+	R61505_DISPLAY_CONTROL1, R61505_DISPLAY_CONTROL1_VON |
+				 R61505_DISPLAY_CONTROL1_GON |
+				 R61505_DISPLAY_CONTROL1_D0,
+};
+
+static void r61505_enable_panel(struct r61505 *panel)
+{
+	unsigned long hactive = panel->pdata->mode->hactive;
+	unsigned long vactive = panel->pdata->mode->vactive;
+	unsigned int i;
+
+	r61505_write_array(panel, sync_data, ARRAY_SIZE(sync_data));
+
+	r61505_write(panel, R61505_OSCILLATION_CONTROL,
+		     R61505_OSCILLATION_CONTROL_CALB);
+	usleep_range(10000, 11000);
+
+	r61505_write(panel, R61505_DRIVER_OUTPUT_CONTROL2,
+		     R61505_DRIVER_OUTPUT_CONTROL2_NL((hactive / 8) - 1));
+	r61505_write_array(panel, magic0_data, ARRAY_SIZE(magic0_data));
+	usleep_range(100000, 101000);
+
+	r61505_write_array(panel, magic1_data, ARRAY_SIZE(magic1_data));
+
+	r61505_write(panel, R61505_WINDOW_HORZ_START, 239 - (vactive - 1));
+	r61505_write(panel, R61505_WINDOW_HORZ_END, 239);
+	r61505_write(panel, R61505_WINDOW_VERT_START, 0);
+	r61505_write(panel, R61505_WINDOW_VERT_END, hactive - 1);
+
+	r61505_write_array(panel, magic2_data, ARRAY_SIZE(magic2_data));
+	usleep_range(10000, 11000);
+
+	r61505_write_array(panel, magic3_data, ARRAY_SIZE(magic3_data));
+	usleep_range(40000, 41000);
+
+	/* Clear GRAM to avoid displaying garbage. */
+	r61505_write(panel, R61505_RAM_ADDR_HORZ, 0);
+	r61505_write(panel, R61505_RAM_ADDR_VERT, 0);
+
+	for (i = 0; i < (hactive * 256); i++) /* yes, 256 words per line */
+		r61505_write(panel, R61505_RAM_DATA, 0);
+
+	r61505_write(panel, R61505_RAM_ADDR_HORZ, 0);
+	r61505_write(panel, R61505_RAM_ADDR_VERT, 0);
+}
+
+static void r61505_disable_panel(struct r61505 *panel)
+{
+	r61505_reset(panel);
+}
+
+static void r61505_display_on(struct r61505 *panel)
+{
+	r61505_write(panel, R61505_DISPLAY_CONTROL1,
+		     R61505_DISPLAY_CONTROL1_BASEE |
+		     R61505_DISPLAY_CONTROL1_VON |
+		     R61505_DISPLAY_CONTROL1_GON |
+		     R61505_DISPLAY_CONTROL1_DTE |
+		     R61505_DISPLAY_CONTROL1_D1 |
+		     R61505_DISPLAY_CONTROL1_D0);
+	usleep_range(40000, 41000);
+}
+
+static void r61505_display_off(struct r61505 *panel)
+{
+	r61505_write(panel, R61505_DISPLAY_CONTROL1,
+		     R61505_DISPLAY_CONTROL1_VON |
+		     R61505_DISPLAY_CONTROL1_GON |
+		     R61505_DISPLAY_CONTROL1_D0);
+}
+
+/* -----------------------------------------------------------------------------
+ * Panel operations
+ */
+
+static const struct display_entity_interface_params r61505_dbi_params = {
+	.type = DISPLAY_ENTITY_INTERFACE_DBI,
+	.p.dbi = {
+		.type = MIPI_DBI_INTERFACE_TYPE_B,
+		.cs_setup = 1,
+		.wr_setup = 0,
+		.wr_cycle = 10,
+		.wr_hold = 9,
+		.rd_setup = 14,
+		.rd_latch = 24,
+		.rd_cycle = 52,
+		.rd_hold = 24,
+	},
+};
+
+static int r61505_set_state(struct display_entity *entity,
+			    enum display_entity_state state)
+{
+	struct r61505 *panel = to_panel(entity);
+
+	switch (state) {
+	case DISPLAY_ENTITY_STATE_OFF:
+		r61505_disable_panel(panel);
+		break;
+
+	case DISPLAY_ENTITY_STATE_STANDBY:
+		if (entity->state = DISPLAY_ENTITY_STATE_OFF)
+			r61505_enable_panel(panel);
+		else
+			r61505_display_off(panel);
+		break;
+
+	case DISPLAY_ENTITY_STATE_ON:
+		if (entity->state = DISPLAY_ENTITY_STATE_OFF)
+			r61505_enable_panel(panel);
+
+		r61505_display_on(panel);
+		break;
+	}
+
+	return 0;
+}
+
+static int r61505_update(struct display_entity *entity)
+{
+	struct r61505 *panel = to_panel(entity);
+
+	mipi_dbi_write_command(panel->dbi, R61505_RAM_DATA);
+	usleep_range(100000, 101000);
+
+	display_entity_set_stream(entity->source,
+				  DISPLAY_ENTITY_STREAM_SINGLE_SHOT);
+	return 0;
+}
+
+static int r61505_get_modes(struct display_entity *entity,
+			    const struct videomode **modes)
+{
+	struct r61505 *panel = to_panel(entity);
+
+	*modes = panel->pdata->mode;
+	return 1;
+}
+
+static int r61505_get_size(struct display_entity *entity,
+			   unsigned int *width, unsigned int *height)
+{
+	struct r61505 *panel = to_panel(entity);
+
+	*width = panel->pdata->width;
+	*height = panel->pdata->height;
+	return 0;
+}
+
+static int r61505_get_params(struct display_entity *entity,
+			     struct display_entity_interface_params *params)
+{
+	*params = r61505_dbi_params;
+	return 0;
+}
+
+static const struct display_entity_control_ops r61505_control_ops = {
+	.set_state = r61505_set_state,
+	.update = r61505_update,
+	.get_modes = r61505_get_modes,
+	.get_size = r61505_get_size,
+	.get_params = r61505_get_params,
+};
+
+static void r61505_release(struct display_entity *entity)
+{
+	struct r61505 *panel = to_panel(entity);
+
+	kfree(panel);
+}
+
+static int r61505_remove(struct mipi_dbi_device *dev)
+{
+	struct r61505 *panel = mipi_dbi_get_drvdata(dev);
+
+	mipi_dbi_set_drvdata(dev, NULL);
+	display_entity_unregister(&panel->entity);
+
+	return 0;
+}
+
+static int __devinit r61505_probe(struct mipi_dbi_device *dev)
+{
+	const struct panel_r61505_platform_data *pdata = dev->dev.platform_data;
+	struct r61505 *panel;
+	int ret;
+
+	if (pdata = NULL)
+		return -ENODEV;
+
+	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+	if (panel = NULL)
+		return -ENOMEM;
+
+	panel->pdata = pdata;
+	panel->dbi = dev;
+
+	dev->flags = MIPI_DBI_FLAG_ALIGN_LEFT;
+	dev->bus_width = pdata->bus_width;
+	mipi_dbi_set_data_width(dev, 16);
+
+	r61505_reset(panel);
+	r61505_write_array(panel, sync_data, ARRAY_SIZE(sync_data));
+
+	if (r61505_read(panel, 0) != R61505_DEVICE_CODE_VALUE) {
+		kfree(panel);
+		return -ENODEV;
+	}
+
+	panel->entity.dev = &dev->dev;
+	panel->entity.release = r61505_release;
+	panel->entity.ops.ctrl = &r61505_control_ops;
+
+	ret = display_entity_register(&panel->entity);
+	if (ret < 0) {
+		kfree(panel);
+		return ret;
+	}
+
+	mipi_dbi_set_drvdata(dev, panel);
+
+	return 0;
+}
+
+static const struct dev_pm_ops r61505_dev_pm_ops = {
+};
+
+static struct mipi_dbi_driver r61505_driver = {
+	.probe = r61505_probe,
+	.remove = r61505_remove,
+	.driver = {
+		.name = "panel_r61505",
+		.owner = THIS_MODULE,
+		.pm = &r61505_dev_pm_ops,
+	},
+};
+
+module_mipi_dbi_driver(r61505_driver);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("Renesas R61505-based Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-r61505.h b/include/video/panel-r61505.h
new file mode 100644
index 0000000..fe4a368
--- /dev/null
+++ b/include/video/panel-r61505.h
@@ -0,0 +1,27 @@
+/*
+ * Renesas R61505-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_R61505_H__
+#define __PANEL_R61505_H__
+
+#include <linux/videomode.h>
+
+struct panel_r61505_platform_data {
+	unsigned long width;		/* Panel width in mm */
+	unsigned long height;		/* Panel height in mm */
+	const struct videomode *mode;
+
+	unsigned int bus_width;
+	int reset;			/* Reset GPIO */
+};
+
+#endif /* __PANEL_R61505_H__ */
-- 
1.7.8.6

[RFC v2 5/5] video: panel: Add R61517 panel support

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-11-22 21:44:48

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R61517 is a MIPI DBI panel controller from Renesas.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig        |    9 +
 drivers/video/display/Makefile       |    1 +
 drivers/video/display/panel-r61517.c |  447 ++++++++++++++++++++++++++++++++++
 include/video/panel-r61517.h         |   28 ++
 4 files changed, 485 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/panel-r61517.c
 create mode 100644 include/video/panel-r61517.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index c88999c..13b6aaf 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -27,4 +27,13 @@ config DISPLAY_PANEL_R61505
 
 	  If you are in doubt, say N.
 
+config DISPLAY_PANEL_R61517
+	tristate "Renesas R61517-based Display Panel"
+	select DISPLAY_MIPI_DBI
+	---help---
+	  Support panels based on the Renesas R61517 panel controller.
+	  Those panels are controlled through a MIPI DBI interface.
+
+	  If you are in doubt, say N.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 4c68465..482bec7 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/panel-r61517.c b/drivers/video/display/panel-r61517.c
new file mode 100644
index 0000000..b4dced4
--- /dev/null
+++ b/drivers/video/display/panel-r61517.c
@@ -0,0 +1,447 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+
+#include <video/display.h>
+#include <video/mipi-dbi-bus.h>
+#include <video/mipi_display.h>
+#include <video/panel-r61517.h>
+
+struct r61517 {
+	struct display_entity entity;
+	struct mipi_dbi_device *dbi;
+	const struct panel_r61517_platform_data *pdata;
+};
+
+#define to_panel(p)	container_of(p, struct r61517, entity)
+
+/* -----------------------------------------------------------------------------
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 cmd)
+{
+	mipi_dbi_write_command(panel->dbi, cmd);
+}
+
+static void r61517_write_data(struct r61517 *panel, u8 data)
+{
+	mipi_dbi_write_data(panel->dbi, &data, 1);
+}
+
+static int r61517_read_data(struct r61517 *panel)
+{
+	u8 data;
+	int ret;
+
+	ret = mipi_dbi_read_data(panel->dbi, &data, 1);
+	if (ret < 0)
+		return ret;
+
+	return data;
+}
+
+static void r61517_write(struct r61517 *panel, u8 reg, const u8 *data,
+			 size_t len)
+{
+	mipi_dbi_write_command(panel->dbi, reg);
+	mipi_dbi_write_data(panel->dbi, data, len);
+}
+
+static void r61517_write8(struct r61517 *panel, u8 reg, u8 data)
+{
+	r61517_write(panel, reg, &data, 1);
+}
+
+static void r61517_write16(struct r61517 *panel, u8 reg, u16 data)
+{
+	u8 buffer[2] = { (data >> 8) & 0xff, (data >> 0) & 0xff };
+
+	r61517_write(panel, reg, buffer, 2);
+}
+
+static void r61517_write32(struct r61517 *panel, u8 reg, u32 data)
+{
+	u8 buffer[4] = { (data >> 24) & 0xff, (data >> 16) & 0xff,
+			 (data >>  8) & 0xff, (data >>  0) & 0xff };
+
+	r61517_write(panel, reg, buffer, 4);
+}
+
+#define r61517_write_array(p, c, a) \
+	r61517_write((p), (c), (a), ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+	gpio_set_value(panel->pdata->protect, 0);	/* PROTECT/ -> L */
+	gpio_set_value(panel->pdata->reset, 0);		/* LCD_RST/ -> L */
+	gpio_set_value(panel->pdata->protect, 1);	/* PROTECT/ -> H */
+	usleep_range(1100, 1200);
+	gpio_set_value(panel->pdata->reset, 1);		/* LCD_RST/ -> H */
+	usleep_range(10, 100);
+	gpio_set_value(panel->pdata->protect, 0);	/* PROTECT/ -> L */
+	msleep(20);
+}
+
+/* -----------------------------------------------------------------------------
+ * Configuration
+ */
+
+static const u8 data_frame_if[] = {
+	0x02, /* WEMODE: 1=cont, 0=one-shot */
+	0x00, 0x00,
+	0x00, /* EPF, DFM */
+	0x02, /* RIM[1] : 1 (18bpp) */
+};
+
+static const u8 data_panel[] = {
+	0x0b,
+	0x63, /* 400 lines */
+	0x04, 0x00, 0x00, 0x04, 0x11, 0x00, 0x00,
+};
+
+static const u8 data_timing[] = {
+	0x00, 0x00, 0x13, 0x08, 0x08,
+};
+
+static const u8 data_timing_src[] = {
+	0x11, 0x01, 0x00, 0x01,
+};
+
+static const u8 data_gamma[] = {
+	0x01, 0x02, 0x08, 0x23,	0x03, 0x0c, 0x00, 0x06,	0x00, 0x00,
+	0x01, 0x00, 0x0c, 0x23, 0x03, 0x08, 0x02, 0x06, 0x00, 0x00,
+};
+
+static const u8 data_power[] = {
+	0x07, 0xc5, 0xdc, 0x02,	0x33, 0x0a,
+};
+
+static const u8 data_vcom[] = {
+	0x00, 0x0f, 0x02,
+};
+
+static unsigned long r61517_read_device_code(struct r61517 *panel)
+{
+	/* access protect OFF */
+	r61517_write8(panel, 0xb0, 0);
+
+	/* deep standby OFF */
+	r61517_write8(panel, 0xb1, 0);
+
+	/* device code command */
+	r61517_write_command(panel, 0xbf);
+	mdelay(50);
+
+	/* dummy read */
+	r61517_read_data(panel);
+
+	/* read device code */
+	return (r61517_read_data(panel) << 24) |
+	       (r61517_read_data(panel) << 16) |
+	       (r61517_read_data(panel) << 8) |
+	       (r61517_read_data(panel) << 0);
+}
+
+static void r61517_write_memory_start(struct r61517 *panel)
+{
+	r61517_write_command(panel, MIPI_DCS_WRITE_MEMORY_START);
+}
+
+static void r61517_clear_memory(struct r61517 *panel)
+{
+	unsigned int size = panel->pdata->mode->hactive
+			  * panel->pdata->mode->vactive;
+	unsigned int i;
+
+	r61517_write_memory_start(panel);
+
+	for (i = 0; i < size; i++)
+		r61517_write_data(panel, 0);
+}
+
+static void r61517_enable_panel(struct r61517 *panel)
+{
+	/* access protect off */
+	r61517_write8(panel, 0xb0, 0);
+
+	/* exit deep standby mode */
+	r61517_write8(panel, 0xb1, 0);
+
+	/* frame memory I/F */
+	r61517_write_array(panel, 0xb3, data_frame_if);
+
+	/* display mode and frame memory write mode */
+	r61517_write8(panel, 0xb4, 0); /* DBI, internal clock */
+
+	/* panel */
+	r61517_write_array(panel, 0xc0, data_panel);
+
+	/* timing (normal) */
+	r61517_write_array(panel, 0xc1, data_timing);
+
+	/* timing (partial) */
+	r61517_write_array(panel, 0xc2, data_timing);
+
+	/* timing (idle) */
+	r61517_write_array(panel, 0xc3, data_timing);
+
+	/* timing (source/VCOM/gate driving) */
+	r61517_write_array(panel, 0xc4, data_timing_src);
+
+	/* gamma (red) */
+	r61517_write_array(panel, 0xc8, data_gamma);
+
+	/* gamma (green) */
+	r61517_write_array(panel, 0xc9, data_gamma);
+
+	/* gamma (blue) */
+	r61517_write_array(panel, 0xca, data_gamma);
+
+	/* power (common) */
+	r61517_write_array(panel, 0xd0, data_power);
+
+	/* VCOM */
+	r61517_write_array(panel, 0xd1, data_vcom);
+
+	/* power (normal) */
+	r61517_write16(panel, 0xd2, 0x6324);
+
+	/* power (partial) */
+	r61517_write16(panel, 0xd3, 0x6324);
+
+	/* power (idle) */
+	r61517_write16(panel, 0xd4, 0x6324);
+
+	r61517_write16(panel, 0xd8, 0x7777);
+
+	/* TE signal */
+	r61517_write8(panel, MIPI_DCS_SET_TEAR_ON, 0);
+
+	/* TE signal line */
+	r61517_write16(panel, MIPI_DCS_SET_TEAR_SCANLINE, 0);
+
+	/* column address */
+	r61517_write32(panel, MIPI_DCS_SET_COLUMN_ADDRESS,
+		       panel->pdata->mode->hactive - 1);
+
+	/* page address */
+	r61517_write32(panel, MIPI_DCS_SET_PAGE_ADDRESS,
+		       panel->pdata->mode->vactive - 1);
+
+	/* exit sleep mode */
+	r61517_write_command(panel, MIPI_DCS_EXIT_SLEEP_MODE);
+
+	mdelay(120);
+
+	/* clear vram */
+	r61517_clear_memory(panel);
+}
+
+static void r61517_disable_panel(struct r61517 *panel)
+{
+	r61517_reset(panel);
+}
+
+static void r61517_display_on(struct r61517 *panel)
+{
+	r61517_write_command(panel, MIPI_DCS_SET_DISPLAY_ON);
+	mdelay(1);
+}
+
+static void r61517_display_off(struct r61517 *panel)
+{
+	r61517_write_command(panel, MIPI_DCS_SET_DISPLAY_OFF);
+}
+
+/* -----------------------------------------------------------------------------
+ * Panel operations
+ */
+
+static const struct display_entity_interface_params r61517_dbi_params = {
+	.type = DISPLAY_ENTITY_INTERFACE_DBI,
+	.p.dbi = {
+		.type = MIPI_DBI_INTERFACE_TYPE_B,
+		.flags = MIPI_DBI_INTERFACE_TE,
+		.cs_setup = 1,
+		.wr_setup = 1,
+		.wr_cycle = 9,
+		.wr_hold = 4,
+		.rd_setup = 1,
+		.rd_latch = 20,
+		.rd_cycle = 41,
+		.rd_hold = 20,
+	},
+};
+
+static int r61517_set_state(struct display_entity *entity,
+			    enum display_entity_state state)
+{
+	struct r61517 *panel = to_panel(entity);
+
+	switch (state) {
+	case DISPLAY_ENTITY_STATE_OFF:
+		r61517_disable_panel(panel);
+		break;
+
+	case DISPLAY_ENTITY_STATE_STANDBY:
+		if (entity->state = DISPLAY_ENTITY_STATE_OFF)
+			r61517_enable_panel(panel);
+		else
+			r61517_display_off(panel);
+		break;
+
+	case DISPLAY_ENTITY_STATE_ON:
+		if (entity->state = DISPLAY_ENTITY_STATE_OFF)
+			r61517_enable_panel(panel);
+
+		r61517_display_on(panel);
+		break;
+	}
+
+	return 0;
+}
+
+static int r61517_update(struct display_entity *entity)
+{
+	struct r61517 *panel = to_panel(entity);
+
+	r61517_write_memory_start(panel);
+
+	display_entity_set_stream(entity->source,
+				  DISPLAY_ENTITY_STREAM_SINGLE_SHOT);
+	return 0;
+}
+
+static int r61517_get_modes(struct display_entity *entity,
+			    const struct videomode **modes)
+{
+	struct r61517 *panel = to_panel(entity);
+
+	*modes = panel->pdata->mode;
+	return 1;
+}
+
+static int r61517_get_size(struct display_entity *entity,
+			   unsigned int *width, unsigned int *height)
+{
+	struct r61517 *panel = to_panel(entity);
+
+	*width = panel->pdata->width;
+	*height = panel->pdata->height;
+	return 0;
+}
+
+static int r61517_get_params(struct display_entity *entity,
+			     struct display_entity_interface_params *params)
+{
+	*params = r61517_dbi_params;
+	return 0;
+}
+
+static const struct display_entity_control_ops r61517_control_ops = {
+	.set_state = r61517_set_state,
+	.update = r61517_update,
+	.get_modes = r61517_get_modes,
+	.get_size = r61517_get_size,
+	.get_params = r61517_get_params,
+};
+
+static void r61517_release(struct display_entity *entity)
+{
+	struct r61517 *panel = to_panel(entity);
+
+	kfree(panel);
+}
+
+static int r61517_remove(struct mipi_dbi_device *dev)
+{
+	struct r61517 *panel = mipi_dbi_get_drvdata(dev);
+
+	mipi_dbi_set_drvdata(dev, NULL);
+	display_entity_unregister(&panel->entity);
+
+	return 0;
+}
+
+static int __devinit r61517_probe(struct mipi_dbi_device *dev)
+{
+	const struct panel_r61517_platform_data *pdata = dev->dev.platform_data;
+	struct r61517 *panel;
+	int ret;
+
+	if (pdata = NULL)
+		return -ENODEV;
+
+	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+	if (panel = NULL)
+		return -ENOMEM;
+
+	panel->pdata = pdata;
+	panel->dbi = dev;
+
+	dev->bus_width = pdata->bus_width;
+	mipi_dbi_set_data_width(dev, 8);
+
+	r61517_reset(panel);
+
+	if (r61517_read_device_code(panel) != 0x01221517) {
+		kfree(panel);
+		return -ENODEV;
+	}
+
+	pr_info("R61517 panel controller detected.\n");
+
+	panel->entity.dev = &dev->dev;
+	panel->entity.release = r61517_release;
+	panel->entity.ops.ctrl = &r61517_control_ops;
+
+	ret = display_entity_register(&panel->entity);
+	if (ret < 0) {
+		kfree(panel);
+		return ret;
+	}
+
+	mipi_dbi_set_drvdata(dev, panel);
+
+	return 0;
+}
+
+static const struct dev_pm_ops r61517_dev_pm_ops = {
+};
+
+static struct mipi_dbi_driver r61517_driver = {
+	.probe = r61517_probe,
+	.remove = r61517_remove,
+	.driver = {
+		.name = "panel_r61517",
+		.owner = THIS_MODULE,
+		.pm = &r61517_dev_pm_ops,
+	},
+};
+
+module_mipi_dbi_driver(r61517_driver);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("Renesas R61517-based Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-r61517.h b/include/video/panel-r61517.h
new file mode 100644
index 0000000..988f2bc
--- /dev/null
+++ b/include/video/panel-r61517.h
@@ -0,0 +1,28 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_R61517_H__
+#define __PANEL_R61517_H__
+
+#include <linux/videomode.h>
+
+struct panel_r61517_platform_data {
+	unsigned long width;		/* Panel width in mm */
+	unsigned long height;		/* Panel height in mm */
+	const struct videomode *mode;
+
+	unsigned int bus_width;
+	int protect;			/* Protect GPIO */
+	int reset;			/* Reset GPIO */
+};
+
+#endif /* __PANEL_R61517_H__ */
-- 
1.7.8.6

Re: [RFC v2 0/5] Common Display Framework

From: Tomi Valkeinen <hidden>
Date: 2012-11-23 14:52:11

Hi,

On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).

Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.


What I suggest is take a simpler approach, something alike to how
regulators or gpios are used, even if slightly more complex than those:
the entity that has a video output (SoC's DSS, external chips) offers
that video output as resource. It doesn't know or care who uses it. The
user of the video output (panel, external chips) will find the video
output (to which it is connected in the HW) by some means, and will use
different operations on that output to operate the device.

This would give us something like the following DT data:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

/ {
	dpi-panel: dpi-panel {
		source = <&dpi0>;
		...panel data...;
	};
};

The panel driver would do something like this in its probe:

int dpi_panel_probe()
{
	// Find the video source, increase ref
	src = get_video_source_from_of("source");

	// Reserve the video source for us. others can still get and
	// observe it, but cannot use it as video data source.
	// I think this should cascade upstream, so that after this call
	// each video entity from the panel to the SoC's CRTC is
	// reserved and locked for this video pipeline.
	reserve_video_source(src);

	// set DPI HW configuration, like DPI data lines. The
	// configuration would come from panel's platform data
	set_dpi_config(src, config);

	// register this panel as a display.
	register_display(this);
}


The DSS's dpi driver would do something like:

int dss_dpi_probe()
{
	// register as a DPI video source
	register_video_source(this);
}

A DSI-2-DPI chip would do something like:

int dsi2dpi_probe()
{
	// get, reserve and config the DSI bus from SoC
	src = get_video_source_from_of("source");
	reserve_video_source(src);
	set_dsi_config(src, config);

	// register as a DPI video source
	register_video_source(this);
}


Here we wouldn't have similar display_entity as you have, but video
sources and displays. Video sources are elements in the video pipeline,
and a video source is used only by the next downstream element. The last
element in the pipeline would not be a video source, but a display,
which would be used by the upper layer.

Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Thierry Reding <hidden>
Date: 2012-11-23 19:56:22

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 entity is registered. The reason for this asynchronous
mode of operation, compared to how drivers acquire regulator or clock
resources, is that the display entities can use resources provided by the
display driver. For instance a panel can be a child of the DBI or DSI bus
controlled by the display device, or use a clock provided by that device. We
can't defer the display device probe until the panel is registered and also
defer the panel device probe until the display is registered. As most display
drivers need to handle output devices hotplug (HDMI monitors for instance),
handling other display entities through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each other.
Those circular references would make driver unloading impossible. One possible
solution to this problem would be to simulate an unplug event for the display
entity, to force the display driver to release the dislay entities it uses. We
would need a userspace API for that though. Better solutions would of course
be welcome.
Maybe I don't understand all of the underlying issues correctly, but a
parent/child model would seem like a better solution to me. We discussed
this back when designing the DT bindings for Tegra DRM and came to the
conclusion that the output resource of the display controller (RGB,
HDMI, DSI or TVO) was the most suitable candidate to be the parent of
the panel or display attached to it. The reason for that decision was
that it keeps the flow of data or addressing of nodes consistent. So the
chain would look something like this (on Tegra):

	CPU
	+-host1x
	  +-dc
	    +-rgb
	    | +-panel
	    +-hdmi
	      +-monitor

In a natural way this makes the output resource the master of the panel
or display. From a programming point of view this becomes quite easy to
implement and is very similar to how other busses like I2C or SPI are
modelled. In device tree these would be represented as subnodes, while
with platform data some kind of lookup could be done like for regulators
or alternatively a board setup registration mechanism like what's in
place for I2C or SPI.

Thierry

Re: [RFC v2 0/5] Common Display Framework

From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2012-11-23 21:42:05

Hi Laurent,

On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
 
The CDF models this using a Russian doll's model. From the display controller
point of view only the first external entity (LVDS to DSI converter) is
visible. The display controller thus calls the control operations implemented
by the LVDS to DSI transmitter driver (left-most green arrow). The driver is
aware of the next entity in the chain,
I can't find this in the code. I can see the video operations
propagating upstream using the source field of struct display_entity,
but how do the control operations propagate downstream? Am I missing
something?

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC v2 0/5] Common Display Framework

From: Tomi Valkeinen <hidden>
Date: 2012-11-24 07:16:22

On 2012-11-23 21:56, Thierry Reding wrote:
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
[...]
quoted
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 entity is registered. The reason for this asynchronous
mode of operation, compared to how drivers acquire regulator or clock
resources, is that the display entities can use resources provided by the
display driver. For instance a panel can be a child of the DBI or DSI bus
controlled by the display device, or use a clock provided by that device. We
can't defer the display device probe until the panel is registered and also
defer the panel device probe until the display is registered. As most display
drivers need to handle output devices hotplug (HDMI monitors for instance),
handling other display entities through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each other.
Those circular references would make driver unloading impossible. One possible
solution to this problem would be to simulate an unplug event for the display
entity, to force the display driver to release the dislay entities it uses. We
would need a userspace API for that though. Better solutions would of course
be welcome.
Maybe I don't understand all of the underlying issues correctly, but a
parent/child model would seem like a better solution to me. We discussed
this back when designing the DT bindings for Tegra DRM and came to the
conclusion that the output resource of the display controller (RGB,
HDMI, DSI or TVO) was the most suitable candidate to be the parent of
the panel or display attached to it. The reason for that decision was
that it keeps the flow of data or addressing of nodes consistent. So the
chain would look something like this (on Tegra):

	CPU
	+-host1x
	  +-dc
	    +-rgb
	    | +-panel
	    +-hdmi
	      +-monitor

In a natural way this makes the output resource the master of the panel
or display. From a programming point of view this becomes quite easy to
implement and is very similar to how other busses like I2C or SPI are
modelled. In device tree these would be represented as subnodes, while
with platform data some kind of lookup could be done like for regulators
or alternatively a board setup registration mechanism like what's in
place for I2C or SPI.
You didn't explicitly say it, but I presume you are talking about the
device model for panels, not just how to refer to the outputs.

How would you deal with a, say, DPI panel that is controlled via I2C or
SPI? You can have the panel device be both a panel device, child of a
RGB output, and an i2c device.

The model you propose is currently used in omapdss, and while it seems
simple and logical, it's not that simple with panels/chips with separate
control and data busses.

I think it makes more sense to consider the device as a child of the
control bus. So a DPI panel controlled via I2C is an I2C device, and it
just happens to use a DPI video output as a resource (like it could use
a regulator, gpio, etc).

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Philipp Zabel <p.zabel@pengutronix.de>
Date: 2012-11-26 07:53:54

Hi Thierry,

Am Freitag, den 23.11.2012, 20:56 +0100 schrieb Thierry Reding:
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
[...]
quoted
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 entity is registered. The reason for this asynchronous
mode of operation, compared to how drivers acquire regulator or clock
resources, is that the display entities can use resources provided by the
display driver. For instance a panel can be a child of the DBI or DSI bus
controlled by the display device, or use a clock provided by that device. We
can't defer the display device probe until the panel is registered and also
defer the panel device probe until the display is registered. As most display
drivers need to handle output devices hotplug (HDMI monitors for instance),
handling other display entities through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each other.
Those circular references would make driver unloading impossible. One possible
solution to this problem would be to simulate an unplug event for the display
entity, to force the display driver to release the dislay entities it uses. We
would need a userspace API for that though. Better solutions would of course
be welcome.
Maybe I don't understand all of the underlying issues correctly, but a
parent/child model would seem like a better solution to me. We discussed
this back when designing the DT bindings for Tegra DRM and came to the
conclusion that the output resource of the display controller (RGB,
HDMI, DSI or TVO) was the most suitable candidate to be the parent of
the panel or display attached to it. The reason for that decision was
that it keeps the flow of data or addressing of nodes consistent. So the
chain would look something like this (on Tegra):

	CPU
	+-host1x
	  +-dc
	    +-rgb
	    | +-panel
	    +-hdmi
	      +-monitor

In a natural way this makes the output resource the master of the panel
or display. From a programming point of view this becomes quite easy to
implement and is very similar to how other busses like I2C or SPI are
modelled. In device tree these would be represented as subnodes, while
with platform data some kind of lookup could be done like for regulators
or alternatively a board setup registration mechanism like what's in
place for I2C or SPI.
I second Tomi's answer. Also, describing data bus connections implicitly
with parent/child relationships doesn't work for entities with multiple
inputs. Imagine there are multiple dc's in the above diagram, and the
single hdmi encoder can be connected to either of them via multiplexing.

regards
Philipp

Re: [RFC v2 0/5] Common Display Framework

From: Alan Cox <hidden>
Date: 2012-11-26 14:42:12

On Sat, 24 Nov 2012 09:15:51 +0200
Tomi Valkeinen [off-list ref] wrote:
On 2012-11-23 21:56, Thierry Reding wrote:
quoted
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
[...]
quoted
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 entity is registered.
The framebuffer layer has some similar 'anyone can' type notifier
behaviour and its not a good thing. That kind of "any one can" behaviour
leads to some really horrible messes unless the connections and the
locking are well defined IMHO.

Alan

Re: [RFC v2 2/5] video: panel: Add DPI panel support

From: Tomi Valkeinen <hidden>
Date: 2012-11-27 13:02:57

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 = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+	display_entity_unregister(&panel->entity);
+
+	return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+	const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
+	struct panel_dpi *panel;
+	int ret;
+
+	if (pdata == NULL)
+		return -ENODEV;
+
+	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+	if (panel == NULL)
+		return -ENOMEM;
+
+	panel->pdata = pdata;
+	panel->entity.dev = &pdev->dev;
+	panel->entity.release = panel_dpi_release;
+	panel->entity.ops.ctrl = &panel_dpi_control_ops;
+
+	ret = display_entity_register(&panel->entity);
+	if (ret < 0) {
+		kfree(panel);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, panel);
+
+	return 0;
+}
+
+static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dpi_driver = {
+	.probe = panel_dpi_probe,
+	.remove = panel_dpi_remove,
+	.driver = {
+		.name = "panel_dpi",
+		.owner = THIS_MODULE,
+		.pm = &panel_dpi_dev_pm_ops,
+	},
+};
I'm not sure of how the free/release works. The release func is called
when the ref count drops to zero. But... The object in question, the
panel_dpi struct which contains the display entity, is not only about
data, it's also about code located in this module.

So I don't see anything preventing from unloading this module, while
some other component is holding a ref for the display entity. While its
holding the ref, it's valid to call ops in the display entity, but the
code for the ops in this module is already unloaded.

I don't really know how the kref can be used properly in this use case...

 Tomi

Re: [RFC v2 1/5] video: Add generic display entity core

From: Tomi Valkeinen <hidden>
Date: 2012-11-27 13:08:08

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
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int display_entity_get_modes(struct display_entity *entity,
+			     const struct videomode **modes)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->get_modes)
+		return 0;
+
+	return entity->ops.ctrl->get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+/**
+ * display_entity_get_size - Get display entity physical size
+ * @entity: The display entity
+ * @width: Physical width in millimeters
+ * @height: Physical height in millimeters
+ *
+ * When applicable, for instance for display panels, retrieve the display
+ * physical size in millimeters.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_get_size(struct display_entity *entity,
+			    unsigned int *width, unsigned int *height)
+{
+	if (!entity->ops.ctrl || !entity->ops.ctrl->get_size)
+		return -EOPNOTSUPP;
+
+	return entity->ops.ctrl->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
How do you envision these to be used with, say, DVI monitors with EDID
data? Should each panel driver, that manages a device with EDID, read
and parse the EDID itself? I guess that shouldn't be too difficult with
a common EDID lib, but that will only expose some of the information
found from EDID. Should the upper levels also have a way to get the raw
EDID data, in addition to funcs like above?

 Tomi

Re: [RFC v2 2/5] video: panel: Add DPI panel support

From: Philipp Zabel <p.zabel@pengutronix.de>
Date: 2012-11-30 09:26:58

Hi Laurent,

Am Donnerstag, den 22.11.2012, 22:45 +0100 schrieb Laurent Pinchart:
quoted hunk
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig     |   13 +++
 drivers/video/display/Makefile    |    1 +
 drivers/video/display/panel-dpi.c |  147 +++++++++++++++++++++++++++++++++++++
 include/video/panel-dpi.h         |   24 ++++++
 4 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 include/video/panel-dpi.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..0f9b990 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,16 @@ menuconfig DISPLAY_CORE
 	tristate "Display Core"
 	---help---
 	  Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+	tristate "DPI (Parallel) Display Panels"
+	---help---
+	  Support for simple digital (parallel) pixel interface panels. Those
+	  panels receive pixel data through a parallel bus and have no control
+	  bus.
I have tried this driver together with the imx parallel-display with the
added patch below for device tree support.
quoted hunk
+	  If you are in doubt, say N.
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..47978d4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/panel-dpi.c b/drivers/video/display/panel-dpi.c
new file mode 100644
index 0000000..c56197a
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,147 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <video/display.h>
+#include <video/panel-dpi.h>
+
+struct panel_dpi {
+	struct display_entity entity;
+	const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p)		container_of(p, struct panel_dpi, entity)
+
+static const struct display_entity_interface_params panel_dpi_params = {
+	.type = DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+static int panel_dpi_set_state(struct display_entity *entity,
+			       enum display_entity_state state)
+{
+	switch (state) {
+	case DISPLAY_ENTITY_STATE_OFF:
+	case DISPLAY_ENTITY_STATE_STANDBY:
+		display_entity_set_stream(entity->source,
+					  DISPLAY_ENTITY_STREAM_STOPPED);
+		break;
+
+	case DISPLAY_ENTITY_STATE_ON:
+		display_entity_set_stream(entity->source,
+					  DISPLAY_ENTITY_STREAM_CONTINUOUS);
+		break;
+	}
+
+	return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+			       const struct videomode **modes)
+{
+	struct panel_dpi *panel = to_panel_dpi(entity);
+
+	*modes = panel->pdata->mode;
+	return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+			      unsigned int *width, unsigned int *height)
+{
+	struct panel_dpi *panel = to_panel_dpi(entity);
+
+	*width = panel->pdata->width;
+	*height = panel->pdata->height;
+	return 0;
+}
+
+static int panel_dpi_get_params(struct display_entity *entity,
+				struct display_entity_interface_params *params)
+{
+	*params = panel_dpi_params;
+	return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+	.set_state = panel_dpi_set_state,
+	.get_modes = panel_dpi_get_modes,
+	.get_size = panel_dpi_get_size,
+	.get_params = panel_dpi_get_params,
+};
+
+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 = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+	display_entity_unregister(&panel->entity);
+
+	return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+	const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
+	struct panel_dpi *panel;
+	int ret;
+
+	if (pdata = NULL)
+		return -ENODEV;
+
+	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+	if (panel = NULL)
+		return -ENOMEM;
+
+	panel->pdata = pdata;
+	panel->entity.dev = &pdev->dev;
+	panel->entity.release = panel_dpi_release;
I don't understand this. Shouldn't the panel be allocated with
devm_kzalloc and display_entity_register make sure that this driver
cannot be unbound instead?

What if we call in sequence on this device's entity:
	display_entity_get(entity);
	display_entity_release(entity); /* here struct panel_dpi gets freed */
	display_entity_get(entity);
	display_entity_release(entity);
quoted hunk
+	panel->entity.ops.ctrl = &panel_dpi_control_ops;
+
+	ret = display_entity_register(&panel->entity);
+	if (ret < 0) {
+		kfree(panel);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, panel);
+
+	return 0;
+}
+
+static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dpi_driver = {
+	.probe = panel_dpi_probe,
+	.remove = panel_dpi_remove,
+	.driver = {
+		.name = "panel_dpi",
+		.owner = THIS_MODULE,
+		.pm = &panel_dpi_dev_pm_ops,
+	},
+};
+
+module_platform_driver(panel_dpi_driver);
+
+MODULE_AUTHOR("Laurent Pinchart [off-list ref]");
+MODULE_DESCRIPTION("DPI Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dpi.h b/include/video/panel-dpi.h
new file mode 100644
index 0000000..0547b4a
--- /dev/null
+++ b/include/video/panel-dpi.h
@@ -0,0 +1,24 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_DPI_H__
+#define __PANEL_DPI_H__
+
+#include <linux/videomode.h>
+
+struct panel_dpi_platform_data {
+	unsigned long width;		/* Panel width in mm */
+	unsigned long height;		/* Panel height in mm */
+	const struct videomode *mode;
+};
+
+#endif /* __PANEL_DPI_H__ */
From: Philipp Zabel <p.zabel@pengutronix.de>
Date: Thu, 29 Nov 2012 19:18:30 +0100
Subject: [PATCH] video: panel: Add device tree support to the DPI panel
 driver

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/video/display/panel-dpi.c |   56 ++++++++++++++++++++++++++++++++++---
 1 file changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/video/display/panel-dpi.c b/drivers/video/display/panel-dpi.c
index c56197a..5a7dd8e 100644
--- a/drivers/video/display/panel-dpi.c
+++ b/drivers/video/display/panel-dpi.c
@@ -14,6 +14,8 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_videomode.h>
 
 #include <video/display.h>
 #include <video/panel-dpi.h>
@@ -98,20 +100,60 @@ static int panel_dpi_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static int __devinit panel_dpi_probe(struct platform_device *pdev)
+static int __devinit panel_dpi_parse_dt(struct device *dev,
+					struct panel_dpi *panel)
 {
-	const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
-	struct panel_dpi *panel;
+	struct device_node *np = dev->of_node;
+	struct panel_dpi_platform_data *pdata;
+	struct videomode *vm;
+	u32 width, height;
 	int ret;
 
+	if (!np)
+		return -ENODEV;
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
 	if (pdata = NULL)
+		return -ENOMEM;
+
+	vm = devm_kzalloc(dev, sizeof(*vm), GFP_KERNEL);
+	if (vm = NULL)
+		return -ENOMEM;
+
+	ret = of_get_videomode(np, vm, 0);
+	if (ret < 0)
 		return -ENODEV;
 
+	of_property_read_u32(np, "width", &width);
+	of_property_read_u32(np, "height", &height);
+
+	pdata->mode = vm;
+	pdata->width = width;
+	pdata->height = height;
+	panel->pdata = pdata;
+
+	return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+	const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
+	struct panel_dpi *panel;
+	int ret;
+
 	panel = kzalloc(sizeof(*panel), GFP_KERNEL);
 	if (panel = NULL)
 		return -ENOMEM;
 
-	panel->pdata = pdata;
+	if (pdata) {
+		panel->pdata = pdata;
+	} else {
+		ret = panel_dpi_parse_dt(&pdev->dev, panel);
+		if (ret < 0) {
+			kfree(panel);
+			return ret;
+		}
+	}
 	panel->entity.dev = &pdev->dev;
 	panel->entity.release = panel_dpi_release;
 	panel->entity.ops.ctrl = &panel_dpi_control_ops;
@@ -130,11 +172,17 @@ static int __devinit panel_dpi_probe(struct platform_device *pdev)
 static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
 };
 
+static const struct of_device_id panel_dpi_dt_ids[] = {
+	{ .compatible = "dpi-panel", },
+	{ }
+};
+
 static struct platform_driver panel_dpi_driver = {
 	.probe = panel_dpi_probe,
 	.remove = panel_dpi_remove,
 	.driver = {
 		.name = "panel_dpi",
+		.of_match_table = panel_dpi_dt_ids,
 		.owner = THIS_MODULE,
 		.pm = &panel_dpi_dev_pm_ops,
 	},
-- 
1.7.10.4

regards
Philipp

Re: [RFC v2 3/5] video: display: Add MIPI DBI bus support

From: Tomi Valkeinen <hidden>
Date: 2012-11-30 12:03:04

Hi,

On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/display/Kconfig        |    4 +
 drivers/video/display/Makefile       |    1 +
 drivers/video/display/mipi-dbi-bus.c |  228 ++++++++++++++++++++++++++++++++++
 include/video/display.h              |    5 +
 include/video/mipi-dbi-bus.h         |  125 +++++++++++++++++++
 5 files changed, 363 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/display/mipi-dbi-bus.c
 create mode 100644 include/video/mipi-dbi-bus.h
I've been doing some omapdss testing with CDF and DSI, and I have some
thoughts about the bus stuff. I already told these to Laurent, but I'll
write them to the mailing list also for discussion.

So with the current CDF model we have separate control and video buses.
The control bus is represented as proper Linux bus, and video bus is
represented via custom display_entity. This sounds good on paper, and I
also agreed to this approach when we were planning CDF.

However, now I doubt that approach.

First, I want to list some examples of devices with different bus
configurations:

1) Panel without any control, only video bus
2) Panel with separate control and video buses, e.g. i2c for control,
DPI for video
3) Panel with the same control and video buses, like DSI or DBI.

The first one is simple, it's just a platform device. No questions there.

The second one can be a bit tricky. Say, if we have a panel controlled
via i2c, and DSI/DBI used for video. The problem here is that with the
current model, DSI/DBI would be represented as a real bus, for control.
But in this case there's only the video path.

So if all the DSI/DBI bus configuration is handled on the DSI/DBI
control bus side, how can it be handled with only the video bus? And if
we add the same bus configuration to the video bus side as we have on
control bus side, then we have duplicated the API, and it's also
somewhat confusing. I don't have any good suggestion for this.

Third one is kinda clear, but I feel slightly uneasy about it. In theory
we can have separate control and video buses, which use the same HW
transport. However, I feel that we'll have some trouble with the
implementation, as we'll then have two more or less independent users
for the HW transport. I can't really point out why this would not be
possible to implement, but I have a gut feeling that it will be
difficult, at least for DSI.

So I think my question is: what does it give us to have separate control
and video buses, and what does the Linux bus give us with the control bus?

I don't see us ever having a case where a device would use one of the
display buses only for control. So either the display bus is only used
for video, or it's used for both control and video. And the display bus
is always 1-to-1, so we're talking about really simple bus here.

I believe things would be much simpler if we just have one entity for
the display buses, which support both video and (when available)
control. What would be the downsides of this approach versus the current
CDF proposal?

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 14:36:01

Hi Tomi,

I finally have time to work on a v3 :-)

On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework also 
targets HDMI and DP. The notification mechanism was actually designed to 
support hotplug.

How do you see the proposal preventing hotplug ?
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that can 
only receive calls (as it needs to control video streams, per your request 
:-)) or only emit calls (as something needs to control it, userspace doesn't 
control the panel directly).
What I suggest is take a simpler approach, something alike to how regulators
or gpios are used, even if slightly more complex than those: the entity that
has a video output (SoC's DSS, external chips) offers that video output as
resource. It doesn't know or care who uses it. The user of the video output
(panel, external chips) will find the video output (to which it is connected
in the HW) by some means, and will use different operations on that output
to operate the device.

This would give us something like the following DT data:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

/ {
	dpi-panel: dpi-panel {
		source = <&dpi0>;
		...panel data...;
	};
};

The panel driver would do something like this in its probe:

int dpi_panel_probe()
{
	// Find the video source, increase ref
	src = get_video_source_from_of("source");

	// Reserve the video source for us. others can still get and
	// observe it, but cannot use it as video data source.
	// I think this should cascade upstream, so that after this call
	// each video entity from the panel to the SoC's CRTC is
	// reserved and locked for this video pipeline.
	reserve_video_source(src);

	// set DPI HW configuration, like DPI data lines. The
	// configuration would come from panel's platform data
	set_dpi_config(src, config);

	// register this panel as a display.
	register_display(this);
}


The DSS's dpi driver would do something like:

int dss_dpi_probe()
{
	// register as a DPI video source
	register_video_source(this);
}

A DSI-2-DPI chip would do something like:

int dsi2dpi_probe()
{
	// get, reserve and config the DSI bus from SoC
	src = get_video_source_from_of("source");
	reserve_video_source(src);
	set_dsi_config(src, config);

	// register as a DPI video source
	register_video_source(this);
}


Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed 
entities (transceivers) differently. I prefer having abstract entities that 
can have a source and a sink, and expose the corresponding operations. That 
would make pipeline handling much easier, as the code will only need to deal 
with a single type of object. Implementing support for entities with multiple 
sinks and/or sources would also be possible.
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.
What is missing in your proposal is an explanation of how the panel is 
controlled. What does your register_display() function register the display 
with, and what then calls the display operations ?

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 14:57:28

Hi Thierry,

On Friday 23 November 2012 20:56:07 Thierry Reding wrote:
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
[...]
quoted
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 entity is registered. The reason for
this asynchronous mode of operation, compared to how drivers acquire
regulator or clock resources, is that the display entities can use
resources provided by the display driver. For instance a panel can be a
child of the DBI or DSI bus controlled by the display device, or use a
clock provided by that device. We can't defer the display device probe
until the panel is registered and also defer the panel device probe until
the display is registered. As most display drivers need to handle output
devices hotplug (HDMI monitors for instance), handling other display
entities through a notification system seemed to be the easiest solution.

Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each
other. Those circular references would make driver unloading impossible.
One possible solution to this problem would be to simulate an unplug event
for the display entity, to force the display driver to release the dislay
entities it uses. We would need a userspace API for that though. Better
solutions would of course be welcome.
Maybe I don't understand all of the underlying issues correctly, but a
parent/child model would seem like a better solution to me. We discussed
this back when designing the DT bindings for Tegra DRM and came to the
conclusion that the output resource of the display controller (RGB,
HDMI, DSI or TVO) was the most suitable candidate to be the parent of
the panel or display attached to it. The reason for that decision was
that it keeps the flow of data or addressing of nodes consistent. So the
chain would look something like this (on Tegra):

	CPU
	+-host1x
	  +-dc
	    +-rgb
	    | +-panel
	    +-hdmi
	      +-monitor

In a natural way this makes the output resource the master of the panel
or display. From a programming point of view this becomes quite easy to
implement and is very similar to how other busses like I2C or SPI are
modelled. In device tree these would be represented as subnodes, while
with platform data some kind of lookup could be done like for regulators
or alternatively a board setup registration mechanism like what's in
place for I2C or SPI.
That works well for panels that have a shared control and video bus (DBI, DSI) 
or only a video bus (DPI), but breaks when you need to support panels with 
separate control and video busses, such as panels with a parallel data bus and 
an I2C or SPI control bus.

Both Linux and DT have a tree-based device model. Devices can have a single 
parent, so you can't represent your panel as a child of both the video source 
and the control bus master. We have the exact same problem in V4L2 with I2C 
camera sensors that output video data on a separate parallel or serial bus, 
and we decided to handle the device as a child of its control bus master. This 
model makes usage of the Linux power management model easier (but not 
straightforward when power management dependencies exist across video busses, 
outside of the kernel device tree).

As the common display framework should handle both panels with common control 
and video busses and panels with separate busses in a similar fashion, DT 
bindings needs to reference the panel through a phandle, even though in some 
cases they could technically just be children of the display controller.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 15:01:03

Hi Sascha,

On Friday 23 November 2012 22:41:58 Sascha Hauer wrote:
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The CDF models this using a Russian doll's model. From the display
controller point of view only the first external entity (LVDS to DSI
converter) is visible. The display controller thus calls the control
operations implemented by the LVDS to DSI transmitter driver (left-most
green arrow). The driver is aware of the next entity in the chain,
I can't find this in the code. I can see the video operations
propagating upstream using the source field of struct display_entity,
but how do the control operations propagate downstream? Am I missing
something?
There's no downstream propagation yet, as there's no display entity driver 
that requires it at the moment. Propagation would be implemented in 
transceiver drivers for instance. I'll have to find one with public 
documentation (and hopefully an existing mainline driver) on one of the boards 
I own.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 15:14:20

Hi Alan,

On Monday 26 November 2012 14:47:08 Alan Cox wrote:
On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote:
quoted
On 2012-11-23 21:56, Thierry Reding wrote:
quoted
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
[...]
quoted
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 entity is registered.
The framebuffer layer has some similar 'anyone can' type notifier
behaviour and its not a good thing. That kind of "any one can" behaviour
leads to some really horrible messes unless the connections and the
locking are well defined IMHO.
I agree with you. I dislike the FBDEV notifier model, and I definitely don't 
intend to duplicate it in the common display framework.

In the CDF model, when the display device driver registers a notifier, it 
tells the core which device it wants to receive events for. This currently 
takes the form of a struct device pointer, and the API will also support 
device nodes in a future version (this is still work in progress). The goal is 
to implement panel discovery in a way that is compatible with (and very 
similar to) hotpluggable display discovery.

Thinking about it now, the API could be cleaner and less subject to abuse if 
the notifier was registered for a given video port instead of a given 
connected device. I'll add that to my TODO list.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Tomi Valkeinen <hidden>
Date: 2012-12-17 15:29:45

On 2012-12-17 16:36, Laurent Pinchart wrote:
Hi Tomi,

I finally have time to work on a v3 :-)

On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
quoted
On 2012-11-22 23:45, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework also 
targets HDMI and DP. The notification mechanism was actually designed to 
support hotplug.
HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a
cable hotplug, handled inside a driver, which doesn't have any effect on
the linux devices.

If we do implement HDMI and DP monitors with real linux drivers, then
yes, we could use real hotplug. But we could as well have the monitor
driver always registered, and just have a driver internal cable-hotplug
system.

To be honest, I'm not sure if implementing real hotplug is easily
possible, as we don't have real, probable (probe-able =) busses. So even
if we'd get a hotplug event of a new display device, what kind of device
would the bus master register? It has no way to know that.
How do you see the proposal preventing hotplug ?
Well, probably it doesn't prevent. But it doesn't feel right to me.

Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be
probed. In the probe function it should somehow register itself to the
cdf, or perhaps the previous entity in the chain.

This sounds to me that the link is from the panel to the previous
entity, not the other way around as you describe, and also the previous
entity doesn't know of the panel entities.
quoted
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that can 
only receive calls (as it needs to control video streams, per your request 
:-)) or only emit calls (as something needs to control it, userspace doesn't 
control the panel directly).
Right, but as I see it, the destination of the panel's calls, and the
source of the calls to panel are different things. The destination is
the bus layer, dealing with the video signal being transferred. The
source is a bit higher level thing, something that's controlling the
display in general.
quoted
Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed 
entities (transceivers) differently. I prefer having abstract entities that 
can have a source and a sink, and expose the corresponding operations. That 
would make pipeline handling much easier, as the code will only need to deal 
with a single type of object. Implementing support for entities with multiple 
sinks and/or sources would also be possible.
Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.
quoted
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.
What is missing in your proposal is an explanation of how the panel is 
controlled. What does your register_display() function register the display 
with, and what then calls the display operations ?
In my particular case, the omapfb calls the display operations, which is
the higher level "manager" for the whole display. So omapfb does calls
both to the DSS side and to the panel side of the pipeline.

I agree that making calls to both ends is a bit silly, but then again, I
think it also happens in your model, it's just hidden there.

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Jani Nikula <jani.nikula@linux.intel.com>
Date: 2012-12-17 16:52:35

Hi Laurent -

On Mon, 17 Dec 2012, Laurent Pinchart [off-list ref] wrote:
Hi Tomi,

I finally have time to work on a v3 :-)

On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
quoted
On 2012-11-22 23:45, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework also 
targets HDMI and DP. The notification mechanism was actually designed to 
support hotplug.
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?

BR,
Jani.

How do you see the proposal preventing hotplug ?
quoted
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that can 
only receive calls (as it needs to control video streams, per your request 
:-)) or only emit calls (as something needs to control it, userspace doesn't 
control the panel directly).
quoted
What I suggest is take a simpler approach, something alike to how regulators
or gpios are used, even if slightly more complex than those: the entity that
has a video output (SoC's DSS, external chips) offers that video output as
resource. It doesn't know or care who uses it. The user of the video output
(panel, external chips) will find the video output (to which it is connected
in the HW) by some means, and will use different operations on that output
to operate the device.

This would give us something like the following DT data:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

/ {
	dpi-panel: dpi-panel {
		source = <&dpi0>;
		...panel data...;
	};
};

The panel driver would do something like this in its probe:

int dpi_panel_probe()
{
	// Find the video source, increase ref
	src = get_video_source_from_of("source");

	// Reserve the video source for us. others can still get and
	// observe it, but cannot use it as video data source.
	// I think this should cascade upstream, so that after this call
	// each video entity from the panel to the SoC's CRTC is
	// reserved and locked for this video pipeline.
	reserve_video_source(src);

	// set DPI HW configuration, like DPI data lines. The
	// configuration would come from panel's platform data
	set_dpi_config(src, config);

	// register this panel as a display.
	register_display(this);
}


The DSS's dpi driver would do something like:

int dss_dpi_probe()
{
	// register as a DPI video source
	register_video_source(this);
}

A DSI-2-DPI chip would do something like:

int dsi2dpi_probe()
{
	// get, reserve and config the DSI bus from SoC
	src = get_video_source_from_of("source");
	reserve_video_source(src);
	set_dsi_config(src, config);

	// register as a DPI video source
	register_video_source(this);
}


Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed 
entities (transceivers) differently. I prefer having abstract entities that 
can have a source and a sink, and expose the corresponding operations. That 
would make pipeline handling much easier, as the code will only need to deal 
with a single type of object. Implementing support for entities with multiple 
sinks and/or sources would also be possible.
quoted
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.
What is missing in your proposal is an explanation of how the panel is 
controlled. What does your register_display() function register the display 
with, and what then calls the display operations ?

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 22:18:37

Hi Jani,

On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
On Mon, 17 Dec 2012, Laurent Pinchart wrote:
quoted
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
quoted
On 2012-11-22 23:45, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also targets HDMI and DP. The notification mechanism was actually
designed to support hotplug.
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's what 
the C stands for, common refers to sharing panel and other display entity 
drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the KMS 
API. We might have to do so later if the hardware complexity grows in such a 
way that finer control than what KMS provides needs to be exposed to 
userspace, but I don't think we're there yet. The CDF API will thus only be 
used internally in the kernel by display controller drivers. The KMS core 
might get functions to handle common display entity operations, but the bulk 
of the work will be in the display controller drivers to start with. We will 
then see what can be abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF 
API. That's just a thought for now, I haven't tried to implement them, but it 
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.

Do you have thoughts to share on this topic ?

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-17 23:17:05

Hi Tomi,

On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote:
On 2012-12-17 16:36, Laurent Pinchart wrote:
quoted
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
quoted
On 2012-11-22 23:45, Laurent Pinchart wrote:
quoted
From: Laurent Pinchart <laurent.pinchart+renesas@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 code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also targets HDMI and DP. The notification mechanism was actually
designed to support hotplug.
HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a cable
hotplug, handled inside a driver, which doesn't have any effect on the linux
devices.

If we do implement HDMI and DP monitors with real linux drivers, then yes,
we could use real hotplug. But we could as well have the monitor driver
always registered, and just have a driver internal cable-hotplug system.

To be honest, I'm not sure if implementing real hotplug is easily possible,
as we don't have real, probable (probe-able =) busses. So even if we'd get a
hotplug event of a new display device, what kind of device would the bus
master register? It has no way to know that.
I get your point.

My design goal is to handle both HDMI/DP and panels through a single hotplug 
interface. I believe it would be simpler for display controller drivers to 
handle all display entities with a common API instead of implementing support 
for HDMI/DP and panels separately. This would require real HDMI and DP monitor 
drivers. I share your concern, I don't know whether this can work in the end, 
the only way to find out will be to try it.
quoted
How do you see the proposal preventing hotplug ?
Well, probably it doesn't prevent. But it doesn't feel right to me.

Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be probed.
That's correct. That's how Linux handles devices, and I don't think we should 
diverge from that model without a very good reason to do so. In my 
understanding you agree with me here, could you please confirm that ?
In the probe function it should somehow register itself to the cdf, or
perhaps the previous entity in the chain.
The panel driver would register the panel device to CDF in its probe function. 
From a panel point of view I think we agree that two sets of operations exist.

- The panel control operations are called by an upper layer component (let's 
call it A) to control the panel (retrieve the list of modes, enable the panel, 
...). That upper layer component will usually call the panel in response to a 
userspace request (that can go through several layers in the kernel before 
reaching the panel), but can also call it in response to a hotplug event, 
without userspace being involved.

- The panel calls video operations of the entity that provides it with a video 
stream (the video source entity, let's call it B) to configure and control the 
video bus.

A and B could be implemented in the same driver or in two separate drivers, 
but at the end of the day I don't think that matters much. A needs a reference 
to the panel, and the panel needs a reference to B, that's all we need to 
provide, regardless of whether A and B come from the same kernel module or 
not.
This sounds to me that the link is from the panel to the previous entity,
not the other way around as you describe, and also the previous entity
doesn't know of the panel entities.
The data flows from the video source to the panel (I'm 100% confident that we 
agree on that :-)), and the video source is controlled by the panel as per 
your request. The link is thus from the video source to the panel, but is 
controlled by the sink, not the source.
quoted
quoted
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that
can only receive calls (as it needs to control video streams, per your
request :-)) or only emit calls (as something needs to control it,
userspace doesn't control the panel directly).
Right, but as I see it, the destination of the panel's calls, and the source
of the calls to panel are different things. The destination is the bus
layer, dealing with the video signal being transferred. The source is a bit
higher level thing, something that's controlling the display in general.
That's correct. They can both be implemented in the same driver, but they're 
different logical entities. (I actually think they should be implemented in 
the same driver, but that's not very relevant here.)
quoted
quoted
Here we wouldn't have similar display_entity as you have, but video
sources and displays. Video sources are elements in the video pipeline,
and a video source is used only by the next downstream element. The last
element in the pipeline would not be a video source, but a display, which
would be used by the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and
mixed entities (transceivers) differently. I prefer having abstract
entities that can have a source and a sink, and expose the corresponding
operations. That would make pipeline handling much easier, as the code
will only need to deal with a single type of object. Implementing support
for entities with multiple sinks and/or sources would also be possible.
Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.
A pure source is an entity with a source pad only that only exposes source pad 
operations, I think the complexity to handle them from the panel point of view 
would roughly be the same (there might be an extra argument to a couple of 
functions with a pad number, but that's more or less it).
quoted
quoted
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.
What is missing in your proposal is an explanation of how the panel is
controlled. What does your register_display() function register the
display with, and what then calls the display operations ?
In my particular case, the omapfb calls the display operations, which is
the higher level "manager" for the whole display. So omapfb does calls
both to the DSS side and to the panel side of the pipeline.

I agree that making calls to both ends is a bit silly, but then again, I
think it also happens in your model, it's just hidden there.
That's probably the biggest difference between our models. Let's discuss it 
face to face tomorrow and hopefully come up with an agreement.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Dave Airlie <airlied@gmail.com>
Date: 2012-12-18 05:09:37

Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?

The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.

Dave.

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-18 06:29:26

On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative.. but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.

CDF or some sort of mechanism to share panel drivers between drivers
is useful.  Keeping it within drm, is probably a good idea, if nothing
else to simplify re-use of helper fxns (like avi-infoframe stuff, for
example) and avoid dealing with merging changes across multiple trees.
  Treating them more like shared libraries and less like sub-devices
which can be dynamically loaded/unloaded (ie. they should be not built
as separate modules or suspend/resumed or probed/removed independently
of the master driver) is a really good idea to avoid uncovering nasty
synchronization issues later (remove vs modeset or pageflip) or
surprising userspace in bad ways.
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms.  But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls.  But I tend to think that is more
useful for cameras.  And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx

BR,
-R
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

From: Daniel Vetter <hidden>
Date: 2012-12-18 08:37:13

On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark [off-list ref] wrote:
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms.  But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls.  But I tend to think that is more
useful for cameras.  And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx
Yeah, I guess having a v4l device also exported by the same driver
that exports the drm interface might make sense in some cases. But in
many cases I think the video part is just an independent IP block and
shuffling data around with dma-buf is all we really need. So yeah, I
guess sharing display resources between v4l and drm kms driver should
be a last resort option, since coordination (especially if it's
supposed to be somewhat dynamic) will be extremely hairy.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [RFC v2 0/5] Common Display Framework

From: Marcus Lorentzon <hidden>
Date: 2012-12-18 10:40:08

On 12/18/2012 06:04 AM, Dave Airlie wrote:
quoted
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:
I like the effort, right now it seems like x86 and arm display sub 
systems are quite different in terms of DRM driver (and HW) design. I 
think this is partly due to little information shared about these 
different architectures and ideas behind the choices made. I hope some 
discussion will light up both sides. And an early discussion will 
hopefully give you less pain when CDF drivers starts to get pushed your way.
The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
Could you give an example? Personally I don't think it is that many. I 
might not have counted the plat devs in all arm drivers. But the STE one 
have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). 
Then of course there are all these panel devices. But I hope that when 
CDF is "finished" we will have DSI devices on the DSI bus and DBI 
devices on the DBI bus. I think most vendors have used platform devices 
for these since they normally can't be probed in a generic way. But as 
they are off SoC I feel this is not the best choice. And then many of 
the panels are I2C devices (control bus) and that I guess is similar to 
"x86" encoders/connectors?
Another part of the difference I feel is that in x86 a DRM device is 
most likely a PCI device, and as such has one huge driver for all IPs on 
that board. The closest thing we get to that in ARM is probably the DSS 
(collection of IPs on SoC, like 3D, 2D, display output, encoders). But 
it doesn't fell right to create a single driver for all these. And as 
you know often 3D is even from a separate vendor. All these lead up to a 
slight increase in the number of devices and drivers. Right way, I feel 
so, but you are welcome to show a better way.
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
I have no intention to use CDF outside KMS connector/encoder and I have 
not heard Laurent talk about this either. Personally I see CDF as 
"helpers" to create and reuse connector/encoder drivers between SoCs 
instead of each SoC do their own panel drivers (which would be about a 
hundred, times the number of supported SoCs). We probably need to 
discuss the connector/encoder mappings to CDF/panels. But I think we 
need to flush out the higher level details like control bus vs. data bus 
vs. display entities. While I like the generic way of the display 
entities, I also like the pure bus/device/driver model without too many 
generalizations.
Do you have any support in x86 world that could be compared to mobile 
phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips 
between the on chip/cpu/SoC CRTC and the external LCD depending on 
product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86?
And if you do, how do you model/setup/share all those in DRM driver? Or 
it is manageable (< 10) and not up in the hundreds of different 
encoders/lcd-drivers?

/BR
/Marcus

Re: [RFC v2 0/5] Common Display Framework

From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Date: 2012-12-18 11:05:31

On 12/18/2012 07:21 AM, Rob Clark wrote:
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie[off-list ref]  wrote:
quoted
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
There have been already some ideas proposed to resolve this at the PM
subsystem level [1]. And this problem is of course not only specific
to platform drivers. The idea of having monolithic drivers, just because
we can't get the suspend/resume sequences right otherwise, doesn't really
sound appealing. SoC IPs get reused on multiple different SoC series,
no only by single manufacturer. Whole graphics/video subsystems are
composed from smaller blocks in SoCs, with various number of distinct
sub-blocks and same sub-blocks repeated different number of times in
a specific SoC revision.
Expressing an IP as a platform device seems justified to me, often these
platform devices have enough differences to treat them as such. E.g.
belong in different power domain/use different clocks. Except there is
big issue with the power management... However probably more important
is to be able to have driver for a specific IP in a separate module.

And this suspend/resume ordering issue is not only about the platform
devices. E.g. camera subsystem can be composed of an image sensor
sub-device driver, which is most often an I2C client driver, and of
multiple SoC processing blocks. The image sensor can have dependencies
on the SoC sub-blocks. So even if we created monolithic driver for the
SoC part, there are still two pieces to get s/r ordering right - I2C
client and SoC drivers. And please don't propose to merge the sensor
sub-device driver too. There has been a lot of effort in V4L2 to
separate those various functional blocks into sub-devices, so they can
be freely reused, without reimplementing same functionality in each
driver. BTW, there has been a nice talk about these topics at ELCE [2],
particularly slide 22 is interesting.

I believe the solution for these issues really needs to be sought in the
PM subsystem itself.
I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative.. but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.
[1] https://lkml.org/lkml/2009/9/9/373
[2] 
http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf

Thanks,
Sylwester

Re: [RFC v2 0/5] Common Display Framework

From: Jani Nikula <jani.nikula@linux.intel.com>
Date: 2012-12-19 14:56:51

Hi Laurent -

On Tue, 18 Dec 2012, Laurent Pinchart [off-list ref] wrote:
Hi Jani,

On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
quoted
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's what 
the C stands for, common refers to sharing panel and other display entity 
drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the KMS 
API. We might have to do so later if the hardware complexity grows in such a 
way that finer control than what KMS provides needs to be exposed to 
userspace, but I don't think we're there yet. The CDF API will thus only be 
used internally in the kernel by display controller drivers. The KMS core 
might get functions to handle common display entity operations, but the bulk 
of the work will be in the display controller drivers to start with. We will 
then see what can be abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF 
API. That's just a thought for now, I haven't tried to implement them, but it 
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.

Do you have thoughts to share on this topic ?
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!

For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.


BR,
Jani.

Re: [RFC v2 0/5] Common Display Framework

From: Tomi Valkeinen <hidden>
Date: 2012-12-19 15:08:13

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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!
The use of CDF is an option, not something that has to be done. A DRM
driver developer may use it if it gives benefit for him for that
particular driver.

I don't know much about desktop display hardware, but I guess that using
CDF would not really give much there. In some cases it could, if the IPs
used on the graphics card are something that are used elsewhere also
(sounds quite unlikely, though). In that case there could be separate
drivers for the IPs.

And note that CDF is not really about the dispc side, i.e. the part that
creates the video stream from pixels in the memory. It's more about the
components after that, and how to connect those components.
For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.
Right. But if you implement drivers for DSI panels with CDF for, say,
OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
Otherwise it'll be a mishmash with two different models.

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-19 15:26:41

On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
[off-list ref] wrote:
Hi Laurent -

On Tue, 18 Dec 2012, Laurent Pinchart [off-list ref] wrote:
quoted
Hi Jani,

On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
quoted
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's what
the C stands for, common refers to sharing panel and other display entity
drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the KMS
API. We might have to do so later if the hardware complexity grows in such a
way that finer control than what KMS provides needs to be exposed to
userspace, but I don't think we're there yet. The CDF API will thus only be
used internally in the kernel by display controller drivers. The KMS core
might get functions to handle common display entity operations, but the bulk
of the work will be in the display controller drivers to start with. We will
then see what can be abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
API. That's just a thought for now, I haven't tried to implement them, but it
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.

Do you have thoughts to share on this topic ?
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!
fwiw, I think there are at least a couple cases where multiple SoC's
have the same HDMI IP block.

And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just
something similar to what drivers/gpu/i2c is today) seems a bit
overkill for me.  Being able to use the helpers in drm and avoiding an
extra layer of translation seems like the better option to me.  So my
vote would be drivers/gpu/cdf.

BR,
-R
For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.


BR,
Jani.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 0/5] Common Display Framework

From: Tomi Valkeinen <hidden>
Date: 2012-12-19 15:39:02

On 2012-12-19 17:26, Rob Clark wrote:
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
[off-list ref] wrote:
quoted
Hi Laurent -

On Tue, 18 Dec 2012, Laurent Pinchart [off-list ref] wrote:
quoted
Hi Jani,

On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
quoted
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's what
the C stands for, common refers to sharing panel and other display entity
drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the KMS
API. We might have to do so later if the hardware complexity grows in such a
way that finer control than what KMS provides needs to be exposed to
userspace, but I don't think we're there yet. The CDF API will thus only be
used internally in the kernel by display controller drivers. The KMS core
might get functions to handle common display entity operations, but the bulk
of the work will be in the display controller drivers to start with. We will
then see what can be abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
API. That's just a thought for now, I haven't tried to implement them, but it
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.

Do you have thoughts to share on this topic ?
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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!
fwiw, I think there are at least a couple cases where multiple SoC's
have the same HDMI IP block.

And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just
something similar to what drivers/gpu/i2c is today) seems a bit
overkill for me.  Being able to use the helpers in drm and avoiding an
extra layer of translation seems like the better option to me.  So my
vote would be drivers/gpu/cdf.
Well, we need to think about that. I would like to keep CDF independent
of DRM. I don't like tying different components/frameworks together if
there's no real need for that.

Also, something that Laurent mentioned in our face-to-face discussions:
Some IPs/chips can be used for other purposes than with DRM.

He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the framework used in these
cases is always v4l2.

The IPs/chips in the above model may be the exact same IPs/chips that
are used with "normal" display. If the CDF was tied to DRM, using the
same drivers for normal and these streaming cases would probably not be
possible.

 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-19 16:13:46

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen [off-list ref] wrote:
On 2012-12-19 17:26, Rob Clark wrote:
quoted
And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just
something similar to what drivers/gpu/i2c is today) seems a bit
overkill for me.  Being able to use the helpers in drm and avoiding an
extra layer of translation seems like the better option to me.  So my
vote would be drivers/gpu/cdf.
Well, we need to think about that. I would like to keep CDF independent
of DRM. I don't like tying different components/frameworks together if
there's no real need for that.

Also, something that Laurent mentioned in our face-to-face discussions:
Some IPs/chips can be used for other purposes than with DRM.

He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the framework used in these
cases is always v4l2.

The IPs/chips in the above model may be the exact same IPs/chips that
are used with "normal" display. If the CDF was tied to DRM, using the
same drivers for normal and these streaming cases would probably not be
possible.
Well, maybe there is a way, but it really seems to be
over-complicating things unnecessarily to keep CDF independent of
DRM..  there will be a lot more traditional uses of CDF compared to
one crazy use-case.  So I don't really fancy making it more difficult
than in needs to be for everyone.

Probably the thing to do is take a step back and reconsider that one
crazy use-case.  For example, KMS doesn't enforce that the buffer
handled passed when you create a drm framebuffer object to scan out is
a GEM buffer.  So on that one crazy platform, maybe it makes sense to
have a DRM/KMS display driver that takes a handle to identify which
video stream coming from the capture end of the pipeline.  Anyways,
that is just an off-the-top-of-my-head idea, probably there are other
options too.

BR,
-R
 Tomi

Re: [RFC v2 0/5] Common Display Framework

From: Stéphane Marchesin <hidden>
Date: 2012-12-19 20:13:34

On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark [off-list ref] wrote:
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative..
You can probe the device tree from a normal DRM driver. For example in
nouveau for PPC we probe the OF device tree looking for connectors. I
don't see how sub-devices or extra platform drivers help with that, as
long as the device tree is populated upfront somehow...

Stéphane
but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.

CDF or some sort of mechanism to share panel drivers between drivers
is useful.  Keeping it within drm, is probably a good idea, if nothing
else to simplify re-use of helper fxns (like avi-infoframe stuff, for
example) and avoid dealing with merging changes across multiple trees.
  Treating them more like shared libraries and less like sub-devices
which can be dynamically loaded/unloaded (ie. they should be not built
as separate modules or suspend/resumed or probed/removed independently
of the master driver) is a really good idea to avoid uncovering nasty
synchronization issues later (remove vs modeset or pageflip) or
surprising userspace in bad ways.
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms.  But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls.  But I tend to think that is more
useful for cameras.  And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx

BR,
-R
quoted
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 13:23:22

Hi Dave,

On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote:
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in no
particular order) Tomi Valkeinen for all the time he spend helping me to
draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4
2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me looking at
stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics and
output world is the proliferation of platform drivers for every little
thing. The whole ordering of operations with respect to things like
suspend/resume or dynamic power management is going to be a real nightmare
if there are dependencies between the drivers.
We share the same concern, although my analysis of the problem is somewhat 
different. The power management ordering issues isn't only caused by the 
software architecture, but also comes from complex hardware requirements. The 
root cause, in my opinion, is the split control and data busses: as soon as a 
device sits on multiple busses and has power management ordering requirements 
related to those busses the Linux power management model breaks. Note that the 
problem isn't restricted to the display, we have run into the exact same 
issues years ago on the video capture side.
How do you enforce ordering of s/r operations between all the various
components?
The way we have handled this problem on the camera side is to use early 
suspend and late resume operations to handle the data (video) busses suspend 
and resume operations, and let the kernel handle the rest using the control 
bus based device tree model. The camera controller stops the video pipeline in 
its early suspend operation (and resumes it in the late resume operation) by 
calling operations provided by the entities (through function pointers of 
course, we don't want direct dependencies between the drivers). The control 
suspend/resume (such as sending a standby command through I2C to put the chip 
in low-power mode, or turning its power supply or clock off) is then handled 
by the PM core.
The other thing I'd like you guys to do is kill the idea of fbdev and v4l
drivers that are "shared" with the drm codebase, really just implement fbdev
and v4l on top of the drm layer, some people might think this is some sort
of maintainer thing, but really nothing else makes sense, and having these
shared display frameworks just to avoid having using drm/kms drivers seems
totally pointless. Fix the drm fbdev emulation if an fbdev interface is
needed. But creating a fourth framework because our previous 3 frameworks
didn't work out doesn't seem like a situation I want to get behind too much.
I think there's a misunderstanding here. I'm definitely not trying to create a 
framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top 
of the same hardware device. That's an idea I really dislike, and I fully 
agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV 
emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 
isn't really a display and graphics API anyway.

My goal here is to share code for chips that are used by different "devices" 
(in the sense of an agregate device, such as a camera or a graphics card) 
supported by different subsystems. For instance, the same I2C-controlled HDMI 
transmitter can be used by a display device when connected to a display 
controller on an SoC, but can also be used by a video output device when 
connected to a video output (some complex TI SoCs have pass-through video 
pipelines with no associated frame buffer, making the V4L2 API better suited 
than DRM/KMS). As the first device would be supported by a DRM/KMS driver and 
the second device by a pure V4L2 driver, we need a common framework to share 
code between both.

If the same framework can be used to share panel drivers between DRM/KMS and 
pure FBDEV drivers (we have a bunch of those, not all of them will be ported 
to DRM/KMS, at least not in the very near future) that's also a bonus.

To summarize my point, CDF aims at creating a self-contained framework that 
can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various 
display-related devices. It does not provide any userspace API, and does not 
offer any way to share devices between the three subsystems at runtime. In a 
way you can think of CDF as a DRM panel framework, but without the drm_ 
prefix.

I hope this clarifies my goals. If not, or if there's still concerns and/or 
disagreements, let's discuss them.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 13:36:01

Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping me
to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
Q4 2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to probe hw
which may or may not be there, since on ARM we often don't have any
alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
they should really be treated as all one device. Especially to avoid
undefined suspend/resume ordering.
I tend to agree, except that I try to reuse the existing PM infrastructure 
when possible to avoid reinventing the wheel. So far handling suspend/resume 
ordering related to data busses in early suspend/late resume operations and 
allowing the Linux PM core to handle control busses using the Linux device 
tree worked pretty well.
CDF or some sort of mechanism to share panel drivers between drivers is
useful.  Keeping it within drm, is probably a good idea, if nothing else to
simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
avoid dealing with merging changes across multiple trees. Treating them more
like shared libraries and less like sub-devices which can be dynamically
loaded/unloaded (ie. they should be not built as separate modules or
suspend/resumed or probed/removed independently of the master driver) is a
really good idea to avoid uncovering nasty synchronization issues later
(remove vs modeset or pageflip) or surprising userspace in bad ways.
We've tried that in V4L2 years ago and realized that the approach led to a 
dead-end, especially when OF/DT got involved. With DT-based device probing, 
I2C camera sensors started getting probed asynchronously to the main camera 
device, as they are children of the I2C bus master. We will have similar 
issues with I2C HDMI transmitters or panels, so we should be prepared for it.

On PC hardware the I2C devices are connected to an I2C master provided by the 
GPU, but on embedded devices they are usually connected to an independent I2C 
master. We thus can't have a single self-contained driver that controls 
everything internally, and need to interface with the rest of the SoC drivers.

I agree that probing/removing devices independently of the master driver can 
lead to bad surprises, which is why I want to establish clear rules in CDF 
regarding what can and can't be done with display entities. Reference counting 
will be one way to make sure that devices don't disappear all of a sudden.
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For fbdev,
it is pretty clear that it is a dead end.  For v4l2 (subdev+mcf), it is
perhaps bit more flexible when it comes to random arbitrary hw pipelines
than kms.  But to take advantage of that, your userspace isn't going to be
portable anyways, so you might as well use driver specific
properties/ioctls.  But I tend to think that is more useful for cameras. 
And from userspace perspective, kms planes are less painful to use for
output than v4l2, so lets stick to drm/kms for output (and not try to add
camera/capture support to kms)..
Agreed. I've started to advocate the deprecation of FBDEV during LPC. The 
positive response has motivated me to continue doing so :-) For V4L2 the 
situation is a little bit different, I think V4L2 shouldn't be used for 
graphics and display hardware, but it still has use cases on the video output 
side for pure video devices (such as pass-through video pipelines with 
embedded processing for instance). As those can use subdevices found in 
display and graphics hardware, I'd like to avoid code duplication.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 13:37:38

Hi Daniel,

On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark [off-list ref] wrote:
quoted
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms.  But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls.  But I tend to think that is more
useful for cameras.  And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx
Yeah, I guess having a v4l device also exported by the same driver that
exports the drm interface might make sense in some cases. But in many cases
I think the video part is just an independent IP block and shuffling data
around with dma-buf is all we really need. So yeah, I guess sharing display
resources between v4l and drm kms driver should be a last resort option,
since coordination (especially if it's supposed to be somewhat dynamic) will
be extremely hairy.
I totally agree. As explained in my replies to Dave and Rob, I don't want to 
share devices between the different subsystems at runtime, but I'd like to 
avoid writing two drivers for a single device that can be used for display and 
graphics on one board, and video output on another board (HDMI transmitters 
are a good example).

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:08:06

Hi Marcus,

On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
On 12/18/2012 06:04 AM, Dave Airlie wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping me
to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
Q4 2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:
I like the effort, right now it seems like x86 and arm display sub systems
are quite different in terms of DRM driver (and HW) design. I think this is
partly due to little information shared about these different architectures
and ideas behind the choices made. I hope some discussion will light up both
sides. And an early discussion will hopefully give you less pain when CDF
drivers starts to get pushed your way.
On the topic of discussions, would anyone be interested in a 
BoF/brainstorming/whatever session during the FOSDEM ?
quoted
The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
Could you give an example? Personally I don't think it is that many. I
might not have counted the plat devs in all arm drivers. But the STE one
have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters).
Then of course there are all these panel devices. But I hope that when
CDF is "finished" we will have DSI devices on the DSI bus and DBI
devices on the DBI bus. I think most vendors have used platform devices
for these since they normally can't be probed in a generic way. But as
they are off SoC I feel this is not the best choice. And then many of
the panels are I2C devices (control bus) and that I guess is similar to
"x86" encoders/connectors?
Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the 
platform bus. Although I still believe that DSI and DBI busses would make 
sense, I agree that they don't provide much in terms of probing and power 
management. You can read the discussion at http://www.spinics.net/lists/linux-
fbdev/msg09250.html.
Another part of the difference I feel is that in x86 a DRM device is
most likely a PCI device, and as such has one huge driver for all IPs on
that board. The closest thing we get to that in ARM is probably the DSS
(collection of IPs on SoC, like 3D, 2D, display output, encoders). But
it doesn't fell right to create a single driver for all these. And as
you know often 3D is even from a separate vendor. All these lead up to a
slight increase in the number of devices and drivers. Right way, I feel
so, but you are welcome to show a better way.
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
I have no intention to use CDF outside KMS connector/encoder and I have
not heard Laurent talk about this either.
I don't either. CDF will mostly target KMS connectors, and can also be used 
for KMS encoders. I have no plan to touch the CRTC.
Personally I see CDF as "helpers" to create and reuse connector/encoder
drivers between SoCs instead of each SoC do their own panel drivers (which
would be about a hundred, times the number of supported SoCs). We probably
need to discuss the connector/encoder mappings to CDF/panels.
That's a topic I was planning to discuss at some point. One of the issues is 
that the KMS model can only have 3 entities in the pipeline, while hardware 
pipelines (especially in the embedded world) could be made of 4 or more 
entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI 
connector). We might not have to expose all details to userspace, but we need 
mapping rules.
But I think we need to flush out the higher level details like control bus
vs. data bus vs. display entities. While I like the generic way of the
display entities, I also like the pure bus/device/driver model without too
many generalizations.
Do you have any support in x86 world that could be compared to mobile
phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips
between the on chip/cpu/SoC CRTC and the external LCD depending on
product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86?
And if you do, how do you model/setup/share all those in DRM driver? Or
it is manageable (< 10) and not up in the hundreds of different
encoders/lcd-drivers?
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:18:21

Hi Sylwester,

On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
On 12/18/2012 07:21 AM, Rob Clark wrote:
quoted
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie[off-list ref]  wrote:
quoted
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
There have been already some ideas proposed to resolve this at the PM
subsystem level [1]. And this problem is of course not only specific to
platform drivers. The idea of having monolithic drivers, just because we
can't get the suspend/resume sequences right otherwise, doesn't really sound
appealing. SoC IPs get reused on multiple different SoC series, no only by
single manufacturer. Whole graphics/video subsystems are composed from
smaller blocks in SoCs, with various number of distinct sub-blocks and same
sub-blocks repeated different number of times in a specific SoC revision.
Expressing an IP as a platform device seems justified to me, often these
platform devices have enough differences to treat them as such. E.g. belong
in different power domain/use different clocks. Except there is big issue
with the power management... However probably more important is to be able
to have driver for a specific IP in a separate module.

And this suspend/resume ordering issue is not only about the platform
devices. E.g. camera subsystem can be composed of an image sensor sub-device
driver, which is most often an I2C client driver, and of multiple SoC
processing blocks. The image sensor can have dependencies on the SoC sub-
blocks. So even if we created monolithic driver for the SoC part, there are
still two pieces to get s/r ordering right - I2C client and SoC drivers. And
please don't propose to merge the sensor sub-device driver too. There has
been a lot of effort in V4L2 to separate those various functional blocks
into sub-devices, so they can be freely reused, without reimplementing same
functionality in each driver. BTW, there has been a nice talk about these
topics at ELCE [2], particularly slide 22 is interesting.

I believe the solution for these issues really needs to be sought in the PM
subsystem itself.
I tend to agree with you, or at least I believe we should research a proper 
solution in the PM framework. In the meantime, though, I think early 
suspend/late resume might provide an intermediate solution.
quoted
I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative.. but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.
[1] https://lkml.org/lkml/2009/9/9/373
[2]
http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:26:03

Hi Jani,

On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
On Tue, 18 Dec 2012, Laurent Pinchart wrote:
quoted
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
quoted
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's
what the C stands for, common refers to sharing panel and other display
entity drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the
KMS API. We might have to do so later if the hardware complexity grows in
such a way that finer control than what KMS provides needs to be exposed
to userspace, but I don't think we're there yet. The CDF API will thus
only be used internally in the kernel by display controller drivers. The
KMS core might get functions to handle common display entity operations,
but the bulk of the work will be in the display controller drivers to
start with. We will then see what can be abstracted in KMS helper
functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
CDF API. That's just a thought for now, I haven't tried to implement them,
but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a
generic way.

Do you have thoughts to share on this topic ?
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each display
controller has one, and can easily handle any chip specific requirements
right there. It's my gut feeling that an additional framework would just get
in the way. Perhaps there could be more common HDMI/DP helper style code in
DRM to reduce overlap across KMS drivers, but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
perspective? Or, put another way, is it more of an alternative to using DRM?
Please enlighten me if there's some real benefit here that I fail to see!
As Rob pointed out, you can have external HDMI/DP encoders, and even internal 
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at 
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.

CDF isn't an alternative to DRM/KMS. It should be seen as a framework that 
helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, 
although those should be ported to DRM/KMS) sharing encoder and connector 
code.
For DSI panels (or DSI-to-whatever bridges) it's of course another story.
You typically need a panel specific driver. And here I see the main point of
the whole CDF: decoupling display controllers and the panel drivers, and
sharing panel (and converter chip) specific drivers across display
controllers. Making it easy to write new drivers, as there would be a model
to follow. I'm definitely in favour of coming up with some framework that
would tackle that.
That's the main (and original) goal of CDF (originally called Generic Panel 
Framwork, and renamed to CDF to support encoder drivers as explained above). 
I'm glad to know that you're in favour of it :-)

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:30:20

Hi Tomi,

On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote:
On 2012-12-19 16:57, Jani Nikula wrote:
quoted
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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!
The use of CDF is an option, not something that has to be done. A DRM
driver developer may use it if it gives benefit for him for that
particular driver.

I don't know much about desktop display hardware, but I guess that using
CDF would not really give much there. In some cases it could, if the IPs
used on the graphics card are something that are used elsewhere also
(sounds quite unlikely, though). In that case there could be separate
drivers for the IPs.

And note that CDF is not really about the dispc side, i.e. the part that
creates the video stream from pixels in the memory. It's more about the
components after that, and how to connect those components.
quoted
For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.
Right. But if you implement drivers for DSI panels with CDF for, say,
OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
Otherwise it'll be a mishmash with two different models.
I second your point here, using CDF for encoders should be simpler, but it 
will not be enforced. A display controller driver developer who wants to 
control the on-SoC encoder without conforming to the CDF model will be totally 
free to do so and won't be blamed.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:34:21

Hi Rob,

On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
quoted
On Tue, 18 Dec 2012, Laurent Pinchart wrote:
quoted
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
quoted
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's
what the C stands for, common refers to sharing panel and other display
entity drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the
KMS API. We might have to do so later if the hardware complexity grows
in such a way that finer control than what KMS provides needs to be
exposed to userspace, but I don't think we're there yet. The CDF API
will thus only be used internally in the kernel by display controller
drivers. The KMS core might get functions to handle common display
entity operations, but the bulk of the work will be in the display
controller drivers to start with. We will then see what can be
abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
CDF API. That's just a thought for now, I haven't tried to implement
them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels
in a generic way.

Do you have thoughts to share on this topic ?
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each
display controller has one, and can easily handle any chip specific
requirements right there. It's my gut feeling that an additional
framework would just get in the way. Perhaps there could be more common
HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a
non-DRM perspective? Or, put another way, is it more of an alternative
to using DRM? Please enlighten me if there's some real benefit here that
I fail to see!
fwiw, I think there are at least a couple cases where multiple SoC's
have the same HDMI IP block.

And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just
something similar to what drivers/gpu/i2c is today) seems a bit
overkill for me.  Being able to use the helpers in drm and avoiding an
extra layer of translation seems like the better option to me.  So my
vote would be drivers/gpu/cdf.
I don't think there will be any need for translation (except perhaps between 
the DRM mode structures and the common video mode structure that is being 
discussed). Add a drm_ prefix to the existing CDF functions and structures, 
and there you go :-)

The reason why I'd like to keep CDF separate from DRM (or at least not 
requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 
drivers.
quoted
For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-12-24 17:39:06

Hi Rob,

(CC'ing Hans Verkuil)

On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
quoted
On 2012-12-19 17:26, Rob Clark wrote:
quoted
And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just something
similar to what drivers/gpu/i2c is today) seems a bit overkill for me. 
Being able to use the helpers in drm and avoiding an extra layer of
translation seems like the better option to me.  So my vote would be
drivers/gpu/cdf.
Well, we need to think about that. I would like to keep CDF independent
of DRM. I don't like tying different components/frameworks together if
there's no real need for that.

Also, something that Laurent mentioned in our face-to-face discussions:
Some IPs/chips can be used for other purposes than with DRM.

He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the framework used in these
cases is always v4l2.

The IPs/chips in the above model may be the exact same IPs/chips that
are used with "normal" display. If the CDF was tied to DRM, using the
same drivers for normal and these streaming cases would probably not be
possible.
Well, maybe there is a way, but it really seems to be over-complicating
things unnecessarily to keep CDF independent of DRM..  there will be a lot
more traditional uses of CDF compared to one crazy use-case.  So I don't
really fancy making it more difficult than in needs to be for everyone.
Most of the use cases will be in DRM, we agree on that. However, I don't think 
that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips 
that can process/capture/generate up to 18 (if my memory is correct) video 
streams, and those are extensively used in video conferencing solutions or set 
top boxes for instance. A couple of the output video streams are display-based 
and should be handled by DRM/KMS, but most of them are V4L2 streams. That's 
something we should discuss with Hans Verkuil, he might be able to provide us 
with more information.
Probably the thing to do is take a step back and reconsider that one crazy
use-case.  For example, KMS doesn't enforce that the buffer handled passed
when you create a drm framebuffer object to scan out is a GEM buffer.  So on
that one crazy platform, maybe it makes sense to have a DRM/KMS display
driver that takes a handle to identify which video stream coming from the
capture end of the pipeline.  Anyways, that is just an off-the-top-of-my-
head idea, probably there are other options too.
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-27 15:54:58

On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
[off-list ref] wrote:
Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
quoted
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping me
to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
Q4 2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to probe hw
which may or may not be there, since on ARM we often don't have any
alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
they should really be treated as all one device. Especially to avoid
undefined suspend/resume ordering.
I tend to agree, except that I try to reuse the existing PM infrastructure
when possible to avoid reinventing the wheel. So far handling suspend/resume
ordering related to data busses in early suspend/late resume operations and
allowing the Linux PM core to handle control busses using the Linux device
tree worked pretty well.
quoted
CDF or some sort of mechanism to share panel drivers between drivers is
useful.  Keeping it within drm, is probably a good idea, if nothing else to
simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
avoid dealing with merging changes across multiple trees. Treating them more
like shared libraries and less like sub-devices which can be dynamically
loaded/unloaded (ie. they should be not built as separate modules or
suspend/resumed or probed/removed independently of the master driver) is a
really good idea to avoid uncovering nasty synchronization issues later
(remove vs modeset or pageflip) or surprising userspace in bad ways.
We've tried that in V4L2 years ago and realized that the approach led to a
dead-end, especially when OF/DT got involved. With DT-based device probing,
I2C camera sensors started getting probed asynchronously to the main camera
device, as they are children of the I2C bus master. We will have similar
issues with I2C HDMI transmitters or panels, so we should be prepared for it.
What I've done to avoid that so far is that the master device
registers the drivers for it's output sub-devices before registering
it's own device.  At least this way I can control that they are probed
first.  Not the prettiest thing, but avoids even uglier problems.
On PC hardware the I2C devices are connected to an I2C master provided by the
GPU, but on embedded devices they are usually connected to an independent I2C
master. We thus can't have a single self-contained driver that controls
everything internally, and need to interface with the rest of the SoC drivers.

I agree that probing/removing devices independently of the master driver can
lead to bad surprises, which is why I want to establish clear rules in CDF
regarding what can and can't be done with display entities. Reference counting
will be one way to make sure that devices don't disappear all of a sudden.
That at least helps cover some issues.. although it doesn't really
help userspace confusion.

Anyways, with enough work perhaps all problems could be solved..
otoh, there are plenty of other important problems to solve in the
world of gpus and kms, so my preference is always not to needlessly
over-complicate CDF and instead leave some time for other things

BR,
-R
quoted
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For fbdev,
it is pretty clear that it is a dead end.  For v4l2 (subdev+mcf), it is
perhaps bit more flexible when it comes to random arbitrary hw pipelines
than kms.  But to take advantage of that, your userspace isn't going to be
portable anyways, so you might as well use driver specific
properties/ioctls.  But I tend to think that is more useful for cameras.
And from userspace perspective, kms planes are less painful to use for
output than v4l2, so lets stick to drm/kms for output (and not try to add
camera/capture support to kms)..
Agreed. I've started to advocate the deprecation of FBDEV during LPC. The
positive response has motivated me to continue doing so :-) For V4L2 the
situation is a little bit different, I think V4L2 shouldn't be used for
graphics and display hardware, but it still has use cases on the video output
side for pure video devices (such as pass-through video pipelines with
embedded processing for instance). As those can use subdevices found in
display and graphics hardware, I'd like to avoid code duplication.

--
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-27 15:57:28

On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
[off-list ref] wrote:
On the topic of discussions, would anyone be interested in a
BoF/brainstorming/whatever session during the FOSDEM ?
I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it
looks like at least Daniel will be there.  If enough others are, it
could be a good idea.

BR,
-R

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-27 16:04:23

On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart
[off-list ref] wrote:
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
quoted
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each display
controller has one, and can easily handle any chip specific requirements
right there. It's my gut feeling that an additional framework would just get
in the way. Perhaps there could be more common HDMI/DP helper style code in
DRM to reduce overlap across KMS drivers, but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
perspective? Or, put another way, is it more of an alternative to using DRM?
Please enlighten me if there's some real benefit here that I fail to see!
As Rob pointed out, you can have external HDMI/DP encoders, and even internal
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.
just fwiw, drm already has something a bit like this.. the i2c
encoder-slave.  With support for a couple external i2c encoders which
could in theory be shared between devices.

BR,
-R

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-27 16:10:13

On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart
[off-list ref] wrote:
On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
quoted
And, there are also external HDMI encoders (for example connected over
i2c) that can also be shared between boards.  So I think there will be
a number of cases where CDF is appropriate for HDMI drivers.  Although
trying to keep this all independent of DRM (as opposed to just
something similar to what drivers/gpu/i2c is today) seems a bit
overkill for me.  Being able to use the helpers in drm and avoiding an
extra layer of translation seems like the better option to me.  So my
vote would be drivers/gpu/cdf.
I don't think there will be any need for translation (except perhaps between
the DRM mode structures and the common video mode structure that is being
discussed). Add a drm_ prefix to the existing CDF functions and structures,
and there you go :-)
well, and translation for any properties that we'd want to expose to
userspace, etc, etc.. I see there being a big potential for a lot of
needless glue

BR,
-R
The reason why I'd like to keep CDF separate from DRM (or at least not
requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2
drivers.
quoted
quoted
For DSI panels (or DSI-to-whatever bridges) it's of course another
story. You typically need a panel specific driver. And here I see the
main point of the whole CDF: decoupling display controllers and the
panel drivers, and sharing panel (and converter chip) specific drivers
across display controllers. Making it easy to write new drivers, as
there would be a model to follow. I'm definitely in favour of coming up
with some framework that would tackle that.
--
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 0/5] Common Display Framework

From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2012-12-27 19:19:16

On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
quoted
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping me
to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
Q4 2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to probe hw
which may or may not be there, since on ARM we often don't have any
alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
they should really be treated as all one device. Especially to avoid
undefined suspend/resume ordering.
I tend to agree, except that I try to reuse the existing PM infrastructure
when possible to avoid reinventing the wheel. So far handling suspend/resume
ordering related to data busses in early suspend/late resume operations and
allowing the Linux PM core to handle control busses using the Linux device
tree worked pretty well.
quoted
CDF or some sort of mechanism to share panel drivers between drivers is
useful.  Keeping it within drm, is probably a good idea, if nothing else to
simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
avoid dealing with merging changes across multiple trees. Treating them more
like shared libraries and less like sub-devices which can be dynamically
loaded/unloaded (ie. they should be not built as separate modules or
suspend/resumed or probed/removed independently of the master driver) is a
really good idea to avoid uncovering nasty synchronization issues later
(remove vs modeset or pageflip) or surprising userspace in bad ways.
We've tried that in V4L2 years ago and realized that the approach led to a
dead-end, especially when OF/DT got involved. With DT-based device probing,
I2C camera sensors started getting probed asynchronously to the main camera
device, as they are children of the I2C bus master. We will have similar
issues with I2C HDMI transmitters or panels, so we should be prepared for it.
What I've done to avoid that so far is that the master device
registers the drivers for it's output sub-devices before registering
it's own device.  At least this way I can control that they are probed
first.  Not the prettiest thing, but avoids even uglier problems.
This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC v2 0/5] Common Display Framework

From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2012-12-27 19:19:17

On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote:
On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
quoted
It just seems to me that, at least from a DRM/KMS perspective, adding
another layer (ÍF) 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 drivers for them. Each display
controller has one, and can easily handle any chip specific requirements
right there. It's my gut feeling that an additional framework would just get
in the way. Perhaps there could be more common HDMI/DP helper style code in
DRM to reduce overlap across KMS drivers, but that's another thing.

So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
perspective? Or, put another way, is it more of an alternative to using DRM?
Please enlighten me if there's some real benefit here that I fail to see!
As Rob pointed out, you can have external HDMI/DP encoders, and even internal
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.
just fwiw, drm already has something a bit like this.. the i2c
encoder-slave.  With support for a couple external i2c encoders which
could in theory be shared between devices.
The problem with this code is that it only works when the i2c device is
registered by a master driver. Once the i2c device comes from the
devicetree there is no possibility to find it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2012-12-27 19:57:58

On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer [off-list ref] wrote:
On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
quoted
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
quoted
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping me
to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
Q4 2012, and Linaro for inviting me to Connect and providing a venue to
discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to probe hw
which may or may not be there, since on ARM we often don't have any
alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
they should really be treated as all one device. Especially to avoid
undefined suspend/resume ordering.
I tend to agree, except that I try to reuse the existing PM infrastructure
when possible to avoid reinventing the wheel. So far handling suspend/resume
ordering related to data busses in early suspend/late resume operations and
allowing the Linux PM core to handle control busses using the Linux device
tree worked pretty well.
quoted
CDF or some sort of mechanism to share panel drivers between drivers is
useful.  Keeping it within drm, is probably a good idea, if nothing else to
simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
avoid dealing with merging changes across multiple trees. Treating them more
like shared libraries and less like sub-devices which can be dynamically
loaded/unloaded (ie. they should be not built as separate modules or
suspend/resumed or probed/removed independently of the master driver) is a
really good idea to avoid uncovering nasty synchronization issues later
(remove vs modeset or pageflip) or surprising userspace in bad ways.
We've tried that in V4L2 years ago and realized that the approach led to a
dead-end, especially when OF/DT got involved. With DT-based device probing,
I2C camera sensors started getting probed asynchronously to the main camera
device, as they are children of the I2C bus master. We will have similar
issues with I2C HDMI transmitters or panels, so we should be prepared for it.
What I've done to avoid that so far is that the master device
registers the drivers for it's output sub-devices before registering
it's own device.  At least this way I can control that they are probed
first.  Not the prettiest thing, but avoids even uglier problems.
This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.
well, it can be brute-forced..  ie. drm driver calls common
register_all_panels() fxn, which, well, registers all the
panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
defines.  If you anyways aren't building the panels as separate
modules, that would work.  Maybe not the most *elegant* approach, but
simple and functional.

I guess it partly depends on the structure in devicetree.  If you are
assuming that the i2c encoder belongs inside the i2c bus, like:

  &i2cN {
    foo-i2c-encoder {
      ....
    };
  };

and you are letting devicetree create the devices, then it doesn't
quite work.  I'm not entirely convinced you should do it that way.
Really any device like that is going to be hooked up to at least a
couple busses..  i2c, some sort of bus carrying pixel data, maybe some
gpio's, etc.  So maybe makes more sense for a virtual drm/kms bus, and
then use phandle stuff to link it to the various other busses it
needs:

  mydrmdev {
    foo-i2c-encoder {
       i2c = <&i2cN>;
       gpio = <&gpioM 2 3>
       ...
    };
  };

ok, admittedly that is a bit different from other proposals about how
this all fits in devicetree.. but otoh, I'm not a huge believer in
letting something that is supposed to make life easier (DT), actually
make things harder or more complicated.  Plus this CDF stuff all needs
to also work on platforms not using OF/DT.

BR,
-R
Sascha

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 0/5] Common Display Framework

From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2012-12-28 00:04:18

On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer [off-list ref] wrote:
quoted
On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
quoted
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.
well, it can be brute-forced..  ie. drm driver calls common
register_all_panels() fxn, which, well, registers all the
panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
defines.  If you anyways aren't building the panels as separate
modules, that would work.  Maybe not the most *elegant* approach, but
simple and functional.

I guess it partly depends on the structure in devicetree.  If you are
assuming that the i2c encoder belongs inside the i2c bus, like:

  &i2cN {
    foo-i2c-encoder {
      ....
    };
  };

and you are letting devicetree create the devices, then it doesn't
quite work.  I'm not entirely convinced you should do it that way.
Really any device like that is going to be hooked up to at least a
couple busses..  i2c, some sort of bus carrying pixel data, maybe some
gpio's, etc.  So maybe makes more sense for a virtual drm/kms bus, and
then use phandle stuff to link it to the various other busses it
needs:

  mydrmdev {
    foo-i2c-encoder {
       i2c = <&i2cN>;
       gpio = <&gpioM 2 3>
       ...
    };
  };
This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.

It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.

I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.

Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.
ok, admittedly that is a bit different from other proposals about how
this all fits in devicetree.. but otoh, I'm not a huge believer in
letting something that is supposed to make life easier (DT), actually
make things harder or more complicated.  Plus this CDF stuff all needs
to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.

CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC v2 0/5] Common Display Framework

From: Daniel Vetter <hidden>
Date: 2013-01-06 17:52:56

On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote:
On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
On the topic of discussions, would anyone be interested in a
BoF/brainstorming/whatever session during the FOSDEM ?
I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it
looks like at least Daniel will be there.  If enough others are, it
could be a good idea.
Seconded. Jesse should be there, too, and from the Helsinki guys Ville and
Andy should show up. Doesn't look like Jani will be able to make it. I
think something on Sunday (to not clash with the X devroom) would be good.

Should we apply for an offical BOF/Is there a process for tahat? Adding
Luc in case he knows ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2013-01-08 08:24:10

Hi Rob,

On Thursday 27 December 2012 09:54:55 Rob Clark wrote:
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart wrote:
quoted
On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
quoted
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie [off-list ref] wrote:
quoted
quoted
Many developers showed interest in the first RFC, and I've had the
opportunity to discuss it with most of them. I would like to thank (in
no particular order) Tomi Valkeinen for all the time he spend helping
me to draft v2, Marcus Lorentzon for his useful input during Linaro
Connect Q4 2012, and Linaro for inviting me to Connect and providing a
venue to discuss this topic.
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to probe
hw which may or may not be there, since on ARM we often don't have any
alternative.. but beyond that, suspend/resume, and other life-cycle
aspects, they should really be treated as all one device. Especially to
avoid undefined suspend/resume ordering.
I tend to agree, except that I try to reuse the existing PM infrastructure
when possible to avoid reinventing the wheel. So far handling
suspend/resume ordering related to data busses in early suspend/late
resume operations and allowing the Linux PM core to handle control busses
using the Linux device tree worked pretty well.
quoted
CDF or some sort of mechanism to share panel drivers between drivers is
useful.  Keeping it within drm, is probably a good idea, if nothing else
to simplify re-use of helper fxns (like avi-infoframe stuff, for example)
and avoid dealing with merging changes across multiple trees. Treating
them more like shared libraries and less like sub-devices which can be
dynamically loaded/unloaded (ie. they should be not built as separate
modules or suspend/resumed or probed/removed independently of the master
driver) is a really good idea to avoid uncovering nasty synchronization
issues later (remove vs modeset or pageflip) or surprising userspace in
bad ways.
We've tried that in V4L2 years ago and realized that the approach led to a
dead-end, especially when OF/DT got involved. With DT-based device
probing, I2C camera sensors started getting probed asynchronously to the
main camera device, as they are children of the I2C bus master. We will
have similar issues with I2C HDMI transmitters or panels, so we should be
prepared for it.
What I've done to avoid that so far is that the master device registers the
drivers for it's output sub-devices before registering it's own device.
I'm not sure to follow you here. The master device doesn't register anything, 
do you mean the master device driver ? If so, how does the master device 
driver register its own device ? Devices are not registered by their driver.
At least this way I can control that they are probed first. Not the
prettiest thing, but avoids even uglier problems.
quoted
On PC hardware the I2C devices are connected to an I2C master provided by
the GPU, but on embedded devices they are usually connected to an
independent I2C master. We thus can't have a single self-contained driver
that controls everything internally, and need to interface with the rest
of the SoC drivers.

I agree that probing/removing devices independently of the master driver
can lead to bad surprises, which is why I want to establish clear rules
in CDF regarding what can and can't be done with display entities.
Reference counting will be one way to make sure that devices don't
disappear all of a sudden.
That at least helps cover some issues.. although it doesn't really help
userspace confusion.

Anyways, with enough work perhaps all problems could be solved.. otoh, there
are plenty of other important problems to solve in the world of gpus and
kms, so my preference is always not to needlessly over-complicate CDF and
instead leave some time for other things
My customer is interested in CDF at the moment. If they ask me to solve other 
GPU-related problems, sure, I can work on that, but that's not planned.
quoted
quoted
quoted
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2 (subdev+mcf),
it is perhaps bit more flexible when it comes to random arbitrary hw
pipelines than kms.  But to take advantage of that, your userspace isn't
going to be portable anyways, so you might as well use driver specific
properties/ioctls.  But I tend to think that is more useful for cameras.
And from userspace perspective, kms planes are less painful to use for
output than v4l2, so lets stick to drm/kms for output (and not try to add
camera/capture support to kms)..
Agreed. I've started to advocate the deprecation of FBDEV during LPC. The
positive response has motivated me to continue doing so :-) For V4L2 the
situation is a little bit different, I think V4L2 shouldn't be used for
graphics and display hardware, but it still has use cases on the video
output side for pure video devices (such as pass-through video pipelines
with embedded processing for instance). As those can use subdevices found
in display and graphics hardware, I'd like to avoid code duplication.
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2013-01-08 08:31:36

On Friday 28 December 2012 01:04:04 Sascha Hauer wrote:
On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
quoted
On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote:
quoted
On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
quoted
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.
well, it can be brute-forced..  ie. drm driver calls common
register_all_panels() fxn, which, well, registers all the
panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
defines.  If you anyways aren't building the panels as separate
modules, that would work.  Maybe not the most *elegant* approach, but
simple and functional.

I guess it partly depends on the structure in devicetree.  If you are

assuming that the i2c encoder belongs inside the i2c bus, like:
  &i2cN {
  
    foo-i2c-encoder {
    
      ....
    
    };
  
  };

and you are letting devicetree create the devices, then it doesn't
quite work.  I'm not entirely convinced you should do it that way.
Really any device like that is going to be hooked up to at least a
couple busses..  i2c, some sort of bus carrying pixel data, maybe some
gpio's, etc.  So maybe makes more sense for a virtual drm/kms bus, and
then use phandle stuff to link it to the various other busses it

needs:
  mydrmdev {
    foo-i2c-encoder {
       i2c = <&i2cN>;
       gpio = <&gpioM 2 3>
       ...
    };
  };
This seems to shift initialization order problem to another place. Here we
have to make sure the controller is initialized before the drm driver. Same
with suspend/resume.

It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address space.

I think grouping the different units together in a devicetree blob because
we think they might form a logical virtual device is not going to work. It
might make it easier from a drm perspective, but I think doing this will
make for a lot of special cases. What will happen for example if you have
two encoder devices in a row to configure? The foo-i2c-encoder would then
get another child node.

Right now the devicetree is strictly ordered by (control-, not data-) bus
topology. Linux has great helper code to support this model. Giving up this
help to brute force a different topology and then trying to fit the result
back into the Linux Bus hierarchy doesn't sound like a good idea to me.
I agree. The Linux device model is architectured around a control bus based 
tree, I don't want to change that. With devices hooked up on several busses we 
will have dependency issues anyway, regardless of how we describe them in DT. 
If we hook up the nodes from a data bus perspective we will run into control 
bus dependency issues. It's thus better in my opinion to keep the classic 
control bus based model and solve the data bus dependency issues.
quoted
ok, admittedly that is a bit different from other proposals about how
this all fits in devicetree.. but otoh, I'm not a huge believer in
letting something that is supposed to make life easier (DT), actually
make things harder or more complicated.  Plus this CDF stuff all needs
to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.

CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.
-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2013-01-08 08:39:38

Hi Daniel,

On Sunday 06 January 2013 18:46:47 Daniel Vetter wrote:
On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote:
quoted
On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart wrote:
quoted
On the topic of discussions, would anyone be interested in a
BoF/brainstorming/whatever session during the FOSDEM ?
I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it
looks like at least Daniel will be there.  If enough others are, it
could be a good idea.
Seconded. Jesse should be there, too, and from the Helsinki guys Ville and
Andy should show up. Doesn't look like Jani will be able to make it. I think
something on Sunday (to not clash with the X devroom) would be good.

Should we apply for an offical BOF/Is there a process for tahat? Adding
Luc in case he knows ...
From the event website it looks like there are free rooms on Sunday, it would 
be good if we could secure one of them.

Are there other X/display related topics that need to be discussed on Sunday ? 
How much time should we set aside ?

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2013-01-08 16:13:49

On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart
[off-list ref] wrote:
Hi Rob,

On Thursday 27 December 2012 09:54:55 Rob Clark wrote:
quoted
What I've done to avoid that so far is that the master device registers the
drivers for it's output sub-devices before registering it's own device.
I'm not sure to follow you here. The master device doesn't register anything,
do you mean the master device driver ? If so, how does the master device
driver register its own device ? Devices are not registered by their driver.
sorry, that should have read "master driver registers drivers for it's
sub-devices.."

BR,
-R

Re: [RFC v2 0/5] Common Display Framework

From: Rahul Sharma <hidden>
Date: 2013-01-09 08:29:47

Hi Laurent,

CDF will also be helpful in supporting Panels with integrated
audio (HDMI/DP) if we can add audio related control operations to
display_entity_control_ops. Video controls will be called by crtc
in DRM/V4L and audio controls from Alsa.

Secondly, if I need to support get_modes operation in hdmi/dp
panel, I need to implement edid parser inside the panel driver. It
will be meaningful to add get_edid control operation for hdmi/dp.

regards,
Rahul Sharma.

On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark [off-list ref] wrote:
On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
Hi Rob,

On Thursday 27 December 2012 09:54:55 Rob Clark wrote:
quoted
What I've done to avoid that so far is that the master device registers the
drivers for it's output sub-devices before registering it's own device.
I'm not sure to follow you here. The master device doesn't register anything,
do you mean the master device driver ? If so, how does the master device
driver register its own device ? Devices are not registered by their driver.
sorry, that should have read "master driver registers drivers for it's
sub-devices.."

BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2013-02-01 23:41:57

Hi Rahul,

On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote:
Hi Laurent,

CDF will also be helpful in supporting Panels with integrated audio
(HDMI/DP) if we can add audio related control operations to
display_entity_control_ops. Video controls will be called by crtc in DRM/V4L
and audio controls from Alsa.
I knew that would come up at some point :-) I agree with you that adding audio 
support would be a very nice improvement, and I'm totally open to that, but I 
will concentrate on video, at least to start with. The first reason is that 
I'm not familiar enough with ALSA, and the second that there's only 24h per 
day :-)

Please feel free, of course, to submit a proposal for audio support.
Secondly, if I need to support get_modes operation in hdmi/dp panel, I need
to implement edid parser inside the panel driver. It will be meaningful to
add get_edid control operation for hdmi/dp.
Even if EDID data is parsed in the panel driver, raw EDID will still need to 
be exported, so a get_edid control operation (or something similar) is 
definitely needed. There's no disagreement on this, I just haven't included 
that operation yet because my test hardware is purely panel-based.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 0/5] Common Display Framework

From: Rob Clark <hidden>
Date: 2013-02-02 10:08:34

On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart
[off-list ref] wrote:
Hi Rahul,

On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote:
quoted
Hi Laurent,

CDF will also be helpful in supporting Panels with integrated audio
(HDMI/DP) if we can add audio related control operations to
display_entity_control_ops. Video controls will be called by crtc in DRM/V4L
and audio controls from Alsa.
I knew that would come up at some point :-) I agree with you that adding audio
support would be a very nice improvement, and I'm totally open to that, but I
will concentrate on video, at least to start with. The first reason is that
I'm not familiar enough with ALSA, and the second that there's only 24h per
day :-)

Please feel free, of course, to submit a proposal for audio support.
quoted
Secondly, if I need to support get_modes operation in hdmi/dp panel, I need
to implement edid parser inside the panel driver. It will be meaningful to
add get_edid control operation for hdmi/dp.
Even if EDID data is parsed in the panel driver, raw EDID will still need to
be exported, so a get_edid control operation (or something similar) is
definitely needed. There's no disagreement on this, I just haven't included
that operation yet because my test hardware is purely panel-based.
one of (probably many) places that just keeping CDF (CDH? common
display helpers..) inside DRM makes life easier :-P

BR,
-R
--
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help