* [RFC 11/17] OMAPDSS: HDMI: Add locking for hdmi interface get/set timing functions
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
The hdmi interface driver exposes functions to the hdmi panel driver to
get and configure the interface timings maintained by the hdmi driver.
These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
to ensure they are called sequentially, this is similar to how hdmi enable and
disable functions need locking.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 2de1f91..dfd582e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -547,7 +547,11 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
void omapdss_hdmi_display_get_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
+ mutex_lock(&hdmi.lock);
+
*timings = hdmi.ip_data.cfg.timings;
+
+ mutex_unlock(&hdmi.lock);
}
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
@@ -570,6 +574,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev,
struct hdmi_cm cm;
const struct hdmi_config *timing;
+ mutex_lock(&hdmi.lock);
+
cm = hdmi_get_code(timings);
hdmi.ip_data.cfg.cm = cm;
@@ -588,6 +594,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev,
} else {
dss_mgr_set_timings(dssdev->manager, &timing->timings);
}
+
+ mutex_unlock(&hdmi.lock);
}
static void hdmi_dump_regs(struct seq_file *s)
--
1.7.9.5
^ permalink raw reply related
* [RFC 12/17] OMAPDSS: SDI: Create a separate function for timing/clock configurations
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
Create a function sdi_set_mode() which configures the DISPC and DSS(PRCM)
clocks to get the required pixel clock, and configure the manager timings.
This is similar to what's done in the DPI driver in dpi_set_mode().
This makes the code a bit cleaner to read, and makes it easier to reconfigure
timings instead of switching off the whole interface, and then enabling the
interface with the new timings.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/sdi.c | 65 +++++++++++++++++++++++------------------
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 5d31699..f2d3f45 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -49,40 +49,21 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
dss_mgr_set_lcd_config(dssdev->manager, &sdi.mgr_config);
}
-int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
+static int sdi_set_mode(struct omap_dss_device *dssdev)
{
+ int r;
struct omap_video_timings *t = &dssdev->panel.timings;
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
unsigned long pck;
- int r;
-
- if (dssdev->manager = NULL) {
- DSSERR("failed to enable display: no manager\n");
- return -ENODEV;
- }
-
- r = omap_dss_start_device(dssdev);
- if (r) {
- DSSERR("failed to start device\n");
- goto err_start_dev;
- }
-
- r = regulator_enable(sdi.vdds_sdi_reg);
- if (r)
- goto err_reg_enable;
-
- r = dispc_runtime_get();
- if (r)
- goto err_get_dispc;
/* 15.5.9.1.2 */
- dssdev->panel.timings.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
- dssdev->panel.timings.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
+ t->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
+ t->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
r = dss_calc_clock_div(t->pixel_clock * 1000, &dss_cinfo, &dispc_cinfo);
if (r)
- goto err_calc_clock_div;
+ return r;
sdi.mgr_config.clock_info = dispc_cinfo;
@@ -96,12 +77,41 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
t->pixel_clock = pck;
}
-
dss_mgr_set_timings(dssdev->manager, t);
r = dss_set_clock_div(&dss_cinfo);
if (r)
- goto err_set_dss_clock_div;
+ return r;
+
+ return 0;
+}
+
+int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ if (dssdev->manager = NULL) {
+ DSSERR("failed to enable display: no manager\n");
+ return -ENODEV;
+ }
+
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR("failed to start device\n");
+ goto err_start_dev;
+ }
+
+ r = regulator_enable(sdi.vdds_sdi_reg);
+ if (r)
+ goto err_reg_enable;
+
+ r = dispc_runtime_get();
+ if (r)
+ goto err_get_dispc;
+
+ r = sdi_set_mode(dssdev);
+ if (r)
+ goto err_set_mode;
sdi_config_lcd_manager(dssdev);
@@ -120,8 +130,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
err_mgr_enable:
dss_sdi_disable();
err_sdi_enable:
-err_set_dss_clock_div:
-err_calc_clock_div:
+err_set_mode:
dispc_runtime_put();
err_get_dispc:
regulator_disable(sdi.vdds_sdi_reg);
--
1.7.9.5
^ permalink raw reply related
* [RFC 13/17] OMAPDSS: SDI: Create a function to set timings
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
Create function omapdss_sdi_set_timings(), this can be used by a SDI panel
driver without disabling/enabling the SDI interface. This is similar to the
set_timings op of the DPI interface driver. It calls sdi_set_mode() which only
configures the DISPC timings and DSS/DISPC clock dividers.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-acx565akm.c | 13 +------------
drivers/video/omap2/dss/sdi.c | 19 +++++++++++++++++++
include/video/omapdss.h | 2 ++
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index eaeed43..11bdc88 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -731,18 +731,7 @@ static int acx_panel_resume(struct omap_dss_device *dssdev)
static void acx_panel_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
- int r;
-
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
- omapdss_sdi_display_disable(dssdev);
-
- dssdev->panel.timings = *timings;
-
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
- r = omapdss_sdi_display_enable(dssdev);
- if (r)
- dev_err(&dssdev->dev, "%s enable failed\n", __func__);
- }
+ omapdss_sdi_set_timings(dssdev, timings);
}
static int acx_panel_check_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index f2d3f45..d88243f 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -155,6 +155,25 @@ void omapdss_sdi_display_disable(struct omap_dss_device *dssdev)
}
EXPORT_SYMBOL(omapdss_sdi_display_disable);
+void omapdss_sdi_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ int r;
+
+ dssdev->panel.timings = *timings;
+
+ if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
+ r = dispc_runtime_get();
+ if (r)
+ return;
+
+ sdi_set_mode(dssdev);
+
+ dispc_runtime_put();
+ }
+}
+EXPORT_SYMBOL(omapdss_sdi_set_timings);
+
static int __init sdi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("SDI init\n");
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index a2cd133..54ba639 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -760,6 +760,8 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
int omapdss_sdi_display_enable(struct omap_dss_device *dssdev);
void omapdss_sdi_display_disable(struct omap_dss_device *dssdev);
+void omapdss_sdi_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings);
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev);
void omapdss_rfbi_display_disable(struct omap_dss_device *dssdev);
--
1.7.9.5
^ permalink raw reply related
* [RFC 14/17] OMAPDSS: SDI: Maintain our own timings field in driver data
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
The SDI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the SDI interface driver dependent
on the omap_dss_device struct.
Make the SDI driver data maintain it's own timings field. The panel driver is
expected to call omapdss_sdi_set_timings() to set these timings before the panel
is enabled.
Make the SDI panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The SDI driver is responsible for maintaining
only it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-acx565akm.c | 4 ++++
drivers/video/omap2/dss/sdi.c | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index 11bdc88..77fe59f 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -600,6 +600,8 @@ static int acx_panel_power_on(struct omap_dss_device *dssdev)
mutex_lock(&md->mutex);
+ omapdss_sdi_set_timings(dssdev, &dssdev->panel.timings);
+
r = omapdss_sdi_display_enable(dssdev);
if (r) {
pr_err("%s sdi enable failed\n", __func__);
@@ -732,6 +734,8 @@ static void acx_panel_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
omapdss_sdi_set_timings(dssdev, timings);
+
+ dssdev->panel.timings = *timings;
}
static int acx_panel_check_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index d88243f..917816d 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -34,6 +34,7 @@ static struct {
struct regulator *vdds_sdi_reg;
struct dss_lcd_mgr_config mgr_config;
+ struct omap_video_timings timings;
} sdi;
static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
@@ -52,7 +53,7 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
static int sdi_set_mode(struct omap_dss_device *dssdev)
{
int r;
- struct omap_video_timings *t = &dssdev->panel.timings;
+ struct omap_video_timings *t = &sdi.timings;
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
unsigned long pck;
@@ -160,7 +161,7 @@ void omapdss_sdi_set_timings(struct omap_dss_device *dssdev,
{
int r;
- dssdev->panel.timings = *timings;
+ sdi.timings = *timings;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
r = dispc_runtime_get();
--
1.7.9.5
^ permalink raw reply related
* [RFC 15/17] OMAPDSS: VENC: Split VENC into interface and panel driver
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
The current venc.c driver contains both the interface and panel driver code.
This makes the driver hard to read, and difficult to understand the work split
between the interface and panel driver and the how the locking works.
This also makes it easier to clearly define the VENC interface ops called by the
panel driver.
Split venc.c into venc.c and venc_panel.c representing the interface and panel
driver respectively. This split is done along the lines of the HDMI interface
and panel drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss.h | 10 ++
drivers/video/omap2/dss/venc.c | 208 ++++++++----------------------
drivers/video/omap2/dss/venc_panel.c | 231 ++++++++++++++++++++++++++++++++++
4 files changed, 295 insertions(+), 156 deletions(-)
create mode 100644 drivers/video/omap2/dss/venc_panel.c
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 5c450b0..30a48fb 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -3,7 +3,7 @@ omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
manager.o overlay.o apply.o
omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
-omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
+omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o venc_panel.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi.o \
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index df49c5d..69b6ab9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -470,6 +470,16 @@ static inline unsigned long venc_get_pixel_clock(void)
return 0;
}
#endif
+int omapdss_venc_display_enable(struct omap_dss_device *dssdev);
+void omapdss_venc_display_disable(struct omap_dss_device *dssdev);
+void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings);
+int omapdss_venc_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings);
+u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
+int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
+int venc_panel_init(void);
+void venc_panel_exit(void);
/* HDMI */
#ifdef CONFIG_OMAP4_DSS_HDMI
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 3a22087..ffca542 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -427,6 +427,10 @@ static int venc_power_on(struct omap_dss_device *dssdev)
u32 l;
int r;
+ r = venc_runtime_get();
+ if (r)
+ goto err0;
+
venc_reset();
venc_write_config(venc_timings_to_config(&dssdev->panel.timings));
@@ -449,26 +453,22 @@ static int venc_power_on(struct omap_dss_device *dssdev)
r = regulator_enable(venc.vdda_dac_reg);
if (r)
- goto err;
-
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
+ goto err1;
r = dss_mgr_enable(dssdev->manager);
if (r)
- goto err;
+ goto err2;
return 0;
-err:
+err2:
+ regulator_disable(venc.vdda_dac_reg);
+err1:
venc_write_reg(VENC_OUTPUT_CONTROL, 0);
dss_set_dac_pwrdn_bgz(0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
- regulator_disable(venc.vdda_dac_reg);
-
+ venc_runtime_put();
+err0:
return r;
}
@@ -479,10 +479,9 @@ static void venc_power_off(struct omap_dss_device *dssdev)
dss_mgr_disable(dssdev->manager);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
regulator_disable(venc.vdda_dac_reg);
+
+ venc_runtime_put();
}
unsigned long venc_get_pixel_clock(void)
@@ -491,171 +490,95 @@ unsigned long venc_get_pixel_clock(void)
return 13500000;
}
-static ssize_t display_output_type_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+int omapdss_venc_display_enable(struct omap_dss_device *dssdev)
{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- const char *ret;
-
- switch (dssdev->phy.venc.type) {
- case OMAP_DSS_VENC_TYPE_COMPOSITE:
- ret = "composite";
- break;
- case OMAP_DSS_VENC_TYPE_SVIDEO:
- ret = "svideo";
- break;
- default:
- return -EINVAL;
- }
+ int r;
- return snprintf(buf, PAGE_SIZE, "%s\n", ret);
-}
-
-static ssize_t display_output_type_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t size)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- enum omap_dss_venc_type new_type;
-
- if (sysfs_streq("composite", buf))
- new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
- else if (sysfs_streq("svideo", buf))
- new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
- else
- return -EINVAL;
+ DSSDBG("venc_display_enable\n");
mutex_lock(&venc.venc_lock);
- if (dssdev->phy.venc.type != new_type) {
- dssdev->phy.venc.type = new_type;
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
- venc_power_off(dssdev);
- venc_power_on(dssdev);
- }
+ if (dssdev->manager = NULL) {
+ DSSERR("Failed to enable display: no manager\n");
+ r = -ENODEV;
+ goto err0;
}
- mutex_unlock(&venc.venc_lock);
-
- return size;
-}
-
-static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
- display_output_type_show, display_output_type_store);
-
-/* driver */
-static int venc_panel_probe(struct omap_dss_device *dssdev)
-{
- dssdev->panel.timings = omap_dss_pal_timings;
-
- return device_create_file(&dssdev->dev, &dev_attr_output_type);
-}
-
-static void venc_panel_remove(struct omap_dss_device *dssdev)
-{
- device_remove_file(&dssdev->dev, &dev_attr_output_type);
-}
-
-static int venc_panel_enable(struct omap_dss_device *dssdev)
-{
- int r = 0;
-
- DSSDBG("venc_enable_display\n");
-
- mutex_lock(&venc.venc_lock);
-
r = omap_dss_start_device(dssdev);
if (r) {
DSSERR("failed to start device\n");
goto err0;
}
- if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
- r = -EINVAL;
- goto err1;
- }
+ if (dssdev->platform_enable)
+ dssdev->platform_enable(dssdev);
- r = venc_runtime_get();
- if (r)
- goto err1;
r = venc_power_on(dssdev);
if (r)
- goto err2;
+ goto err1;
venc.wss_data = 0;
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-
mutex_unlock(&venc.venc_lock);
+
return 0;
-err2:
- venc_runtime_put();
err1:
+ if (dssdev->platform_disable)
+ dssdev->platform_disable(dssdev);
omap_dss_stop_device(dssdev);
err0:
mutex_unlock(&venc.venc_lock);
-
return r;
}
-static void venc_panel_disable(struct omap_dss_device *dssdev)
+void omapdss_venc_display_disable(struct omap_dss_device *dssdev)
{
- DSSDBG("venc_disable_display\n");
+ DSSDBG("venc_display_disable\n");
mutex_lock(&venc.venc_lock);
- if (dssdev->state = OMAP_DSS_DISPLAY_DISABLED)
- goto end;
-
- if (dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED) {
- /* suspended is the same as disabled with venc */
- dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
- goto end;
- }
-
venc_power_off(dssdev);
- venc_runtime_put();
-
- dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
-
omap_dss_stop_device(dssdev);
-end:
- mutex_unlock(&venc.venc_lock);
-}
-static int venc_panel_suspend(struct omap_dss_device *dssdev)
-{
- venc_panel_disable(dssdev);
- return 0;
-}
+ if (dssdev->platform_disable)
+ dssdev->platform_disable(dssdev);
-static int venc_panel_resume(struct omap_dss_device *dssdev)
-{
- return venc_panel_enable(dssdev);
+ mutex_unlock(&venc.venc_lock);
}
-static void venc_set_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
+void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
{
DSSDBG("venc_set_timings\n");
+ mutex_lock(&venc.venc_lock);
+
/* Reset WSS data when the TV standard changes. */
if (memcmp(&dssdev->panel.timings, timings, sizeof(*timings)))
venc.wss_data = 0;
dssdev->panel.timings = *timings;
+
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
+ int r;
+
/* turn the venc off and on to get new timings to use */
- venc_panel_disable(dssdev);
- venc_panel_enable(dssdev);
+ venc_power_off(dssdev);
+
+ r = venc_power_on(dssdev);
+ if (r)
+ DSSERR("failed to power on VENC\n");
} else {
dss_mgr_set_timings(dssdev->manager, timings);
}
+
+ mutex_unlock(&venc.venc_lock);
}
-static int venc_check_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
+int omapdss_venc_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
{
DSSDBG("venc_check_timings\n");
@@ -668,13 +591,13 @@ static int venc_check_timings(struct omap_dss_device *dssdev,
return -EINVAL;
}
-static u32 venc_get_wss(struct omap_dss_device *dssdev)
+u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev)
{
/* Invert due to VENC_L21_WC_CTL:INV=1 */
return (venc.wss_data >> 8) ^ 0xfffff;
}
-static int venc_set_wss(struct omap_dss_device *dssdev, u32 wss)
+int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss)
{
const struct venc_config *config;
int r;
@@ -703,31 +626,6 @@ err:
return r;
}
-static struct omap_dss_driver venc_driver = {
- .probe = venc_panel_probe,
- .remove = venc_panel_remove,
-
- .enable = venc_panel_enable,
- .disable = venc_panel_disable,
- .suspend = venc_panel_suspend,
- .resume = venc_panel_resume,
-
- .get_resolution = omapdss_default_get_resolution,
- .get_recommended_bpp = omapdss_default_get_recommended_bpp,
-
- .set_timings = venc_set_timings,
- .check_timings = venc_check_timings,
-
- .get_wss = venc_get_wss,
- .set_wss = venc_set_wss,
-
- .driver = {
- .name = "venc",
- .owner = THIS_MODULE,
- },
-};
-/* driver end */
-
static int __init venc_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
@@ -897,9 +795,9 @@ static int __init omap_venchw_probe(struct platform_device *pdev)
venc_runtime_put();
- r = omap_dss_register_driver(&venc_driver);
+ r = venc_panel_init();
if (r)
- goto err_reg_panel_driver;
+ goto err_panel_init;
dss_debugfs_create_file("venc", venc_dump_regs);
@@ -907,7 +805,7 @@ static int __init omap_venchw_probe(struct platform_device *pdev)
return 0;
-err_reg_panel_driver:
+err_panel_init:
err_runtime_get:
pm_runtime_disable(&pdev->dev);
venc_put_clocks();
@@ -923,7 +821,7 @@ static int __exit omap_venchw_remove(struct platform_device *pdev)
venc.vdda_dac_reg = NULL;
}
- omap_dss_unregister_driver(&venc_driver);
+ venc_panel_exit();
pm_runtime_disable(&pdev->dev);
venc_put_clocks();
diff --git a/drivers/video/omap2/dss/venc_panel.c b/drivers/video/omap2/dss/venc_panel.c
new file mode 100644
index 0000000..6b31298
--- /dev/null
+++ b/drivers/video/omap2/dss/venc_panel.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+ *
+ * VENC panel driver
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/mutex.h>
+#include <linux/module.h>
+
+#include <video/omapdss.h>
+
+#include "dss.h"
+
+static struct {
+ struct mutex lock;
+} venc_panel;
+
+static ssize_t display_output_type_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ const char *ret;
+
+ switch (dssdev->phy.venc.type) {
+ case OMAP_DSS_VENC_TYPE_COMPOSITE:
+ ret = "composite";
+ break;
+ case OMAP_DSS_VENC_TYPE_SVIDEO:
+ ret = "svideo";
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", ret);
+}
+
+static ssize_t display_output_type_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ enum omap_dss_venc_type new_type;
+
+ if (sysfs_streq("composite", buf))
+ new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
+ else if (sysfs_streq("svideo", buf))
+ new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
+ else
+ return -EINVAL;
+
+ mutex_lock(&venc_panel.lock);
+
+ if (dssdev->phy.venc.type != new_type) {
+ dssdev->phy.venc.type = new_type;
+ if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
+ omapdss_venc_display_disable(dssdev);
+ omapdss_venc_display_enable(dssdev);
+ }
+ }
+
+ mutex_unlock(&venc_panel.lock);
+
+ return size;
+}
+
+static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
+ display_output_type_show, display_output_type_store);
+
+static int venc_panel_probe(struct omap_dss_device *dssdev)
+{
+ mutex_init(&venc_panel.lock);
+
+ /* set initial timings to PAL */
+ dssdev->panel.timings = (struct omap_video_timings)
+ { 720, 574, 13500, 64, 12, 68, 5, 5, 41,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ true,
+ };
+
+ return device_create_file(&dssdev->dev, &dev_attr_output_type);
+}
+
+static void venc_panel_remove(struct omap_dss_device *dssdev)
+{
+ device_remove_file(&dssdev->dev, &dev_attr_output_type);
+}
+
+static int venc_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ dev_dbg(&dssdev->dev, "venc_panel_enable\n");
+
+ mutex_lock(&venc_panel.lock);
+
+ if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
+ r = -EINVAL;
+ goto err;
+ }
+
+ r = omapdss_venc_display_enable(dssdev);
+ if (r)
+ goto err;
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ mutex_unlock(&venc_panel.lock);
+
+ return 0;
+err:
+ mutex_unlock(&venc_panel.lock);
+
+ return r;
+}
+
+static void venc_panel_disable(struct omap_dss_device *dssdev)
+{
+ dev_dbg(&dssdev->dev, "venc_panel_disable\n");
+
+ mutex_lock(&venc_panel.lock);
+
+ if (dssdev->state = OMAP_DSS_DISPLAY_DISABLED)
+ goto end;
+
+ if (dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED) {
+ /* suspended is the same as disabled with venc */
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+ goto end;
+ }
+
+ omapdss_venc_display_disable(dssdev);
+
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+end:
+ mutex_unlock(&venc_panel.lock);
+}
+
+static int venc_panel_suspend(struct omap_dss_device *dssdev)
+{
+ venc_panel_disable(dssdev);
+ return 0;
+}
+
+static int venc_panel_resume(struct omap_dss_device *dssdev)
+{
+ return venc_panel_enable(dssdev);
+}
+
+static void venc_panel_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ dev_dbg(&dssdev->dev, "venc_panel_set_timings\n");
+
+ mutex_lock(&venc_panel.lock);
+
+ omapdss_venc_set_timings(dssdev, timings);
+
+ mutex_unlock(&venc_panel.lock);
+}
+
+static int venc_panel_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ dev_dbg(&dssdev->dev, "venc_panel_check_timings\n");
+
+ return omapdss_venc_check_timings(dssdev, timings);
+}
+
+static u32 venc_panel_get_wss(struct omap_dss_device *dssdev)
+{
+ dev_dbg(&dssdev->dev, "venc_panel_get_wss\n");
+
+ return omapdss_venc_get_wss(dssdev);
+}
+
+static int venc_panel_set_wss(struct omap_dss_device *dssdev, u32 wss)
+{
+ dev_dbg(&dssdev->dev, "venc_panel_set_wss\n");
+
+ return omapdss_venc_set_wss(dssdev, wss);
+}
+
+static struct omap_dss_driver venc_driver = {
+ .probe = venc_panel_probe,
+ .remove = venc_panel_remove,
+
+ .enable = venc_panel_enable,
+ .disable = venc_panel_disable,
+ .suspend = venc_panel_suspend,
+ .resume = venc_panel_resume,
+
+ .get_resolution = omapdss_default_get_resolution,
+ .get_recommended_bpp = omapdss_default_get_recommended_bpp,
+
+ .set_timings = venc_panel_set_timings,
+ .check_timings = venc_panel_check_timings,
+
+ .get_wss = venc_panel_get_wss,
+ .set_wss = venc_panel_set_wss,
+
+ .driver = {
+ .name = "venc",
+ .owner = THIS_MODULE,
+ },
+};
+
+int venc_panel_init(void)
+{
+ return omap_dss_register_driver(&venc_driver);
+}
+
+void venc_panel_exit(void)
+{
+ omap_dss_unregister_driver(&venc_driver);
+}
--
1.7.9.5
^ permalink raw reply related
* [RFC 16/17] OMAPDSS: VENC: Maintain our own timings field in driver data
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
The VENC driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and VENC blocks accordingly. This makes the VENC interface
driver dependent on the omap_dss_device struct.
Make the VENC driver data maintain it's own timings field. The panel driver is
expected to call omapdss_venc_set_timings() to set these timings before the
panel is enabled.
Make the VENC panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
only it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/venc.c | 12 +++++++-----
drivers/video/omap2/dss/venc_panel.c | 1 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index ffca542..d96025e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -300,6 +300,8 @@ static struct {
struct regulator *vdda_dac_reg;
struct clk *tv_dac_clk;
+
+ struct omap_video_timings timings;
} venc;
static inline void venc_write_reg(int idx, u32 val)
@@ -432,7 +434,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
goto err0;
venc_reset();
- venc_write_config(venc_timings_to_config(&dssdev->panel.timings));
+ venc_write_config(venc_timings_to_config(&venc.timings));
dss_set_venc_output(dssdev->phy.venc.type);
dss_set_dac_pwrdn_bgz(1);
@@ -449,7 +451,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
venc_write_reg(VENC_OUTPUT_CONTROL, l);
- dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
+ dss_mgr_set_timings(dssdev->manager, &venc.timings);
r = regulator_enable(venc.vdda_dac_reg);
if (r)
@@ -556,10 +558,10 @@ void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
mutex_lock(&venc.venc_lock);
/* Reset WSS data when the TV standard changes. */
- if (memcmp(&dssdev->panel.timings, timings, sizeof(*timings)))
+ if (memcmp(&venc.timings, timings, sizeof(*timings)))
venc.wss_data = 0;
- dssdev->panel.timings = *timings;
+ venc.timings = *timings;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
int r;
@@ -606,7 +608,7 @@ int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss)
mutex_lock(&venc.venc_lock);
- config = venc_timings_to_config(&dssdev->panel.timings);
+ config = venc_timings_to_config(&venc.timings);
/* Invert due to VENC_L21_WC_CTL:INV=1 */
venc.wss_data = (wss ^ 0xfffff) << 8;
diff --git a/drivers/video/omap2/dss/venc_panel.c b/drivers/video/omap2/dss/venc_panel.c
index 6b31298..350b0d9 100644
--- a/drivers/video/omap2/dss/venc_panel.c
+++ b/drivers/video/omap2/dss/venc_panel.c
@@ -170,6 +170,7 @@ static void venc_panel_set_timings(struct omap_dss_device *dssdev,
mutex_lock(&venc_panel.lock);
omapdss_venc_set_timings(dssdev, timings);
+ dssdev->panel.timings = *timings;
mutex_unlock(&venc_panel.lock);
}
--
1.7.9.5
^ permalink raw reply related
* [RFC 17/17] OMAPDSS: VENC: Add a get_timing function for VENC interface
From: Archit Taneja @ 2012-08-01 10:43 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob, Archit Taneja
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
Add function omapdss_venc_get_timing() which returns the timings
maintained by the VENC interface driver in it's driver data. This is just used
once by the driver during it's probe. This prevents the need for the panel
driver to configure default timings in it's probe.
Int the VENC interface's probe, the timings field is set to PAL as a default
value. The get_timing op makes more sense for interfaces which can be configured
to a default timing.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dss.h | 2 ++
drivers/video/omap2/dss/venc.c | 13 +++++++++++++
drivers/video/omap2/dss/venc_panel.c | 11 +++++------
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 69b6ab9..3fe76c0 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -474,6 +474,8 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev);
void omapdss_venc_display_disable(struct omap_dss_device *dssdev);
void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
+void omapdss_venc_get_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings);
int omapdss_venc_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index d96025e..42f97ac 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -579,6 +579,18 @@ void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
mutex_unlock(&venc.venc_lock);
}
+void omapdss_venc_get_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ DSSDBG("venc_set_timings\n");
+
+ mutex_lock(&venc.venc_lock);
+
+ *timings = venc.timings;
+
+ mutex_unlock(&venc.venc_lock);
+}
+
int omapdss_venc_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
@@ -768,6 +780,7 @@ static int __init omap_venchw_probe(struct platform_device *pdev)
mutex_init(&venc.venc_lock);
venc.wss_data = 0;
+ venc.timings = omap_dss_pal_timings;
venc_mem = platform_get_resource(venc.pdev, IORESOURCE_MEM, 0);
if (!venc_mem) {
diff --git a/drivers/video/omap2/dss/venc_panel.c b/drivers/video/omap2/dss/venc_panel.c
index 350b0d9..fe9958d 100644
--- a/drivers/video/omap2/dss/venc_panel.c
+++ b/drivers/video/omap2/dss/venc_panel.c
@@ -84,14 +84,13 @@ static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
static int venc_panel_probe(struct omap_dss_device *dssdev)
{
+ struct omap_video_timings timings;
+
mutex_init(&venc_panel.lock);
- /* set initial timings to PAL */
- dssdev->panel.timings = (struct omap_video_timings)
- { 720, 574, 13500, 64, 12, 68, 5, 5, 41,
- OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
- true,
- };
+ omapdss_venc_get_timings(dssdev, &timings);
+
+ dssdev->panel.timings = timings;
return device_create_file(&dssdev->dev, &dev_attr_output_type);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC 00/17] OMAPDSS: Change way of passing timings from panel driver to interface
From: Archit Taneja @ 2012-08-01 10:47 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, sumit.semwal, rob
In-Reply-To: <1343817088-29645-1-git-send-email-archit@ti.com>
On Wednesday 01 August 2012 04:01 PM, Archit Taneja wrote:
> This series tries to make interface drivers less dependent on omap_dss_device
> which represents a panel/device connected to that interface. The current way of
> configuring an interface is to populate the panel's omap_dss_device instance
> with parameters common to the panel and the interface, they are either populated
> in the board file, or in the panel driver. Panel timings, number of lanes
> connected to interface, and pixel format are examples of such parameters, these
> are then extracted by the interface driver to configure itself.
>
> This approach has some disadvantages:
>
> - The omap_dss_device contains fields which could be handled independently by
> the panel driver. For example, we have an enum field in omap_dss_device to
> tell what mode the panel operates in. This information could be handled by the
> panel driver itself. But it's a part of omap_dss_device since we need to pass
> this down to the interface driver.
>
> - An interface can't exist by itself. That is, it needs a panel to be connected
> to it to configure itself. It's not practical to configure an interface
> without a panel, but it's theoretically possible, and we may need it if we
> expose the interface as an entity to a user of OMAPDSS. It's also useful if we
> represent writeback as an interface, writeback isn't connected to a panel.
>
> - There is a lack of clarity in how the interface configures itself. Since the
> interface driver extracts info from omap_dss_device, it's unclear from a panel
> driver point of view about what information in omap_dss_device the interface
> is using and what it's not using.
>
> - There are issues with checking the correctness of the parameters in
> omap_dss_device. We currently fill up the omap_dss_device completely, and then
> try to enable the interface, this results in catching a wrong parameter at a
> much later point, rather than catching it immediately.
>
> The alternative approach is for the interface drivers to expose functions/api to
> the panel drivers to configure such parameters. This way, the panel driver can
> pass the parameters to the interface itself, rather than filling up
> omap_dss_device. This would need the panel driver to keep a copy of the
> parameters so that it can use to configure it later. This resolves all the
> issues mentioned above, and also gives us a chance to make a generic set of
> function ops for interfaces, this can make a panel driver independent of
> the underlying platform.
>
> The current series starts of this work by creating a set_timings function for
> all interfaces passing omap_video_timings, this prevents dssdev->panel.timings
> references. The first few patches are some minor cleanups which are useful for
> the patches which come later.
>
> There are some points on which I need suggestions/clarifications:
> - How do we make sure that these functions are called by the panel driver at the
> right time? For example, when setting timings for DSI video mode, we would
> need to call omapdss_dsi_set_timings() before we call
> omapdss_dsi_display_enable(), otherwise the copy of timings contained in DSI
> driver data would be invalid. Also, what should the behaviour of such a
> set_timings operation if the interface is already enabled. It is clear for
> DPI and HDMI, but I'm not clear about what to do about other interfaces. Do we
> add checks for the state of the interface/panel?
>
> - A specific issue about DSI/RFBI getting the resolution via
> device->driver->get_resolution(), does this provide a result based on panel
> rotation? Can this somehow be replaced by timings?
>
> - For SDI, the set_timings operation is simplified, instead of disabling and
> then enabling the panel with a new set of timings, only the new timings are
> configured. This is similar to what is done in DPI. I am not clear if this
> will work for SDI or not.
>
> - There is no set_timings() function for RFBI yet, this needs to be though of
> and fixed.
>
> The reference tree and branch:
forgot to add the link here:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git
pass_timings_interface
Archit
>
> This is based on Tomi's for-florian-merged branch, and has 2 of his patches which
> got missed the last merge window.
>
> This hasn't been tested thoroughly with all interfaces yet. I was interested in
> getting some comments.
>
> Archit Taneja (17):
> OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings
> OMAPDSS: DPI: Remove omap_dss_device arguments in
> dpi_set_dsi_clk/dpi_set_dispc_clk
> OMAPDSS: HDMI: Remove omap_dss_device argument from hdmi_compute_pll
> OMAPDSS: DPI: Add locking for DPI interface
> OMAPDSS: DPI: Maintain our own timings field in driver data
> OMAPDSS: DPI displays: Take care of panel timings in the driver
> itself
> OMAPDSS: Displays: Add locking in generic DPI panel driver
> OMAPDSS: DSI: Maintain own copy of timings in driver data
> OMAPDSS: HDMI: Use our own omap_video_timings field when setting
> interface timings
> OMAPDSS: HDMI: Add a get_timing function for HDMI interface
> OMAPDSS: HDMI: Add locking for hdmi interface get/set timing
> functions
> OMAPDSS: SDI: Create a separate function for timing/clock
> configurations
> OMAPDSS: SDI: Create a function to set timings
> OMAPDSS: SDI: Maintain our own timings field in driver data
> OMAPDSS: VENC: Split VENC into interface and panel driver
> OMAPDSS: VENC: Maintain our own timings field in driver data
> OMAPDSS: VENC: Add a get_timing function for VENC interface
>
> drivers/video/omap2/displays/panel-acx565akm.c | 13 +-
> drivers/video/omap2/displays/panel-generic-dpi.c | 75 ++++++-
> .../omap2/displays/panel-lgphilips-lb035q02.c | 2 +
> .../omap2/displays/panel-nec-nl8048hl11-01b.c | 2 +
> drivers/video/omap2/displays/panel-picodlp.c | 3 +
> .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 2 +
> drivers/video/omap2/displays/panel-taal.c | 2 +
> drivers/video/omap2/displays/panel-tfp410.c | 5 +-
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 6 +-
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/apply.c | 4 +-
> drivers/video/omap2/dss/dpi.c | 52 +++--
> drivers/video/omap2/dss/dsi.c | 27 ++-
> drivers/video/omap2/dss/dss.h | 19 +-
> drivers/video/omap2/dss/hdmi.c | 60 +++--
> drivers/video/omap2/dss/hdmi_panel.c | 12 +-
> drivers/video/omap2/dss/sdi.c | 87 +++++---
> drivers/video/omap2/dss/venc.c | 233 ++++++--------------
> drivers/video/omap2/dss/venc_panel.c | 231 +++++++++++++++++++
> include/video/omapdss.h | 8 +-
> 20 files changed, 579 insertions(+), 266 deletions(-)
> create mode 100644 drivers/video/omap2/dss/venc_panel.c
>
^ permalink raw reply
* [GIT PULL] fbdev updates for 3.6
From: Florian Tobias Schandinat @ 2012-08-01 13:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org
Hi Linus,
please pull the changes below.
Thanks,
Florian Tobias Schandinat
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git fbdev-updates-for-3.6
for you to fetch changes up to a0239073fd75489d25575cf3aaf71ab55b416020:
da8xx-fb: fix compile issue due to missing include (2012-07-29 16:47:40 +0000)
----------------------------------------------------------------
fbdev updates for 3.6
It includes:
- large updates for OMAP
- support for LCD3 overlay manager (omap5)
- omapdss output cleanup
- removal of passive matrix LCD support as there are no drivers for
such panels for DSS or DSS2 and nobody complained (cleanup)
- large updates for SH Mobile
- overlay support
- separating MERAM (cache) from framebuffer driver
- some updates for Exynos and da8xx-fb
- various other small patches
----------------------------------------------------------------
Aditya Nellutla (1):
da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
Alexander Holler (1):
video/smscufx: fix line counting in fb_write
Alexander Shiyan (1):
fb: epson1355fb: Fix section mismatch
Archit Taneja (27):
OMAPDSS: Remove passive matrix LCD support (part 1)
OMAPDSS: Remove passive matrix LCD support (part 2)
OMAPDSS: Remove passive matrix LCD support (part 3)
OMAPDSS: Remove passive matrix LCD support (part 4)
OMAPDSS: Add some new fields to omap_video_timings
OMAPDSS: DISPLAY: Ignore newly added omap_video_timings fields for display timings sysfs file
OMAPDSS: DISPC: Configure newly added omap_video_timing fields
OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq()
OMAPFB: Map the newly added omap_video_timings fields with fb sync flags
OMAPDSS: Remove omap_panel_config enum from omap_dss_device
OMAPDSS: Add interlace parameter to omap_video_timings
OMAPDSS: DISPC/APPLY: Use interlace info in manager timings for dispc_ovl_setup()
OMAPFB: Map interlace field in omap_video_timings with fb vmode flags
OMAPDSS: HDMI: Remove custom hdmi_video_timings struct
OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSI
OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div()
OMAPDSS: Add struct to hold LCD overlay manager configuration
OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters
OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters
OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters
OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters
OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers
OMAPDSS: MANAGER: Check LCD related overlay manager parameters
OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks
OMAPDSS: DISPC: Remove a redundant function
OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager
OMAPDSS: OVERLAY: Clean up replication checking
Benjamin Herrenschmidt (1):
fbdev: Make pixel_to_pat() failure mode more friendly
Chandrabhanu Mahapatra (5):
OMAPDSS: Cleanup implementation of LCD channels
OMAPDSS: Add support for LCD3 channel
OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support
OMAPDSS: Add dump and debug support for LCD3
ARM: OMAP2PLUS: DSS: Disable LCD3 output when resetting DSS
Donghwa Lee (1):
video: exynos mipi dsi: Fix mipi dsi regulators handling issue
Emil Goode (2):
grvga: Fix error handling issues
aty128fb: Fix coding style issues
Florian Tobias Schandinat (5):
Merge branch 'planes' of git://linuxtv.org/pinchartl/fbdev into fbdev-next
Merge branch 'fbdev-for-linus' into fbdev-next
Merge branch 'for-next' of git://linuxtv.org/pinchartl/fbdev into fbdev-next
Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into fbdev-next
da8xx-fb: fix compile issue due to missing include
Guennadi Liakhovetski (1):
fbdev: sh_mipi_dsi: fix a section mismatch
Jassi Brar (2):
OMAPDSS: HDMI: Discard phy_tx_enabled member
OMAPDSS: HDMI: Replace spinlock with mutex in hdmi_check_hpd_state
Jingoo Han (5):
video: exynos_dp: fix build warning due to uninitialized value
video: exynos_dp: remove duplicated declarations from header file
video: exynos_dp: fix wrong DPCD address during Link Training
video: exynos_dp: check the only INTERLANE_ALIGN_DONE bit during Link Training
video: exynos_dp: use usleep_range instead of delay
Laurent Pinchart (13):
fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
fbdev: sh_mobile_lcdc: Implement overlays support
sh_mobile_meram: Rename operations to cache_[alloc|free|update]
sh_mobile_meram: Use direct function calls for the public API
sh_mobile_meram: Add direct MERAM allocation API
fbdev: sh_mobile_lcdc: Destroy mutex at remove time
fbdev: sh_mobile_lcdc: Fix line pitch computation
fbdev: sh_mobile_lcdc: Use channel configuration to initialize fb device
fbdev: sh_mobile_lcdc: Support horizontal panning
fbdev: sh_mobile_lcdc: Fix overlay registers update during pan operation
fbdev: sh_mobile_lcdc: Fix pan offset computation in YUV mode
fbdev: sh_mobile_lcdc: Fix vertical panning step
Liu Ying (2):
mx3fb: support pan display with fb_set_var
mx3fb: avoid screen flash when panning with fb_set_var
Manjunathappa, Prakash (6):
video: da8xx-fb rev2: fix disabling of palette completion interrupt
video: da8xx-fb: fix flicker due to 1 frame delay in updated frame
video: da8xx-fb: configure FIFO threshold to reduce underflow errors
arm: da850: configure LCDC fifo threshold
video: da8xx-fb: do clock reset of revision 2 LCDC before enabling
da8xx-fb: do not turn ON LCD backlight unless LCDC is enabled
Ondrej Zary (1):
s3fb: Add Virge/MX (86C260)
Paul Bolle (1):
video: backlight: remove unused header
Paul Parsons (1):
video: w100fb: Reduce sleep mode battery discharge
Peter Meerwald (1):
OMAPDSS: fix specification spelling in Kconfig
Rajendra Nayak (1):
OMAPDSS: add clk_prepare_enable and clk_disable_unprepare
Tomi Valkeinen (8):
Merge tag 'v3.5-rc2'
OMAPDSS: remove enum omap_dss_overlay_managers
OMAPDSS: Use PM notifiers for system suspend
OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n
Merge Misc DSS clean ups from Archit
Merge "Apply LCD manager related parameters" from Archit
OMAPDSS: Use PM notifiers for system suspend
OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n
Yegor Yefremov (1):
da8xx-fb: add missing FB_BLANK operations
.../sysfs-devices-platform-sh_mobile_lcdc_fb | 44 +
arch/arm/mach-davinci/devices-da8xx.c | 1 +
arch/arm/mach-omap2/display.c | 25 +-
drivers/video/aty/aty128fb.c | 180 ++--
drivers/video/da8xx-fb.c | 78 ++-
drivers/video/epson1355fb.c | 8 +-
drivers/video/exynos/exynos_dp_core.c | 23 +-
drivers/video/exynos/exynos_dp_core.h | 4 -
drivers/video/exynos/exynos_dp_reg.c | 4 +-
drivers/video/exynos/exynos_mipi_dsi.c | 2 +-
drivers/video/exynos/s6e8ax0.h | 21 -
drivers/video/fb_draw.h | 7 +-
drivers/video/grvga.c | 47 +-
drivers/video/mx3fb.c | 55 +-
drivers/video/omap2/displays/panel-acx565akm.c | 10 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 179 ++--
.../omap2/displays/panel-lgphilips-lb035q02.c | 8 +-
drivers/video/omap2/displays/panel-n8x0.c | 1 -
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 9 +-
drivers/video/omap2/displays/panel-picodlp.c | 9 +-
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 9 +-
drivers/video/omap2/displays/panel-taal.c | 1 -
drivers/video/omap2/displays/panel-tfp410.c | 7 +-
.../video/omap2/displays/panel-tpo-td043mtea1.c | 8 +-
drivers/video/omap2/dss/Kconfig | 4 +-
drivers/video/omap2/dss/apply.c | 91 ++-
drivers/video/omap2/dss/core.c | 43 +-
drivers/video/omap2/dss/dispc.c | 496 +++++-----
drivers/video/omap2/dss/dispc.h | 28 +
drivers/video/omap2/dss/display.c | 40 +-
drivers/video/omap2/dss/dpi.c | 64 +-
drivers/video/omap2/dss/dsi.c | 154 ++--
drivers/video/omap2/dss/dss.c | 21 +-
drivers/video/omap2/dss/dss.h | 54 +-
drivers/video/omap2/dss/dss_features.h | 5 +-
drivers/video/omap2/dss/hdmi.c | 248 ++++-
drivers/video/omap2/dss/hdmi_panel.c | 9 +-
drivers/video/omap2/dss/manager.c | 51 +-
drivers/video/omap2/dss/overlay.c | 33 +-
drivers/video/omap2/dss/rfbi.c | 42 +-
drivers/video/omap2/dss/sdi.c | 42 +-
drivers/video/omap2/dss/ti_hdmi.h | 21 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 26 +-
drivers/video/omap2/dss/venc.c | 10 +-
drivers/video/omap2/omapfb/omapfb-main.c | 51 +-
drivers/video/s3fb.c | 31 +-
drivers/video/sh_mipi_dsi.c | 7 +-
drivers/video/sh_mobile_lcdcfb.c | 1117 +++++++++++++++++---
drivers/video/sh_mobile_lcdcfb.h | 5 +-
drivers/video/sh_mobile_meram.c | 235 +++--
drivers/video/smscufx.c | 2 +-
drivers/video/w100fb.c | 12 +
include/video/da8xx-fb.h | 3 +
include/video/omapdss.h | 51 +-
include/video/sh_mobile_lcdc.h | 7 +
include/video/sh_mobile_meram.h | 71 +-
56 files changed, 2654 insertions(+), 1160 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb
delete mode 100644 drivers/video/exynos/s6e8ax0.h
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-08-01 13:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120801074113.GF29673-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Wed, Aug 01, 2012 at 09:41:13AM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> > Sure there is - take a copy of the platform data in probe().
> Yes, but that will only work for built-in drivers. If you unload the
> module and that causes the platform data to be discarded, reloading
> won't work.
This is why __devinit data will only be discarded when this is not
possible.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-08-01 13:38 UTC (permalink / raw)
To: Mark Brown
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120801132651.GU11892-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 09:41:13AM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
>
> > > Sure there is - take a copy of the platform data in probe().
>
> > Yes, but that will only work for built-in drivers. If you unload the
> > module and that causes the platform data to be discarded, reloading
> > won't work.
>
> This is why __devinit data will only be discarded when this is not
> possible.
That's exactly my point. But I seem to have miserably failed to get that
across. =)
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-08-01 13:55 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120801133814.GA19771-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Wed, Aug 01, 2012 at 03:38:14PM +0200, Thierry Reding wrote:
> On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
> > This is why __devinit data will only be discarded when this is not
> > possible.
> That's exactly my point. But I seem to have miserably failed to get that
> across. =)
We must be talking at cross purposes then. What I'm saying is that the
framework shouldn't rely on platform data and should assume that the
kernel might be configured so it can be discarded (by copying most
likely).
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-08-01 14:01 UTC (permalink / raw)
To: Mark Brown
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120801135531.GW11892-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On Wed, Aug 01, 2012 at 02:55:31PM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 03:38:14PM +0200, Thierry Reding wrote:
> > On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
>
> > > This is why __devinit data will only be discarded when this is not
> > > possible.
>
> > That's exactly my point. But I seem to have miserably failed to get that
> > across. =)
>
> We must be talking at cross purposes then. What I'm saying is that the
> framework shouldn't rely on platform data and should assume that the
> kernel might be configured so it can be discarded (by copying most
> likely).
Yes. I think this should be solved by the power_seq_build() function
which uses the platform data description of the sequence and builds it
into something for internal use that doesn't rely on anything in the
platform data.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
From: Damien Cassou @ 2012-08-01 16:36 UTC (permalink / raw)
To: Jingoo Han
Cc: Sachin Kamat, kernel-janitors, Florian Tobias Schandinat,
linux-fbdev, linux-kernel
In-Reply-To: <004201cd6fa3$b0538b70$10faa250$%han@samsung.com>
On Wed, Aug 1, 2012 at 7:08 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> To Damien,
> As Sachin Kamat mentioned, please change the subject more specific. For example,
>
> video: exynos_dp: use devm_clk_get function
ok, done in a new thread titled:
[PATCH v2] video: exynos_dp: use devm_clk_get function
Thank you for the feedback
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
^ permalink raw reply
* Re: [PATCH v2] video: exynos_dp: use devm_clk_get function
From: Jingoo Han @ 2012-08-01 22:59 UTC (permalink / raw)
To: 'Damien Cassou'
Cc: 'Florian Tobias Schandinat', linux-fbdev, linux-kernel,
'Sachin Kamat', 'Jingoo Han'
In-Reply-To: <877gti1t48.fsf@gmail.com>
On Thursday, August 02, 2012 1:21 AM Damien Cassou wrote:
>
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The devm_clk_get function allocates memory that is released when a driver
> detaches. This patch uses this function for data that is allocated in the probe
> function of a platform device and is only freed in the remove function.
>
> Additionally, this patch removes a null check after platform_get_resource that
> is redundant with the one done by devm_request_and_ioremap.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Thank you for sending the patch.
Best regards,
Jingoo Han
>
> ---
> Changed subject line and description
> drivers/video/exynos/exynos_dp_core.c | 27 +++++++--------------------
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index c6c016a..00fe4f0 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>
> dp->dev = &pdev->dev;
>
> - dp->clock = clk_get(&pdev->dev, "dp");
> + dp->clock = devm_clk_get(&pdev->dev, "dp");
> if (IS_ERR(dp->clock)) {
> dev_err(&pdev->dev, "failed to get clock\n");
> return PTR_ERR(dp->clock);
> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> clk_enable(dp->clock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "failed to get registers\n");
> - ret = -EINVAL;
> - goto err_clock;
> - }
>
> dp->reg_base = devm_request_and_ioremap(&pdev->dev, res);
> if (!dp->reg_base) {
> dev_err(&pdev->dev, "failed to ioremap\n");
> - ret = -ENOMEM;
> - goto err_clock;
> + return -ENOMEM;
> }
>
> dp->irq = platform_get_irq(pdev, 0);
> if (!dp->irq) {
> dev_err(&pdev->dev, "failed to get irq\n");
> - ret = -ENODEV;
> - goto err_clock;
> + return -ENODEV;
> }
>
> ret = devm_request_irq(&pdev->dev, dp->irq, exynos_dp_irq_handler, 0,
> "exynos-dp", dp);
> if (ret) {
> dev_err(&pdev->dev, "failed to request irq\n");
> - goto err_clock;
> + return ret;
> }
>
> dp->video_info = pdata->video_info;
> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> ret = exynos_dp_detect_hpd(dp);
> if (ret) {
> dev_err(&pdev->dev, "unable to detect hpd\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_handle_edid(dp);
> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> dp->video_info->link_rate);
> if (ret) {
> dev_err(&pdev->dev, "unable to do link train\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_enable_scramble(dp, 1);
> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> ret = exynos_dp_config_video(dp, dp->video_info);
> if (ret) {
> dev_err(&pdev->dev, "unable to config video\n");
> - goto err_clock;
> + return ret;
> }
>
> platform_set_drvdata(pdev, dp);
>
> return 0;
> -
> -err_clock:
> - clk_put(dp->clock);
> -
> - return ret;
> }
>
> static int __devexit exynos_dp_remove(struct platform_device *pdev)
> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
> pdata->phy_exit();
>
> clk_disable(dp->clock);
> - clk_put(dp->clock);
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH 1/4] video: Add support for the Solomon SSD1307 OLED Controller
From: Shawn Guo @ 2012-08-02 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <501904CB.9040104@free-electrons.com>
On Wed, Aug 01, 2012 at 12:28:27PM +0200, Maxime Ripard wrote:
> Thanks for the tip.
> However, I'm not sure this device will be mxs specific, since this
> controller is used on some other devices as well (I know for example
> that some uses it with the Arduino, even though it's not related to
> Linux), so relying on mxs-specific capabilities here might not be that
> great.
>
Ok, agreed. In that case, putting "1" in last cell of oled-reset-gpio
does not make any point then.
+Examples:
+ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ oled-reset-gpio = <&gpio2 7 1>;
+ oled-reset-active-low;
+};
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] video: exynos-mipi-dsi: Add missing static storage class specifiers
From: Sachin Kamat @ 2012-08-02 6:26 UTC (permalink / raw)
To: linux-fbdev
Fixes the following sparse warnings:
drivers/video/exynos/exynos_mipi_dsi.c:208:22: warning:
symbol 'exynos_mipi_dsi_find_lcd_device' was not declared. Should it be static?
drivers/video/exynos/exynos_mipi_dsi.c:268:22: warning:
symbol 'exynos_mipi_dsi_bind_lcd_ddi' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/exynos/exynos_mipi_dsi.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 4bc2b8a..ef68228 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -205,7 +205,8 @@ int exynos_mipi_dsi_register_lcd_device(struct mipi_dsim_lcd_device *lcd_dev)
return 0;
}
-struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(struct mipi_dsim_lcd_driver *lcd_drv)
+static struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(
+ struct mipi_dsim_lcd_driver *lcd_drv)
{
struct mipi_dsim_ddi *dsim_ddi, *next;
struct mipi_dsim_lcd_device *lcd_dev;
@@ -265,7 +266,8 @@ int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv)
}
-struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(struct mipi_dsim_device *dsim,
+static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(
+ struct mipi_dsim_device *dsim,
const char *name)
{
struct mipi_dsim_ddi *dsim_ddi, *next;
--
1.7.4.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: use devm_clk_get()
From: Jingoo Han @ 2012-08-02 6:59 UTC (permalink / raw)
To: linux-fbdev
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_clk_get() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 24 +++++-------------------
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 69bf9d0..6c95126 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1398,17 +1398,16 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
spin_lock_init(&sfb->slock);
- sfb->bus_clk = clk_get(dev, "lcd");
+ sfb->bus_clk = devm_clk_get(dev, "lcd");
if (IS_ERR(sfb->bus_clk)) {
dev_err(dev, "failed to get bus clock\n");
- ret = PTR_ERR(sfb->bus_clk);
- goto err_sfb;
+ return PTR_ERR(sfb->bus_clk);
}
clk_enable(sfb->bus_clk);
if (!sfb->variant.has_clksel) {
- sfb->lcd_clk = clk_get(dev, "sclk_fimd");
+ sfb->lcd_clk = devm_clk_get(dev, "sclk_fimd");
if (IS_ERR(sfb->lcd_clk)) {
dev_err(dev, "failed to get lcd clock\n");
ret = PTR_ERR(sfb->lcd_clk);
@@ -1421,12 +1420,6 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
pm_runtime_enable(sfb->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to find registers\n");
- ret = -ENOENT;
- goto err_lcd_clk;
- }
-
sfb->regs = devm_request_and_ioremap(dev, res);
if (!sfb->regs) {
dev_err(dev, "failed to map registers\n");
@@ -1510,16 +1503,12 @@ err_pm_runtime:
err_lcd_clk:
pm_runtime_disable(sfb->dev);
- if (!sfb->variant.has_clksel) {
+ if (!sfb->variant.has_clksel)
clk_disable(sfb->lcd_clk);
- clk_put(sfb->lcd_clk);
- }
err_bus_clk:
clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
-err_sfb:
return ret;
}
@@ -1541,13 +1530,10 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
if (sfb->windows[win])
s3c_fb_release_win(sfb, sfb->windows[win]);
- if (!sfb->variant.has_clksel) {
+ if (!sfb->variant.has_clksel)
clk_disable(sfb->lcd_clk);
- clk_put(sfb->lcd_clk);
- }
clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
--
1.7.1
^ permalink raw reply related
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-08-02 8:00 UTC (permalink / raw)
To: Stephen Warren
Cc: Stephen Warren, Thierry Reding, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <50170EA0.1010408@wwwdotorg.org>
On 07/31/2012 07:45 AM, Stephen Warren wrote:
> Oh I see. That's a little confusing. Why not just reference the relevant
> resources directly in each step; something more like:
>
> gpio@1 {
> action = "enable-gpio";
> gpio = <&gpio 1 0>;
> };
>
> I guess that might make parsing/building a little harder, since you'd
> have to detect when you'd already done gpio_request() on a given GPIO
> and not repeat it or something like that, but to me this makes the DT a
> lot easier to comprehend.
I tried to move towards having the phandles directly in the sequences
themselves - that reminded me why I did not do that in the first place.
Let's say we have a sequence like this (reg property omitted on purpose):
power-on-sequence {
step@0 {
regulator = <&backlight_reg>;
enable;
};
step@1 {
delay = <10000>;
};
step@2 {
pwm = <&pwm 2 5000000>;
enable;
};
step@3 {
gpio = <&gpio 28 0>;
enable;
};
};
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be infered by the name of the
property. The hard part is resolving the resource from the phandle - it
seems like the API just does not allow to do this. GPIO has
of_get_named_gpio, but AFAIK there are no equivalent for regulator
consumer and PWM: the only way to use the DT with them is through
get_regulator and get_pwm which work at the device level.
Or is there a way that I overlooked?
Thanks,
Alex.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-08-02 8:21 UTC (permalink / raw)
To: Alex Courbot
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <501A338D.7080105-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >Oh I see. That's a little confusing. Why not just reference the relevant
> >resources directly in each step; something more like:
> >
> > gpio@1 {
> > action = "enable-gpio";
> > gpio = <&gpio 1 0>;
> > };
> >
> >I guess that might make parsing/building a little harder, since you'd
> >have to detect when you'd already done gpio_request() on a given GPIO
> >and not repeat it or something like that, but to me this makes the DT a
> >lot easier to comprehend.
>
> I tried to move towards having the phandles directly in the
> sequences themselves - that reminded me why I did not do that in the
> first place. Let's say we have a sequence like this (reg property
> omitted on purpose):
>
> power-on-sequence {
> step@0 {
> regulator = <&backlight_reg>;
> enable;
> };
> step@1 {
> delay = <10000>;
> };
> step@2 {
> pwm = <&pwm 2 5000000>;
> enable;
> };
> step@3 {
> gpio = <&gpio 28 0>;
> enable;
> };
> };
>
> The problem is, how do we turn these phandles into the resource of
> interest. The type of the resource can be infered by the name of the
> property. The hard part is resolving the resource from the phandle -
> it seems like the API just does not allow to do this. GPIO has
> of_get_named_gpio, but AFAIK there are no equivalent for regulator
> consumer and PWM: the only way to use the DT with them is through
> get_regulator and get_pwm which work at the device level.
>
> Or is there a way that I overlooked?
No, you are right. Perhaps we should add exported functions that do the
equivalent of of_pwm_request() or the regulator_dev_lookup() and
of_get_regulator() pair.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-08-02 8:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120802082157.GA14866-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> Oh I see. That's a little confusing. Why not just reference the relevant
>>> resources directly in each step; something more like:
>>>
>>> gpio@1 {
>>> action = "enable-gpio";
>>> gpio = <&gpio 1 0>;
>>> };
>>>
>>> I guess that might make parsing/building a little harder, since you'd
>>> have to detect when you'd already done gpio_request() on a given GPIO
>>> and not repeat it or something like that, but to me this makes the DT a
>>> lot easier to comprehend.
>>
>> I tried to move towards having the phandles directly in the
>> sequences themselves - that reminded me why I did not do that in the
>> first place. Let's say we have a sequence like this (reg property
>> omitted on purpose):
>>
>> power-on-sequence {
>> step@0 {
>> regulator = <&backlight_reg>;
>> enable;
>> };
>> step@1 {
>> delay = <10000>;
>> };
>> step@2 {
>> pwm = <&pwm 2 5000000>;
>> enable;
>> };
>> step@3 {
>> gpio = <&gpio 28 0>;
>> enable;
>> };
>> };
>>
>> The problem is, how do we turn these phandles into the resource of
>> interest. The type of the resource can be infered by the name of the
>> property. The hard part is resolving the resource from the phandle -
>> it seems like the API just does not allow to do this. GPIO has
>> of_get_named_gpio, but AFAIK there are no equivalent for regulator
>> consumer and PWM: the only way to use the DT with them is through
>> get_regulator and get_pwm which work at the device level.
>>
>> Or is there a way that I overlooked?
>
> No, you are right. Perhaps we should add exported functions that do the
> equivalent of of_pwm_request() or the regulator_dev_lookup() and
> of_get_regulator() pair.
How would that be looked with respect to "good DT practices"? I can
somehow understand the wish to restrain DT access to these functions
that integrate well with current workflows. Aren't we going to be
frowned upon if we make more low-level functions public?
Alex.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-08-02 8:45 UTC (permalink / raw)
To: Alex Courbot
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <501A3A00.7070207@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
> On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> >>On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>>Oh I see. That's a little confusing. Why not just reference the relevant
> >>>resources directly in each step; something more like:
> >>>
> >>> gpio@1 {
> >>> action = "enable-gpio";
> >>> gpio = <&gpio 1 0>;
> >>> };
> >>>
> >>>I guess that might make parsing/building a little harder, since you'd
> >>>have to detect when you'd already done gpio_request() on a given GPIO
> >>>and not repeat it or something like that, but to me this makes the DT a
> >>>lot easier to comprehend.
> >>
> >>I tried to move towards having the phandles directly in the
> >>sequences themselves - that reminded me why I did not do that in the
> >>first place. Let's say we have a sequence like this (reg property
> >>omitted on purpose):
> >>
> >> power-on-sequence {
> >> step@0 {
> >> regulator = <&backlight_reg>;
> >> enable;
> >> };
> >> step@1 {
> >> delay = <10000>;
> >> };
> >> step@2 {
> >> pwm = <&pwm 2 5000000>;
> >> enable;
> >> };
> >> step@3 {
> >> gpio = <&gpio 28 0>;
> >> enable;
> >> };
> >> };
> >>
> >>The problem is, how do we turn these phandles into the resource of
> >>interest. The type of the resource can be infered by the name of the
> >>property. The hard part is resolving the resource from the phandle -
> >>it seems like the API just does not allow to do this. GPIO has
> >>of_get_named_gpio, but AFAIK there are no equivalent for regulator
> >>consumer and PWM: the only way to use the DT with them is through
> >>get_regulator and get_pwm which work at the device level.
> >>
> >>Or is there a way that I overlooked?
> >
> >No, you are right. Perhaps we should add exported functions that do the
> >equivalent of of_pwm_request() or the regulator_dev_lookup() and
> >of_get_regulator() pair.
>
> How would that be looked with respect to "good DT practices"? I can
> somehow understand the wish to restrain DT access to these functions
> that integrate well with current workflows. Aren't we going to be
> frowned upon if we make more low-level functions public?
Yes, I think that's exactly what will happen.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-08-02 9:20 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20120802084541.GA15042@avionic-0098.adnet.avionic-design.de>
On Thu 02 Aug 2012 05:45:41 PM JST, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
>> On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
>>>> Old Signed by an unknown key
>>>
>>> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
>>>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>>>> Oh I see. That's a little confusing. Why not just reference the relevant
>>>>> resources directly in each step; something more like:
>>>>>
>>>>> gpio@1 {
>>>>> action = "enable-gpio";
>>>>> gpio = <&gpio 1 0>;
>>>>> };
>>>>>
>>>>> I guess that might make parsing/building a little harder, since you'd
>>>>> have to detect when you'd already done gpio_request() on a given GPIO
>>>>> and not repeat it or something like that, but to me this makes the DT a
>>>>> lot easier to comprehend.
>>>>
>>>> I tried to move towards having the phandles directly in the
>>>> sequences themselves - that reminded me why I did not do that in the
>>>> first place. Let's say we have a sequence like this (reg property
>>>> omitted on purpose):
>>>>
>>>> power-on-sequence {
>>>> step@0 {
>>>> regulator = <&backlight_reg>;
>>>> enable;
>>>> };
>>>> step@1 {
>>>> delay = <10000>;
>>>> };
>>>> step@2 {
>>>> pwm = <&pwm 2 5000000>;
>>>> enable;
>>>> };
>>>> step@3 {
>>>> gpio = <&gpio 28 0>;
>>>> enable;
>>>> };
>>>> };
>>>>
>>>> The problem is, how do we turn these phandles into the resource of
>>>> interest. The type of the resource can be infered by the name of the
>>>> property. The hard part is resolving the resource from the phandle -
>>>> it seems like the API just does not allow to do this. GPIO has
>>>> of_get_named_gpio, but AFAIK there are no equivalent for regulator
>>>> consumer and PWM: the only way to use the DT with them is through
>>>> get_regulator and get_pwm which work at the device level.
>>>>
>>>> Or is there a way that I overlooked?
>>>
>>> No, you are right. Perhaps we should add exported functions that do the
>>> equivalent of of_pwm_request() or the regulator_dev_lookup() and
>>> of_get_regulator() pair.
>>
>> How would that be looked with respect to "good DT practices"? I can
>> somehow understand the wish to restrain DT access to these functions
>> that integrate well with current workflows. Aren't we going to be
>> frowned upon if we make more low-level functions public?
>
> Yes, I think that's exactly what will happen.
Probably not worth to try this then?
Alex.
^ permalink raw reply
* Re: [RFC PATCH 22/29] OMAPDSS: DISPC: Setup writeback go, enable and channel_in functions
From: Mahapatra, Chandrabhanu @ 2012-08-02 10:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, rohitkc, linux-omap, linux-fbdev
In-Reply-To: <1324989432-3625-23-git-send-email-archit@ti.com>
On Tue, Dec 27, 2011 at 6:07 PM, Archit Taneja <archit@ti.com> wrote:
> Fill up dispc_wb_go(), dispc_wb_go_busy(), dispc_wb_enable() and
> dispc_wb_get_channel_in()/set_channel_in() with writeback register writes. Make
> a minor modification in dss_wb_write_regs_extra() to pass the plane_id instead
> of the writeback id when calling dispc_wb_set_channel_in().
>
> Setup dispc_wb_enable() as dispc_enable_lcd_out() function and wait for the
> FRAMEDONEWB interrupt while disabling writeback.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 2 +-
> drivers/video/omap2/dss/dispc.c | 68 +++++++++++++++++++++++++++++++++++----
> drivers/video/omap2/dss/dss.h | 2 +-
> 3 files changed, 63 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index dd1fd419..57b061f 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -690,7 +690,7 @@ static void dss_wb_write_regs_extra(struct omap_dss_writeback *wb)
> if (!wp->extra_info_dirty)
> return;
>
> - dispc_wb_set_channel_in(wb->id, wp->channel_in);
> + dispc_wb_set_channel_in(wb->plane_id, wp->channel_in);
> dispc_ovl_set_fifo_threshold(wb->plane_id, wp->fifo_low, wp->fifo_high);
>
> wp->extra_info_dirty = false;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index c7de56d..cbce120 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -510,12 +510,26 @@ void dispc_mgr_go(enum omap_channel channel)
>
> bool dispc_wb_go_busy(int id)
> {
> - return false;
> + return REG_GET(DISPC_CONTROL2, 6, 6) = 1;
> }
>
> void dispc_wb_go(int id)
> {
> - return;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + bool enable, go;
> +
> + enable = REG_GET(DISPC_OVL_ATTRIBUTES(wb->plane_id), 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_ovl_write_firh_reg(enum omap_plane plane, int reg, u32 value)
> @@ -903,16 +917,24 @@ static enum omap_channel dispc_ovl_get_channel_out(enum omap_plane plane)
> return channel;
> }
>
> -void dispc_wb_set_channel_in(int id, enum dss_writeback_channel_in ch_in)
> +void dispc_wb_set_channel_in(int plane, enum dss_writeback_channel_in ch_in)
> {
> - return;
> + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ch_in, 18, 16);
> }
>
> static enum omap_channel dispc_wb_get_channel_in(int plane)
> {
> - /* Return LCD channel for now */
> + int channel_in = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 18, 16);
>
> - return OMAP_DSS_CHANNEL_LCD;
> + switch (channel_in) {
> + case OMAP_DSS_WB_LCD2_MGR:
> + return OMAP_DSS_CHANNEL_LCD2;
> + case OMAP_DSS_WB_TV_MGR:
> + return OMAP_DSS_CHANNEL_DIGIT;
> + case OMAP_DSS_WB_LCD1_MGR:
> + default:
> + return OMAP_DSS_CHANNEL_LCD;
> + };
> }
>
What about other cases of pipelines and overlays here? You have
considered only overlays and that too ignored OMAP_DSS_CHANNEL_LCD3.
The channel_in parameter of DISPC_WB_ATTRIBUTES does handle the
following cases as well:
0x0: Primary LCD overlay output
0x1: Secondary LCD output
0x2: TV overlay output
0x7: Third LCD output
0x3: Graphics pipeline output
0x4: Video1 pipeline output
0x5: Video2 pipeline output
0x6: Video3 pipeline output
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> @@ -2138,7 +2160,39 @@ void dispc_mgr_enable(enum omap_channel channel, bool enable)
>
> void dispc_wb_enable(int id, bool enable)
> {
> - return;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + enum omap_plane plane = wb->plane_id;
> + 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");
> + }
> }
>
> void dispc_lcd_enable_signal_polarity(bool act_high)
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 69b4793..c05658b 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -498,7 +498,7 @@ void dispc_wb_go(int id);
> int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi,
> u16 in_width, u16 in_height);
> void dispc_wb_enable(int id, bool enable);
> -void dispc_wb_set_channel_in(int id, enum dss_writeback_channel_in ch_in);
> +void dispc_wb_set_channel_in(int plane, enum dss_writeback_channel_in ch_in);
>
> /* VENC */
> #ifdef CONFIG_OMAP2_DSS_VENC
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ permalink raw reply
* Re: [RFC PATCH 21/29] OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
From: Chandrabhanu Mahapatra @ 2012-08-02 10:22 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, rohitkc, linux-omap, linux-fbdev
In-Reply-To: <1324989432-3625-22-git-send-email-archit@ti.com>
On Tuesday 27 December 2011 06:07 PM, Archit Taneja wrote:
> Call dispc_plane_setup() through dispc_wb_setup() to configure overlay-like
> parameters. Create a helper function in writeback.c called dss_wb_calc_params()
> which for now calculates the input width and height which goes to writeback.
> Create a dummy dispc function which returns the channel of the manager to which
> the writeback pipeline is connected.
>
> The parameters in dispc_plane_setup() which do not hold for writeback are filled
> passed as zeroes or false, dispc_plane_setup() takes care of not configuring
> them if the plane is writeback.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 5 ++++-
> drivers/video/omap2/dss/dispc.c | 33 +++++++++++++++++++++++++++++++--
> drivers/video/omap2/dss/dss.h | 6 +++++-
> drivers/video/omap2/dss/writeback.c | 17 +++++++++++++++++
> 4 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index a17cc47..dd1fd419 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -661,6 +661,7 @@ static void dss_wb_write_regs(struct omap_dss_writeback *wb)
> {
> struct wb_priv_data *wp = get_wb_priv(wb);
> struct omap_dss_writeback_info *wi;
> + u16 in_width, in_height;
> int r;
>
> if (!wp->enabled || !wp->info_dirty)
> @@ -670,7 +671,9 @@ static void dss_wb_write_regs(struct omap_dss_writeback *wb)
>
> wi = &wp->info;
>
> - r = dispc_wb_setup(wb->id, wi);
> + dss_wb_calc_params(wb, wi, &in_width, &in_height);
> +
> + r = dispc_wb_setup(wb->id, wi, in_width, in_height);
> if (r) {
> DSSERR("dispc_wb_setup failed\n");
> return;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 3a40f8e..c7de56d 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -908,6 +908,13 @@ void dispc_wb_set_channel_in(int id, enum dss_writeback_channel_in ch_in)
> return;
> }
>
> +static enum omap_channel dispc_wb_get_channel_in(int plane)
> +{
> + /* Return LCD channel for now */
> +
> + return OMAP_DSS_CHANNEL_LCD;
> +}
> +
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> enum omap_burst_size burst_size)
> {
> @@ -1935,9 +1942,31 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
> return r;
> }
>
> -int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi)
> +int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi,
> + u16 in_width, u16 in_height)
> {
> - return 0;
> + int r;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + const int pos_x = 0, pos_y = 0;
> + const u8 zorder = 0, global_alpha = 0;
> + const bool chroma_upscale = false, ilace = false, replication = false;
> + enum omap_channel channel;
> +
> + channel = dispc_wb_get_channel_in(wb->plane_id);
> +
> + DSSDBG("dispc_wb_setup %d, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
> + "rot %d, mir %d, chan %d\n",
> + wb->id, wi->paddr, wi->p_uv_addr, in_width, in_height,
> + wi->buf_width, wi->buf_height, wi->color_mode, wi->rotation,
> + wi->mirror, channel);
> +
> + r = dispc_plane_setup(wb->plane_id, channel, wb->caps, wi->paddr,
> + wi->p_uv_addr, in_width, pos_x, pos_y, in_width, in_height,
> + wi->buf_width, wi->buf_height, wi->color_mode, wi->rotation,
> + wi->mirror, zorder, wi->pre_mult_alpha, global_alpha,
> + wi->rotation_type, chroma_upscale, ilace, replication);
The only note worthy difference here is use of omap_dss_writeback_info
*wi instead of omap_overlay_info *oi in dispc_ovl_setup(). If
omap_overlay_info can be used instead of omap_dss_writeback_info then
the same dispc_ovl_setup() would have been used to handle writeback as a
plane just like others but with extra checks for (plane = OMAP_DSS_WB).
I think this way it would have been much cleaner otherwise it looks good.
> +
> + return r;
> }
>
> int dispc_ovl_enable(enum omap_plane plane, bool enable)
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 1b128f1..69b4793 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -249,6 +249,9 @@ void dss_init_writeback(void);
> void dss_uninit_writeback(void);
> int writeback_init_display(struct omap_dss_device *dssdev);
> enum dss_writeback_channel_in dss_wb_calc_channel_in(struct omap_dss_writeback *wb);
> +void dss_wb_calc_params(struct omap_dss_writeback *wb,
> + struct omap_dss_writeback_info *wi, u16 *in_width,
> + u16 *in_height);
> int dss_wb_simple_check(struct omap_dss_writeback *wb,
> const struct omap_dss_writeback_info *info);
>
> @@ -492,7 +495,8 @@ void dispc_mgr_setup(enum omap_channel channel,
>
> bool dispc_wb_go_busy(int id);
> void dispc_wb_go(int id);
> -int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi);
> +int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi,
> + u16 in_width, u16 in_height);
> void dispc_wb_enable(int id, bool enable);
> void dispc_wb_set_channel_in(int id, enum dss_writeback_channel_in ch_in);
>
> diff --git a/drivers/video/omap2/dss/writeback.c b/drivers/video/omap2/dss/writeback.c
> index 14103bf..7c4e9c0 100644
> --- a/drivers/video/omap2/dss/writeback.c
> +++ b/drivers/video/omap2/dss/writeback.c
> @@ -141,6 +141,23 @@ enum dss_writeback_channel_in dss_wb_calc_channel_in(struct omap_dss_writeback *
> }
> }
>
> +void dss_wb_calc_params(struct omap_dss_writeback *wb,
> + struct omap_dss_writeback_info *wi, u16 *in_width,
> + u16 *in_height)
> +{
> + struct omap_video_timings timings;
> + struct omap_dss_device *dssdev;
> + struct omap_overlay_manager *mgr;
> +
> + mgr = wb->dssdev->manager;
> + dssdev = mgr->get_display(mgr);
> +
> + dssdev->driver->get_timings(dssdev, &timings);
> +
> + *in_width = timings.x_res;
> + *in_height = timings.y_res;
> +}
> +
> int dss_wb_simple_check(struct omap_dss_writeback *wb,
> const struct omap_dss_writeback_info *info)
> {
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ 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