* [PATCHv2 2/5] videomode: combine videomode dmt_flags and data_flags
From: Tomi Valkeinen @ 2013-03-27 6:58 UTC (permalink / raw)
To: Steffen Trumtrar, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <1364367505-4366-1-git-send-email-tomi.valkeinen@ti.com>
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY_FLAGS_*.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/gpu/drm/drm_modes.c | 12 ++++++------
drivers/video/fbmon.c | 8 ++++----
drivers/video/of_display_timing.c | 19 +++++++++----------
drivers/video/videomode.c | 3 +--
include/video/display_timing.h | 26 +++++++++++---------------
include/video/videomode.h | 3 +--
6 files changed, 32 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0698c0e..f83f071 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -523,17 +523,17 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
dmode->clock = vm->pixelclock / 1000;
dmode->flags = 0;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
dmode->flags |= DRM_MODE_FLAG_PHSYNC;
- else if (vm->dmt_flags & VESA_DMT_HSYNC_LOW)
+ else if (vm->flags & DISPLAY_FLAGS_HSYNC_LOW)
dmode->flags |= DRM_MODE_FLAG_NHSYNC;
- if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
+ if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH)
dmode->flags |= DRM_MODE_FLAG_PVSYNC;
- else if (vm->dmt_flags & VESA_DMT_VSYNC_LOW)
+ else if (vm->flags & DISPLAY_FLAGS_VSYNC_LOW)
dmode->flags |= DRM_MODE_FLAG_NVSYNC;
- if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ if (vm->flags & DISPLAY_FLAGS_INTERLACED)
dmode->flags |= DRM_MODE_FLAG_INTERLACE;
- if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
drm_mode_set_name(dmode);
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 368cedf..e5cc2fd 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1398,13 +1398,13 @@ int fb_videomode_from_videomode(const struct videomode *vm,
fbmode->sync = 0;
fbmode->vmode = 0;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
- if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ if (vm->flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
- if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
fbmode->vmode |= FB_VMODE_DOUBLE;
fbmode->flag = 0;
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 13ecd98..56009bc 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -79,25 +79,24 @@ static struct display_timing *of_get_display_timing(struct device_node *np)
ret |= parse_timing_property(np, "vsync-len", &dt->vsync_len);
ret |= parse_timing_property(np, "clock-frequency", &dt->pixelclock);
- dt->dmt_flags = 0;
- dt->data_flags = 0;
+ dt->flags = 0;
if (!of_property_read_u32(np, "vsync-active", &val))
- dt->dmt_flags |= val ? VESA_DMT_VSYNC_HIGH :
- VESA_DMT_VSYNC_LOW;
+ dt->flags |= val ? DISPLAY_FLAGS_VSYNC_HIGH :
+ DISPLAY_FLAGS_VSYNC_LOW;
if (!of_property_read_u32(np, "hsync-active", &val))
- dt->dmt_flags |= val ? VESA_DMT_HSYNC_HIGH :
- VESA_DMT_HSYNC_LOW;
+ dt->flags |= val ? DISPLAY_FLAGS_HSYNC_HIGH :
+ DISPLAY_FLAGS_HSYNC_LOW;
if (!of_property_read_u32(np, "de-active", &val))
- dt->data_flags |= val ? DISPLAY_FLAGS_DE_HIGH :
+ dt->flags |= val ? DISPLAY_FLAGS_DE_HIGH :
DISPLAY_FLAGS_DE_LOW;
if (!of_property_read_u32(np, "pixelclk-active", &val))
- dt->data_flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE :
+ dt->flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE :
DISPLAY_FLAGS_PIXDATA_NEGEDGE;
if (of_property_read_bool(np, "interlaced"))
- dt->data_flags |= DISPLAY_FLAGS_INTERLACED;
+ dt->flags |= DISPLAY_FLAGS_INTERLACED;
if (of_property_read_bool(np, "doublescan"))
- dt->data_flags |= DISPLAY_FLAGS_DOUBLESCAN;
+ dt->flags |= DISPLAY_FLAGS_DOUBLESCAN;
if (ret) {
pr_err("%s: error reading timing properties\n",
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
index 21c47a2..810afff 100644
--- a/drivers/video/videomode.c
+++ b/drivers/video/videomode.c
@@ -31,8 +31,7 @@ int videomode_from_timing(const struct display_timings *disp,
vm->vback_porch = display_timing_get_value(&dt->vback_porch, TE_TYP);
vm->vsync_len = display_timing_get_value(&dt->vsync_len, TE_TYP);
- vm->dmt_flags = dt->dmt_flags;
- vm->data_flags = dt->data_flags;
+ vm->flags = dt->flags;
return 0;
}
diff --git a/include/video/display_timing.h b/include/video/display_timing.h
index 71e9a38..a8a4be5 100644
--- a/include/video/display_timing.h
+++ b/include/video/display_timing.h
@@ -12,19 +12,16 @@
#include <linux/bitops.h>
#include <linux/types.h>
-/* VESA display monitor timing parameters */
-#define VESA_DMT_HSYNC_LOW BIT(0)
-#define VESA_DMT_HSYNC_HIGH BIT(1)
-#define VESA_DMT_VSYNC_LOW BIT(2)
-#define VESA_DMT_VSYNC_HIGH BIT(3)
-
-/* display specific flags */
-#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */
-#define DISPLAY_FLAGS_DE_HIGH BIT(1)
-#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */
-#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */
-#define DISPLAY_FLAGS_INTERLACED BIT(4)
-#define DISPLAY_FLAGS_DOUBLESCAN BIT(5)
+#define DISPLAY_FLAGS_HSYNC_LOW BIT(0)
+#define DISPLAY_FLAGS_HSYNC_HIGH BIT(1)
+#define DISPLAY_FLAGS_VSYNC_LOW BIT(2)
+#define DISPLAY_FLAGS_VSYNC_HIGH BIT(3)
+#define DISPLAY_FLAGS_DE_LOW BIT(4) /* data enable flag */
+#define DISPLAY_FLAGS_DE_HIGH BIT(5)
+#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(6) /* drive data on pos. edge */
+#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(7) /* drive data on neg. edge */
+#define DISPLAY_FLAGS_INTERLACED BIT(8)
+#define DISPLAY_FLAGS_DOUBLESCAN BIT(9)
/*
* A single signal can be specified via a range of minimal and maximal values
@@ -72,8 +69,7 @@ struct display_timing {
struct timing_entry vback_porch; /* ver. back porch */
struct timing_entry vsync_len; /* ver. sync len */
- unsigned int dmt_flags; /* VESA DMT flags */
- unsigned int data_flags; /* video data flags */
+ unsigned int flags; /* display flags */
};
/*
diff --git a/include/video/videomode.h b/include/video/videomode.h
index a421562..f4ae6ed 100644
--- a/include/video/videomode.h
+++ b/include/video/videomode.h
@@ -29,8 +29,7 @@ struct videomode {
u32 vback_porch;
u32 vsync_len;
- unsigned int dmt_flags; /* VESA DMT flags */
- unsigned int data_flags; /* video data flags */
+ unsigned int flags; /* display flags */
};
/**
--
1.7.10.4
^ permalink raw reply related
* [PATCHv2 3/5] videomode: create enum for videomode's display flags
From: Tomi Valkeinen @ 2013-03-27 6:58 UTC (permalink / raw)
To: Steffen Trumtrar, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <1364367505-4366-1-git-send-email-tomi.valkeinen@ti.com>
Instead of having plain defines for the videomode's flags, add an enum
for the flags. This makes the flags clearer to use, as the enum tells
which values can be used with the flags field.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
include/video/display_timing.h | 28 +++++++++++++++++-----------
include/video/videomode.h | 2 +-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/include/video/display_timing.h b/include/video/display_timing.h
index a8a4be5..b63471d 100644
--- a/include/video/display_timing.h
+++ b/include/video/display_timing.h
@@ -12,16 +12,22 @@
#include <linux/bitops.h>
#include <linux/types.h>
-#define DISPLAY_FLAGS_HSYNC_LOW BIT(0)
-#define DISPLAY_FLAGS_HSYNC_HIGH BIT(1)
-#define DISPLAY_FLAGS_VSYNC_LOW BIT(2)
-#define DISPLAY_FLAGS_VSYNC_HIGH BIT(3)
-#define DISPLAY_FLAGS_DE_LOW BIT(4) /* data enable flag */
-#define DISPLAY_FLAGS_DE_HIGH BIT(5)
-#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(6) /* drive data on pos. edge */
-#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(7) /* drive data on neg. edge */
-#define DISPLAY_FLAGS_INTERLACED BIT(8)
-#define DISPLAY_FLAGS_DOUBLESCAN BIT(9)
+enum display_flags {
+ DISPLAY_FLAGS_HSYNC_LOW = BIT(0),
+ DISPLAY_FLAGS_HSYNC_HIGH = BIT(1),
+ DISPLAY_FLAGS_VSYNC_LOW = BIT(2),
+ DISPLAY_FLAGS_VSYNC_HIGH = BIT(3),
+
+ /* data enable flag */
+ DISPLAY_FLAGS_DE_LOW = BIT(4),
+ DISPLAY_FLAGS_DE_HIGH = BIT(5),
+ /* drive data on pos. edge */
+ DISPLAY_FLAGS_PIXDATA_POSEDGE = BIT(6),
+ /* drive data on neg. edge */
+ DISPLAY_FLAGS_PIXDATA_NEGEDGE = BIT(7),
+ DISPLAY_FLAGS_INTERLACED = BIT(8),
+ DISPLAY_FLAGS_DOUBLESCAN = BIT(9),
+};
/*
* A single signal can be specified via a range of minimal and maximal values
@@ -69,7 +75,7 @@ struct display_timing {
struct timing_entry vback_porch; /* ver. back porch */
struct timing_entry vsync_len; /* ver. sync len */
- unsigned int flags; /* display flags */
+ enum display_flags flags; /* display flags */
};
/*
diff --git a/include/video/videomode.h b/include/video/videomode.h
index f4ae6ed..8b12e60 100644
--- a/include/video/videomode.h
+++ b/include/video/videomode.h
@@ -29,7 +29,7 @@ struct videomode {
u32 vback_porch;
u32 vsync_len;
- unsigned int flags; /* display flags */
+ enum display_flags flags; /* display flags */
};
/**
--
1.7.10.4
^ permalink raw reply related
* [PATCHv2 4/5] videomode: remove timing_entry_index
From: Tomi Valkeinen @ 2013-03-27 6:58 UTC (permalink / raw)
To: Steffen Trumtrar, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <1364367505-4366-1-git-send-email-tomi.valkeinen@ti.com>
Display timing's fields have minimum, typical and maximum values. These
can be accessed by using timing_entry_index enum, and
display_timing_get_value() function.
There's no real need for this extra complexity. The values can be
accessed more easily by just using the min/typ/max fields.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/video/videomode.c | 18 +++++++++---------
include/video/display_timing.h | 25 -------------------------
2 files changed, 9 insertions(+), 34 deletions(-)
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
index 810afff..a3d95f2 100644
--- a/drivers/video/videomode.c
+++ b/drivers/video/videomode.c
@@ -20,16 +20,16 @@ int videomode_from_timing(const struct display_timings *disp,
if (!dt)
return -EINVAL;
- vm->pixelclock = display_timing_get_value(&dt->pixelclock, TE_TYP);
- vm->hactive = display_timing_get_value(&dt->hactive, TE_TYP);
- vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, TE_TYP);
- vm->hback_porch = display_timing_get_value(&dt->hback_porch, TE_TYP);
- vm->hsync_len = display_timing_get_value(&dt->hsync_len, TE_TYP);
+ vm->pixelclock = dt->pixelclock.typ;
+ vm->hactive = dt->hactive.typ;
+ vm->hfront_porch = dt->hfront_porch.typ;
+ vm->hback_porch = dt->hback_porch.typ;
+ vm->hsync_len = dt->hsync_len.typ;
- vm->vactive = display_timing_get_value(&dt->vactive, TE_TYP);
- vm->vfront_porch = display_timing_get_value(&dt->vfront_porch, TE_TYP);
- vm->vback_porch = display_timing_get_value(&dt->vback_porch, TE_TYP);
- vm->vsync_len = display_timing_get_value(&dt->vsync_len, TE_TYP);
+ vm->vactive = dt->vactive.typ;
+ vm->vfront_porch = dt->vfront_porch.typ;
+ vm->vback_porch = dt->vback_porch.typ;
+ vm->vsync_len = dt->vsync_len.typ;
vm->flags = dt->flags;
diff --git a/include/video/display_timing.h b/include/video/display_timing.h
index b63471d..5d0259b 100644
--- a/include/video/display_timing.h
+++ b/include/video/display_timing.h
@@ -39,12 +39,6 @@ struct timing_entry {
u32 max;
};
-enum timing_entry_index {
- TE_MIN = 0,
- TE_TYP = 1,
- TE_MAX = 2,
-};
-
/*
* Single "mode" entry. This describes one set of signal timings a display can
* have in one setting. This struct can later be converted to struct videomode
@@ -91,25 +85,6 @@ struct display_timings {
struct display_timing **timings;
};
-/* get value specified by index from struct timing_entry */
-static inline u32 display_timing_get_value(const struct timing_entry *te,
- enum timing_entry_index index)
-{
- switch (index) {
- case TE_MIN:
- return te->min;
- break;
- case TE_TYP:
- return te->typ;
- break;
- case TE_MAX:
- return te->max;
- break;
- default:
- return te->typ;
- }
-}
-
/* get one entry from struct display_timings */
static inline struct display_timing *display_timings_get(const struct
display_timings *disp,
--
1.7.10.4
^ permalink raw reply related
* [PATCHv2 5/5] videomode: videomode_from_timing work
From: Tomi Valkeinen @ 2013-03-27 6:58 UTC (permalink / raw)
To: Steffen Trumtrar, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <1364367505-4366-1-git-send-email-tomi.valkeinen@ti.com>
We currently have videomode_from_timing(), which takes one
display_timing entry from display_timings.
To make it easier to use display_timing without display_timings, this
patch renames videomode_from_timing() to videomode_from_timings(), and
adds a new videomode_from_timing() which just converts a given
display_timing to videomode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
drivers/video/of_videomode.c | 2 +-
drivers/video/videomode.c | 25 ++++++++++++++++---------
include/video/videomode.h | 15 +++++++++++++--
4 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 580b74e..90ee497 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -173,7 +173,7 @@ static int panel_connector_get_modes(struct drm_connector *connector)
struct drm_display_mode *mode = drm_mode_create(dev);
struct videomode vm;
- if (videomode_from_timing(timings, &vm, i))
+ if (videomode_from_timings(timings, &vm, i))
break;
drm_display_mode_from_videomode(&vm, mode);
diff --git a/drivers/video/of_videomode.c b/drivers/video/of_videomode.c
index 5b8066c..111c2d1 100644
--- a/drivers/video/of_videomode.c
+++ b/drivers/video/of_videomode.c
@@ -43,7 +43,7 @@ int of_get_videomode(struct device_node *np, struct videomode *vm,
if (index = OF_USE_NATIVE_MODE)
index = disp->native_mode;
- ret = videomode_from_timing(disp, vm, index);
+ ret = videomode_from_timings(disp, vm, index);
if (ret)
return ret;
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
index a3d95f2..df375c9 100644
--- a/drivers/video/videomode.c
+++ b/drivers/video/videomode.c
@@ -11,15 +11,9 @@
#include <video/display_timing.h>
#include <video/videomode.h>
-int videomode_from_timing(const struct display_timings *disp,
- struct videomode *vm, unsigned int index)
+void videomode_from_timing(const struct display_timing *dt,
+ struct videomode *vm)
{
- struct display_timing *dt;
-
- dt = display_timings_get(disp, index);
- if (!dt)
- return -EINVAL;
-
vm->pixelclock = dt->pixelclock.typ;
vm->hactive = dt->hactive.typ;
vm->hfront_porch = dt->hfront_porch.typ;
@@ -32,7 +26,20 @@ int videomode_from_timing(const struct display_timings *disp,
vm->vsync_len = dt->vsync_len.typ;
vm->flags = dt->flags;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
+
+int videomode_from_timings(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ videomode_from_timing(dt, vm);
return 0;
}
-EXPORT_SYMBOL_GPL(videomode_from_timing);
+EXPORT_SYMBOL_GPL(videomode_from_timings);
diff --git a/include/video/videomode.h b/include/video/videomode.h
index 8b12e60..3f1049d 100644
--- a/include/video/videomode.h
+++ b/include/video/videomode.h
@@ -34,14 +34,25 @@ struct videomode {
/**
* videomode_from_timing - convert display timing to videomode
+ * @dt: display_timing structure
+ * @vm: return value
+ *
+ * DESCRIPTION:
+ * This function converts a struct display_timing to a struct videomode.
+ */
+void videomode_from_timing(const struct display_timing *dt,
+ struct videomode *vm);
+
+/**
+ * videomode_from_timings - convert one display timings entry to videomode
* @disp: structure with all possible timing entries
* @vm: return value
* @index: index into the list of display timings in devicetree
*
* DESCRIPTION:
- * This function converts a struct display_timing to a struct videomode.
+ * This function converts one struct display_timing entry to a struct videomode.
*/
-int videomode_from_timing(const struct display_timings *disp,
+int videomode_from_timings(const struct display_timings *disp,
struct videomode *vm, unsigned int index);
#endif
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work
From: Tomi Valkeinen @ 2013-03-27 7:24 UTC (permalink / raw)
To: Archit Taneja; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <1364305525-28496-4-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]
On 2013-03-26 15:45, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel driver
> has these ops or not, and that leads to a crash.
>
> The following things are done to make fixed panels work:
>
> - The omap_connector's detect function is modified such that it considers panel
> types which are generally fixed panels as always connected(provided the panel
> driver doesn't have a detect op). Hence, the connector corresponding to these
> panels is always in a 'connected' state.
>
> - If a panel driver doesn't have a check_timings op, assume that it supports the
> mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
>
> - The function omap_encoder_update shouldn't really do anything for fixed
> resolution panels, make sure that it calls set_timings only if the panel
> driver has one.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> v3: clear the timings local variable first before using memcmp
> v2: make sure the timings we try to set for a fixed resolution panel match the
> panel's timings
>
> drivers/gpu/drm/omapdrm/omap_connector.c | 27 +++++++++++++++++++++++++--
> drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++++++++++++++--
> 2 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c
> index c451c41..912759d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
> ret = connector_status_connected;
> else
> ret = connector_status_disconnected;
> + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
> + ret = connector_status_connected;
> } else {
> ret = connector_status_unknown;
> }
Can we leave this part out? I don't like hardcoding things like that,
and if I'm not mistaken, this only affects VENC.
If the code above would use detect where available, and presume the
panel is connected in other cases, it'll be right for all other displays
but VENC, for which we have no connect information.
Or, there could be a special case for VENC, like above, which sets the
connector status to unknown for that. And connected for all others. It'd
still be hardcoded, but for much less cases.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers
From: Tomi Valkeinen @ 2013-03-27 7:30 UTC (permalink / raw)
To: Archit Taneja; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <1364305525-28496-6-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]
On 2013-03-26 15:45, Archit Taneja wrote:
> Each version of OMAP has a limitation on the maximum pixel clock frequency
> supported by an overlay manager. This limit isn't checked by omapdss. Add
> dispc feats for lcd and tv managers and check whether the target timings can
> be supported or not.
>
> The pixel clock limitations are actually more complex. They depend on which OPP
> OMAP is in, and they also depend on which encoder is the manager connected to.
> The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
> when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
> These limits should come from the encoder driver.
>
> The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
> as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 32 +++++++++++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 8cfa27b..73a730a 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -69,6 +69,8 @@ struct dispc_features {
> u8 mgr_height_start;
> u16 mgr_width_max;
> u16 mgr_height_max;
> + unsigned long max_lcd_pclk;
> + unsigned long max_tv_pclk;
> int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
> const struct omap_video_timings *mgr_timings,
> u16 width, u16 height, u16 out_width, u16 out_height,
> @@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
> return true;
> }
>
> +static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
> + unsigned long pclk)
> +{
> + if (dss_mgr_is_lcd(channel))
> + return pclk <= dispc.feat->max_lcd_pclk ? true : false;
> + else
> + return pclk <= dispc.feat->max_tv_pclk ? true : false;
> +}
> +
> bool dispc_mgr_timings_ok(enum omap_channel channel,
> const struct omap_video_timings *timings)
> {
> @@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
>
> timings_ok = _dispc_mgr_size_ok(timings->x_res, timings->y_res);
>
> - if (dss_mgr_is_lcd(channel))
> - timings_ok = timings_ok && _dispc_lcd_timings_ok(timings->hsw,
> - timings->hfp, timings->hbp,
> - timings->vsw, timings->vfp,
> - timings->vbp);
> + timings_ok &= _dispc_mgr_pclk_ok(channel, timings->pixel_clock * 1000);
> +
> + if (dss_mgr_is_lcd(channel)) {
> + timings_ok &= _dispc_lcd_timings_ok(timings->hsw, timings->hfp,
> + timings->hbp, timings->vsw, timings->vfp,
> + timings->vbp);
> + }
>
> return timings_ok;
> }
> @@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
> .mgr_height_start = 26,
> .mgr_width_max = 2048,
> .mgr_height_max = 2048,
> + .max_lcd_pclk = 66500000,
> .calc_scaling = dispc_ovl_calc_scaling_24xx,
> .calc_core_clk = calc_core_clk_24xx,
> .num_fifos = 3,
OMAP2 has VENC output, but there's no max_tv_pclk above. This would make
VENC pclk check to fail always, wouldn't it?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges
From: Tomi Valkeinen @ 2013-03-27 7:33 UTC (permalink / raw)
To: Archit Taneja; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <1364305525-28496-7-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
On 2013-03-26 15:45, Archit Taneja wrote:
> Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
> some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
> OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
> DSI PLL Fint range, this was previously just copied from the OMAP4 param range
> struct.
>
> Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dss_features.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
> index 7f791ae..77dbe0c 100644
> --- a/drivers/video/omap2/dss/dss_features.c
> +++ b/drivers/video/omap2/dss/dss_features.c
> @@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
> };
>
> static const struct dss_param_range omap2_dss_param_range[] = {
> - [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
> + [FEAT_PARAM_DSS_FCK] = { 0, 133000000 },
> [FEAT_PARAM_DSS_PCD] = { 2, 255 },
> [FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
> [FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
> @@ -459,15 +459,15 @@ static const struct dss_param_range omap4_dss_param_range[] = {
> };
>
> static const struct dss_param_range omap5_dss_param_range[] = {
> - [FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
> + [FEAT_PARAM_DSS_FCK] = { 0, 209250000 },
> [FEAT_PARAM_DSS_PCD] = { 1, 255 },
> [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
> [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
> [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
> [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
> - [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
> + [FEAT_PARAM_DSIPLL_FINT] = { 150000, 52000000 },
Just a note, I think the PLL FINT range for OMAP3/4 may be wrong also.
Some TRMs mention the FINT range being up to 52MHz or so. I don't think
it's ever very clearly stated, though...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work
From: Archit Taneja @ 2013-03-27 7:47 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <51529EC2.4040403@ti.com>
On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
>> and SDI drivers. At some places, there are no checks to see if the panel driver
>> has these ops or not, and that leads to a crash.
>>
>> The following things are done to make fixed panels work:
>>
>> - The omap_connector's detect function is modified such that it considers panel
>> types which are generally fixed panels as always connected(provided the panel
>> driver doesn't have a detect op). Hence, the connector corresponding to these
>> panels is always in a 'connected' state.
>>
>> - If a panel driver doesn't have a check_timings op, assume that it supports the
>> mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
>>
>> - The function omap_encoder_update shouldn't really do anything for fixed
>> resolution panels, make sure that it calls set_timings only if the panel
>> driver has one.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> v3: clear the timings local variable first before using memcmp
>> v2: make sure the timings we try to set for a fixed resolution panel match the
>> panel's timings
>>
>> drivers/gpu/drm/omapdrm/omap_connector.c | 27 +++++++++++++++++++++++++--
>> drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++++++++++++++--
>> 2 files changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c
>> index c451c41..912759d 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
>> ret = connector_status_connected;
>> else
>> ret = connector_status_disconnected;
>> + } else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
>> + ret = connector_status_connected;
>> } else {
>> ret = connector_status_unknown;
>> }
>
> Can we leave this part out? I don't like hardcoding things like that,
> and if I'm not mistaken, this only affects VENC.
>
> If the code above would use detect where available, and presume the
> panel is connected in other cases, it'll be right for all other displays
> but VENC, for which we have no connect information.
>
> Or, there could be a special case for VENC, like above, which sets the
> connector status to unknown for that. And connected for all others. It'd
> still be hardcoded, but for much less cases.
I guess we can leave the status for VENC as always connected too, if we
leave it as unknown by default and have no detect func for VENC, it
would never run with omapdrm.
Archit
^ permalink raw reply
* Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers
From: Archit Taneja @ 2013-03-27 7:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <5152A031.3080209@ti.com>
On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> Each version of OMAP has a limitation on the maximum pixel clock frequency
>> supported by an overlay manager. This limit isn't checked by omapdss. Add
>> dispc feats for lcd and tv managers and check whether the target timings can
>> be supported or not.
>>
>> The pixel clock limitations are actually more complex. They depend on which OPP
>> OMAP is in, and they also depend on which encoder is the manager connected to.
>> The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
>> when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
>> These limits should come from the encoder driver.
>>
>> The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
>> as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> drivers/video/omap2/dss/dispc.c | 32 +++++++++++++++++++++++++++-----
>> 1 file changed, 27 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
>> index 8cfa27b..73a730a 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -69,6 +69,8 @@ struct dispc_features {
>> u8 mgr_height_start;
>> u16 mgr_width_max;
>> u16 mgr_height_max;
>> + unsigned long max_lcd_pclk;
>> + unsigned long max_tv_pclk;
>> int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
>> const struct omap_video_timings *mgr_timings,
>> u16 width, u16 height, u16 out_width, u16 out_height,
>> @@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
>> return true;
>> }
>>
>> +static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
>> + unsigned long pclk)
>> +{
>> + if (dss_mgr_is_lcd(channel))
>> + return pclk <= dispc.feat->max_lcd_pclk ? true : false;
>> + else
>> + return pclk <= dispc.feat->max_tv_pclk ? true : false;
>> +}
>> +
>> bool dispc_mgr_timings_ok(enum omap_channel channel,
>> const struct omap_video_timings *timings)
>> {
>> @@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
>>
>> timings_ok = _dispc_mgr_size_ok(timings->x_res, timings->y_res);
>>
>> - if (dss_mgr_is_lcd(channel))
>> - timings_ok = timings_ok && _dispc_lcd_timings_ok(timings->hsw,
>> - timings->hfp, timings->hbp,
>> - timings->vsw, timings->vfp,
>> - timings->vbp);
>> + timings_ok &= _dispc_mgr_pclk_ok(channel, timings->pixel_clock * 1000);
>> +
>> + if (dss_mgr_is_lcd(channel)) {
>> + timings_ok &= _dispc_lcd_timings_ok(timings->hsw, timings->hfp,
>> + timings->hbp, timings->vsw, timings->vfp,
>> + timings->vbp);
>> + }
>>
>> return timings_ok;
>> }
>> @@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
>> .mgr_height_start = 26,
>> .mgr_width_max = 2048,
>> .mgr_height_max = 2048,
>> + .max_lcd_pclk = 66500000,
>> .calc_scaling = dispc_ovl_calc_scaling_24xx,
>> .calc_core_clk = calc_core_clk_24xx,
>> .num_fifos = 3,
>
> OMAP2 has VENC output, but there's no max_tv_pclk above. This would make
> VENC pclk check to fail always, wouldn't it?
oops, I missed adding it for omap2, will fix it.
Archit
^ permalink raw reply
* Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges
From: Archit Taneja @ 2013-03-27 7:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <5152A0E6.3010300@ti.com>
On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
>> some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
>> OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
>> DSI PLL Fint range, this was previously just copied from the OMAP4 param range
>> struct.
>>
>> Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> drivers/video/omap2/dss/dss_features.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
>> index 7f791ae..77dbe0c 100644
>> --- a/drivers/video/omap2/dss/dss_features.c
>> +++ b/drivers/video/omap2/dss/dss_features.c
>> @@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
>> };
>>
>> static const struct dss_param_range omap2_dss_param_range[] = {
>> - [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
>> + [FEAT_PARAM_DSS_FCK] = { 0, 133000000 },
>> [FEAT_PARAM_DSS_PCD] = { 2, 255 },
>> [FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
>> [FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
>> @@ -459,15 +459,15 @@ static const struct dss_param_range omap4_dss_param_range[] = {
>> };
>>
>> static const struct dss_param_range omap5_dss_param_range[] = {
>> - [FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
>> + [FEAT_PARAM_DSS_FCK] = { 0, 209250000 },
>> [FEAT_PARAM_DSS_PCD] = { 1, 255 },
>> [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
>> [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
>> [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
>> [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
>> - [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
>> + [FEAT_PARAM_DSIPLL_FINT] = { 150000, 52000000 },
>
> Just a note, I think the PLL FINT range for OMAP3/4 may be wrong also.
> Some TRMs mention the FINT range being up to 52MHz or so. I don't think
> it's ever very clearly stated, though...
I'll drop the FINT range modification for now. It's not that critical
anyway since we manage to lock the PLL for most frequencies anyway. I'll
do an update later after reading more detailed specs of the PLL.
Archit
^ permalink raw reply
* Re: [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements
From: Tomi Valkeinen @ 2013-03-27 7:54 UTC (permalink / raw)
To: Archit Taneja; +Cc: robdclark, andy.gross, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <1364305525-28496-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]
On 2013-03-26 15:45, Archit Taneja wrote:
> These are misc fixes and improvements within omapdrm and omapdss. The fixes do the
> following:
>
> - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
> makes sure that omapdrm is functional for OMAP platforms with different
> combinations of panels connected to it.
>
> - Fix certain areas in omapdrm which allow fixed resolution panels to work.
>
> - Fix functional and pixel clock limits for DISPC, this ensures we don't try
> to try a mode that the hardware can't support.
>
> - Some changes that came in OMAP5 ES2 silicon.
>
> Note: The branch is based on the DSS misc series and dsi video mode calc series
> posted by Tomi. Reference branch:
>
> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.10/misc_drm_dss
Which of the fixes should go for 3.9? We need those separately, based on
the mainline.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [RFC 00/14] Add DT support to OMAPDSS
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.
The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.
Some notes:
* DSS Submodules
The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.
* ti,dsi-module-id
There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.
* Display chains
Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts.
So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.
You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.
* DSI lanes
The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.
Tomi
Tomi Valkeinen (14):
ARM: OMAP: remove DSS DT hack
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: Add DT support to DSS, DISPC, DPI
OMAPDSS: Add DT support to DSI
OMAPDSS: Add DT support to HDMI
OMAPDSS: Taal: Add DT support
OMAPDSS: TFP410: Add DT support
OMAPDSS: panel-generic-dpi: add DT support
ARM: omap3.dtsi: add omapdss information
ARM: omap4.dtsi: add omapdss information
ARM: omap4-panda.dts: add display information
ARM: omap4-sdp.dts: add display information
ARM: omap3-tobi.dts: add lcd (TEST)
ARM: omap3-beagle.dts: add TFP410
arch/arm/boot/dts/omap3-beagle.dts | 20 +++++
arch/arm/boot/dts/omap3-tobi.dts | 13 ++++
arch/arm/boot/dts/omap3.dtsi | 49 ++++++++++++
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 71 +++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 9 +--
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 34 +++++++++
arch/arm/mach-omap2/dss-common.c | 24 ------
arch/arm/mach-omap2/dss-common.h | 2 -
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++++++++++++
drivers/video/omap2/displays/panel-taal.c | 89 ++++++++++++++++++++++
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++
drivers/video/omap2/dss/dispc.c | 7 ++
drivers/video/omap2/dss/dpi.c | 8 ++
drivers/video/omap2/dss/dsi.c | 24 +++++-
drivers/video/omap2/dss/dss.c | 7 ++
drivers/video/omap2/dss/hdmi.c | 7 ++
drivers/video/omap2/dss/hdmi_panel.c | 86 ++++++++++++++++++++-
20 files changed, 641 insertions(+), 37 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [RFC 01/14] ARM: OMAP: remove DSS DT hack
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda & sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 8 --------
arch/arm/mach-omap2/dss-common.c | 24 ------------------------
arch/arm/mach-omap2/dss-common.h | 2 --
3 files changed, 34 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index e54a480..a61544b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,14 +41,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- /*
- * HACK: call display setup code for selected boards to enable omapdss.
- * This will be removed when omapdss supports DT.
- */
- if (of_machine_is_compatible("ti,omap4-panda"))
- omap4_panda_display_init_of();
- else if (of_machine_is_compatible("ti,omap4-sdp"))
- omap_4430sdp_display_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index a10c56b..78e409a 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -93,13 +93,6 @@ void __init omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(&omap4_panda_dss_data);
- platform_device_register(&omap4_panda_tfp410_device);
- platform_device_register(&omap4_panda_hdmi_device);
-}
-
/* OMAP4 Blaze display data */
@@ -242,20 +235,3 @@ void __init omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- /* Enable LCD2 by default (instead of Pico DLP) */
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- sdp4430_picodlp_init();
- omap_display_init(&sdp4430_dss_data);
- platform_device_register(&sdp4430_hdmi_device);
- platform_device_register(&sdp4430_lcd1_device);
- platform_device_register(&sdp4430_lcd2_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..611b341 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -7,8 +7,6 @@
*/
void __init omap4_panda_display_init(void);
-void __init omap4_panda_display_init_of(void);
void __init omap_4430sdp_display_init(void);
-void __init omap_4430sdp_display_init_of(void);
#endif
--
1.7.10.4
^ permalink raw reply related
* [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..e9ac1fd 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,5 +293,7 @@ extern void omap_reserve(void);
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include "omap_hwmod.h"
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver = OMAPDSS_VER_UNKNOWN) {
+ pr_err("DSS not supported on this SoC\n");
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = &board_data;
+
+ r = platform_device_register(&omap_display_device);
+ if (r < 0) {
+ pr_err("Unable to register omapdss device\n");
+ return r;
+ }
+
+ return 0;
+}
--
1.7.10.4
^ permalink raw reply related
* [RFC 03/14] OMAPDSS: Add DT support to DSS, DISPC, DPI
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Add the code to make DSS, DISPC and DPI drivers work with device tree on
OMAP3 and OMAP4. The only change is adding the of_match_tables.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 7 +++++++
drivers/video/omap2/dss/dpi.c | 8 ++++++++
drivers/video/omap2/dss/dss.c | 7 +++++++
3 files changed, 22 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..be53d64 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3705,12 +3705,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = "ti,omap3-dispc", },
+ { .compatible = "ti,omap4-dispc", },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = "omapdss_dispc",
.owner = THIS_MODULE,
.pm = &dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e7beea2..dc7e324 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/string.h>
+#include <linux/of.h>
#include <video/omapdss.h>
@@ -765,11 +766,18 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dpi_of_match[] = {
+ { .compatible = "ti,omap3-dpi", },
+ { .compatible = "ti,omap4-dpi", },
+ {},
+};
+
static struct platform_driver omap_dpi_driver = {
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = "omapdss_dpi",
.owner = THIS_MODULE,
+ .of_match_table = dpi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 62db201..dc721f4 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -962,12 +962,19 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
};
+static const struct of_device_id dss_of_match[] = {
+ { .compatible = "ti,omap3-dss", },
+ { .compatible = "ti,omap4-dss", },
+ {},
+};
+
static struct platform_driver omap_dsshw_driver = {
.remove = __exit_p(omap_dsshw_remove),
.driver = {
.name = "omapdss_dss",
.owner = THIS_MODULE,
.pm = &dss_pm_ops,
+ .of_match_table = dss_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 04/14] OMAPDSS: Add DT support to DSI
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4. The of_match_table is added, and also a bit hacky
"ti,dsi-module-id" DT property, which tells the DSI ID number.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index fb77aa8..1058cab 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,7 @@
#include <linux/slab.h>
#include <linux/debugfs.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include <video/mipi_display.h>
@@ -5541,7 +5542,20 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
if (!dsi)
return -ENOMEM;
- dsi->module_id = dsidev->id;
+ if (dsidev->dev.of_node) {
+ u32 id;
+ r = of_property_read_u32(dsidev->dev.of_node,
+ "ti,dsi-module-id", &id);
+ if (r) {
+ DSSERR("failed to read DSI module ID\n");
+ return r;
+ }
+
+ dsi->module_id = id;
+ } else {
+ dsi->module_id = dsidev->id;
+ }
+
dsi->pdev = dsidev;
dev_set_drvdata(&dsidev->dev, dsi);
@@ -5642,6 +5656,7 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
else if (dsi->module_id = 1)
dss_debugfs_create_file("dsi2_irqs", dsi2_dump_irqs);
#endif
+
return 0;
err_runtime_get:
@@ -5700,12 +5715,19 @@ static const struct dev_pm_ops dsi_pm_ops = {
.runtime_resume = dsi_runtime_resume,
};
+static const struct of_device_id dsi_of_match[] = {
+ { .compatible = "ti,omap3-dsi", },
+ { .compatible = "ti,omap4-dsi", },
+ {},
+};
+
static struct platform_driver omap_dsihw_driver = {
.remove = __exit_p(omap_dsihw_remove),
.driver = {
.name = "omapdss_dsi",
.owner = THIS_MODULE,
.pm = &dsi_pm_ops,
+ .of_match_table = dsi_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 05/14] OMAPDSS: Add DT support to HDMI
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Add the code to make the HDMI driver work with device tree.
The OMAP SoC HDMI (hdmi.c) change is simple, just add of_match_table.
The hdmi_panel.c is a bit more complex. We model both the TPD12S015 chip
and the HDMI connector, and handle both in the same driver. In the
future those should be separate drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 7 +++
drivers/video/omap2/dss/hdmi_panel.c | 86 +++++++++++++++++++++++++++++++++-
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f9e38c4..e7a18d3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -34,6 +34,7 @@
#include <linux/clk.h>
#include <linux/gpio.h>
#include <linux/regulator/consumer.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include "ti_hdmi.h"
@@ -1202,12 +1203,18 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = "ti,omap4-hdmi", },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.remove = __exit_p(omapdss_hdmihw_remove),
.driver = {
.name = "omapdss_hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/hdmi_panel.c b/drivers/video/omap2/dss/hdmi_panel.c
index bc4dea3..8dffd5d 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -27,12 +27,16 @@
#include <video/omapdss.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include "dss.h"
static struct {
struct omap_dss_device dssdev;
+ struct omap_dss_hdmi_data pdata;
+
/* This protects the panel ops, mainly when accessing the HDMI IP. */
struct mutex lock;
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -43,6 +47,62 @@ static struct {
static struct omap_dss_driver hdmi_driver;
+static int hdmi_panel_probe_pdata(struct platform_device *pdev)
+{
+ const struct omap_dss_hdmi_data *pdata = dev_get_platdata(&pdev->dev);
+
+ hdmi.pdata = *pdata;
+
+ return 0;
+}
+
+static int hdmi_parse_tpd12s015_of(struct device_node *node,
+ struct omap_dss_hdmi_data *pdata)
+{
+ int gpio;
+
+ gpio = of_get_gpio(node, 0); /* CT CP HPD */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata->ct_cp_hpd_gpio = gpio;
+
+ gpio = of_get_gpio(node, 1); /* LS OE */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata->ls_oe_gpio = gpio;
+
+ gpio = of_get_gpio(node, 2); /* HPD */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata->hpd_gpio = gpio;
+
+ return 0;
+}
+
+static int hdmi_panel_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *src_node;
+ int r;
+
+ /*
+ * We don't have a real driver for the TPD12S015 chip, but it is
+ * modeled right in the DT data. So we need to parse the TPD12S015 data
+ * here.
+ */
+ src_node = of_parse_phandle(node, "video-source", 0);
+ if (!src_node) {
+ dev_err(&pdev->dev, "failed to parse video source\n");
+ return -ENODEV;
+ }
+
+ r = hdmi_parse_tpd12s015_of(src_node, &hdmi.pdata);
+ if (r)
+ return r;
+
+ return 0;
+}
+
static int hdmi_panel_probe(struct platform_device *pdev)
{
/* Initialize default timings to VGA in DVI mode */
@@ -63,12 +123,28 @@ static int hdmi_panel_probe(struct platform_device *pdev)
.interlace = false,
};
- struct omap_dss_hdmi_data *pdata = dev_get_platdata(&pdev->dev);
struct omap_dss_device *dssdev = &hdmi.dssdev;
int r;
DSSDBG("ENTER hdmi_panel_probe\n");
+ if (dev_get_platdata(&pdev->dev)) {
+ r = hdmi_panel_probe_pdata(pdev);
+ if (r) {
+ dev_err(&pdev->dev, "failed to read platform data\n");
+ return r;
+ }
+ } else if (pdev->dev.of_node) {
+ r = hdmi_panel_probe_of(pdev);
+ if (r) {
+ dev_err(&pdev->dev, "failed to parse OF data\n");
+ return r;
+ }
+ } else {
+ return -ENODEV;
+ }
+
+
dssdev->panel.timings = default_timings;
dssdev->driver = &hdmi_driver;
dssdev->name = "hdmi";
@@ -78,7 +154,7 @@ static int hdmi_panel_probe(struct platform_device *pdev)
* XXX for now, the hdmi panel's platform data contains the gpios for
* the tpd level shifter chip, so we pass this data to the hdmi driver.
*/
- dssdev->data = pdata;
+ dssdev->data = &hdmi.pdata;
DSSDBG("hdmi_panel_probe x_res= %d y_res = %d\n",
dssdev->panel.timings.x_res,
@@ -415,12 +491,18 @@ static struct omap_dss_driver hdmi_driver = {
.audio_config = hdmi_panel_audio_config,
};
+static const struct of_device_id hdmi_panel_of_match[] = {
+ { .compatible = "ti,hdmi_connector", },
+ {},
+};
+
static struct platform_driver hdmi_panel_platform_driver = {
.probe = hdmi_panel_probe,
.remove = hdmi_panel_remove,
.driver = {
.name = "hdmi_panel",
.owner = THIS_MODULE,
+ .of_match_table = hdmi_panel_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 06/14] OMAPDSS: Taal: Add DT support
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Add DT support to Taal panel driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/panel-taal.c | 89 +++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index 01de2a9..f8771da 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -32,6 +32,8 @@
#include <linux/slab.h>
#include <linux/mutex.h>
#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-nokia-dsi.h>
@@ -788,6 +790,81 @@ static int taal_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int taal_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct taal_data *td = dev_get_drvdata(&pdev->dev);
+ struct property *prop;
+ struct device_node *src_node;
+ u32 lane_arr[10];
+ int gpio, len, num_pins;
+ int r, i;
+
+ src_node = of_parse_phandle(node, "video-source", 0);
+ if (!src_node) {
+ dev_err(&pdev->dev, "failed to parse video source\n");
+ return -ENODEV;
+ }
+
+ td->src = omap_dss_find_output_by_node(src_node);
+ if (!td->src) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return -ENODEV;
+ }
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio)) {
+ td->reset_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse reset gpio\n");
+ return gpio;
+ }
+
+ if (of_gpio_count(node) > 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio)) {
+ td->ext_te_gpio = gpio;
+ } else if (gpio = -ENOENT) {
+ td->ext_te_gpio = -1;
+ } else {
+ dev_err(&pdev->dev, "failed to parse TE gpio\n");
+ return gpio;
+ }
+ } else {
+ td->ext_te_gpio = -1;
+ }
+
+ prop = of_find_property(node, "lanes", &len);
+ if (prop = NULL) {
+ dev_err(&pdev->dev, "failed to find lane data\n");
+ return -EINVAL;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins < 4 || num_pins % 2 != 0
+ || num_pins > ARRAY_SIZE(lane_arr)) {
+ dev_err(&pdev->dev, "bad number of lanes\n");
+ return -EINVAL;
+ }
+
+ r = of_property_read_u32_array(node, "lanes", lane_arr, num_pins);
+ if (r) {
+ dev_err(&pdev->dev, "failed to read lane data\n");
+ return r;
+ }
+
+ td->pin_config.num_pins = num_pins;
+ for (i = 0; i < num_pins; ++i)
+ td->pin_config.pins[i] = (int)lane_arr[i];
+
+ td->dssdev.name = node->name;
+
+ return 0;
+}
+
static int taal_probe(struct platform_device *pdev)
{
const struct nokia_dsi_panel_data *pdata = dev_get_platdata(&pdev->dev);
@@ -813,6 +890,12 @@ static int taal_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to read platform data\n");
return r;
}
+ } else if (pdev->dev.of_node) {
+ r = taal_probe_of(pdev);
+ if (r) {
+ dev_err(&pdev->dev, "failed to parse OF data\n");
+ return r;
+ }
} else {
return -ENODEV;
}
@@ -1576,12 +1659,18 @@ static struct omap_dss_driver taal_driver = {
.memory_read = taal_memory_read,
};
+static const struct of_device_id taal_of_match[] = {
+ { .compatible = "tpo,taal", },
+ {},
+};
+
static struct platform_driver taal_platform_driver = {
.probe = taal_probe,
.remove = __exit_p(taal_remove),
.driver = {
.name = "taal",
.owner = THIS_MODULE,
+ .of_match_table = taal_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 07/14] OMAPDSS: TFP410: Add DT support
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
In the DT data we model the TFP410 chip and the DVI connector. For the
moment we have only 1 driver to handle those both.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index a225ea1..a087489c 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -24,6 +24,8 @@
#include <linux/gpio.h>
#include <linux/platform_device.h>
#include <drm/drm_edid.h>
+#include <linux/of_gpio.h>
+#include <linux/of_i2c.h>
#include <video/omap-panel-tfp410.h>
@@ -112,6 +114,63 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(&pdev->dev);
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+ int r, gpio, datalines;
+
+ ddata->name = node->name;
+
+ node = of_parse_phandle(node, "video-source", 0);
+ if (!node) {
+ dev_err(&pdev->dev, "failed to parse video source\n");
+ return -ENODEV;
+ }
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio)) {
+ r = devm_gpio_request_one(&pdev->dev, gpio,
+ GPIOF_OUT_INIT_LOW, "tfp410 pd");
+ if (r) {
+ dev_err(&pdev->dev, "Failed to request PD GPIO %d\n",
+ gpio);
+ return r;
+ }
+
+ ddata->pd_gpio = gpio;
+ } else if (gpio = -ENOENT) {
+ ddata->pd_gpio = -1;
+ } else {
+ dev_err(&pdev->dev, "failed to parse PD gpio\n");
+ return gpio;
+ }
+
+ r = of_property_read_u32(node, "data-lines", &datalines);
+ if (r) {
+ dev_err(&pdev->dev, "failed to parse datalines");
+ return r;
+ }
+
+ ddata->data_lines = datalines;
+
+ adapter_node = of_parse_phandle(node, "i2c-bus", 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter = NULL) {
+ dev_err(&pdev->dev, "failed to parse i2c-bus\n");
+ return -EINVAL;
+ }
+
+ ddata->i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
@@ -131,6 +190,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -380,12 +443,20 @@ static struct omap_dss_driver tfp410_driver = {
.detect = tfp410_detect,
};
+static const struct of_device_id tfp410_of_match[] = {
+ {
+ .compatible = "ti,dvi_connector",
+ },
+ {},
+};
+
static struct platform_driver tfp410_platform_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = "tfp410",
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 08/14] OMAPDSS: panel-generic-dpi: add DT support
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Tomi Valkeinen, Santosh Shilimkar, Archit Taneja, Andy Gross
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index cc49c48..a00c942 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include <video/omap-panel-generic-dpi.h>
@@ -618,6 +619,42 @@ static int generic_dpi_panel_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int generic_dpi_panel_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct panel_drv_data *drv_data = dev_get_drvdata(&pdev->dev);
+ struct panel_config *panel_config = NULL;
+ int r, i;
+ int datalines;
+ const char *panel_name;
+
+ r = of_property_read_string(node, "panel-name", &panel_name);
+ if (r)
+ return r;
+
+ for (i = 0; i < ARRAY_SIZE(generic_dpi_panels); i++) {
+ if (strcmp(panel_name, generic_dpi_panels[i].name) = 0) {
+ panel_config = &generic_dpi_panels[i];
+ break;
+ }
+ }
+
+ if (!panel_config)
+ return -EINVAL;
+
+ r = of_property_read_u32(node, "data-lines", &datalines);
+ if (r) {
+ dev_err(&pdev->dev, "failed to parse datalines");
+ return r;
+ }
+
+ drv_data->panel_config = panel_config;
+ drv_data->name = node->name;
+ drv_data->data_lines = datalines;
+
+ return 0;
+}
+
static int generic_dpi_panel_probe(struct platform_device *pdev)
{
struct panel_drv_data *drv_data;
@@ -636,6 +673,10 @@ static int generic_dpi_panel_probe(struct platform_device *pdev)
r = generic_dpi_panel_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = generic_dpi_panel_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -EINVAL;
}
@@ -754,12 +795,18 @@ static struct omap_dss_driver generic_dpi_panel_driver = {
.get_resolution = omapdss_default_get_resolution,
};
+static const struct of_device_id generic_dpi_panel_of_match[] = {
+ { .compatible = "ti,dpi_panel", },
+ {},
+};
+
static struct platform_driver generic_dpi_panel_platform_driver = {
.probe = generic_dpi_panel_probe,
.remove = __exit_p(generic_dpi_panel_remove),
.driver = {
.name = "generic_dpi_panel",
.owner = THIS_MODULE,
+ .of_match_table = generic_dpi_panel_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 09/14] ARM: omap3.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Tomi Valkeinen, Santosh Shilimkar, Archit Taneja, Andy Gross
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 49 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..49de390 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,54 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ dss@48050000 {
+ compatible = "ti,omap3-dss", "simple-bus";
+ reg = <0x48050000 0x200>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@48050400 {
+ compatible = "ti,omap3-dispc";
+ reg = <0x48050400 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: dpi {
+ compatible = "ti,omap3-dpi";
+ };
+
+ sdi: sdi {
+ compatible = "ti,omap3-sdi";
+ };
+
+ dsi: dsi@4804fc00 {
+ compatible = "ti,omap3-dsi";
+ reg = <0x4804fc00 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dsi1";
+
+ /*
+ * XXX dss_core needs to know module-id,
+ * so this data should be there.
+ */
+ ti,dsi-module-id = <0>;
+ };
+
+ rfbi: rfbi@48050800 {
+ compatible = "ti,omap3-rfbi";
+ reg = <0x48050800 0x100>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ venc: venc@48050c00 {
+ compatible = "ti,omap3-venc";
+ reg = <0x48050c00 0x100>;
+ ti,hwmods = "dss_venc";
+ };
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 10/14] ARM: omap4.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Tomi Valkeinen, Santosh Shilimkar, Archit Taneja, Andy Gross
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 71 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..967f706 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,76 @@
ti,hwmods = "timer11";
ti,timer-pwm;
};
+
+ dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <0 25 0x4>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: dpi {
+ compatible = "ti,omap4-dpi";
+ };
+
+ rfbi: rfbi@58002000 {
+ compatible = "ti,omap4-rfbi";
+ reg = <0x58002000 0x1000>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ /*
+ * Accessing venc registers cause a crash on omap4, so
+ * this is disabled for now.
+ */
+ /*
+ venc: venc@58003000 {
+ compatible = "ti,omap4-venc";
+ reg = <0x58003000 0x1000>;
+ ti,hwmods = "dss_venc";
+ };
+ */
+
+ dsi1: dsi@58004000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58004000 0x200>;
+ interrupts = <0 53 0x4>;
+ ti,hwmods = "dss_dsi1";
+
+ /*
+ * XXX dss_core needs to know module-id,
+ * so this data should be there.
+ */
+ ti,dsi-module-id = <0>;
+ };
+
+ dsi2: dsi@58005000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58005000 0x200>;
+ interrupts = <0 84 0x4>;
+ ti,hwmods = "dss_dsi2";
+
+ /*
+ * XXX dss_core needs to know module-id,
+ * so this data should be there.
+ */
+ ti,dsi-module-id = <1>;
+ };
+
+ hdmi: hdmi@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x1000>;
+ interrupts = <0 101 0x4>;
+ ti,hwmods = "dss_hdmi";
+ };
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [RFC 11/14] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..45dd40a 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,47 @@
&twl_usb_comparator {
usb-supply = <&vusb>;
};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+ tfp410: tfp410 {
+ compatible = "ti,tfp410";
+ video-source = <&dpi>;
+ data-lines = <24>;
+ gpios = <&gpio1 0 0>; /* 0, power-down */
+ i2c-bus = <&i2c3>;
+ };
+
+ dvi {
+ compatible = "ti,dvi_connector";
+
+ video-source = <&tfp410>;
+ };
+
+ tpd12s015: tpd12s015 {
+ compatible = "ti,tpd12s015";
+
+ video-source = <&hdmi>;
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+ };
+
+ hdmi {
+ compatible = "ti,hdmi_connector";
+
+ video-source = <&tpd12s015>;
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [RFC 12/14] ARM: omap4-sdp.dts: add display information
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree-discuss, linux-arm-kernel
Cc: Archit Taneja, Andy Gross, Tony Lindgren, Benoit Cousson,
Santosh Shilimkar, Tomi Valkeinen
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 64 +++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..3bef36e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,67 @@
&twl_usb_comparator {
usb-supply = <&vusb>;
};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+ lcd {
+ compatible = "tpo,taal";
+
+ video-source = <&dsi1>;
+
+ lanes = <
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ >;
+
+ gpios = <&gpio4 6 0>; /* 102, reset */
+ };
+
+ lcd2 {
+ compatible = "tpo,taal";
+
+ video-source = <&dsi2>;
+
+ lanes = <
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ >;
+
+ gpios = <&gpio4 8 0>; /* 104, reset */
+ };
+
+ tpd12s015: tpd12s015 {
+ compatible = "ti,tpd12s015";
+
+ video-source = <&hdmi>;
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+ };
+
+ hdmi {
+ compatible = "ti,hdmi_connector";
+
+ video-source = <&tpd12s015>;
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [RFC 13/14] ARM: omap3-tobi.dts: add lcd (TEST)
From: Tomi Valkeinen @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Tomi Valkeinen, Santosh Shilimkar, Archit Taneja, Andy Gross
In-Reply-To: <1364373921-7599-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-tobi.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index a13d12d..68e3c1b 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -33,3 +33,16 @@
&mmc3 {
status = "disabled";
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+};
+
+/ {
+ lcd43 {
+ compatible = "ti,dpi_panel";
+ video-source = <&dpi>;
+ data-lines = <24>;
+ panel-name = "samsung_lte430wq_f0c";
+ };
+};
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox