[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91041

--- Comment #1 from robotbuilderfiletransfer at gmail.com ---
(In reply to robotbuilderfiletransfer from comment #0)
> The problem can be sloved by executing this command: "xrandr --output HDMI-0
> --auto --set audio off".
> I found a simillar, but very old (6 years old), bug here:
> https://bugs.freedesktop.org/show_bug.cgi?id=23384.

I am using the xf86-video-ati driver.  My kernel version is 4.0.5-1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/cd223050/attachment.html>

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91041

robotbuilderfiletransfer at gmail.com changed:

   What|Removed |Added

URL||Bug on arch linux bug
   ||tracker:
   ||https://bugs.archlinux.org/
   ||task/45243

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/989aff30/attachment.html>

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91041

Bug ID: 91041
   Summary: Purple line is visible on left side of screen and the
screen is blurry using HTMI output with AMD radeon
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: robotbuilderfiletransfer at gmail.com

The problem can be sloved by executing this command: "xrandr --output HDMI-0
--auto --set audio off".
I found a simillar, but very old (6 years old), bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=23384.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/2baa56ca/attachment.html>

[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91009

--- Comment #7 from Christian König  ---
(In reply to Andy Furniss from comment #6)
> Created attachment 116614 [details]
> mplayer uvd crash 270x

At least that crash shows something GFX driver related. Yuriy's dmesg looks
like a crash in the poll() system call which doesn't looks like it is related
to GFX at all.

Especially I don't have any idea where to start looking for the cause of this.

> This is going to be the last from me on R9270X issues as my card seems to
> have died :-(

Well that's sad. Did an elco plopped open or does it just don't work any more?
Maybe we could do something about it.

Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/b0908032/attachment-0001.html>

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Paul Gortmaker]

[Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver] On 
20/06/2015 (Sat 13:23) Paul Bolle wrote:

> [Added Paul Gortmaker.]
> 
> Hi Shobhit,
> 
> On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote:
> > So what is the exact big problem with this ?
> 
> The main problem I have is that it's hard to read a submitter's mind.
> And, I think, in cases like this we need to know if the submitter just
> made some silly mistake or that the mismatch (between Kconfig type and
> code) was intentional. So each time such a mismatch is spotted the
> submitter ought to be asked about it.
> 
> (I'd guess that one or two new drivers are submitted _each_ day. And
> these mismatches are quite common. I'd say I receive answers like:
> - "Oops, yes bool should have been tristate"; or
> - "Oops, forgot to clean up after noticing tristate didn't work"; or
> - "I just copy-and-pasted a similar driver, the module stuff isn't
>   actually needed"
> at least once a week. Not sure, I don't keep track of this stuff.)
> 
> Furthermore, it appears that Paul Gortmaker is on a mission to, badly
> summarized, untangle the module and init code. See for instance
> https://lkml.org/lkml/2015/5/28/809 and
> https://lkml.org/lkml/2015/5/31/205 .
> 
> Now, I don't know whether (other) Paul is bothered by these MODULE_*
> macros. But Paul did submit a series that adds

Yes, I agree that it would be nice to not see these mismatches,
regardless of whether we can get away with it or not.

> builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 .
> That new macro ensures built-in only code doesn't have to use
> module_platform_driver(), which your patch also uses. So perhaps Paul
> can explain some of the non-obvious issues caused by built-in only code
> using module specific constructs.

In  https://lkml.org/lkml/2015/5/10/125 I'd written:

  There are several downsides to this:
  1) The code can appear modular to a reader of the code, and they
 won't know if the code really is modular without checking the
 Makefile and Kconfig to see if compilation is governed by a
 bool or tristate.
  2) Coders of drivers may be tempted to code up an __exit function
 that is never used, just in order to satisfy the required three
 args of the modular registration function.
  3) Non-modular code ends up including the  which increases
 CPP overhead that they don't need.
  4) It hinders us from performing better separation of the module
 init code and the generic init code.

The nature of linux means that thousands of developers are reading the
code every day -- so I think that there is a genuine value in having the
code convey a clear message on how it was designed to be used.  Only
using module related headers/macros for genuinely modular code helps us
(albeit in a small way) towards achieving that.

Looking at this thread, I see that one of the reasons given for this
code's ambiguous module vs. built-in identity was the observation of a
similar identity crisis of the related INTEL_SOC_PMIC code. Does that
not back up the point above about the value in having the code speak for
itself?  So IMHO we probably should clarify the PMIC code vs. adding
another example that looks just like it.

Paul.
--

> 
> > I can anyway shove out these macros to end the discussion.
> 
> I'd rather convince you than annoy you into doing as I suggested.
> 
> > BTW whether you  buy the argument or not, please do treat yourself
> > with ice cream for being able to make such a comment.
> 
> Will do.
> 
> Thanks,
> 
> 
> Paul Bolle
> 

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Paul Bolle]

[Added Paul Gortmaker.]

Hi Shobhit,

On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote:
> So what is the exact big problem with this ?

The main problem I have is that it's hard to read a submitter's mind.
And, I think, in cases like this we need to know if the submitter just
made some silly mistake or that the mismatch (between Kconfig type and
code) was intentional. So each time such a mismatch is spotted the
submitter ought to be asked about it.

(I'd guess that one or two new drivers are submitted _each_ day. And
these mismatches are quite common. I'd say I receive answers like:
- "Oops, yes bool should have been tristate"; or
- "Oops, forgot to clean up after noticing tristate didn't work"; or
- "I just copy-and-pasted a similar driver, the module stuff isn't
  actually needed"
at least once a week. Not sure, I don't keep track of this stuff.)

Furthermore, it appears that Paul Gortmaker is on a mission to, badly
summarized, untangle the module and init code. See for instance
https://lkml.org/lkml/2015/5/28/809 and
https://lkml.org/lkml/2015/5/31/205 .

Now, I don't know whether (other) Paul is bothered by these MODULE_*
macros. But Paul did submit a series that adds
builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 .
That new macro ensures built-in only code doesn't have to use
module_platform_driver(), which your patch also uses. So perhaps Paul
can explain some of the non-obvious issues caused by built-in only code
using module specific constructs.

> I can anyway shove out these macros to end the discussion.

I'd rather convince you than annoy you into doing as I suggested.

> BTW whether you  buy the argument or not, please do treat yourself
> with ice cream for being able to make such a comment.

Will do.

Thanks,


Paul Bolle

[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91009

--- Comment #6 from Andy Furniss  ---
Created attachment 116614
  --> https://bugs.freedesktop.org/attachment.cgi?id=116614=edit
mplayer uvd crash 270x

This is going to be the last from me on R9270X issues as my card seems to have
died :-(

Shan't be buying HIS again - it was only 15 months old.

But anyway I retested my mplayer start uvd script when I saw this and it did go
quicker than usual (12 starts), so I don't know if something new has developed.

My Oops does mention GPU stuff - historically I have managed to get Oopses/OOMs
that don't with the same test.

Maybe Yuriy could try with mesa commit 

6327b584155d040ae089e65fd6747186bdd9666b

reverted to see if it is something different from my old bug

https://bugs.freedesktop.org/show_bug.cgi?id=83998

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/fe6b18e1/attachment.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

smattering of fixes,

mgag200:
don't accept modes that aren't aligned properly as hw can't do it

i915: 
two regression fixes

radeon:
one query to allow userspace fixes
one oops fixer for older hw with new options enabled

Dave.

The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27:

  Linux 4.1-rc8 (2015-06-14 15:51:10 -1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to fcee3c73a2c51982057b93fe599b7c68e16d0636:

  Merge tag 'drm-intel-fixes-2015-06-18' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-06-19 11:58:39 
+1000)



Adam Jackson (1):
  drm/mgag200: Reject non-character-cell-aligned mode widths

Chris Wilson (1):
  drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

Dave Airlie (3):
  drm/radeon: don't probe MST on hw we don't support it on
  Merge branch 'drm-fixes-4.1' of 
git://people.freedesktop.org/~deathsimple/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2015-06-18' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Jani Nikula (1):
  Revert "drm/i915: Don't skip request retirement if the active list is 
empty"

Michel Dänzer (1):
  drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query

 drivers/gpu/drm/i915/i915_gem.c| 5 -
 drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 +
 drivers/gpu/drm/radeon/radeon_kms.c| 3 +++
 include/uapi/drm/radeon_drm.h  | 1 +
 5 files changed, 18 insertions(+), 1 deletion(-)

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91014

--- Comment #1 from Mark Janes  ---
I built and tested mesa=c2a0600 on g33.  The test provided the
following output, running against the latest drm with gbm back end:




  /tmp/build_root/m64/lib/piglit/bin/texture-packed-formats
-auto

  i915: unsupported texture swizzle for format 6
i915: unsupported texture swizzle for format 6
i915: unsupported texture swizzle for format 5
i915: unsupported texture swizzle for format 5
i915: unsupported texture swizzle for format 131
i915: unsupported texture swizzle for format 131
i915: unsupported texture swizzle for format 6
i915: unsupported texture swizzle for format 6
i915: unsupported texture swizzle for format 5
i915: unsupported texture swizzle for format 5
i915: unsupported texture swizzle for format 131
i915: unsupported texture swizzle for format 131




status="pass" differs from what was reported in the bug.

I can't bisect further if I can't repro.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150620/ca0393cd/attachment.html>

[PATCH v5 6/6] dt-bindings: Add documentation for rockchip-hdmi-audio driver

[Yakir Yang]

Required properties:
- compatible: platform specific
- i2s-controller: the i2s controller device node

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- modify cpu-of-node to i2s-controller

Changes in v2:
- remove codec-name and codec-dai-name
- rename rockchip,rockchip-hdmi-audio.txt to rockchip,rockchip-dw-hdmi-audio.txt

 .../bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt   | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
new file mode 100644
index 000..f0d23c5
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
@@ -0,0 +1,12 @@
+Rockchip hdmi audio bindings
+
+Required properties:
+- compatible: platform specific
+- i2s-controller: the i2s controller device node
+
+Example:
+
+sound {
+   compatible = "rockchip,rk3288-hdmi-audio";
+   i2s-controller = <>;
+};
-- 
2.1.2

[PATCH v5 5/6] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

[Yakir Yang]

Add a sound driver that combines rockchip-i2s cpu_dai and dw-hdmi-codec
as codec_dai to provide hdmi audio output on rk3288 platforms.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Take Mark Brown suggest that remove the no useful code in probe func,
  and remove the snd_soc_dai_set_fmt() snd_soc_unregister_card(), remove
  those noisy dev_info()
- Rename codec_dai_name to "dw-hdmi-i2s-hifi"

Changes in v4:
- Add ".pm = _soc_pm_ops,"

Changes in v3:
- Delete the operation of jack in rockchip-hdmi-audio driver,
  get ready to switch to simple-audio-card driver.

Changes in v2:
- give "codec-name" & "codec-dai-name" an const name

 sound/soc/rockchip/Kconfig   |   9 ++
 sound/soc/rockchip/Makefile  |   2 +
 sound/soc/rockchip/rockchip_hdmi_audio.c | 138 +++
 3 files changed, 149 insertions(+)
 create mode 100644 sound/soc/rockchip/rockchip_hdmi_audio.c

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index e181826..ed2b7f0 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -14,3 +14,12 @@ config SND_SOC_ROCKCHIP_I2S
  Say Y or M if you want to add support for I2S driver for
  Rockchip I2S device. The device supports upto maximum of
  8 channels each for play and record.
+
+config SND_SOC_ROCKCHIP_HDMI_AUDIO
+   tristate "ASoC support for Rockchip HDMI audio"
+   depends on SND_SOC_ROCKCHIP
+   select SND_SOC_ROCKCHIP_I2S
+   select SND_SOC_DW_HDMI_AUDIO
+   help
+ Say Y or M here if you want to add support for SoC audio on Rockchip
+ HDMI, such as rk3288 hdmi.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index b921909..b9185b3 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -1,4 +1,6 @@
 # ROCKCHIP Platform Support
 snd-soc-i2s-objs := rockchip_i2s.o
+snd-soc-rockchip-hdmi-audio-objs := rockchip_hdmi_audio.o

 obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
+obj-$(CONFIG_SND_SOC_ROCKCHIP_HDMI_AUDIO) += snd-soc-rockchip-hdmi-audio.o
diff --git a/sound/soc/rockchip/rockchip_hdmi_audio.c 
b/sound/soc/rockchip/rockchip_hdmi_audio.c
new file mode 100644
index 000..53ecd60
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_hdmi_audio.c
@@ -0,0 +1,138 @@
+/*
+ * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors.
+ * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
+ * Authors: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .*
+ *
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_i2s.h"
+
+#define DRV_NAME "rockchip-hdmi-audio"
+
+static int rockchip_hdmi_audio_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   unsigned int dai_fmt = rtd->dai_link->dai_fmt;
+   int mclk, ret;
+
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk, SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(cpu_dai->dev, "failed to set cpu_dai sysclk.\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops hdmi_audio_dai_ops = {
+   .hw_params = rockchip_hdmi_audio_hw_params,
+};
+
+static struct snd_soc_dai_link hdmi_audio_dai = {
+   .name = "RockchipHDMI",
+   .stream_name = "RockchipHDMI",
+   .codec_name = "dw-hdmi-i2s-audio",
+   .codec_dai_name = "dw-hdmi-i2s-hifi",
+   .ops = _audio_dai_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+  SND_SOC_DAIFMT_CBS_CFS,
+};
+
+static struct snd_soc_card rockchip_hdmi_audio_card = {
+   .name = "RockchipHDMI",
+   .owner = THIS_MODULE,
+   .dai_link = _audio_dai,
+   .num_links = 1,
+};
+
+static int rockchip_hdmi_audio_probe(struct platform_device *pdev)
+{
+   struct snd_soc_card 

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

[Yakir Yang]

Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card
driver could connect to this codec through the codec dai name
"dw-hdmi-i2s-audio".

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Take Mark Brown suggest that remove jack_status recorded, report
  jack status directly when hdmi plug happend, and remove devm_kfree
  and devm_free_irq.
- Correct the MODULE_LICENSE to "GPL v2"
- Move source from sound/soc/codecs to drivers/gpu/drm/bridge/
- Rename dai driver name to "dw-hdmi-i2s-hifi"

Changes in v4:
- Replace delaywork with irq thread, and add suspend/resume interfaces,
  replace "dw-hdmi-audio" with consecutive strings.

Changes in v3:
- Keep audio format config function in dw-hdmi-audio driver
  and remove audio_config & get_connect_status functions,
  move jack control to dw-hdmi-audio completely.

Changes in v2:
- Update dw_hdmi audio control interfaces, and adjust jack report process

 drivers/gpu/drm/bridge/Kconfig |   9 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c | 398 +
 drivers/gpu/drm/bridge/dw_hdmi.c   |  24 +-
 drivers/gpu/drm/bridge/dw_hdmi.h   |   3 +
 5 files changed, 426 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 204861b..59e3f24 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -14,6 +14,15 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsis Designware I2S Audio interface"
+   depends on DRM_DW_HDMI && SND
+   select SND_PCM
+   help
+ Support the I2S Audio interface which is part of the Synopsis
+ Designware HDMI block.  This is used in conjunction with the
+ RK3288 HDMI driver.
+
 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index eb80dbb..65a1239 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_PS8622) += ps8622.o
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw_hdmi-i2s-audio.o
diff --git a/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
new file mode 100644
index 000..341ab97
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
@@ -0,0 +1,398 @@
+/*
+ * DesignWare HDMI audio driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Written and tested against the Designware HDMI Tx found in RK3288.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_hdmi-audio.h"
+
+#define DRIVER_NAME "dw-hdmi-i2s-audio"
+
+enum {
+   AUDIO_CONF1_DATWIDTH_MSK = 0x1F,
+   AUDIO_CONF1_DATAMODE_MSK = 0xE0,
+   AUDIO_DAIFMT_IIS = 0x0,
+   AUDIO_DAIFMT_RIGHT_J = 0x20,
+   AUDIO_DAIFMT_LEFT_J = 0x40,
+   AUDIO_DAIFMT_BURST_1 = 0x60,
+   AUDIO_DAIFMT_BURST_2 = 0x80,
+   AUDIO_CONF0_INTERFACE_MSK = BIT(5),
+   AUDIO_INPUTTYPE_IIS = 0x20,
+   AUDIO_INPUTTYPE_SPDIF = 0x00,
+   AUDIO_CONF0_I2SINEN_MSK = 0x0F,
+   AUDIO_CHANNELNUM_2 = 0x01,
+   AUDIO_CHANNELNUM_4 = 0x03,
+   AUDIO_CHANNELNUM_6 = 0x07,
+   AUDIO_CHANNELNUM_8 = 0x0F,
+   HDMI_PHY_HPD = BIT(1),
+   HDMI_PHY_STAT0 = 0x3004,
+   HDMI_AUD_CONF0 = 0x3100,
+   HDMI_AUD_CONF1 = 0x3101,
+   HDMI_AUD_INPUTCLKFS = 0x3206,
+};
+
+struct dw_audio_fmt {
+   int input_type;
+   int chan_num;
+   int sample_rate;
+   int word_length;
+   int dai_fmt;
+};
+
+struct snd_dw_hdmi {
+   struct device *dev;
+   struct dw_hdmi_audio_data data;
+
+   bool is_jack_ready;
+   struct snd_soc_jack jack;
+
+   bool is_playback_status;
+   struct dw_audio_fmt fmt;
+};
+
+static void hdmi_writel(struct snd_dw_hdmi *dw, u8 val, int offset)
+{
+   writel(val, dw->data.base + (offset << 2));
+}
+
+static u8 hdmi_readl(struct snd_dw_hdmi *dw, int offset)
+{
+   return readl(dw->data.base + (offset << 2));
+}
+
+static void hdmi_modl(struct snd_dw_hdmi *dw, u8 data,
+ u8 mask, unsigned reg)
+{
+   u8 val = hdmi_readl(dw, reg) & ~mask;
+
+   val |= data & mask;
+   hdmi_writel(dw, val, reg);
+}
+
+int snd_dw_hdmi_jack_detect(struct snd_dw_hdmi *dw)
+{
+   u8 jack_status;
+
+   if (!dw->is_jack_ready)
+   return -EINVAL;
+

[PATCH v5 3/6] drm: bridge/dw_hdmi: rename dw_hdmi-ahb-audio.h to dw_hdmi-audio.h

[Yakir Yang]

First step to make ahb audio driver and i2s audio driver code exist,
share the audio data struct in dw_hdmi-audio.h

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c  | 2 +-
 drivers/gpu/drm/bridge/{dw_hdmi-ahb-audio.h => dw_hdmi-audio.h} | 0
 drivers/gpu/drm/bridge/dw_hdmi.c| 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename drivers/gpu/drm/bridge/{dw_hdmi-ahb-audio.h => dw_hdmi-audio.h} (100%)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
index 2bb68bd..0a270ea 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
@@ -21,7 +21,7 @@
 #include 
 #include 

-#include "dw_hdmi-ahb-audio.h"
+#include "dw_hdmi-audio.h"

 #define DRIVER_NAME "dw-hdmi-ahb-audio"

diff --git a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h 
b/drivers/gpu/drm/bridge/dw_hdmi-audio.h
similarity index 100%
rename from drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h
rename to drivers/gpu/drm/bridge/dw_hdmi-audio.h
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 417cc82..cbb55ae 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -28,7 +28,7 @@
 #include 

 #include "dw_hdmi.h"
-#include "dw_hdmi-ahb-audio.h"
+#include "dw_hdmi-audio.h"

 #define HDMI_EDID_LEN  512

-- 
2.1.2

[PATCH v5 2/6] drm: bridge/dw_hdmi: enable audio when sink device is HDMI and has audio

[Yakir Yang]

The original code only provide audio func when video code is a CEA mode,
but I found that No-CEA mode could also play sound when sink is HDMI mode
and has audio. So I think if sink device has the ability to play audio,
then source should enable audio support that set fc_invidconf to HDMI mode
and config n/cts rightly.

And actually we could know those information through parsing sink edid.
drm_detect_hdmi_monitor() could report whether sink is a HDMI monitor,
drm_detect_monitor_audio() could return whether sink has audio.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Take Russell suggest that create "sink_has_audio" and "sink_is_hdmi" in
  struct hdmi, and keep vmode's mdvi changeless.
- Config fc_invidconf to HDMI mode when sink device is HDMI monitor.

Changes in v4:
- Take Dainel suggest that introduce drm_detect_monitor_audio() to judge
  whether source should config audio.

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index f717a2a..417cc82 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -119,6 +119,8 @@ struct dw_hdmi {

u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
+   bool sink_is_hdmi;
+   bool sink_has_audio;

bool phy_enabled;
struct drm_display_mode previous_mode;
@@ -1152,7 +1154,11 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
HDMI_FC_INVIDCONF_IN_I_P_INTERLACED :
HDMI_FC_INVIDCONF_IN_I_P_PROGRESSIVE;

-   inv_val |= (vmode->mdvi ?
+   /*
+* when sink device is hdmi monitor, then we can config
+* this to hdmi_mode even if the video mode is No-CEA mode.
+*/
+   inv_val |= (hdmi->sink_is_hdmi ?
HDMI_FC_INVIDCONF_DVI_MODEZ_DVI_MODE :
HDMI_FC_INVIDCONF_DVI_MODEZ_HDMI_MODE);

@@ -1330,11 +1336,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
/* HDMI Initialization Step B.3 */
dw_hdmi_enable_video_path(hdmi);

-   /* not for DVI mode */
-   if (hdmi->hdmi_data.video_mode.mdvi) {
-   dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
+   if (!hdmi->sink_has_audio) {
+   dev_info(hdmi->dev, "sink device does not support audio\n");
} else {
-   dev_dbg(hdmi->dev, "%s CEA mode\n", __func__);
+   dev_dbg(hdmi->dev, "sink device support audio\n");

/* HDMI Initialization Step E - Configure audio */
hdmi_clk_regenerator_update_pixel_clock(hdmi);
@@ -1500,6 +1505,9 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);

+   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
+   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
+
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
-- 
2.1.2

[PATCH v5 1/6] drm: bridge/dw_hdmi: add audio support for more display resolutions

[Yakir Yang]

Just like HDMISpecification 1.4 document descripted, the soure shall
determine the fractional relationship between the TMDS clock an an
audio reference clock, the sink may then recreate the audio clock from
the TMDS clock by using an clock divider. So if we can make sink generate
the correct samplerate, then we can say those display resolutions with
this pixelclock could support audio play.

The exact relationship between the two clocks will be:
128 * SampleRate = TmdsClock * N / CTS.
So this patch would generate the correct N/CTS values, add audio support
for the below  tmds clocks:
25.175MHz, 40MHz, 54MHz, 65MHz, 74.25MHz, 83.5MHz, 106.5MHz, 108Mhz

Signed-off-by: Yakir Yang 
---
Changes in v5:
- make more words in commit message.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index dc0aed1..f717a2a 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -222,8 +222,24 @@ static unsigned int hdmi_compute_n(unsigned int freq, 
unsigned long pixel_clk,
case 44100:
if (pixel_clk == 2517)
n = 7007;
+   else if (pixel_clk == 25175000)
+   n = 28224;
+   else if (pixel_clk == 4000)
+   n = 7056;
+   else if (pixel_clk == 5400)
+   n = 6272;
+   else if (pixel_clk == 6500)
+   n = 7056;
else if (pixel_clk == 7417)
n = 17836;
+   else if (pixel_clk == 7425)
+   n = 6272;
+   else if (pixel_clk == 8350)
+   n = 7056;
+   else if (pixel_clk == 10650)
+   n = 4074;
+   else if (pixel_clk == 10800)
+   n = 4018;
else if (pixel_clk == 14835)
n = (ratio == 150) ? 17836 : 8918;
else
@@ -233,10 +249,26 @@ static unsigned int hdmi_compute_n(unsigned int freq, 
unsigned long pixel_clk,
case 48000:
if (pixel_clk == 2517)
n = (ratio == 150) ? 9152 : 6864;
+   else if (pixel_clk == 25175000)
+   n = 6144;
else if (pixel_clk == 2702)
n = (ratio == 150) ? 8192 : 6144;
+   else if (pixel_clk == 4000)
+   n = 6144;
+   else if (pixel_clk == 5400)
+   n = 6144;
+   else if (pixel_clk == 6500)
+   n = 6144;
else if (pixel_clk == 7417)
n = 11648;
+   else if (pixel_clk == 7425)
+   n = 6144;
+   else if (pixel_clk == 8350)
+   n = 6144;
+   else if (pixel_clk == 10650)
+   n = 6144;
+   else if (pixel_clk == 10800)
+   n = 6144;
else if (pixel_clk == 14835)
n = (ratio == 150) ? 11648 : 5824;
else
@@ -284,10 +316,16 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
case 96000:
case 192000:
switch (pixel_clk) {
+   case 25175000:
case 2520:
case 2700:
+   case 4000:
case 5400:
+   case 6500:
case 7425:
+   case 8350:
+   case 10650:
+   case 10800:
case 14850:
cts = pixel_clk / 1000;
break;
@@ -308,18 +346,36 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
case 88200:
case 176400:
switch (pixel_clk) {
+   case 25175000:
+   cts = 125875;
+   break;
case 2520:
cts = 28000;
break;
case 2700:
cts = 3;
break;
+   case 4000:
+   cts = 5;
+   break;
case 5400:
cts = 6;
break;
+   case 6500:
+   cts = 81250;
+   break;
case 7425:
cts = 82500;
break;
+   case 8350:
+   cts = 104375;
+   break;
+   case 10650:

[PATCH v5 0/6] Add dw_hdmi i2s audio support

[Yakir Yang]

As Russell have send an series patches for dw_hdmi audio, and most important
it works well on rockchip platform. Cause some patches have been achieve in
Russell's series, so I abondon some patches in this verison.

Here are the abondon patches that already be achieved:
* drm: bridge/dw_hdmi: adjust n/cts setting order
* drm: bridge/dw_hdmi: set ncts_atomic_write & cts_manual
* drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and 
hdmi_regenerate_cts()
* drm: bridge/dw_hdmi: add enable/disable to dw_hdmi_audio callbacks

And I also abondon some interrupt patches that is not a common bug in dw_hdmi
driver, but is a rockchip platform bug which HDMI registers would reset by CRU
module after system suspend/resume (in this case HPD interrupt mask would reset,
then driver can't respond hot plug event after system resume).

Here are the abondon patches that used to "fix" dw_hdmi interrupt bug:
* drm: bridge/dw_hdmi: add irq control to suspend/resume
* drm: bridge/dw_hdmi: wrap irq control in fucntions
* drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

Here are the leave list that I have make in my series:
- add n/cts combinations for more display modes
- enable audio support when sink device is HDMI monitor and has audio
- rename dw_hdmi-ahb-audio.h to dw_hdmi-audio.h
- add dw_hdmi i2s audio driver
- add rockchip_hdmi_audio sound card driver
- add dt-bindings for documentation for rockchip_hdmi_audio driver


Changes in v5:
- make more words in commit message.
- Take Russell suggest that create "sink_has_audio" and "sink_is_hdmi" in
  struct hdmi, and keep vmode's mdvi changeless.
- Config fc_invidconf to HDMI mode when sink device is HDMI monitor.
- Take Mark Brown suggest that remove jack_status recorded, report
  jack status directly when hdmi plug happend, and remove devm_kfree
  and devm_free_irq.
- Correct the MODULE_LICENSE to "GPL v2"
- Move source from sound/soc/codecs to drivers/gpu/drm/bridge/
- Rename dai driver name to "dw-hdmi-i2s-hifi"
- Take Mark Brown suggest that remove the no useful code in probe func,
  and remove the snd_soc_dai_set_fmt() snd_soc_unregister_card(), remove
  those noisy dev_info()
- Rename codec_dai_name to "dw-hdmi-i2s-hifi"

Changes in v4:
- Take Dainel suggest that introduce drm_detect_monitor_audio() to judge
  whether source should config audio.
- Replace delaywork with irq thread, and add suspend/resume interfaces,
  replace "dw-hdmi-audio" with consecutive strings.
- Add ".pm = _soc_pm_ops,"

Changes in v3:
- Keep audio format config function in dw-hdmi-audio driver
  and remove audio_config & get_connect_status functions,
  move jack control to dw-hdmi-audio completely.
- Delete the operation of jack in rockchip-hdmi-audio driver,
  get ready to switch to simple-audio-card driver.
- modify cpu-of-node to i2s-controller

Changes in v2:
- Update dw_hdmi audio control interfaces, and adjust jack report process
- give "codec-name" & "codec-dai-name" an const name
- remove codec-name and codec-dai-name
- rename rockchip,rockchip-hdmi-audio.txt to rockchip,rockchip-dw-hdmi-audio.txt

Yakir Yang (6):
  drm: bridge/dw_hdmi: add audio support for more display resolutions
  drm: bridge/dw_hdmi: enable audio when sink device is HDMI and has audio
  drm: bridge/dw_hdmi: rename dw_hdmi-ahb-audio.h to dw_hdmi-audio.h
  drm: bridge/dw_hdmi-i2s-audio: add audio driver
  ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio
  dt-bindings: Add documentation for rockchip_hdmi_audio driver

 .../sound/rockchip,rockchip-dw-hdmi-audio.txt  |  12 +
 drivers/gpu/drm/bridge/Kconfig |   9 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c |   2 +-
 .../{dw_hdmi-ahb-audio.h => dw_hdmi-audio.h}   |   0
 drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c | 398 +
 drivers/gpu/drm/bridge/dw_hdmi.c   | 100 +-
 drivers/gpu/drm/bridge/dw_hdmi.h   |   3 +
 sound/soc/rockchip/Kconfig |   9 +
 sound/soc/rockchip/Makefile|   2 +
 sound/soc/rockchip/rockchip_hdmi_audio.c   | 138 +++
 11 files changed, 658 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
 rename drivers/gpu/drm/bridge/{dw_hdmi-ahb-audio.h => dw_hdmi-audio.h} (100%)
 create mode 100644 drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
 create mode 100644 sound/soc/rockchip/rockchip_hdmi_audio.c

-- 
2.1.2