[PATCH 0/3] Improve dw-hdmi CTS/N setting

[PATCH 0/3] Improve dw-hdmi CTS/N setting

[Russell King - ARM Linux]

All,

This is a mini-series to try and move audio support for the Designware
HDMI bridge along.

There are two known versions of the Designware HDMI audio:

- The Rockchip version, which is based upon feeding the HDMI block I2S
  stream(s), which doesn't have any on-board DMA support.
- The Freescale version, which only has AHB DMA support.

There are two drivers around at present, one which I've had which is
ALSA based due to its simplicity for the Freescale version of the IP,
and one which is ASoC based from Yakir Yang for the Rockchip version.

There is some commonality between the two drivers - for example, the
setup of the CTS/N values is very similar, although not identical.

I have been reviewing (when time permits) the patches from Yakir Yang,
and making recommendations to try and extract the common parts of the
driver.  This is the patch set I came up with (mentioned in
20150202130920.GC8656 at n2100.arm.linux.org.uk).

Yakir merged some of my ideas into his patch set - for example, Yakir
Yang's "drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
hdmi_regenerate_cts()" is very close to the version which I came up
with.

Yakir Yang didn't include the mutex patch, which I've included here -
it really is necessary because we have potentially two different
threads which can change the CTS/N values - a change of the video mode
vs a change in the audio driver.

The last patch is adjusting the CTS/N setting order - I have only gone
as far as what we know works for iMX6, and this is also identical to
Yakir Yang's patch.

The identical nature is hardly surprising; my patches were derived from
a previous set of his patches (which I acknowledge in the commit messages)
and I detailed in the above message what I wanted to see.

What I would like to see is that - as we are effectively in agreement
over two of these patches - we get these patches merged rather than
having to repeatedly see them.  If there's any objection, please let me
know, otherwise I'll collect acks and send them to David.

 drivers/gpu/drm/bridge/dw_hdmi.c | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()

[Russell King]

Combine these two functions into a single implementation.  These two
functions are called consecutively anyway.  Idea from a patch by
Yakir Yang.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cd6a70647e32..78363552d80e 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -177,19 +177,16 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
 	hdmi_modb(hdmi, data << shift, mask, reg);
 }
 
-static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
-					 unsigned int value)
+static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned int cts,
+			   unsigned int n)
 {
-	hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
-	hdmi_writeb(hdmi, (value >> 8) & 0xff, HDMI_AUD_N2);
-	hdmi_writeb(hdmi, (value >> 16) & 0x0f, HDMI_AUD_N3);
+	hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
+	hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
+	hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
 
 	/* nshift factor = 0 */
 	hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
-}
 
-static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
-{
 	/* Must be set/cleared first */
 	hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
 
@@ -355,8 +352,7 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
 		__func__, hdmi->sample_rate, hdmi->ratio,
 		pixel_clk, clk_n, clk_cts);
 
-	hdmi_set_clock_regenerator_n(hdmi, clk_n);
-	hdmi_regenerate_cts(hdmi, clk_cts);
+	hdmi_set_cts_n(hdmi, clk_cts, clk_n);
 }
 
 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
-- 
1.8.3.1

[PATCH 2/3] drm: bridge/dw_hdmi: protect n/cts setting with a mutex

[Russell King]

The HDMI n/cts settings need to be updated whenever the audio sample
rate or the video pixel clock changes.  This needs to be protected
against concurrency as there is no synchronisation between these two
operations.  Introduce a mutex (called audio_mutex) to protect against
two threads trying to update the video clock rate and pixel clock
simultaneously.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 78363552d80e..b75922d4901e 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/hdmi.h>
+#include <linux/mutex.h>
 #include <linux/of_device.h>
 
 #include <drm/drm_of.h>
@@ -126,6 +127,7 @@ struct dw_hdmi {
 	struct i2c_adapter *ddc;
 	void __iomem *regs;
 
+	struct mutex audio_mutex;
 	unsigned int sample_rate;
 	int ratio;
 
@@ -357,12 +359,16 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
 
 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
 {
+	mutex_lock(&hdmi->audio_mutex);
 	hdmi_set_clk_regenerator(hdmi, 74250000);
+	mutex_unlock(&hdmi->audio_mutex);
 }
 
 static void hdmi_clk_regenerator_update_pixel_clock(struct dw_hdmi *hdmi)
 {
+	mutex_lock(&hdmi->audio_mutex);
 	hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock);
+	mutex_unlock(&hdmi->audio_mutex);
 }
 
 /*
@@ -1565,6 +1571,8 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 	hdmi->ratio = 100;
 	hdmi->encoder = encoder;
 
+	mutex_init(&hdmi->audio_mutex);
+
 	of_property_read_u32(np, "reg-io-width", &val);
 
 	switch (val) {
-- 
1.8.3.1

[PATCH 3/3] drm: bridge/dw_hdmi: adjust n/cts setting order

[Russell King]

Patch derived from one from Yakir Yang.  Yakir Yang says:
For Designerware HDMI, the following write sequence is recommended:
1. aud_n3 (set bit ncts_atomic_write if desired)
2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
3. aud_cts2 (required in CTS_manual)
4. aud_cts1 (required in CTS_manual)
5. aud_n3 (bit ncts_atomic_write with same value as in step 1.)
6. aud_n2
7. aud_n1

However, avoid the ncts_atomic_write_bit and CTS_manual settings in this
patch, both of which are marked reserved in the iMX6 documentation.  All
iMX6 code in the wild seems to want CTS_manual cleared.

Having requested clarification from FSL, it appears that neither of
these bits are implemented in their version of the IP.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index b75922d4901e..cca1c3d165e2 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -182,20 +182,20 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
 static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned int cts,
 			   unsigned int n)
 {
-	hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
-	hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
-	hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
+	/* Must be set/cleared first */
+	hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
 
 	/* nshift factor = 0 */
 	hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
 
-	/* Must be set/cleared first */
-	hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
-
-	hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
-	hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
 	hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
 		    HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
+	hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
+	hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
+
+	hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
+	hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
+	hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
 }
 
 static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk,
-- 
1.8.3.1

[PATCH 0/3] Improve dw-hdmi CTS/N setting

[Philipp Zabel]

Hi Russell,

Am Freitag, den 27.03.2015, 11:13 +0000 schrieb Russell King - ARM
Linux:
> All,
> 
> This is a mini-series to try and move audio support for the Designware
> HDMI bridge along.
>
> There are two known versions of the Designware HDMI audio:
> 
> - The Rockchip version, which is based upon feeding the HDMI block I2S
>   stream(s), which doesn't have any on-board DMA support.
> - The Freescale version, which only has AHB DMA support.
> 
> There are two drivers around at present, one which I've had which is
> ALSA based due to its simplicity for the Freescale version of the IP,
> and one which is ASoC based from Yakir Yang for the Rockchip version.
> 
> There is some commonality between the two drivers - for example, the
> setup of the CTS/N values is very similar, although not identical.
> 
> I have been reviewing (when time permits) the patches from Yakir Yang,
> and making recommendations to try and extract the common parts of the
> driver.  This is the patch set I came up with (mentioned in
> 20150202130920.GC8656 at n2100.arm.linux.org.uk).
> 
> Yakir merged some of my ideas into his patch set - for example, Yakir
> Yang's "drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
> hdmi_regenerate_cts()" is very close to the version which I came up
> with.
> 
> Yakir Yang didn't include the mutex patch, which I've included here -
> it really is necessary because we have potentially two different
> threads which can change the CTS/N values - a change of the video mode
> vs a change in the audio driver.
> 
> The last patch is adjusting the CTS/N setting order - I have only gone
> as far as what we know works for iMX6, and this is also identical to
> Yakir Yang's patch.
> 
> The identical nature is hardly surprising; my patches were derived from
> a previous set of his patches (which I acknowledge in the commit messages)
> and I detailed in the above message what I wanted to see.
> 
> What I would like to see is that - as we are effectively in agreement
> over two of these patches - we get these patches merged rather than
> having to repeatedly see them.  If there's any objection, please let me
> know, otherwise I'll collect acks and send them to David.

Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Also,
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
(with your dw-hdmi-audio patches on i.MX6)

best regards
Philipp

[PATCH 0/3] Improve dw-hdmi CTS/N setting

[Russell King - ARM Linux]

On Mon, Mar 30, 2015 at 11:43:17AM +0200, Philipp Zabel wrote:
> Hi Russell,
> 
> Am Freitag, den 27.03.2015, 11:13 +0000 schrieb Russell King - ARM
> Linux:
> > All,
> > 
> > This is a mini-series to try and move audio support for the Designware
> > HDMI bridge along.
> >
> > There are two known versions of the Designware HDMI audio:
> > 
> > - The Rockchip version, which is based upon feeding the HDMI block I2S
> >   stream(s), which doesn't have any on-board DMA support.
> > - The Freescale version, which only has AHB DMA support.
> > 
> > There are two drivers around at present, one which I've had which is
> > ALSA based due to its simplicity for the Freescale version of the IP,
> > and one which is ASoC based from Yakir Yang for the Rockchip version.
> > 
> > There is some commonality between the two drivers - for example, the
> > setup of the CTS/N values is very similar, although not identical.
> > 
> > I have been reviewing (when time permits) the patches from Yakir Yang,
> > and making recommendations to try and extract the common parts of the
> > driver.  This is the patch set I came up with (mentioned in
> > 20150202130920.GC8656 at n2100.arm.linux.org.uk).
> > 
> > Yakir merged some of my ideas into his patch set - for example, Yakir
> > Yang's "drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
> > hdmi_regenerate_cts()" is very close to the version which I came up
> > with.
> > 
> > Yakir Yang didn't include the mutex patch, which I've included here -
> > it really is necessary because we have potentially two different
> > threads which can change the CTS/N values - a change of the video mode
> > vs a change in the audio driver.
> > 
> > The last patch is adjusting the CTS/N setting order - I have only gone
> > as far as what we know works for iMX6, and this is also identical to
> > Yakir Yang's patch.
> > 
> > The identical nature is hardly surprising; my patches were derived from
> > a previous set of his patches (which I acknowledge in the commit messages)
> > and I detailed in the above message what I wanted to see.
> > 
> > What I would like to see is that - as we are effectively in agreement
> > over two of these patches - we get these patches merged rather than
> > having to repeatedly see them.  If there's any objection, please let me
> > know, otherwise I'll collect acks and send them to David.
> 
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Also,
> Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> (with your dw-hdmi-audio patches on i.MX6)

Thanks.

I'd really like an Acked-by from Andy Yan on these patches so that we
can be sure we have agreement that these should be merged.

Over the last few days, I've separated out some more patches from the
audio work, and also cleaned up dw_hdmi a little more:

drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()
 drivers/gpu/drm/bridge/dw_hdmi.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

drm: bridge/dw_hdmi: introduce interface to setting sample rate
 drivers/gpu/drm/bridge/dw_hdmi.c | 10 ++++++++++
 include/drm/bridge/dw_hdmi.h     |  5 +++++
 2 files changed, 15 insertions(+)

drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio
 drivers/gpu/drm/bridge/dw_hdmi.c | 34 +++++++++++++++++++++++++++++++++-
 include/drm/bridge/dw_hdmi.h     |  2 ++
 2 files changed, 35 insertions(+), 1 deletion(-)

drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()
 drivers/gpu/drm/bridge/dw_hdmi.c | 126 +++++++++++++++++++++------------------
 1 file changed, 67 insertions(+), 59 deletions(-)

drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little
 drivers/gpu/drm/bridge/dw_hdmi.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced
 drivers/gpu/drm/bridge/dw_hdmi.c | 22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

drm/edid: add function to help find SADs
 include/drm/drm_edid.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

The 3rd is part of the fix for one of the iMX6 bugs - it doesn't do
anything other than manipulate the programmed N value right now.  What
we don't know is whether Rockchip's implementation suffers from the
same problem.  I suspect it doesn't, as the problematical FIFO probably
isn't present.

It's a bit of a shame that switching to using the new
drm_hdmi_avi_infoframe_from_display_mode() helper has increased the
code size - that's mainly down to the differently formatted infoframe
data (annoyingly, the dw_hdmi's registers have the bits in different
positions to the HDMI packets.)  On the plus side, we get proper
signalling of the aspect ratio data from the DRM mode structure.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/3] Improve dw-hdmi CTS/N setting

[Andy Yan]

Hi Russell:

On 2015?03?27? 19:13, Russell King - ARM Linux wrote:
> All,
>
> This is a mini-series to try and move audio support for the Designware
> HDMI bridge along.
>
> There are two known versions of the Designware HDMI audio:
>
> - The Rockchip version, which is based upon feeding the HDMI block I2S
>    stream(s), which doesn't have any on-board DMA support.
> - The Freescale version, which only has AHB DMA support.
>
> There are two drivers around at present, one which I've had which is
> ALSA based due to its simplicity for the Freescale version of the IP,
> and one which is ASoC based from Yakir Yang for the Rockchip version.
>
> There is some commonality between the two drivers - for example, the
> setup of the CTS/N values is very similar, although not identical.
>
> I have been reviewing (when time permits) the patches from Yakir Yang,
> and making recommendations to try and extract the common parts of the
> driver.  This is the patch set I came up with (mentioned in
> 20150202130920.GC8656 at n2100.arm.linux.org.uk).
>
> Yakir merged some of my ideas into his patch set - for example, Yakir
> Yang's "drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
> hdmi_regenerate_cts()" is very close to the version which I came up
> with.
>
> Yakir Yang didn't include the mutex patch, which I've included here -
> it really is necessary because we have potentially two different
> threads which can change the CTS/N values - a change of the video mode
> vs a change in the audio driver.
>
> The last patch is adjusting the CTS/N setting order - I have only gone
> as far as what we know works for iMX6, and this is also identical to
> Yakir Yang's patch.
>
> The identical nature is hardly surprising; my patches were derived from
> a previous set of his patches (which I acknowledge in the commit messages)
> and I detailed in the above message what I wanted to see.
>
> What I would like to see is that - as we are effectively in agreement
> over two of these patches - we get these patches merged rather than
> having to repeatedly see them.  If there's any objection, please let me
> know, otherwise I'll collect acks and send them to David.
>
>   drivers/gpu/drm/bridge/dw_hdmi.c | 34 +++++++++++++++++++---------------
>   1 file changed, 19 insertions(+), 15 deletions(-)
>
   After talk with Yakir Yang, we are glad your suggestion and patch.
   Acked-by: Andy Yan <andy.yan@rock-chips.com>