linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 May 2009 23:24:24 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Timur Tabi <timur@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 02:50:27PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 12:32 PM, Mark Brown

> > This worries me too, my experiences with OF device tree handling for
> > ASoC have been pretty negative - but then audio is one of the worst
> > cases for handling within the device tree.

> ASoC is where I2C was a year ago. I2C had it's own module loading
> conventions. OF assumes the subsystem is going to follow the standard
> kernel module loading conventions. I2C has now been fixed to use the
> standard conventions and it happily works with OF now.

As I just said to Grant this is not the case any more, unless you are
using AC97.  You can instantiate all the component drivers for an ASoC
card via the normal device model methods, the overwhelming majority of
my ASoC work is done on systems that do exactly this.

> The fight with ASoC is that two different entities are trying to link
> the modules together - ASoC (machine drivers) and the device tree
> code. There should only be one system linking everything together.

That's not the fundamental problem that machine drivers solve, though
they do the basic tab A into slot B stuff too.  The biggest problem that
machine drivers solve is that they allow us to set up the clocks used in
the audio subsystem in a way that is appropriate for the system based on
how it's wired up and what it's supposed to do.  As I just said to Grant
any OS neutral expression of this configuration suitable for use in a
device tree would need to be able to provide some constraints and a wiring
diagram.  These would then be used together with constraints from the
current runtime configuration to calculate an actual clock configuration
for the system.

If we had a cross-platform clock framework which was capable of handling
this then producing a generic machine driver would be more tractable but
there's no visible prospect of that happening any time soon.

Please read back over the original soc-of-simple thread, it goes into
the problems in a bit more detail.

> But you want these ASoC machine drivers on ARM because ARM doesn't
> have device trees.

This is nothing to do with the device trees, as I believe I've mentioned
before the existing ARM equivalents of the device tree are exactly
equivalent to it for device loading as far as things outside arch/arm
are concerned.

> I2C had the same problem. I2C wanted everything loaded form machine
> drivers. The machine drivers are now optional. ASoC can be fixed in
> the same way.

It's very easy to say things like this but there's quite a way to go
before they can be delivered upon; if it were straightforward to handle
I'd expect that soc-of-simple would be able to cope with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/