* [PATCH 18/21] OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()
From: Archit Taneja @ 2012-09-13 12:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1347538505-25359-1-git-send-email-archit@ti.com>
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:
truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.
writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 26 +++++++++++++++++++++++++-
drivers/video/omap2/dss/dss.h | 2 +-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f575875..a44cbac 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2465,13 +2465,15 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
}
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
- const struct omap_video_timings *mgr_timings)
+ bool mem_to_mem, const struct omap_video_timings *mgr_timings)
{
int r;
+ u32 l;
enum omap_plane plane = OMAP_DSS_WB;
const int pos_x = 0, pos_y = 0;
const u8 zorder = 0, global_alpha = 0;
const bool replication = false;
+ bool truncation;
int in_width = mgr_timings->x_res;
int in_height = mgr_timings->y_res;
unsigned long out_rate;
@@ -2491,6 +2493,28 @@ int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
wi->mirror, zorder, wi->pre_mult_alpha, global_alpha,
wi->rotation_type, replication, mgr_timings);
+ switch (wi->color_mode) {
+ case OMAP_DSS_COLOR_RGB16:
+ case OMAP_DSS_COLOR_RGB24P:
+ case OMAP_DSS_COLOR_ARGB16:
+ case OMAP_DSS_COLOR_RGBA16:
+ case OMAP_DSS_COLOR_RGB12U:
+ case OMAP_DSS_COLOR_ARGB16_1555:
+ case OMAP_DSS_COLOR_XRGB16_1555:
+ case OMAP_DSS_COLOR_RGBX16:
+ truncation = true;
+ break;
+ default:
+ truncation = false;
+ break;
+ }
+
+ /* setup extra DISPC_WB_ATTRIBUTES */
+ l = dispc_read_reg(DISPC_OVL_ATTRIBUTES(plane));
+ l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
+ l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
+ dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), l);
+
return r;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index bd7c5cf..c49c054 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -483,7 +483,7 @@ void dispc_mgr_setup(enum omap_channel channel,
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
- const struct omap_video_timings *timings);
+ bool mem_to_mem, const struct omap_video_timings *timings);
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
--
1.7.9.5
^ permalink raw reply related
* [PATCH 19/21] OMAPDSS: DISPC: Configure writeback FIFOs
From: Archit Taneja @ 2012-09-13 12:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1347538505-25359-1-git-send-email-archit@ti.com>
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a44cbac..6068271 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -997,7 +997,7 @@ void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
static void dispc_plane_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
{
- static const unsigned shifts[] = { 6, 14, 14, 14, };
+ static const unsigned shifts[] = { 6, 14, 14, 14, 14, };
int shift;
shift = shifts[plane];
@@ -1229,6 +1229,14 @@ void dispc_plane_compute_fifo_thresholds(enum omap_plane plane,
if (manual_update && dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
*fifo_low = plane_fifo_size - burst_size * 2;
*fifo_high = total_fifo_size - burst_size;
+ } else if (plane = OMAP_DSS_WB) {
+ /*
+ * Most optimal configuration for writeback is to push out data
+ * to the interconnect the moment writeback pushes enough pixels
+ * in the FIFO to form a burst
+ */
+ *fifo_low = 0;
+ *fifo_high = burst_size;
} else {
*fifo_low = plane_fifo_size - burst_size;
*fifo_high = total_fifo_size - buf_unit;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 20/21] OMAPDSS: DISPC: Add manager like functions for writeback
From: Archit Taneja @ 2012-09-13 12:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1347538505-25359-1-git-send-email-archit@ti.com>
Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 70 +++++++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 5 +++
2 files changed, 75 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6068271..1623c9b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -535,6 +535,11 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
return mgr_desc[channel].framedone_irq;
}
+u32 dispc_wb_get_framedone_irq(void)
+{
+ return DISPC_IRQ_FRAMEDONEWB;
+}
+
bool dispc_mgr_go_busy(enum omap_channel channel)
{
return mgr_fld_read(channel, DISPC_MGR_FLD_GO) = 1;
@@ -562,6 +567,30 @@ void dispc_mgr_go(enum omap_channel channel)
mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
}
+bool dispc_wb_go_busy(void)
+{
+ return REG_GET(DISPC_CONTROL2, 6, 6) = 1;
+}
+
+void dispc_wb_go(void)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+ bool enable, go;
+
+ enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) = 1;
+
+ if (!enable)
+ return;
+
+ go = REG_GET(DISPC_CONTROL2, 6, 6) = 1;
+ if (go) {
+ DSSERR("GO bit not down for WB\n");
+ return;
+ }
+
+ REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
+}
+
static void dispc_plane_write_firh_reg(enum omap_plane plane, int reg,
u32 value)
{
@@ -2678,6 +2707,47 @@ void dispc_mgr_enable(enum omap_channel channel, bool enable)
BUG();
}
+void dispc_wb_enable(bool enable)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+ struct completion frame_done_completion;
+ bool is_on;
+ int r;
+ u32 irq;
+
+ is_on = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+ irq = DISPC_IRQ_FRAMEDONEWB;
+
+ if (!enable && is_on) {
+ init_completion(&frame_done_completion);
+
+ r = omap_dispc_register_isr(dispc_disable_isr,
+ &frame_done_completion, irq);
+ if (r)
+ DSSERR("failed to register FRAMEDONEWB isr\n");
+ }
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 0, 0);
+
+ if (!enable && is_on) {
+ if (!wait_for_completion_timeout(&frame_done_completion,
+ msecs_to_jiffies(100)))
+ DSSERR("timeout waiting for FRAMEDONEWB\n");
+
+ r = omap_dispc_unregister_isr(dispc_disable_isr,
+ &frame_done_completion, irq);
+ if (r)
+ DSSERR("failed to unregister FRAMEDONEWB isr\n");
+ }
+}
+
+bool dispc_wb_is_enabled(void)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+
+ return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+}
+
void dispc_lcd_enable_signal_polarity(bool act_high)
{
if (!dss_has_feature(FEAT_LCDENABLEPOL))
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c49c054..59ea86a 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -481,6 +481,11 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
+u32 dispc_wb_get_framedone_irq(void);
+bool dispc_wb_go_busy(void);
+void dispc_wb_go(void);
+void dispc_wb_enable(bool enable);
+bool dispc_wb_is_enabled(void);
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
bool mem_to_mem, const struct omap_video_timings *timings);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 21/21] OMAPDSS: DISPC: Configure color conversion coefficients for writeback
From: Archit Taneja @ 2012-09-13 12:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1347538505-25359-1-git-send-email-archit@ti.com>
Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to convert
the RGB pixels to YUV. The scalar in WB then converts it to the target color
mode.
Hence, the color conversion coefficients that need to be programmed are the ones
which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
pipeline.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1623c9b..5811a18 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -681,20 +681,30 @@ static void dispc_plane_set_scale_coef(enum omap_plane plane, int fir_hinc,
static void _dispc_setup_color_conv_coef(void)
{
int i;
+ int num_ovl = dss_feat_get_num_ovls();
+ int num_wb = dss_feat_get_num_wbs();
+
const struct color_conv_coef {
int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
int full_range;
- } ctbl_bt601_5 = {
- 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
+ } ctbl_bt601_5[2] = {
+ { 298, 409, 0, 298, -208, -100, 298, 0, 517, 0, },
+ { 66, 112, -38, 129, -94, -74, 25, -18, 112, 0, },
};
const struct color_conv_coef *ct;
#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+#define YUVTORGB 0
+#define RGBTOYUV 1
- ct = &ctbl_bt601_5;
+ ct = &ctbl_bt601_5[YUVTORGB];
+
+ for (i = 1; i < num_ovl + num_wb; i++) {
+
+ if (i >= num_ovl)
+ ct = &ctbl_bt601_5[RGBTOYUV];
- for (i = 1; i < dss_feat_get_num_ovls(); i++) {
dispc_write_reg(DISPC_OVL_CONV_COEF(i, 0),
CVAL(ct->rcr, ct->ry));
dispc_write_reg(DISPC_OVL_CONV_COEF(i, 1),
@@ -710,6 +720,8 @@ static void _dispc_setup_color_conv_coef(void)
11, 11);
}
+#undef RGBTOYUV
+#undef YUVTORGB
#undef CVAL
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video: exynos_dp: Add device tree support to DP driver
From: Ajay Kumar @ 2012-09-13 13:24 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, jg1.han, thomas.ab; +Cc: FlorianSchandinat
This patch enables device tree based discovery support for DP driver.
The driver is modified to handle platform data in both the cases:
with DT and non-DT.
DP-PHY should be regarded as a seperate device node while
being passed from device tree list, and device node for
DP should contain DP-PHY as child node with property name "dp-phy"
associated with it.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 156 +++++++++++++++++++++++++++++++--
drivers/video/exynos/exynos_dp_core.h | 2 +
2 files changed, 151 insertions(+), 7 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index f57c915..15887bd 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/of.h>
#include <video/exynos_dp.h>
@@ -856,20 +857,117 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
+#ifdef CONFIG_OF
+struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+{
+ struct device_node *dp_node = dev->of_node;
+ struct exynos_dp_platdata *pd;
+ struct video_info *dp_video_config;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "memory allocation for pdata failed\n");
+ return ERR_PTR(-ENOMEM);
+ }
+ dp_video_config = devm_kzalloc(dev,
+ sizeof(*dp_video_config), GFP_KERNEL);
+
+ if (!dp_video_config) {
+ dev_err(dev, "memory allocation for video config failed\n");
+ return ERR_PTR(-ENOMEM);
+ }
+ pd->video_info = dp_video_config;
+
+ if (of_get_property(dp_node, "samsung,h-sync-polarity", NULL))
+ dp_video_config->h_sync_polarity = 1;
+
+ if (of_get_property(dp_node, "samsung,v-sync-polarity", NULL))
+ dp_video_config->v_sync_polarity = 1;
+
+ if (of_get_property(dp_node, "samsung,interlaced", NULL))
+ dp_video_config->interlaced = 1;
+
+ of_property_read_u32(dp_node, "samsung,color_space",
+ &dp_video_config->color_space);
+
+ of_property_read_u32(dp_node, "samsung,dynamic_range",
+ &dp_video_config->dynamic_range);
+
+ of_property_read_u32(dp_node, "samsung,ycbcr_coeff",
+ &dp_video_config->ycbcr_coeff);
+
+ of_property_read_u32(dp_node, "samsung,color_depth",
+ &dp_video_config->color_depth);
+
+ of_property_read_u32(dp_node, "samsung,link_rate",
+ &dp_video_config->link_rate);
+
+ of_property_read_u32(dp_node, "samsung,lane_count",
+ &dp_video_config->lane_count);
+ return pd;
+}
+
+void exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
+{
+ struct device_node *dp_phy_node;
+
+ const __be32 *parp;
+
+ u32 phy_base;
+
+ void *virt_phy_base;
+
+ parp = of_get_property(dp->dev->of_node, "dp_phy", NULL);
+ if (!parp) {
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+
+ dp_phy_node = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (!dp_phy_node) {
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+
+ of_property_read_u32(dp_phy_node, "samsung,dptx_phy_reg", &phy_base);
+ of_property_read_u32(dp_phy_node, "samsung,enable_bit",
+ &dp->enable_bit);
+ virt_phy_base = ioremap(phy_base, SZ_4);
+ if (!virt_phy_base) {
+ dev_err(dp->dev, "failed to ioremap dp-phy\n");
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+ dp->dp_phy_addr = virt_phy_base;
+}
+
+void dp_phy_init(struct exynos_dp_device *dp)
+{
+ u32 reg;
+
+ reg = __raw_readl(dp->dp_phy_addr);
+ reg |= dp->enable_bit;
+ __raw_writel(reg, dp->dp_phy_addr);
+}
+
+void dp_phy_exit(struct exynos_dp_device *dp)
+{
+ u32 reg;
+
+ reg = __raw_readl(dp->dp_phy_addr);
+ reg &= ~(dp->enable_bit);
+ __raw_writel(reg, dp->dp_phy_addr);
+}
+#endif /* CONFIG_OF */
+
static int __devinit exynos_dp_probe(struct platform_device *pdev)
{
struct resource *res;
struct exynos_dp_device *dp;
- struct exynos_dp_platdata *pdata;
+ struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
int ret = 0;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "no platform data\n");
- return -EINVAL;
- }
-
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
if (!dp) {
@@ -879,6 +982,19 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
dp->dev = &pdev->dev;
+ if (pdev->dev.of_node) {
+ pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+
+ exynos_dp_dt_parse_phydata(dp);
+ }
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -EINVAL;
+ }
+
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
@@ -909,9 +1025,13 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
}
dp->video_info = pdata->video_info;
if (pdata->phy_init)
pdata->phy_init();
+ if (pdev->dev.of_node)
+ if (dp->dp_phy_addr)
+ dp_phy_init(dp);
+
exynos_dp_init_dp(dp);
ret = exynos_dp_detect_hpd(dp);
@@ -956,6 +1077,10 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
if (pdata && pdata->phy_exit)
pdata->phy_exit();
+ if (pdev->dev.of_node)
+ if (dp->dp_phy_addr)
+ dp_phy_exit(dp);
+
clk_disable(dp->clock);
return 0;
@@ -971,6 +1096,10 @@ static int exynos_dp_suspend(struct device *dev)
if (pdata && pdata->phy_exit)
pdata->phy_exit();
+ if (dev->of_node)
+ if (dp->dp_phy_addr)
+ dp_phy_exit(dp);
+
clk_disable(dp->clock);
return 0;
@@ -985,6 +1114,10 @@ static int exynos_dp_resume(struct device *dev)
if (pdata && pdata->phy_init)
pdata->phy_init();
+ if (dev->of_node)
+ if (dp->dp_phy_addr)
+ dp_phy_init(dp);
+
clk_enable(dp->clock);
exynos_dp_init_dp(dp);
@@ -1013,6 +1146,14 @@ static const struct dev_pm_ops exynos_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
};
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_dp_match[] = {
+ { .compatible = "samsung,exynos5-dp" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_match);
+#endif
+
static struct platform_driver exynos_dp_driver = {
.probe = exynos_dp_probe,
.remove = __devexit_p(exynos_dp_remove),
@@ -1020,6 +1161,7 @@ static struct platform_driver exynos_dp_driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
.pm = &exynos_dp_pm_ops,
+ .of_match_table = of_match_ptr(exynos_dp_match),
},
};
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 57b8a65..49b30cb 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -29,6 +29,8 @@ struct exynos_dp_device {
struct clk *clock;
unsigned int irq;
void __iomem *reg_base;
+ void __iomem *dp_phy_addr;
+ int enable_bit;
struct video_info *video_info;
struct link_train link_train;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
From: Stephen Warren @ 2012-09-13 15:24 UTC (permalink / raw)
To: Mark Brown
Cc: Alex Courbot, linux-fbdev@vger.kernel.org, Stephen Warren,
linux-pm@vger.kernel.org, Leela Krishna Amudala,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring, Anton Vorontsov, Tomi Valkeinen,
linux-tegra@vger.kernel.org, David Woodhouse,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20120913072943.GB20959@opensource.wolfsonmicro.com>
On 09/13/2012 01:29 AM, Mark Brown wrote:
> On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote:
>> On Thursday 13 September 2012 15:19:30 Mark Brown wrote:
>>>> On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
>>>>> It would be sensible to make sure that the framework is done in such a
>>>>> way that drivers can use it - there will be drivers (perhaps not display
>>>>> ones) that have a known power sequence and which could benefit from the
>>>>> ability to use library code to implement it based on the user simply
>>>>> supplying named resources.
>
>>>> Not sure I understand what you mean, but things should be working this way
>>>> already - regulators and PWMs are acquired by name using the standard
>>>> regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way
>>>> to be referenced by name so their number is used instead.
>
>>> Right, but the sequencing for enabling them is currently open coded in
>>> each driver.
>
>> Mmm then I'm afraid I don't see what you wanted to say initially - could you
>> elaborate?
>
> The driver knows the power sequence. Having to type the same sequence
> into the DT or platform data for each board using the device wouuld be
> retarded so we need the drivers to be able to give the sequence to the
> library if they're going to be able to reuse it (which is a lot of what
> Tomi is talking about).
I believe that's trivial to implement. The relevant function is:
struct power_seq_set *devm_power_seq_set_build(struct device *dev,
struct platform_power_seq_set *pseq);
It's up to the driver whether pseq comes from platform data or is
hard-coded into the driver (or not provided at all, for the DT case).
So, the only change needed to convert a "hard-coded" driver to this API
is to convert the current custom data structure (or code) that describes
the sequence into a struct platform_power_seq_set.
^ permalink raw reply
* Re: [PATCH v6 1/4] Runtime Interpreted Power Sequences
From: Stephen Warren @ 2012-09-13 15:37 UTC (permalink / raw)
To: Alex Courbot
Cc: Tomi Valkeinen, Stephen Warren, Thierry Reding, Simon Glass,
Grant Likely, Rob Herring, Mark Brown, Anton Vorontsov,
David Woodhouse, Arnd Bergmann, Leela Krishna Amudala,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-pm@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <3082244.Oec3ulPCgi@percival>
On 09/13/2012 01:08 AM, Alex Courbot wrote:
> On Thursday 13 September 2012 14:54:09 Tomi Valkeinen wrote:
>> * PGP Signed by an unknown key
>>
>> On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
>>
>>> On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
>>>
>>>
>>>
>>>> However, I fear these board specific things may be quite a bit
>>>> anything,
>>>> so it may well be pwm, gpios and regulators are not enough for them.
>>>> For
>>>> example, there could be an FPGA on the board which requires some
>>>> configuration to accomplish the task at hand. It could be rather
>>>> difficult to handle it with a generic power sequence.
>>>
>>>
>>> Right. Note that this framework is supposed to be extended - I would like
>>> to at least add regulator voltage setting, and maybe even support for
>>> clocks and pinmux (but that might be out of place).
>>
>>
>> Yes, that's one concern of mine... I already can imagine someone
>> suggesting adding conditionals to the power sequence data.
>
> I took care of that when naming the feature - it is not a "sequence" anymore
> if you have conditionals. :P
>
>> Perhaps also
>> direct memory read/writes so you can twiddle registers directly. And so
>> on. Where's the limit what it should contain? Can we soon write full
>> drivers with the DT data? =)
>
> I shall be satisfied the day the kernel is released as one big DT node along
> with the 5KB interpreter that runs it.
I know you're joking, but *cough* OpenFirmware *cough*, right?
^ permalink raw reply
* Re: [PATCH v6 1/4] Runtime Interpreted Power Sequences
From: Stephen Warren @ 2012-09-13 15:44 UTC (permalink / raw)
To: Alex Courbot
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Brown,
Stephen Warren, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Leela Krishna Amudala,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Anton Vorontsov,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Woodhouse,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <3678448.5nUOr4ZZV4@percival>
On 09/13/2012 12:02 AM, Alex Courbot wrote:
> On Thursday 13 September 2012 06:07:13 Stephen Warren wrote:
>> On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
>>> Some device drivers (panel backlights especially) need to follow precise
>>> sequences for powering on and off, involving gpios, regulators, PWMs
>>> with a precise powering order and delays to respect between each steps.
>>> These sequences are board-specific, and do not belong to a particular
>>> driver - therefore they have been performed by board-specific hook
>>> functions to far.
>>>
>>> With the advent of the device tree and of ARM kernels that are not
>>> board-tied, we cannot rely on these board-specific hooks anymore but
>>> need a way to implement these sequences in a portable manner. This patch
>>> introduces a simple interpreter that can execute such power sequences
>>> encoded either as platform data or within the device tree.
>>>
>>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>>>
>>> diff --git a/Documentation/power/power_seq.txt
>>> b/Documentation/power/power_seq.txt
>>>
>>> +Sometimes, you may want to browse the list of resources allocated by a
>>> sequence, +for instance to ensure that a resource of a given type is
>>> present. The +power_seq_set_resources() function returns a list head that
>>> can be used with +the power_seq_for_each_resource() macro to browse all
>>> the resources of a set: +
>>> + struct list_head *power_seq_set_resources(struct power_seq_set *seqs);
>>> + power_seq_for_each_resource(pos, seqs)
>>> +
>>> +Here "pos" will be a pointer to a struct power_seq_resource. This
>>> structure +contains the type of the resource, the information used for
>>> identifying it, and +the resolved resource itself.
>>
>> I don't think you need to include that [power_seq_set_resources] prototype
>> here?
>
> Why not? I thought it was customary to include the prototypes in the
> documentation, and this seems to be the right place for this function.
It's something used internally to the macro; what the user cares about
is which macro to use for the functionality you're describing, not any
prototypes needed by the internal implementation of the macro, which are
always provided by the appropriate header.
>>> diff --git a/drivers/power/power_seq/power_seq.c
>>> b/drivers/power/power_seq/power_seq.c
>>>
>>> +struct power_seq_step {
>>> + /* Copy of the platform data */
>>> + struct platform_power_seq_step pdata;
>>
>> I'd reword the comment to "Copy of the step", and name the field "step".
>
> That would make a step within a step - doesn't pdata make it more explicit
> what this member is for (containing the platform data for this step)?
Well, it's not always platform data; it could come from device tree.
Sorry for bike-shedding slightly, but how about just "data",
"step_data", "config", or "step_config"?
>>> +static const struct power_seq_res_ops
>>> power_seq_types[POWER_SEQ_NUM_TYPES] = { + [POWER_SEQ_DELAY] >>> POWER_SEQ_DELAY_TYPE,
>>> + [POWER_SEQ_REGULATOR] = POWER_SEQ_REGULATOR_TYPE,
>>> + [POWER_SEQ_PWM] = POWER_SEQ_PWM_TYPE,
>>> + [POWER_SEQ_GPIO] = POWER_SEQ_GPIO_TYPE,
>>> +};
>>
>> Ah, I see why you're using #include now.
>
> We could also go with something more dynamic and compile these files
> separately, but that would require some registration mechanism which I don't
> think is needed for such a simple feature.
Sure. There are already examples in the kernel of basically what you're
doing anyway, and it's not like it'd be hard to change this if we want
to do something different in the future too.
^ permalink raw reply
* Re: [PATCH 2/5] drivers/video/gbefb.c: use devm_ functions
From: Geert Uytterhoeven @ 2012-09-13 19:06 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Damien Cassou, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <50369498.4010006@gmx.de>
On Thu, Aug 23, 2012 at 10:37 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 07/31/2012 04:39 PM, Damien Cassou wrote:
>> From: Damien Cassou <damien.cassou@lifl.fr>
>>
>> The various devm_ functions allocate memory that is released when a driver
>> detaches. This patch uses these functions for data that is allocated in
>> the probe function of a platform device and is only freed in the remove
>> function.
>>
>> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
>
> Applied.
>> diff --git a/drivers/video/gbefb.c b/drivers/video/gbefb.c
>> index 7e7b7a9..9b79d38 100644
>> --- a/drivers/video/gbefb.c
>> +++ b/drivers/video/gbefb.c
>> @@ -1156,7 +1156,8 @@ static int __devinit gbefb_probe(struct platform_device *p_dev)
>> goto out_release_framebuffer;
>> }
>>
>> - gbe = (struct sgi_gbe *) ioremap(GBE_BASE, sizeof(struct sgi_gbe));
>> + gbe = (struct sgi_gbe *) devm_ioremap(&p_dev->dev, GBE_BASE,
>> + sizeof(struct sgi_gbe));
drivers/video/gbefb.c:1159:16: error: implicit declaration of function
'devm_ioremap' [-Werror=implicit-function-declaration]
drivers/video/gbefb.c:1179:3: error: implicit declaration of function
'devm_ioremap_nocache' [-Werror=implicit-function-declaration]
http://kisskb.ellerman.id.au/kisskb/buildresult/7187731/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC 1/5] video: Add generic display panel core
From: Robert Schwebel @ 2012-09-13 19:32 UTC (permalink / raw)
To: Sascha Hauer
Cc: Laurent Pinchart, linux-fbdev, Marcus Lorentzon, dri-devel,
Kyungmin Park, Richard Purdie, Sebastien Guiriec, Bryan Wu,
linux-leds, linux-media, Steffen Trumtrar
In-Reply-To: <20120913112954.GI6180@pengutronix.de>
On Thu, Sep 13, 2012 at 01:29:54PM +0200, Sascha Hauer wrote:
> > > You have seen my of videomode helper proposal. One result there
> > > was that we want to have ranges for the margin/synclen fields.
> > > Does it make sense to base this new panel framework on a more
> > > sophisticated internal reprentation of the panel parameters?
> >
> > I think it does, yes. We need a common video mode structure, and the
> > panel framework should use it. I'll try to rebase my patches on top
> > of your proposal. Have you posted the latest version ?
>
> V2 is the newest version. I'd like to implement ranges for the display
> timings which then makes for a new common video mode structure, which
> then could be used by drm and fbdev, probably with helper functions to
> convert from common videomode to drm/fbdev specific variants.
Steffen has a reworked series with the latest changes and will post them
soon.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv3 1/4] video: mmp display subsystem
From: Zhou Zhu @ 2012-09-14 2:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347007704-27645-1-git-send-email-zzhu3@marvell.com>
Hi, Florian,
Would you please help to review my patches?
Thank you very much!
On Fri, Sep 7, 2012 at 4:48 PM, Zhou Zhu <zzhu3@marvell.com> wrote:
> Added mmp display subsystem to support Marvell MMP display controllers.
>
> This subsystem contains 4 parts:
> --fb folder
> --core.c
> --hw folder
> --panel folder
>
> 1. fb folder contains implementation of fb.
> fb get path and ovly from common interface and operates on these structures.
>
> 2. core.c provides common interface for a hardware abstraction.
> Major parts of this interface are:
> a) Path: path is a output device connected to a panel or HDMI TV.
> Main operations of the path is set/get timing/output color.
> fb operates output device through path structure.
> b) Ovly: Ovly is a buffer shown on the path.
> Ovly describes frame buffer and its source/destination size, offset, input
> color, buffer address, z-order, and so on.
> Each fb device maps to one ovly.
>
> 3. hw folder contains implementation of hardware operations defined by core.c.
> It registers paths for fb use.
>
> 4. panel folder contains implementation of panels.
> It's connected to path. Panel drivers would also regiester panels and linked
> to path when probe.
>
> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> Signed-off-by: Lisa Du <cldu@marvell.com>
Thanks,
-Zhou
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 8:27 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347538505-25359-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other
> pipelines(called overlays in OMAPDSS), writeback takes pixel data from an
> overlay output or a overlay manager output and writes it back into a specified
> address in memory.
>
> writeback pipeline allows us to take benefit of the hardware processing
> available inside the DISPC like color space conversion, rescaling, compositing
> etc and do either a) perform memory-to-memory transfer with data processing,
> b) capture a displayed frame. The former is known as memory to memory mode of
> the writeback pipeline, and the latter is known as capture mode. More details
> about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs.
>
> witeback has properties of both overlays and overlay managers. It is like an
> overlay as it has programmable base addresses and contains blocks like scalar,
You consistently use the term "scalar" in the patches, but I believe the
correct term is "scaler".
> color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as
> enabling it immediately starts transfer to the memory, and it has a GO bit to use
> a new writeback configuration.
>
> This series prepares the low level DISPC driver(dispc.c) to configure writeback
> registers. The aim is to reuse most of the code as most of its registers are
> like overlay or manager registers, and are configured in the same way in most
> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
I'm not sure if the renaming causes more confusion than clarity... It
kinda creates a mishmash of ovl/plane names, and the term "plane"
doesn't really sound like it's a base for both overlays and wb. Could we
consider the wb as a special case, and keep the ovl name for most of the
things and have "wb" used for wb specific things?
> functions. The next few patches change how overlay caps are used within the
> dispc functions, this helps reusing more functions between overlays and
I dislike this a bit, I think dispc driver should know what HW it has,
you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
to have this information in dispc_features. I believe all OVL_CAPS
should be there, and then exported to other drivers via some means. I
guess this means could for now be just initializing ovl->caps with data
from dispc.c.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 8:46 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347611263.2559.44.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> > This series prepares the low level DISPC driver(dispc.c) to configure writeback
> > registers. The aim is to reuse most of the code as most of its registers are
> > like overlay or manager registers, and are configured in the same way in most
> > cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>
> I'm not sure if the renaming causes more confusion than clarity... It
> kinda creates a mishmash of ovl/plane names, and the term "plane"
> doesn't really sound like it's a base for both overlays and wb. Could we
> consider the wb as a special case, and keep the ovl name for most of the
> things and have "wb" used for wb specific things?
And while WB is a combination of overlays and ovl managers, do you think
it'd be difficult to consider WB as a special, extended overlay? So just
call it an overlay, and consider it as an overlay with special features,
at least inside dispc.c. We probably need to have it as a totally
different entity from user's point of view (i.e. the list of overlays
wouldn't return WB, etc).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 8:53 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347538505-25359-10-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> Scaling calculations for an overlay are done by comparing pixel clock of the
> connected overlay manager and the core clock of DISPC. The pixel clock is the
> output rate of the scalar. The scalar block needs to provide pixels at this rate
> since the manager is connected to a panel, which has real time constraints.
>
> In the case of writeback in memory to memory mode, the output of the scalar
> blocks aren't connected to a display, and hence there isn't a pixel clock which
> causes downscaling limitations.
>
> Make the input to scaling calculations a bit more generic by passing the scalar
> output rate rather than passing pixel clock of the overlay manager connected to
> the pipeline, as we now have use cases where the scalar's output may not go to
> a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Or was there some other reason for the rename, that I missed?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 21/21] OMAPDSS: DISPC: Configure color conversion coefficients for writeback
From: Tomi Valkeinen @ 2012-09-14 9:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347538505-25359-22-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
On Thu, 2012-09-13 at 17:45 +0530, Archit Taneja wrote:
> Writeback pipeline receives RGB data from one of the overlays or one of the
> overlay managers. If the target color mode is YUV422 or NV12, we need to convert
> the RGB pixels to YUV. The scalar in WB then converts it to the target color
> mode.
>
> Hence, the color conversion coefficients that need to be programmed are the ones
> which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
> pipeline.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 1623c9b..5811a18 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -681,20 +681,30 @@ static void dispc_plane_set_scale_coef(enum omap_plane plane, int fir_hinc,
> static void _dispc_setup_color_conv_coef(void)
> {
> int i;
> + int num_ovl = dss_feat_get_num_ovls();
> + int num_wb = dss_feat_get_num_wbs();
> +
> const struct color_conv_coef {
> int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
> int full_range;
> - } ctbl_bt601_5 = {
> - 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
> + } ctbl_bt601_5[2] = {
> + { 298, 409, 0, 298, -208, -100, 298, 0, 517, 0, },
> + { 66, 112, -38, 129, -94, -74, 25, -18, 112, 0, },
> };
>
> const struct color_conv_coef *ct;
>
> #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> +#define YUVTORGB 0
> +#define RGBTOYUV 1
>
> - ct = &ctbl_bt601_5;
> + ct = &ctbl_bt601_5[YUVTORGB];
> +
> + for (i = 1; i < num_ovl + num_wb; i++) {
> +
> + if (i >= num_ovl)
> + ct = &ctbl_bt601_5[RGBTOYUV];
>
> - for (i = 1; i < dss_feat_get_num_ovls(); i++) {
> dispc_write_reg(DISPC_OVL_CONV_COEF(i, 0),
> CVAL(ct->rcr, ct->ry));
> dispc_write_reg(DISPC_OVL_CONV_COEF(i, 1),
This looks a bit funny. I'd suggest to take the actual register writes
to a separate function, and have a separate tables for ovls and wb, and
have two for loops, first for ovls and then for wbs.
Btw, I wonder if we could consider WB as a single special entity, i.e.
no need for "num_wbs" or such. I know things may change in the future
HW, but I got the impression that adding overlays to DSS is costly, and
single WB is enough.
Then again, I'm not sure if handling only single WB would simplify much.
If you think it's no issue to have support for multiple WBs, perhaps we
can have it, just in case.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Archit Taneja @ 2012-09-14 9:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347612788.2559.57.camel@deskari>
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>> Scaling calculations for an overlay are done by comparing pixel clock of the
>> connected overlay manager and the core clock of DISPC. The pixel clock is the
>> output rate of the scalar. The scalar block needs to provide pixels at this rate
>> since the manager is connected to a panel, which has real time constraints.
>>
>> In the case of writeback in memory to memory mode, the output of the scalar
>> blocks aren't connected to a display, and hence there isn't a pixel clock which
>> causes downscaling limitations.
>>
>> Make the input to scaling calculations a bit more generic by passing the scalar
>> output rate rather than passing pixel clock of the overlay manager connected to
>> the pipeline, as we now have use cases where the scalar's output may not go to
>> a manager connected to a panel.
>
> Pixel clock is the rate at which pixels are processed. I don't see it
> only meaning a clock that's related to actual video signal going out of
> OMAP. So if in normal case the scaler outputs pixels at the rate of
> pixel clock, we can call it pixel clock with WB's case also, instead of
> renaming it to output clock.
Pixel clock, in OMAP DSS terms, is the rate at which the video port of
an overlay manager provides pixels to an output. It is a fixed rate at
which the scaler needs to push out data.
If we stick to this terminology of pixel clock, I don't think it applies
to writeback. As far as I see it, there is no specific rate at which the
scaler outputs data, it adjusts itself based on how much scaling is
done, and at the rate we can get/push data to the interconnect. That's
why I didn't want to call it pixel clock. Because, that sounds a lot
like a fixed rate at which pixels need to be output.
>
> Or was there some other reason for the rename, that I missed?
The main aim of this patch was to pass pixel clock rate/or output rate
as an argument to scaler functions, rather than passing the overlay
manager's channel id to calculate this rate. I can rename it to pixel
clock if that seems better.
Archit
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 9:49 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5052F547.9090102@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]
On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> >> Scaling calculations for an overlay are done by comparing pixel clock of the
> >> connected overlay manager and the core clock of DISPC. The pixel clock is the
> >> output rate of the scalar. The scalar block needs to provide pixels at this rate
> >> since the manager is connected to a panel, which has real time constraints.
> >>
> >> In the case of writeback in memory to memory mode, the output of the scalar
> >> blocks aren't connected to a display, and hence there isn't a pixel clock which
> >> causes downscaling limitations.
> >>
> >> Make the input to scaling calculations a bit more generic by passing the scalar
> >> output rate rather than passing pixel clock of the overlay manager connected to
> >> the pipeline, as we now have use cases where the scalar's output may not go to
> >> a manager connected to a panel.
> >
> > Pixel clock is the rate at which pixels are processed. I don't see it
> > only meaning a clock that's related to actual video signal going out of
> > OMAP. So if in normal case the scaler outputs pixels at the rate of
> > pixel clock, we can call it pixel clock with WB's case also, instead of
> > renaming it to output clock.
>
> Pixel clock, in OMAP DSS terms, is the rate at which the video port of
> an overlay manager provides pixels to an output. It is a fixed rate at
> which the scaler needs to push out data.
>
> If we stick to this terminology of pixel clock, I don't think it applies
> to writeback. As far as I see it, there is no specific rate at which the
> scaler outputs data, it adjusts itself based on how much scaling is
> done, and at the rate we can get/push data to the interconnect. That's
> why I didn't want to call it pixel clock. Because, that sounds a lot
> like a fixed rate at which pixels need to be output.
I see your reasoning. I'm a bit reluctant to add a new clock term to
omapdss. You can't (probably) find it in the TRM. Does the TRM talk
about clocks with regard to WB?
I do think pixel clock can be used as well here. While normally used for
output, it's just a clock used for pixels, and at each tick we process
one pixel, which is exactly what happens with WB also.
Also, if I understood right, this pixel clock is not even used for WB,
and in a later patch you just use a dummy value of 1 for the clock for
WB. So even if pixel clock would not be the best name, would it make
sense to use the name of pixel clock, but return 0 as the pck for WB,
implying that pck is not valid/does not exist, and the scaling
restrictions can be skipped for that?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Archit Taneja @ 2012-09-14 10:15 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347616145.2559.70.camel@deskari>
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
> On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
>> On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
>>> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>>>> Scaling calculations for an overlay are done by comparing pixel clock of the
>>>> connected overlay manager and the core clock of DISPC. The pixel clock is the
>>>> output rate of the scalar. The scalar block needs to provide pixels at this rate
>>>> since the manager is connected to a panel, which has real time constraints.
>>>>
>>>> In the case of writeback in memory to memory mode, the output of the scalar
>>>> blocks aren't connected to a display, and hence there isn't a pixel clock which
>>>> causes downscaling limitations.
>>>>
>>>> Make the input to scaling calculations a bit more generic by passing the scalar
>>>> output rate rather than passing pixel clock of the overlay manager connected to
>>>> the pipeline, as we now have use cases where the scalar's output may not go to
>>>> a manager connected to a panel.
>>>
>>> Pixel clock is the rate at which pixels are processed. I don't see it
>>> only meaning a clock that's related to actual video signal going out of
>>> OMAP. So if in normal case the scaler outputs pixels at the rate of
>>> pixel clock, we can call it pixel clock with WB's case also, instead of
>>> renaming it to output clock.
>>
>> Pixel clock, in OMAP DSS terms, is the rate at which the video port of
>> an overlay manager provides pixels to an output. It is a fixed rate at
>> which the scaler needs to push out data.
>>
>> If we stick to this terminology of pixel clock, I don't think it applies
>> to writeback. As far as I see it, there is no specific rate at which the
>> scaler outputs data, it adjusts itself based on how much scaling is
>> done, and at the rate we can get/push data to the interconnect. That's
>> why I didn't want to call it pixel clock. Because, that sounds a lot
>> like a fixed rate at which pixels need to be output.
>
> I see your reasoning. I'm a bit reluctant to add a new clock term to
> omapdss. You can't (probably) find it in the TRM. Does the TRM talk
> about clocks with regard to WB?
Yes, you can't find the word pixel clock linked to WB in the TRM.
>
> I do think pixel clock can be used as well here. While normally used for
> output, it's just a clock used for pixels, and at each tick we process
> one pixel, which is exactly what happens with WB also.
>
> Also, if I understood right, this pixel clock is not even used for WB,
> and in a later patch you just use a dummy value of 1 for the clock for
> WB. So even if pixel clock would not be the best name, would it make
> sense to use the name of pixel clock, but return 0 as the pck for WB,
> implying that pck is not valid/does not exist, and the scaling
> restrictions can be skipped for that?
Yes, we could do that. I can check if zero leads to some bad results, or
we could just bypass the scaler clock stuff if the pixel clock is 0.
Archit
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 10:18 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <505300FC.3020706@ti.com>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Fri, 2012-09-14 at 15:33 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
> > I see your reasoning. I'm a bit reluctant to add a new clock term to
> > omapdss. You can't (probably) find it in the TRM. Does the TRM talk
> > about clocks with regard to WB?
>
> Yes, you can't find the word pixel clock linked to WB in the TRM.
Is there some other term for the clock related to WB?
> Yes, we could do that. I can check if zero leads to some bad results, or
> we could just bypass the scaler clock stuff if the pixel clock is 0.
I think 0 value would make more sense than a dummy 1. 1 is still a valid
clock, and it could go unnoticed in some other code paths that would use
the function to get the clock.
Of course, the scaler check function could internally check if the pck
is 0, and then use 1 in its calculations, if that makes the function
simpler.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Archit Taneja @ 2012-09-14 10:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347611263.2559.44.camel@deskari>
On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>> DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other
>> pipelines(called overlays in OMAPDSS), writeback takes pixel data from an
>> overlay output or a overlay manager output and writes it back into a specified
>> address in memory.
>>
>> writeback pipeline allows us to take benefit of the hardware processing
>> available inside the DISPC like color space conversion, rescaling, compositing
>> etc and do either a) perform memory-to-memory transfer with data processing,
>> b) capture a displayed frame. The former is known as memory to memory mode of
>> the writeback pipeline, and the latter is known as capture mode. More details
>> about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs.
>>
>> witeback has properties of both overlays and overlay managers. It is like an
>> overlay as it has programmable base addresses and contains blocks like scalar,
>
> You consistently use the term "scalar" in the patches, but I believe the
> correct term is "scaler".
Yes, my bad, I'll fix this.
>
>> color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as
>> enabling it immediately starts transfer to the memory, and it has a GO bit to use
>> a new writeback configuration.
>>
>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
>> registers. The aim is to reuse most of the code as most of its registers are
>> like overlay or manager registers, and are configured in the same way in most
>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>
> I'm not sure if the renaming causes more confusion than clarity... It
> kinda creates a mishmash of ovl/plane names, and the term "plane"
> doesn't really sound like it's a base for both overlays and wb. Could we
> consider the wb as a special case, and keep the ovl name for most of the
> things and have "wb" used for wb specific things?
I initially kept all of this the same, but I changed my mind at some
point, not totally sure why. Even if we stick to the dispc_ovl_* names,
we would still need to create q common function which dispc_ovl_setup()
and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
then it felt weird to call everything else ovl specifuic, hence renamed
all of them to dispc_plane_*.
Could you suggest a better name than dispc_plane_setup?
>
>> functions. The next few patches change how overlay caps are used within the
>> dispc functions, this helps reusing more functions between overlays and
>
> I dislike this a bit, I think dispc driver should know what HW it has,
> you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
> to have this information in dispc_features. I believe all OVL_CAPS
> should be there, and then exported to other drivers via some means. I
> guess this means could for now be just initializing ovl->caps with data
> from dispc.c.
Currently, we pass the plane id to these low level functions, it
extracts out the ovl struct usingthe plane id, and checks the ovl caps.
What I'm doing now is just passing the caps directly to these low level
functions. So that I don't need to have complicated checks in every
function to extract caps between overlays or writeback.
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Archit Taneja @ 2012-09-14 10:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347612392.2559.54.camel@deskari>
On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
> On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
>> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>
>>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
>>> registers. The aim is to reuse most of the code as most of its registers are
>>> like overlay or manager registers, and are configured in the same way in most
>>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>>
>> I'm not sure if the renaming causes more confusion than clarity... It
>> kinda creates a mishmash of ovl/plane names, and the term "plane"
>> doesn't really sound like it's a base for both overlays and wb. Could we
>> consider the wb as a special case, and keep the ovl name for most of the
>> things and have "wb" used for wb specific things?
>
> And while WB is a combination of overlays and ovl managers, do you think
> it'd be difficult to consider WB as a special, extended overlay? So just
> call it an overlay, and consider it as an overlay with special features,
> at least inside dispc.c. We probably need to have it as a totally
> different entity from user's point of view (i.e. the list of overlays
> wouldn't return WB, etc).
Yes, we could do that within dispc.c, we would still need some manager
like functions which set GO or ENABLE. But apart from that it should be
okay.
I think for dispc.c in general, for future, it might be a good idea to
represent each piece of HW(like scalar or color converter, or a timing
FSM) as a little function/module, and construct
overlay/writeback/manager out of those, it might be cleaner. However,
this may be an overkill, and not needed much if there aren't any new
blocks comprising of these little blocks.
Archit
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 10:53 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50530367.5030303@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
On Fri, 2012-09-14 at 15:43 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
> I initially kept all of this the same, but I changed my mind at some
> point, not totally sure why. Even if we stick to the dispc_ovl_* names,
> we would still need to create q common function which dispc_ovl_setup()
> and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
> then it felt weird to call everything else ovl specifuic, hence renamed
> all of them to dispc_plane_*.
>
> Could you suggest a better name than dispc_plane_setup?
Well... dispc_ovl_setup_common?
The function is also quite big, with huge number of arguments. Makes me
wonder if we could split it up to some sensible parts. Would it be
possible to have functions to setup, say, input related parameters
(base-address, pix format, etc.), output related parameters (ovl
position, ...).
Well, it could just make it more confusing, as some things are shared
between input and output, like scaling related things. But just an idea.
>
> >
> >> functions. The next few patches change how overlay caps are used within the
> >> dispc functions, this helps reusing more functions between overlays and
> >
> > I dislike this a bit, I think dispc driver should know what HW it has,
> > you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
> > to have this information in dispc_features. I believe all OVL_CAPS
> > should be there, and then exported to other drivers via some means. I
> > guess this means could for now be just initializing ovl->caps with data
> > from dispc.c.
>
> Currently, we pass the plane id to these low level functions, it
> extracts out the ovl struct usingthe plane id, and checks the ovl caps.
>
> What I'm doing now is just passing the caps directly to these low level
> functions. So that I don't need to have complicated checks in every
> function to extract caps between overlays or writeback.
Yep, I see. It's ok.
My main dislike is the use of omap_dss_get_overlay() in dispc.c. I'd
like dispc.c to be self-contained, so what I mean is that instead of
initializing the caps in dss_features.c, and calling the above function
in dispc.c, we should have a dispc.c internal table for dispc's HW,
which would contain the caps and other necessary information.
But that's not really related to this series.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 10:57 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <505305F2.4000602@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]
On Fri, 2012-09-14 at 15:54 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
> > On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
> >> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> >
> >>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
> >>> registers. The aim is to reuse most of the code as most of its registers are
> >>> like overlay or manager registers, and are configured in the same way in most
> >>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
> >>
> >> I'm not sure if the renaming causes more confusion than clarity... It
> >> kinda creates a mishmash of ovl/plane names, and the term "plane"
> >> doesn't really sound like it's a base for both overlays and wb. Could we
> >> consider the wb as a special case, and keep the ovl name for most of the
> >> things and have "wb" used for wb specific things?
> >
> > And while WB is a combination of overlays and ovl managers, do you think
> > it'd be difficult to consider WB as a special, extended overlay? So just
> > call it an overlay, and consider it as an overlay with special features,
> > at least inside dispc.c. We probably need to have it as a totally
> > different entity from user's point of view (i.e. the list of overlays
> > wouldn't return WB, etc).
>
> Yes, we could do that within dispc.c, we would still need some manager
> like functions which set GO or ENABLE. But apart from that it should be
> okay.
Yep, I was going through the WB registers, and to me it looks like 99%
of them are like overlay regs. Then there are a few bits like GO which
are special.
> I think for dispc.c in general, for future, it might be a good idea to
> represent each piece of HW(like scalar or color converter, or a timing
Scal_e_r! ;)
> FSM) as a little function/module, and construct
> overlay/writeback/manager out of those, it might be cleaner. However,
> this may be an overkill, and not needed much if there aren't any new
> blocks comprising of these little blocks.
I agree. In the minimum we should try to somehow group functions related
to certain block, perhaps with name prefixes etc. I think it'll also
help understanding the code.
We probably currently have functions that touch multiple different
blocks. Those funcs should be split to handle only one of the blocks.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v3] of: Add videomode helper
From: Steffen Trumtrar @ 2012-09-14 16:24 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Steffen Trumtrar,
Sascha Hauer, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Hi!
The original patch was done by Sascha Hauer. I reworked his v2 a "little" bit.
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (<min,typ,max>)
- functions to get display_mode or fb_videomode
Regards,
Steffen
.../devicetree/bindings/video/displaymode | 74 ++++++
drivers/of/Kconfig | 5 +
drivers/of/Makefile | 1 +
drivers/of/of_videomode.c | 236 ++++++++++++++++++++
include/linux/of_videomode.h | 56 +++++
5 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/displaymode
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/Documentation/devicetree/bindings/video/displaymode b/Documentation/devicetree/bindings/video/displaymode
new file mode 100644
index 0000000..990ca52
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,74 @@
+videomode bindings
+=========
+
+Required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree representation
+corresponds to the one commonly found in datasheets for displays.
+The description of the display and its mode is split in two parts: first the display
+properties like size in mm and (optionally) multiple subnodes with the supported modes.
+
+Example:
+
+ display@0 {
+ width-mm = <800>;
+ height-mm = <480>;
+ modes {
+ mode0: mode@0 {
+ /* 1920x1080p24 */
+ clock = <52000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active-high;
+ };
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used datasheet
+description with <min typ max>-tuples can be used.
+
+Example:
+
+ mode1: mode@1 {
+ /* 1920x1080p24 */
+ clock = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <0 44 60>;
+ hfront-porch = <80 88 95>;
+ hback-porch = <100 148 160>;
+ vfront-porch = <0 4 6>;
+ vback-porch = <0 36 50>;
+ vsync-len = <0 5 6>;
+ };
+
+The videomode can be linked to a connector via phandles. The connector has to
+support the display- and default-mode-property to link to and select a mode.
+
+Example:
+
+ hdmi@00120000 {
+ status = "okay";
+ display = <&benq>;
+ default-mode = <&mode1>;
+ };
+
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..a3acaa3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to parse videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..80e6db3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 0000000..217edf8
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,236 @@
+/*
+ * OF helpers for parsing display modes
+ *
+ * Copyright (c) 2012 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/of.h>
+#include <linux/fb.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+#include <linux/of_videomode.h>
+
+/* FIXME */
+static u32 of_video_get_value(struct mode_property *prop)
+{
+ return (prop->min >= prop->typ) ? prop->min : prop->typ;
+}
+
+/* read property into new mode_property */
+static int of_video_parse_property(struct device_node *np, char *name,
+ struct mode_property *result)
+{
+ struct property *prop;
+ int length;
+ int cells;
+ int ret;
+
+ prop = of_find_property(np, name, &length);
+ if (!prop)
+ return -EINVAL;
+
+ cells = length / sizeof(u32);
+
+ memset(result, 0, sizeof(*result));
+
+ ret = of_property_read_u32_array(np, name, &result->min, cells);
+ of_video_get_value(result);
+ return ret;
+}
+
+int videomode_to_display_mode(struct display *disp, struct drm_display_mode *dmode, int index)
+{
+ struct videomode *vm;
+
+ memset(dmode, 0, sizeof(*dmode));
+
+ if (index > disp->num_modes)
+ return -EINVAL;
+ vm = disp->modes[index];
+
+ dmode->hdisplay = of_video_get_value(&vm->hactive);
+ dmode->hsync_start = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch);
+ dmode->hsync_end = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch)
+ + of_video_get_value(&vm->hsync_len);
+ dmode->htotal = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch)
+ + of_video_get_value(&vm->hsync_len) + of_video_get_value(&vm->hback_porch);
+
+ dmode->vdisplay = of_video_get_value(&vm->vactive);
+ dmode->vsync_start = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch);
+ dmode->vsync_end = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch)
+ + of_video_get_value(&vm->vsync_len);
+ dmode->vtotal = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch) +
+ of_video_get_value(&vm->vsync_len) + of_video_get_value(&vm->vback_porch);
+
+ dmode->width_mm = disp->width_mm;
+ dmode->height_mm = disp->height_mm;
+
+ dmode->clock = of_video_get_value(&vm->clock) / 1000;
+
+ if (vm->hah)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->vah)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->interlaced)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->doublescan)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+
+ drm_mode_set_name(dmode);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_display_mode);
+
+int videomode_to_fb_mode(struct display *disp, struct fb_videomode *fbmode, int index)
+{
+ struct videomode *vm;
+ memset(fbmode, 0, sizeof(*fbmode));
+
+ vm = disp->modes[index];
+
+ fbmode->xres = of_video_get_value(&vm->hactive);
+ fbmode->left_margin = of_video_get_value(&vm->hback_porch);
+ fbmode->right_margin = of_video_get_value(&vm->hfront_porch);
+ fbmode->hsync_len = of_video_get_value(&vm->hsync_len);
+
+ fbmode->yres = of_video_get_value(&vm->vactive);
+ fbmode->upper_margin = of_video_get_value(&vm->vback_porch);
+ fbmode->lower_margin = of_video_get_value(&vm->vfront_porch);
+ fbmode->vsync_len = of_video_get_value(&vm->vsync_len);
+
+ fbmode->pixclock = KHZ2PICOS(of_video_get_value(&vm->clock) / 1000);
+
+ if (vm->hah)
+ fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm->vah)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->interlaced)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->doublescan)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_fb_mode);
+
+int of_get_video_mode(struct device_node *np, struct display *disp)
+{
+ struct device_node *display_np;
+ struct device_node *mode_np;
+ struct device_node *modes_np;
+ char *default_mode;
+
+ int ret = 0;
+
+ memset(disp, 0, sizeof(*disp));
+ disp->modes = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
+ if (!np)
+ return -EINVAL;
+
+ display_np = of_parse_phandle(np, "display", 0);
+
+ if (!display_np)
+ return -EINVAL;
+
+ of_property_read_u32(display_np, "width-mm", &disp->width_mm);
+ of_property_read_u32(display_np, "height-mm", &disp->height_mm);
+
+ mode_np = of_parse_phandle(np, "default-mode", 0);
+
+ if (!mode_np)
+ mode_np = of_find_node_by_name(np, "mode");
+
+ if (!mode_np)
+ return -EINVAL;
+
+ default_mode = (char *)mode_np->full_name;
+
+ modes_np = of_find_node_by_name(np, "modes");
+ for_each_child_of_node(modes_np, mode_np) {
+ struct videomode *vm;
+ vm = kmalloc(sizeof(struct videomode), GFP_KERNEL);
+ disp->modes[disp->num_modes] = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
+
+ ret |= of_video_parse_property(mode_np, "hback-porch", &vm->hback_porch);
+ ret |= of_video_parse_property(mode_np, "hfront-porch", &vm->hfront_porch);
+ ret |= of_video_parse_property(mode_np, "hactive", &vm->hactive);
+ ret |= of_video_parse_property(mode_np, "hsync-len", &vm->hsync_len);
+ ret |= of_video_parse_property(mode_np, "vback-porch", &vm->vback_porch);
+ ret |= of_video_parse_property(mode_np, "vfront-porch", &vm->vfront_porch);
+ ret |= of_video_parse_property(mode_np, "vactive", &vm->vactive);
+ ret |= of_video_parse_property(mode_np, "vsync-len", &vm->vsync_len);
+ ret |= of_video_parse_property(mode_np, "clock", &vm->clock);
+
+ if (ret)
+ return -EINVAL;
+
+ vm->hah = of_property_read_bool(mode_np, "hsync-active-high");
+ vm->vah = of_property_read_bool(mode_np, "vsync-active-high");
+ vm->interlaced = of_property_read_bool(mode_np, "interlaced");
+ vm->doublescan = of_property_read_bool(mode_np, "doublescan");
+
+ if (strcmp(default_mode,mode_np->full_name) = 0) {
+ printk("%s: default_node = %d\n", __func__, disp->num_modes);
+ disp->default_mode = disp->num_modes;
+ }
+
+ disp->modes[disp->num_modes] = vm;
+ disp->num_modes++;
+ }
+ of_node_put(display_np);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_video_mode);
+
+int of_video_mode_exists(struct device_node *np)
+{
+ struct device_node *display_np;
+ struct device_node *mode_np;
+
+ if (!np)
+ return -EINVAL;
+
+ display_np = of_parse_phandle(np, "display", 0);
+ if (!display_np)
+ return -EINVAL;
+ mode_np = of_parse_phandle(np, "default-mode", 0);
+ if (mode_np)
+ return 0;
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(of_video_mode_exists);
+
+int of_get_display_mode(struct device_node *np, struct drm_display_mode *dmode, int index)
+{
+ struct display disp;
+
+ of_get_video_mode(np, &disp);
+ if (index = OF_MODE_SELECTION)
+ index = disp.default_mode;
+ if (dmode)
+ videomode_to_display_mode(&disp, dmode, index);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_display_mode);
+
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fbmode, int index)
+{
+ struct display disp;
+
+ of_get_video_mode(np, &disp);
+
+ if (fbmode)
+ videomode_to_fb_mode(&disp, fbmode, index);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
new file mode 100644
index 0000000..a6b4da0
--- /dev/null
+++ b/include/linux/of_videomode.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2012 Sascha Hauer <s.hauer@pengutronix.de>
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * OF helpers for videomodes.
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_VIDEOMODE_H
+#define __LINUX_OF_VIDEOMODE_H
+
+#define OF_MODE_SELECTION -1
+
+struct mode_property {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct display {
+ u32 width_mm;
+ u32 height_mm;
+ struct videomode **modes;
+ int default_mode;
+ int num_modes;
+};
+
+/* describe videomode in terms of hardware parameters */
+struct videomode {
+ struct mode_property hback_porch;
+ struct mode_property hfront_porch;
+ struct mode_property hactive;
+ struct mode_property hsync_len;
+
+ struct mode_property vback_porch;
+ struct mode_property vfront_porch;
+ struct mode_property vactive;
+ struct mode_property vsync_len;
+
+ struct mode_property clock;
+
+ bool hah;
+ bool vah;
+ bool interlaced;
+ bool doublescan;
+};
+
+int of_video_mode_exists(struct device_node *np);
+int videomode_to_display_mode(struct display *disp, struct drm_display_mode *dmode, int index);
+int videomode_to_fb_mode(struct display *disp, struct fb_videomode *fbmode, int index);
+int of_get_video_mode(struct device_node *np, struct display *disp);
+int of_video_mode_exists(struct device_node *np);
+int of_get_display_mode(struct device_node *np, struct drm_display_mode *dmode, int index);
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fbmode, int index);
+#endif /* __LINUX_OF_VIDEOMODE_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 23/24] video: da8xx-fb: use __iomem pointers for MMIO
From: Arnd Bergmann @ 2012-09-14 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347658492-11608-1-git-send-email-arnd@arndb.de>
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/video/da8xx-fb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7ae9d53..113d43a 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,7 +131,7 @@
#define UPPER_MARGIN 32
#define LOWER_MARGIN 32
-static resource_size_t da8xx_fb_reg_base;
+static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
static irq_handler_t lcdc_irq_handler;
@@ -951,7 +951,7 @@ static int __devexit fb_remove(struct platform_device *dev)
clk_disable(par->lcdc_clk);
clk_put(par->lcdc_clk);
framebuffer_release(info);
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
}
@@ -1171,7 +1171,7 @@ static int __devinit fb_probe(struct platform_device *device)
if (!lcdc_regs)
return -EBUSY;
- da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs->start, len);
+ da8xx_fb_reg_base = ioremap(lcdc_regs->start, len);
if (!da8xx_fb_reg_base) {
ret = -EBUSY;
goto err_request_mem;
@@ -1392,7 +1392,7 @@ err_clk_put:
clk_put(fb_clk);
err_ioremap:
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
err_request_mem:
release_mem_region(lcdc_regs->start, len);
--
1.7.10
^ 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