Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* [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 1/5] OMAPDSS: APPLY: Add manager timings as extra_info in private data
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>

DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.

To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.

Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.

Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info and writes it to the registers and set the go bits.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/video/omap2/dss/apply.c |   96 +++++++++++++++++++++++++++++++++-----
 drivers/video/omap2/dss/dss.h   |    2 +
 2 files changed, 85 insertions(+), 13 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b10b3bc..57686f6 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -99,6 +99,11 @@ struct mgr_priv_data {
 
 	/* If true, a display is enabled using this manager */
 	bool enabled;
+
+	bool extra_info_dirty;
+	bool shadow_extra_info_dirty;
+
+	struct omap_video_timings timings;
 };
 
 static struct {
@@ -261,6 +266,20 @@ static bool need_isr(void)
 			if (mp->shadow_info_dirty)
 				return true;
 
+			/*
+			 * NOTE: we don't check extra_info flags for disabled
+			 * managers, once the manager is enabled, the extra_info
+			 * related manager changes will be taken in by HW.
+			 */
+
+			/* to write new values to registers */
+			if (mp->extra_info_dirty)
+				return true;
+
+			/* to set GO bit */
+			if (mp->shadow_extra_info_dirty)
+				return true;
+
 			list_for_each_entry(ovl, &mgr->overlays, list) {
 				struct ovl_priv_data *op;
 
@@ -305,7 +324,7 @@ static bool need_go(struct omap_overlay_manager *mgr)
 
 	mp = get_mgr_priv(mgr);
 
-	if (mp->shadow_info_dirty)
+	if (mp->shadow_info_dirty || mp->shadow_extra_info_dirty)
 		return true;
 
 	list_for_each_entry(ovl, &mgr->overlays, list) {
@@ -320,20 +339,16 @@ static bool need_go(struct omap_overlay_manager *mgr)
 /* returns true if an extra_info field is currently being updated */
 static bool extra_info_update_ongoing(void)
 {
-	const int num_ovls = omap_dss_get_num_overlays();
-	struct ovl_priv_data *op;
-	struct omap_overlay *ovl;
-	struct mgr_priv_data *mp;
+	const int num_mgrs = dss_feat_get_num_mgrs();
 	int i;
 
-	for (i = 0; i < num_ovls; ++i) {
-		ovl = omap_dss_get_overlay(i);
-		op = get_ovl_priv(ovl);
-
-		if (!ovl->manager)
-			continue;
+	for (i = 0; i < num_mgrs; ++i) {
+		struct omap_overlay_manager *mgr;
+		struct omap_overlay *ovl;
+		struct mgr_priv_data *mp;
 
-		mp = get_mgr_priv(ovl->manager);
+		mgr = omap_dss_get_overlay_manager(i);
+		mp = get_mgr_priv(mgr);
 
 		if (!mp->enabled)
 			continue;
@@ -341,8 +356,15 @@ static bool extra_info_update_ongoing(void)
 		if (!mp->updating)
 			continue;
 
-		if (op->extra_info_dirty || op->shadow_extra_info_dirty)
+		if (mp->extra_info_dirty || mp->shadow_extra_info_dirty)
 			return true;
+
+		list_for_each_entry(ovl, &mgr->overlays, list) {
+			struct ovl_priv_data *op = get_ovl_priv(ovl);
+
+			if (op->extra_info_dirty || op->shadow_extra_info_dirty)
+				return true;
+		}
 	}
 
 	return false;
@@ -601,6 +623,22 @@ static void dss_mgr_write_regs(struct omap_overlay_manager *mgr)
 	}
 }
 
+static void dss_mgr_write_regs_extra(struct omap_overlay_manager *mgr)
+{
+	struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+	DSSDBGF("%d", mgr->id);
+
+	if (!mp->extra_info_dirty)
+		return;
+
+	dispc_mgr_set_timings(mgr->id, &mp->timings);
+
+	mp->extra_info_dirty = false;
+	if (mp->updating)
+		mp->shadow_extra_info_dirty = true;
+}
+
 static void dss_write_regs_common(void)
 {
 	const int num_mgrs = omap_dss_get_num_overlay_managers();
@@ -654,6 +692,7 @@ static void dss_write_regs(void)
 		}
 
 		dss_mgr_write_regs(mgr);
+		dss_mgr_write_regs_extra(mgr);
 	}
 }
 
@@ -693,6 +732,7 @@ static void mgr_clear_shadow_dirty(struct omap_overlay_manager *mgr)
 
 	mp = get_mgr_priv(mgr);
 	mp->shadow_info_dirty = false;
+	mp->shadow_extra_info_dirty = false;
 
 	list_for_each_entry(ovl, &mgr->overlays, list) {
 		op = get_ovl_priv(ovl);
@@ -719,6 +759,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
 	}
 
 	dss_mgr_write_regs(mgr);
+	dss_mgr_write_regs_extra(mgr);
 
 	dss_write_regs_common();
 
@@ -1225,6 +1266,35 @@ err:
 	return r;
 }
 
+static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
+		struct omap_video_timings *timings)
+{
+	struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+	mp->timings = *timings;
+	mp->extra_info_dirty = true;
+}
+
+void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
+		struct omap_video_timings *timings)
+{
+	unsigned long flags;
+
+	mutex_lock(&apply_lock);
+
+	spin_lock_irqsave(&data_lock, flags);
+
+	dss_apply_mgr_timings(mgr, timings);
+
+	dss_write_regs();
+	dss_set_go_bits();
+
+	spin_unlock_irqrestore(&data_lock, flags);
+
+	wait_pending_extra_info_updates();
+
+	mutex_unlock(&apply_lock);
+}
 
 int dss_ovl_set_info(struct omap_overlay *ovl,
 		struct omap_overlay_info *info)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 5ca67f1..ca59481 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -177,6 +177,8 @@ void dss_mgr_get_info(struct omap_overlay_manager *mgr,
 int dss_mgr_set_device(struct omap_overlay_manager *mgr,
 		struct omap_dss_device *dssdev);
 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);
 
 bool dss_ovl_is_enabled(struct omap_overlay *ovl);
 int dss_ovl_enable(struct omap_overlay *ovl);
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH v3 0/5] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Archit Taneja @ 2012-05-08 10:10 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1334561027-28569-1-git-send-email-archit@ti.com>

An overlay manager's timings (the manager size, and blanking parameters if an
LCD manager) are DISPC shadow registers, and they should hence follow the
correct programming model.

This set makes the timings an extra_info parameter in manager's private data .
The interface drivers now apply the timings in instead of directly writing to
registers.

This change also prevents the need to use display resolution for overlay
checks, hence making some of the APPLY functions less dependent on the display.

Changes since v3:

- Make sure that we write to the timing registers and set go bits when calling
  dss_mgr_set_timings
- Don't create dss_mgr_get_timings(), apply should pass the timings rather than
  outside DSS dunctions querying form it.

These patches apply over:

git://gitorious.org/linux-omap-dss2/linux.git dev

Archit Taneja (5):
  OMAPDSS: APPLY: Add manager timings as extra_info in private data
  OMAPDSS: Apply manager timings instead of direct DISPC writes
  OMAPDSS: MANAGER: Create a function to check manager timings
  OMAPDSS: APPLY: Remove display dependency from overlay and manager
    checks
  OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled

 drivers/video/omap2/dss/apply.c   |  140 ++++++++++++++++++++++++++++++-------
 drivers/video/omap2/dss/dispc.c   |    2 +-
 drivers/video/omap2/dss/dpi.c     |    6 +-
 drivers/video/omap2/dss/dsi.c     |    5 +-
 drivers/video/omap2/dss/dss.h     |   13 +++-
 drivers/video/omap2/dss/hdmi.c    |    4 +-
 drivers/video/omap2/dss/manager.c |   19 +++++-
 drivers/video/omap2/dss/overlay.c |   20 +++---
 drivers/video/omap2/dss/rfbi.c    |    4 +-
 drivers/video/omap2/dss/sdi.c     |    2 +-
 drivers/video/omap2/dss/venc.c    |    2 +-
 11 files changed, 163 insertions(+), 54 deletions(-)

-- 
1.7.5.4


^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08  9:19 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336467151.5761.20.camel@deskari>

On Tuesday 08 May 2012 02:22 PM, Tomi Valkeinen wrote:
> On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote:
>> On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
>
>>> I'm not sure if it applies here, but as a general strategy, I suggest
>>> doing things in apply.c that require data from apply.c's internal data.
>>> When that's not possible, apply.c should call the functions outside
>>> apply.c, and pass the internal data as parameters (like calls to dispc).
>>>
>>> In your case, I for example see dss_mgr_check() calling
>>> dss_mgr_get_timings(). It would be quite easy to pass the timings to
>>> dss_mgr_check() from apply.c, thus removing the need to call the
>>> function. And, as you see, dss_mgr_check() already has a bunch of
>>> parameters, and the idea is the same with those: give the params, so
>>> that dss_mgr_check() doesn't need to ask for them.
>>
>> Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I
>> you see the misc cleanup patch series I posted, I use
>> dss_mgr_get_timings()  in dispc.c functions to remove some
>> omap_dss_device references. These DISPC functions are called in
>> dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so
>> that it comes directly from apply.c. What do you say?
>
> Yes, I guess dispc_ovl_setup should get the timings pointer also. It's
> getting a bit complex, but I don't see any simpler way. Especially dispc
> functions should be quite self contained, dispc.c should not call
> elsewhere, but it should get all the needed data as parameters.

Ok, you are right about dispc.c querying stuff from apply, it should all 
be one way from apply/interface drivers to the dispc, and if that's the 
case, then it has to get more complex. We could just pass the data in a 
nicer way to make the number of arguments passed to dispc functions seem 
small.

>
>> I guess we can get away from exposing private data in apply to DSS, but
>> it might get a bit harder when we try to remove other omap_dss_device
>> references in the future. I'm just guessing though.
>
> We have two cases here: 1) using timings when doing apply.c things, as
> your patches do. In these cases the timings can be passed from apply.c
> as parameters. 2) using timings "outside" apply.c. I guess we currently
> don't have these, but for those we could have a get_timings() function
> that does take the locks. And similarly for other configs.
>
> Of course, that's still not perfect. Even if get_timings() is protected
> properly, there's no guarantee that the timings won't change right after
> get_timings has returned. But hopefully all writes and reads to timings
> would go via the same place, for example dpi.c. And dpi.c's own lock
> will protect the change of timings while another thread is using them.
>
> Btw, there's a typo in "OMAPDSS: DISPC: Remove usage of
> dispc_mgr_get_device()"'s description, dss_mgr_get_device() should be
> get_timings in one place.

Ah ok, I am removing the dss_mgr_get_timings() usage anyway, I'll pass 
timings through dispc_ovl_setup().

I am also going to make the first patch of the newer set 'OMAPDSS: 
DPI/HDMI: Apply manager timings even if panel is disabled' a part of 
this series since it's more related to applying timings. I posted it in 
the next series since I had already posted out this series.

Archit

>
>   Tomi
>


^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-08  8:52 UTC (permalink / raw)
  To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA8CD6D.3010503@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote:
> On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:

> > I'm not sure if it applies here, but as a general strategy, I suggest
> > doing things in apply.c that require data from apply.c's internal data.
> > When that's not possible, apply.c should call the functions outside
> > apply.c, and pass the internal data as parameters (like calls to dispc).
> >
> > In your case, I for example see dss_mgr_check() calling
> > dss_mgr_get_timings(). It would be quite easy to pass the timings to
> > dss_mgr_check() from apply.c, thus removing the need to call the
> > function. And, as you see, dss_mgr_check() already has a bunch of
> > parameters, and the idea is the same with those: give the params, so
> > that dss_mgr_check() doesn't need to ask for them.
> 
> Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I 
> you see the misc cleanup patch series I posted, I use 
> dss_mgr_get_timings()  in dispc.c functions to remove some 
> omap_dss_device references. These DISPC functions are called in 
> dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so 
> that it comes directly from apply.c. What do you say?

Yes, I guess dispc_ovl_setup should get the timings pointer also. It's
getting a bit complex, but I don't see any simpler way. Especially dispc
functions should be quite self contained, dispc.c should not call
elsewhere, but it should get all the needed data as parameters.

> I guess we can get away from exposing private data in apply to DSS, but 
> it might get a bit harder when we try to remove other omap_dss_device 
> references in the future. I'm just guessing though.

We have two cases here: 1) using timings when doing apply.c things, as
your patches do. In these cases the timings can be passed from apply.c
as parameters. 2) using timings "outside" apply.c. I guess we currently
don't have these, but for those we could have a get_timings() function
that does take the locks. And similarly for other configs.

Of course, that's still not perfect. Even if get_timings() is protected
properly, there's no guarantee that the timings won't change right after
get_timings has returned. But hopefully all writes and reads to timings
would go via the same place, for example dpi.c. And dpi.c's own lock
will protect the change of timings while another thread is using them.

Btw, there's a typo in "OMAPDSS: DISPC: Remove usage of
dispc_mgr_get_device()"'s description, dss_mgr_get_device() should be
get_timings in one place.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tomi Valkeinen @ 2012-05-08  8:44 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <20120507174657.GF5088@atomide.com>

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

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?

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.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08  7:50 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336461377.1896.23.camel@lappyti>

On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
> On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
>> On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
>>> On Thu, 2012-05-03 at 12:37 +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.
>>>>
>>>> Create a function dss_mgr_get_timings() which returns the timings in manager's
>>>> private data. 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>
>>>
>>>> +struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr)
>>>> +{
>>>> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
>>>> +
>>>> +	return&mp->timings;
>>>> +}
>>>
>>> This one returns a pointer into apply.c's internal data structures. The
>>> safest way would be to return a copy, but as it's an omapdss internal
>>> function, I think it's enough to return a pointer to a const struct.
>>
>> Okay I'll fix that, I was a bit concerned about the locking here, I use
>> this function in the later series to remove some dssdev references in
>> dispc.c. I traced the paths and saw that in all cases this function
>> would be protected by the data_lock spinlock, but not the apply_lock
>> mutex in all cases. Any thoughts on this?
>
> Hmm, you're right, locking here gets a bit confusing. set_timings has
> locks, so logically get_timings should also. But I guess all the uses of
> get_timings happens via apply.c, and apply.c already holds the
> data_lock, as you said?

Yes.

>
> Making the get_timings function public (inside omapdss) is a bit nasty,
> as it's quite easy to call it without having the appropriate locks. And
> actually there's no way to acquire the locks outside apply.c
>
> I'm not sure if it applies here, but as a general strategy, I suggest
> doing things in apply.c that require data from apply.c's internal data.
> When that's not possible, apply.c should call the functions outside
> apply.c, and pass the internal data as parameters (like calls to dispc).
>
> In your case, I for example see dss_mgr_check() calling
> dss_mgr_get_timings(). It would be quite easy to pass the timings to
> dss_mgr_check() from apply.c, thus removing the need to call the
> function. And, as you see, dss_mgr_check() already has a bunch of
> parameters, and the idea is the same with those: give the params, so
> that dss_mgr_check() doesn't need to ask for them.

Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I 
you see the misc cleanup patch series I posted, I use 
dss_mgr_get_timings()  in dispc.c functions to remove some 
omap_dss_device references. These DISPC functions are called in 
dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so 
that it comes directly from apply.c. What do you say?

I guess we can get away from exposing private data in apply to DSS, but 
it might get a bit harder when we try to remove other omap_dss_device 
references in the future. I'm just guessing though.

Archit

>
>   Tomi
>


^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-08  7:16 UTC (permalink / raw)
  To: Archit Taneja; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <4FA8A927.9080705@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
> On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-05-03 at 12:37 +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.
> >>
> >> Create a function dss_mgr_get_timings() which returns the timings in manager's
> >> private data. 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>
> >
> >> +struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr)
> >> +{
> >> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
> >> +
> >> +	return&mp->timings;
> >> +}
> >
> > This one returns a pointer into apply.c's internal data structures. The
> > safest way would be to return a copy, but as it's an omapdss internal
> > function, I think it's enough to return a pointer to a const struct.
> 
> Okay I'll fix that, I was a bit concerned about the locking here, I use 
> this function in the later series to remove some dssdev references in 
> dispc.c. I traced the paths and saw that in all cases this function 
> would be protected by the data_lock spinlock, but not the apply_lock 
> mutex in all cases. Any thoughts on this?

Hmm, you're right, locking here gets a bit confusing. set_timings has
locks, so logically get_timings should also. But I guess all the uses of
get_timings happens via apply.c, and apply.c already holds the
data_lock, as you said?

Making the get_timings function public (inside omapdss) is a bit nasty,
as it's quite easy to call it without having the appropriate locks. And
actually there's no way to acquire the locks outside apply.c

I'm not sure if it applies here, but as a general strategy, I suggest
doing things in apply.c that require data from apply.c's internal data.
When that's not possible, apply.c should call the functions outside
apply.c, and pass the internal data as parameters (like calls to dispc).

In your case, I for example see dss_mgr_check() calling
dss_mgr_get_timings(). It would be quite easy to pass the timings to
dss_mgr_check() from apply.c, thus removing the need to call the
function. And, as you see, dss_mgr_check() already has a bunch of
parameters, and the idea is the same with those: give the params, so
that dss_mgr_check() doesn't need to ask for them.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
From: Tomi Valkeinen @ 2012-05-08  7:01 UTC (permalink / raw)
  To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA8A00B.4040600@ti.com>

[-- Attachment #1: Type: text/plain, Size: 3059 bytes --]

On Tue, 2012-05-08 at 09:54 +0530, Archit Taneja wrote:
> Hi,
> 
> On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote:
> > Hi,

> > dss_<ovl|mgr>_<enable|disable>  functions handle GO, so you could have a
> > look at them. However, setting the timings is a bit different, so I'm
> > not sure how it should be done.
> >
> > I think we have a few different options:
> >
> > - Separate omapdss internal function (in apply.c) that can be used to
> > set GO after set_timings
> >
> > - set GO in dss_mgr_set_timings(), but don't block
> >
> > - set GO in dss_mgr_set_timings(), and block until the changes are in HW
> > (this is more or less what the dss_<ovl|mgr>_<enable|disable>  functions
> > do).
> >
> > The first one would be good if the interface drivers would need to set
> > multiple configurations, and we don't want to block after each set call.
> > But we don't have anything like that, at least currently.
> >
> > The second one avoids blocking, but could perhaps cause problems because
> > the timings are not actually used yet when the function returns.
> >
> > I don't see any problem with the last option, so I'm slightly leaning
> > towards it.
> 
> The 3rd option looks good to me too, but I'm wondering if we would need 
> to do the same things with all manager parameters which are in shadow 
> registers. Like in dpi.c, in dpi_set_mode() we set the DISPC_POL_FREQ 
> and DISPC_DIVISORo registers, writing GO for each parameter would be in 
> efficient, it's good that it doesn't happen much often. Maybe we could 
> group the rest of these parameters.

Hmm, that's true.

We could make shortcuts with settings that are only changed while the
display is off. For example, currently DISPC_POL_FREQ cannot be changed
dynamically, so it could only be set when before enabling the output.
However, it seems we currently do call dispc_mgr_set_pol_freq() in
dpi_set_mode(), which could be called when the output is enabled. But
even then we always set the same values, so it doesn't matter.

For DISPC_DIVISORo, I guess we could make a shortcut with that also.
While it is a shadow register, when we are changing the dss clocks we
also set non-shadowed registers. So I think the best way to change clock
frequencies is to turn off the output temporarily.

Perhaps all the shadow registers currently being set directly from
interface drivers are such settings? The code should still be changed so
that we only touch the registers when enabling the output.

But, of course, a better design and also more future proof would be to
handle all shadow registers properly, even if we currently only set them
while the output is off. That may be left for future, though.

In any case, I think we should mark clearly the places where we set
shadow registers directly, without using the apply.c. Perhaps we should
even mark all the dispc functions that set shadow registers, like
dispc_mgr_set_pol_freq_sh(). But let's not do that now either, as we're
quite close to merge window.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-08  5:15 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <1336403017.3522.2.camel@lappyti>

On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
> On Thu, 2012-05-03 at 12:37 +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.
>>
>> Create a function dss_mgr_get_timings() which returns the timings in manager's
>> private data. 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>
>
>> +struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr)
>> +{
>> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
>> +
>> +	return&mp->timings;
>> +}
>
> This one returns a pointer into apply.c's internal data structures. The
> safest way would be to return a copy, but as it's an omapdss internal
> function, I think it's enough to return a pointer to a const struct.

Okay I'll fix that, I was a bit concerned about the locking here, I use 
this function in the later series to remove some dssdev references in 
dispc.c. I traced the paths and saw that in all cases this function 
would be protected by the data_lock spinlock, but not the apply_lock 
mutex in all cases. Any thoughts on this?

Archit

>
>   Tomi
>


^ permalink raw reply
* Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
From: Archit Taneja @ 2012-05-08  4:36 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336402071.2667.16.camel@deskari>

Hi,

On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
>> DISPC manager size and DISPC manager blanking parameters(for LCD managers)
>> follow the shadow register programming model. Currently, they are programmed
>> directly by the interface drivers.
>>
>> To configure manager timings using APPLY, there is a need to introduce extra
>> info flags for managers, similar to what is done for overlays. This is needed
>> because timings aren't a part of overlay_manager_info struct configured by a
>> user of DSS, they are configured internally by the interface or panel drivers.
>>
>> Add dirty and shadow_dirty extra_info flags for managers, update these flags
>> at the appropriate places. Rewrite the function extra_info_update_ongoing()
>> slightly as checking for manager's extra_info flags can simplify the code a bit.
>>
>> Create function dss_mgr_set_timings() which applies the new manager timings to
>> extra_info.
>>
>> Signed-off-by: Archit Taneja<archit@ti.com>
>
> <snip>
>
>> +static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
>> +		struct omap_video_timings *timings)
>> +{
>> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
>> +
>> +	mp->timings = *timings;
>> +	mp->extra_info_dirty = true;
>> +}
>> +
>> +void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
>> +		struct omap_video_timings *timings)
>> +{
>> +	unsigned long flags;
>> +
>> +	mutex_lock(&apply_lock);
>> +
>> +	spin_lock_irqsave(&data_lock, flags);
>> +
>> +	dss_apply_mgr_timings(mgr, timings);
>> +
>> +	spin_unlock_irqrestore(&data_lock, flags);
>> +
>> +	mutex_unlock(&apply_lock);
>> +}
>
> With this, dpi.c&  others still need to use dispc_mgr_go(), which is
> something that should be removed and done only from apply.c.

Ah ok, so with this set, dss_mgr_set_timings() doesn't ensure that the 
configuration is taken in, the configuration may go in the next 
overlay/manager enable or the next mgr_apply, but that may happen much 
later.

>
> dss_<ovl|mgr>_<enable|disable>  functions handle GO, so you could have a
> look at them. However, setting the timings is a bit different, so I'm
> not sure how it should be done.
>
> I think we have a few different options:
>
> - Separate omapdss internal function (in apply.c) that can be used to
> set GO after set_timings
>
> - set GO in dss_mgr_set_timings(), but don't block
>
> - set GO in dss_mgr_set_timings(), and block until the changes are in HW
> (this is more or less what the dss_<ovl|mgr>_<enable|disable>  functions
> do).
>
> The first one would be good if the interface drivers would need to set
> multiple configurations, and we don't want to block after each set call.
> But we don't have anything like that, at least currently.
>
> The second one avoids blocking, but could perhaps cause problems because
> the timings are not actually used yet when the function returns.
>
> I don't see any problem with the last option, so I'm slightly leaning
> towards it.

The 3rd option looks good to me too, but I'm wondering if we would need 
to do the same things with all manager parameters which are in shadow 
registers. Like in dpi.c, in dpi_set_mode() we set the DISPC_POL_FREQ 
and DISPC_DIVISORo registers, writing GO for each parameter would be in 
efficient, it's good that it doesn't happen much often. Maybe we could 
group the rest of these parameters.

Archit

>
>   Tomi
>


^ permalink raw reply
* [PATCH 4/4] fbdev: sh_mobile_hdmi: add HDMI Control Register support
From: Kuninori Morimoto @ 2012-05-08  4:08 UTC (permalink / raw)
  To: linux-fbdev

Latest SuperH HDMI uses not only HDMI Core Register (HTOP0)
but also HDMI Control Register (HTOP1).
This patch adds HDMI Control Register support.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/video/sh_mobile_hdmi.c |  152 +++++++++++++++++++++++++++++++++++++++-
 include/video/sh_mobile_hdmi.h |    1 +
 2 files changed, 152 insertions(+), 1 deletions(-)

diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 4d48a80..930e550 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -31,6 +31,7 @@
 
 #include "sh_mobile_lcdcfb.h"
 
+/* HDMI Core Control Register (HTOP0) */
 #define HDMI_SYSTEM_CTRL			0x00 /* System control */
 #define HDMI_L_R_DATA_SWAP_CTRL_RPKT		0x01 /* L/R data swap control,
 							bits 19..16 of 20-bit N for Audio Clock Regeneration packet */
@@ -201,6 +202,68 @@
 #define HDMI_REVISION_ID			0xF1 /* Revision ID */
 #define HDMI_TEST_MODE				0xFE /* Test mode */
 
+/* HDMI Control Register (HTOP1) */
+#define HDMI_HTOP1_TEST_MODE			0x0000 /* Test mode */
+#define HDMI_HTOP1_VIDEO_INPUT			0x0008 /* VideoInput */
+#define HDMI_HTOP1_CORE_RSTN			0x000C /* CoreResetn */
+#define HDMI_HTOP1_PLLBW			0x0018 /* PLLBW */
+#define HDMI_HTOP1_CLK_TO_PHY			0x001C /* Clk to Phy */
+#define HDMI_HTOP1_VIDEO_INPUT2			0x0020 /* VideoInput2 */
+#define HDMI_HTOP1_TISEMP0_1			0x0024 /* tisemp0-1 */
+#define HDMI_HTOP1_TISEMP2_C			0x0028 /* tisemp2-c */
+#define HDMI_HTOP1_TISIDRV			0x002C /* tisidrv */
+#define HDMI_HTOP1_TISEN			0x0034 /* tisen */
+#define HDMI_HTOP1_TISDREN			0x0038 /* tisdren  */
+#define HDMI_HTOP1_CISRANGE			0x003C /* cisrange  */
+#define HDMI_HTOP1_ENABLE_SELECTOR		0x0040 /* Enable Selector */
+#define HDMI_HTOP1_MACRO_RESET			0x0044 /* Macro reset */
+#define HDMI_HTOP1_PLL_CALIBRATION		0x0048 /* PLL calibration */
+#define HDMI_HTOP1_RE_CALIBRATION		0x004C /* Re-calibration */
+#define HDMI_HTOP1_CURRENT			0x0050 /* Current */
+#define HDMI_HTOP1_PLL_LOCK_DETECT		0x0054 /* PLL lock detect */
+#define HDMI_HTOP1_PHY_TEST_MODE		0x0058 /* PHY Test Mode */
+#define HDMI_HTOP1_CLK_SET			0x0080 /* Clock Set */
+#define HDMI_HTOP1_DDC_FAIL_SAFE		0x0084 /* DDC fail safe */
+#define HDMI_HTOP1_PRBS				0x0088 /* PRBS */
+#define HDMI_HTOP1_EDID_AINC_CONTROL		0x008C /* EDID ainc Control */
+#define HDMI_HTOP1_HTOP_DCL_MODE		0x00FC /* Deep Coloer Mode */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF0		0x0100 /* Deep Color:FRC COEF0 */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF1		0x0104 /* Deep Color:FRC COEF1 */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF2		0x0108 /* Deep Color:FRC COEF2 */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF3		0x010C /* Deep Color:FRC COEF3 */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF0_C		0x0110 /* Deep Color:FRC COEF0C */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF1_C		0x0114 /* Deep Color:FRC COEF1C */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF2_C		0x0118 /* Deep Color:FRC COEF2C */
+#define HDMI_HTOP1_HTOP_DCL_FRC_COEF3_C		0x011C /* Deep Color:FRC COEF3C */
+#define HDMI_HTOP1_HTOP_DCL_FRC_MODE		0x0120 /* Deep Color:FRC Mode */
+#define HDMI_HTOP1_HTOP_DCL_RECT_START1		0x0124 /* Deep Color:Rect Start1 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_SIZE1		0x0128 /* Deep Color:Rect Size1 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_START2		0x012C /* Deep Color:Rect Start2 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_SIZE2		0x0130 /* Deep Color:Rect Size2 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_START3		0x0134 /* Deep Color:Rect Start3 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_SIZE3		0x0138 /* Deep Color:Rect Size3 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_START4		0x013C /* Deep Color:Rect Start4 */
+#define HDMI_HTOP1_HTOP_DCL_RECT_SIZE4		0x0140 /* Deep Color:Rect Size4 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y1_1	0x0144 /* Deep Color:Fil Para Y1_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y1_2	0x0148 /* Deep Color:Fil Para Y1_2 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB1_1	0x014C /* Deep Color:Fil Para CB1_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB1_2	0x0150 /* Deep Color:Fil Para CB1_2 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR1_1	0x0154 /* Deep Color:Fil Para CR1_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR1_2	0x0158 /* Deep Color:Fil Para CR1_2 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y2_1	0x015C /* Deep Color:Fil Para Y2_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y2_2	0x0160 /* Deep Color:Fil Para Y2_2 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB2_1	0x0164 /* Deep Color:Fil Para CB2_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB2_2	0x0168 /* Deep Color:Fil Para CB2_2 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR2_1	0x016C /* Deep Color:Fil Para CR2_1 */
+#define HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR2_2	0x0170 /* Deep Color:Fil Para CR2_2 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_Y1		0x0174 /* Deep Color:Cor Para Y1 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_CB1	0x0178 /* Deep Color:Cor Para CB1 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_CR1	0x017C /* Deep Color:Cor Para CR1 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_Y2		0x0180 /* Deep Color:Cor Para Y2 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_CB2	0x0184 /* Deep Color:Cor Para CB2 */
+#define HDMI_HTOP1_HTOP_DCL_COR_PARA_CR2	0x0188 /* Deep Color:Cor Para CR2 */
+#define HDMI_HTOP1_EDID_DATA_READ		0x0200 /* EDID Data Read 128Byte:0x03FC */
+
 enum hotplug_state {
 	HDMI_HOTPLUG_DISCONNECTED,
 	HDMI_HOTPLUG_CONNECTED,
@@ -211,6 +274,7 @@ struct sh_hdmi {
 	struct sh_mobile_lcdc_entity entity;
 
 	void __iomem *base;
+	void __iomem *htop1;
 	enum hotplug_state hp_state;	/* hot-plug status */
 	u8 preprogrammed_vic;		/* use a pre-programmed VIC or
 					   the external mode */
@@ -271,6 +335,17 @@ static void hdmi_bit_set(struct sh_hdmi *hdmi, u8 mask, u8 data, u8 reg)
 	hdmi_write(hdmi, val, reg);
 }
 
+static void hdmi_htop1_write(struct sh_hdmi *hdmi, u32 data, u32 reg)
+{
+	iowrite32(data, hdmi->htop1 + reg);
+	udelay(100);
+}
+
+static u32 hdmi_htop1_read(struct sh_hdmi *hdmi, u32 reg)
+{
+	return ioread32(hdmi->htop1 + reg);
+}
+
 /*
  *	HDMI sound
  */
@@ -781,7 +856,9 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi, unsigned long *hdmi_rate,
 	/* Read EDID */
 	dev_dbg(hdmi->dev, "Read back EDID code:");
 	for (i = 0; i < 128; i++) {
-		edid[i] = hdmi_read(hdmi, HDMI_EDID_KSV_FIFO_ACCESS_WINDOW);
+		edid[i] = (hdmi->htop1) ?
+			(u8)hdmi_htop1_read(hdmi, HDMI_HTOP1_EDID_DATA_READ + (i * 4)) :
+			hdmi_read(hdmi, HDMI_EDID_KSV_FIFO_ACCESS_WINDOW);
 #ifdef DEBUG
 		if ((i % 16) = 0) {
 			printk(KERN_CONT "\n");
@@ -1145,10 +1222,58 @@ out:
 	dev_dbg(hdmi->dev, "%s(%p): end\n", __func__, hdmi);
 }
 
+static void sh_hdmi_htop1_init(struct sh_hdmi *hdmi)
+{
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_MODE);
+	hdmi_htop1_write(hdmi, 0x0000000b, 0x0010);
+	hdmi_htop1_write(hdmi, 0x00006710, HDMI_HTOP1_HTOP_DCL_FRC_MODE);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y1_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y1_2);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB1_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB1_2);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR1_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR1_2);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y2_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_Y2_2);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB2_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CB2_2);
+	hdmi_htop1_write(hdmi, 0x01020406, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR2_1);
+	hdmi_htop1_write(hdmi, 0x07080806, HDMI_HTOP1_HTOP_DCL_FIL_PARA_CR2_2);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_Y1);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_CB1);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_CR1);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_Y2);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_CB2);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_HTOP_DCL_COR_PARA_CR2);
+	hdmi_htop1_write(hdmi, 0x00000008, HDMI_HTOP1_CURRENT);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_TISEMP0_1);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_TISEMP2_C);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_PHY_TEST_MODE);
+	hdmi_htop1_write(hdmi, 0x00000081, HDMI_HTOP1_TISIDRV);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_PLLBW);
+	hdmi_htop1_write(hdmi, 0x0000000f, HDMI_HTOP1_TISEN);
+	hdmi_htop1_write(hdmi, 0x0000000f, HDMI_HTOP1_TISDREN);
+	hdmi_htop1_write(hdmi, 0x00000003, HDMI_HTOP1_ENABLE_SELECTOR);
+	hdmi_htop1_write(hdmi, 0x00000001, HDMI_HTOP1_MACRO_RESET);
+	hdmi_htop1_write(hdmi, 0x00000016, HDMI_HTOP1_CISRANGE);
+	msleep(100);
+	hdmi_htop1_write(hdmi, 0x00000001, HDMI_HTOP1_ENABLE_SELECTOR);
+	msleep(100);
+	hdmi_htop1_write(hdmi, 0x00000003, HDMI_HTOP1_ENABLE_SELECTOR);
+	hdmi_htop1_write(hdmi, 0x00000001, HDMI_HTOP1_MACRO_RESET);
+	hdmi_htop1_write(hdmi, 0x0000000f, HDMI_HTOP1_TISEN);
+	hdmi_htop1_write(hdmi, 0x0000000f, HDMI_HTOP1_TISDREN);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_VIDEO_INPUT);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_CLK_TO_PHY);
+	hdmi_htop1_write(hdmi, 0x00000000, HDMI_HTOP1_VIDEO_INPUT2);
+	hdmi_htop1_write(hdmi, 0x0000000a, HDMI_HTOP1_CLK_SET);
+}
+
 static int __init sh_hdmi_probe(struct platform_device *pdev)
 {
 	struct sh_mobile_hdmi_info *pdata = pdev->dev.platform_data;
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct resource *htop1_res;
 	int irq = platform_get_irq(pdev, 0), ret;
 	struct sh_hdmi *hdmi;
 	long rate;
@@ -1156,6 +1281,15 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
 	if (!res || !pdata || irq < 0)
 		return -ENODEV;
 
+	htop1_res = NULL;
+	if (pdata->flags & HDMI_HAS_HTOP1) {
+		htop1_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		if (!htop1_res) {
+			dev_err(&pdev->dev, "htop1 needs register base\n");
+			return -EINVAL;
+		}
+	}
+
 	hdmi = kzalloc(sizeof(*hdmi), GFP_KERNEL);
 	if (!hdmi) {
 		dev_err(&pdev->dev, "Cannot allocate device data\n");
@@ -1227,6 +1361,17 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
 	if (pdata->flags & HDMI_OUTPUT_POLARITY_HI)
 		hdmi_bit_set(hdmi, 0x01, 0x01, HDMI_SYSTEM_CTRL);
 
+	/* enable htop1 register if needed */
+	if (htop1_res) {
+		hdmi->htop1 = ioremap(htop1_res->start, resource_size(htop1_res));
+		if (!hdmi->htop1) {
+			dev_err(&pdev->dev, "control register region already claimed\n");
+			ret = -ENOMEM;
+			goto emap_htop1;
+		}
+		sh_hdmi_htop1_init(hdmi);
+	}
+
 	/* Product and revision IDs are 0 in sh-mobile version */
 	dev_info(&pdev->dev, "Detected HDMI controller 0x%x:0x%x\n",
 		 hdmi_read(hdmi, HDMI_PRODUCT_ID), hdmi_read(hdmi, HDMI_REVISION_ID));
@@ -1250,6 +1395,9 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
 ecodec:
 	free_irq(irq, hdmi);
 ereqirq:
+	if (hdmi->htop1)
+		iounmap(hdmi->htop1);
+emap_htop1:
 	pm_runtime_put(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	iounmap(hdmi->base);
@@ -1281,6 +1429,8 @@ static int __exit sh_hdmi_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	clk_disable(hdmi->hdmi_clk);
 	clk_put(hdmi->hdmi_clk);
+	if (hdmi->htop1)
+		iounmap(hdmi->htop1);
 	iounmap(hdmi->base);
 	release_mem_region(res->start, resource_size(res));
 	kfree(hdmi);
diff --git a/include/video/sh_mobile_hdmi.h b/include/video/sh_mobile_hdmi.h
index ce8a540..63d20ef 100644
--- a/include/video/sh_mobile_hdmi.h
+++ b/include/video/sh_mobile_hdmi.h
@@ -38,6 +38,7 @@ struct clk;
 
 /* Chip specific option */
 #define HDMI_32BIT_REG		(1 << 8)
+#define HDMI_HAS_HTOP1		(1 << 9)
 
 struct sh_mobile_hdmi_info {
 	unsigned int			 flags;
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 3/4] fbdev: sh_mobile_hdmi: 32bit register access support
From: Kuninori Morimoto @ 2012-05-08  4:07 UTC (permalink / raw)
  To: linux-fbdev

Latest SuperH HDMI allows 32bit access only.
But the data is 8bit. So, we can keep compatibility by switching 8/32 bit access.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/video/sh_mobile_hdmi.c |   38 ++++++++++++++++++++++++++++++++++++--
 include/video/sh_mobile_hdmi.h |    5 ++++-
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 0bc39bc..4d48a80 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -222,20 +222,45 @@ struct sh_hdmi {
 	struct delayed_work edid_work;
 	struct fb_videomode mode;
 	struct fb_monspecs monspec;
+
+	/* register access functions */
+	void (*write)(struct sh_hdmi *hdmi, u8 data, u8 reg);
+	u8 (*read)(struct sh_hdmi *hdmi, u8 reg);
 };
 
 #define entity_to_sh_hdmi(e)	container_of(e, struct sh_hdmi, entity)
 
-static void hdmi_write(struct sh_hdmi *hdmi, u8 data, u8 reg)
+static void __hdmi_write8(struct sh_hdmi *hdmi, u8 data, u8 reg)
 {
 	iowrite8(data, hdmi->base + reg);
 }
 
-static u8 hdmi_read(struct sh_hdmi *hdmi, u8 reg)
+static u8 __hdmi_read8(struct sh_hdmi *hdmi, u8 reg)
 {
 	return ioread8(hdmi->base + reg);
 }
 
+static void __hdmi_write32(struct sh_hdmi *hdmi, u8 data, u8 reg)
+{
+	iowrite32((u32)data, hdmi->base + (reg * 4));
+	udelay(100);
+}
+
+static u8 __hdmi_read32(struct sh_hdmi *hdmi, u8 reg)
+{
+	return (u8)ioread32(hdmi->base + (reg * 4));
+}
+
+static void hdmi_write(struct sh_hdmi *hdmi, u8 data, u8 reg)
+{
+	hdmi->write(hdmi, data, reg);
+}
+
+static u8 hdmi_read(struct sh_hdmi *hdmi, u8 reg)
+{
+	return hdmi->read(hdmi, reg);
+}
+
 static void hdmi_bit_set(struct sh_hdmi *hdmi, u8 mask, u8 data, u8 reg)
 {
 	u8 val = hdmi_read(hdmi, reg);
@@ -1148,6 +1173,15 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
 		goto egetclk;
 	}
 
+	/* select register access functions */
+	if (pdata->flags & HDMI_32BIT_REG) {
+		hdmi->write	= __hdmi_write32;
+		hdmi->read	= __hdmi_read32;
+	} else {
+		hdmi->write	= __hdmi_write8;
+		hdmi->read	= __hdmi_read8;
+	}
+
 	/* An arbitrary relaxed pixclock just to get things started: from standard 480p */
 	rate = clk_round_rate(hdmi->hdmi_clk, PICOS2KHZ(37037));
 	if (rate > 0)
diff --git a/include/video/sh_mobile_hdmi.h b/include/video/sh_mobile_hdmi.h
index 2699635..ce8a540 100644
--- a/include/video/sh_mobile_hdmi.h
+++ b/include/video/sh_mobile_hdmi.h
@@ -18,10 +18,11 @@ struct clk;
 /*
  * flags format
  *
- * 0x000000BA
+ * 0x00000CBA
  *
  * A: Audio source select
  * B: Int output option
+ * C: Chip specific option
  */
 
 /* Audio source select */
@@ -35,6 +36,8 @@ struct clk;
 #define HDMI_OUTPUT_PUSH_PULL	(1 << 4) /* System control : output mode */
 #define HDMI_OUTPUT_POLARITY_HI	(1 << 5) /* System control : output polarity */
 
+/* Chip specific option */
+#define HDMI_32BIT_REG		(1 << 8)
 
 struct sh_mobile_hdmi_info {
 	unsigned int			 flags;
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 2/4] fbdev: sh_mobile_hdmi: add interrupt output option
From: Kuninori Morimoto @ 2012-05-08  4:07 UTC (permalink / raw)
  To: linux-fbdev

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/video/sh_mobile_hdmi.c |    7 +++++++
 include/video/sh_mobile_hdmi.h |    8 +++++++-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index e201d6f..0bc39bc 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1186,6 +1186,13 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_get_sync(&pdev->dev);
 
+	/* init interrupt polarity */
+	if (pdata->flags & HDMI_OUTPUT_PUSH_PULL)
+		hdmi_bit_set(hdmi, 0x02, 0x02, HDMI_SYSTEM_CTRL);
+
+	if (pdata->flags & HDMI_OUTPUT_POLARITY_HI)
+		hdmi_bit_set(hdmi, 0x01, 0x01, HDMI_SYSTEM_CTRL);
+
 	/* Product and revision IDs are 0 in sh-mobile version */
 	dev_info(&pdev->dev, "Detected HDMI controller 0x%x:0x%x\n",
 		 hdmi_read(hdmi, HDMI_PRODUCT_ID), hdmi_read(hdmi, HDMI_REVISION_ID));
diff --git a/include/video/sh_mobile_hdmi.h b/include/video/sh_mobile_hdmi.h
index 728f9de..2699635 100644
--- a/include/video/sh_mobile_hdmi.h
+++ b/include/video/sh_mobile_hdmi.h
@@ -18,9 +18,10 @@ struct clk;
 /*
  * flags format
  *
- * 0x0000000A
+ * 0x000000BA
  *
  * A: Audio source select
+ * B: Int output option
  */
 
 /* Audio source select */
@@ -30,6 +31,11 @@ struct clk;
 #define HDMI_SND_SRC_DSD	(2 << 0)
 #define HDMI_SND_SRC_HBR	(3 << 0)
 
+/* Int output option */
+#define HDMI_OUTPUT_PUSH_PULL	(1 << 4) /* System control : output mode */
+#define HDMI_OUTPUT_POLARITY_HI	(1 << 5) /* System control : output polarity */
+
+
 struct sh_mobile_hdmi_info {
 	unsigned int			 flags;
 	long (*clk_optimize_parent)(unsigned long target, unsigned long *best_freq,
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 1/4] fbdev: sh_mobile_hdmi: add hdmi_bit_set() function
From: Kuninori Morimoto @ 2012-05-08  4:06 UTC (permalink / raw)
  To: linux-fbdev

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/video/sh_mobile_hdmi.c |   22 ++++++++++++++++------
 1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index eafb19d..e201d6f 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -236,6 +236,16 @@ static u8 hdmi_read(struct sh_hdmi *hdmi, u8 reg)
 	return ioread8(hdmi->base + reg);
 }
 
+static void hdmi_bit_set(struct sh_hdmi *hdmi, u8 mask, u8 data, u8 reg)
+{
+	u8 val = hdmi_read(hdmi, reg);
+
+	val &= ~mask;
+	val |= (data & mask);
+
+	hdmi_write(hdmi, val, reg);
+}
+
 /*
  *	HDMI sound
  */
@@ -693,11 +703,11 @@ static void sh_hdmi_configure(struct sh_hdmi *hdmi)
 	msleep(10);
 
 	/* PS mode b->d, reset PLLA and PLLB */
-	hdmi_write(hdmi, 0x4C, HDMI_SYSTEM_CTRL);
+	hdmi_bit_set(hdmi, 0xFC, 0x4C, HDMI_SYSTEM_CTRL);
 
 	udelay(10);
 
-	hdmi_write(hdmi, 0x40, HDMI_SYSTEM_CTRL);
+	hdmi_bit_set(hdmi, 0xFC, 0x40, HDMI_SYSTEM_CTRL);
 }
 
 static unsigned long sh_hdmi_rate_error(struct sh_hdmi *hdmi,
@@ -917,13 +927,13 @@ static irqreturn_t sh_hdmi_hotplug(int irq, void *dev_id)
 	u8 status1, status2, mask1, mask2;
 
 	/* mode_b and PLLA and PLLB reset */
-	hdmi_write(hdmi, 0x2C, HDMI_SYSTEM_CTRL);
+	hdmi_bit_set(hdmi, 0xFC, 0x2C, HDMI_SYSTEM_CTRL);
 
 	/* How long shall reset be held? */
 	udelay(10);
 
 	/* mode_b and PLLA and PLLB reset release */
-	hdmi_write(hdmi, 0x20, HDMI_SYSTEM_CTRL);
+	hdmi_bit_set(hdmi, 0xFC, 0x20, HDMI_SYSTEM_CTRL);
 
 	status1 = hdmi_read(hdmi, HDMI_INTERRUPT_STATUS_1);
 	status2 = hdmi_read(hdmi, HDMI_INTERRUPT_STATUS_2);
@@ -1001,7 +1011,7 @@ static int sh_hdmi_display_on(struct sh_mobile_lcdc_entity *entity)
 	 */
 	if (hdmi->hp_state = HDMI_HOTPLUG_EDID_DONE) {
 		/* PS mode d->e. All functions are active */
-		hdmi_write(hdmi, 0x80, HDMI_SYSTEM_CTRL);
+		hdmi_bit_set(hdmi, 0xFC, 0x80, HDMI_SYSTEM_CTRL);
 		dev_dbg(hdmi->dev, "HDMI running\n");
 	}
 
@@ -1016,7 +1026,7 @@ static void sh_hdmi_display_off(struct sh_mobile_lcdc_entity *entity)
 
 	dev_dbg(hdmi->dev, "%s(%p)\n", __func__, hdmi);
 	/* PS mode e->a */
-	hdmi_write(hdmi, 0x10, HDMI_SYSTEM_CTRL);
+	hdmi_bit_set(hdmi, 0xFC, 0x10, HDMI_SYSTEM_CTRL);
 }
 
 static const struct sh_mobile_lcdc_entity_ops sh_hdmi_ops = {
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 0/4] fbdev: sh_mobile_hdmi: adds HDMI control register support
From: Kuninori Morimoto @ 2012-05-08  4:05 UTC (permalink / raw)
  To: linux-fbdev


Hi Florian
Cc: Magnus, Guennadi, Simon

These are sh_mobile_hdmi update patches to supporting
HDMI control register on latest SuperH chip

Kuninori Morimoto (4):
      fbdev: sh_mobile_hdmi: add hdmi_bit_set() function
      fbdev: sh_mobile_hdmi: add interrupt output option
      fbdev: sh_mobile_hdmi: 32bit register access support
      fbdev: sh_mobile_hdmi: add HDMI Control Register support

These patches add 32bit access support, and init control registers.
These are tested on Armadillo800eva board

Best regards
---
Kuninori Morimoto

^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted
From: Christoph Fritz @ 2012-05-07 21:55 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
	linux-fbdev
In-Reply-To: <20120504132845.GA24245@lovely.krouter>

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


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 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-07 17:46 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336053481-25433-1-git-send-email-tomi.valkeinen@ti.com>

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.

Regards,

Tony

^ permalink raw reply
* Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-07 15:03 UTC (permalink / raw)
  To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336028864-13895-5-git-send-email-archit@ti.com>

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thu, 2012-05-03 at 12:37 +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.
> 
> Create a function dss_mgr_get_timings() which returns the timings in manager's
> private data. 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>

> +struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr)
> +{
> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
> +
> +	return &mp->timings;
> +}

This one returns a pointer into apply.c's internal data structures. The
safest way would be to return a copy, but as it's an omapdss internal
function, I think it's enough to return a pointer to a const struct.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
From: Tomi Valkeinen @ 2012-05-07 14:47 UTC (permalink / raw)
  To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336028864-13895-2-git-send-email-archit@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

Hi,

On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
> DISPC manager size and DISPC manager blanking parameters(for LCD managers)
> follow the shadow register programming model. Currently, they are programmed
> directly by the interface drivers.
> 
> To configure manager timings using APPLY, there is a need to introduce extra
> info flags for managers, similar to what is done for overlays. This is needed
> because timings aren't a part of overlay_manager_info struct configured by a
> user of DSS, they are configured internally by the interface or panel drivers.
> 
> Add dirty and shadow_dirty extra_info flags for managers, update these flags
> at the appropriate places. Rewrite the function extra_info_update_ongoing()
> slightly as checking for manager's extra_info flags can simplify the code a bit.
> 
> Create function dss_mgr_set_timings() which applies the new manager timings to
> extra_info.
> 
> Signed-off-by: Archit Taneja <archit@ti.com>

<snip>

> +static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
> +		struct omap_video_timings *timings)
> +{
> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
> +
> +	mp->timings = *timings;
> +	mp->extra_info_dirty = true;
> +}
> +
> +void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
> +		struct omap_video_timings *timings)
> +{
> +	unsigned long flags;
> +
> +	mutex_lock(&apply_lock);
> +
> +	spin_lock_irqsave(&data_lock, flags);
> +
> +	dss_apply_mgr_timings(mgr, timings);
> +
> +	spin_unlock_irqrestore(&data_lock, flags);
> +
> +	mutex_unlock(&apply_lock);
> +}

With this, dpi.c & others still need to use dispc_mgr_go(), which is
something that should be removed and done only from apply.c.

dss_<ovl|mgr>_<enable|disable> functions handle GO, so you could have a
look at them. However, setting the timings is a bit different, so I'm
not sure how it should be done.

I think we have a few different options:

- Separate omapdss internal function (in apply.c) that can be used to
set GO after set_timings

- set GO in dss_mgr_set_timings(), but don't block

- set GO in dss_mgr_set_timings(), and block until the changes are in HW
(this is more or less what the dss_<ovl|mgr>_<enable|disable> functions
do).

The first one would be good if the interface drivers would need to set
multiple configurations, and we don't want to block after each set call.
But we don't have anything like that, at least currently.

The second one avoids blocking, but could perhaps cause problems because
the timings are not actually used yet when the function returns.

I don't see any problem with the last option, so I'm slightly leaning
towards it.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply
* [PATCH 2/2] OMAPDSS: HDMI: define and dump CORE registers in correct order
From: Archit Taneja @ 2012-05-07 13:32 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336396828-29311-1-git-send-email-archit@ti.com>

The HDMI core register offset macros aren't defined in ascending order of their
values, some of the offset macros are also redefined. The same issues occur when
these core registers are dumped.

Clean up the ordering of HDMI core registers and remove repeated registers in
the definition in ti_hdmi_4xxx_ip.h and in ti_hdmi_4xxx_core_dump().

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   65 +++++++++++++++--------------
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |   57 +++++++++++--------------
 2 files changed, 59 insertions(+), 63 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e266b8e..8fc09d4 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -900,6 +900,13 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
 	DUMPCORE(HDMI_CORE_SYS_SRST);
 	DUMPCORE(HDMI_CORE_CTRL1);
 	DUMPCORE(HDMI_CORE_SYS_SYS_STAT);
+	DUMPCORE(HDMI_CORE_SYS_DE_DLY);
+	DUMPCORE(HDMI_CORE_SYS_DE_CTRL);
+	DUMPCORE(HDMI_CORE_SYS_DE_TOP);
+	DUMPCORE(HDMI_CORE_SYS_DE_CNTL);
+	DUMPCORE(HDMI_CORE_SYS_DE_CNTH);
+	DUMPCORE(HDMI_CORE_SYS_DE_LINL);
+	DUMPCORE(HDMI_CORE_SYS_DE_LINH_1);
 	DUMPCORE(HDMI_CORE_SYS_VID_ACEN);
 	DUMPCORE(HDMI_CORE_SYS_VID_MODE);
 	DUMPCORE(HDMI_CORE_SYS_INTR_STATE);
@@ -909,49 +916,20 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
 	DUMPCORE(HDMI_CORE_SYS_INTR4);
 	DUMPCORE(HDMI_CORE_SYS_UMASK1);
 	DUMPCORE(HDMI_CORE_SYS_TMDS_CTRL);
-	DUMPCORE(HDMI_CORE_SYS_DE_DLY);
-	DUMPCORE(HDMI_CORE_SYS_DE_CTRL);
-	DUMPCORE(HDMI_CORE_SYS_DE_TOP);
-	DUMPCORE(HDMI_CORE_SYS_DE_CNTL);
-	DUMPCORE(HDMI_CORE_SYS_DE_CNTH);
-	DUMPCORE(HDMI_CORE_SYS_DE_LINL);
-	DUMPCORE(HDMI_CORE_SYS_DE_LINH_1);
 
-	DUMPCORE(HDMI_CORE_DDC_CMD);
-	DUMPCORE(HDMI_CORE_DDC_STATUS);
 	DUMPCORE(HDMI_CORE_DDC_ADDR);
+	DUMPCORE(HDMI_CORE_DDC_SEGM);
 	DUMPCORE(HDMI_CORE_DDC_OFFSET);
 	DUMPCORE(HDMI_CORE_DDC_COUNT1);
 	DUMPCORE(HDMI_CORE_DDC_COUNT2);
+	DUMPCORE(HDMI_CORE_DDC_STATUS);
+	DUMPCORE(HDMI_CORE_DDC_CMD);
 	DUMPCORE(HDMI_CORE_DDC_DATA);
-	DUMPCORE(HDMI_CORE_DDC_SEGM);
 
-	DUMPCOREAV(HDMI_CORE_AV_HDMI_CTRL);
-	DUMPCOREAV(HDMI_CORE_AV_DPD);
-	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL1);
-	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL2);
-	DUMPCOREAV(HDMI_CORE_AV_AVI_TYPE);
-	DUMPCOREAV(HDMI_CORE_AV_AVI_VERS);
-	DUMPCOREAV(HDMI_CORE_AV_AVI_LEN);
-	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);
 
 	DUMPCOREAV(HDMI_CORE_AV_ACR_CTRL);
 	DUMPCOREAV(HDMI_CORE_AV_FREQ_SVAL);
@@ -991,19 +969,42 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
 	DUMPCOREAV(HDMI_CORE_AV_AVI_VERS);
 	DUMPCOREAV(HDMI_CORE_AV_AVI_LEN);
 	DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM);
+
+	for (i = 0; i < HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++)
+		DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE);
+
 	DUMPCOREAV(HDMI_CORE_AV_SPD_TYPE);
 	DUMPCOREAV(HDMI_CORE_AV_SPD_VERS);
 	DUMPCOREAV(HDMI_CORE_AV_SPD_LEN);
 	DUMPCOREAV(HDMI_CORE_AV_SPD_CHSUM);
+
+	for (i = 0; i < HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++)
+		DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE);
+
 	DUMPCOREAV(HDMI_CORE_AV_AUDIO_TYPE);
 	DUMPCOREAV(HDMI_CORE_AV_AUDIO_VERS);
 	DUMPCOREAV(HDMI_CORE_AV_AUDIO_LEN);
 	DUMPCOREAV(HDMI_CORE_AV_AUDIO_CHSUM);
+
+	for (i = 0; i < HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++)
+		DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE);
+
 	DUMPCOREAV(HDMI_CORE_AV_MPEG_TYPE);
 	DUMPCOREAV(HDMI_CORE_AV_MPEG_VERS);
 	DUMPCOREAV(HDMI_CORE_AV_MPEG_LEN);
 	DUMPCOREAV(HDMI_CORE_AV_MPEG_CHSUM);
+
+	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);
+
 	DUMPCOREAV(HDMI_CORE_AV_CP_BYTE1);
+
+	for (i = 0; i < HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++)
+		DUMPCOREAV2(i, HDMI_CORE_AV_GEN2_DBYTE);
+
 	DUMPCOREAV(HDMI_CORE_AV_CEC_ADDR_ID);
 }
 
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a14d1a0..b724bc6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -57,6 +57,13 @@
 #define HDMI_CORE_SYS_SRST			0x14
 #define HDMI_CORE_CTRL1				0x20
 #define HDMI_CORE_SYS_SYS_STAT			0x24
+#define HDMI_CORE_SYS_DE_DLY			0xC8
+#define HDMI_CORE_SYS_DE_CTRL			0xCC
+#define HDMI_CORE_SYS_DE_TOP			0xD0
+#define HDMI_CORE_SYS_DE_CNTL			0xD8
+#define HDMI_CORE_SYS_DE_CNTH			0xDC
+#define HDMI_CORE_SYS_DE_LINL			0xE0
+#define HDMI_CORE_SYS_DE_LINH_1			0xE4
 #define HDMI_CORE_SYS_VID_ACEN			0x124
 #define HDMI_CORE_SYS_VID_MODE			0x128
 #define HDMI_CORE_SYS_INTR_STATE		0x1C0
@@ -66,50 +73,24 @@
 #define HDMI_CORE_SYS_INTR4			0x1D0
 #define HDMI_CORE_SYS_UMASK1			0x1D4
 #define HDMI_CORE_SYS_TMDS_CTRL			0x208
-#define HDMI_CORE_SYS_DE_DLY			0xC8
-#define HDMI_CORE_SYS_DE_CTRL			0xCC
-#define HDMI_CORE_SYS_DE_TOP			0xD0
-#define HDMI_CORE_SYS_DE_CNTL			0xD8
-#define HDMI_CORE_SYS_DE_CNTH			0xDC
-#define HDMI_CORE_SYS_DE_LINL			0xE0
-#define HDMI_CORE_SYS_DE_LINH_1			0xE4
+
 #define HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC	0x1
 #define HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC	0x1
-#define HDMI_CORE_CTRL1_BSEL_24BITBUS		0x1
+#define HDMI_CORE_CTRL1_BSEL_24BITBUS	0x1
 #define HDMI_CORE_CTRL1_EDGE_RISINGEDGE	0x1
 
 /* HDMI DDC E-DID */
-#define HDMI_CORE_DDC_CMD			0x3CC
-#define HDMI_CORE_DDC_STATUS			0x3C8
 #define HDMI_CORE_DDC_ADDR			0x3B4
+#define HDMI_CORE_DDC_SEGM			0x3B8
 #define HDMI_CORE_DDC_OFFSET			0x3BC
 #define HDMI_CORE_DDC_COUNT1			0x3C0
 #define HDMI_CORE_DDC_COUNT2			0x3C4
+#define HDMI_CORE_DDC_STATUS			0x3C8
+#define HDMI_CORE_DDC_CMD			0x3CC
 #define HDMI_CORE_DDC_DATA			0x3D0
-#define HDMI_CORE_DDC_SEGM			0x3B8
 
 /* HDMI IP Core Audio Video */
 
-#define HDMI_CORE_AV_HDMI_CTRL			0xBC
-#define HDMI_CORE_AV_DPD			0xF4
-#define HDMI_CORE_AV_PB_CTRL1			0xF8
-#define HDMI_CORE_AV_PB_CTRL2			0xFC
-#define HDMI_CORE_AV_AVI_TYPE			0x100
-#define HDMI_CORE_AV_AVI_VERS			0x104
-#define HDMI_CORE_AV_AVI_LEN			0x108
-#define HDMI_CORE_AV_AVI_CHSUM			0x10C
-#define HDMI_CORE_AV_AVI_DBYTE(n)		(n * 4 + 0x110)
-#define HDMI_CORE_AV_AVI_DBYTE_NELEMS		15
-#define HDMI_CORE_AV_SPD_DBYTE(n)		(n * 4 + 0x190)
-#define HDMI_CORE_AV_SPD_DBYTE_NELEMS		27
-#define HDMI_CORE_AV_AUD_DBYTE(n)		(n * 4 + 0x210)
-#define HDMI_CORE_AV_AUD_DBYTE_NELEMS		10
-#define HDMI_CORE_AV_MPEG_DBYTE(n)		(n * 4 + 0x290)
-#define HDMI_CORE_AV_MPEG_DBYTE_NELEMS		27
-#define HDMI_CORE_AV_GEN_DBYTE(n)		(n * 4 + 0x300)
-#define HDMI_CORE_AV_GEN_DBYTE_NELEMS		31
-#define HDMI_CORE_AV_GEN2_DBYTE(n)		(n * 4 + 0x380)
-#define HDMI_CORE_AV_GEN2_DBYTE_NELEMS		31
 #define HDMI_CORE_AV_ACR_CTRL			0x4
 #define HDMI_CORE_AV_FREQ_SVAL			0x8
 #define HDMI_CORE_AV_N_SVAL1			0xC
@@ -148,25 +129,39 @@
 #define HDMI_CORE_AV_AVI_VERS			0x104
 #define HDMI_CORE_AV_AVI_LEN			0x108
 #define HDMI_CORE_AV_AVI_CHSUM			0x10C
+#define HDMI_CORE_AV_AVI_DBYTE(n)		(n * 4 + 0x110)
 #define HDMI_CORE_AV_SPD_TYPE			0x180
 #define HDMI_CORE_AV_SPD_VERS			0x184
 #define HDMI_CORE_AV_SPD_LEN			0x188
 #define HDMI_CORE_AV_SPD_CHSUM			0x18C
+#define HDMI_CORE_AV_SPD_DBYTE(n)		(n * 4 + 0x190)
 #define HDMI_CORE_AV_AUDIO_TYPE			0x200
 #define HDMI_CORE_AV_AUDIO_VERS			0x204
 #define HDMI_CORE_AV_AUDIO_LEN			0x208
 #define HDMI_CORE_AV_AUDIO_CHSUM		0x20C
+#define HDMI_CORE_AV_AUD_DBYTE(n)		(n * 4 + 0x210)
 #define HDMI_CORE_AV_MPEG_TYPE			0x280
 #define HDMI_CORE_AV_MPEG_VERS			0x284
 #define HDMI_CORE_AV_MPEG_LEN			0x288
 #define HDMI_CORE_AV_MPEG_CHSUM			0x28C
+#define HDMI_CORE_AV_MPEG_DBYTE(n)		(n * 4 + 0x290)
+#define HDMI_CORE_AV_GEN_DBYTE(n)		(n * 4 + 0x300)
 #define HDMI_CORE_AV_CP_BYTE1			0x37C
+#define HDMI_CORE_AV_GEN2_DBYTE(n)		(n * 4 + 0x380)
 #define HDMI_CORE_AV_CEC_ADDR_ID		0x3FC
+
 #define HDMI_CORE_AV_SPD_DBYTE_ELSIZE		0x4
 #define HDMI_CORE_AV_GEN2_DBYTE_ELSIZE		0x4
 #define HDMI_CORE_AV_MPEG_DBYTE_ELSIZE		0x4
 #define HDMI_CORE_AV_GEN_DBYTE_ELSIZE		0x4
 
+#define HDMI_CORE_AV_AVI_DBYTE_NELEMS		15
+#define HDMI_CORE_AV_SPD_DBYTE_NELEMS		27
+#define HDMI_CORE_AV_AUD_DBYTE_NELEMS		10
+#define HDMI_CORE_AV_MPEG_DBYTE_NELEMS		27
+#define HDMI_CORE_AV_GEN_DBYTE_NELEMS		31
+#define HDMI_CORE_AV_GEN2_DBYTE_NELEMS		31
+
 /* PLL */
 
 #define PLLCTRL_PLL_CONTROL			0x0
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 1/2] OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
From: Archit Taneja @ 2012-05-07 13:32 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336396828-29311-1-git-send-email-archit@ti.com>

The function ti_hdmi_4xxx_core_dump has some bugs, the following mention the
bugs and the solutions:

- The macros DUMPCORE and DUMPCOREAV in ti_hdmi_4xxx_core_dump() use
  hdmi_pll_base() for the offsets needed to calculate register addresses, use
  functions hdmi_core_sys_base() amd hdmi_av_base() to calculate the correct
  offsets for CORE_SYS and CORE_AV registers.

- Many of the CORE_AV registers use the DUMPCORE macro, and hence the register
  addresses are calculated incorrectly. Rename the current DUMPCOREAV macro as
  DUMPCOREAV2 as it takes 2 arguments to dump indexed CORE_AV registers, create
  a new macro called DUMPCOREAV which is now used for dumping non-indexed
  CORE_AV registers.

Thanks to Ancy Tom <ancytom@gmail.com> for pointing out the issues.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |  142 +++++++++++++++--------------
 1 files changed, 72 insertions(+), 70 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bfe6fe6..e266b8e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -886,10 +886,12 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
 
 #define CORE_REG(i, name) name(i)
 #define DUMPCORE(r) seq_printf(s, "%-35s %08x\n", #r,\
-		hdmi_read_reg(hdmi_pll_base(ip_data), r))
-#define DUMPCOREAV(i, r) seq_printf(s, "%s[%d]%*s %08x\n", #r, i, \
+		hdmi_read_reg(hdmi_core_sys_base(ip_data), r))
+#define DUMPCOREAV(r) seq_printf(s, "%-35s %08x\n", #r,\
+		hdmi_read_reg(hdmi_av_base(ip_data), r))
+#define DUMPCOREAV2(i, r) seq_printf(s, "%s[%d]%*s %08x\n", #r, i, \
 		(i < 10) ? 32 - strlen(#r) : 31 - strlen(#r), " ", \
-		hdmi_read_reg(hdmi_pll_base(ip_data), CORE_REG(i, r)))
+		hdmi_read_reg(hdmi_av_base(ip_data), CORE_REG(i, r)))
 
 	DUMPCORE(HDMI_CORE_SYS_VND_IDL);
 	DUMPCORE(HDMI_CORE_SYS_DEV_IDL);
@@ -924,85 +926,85 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
 	DUMPCORE(HDMI_CORE_DDC_DATA);
 	DUMPCORE(HDMI_CORE_DDC_SEGM);
 
-	DUMPCORE(HDMI_CORE_AV_HDMI_CTRL);
-	DUMPCORE(HDMI_CORE_AV_DPD);
-	DUMPCORE(HDMI_CORE_AV_PB_CTRL1);
-	DUMPCORE(HDMI_CORE_AV_PB_CTRL2);
-	DUMPCORE(HDMI_CORE_AV_AVI_TYPE);
-	DUMPCORE(HDMI_CORE_AV_AVI_VERS);
-	DUMPCORE(HDMI_CORE_AV_AVI_LEN);
-	DUMPCORE(HDMI_CORE_AV_AVI_CHSUM);
+	DUMPCOREAV(HDMI_CORE_AV_HDMI_CTRL);
+	DUMPCOREAV(HDMI_CORE_AV_DPD);
+	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL1);
+	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL2);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_TYPE);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_VERS);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM);
 
 	for (i = 0; i < HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_AVI_DBYTE);
+		DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE);
 
 	for (i = 0; i < HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_SPD_DBYTE);
+		DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE);
 
 	for (i = 0; i < HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_AUD_DBYTE);
+		DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE);
 
 	for (i = 0; i < HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_MPEG_DBYTE);
+		DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE);
 
 	for (i = 0; i < HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_GEN_DBYTE);
+		DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE);
 
 	for (i = 0; i < HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++)
-		DUMPCOREAV(i, HDMI_CORE_AV_GEN2_DBYTE);
-
-	DUMPCORE(HDMI_CORE_AV_ACR_CTRL);
-	DUMPCORE(HDMI_CORE_AV_FREQ_SVAL);
-	DUMPCORE(HDMI_CORE_AV_N_SVAL1);
-	DUMPCORE(HDMI_CORE_AV_N_SVAL2);
-	DUMPCORE(HDMI_CORE_AV_N_SVAL3);
-	DUMPCORE(HDMI_CORE_AV_CTS_SVAL1);
-	DUMPCORE(HDMI_CORE_AV_CTS_SVAL2);
-	DUMPCORE(HDMI_CORE_AV_CTS_SVAL3);
-	DUMPCORE(HDMI_CORE_AV_CTS_HVAL1);
-	DUMPCORE(HDMI_CORE_AV_CTS_HVAL2);
-	DUMPCORE(HDMI_CORE_AV_CTS_HVAL3);
-	DUMPCORE(HDMI_CORE_AV_AUD_MODE);
-	DUMPCORE(HDMI_CORE_AV_SPDIF_CTRL);
-	DUMPCORE(HDMI_CORE_AV_HW_SPDIF_FS);
-	DUMPCORE(HDMI_CORE_AV_SWAP_I2S);
-	DUMPCORE(HDMI_CORE_AV_SPDIF_ERTH);
-	DUMPCORE(HDMI_CORE_AV_I2S_IN_MAP);
-	DUMPCORE(HDMI_CORE_AV_I2S_IN_CTRL);
-	DUMPCORE(HDMI_CORE_AV_I2S_CHST0);
-	DUMPCORE(HDMI_CORE_AV_I2S_CHST1);
-	DUMPCORE(HDMI_CORE_AV_I2S_CHST2);
-	DUMPCORE(HDMI_CORE_AV_I2S_CHST4);
-	DUMPCORE(HDMI_CORE_AV_I2S_CHST5);
-	DUMPCORE(HDMI_CORE_AV_ASRC);
-	DUMPCORE(HDMI_CORE_AV_I2S_IN_LEN);
-	DUMPCORE(HDMI_CORE_AV_HDMI_CTRL);
-	DUMPCORE(HDMI_CORE_AV_AUDO_TXSTAT);
-	DUMPCORE(HDMI_CORE_AV_AUD_PAR_BUSCLK_1);
-	DUMPCORE(HDMI_CORE_AV_AUD_PAR_BUSCLK_2);
-	DUMPCORE(HDMI_CORE_AV_AUD_PAR_BUSCLK_3);
-	DUMPCORE(HDMI_CORE_AV_TEST_TXCTRL);
-	DUMPCORE(HDMI_CORE_AV_DPD);
-	DUMPCORE(HDMI_CORE_AV_PB_CTRL1);
-	DUMPCORE(HDMI_CORE_AV_PB_CTRL2);
-	DUMPCORE(HDMI_CORE_AV_AVI_TYPE);
-	DUMPCORE(HDMI_CORE_AV_AVI_VERS);
-	DUMPCORE(HDMI_CORE_AV_AVI_LEN);
-	DUMPCORE(HDMI_CORE_AV_AVI_CHSUM);
-	DUMPCORE(HDMI_CORE_AV_SPD_TYPE);
-	DUMPCORE(HDMI_CORE_AV_SPD_VERS);
-	DUMPCORE(HDMI_CORE_AV_SPD_LEN);
-	DUMPCORE(HDMI_CORE_AV_SPD_CHSUM);
-	DUMPCORE(HDMI_CORE_AV_AUDIO_TYPE);
-	DUMPCORE(HDMI_CORE_AV_AUDIO_VERS);
-	DUMPCORE(HDMI_CORE_AV_AUDIO_LEN);
-	DUMPCORE(HDMI_CORE_AV_AUDIO_CHSUM);
-	DUMPCORE(HDMI_CORE_AV_MPEG_TYPE);
-	DUMPCORE(HDMI_CORE_AV_MPEG_VERS);
-	DUMPCORE(HDMI_CORE_AV_MPEG_LEN);
-	DUMPCORE(HDMI_CORE_AV_MPEG_CHSUM);
-	DUMPCORE(HDMI_CORE_AV_CP_BYTE1);
-	DUMPCORE(HDMI_CORE_AV_CEC_ADDR_ID);
+		DUMPCOREAV2(i, HDMI_CORE_AV_GEN2_DBYTE);
+
+	DUMPCOREAV(HDMI_CORE_AV_ACR_CTRL);
+	DUMPCOREAV(HDMI_CORE_AV_FREQ_SVAL);
+	DUMPCOREAV(HDMI_CORE_AV_N_SVAL1);
+	DUMPCOREAV(HDMI_CORE_AV_N_SVAL2);
+	DUMPCOREAV(HDMI_CORE_AV_N_SVAL3);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_SVAL1);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_SVAL2);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_SVAL3);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_HVAL1);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_HVAL2);
+	DUMPCOREAV(HDMI_CORE_AV_CTS_HVAL3);
+	DUMPCOREAV(HDMI_CORE_AV_AUD_MODE);
+	DUMPCOREAV(HDMI_CORE_AV_SPDIF_CTRL);
+	DUMPCOREAV(HDMI_CORE_AV_HW_SPDIF_FS);
+	DUMPCOREAV(HDMI_CORE_AV_SWAP_I2S);
+	DUMPCOREAV(HDMI_CORE_AV_SPDIF_ERTH);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_IN_MAP);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_IN_CTRL);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_CHST0);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_CHST1);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_CHST2);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_CHST4);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_CHST5);
+	DUMPCOREAV(HDMI_CORE_AV_ASRC);
+	DUMPCOREAV(HDMI_CORE_AV_I2S_IN_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_HDMI_CTRL);
+	DUMPCOREAV(HDMI_CORE_AV_AUDO_TXSTAT);
+	DUMPCOREAV(HDMI_CORE_AV_AUD_PAR_BUSCLK_1);
+	DUMPCOREAV(HDMI_CORE_AV_AUD_PAR_BUSCLK_2);
+	DUMPCOREAV(HDMI_CORE_AV_AUD_PAR_BUSCLK_3);
+	DUMPCOREAV(HDMI_CORE_AV_TEST_TXCTRL);
+	DUMPCOREAV(HDMI_CORE_AV_DPD);
+	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL1);
+	DUMPCOREAV(HDMI_CORE_AV_PB_CTRL2);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_TYPE);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_VERS);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM);
+	DUMPCOREAV(HDMI_CORE_AV_SPD_TYPE);
+	DUMPCOREAV(HDMI_CORE_AV_SPD_VERS);
+	DUMPCOREAV(HDMI_CORE_AV_SPD_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_SPD_CHSUM);
+	DUMPCOREAV(HDMI_CORE_AV_AUDIO_TYPE);
+	DUMPCOREAV(HDMI_CORE_AV_AUDIO_VERS);
+	DUMPCOREAV(HDMI_CORE_AV_AUDIO_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_AUDIO_CHSUM);
+	DUMPCOREAV(HDMI_CORE_AV_MPEG_TYPE);
+	DUMPCOREAV(HDMI_CORE_AV_MPEG_VERS);
+	DUMPCOREAV(HDMI_CORE_AV_MPEG_LEN);
+	DUMPCOREAV(HDMI_CORE_AV_MPEG_CHSUM);
+	DUMPCOREAV(HDMI_CORE_AV_CP_BYTE1);
+	DUMPCOREAV(HDMI_CORE_AV_CEC_ADDR_ID);
 }
 
 void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
From: Archit Taneja @ 2012-05-07 13:32 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja

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(-)

-- 
1.7.5.4


^ permalink raw reply
* [PATCH 6/6] OMAPDSS: DISPC: Remove Fake VSYNC support
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>

Fake VSYNC support is a hack and has some bugs in it. It isn't used by any user
of DSS. Remove Fake VSYNC support. For DSI command mode and RFBI panels, a user
of DSS should wait for the completion of a frame by using the panel driver's
sync op.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/video/omap2/dss/Kconfig |    9 ---------
 drivers/video/omap2/dss/dispc.c |   21 ---------------------
 drivers/video/omap2/dss/dsi.c   |    4 ----
 drivers/video/omap2/dss/dss.h   |    1 -
 4 files changed, 0 insertions(+), 35 deletions(-)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 7be7c06..9aaf324 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -90,15 +90,6 @@ config OMAP2_DSS_DSI
 
 	  See http://www.mipi.org/ for DSI spesifications.
 
-config OMAP2_DSS_FAKE_VSYNC
-	bool "Fake VSYNC irq from manual update displays"
-	default n
-	help
-	  If this is selected, DSI will generate a fake DISPC VSYNC interrupt
-	  when DSI has sent a frame. This is only needed with DSI or RFBI
-	  displays using manual mode, and you want VSYNC to, for example,
-	  time animation.
-
 config OMAP2_DSS_MIN_FCK_PER_PCK
 	int "Minimum FCK/PCK ratio (for scaling)"
 	range 0 32
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ef131cd..89d54c5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3443,27 +3443,6 @@ int omap_dispc_wait_for_irq_interruptible_timeout(u32 irqmask,
 	return 0;
 }
 
-#ifdef CONFIG_OMAP2_DSS_FAKE_VSYNC
-void dispc_fake_vsync_irq(void)
-{
-	u32 irqstatus = DISPC_IRQ_VSYNC;
-	int i;
-
-	WARN_ON(!in_interrupt());
-
-	for (i = 0; i < DISPC_MAX_NR_ISRS; i++) {
-		struct omap_dispc_isr_data *isr_data;
-		isr_data = &dispc.registered_isr[i];
-
-		if (!isr_data->isr)
-			continue;
-
-		if (isr_data->mask & irqstatus)
-			isr_data->isr(isr_data->arg, irqstatus);
-	}
-}
-#endif
-
 static void _omap_dispc_initialize_irq(void)
 {
 	unsigned long flags;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index db73598..95bc996 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4152,10 +4152,6 @@ static void dsi_framedone_irq_callback(void *data, u32 mask)
 	__cancel_delayed_work(&dsi->framedone_timeout_work);
 
 	dsi_handle_framedone(dsidev, 0);
-
-#ifdef CONFIG_OMAP2_DSS_FAKE_VSYNC
-	dispc_fake_vsync_irq();
-#endif
 }
 
 int omap_dsi_update(struct omap_dss_device *dssdev, int channel,
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f2a51c6..6699197 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -399,7 +399,6 @@ void dispc_dump_clocks(struct seq_file *s);
 void dispc_dump_irqs(struct seq_file *s);
 void dispc_dump_regs(struct seq_file *s);
 void dispc_irq_handler(void);
-void dispc_fake_vsync_irq(void);
 
 int dispc_runtime_get(void);
 void dispc_runtime_put(void);
-- 
1.7.5.4


^ permalink raw reply related
* [PATCH 5/6] OMAPDSS: Fix DSI_FCLK clock source selection
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>

The wrong bit field was being updated in DSS_CTRL when trying to configure the
clock source of DSI2 functional clock. Use the correct bit field based on the
dsi module number.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/video/omap2/dss/dss.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index e731aa4..e212acb 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -335,7 +335,7 @@ void dss_select_dsi_clk_source(int dsi_module,
 		enum omap_dss_clk_source clk_src)
 {
 	struct platform_device *dsidev;
-	int b;
+	int b, pos;
 
 	switch (clk_src) {
 	case OMAP_DSS_CLK_SRC_FCK:
@@ -357,7 +357,8 @@ void dss_select_dsi_clk_source(int dsi_module,
 		BUG();
 	}
 
-	REG_FLD_MOD(DSS_CONTROL, b, 1, 1);	/* DSI_CLK_SWITCH */
+	pos = dsi_module = 0 ? 1 : 10;
+	REG_FLD_MOD(DSS_CONTROL, b, pos, pos);	/* DSIx_CLK_SWITCH */
 
 	dss.dsi_clk_source[dsi_module] = clk_src;
 }
-- 
1.7.5.4


^ permalink raw reply related
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox