[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130810111231.GR6427@sirena.org.uk>
Date: Sat, 10 Aug 2013 12:12:31 +0100
From: Mark Brown <broonie@...nel.org>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Jean-Francois Moine <moinejf@...e.fr>,
Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Rob Herring <rob.herring@...xeda.com>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio
subsystem
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 is to sort out DPCM, get that working and then sort out
> the DT side of it, so that everyone gets only one transition to DT, not a
> transition to a half-baked stop-gap DT and then have to go through another
> round of DT changes. "Because we can" is not a good enough reason not to
> get this sorted properly.
Since we know what the hardware physically looks like we should be able
to write a DT binding which can be stable for both before and after the
DPCM transition. The bindings would have to be truly awful to require a
rewrite here and as with all the DMA wrapper drivers if parts of DPCM
that don't reflect actual hardware are appearing in the DT we're doing
something wrong.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists