[PATCH 0/10] Kirkwood ASoC drivers fixes and improvements

[PATCH 0/10] Kirkwood ASoC drivers fixes and improvements

[Russell King - ARM Linux]

All,

I'm opening this to a wider audience in the hope of getting a solution.

There are classes of hardware out there where the DMA support is tightly
integrated along side the rest of the I2S interface.

One such example of this is the hardware found on Marvell Kirkwood
platforms and their derivatives.   Not only are the registers interleaved
between the I2S interface part and the DMA part, and the DMA can only be
used for I2S, but the current Kirkwood ASoC implementation in
sound/soc/kirkwood shares a common data structure created by the "cpu dai"
to provide register access and other data.  This data structure is
"struct kirkwood_dma_data".

This means that in software, as things stand today, kirkwood-dma.c has
intimate knowledge of kirkwood-i2s.c despite being two separate platform
drivers.  This also means that the split between kirkwood-dma.c and
kirkwood-i2s.c is entirely artificial, brought about by the insistance
of ASoC that these things shall be separate.

How does ASoC insist that these be separate?  It only provides the
necessary callbacks for DMA related stuff to what it calls the "platform"
driver.  The interface part is called a "cpu dai" and one of those must
always be provided.  Each of these must be a separate platform device,
because they're each named drivers, and the name comes from the
device/driver.

This is fine in the pre-DT world, where we have board files in arch/arm
which can create whatever platform devices are needed to bring ASoC up,
but we're moving to a DT-only solution - that means no board files.
DT is a hardware description; it does not describe whatever random ideas
some software implementation has come up with; a DT description of audio
on Kirkwood will not make any distinction between the artificial
"platform" part and the "cpu dai" part.

Instead, a DT description will just declare there to be one I2S device
with its relevant resources.

Such a description is _inherently_ incompatible with ASoC as long as
ASoC insists that there is this artificial distinction.

What Mark is telling me is that he requires yet more board files to
spring up under sound/soc/ which create these artificial platform
devices.  Not only does that go against the direction which we're heading
on ARM (at Linus' insistance) to get rid of board files, but it perpetuates
this silly idea that every audio interface should be split up whether
there's a distinction there or not.

It also makes the handling of -EPROBE_DEFER yet more complex; using this
driver on the Dove Cubox platform with built as a set of modules revealed
that where a platform device was being registered by code in
sound/soc/kirkwood, and would be immediately unregistered on -EPROBE_DEFER
never to be re-registered.

It is my belief that Mark's position is not the right solution for where
things are heading.

We need to have solutions which do not require artificial breakup of
drivers; we need solutions where hardware can be described by DT and
that DT description be used by the kernel with the minimum of code.
What we don't need are yet more board files appearing in some other
random part of the kernel tree.

Your thoughts please.

[PATCH 0/10] Kirkwood ASoC drivers fixes and improvements

[Mark Brown]

On Thu, Nov 22, 2012 at 02:06:14PM +0000, Russell King - ARM Linux wrote:

> Instead, a DT description will just declare there to be one I2S device
> with its relevant resources.

Yes, this is exactly the sort of thing all the existing platforms
using DT are doing in their ASoC drivers - there's normally some
grouping or sharing at the hardware level that doesn't map exactly onto
Linux models.  We're already at the point you're trying to get to here.

> Such a description is _inherently_ incompatible with ASoC as long as
> ASoC insists that there is this artificial distinction.

> What Mark is telling me is that he requires yet more board files to
> spring up under sound/soc/ which create these artificial platform
> devices.  Not only does that go against the direction which we're heading

What I said was that you should just register everything from the DT
nodes that describe the hardware and not create dummy devices in the DT
for the Linux internals.  The drivers instantiated from DT should take
care of mapping the hardware into Linux, instantiating everything they
need to from code.  The approach the existing drivers in mainline are
taking is to register multiple ASoC functions from a single device model
device which seems like the logical approach to doing the mapping to me.

Some of the remarks you've made on IRC and code you've pointed me at
suggest that you have formed the impression that there needs to be a 1:1
mapping between device model devices and ASoC function drivers.  This is
not the case.  A driver for a device model device can register as many
different ASoC functions of whatever type it sees fit from a single
device model device.

> on ARM (at Linus' insistance) to get rid of board files, but it perpetuates
> this silly idea that every audio interface should be split up whether
> there's a distinction there or not.

I'm not entirely convinced that modelling different areas of
functionality with different ops structures (which is essentially what
is happening here) is a massive design flaw.

> We need to have solutions which do not require artificial breakup of
> drivers; we need solutions where hardware can be described by DT and
> that DT description be used by the kernel with the minimum of code.
> What we don't need are yet more board files appearing in some other
> random part of the kernel tree.

This is the current situation, none of the existing DT using platforms
have had any need to do that.  Nothing about Kirkwood audio seems to be
at all unusual here.

We *do* have board files for the linkage between the various components
since (as discussed previously ad nauseum) a lot of embedded audio
hardware is interesting enough to warrant having a driver itself.  There
has been some work on generic drivers for simpler systems which should
be useful and can be built on, though we do need the problems with the
clock framework availability to be addressed (both getting it available
on all platforms and ensuring that the platforms with custom frameworks
move to the genric one).  These drivers are separate to the issue you
are discussing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121123/c35b8c7f/attachment.sig>