Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933410AbcDERbs (ORCPT ); Tue, 5 Apr 2016 13:31:48 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:45526 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758390AbcDERbp (ORCPT ); Tue, 5 Apr 2016 13:31:45 -0400 Date: Tue, 5 Apr 2016 10:31:25 -0700 From: Mark Brown To: Octavian Purdila Cc: Irina Tirdea , "Rafael J. Wysocki" , Len Brown , Mika Westerberg , Linus Walleij , "linux-gpio@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Rob Herring , Heikki Krogerus , Andy Shevchenko , Cristina Ciocan , devicetree@vger.kernel.org, lkml , mark.rutland@arm.com Message-ID: <20160405173125.GF1924@sirena.org.uk> References: <1459424685-26965-1-git-send-email-irina.tirdea@intel.com> <20160404214034.GL2350@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V4b9U9vrdWczvw78" Content-Disposition: inline In-Reply-To: X-Cookie: Even bytes get lonely for a little bit. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 209.65.105.100 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2852 Lines: 66 --V4b9U9vrdWczvw78 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 05, 2016 at 03:51:18PM +0300, Octavian Purdila wrote: > On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown wrote: > > So this is mainly targeted at modules being added to base boards? > That is the main use case, yes. Velocity of platform > debugging/enabling is another one. The speed thing sounds like someone needs to work on the tooling for working on firmware TBH. > > This means that any binding of a board to an ACPI > > using system that just uses this is going to be entirely specific to the > > particular combination of base and expansion board even if the > > electrical connections are standard. > This can be solved by tools that work with high level abstractions and > generate this specific information. Simply stating that there are in future going to be some higher level things which make use of this firmware interface isn't altogether reassuring when we're still in the process of solving the issues for the DT version of this... > > This is something that people are currently looking at for DT, there the > > discussion has been about defining the connectors as entities and hiding > > the details of the muxing on the SoC behind that along with higher level > > concepts like instantiation of buses like I2C and SPI. It seems like if > > we do want to try to share between DT and ACPI we should be doing it at > > that level rather than dealing with pinmuxing at the extremely low level > > that pinctrl does. > At some point we still need to poke registers. We already have a > drivers that do this (pinctrl) and a standard configuration interface > (the pinctrl device tree bindings). It seems natural to build on top > of this for those higher level concepts / tools. Both DT and ACPI have a system model behind them and they're not the stame system model. Importing one into the other directly without carefully thinking through how they play nicely with each other seems likely to lead to problems further down the line, you might know exactly how you intend this to work but how do we make sure that a firmware author in some system integrator knows about this and is able to safely write firmware in a few years? --V4b9U9vrdWczvw78 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXA/ZpAAoJECTWi3JdVIfQi7IH/j5oprmSwIrvfgV9B4EC17lV Jke/IgGvCWZ+5e2WhB8j6EGzMFQ+To/Stp8k5+iIzmmjPu/3VTQgCRGovo0XnOee MkMRm03fbtb+9ZmEMHVjZaRVgSBP32DzMQ5D/+fNphNFszftpIk/PJy+tNDtbcZm SiOyuRBnpOk62bgZlMwxjIyxrv5pyN3mbokDmbmeDbRmmrzuf+inqnd+sb5oH6Xu OZdkIhuHlZzaAexDO1iZYfqFRNWhlQiW4liNK2ZS702SJvJ2jFc3oB49LuzLMjVZ 8MfqztvBx3QnBv5PIhe1e79YGZRRVgEUOmCH+rKVM2vEdl6zinZbJJlXBUK8A7U= =jjXV -----END PGP SIGNATURE----- --V4b9U9vrdWczvw78--