On Sat, Aug 10, 2013 at 10:31:37AM +0100, Russell King - ARM Linux wrote:
> Right, so what you're proposing is to come up with a DT description for
> the existing stuff, and then have to change (or at the very least augment)
> that description later when the DPCM stuff goes in.
> What should be
On Sat, Aug 10, 2013 at 12:42:09AM +0100, Mark Brown wrote:
> On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
>
> > > If someone wants to it should also be possible to convert the existing
> > > platforms
Dear Jean-Francois Moine,
On Fri, 9 Aug 2013 11:06:23 +0200, Jean-Francois Moine wrote:
> > we need at least two more compatibles for the audio controller found on
> > Dove and Kirkwood respectively. This is how we are going to distinguish
> > those two, e.g. Kirkwood has SPDIF in which Dove
Dear Jean-Francois Moine,
On Fri, 9 Aug 2013 11:06:23 +0200, Jean-Francois Moine wrote:
we need at least two more compatibles for the audio controller found on
Dove and Kirkwood respectively. This is how we are going to distinguish
those two, e.g. Kirkwood has SPDIF in which Dove hasn't.
On Sat, Aug 10, 2013 at 12:42:09AM +0100, Mark Brown wrote:
On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
If someone wants to it should also be possible to convert the existing
platforms without
On Sat, Aug 10, 2013 at 10:31:37AM +0100, Russell King - ARM Linux wrote:
Right, so what you're proposing is to come up with a DT description for
the existing stuff, and then have to change (or at the very least augment)
that description later when the DPCM stuff goes in.
What should be done
On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
> > If someone wants to it should also be possible to convert the existing
> > platforms without S/PDIF support over to DT, providing you don't mind
> > changing
On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
> If someone wants to it should also be possible to convert the existing
> platforms without S/PDIF support over to DT, providing you don't mind
> changing the code once the DPCM and S/PDIF support is added and a bit of
> thought is put
On Fri, Aug 09, 2013 at 07:25:16PM +0100, Russell King - ARM Linux wrote:
> Sigh, you completely miss the point.
> What all three of us are ultimately after is a DT description for the
> kirkwood stuff which covers all its use cases. The use case which all
> three of us have in common is the
On Fri, Aug 09, 2013 at 07:00:58PM +0100, Mark Brown wrote:
> On Fri, Aug 09, 2013 at 02:09:32PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
>
> > > So extend Morimoto-san's work on the simple card for this - that's what
> > > it's there
On Fri, Aug 09, 2013 at 02:09:32PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
> > So extend Morimoto-san's work on the simple card for this - that's what
> > it's there for, it's doing exactly this job for non-DT systems but it
> > just
On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
> So extend Morimoto-san's work on the simple card for this - that's what
> it's there for, it's doing exactly this job for non-DT systems but it
> just didn't get DT support added yet. All the trivial cards should end
> up using this.
On Fri, Aug 09, 2013 at 01:01:24PM +0200, Sebastian Hesselbarth wrote:
> And that is *the only thing* that keeps bugging me in Mark's replies -
> he *insists* on having that virtual audio nodes. I have nothing against
> it, except it should be *required* for every DT we have. DRM doesn't
> _need_
On 08/09/13 11:43, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
I do understand there may be SoCs requiring sophisticated extra audio
nodes, but Marvell SoCs don't. I prefer having a single node for the
i2s controller *and* exploit the
On Fri, 9 Aug 2013 10:43:40 +0100
Russell King - ARM Linux wrote:
> Note that we do have another case not yet in tree, which is DRM, but
> this case is different from that, because ASoC can cope with components
> with independent initialisation.
No sure!
Sometimes, with the tda998x in HDMI
On Fri, Aug 09, 2013 at 12:05:58PM +0200, Lars-Peter Clausen wrote:
> On 08/09/2013 11:34 AM, Sebastian Hesselbarth wrote:
> > I do understand there may be SoCs requiring sophisticated extra audio
> > nodes, but Marvell SoCs don't. I prefer having a single node for the
> > i2s controller *and*
On 08/09/2013 11:34 AM, Sebastian Hesselbarth wrote:
> On 08/09/13 11:19, Mark Brown wrote:
>> On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
>>> On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
>>
+i2s1: audio-controller@b4000 {
+compatible =
On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
> Mark,
>
> I do understand there may be SoCs requiring sophisticated extra audio
> nodes, but Marvell SoCs don't. I prefer having a single node for the
> i2s controller *and* exploit the audio subsystem properties from that.
>
On 08/09/13 11:19, Mark Brown wrote:
On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
+i2s1: audio-controller@b4000 {
+ compatible = "mrvl,mvebu-audio";
+ reg = <0xb4000 0x2210>;
+ interrupts = <21>,
On Fri, Aug 09, 2013 at 11:06:23AM +0200, Jean-Francois Moine wrote:
> On Fri, 09 Aug 2013 10:23:50 +0200
> Sebastian Hesselbarth wrote:
> > we need at least two more compatibles for the audio controller found on
> > Dove and Kirkwood respectively. This is how we are going to distinguish
> >
On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
> On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
> >+i2s1: audio-controller@b4000 {
> >+compatible = "mrvl,mvebu-audio";
> >+reg = <0xb4000 0x2210>;
> >+interrupts = <21>, <22>;
> >+clocks = <_clk 13>;
> >+
On Fri, 09 Aug 2013 10:23:50 +0200
Sebastian Hesselbarth wrote:
> On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
> > This patch adds DT support to the audio subsystem of the mvebu family
> > (Kirkwood, Dove, Armada 370).
> >
> > Signed-off-by: Jean-Francois Moine
> > ---
> >
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
This patch adds DT support to the audio subsystem of the mvebu family
(Kirkwood, Dove, Armada 370).
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/sound/mvebu-audio.txt | 29 ++
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
This patch adds DT support to the audio subsystem of the mvebu family
(Kirkwood, Dove, Armada 370).
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
.../devicetree/bindings/sound/mvebu-audio.txt | 29 ++
On Fri, 09 Aug 2013 10:23:50 +0200
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
This patch adds DT support to the audio subsystem of the mvebu family
(Kirkwood, Dove, Armada 370).
Signed-off-by: Jean-Francois Moine
On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
+i2s1: audio-controller@b4000 {
+compatible = mrvl,mvebu-audio;
+reg = 0xb4000 0x2210;
+interrupts = 21, 22;
+clocks = gate_clk 13;
+clock-names =
On Fri, Aug 09, 2013 at 11:06:23AM +0200, Jean-Francois Moine wrote:
On Fri, 09 Aug 2013 10:23:50 +0200
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
we need at least two more compatibles for the audio controller found on
Dove and Kirkwood respectively. This is how we are
On 08/09/13 11:19, Mark Brown wrote:
On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
+i2s1: audio-controller@b4000 {
+ compatible = mrvl,mvebu-audio;
+ reg = 0xb4000 0x2210;
+ interrupts = 21, 22;
+
On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
Mark,
I do understand there may be SoCs requiring sophisticated extra audio
nodes, but Marvell SoCs don't. I prefer having a single node for the
i2s controller *and* exploit the audio subsystem properties from that.
For
On 08/09/2013 11:34 AM, Sebastian Hesselbarth wrote:
On 08/09/13 11:19, Mark Brown wrote:
On Fri, Aug 09, 2013 at 10:23:50AM +0200, Sebastian Hesselbarth wrote:
On 08/08/2013 01:22 PM, Jean-Francois Moine wrote:
+i2s1: audio-controller@b4000 {
+compatible = mrvl,mvebu-audio;
+reg =
On Fri, Aug 09, 2013 at 12:05:58PM +0200, Lars-Peter Clausen wrote:
On 08/09/2013 11:34 AM, Sebastian Hesselbarth wrote:
I do understand there may be SoCs requiring sophisticated extra audio
nodes, but Marvell SoCs don't. I prefer having a single node for the
i2s controller *and* exploit
On Fri, 9 Aug 2013 10:43:40 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
Note that we do have another case not yet in tree, which is DRM, but
this case is different from that, because ASoC can cope with components
with independent initialisation.
No sure!
Sometimes, with the
On 08/09/13 11:43, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
I do understand there may be SoCs requiring sophisticated extra audio
nodes, but Marvell SoCs don't. I prefer having a single node for the
i2s controller *and* exploit the
On Fri, Aug 09, 2013 at 01:01:24PM +0200, Sebastian Hesselbarth wrote:
And that is *the only thing* that keeps bugging me in Mark's replies -
he *insists* on having that virtual audio nodes. I have nothing against
it, except it should be *required* for every DT we have. DRM doesn't
_need_ it,
On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
So extend Morimoto-san's work on the simple card for this - that's what
it's there for, it's doing exactly this job for non-DT systems but it
just didn't get DT support added yet. All the trivial cards should end
up using this.
It's
On Fri, Aug 09, 2013 at 02:09:32PM +0100, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
So extend Morimoto-san's work on the simple card for this - that's what
it's there for, it's doing exactly this job for non-DT systems but it
just didn't
On Fri, Aug 09, 2013 at 07:00:58PM +0100, Mark Brown wrote:
On Fri, Aug 09, 2013 at 02:09:32PM +0100, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
So extend Morimoto-san's work on the simple card for this - that's what
it's there for, it's
On Fri, Aug 09, 2013 at 07:25:16PM +0100, Russell King - ARM Linux wrote:
Sigh, you completely miss the point.
What all three of us are ultimately after is a DT description for the
kirkwood stuff which covers all its use cases. The use case which all
three of us have in common is the Cubox,
On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
If someone wants to it should also be possible to convert the existing
platforms without S/PDIF support over to DT, providing you don't mind
changing the code once the DPCM and S/PDIF support is added and a bit of
thought is put into
On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
If someone wants to it should also be possible to convert the existing
platforms without S/PDIF support over to DT, providing you don't mind
changing the
This patch adds DT support to the audio subsystem of the mvebu family
(Kirkwood, Dove, Armada 370).
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/sound/mvebu-audio.txt | 29 ++
sound/soc/kirkwood/kirkwood-i2s.c | 26
This patch adds DT support to the audio subsystem of the mvebu family
(Kirkwood, Dove, Armada 370).
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
.../devicetree/bindings/sound/mvebu-audio.txt | 29 ++
sound/soc/kirkwood/kirkwood-i2s.c | 26
42 matches
Mail list logo
