On Mon, 18 Nov 2013 16:05:37 +0100, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Saturday 16 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > > > For all I know, doing this in ACPI is something that is only now being > > > discussed as Intel wants to be able to reuse the existing features from > > > DT enabled drivers in the kernel and share the implementation between > > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > > isn't as crazy. > > > > > > The existing ACPI usage however is basically all binary and cannot be > > > shared with DT, in particular it won't help for the orthogonal problem of > > > using ACPI to get "enterprise server" features on ARM64. > > > > That's strange, because the patches I've seen from people who want to > > add ACPI support to AMBA are all based around very similar strings to > > those in DT to lookup the same data in ACPI. > > Can you point to specific patches? I can't say I'm an expert on this, but > everything I've seen with ACPI is tables of binary data with four-letter > identifiers that are defined by the ACPI group, but not using strings > in a similar manner to DT. Apple has an extension to do DT-style properties > in their phones, and we had a discussion at the kernel summit to do > a more generic variation of the same idea that Darren Hart presented, > but that is still in prototype stage. ACPI is a mix of binary tables (can be dereferenced directly as C structs) and the "ACPI Namespace" which looks remarkably like a device tree, except the nodes contains bytecode methods instead of static properties. Many of the methods are defined by the ACPI standard to be called for various events; like initialization and power management activities. A lot of core devices on the platform are described both in the static tables and the ACPI namespace. (The ACPI namepaces is the structure decoded by interpreting the bytecode in the DSDT and SSDT tables.) As I see it, ACPI prefers to defer the difficult bits to the platform by using a bytecode to perform arbitrary operations. DT on the other hand defers to the kernel. > > What's been done there is the function which reads from DT has been > > duplicated, and instead of reading the information from DT, it reads it > > from ACPI instead using string names without the vendor prefix. > > The recently posted x-gene ahci driver does this, but from what I can > tell, the implementation is inappropriate on both DT (because of the > use of unreadable four-character upper-case identifiers) and on ACPI > (because of the use of non-standard identifiers). > > > That tells me that what I've stated in my previous email to which you > > replied is _definitely_ possible to do. That means it's certainly > > possible to do this without reinventing the wheel, and without having > > to rewrite lots of parsing code, precisely along the lines I set out > > in my original email. > > To clarify my complaint: while we can do simple (boolean, integer, text, > or arrays of those three) properties with Darren's approach as long as they > are private to one device, that won't suffice for anything that requires > links between devices. We have phandles on DT that can be freely mixed with > integers for things like GPIO or clock references. ACPI has similar > references, but uses a different syntax for doing the same things, and these > have to be standardized per subsystem (i.e. per type of connection) to make > sense. > As a result, every subsystem that has a producer-consumer type connection > requires different code for DT and for ACPI. If the subsystem-to-driver > interface is done well, we can have a common device driver, but in a > lot of cases there will be a leaky abstraction. As Olof pointed out, > even migrating from a DT-only interface to a generic interface would > require changing each driver, even if the result is no more ugly than > the current state. This too should look transparent to device drivers. DT and ACPI have different mechanism for doing cross tree references, but the concept is the same. A driver calling something like "platform_get_my_gpio_resource()" should do the right thing with either an ACPI or DT backend. None of that should appear as custom device driver or architecture code. It should be generic code supporting the driver core. Regardless of the ACPI on ARM question, we need to do this anyway. There are Intel platforms that need it. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
