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:	Thu, 28 May 2009 11:37:46 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	David Miller <davem@...emloft.net>
Cc:	r.schwebel@...gutronix.de, scottwood@...escale.com,
	grant.likely@...retlab.ca, devicetree-discuss@...abs.org,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, yuan-bo.ye@...orola.com,
	timur@...escale.com, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote:
> From: Robert Schwebel <r.schwebel@...gutronix.de>

> > It works badly for corner cases, and embedded land is full
> > of it. The effort to get the oftree stuff right is often more than a
> > magnitude of order higher than the effort for the actual functionality.
> > That should be an alarm sign that something is wrong.

> And here you speak about the negatives purely in generalities that
> cannot be discussed concretely.

> And, sadly, I think this is on purpose.

A concrete example that was mentioned elsewhere in the thread is audio
subsystems.  The audio subsystem for an embedded system will contain
multiple chips - a mobile phone could have the CPU, an audio CODEC,
bluetooth and GSM for example.  These will be interconnected by a
combination of analogue and digital links.  The digital links consist of
six wires (data, sync clock and bit clock for each of transmit and
recieve), some of which may be tied together in hardware.  Some of these
links may be shared either with switches or using TDM.  The devices will
also have master clocks from various sources and will often have PLLs or
FLLs able to generate clocks if the inputs aren't directly usable.  Each
clock domain within the audio subsystem will need some level of
synchronisation of the clocks and there may be multiple clock domains
within the system.

In principle we could describe the links between the devices, provide
some additional use case based constraints then take this information
and figure out a suitable runtime configuration automatically; this is
probably the only viable OS neutral way of doing things.  In practice
we're nowhere near having a clock framework which is able to support
implementing this.

The current approach is to write custom code that knows a suitable way
to set things up in a given system (which is a much more tractable
problem).  The PowerPC people have mostly accepted using this approach
but they're really not happy with it and it's been difficult to get the
general community understanding that it's hard to cope with this in the
device tree.
--
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/