* [PATCH 1/3] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
2015-03-27 11:13 [PATCH 0/3] Improve dw-hdmi CTS/N setting Russell King - ARM Linux
@ 2015-03-27 11:13 ` Russell King
2015-03-27 11:13 ` [PATCH 2/3] drm: bridge/dw_hdmi: protect n/cts setting with a mutex Russell King
` (3 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: Russell King @ 2015-03-27 11:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 2/3] drm: bridge/dw_hdmi: protect n/cts setting with a mutex
2015-03-27 11:13 [PATCH 0/3] Improve dw-hdmi CTS/N setting Russell King - ARM Linux
2015-03-27 11:13 ` [PATCH 1/3] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts() Russell King
@ 2015-03-27 11:13 ` Russell King
2015-03-27 11:13 ` [PATCH 3/3] drm: bridge/dw_hdmi: adjust n/cts setting order Russell King
` (2 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: Russell King @ 2015-03-27 11:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 3/3] drm: bridge/dw_hdmi: adjust n/cts setting order
2015-03-27 11:13 [PATCH 0/3] Improve dw-hdmi CTS/N setting Russell King - ARM Linux
2015-03-27 11:13 ` [PATCH 1/3] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts() Russell King
2015-03-27 11:13 ` [PATCH 2/3] drm: bridge/dw_hdmi: protect n/cts setting with a mutex Russell King
@ 2015-03-27 11:13 ` Russell King
2015-03-30 9:43 ` [PATCH 0/3] Improve dw-hdmi CTS/N setting Philipp Zabel
2015-03-30 13:23 ` Andy Yan
4 siblings, 0 replies; 7+ messages in thread
From: Russell King @ 2015-03-27 11:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 0/3] Improve dw-hdmi CTS/N setting
2015-03-27 11:13 [PATCH 0/3] Improve dw-hdmi CTS/N setting Russell King - ARM Linux
` (2 preceding siblings ...)
2015-03-27 11:13 ` [PATCH 3/3] drm: bridge/dw_hdmi: adjust n/cts setting order Russell King
@ 2015-03-30 9:43 ` Philipp Zabel
2015-03-30 12:25 ` Russell King - ARM Linux
2015-03-30 13:23 ` Andy Yan
4 siblings, 1 reply; 7+ messages in thread
From: Philipp Zabel @ 2015-03-30 9:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH 0/3] Improve dw-hdmi CTS/N setting
2015-03-30 9:43 ` [PATCH 0/3] Improve dw-hdmi CTS/N setting Philipp Zabel
@ 2015-03-30 12:25 ` Russell King - ARM Linux
0 siblings, 0 replies; 7+ messages in thread
From: Russell King - ARM Linux @ 2015-03-30 12:25 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 0/3] Improve dw-hdmi CTS/N setting
2015-03-27 11:13 [PATCH 0/3] Improve dw-hdmi CTS/N setting Russell King - ARM Linux
` (3 preceding siblings ...)
2015-03-30 9:43 ` [PATCH 0/3] Improve dw-hdmi CTS/N setting Philipp Zabel
@ 2015-03-30 13:23 ` Andy Yan
4 siblings, 0 replies; 7+ messages in thread
From: Andy Yan @ 2015-03-30 13:23 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 7+ messages in thread