* [PATCH] tps65217: Allow placement elsewhere than parent mfd device
From: Pantelis Antoniou @ 2012-10-30 18:17 UTC (permalink / raw)
To: Richard Purdie
Cc: Pantelis Antoniou, Florian Tobias Schandinat, Grant Likely,
linux-fbdev, devicetree-discuss, linux-kernel, Koen Kooi,
Matt Porter, Russ Dill, linux-omap
The current code expect the configuration of the backlight to stay
constant after initialization. This patch allows to move it around.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
drivers/video/backlight/tps65217_bl.c | 103 ++++++++++++++++++++++++++++++----
1 file changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c
index 7088163..69c1dfe 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -24,8 +24,11 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/of_i2c.h>
struct tps65217_bl {
+ struct i2c_client *i2c_client;
struct tps65217 *tps;
struct device *dev;
struct backlight_device *bl;
@@ -98,8 +101,6 @@ static int tps65217_bl_update_status(struct backlight_device *bl)
return rc;
}
- dev_dbg(tps65217_bl->dev, "brightness set to %d\n", brightness);
-
if (!tps65217_bl->is_enabled)
rc = tps65217_bl_enable(tps65217_bl);
} else {
@@ -187,14 +188,69 @@ static int tps65217_bl_hw_init(struct tps65217_bl *tps65217_bl,
#ifdef CONFIG_OF
static struct tps65217_bl_pdata *
-tps65217_bl_parse_dt(struct platform_device *pdev)
+tps65217_bl_parse_dt(struct platform_device *pdev, struct tps65217 **tpsp,
+ int *brightnessp)
{
- struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
- struct device_node *node = of_node_get(tps->dev->of_node);
+ struct i2c_client *i2c_client;
+ struct tps65217 *tps;
+ struct device_node *node, *rnode, *pnode;
struct tps65217_bl_pdata *pdata, *err;
+ u32 tps_handle;
u32 val;
- node = of_find_node_by_name(node, "backlight");
+ tps = NULL;
+ node = NULL;
+ *brightnessp = 0;
+
+ /* our node (compatible) */
+ pnode = pdev->dev.of_node;
+ if (pnode != NULL &&
+ of_property_read_u32(pnode, "tps", &tps_handle) = 0) {
+ /* we are not instantiated from the mfd */
+ node = of_find_node_by_phandle(tps_handle);
+ if (node = NULL) {
+ dev_err(&pdev->dev, "failed to find the tps node\n");
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ i2c_client = of_find_i2c_device_by_node(node);
+ if (i2c_client = NULL) {
+ dev_err(&pdev->dev, "failed to find the i2c device "
+ "of tps node\n");
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ /* yeah this is gross; the whole concept is */
+ tps = i2c_get_clientdata(i2c_client);
+ if (tps = NULL) {
+ dev_err(&pdev->dev, "failed to get tps structure\n");
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+
+ /* read default brightness */
+ val = 0;
+ of_property_read_u32(pnode, "brightness", &val);
+ if (val >= 100)
+ val = 100;
+
+ *brightnessp = val;
+
+ /* no need for this anymore */
+ of_node_put(node);
+
+ dev_info(&pdev->dev, "got tps=%p from handle 0x%x\n", tps, tps_handle);
+ }
+
+ if (tps = NULL)
+ tps = dev_get_drvdata(pdev->dev.parent);
+
+ rnode = of_node_get(tps->dev->of_node);
+
+ node = of_find_node_by_name(rnode, "backlight");
+ of_node_put(rnode);
+ rnode = NULL;
+
if (!node)
return ERR_PTR(-ENODEV);
@@ -247,6 +303,7 @@ tps65217_bl_parse_dt(struct platform_device *pdev)
of_node_put(node);
+ *tpsp = tps;
return pdata;
err:
@@ -254,9 +311,16 @@ err:
return err;
}
+
+static struct of_device_id tps65217_backlight_of_match[] = {
+ { .compatible = "tps65217-backlight" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tps65217_backlight_of_match);
#else
static struct tps65217_bl_pdata *
-tps65217_bl_parse_dt(struct platform_device *pdev)
+tps65217_bl_parse_dt(struct platform_device *pdev, struct tps65217 **tpsp,
+ int *brightnessp)
{
return NULL;
}
@@ -265,13 +329,16 @@ tps65217_bl_parse_dt(struct platform_device *pdev)
static int tps65217_bl_probe(struct platform_device *pdev)
{
int rc;
- struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
+ struct tps65217 *tps;
struct tps65217_bl *tps65217_bl;
struct tps65217_bl_pdata *pdata;
struct backlight_properties bl_props;
+ int brightness = 0;
- if (tps->dev->of_node) {
- pdata = tps65217_bl_parse_dt(pdev);
+ tps = NULL;
+
+ if (pdev->dev.of_node) {
+ pdata = tps65217_bl_parse_dt(pdev, &tps, &brightness);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -281,6 +348,14 @@ static int tps65217_bl_probe(struct platform_device *pdev)
}
pdata = pdev->dev.platform_data;
+
+ /* get the parent device */
+ tps = dev_get_drvdata(pdev->dev.parent);
+ }
+
+ if (tps = NULL) {
+ dev_err(&pdev->dev, "failed to find tps\n");
+ return -EINVAL;
}
tps65217_bl = devm_kzalloc(&pdev->dev, sizeof(*tps65217_bl),
@@ -311,9 +386,14 @@ static int tps65217_bl_probe(struct platform_device *pdev)
return PTR_ERR(tps65217_bl->bl);
}
- tps65217_bl->bl->props.brightness = 0;
+ tps65217_bl->bl->props.brightness = brightness;
platform_set_drvdata(pdev, tps65217_bl);
+ /* update with initial settings */
+ tps65217_bl_update_status(tps65217_bl->bl);
+
+ dev_info(&pdev->dev, "OK.\n");
+
return 0;
}
@@ -332,6 +412,7 @@ static struct platform_driver tps65217_bl_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "tps65217-bl",
+ .of_match_table = of_match_ptr(tps65217_backlight_of_match),
},
};
--
1.7.12
^ permalink raw reply related
* [PATCH] da8xx-fb: add panel definition for beaglebone LCD7 cape
From: Pantelis Antoniou @ 2012-10-30 18:17 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Koen Kooi, linux-fbdev, linux-kernel, Matt Porter, Russ Dill,
linux-omap
From: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
drivers/video/da8xx-fb.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 4462d9e..c661665 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -284,6 +284,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 56000000,
.invert_pxl_clk = 0,
},
+ /* ThreeFive S9700RTWV35TR */
+ [4] = {
+ .name = "TFC_S9700RTWV35TR_01B",
+ .width = 800,
+ .height = 480,
+ .hfp = 39,
+ .hbp = 39,
+ .hsw = 47,
+ .vfp = 13,
+ .vbp = 29,
+ .vsw = 2,
+ .pxl_clk = 30000000,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
--
1.7.12
^ permalink raw reply related
* [PATCH] da8xx: De-constify members in the platform config.
From: Pantelis Antoniou @ 2012-10-30 18:15 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Pantelis Antoniou, linux-fbdev, linux-kernel, Koen Kooi,
Matt Porter, Russ Dill, linux-omap
There's no need for this to be const. It interferes with
creating the platform data dynamically.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
include/video/da8xx-fb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 5a0e4f9..a512d6b 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -35,9 +35,9 @@ struct display_panel {
};
struct da8xx_lcdc_platform_data {
- const char manu_name[10];
+ char manu_name[10];
void *controller_data;
- const char type[25];
+ char type[25];
void (*panel_power_ctrl)(int);
};
--
1.7.12
^ permalink raw reply related
* [PATCH] pwm-backlight: Pinctrl-fy
From: Pantelis Antoniou @ 2012-10-30 18:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Pantelis Antoniou, Richard Purdie, Florian Tobias Schandinat,
linux-fbdev, linux-kernel, Koen Kooi, Matt Porter, Russ Dill,
linux-omap
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
drivers/video/backlight/pwm_bl.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 0c91023..f3b6194 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,6 +20,8 @@
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
#include <linux/slab.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/err.h>
struct pwm_bl_data {
struct pwm_device *pwm;
@@ -180,9 +182,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ struct pinctrl *pinctrl;
unsigned int max;
int ret;
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(&pdev->dev, "unable to select pin group\n");
+
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
if (ret < 0) {
--
1.7.12
^ permalink raw reply related
* [PATCH] da8xx: Fix revision check on the da8xx driver
From: Pantelis Antoniou @ 2012-10-30 18:14 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Pantelis Antoniou, linux-fbdev, linux-kernel, Koen Kooi,
Matt Porter, Russ Dill, linux-omap
The revision check fails for the beaglebone; Add new revision ID.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
drivers/video/da8xx-fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 80665f6..866d804 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1283,6 +1283,7 @@ static int __devinit fb_probe(struct platform_device *device)
lcd_revision = LCD_VERSION_1;
break;
case 0x4F200800:
+ case 0x4F201000:
lcd_revision = LCD_VERSION_2;
break;
default:
--
1.7.12
^ permalink raw reply related
* [PATCH] da8xx: Add CDTech_S035Q01 panel (used by LCD3 bone cape)
From: Pantelis Antoniou @ 2012-10-30 18:12 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Pantelis Antoniou, linux-fbdev, linux-kernel, Koen Kooi,
Matt Porter, Russ Dill, linux-omap
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
drivers/video/da8xx-fb.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index c661665..c1f5d30 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -298,6 +298,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 30000000,
.invert_pxl_clk = 0,
},
+ [5] = {
+ /* CDTech S035Q01 */
+ .name = "CDTech_S035Q01",
+ .width = 320,
+ .height = 240,
+ .hfp = 58,
+ .hbp = 21,
+ .hsw = 47,
+ .vfp = 23,
+ .vbp = 11,
+ .vsw = 2,
+ .pxl_clk = 8000000,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
--
1.7.12
^ permalink raw reply related
* Re: [RFC 0/5] Generic panel framework
From: Laurent Pinchart @ 2012-10-30 16:35 UTC (permalink / raw)
To: Zhou Zhu
Cc: Jun Nie, Tomi Valkeinen, linux-fbdev, dri-devel, linux-leds,
linux-media, Bryan Wu, Richard Purdie, Marcus Lorentzon,
Sumit Semwal, Archit Taneja, Sebastien Guiriec, Inki Dae,
Kyungmin Park
In-Reply-To: <CAJATT-5=kQzUaubL--oRJdm6u8Z10Hus+SMLt3zG1ZSi4QUVWw@mail.gmail.com>
Hi Zhou,
On Tuesday 04 September 2012 16:20:38 Zhou Zhu wrote:
> Hi Laurent,
>
> Basically I agree that we need a common panel framework. I just have
> some questions:
> 1. I think we should add color format in videomode - if we use such
> common video mode structure shared across subsystems.
> In HDMI, colors are bind with timings tightly. We need a combined
> videomode with timing and color format together.
What kind of color formats do you have in mind ?
> 2. I think we should add "set_videomode" interface. It helps HDMI
> monitors to set EDIDs.
For panels that support several video modes, sure, we need a way to set the
video mode. I don't have access to any such panel though, that's why the
operation has been left out. It wouldn't be difficult to add it when a real
use case will come up.
What do you mean exactly about HDMI monitors setting EDID ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC 0/5] Generic panel framework
From: Laurent Pinchart @ 2012-10-30 16:23 UTC (permalink / raw)
To: Jun Nie
Cc: Tomi Valkeinen, linux-fbdev, dri-devel, linux-leds, linux-media,
Bryan Wu, Richard Purdie, Marcus Lorentzon, Sumit Semwal,
Archit Taneja, Sebastien Guiriec, Inki Dae, Kyungmin Park
In-Reply-To: <CAGA24MLnW-i0koFuAsnFQ2mNnrLupkmbxW5T8WYiV3QuoA2vig@mail.gmail.com>
Hi Jun,
I've finally been able to resume my work on the panel framework (I hope to
post a v2 at the end of the week).
On Thursday 23 August 2012 14:23:01 Jun Nie wrote:
> Hi Laurent,
> Do you plan to add an API to get and parse EDID to mode list?
An API to get the raw EDID data is likely needed. Parsing EDID data in the
panel driver and providing the modes to the caller isn't enough, as EDID
contains more than just video modes. I'm not sure whether a driver for an
EDID-aware panel should parse the EDID data internally and provide both modes
and raw EDID data, or only raw EDID data.
> video mode is tightly coupled with panel that is capable of hot-plug.
> Or you are busy on modifying EDID parsing code for sharing it amoung
> DRM/FB/etc? I see you mentioned this in Mar.
That's needed as well, but -ENOTIME :-S
> It is great if you are considering add more info into video mode, such as
> pixel repeating, 3D timing related parameter.
Please have a look at "[PATCH 2/2 v6] of: add generic videomode description"
on dri-devel. There's a proposal for a common video mode structure.
> I have some code for CEA modes filtering and 3D parsing, but still tight
> coupled with FB and with a little hack style.
>
> My HDMI driver is implemented as lcd device as you mentioned here.
> But more complex than other lcd devices for a kthread is handling
> hot-plug/EDID/HDCP/ASoC etc.
>
> I also feel a little weird to add code parsing HDMI audio related
> info in fbmod.c in my current implementation, thought it is the only
> place to handle EDID in kernel. Your panel framework provide a better
> place to add panel related audio/HDCP code. panel notifier can also
> trigger hot-plug related feature, such as HDCP start.
That's a good idea. I was wondering whether to put the common EDID parser in
drivers/gpu/drm, drivers/video or drivers/media. Putting it wherever the panel
framework will be might be a good option as well.
> Looking forward to your hot-plug panel patch. Or I can help add it
> if you would like me to.
I'll try to post a v2 at the end of the week, but likely without much hot-plug
support. Patches and enhancement proposals will be welcome.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 64 ++++++++++++++++++++++++-----------------
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 267caf0..32e7dd5 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -49,28 +49,30 @@ static struct {
struct omap_dss_output output;
} dpi;
-static struct platform_device *dpi_get_dsidev(enum omap_dss_clk_source clk)
+static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
{
- int dsi_module;
-
- dsi_module = clk = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ? 0 : 1;
-
- return dsi_get_dsidev_from_id(dsi_module);
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD2:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
}
-static bool dpi_use_dsi_pll(struct omap_dss_device *dssdev)
+static enum omap_dss_clk_source dpi_get_alt_clk_src(enum omap_channel channel)
{
- if (dssdev->clocks.dispc.dispc_fclk_src =
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
- dssdev->clocks.dispc.dispc_fclk_src =
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ||
- dssdev->clocks.dispc.channel.lcd_clk_src =
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
- dssdev->clocks.dispc.channel.lcd_clk_src =
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC)
- return true;
- else
- return false;
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC;
+ case OMAP_DSS_CHANNEL_LCD2:
+ return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC;
+ default:
+ /* this shouldn't happen */
+ WARN_ON(1);
+ return OMAP_DSS_CLK_SRC_FCK;
+ }
}
static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
@@ -92,7 +94,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
return r;
dss_select_lcd_clk_source(mgr->id,
- dssdev->clocks.dispc.channel.lcd_clk_src);
+ dpi_get_alt_clk_src(mgr->id));
dpi.mgr_config.clock_info = dispc_cinfo;
@@ -385,6 +387,8 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
+ struct platform_device *dsidev;
+
DSSDBG("init_display\n");
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
@@ -401,17 +405,23 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- if (dpi_use_dsi_pll(dssdev)) {
- enum omap_dss_clk_source dispc_fclk_src - dssdev->clocks.dispc.dispc_fclk_src;
- dpi.dsidev = dpi_get_dsidev(dispc_fclk_src);
+ /*
+ * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
+ * source for DPI is SoC integration detail, not something that should
+ * be configured in the dssdev
+ */
+ dsidev = dpi_get_dsidev(dssdev->channel);
- if (dpi_verify_dsi_pll(dpi.dsidev)) {
- dpi.dsidev = NULL;
- DSSWARN("DSI PLL not operational\n");
- }
+ if (dpi_verify_dsi_pll(dsidev)) {
+ dsidev = NULL;
+ DSSWARN("DSI PLL not operational\n");
}
+ if (dsidev)
+ DSSDBG("using DSI PLL for DPI clock\n");
+
+ dpi.dsidev = dsidev;
+
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/12] OMAPDSS: DPI: verify if DSI PLL is operational
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
The SoCs that have DSI module should have a working DSI PLL. However,
some rare boards have not connected the powers to the DSI PLL.
This patch adds a function that tries to power up the DSI PLL, and
reports if that doesn't succeed. DPI uses this function to fall back to
PRCM clocks if DSI PLL doesn't work.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index fc1ec7d..267caf0 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -361,6 +361,28 @@ void omapdss_dpi_set_data_lines(struct omap_dss_device *dssdev, int data_lines)
}
EXPORT_SYMBOL(omapdss_dpi_set_data_lines);
+static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
+{
+ int r;
+
+ /* do initial setup with the PLL to see if it is operational */
+
+ r = dsi_runtime_get(dsidev);
+ if (r)
+ return r;
+
+ r = dsi_pll_init(dsidev, 0, 1);
+ if (r) {
+ dsi_runtime_put(dsidev);
+ return r;
+ }
+
+ dsi_pll_uninit(dsidev, true);
+ dsi_runtime_put(dsidev);
+
+ return 0;
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
@@ -383,6 +405,11 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
enum omap_dss_clk_source dispc_fclk_src dssdev->clocks.dispc.dispc_fclk_src;
dpi.dsidev = dpi_get_dsidev(dispc_fclk_src);
+
+ if (dpi_verify_dsi_pll(dpi.dsidev)) {
+ dpi.dsidev = NULL;
+ DSSWARN("DSI PLL not operational\n");
+ }
}
return 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/12] OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
can just check if dpi.dsidev != NULL.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 9df62cf..fc1ec7d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -137,7 +137,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
unsigned long pck;
int r = 0;
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
r = dpi_set_dsi_clk(dssdev, t->pixel_clock * 1000, &fck,
&lck_div, &pck_div);
else
@@ -216,7 +216,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
if (r)
goto err_src_sel;
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
r = dsi_runtime_get(dpi.dsidev);
if (r)
goto err_get_dsi;
@@ -244,10 +244,10 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
err_mgr_enable:
err_set_mode:
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
dsi_pll_uninit(dpi.dsidev, true);
err_dsi_pll_init:
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
dsi_runtime_put(dpi.dsidev);
err_get_dsi:
err_src_sel:
@@ -273,7 +273,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
dss_mgr_disable(mgr);
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
dsi_pll_uninit(dpi.dsidev, true);
dsi_runtime_put(dpi.dsidev);
@@ -319,7 +319,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
if (timings->pixel_clock = 0)
return -EINVAL;
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
struct dsi_clock_info dsi_cinfo;
r = dsi_pll_calc_clock_div_pck(dpi.dsidev,
timings->pixel_clock * 1000,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source()
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.
After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 6 ++++--
drivers/video/omap2/dss/dsi.c | 3 ---
drivers/video/omap2/dss/dss.c | 6 ++++--
drivers/video/omap2/dss/dss.h | 1 -
drivers/video/omap2/dss/hdmi.c | 8 --------
5 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 56748cf..9df62cf 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -77,6 +77,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
+ struct omap_overlay_manager *mgr = dssdev->output->manager;
struct dsi_clock_info dsi_cinfo;
struct dispc_clock_info dispc_cinfo;
int r;
@@ -90,7 +91,8 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
+ dss_select_lcd_clk_source(mgr->id,
+ dssdev->clocks.dispc.channel.lcd_clk_src);
dpi.mgr_config.clock_info = dispc_cinfo;
@@ -272,7 +274,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
dss_mgr_disable(mgr);
if (dpi_use_dsi_pll(dssdev)) {
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
+ dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
dsi_pll_uninit(dpi.dsidev, true);
dsi_runtime_put(dpi.dsidev);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 26d1a78..70bd7a5 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4720,7 +4720,6 @@ static int dsi_display_init_dsi(struct omap_dss_device *dssdev)
if (r)
goto err1;
- dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
dss_select_dsi_clk_source(dsi->module_id, dssdev->clocks.dsi.dsi_fclk_src);
dss_select_lcd_clk_source(mgr->id,
dssdev->clocks.dispc.channel.lcd_clk_src);
@@ -4755,7 +4754,6 @@ static int dsi_display_init_dsi(struct omap_dss_device *dssdev)
err3:
dsi_cio_uninit(dsidev);
err2:
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
dss_select_dsi_clk_source(dsi->module_id, OMAP_DSS_CLK_SRC_FCK);
dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
@@ -4782,7 +4780,6 @@ static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
dsi_vc_enable(dsidev, 2, 0);
dsi_vc_enable(dsidev, 3, 0);
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
dss_select_dsi_clk_source(dsi->module_id, OMAP_DSS_CLK_SRC_FCK);
dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
dsi_cio_uninit(dsidev);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 034cc1a..086ed56 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -304,7 +304,7 @@ static void dss_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
+static void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
{
struct platform_device *dsidev;
int b;
@@ -375,8 +375,10 @@ void dss_select_lcd_clk_source(enum omap_channel channel,
struct platform_device *dsidev;
int b, ix, pos;
- if (!dss_has_feature(FEAT_LCD_CLK_SRC))
+ if (!dss_has_feature(FEAT_LCD_CLK_SRC)) {
+ dss_select_dispc_clk_source(clk_src);
return;
+ }
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ae4e618..e8435ea 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -284,7 +284,6 @@ void dss_sdi_init(int datapairs);
int dss_sdi_enable(void);
void dss_sdi_disable(void);
-void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src);
void dss_select_dsi_clk_source(int dsi_module,
enum omap_dss_clk_source clk_src);
void dss_select_lcd_clk_source(enum omap_channel channel,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index adcc906..dc6d72c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -552,14 +552,6 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
/* Make selection of HDMI in DSS */
dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
- /* Select the dispc clock source as PRCM clock, to ensure that it is not
- * DSI PLL source as the clock selected by DSI PLL might not be
- * sufficient for the resolution selected / that can be changed
- * dynamically by user. This can be moved to single location , say
- * Boardfile.
- */
- dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
-
/* bypass TV gamma table */
dispc_enable_gamma_table(0);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/12] OMAPDSS: setup default dss fck
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.
For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
change the dss fck, and thus it may be left unconfigured. Usually the
dss fck is already setup fine by default, but we can't trust this.
This patch sets the dss fck to maximum at probe time.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 5affa86..034cc1a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -485,6 +485,36 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+static int dss_setup_default_clock(void)
+{
+ unsigned long max_dss_fck, prate;
+ unsigned fck_div;
+ struct dss_clock_info dss_cinfo = { 0 };
+ int r;
+
+ if (dss.dpll4_m4_ck = NULL)
+ return 0;
+
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+
+ prate = dss_get_dpll4_rate();
+
+ fck_div = DIV_ROUND_UP(prate * dss.feat->dss_fck_multiplier,
+ max_dss_fck);
+
+ dss_cinfo.fck_div = fck_div;
+
+ r = dss_calc_clock_rates(&dss_cinfo);
+ if (r)
+ return r;
+
+ r = dss_set_clock_div(&dss_cinfo);
+ if (r)
+ return r;
+
+ return 0;
+}
+
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo)
{
@@ -913,6 +943,10 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
+ r = dss_setup_default_clock();
+ if (r)
+ goto err_setup_clocks;
+
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -923,6 +957,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
return 0;
+err_setup_clocks:
+ dss_runtime_put();
err_runtime_get:
pm_runtime_disable(&pdev->dev);
dss_put_clocks();
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.c | 23 +++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index a85bd05..5affa86 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -432,6 +432,29 @@ enum omap_dss_clk_source dss_get_lcd_clk_source(enum omap_channel channel)
}
}
+/* calculate clock rates using dividers in cinfo */
+int dss_calc_clock_rates(struct dss_clock_info *cinfo)
+{
+ if (dss.dpll4_m4_ck) {
+ unsigned long prate;
+
+ if (cinfo->fck_div > dss.feat->fck_div_max ||
+ cinfo->fck_div = 0)
+ return -EINVAL;
+
+ prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
+
+ cinfo->fck = prate / cinfo->fck_div *
+ dss.feat->dss_fck_multiplier;
+ } else {
+ if (cinfo->fck_div != 0)
+ return -EINVAL;
+ cinfo->fck = clk_get_rate(dss.dss_clk);
+ }
+
+ return 0;
+}
+
int dss_set_clock_div(struct dss_clock_info *cinfo)
{
if (dss.dpll4_m4_ck) {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index fb89165..ae4e618 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -297,6 +297,7 @@ void dss_set_venc_output(enum omap_dss_venc_type type);
void dss_set_dac_pwrdn_bgz(bool enable);
unsigned long dss_get_dpll4_rate(void);
+int dss_calc_clock_rates(struct dss_clock_info *cinfo);
int dss_set_clock_div(struct dss_clock_info *cinfo);
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/12] OMAPDSS: DSI: workaround for HSDiv problem
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
It looks like on many OMAP versions powers for both HSClk and HSDiv to
be enabled to have a functional HSDiv.
This patch fixes the issue by forcing both powers on.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d0e35da..26d1a78 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1741,6 +1741,12 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
DSSDBG("PLL init\n");
+ /*
+ * It seems that on many OMAPs we need to enable both to have a
+ * functional HSDivider.
+ */
+ enable_hsclk = enable_hsdiv = true;
+
if (dsi->vdds_dsi_reg = NULL) {
struct regulator *vdds_dsi;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI output
pin the voltage of the signal is shifted from the OMAP's internal
minimal voltage to 1.8V range. The shifting is not instant, and the
higher the clock frequency, the less time there is to shift the signal
to nominal voltage.
If the HSDivider's divider is greater than one and odd, the resulting
pixel clock does not have 50% duty cycle. For example, with a divider of
3, the duty cycle is 33%.
When combining high frequency (in the area of 140MHz+) and non-50% duty
cycle, it has been observed the the shifter does not have enough time to
shift the voltage enough, and this leads to bad signal which is rejected
by monitors.
As a workaround this patch makes the divider calculation skip all odd
dividers when the required pixel clock is over 100MHz.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 7d0db2b..d0e35da 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1386,6 +1386,11 @@ retry:
cur.dsi_pll_hsdiv_dispc_clk cur.clkin4ddr / cur.regm_dispc;
+ if (cur.regm_dispc > 1 &&
+ cur.regm_dispc % 2 != 0 &&
+ req_pck >= 1000000)
+ continue;
+
/* this will narrow down the search a bit,
* but still give pixclocks below what was
* requested */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 37ee465..a85bd05 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -97,6 +97,8 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC] = "DSI_PLL_HSDIV_DISPC",
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI] = "DSI_PLL_HSDIV_DSI",
[OMAP_DSS_CLK_SRC_FCK] = "DSS_FCK",
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC] = "DSI_PLL2_HSDIV_DISPC",
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = "DSI_PLL2_HSDIV_DSI",
};
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/12] OMAPDSS: fix DPI & DSI init order
From: Tomi Valkeinen @ 2012-10-30 16:10 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver
is added first, which causes DPI initialization to fail when it tries to
get the DSI PLL.
This patch changes the init order to fix this.
A better solution would be to separate DSI PLL and DSI drivers. They
have dependencies, though, but we could still have DSI PLL as an
independent entity that we could initialize before any of the output
drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 00aa026..d25374c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -502,6 +502,9 @@ static int __init omap_dss_bus_register(void)
/* INIT */
static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_init_platform_driver,
+#endif
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_init_platform_driver,
#endif
@@ -514,15 +517,15 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
#ifdef CONFIG_OMAP2_DSS_VENC
venc_init_platform_driver,
#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_init_platform_driver,
-#endif
#ifdef CONFIG_OMAP4_DSS_HDMI
hdmi_init_platform_driver,
#endif
};
static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_uninit_platform_driver,
+#endif
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_uninit_platform_driver,
#endif
@@ -535,9 +538,6 @@ static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
#ifdef CONFIG_OMAP2_DSS_VENC
venc_uninit_platform_driver,
#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_uninit_platform_driver,
-#endif
#ifdef CONFIG_OMAP4_DSS_HDMI
hdmi_uninit_platform_driver,
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/12] OMAPFB: improve mode selection from EDID
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not the fastest of the
operations, and while doing it for one mode is usually ok, doing it for
20 modes is noticable.
Also, the first mode given in the EDID data should be the native mode of
the monitor, and thus also the best mode, so if that can be used, no
need to look further.
This patch changes the code to use the first mode that is compatible
with the DSS hardware.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 0358b14..6e5334c 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2258,7 +2258,7 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
{
struct fb_monspecs *specs;
u8 *edid;
- int r, i, best_xres, best_idx, len;
+ int r, i, best_idx, len;
if (!display->driver->read_edid)
return -ENODEV;
@@ -2274,7 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
fb_edid_to_monspecs(edid, specs);
- best_xres = 0;
best_idx = -1;
for (i = 0; i < specs->modedb_len; ++i) {
@@ -2290,16 +2289,20 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
if (m->xres = 2880 || m->xres = 1440)
continue;
+ if (m->vmode & FB_VMODE_INTERLACED ||
+ m->vmode & FB_VMODE_DOUBLE)
+ continue;
+
fb_videomode_to_omap_timings(m, display, &t);
r = display->driver->check_timings(display, &t);
- if (r = 0 && best_xres < m->xres) {
- best_xres = m->xres;
+ if (r = 0) {
best_idx = i;
+ break;
}
}
- if (best_xres = 0) {
+ if (best_idx = -1) {
r = -ENOENT;
goto err2;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 01/12] OMAPFB: remove use of extended edid block
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from the first
EDID block, thus making the default videomode selection not to work
properly.
This patch removes the use of the extended edid block for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index bc225e4..0358b14 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2274,9 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
fb_edid_to_monspecs(edid, specs);
- if (edid[126] > 0)
- fb_edid_add_monspecs(edid + 0x80, specs);
-
best_xres = 0;
best_idx = -1;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/12] OMAPDSS: use DSI PLL clk for DPI
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
Hi,
The aim of this series is to enable using DSI PLL as the pixel clock source for
DPI output. There are the following main parts:
* first 4 patches are slightly related generic improvements/fixes
* fix DSI PLL problem related to non-50% duty cycle
* fix DSI PLL problem related to powering
* changes to the clock handling to always use DSI PLL for DPI when possible
I've tested the series on OMAP4 Panda, OMAP4 SDP and OMAP3 Beagle.
Tomi
Tomi Valkeinen (12):
OMAPFB: remove use of extended edid block
OMAPFB: improve mode selection from EDID
OMAPDSS: fix DPI & DSI init order
OMAPDSS: fix DSI2 PLL clk names
OMAPDSS: DSI: skip odd dividers when pck >= 100MHz
OMAPDSS: DSI: workaround for HSDiv problem
OMAPDSS: add dss_calc_clock_rates() back
OMAPDSS: setup default dss fck
OMAPDSS: hide dss_select_dispc_clk_source()
OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll
OMAPDSS: DPI: verify if DSI PLL is operational
OMAPDSS: DPI: always use DSI PLL if available
drivers/video/omap2/dss/core.c | 12 ++--
drivers/video/omap2/dss/dpi.c | 99 +++++++++++++++++++++---------
drivers/video/omap2/dss/dsi.c | 14 ++++-
drivers/video/omap2/dss/dss.c | 67 +++++++++++++++++++-
drivers/video/omap2/dss/dss.h | 2 +-
drivers/video/omap2/dss/hdmi.c | 8 ---
drivers/video/omap2/omapfb/omapfb-main.c | 16 ++---
7 files changed, 160 insertions(+), 58 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH v3] video: Versatile Express DVI output driver
From: Pawel Moll @ 2012-10-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350405036-17997-1-git-send-email-pawel.moll@arm.com>
Hello again Florian,
On Tue, 2012-10-16 at 17:30 +0100, Pawel Moll wrote:
> Versatile Express' DVI video output can be connected to one the three
> sources - motherboard's CLCD controller or a video signal generated
> by one of the daughterboards.
>
> This driver configures the muxer FPGA so the output displays content
> of one of the framebuffers in the system (0 by default, can be changed
> by user writing to the "fb" sysfs attribute of the muxfpga device).
>
> It will also set up the display formatter mode and keep it up
> to date with mode changes requested by the user (eg. with fbset
> tool).
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
It's just a polite a friendly nag regarding this patch - it's been 2
weeks since I posted this version (and 1.5 month since the first one)...
Does it look good enough or completely wrong?
Cheers!
Paweł
^ permalink raw reply
* Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
From: Archit Taneja @ 2012-10-29 10:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E597F.60406@ti.com>
On Monday 29 October 2012 03:55 PM, Tomi Valkeinen wrote:
> On 2012-10-29 12:04, Archit Taneja wrote:
>> On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
>>> Currently omapdss driver sets up the initial connections between
>>> overlays, overlay manager and a panel, based on default display
>>> parameter coming from the board file or via module parameters.
>>>
>>> This is unnecessary, as it's the higher level component that should
>>> decide what display to use and how. This patch removes the code from
>>> omapdss, and implements similar code to omapfb.
>>>
>>> The def_disp module parameter and the default display platform_data
>>> parameter are kept in omapdss, but omapdss doesn't do anything with
>>> them. It will just return the default display name with
>>> dss_get_default_display_name() call, which omapfb uses. This is done to
>>> keep the backward compatibility.
>>
>> We might need to do something similar for omap_vout and omapdrm also to
>> set the initial connections.
>
> I believe omapdrm already does this.
>
> For omap_vout... I'm not sure if we can do that. Both omapfb and
> omap_vout work at the same time, so they could be setting up the
> settings at the same time, perhaps with conflicting values. The reason I
> left omap_vout out is that I think omapfb is always used with omap_vout,
> thus the config can be left for omapfb. I didn't test this, though.
I thought we could have omap_vout without omapfb, at least we can build
it separately. Anyway, setting initial connections in omap_vout doesn't
seem very important as we generally have both of them together.
>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/dss/core.c | 1 +
>>> drivers/video/omap2/dss/display.c | 78
>>> +++---------------------------
>>> drivers/video/omap2/omapfb/omapfb-main.c | 77
>>> ++++++++++++++++++++++++-----
>>> include/video/omapdss.h | 1 +
>>> 4 files changed, 75 insertions(+), 82 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/dss/core.c
>>> b/drivers/video/omap2/dss/core.c
>>> index 685d9a9..4cb669e 100644
>>> --- a/drivers/video/omap2/dss/core.c
>>> +++ b/drivers/video/omap2/dss/core.c
>>> @@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
>>> {
>>> return core.default_display_name;
>>> }
>>> +EXPORT_SYMBOL(dss_get_default_display_name);
>>
>> Since we are exporting this, it might be better to name it
>> omapdss_get_default_display_name
>
> True.
>
>>> enum omapdss_version omapdss_get_version(void)
>>> {
>>> diff --git a/drivers/video/omap2/dss/display.c
>>> b/drivers/video/omap2/dss/display.c
>>> index 1e58730..6d33112 100644
>>> --- a/drivers/video/omap2/dss/display.c
>>> +++ b/drivers/video/omap2/dss/display.c
>>> @@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
>>> omap_dss_device *dssdev,
>>> }
>>> EXPORT_SYMBOL(omapdss_default_get_timings);
>>>
>>> -/*
>>> - * Connect dssdev to a manager if the manager is free or if force is
>>> specified.
>>> - * Connect all overlays to that manager if they are free or if force is
>>> - * specified.
>>> - */
>>> -static int dss_init_connections(struct omap_dss_device *dssdev, bool
>>> force)
>>> +int dss_init_device(struct platform_device *pdev,
>>> + struct omap_dss_device *dssdev)
>>> {
>>> + struct device_attribute *attr;
>>> struct omap_dss_output *out;
>>> - struct omap_overlay_manager *mgr;
>>> int i, r;
>>>
>>> out = omapdss_get_output_from_dssdev(dssdev);
>>>
>>> - WARN_ON(dssdev->output);
>>> - WARN_ON(out->device);
>>> -
>>> r = omapdss_output_set_device(out, dssdev);
>>> if (r) {
>>> DSSERR("failed to connect output to new device\n");
>>> return r;
>>> }
>>
>> So, we still manage the output-device links in the omapdss driver, but
>> move the manager-output and overlay-manager links to omapfb. I guess
>> this is fine. But maybe this split might change based on how generic
>> panel framework looks like, and how much we want to expose outputs to
>> fb/drm.
>
> We can set the output-device link in omapdss because it's a hardware
> configuration. A panel is connected to an output, so there's nothing to
> configure there. ovls and ovl-mgrs, on the other hand, may be configured
> depending on the use cases.
Yes, that makes sense.
Archit
^ permalink raw reply
* Re: [PATCH 11/20] OMAPDSS: HDMI: split power_on/off to two parts
From: Tomi Valkeinen @ 2012-10-29 10:30 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev, Ricardo Neri
In-Reply-To: <508E570D.1000101@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3819 bytes --]
On 2012-10-29 12:14, Archit Taneja wrote:
> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>> There's currently just one power-on function for HDMI, which enables the
>> IP and the video output. When reading EDID or detecting if a monitor is
>> connected, we don't need the video output.
>>
>> Enabling the video output for these operations is not a big problem in
>> itself, but the quick enable/disable cycles caused by the operations
>> seem to cause sync lost errors from time to time. Also, this makes it
>> possible to read the EDID before the full video path has been set up.
>>
>> This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
>> and hdmi_power_on_full. The "full" version does what hdmi_power_on does
>> currently, and hdmi_power_on_core only enables the core IP. Similar
>> changes are made for power_off.
>>
>> Note that these don't allow the HDMI IP to be first enabled, and later
>> enable the video output, but the HDMI IP will first need to be powered
>> off before calling the full version. So this is rather limited
>> implementation, but it fills the needs for reading EDID.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ricardo Neri <ricardo.neri@ti.com>
>> ---
>> drivers/video/omap2/dss/hdmi.c | 75
>> ++++++++++++++++++++++++----------------
>> 1 file changed, 46 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/hdmi.c
>> b/drivers/video/omap2/dss/hdmi.c
>> index c1c5488..50d5a10 100644
>> --- a/drivers/video/omap2/dss/hdmi.c
>> +++ b/drivers/video/omap2/dss/hdmi.c
>> @@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct
>> omap_dss_device *dssdev, int phy,
>> DSSDBG("range = %d sd = %d\n", pi->dcofreq, pi->regsd);
>> }
>>
>> -static int hdmi_power_on(struct omap_dss_device *dssdev)
>> +static int hdmi_power_on_core(struct omap_dss_device *dssdev)
>> {
>> int r;
>> - struct omap_video_timings *p;
>> - struct omap_overlay_manager *mgr = dssdev->output->manager;
>> - unsigned long phy;
>>
>> gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
>> gpio_set_value(hdmi.ls_oe_gpio, 1);
>> @@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device
>> *dssdev)
>> if (r)
>> goto err_runtime_get;
>>
>> + /* Make selection of HDMI in DSS */
>> + dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
>> +
>> + /* Select the dispc clock source as PRCM clock, to ensure that it
>> is not
>> + * DSI PLL source as the clock selected by DSI PLL might not be
>> + * sufficient for the resolution selected / that can be changed
>> + * dynamically by user. This can be moved to single location , say
>> + * Boardfile.
>> + */
>> + dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
>> +
>> + return 0;
>> +
>> +err_runtime_get:
>> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
>> +err_vdac_enable:
>> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
>> + gpio_set_value(hdmi.ls_oe_gpio, 0);
>> + return r;
>> +}
>> +
>> +static void hdmi_power_off_core(struct omap_dss_device *dssdev)
>> +{
>> + hdmi_runtime_put();
>> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
>> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
>> + gpio_set_value(hdmi.ls_oe_gpio, 0);
>
> We might want to set the DISPC clock source back to DSS_FCK here. Just
> in case it was using something else. Having this still won't make things
> full proof, but probably slightly better.
In this patch I only split the code, keeping the current behavior. But
true, setting the clk src back to DSS_FCK makes sense. Although I'd
rather remove the whole dispc clk src call, as the output drivers
calling it can easily mess things up.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
From: Archit Taneja @ 2012-10-29 10:30 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E389C.8080503@ti.com>
On Monday 29 October 2012 01:34 PM, Tomi Valkeinen wrote:
> On 2012-10-29 09:12, Archit Taneja wrote:
>> Hi,
>>
>> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>>> The dispc error handler tries to "fix" issues by disabling and enabling
>>> panel. This is problematic, as we're trying to remove the dependency
>>> from omapdss to the omap_dss_devices. It's also racy, and doesn't really
>>> fix anything.
>>>
>>> This patch removes the use of omap_dss_device from the error handler,
>>> and just disables and enables the associated overlay manager. This
>>> should produce similar results as the previous solution, without using
>>> dssdev.
>>
>> Calling APPLY functions from the DISPC driver seems a bit incorrect.
>> Instead of disabling/enabling the panel, can't we disable/enable the
>> manger by just using DISPC funcs?
>
> I agree, but if we don't call apply functions, we're bypassing the
> locks/etc from apply, and we could end up messing up what apply.c thinks
> is going on.
>
> With my omapdss+omapdrm compatibility patch series I'm moving the error
> handler to the apply mechanism, so it becomes a bit saner.
Okay. Having the error handler in apply would make things better.
Archit
^ permalink raw reply
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