* [PATCH v2 7/8] OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers
From: Archit Taneja @ 2013-03-26 13:57 UTC (permalink / raw)
To: tomi.valkeinen, robdclark, andy.gross
Cc: linux-omap, linux-fbdev, dri-devel, Archit Taneja
In-Reply-To: <1364305525-28496-1-git-send-email-archit@ti.com>
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
calculate the row increment needed for the UV plane by using double the stride
value based on whether this bit is set or not.
Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
the bit shouldn't be set.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 73a730a..ddbf031 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1588,6 +1588,7 @@ static void dispc_ovl_set_scaling(enum omap_plane plane,
}
static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation,
+ enum omap_dss_rotation_type rotation_type,
bool mirroring, enum omap_color_mode color_mode)
{
bool row_repeat = false;
@@ -1638,6 +1639,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation,
if (dss_has_feature(FEAT_ROWREPEATENABLE))
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
row_repeat ? 1 : 0, 18, 18);
+
+ if (color_mode = OMAP_DSS_COLOR_NV12) {
+ bool doublestride = (rotation_type = OMAP_DSS_ROT_TILER) &&
+ (rotation = OMAP_DSS_ROT_0 ||
+ rotation = OMAP_DSS_ROT_180);
+ /* DOUBLESTRIDE */
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), doublestride, 22, 22);
+ }
+
}
static int color_mode_to_bpp(enum omap_color_mode color_mode)
@@ -2516,7 +2526,8 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
dispc_ovl_set_vid_color_conv(plane, cconv);
}
- dispc_ovl_set_rotation_attrs(plane, rotation, mirror, color_mode);
+ dispc_ovl_set_rotation_attrs(plane, rotation, rotation_type, mirror,
+ color_mode);
dispc_ovl_set_zorder(plane, caps, zorder);
dispc_ovl_set_pre_mult_alpha(plane, caps, pre_mult_alpha);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 8/8] OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5
From: Archit Taneja @ 2013-03-26 13:57 UTC (permalink / raw)
To: tomi.valkeinen, robdclark, andy.gross
Cc: linux-omap, linux-fbdev, dri-devel, Archit Taneja
In-Reply-To: <1364305525-28496-1-git-send-email-archit@ti.com>
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.
There is a register field which can let us revert to the older mechanism of
asserting Mstandby. Configure this field to prevent underflows.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 7 +++++++
drivers/video/omap2/dss/dispc.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ddbf031..b33b016 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -87,6 +87,9 @@ struct dispc_features {
/* no DISPC_IRQ_FRAMEDONETV on this SoC */
bool no_framedone_tv:1;
+
+ /* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
+ bool mstandby_workaround:1;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -3502,6 +3505,9 @@ static void _omap_dispc_initial_config(void)
dispc_configure_burst_sizes();
dispc_ovl_enable_zorder_planes();
+
+ if (dispc.feat->mstandby_workaround)
+ REG_FLD_MOD(DISPC_MSTANDBY_CTRL, 1, 0, 0);
}
static const struct dispc_features omap24xx_dispc_feats __initconst = {
@@ -3596,6 +3602,7 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
.gfx_fifo_workaround = true,
+ .mstandby_workaround = true,
};
static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 222363c..de4863d 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -39,6 +39,7 @@
#define DISPC_GLOBAL_BUFFER 0x0800
#define DISPC_CONTROL3 0x0848
#define DISPC_CONFIG3 0x084C
+#define DISPC_MSTANDBY_CTRL 0x0858
/* DISPC overlay registers */
#define DISPC_OVL_BA0(n) (DISPC_OVL_BASE(n) + \
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 00/26] DSS device model change
From: Tony Lindgren @ 2013-03-26 17:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1364304836-18134-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130326 06:38]:
> Hi,
>
> To make it possible to add DT support to DSS, and later use the Common Display
> Framework, we need to change the DSS device model. We currently have a custom
> dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that
> bus.
>
> The panel devices will be converted occording to the control bus of the panel.
> For many panels this means that the panel device will become a platform_device.
> For some, it means the panel devices become i2c or spi devices.
>
> This series takes the first step toward that goal. This series:
>
> * Converts DPI, HDMI and DSI outputs to work with new style panels
> * Converts TFP410, Taal and generic-dpi panels to new model
> * Converts Panda, 4430SDP and Overo boards to use the new panels
>
> The non-converted outputs and panels still work, so they can be converted in
> stages.
This is nice, it removes a merge dependency between ARM code and the driver :)
> Note about board files: I only convert a few board files here for example. I
> have a branch with board file changes for all the affected board files. I did
> not include them as they are more or less identical. If this series looks good,
> I will create an independent branch for the arch/arm stuff, so it can be pulled
> separately.
Great looks good to me thanks.
Tony
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Kuninori Morimoto @ 2013-03-26 23:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
Hi Simon
> > > > > On Monday 04 March 2013 21:07:10 Kuninori Morimoto wrote:
> > > > > > The lcdc B side horizon output is shifted
> > > > > > if sh_mobile_lcdc_pan() was called.
> > > > > > This patch fixup this issue.
> > > > > > It is tested on R8A7740 Armadillo800eva HDMI output.
> > > > > > Special thanks to Fukushima-san, and Sano-san
> > > > > >
> > > > > > Reported-by: Osamu Fukushima <osamu.fukushima.wr@renesas.com>
> > > > > > Signed-off-by: Hideyuki Sano <hideyuki.sano.dn@renesas.com>
> > > > > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > > > >
> > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > >
> > > > Laurent, can you handle getting this merged?
> > > > If not, please let me know who to prod.
> > >
> > > We have no fbdev maintainer anymore. Can this be pushed through your tree ?
> >
> > Could you please teach me current status of this patch ?
>
> Sorry, I have been a bit slow and haven't applied it yet.
> I plan to do so shortly.
Thank you for your help!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Simon Horman @ 2013-03-27 6:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
On Tue, Mar 26, 2013 at 04:56:09PM -0700, Kuninori Morimoto wrote:
>
> Hi Simon
>
> > > > > > On Monday 04 March 2013 21:07:10 Kuninori Morimoto wrote:
> > > > > > > The lcdc B side horizon output is shifted
> > > > > > > if sh_mobile_lcdc_pan() was called.
> > > > > > > This patch fixup this issue.
> > > > > > > It is tested on R8A7740 Armadillo800eva HDMI output.
> > > > > > > Special thanks to Fukushima-san, and Sano-san
> > > > > > >
> > > > > > > Reported-by: Osamu Fukushima <osamu.fukushima.wr@renesas.com>
> > > > > > > Signed-off-by: Hideyuki Sano <hideyuki.sano.dn@renesas.com>
> > > > > > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > > > > >
> > > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > >
> > > > > Laurent, can you handle getting this merged?
> > > > > If not, please let me know who to prod.
> > > >
> > > > We have no fbdev maintainer anymore. Can this be pushed through your tree ?
> > >
> > > Could you please teach me current status of this patch ?
> >
> > Sorry, I have been a bit slow and haven't applied it yet.
> > I plan to do so shortly.
>
> Thank you for your help!
Can I confirm if this is for v3.9 or v3.10.
If it is for v3.9 perhaps it is also suitable for -stable?
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Kuninori Morimoto @ 2013-03-27 6:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
Hi Simon
> > > Sorry, I have been a bit slow and haven't applied it yet.
> > > I plan to do so shortly.
> >
> > Thank you for your help!
>
> Can I confirm if this is for v3.9 or v3.10.
> If it is for v3.9 perhaps it is also suitable for -stable?
Yes, it needs in v3.9.
I'm not sure detail of -stable branch,
but it is very nice if it have this patch
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 00/26] DSS device model change
From: Tomi Valkeinen @ 2013-03-27 6:13 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <20130326171006.GG25575@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
On 2013-03-26 19:10, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130326 06:38]:
>> Hi,
>>
>> To make it possible to add DT support to DSS, and later use the Common Display
>> Framework, we need to change the DSS device model. We currently have a custom
>> dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that
>> bus.
>>
>> The panel devices will be converted occording to the control bus of the panel.
>> For many panels this means that the panel device will become a platform_device.
>> For some, it means the panel devices become i2c or spi devices.
>>
>> This series takes the first step toward that goal. This series:
>>
>> * Converts DPI, HDMI and DSI outputs to work with new style panels
>> * Converts TFP410, Taal and generic-dpi panels to new model
>> * Converts Panda, 4430SDP and Overo boards to use the new panels
>>
>> The non-converted outputs and panels still work, so they can be converted in
>> stages.
>
> This is nice, it removes a merge dependency between ARM code and the driver :)
Yes. It does give me a few more gray hairs, though =). It'd be so much
easier to have all related changes in one clean patch series.
>> Note about board files: I only convert a few board files here for example. I
>> have a branch with board file changes for all the affected board files. I did
>> not include them as they are more or less identical. If this series looks good,
>> I will create an independent branch for the arch/arm stuff, so it can be pulled
>> separately.
>
> Great looks good to me thanks.
To make the DSS work properly after this device model change, we also
need to solve the problem related to multiple display devices on the
same video bus.
Did the approach I suggested in
http://permalink.gmane.org/gmane.linux.ports.arm.omap/96039
look ok? Overo is the most complex one, I think the rest of the boards
that require changes have just LCD and DVI that conflict. But it still
means we'll have that kind of choice Kconfig option for all those boards.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Call for fbdev patches for 3.10
From: Tomi Valkeinen @ 2013-03-27 6:46 UTC (permalink / raw)
To: linux-fbdev
Hi,
If nobody objects, I'll collect fbdev patches for 3.10 in addition to
collecting fbdev fixes for 3.9.
So, send the patches to me if there's only a few of them, but for bigger
series please send me a proper pull request, with annotated tag shortly
describing the changes.
And only reviewed and good patches, nothing controversial =).
Tomi
^ permalink raw reply
* Re: Call for fbdev patches for 3.10
From: Tomi Valkeinen @ 2013-03-27 6:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <515295CE.6060706@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
On 2013-03-27 08:46, Tomi Valkeinen wrote:
> Hi,
>
> If nobody objects, I'll collect fbdev patches for 3.10 in addition to
> collecting fbdev fixes for 3.9.
>
> So, send the patches to me if there's only a few of them, but for bigger
> series please send me a proper pull request, with annotated tag shortly
> describing the changes.
>
> And only reviewed and good patches, nothing controversial =).
Oops, that was meant to be sent from my @ti address. So please send the
patches/pull requests to my ti.com address.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCHv2 0/5] videomode patches
From: Tomi Valkeinen @ 2013-03-27 6:58 UTC (permalink / raw)
To: Steffen Trumtrar, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Laurent Pinchart
Hi,
Here's a v2 of the videomode series. The changes compared to v1:
* Dropped "videomode: rename fields", as it received only negative comments
* New patch: "videomode: videomode_from_timing work"
Patches 1-4 are unchanged.
Tomi
Tomi Valkeinen (5):
videomode: simplify videomode Kconfig and Makefile
videomode: combine videomode dmt_flags and data_flags
videomode: create enum for videomode's display flags
videomode: remove timing_entry_index
videomode: videomode_from_timing work
drivers/gpu/drm/drm_modes.c | 20 ++++++------
drivers/gpu/drm/tilcdc/Kconfig | 3 +-
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
drivers/video/Kconfig | 22 ++-----------
drivers/video/Makefile | 8 ++---
drivers/video/fbmon.c | 16 ++++-----
drivers/video/of_display_timing.c | 19 ++++++-----
drivers/video/of_videomode.c | 2 +-
drivers/video/videomode.c | 36 ++++++++++++---------
include/video/display_timing.h | 57 ++++++++++-----------------------
include/video/videomode.h | 18 ++++++++---
11 files changed, 88 insertions(+), 115 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCHv2 1/5] videomode: simplify videomode Kconfig and Makefile
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>
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The related code should just be
included if it's needed, i.e. selected by drivers using videomode.
* There's no need to have separate Kconfig options for videomode and
display_timing. First of all, the amount of code for both is quite
small. Second, videomode depends on display_timing, and display_timing
in itself is not really useful, so both would be included in any case.
* CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS
describes better what's included.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/drm_modes.c | 8 ++++----
drivers/gpu/drm/tilcdc/Kconfig | 3 +--
drivers/video/Kconfig | 22 ++--------------------
drivers/video/Makefile | 8 ++++----
drivers/video/fbmon.c | 8 ++++----
5 files changed, 15 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 04fa6f1..0698c0e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -506,7 +506,7 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
-#if IS_ENABLED(CONFIG_VIDEOMODE)
+#ifdef CONFIG_VIDEOMODE_HELPERS
int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode)
{
@@ -540,9 +540,8 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
return 0;
}
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
-#endif
-#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+#ifdef CONFIG_OF
/**
* of_get_drm_display_mode - get a drm_display_mode from devicetree
* @np: device_node with the timing specification
@@ -572,7 +571,8 @@ int of_get_drm_display_mode(struct device_node *np,
return 0;
}
EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
-#endif
+#endif /* CONFIG_OF */
+#endif /* CONFIG_VIDEOMODE_HELPERS */
/**
* drm_mode_set_name - set the name on a mode
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index d24d040..e461e99 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -4,8 +4,7 @@ config DRM_TILCDC
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
- select OF_VIDEOMODE
- select OF_DISPLAY_TIMING
+ select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
help
Choose this option if you have an TI SoC with LCDC display
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..2a81b11 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -31,26 +31,8 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
-config DISPLAY_TIMING
- bool
-
-config VIDEOMODE
- bool
-
-config OF_DISPLAY_TIMING
- bool "Enable device tree display timing support"
- depends on OF
- select DISPLAY_TIMING
- help
- helper to parse display timings from the devicetree
-
-config OF_VIDEOMODE
- bool "Enable device tree videomode support"
- depends on OF
- select VIDEOMODE
- select OF_DISPLAY_TIMING
- help
- helper to get videomodes from the devicetree
+config VIDEOMODE_HELPERS
+ bool
config HDMI
bool
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9df3873..e414378 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -171,7 +171,7 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
-obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
-obj-$(CONFIG_OF_DISPLAY_TIMING) += of_display_timing.o
-obj-$(CONFIG_VIDEOMODE) += videomode.o
-obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
+obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
+ifeq ($(CONFIG_OF),y)
+obj-$(CONFIG_VIDEOMODE_HELPERS) += of_display_timing.o of_videomode.o
+endif
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 94ad0f7..368cedf 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1376,7 +1376,7 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf
return err;
}
-#if IS_ENABLED(CONFIG_VIDEOMODE)
+#ifdef CONFIG_VIDEOMODE_HELPERS
int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode)
{
@@ -1424,9 +1424,8 @@ int fb_videomode_from_videomode(const struct videomode *vm,
return 0;
}
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
-#endif
-#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+#ifdef CONFIG_OF
static inline void dump_fb_videomode(const struct fb_videomode *m)
{
pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u %u\n",
@@ -1465,7 +1464,8 @@ int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
return 0;
}
EXPORT_SYMBOL_GPL(of_get_fb_videomode);
-#endif
+#endif /* CONFIG_OF */
+#endif /* CONFIG_VIDEOMODE_HELPERS */
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
--
1.7.10.4
^ permalink raw reply related
* [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
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