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 A947496D for ; Sun, 4 May 2014 21:16:54 +0000 (UTC) Received: from v094114.home.net.pl (v094114.home.net.pl [79.96.170.134]) by smtp1.linuxfoundation.org (Postfix) with SMTP id 57A0F20313 for ; Sun, 4 May 2014 21:16:52 +0000 (UTC) From: "Rafael J. Wysocki" To: ksummit-discuss@lists.linuxfoundation.org Date: Sun, 04 May 2014 23:33:28 +0200 Message-ID: <1753987.hbb65qFWcl@vostro.rjw.lan> In-Reply-To: <20140504171807.GA4418@quad.lixom.net> References: <20140504111436.GC15180@arm.com> <20140504171807.GA4418@quad.lixom.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: "dvhart@dvhart.com" , "Rafael J. Wysocki" , Greg Kroah-Hartman 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 Sunday, May 04, 2014 10:18:07 AM Olof Johansson wrote: > Hi, Hi, > [BTW, I forgot to mention that BenH of course would be one person we need > involved in all this. Adding him to the cc list here, but I know he's seen the > thread already :)] > > On Sun, May 04, 2014 at 12:14:36PM +0100, Catalin Marinas wrote: > > On Sat, May 03, 2014 at 04:14:51PM +0100, Arnd Bergmann wrote: > > > On Saturday 03 May 2014 02:05:21 Rafael J. Wysocki wrote: > > > > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote: > > > > > * Converting either of them to use platform device model > > > > > (platform_data) to register drivers, and leave them unaware of either > > > > > hardware description > > > > > * [... I'm likely missing something here as well] > > > > > > Olof, funny you missed the proposal you made yourself: > > > > > > * convert ACPI data into DT format at boot time > > > > I thought this was discussed at length and agreed it's not a way > > forward, given the differences between ACPI and DT, especially on the > > AML feature which DT does not have (making one-off boot-time conversion > > not feasible). > > I'm explicitly choosing to not discuss the ARM64 situation here myself, > I am more interested in solving the issues around Intel's forage into > embedded. > > ACPI on ARM64/SBSA is in many ways a different problem, and one that > I don't know what there is to talk about, to be honest. Mostly because > we're still talking hypotheticals and not-yet-published docs, and all > vendors are still under deep NDA on product plans and what they're > planning on doing. It means we're playing games of telephone right now > and it's better to just wait until we have something concrete to center > the discussions around. > > Intel, on the other hand, are already shipping this hardware, and have > a platforms to do the work on (Minnowboard and Galieo, for example). > > So, to address Arnd's original question: > > Yes, it could make more sense to translate the data to a common > format and use the existing accessors for that data format, instead > of reinventing the accessors and still needing to represent the data > some way. I think it depends on how some of the other things develop -- > I don't know enough about what Darren's current approach is, for example, > to tell if it would be easier to do it that way. > > Also, even if we do a common API with different backends, there will > need to be some knowledge somewhere about custom bindings and what they mean, > how to translate them and how the different descriptions correlate. > I personally think we're best off putting that in the drivers, instead of > making some part of the driver core aware of a bunch of quirks/hooks for > various devices. But we have such quirks for some bus types already, like PCI and PNP. > > > > For what it's worth, we are working on extending ACPI to allow DT-style > > > > information to be included into ACPI tables. > > > > > > I think it's important to understand that we have people coming from > > > two sides here: Intel x86 embedded systems with ACPI wanting to the > > > same things we do on embbeded PowerPC and ARM systems with DT, and ARM64 > > > servers trying to do the same things that x86 servers do by moving > > > to ACPI. > > > > > > These two have very different requirements and while there is some > > > overlap, I suspect we will end up with different solutions as well. > > > > I think the middle ground is that for x86 to get into embedded and ARM64 > > into servers, the ACPI spec is not enough as hardware description. > > Traditionally, the x86 hardware is rather standard and ACPI didn't need > > to describe so many things. On ARM, OTOH, we have lots of variation and > > DT provides such flexibility. Even if ARM is pushing for more standard > > server hardware like SBSA, it's still relaxed enough not to look like a > > PC platform. So even if the aims are different, the x86 efforts on more > > hw description in ACPI help both Intel and ARM. Given the collaboration > > between the two on ACPI forums already, I think there are good chances > > of ending up with a common solution for Linux. Of course, x86 may decide > > to go the DT route all the way (and ARM in the other direction ;)). > > I think it's very optimistic to assume that there will ever be a common > solution for both ends of the spectrum (embedded - enterprise), but we > should make sure we can stay sane and not have more solutions than we need > in parallel, and that things will work together where there is overlap. Agreed. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.