[Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

Pantelis Antoniou panto at antoniou-consulting.com
Mon May 5 02:52:53 UTC 2014


Hi Guenter,

Replies inline.

On May 4, 2014, at 10:27 AM, Guenter Roeck wrote:

> On 05/04/2014 10:18 AM, Olof Johansson wrote:
>> 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.
>> 

As far as I can tell, if you forgo ACPI's AML execution hooks a conversion of the
ACPI tables to DT is completely doable. The standard PC platform is not that diverse
really, especially compared with the wild differences between ARM platforms.

>>>>> 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.
>> 
> We (Juniper) are moving towards a partial conversion from ACPI to DT, pretty
> much just enough to let us work with DT overlays on X86. If there is interest
> to discuss this, it might make sense to invite Pantelis Antoniou and possibly
> Georgi Vlaev, since both are instrumental to making it work.
> 

I can see that Intel makes yet another push to embedded. It remains to be seen
how committed they are this time. A lot of people got burned the last time
when Intel abandoned the market, so expect lots of skepticism this time. 

Due to the crazy variety in embedded applications any rigid solution is going to
have a hard time/lead to hacks that for ever shall be maintained out of mainline.
 
> Guenter
> 

Regards

-- Pantelis


More information about the Ksummit-discuss mailing list