From: Yakir Yang <hidden> Date: 2014-12-15 02:55:55
Required properties:
- compatible: platform specific
- cpu-of-node: the device node of cpu_dai
- codec-name: the dw-hdmi codec's device name
- codec-dai-name: the dw-hdmi codec's dai name
Signed-off-by: Yakir Yang <redacted>
---
.../bindings/sound/rockchip,rockchip-hdmi-audio.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rockchip-hdmi-audio.txt
Hi lars:
thks for your review, I will move it to hdmi audio driver, give the
codec_name & codec_dai_name an const string.
Best Regards.
? 2014?12?15? 17:02, Lars-Peter Clausen ??:
On 12/15/2014 03:55 AM, Yakir Yang wrote:
[...]
quoted
+- codec-name: the dw-hdmi codec's device name
+- codec-dai-name: the dw-hdmi codec's dai name
Please you phandles for this, the names are Linux driver and framework
specific details. That should not leak into the DT bindings.
[..]
From: Russell King - ARM Linux <hidden> Date: 2014-12-15 10:39:10
On Mon, Dec 15, 2014 at 10:11:28AM +0800, Yakir Yang wrote:
rk3288 use Designware HDMI IP, Designware HDMI supports four interfaces to
config hdmi audio(I2S, S/PDIF, Generic Parallel Audio, AHB Audio DMA), but
rk3288 only support two ways to config hdmi audio(I2S, S/PDIF), So we take
I2S as hdmi audio operation interfaces, and then treat hdmi audio as an
standard ALSA devices(only got platback function).
There is no need for dw-hdmi audio to be implemented as an ASoC
device - as I've already sent patches to Andy with my ALSA driver
which has been around for the last two years, and works well, and
doesn't require any additional DT description.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
From: Russell King - ARM Linux <hidden> Date: 2014-12-15 10:40:58
On Mon, Dec 15, 2014 at 10:55:14AM +0800, Yakir Yang wrote:
Required properties:
- compatible: platform specific
- cpu-of-node: the device node of cpu_dai
- codec-name: the dw-hdmi codec's device name
- codec-dai-name: the dw-hdmi codec's dai name
This is not actually a separate physical device from the main dw-hdmi
device. What you are doing is merely describing the Linux kernel
internals in DT, which is not what DT is supposed to be about. DT is
supposed to describe the hardware in an operating system independent
manner.
Including details like this (because ASoC needs a separate DT node) is
the wrong approach.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
From: Mark Brown <broonie@kernel.org> Date: 2014-12-15 12:03:14
On Mon, Dec 15, 2014 at 10:40:29AM +0000, Russell King - ARM Linux wrote:
Including details like this (because ASoC needs a separate DT node) is
the wrong approach.
And indeed there should be no Linux-internal reason for that - we should
be able to use whatever DT node makes sense, if there's some reason
that's not possible we should fix that (we do have several drivers doing
this sort of thing already though).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141215/c37dc47a/attachment.sig>
Hi Mark & Russell:
thanks for your replay, what your say is right, those dt is merely
describing the Linux kernel internals.
Instead of transmit cpu-of-node & codec-name & codec-dai-name through
dt, i can give those an const
name to rockchip-hdmi-audio.c .
In that way, dt will only need compatible for creating sound device. is
it ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
Best Regards.
? 2014?12?15? 20:02, Mark Brown ??:
On Mon, Dec 15, 2014 at 10:40:29AM +0000, Russell King - ARM Linux wrote:
quoted
Including details like this (because ASoC needs a separate DT node) is
the wrong approach.
And indeed there should be no Linux-internal reason for that - we should
be able to use whatever DT node makes sense, if there's some reason
that's not possible we should fix that (we do have several drivers doing
this sort of thing already though).
From: Mark Brown <broonie@kernel.org> Date: 2014-12-15 16:19:52
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
In that way, dt will only need compatible for creating sound device. is it
ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
That'd be good, though the other question is if this can be made to use
simple-card so we can avoid having a custom driver for this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141215/31851b77/attachment.sig>
Hi Mark :
Got it, it will be good to use simple-card. i will try it in next version.
Best Regards.
? 2014?12?16? 00:18, Mark Brown ??:
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
quoted
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
quoted
In that way, dt will only need compatible for creating sound device. is it
ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
That'd be good, though the other question is if this can be made to use
simple-card so we can avoid having a custom driver for this.
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
quoted
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
got it, thanks for your remind.
quoted
In that way, dt will only need compatible for creating sound device. is it
ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
That'd be good, though the other question is if this can be made to use
simple-card so we can avoid having a custom driver for this.
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
quoted
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
quoted
In that way, dt will only need compatible for creating sound device. is it
ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
That'd be good, though the other question is if this can be made to use
simple-card so we can avoid having a custom driver for this.
Hi Russell & Mark:
hdmi-audio driver share irq with dw_hdmi driver, for continuing
AHBAUDDMA or for detecting hdmi insert.
So maybe it's hard to switch to simple-card way, Russell what's your
opinion ?
Best Regards.
From: Russell King - ARM Linux <hidden> Date: 2014-12-16 09:35:29
On Tue, Dec 16, 2014 at 02:17:51PM +0800, Kuankuan.Yang wrote:
hdmi-audio driver share irq with dw_hdmi driver, for continuing AHBAUDDMA
or for detecting hdmi insert.
So maybe it's hard to switch to simple-card way, Russell what's your
opinion ?
My "opinion" is that I need to spend some time looking in depth at both
your code and my code before I can form an idea of how to proceed.
However, since I seem to be spending a lot of time chasing regressions
which have appeared in v3.18, I don't have a lot of time to look at this
right now.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tue, Dec 16, 2014 at 02:17:51PM +0800, Kuankuan.Yang wrote:
quoted
hdmi-audio driver share irq with dw_hdmi driver, for continuing AHBAUDDMA
or for detecting hdmi insert.
So maybe it's hard to switch to simple-card way, Russell what's your
opinion ?
My "opinion" is that I need to spend some time looking in depth at both
your code and my code before I can form an idea of how to proceed.
However, since I seem to be spending a lot of time chasing regressions
which have appeared in v3.18, I don't have a lot of time to look at this
right now.
okay, if u got any ideas, wish u can let me know, thks.