* [PATCH v3 2/5] OMAPDSS: Apply manager timings instead of direct DISPC writes
From: Archit Taneja @ 2012-05-08 10:10 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336471096-21096-1-git-send-email-archit@ti.com>
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dpi.c | 2 +-
drivers/video/omap2/dss/dsi.c | 5 ++---
drivers/video/omap2/dss/hdmi.c | 2 +-
drivers/video/omap2/dss/rfbi.c | 4 ++--
drivers/video/omap2/dss/sdi.c | 2 +-
drivers/video/omap2/dss/venc.c | 2 +-
6 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cec1166..5d84ab0 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t->pixel_clock = pck;
}
- dispc_mgr_set_timings(dssdev->manager->id, t);
+ dss_mgr_set_timings(dssdev->manager, t);
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b6cf03c..db73598 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4219,13 +4219,12 @@ static int dsi_display_init_dispc(struct omap_dss_device *dssdev)
dispc_mgr_enable_stallmode(dssdev->manager->id, true);
dispc_mgr_enable_fifohandcheck(dssdev->manager->id, 1);
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
} else {
dispc_mgr_enable_stallmode(dssdev->manager->id, false);
dispc_mgr_enable_fifohandcheck(dssdev->manager->id, 0);
- dispc_mgr_set_timings(dssdev->manager->id,
- &dssdev->panel.timings);
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
}
dispc_mgr_set_lcd_display_type(dssdev->manager->id,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 56f6e9c..8d4ff8c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -376,7 +376,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_gamma_table(0);
/* tv size */
- dispc_mgr_set_timings(dssdev->manager->id, &dssdev->panel.timings);
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 1);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a81ffcb..feadfab 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -320,7 +320,7 @@ static void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
DSSDBG("rfbi_transfer_area %dx%d\n", width, height);
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
dispc_mgr_enable(dssdev->manager->id, true);
@@ -804,7 +804,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
if (*w = 0 || *h = 0)
return -EINVAL;
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
return 0;
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 741b834..67fbe7c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -107,7 +107,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
}
- dispc_mgr_set_timings(dssdev->manager->id, t);
+ dss_mgr_set_timings(dssdev->manager, t);
r = dss_set_clock_div(&dss_cinfo);
if (r)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 30bbb63..e237464 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -444,7 +444,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
timings = dssdev->panel.timings;
timings.y_res /= 2;
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
r = regulator_enable(venc.vdda_dac_reg);
if (r)
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 3/5] OMAPDSS: MANAGER: Create a function to check manager timings
From: Archit Taneja @ 2012-05-08 10:10 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336471096-21096-1-git-send-email-archit@ti.com>
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.
Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dpi.c | 2 +-
drivers/video/omap2/dss/dss.h | 4 +++-
drivers/video/omap2/dss/manager.c | 15 +++++++++++++++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 49015b8..2829a92 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2479,7 +2479,7 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
}
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings)
+ const struct omap_video_timings *timings)
{
bool timings_ok;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5d84ab0..8127f46 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -312,7 +312,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
unsigned long pck;
struct dispc_clock_info dispc_cinfo;
- if (!dispc_mgr_timings_ok(dssdev->manager->id, timings))
+ if (!dss_mgr_check_timings(dssdev->manager, timings))
return -EINVAL;
if (timings->pixel_clock = 0)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ca59481..7c9b9bc 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -208,6 +208,8 @@ int dss_init_overlay_managers(struct platform_device *pdev);
void dss_uninit_overlay_managers(struct platform_device *pdev);
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -414,7 +416,7 @@ void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings);
+ const struct omap_video_timings *timings);
unsigned long dispc_fclk_rate(void);
void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index e736460..566fbba 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -654,6 +654,17 @@ static int dss_mgr_check_zorder(struct omap_overlay_manager *mgr,
return 0;
}
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings)
+{
+ if (!dispc_mgr_timings_ok(mgr->id, timings)) {
+ DSSERR("check_manager: invalid timings\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -668,6 +679,10 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
+ r = dss_mgr_check_timings(mgr, &dssdev->panel.timings);
+ if (r)
+ return r;
+
list_for_each_entry(ovl, &mgr->overlays, list) {
struct omap_overlay_info *oi;
int r;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08 10:10 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336471096-21096-1-git-send-email-archit@ti.com>
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings(in private data) to dss_mgr_check(). Remove the need
of passing omap_dss_device structs in the functions which check for overlay and
managers.
Have some initial values for manager timings in apply_init(), these would ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 44 ++++++++++++++++++++++++++-----------
drivers/video/omap2/dss/dss.h | 7 +++--
drivers/video/omap2/dss/manager.c | 6 ++--
drivers/video/omap2/dss/overlay.c | 20 +++++++---------
4 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 57686f6..7d59caf 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -137,10 +137,30 @@ static struct mgr_priv_data *get_mgr_priv(struct omap_overlay_manager *mgr)
void dss_apply_init(void)
{
const int num_ovls = dss_feat_get_num_ovls();
+ const int num_mgrs = dss_feat_get_num_ovls();
int i;
+ /* Use dummy manager timings during initialization */
+ struct omap_video_timings timings = {
+ .hsw = 1,
+ .hfp = 1,
+ .hbp = 1,
+ .vsw = 1,
+ .vfp = 0,
+ .vbp = 0,
+ .x_res = dss_feat_get_param_max(FEAT_PARAM_MGR_WIDTH),
+ .y_res = dss_feat_get_param_max(FEAT_PARAM_MGR_HEIGHT),
+ };
spin_lock_init(&data_lock);
+ for (i = 0; i < num_mgrs; i++) {
+ struct mgr_priv_data *mp;
+
+ mp = &dss_data.mgr_priv_data_array[i];
+
+ mp->timings = timings;
+ }
+
for (i = 0; i < num_ovls; ++i) {
struct ovl_priv_data *op;
@@ -181,7 +201,7 @@ static bool mgr_manual_update(struct omap_overlay_manager *mgr)
}
static int dss_check_settings_low(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev, bool applying)
+ bool applying)
{
struct omap_overlay_info *oi;
struct omap_overlay_manager_info *mi;
@@ -211,26 +231,24 @@ static int dss_check_settings_low(struct omap_overlay_manager *mgr,
ois[ovl->id] = oi;
}
- return dss_mgr_check(mgr, dssdev, mi, ois);
+ return dss_mgr_check(mgr, mi, &mp->timings, ois);
}
/*
* check manager and overlay settings using overlay_info from data->info
*/
-static int dss_check_settings(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, false);
+ return dss_check_settings_low(mgr, false);
}
/*
* check manager and overlay settings using overlay_info from ovl->info if
* dirty and from data->info otherwise
*/
-static int dss_check_settings_apply(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings_apply(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, true);
+ return dss_check_settings_low(mgr, true);
}
static bool need_isr(void)
@@ -684,7 +702,7 @@ static void dss_write_regs(void)
if (!mp->enabled || mgr_manual_update(mgr) || mp->busy)
continue;
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("cannot write registers for manager %s: "
"illegal configuration\n", mgr->name);
@@ -751,7 +769,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
WARN_ON(mp->updating);
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("cannot start manual update: illegal configuration\n");
spin_unlock_irqrestore(&data_lock, flags);
@@ -898,7 +916,7 @@ int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
spin_lock_irqsave(&data_lock, flags);
- r = dss_check_settings_apply(mgr, mgr->device);
+ r = dss_check_settings_apply(mgr);
if (r) {
spin_unlock_irqrestore(&data_lock, flags);
DSSERR("failed to apply settings: illegal configuration.\n");
@@ -1091,7 +1109,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
mp->enabled = true;
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("failed to enable manager %d: check_settings failed\n",
mgr->id);
@@ -1463,7 +1481,7 @@ int dss_ovl_enable(struct omap_overlay *ovl)
op->enabling = true;
- r = dss_check_settings(ovl->manager, ovl->manager->device);
+ r = dss_check_settings(ovl->manager);
if (r) {
DSSERR("failed to enable overlay %d: check_settings failed\n",
ovl->id);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 7c9b9bc..eff3d7f 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -179,6 +179,7 @@ int dss_mgr_set_device(struct omap_overlay_manager *mgr,
int dss_mgr_unset_device(struct omap_overlay_manager *mgr);
void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
struct omap_video_timings *timings);
+const struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr);
bool dss_ovl_is_enabled(struct omap_overlay *ovl);
int dss_ovl_enable(struct omap_overlay *ovl);
@@ -211,8 +212,8 @@ int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
+ const struct omap_video_timings *mgr_timings,
struct omap_overlay_info **overlay_infos);
/* overlay */
@@ -222,8 +223,8 @@ void dss_overlay_setup_dispc_manager(struct omap_overlay_manager *mgr);
void dss_recheck_connections(struct omap_dss_device *dssdev, bool force);
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info);
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev);
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings);
/* DSS */
int dss_init_platform_driver(void);
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index 566fbba..0cbcde4 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -666,8 +666,8 @@ int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
}
int dss_mgr_check(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
+ const struct omap_video_timings *mgr_timings,
struct omap_overlay_info **overlay_infos)
{
struct omap_overlay *ovl;
@@ -679,7 +679,7 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
- r = dss_mgr_check_timings(mgr, &dssdev->panel.timings);
+ r = dss_mgr_check_timings(mgr, mgr_timings);
if (r)
return r;
@@ -692,7 +692,7 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
if (oi = NULL)
continue;
- r = dss_ovl_check(ovl, oi, dssdev);
+ r = dss_ovl_check(ovl, oi, mgr_timings);
if (r)
return r;
}
diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index 6e82181..74db90c 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -631,16 +631,14 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
return 0;
}
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev)
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings)
{
u16 outw, outh;
- u16 dw, dh;
+ u16 mgr_width, mgr_height;
- if (dssdev = NULL)
- return 0;
-
- dssdev->driver->get_resolution(dssdev, &dw, &dh);
+ mgr_width = mgr_timings->x_res;
+ mgr_height = mgr_timings->y_res;
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) = 0) {
outw = info->width;
@@ -657,17 +655,17 @@ int dss_ovl_check(struct omap_overlay *ovl,
outh = info->out_height;
}
- if (dw < info->pos_x + outw) {
+ if (mgr_width < info->pos_x + outw) {
DSSERR("overlay %d horizontally not inside the display area "
"(%d + %d >= %d)\n",
- ovl->id, info->pos_x, outw, dw);
+ ovl->id, info->pos_x, outw, mgr_width);
return -EINVAL;
}
- if (dh < info->pos_y + outh) {
+ if (mgr_height < info->pos_y + outh) {
DSSERR("overlay %d vertically not inside the display area "
"(%d + %d >= %d)\n",
- ovl->id, info->pos_y, outh, dh);
+ ovl->id, info->pos_y, outh, mgr_height);
return -EINVAL;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 5/5] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
From: Archit Taneja @ 2012-05-08 10:10 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336471096-21096-1-git-send-email-archit@ti.com>
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings held by omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dpi.c | 2 ++
drivers/video/omap2/dss/hdmi.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8127f46..1650050 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -298,6 +298,8 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
dispc_runtime_put();
dss_runtime_put();
+ } else {
+ dss_mgr_set_timings(dssdev->manager, timings);
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8d4ff8c..32ad712 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -435,6 +435,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev)
r = hdmi_power_on(dssdev);
if (r)
DSSERR("failed to power on device\n");
+ } else {
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
}
}
--
1.7.5.4
^ permalink raw reply related
* Re: ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted
From: Christoph Fritz @ 2012-05-08 10:29 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120507215506.GA5063@lovely.krouter>
On Mon, May 07, 2012 at 11:55:06PM +0200, Christoph Fritz wrote:
> On Fri, May 04, 2012 at 03:28:45PM +0200, Christoph Fritz wrote:
> > On Fri, Apr 27, 2012 at 02:46:39PM +0100, Mark Brown wrote:
> > > On Fri, Apr 27, 2012 at 10:00:02AM +0200, Christoph Fritz wrote:
> > > > On Thu, 2012-04-26 at 22:37 +0100, Mark Brown wrote:
> > >
> > > > > The write will be suppresed if the register contents don't
> > > > > change which looks like what you're seeing here -
> > >
> > > > Can you imagine why the registers don't change?
> > >
> > > I can't immediately think of any reason, no - I'd step through or
> > > annotate the code and have a look.
> >
> > I'm still on.
> >
> > And while testing WM9712 its touchpad interface, connecting a 800x600
> > display (instead of the default 640x480 one) results in a gone sound and
> > input-device - pretty queer:
> >
> > WM9711/WM9712 SoC Audio Codec 0.4
> > asoc: platform pcm constructor failed
> > asoc: can't create pcm HiFi
> > asoc: failed to instantiate card PhyCORE-ac97-audio: -12
> >
> > I have to admit that I used this time a 3.2 kernel. I'll test with
> > current later these days.
>
> Same behaviour with 3.4.0-rc6:
>
> Framebuffer driver mx3fb configured for a 800x600 display:
>
> soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
> asoc: platform pcm constructor failed
> asoc: can't create pcm HiFi :-12
> asoc: failed to instantiate card PhyCORE-ac97-audio: -12
When I do decrease from 800x600 to 800x594, wm9712 works.
Any ideas?
>
>
> mx3fb configured for a 640x480 display:
> soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use
> snd_soc_register_card()
> asoc: wm9712-hifi <-> imx-ssi.0 mapping ok
>
>
> Thanks,
> -- Christoph
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-08 10:50 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336471096-21096-5-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
> In order to check the validity of overlay and manager info, there was a need to
> use the omap_dss_device struct to get the panel resolution. The manager's
> private data in APPLY now contains the manager timings. Hence, we don't need to
> rely on the display resolution any more.
>
> Pass the manager's timings(in private data) to dss_mgr_check(). Remove the need
> of passing omap_dss_device structs in the functions which check for overlay and
> managers.
>
> Have some initial values for manager timings in apply_init(), these would ensure
> that manager checks don't fail if an interface driver or a panel driver hasn't
> set the manager timings yet.
In what code patch were the initial values needed?
Checking the validity of all the settings is a bit tricky, but currently
I think, as a rule of thumb, we should accept any settings when things
are disabled. So, until the interface driver sets the timings before
enabling the output, all ovl/mgr settings should be allowed. And we
shouldn't even write any shadow registers until the moment the output is
enabled.
Except settings that do not depend on anything, like, if max ovl width
is 2048, it's fine to reject 2049+ width anytime.
> -int dss_ovl_check(struct omap_overlay *ovl,
> - struct omap_overlay_info *info, struct omap_dss_device *dssdev)
> +int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
> + const struct omap_video_timings *mgr_timings)
> {
> u16 outw, outh;
> - u16 dw, dh;
> + u16 mgr_width, mgr_height;
>
> - if (dssdev == NULL)
> - return 0;
> -
> - dssdev->driver->get_resolution(dssdev, &dw, &dh);
> + mgr_width = mgr_timings->x_res;
> + mgr_height = mgr_timings->y_res;
I think you could've just used the existing dw and dh variables, thus
avoiding the need to change the rest of the function. The 'd' refers to
display, which is more or less the same as mgr width.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] OMAPDSS: Apply manager timings instead of direct DISPC writes
From: Tomi Valkeinen @ 2012-05-08 10:59 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336471096-21096-3-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
> Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
> interface drivers. The latter function ensures that the timing related DISPC
> registers are configured according to the shadow register programming model.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 2 +-
> drivers/video/omap2/dss/dsi.c | 5 ++---
> drivers/video/omap2/dss/hdmi.c | 2 +-
> drivers/video/omap2/dss/rfbi.c | 4 ++--
> drivers/video/omap2/dss/sdi.c | 2 +-
> drivers/video/omap2/dss/venc.c | 2 +-
> 6 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index cec1166..5d84ab0 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
> t->pixel_clock = pck;
> }
>
> - dispc_mgr_set_timings(dssdev->manager->id, t);
> + dss_mgr_set_timings(dssdev->manager, t);
>
> return 0;
> }
I think you can now remove the dispc_mgr_go() from dpi.c in this patch.
And something else, which doesn't need to be fixed now, but just to
point out: dpi_set_timings() currently uses runtime_get to enable the
HW. If everything was in proper shape, this wouldn't be needed.
dpi_set_timings() would call apply.c's functions, and if the output is
disabled, the settings would just be stored in ram. So there wouldn't be
any need to enable the HW with runtime_get().
Then again, if we do change clock settings or non-shadow registers in
dpi_set_timings(), then that's not possible (at least via apply.c's
caching system).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Jean Delvare @ 2012-05-08 11:31 UTC (permalink / raw)
To: Mark Brown
Cc: Florian Tobias Schandinat, Dmitry Torokhov, Wolfram Sang,
linux-i2c, linux-input, linux-fbdev
In-Reply-To: <1336127208-17951-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Fri, 4 May 2012 11:26:48 +0100, Mark Brown wrote:
> Since there are uses for I2C_M_NOSTART which are much more sensible and
> standard than most of the protocol mangling functionality (the main one
> being gather writes to devices where something like a register address
> needs to be inserted before a block of data) create a new I2C_FUNC_NOSTART
> for this feature and update all the users to use it.
>
> Also strengthen the disrecommendation of the protocol mangling while we're
> at it.
>
> In the case of regmap-i2c we remove the requirement for mangling as
> I2C_M_NOSTART is the only mangling feature which is being used.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> Documentation/i2c/functionality | 8 +++++---
> Documentation/i2c/i2c-protocol | 9 ++++++++-
> drivers/base/regmap/regmap-i2c.c | 2 +-
> drivers/i2c/algos/i2c-algo-bit.c | 2 +-
> drivers/i2c/busses/i2c-nuc900.c | 3 ++-
> drivers/i2c/busses/i2c-s3c2410.c | 3 ++-
> drivers/input/joystick/as5011.c | 1 +
> drivers/video/matrox/matroxfb_maven.c | 1 +
> include/linux/i2c.h | 5 +++--
> 9 files changed, 24 insertions(+), 10 deletions(-)
> (...)
Applied with minor cleanups, thanks.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08 11:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336474223.1821.6.camel@lappyti>
On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
> On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
>> In order to check the validity of overlay and manager info, there was a need to
>> use the omap_dss_device struct to get the panel resolution. The manager's
>> private data in APPLY now contains the manager timings. Hence, we don't need to
>> rely on the display resolution any more.
>>
>> Pass the manager's timings(in private data) to dss_mgr_check(). Remove the need
>> of passing omap_dss_device structs in the functions which check for overlay and
>> managers.
>>
>> Have some initial values for manager timings in apply_init(), these would ensure
>> that manager checks don't fail if an interface driver or a panel driver hasn't
>> set the manager timings yet.
>
> In what code patch were the initial values needed?
I guess you meant code path. If a panel driver doesn't have set_timings
op, then we get into trouble with omapfb. The following steps happen:
- try to set timings of display
- create buffers, configure overlays according to omap_dss_device
- call mgr->apply()
- enable the panel
For panels which don't have set_timings populated, if apply is called,
the manager timings are still zero, and the mgr->apply fails when
dss_mgr_check() is called.
When the panel driver's enable is called, the timings are configured in
the interface drivers 'enable'. The enables(like
dpi_display_enable,dsi_display_enable) of all interface driver's call
dss_mgr_set_timings(), so we are sure that the timings are configured by
then. But there is no such guarantee at set timings.
Things used to work previously because we used to simply get the
connected panel and use its dimensions, if there was no panel connected,
we used to skip the check.
>
> Checking the validity of all the settings is a bit tricky, but currently
> I think, as a rule of thumb, we should accept any settings when things
> are disabled. So, until the interface driver sets the timings before
> enabling the output, all ovl/mgr settings should be allowed. And we
We have 2 ways to go about this, one is to have an initial set of
'always valid' values like I have done, the other option is to ignore
manager timing related checks if the manager is disabled, i.e all
configs are okay. To implement the second option, I think our function
dss_check_settings_low() would get more complicated. We would now have
to pass mp->enabled outside of apply, and pass it to dss_mgr_check()
which would further need to pass this to dss_ovl_check(). Hence I used
the first approach.
> shouldn't even write any shadow registers until the moment the output is
> enabled.
That's being done correctly even now I guess, with the checks for
mp->enabled in wrtie_regs() and set_go_bits().
>
> Except settings that do not depend on anything, like, if max ovl width
> is 2048, it's fine to reject 2049+ width anytime.
>
>> -int dss_ovl_check(struct omap_overlay *ovl,
>> - struct omap_overlay_info *info, struct omap_dss_device *dssdev)
>> +int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
>> + const struct omap_video_timings *mgr_timings)
>> {
>> u16 outw, outh;
>> - u16 dw, dh;
>> + u16 mgr_width, mgr_height;
>>
>> - if (dssdev = NULL)
>> - return 0;
>> -
>> - dssdev->driver->get_resolution(dssdev,&dw,&dh);
>> + mgr_width = mgr_timings->x_res;
>> + mgr_height = mgr_timings->y_res;
>
> I think you could've just used the existing dw and dh variables, thus
> avoiding the need to change the rest of the function. The 'd' refers to
> display, which is more or less the same as mgr width.
I'll fix this.
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-08 11:55 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA901EC.8020002@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
> On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
> > Checking the validity of all the settings is a bit tricky, but currently
> > I think, as a rule of thumb, we should accept any settings when things
> > are disabled. So, until the interface driver sets the timings before
> > enabling the output, all ovl/mgr settings should be allowed. And we
>
> We have 2 ways to go about this, one is to have an initial set of
> 'always valid' values like I have done, the other option is to ignore
> manager timing related checks if the manager is disabled, i.e all
> configs are okay. To implement the second option, I think our function
> dss_check_settings_low() would get more complicated. We would now have
> to pass mp->enabled outside of apply, and pass it to dss_mgr_check()
> which would further need to pass this to dss_ovl_check(). Hence I used
> the first approach.
I'm not sure about that. We already do it for overlay. In ovl.c we have
dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the
settings pass basic sanity check. The check sees if all the ovl & mgr
settings are compatible with each other.
Simple check is done when setting the config, called from
dss_ovl_set_info(). The proper check is done later when the actual
config is about to be taken into use.
If mp->enabled == false, can't we just skip dss_check_settings_low()
totally for that manager? We skip the check for ovls the same way.
> > shouldn't even write any shadow registers until the moment the output is
> > enabled.
>
> That's being done correctly even now I guess, with the checks for
> mp->enabled in wrtie_regs() and set_go_bits().
Yes, for timings. I was thinking more about the other settings done in
dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to
registers, so we need runtime_get for that.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
From: Tomi Valkeinen @ 2012-05-08 11:58 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote:
> The first patch in this series is a follow up on the previously posted series
> 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
> required for HDMI and DPI interfaces to work properly, it ensures manager
> timings are applied in the set_timing() ops for these interfaces.
>
> The next 3 patches remove some unnecessary usage of omap_dss_device pointer in
> DISPC and APPLY.
>
> The last 2 patches are miscellaneous fixes and are self explanatory.
>
> Reference tree containing this series:
>
> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes
>
> Tested on OMAP4 SDP.
>
> Archit Taneja (6):
> OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
> OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
> OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
> dispc_mgr_pclk_rate()
> OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
> OMAPDSS: Fix DSI_FCLK clock source selection
> OMAPDSS: DISPC: Remove Fake VSYNC support
The first four patches seem to be related (or at least based) to the
set_timings series (and the first patch you already had included in
later version).
Should I take the two last patches and apply them already, as they are
fine and don't depend on anything? You could add the first 4 patches
into the set_timings series.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
From: Tomi Valkeinen @ 2012-05-08 12:04 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336396828-29311-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote:
> The HDMI CORE registers are dumped incorrectly due to incorrect register offset
> calculations. They are also dumped in a random order, with some of the registers
> repeated. This series fixes these issues.
>
> The patches apply over:
>
> git://gitorious.org/linux-omap-dss2/linux.git dev
>
> Tested on OMAP4 SDP.
>
> Archit Taneja (2):
> OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
> OMAPDSS: HDMI: define and dump CORE registers in correct order
>
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 163 +++++++++++++++--------------
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +++++------
> 2 files changed, 109 insertions(+), 111 deletions(-)
Thanks, applying these.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
From: Archit Taneja @ 2012-05-08 12:21 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336478684.5761.30.camel@deskari>
Hi,
On Tuesday 08 May 2012 05:34 PM, Tomi Valkeinen wrote:
> On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote:
>> The HDMI CORE registers are dumped incorrectly due to incorrect register offset
>> calculations. They are also dumped in a random order, with some of the registers
>> repeated. This series fixes these issues.
>>
>> The patches apply over:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git dev
>>
>> Tested on OMAP4 SDP.
>>
>> Archit Taneja (2):
>> OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
>> OMAPDSS: HDMI: define and dump CORE registers in correct order
>>
>> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 163 +++++++++++++++--------------
>> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +++++------
>> 2 files changed, 109 insertions(+), 111 deletions(-)
>
> Thanks, applying these.
In the second patch, there are some unnecessary lines left in the
core_dump function():
- DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM);
- for (i = 0; i < HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE);
- for (i = 0; i < HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE);
- for (i = 0; i < HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE);
-
- for (i = 0; i < HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE);
- for (i = 0; i < HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE);
-
- for (i = 0; i < HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++)
- DUMPCOREAV2(i, HDMI_CORE_AV_GEN2_DBYTE);
So you will see 5 annoying empty lines, could you remove those when you
apply, i totally missed this out..
Thanks,
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
From: Archit Taneja @ 2012-05-08 12:24 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336478337.5761.29.camel@deskari>
On Tuesday 08 May 2012 05:28 PM, Tomi Valkeinen wrote:
> On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote:
>> The first patch in this series is a follow up on the previously posted series
>> 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
>> required for HDMI and DPI interfaces to work properly, it ensures manager
>> timings are applied in the set_timing() ops for these interfaces.
>>
>> The next 3 patches remove some unnecessary usage of omap_dss_device pointer in
>> DISPC and APPLY.
>>
>> The last 2 patches are miscellaneous fixes and are self explanatory.
>>
>> Reference tree containing this series:
>>
>> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes
>>
>> Tested on OMAP4 SDP.
>>
>> Archit Taneja (6):
>> OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
>> OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
>> OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
>> dispc_mgr_pclk_rate()
>> OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
>> OMAPDSS: Fix DSI_FCLK clock source selection
>> OMAPDSS: DISPC: Remove Fake VSYNC support
>
> The first four patches seem to be related (or at least based) to the
> set_timings series (and the first patch you already had included in
> later version).
>
> Should I take the two last patches and apply them already, as they are
> fine and don't depend on anything? You could add the first 4 patches
> into the set_timings series.
Yes, you can apply the last 2 patches.
Thanks,
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08 12:47 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336478139.5761.27.camel@deskari>
On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote:
> On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
>> On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
>
>>> Checking the validity of all the settings is a bit tricky, but currently
>>> I think, as a rule of thumb, we should accept any settings when things
>>> are disabled. So, until the interface driver sets the timings before
>>> enabling the output, all ovl/mgr settings should be allowed. And we
>>
>> We have 2 ways to go about this, one is to have an initial set of
>> 'always valid' values like I have done, the other option is to ignore
>> manager timing related checks if the manager is disabled, i.e all
>> configs are okay. To implement the second option, I think our function
>> dss_check_settings_low() would get more complicated. We would now have
>> to pass mp->enabled outside of apply, and pass it to dss_mgr_check()
>> which would further need to pass this to dss_ovl_check(). Hence I used
>> the first approach.
>
> I'm not sure about that. We already do it for overlay. In ovl.c we have
> dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the
> settings pass basic sanity check. The check sees if all the ovl& mgr
> settings are compatible with each other.
>
> Simple check is done when setting the config, called from
> dss_ovl_set_info(). The proper check is done later when the actual
> config is about to be taken into use.
>
> If mp->enabled = false, can't we just skip dss_check_settings_low()
> totally for that manager? We skip the check for ovls the same way.
Okay, this would work better I guess. If someone tries to enable the
manager without setting the timings, that check should fail, and in my
approach, it would have passed, and would have led to bad stuff later.
>
>>> shouldn't even write any shadow registers until the moment the output is
>>> enabled.
>>
>> That's being done correctly even now I guess, with the checks for
>> mp->enabled in wrtie_regs() and set_go_bits().
>
> Yes, for timings. I was thinking more about the other settings done in
> dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to
> registers, so we need runtime_get for that.
Ok.
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Jonathan Cameron @ 2012-05-08 13:47 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Samuel Ortiz, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120503163617.GD15752@localhost>
On 5/3/2012 5:36 PM, Johan Hovold wrote:
> On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
>> On 5/3/2012 11:26 AM, Johan Hovold wrote:
>>> Add sub-driver for the ambient light sensor interface on National
>>> Semiconductor / TI LM3533 lighting power chips.
>>>
>>> The sensor interface can be used to control the LEDs and backlights of
>>> the chip through defining five light zones and three sets of
>>> corresponding brightness target levels.
>>>
>>> The driver provides raw and mean adc readings along with the current
>>> light zone through sysfs. A threshold event can be generated on zone
>>> changes.
>> Code is fine. Pretty much all my comments are to do with the interface.
> [...]
>
>>> diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als b/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
>>> new file mode 100644
>>> index 0000000..9849d14
>>> --- /dev/null
>>> +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
>>> @@ -0,0 +1,62 @@
>>> +What: /sys/bus/iio/devices/iio:deviceX/gain
>>> +Date: April 2012
>>> +KernelVersion: 3.5
>>> +Contact: Johan Hovold<jhovold@gmail.com>
>>> +Description:
>>> + Set the ALS gain-resistor setting (0..127) for analog input
>>> + mode, where
>>> +
>>> + 0000000 - ALS input is high impedance
>>> + 0000001 - 200kOhm (10uA at 2V full-scale)
>>> + 0000010 - 100kOhm (20uA at 2V full-scale)
>>> + ...
>>> + 1111110 - 1.587kOhm (1.26mA at 2V full-scale)
>>> + 1111111 - 1.575kOhm (1.27mA at 2V full-scale)
>>> +
>>> + R_als = 2V / (10uA * gain) (gain> 0)
>> Firstly, no magic numbers. These are definitely magic.
> Not that magic as they're clearly documented (in code and public
> datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
>
>> Secondly see
>> in_illuminance0_scale for a suitable existing attribute.
> I didn't consider scale to be appropriate given the following
> documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently
wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling
before the raw reading is generated (so in hardware).
>
> "If known for a device, scale to be applied to<type>Y[_name]_raw post
> addition of<type>[Y][_name]_offset in order to obtain the measured
> value in<type> units as specified in<type>[Y][_name]_raw
> documentation."
>
> That is, the gain setting has nothing to do with scaling the raw adc
> reading to SI-units or such, it's simply a setup dependent gain setting
> (which affects the raw readings as well). [And as such, should probably
> go into to the platform data eventually as well.]
>
>>> +
>>> +What: /sys/bus/iio/devices/iio:deviceX/illuminance_zone
>>> +Date: April 2012
>>> +KernelVersion: 3.5
>>> +Contact: Johan Hovold<jhovold@gmail.com>
>>> +Description:
>>> + Get the current light zone (0..4) as defined by the
>>> + in_illuminance_thresh[n]_{falling,rising} thresholds.
>> Hmm.. definitely have an in prefix, beyond that I'm not sure what the
>> cleanest
> Thanks for catching this, it's a typo in the sysfs document -- the in_
> prefix is in the code.
>
>> interface will be for this. Could extend the event codes to deal with the
>> zone index. Slightly tricky as the channel could already be modified so
>> chan2 isn't necesarily available.
>>
>>> +
>>> +What: /sys/.../events/in_illuminance_thresh_either_en
>>> +Date: April 2012
>>> +KernelVersion: 3.5
>>> +Contact: Johan Hovold<jhovold@gmail.com>
>>> +Description:
>>> + Event generated when channel passes one of the four threshold
>>> + in either direction (rising|falling) and a zone change occurs.
>>> + The corresponding light zone can be read from
>>> + illuminance_zone.
>>> +
>>> +What: /sys/.../events/illuminance_thresh0_falling_value
>> hmm.. every time you think you are making progress a new and exciting
>> device comes
>> along requiring the abi to be extended.
> Exciting isn't it. :)
humph.
>
>> in_illuminanceX_threshY_rising_value
>> in_illuminanceX_threshY_falling_value
>> should do with appropriate description.
> Ok.
>
>>> +What: /sys/.../events/illuminance_thresh0_raising_value
>>> +What: /sys/.../events/illuminance_thresh1_falling_value
>>> +What: /sys/.../events/illuminance_thresh1_raising_value
>>> +What: /sys/.../events/illuminance_thresh2_falling_value
>>> +What: /sys/.../events/illuminance_thresh2_raising_value
>>> +What: /sys/.../events/illuminance_thresh3_falling_value
>>> +What: /sys/.../events/illuminance_thresh3_raising_value
>>> +Date: April 2012
>>> +KernelVersion: 3.5
>>> +Contact: Johan Hovold<jhovold@gmail.com>
>>> +Description:
>>> + Specifies the value of threshold that the device is comparing
>>> + against for the events enabled by
>>> + in_illuminance_thresh_either_en, and defines the
>>> + the five light zones.
>>> +
>>> + These thresholds correspond to the eight zone-boundary
>>> + registers (boundary[n]_{low,high}).
>>> +
>> This interface is going to take some thought. We have
>> in_illuminance0_target at the
>> moment, so I guess we can add a zoning concept to that...
> But target isn't really related, as far as I understand. That's another
> calibration setting right? While zone is derived from the average adc
> readings. (More below.)
True enough. I'd missunderstood this.
>
>>> +What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]
>>> +Date: April 2012
>>> +KernelVersion: 3.5
>>> +Contact: Johan Hovold<jhovold@gmail.com>
>>> +Description:
>>> + Set the target brightness for ALS-mapper m in light zone n
>>> + (0..255), where m in 1..3 and n in 0..4.
>> Don't suppose you could do a quick summary of what these zones are and
>> why there
>> are 3 ALS-mappers? I'm not getting terribly far on a quick look at the
>> datasheet!
> Of course. The average adc readings are mapped to five light zones using
> eight zone boundary registers (4 boundaries with hysteresis) and a set
> of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes
to fully specify these (nothing would indicate that hysterisis is
involved otherwise).
>
> To simplify somewhat (by ignoring some of the rules): If the average
> adc input drops below boundary0_low, the zone register reads 0; if it
> drops below boundary1_low, it reads 1, and so on. If the input it
> increases over boundary3_high, the zone register return 4; if it
> increases passed boundary2_high, it returns zone 3, etc.
>
> That is, roughly something like (we get 8-bits of input from the ADC):
>
> zone 0
>
> boundary0_low 51
> boundary0_high 53
>
> zone 1
>
> boundary1_low 102
> boundary1_high 106
>
> zone 2
>
> boundary2_low 153
> boundary2_high 161
>
> zone 3
>
> boundary3_low 204
> boundary3_high 220
>
> zone 4
>
> [ Figure 6 on page 20 in the datasheets should make it clear. ]
>
> The ALS interface and it's zone concept can then be used to control the
> LEDs and backlights of the chip, by determining the target brightness for
> each zone, e.g., set brightness to 52 when in zone 0.
>
> To complicate things further (and it is complicated), there are three
> such sets of target brightness values: ALSM1, ALSM2, ALSM3.
>
> So for each LED or backlight you can set ALS-input control mode, by
> saying that the device should get it's brightness levels from target set
> 1, 2, or 3.
>
> [ And it gets even more complicated, as ALSM1 can only control
> backlight0, where as ALSM2 and ALSM3 can control any of the remaining
> devices, but that's irrelevant here. ]
>
> Initially, I thought this interface to be too esoteric to be worth
> generalising, but it sort of fits with event thresholds so I gave it a
> try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
> The biggest conceptual problem, I think, is that the zone
> boundaries can be used to control the other devices, even when the event
> is not enabled (or even an irq line not configured). That is, I find it
> a bit awkward that the event thresholds also defines the zones (a sort of
> discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control
these from the other devices (e.g. the back light driver) then we'll
have to get them
into chan_spec and use the inkernel interfaces to do it. Not infeasible but
I was hoping to avoid that until we have had a few months to see what
similar
devices show up (on basis nothing in this world is a one off for long ;)
>
>
> Perhaps simply keeping the attributes outside of events (e.g. named
> boundary[n]_{low,high}) and having a custom event enabled (e.g.
> in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing
it as you describe above (with the addition fo hysteresis attributes) should
be fine. Just document the 'quirks'.
>
> [...]
>
>>> diff --git a/drivers/staging/iio/light/lm3533-als.c b/drivers/staging/iio/light/lm3533-als.c
>>> new file mode 100644
>>> index 0000000..e2c9be6
>>> --- /dev/null
>>> +++ b/drivers/staging/iio/light/lm3533-als.c
>>> @@ -0,0 +1,617 @@
>>> +/*
>>> + * lm3533-als.c -- LM3533 Ambient Light Sensor driver
>>> + *
>>> + * Copyright (C) 2011-2012 Texas Instruments
>>> + *
>>> + * Author: Johan Hovold<jhovold@gmail.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License as published by the
>>> + * Free Software Foundation; either version 2 of the License, or (at your
>>> + * option) any later version.
>>> + */
>>> +
>>> +#include<linux/atomic.h>
>>> +#include<linux/fs.h>
>>> +#include<linux/interrupt.h>
>>> +#include<linux/io.h>
>>> +#include<linux/module.h>
>>> +#include<linux/mfd/core.h>
>>> +#include<linux/platform_device.h>
>>> +#include<linux/slab.h>
>>> +#include<linux/uaccess.h>
>>> +
>>> +#include<linux/mfd/lm3533.h>
>>> +
>>> +#include "../events.h"
>>> +#include "../iio.h"
>> This will need to go through the staging-next tree. In there these
>> headers have moved.
> I'm aware of the move. Should the different sub-drivers go in through
> each tree respectively? Right now the four patches are all against rc5.
They will probably have to. Typically mfd bit goes in first, then the
rest get added
in a random order after that.
>
> [...]
>
>>> +static const struct iio_chan_spec lm3533_als_channels[] = {
>>> + {
>>> + .type = IIO_LIGHT,
>>> + .info_mask = IIO_CHAN_INFO_AVERAGE_RAW_SEPARATE_BIT,
>>> + .channel = 0,
>> channel doesn't get used unless you also set indexed = 1.
> So, you mean I could drop channel as well? Or should I add indexed, as I
> use channel 0 when reporting the event?
Either option is valid. I personally tend to set indexed = 1 but we
decided that
it didn't matter either way. Userspace code that uses the abi right
should allow
for either.
>
> [...]
>
>>> +static int lm3533_als_set_int_mode(struct iio_dev *indio_dev, int enable)
>>> +{
>>> + struct lm3533_als *als = iio_priv(indio_dev);
>>> + u8 mask = LM3533_ALS_INT_ENABLE_MASK;
>>> + u8 val;
>>> + int ret;
>>> +
>>> + if (enable)
>>> + val = mask;
>>> + else
>>> + val = 0;
>>> +
>>> + ret = lm3533_update(als->lm3533, LM3533_REG_ALS_ZONE_INFO, val, mask);
>>> + if (ret) {
>>> + dev_err(&indio_dev->dev, "failed to set int mode %d\n",
>>> + enable);
>> extra brackets.
> I prefer the brackets for multi-line (single) statements even though
> they are not required. (Especially if the single statement spans
> several lines -- but I try to be consistent.) If you have a strong
> opinion about this, I'll drop them.
I don't care either way.
>
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
> Thanks,
> Johan
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-08 16:00 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336466668.5761.12.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120508 01:48]:
> On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [120503 07:01]:
> > > Hi,
> > >
> > > I started cleaning up and restructuring omapdss for device tree, and here's the
> > > first set of patches from that ordeal. There's nothing DT specific in these
> > > patches, but they are mostly generic cleanups that make sense even without DT.
> > >
> > > This is the second version of these patches, the previous version can be found
> > > from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
> > >
> > > The first 21 patches, which were in the previous version, have only gotten
> > > minor cleanups (and, of course, more testing). The last 4 patches are new. The
> > > most important of those patches is the DSI pin config patch, which makes it
> > > possible for the panel driver to configure the DSI pins it needs.
> > >
> > > This series can also be found from:
> > > git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
> >
> > Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
> > patches (and the drivers/video dependencies needed) into a separate branch
> > and send me a pull request. That is assuming those patches are now immutable.
> >
> > Then I can pull it into cleanup-dss branch that we both can merge as
> > needed.
>
> Ok, I'll see how it goes. Do I have your ack for the board file changes?
Acked-by: Tony Lindgren <tony@atomide.com>
> Do you want to have patches that touch only
> arch/arm/mach-omap2/display.c, but not the board files? That's a dss
> specific file, and I don't expect anyone else to make changes to it, so
> chances for conflicts should be quite minimal.
Yes probably board-*.c files are enough to avoid annoying merge conflicts.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
From: Russ Dill @ 2012-05-08 23:38 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
On Mon, May 7, 2012 at 4:21 AM, Archit Taneja <archit@ti.com> wrote:
>
> The first patch in this series is a follow up on the previously posted
> series
> 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
> required for HDMI and DPI interfaces to work properly, it ensures manager
> timings are applied in the set_timing() ops for these interfaces.
>
> The next 3 patches remove some unnecessary usage of omap_dss_device
> pointer in
> DISPC and APPLY.
>
> The last 2 patches are miscellaneous fixes and are self explanatory.
>
> Reference tree containing this series:
>
> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git
> mgr_timing_and_fixes
>
> Tested on OMAP4 SDP.
>
> Archit Taneja (6):
> OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
> OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
> OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
> dispc_mgr_pclk_rate()
> OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
> OMAPDSS: Fix DSI_FCLK clock source selection
> OMAPDSS: DISPC: Remove Fake VSYNC support
>
> drivers/video/omap2/dss/Kconfig | 9 ------
> drivers/video/omap2/dss/apply.c | 3 --
> drivers/video/omap2/dss/dispc.c | 61
> +++++++++++++-------------------------
> drivers/video/omap2/dss/dpi.c | 2 +
> drivers/video/omap2/dss/dsi.c | 4 --
> drivers/video/omap2/dss/dss.c | 5 ++-
> drivers/video/omap2/dss/dss.h | 1 -
> drivers/video/omap2/dss/hdmi.c | 2 +
> 8 files changed, 28 insertions(+), 59 deletions(-)
I did a build and boot of each one of the patches on the
mgr_timing_and_fixes branch including these on:
Beagleboard-xM rev C1
Beagleboard rev B4
Mistral AM37x-EVM
Zoom AM3517 EVM
Zoom AM1808 EVM
Tested-by: Russ.Dill@ti.com
^ permalink raw reply
* [PATCH 1/5] video: exynos mipi dsi: enable interrupt again after sw reset
From: Donghwa Lee @ 2012-05-09 5:33 UTC (permalink / raw)
To: linux-arm-kernel
I resend this patch by including this series.
You can refer the original patch by below url.
http://marc.info/?l=linux-fbdev&m\x133610770329570&w=2
When exynos_mipi_update_cfg() is called, mipi dsi registers were become
sw reset. So, It needs to enable interrupt again.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 557091d..49c7351 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -102,6 +102,8 @@ static void exynos_mipi_update_cfg(struct mipi_dsim_device *dsim)
/* set display timing. */
exynos_mipi_dsi_set_display_mode(dsim, dsim->dsim_config);
+ exynos_mipi_dsi_init_interrupt(dsim);
+
/*
* data from Display controller(FIMD) is transferred in video mode
* but in case of command mode, all settigs is updated to registers.
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/5] video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
From: Donghwa Lee @ 2012-05-09 5:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
Use proper PM ops from struct dev_pm_ops rather than the deprecated ones.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 49c7351..e004f1d 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -517,10 +517,10 @@ static int __devexit exynos_mipi_dsi_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int exynos_mipi_dsi_suspend(struct platform_device *pdev,
- pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int exynos_mipi_dsi_suspend(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct mipi_dsim_device *dsim = platform_get_drvdata(pdev);
struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
@@ -546,8 +546,9 @@ static int exynos_mipi_dsi_suspend(struct platform_device *pdev,
return 0;
}
-static int exynos_mipi_dsi_resume(struct platform_device *pdev)
+static int exynos_mipi_dsi_resume(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct mipi_dsim_device *dsim = platform_get_drvdata(pdev);
struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
@@ -579,19 +580,19 @@ static int exynos_mipi_dsi_resume(struct platform_device *pdev)
return 0;
}
-#else
-#define exynos_mipi_dsi_suspend NULL
-#define exynos_mipi_dsi_resume NULL
#endif
+static const struct dev_pm_ops exynos_mipi_dsi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(exynos_mipi_dsi_suspend, exynos_mipi_dsi_resume)
+};
+
static struct platform_driver exynos_mipi_dsi_driver = {
.probe = exynos_mipi_dsi_probe,
.remove = __devexit_p(exynos_mipi_dsi_remove),
- .suspend = exynos_mipi_dsi_suspend,
- .resume = exynos_mipi_dsi_resume,
.driver = {
.name = "exynos-mipi-dsim",
.owner = THIS_MODULE,
+ .pm = &exynos_mipi_dsi_pm_ops,
},
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/5] video: exynos mipi dsi: Avoid races in probe()
From: Donghwa Lee @ 2012-05-09 5:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
Make sure all resources are initialized before interrupt handler is
registered. Pass full platform device name to request_irq() so it
can be distinguished which device has requested an interrupt in cases
there are multiple instances in the system.
Also enable voltage regulators regardless of they have been enabled
by bootloader or not, to make sure other drivers using same regulators
don't disable them unexpectedly.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 26 ++++++++++++++------------
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index e004f1d..3fcdbf9 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -415,27 +415,30 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
goto err_platform_get_irq;
}
+ init_completion(&dsim_wr_comp);
+ init_completion(&dsim_rd_comp);
+ platform_set_drvdata(pdev, dsim);
+
ret = request_irq(dsim->irq, exynos_mipi_dsi_interrupt_handler,
- IRQF_SHARED, pdev->name, dsim);
+ IRQF_SHARED, dev_name(&pdev->dev), dsim);
if (ret != 0) {
dev_err(&pdev->dev, "failed to request dsim irq\n");
ret = -EINVAL;
goto err_bind;
}
- init_completion(&dsim_wr_comp);
- init_completion(&dsim_rd_comp);
-
- /* enable interrupt */
+ /* enable interrupts */
exynos_mipi_dsi_init_interrupt(dsim);
/* initialize mipi-dsi client(lcd panel). */
if (dsim_ddi->dsim_lcd_drv && dsim_ddi->dsim_lcd_drv->probe)
dsim_ddi->dsim_lcd_drv->probe(dsim_ddi->dsim_lcd_dev);
- /* in case that mipi got enabled at bootloader. */
- if (dsim_pd->enabled)
- goto out;
+ /* in case mipi-dsi has been enabled by bootloader */
+ if (dsim_pd->enabled) {
+ exynos_mipi_regulator_enable(dsim);
+ goto done;
+ }
/* lcd panel power on. */
if (dsim_ddi->dsim_lcd_drv && dsim_ddi->dsim_lcd_drv->power_on)
@@ -455,12 +458,11 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
dsim->suspended = false;
-out:
+done:
platform_set_drvdata(pdev, dsim);
- dev_dbg(&pdev->dev, "mipi-dsi driver(%s mode) has been probed.\n",
- (dsim_config->e_interface = DSIM_COMMAND) ?
- "CPU" : "RGB");
+ dev_dbg(&pdev->dev, "%s() completed sucessfuly (%s mode)\n", __func__,
+ dsim_config->e_interface = DSIM_COMMAND ? "CPU" : "RGB");
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/5] video: exynos mipi dsi: Properly interpret the interrupt source flags
From: Donghwa Lee @ 2012-05-09 5:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
Rework the interrupt handler so the RX_DONE, FIFO_EMPTY interrupts are
properly detected. This prevents missing the interrupts when there are
other bits set in the INTSRC register than just RX_DONE and FIFO_EMPTY.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi_common.c | 28 +++++++++----------------
1 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
index 14909c1..b78d448 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -76,33 +76,25 @@ static unsigned int dpll_table[15] = {
irqreturn_t exynos_mipi_dsi_interrupt_handler(int irq, void *dev_id)
{
- unsigned int intsrc = 0;
- unsigned int intmsk = 0;
- struct mipi_dsim_device *dsim = NULL;
-
- dsim = dev_id;
- if (!dsim) {
- dev_dbg(dsim->dev, KERN_ERR "%s:error: wrong parameter\n",
- __func__);
- return IRQ_HANDLED;
+ struct mipi_dsim_device *dsim = dev_id;
+ unsigned int intsrc, intmsk;
+
+ if (dsim = NULL) {
+ dev_err(dsim->dev, "%s: wrong parameter\n", __func__);
+ return IRQ_NONE;
}
intsrc = exynos_mipi_dsi_read_interrupt(dsim);
intmsk = exynos_mipi_dsi_read_interrupt_mask(dsim);
+ intmsk = ~intmsk & intsrc;
- intmsk = ~(intmsk) & intsrc;
-
- switch (intmsk) {
- case INTMSK_RX_DONE:
+ if (intsrc & INTMSK_RX_DONE) {
complete(&dsim_rd_comp);
dev_dbg(dsim->dev, "MIPI INTMSK_RX_DONE\n");
- break;
- case INTMSK_FIFO_EMPTY:
+ }
+ if (intsrc & INTMSK_FIFO_EMPTY) {
complete(&dsim_wr_comp);
dev_dbg(dsim->dev, "MIPI INTMSK_FIFO_EMPTY\n");
- break;
- default:
- break;
}
exynos_mipi_dsi_clear_interrupt(dsim, intmsk);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/5] video: exynos mipi dsi: support reverse panel type
From: Donghwa Lee @ 2012-05-09 5:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds panel_reverse variable to support reversed s6e8ax0 panel
type.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/s6e8ax0.c | 15 +++++++++++++--
include/video/exynos_mipi_dsim.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 4aa9ac6..05d080b 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -293,9 +293,20 @@ static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
0x6e, 0x00, 0x00, 0x00, 0x02, 0x08, 0x08, 0x23, 0x23, 0xc0,
0xc8, 0x08, 0x48, 0xc1, 0x00, 0xc1, 0xff, 0xff, 0xc8
};
+ static const unsigned char data_to_send_panel_reverse[] = {
+ 0xf8, 0x19, 0x35, 0x00, 0x00, 0x00, 0x93, 0x00, 0x3c, 0x7d,
+ 0x08, 0x27, 0x7d, 0x3f, 0x00, 0x00, 0x00, 0x20, 0x04, 0x08,
+ 0x6e, 0x00, 0x00, 0x00, 0x02, 0x08, 0x08, 0x23, 0x23, 0xc0,
+ 0xc1, 0x01, 0x41, 0xc1, 0x00, 0xc1, 0xf6, 0xf6, 0xc1
+ };
- ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
- data_to_send, ARRAY_SIZE(data_to_send));
+ if (lcd->dsim_dev->panel_reverse)
+ ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
+ data_to_send_panel_reverse,
+ ARRAY_SIZE(data_to_send_panel_reverse));
+ else
+ ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
+ data_to_send, ARRAY_SIZE(data_to_send));
}
static void s6e8ax0_display_cond(struct s6e8ax0 *lcd)
diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
index 772c770..83ce5e6 100644
--- a/include/video/exynos_mipi_dsim.h
+++ b/include/video/exynos_mipi_dsim.h
@@ -315,6 +315,7 @@ struct mipi_dsim_lcd_device {
int id;
int bus_id;
int irq;
+ int panel_reverse;
struct mipi_dsim_device *master;
void *platform_data;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
From: Archit Taneja @ 2012-05-09 5:36 UTC (permalink / raw)
To: Russ Dill; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
In-Reply-To: <CA+Bv8Xa0KDmf3=DTbWmw2khNNm6DvtZc+4+adVqX-22rNYoeEA@mail.gmail.com>
On Wednesday 09 May 2012 05:08 AM, Russ Dill wrote:
> On Mon, May 7, 2012 at 4:21 AM, Archit Taneja<archit@ti.com> wrote:
>>
>> The first patch in this series is a follow up on the previously posted
>> series
>> 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
>> required for HDMI and DPI interfaces to work properly, it ensures manager
>> timings are applied in the set_timing() ops for these interfaces.
>>
>> The next 3 patches remove some unnecessary usage of omap_dss_device
>> pointer in
>> DISPC and APPLY.
>>
>> The last 2 patches are miscellaneous fixes and are self explanatory.
>>
>> Reference tree containing this series:
>>
>> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git
>> mgr_timing_and_fixes
>>
>> Tested on OMAP4 SDP.
>>
>> Archit Taneja (6):
>> OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
>> OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
>> OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
>> dispc_mgr_pclk_rate()
>> OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
>> OMAPDSS: Fix DSI_FCLK clock source selection
>> OMAPDSS: DISPC: Remove Fake VSYNC support
>>
>> drivers/video/omap2/dss/Kconfig | 9 ------
>> drivers/video/omap2/dss/apply.c | 3 --
>> drivers/video/omap2/dss/dispc.c | 61
>> +++++++++++++-------------------------
>> drivers/video/omap2/dss/dpi.c | 2 +
>> drivers/video/omap2/dss/dsi.c | 4 --
>> drivers/video/omap2/dss/dss.c | 5 ++-
>> drivers/video/omap2/dss/dss.h | 1 -
>> drivers/video/omap2/dss/hdmi.c | 2 +
>> 8 files changed, 28 insertions(+), 59 deletions(-)
>
> I did a build and boot of each one of the patches on the
> mgr_timing_and_fixes branch including these on:
>
> Beagleboard-xM rev C1
> Beagleboard rev B4
> Mistral AM37x-EVM
> Zoom AM3517 EVM
> Zoom AM1808 EVM
Thanks! I'll be posting out a newer version of the series with some
minor changes. But the content should be more or less the same.
Thanks,
Archit
>
> Tested-by: Russ.Dill@ti.com
>
^ permalink raw reply
* [PATCH 0/5] video: exynos mipi dsi: fixes some bugs and clean the codes
From: Donghwa Lee @ 2012-05-09 5:49 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix some bugs and clean the codes for exynos mipi dsi
display driver.
video: exynos mipi dsi: enable interrupt again after sw reset
:I resend this patch by including this series.
You can refer the original patch by below url.
http://marc.info/?l=linux-fbdev&m\x133610770329570&w=2
video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
video: exynos mipi dsi: Avoid races in probe()
video: exynos mipi dsi: Properly interpret the interrupt source flags
video: exynos mipi dsi: support reverse panel type
Thank you,
Donghwa Lee
^ 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