From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 6AFEB4C6 for ; Sun, 18 May 2014 23:45:33 +0000 (UTC) Received: from v094114.home.net.pl (v094114.home.net.pl [79.96.170.134]) by smtp1.linuxfoundation.org (Postfix) with SMTP id 6FFD81FA9C for ; Sun, 18 May 2014 23:45:32 +0000 (UTC) From: "Rafael J. Wysocki" To: Darren Vincent Hart Date: Mon, 19 May 2014 02:02:26 +0200 Message-ID: <29190889.bIH6D7yf6C@vostro.rjw.lan> In-Reply-To: <1400289090.9575.37.camel@wasp-deb.dvhart.com> References: <1527482.CPBrbWbyLU@vostro.rjw.lan> <1400289090.9575.37.camel@wasp-deb.dvhart.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: dvhart@dvhart.com, ksummit-discuss@lists.linuxfoundation.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Mika Westerberg Subject: Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Friday, May 16, 2014 06:11:30 PM Darren Vincent Hart wrote: > On Thu, 2014-05-15 at 14:05 +0200, Rafael J. Wysocki wrote: > > On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote: > > > > > > Some of what's going on is limitations in current ACPI and it does make > > > sense to address those in as generic a fashion as possible but it isn't > > > clear to me that all ACPI users want to have something that looks like > > > DT. > > > > For things that are not covered by ACPI either directly or indirectly today, > > that seems to be the only approach feasible in a reasonable time frame. > > > > For things that are covered by ACPI that is less clear. Even in that case, > > though, if there's a binding (defined as a set of keys and value data types > > associated with them) that a driver expects to be used, it makes a little > > sense to create a second binding for it just for the purpose of using it with > > a different firmware interface. > > > > Rafael > > > > As Mark has pointed out, there are many ways in which ACPI is used (and > sometimes abused), and we agree that "all" ACPI users may not want to > use something that looks like DT. This gives us the flexibility to do > so, and solves a couple critical issies. > > What we are starting to see is people developing with ACPI-based systems > that need to use both 1) drivers with some kind of parameterization that > isn't explicitly covered in the ACPI specification and 2) DT-aware > platform drivers without ACPI support. > > For 1, without any kind of clear guiding principles like a DT Binding, > we are seeing lots of custom non-reusable implementations ranging from > all kinds of _DSM implementations to named objects (ACPI pdata > basically), all with driver-specific validation, parsing, formats, etc. > > For 2, we tend to see more board files. > > With a standardized mechanism in ACPI to provide property data, we can > enhance ACPI-aware drivers while abstracting the parsing, validation, > etc. into something that can be shared across the drivers. The idea > being we reduce code duplication and the associated bugs and maintenance > overhead that brings with it. I obviously agree. :-) Rafael