[PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s

[Mark Brown]

On Mon, Aug 05, 2013 at 08:14:47PM +0200, Sebastian Hesselbarth wrote:
> On 08/05/2013 06:59 PM, Mark Brown wrote:

> >The clocking arrangements are an example of why the boards can get
> >interesting enough to describe for themselves.

> I understand there are complex arrangements, I still don't think that
> you need a global super-node to describe them. Anyway, I am not voting
> against a super-node.

Please look back through the list archives, we've been round this loop
repeatedly.

> >>Also, all those "nvidia," properties would have fit very well into the
> >>i2s controller node

> >No, almost none of them have any place there.  For example, the audio
> >routing contains only connections to the CODEC so the I2S controller
> >isn't in play, the headphone detection is connected to the AP but isn't
> >connected to the I2S port.

> From a quick look in tegra30_hub.h, I can see configuration registers
> i2s formatting. I assume that i2s controller on Tegra can therefore
> directly connected to a I2S codec, can't it? Then, with an existing i2s
> node and an existing codec node - why is there no place to link both?

At a minimum we'd need to figure out which end of the link to put it on
and what to do about multi-drop links or links which share some or all
of the clocks but have split data lines.

> I can think of use cases that are hard to describe in a link-to-link
> way, but none of them really requires a super-node nor special
> board-specific compatible strings. With that we can just have the root
> DT node be compatible with Beaver above and register all the old
> platform_device way.

It's just plain good practice to have some way to figure out which board
we're running on.

> [...]
> >>I learned to never match "device nodes" with "drivers" as there
> >>is simply no relation between them.

> >That's clearly a thinko for device node.

> I assume with "thinko" you mean "thought wrong" - IMHO the above
> statement is very true. If it wouldn't, why not just have a node for
> kirkwood-dma and kirkwood-i2s instead of merging the drivers?
> You think that will also be accepted by DT maintainers?

We don't have a node for the DMA driver because it's just a software
wrapper for the DMA controller.  We do have a node for the board because
it's an actual physical thing that we can point at, the board driver is
representing the audio subsystem schematic.

> > From my point of view I'd rather not be shoving vendor prefixes on all
> >the properties, this is coming from DT convention requiring vendor
> >prefixes on bindings.

> I understand that those vendor prefixes are part of the helper
> functions of ASoC. But no other subsystem has a similar approach but

No?  I can't parse what you're saying here at all.

> though of properties generic enough to help drivers find what they
> need to know. Either ASoC is mis-interpreting the vendor-prefix
> requirement - or all other subsystems are.

This isn't me, this is people like Stephen (who's one of the DT
guys...).
-------------- 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/20130805/f1e2979e/attachment.sig>