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

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

[Olof Johansson]

I'm about as tired of this as everybody else, but that won't make the
issues go away...

I think we resolved a bunch of stuff around DT last year (and since),
but there are still things left to figure out and agree on in these
areas. In particular in the intersection of Intel platforms with ACPI
and embedded are where there are issues and model mismatches, and
doing it in person might be much easier than doing centithreads.
There's been some various hallway talk at conferences about proposals
to make this work better, but the full set of people have never been
in the same room at the same time.

I labelled this as a tech topic. Feel free to upgrade it to a workshop
or relabel it if needed. Base set of people I'd like to see involved
are:

* Darren Hart, who is doing things to make ACPI more DT-like for
embedded use cases.
* Rafael Wysocki, who also has had some ideas on how to make the
models fit together.
* Grant Likely, since he's in the intersection as well.
* Greg K-H would be much appreciated as well, since he'd have to deal
with some of the resulting mess.
* Dave Woodhouse would also be good to have there.

.. I'm probably missing names but they're bound to reply to this email
anyway with opinions.


Some of the ideas I have heard discussed are:
* Adding a new common API for resource management which will have
backends for ACPI or DT depending on platform
* Adding ACPI and DT probing to drivers that lack on or the other
today (giving them a total of three probe methods: platform_device,
DT, ACPI).
* 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]

All solutions above have trade-offs, and neither is an obvious choice.
We could likely spend between now and KS arguing this every day on the
lists if we wanted to. Getting the people into the same room for a
couple of hours is likely to be a much better way to resolve it.


-Olof

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

[Rafael J. Wysocki]

Hi Olof,

Thanks for submitting this!

I was about to submit it too, but you beat me to that. :-)

On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> I'm about as tired of this as everybody else, but that won't make the
> issues go away...
> 
> I think we resolved a bunch of stuff around DT last year (and since),
> but there are still things left to figure out and agree on in these
> areas. In particular in the intersection of Intel platforms with ACPI
> and embedded are where there are issues and model mismatches, and
> doing it in person might be much easier than doing centithreads.

Agreed.

> There's been some various hallway talk at conferences about proposals
> to make this work better, but the full set of people have never been
> in the same room at the same time.

Yes.

> I labelled this as a tech topic. Feel free to upgrade it to a workshop
> or relabel it if needed. Base set of people I'd like to see involved
> are:
> 
> * Darren Hart, who is doing things to make ACPI more DT-like for
> embedded use cases.
> * Rafael Wysocki, who also has had some ideas on how to make the
> models fit together.
> * Grant Likely, since he's in the intersection as well.
> * Greg K-H would be much appreciated as well, since he'd have to deal
> with some of the resulting mess.
> * Dave Woodhouse would also be good to have there.

+ H. Peter Anvin

> .. I'm probably missing names but they're bound to reply to this email
> anyway with opinions.
> 
> 
> Some of the ideas I have heard discussed are:
> * Adding a new common API for resource management which will have
> backends for ACPI or DT depending on platform

I would like to do this, personally, because I believe that drivers
should not need to add support for any particular firmware interfaces
directly (except for listing matching device IDs).

> * Adding ACPI and DT probing to drivers that lack on or the other
> today (giving them a total of three probe methods: platform_device,
> DT, ACPI).

But that is not about platform devices only.  There also are SPI and I2C
devices (and likely other bus types too) that require similar kind of
information from the platform firmware (e.g. are not natively enumerable).

> * 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]
> 
> All solutions above have trade-offs, and neither is an obvious choice.
> We could likely spend between now and KS arguing this every day on the
> lists if we wanted to. Getting the people into the same room for a
> couple of hours is likely to be a much better way to resolve it.

For what it's worth, we are working on extending ACPI to allow DT-style
information to be included into ACPI tables.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Sat, May 03, 2014 at 02:05:21AM +0200, Rafael J. Wysocki wrote:
> On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:

> > Some of the ideas I have heard discussed are:
> > * Adding a new common API for resource management which will have
> > backends for ACPI or DT depending on platform

> I would like to do this, personally, because I believe that drivers
> should not need to add support for any particular firmware interfaces
> directly (except for listing matching device IDs).

The trouble with this is that the different firmware interfaces have
rather different ideas about how things should work.  Basic things like
interrupts are generally fine but more complex things like the way that
devices integrate with system power management are much more up in the
air.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On Friday, May 02, 2014 07:02:42 PM Mark Brown wrote:
> 
> --sXc4Kmr5FA7axrvy
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Sat, May 03, 2014 at 02:05:21AM +0200, Rafael J. Wysocki wrote:
> > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> 
> > > Some of the ideas I have heard discussed are:
> > > * Adding a new common API for resource management which will have
> > > backends for ACPI or DT depending on platform
> 
> > I would like to do this, personally, because I believe that drivers
> > should not need to add support for any particular firmware interfaces
> > directly (except for listing matching device IDs).
> 
> The trouble with this is that the different firmware interfaces have
> rather different ideas about how things should work.  Basic things like
> interrupts are generally fine but more complex things like the way that
> devices integrate with system power management are much more up in the
> air.

In my opinion, device drivers should not be concerned about that really.
The layers of code above them (bus types etc.) should, but not drivers
themselves, because that makes it difficult to use the same driver
for the same piece of hardware on two systems with different firmware
interfaces.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Benjamin Herrenschmidt]

On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
> In my opinion, device drivers should not be concerned about that
> really.
> The layers of code above them (bus types etc.) should, but not drivers
> themselves, because that makes it difficult to use the same driver
> for the same piece of hardware on two systems with different firmware
> interfaces.

Only for standardized resource types, such as mmio ranges or interrupts.

Anything else is absolutely in the domain of competence of the driver
and I would argue *only* in the domain of competence of the driver.

This is a dirty enough table, don't invite a 3rd party to it :-)

Cheers,
Ben.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Mon, May 05, 2014 at 06:45:28PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:

> > In my opinion, device drivers should not be concerned about that
> > really.
> > The layers of code above them (bus types etc.) should, but not drivers
> > themselves, because that makes it difficult to use the same driver
> > for the same piece of hardware on two systems with different firmware
> > interfaces.

> Only for standardized resource types, such as mmio ranges or interrupts.

> Anything else is absolutely in the domain of competence of the driver
> and I would argue *only* in the domain of competence of the driver.

> This is a dirty enough table, don't invite a 3rd party to it :-)

Right - boring and easy stuff is boring and easy but that's not all the
world and we need to acknowledge that.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
> > In my opinion, device drivers should not be concerned about that
> > really.
> > The layers of code above them (bus types etc.) should, but not drivers
> > themselves, because that makes it difficult to use the same driver
> > for the same piece of hardware on two systems with different firmware
> > interfaces.
> 
> Only for standardized resource types, such as mmio ranges or interrupts.
> 
> Anything else is absolutely in the domain of competence of the driver
> and I would argue *only* in the domain of competence of the driver.

But why can't we treat DT bindings as a standard?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
> > On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:

> > > In my opinion, device drivers should not be concerned about that
> > > really.
> > > The layers of code above them (bus types etc.) should, but not drivers
> > > themselves, because that makes it difficult to use the same driver
> > > for the same piece of hardware on two systems with different firmware
> > > interfaces.

> > Only for standardized resource types, such as mmio ranges or interrupts.

> > Anything else is absolutely in the domain of competence of the driver
> > and I would argue *only* in the domain of competence of the driver.

> But why can't we treat DT bindings as a standard?

Aside from the whole question of people bothering to pay attention to
the specs when writing their BIOSs DTs (as used in modern systems) and
ACPI have quite different models for what should be handled where - FDT
is pure data and expects the kernel to do everything while ACPI expects
to be used with active firmware.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On 5/12/2014 11:59 PM, Mark Brown wrote:
> On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
>> On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
>>> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
>>>> In my opinion, device drivers should not be concerned about that
>>>> really.
>>>> The layers of code above them (bus types etc.) should, but not drivers
>>>> themselves, because that makes it difficult to use the same driver
>>>> for the same piece of hardware on two systems with different firmware
>>>> interfaces.
>>> Only for standardized resource types, such as mmio ranges or interrupts.
>>> Anything else is absolutely in the domain of competence of the driver
>>> and I would argue *only* in the domain of competence of the driver.
>> But why can't we treat DT bindings as a standard?
> Aside from the whole question of people bothering to pay attention to
> the specs when writing their BIOSs DTs (as used in modern systems) and
> ACPI have quite different models for what should be handled where - FDT
> is pure data and expects the kernel to do everything while ACPI expects
> to be used with active firmware.

While in practice ACPI is used on systems with active firmware usually, 
there's no expectation like this in ACPI itself in principle.

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

[Arnd Bergmann]

On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> On 5/12/2014 11:59 PM, Mark Brown wrote:
> > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> >> On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
> >>> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
> >>> Only for standardized resource types, such as mmio ranges or interrupts.
> >>> Anything else is absolutely in the domain of competence of the driver
> >>> and I would argue *only* in the domain of competence of the driver.
> >>
> >> But why can't we treat DT bindings as a standard?
> >
> > Aside from the whole question of people bothering to pay attention to
> > the specs when writing their BIOSs DTs (as used in modern systems) and
> > ACPI have quite different models for what should be handled where - FDT
> > is pure data and expects the kernel to do everything while ACPI expects
> > to be used with active firmware.
> 
> While in practice ACPI is used on systems with active firmware usually, 
> there's no expectation like this in ACPI itself in principle.

Right. Open Firmware already has multiple ways of running code from the
firmware (client calls, RTAS, FCODE, ...), which are used all the time,
but we intentionally chose to not allow them for embedded systems with
the FDT subset.

It should be entirely possible and reasonable to do the same thing for
ACPI on embedded systems. I believe this is what SFI attempted to
do, but that seems to have been discarded for some reason.

	Arnd

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

[Rafael J. Wysocki]

On Tuesday, May 13, 2014 09:34:35 AM Arnd Bergmann wrote:
> On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> > >> On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
> > >>> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
> > >>> Only for standardized resource types, such as mmio ranges or interrupts.
> > >>> Anything else is absolutely in the domain of competence of the driver
> > >>> and I would argue *only* in the domain of competence of the driver.
> > >>
> > >> But why can't we treat DT bindings as a standard?
> > >
> > > Aside from the whole question of people bothering to pay attention to
> > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > ACPI have quite different models for what should be handled where - FDT
> > > is pure data and expects the kernel to do everything while ACPI expects
> > > to be used with active firmware.
> > 
> > While in practice ACPI is used on systems with active firmware usually, 
> > there's no expectation like this in ACPI itself in principle.
> 
> Right. Open Firmware already has multiple ways of running code from the
> firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> but we intentionally chose to not allow them for embedded systems with
> the FDT subset.
> 
> It should be entirely possible and reasonable to do the same thing for
> ACPI on embedded systems. I believe this is what SFI attempted to
> do, but that seems to have been discarded for some reason.

The reason was that the SFI turned out to be too simplistic and had to be
supplemented with things like board files.

HW Reduced ACPI is a step in that direction too.  It doesn't preclude active
firmware, but it makes it difficult to coordinate with that firmware if it
does exist.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

On Tue, May 13, 2014 at 09:34:35AM +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:

> > > Aside from the whole question of people bothering to pay attention to
> > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > ACPI have quite different models for what should be handled where - FDT
> > > is pure data and expects the kernel to do everything while ACPI expects
> > > to be used with active firmware.

> > While in practice ACPI is used on systems with active firmware usually, 
> > there's no expectation like this in ACPI itself in principle.

> Right. Open Firmware already has multiple ways of running code from the
> firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> but we intentionally chose to not allow them for embedded systems with
> the FDT subset.

I wouldn't say they're used all the time these days - the platforms with
runtime OF aren't terribly active any more and don't have much overlap
with other systems.

> It should be entirely possible and reasonable to do the same thing for
> ACPI on embedded systems. I believe this is what SFI attempted to
> do, but that seems to have been discarded for some reason.

SFI didn't provide any way of giving data to devices other than
registering them which meant that it ended up with the pain of firmware
based device registration requring firmware updates to get the device
present being combined with the need for board files to actually get the
devices to do anything useful.  On the bright side this got around the
fact that in my experience the firmware was frequently not modifiable by
people directly working on Linux.

This might be another issue for the model where we treat ACPI as DT.
One of the things that makes the DT model workable in the embedded case
is that most of the time as far as the rest of the system is concerned
the DT is essentially part of the kernel - it's built from the same tree
and so on.  If ACPI goes the same way for embedded systems that'd work
just as well but that's obviously not how ACPI has historically been
done and if systems end up being built like they have been that might
not make people happy.  One of the things that active firmware is doing
is decoupling the firmware from the kernel which is a real and useful
benefit in many embedded situations, otherwise you just end up either
doing board quirks or just hacking things to be system specific in code.

There's also the possibility that the driver is going to have to figure
out at runtime if it's on a system with active ACPI or a system with
passsive ACPI, though I expect we can just do something like check what
properties are there for that assuming people don't end up doing
mix'n'match type things.  People are interested in ACPI for embedded
cases outside of x86 to a large extent so that they don't have to deal
with two different firmware interfaces if they also work on the server
cases.

I'm worried that there's more to the model for using a given firmware
interface than just the in kernel API but we're only thinking about
what's convenient in kernel here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Tuesday 13 May 2014 13:11:48 Mark Brown wrote:
> On Tue, May 13, 2014 at 09:34:35AM +0200, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> 
> > > > Aside from the whole question of people bothering to pay attention to
> > > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > > ACPI have quite different models for what should be handled where - FDT
> > > > is pure data and expects the kernel to do everything while ACPI expects
> > > > to be used with active firmware.
> 
> > > While in practice ACPI is used on systems with active firmware usually, 
> > > there's no expectation like this in ACPI itself in principle.
> 
> > Right. Open Firmware already has multiple ways of running code from the
> > firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> > but we intentionally chose to not allow them for embedded systems with
> > the FDT subset.
> 
> I wouldn't say they're used all the time these days - the platforms with
> runtime OF aren't terribly active any more and don't have much overlap
> with other systems.

I'm not following PowerPC closely any more. It seems that powernv actually
has rtas disabled in the defconfig, but still supports it.
So it's basically down to pseries now, which of course is still an
important platform. You are definitely right that it doesn't have much
overlap with anything else.

powermac, maple, cell, and chrp can probably all be considered dead now.

> > It should be entirely possible and reasonable to do the same thing for
> > ACPI on embedded systems. I believe this is what SFI attempted to
> > do, but that seems to have been discarded for some reason.
> 
> SFI didn't provide any way of giving data to devices other than
> registering them which meant that it ended up with the pain of firmware
> based device registration requring firmware updates to get the device
> present being combined with the need for board files to actually get the
> devices to do anything useful.  On the bright side this got around the
> fact that in my experience the firmware was frequently not modifiable by
> people directly working on Linux.

I see.

> This might be another issue for the model where we treat ACPI as DT.
> One of the things that makes the DT model workable in the embedded case
> is that most of the time as far as the rest of the system is concerned
> the DT is essentially part of the kernel - it's built from the same tree
> and so on.  If ACPI goes the same way for embedded systems that'd work
> just as well but that's obviously not how ACPI has historically been
> done and if systems end up being built like they have been that might
> not make people happy.  One of the things that active firmware is doing
> is decoupling the firmware from the kernel which is a real and useful
> benefit in many embedded situations, otherwise you just end up either
> doing board quirks or just hacking things to be system specific in code.
> 
> There's also the possibility that the driver is going to have to figure
> out at runtime if it's on a system with active ACPI or a system with
> passsive ACPI, though I expect we can just do something like check what
> properties are there for that assuming people don't end up doing
> mix'n'match type things.  People are interested in ACPI for embedded
> cases outside of x86 to a large extent so that they don't have to deal
> with two different firmware interfaces if they also work on the server
> cases.

To be clear, I was only talking about embedded x86 above, there is
no reason to introduce ACPI on any new architecture really.

While we will likely get ACPI on ARM64 in the future, I definitely don't
want to have two incompatible ACPI implementations, especially for the
same chip. While AMD recently announced they are also going after
embedded markets with their ARM64 products, they should either
just use DT in that case, or they should use the same firmware they
have on their servers.

	Arnd

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Tue, May 13, 2014 at 03:08:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 13:11:48 Mark Brown wrote:

> > There's also the possibility that the driver is going to have to figure
> > out at runtime if it's on a system with active ACPI or a system with
> > passsive ACPI, though I expect we can just do something like check what
> > properties are there for that assuming people don't end up doing
> > mix'n'match type things.  People are interested in ACPI for embedded
> > cases outside of x86 to a large extent so that they don't have to deal
> > with two different firmware interfaces if they also work on the server
> > cases.

> To be clear, I was only talking about embedded x86 above, there is
> no reason to introduce ACPI on any new architecture really.

> While we will likely get ACPI on ARM64 in the future, I definitely don't
> want to have two incompatible ACPI implementations, especially for the
> same chip. While AMD recently announced they are also going after
> embedded markets with their ARM64 products, they should either
> just use DT in that case, or they should use the same firmware they
> have on their servers.

I'd heard mutterings like that from elsewhere (I don't know anything
about AMD's thoughts), and of course there's nothing stopping ARM people
just picking up the out of tree ACPI stuff and using that if they decide
they want to work that way.

In any case that was more a comment about it being an area of broader
interest than just some future Intel stuff - my main concern is that
we've already got upstream embedded ACPI stuff for x86 which doesn't
look *particularly* like what we do for DT but more like what seems
idiomatic for ACPI (some of the Haswell and Baytrail laptops have
embedded style audio subsystems) and as far as I am aware those systems
are in the active ACPI model rather than a passive ACPI model.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Tuesday 13 May 2014 20:31:46 Mark Brown wrote:
> 
> I'd heard mutterings like that from elsewhere (I don't know anything
> about AMD's thoughts), and of course there's nothing stopping ARM people
> just picking up the out of tree ACPI stuff and using that if they decide
> they want to work that way.

Sure, anyone can do that, but to me that falls into the same category
as using board files, unreviewed DT bindings or FEX: do what makes you
happy in a private embedded kernel fork, but don't expect that to get
merged upstream.

	Arnd

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

[Rafael J. Wysocki]

On Tuesday, May 13, 2014 08:31:46 PM Mark Brown wrote:
> 
> --CHuL9rjfPiigWdCj
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Tue, May 13, 2014 at 03:08:29PM +0200, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 13:11:48 Mark Brown wrote:
> 
> > > There's also the possibility that the driver is going to have to figure
> > > out at runtime if it's on a system with active ACPI or a system with
> > > passsive ACPI, though I expect we can just do something like check what
> > > properties are there for that assuming people don't end up doing
> > > mix'n'match type things.  People are interested in ACPI for embedded
> > > cases outside of x86 to a large extent so that they don't have to deal
> > > with two different firmware interfaces if they also work on the server
> > > cases.
> 
> > To be clear, I was only talking about embedded x86 above, there is
> > no reason to introduce ACPI on any new architecture really.
> 
> > While we will likely get ACPI on ARM64 in the future, I definitely don't
> > want to have two incompatible ACPI implementations, especially for the
> > same chip. While AMD recently announced they are also going after
> > embedded markets with their ARM64 products, they should either
> > just use DT in that case, or they should use the same firmware they
> > have on their servers.
> 
> I'd heard mutterings like that from elsewhere (I don't know anything
> about AMD's thoughts), and of course there's nothing stopping ARM people
> just picking up the out of tree ACPI stuff and using that if they decide
> they want to work that way.
> 
> In any case that was more a comment about it being an area of broader
> interest than just some future Intel stuff - my main concern is that
> we've already got upstream embedded ACPI stuff for x86 which doesn't
> look *particularly* like what we do for DT but more like what seems
> idiomatic for ACPI (some of the Haswell and Baytrail laptops have
> embedded style audio subsystems) and as far as I am aware those systems
> are in the active ACPI model rather than a passive ACPI model.

They are, but the ACPI stuff that was added there is not exactly what I would
like it to be, due to gaps in ACPI itself to some extent.

Of course, ACPI "support" can be shoehorned into a limited number of things
this way, but it really doesn't scale and very often the result is really
disgusting.  Also ACPI in its current form may not even be able to provide
information expected by device drivers in the first place, because ACPI
doesn't have means to encode that information in any sensible way today
(that includes clocks, voltage regulators, PWMs, pin control and even GPIOs
to some extent).

If ACPI is extended so that such information can be put into the tables,
there is no reason why the interface for extracting it should be much different
from the of_ one, except that instead of calling of_get_something(device_node, ...)
drivers will call fw_get_something(device, ...).  And that can use the old good
of_ for systems with DT, so it really is a matter of getting the ACPI side of
things to match it.

And if you're asking why things are currently done in different ways, the
reason is simple: ACPI has not been extended yet and the fw_get_something(device, ...)
interface doesn't exist, so people have to use what is available today and there are
products to support in the meatime.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3217 bytes --]

On Tue, May 13, 2014 at 11:19:00PM +0200, Rafael J. Wysocki wrote:

> Of course, ACPI "support" can be shoehorned into a limited number of things
> this way, but it really doesn't scale and very often the result is really
> disgusting.  Also ACPI in its current form may not even be able to provide
> information expected by device drivers in the first place, because ACPI
> doesn't have means to encode that information in any sensible way today
> (that includes clocks, voltage regulators, PWMs, pin control and even GPIOs
> to some extent).

> If ACPI is extended so that such information can be put into the tables,
> there is no reason why the interface for extracting it should be much different
> from the of_ one, except that instead of calling of_get_something(device_node, ...)
> drivers will call fw_get_something(device, ...).  And that can use the old good
> of_ for systems with DT, so it really is a matter of getting the ACPI side of
> things to match it.

Of course, and for all of these things other than GPIOs we already
handle the lookups without any DT code at all in the drivers (and GPIOs
are moving away from needing explicit code too).  Things like that just
aren't an issue and I'd say that if we are adding new fw_ interfaces for
resource lookup like you describe we're doing things wrong, we already
have the idiom of looking up by device and some key which works well.

It gets more interesting with compound devices like multimedia; there's
not really a clear general model for handling these in kernel in the
first place plus also some ongoing discussion about how they are best
represented in DT.  Those might well fall into the too hard to handle
generically category though.

> And if you're asking why things are currently done in different ways, the
> reason is simple: ACPI has not been extended yet and the fw_get_something(device, ...)
> interface doesn't exist, so people have to use what is available today and there are
> products to support in the meatime.

Not really, the issue is more about the model and applies just as much
to things like device specific properties as it does to resource lookup
(to be honest resource lookup is the easiest thing here - it's not a
relevant issue with the in tree stuff).

Active ACPI systems have the idea that the firmware is going to go and
interact with the hardware directly itself, one of the goals being to
allow the hardware to be extended in ways that the OS would otherwise
need to be modified to support.  In contrast FDT and the new passive
ACPI model you are describing just provide data and leave everything up
to the OS in terms of interacting with the hardware.  What's tasteful
and what system integrators expect to work with both seem to vary
between the two - one of the most common I'm seeing is that with active
firmware configuration written into the device on startup may actually
be real and worth paying attention to while with passive firmware it's
usually best to ignore the device state.

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:
> 
> --7Mplw3OCI4oLNRBG
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Tue, May 13, 2014 at 11:19:00PM +0200, Rafael J. Wysocki wrote:
> 
> > Of course, ACPI "support" can be shoehorned into a limited number of things
> > this way, but it really doesn't scale and very often the result is really
> > disgusting.  Also ACPI in its current form may not even be able to provide
> > information expected by device drivers in the first place, because ACPI
> > doesn't have means to encode that information in any sensible way today
> > (that includes clocks, voltage regulators, PWMs, pin control and even GPIOs
> > to some extent).
> 
> > If ACPI is extended so that such information can be put into the tables,
> > there is no reason why the interface for extracting it should be much different
> > from the of_ one, except that instead of calling of_get_something(device_node, ...)
> > drivers will call fw_get_something(device, ...).  And that can use the old good
> > of_ for systems with DT, so it really is a matter of getting the ACPI side of
> > things to match it.
> 
> Of course, and for all of these things other than GPIOs we already
> handle the lookups without any DT code at all in the drivers (and GPIOs
> are moving away from needing explicit code too).  Things like that just
> aren't an issue and I'd say that if we are adding new fw_ interfaces for
> resource lookup like you describe we're doing things wrong, we already
> have the idiom of looking up by device and some key which works well.

The "key" think doesn't really work in ACPI if it is a string, however.

That's a real problem, because, for example, ACPI says "I have these GPIO
connections between your device and controller X" and it gives you pin
numbers.  Now the driver (or someone else) needs to figure out which pin
is used for what.

If there's only one pin per device, all is fine, but if there are more of
them things get very ugly quite quickly.

So in "native" ACPI something like gpiod_get() cannot really be implemented
to use con_id and if you look at acpi_find_gpio() (the one in gpiolib.c),
you'll see that it actually only uses the index for this very reason.

It may look good on the surface, but if you go deeper into things, it really
doesn't.

Same goes for similar "resources".

> It gets more interesting with compound devices like multimedia; there's
> not really a clear general model for handling these in kernel in the
> first place plus also some ongoing discussion about how they are best
> represented in DT.  Those might well fall into the too hard to handle
> generically category though.

Well, that's hard to say wihtout looking at specific examples.

If something proves too hard to be addressed in a common fashion, which is
not unlikely, we'll need to find some other way to address it, but as long
as we *can* do things in common ways, we should do that in my opinion.

> > And if you're asking why things are currently done in different ways, the
> > reason is simple: ACPI has not been extended yet and the fw_get_something(device, ...)
> > interface doesn't exist, so people have to use what is available today and there are
> > products to support in the meatime.
> 
> Not really, the issue is more about the model and applies just as much
> to things like device specific properties as it does to resource lookup
> (to be honest resource lookup is the easiest thing here - it's not a
> relevant issue with the in tree stuff).
> 
> Active ACPI systems have the idea that the firmware is going to go and
> interact with the hardware directly itself, one of the goals being to
> allow the hardware to be extended in ways that the OS would otherwise
> need to be modified to support.

I agree.

Nevertheless, it often turns out that the OS needs to interact with that
hardware too for various reasons.

> In contrast FDT and the new passive
> ACPI model you are describing just provide data and leave everything up
> to the OS in terms of interacting with the hardware.  What's tasteful
> and what system integrators expect to work with both seem to vary
> between the two - one of the most common I'm seeing is that with active
> firmware configuration written into the device on startup may actually
> be real and worth paying attention to while with passive firmware it's
> usually best to ignore the device state.

Again, I agree.  The PCI host bridge is actually a good example of that.

> 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

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

[Darren Vincent Hart]

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.

At the same time, we can readily adapt DT-aware platform drivers to
build pdata from the same schema/binding, represented in a standardized
key:value format. The abstraction layer Rafael has mentioned allows us
to keep the changes to the drivers minimal by not having to add an
ACPI-specific pdata builder (like I did in my prototype precursor to
this ACPI Spec change at ELC/KS last year).

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

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

[Rafael J. Wysocki]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Thu, May 15, 2014 at 02:05:43PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:

> > Of course, and for all of these things other than GPIOs we already
> > handle the lookups without any DT code at all in the drivers (and GPIOs
> > are moving away from needing explicit code too).  Things like that just
> > aren't an issue and I'd say that if we are adding new fw_ interfaces for
> > resource lookup like you describe we're doing things wrong, we already
> > have the idiom of looking up by device and some key which works well.

> The "key" think doesn't really work in ACPI if it is a string, however.

> That's a real problem, because, for example, ACPI says "I have these GPIO
> connections between your device and controller X" and it gives you pin
> numbers.  Now the driver (or someone else) needs to figure out which pin
> is used for what.

> If there's only one pin per device, all is fine, but if there are more of
> them things get very ugly quite quickly.

> So in "native" ACPI something like gpiod_get() cannot really be implemented
> to use con_id and if you look at acpi_find_gpio() (the one in gpiolib.c),
> you'll see that it actually only uses the index for this very reason.

Surely all we need to do for these cases is provide a way for drivers to
supply the name to number mappings for usage with ACPI (probably with
per device and per board overrides possible due to all the failures
usually associated with numbers)?  That's much less invasive than making
new APIs.

> > It gets more interesting with compound devices like multimedia; there's
> > not really a clear general model for handling these in kernel in the
> > first place plus also some ongoing discussion about how they are best
> > represented in DT.  Those might well fall into the too hard to handle
> > generically category though.

> Well, that's hard to say wihtout looking at specific examples.

> If something proves too hard to be addressed in a common fashion, which is
> not unlikely, we'll need to find some other way to address it, but as long
> as we *can* do things in common ways, we should do that in my opinion.

That does make sense.  The complex examples I thinking of are things
like Documentation/devicetree/bindings/sound/simple-card.txt and the
more complex versions of such subsystems.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On Saturday, May 17, 2014 02:24:23 PM Mark Brown wrote:
> 
> --ucW7QTJbHsz5ya91
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Thu, May 15, 2014 at 02:05:43PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:
> 
> > > Of course, and for all of these things other than GPIOs we already
> > > handle the lookups without any DT code at all in the drivers (and GPIOs
> > > are moving away from needing explicit code too).  Things like that just
> > > aren't an issue and I'd say that if we are adding new fw_ interfaces for
> > > resource lookup like you describe we're doing things wrong, we already
> > > have the idiom of looking up by device and some key which works well.
> 
> > The "key" think doesn't really work in ACPI if it is a string, however.
> 
> > That's a real problem, because, for example, ACPI says "I have these GPIO
> > connections between your device and controller X" and it gives you pin
> > numbers.  Now the driver (or someone else) needs to figure out which pin
> > is used for what.
> 
> > If there's only one pin per device, all is fine, but if there are more of
> > them things get very ugly quite quickly.
> 
> > So in "native" ACPI something like gpiod_get() cannot really be implemented
> > to use con_id and if you look at acpi_find_gpio() (the one in gpiolib.c),
> > you'll see that it actually only uses the index for this very reason.
> 
> Surely all we need to do for these cases is provide a way for drivers to
> supply the name to number mappings for usage with ACPI (probably with
> per device and per board overrides possible due to all the failures
> usually associated with numbers)?

Yes, we can do that for things like gpiod_get() that already abstract the
firmware interface away from device drivers.

> That's much less invasive than making new APIs.

But for drivers that call of_get_something() directly I don't see any other
sensible way forward.  Otherwise each of them will need to do something like

if (dev->of_node)
	use of_get_X()
else if (ACPI_COMPANION(dev))
	use acpi_get_X()
else
	use black magic

possibly in several places.

Rafael

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Mon, May 19, 2014 at 01:56:33AM +0200, Rafael J. Wysocki wrote:
> On Saturday, May 17, 2014 02:24:23 PM Mark Brown wrote:

> > That's much less invasive than making new APIs.

> But for drivers that call of_get_something() directly I don't see any other
> sensible way forward.  Otherwise each of them will need to do something like

> if (dev->of_node)
> 	use of_get_X()
> else if (ACPI_COMPANION(dev))
> 	use acpi_get_X()
> else
> 	use black magic

> possibly in several places.

OK, but that's basically just the property reading cases (unless we're
doing something fancy involving phandles which is a bit more fun and
less clear that it'll Just Work) - it seems a bit of a shame to have to
churn all the APIs to do it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Linus Walleij]

On Mon, May 19, 2014 at 1:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Saturday, May 17, 2014 02:24:23 PM Mark Brown wrote:

>> That's much less invasive than making new APIs.
>
> But for drivers that call of_get_something() directly I don't see any other
> sensible way forward.  Otherwise each of them will need to do something like
>
> if (dev->of_node)
>         use of_get_X()
> else if (ACPI_COMPANION(dev))
>         use acpi_get_X()
> else
>         use black magic

So there is currently net/rfkill/rfkill-gpio.c,
and there is a patch to add device tree support out there:
http://marc.info/?l=devicetree&m=139754665715639&w=2

And after that it looks like that:

static int rfkill_gpio_acpi_probe(struct device *dev,
                                  struct rfkill_gpio_data *rfkill)
{
        const struct acpi_device_id *id;

        id = acpi_match_device(dev->driver->acpi_match_table, dev);
        if (!id)
                return -ENODEV;

        rfkill->name = dev_name(dev);
        rfkill->type = (unsigned)id->driver_data;

        return 0;
}

static int rfkill_gpio_dt_probe(struct device *dev, struct
rfkill_gpio_data *rfkill)
{
        struct device_node * np = dev->of_node;

        rfkill->name = np->name;
        of_property_read_string(np, "rfkill-name", &rfkill->name);
        of_property_read_u32(np, "rfkill-type", &rfkill->type);

        return 0;
}

static int rfkill_gpio_probe(struct platform_device *pdev)
{
(...)
        if (ACPI_HANDLE(&pdev->dev)) {
                ret = rfkill_gpio_acpi_probe(&pdev->dev, rfkill);
                if (ret)
                        return ret;
        } else if (&pdev->dev.of_node) {
               ret = rfkill_gpio_dt_probe(&pdev->dev, rfkill);
               if (ret)
                       return ret;
        } else if (pdata) {
                rfkill->name = pdata->name;
                rfkill->type = pdata->type;
        } else {
                return -ENODEV;
        }
}

Whopee-do. The semantic differences are not so subtle. In
one case the type is defined in the driver itself by ACPI's match
data, in the DT case it is explicitly provided in a node in the DT
itself. DT can also explicitly name the rfkill, whereas ACPI will
just use the device name.

What should we do? How will the interface look? I mean for real.

This is the discussion we need to have. Admittedly I do not see anything
clean enough :-(

And this is a DEAD SIMPLE example.

And even if there can be something clean and nice in the probe path,
we still have this:

#ifdef CONFIG_ACPI
static const struct acpi_device_id rfkill_acpi_match[] = {
        { "BCM2E1A", RFKILL_TYPE_BLUETOOTH },
        { "BCM2E39", RFKILL_TYPE_BLUETOOTH },
        { "BCM2E3D", RFKILL_TYPE_BLUETOOTH },
        { "BCM4752", RFKILL_TYPE_GPS },
        { "LNV4752", RFKILL_TYPE_GPS },
        { },
};
#endif
#ifdef CONFIG_OF
static const struct of_device_id rfkill_of_match[] = {
       { .compatible = "rfkill-gpio", },
       {},
};
#endif
(...)
                .acpi_match_table = ACPI_PTR(rfkill_acpi_match),
                .of_match_table = of_match_ptr(rfkill_of_match),
(...)

This stuff we don't even talk about unifiing right?

Yours,
Linus Walleij

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

[Rafael J. Wysocki]

On Monday, May 26, 2014 11:19:26 PM Linus Walleij wrote:
> On Mon, May 19, 2014 at 1:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Saturday, May 17, 2014 02:24:23 PM Mark Brown wrote:
> 
> >> That's much less invasive than making new APIs.
> >
> > But for drivers that call of_get_something() directly I don't see any other
> > sensible way forward.  Otherwise each of them will need to do something like
> >
> > if (dev->of_node)
> >         use of_get_X()
> > else if (ACPI_COMPANION(dev))
> >         use acpi_get_X()
> > else
> >         use black magic
> 
> So there is currently net/rfkill/rfkill-gpio.c,
> and there is a patch to add device tree support out there:
> http://marc.info/?l=devicetree&m=139754665715639&w=2
> 
> And after that it looks like that:
> 
> static int rfkill_gpio_acpi_probe(struct device *dev,
>                                   struct rfkill_gpio_data *rfkill)
> {
>         const struct acpi_device_id *id;
> 
>         id = acpi_match_device(dev->driver->acpi_match_table, dev);
>         if (!id)
>                 return -ENODEV;
> 
>         rfkill->name = dev_name(dev);
>         rfkill->type = (unsigned)id->driver_data;
> 
>         return 0;
> }
> 
> static int rfkill_gpio_dt_probe(struct device *dev, struct
> rfkill_gpio_data *rfkill)
> {
>         struct device_node * np = dev->of_node;
> 
>         rfkill->name = np->name;
>         of_property_read_string(np, "rfkill-name", &rfkill->name);
>         of_property_read_u32(np, "rfkill-type", &rfkill->type);
> 
>         return 0;
> }
> 
> static int rfkill_gpio_probe(struct platform_device *pdev)
> {
> (...)
>         if (ACPI_HANDLE(&pdev->dev)) {
>                 ret = rfkill_gpio_acpi_probe(&pdev->dev, rfkill);
>                 if (ret)
>                         return ret;
>         } else if (&pdev->dev.of_node) {
>                ret = rfkill_gpio_dt_probe(&pdev->dev, rfkill);
>                if (ret)
>                        return ret;
>         } else if (pdata) {
>                 rfkill->name = pdata->name;
>                 rfkill->type = pdata->type;
>         } else {
>                 return -ENODEV;
>         }
> }
> 
> Whopee-do. The semantic differences are not so subtle. In
> one case the type is defined in the driver itself by ACPI's match
> data, in the DT case it is explicitly provided in a node in the DT
> itself. DT can also explicitly name the rfkill, whereas ACPI will
> just use the device name.
> 
> What should we do? How will the interface look? I mean for real.

This is talking about *current* ACPI, which may be different from future
ACPI (where I mean 5.1).  And future ACPI may be able to do the same thing
as DT does.  So why don't we get back to that when ACPI 5.1 is out
(which should be some time in the summer)?

> This is the discussion we need to have. Admittedly I do not see anything
> clean enough :-(
> 
> And this is a DEAD SIMPLE example.
> 
> And even if there can be something clean and nice in the probe path,
> we still have this:
> 
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id rfkill_acpi_match[] = {
>         { "BCM2E1A", RFKILL_TYPE_BLUETOOTH },
>         { "BCM2E39", RFKILL_TYPE_BLUETOOTH },
>         { "BCM2E3D", RFKILL_TYPE_BLUETOOTH },
>         { "BCM4752", RFKILL_TYPE_GPS },
>         { "LNV4752", RFKILL_TYPE_GPS },
>         { },
> };
> #endif
> #ifdef CONFIG_OF
> static const struct of_device_id rfkill_of_match[] = {
>        { .compatible = "rfkill-gpio", },
>        {},
> };
> #endif
> (...)
>                 .acpi_match_table = ACPI_PTR(rfkill_acpi_match),
>                 .of_match_table = of_match_ptr(rfkill_of_match),
> (...)
> 
> This stuff we don't even talk about unifiing right?

We haven't been talking about that so far.

Rafael

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

[Olof Johansson]

On Tue, May 13, 2014 at 03:08:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 13:11:48 Mark Brown wrote:
> > On Tue, May 13, 2014 at 09:34:35AM +0200, Arnd Bergmann wrote:
> > > On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > > > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> > 
> > > > > Aside from the whole question of people bothering to pay attention to
> > > > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > > > ACPI have quite different models for what should be handled where - FDT
> > > > > is pure data and expects the kernel to do everything while ACPI expects
> > > > > to be used with active firmware.
> > 
> > > > While in practice ACPI is used on systems with active firmware usually, 
> > > > there's no expectation like this in ACPI itself in principle.
> > 
> > > Right. Open Firmware already has multiple ways of running code from the
> > > firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> > > but we intentionally chose to not allow them for embedded systems with
> > > the FDT subset.
> > 
> > I wouldn't say they're used all the time these days - the platforms with
> > runtime OF aren't terribly active any more and don't have much overlap
> > with other systems.
> 
> I'm not following PowerPC closely any more. It seems that powernv actually
> has rtas disabled in the defconfig, but still supports it.
> So it's basically down to pseries now, which of course is still an
> important platform. You are definitely right that it doesn't have much
> overlap with anything else.
> 
> powermac, maple, cell, and chrp can probably all be considered dead now.
> 
> > > It should be entirely possible and reasonable to do the same thing for
> > > ACPI on embedded systems. I believe this is what SFI attempted to
> > > do, but that seems to have been discarded for some reason.
> > 
> > SFI didn't provide any way of giving data to devices other than
> > registering them which meant that it ended up with the pain of firmware
> > based device registration requring firmware updates to get the device
> > present being combined with the need for board files to actually get the
> > devices to do anything useful.  On the bright side this got around the
> > fact that in my experience the firmware was frequently not modifiable by
> > people directly working on Linux.
> 
> I see.
> 
> > This might be another issue for the model where we treat ACPI as DT.
> > One of the things that makes the DT model workable in the embedded case
> > is that most of the time as far as the rest of the system is concerned
> > the DT is essentially part of the kernel - it's built from the same tree
> > and so on.  If ACPI goes the same way for embedded systems that'd work
> > just as well but that's obviously not how ACPI has historically been
> > done and if systems end up being built like they have been that might
> > not make people happy.  One of the things that active firmware is doing
> > is decoupling the firmware from the kernel which is a real and useful
> > benefit in many embedded situations, otherwise you just end up either
> > doing board quirks or just hacking things to be system specific in code.
> > 
> > There's also the possibility that the driver is going to have to figure
> > out at runtime if it's on a system with active ACPI or a system with
> > passsive ACPI, though I expect we can just do something like check what
> > properties are there for that assuming people don't end up doing
> > mix'n'match type things.  People are interested in ACPI for embedded
> > cases outside of x86 to a large extent so that they don't have to deal
> > with two different firmware interfaces if they also work on the server
> > cases.
> 
> To be clear, I was only talking about embedded x86 above, there is
> no reason to introduce ACPI on any new architecture really.
> 
> While we will likely get ACPI on ARM64 in the future, I definitely don't
> want to have two incompatible ACPI implementations, especially for the
> same chip. While AMD recently announced they are also going after
> embedded markets with their ARM64 products, they should either
> just use DT in that case, or they should use the same firmware they
> have on their servers.

This is quickly veering off of topic, however:

I'd be really interested to hear what AMD are planning w.r.t. realistic
software support (i.e. not the hype from the ACPI marketing
machine). According to their announcement they clearly are aiming the
chipset at a range of markets, including those who need aggressive power
management (mobile, embedded). It's not obvious to me that they'll be able to
fit that in with the SBSA-style ACPI platform in a clean way.


-Olof

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

[Darren Vincent Hart]

On Tue, 2014-05-13 at 13:11 +0100, Mark Brown wrote:
> On Tue, May 13, 2014 at 09:34:35AM +0200, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:
> 
> > > > Aside from the whole question of people bothering to pay attention to
> > > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > > ACPI have quite different models for what should be handled where - FDT
> > > > is pure data and expects the kernel to do everything while ACPI expects
> > > > to be used with active firmware.
> 
> > > While in practice ACPI is used on systems with active firmware usually, 
> > > there's no expectation like this in ACPI itself in principle.
> 
> > Right. Open Firmware already has multiple ways of running code from the
> > firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> > but we intentionally chose to not allow them for embedded systems with
> > the FDT subset.
> 
> I wouldn't say they're used all the time these days - the platforms with
> runtime OF aren't terribly active any more and don't have much overlap
> with other systems.
> 
> > It should be entirely possible and reasonable to do the same thing for
> > ACPI on embedded systems. I believe this is what SFI attempted to
> > do, but that seems to have been discarded for some reason.
> 
> SFI didn't provide any way of giving data to devices other than
> registering them which meant that it ended up with the pain of firmware
> based device registration requring firmware updates to get the device
> present being combined with the need for board files to actually get the
> devices to do anything useful.  On the bright side this got around the
> fact that in my experience the firmware was frequently not modifiable by
> people directly working on Linux.
> 
> This might be another issue for the model where we treat ACPI as DT.
> One of the things that makes the DT model workable in the embedded case
> is that most of the time as far as the rest of the system is concerned
> the DT is essentially part of the kernel - it's built from the same tree
> and so on.  If ACPI goes the same way for embedded systems that'd work
> just as well but that's obviously not how ACPI has historically been
> done and if systems end up being built like they have been that might
> not make people happy.

Which people do you mean?

It is clear that for ACPI to be a viable mechanism in the embedded
space, we need the ability to add additional device descriptions beyond
what ships in the firmware on the board. We could stick with the old
monolithic model by enabling people to easily rebuild the firmware
(something I personally think we need to do anyway), but just because
people *can* rebuild the firmware, doesn't mean they are going to want
to! Alternatively, tooling could be provided to modify these tables
without technically rebuilding the firmware image in the traditional
sense - and similar tooling exists in industry today.

The other option of course is the FDT approach where we enable the
ability to provide an ACPI SSDT as an independent item from the board
firmware. This could be similar to what we do today for wholesale
replacement of the tables, but instead load and rescan the ACPI
namespace based on the newly provided data.

While some folks are exploring using DT on Intel platforms, I personally
think it makes more sense to incrementally improve ACPI to provide the
necessary flexibility (it really doesn't need much) than to throw it all
out and have to tackle all the issues that raises. For one thing, it
maintains the integrity of the platform and all the compatibility, etc.
that it brings you.

My intersection with this stuff is my work on the MinnowBoard program,
which is a divergence from the static motherboard model typical to Intel
designs where expansion is only done over enumerable self-describing
buses, to what I call a "dynamic base-board" (is there a real industry
term for this?) where we expose the other buses and GPIOs people have to
expect in developer boards like these. Response to the MinnowBoard-Max
suggests to me that we're on the right track here.

> One of the things that active firmware is doing
> is decoupling the firmware from the kernel which is a real and useful
> benefit in many embedded situations, otherwise you just end up either
> doing board quirks or just hacking things to be system specific in code.
> 
> There's also the possibility that the driver is going to have to figure
> out at runtime if it's on a system with active ACPI or a system with
> passsive ACPI, though I expect we can just do something like check what
> properties are there for that assuming people don't end up doing
> mix'n'match type things.  People are interested in ACPI for embedded
> cases outside of x86 to a large extent so that they don't have to deal
> with two different firmware interfaces if they also work on the server
> cases.

We can determine which method is used based on which device struct
pointers are populated.

> I'm worried that there's more to the model for using a given firmware
> interface than just the in kernel API but we're only thinking about
> what's convenient in kernel here.

>From the ACPI side of things at least, we've definitely been thinking
more broadly than that. In fact the kernel interface, like the one Arnd
mentioned which happens to be the same thing Rafael and I have
suggested, is intended to solve a problem we are seeing in industry
where we can't reuse drivers on ACPI platforms without a lot of driver
development. The new API is intended to minimize that effort.

Other non-kernel considerations include the format of the changes to the
ACPI specification being flexible enough to allow reuse of the existing
DT bindings/schemas and keeping the definition of these schemas in the
hands of the hardware vendors.

There's more... but rather than just dump here... could you elaborate on
your concerns here? Are there some specific things we might be
overlooking - would like to hear your thoughts as I agree, this is
bigger than the kernel changes.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3692 bytes --]

On Fri, May 16, 2014 at 08:57:59PM -0700, Darren Vincent Hart wrote:
> On Tue, 2014-05-13 at 13:11 +0100, Mark Brown wrote:

> > and so on.  If ACPI goes the same way for embedded systems that'd work
> > just as well but that's obviously not how ACPI has historically been
> > done and if systems end up being built like they have been that might
> > not make people happy.

> Which people do you mean?

Systems integrators in the embedded space, I'm mostly thinking from the
perspective of people who make consumer electronics but the issues apply
in other embedded sitautions.

> It is clear that for ACPI to be a viable mechanism in the embedded
> space, we need the ability to add additional device descriptions beyond
> what ships in the firmware on the board. We could stick with the old
> monolithic model by enabling people to easily rebuild the firmware
> (something I personally think we need to do anyway), but just because
> people *can* rebuild the firmware, doesn't mean they are going to want
> to! Alternatively, tooling could be provided to modify these tables

Right, and there are frequently process issues which make it difficult
to do this - in larger organisations the firmware may well be maintained
by a different team to the kernel team which can make getting changes
done harder for non-technical resons.

> > There's also the possibility that the driver is going to have to figure
> > out at runtime if it's on a system with active ACPI or a system with
> > passsive ACPI, though I expect we can just do something like check what
> > properties are there for that assuming people don't end up doing
> > mix'n'match type things.  People are interested in ACPI for embedded
> > cases outside of x86 to a large extent so that they don't have to deal
> > with two different firmware interfaces if they also work on the server
> > cases.

> We can determine which method is used based on which device struct
> pointers are populated.

Not at present - we can tell if we are running on ACPI but that's not
the issue.

> > I'm worried that there's more to the model for using a given firmware
> > interface than just the in kernel API but we're only thinking about
> > what's convenient in kernel here.

> From the ACPI side of things at least, we've definitely been thinking
> more broadly than that. In fact the kernel interface, like the one Arnd
> mentioned which happens to be the same thing Rafael and I have
> suggested, is intended to solve a problem we are seeing in industry
> where we can't reuse drivers on ACPI platforms without a lot of driver
> development. The new API is intended to minimize that effort.

I'm surprised it's a *lot* of development TBH - or rather that the hard
bit is not mostly putting new back ends on existing APIs.

> There's more... but rather than just dump here... could you elaborate on
> your concerns here? Are there some specific things we might be
> overlooking - would like to hear your thoughts as I agree, this is
> bigger than the kernel changes.

The most immediate thing is if the tooling around ACPI based systems is
going to be able to support people providing configuration to the system
without undule pain, otherwise it becomes more likely that people won't
use the new infrastructure.

The thing I'm less clear on is if there are going to be problems down
the line with people trying to do things that they currently do with
ACPI like hide details of new board versions causing conflicts with code
that assumes the firmware is just providing data.  This may end up being
nothing to worry about, hopefully it is, but right now as a driver
author I'd expect to approach things differently with a different
firmware.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Darren Vincent Hart]

On Sat, 2014-05-17 at 14:09 +0100, Mark Brown wrote:
> On Fri, May 16, 2014 at 08:57:59PM -0700, Darren Vincent Hart wrote:
> > On Tue, 2014-05-13 at 13:11 +0100, Mark Brown wrote:
> 
> > > and so on.  If ACPI goes the same way for embedded systems that'd work
> > > just as well but that's obviously not how ACPI has historically been
> > > done and if systems end up being built like they have been that might
> > > not make people happy.
> 
> > Which people do you mean?
> 
> Systems integrators in the embedded space, I'm mostly thinking from the
> perspective of people who make consumer electronics but the issues apply
> in other embedded sitautions.


OK, good. For the record, I'm focused primarily on two groups:

1) Systems integrators as you describe
2) Individual innovators (People developing stuff with MinnowBoard-Max)


> > It is clear that for ACPI to be a viable mechanism in the embedded
> > space, we need the ability to add additional device descriptions beyond
> > what ships in the firmware on the board. We could stick with the old
> > monolithic model by enabling people to easily rebuild the firmware
> > (something I personally think we need to do anyway), but just because
> > people *can* rebuild the firmware, doesn't mean they are going to want
> > to! Alternatively, tooling could be provided to modify these tables
> 
> Right, and there are frequently process issues which make it difficult
> to do this - in larger organisations the firmware may well be maintained
> by a different team to the kernel team which can make getting changes
> done harder for non-technical resons.


Absolutely. In other situations, the product is an integration of known
working components, and the expectation is that there is no firmware or
even kernel development to be done in the way we think of it.
Special-purpose tooling exists to handle the board-file type integration
- this can be implemented at various layers in the stack, or a
combinatino of them: binary firmware manipulation, ASL, config file
driver parameterization, static kernel board-file generation, etc.


> > > There's also the possibility that the driver is going to have to figure
> > > out at runtime if it's on a system with active ACPI or a system with
> > > passsive ACPI, though I expect we can just do something like check what
> > > properties are there for that assuming people don't end up doing
> > > mix'n'match type things.  People are interested in ACPI for embedded
> > > cases outside of x86 to a large extent so that they don't have to deal
> > > with two different firmware interfaces if they also work on the server
> > > cases.
> 
> > We can determine which method is used based on which device struct
> > pointers are populated.
> 
> Not at present - we can tell if we are running on ACPI but that's not
> the issue.


I misread your statement above, specifically about distinguishing
between passive and active ACPI. This is a concept you've made several
times throughout this thread, and I don't think I'm seeing the broader
point you're trying to make.

As Rafael has pointed out, a lot of the executable methods are handled
at the ACPICA layer and are not dealt with at the individual driver
level.

Also worth mentioning is that any ACPI name could be implemented as a
method, and the OS won't know. For example:

Name(OBJ1, Package (2) { "foo", "bar" })

Could also be implemented as:

Method(OBJ1){
  if (\BAZ){
    Return(Package (2) { "foo", "baz" })
  }
  Return(Package (2) { "foo", "bar" })
}

Can you elaborate on the issues you're trying to call out regarding
active versus passive ACPI?


> 
> > > I'm worried that there's more to the model for using a given firmware
> > > interface than just the in kernel API but we're only thinking about
> > > what's convenient in kernel here.
> 
> > From the ACPI side of things at least, we've definitely been thinking
> > more broadly than that. In fact the kernel interface, like the one Arnd
> > mentioned which happens to be the same thing Rafael and I have
> > suggested, is intended to solve a problem we are seeing in industry
> > where we can't reuse drivers on ACPI platforms without a lot of driver
> > development. The new API is intended to minimize that effort.
> 
> I'm surprised it's a *lot* of development TBH - or rather that the hard
> bit is not mostly putting new back ends on existing APIs.


At the individual driver level, it is trivial. However, there are
thousands of drivers, and as we discussed above, many of the integrators
of these things don't do any driver development. Making those drivers
available to ACPI based platforms then becomes a large task in
aggregate.

The property abstraction layer being discussed is aimed at making that
aggregate task as small as possible - partly via new backends as you
describe.


> > There's more... but rather than just dump here... could you elaborate on
> > your concerns here? Are there some specific things we might be
> > overlooking - would like to hear your thoughts as I agree, this is
> > bigger than the kernel changes.
> 
> The most immediate thing is if the tooling around ACPI based systems is
> going to be able to support people providing configuration to the system
> without undule pain, otherwise it becomes more likely that people won't
> use the new infrastructure.


Agreed. I believe the components here include clear documentation on
creating ACPI equivalents of DT bindings. Or, for new devices, a higher
level properties schema that can be implemented as an FDT or in ASL.
Second, we will need a mechanism for handling SSDT additions independent
from that provided by the board firmware.


> The thing I'm less clear on is if there are going to be problems down
> the line with people trying to do things that they currently do with
> ACPI like hide details of new board versions causing conflicts with code
> that assumes the firmware is just providing data.


OK, this goes back to your concerns on active/passive ACPI I guess?

I believe our best weapon against (new) nasty firmware hacks is to
provide a flexible mechanism with excellent documentation and examples
that make it easier to follow them than to contrive some gross
workaround.

In the past, this is something that ACPI has been lacking. When I first
started looking into this, I kept asking for a Manual, and all I would
get was a Specification.

As part of the ACPI properties update to the specification, we are also
preparing independent documentation for how to use it.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

On Fri, May 16, 2014 at 11:52:22PM -0700, Darren Vincent Hart wrote:
> On Sat, 2014-05-17 at 14:09 +0100, Mark Brown wrote:
> > On Fri, May 16, 2014 at 08:57:59PM -0700, Darren Vincent Hart wrote:
> > > On Tue, 2014-05-13 at 13:11 +0100, Mark Brown wrote:

> Can you elaborate on the issues you're trying to call out regarding
> active versus passive ACPI?

As far as I can tell a big part of what people see themselves getting
from ACPI is the ability to use the executable methods to handle
hardware updates without software updates, including things you can't do
by just changing the data you supply to the system.  Device drivers can
do things to play nicely with this, such as assuming that configuration
in the device when they start is sane and should be preserved unless
they know what they're doing, but in a data only model it's generally
safer to just discard any such configuration and get the hardware into a
known good state by resetting it or similar (this is the most common
pattern that has a practical impact which I'm aware of).  Things like
configuring the features on a new variant of a device for example, or
turning on a previously unsupported feature.

In the embedded case it's generally relatively straightforward to add a
new property, add the code to handle it and rebuild the world.  If
updating the OS isn't an option that gets a lot more tricky and doing
things via firmware methods more sensible.

> At the individual driver level, it is trivial. However, there are
> thousands of drivers, and as we discussed above, many of the integrators
> of these things don't do any driver development. Making those drivers
> available to ACPI based platforms then becomes a large task in
> aggregate.

> The property abstraction layer being discussed is aimed at making that
> aggregate task as small as possible - partly via new backends as you
> describe.

OK, but then can't ACPI just present via the OF APIs rather than
requiring us to go and search and replace all the property parsing code?

> > The thing I'm less clear on is if there are going to be problems down
> > the line with people trying to do things that they currently do with
> > ACPI like hide details of new board versions causing conflicts with code
> > that assumes the firmware is just providing data.

> OK, this goes back to your concerns on active/passive ACPI I guess?

Yes.

> I believe our best weapon against (new) nasty firmware hacks is to
> provide a flexible mechanism with excellent documentation and examples
> that make it easier to follow them than to contrive some gross
> workaround.

> In the past, this is something that ACPI has been lacking. When I first
> started looking into this, I kept asking for a Manual, and all I would
> get was a Specification.

> As part of the ACPI properties update to the specification, we are also
> preparing independent documentation for how to use it.

That should help, though obviously documentation is not always consulted
with the frequency and dilligency that one may desire (and to be fair
it's not always very discoverable).  However a part of my worry is that
given what at least some people are trying to achieve the things they
get up to aren't that tasteless, they just happen to have different aims
and use cases to the embedded one.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Saturday 03 May 2014 02:05:21 Rafael J. Wysocki wrote:
> On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:

> > .. I'm probably missing names but they're bound to reply to this email
> > anyway with opinions.
> > 
> > 
> > Some of the ideas I have heard discussed are:
> > * Adding a new common API for resource management which will have
> > backends for ACPI or DT depending on platform
> 
> I would like to do this, personally, because I believe that drivers
> should not need to add support for any particular firmware interfaces
> directly (except for listing matching device IDs).

We already have this for some things (IRQs, MMIO registers, ...), and
it's probably a good idea to add more. Whether or not we want it for
everything that can be described is open for debate.

Adding it for bool/integer/string properties once they are implemented
in ACPI should be straightforward.

> > * Adding ACPI and DT probing to drivers that lack on or the other
> > today (giving them a total of three probe methods: platform_device,
> > DT, ACPI).
> 
> But that is not about platform devices only.  There also are SPI and I2C
> devices (and likely other bus types too) that require similar kind of
> information from the platform firmware (e.g. are not natively enumerable).
> 
> > * 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

> > All solutions above have trade-offs, and neither is an obvious choice.
> > We could likely spend between now and KS arguing this every day on the
> > lists if we wanted to. Getting the people into the same room for a
> > couple of hours is likely to be a much better way to resolve it.
> 
> 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.

	Arnd

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

[Catalin Marinas]

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).

> > 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 ;)).

-- 
Catalin

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

[Olof Johansson]

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.

> > > 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.


-Olof

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

[Guenter Roeck]

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.
>
>>>> 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.

Guenter

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

[Rafael J. Wysocki]

Hi,

On Sunday, May 04, 2014 10:27:59 AM Guenter Roeck wrote:
> On 05/04/2014 10:18 AM, Olof Johansson wrote:

[cut]

> > 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 actually wonder how you are going to handle things like references from
a DT overlay to ACPI device objects in the namespace (like various things
controllers etc).

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Pantelis Antoniou]

Hi Rafael,

On May 4, 2014, at 3:02 PM, Rafael J. Wysocki wrote:

> Hi,
> 
> On Sunday, May 04, 2014 10:27:59 AM Guenter Roeck wrote:
>> On 05/04/2014 10:18 AM, Olof Johansson wrote:
> 
> [cut]
> 
>>> 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 actually wonder how you are going to handle things like references from
> a DT overlay to ACPI device objects in the namespace (like various things
> controllers etc).
> 

At the moment we got dynamic PCI DT node creation; i.e. the PCI bus(es) is probed
and the platform's pci bios creates DT nodes; PCI nodes that already defined do not
get created from scratch, rather DT properties are appended to them.

It is not a whole-sale conversion (yet), but it seems to work find as a target for
DT overlays.

All this is on vanilla x86-64 btw, with very small fixes to get booted using an DT blob.

So far we didn't have to deal with ACPI device objects; perhaps it will be required
for when we tackle pure platform devices. But TBH it doesn't seem that difficult.

> Thanks!
> 
> -- 
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

Regards

-- Pantelis

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

[Rafael J. Wysocki]

On Sunday, May 04, 2014 07:44:27 PM Pantelis Antoniou wrote:
> Hi Rafael,
> 
> On May 4, 2014, at 3:02 PM, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > On Sunday, May 04, 2014 10:27:59 AM Guenter Roeck wrote:
> >> On 05/04/2014 10:18 AM, Olof Johansson wrote:
> > 
> > [cut]
> > 
> >>> 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 actually wonder how you are going to handle things like references from
> > a DT overlay to ACPI device objects in the namespace (like various things
> > controllers etc).
> > 
> 
> At the moment we got dynamic PCI DT node creation; i.e. the PCI bus(es) is probed
> and the platform's pci bios creates DT nodes; PCI nodes that already defined do not
> get created from scratch, rather DT properties are appended to them.

Well, what you're describing is not a DT overlay on top of an otherwise ACPI-based
system.  It is DT support for PCI.

> It is not a whole-sale conversion (yet), but it seems to work find as a target for
> DT overlays.
> 
> All this is on vanilla x86-64 btw, with very small fixes to get booted using an DT blob.
> 
> So far we didn't have to deal with ACPI device objects; perhaps it will be required
> for when we tackle pure platform devices. But TBH it doesn't seem that difficult.

In the context of DT-over-ACPI overlays it doesn't matter what devices you're
considering.  The problem is the translation of phandles into ACPI device object
pointers (paths) or the other way around.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Pantelis Antoniou]

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

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

[Guenter Roeck]

Hi Pantelis,

On 05/04/2014 07:52 PM, Pantelis Antoniou wrote:
>
> 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.
>

<soapbox>

Intel marketing is like BMW marketing ... Intel doesn't sell the CPUs I would
buy (like affordable 6- or 8-core Haswell CPUs), just like BMW doesn't sell
the cars I would buy (like the 50 mpg 5-series they only sell in Germany).

</soapbox>

Cheers,
Guenter

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

[Pantelis Antoniou]

On May 4, 2014, at 9:21 PM, Guenter Roeck wrote:

> Hi Pantelis,
> 
> On 05/04/2014 07:52 PM, Pantelis Antoniou wrote:
>> 
>> 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.
>> 
> 
> <soapbox>
> 
> Intel marketing is like BMW marketing ... Intel doesn't sell the CPUs I would
> buy (like affordable 6- or 8-core Haswell CPUs), just like BMW doesn't sell
> the cars I would buy (like the 50 mpg 5-series they only sell in Germany).
> 
> </soapbox>
> 

It's not easy working on BMW stuff, let me tell you stories :)

> Cheers,
> Guenter
> 
> 

Regards

-- Pantelis

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

[Rafael J. Wysocki]

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.

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

[Benjamin Herrenschmidt]

On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
> 
> 
> But we have such quirks for some bus types already, like PCI and PNP.

And they suck big time. They duplicate definitions from the driver,
they get missed at grep time, they bit rot, etc...

There are a few cases where that's justified simply because the driver
can be a module but the quirk needs to run early and always, but mostly
these quirks are about working around HW bugs that would otherwise cause
the system to misbehave even in absence of the driver.

For example, bad class code in bridges, BAR issues, etc...

Generally speaking though, quirks like that are a bad idea and in this
case, totally unjustified since the code performing whatever translation
is necessary (or interpretation) is entirely specific to the driver
anyway.

Also if the bindings evolve, you just created a 3rd way dependency.
Instead of just having to deal with DT/ACPI binding version vs. driver
version, we now have to also handle quirk versioning.


Cheers,
Ben.
 

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

[Rafael J. Wysocki]

On Monday, May 05, 2014 06:43:55 PM Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
> > 
> > 
> > But we have such quirks for some bus types already, like PCI and PNP.
> 
> And they suck big time. They duplicate definitions from the driver,
> they get missed at grep time, they bit rot, etc...
> 
> There are a few cases where that's justified simply because the driver
> can be a module but the quirk needs to run early and always, but mostly
> these quirks are about working around HW bugs that would otherwise cause
> the system to misbehave even in absence of the driver.
> 
> For example, bad class code in bridges, BAR issues, etc...
> 
> Generally speaking though, quirks like that are a bad idea and in this
> case, totally unjustified since the code performing whatever translation
> is necessary (or interpretation) is entirely specific to the driver
> anyway.

The interpretation - yes, the translation - not necessarily.  By putting
the translation part into drivers we'll duplicate a lot of code used for
that.  In my opinion there needs to be a layer doing the translation
automatically.

> Also if the bindings evolve, you just created a 3rd way dependency.
> Instead of just having to deal with DT/ACPI binding version vs. driver
> version, we now have to also handle quirk versioning.

The bindings should not depend on the translation.  In the end the bindings
are what the driver will ask for.  If it asks for an integer property called
"fred", for example, it should get that property from the upper layer
regardless of the firmware interface used on that platform (if the property
is there, of course).

Otherwise every driver has to know about all of the possible firmware interfaces
that can be used with it and may I call that suboptimal?  With two of them on
the table it would be workable I guess, but what if someone invents a *third*
firmware interface to use with device drivers?  Are we going to change all of
them, then?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Benjamin Herrenschmidt]

On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> The interpretation - yes, the translation - not necessarily.  By putting
> the translation part into drivers we'll duplicate a lot of code used for
> that.  In my opinion there needs to be a layer doing the translation
> automatically.

I'm afraid I don't understand. How can you do the translation
automatically if you have fundamentally different representation of
device-specific concepts ?

> > Also if the bindings evolve, you just created a 3rd way dependency.
> > Instead of just having to deal with DT/ACPI binding version vs. driver
> > version, we now have to also handle quirk versioning.
> 
> The bindings should not depend on the translation.  In the end the bindings
> are what the driver will ask for.  If it asks for an integer property called
> "fred", for example, it should get that property from the upper layer
> regardless of the firmware interface used on that platform (if the property
> is there, of course).

Except that the DT will have something like ibm,fred as a 32-bit cell
and ACPI will have it named subtly differently in a different format and
thing will not be consistent accross devices, bindings or even FW
variants.

> Otherwise every driver has to know about all of the possible firmware interfaces
> that can be used with it and may I call that suboptimal?

Well as I said, it depends what we are talking about here. For well
defined resources such as MMIO regions, interrupts, and we might
possibly manage to classify things like GPIO, etc... in that bucket, yes
we can most definitely find a common ground.

However in that case it's less likely to be a "translation" from one
representation to another than it is to be the core interpreting both
representation and turning them into something linux specific such as
struct resource or higher level representations of linkage between
subsystems.

But then there's everything else ... The various device specific
properties which *are* going to be represented differently left right
and center, the buggy firmwares with bad ACPI tables or bad device-tree,
the representation for some new linkage to a subsytem that doesn't have
stable bindings yet, etc...

In the end, it's an evolutionary process. That stuff starts in the
drivers. If enough drivers do the same thing for a given category of
"properties" (in the generic meaning of the word, not specifically a
device-tree prop), then we can move that part into the core, either in
the form of helpers, or pre-parsing into some new type of struct
resource or whatever else match.

It's time and experience that will tell us what works. There is only so
much we can "design" for when what we're going to deal with is vendor
firwmare mostly developed behind closed doors.

>   With two of them on
> the table it would be workable I guess, but what if someone invents a *third*
> firmware interface to use with device drivers?  Are we going to change all of
> them, then?

Yes. Though the odds of that happening are fairly low at this point.

Ben.

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

[Rafael J. Wysocki]

On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > The interpretation - yes, the translation - not necessarily.  By putting
> > the translation part into drivers we'll duplicate a lot of code used for
> > that.  In my opinion there needs to be a layer doing the translation
> > automatically.
> 
> I'm afraid I don't understand. How can you do the translation
> automatically if you have fundamentally different representation of
> device-specific concepts ?

I'm not entirely sure how fundamentally different it is to be honest, but in
any case I'm talking about the situation in which the hardware is the same
and the driver is the same, only the firmware interface is different.  In
that case either the firmware supplies the information the driver needs, or
it doesn't (and as long as the information is supplied, the format doesn't
really matter, because it only is a matter of translation).

Now, the problem, as I see it, is that in many cases ACPI actually doesn't
supply information that is expected by drivers.  There may be two reasons
for that.

The first reason is when ACPI provides methods to be used for manipulating
things that aren't explicitly exposed.  I *think* this only is the case in
the power management area, where clocks and voltage regulators are often
hidden behind ACPI power resources and methods to switch device power states.
In this particular case, however, drivers are not supposed to execute those
methods and operate ACPI power resources directly anyway (there are other
layers of code taking care of that), so they simply need not touch things
that cannot be found.

The second reason is when ACPI doesn't have means to provide the expected
information to drivers and *that* is a real problem in my view.  To address
it, we might try to extend the ACPI spec to cover all of the things that
are covered by driver bindings for Device Trees, but that is impractical
for two reasons.  First, it would be trying to open a door that's already
opened.  Second, it wouldn't cover future additions to (or generally future
modifications of) those bindings.  Thus the only viable approach is to use
those bindings directly and put them into the ACPI tables (or generally into
the ACPI namespace) somehow.

Of course, there are obstacles to that.  First, ACPI already has its own ways
to describe things like GPIOs, I2C/SPI connections etc. which are not
compatible with the existing DT bindings.  That may be addressed by adding
extra "bindings" to map the information that ACPI already provides into what
drivers expect and adding some extra library code to process that.  Second,
vendors may not add the DT-style information to the ACPI tables they ship
(for example, because the machines in question ship with Windows and the
vendor doesn't care about Linux on them), which may be addressed by allowing
ACPI definition block overlays to be used to provide that information and
add it to the ACPI namespace during initialization.  In principle, such
overlays may be supplied along with the kernel and loaded during boot (kind
of like dts files).

Bottom line: I'd like to avoid modifying drivers that use the of_ interface
today if possible.  Instead, I'd prefer to modify the firmware layer so that
those drivers can get what they ask for regardless of what firmware interface
the platform is using.

> > > Also if the bindings evolve, you just created a 3rd way dependency.
> > > Instead of just having to deal with DT/ACPI binding version vs. driver
> > > version, we now have to also handle quirk versioning.
> > 
> > The bindings should not depend on the translation.  In the end the bindings
> > are what the driver will ask for.  If it asks for an integer property called
> > "fred", for example, it should get that property from the upper layer
> > regardless of the firmware interface used on that platform (if the property
> > is there, of course).
> 
> Except that the DT will have something like ibm,fred as a 32-bit cell
> and ACPI will have it named subtly differently in a different format and
> thing will not be consistent accross devices, bindings or even FW
> variants.
> 
> > Otherwise every driver has to know about all of the possible firmware interfaces
> > that can be used with it and may I call that suboptimal?
> 
> Well as I said, it depends what we are talking about here. For well
> defined resources such as MMIO regions, interrupts, and we might
> possibly manage to classify things like GPIO, etc... in that bucket, yes
> we can most definitely find a common ground.
> 
> However in that case it's less likely to be a "translation" from one
> representation to another than it is to be the core interpreting both
> representation and turning them into something linux specific such as
> struct resource or higher level representations of linkage between
> subsystems.
> 
> But then there's everything else ... The various device specific
> properties which *are* going to be represented differently left right
> and center, the buggy firmwares with bad ACPI tables or bad device-tree,
> the representation for some new linkage to a subsytem that doesn't have
> stable bindings yet, etc...
> 
> In the end, it's an evolutionary process. That stuff starts in the
> drivers. If enough drivers do the same thing for a given category of
> "properties" (in the generic meaning of the word, not specifically a
> device-tree prop), then we can move that part into the core, either in
> the form of helpers, or pre-parsing into some new type of struct
> resource or whatever else match.
> 
> It's time and experience that will tell us what works. There is only so
> much we can "design" for when what we're going to deal with is vendor
> firwmare mostly developed behind closed doors.

I agree.  That's why I think that the firmware layer has to be able to
evolve along with everything else and the driver bindings should define
what information the firmware is expected to provide.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Arnd Bergmann]

On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > > The interpretation - yes, the translation - not necessarily.  By putting
> > > the translation part into drivers we'll duplicate a lot of code used for
> > > that.  In my opinion there needs to be a layer doing the translation
> > > automatically.
> > 
> > I'm afraid I don't understand. How can you do the translation
> > automatically if you have fundamentally different representation of
> > device-specific concepts ?
> 
> I'm not entirely sure how fundamentally different it is to be honest, but in
> any case I'm talking about the situation in which the hardware is the same
> and the driver is the same, only the firmware interface is different.  In
> that case either the firmware supplies the information the driver needs, or
> it doesn't (and as long as the information is supplied, the format doesn't
> really matter, because it only is a matter of translation).

One example for something that is fundamentally different between an
embedded system using DT and any ACPI system is how a PCI(e) host bridge
gets treated, we are currently having long discussions about this elsewhere.

With ACPI (or a server running OF for that matter), you assume that the
PCI host is operational and all buses are fully probed and then you
have methods for doing hotplugging, you just look at the device that
are already initialized by the firmware.

With embedded systems, you (in general, some steps may get skipped
in practice) go through a lot more steps:
- detect the presence of the host bridge device
- enable clocks, voltages, phys, resets, etc.
- set up inbound and outbound MMIO and PIO address translation windows
- perform a full bus scan and assign bus and device resources

We probably woulnd't go through that hassle on ACPI systems. I think
we shouldn't attempt any translation here, and keep the code completely
separate, with the common parts being handled by the PCI core as we
do today.

An example about a subsystem where translate complex information
from both DT and ACPI into a common format is the dmaengine: We can
have references to dma channels in completely incompatible ways
but still use the same dma_request_slave_channel() interface for
both. The ACPI path currently is lacking a bit (e.g. there is no
way to specify the channel name in ACPI, so the code makes
assumptions that don't hold true in general), but that's fixable.

I assume we will see more of the second kind in the future, and this
would be limited to embedded systems on both ACPI and DT, since you
shouldn't see dma slave devices on general purpose systems with
either.

> Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> today if possible.  Instead, I'd prefer to modify the firmware layer so that
> those drivers can get what they ask for regardless of what firmware interface
> the platform is using.

Looking at the most trivial example:

bool of_property_read_bool(const struct device_node *np,                                       				    const char *propname);

We should definitely be able to have an interface like this for
ACPI, but you don't have a 'struct device_node' pointer then.
We can add a new

bool dev_property_read_bool(const struct device *dev,
                            const char *propname);

that handles both, but then you have to change every driver
that is already using of_property_read_bool() and that can
get used with ACPI. An advantage of the dev_property_read_bool()
interface however is that it would also work for platform
devices that are created in platform code using
platform_device_register_full() or similar if we add a way
to define simple properties in C code. That would also simplify
a lot of drivers that use both (simple) platform_data and DT
today.

	Arnd

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

[Rafael J. Wysocki]

On Tuesday, May 06, 2014 03:35:41 PM Arnd Bergmann wrote:
> On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > > > The interpretation - yes, the translation - not necessarily.  By putting
> > > > the translation part into drivers we'll duplicate a lot of code used for
> > > > that.  In my opinion there needs to be a layer doing the translation
> > > > automatically.
> > > 
> > > I'm afraid I don't understand. How can you do the translation
> > > automatically if you have fundamentally different representation of
> > > device-specific concepts ?
> > 
> > I'm not entirely sure how fundamentally different it is to be honest, but in
> > any case I'm talking about the situation in which the hardware is the same
> > and the driver is the same, only the firmware interface is different.  In
> > that case either the firmware supplies the information the driver needs, or
> > it doesn't (and as long as the information is supplied, the format doesn't
> > really matter, because it only is a matter of translation).
> 
> One example for something that is fundamentally different between an
> embedded system using DT and any ACPI system is how a PCI(e) host bridge
> gets treated, we are currently having long discussions about this elsewhere.

Well, that's rather an extreme example. :-)

The PCI host bridge is also special, because there already is an ACPI drvier
for it, so that is not a case when we have a driver using DTs and would
like to modify it to add ACPI-specific handling.  This one is a different
problem.

> With ACPI (or a server running OF for that matter), you assume that the
> PCI host is operational and all buses are fully probed and then you
> have methods for doing hotplugging, you just look at the device that
> are already initialized by the firmware.
> 
> With embedded systems, you (in general, some steps may get skipped
> in practice) go through a lot more steps:
> - detect the presence of the host bridge device
> - enable clocks, voltages, phys, resets, etc.
> - set up inbound and outbound MMIO and PIO address translation windows
> - perform a full bus scan and assign bus and device resources
> 
> We probably woulnd't go through that hassle on ACPI systems. I think
> we shouldn't attempt any translation here, and keep the code completely
> separate, with the common parts being handled by the PCI core as we
> do today.

I agree.

> An example about a subsystem where translate complex information
> from both DT and ACPI into a common format is the dmaengine: We can
> have references to dma channels in completely incompatible ways
> but still use the same dma_request_slave_channel() interface for
> both. The ACPI path currently is lacking a bit (e.g. there is no
> way to specify the channel name in ACPI, so the code makes
> assumptions that don't hold true in general), but that's fixable.
> 
> I assume we will see more of the second kind in the future, and this
> would be limited to embedded systems on both ACPI and DT, since you
> shouldn't see dma slave devices on general purpose systems with
> either.
> 
> > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> > those drivers can get what they ask for regardless of what firmware interface
> > the platform is using.
> 
> Looking at the most trivial example:
> 
> bool of_property_read_bool(const struct device_node *np,                                       				    const char *propname);
> 
> We should definitely be able to have an interface like this for
> ACPI, but you don't have a 'struct device_node' pointer then.
> We can add a new
> 
> bool dev_property_read_bool(const struct device *dev,
>                             const char *propname);
> 
> that handles both, but then you have to change every driver
> that is already using of_property_read_bool() and that can
> get used with ACPI.

Yes, but that's not a very difficult change to make, arguably.

> An advantage of the dev_property_read_bool()
> interface however is that it would also work for platform
> devices that are created in platform code using
> platform_device_register_full() or similar if we add a way
> to define simple properties in C code. That would also simplify
> a lot of drivers that use both (simple) platform_data and DT
> today.

Yes.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Benjamin Herrenschmidt]

On Tue, 2014-05-06 at 15:35 +0200, Arnd Bergmann wrote:
> 
> With ACPI (or a server running OF for that matter), you assume that the
> PCI host is operational and all buses are fully probed and then you
> have methods for doing hotplugging, you just look at the device that
> are already initialized by the firmware.
> 
> With embedded systems, you (in general, some steps may get skipped
> in practice) go through a lot more steps:
> - detect the presence of the host bridge device
> - enable clocks, voltages, phys, resets, etc.
> - set up inbound and outbound MMIO and PIO address translation windows
> - perform a full bus scan and assign bus and device resources
> 
> We probably woulnd't go through that hassle on ACPI systems. I think
> we shouldn't attempt any translation here, and keep the code completely
> separate, with the common parts being handled by the PCI core as we
> do today.

Well, you said it "or a server running OF for that matter" ...

PCI Hotplug is a whole separate can of worms, let's not get there :-)

Even on OF machine, it's very platform specific. I don't think we can
use it as an example of something that's widely different between DT
and ACPI per-se as it's going to be widely different between everything
non-ACPI.

This is a case of ACPI-does-methods being actually somewhat useful.

Cheers,
Ben.

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

[Olof Johansson]

On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > > > The interpretation - yes, the translation - not necessarily.  By putting
> > > > the translation part into drivers we'll duplicate a lot of code used for
> > > > that.  In my opinion there needs to be a layer doing the translation
> > > > automatically.
> > > 
> > > I'm afraid I don't understand. How can you do the translation
> > > automatically if you have fundamentally different representation of
> > > device-specific concepts ?
> > 
> > I'm not entirely sure how fundamentally different it is to be honest, but in
> > any case I'm talking about the situation in which the hardware is the same
> > and the driver is the same, only the firmware interface is different.  In
> > that case either the firmware supplies the information the driver needs, or
> > it doesn't (and as long as the information is supplied, the format doesn't
> > really matter, because it only is a matter of translation).
> 
> One example for something that is fundamentally different between an
> embedded system using DT and any ACPI system is how a PCI(e) host bridge
> gets treated, we are currently having long discussions about this elsewhere.
> 
> With ACPI (or a server running OF for that matter), you assume that the
> PCI host is operational and all buses are fully probed and then you
> have methods for doing hotplugging, you just look at the device that
> are already initialized by the firmware.
> 
> With embedded systems, you (in general, some steps may get skipped
> in practice) go through a lot more steps:
> - detect the presence of the host bridge device
> - enable clocks, voltages, phys, resets, etc.
> - set up inbound and outbound MMIO and PIO address translation windows
> - perform a full bus scan and assign bus and device resources
> 
> We probably woulnd't go through that hassle on ACPI systems. I think
> we shouldn't attempt any translation here, and keep the code completely
> separate, with the common parts being handled by the PCI core as we
> do today.
> 
> An example about a subsystem where translate complex information
> from both DT and ACPI into a common format is the dmaengine: We can
> have references to dma channels in completely incompatible ways
> but still use the same dma_request_slave_channel() interface for
> both. The ACPI path currently is lacking a bit (e.g. there is no
> way to specify the channel name in ACPI, so the code makes
> assumptions that don't hold true in general), but that's fixable.
> 
> I assume we will see more of the second kind in the future, and this
> would be limited to embedded systems on both ACPI and DT, since you
> shouldn't see dma slave devices on general purpose systems with
> either.
> 
> > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> > those drivers can get what they ask for regardless of what firmware interface
> > the platform is using.
> 
> Looking at the most trivial example:
> 
> bool of_property_read_bool(const struct device_node *np,                                       				    const char *propname);
> 
> We should definitely be able to have an interface like this for
> ACPI, but you don't have a 'struct device_node' pointer then.
> We can add a new
> 
> bool dev_property_read_bool(const struct device *dev,
>                             const char *propname);

> 
> that handles both, but then you have to change every driver
> that is already using of_property_read_bool() and that can
> get used with ACPI.

It's actually not that easy in practice. There's not a one-to-one
correspondence between device tree nodes and struct devices in the
kernel. There are many bindings that use subnodes for sections of their
information, and so on.

> An advantage of the dev_property_read_bool()
> interface however is that it would also work for platform
> devices that are created in platform code using
> platform_device_register_full() or similar if we add a way
> to define simple properties in C code. That would also simplify
> a lot of drivers that use both (simple) platform_data and DT
> today.

I'm not a fan of this "grand unified abstraction layer". Driver writes are
already complaining that things are too complicated with the move to device
tree, and we're making things even more abstracted and complicated here. People
will need to peel back even more layers to figure out what's actually going on.


For the truly trivial stuff, there are some quite simple ways to handle this:

1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
   mean moving over GPIO and possibly clocks to that, and use those for lookup.

2. If Rafael's arguments are to be believed, that the translation should be
   trivial and easy to do, then we might as well reuse the structures and APIs
   that are already in the kernel. In other words, allocate a struct
   device_node, populate it with the properties from the ACPI structure, and
   attach it to the struct device. Then there's no need for any churn in the
   drivers (until they need ACPI-specific tweaks, which they will all need).


The real problem is the non-trivial stuff. There, I think there's no real
alternative than to teach the drivers about both firmware interfaces.


-Olof

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

[Rafael J. Wysocki]

On Tuesday, May 13, 2014 02:14:42 PM Olof Johansson wrote:
> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > > > > The interpretation - yes, the translation - not necessarily.  By putting
> > > > > the translation part into drivers we'll duplicate a lot of code used for
> > > > > that.  In my opinion there needs to be a layer doing the translation
> > > > > automatically.
> > > > 
> > > > I'm afraid I don't understand. How can you do the translation
> > > > automatically if you have fundamentally different representation of
> > > > device-specific concepts ?
> > > 
> > > I'm not entirely sure how fundamentally different it is to be honest, but in
> > > any case I'm talking about the situation in which the hardware is the same
> > > and the driver is the same, only the firmware interface is different.  In
> > > that case either the firmware supplies the information the driver needs, or
> > > it doesn't (and as long as the information is supplied, the format doesn't
> > > really matter, because it only is a matter of translation).
> > 
> > One example for something that is fundamentally different between an
> > embedded system using DT and any ACPI system is how a PCI(e) host bridge
> > gets treated, we are currently having long discussions about this elsewhere.
> > 
> > With ACPI (or a server running OF for that matter), you assume that the
> > PCI host is operational and all buses are fully probed and then you
> > have methods for doing hotplugging, you just look at the device that
> > are already initialized by the firmware.
> > 
> > With embedded systems, you (in general, some steps may get skipped
> > in practice) go through a lot more steps:
> > - detect the presence of the host bridge device
> > - enable clocks, voltages, phys, resets, etc.
> > - set up inbound and outbound MMIO and PIO address translation windows
> > - perform a full bus scan and assign bus and device resources
> > 
> > We probably woulnd't go through that hassle on ACPI systems. I think
> > we shouldn't attempt any translation here, and keep the code completely
> > separate, with the common parts being handled by the PCI core as we
> > do today.
> > 
> > An example about a subsystem where translate complex information
> > from both DT and ACPI into a common format is the dmaengine: We can
> > have references to dma channels in completely incompatible ways
> > but still use the same dma_request_slave_channel() interface for
> > both. The ACPI path currently is lacking a bit (e.g. there is no
> > way to specify the channel name in ACPI, so the code makes
> > assumptions that don't hold true in general), but that's fixable.
> > 
> > I assume we will see more of the second kind in the future, and this
> > would be limited to embedded systems on both ACPI and DT, since you
> > shouldn't see dma slave devices on general purpose systems with
> > either.
> > 
> > > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> > > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> > > those drivers can get what they ask for regardless of what firmware interface
> > > the platform is using.
> > 
> > Looking at the most trivial example:
> > 
> > bool of_property_read_bool(const struct device_node *np,                                       				    const char *propname);
> > 
> > We should definitely be able to have an interface like this for
> > ACPI, but you don't have a 'struct device_node' pointer then.
> > We can add a new
> > 
> > bool dev_property_read_bool(const struct device *dev,
> >                             const char *propname);
> 
> > 
> > that handles both, but then you have to change every driver
> > that is already using of_property_read_bool() and that can
> > get used with ACPI.
> 
> It's actually not that easy in practice. There's not a one-to-one
> correspondence between device tree nodes and struct devices in the
> kernel. There are many bindings that use subnodes for sections of their
> information, and so on.
> 
> > An advantage of the dev_property_read_bool()
> > interface however is that it would also work for platform
> > devices that are created in platform code using
> > platform_device_register_full() or similar if we add a way
> > to define simple properties in C code. That would also simplify
> > a lot of drivers that use both (simple) platform_data and DT
> > today.
> 
> I'm not a fan of this "grand unified abstraction layer". Driver writes are
> already complaining that things are too complicated with the move to device
> tree, and we're making things even more abstracted and complicated here. People
> will need to peel back even more layers to figure out what's actually going on.
> 
> 
> For the truly trivial stuff, there are some quite simple ways to handle this:
> 
> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
>    mean moving over GPIO and possibly clocks to that, and use those for lookup.
> 
> 2. If Rafael's arguments are to be believed, that the translation should be
>    trivial and easy to do, then we might as well reuse the structures and APIs
>    that are already in the kernel. In other words, allocate a struct
>    device_node, populate it with the properties from the ACPI structure, and
>    attach it to the struct device. Then there's no need for any churn in the
>    drivers (until they need ACPI-specific tweaks, which they will all need).

The problem with that is that we have either device_node or acpi_node.companion
under struct device and they are mutually exclusive.  So this isn't going to fly.
[And it doesn't make sense to duplicate information already available from
acpi_node.companion this way IMHO.]

Also device references are problematic here, because both interfaces use
different ways to do that (phandles vs object paths in the ACPI namespace).

So actually, what Arnd proposed seems to be the simplest approach.

> The real problem is the non-trivial stuff. There, I think there's no real
> alternative than to teach the drivers about both firmware interfaces.

I'm not sure about that.  I won't say "this isn't the case" until I actually
try things out, but it *may* be avoidable AFAICS today.

Rafael

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

[Olof Johansson]

On Tue, May 13, 2014 at 2:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, May 13, 2014 02:14:42 PM Olof Johansson wrote:
>> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
>> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
>> > > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
>> > > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
>> > > > > The interpretation - yes, the translation - not necessarily.  By putting
>> > > > > the translation part into drivers we'll duplicate a lot of code used for
>> > > > > that.  In my opinion there needs to be a layer doing the translation
>> > > > > automatically.
>> > > >
>> > > > I'm afraid I don't understand. How can you do the translation
>> > > > automatically if you have fundamentally different representation of
>> > > > device-specific concepts ?
>> > >
>> > > I'm not entirely sure how fundamentally different it is to be honest, but in
>> > > any case I'm talking about the situation in which the hardware is the same
>> > > and the driver is the same, only the firmware interface is different.  In
>> > > that case either the firmware supplies the information the driver needs, or
>> > > it doesn't (and as long as the information is supplied, the format doesn't
>> > > really matter, because it only is a matter of translation).
>> >
>> > One example for something that is fundamentally different between an
>> > embedded system using DT and any ACPI system is how a PCI(e) host bridge
>> > gets treated, we are currently having long discussions about this elsewhere.
>> >
>> > With ACPI (or a server running OF for that matter), you assume that the
>> > PCI host is operational and all buses are fully probed and then you
>> > have methods for doing hotplugging, you just look at the device that
>> > are already initialized by the firmware.
>> >
>> > With embedded systems, you (in general, some steps may get skipped
>> > in practice) go through a lot more steps:
>> > - detect the presence of the host bridge device
>> > - enable clocks, voltages, phys, resets, etc.
>> > - set up inbound and outbound MMIO and PIO address translation windows
>> > - perform a full bus scan and assign bus and device resources
>> >
>> > We probably woulnd't go through that hassle on ACPI systems. I think
>> > we shouldn't attempt any translation here, and keep the code completely
>> > separate, with the common parts being handled by the PCI core as we
>> > do today.
>> >
>> > An example about a subsystem where translate complex information
>> > from both DT and ACPI into a common format is the dmaengine: We can
>> > have references to dma channels in completely incompatible ways
>> > but still use the same dma_request_slave_channel() interface for
>> > both. The ACPI path currently is lacking a bit (e.g. there is no
>> > way to specify the channel name in ACPI, so the code makes
>> > assumptions that don't hold true in general), but that's fixable.
>> >
>> > I assume we will see more of the second kind in the future, and this
>> > would be limited to embedded systems on both ACPI and DT, since you
>> > shouldn't see dma slave devices on general purpose systems with
>> > either.
>> >
>> > > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
>> > > today if possible.  Instead, I'd prefer to modify the firmware layer so that
>> > > those drivers can get what they ask for regardless of what firmware interface
>> > > the platform is using.
>> >
>> > Looking at the most trivial example:
>> >
>> > bool of_property_read_bool(const struct device_node *np,                                                                        const char *propname);
>> >
>> > We should definitely be able to have an interface like this for
>> > ACPI, but you don't have a 'struct device_node' pointer then.
>> > We can add a new
>> >
>> > bool dev_property_read_bool(const struct device *dev,
>> >                             const char *propname);
>>
>> >
>> > that handles both, but then you have to change every driver
>> > that is already using of_property_read_bool() and that can
>> > get used with ACPI.
>>
>> It's actually not that easy in practice. There's not a one-to-one
>> correspondence between device tree nodes and struct devices in the
>> kernel. There are many bindings that use subnodes for sections of their
>> information, and so on.
>>
>> > An advantage of the dev_property_read_bool()
>> > interface however is that it would also work for platform
>> > devices that are created in platform code using
>> > platform_device_register_full() or similar if we add a way
>> > to define simple properties in C code. That would also simplify
>> > a lot of drivers that use both (simple) platform_data and DT
>> > today.
>>
>> I'm not a fan of this "grand unified abstraction layer". Driver writes are
>> already complaining that things are too complicated with the move to device
>> tree, and we're making things even more abstracted and complicated here. People
>> will need to peel back even more layers to figure out what's actually going on.
>>
>>
>> For the truly trivial stuff, there are some quite simple ways to handle this:
>>
>> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
>>    mean moving over GPIO and possibly clocks to that, and use those for lookup.
>>
>> 2. If Rafael's arguments are to be believed, that the translation should be
>>    trivial and easy to do, then we might as well reuse the structures and APIs
>>    that are already in the kernel. In other words, allocate a struct
>>    device_node, populate it with the properties from the ACPI structure, and
>>    attach it to the struct device. Then there's no need for any churn in the
>>    drivers (until they need ACPI-specific tweaks, which they will all need).
>
> The problem with that is that we have either device_node or acpi_node.companion
> under struct device and they are mutually exclusive.  So this isn't going to fly.
> [And it doesn't make sense to duplicate information already available from
> acpi_node.companion this way IMHO.]
>
> Also device references are problematic here, because both interfaces use
> different ways to do that (phandles vs object paths in the ACPI namespace).
>
> So actually, what Arnd proposed seems to be the simplest approach.

Again, that suggestion assumes a 1:1 mapping between device nodes and
struct devices, which does not exist. And we won't churn bindings nor
drivers to make it fit since the whole point of your proposal is to
avoid doing that.

>> The real problem is the non-trivial stuff. There, I think there's no real
>> alternative than to teach the drivers about both firmware interfaces.
>
> I'm not sure about that.  I won't say "this isn't the case" until I actually
> try things out, but it *may* be avoidable AFAICS today.

Do you have a rough idea of when you can do that?


-Olof

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

[Rafael J. Wysocki]

On Tuesday, May 13, 2014 02:28:05 PM Olof Johansson wrote:
> On Tue, May 13, 2014 at 2:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, May 13, 2014 02:14:42 PM Olof Johansson wrote:
> >> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> >> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> >> > > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> >> > > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> >> > > > > The interpretation - yes, the translation - not necessarily.  By putting
> >> > > > > the translation part into drivers we'll duplicate a lot of code used for
> >> > > > > that.  In my opinion there needs to be a layer doing the translation
> >> > > > > automatically.
> >> > > >
> >> > > > I'm afraid I don't understand. How can you do the translation
> >> > > > automatically if you have fundamentally different representation of
> >> > > > device-specific concepts ?
> >> > >
> >> > > I'm not entirely sure how fundamentally different it is to be honest, but in
> >> > > any case I'm talking about the situation in which the hardware is the same
> >> > > and the driver is the same, only the firmware interface is different.  In
> >> > > that case either the firmware supplies the information the driver needs, or
> >> > > it doesn't (and as long as the information is supplied, the format doesn't
> >> > > really matter, because it only is a matter of translation).
> >> >
> >> > One example for something that is fundamentally different between an
> >> > embedded system using DT and any ACPI system is how a PCI(e) host bridge
> >> > gets treated, we are currently having long discussions about this elsewhere.
> >> >
> >> > With ACPI (or a server running OF for that matter), you assume that the
> >> > PCI host is operational and all buses are fully probed and then you
> >> > have methods for doing hotplugging, you just look at the device that
> >> > are already initialized by the firmware.
> >> >
> >> > With embedded systems, you (in general, some steps may get skipped
> >> > in practice) go through a lot more steps:
> >> > - detect the presence of the host bridge device
> >> > - enable clocks, voltages, phys, resets, etc.
> >> > - set up inbound and outbound MMIO and PIO address translation windows
> >> > - perform a full bus scan and assign bus and device resources
> >> >
> >> > We probably woulnd't go through that hassle on ACPI systems. I think
> >> > we shouldn't attempt any translation here, and keep the code completely
> >> > separate, with the common parts being handled by the PCI core as we
> >> > do today.
> >> >
> >> > An example about a subsystem where translate complex information
> >> > from both DT and ACPI into a common format is the dmaengine: We can
> >> > have references to dma channels in completely incompatible ways
> >> > but still use the same dma_request_slave_channel() interface for
> >> > both. The ACPI path currently is lacking a bit (e.g. there is no
> >> > way to specify the channel name in ACPI, so the code makes
> >> > assumptions that don't hold true in general), but that's fixable.
> >> >
> >> > I assume we will see more of the second kind in the future, and this
> >> > would be limited to embedded systems on both ACPI and DT, since you
> >> > shouldn't see dma slave devices on general purpose systems with
> >> > either.
> >> >
> >> > > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> >> > > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> >> > > those drivers can get what they ask for regardless of what firmware interface
> >> > > the platform is using.
> >> >
> >> > Looking at the most trivial example:
> >> >
> >> > bool of_property_read_bool(const struct device_node *np,                                                                        const char *propname);
> >> >
> >> > We should definitely be able to have an interface like this for
> >> > ACPI, but you don't have a 'struct device_node' pointer then.
> >> > We can add a new
> >> >
> >> > bool dev_property_read_bool(const struct device *dev,
> >> >                             const char *propname);
> >>
> >> >
> >> > that handles both, but then you have to change every driver
> >> > that is already using of_property_read_bool() and that can
> >> > get used with ACPI.
> >>
> >> It's actually not that easy in practice. There's not a one-to-one
> >> correspondence between device tree nodes and struct devices in the
> >> kernel. There are many bindings that use subnodes for sections of their
> >> information, and so on.
> >>
> >> > An advantage of the dev_property_read_bool()
> >> > interface however is that it would also work for platform
> >> > devices that are created in platform code using
> >> > platform_device_register_full() or similar if we add a way
> >> > to define simple properties in C code. That would also simplify
> >> > a lot of drivers that use both (simple) platform_data and DT
> >> > today.
> >>
> >> I'm not a fan of this "grand unified abstraction layer". Driver writes are
> >> already complaining that things are too complicated with the move to device
> >> tree, and we're making things even more abstracted and complicated here. People
> >> will need to peel back even more layers to figure out what's actually going on.
> >>
> >>
> >> For the truly trivial stuff, there are some quite simple ways to handle this:
> >>
> >> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
> >>    mean moving over GPIO and possibly clocks to that, and use those for lookup.
> >>
> >> 2. If Rafael's arguments are to be believed, that the translation should be
> >>    trivial and easy to do, then we might as well reuse the structures and APIs
> >>    that are already in the kernel. In other words, allocate a struct
> >>    device_node, populate it with the properties from the ACPI structure, and
> >>    attach it to the struct device. Then there's no need for any churn in the
> >>    drivers (until they need ACPI-specific tweaks, which they will all need).
> >
> > The problem with that is that we have either device_node or acpi_node.companion
> > under struct device and they are mutually exclusive.  So this isn't going to fly.
> > [And it doesn't make sense to duplicate information already available from
> > acpi_node.companion this way IMHO.]
> >
> > Also device references are problematic here, because both interfaces use
> > different ways to do that (phandles vs object paths in the ACPI namespace).
> >
> > So actually, what Arnd proposed seems to be the simplest approach.
> 
> Again, that suggestion assumes a 1:1 mapping between device nodes and
> struct devices, which does not exist.

I suppose your concern is that there may be device nodes without struct device,
right?  So drivers may need to access those device nodes directly?

Can you please point me to code where this is the case?

> And we won't churn bindings nor drivers to make it fit since the whole point
> of your proposal is to avoid doing that.

Yes.

> >> The real problem is the non-trivial stuff. There, I think there's no real
> >> alternative than to teach the drivers about both firmware interfaces.
> >
> > I'm not sure about that.  I won't say "this isn't the case" until I actually
> > try things out, but it *may* be avoidable AFAICS today.
> 
> Do you have a rough idea of when you can do that?

Next month?  That time frame, more or less.

Surely before August. :-)

Rafael

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

[Darren Vincent Hart]

On Tue, 2014-05-13 at 23:51 +0200, Rafael J. Wysocki wrote:
> On Tuesday, May 13, 2014 02:28:05 PM Olof Johansson wrote:
> > On Tue, May 13, 2014 at 2:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > On Tuesday, May 13, 2014 02:14:42 PM Olof Johansson wrote:
> > >> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > >> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > >> > > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > >> > > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > >> > > > > The interpretation - yes, the translation - not necessarily.  By putting
> > >> > > > > the translation part into drivers we'll duplicate a lot of code used for
> > >> > > > > that.  In my opinion there needs to be a layer doing the translation
> > >> > > > > automatically.
> > >> > > >
> > >> > > > I'm afraid I don't understand. How can you do the translation
> > >> > > > automatically if you have fundamentally different representation of
> > >> > > > device-specific concepts ?
> > >> > >
> > >> > > I'm not entirely sure how fundamentally different it is to be honest, but in
> > >> > > any case I'm talking about the situation in which the hardware is the same
> > >> > > and the driver is the same, only the firmware interface is different.  In
> > >> > > that case either the firmware supplies the information the driver needs, or
> > >> > > it doesn't (and as long as the information is supplied, the format doesn't
> > >> > > really matter, because it only is a matter of translation).
> > >> >
> > >> > One example for something that is fundamentally different between an
> > >> > embedded system using DT and any ACPI system is how a PCI(e) host bridge
> > >> > gets treated, we are currently having long discussions about this elsewhere.
> > >> >
> > >> > With ACPI (or a server running OF for that matter), you assume that the
> > >> > PCI host is operational and all buses are fully probed and then you
> > >> > have methods for doing hotplugging, you just look at the device that
> > >> > are already initialized by the firmware.
> > >> >
> > >> > With embedded systems, you (in general, some steps may get skipped
> > >> > in practice) go through a lot more steps:
> > >> > - detect the presence of the host bridge device
> > >> > - enable clocks, voltages, phys, resets, etc.
> > >> > - set up inbound and outbound MMIO and PIO address translation windows
> > >> > - perform a full bus scan and assign bus and device resources
> > >> >
> > >> > We probably woulnd't go through that hassle on ACPI systems. I think
> > >> > we shouldn't attempt any translation here, and keep the code completely
> > >> > separate, with the common parts being handled by the PCI core as we
> > >> > do today.
> > >> >
> > >> > An example about a subsystem where translate complex information
> > >> > from both DT and ACPI into a common format is the dmaengine: We can
> > >> > have references to dma channels in completely incompatible ways
> > >> > but still use the same dma_request_slave_channel() interface for
> > >> > both. The ACPI path currently is lacking a bit (e.g. there is no
> > >> > way to specify the channel name in ACPI, so the code makes
> > >> > assumptions that don't hold true in general), but that's fixable.
> > >> >
> > >> > I assume we will see more of the second kind in the future, and this
> > >> > would be limited to embedded systems on both ACPI and DT, since you
> > >> > shouldn't see dma slave devices on general purpose systems with
> > >> > either.
> > >> >
> > >> > > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> > >> > > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> > >> > > those drivers can get what they ask for regardless of what firmware interface
> > >> > > the platform is using.
> > >> >
> > >> > Looking at the most trivial example:
> > >> >
> > >> > bool of_property_read_bool(const struct device_node *np,                                                                        const char *propname);
> > >> >
> > >> > We should definitely be able to have an interface like this for
> > >> > ACPI, but you don't have a 'struct device_node' pointer then.
> > >> > We can add a new
> > >> >
> > >> > bool dev_property_read_bool(const struct device *dev,
> > >> >                             const char *propname);
> > >>
> > >> >
> > >> > that handles both, but then you have to change every driver
> > >> > that is already using of_property_read_bool() and that can
> > >> > get used with ACPI.
> > >>
> > >> It's actually not that easy in practice. There's not a one-to-one
> > >> correspondence between device tree nodes and struct devices in the
> > >> kernel. There are many bindings that use subnodes for sections of their
> > >> information, and so on.
> > >>
> > >> > An advantage of the dev_property_read_bool()
> > >> > interface however is that it would also work for platform
> > >> > devices that are created in platform code using
> > >> > platform_device_register_full() or similar if we add a way
> > >> > to define simple properties in C code. That would also simplify
> > >> > a lot of drivers that use both (simple) platform_data and DT
> > >> > today.
> > >>
> > >> I'm not a fan of this "grand unified abstraction layer". Driver writes are
> > >> already complaining that things are too complicated with the move to device
> > >> tree, and we're making things even more abstracted and complicated here. People
> > >> will need to peel back even more layers to figure out what's actually going on.
> > >>
> > >>
> > >> For the truly trivial stuff, there are some quite simple ways to handle this:
> > >>
> > >> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
> > >>    mean moving over GPIO and possibly clocks to that, and use those for lookup.
> > >>
> > >> 2. If Rafael's arguments are to be believed, that the translation should be
> > >>    trivial and easy to do, then we might as well reuse the structures and APIs
> > >>    that are already in the kernel. In other words, allocate a struct
> > >>    device_node, populate it with the properties from the ACPI structure, and
> > >>    attach it to the struct device. Then there's no need for any churn in the
> > >>    drivers (until they need ACPI-specific tweaks, which they will all need).
> > >
> > > The problem with that is that we have either device_node or acpi_node.companion
> > > under struct device and they are mutually exclusive.  So this isn't going to fly.
> > > [And it doesn't make sense to duplicate information already available from
> > > acpi_node.companion this way IMHO.]
> > >
> > > Also device references are problematic here, because both interfaces use
> > > different ways to do that (phandles vs object paths in the ACPI namespace).
> > >
> > > So actually, what Arnd proposed seems to be the simplest approach.
> > 
> > Again, that suggestion assumes a 1:1 mapping between device nodes and
> > struct devices, which does not exist.
> 
> I suppose your concern is that there may be device nodes without struct device,
> right?  So drivers may need to access those device nodes directly?
> 
> Can you please point me to code where this is the case?

gpio-keys.c is a good example, and the one I chose for the MinnowBoard
example last year.

This is a really good point. My thinking was that we iterate through the
devices - but I had my ACPI glasses on at the time  and wasn't thinking
about how that iteration would work for DT in with the properties
abstraction.

The ACPI sub-devices do have something in common with the DT sub-nodes,
they are not themselves "compatible" with a specific driver, nor are the
known by the acpi_platform match table.

So in both cases we have effectively a hierarchy of properties. Could we
not support such a concept in the properties interface? The basic
signature might be something more like:

device_get_property(dev, NULL, "foo") // for the top level properties

We could have some kind of a foreach iterator for children, and

device_get_property(dev, child, "baz")

Thoughts?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Arnd Bergmann]

On Tuesday 13 May 2014 14:14:42 Olof Johansson wrote:
> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > 
> > We should definitely be able to have an interface like this for
> > ACPI, but you don't have a 'struct device_node' pointer then.
> > We can add a new
> > 
> > bool dev_property_read_bool(const struct device *dev,
> >                             const char *propname);
> 
> > 
> > that handles both, but then you have to change every driver
> > that is already using of_property_read_bool() and that can
> > get used with ACPI.
> 
> It's actually not that easy in practice. There's not a one-to-one
> correspondence between device tree nodes and struct devices in the
> kernel. There are many bindings that use subnodes for sections of their
> information, and so on.

I also don't think we can have a grand unified solution to the general
problem, but doing the above would solve a lot of individual problems
for all the simple drivers that don't use sub-nodes in DT.

I really don't see any downsides to using a common named property
API for simple values in drivers that can.

Devices with sub-nodes are by definition complex to handle, and
I think we will always have cases that are too complex to use
a common interface. At the moment, we can share drivers that
have only memory and irq resources, which is a significant share
already. We can over time extend this to drivers that use strings,
booleans, integers, or arrays of those. We can also extend it
for things like gpios and dma-channels (both of which partly work
already but are limited when it comes to naming) and a few other
things.

> > An advantage of the dev_property_read_bool()
> > interface however is that it would also work for platform
> > devices that are created in platform code using
> > platform_device_register_full() or similar if we add a way
> > to define simple properties in C code. That would also simplify
> > a lot of drivers that use both (simple) platform_data and DT
> > today.
> 
> I'm not a fan of this "grand unified abstraction layer". Driver writes are
> already complaining that things are too complicated with the move to device
> tree, and we're making things even more abstracted and complicated here. People
> will need to peel back even more layers to figure out what's actually going on.
> 
> 
> For the truly trivial stuff, there are some quite simple ways to handle this:
> 
> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
>    mean moving over GPIO and possibly clocks to that, and use those for lookup.

We are actually moving away from IORESOURCE_* for things that are not
originally handled as resources. I don't think we should reverse that
course.

For both the examples I mentioned above (GPIO and DMA), people have in the
past put them into resource structures with a platform specific
interpretation. With the move to DT, we have actually broken this
because there is no longer a global number space for them in general.

Instead, you have a device pointer and a local name that you can use
to resolve a pointer to a structure (gpio descriptor or dma channel).
For GPIOs, we keep the integer based API for compatibility, but it would
be nice to move to the descriptor interface over time.

If it were not so much work, we'd probably also move away from IRQ numbers
towards passing IRQ descriptor pointers.

The way I see things moving forward for ACPI is to add a standard way to
name things (GPIOs, IRQs, DMAs, ...) so we can have a generic 'give me
a pointer to the X object for this device' for each subsystem we want to
have it for. Note that this would probably not be a combined interface
across subsystems though.

> The real problem is the non-trivial stuff. There, I think there's no real
> alternative than to teach the drivers about both firmware interfaces.

Agreed. 

	Arnd

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Wed, May 14, 2014 at 02:06:10PM +0200, Arnd Bergmann wrote:

> The way I see things moving forward for ACPI is to add a standard way to
> name things (GPIOs, IRQs, DMAs, ...) so we can have a generic 'give me
> a pointer to the X object for this device' for each subsystem we want to
> have it for. Note that this would probably not be a combined interface
> across subsystems though.

And indeed we already have that interface in the kernel for most APIs
newer than GPIOs so in implementation terms this normally boils down to
adding an ACPI backend for looking things up.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Linus Walleij]

On Wed, May 14, 2014 at 2:25 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 14, 2014 at 02:06:10PM +0200, Arnd Bergmann wrote:
>
>> The way I see things moving forward for ACPI is to add a standard way to
>> name things (GPIOs, IRQs, DMAs, ...) so we can have a generic 'give me
>> a pointer to the X object for this device' for each subsystem we want to
>> have it for. Note that this would probably not be a combined interface
>> across subsystems though.
>
> And indeed we already have that interface in the kernel for most APIs
> newer than GPIOs so in implementation terms this normally boils down to
> adding an ACPI backend for looking things up.

We have this for GPIO too, just need to continue to roll it out.

And we have backends for DT and ACPI alike.

Yours,
Linus Walleij

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

[Rafael J. Wysocki]

On Wednesday, May 14, 2014 02:06:10 PM Arnd Bergmann wrote:
> On Tuesday 13 May 2014 14:14:42 Olof Johansson wrote:
> > On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > 
> > > We should definitely be able to have an interface like this for
> > > ACPI, but you don't have a 'struct device_node' pointer then.
> > > We can add a new
> > > 
> > > bool dev_property_read_bool(const struct device *dev,
> > >                             const char *propname);
> > 
> > > 
> > > that handles both, but then you have to change every driver
> > > that is already using of_property_read_bool() and that can
> > > get used with ACPI.
> > 
> > It's actually not that easy in practice. There's not a one-to-one
> > correspondence between device tree nodes and struct devices in the
> > kernel. There are many bindings that use subnodes for sections of their
> > information, and so on.
> 
> I also don't think we can have a grand unified solution to the general
> problem, but doing the above would solve a lot of individual problems
> for all the simple drivers that don't use sub-nodes in DT.
> 
> I really don't see any downsides to using a common named property
> API for simple values in drivers that can.

I agree.

> Devices with sub-nodes are by definition complex to handle, and
> I think we will always have cases that are too complex to use
> a common interface. At the moment, we can share drivers that
> have only memory and irq resources, which is a significant share
> already. We can over time extend this to drivers that use strings,
> booleans, integers, or arrays of those. We can also extend it
> for things like gpios and dma-channels (both of which partly work
> already but are limited when it comes to naming) and a few other
> things.

Yes.

> > > An advantage of the dev_property_read_bool()
> > > interface however is that it would also work for platform
> > > devices that are created in platform code using
> > > platform_device_register_full() or similar if we add a way
> > > to define simple properties in C code. That would also simplify
> > > a lot of drivers that use both (simple) platform_data and DT
> > > today.
> > 
> > I'm not a fan of this "grand unified abstraction layer". Driver writes are
> > already complaining that things are too complicated with the move to device
> > tree, and we're making things even more abstracted and complicated here. People
> > will need to peel back even more layers to figure out what's actually going on.
> > 
> > 
> > For the truly trivial stuff, there are some quite simple ways to handle this:
> > 
> > 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
> >    mean moving over GPIO and possibly clocks to that, and use those for lookup.
> 
> We are actually moving away from IORESOURCE_* for things that are not
> originally handled as resources. I don't think we should reverse that
> course.
> 
> For both the examples I mentioned above (GPIO and DMA), people have in the
> past put them into resource structures with a platform specific
> interpretation. With the move to DT, we have actually broken this
> because there is no longer a global number space for them in general.
> 
> Instead, you have a device pointer and a local name that you can use
> to resolve a pointer to a structure (gpio descriptor or dma channel).
> For GPIOs, we keep the integer based API for compatibility, but it would
> be nice to move to the descriptor interface over time.
> 
> If it were not so much work, we'd probably also move away from IRQ numbers
> towards passing IRQ descriptor pointers.
> 
> The way I see things moving forward for ACPI is to add a standard way to
> name things (GPIOs, IRQs, DMAs, ...) so we can have a generic 'give me
> a pointer to the X object for this device' for each subsystem we want to
> have it for. Note that this would probably not be a combined interface
> across subsystems though.

That's my idea too.

Rafael

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

[Darren Vincent Hart]

On Wed, 2014-05-14 at 14:06 +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 14:14:42 Olof Johansson wrote:
> > On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > 
> > > We should definitely be able to have an interface like this for
> > > ACPI, but you don't have a 'struct device_node' pointer then.
> > > We can add a new
> > > 
> > > bool dev_property_read_bool(const struct device *dev,
> > >                             const char *propname);
> > 
> > > 
> > > that handles both, but then you have to change every driver
> > > that is already using of_property_read_bool() and that can
> > > get used with ACPI.
> > 
> > It's actually not that easy in practice. There's not a one-to-one
> > correspondence between device tree nodes and struct devices in the
> > kernel. There are many bindings that use subnodes for sections of their
> > information, and so on.
> 
> I also don't think we can have a grand unified solution to the general
> problem, but doing the above would solve a lot of individual problems
> for all the simple drivers that don't use sub-nodes in DT.
> 
> I really don't see any downsides to using a common named property
> API for simple values in drivers that can.
> 
> Devices with sub-nodes are by definition complex to handle, and
> I think we will always have cases that are too complex to use
> a common interface. At the moment, we can share drivers that
> have only memory and irq resources, which is a significant share
> already. We can over time extend this to drivers that use strings,
> booleans, integers, or arrays of those. We can also extend it
> for things like gpios and dma-channels (both of which partly work
> already but are limited when it comes to naming) and a few other
> things.


Agreed, well said.


-- 
Darren Hart
Intel Open Source Technology Center

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

[Darren Vincent Hart]

On Tue, 2014-05-13 at 14:14 -0700, Olof Johansson wrote:
> On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > On Monday, May 05, 2014 09:31:04 PM Benjamin Herrenschmidt wrote:
> > > > On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> > > > > The interpretation - yes, the translation - not necessarily.  By putting
> > > > > the translation part into drivers we'll duplicate a lot of code used for
> > > > > that.  In my opinion there needs to be a layer doing the translation
> > > > > automatically.
> > > > 
> > > > I'm afraid I don't understand. How can you do the translation
> > > > automatically if you have fundamentally different representation of
> > > > device-specific concepts ?
> > > 
> > > I'm not entirely sure how fundamentally different it is to be honest, but in
> > > any case I'm talking about the situation in which the hardware is the same
> > > and the driver is the same, only the firmware interface is different.  In
> > > that case either the firmware supplies the information the driver needs, or
> > > it doesn't (and as long as the information is supplied, the format doesn't
> > > really matter, because it only is a matter of translation).
> > 
> > One example for something that is fundamentally different between an
> > embedded system using DT and any ACPI system is how a PCI(e) host bridge
> > gets treated, we are currently having long discussions about this elsewhere.
> > 
> > With ACPI (or a server running OF for that matter), you assume that the
> > PCI host is operational and all buses are fully probed and then you
> > have methods for doing hotplugging, you just look at the device that
> > are already initialized by the firmware.
> > 
> > With embedded systems, you (in general, some steps may get skipped
> > in practice) go through a lot more steps:
> > - detect the presence of the host bridge device
> > - enable clocks, voltages, phys, resets, etc.
> > - set up inbound and outbound MMIO and PIO address translation windows
> > - perform a full bus scan and assign bus and device resources
> > 
> > We probably woulnd't go through that hassle on ACPI systems. I think
> > we shouldn't attempt any translation here, and keep the code completely
> > separate, with the common parts being handled by the PCI core as we
> > do today.
> > 
> > An example about a subsystem where translate complex information
> > from both DT and ACPI into a common format is the dmaengine: We can
> > have references to dma channels in completely incompatible ways
> > but still use the same dma_request_slave_channel() interface for
> > both. The ACPI path currently is lacking a bit (e.g. there is no
> > way to specify the channel name in ACPI, so the code makes
> > assumptions that don't hold true in general), but that's fixable.
> > 
> > I assume we will see more of the second kind in the future, and this
> > would be limited to embedded systems on both ACPI and DT, since you
> > shouldn't see dma slave devices on general purpose systems with
> > either.
> > 
> > > Bottom line: I'd like to avoid modifying drivers that use the of_ interface
> > > today if possible.  Instead, I'd prefer to modify the firmware layer so that
> > > those drivers can get what they ask for regardless of what firmware interface
> > > the platform is using.
> > 
> > Looking at the most trivial example:
> > 
> > bool of_property_read_bool(const struct device_node *np,                                       				    const char *propname);
> > 
> > We should definitely be able to have an interface like this for
> > ACPI, but you don't have a 'struct device_node' pointer then.
> > We can add a new
> > 
> > bool dev_property_read_bool(const struct device *dev,
> >                             const char *propname);
> 
> > 
> > that handles both, but then you have to change every driver
> > that is already using of_property_read_bool() and that can
> > get used with ACPI.
> 
> It's actually not that easy in practice. There's not a one-to-one
> correspondence between device tree nodes and struct devices in the
> kernel. There are many bindings that use subnodes for sections of their
> information, and so on.


This is the approach that we have prototyped and demonstrated for some
admittedly trivial examples. One gap in my original approach was how to
deal with the DT sub-nodes - or rather didn't. The latest approach uses
a 1:1 device tree node to ACPI DEVICE object (which can also be nested
inside parent DEVICE objects in much the same way) and provide
properties to these sub nodes as well.  This will at least provide us
with the ability to us the same schema with the same hiearchy.

> 
> > An advantage of the dev_property_read_bool()
> > interface however is that it would also work for platform
> > devices that are created in platform code using
> > platform_device_register_full() or similar if we add a way
> > to define simple properties in C code. That would also simplify
> > a lot of drivers that use both (simple) platform_data and DT
> > today.
> 
> I'm not a fan of this "grand unified abstraction layer". Driver writes are
> already complaining that things are too complicated with the move to device
> tree, and we're making things even more abstracted and complicated here. People
> will need to peel back even more layers to figure out what's actually going on.
> 

I guess I can't argue with that since when I first started into this I
said very much the same thing about driver code being simple - but the
APIs being complicated (vs core kernel code which tends have very simple
APIs with some pretty complicated algorithms and such).

> 
> For the truly trivial stuff, there are some quite simple ways to handle this:
> 
> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
>    mean moving over GPIO and possibly clocks to that, and use those for lookup.

That's seems consistent with what one of our guiding principles has
been: We're looking to fill the gaps in ACPI, not replace the existing
mechanism. I will need to look into the IORESOURCE_* in more detail to
make sure I fully understand the implications.

> 
> 2. If Rafael's arguments are to be believed, that the translation should be
>    trivial and easy to do, then we might as well reuse the structures and APIs
>    that are already in the kernel. In other words, allocate a struct
>    device_node, populate it with the properties from the ACPI structure, and
>    attach it to the struct device. Then there's no need for any churn in the
>    drivers (until they need ACPI-specific tweaks, which they will all need).
> 

There is some missing context that I think is confusing this issue.
Current ACPI tables don't translate like this. The new ACPI Device
Properties stuff in the works will provide the flexibility we need to
provide the missing properties in a format which is much more trivial to
translate. That is only part of the problem though.

> 
> The real problem is the non-trivial stuff. There, I think there's no real
> alternative than to teach the drivers about both firmware interfaces.

I think it would help me a great deal to pick a driver and discuss it
specifically.

Olof - could you recommend one where you feel specific knowledge of
firmware interfaces is really unavoidable?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Linus Walleij]

On Tue, May 13, 2014 at 11:14 PM, Olof Johansson <olof@lixom.net> wrote:

> For the truly trivial stuff, there are some quite simple ways to handle this:
>
> 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
>    mean moving over GPIO and possibly clocks to that, and use those for lookup.

GPIO consumers shall use devm_gpiod_get() or devm_gpiod_get_index()
to get an abstract GPIO descriptor. This already works with DT and ACPI
alike, driver authors just haven't caught up. Yes we have to patch ourselves
through this entire GPIO number exodus ...
Documentation/gpio/consumer.txt

GPIOs, clocks, regulators and pins are already on abstract handles
tied into the device model, so what am I missing?

Yours,
Linus Walleij

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

[Rob Herring]

On Mon, May 5, 2014 at 3:43 AM, Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:
> On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
>>
>>
>> But we have such quirks for some bus types already, like PCI and PNP.
>
> And they suck big time. They duplicate definitions from the driver,
> they get missed at grep time, they bit rot, etc...
>
> There are a few cases where that's justified simply because the driver
> can be a module but the quirk needs to run early and always, but mostly
> these quirks are about working around HW bugs that would otherwise cause
> the system to misbehave even in absence of the driver.
>
> For example, bad class code in bridges, BAR issues, etc...
>
> Generally speaking though, quirks like that are a bad idea and in this
> case, totally unjustified since the code performing whatever translation
> is necessary (or interpretation) is entirely specific to the driver
> anyway.

On the flip side, DT entirely lacks any sort of infrastructure for
quirks other than match table data, and it handles various quirks
inline mostly. It's not so much of a problem now as much of PPC is
pretty stable and ARM is still a newcomer to DT, but I worry that we
have an impending problem as ARM DTs start to mature. So what is the
direction we want to go with quirks which can't be self-contained
within drivers?

Rob

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

[Jason Cooper]

On Mon, May 05, 2014 at 10:09:04AM -0500, Rob Herring wrote:
> On Mon, May 5, 2014 at 3:43 AM, Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:
> > On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
> >>
> >>
> >> But we have such quirks for some bus types already, like PCI and PNP.
> >
> > And they suck big time. They duplicate definitions from the driver,
> > they get missed at grep time, they bit rot, etc...
> >
> > There are a few cases where that's justified simply because the driver
> > can be a module but the quirk needs to run early and always, but mostly
> > these quirks are about working around HW bugs that would otherwise cause
> > the system to misbehave even in absence of the driver.
> >
> > For example, bad class code in bridges, BAR issues, etc...
> >
> > Generally speaking though, quirks like that are a bad idea and in this
> > case, totally unjustified since the code performing whatever translation
> > is necessary (or interpretation) is entirely specific to the driver
> > anyway.
> 
> On the flip side, DT entirely lacks any sort of infrastructure for
> quirks other than match table data, and it handles various quirks
> inline mostly. It's not so much of a problem now as much of PPC is
> pretty stable and ARM is still a newcomer to DT, but I worry that we
> have an impending problem as ARM DTs start to mature. So what is the
> direction we want to go with quirks which can't be self-contained
> within drivers?

regrettably, soc code.  We (mvebu) have the good fortune to be
integrating mainline support for brand new SoCs from Marvell, as they
ship.  Unfortunately, this means that the free-electron's guys
(contracted by Marvell to mainline the code) are having to work with
pre-release SoCs (Z1 stepping).

There are several quirks in the Z1 stepping that have required
workarounds, sometimes across subsystems.  You can see some examples in
arch/arm/mach-mvebu/board-v7.c, eg:

static void __init mvebu_dt_init(void)
{
        if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
                i2c_quirk();
        if (of_machine_is_compatible("marvell,a375-db"))
                thermal_quirk();

        of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}

the quirk code then uses runtime detection to determine which SoC
stepping it is on, adjusts the compatible string and any other DT
nodes, as necessary.

The driver then gets the correct information from the DT, and we don't
have to maintain two dts files for a given board.  The bigger benefit is
that the user never has to figure out which SoC stepping they have.

thx,

Jason.

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

[Thomas Petazzoni]

Dear Jason Cooper,

On Mon, 5 May 2014 12:02:37 -0400, Jason Cooper wrote:

> > On the flip side, DT entirely lacks any sort of infrastructure for
> > quirks other than match table data, and it handles various quirks
> > inline mostly. It's not so much of a problem now as much of PPC is
> > pretty stable and ARM is still a newcomer to DT, but I worry that we
> > have an impending problem as ARM DTs start to mature. So what is the
> > direction we want to go with quirks which can't be self-contained
> > within drivers?
> 
> regrettably, soc code.  We (mvebu) have the good fortune to be
> integrating mainline support for brand new SoCs from Marvell, as they
> ship.  Unfortunately, this means that the free-electron's guys
> (contracted by Marvell to mainline the code) are having to work with
> pre-release SoCs (Z1 stepping).

On the other hand, Rob was asking about "quirks which can't be
self-contained within drivers". And the two quirks below:

> static void __init mvebu_dt_init(void)
> {
>         if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
>                 i2c_quirk();
>         if (of_machine_is_compatible("marvell,a375-db"))
>                 thermal_quirk();

could perfectly be fine be self-contained into the respective device
drivers. Actually, for the I2C quirk, it was even the original
implementation that my colleague Gregory Clement proposed. But this
approach was rejected, and we were asked to replace that by the current
approach: a quirk in the mach-mvebu SoC code that changes the
compatible string.

I continue to have the feeling that the strategy we have been asked to
use is going against the principle of having less stuff in mach-<foo>
directories.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Benjamin Herrenschmidt]

On Mon, 2014-05-05 at 10:09 -0500, Rob Herring wrote:
> On the flip side, DT entirely lacks any sort of infrastructure for
> quirks other than match table data, and it handles various quirks
> inline mostly. It's not so much of a problem now as much of PPC is
> pretty stable and ARM is still a newcomer to DT, but I worry that we
> have an impending problem as ARM DTs start to mature. So what is the
> direction we want to go with quirks which can't be self-contained
> within drivers?

I have a few cases with real OF already indeed. On Mac, I have a few
fixups where I "correct" bad device-trees. Additionally in the macio
device framework, I have additional workarounds. I would rather have
those in the drivers but that was the price of getting even the basic
resources right (those old Apple DTs were really really bad).

If we ever need to do things like that, I'd rather it's done in a
per-board fixup file that does the fixups once at boot.

Ben.

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

[Darren Vincent Hart]

On Mon, 2014-05-05 at 18:43 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
> > 
> > 
> > But we have such quirks for some bus types already, like PCI and PNP.
> 
> And they suck big time. They duplicate definitions from the driver,
> they get missed at grep time, they bit rot, etc...
> 
> There are a few cases where that's justified simply because the driver
> can be a module but the quirk needs to run early and always, but mostly
> these quirks are about working around HW bugs that would otherwise cause
> the system to misbehave even in absence of the driver.
> 
> For example, bad class code in bridges, BAR issues, etc...
> 
> Generally speaking though, quirks like that are a bad idea and in this
> case, totally unjustified since the code performing whatever translation
> is necessary (or interpretation) is entirely specific to the driver
> anyway.
> 
> Also if the bindings evolve, you just created a 3rd way dependency.
> Instead of just having to deal with DT/ACPI binding version vs. driver
> version, we now have to also handle quirk versioning.

Hrm, I think I might have been answering only half of the question
earlier, and I might be confused about what Arnd, Olof, and you are
saying here.

I think the scope is larger than the specific problem I have been
focused on (which is the arbitrary device properties not covered by the
irq/mmio/gpio/etc mechanisms we already have), and making that
compatible with DT bindings.

Of course DT bindings include more than those arbitrary properties, and
I think it's here where we entered this format translation discussion?
As in:

ACPI:GpioIO and DT:gpios being possibly wrapped by another
representation? That is then translated into using the gpiod framework?
If so... yeah, that doesn't appeal to me very much either :-)

I said earlier that I would like to be able to collect this information
without having to know about the underlying firmware implementation in
the driver itself, ... is this necessarily the same thing as that third
representation?

It seems to me rather than parsing gpios or GpioIO representation,
drivers could instead ask dev_get_property_gpiod("volume_up"), and get
back a gpio descriptor, which is the interface they ultimately need to
use to do anything with it anyway.

I fear I might have veered way off into the weeds here... are we talking
past eachother?

> 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

-- 
Darren Hart
Intel Open Source Technology Center

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

[Benjamin Herrenschmidt]

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

I tend to agree.

In the end, there is no silver bullet, however, it would make things easier
of the drivers could be structured such that for most things, when they need
a piece of information they use a single accessor to get named properties,
and if needed, they can have a single conversion function that converts ACPI
"stuff" into these (provided the ACPI extension for passing properties isn't
present, or possibly for translating "keys" between the bindings etc...).

IE. A single point of translation is less messy imho than sprinkling things
all over the driver, and we *will* need translation.

Now for standard stuff such as MMIO ranges etc... we all agree I believe to
stick to the existing Linux struct resource & co and have the parsing happen
at the core level, but for everything else, the trick is to see what we can
do to make driver life easier.

They *will* have to deal with the dual world, we can't completely hide it,
but we can make it less painful via good practices.

The other option is to have both the DT representation and the ACPI
representation reach the drivers and leave it to the them (the drivers) to get
through two different functions at probe time to "translates" that into a
"3rd" driver private one (a structure, in a way akin to the old platform data
but of course completely local to the driver scope).

I know of the drawbacks but for many drivers who already just pick these
things up at probe time just to copy/encode them into their driver private
structure, that's a fairly workable and simple approach.

Cheers,
Ben.

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

[Rafael J. Wysocki]

On Monday, May 05, 2014 06:39:16 PM Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-04 at 10:18 -0700, Olof Johansson wrote:
> > 
> > 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.
> 
> I tend to agree.
> 
> In the end, there is no silver bullet, however, it would make things easier
> of the drivers could be structured such that for most things, when they need
> a piece of information they use a single accessor to get named properties,
> and if needed, they can have a single conversion function that converts ACPI
> "stuff" into these (provided the ACPI extension for passing properties isn't
> present, or possibly for translating "keys" between the bindings etc...).
> 
> IE. A single point of translation is less messy imho than sprinkling things
> all over the driver, and we *will* need translation.

Precisely.

> Now for standard stuff such as MMIO ranges etc... we all agree I believe to
> stick to the existing Linux struct resource & co and have the parsing happen
> at the core level, but for everything else, the trick is to see what we can
> do to make driver life easier.
> 
> They *will* have to deal with the dual world, we can't completely hide it,
> but we can make it less painful via good practices.

Probably.

> The other option is to have both the DT representation and the ACPI
> representation reach the drivers and leave it to the them (the drivers) to get
> through two different functions at probe time to "translates" that into a
> "3rd" driver private one (a structure, in a way akin to the old platform data
> but of course completely local to the driver scope).
> 
> I know of the drawbacks but for many drivers who already just pick these
> things up at probe time just to copy/encode them into their driver private
> structure, that's a fairly workable and simple approach.

It may be workable from an individual driver point of view, but not from
a framework perspective.  At least duplication of code has to be avoided.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> 
> The other option is to have both the DT representation and the ACPI
> representation reach the drivers and leave it to the them (the drivers) to get
> through two different functions at probe time to "translates" that into a
> "3rd" driver private one (a structure, in a way akin to the old platform data
> but of course completely local to the driver scope).

I don't like that much. For "leaf-node" device drivers, I think we're
better off with a simple set of "device_get_property" functions which
are a little more type-safe than the existing of_* ones, thus helping us
to deal with the details of 32-bit cells vs. ACPI integers, etc.


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

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

[Rafael J. Wysocki]

On Wednesday, May 07, 2014 12:05:02 PM David Woodhouse wrote:
> 
> --===============1197259587839153410==
> Content-Type: multipart/signed; micalg="sha-1"; protocol="application/x-pkcs7-signature";
> 	boundary="=-0RE4bWH9BSP3Smq+x4xP"
> 
> 
> --=-0RE4bWH9BSP3Smq+x4xP
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> >=20
> > The other option is to have both the DT representation and the ACPI
> > representation reach the drivers and leave it to the them (the drivers) t=
> o get
> > through two different functions at probe time to "translates" that into a
> > "3rd" driver private one (a structure, in a way akin to the old platform =
> data
> > but of course completely local to the driver scope).
> 
> I don't like that much. For "leaf-node" device drivers, I think we're
> better off with a simple set of "device_get_property" functions which
> are a little more type-safe than the existing of_* ones, thus helping us
> to deal with the details of 32-bit cells vs. ACPI integers, etc.

I agree.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Benjamin Herrenschmidt]

On Wed, 2014-05-07 at 12:05 +0100, David Woodhouse wrote:
> On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> > 
> > The other option is to have both the DT representation and the ACPI
> > representation reach the drivers and leave it to the them (the drivers) to get
> > through two different functions at probe time to "translates" that into a
> > "3rd" driver private one (a structure, in a way akin to the old platform data
> > but of course completely local to the driver scope).
> 
> I don't like that much. For "leaf-node" device drivers, I think we're
> better off with a simple set of "device_get_property" functions which
> are a little more type-safe than the existing of_* ones, thus helping us
> to deal with the details of 32-bit cells vs. ACPI integers, etc.

Fair enough. I was mostly putting all options on the table. It is still
not completely clear on my mind how we'll get the properties from ACPI
(via that new scheme Darren's working on ?) and how good we'll manage to
keep the bindings in sync sufficiently to avoid a bunch of:

	if (OF)
		get_property("foo"...)
	else
		get_property("bar"...)

Because of subtle differences in property names, format, content, etc...

It might end up working out ... but it's going to be a constant battle
at least initially.

I'm mostly concerned here about device specific random attributes. I
think we all agree that the "common" stuff such as memory and irq is
going to be translated by the core into Linux native representation.

Of course there is going to be a pile of work defining the right
representation & translation for some of that "common" stuff in areas
like clocks, gpios, etc...

Cheers,
Ben.

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

[Darren Vincent Hart]

On Thu, 2014-05-08 at 13:27 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-05-07 at 12:05 +0100, David Woodhouse wrote:
> > On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> > > 
> > > The other option is to have both the DT representation and the ACPI
> > > representation reach the drivers and leave it to the them (the drivers) to get
> > > through two different functions at probe time to "translates" that into a
> > > "3rd" driver private one (a structure, in a way akin to the old platform data
> > > but of course completely local to the driver scope).
> > 
> > I don't like that much. For "leaf-node" device drivers, I think we're
> > better off with a simple set of "device_get_property" functions which
> > are a little more type-safe than the existing of_* ones, thus helping us
> > to deal with the details of 32-bit cells vs. ACPI integers, etc.
> 
> Fair enough. I was mostly putting all options on the table. It is still
> not completely clear on my mind how we'll get the properties from ACPI
> (via that new scheme Darren's working on ?) and how good we'll manage to
> keep the bindings in sync sufficiently to avoid a bunch of:
> 
> 	if (OF)
> 		get_property("foo"...)
> 	else
> 		get_property("bar"...)
> 
> Because of subtle differences in property names, format, content, etc...
> 

Right, we have to avoid this. I'd rather see:

get_of_pdata() and get_acpi_pdata() than a slew of if/else blocks
implementing slightly skewed schemas.


> It might end up working out ... but it's going to be a constant battle
> at least initially.
> 

For the of-capable platform devices we have today, the above doesn't
even become an option. We switch to the new API dev_get_property("foo")
and people wanting to use these drivers with ACPI WILL use that schema.
I'm talking with a few of these folks a lot lately, and they absolutely
do not want to have to special case / rewrite all these drivers. All
they will have to do is add the DEVICE and Package() to the ASL and the
driver works. So it is in their best interest NOT to fragment the
schema. 

> I'm mostly concerned here about device specific random attributes. I

Right, and this the area we're focused on with the new ACPI properties
mechanism. If ACPI already provides a specific object type, like for
GPIO, we continue to use that.

> think we all agree that the "common" stuff such as memory and irq is
> going to be translated by the core into Linux native representation.
> 
> Of course there is going to be a pile of work defining the right
> representation & translation for some of that "common" stuff in areas
> like clocks, gpios, etc...

Nodding... :-)


-- 
Darren

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

[Darren Vincent Hart]

On Sun, 2014-05-04 at 10:18 -0700, Olof Johansson wrote:

...


> 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

In my opinion, the common dev_get_property() interface which calls the
appropriate firmware accessor function makes the most sense. Creating
another intermediate format which we then have to make into something
useful (like pdata) strikes me as unnecessary and likely limiting. 

> 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.

Right, so let me give a trivial example indicating what this looks like.

In ASL (DSDT that ships with the board, or an SSDT that we add after the
fact - another discussion on how to integrate that at boot time, table
that for now), under the Device objection, you have a named object (not
a method) that provides a Package in a known format, something like:

Package () {
  Package (2) { "label", "foo" },
  Package (2) { "value", 1}
  Package (2) { "devs_indices", Package { _SB.DEV1, 1, _SB.DEV2, 0 }
}

NOTE: I've pared off some implementation detail above just to focus on
what's relevant to this discussion. We're in a mad rush right now
between working group meetings, writing documentation to explain all
this, and discussing things here while we have people's attention. All
important, all time sensitive. I apologize for not just having a
complete wiki page to point everyone to - but we'll have something a lot
more concrete *very* shortly.

When the platform driver discovers pdata is NULL and that there is
firmware to be probed (dev exists), it starts populating a pdata
structure with calls like:

pdata.label = dev_get_property_string("label");

This would go through ACPICA to get the property on this device, but
could also go through OF on a different system, without any change to
the driver.


> 
> 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.


Of course there will be exceptions in the way certain things are
represented in each firmware type, but we already have accessors per
firmware type, so we have the groundwork to deal with those via
specific-property-type accessors.

> 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.

Hrm, I was hoping to see it in the properties core (driver core I guess)
so we didn't have to see every driver. I suppose  we could approach this
like we do subsystems in general. If we see something repeated enough,
we abstract it and move it down a level :-)

For example, DT and ACPI handle device references differently - but that
isn't a quirky device-specific kind of thing, it's a firmware
representation thing, and that should be abstracted away from the driver
IMO.

GPIO is another example (which is actually dependent on the phandle/ACPI
namespace difference).

Thanks,

-- 
Darren

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

[Benjamin Herrenschmidt]

On Fri, 2014-05-16 at 18:54 -0700, Darren Vincent Hart wrote:

> In my opinion, the common dev_get_property() interface which calls the
> appropriate firmware accessor function makes the most sense. Creating
> another intermediate format which we then have to make into something
> useful (like pdata) strikes me as unnecessary and likely limiting. 

So in the end it will really depend on whether people are good enough to
use the same property/value "names" and format accross the
representations.

So yes, maybe something like dev_get_property() would work fine for
most cases, which would be great. And for the always necessary quirks
where for example the ACPI variant used a wrong spelling or the DT
variant used a different size or something, the driver can either
openly call different of and acpi variants or we could have quirks in
the driver itself... ie, a pointer in struct device to a quirk table,
possibly based on hash of the name for fast lookup. But let's wait
for some real implementations to see how necessary that really is.

Ben.

> Right, so let me give a trivial example indicating what this looks like.
> 
> In ASL (DSDT that ships with the board, or an SSDT that we add after the
> fact - another discussion on how to integrate that at boot time, table
> that for now), under the Device objection, you have a named object (not
> a method) that provides a Package in a known format, something like:
> 
> Package () {
>   Package (2) { "label", "foo" },
>   Package (2) { "value", 1}
>   Package (2) { "devs_indices", Package { _SB.DEV1, 1, _SB.DEV2, 0 }
> }
> 
> NOTE: I've pared off some implementation detail above just to focus on
> what's relevant to this discussion. We're in a mad rush right now
> between working group meetings, writing documentation to explain all
> this, and discussing things here while we have people's attention. All
> important, all time sensitive. I apologize for not just having a
> complete wiki page to point everyone to - but we'll have something a lot
> more concrete *very* shortly.
> 
> When the platform driver discovers pdata is NULL and that there is
> firmware to be probed (dev exists), it starts populating a pdata
> structure with calls like:
> 
> pdata.label = dev_get_property_string("label");
>
> This would go through ACPICA to get the property on this device, but
> could also go through OF on a different system, without any change to
> the driver.

Very minor detail ... do we return the const string pointer or do we
return a copy of it that must be freed ? The latter give more latitude
for quirks or fancy ways to retrieve it in case it's not readily
available but at the expense of more driver complexity and resulting
mistakes causing leaks.

> Of course there will be exceptions in the way certain things are
> represented in each firmware type, but we already have accessors per
> firmware type, so we have the groundwork to deal with those via
> specific-property-type accessors.

Yes.

> > 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.
> 
> Hrm, I was hoping to see it in the properties core (driver core I guess)
> so we didn't have to see every driver. I suppose  we could approach this
> like we do subsystems in general. If we see something repeated enough,
> we abstract it and move it down a level :-)

:-)

> For example, DT and ACPI handle device references differently - but that
> isn't a quirky device-specific kind of thing, it's a firmware
> representation thing, and that should be abstracted away from the driver
> IMO.

Yes. I agree. I was more thinking of "oops, this thing is an int on OF
and a string on ACPI" kind of accidental difference in device specific
properties, or spelling mistakes in property names (_ vs - etc...)

> GPIO is another example (which is actually dependent on the phandle/ACPI
> namespace difference).

Yes, anything that is generic such as resources, references etc...
should be handled there. What is related to a given subsystem (and
common accross drivers of that subsystem) should be handled at the
subsystem level of course, so GPIO fits that category.

Cheers,
Ben.

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

[Linus Walleij]

On Sun, May 18, 2014 at 1:03 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2014-05-16 at 18:54 -0700, Darren Vincent Hart wrote:
>
>> In my opinion, the common dev_get_property() interface which calls the
>> appropriate firmware accessor function makes the most sense. Creating
>> another intermediate format which we then have to make into something
>> useful (like pdata) strikes me as unnecessary and likely limiting.
>
> So in the end it will really depend on whether people are good enough to
> use the same property/value "names" and format accross the
> representations.
>
> So yes, maybe something like dev_get_property() would work fine for
> most cases, which would be great. And for the always necessary quirks
> where for example the ACPI variant used a wrong spelling or the DT
> variant used a different size or something, the driver can either
> openly call different of and acpi variants or we could have quirks in
> the driver itself... ie, a pointer in struct device to a quirk table,
> possibly based on hash of the name for fast lookup. But let's wait
> for some real implementations to see how necessary that really is.

This has already happened with GPIO as DT had named GPIOs
and ACPI yet had not, but could get GPIOs from a certain
index, which DT also could.

So:

gpios = <a, b>;

or:

foo-gpio = <a>;
bar-gpio = <b>;

Whereas in ACPI it would only be the former representation.
So the prototype had to be something like:

GPIO = gpiod_get_index(device, name, index);

So we first look for a named GPIO and if that doesn't work
we look for an indexed GPIO. All fine.

Anyway, then ACPI said they are going to introduce named
GPIOs so all is good. Or is it?

No, they can still choose a totally different name from what
DT is using. So we end up with code like this:

if (gpio = gpiod_get_index(device, "foo", index))
...
else if (gpio = giod_get_index(device, "bar", index))
...

That is however not enough since they can also disagree
with indexed values so that whereas the two GPIO pins
may be gpios = <a, b>; in DT nothing stops the ACPI
guys from putting it in order <b, a> and we get code to
compensate for that instead.

So there are, with the simple example of GPIO, already
a multitude of ways of shooting oneself in the foot, defining
bindings for the same hardware in incompatible ways and
generally screwing up.

And this almost already happened for RFkill but luckily
eventually we stayed clear of some of it by managing
to DEFINE that the RESET GPIO comes at index 0 and
SHUTDOWN GPIO comes at index 1, in BOTH
representations UNLESS they are named, and in that
case the name takes precedence and this file:
net/rfkill/rfkill-gpio.c

Is actually a good example of how things should look.

Looking at that file, do we all think this looks good?

And this is just until the day someone comes along
and admits they shipped a firmware with the GPIOs
swapped.

Beware that GPIO is a *simple* example...

Yours,
Linus Walleij

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

[Darren Vincent Hart]

On Sun, 2014-05-18 at 22:28 +0200, Linus Walleij wrote:
> On Sun, May 18, 2014 at 1:03 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2014-05-16 at 18:54 -0700, Darren Vincent Hart wrote:
> >
> >> In my opinion, the common dev_get_property() interface which calls the
> >> appropriate firmware accessor function makes the most sense. Creating
> >> another intermediate format which we then have to make into something
> >> useful (like pdata) strikes me as unnecessary and likely limiting.
> >
> > So in the end it will really depend on whether people are good enough to
> > use the same property/value "names" and format accross the
> > representations.
> >
> > So yes, maybe something like dev_get_property() would work fine for
> > most cases, which would be great. And for the always necessary quirks
> > where for example the ACPI variant used a wrong spelling or the DT
> > variant used a different size or something, the driver can either
> > openly call different of and acpi variants or we could have quirks in
> > the driver itself... ie, a pointer in struct device to a quirk table,
> > possibly based on hash of the name for fast lookup. But let's wait
> > for some real implementations to see how necessary that really is.
> 
> This has already happened with GPIO as DT had named GPIOs
> and ACPI yet had not, but could get GPIOs from a certain
> index, which DT also could.
> 
> So:
> 
> gpios = <a, b>;
> 
> or:
> 
> foo-gpio = <a>;
> bar-gpio = <b>;
> 
> Whereas in ACPI it would only be the former representation.
> So the prototype had to be something like:
> 
> GPIO = gpiod_get_index(device, name, index);
> 
> So we first look for a named GPIO and if that doesn't work
> we look for an indexed GPIO. All fine.
> 
> Anyway, then ACPI said they are going to introduce named
> GPIOs so all is good. Or is it?
> 
> No, they can still choose a totally different name from what
> DT is using. So we end up with code like this:
> 
> if (gpio = gpiod_get_index(device, "foo", index))
> ...
> else if (gpio = giod_get_index(device, "bar", index))
> ...
> 
> That is however not enough since they can also disagree
> with indexed values so that whereas the two GPIO pins
> may be gpios = <a, b>; in DT nothing stops the ACPI
> guys from putting it in order <b, a> and we get code to
> compensate for that instead.

I see two distinct problems being raised. One on equivalent mechanisms,
and one on parameterization.

With respect to mechanism, it is my understanding that ACPI 5.0 does
provide for GpioIO pin lists, but for some reason, those are rarely used
(and not implemented in the Linux ACPICA). However, it seems to me those
could be used in the same way as <function>-gpios in DT land.

While independent from the ACPI Device Properties work we have been
working on, I wonder if we could address this in some of the
documentation we're preparing as well - as it is intended to document
best practice, and the properties need to interact with the already
defined resource types, such as GPIO.

Rafael - what do you think?

As for parameterization like the function name ("foo" or "bar"), or
which "index", that is what the DT and ACPI Device Properties are meant
to abstract, so I don't see this as a problem. Rather than if/else
blocks in the code as you've described above, those names and indexes
should be read from the device properties.

> 
> So there are, with the simple example of GPIO, already
> a multitude of ways of shooting oneself in the foot, defining
> bindings for the same hardware in incompatible ways and
> generally screwing up.
> 
> And this almost already happened for RFkill but luckily
> eventually we stayed clear of some of it by managing
> to DEFINE that the RESET GPIO comes at index 0 and
> SHUTDOWN GPIO comes at index 1, in BOTH
> representations UNLESS they are named, and in that
> case the name takes precedence and this file:
> net/rfkill/rfkill-gpio.c
> 
> Is actually a good example of how things should look.
> 
> Looking at that file, do we all think this looks good?

Thanks, concrete examples are usually helpful.

It is a good example I think. The only bit I don't like is that
acpi_find_gpio ignores con_id. I'm sure there is a lot of context here
as to why - probably mostly surrounding the fact that while ACPI *CAN*
do this, there hasn't been a standard way of doing it and therefor
nothing we could reliably abstract... I'd like to see if we can improve
that.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Rafael J. Wysocki]

On Sunday, May 18, 2014 09:12:21 AM Darren Vincent Hart wrote:
> On Sun, 2014-05-18 at 22:28 +0200, Linus Walleij wrote:
> > On Sun, May 18, 2014 at 1:03 AM, Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > > On Fri, 2014-05-16 at 18:54 -0700, Darren Vincent Hart wrote:
> > >
> > >> In my opinion, the common dev_get_property() interface which calls the
> > >> appropriate firmware accessor function makes the most sense. Creating
> > >> another intermediate format which we then have to make into something
> > >> useful (like pdata) strikes me as unnecessary and likely limiting.
> > >
> > > So in the end it will really depend on whether people are good enough to
> > > use the same property/value "names" and format accross the
> > > representations.
> > >
> > > So yes, maybe something like dev_get_property() would work fine for
> > > most cases, which would be great. And for the always necessary quirks
> > > where for example the ACPI variant used a wrong spelling or the DT
> > > variant used a different size or something, the driver can either
> > > openly call different of and acpi variants or we could have quirks in
> > > the driver itself... ie, a pointer in struct device to a quirk table,
> > > possibly based on hash of the name for fast lookup. But let's wait
> > > for some real implementations to see how necessary that really is.
> > 
> > This has already happened with GPIO as DT had named GPIOs
> > and ACPI yet had not, but could get GPIOs from a certain
> > index, which DT also could.
> > 
> > So:
> > 
> > gpios = <a, b>;
> > 
> > or:
> > 
> > foo-gpio = <a>;
> > bar-gpio = <b>;
> > 
> > Whereas in ACPI it would only be the former representation.
> > So the prototype had to be something like:
> > 
> > GPIO = gpiod_get_index(device, name, index);
> > 
> > So we first look for a named GPIO and if that doesn't work
> > we look for an indexed GPIO. All fine.
> > 
> > Anyway, then ACPI said they are going to introduce named
> > GPIOs so all is good. Or is it?
> > 
> > No, they can still choose a totally different name from what
> > DT is using. So we end up with code like this:
> > 
> > if (gpio = gpiod_get_index(device, "foo", index))
> > ...
> > else if (gpio = giod_get_index(device, "bar", index))
> > ...
> > 
> > That is however not enough since they can also disagree
> > with indexed values so that whereas the two GPIO pins
> > may be gpios = <a, b>; in DT nothing stops the ACPI
> > guys from putting it in order <b, a> and we get code to
> > compensate for that instead.
> 
> I see two distinct problems being raised. One on equivalent mechanisms,
> and one on parameterization.
> 
> With respect to mechanism, it is my understanding that ACPI 5.0 does
> provide for GpioIO pin lists, but for some reason, those are rarely used
> (and not implemented in the Linux ACPICA). However, it seems to me those
> could be used in the same way as <function>-gpios in DT land.
> 
> While independent from the ACPI Device Properties work we have been
> working on, I wonder if we could address this in some of the
> documentation we're preparing as well - as it is intended to document
> best practice, and the properties need to interact with the already
> defined resource types, such as GPIO.
> 
> Rafael - what do you think?

That depends on what part of the spec you're referring to in particular.
Care to be more specific?

> As for parameterization like the function name ("foo" or "bar"), or
> which "index", that is what the DT and ACPI Device Properties are meant
> to abstract, so I don't see this as a problem. Rather than if/else
> blocks in the code as you've described above, those names and indexes
> should be read from the device properties.

Well, gpiod_get() takes a *name* and that's the preferred interface if
my understanding is correct.  There's no mechanism in ACPI I'm aware of that
can allow a name to be associated with a GPIO pin (or a list of pins for
that matter).

> > So there are, with the simple example of GPIO, already
> > a multitude of ways of shooting oneself in the foot, defining
> > bindings for the same hardware in incompatible ways and
> > generally screwing up.
> > 
> > And this almost already happened for RFkill but luckily
> > eventually we stayed clear of some of it by managing
> > to DEFINE that the RESET GPIO comes at index 0 and
> > SHUTDOWN GPIO comes at index 1, in BOTH
> > representations UNLESS they are named, and in that
> > case the name takes precedence and this file:
> > net/rfkill/rfkill-gpio.c

Well, yeah.

> > Is actually a good example of how things should look.
> > 
> > Looking at that file, do we all think this looks good?
> 
> Thanks, concrete examples are usually helpful.
> 
> It is a good example I think. The only bit I don't like is that
> acpi_find_gpio ignores con_id.

Precisely.  And it can't do anything else ATM.

> I'm sure there is a lot of context here
> as to why - probably mostly surrounding the fact that while ACPI *CAN*

Or can it?  How exactly?

> do this, there hasn't been a standard way of doing it and therefor
> nothing we could reliably abstract... I'd like to see if we can improve
> that.

Well, me too. :-)

Rafael

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

[Catalin Marinas]

Hi Rafael,

On Sat, May 03, 2014 at 01:05:21AM +0100, Rafael J. Wysocki wrote:
> On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> > I labelled this as a tech topic. Feel free to upgrade it to a workshop
> > or relabel it if needed. Base set of people I'd like to see involved
> > are:
> > 
> > * Darren Hart, who is doing things to make ACPI more DT-like for
> > embedded use cases.
> > * Rafael Wysocki, who also has had some ideas on how to make the
> > models fit together.
> > * Grant Likely, since he's in the intersection as well.
> > * Greg K-H would be much appreciated as well, since he'd have to deal
> > with some of the resulting mess.
> > * Dave Woodhouse would also be good to have there.

BTW, that's a topic of high interest to me as well (as arm64 maintainer
and lots of ACPI patches coming my way ;)).

> > All solutions above have trade-offs, and neither is an obvious choice.
> > We could likely spend between now and KS arguing this every day on the
> > lists if we wanted to. Getting the people into the same room for a
> > couple of hours is likely to be a much better way to resolve it.
> 
> For what it's worth, we are working on extending ACPI to allow DT-style
> information to be included into ACPI tables.

That's good as long as it's covered by some future ACPI spec. My biggest
worry on the ARM(64) side is hw vendors being inventive and coming up
with their own (less than standard) ACPI+DT mix.

-- 
Catalin

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

[Rafael J. Wysocki]

On Sunday, May 04, 2014 11:56:12 AM Catalin Marinas wrote:
> Hi Rafael,

Hi,

> On Sat, May 03, 2014 at 01:05:21AM +0100, Rafael J. Wysocki wrote:
> > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> > > I labelled this as a tech topic. Feel free to upgrade it to a workshop
> > > or relabel it if needed. Base set of people I'd like to see involved
> > > are:
> > > 
> > > * Darren Hart, who is doing things to make ACPI more DT-like for
> > > embedded use cases.
> > > * Rafael Wysocki, who also has had some ideas on how to make the
> > > models fit together.
> > > * Grant Likely, since he's in the intersection as well.
> > > * Greg K-H would be much appreciated as well, since he'd have to deal
> > > with some of the resulting mess.
> > > * Dave Woodhouse would also be good to have there.
> 
> BTW, that's a topic of high interest to me as well (as arm64 maintainer
> and lots of ACPI patches coming my way ;)).

Sure. :-)

> > > All solutions above have trade-offs, and neither is an obvious choice.
> > > We could likely spend between now and KS arguing this every day on the
> > > lists if we wanted to. Getting the people into the same room for a
> > > couple of hours is likely to be a much better way to resolve it.
> > 
> > For what it's worth, we are working on extending ACPI to allow DT-style
> > information to be included into ACPI tables.
> 
> That's good as long as it's covered by some future ACPI spec.

There are three levels of this.  First, we need an ACPI configuration object
to put the information into and getting this part into the spec is one of
the goals.  Second, the format of the information has to be specified and
that will probably require an auxiliary document the creation of which is
the next goal.  Finally, we need a specification of the DT bindings for the
IP blocks in question, but that's necessary for entirely DT-based firmware too.

> My biggest worry on the ARM(64) side is hw vendors being inventive and coming
> up with their own (less than standard) ACPI+DT mix.

That's everyone's worry so to speak.  It would be good if we could point them
in the right direction sooner rather than later.

Thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Olof Johansson]

On Sun, May 04, 2014 at 02:19:55PM +0200, Rafael J. Wysocki wrote:
> On Sunday, May 04, 2014 11:56:12 AM Catalin Marinas wrote:
> > Hi Rafael,
> 
> Hi,
> 
> > On Sat, May 03, 2014 at 01:05:21AM +0100, Rafael J. Wysocki wrote:
> > > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> > > > I labelled this as a tech topic. Feel free to upgrade it to a workshop
> > > > or relabel it if needed. Base set of people I'd like to see involved
> > > > are:
> > > > 
> > > > * Darren Hart, who is doing things to make ACPI more DT-like for
> > > > embedded use cases.
> > > > * Rafael Wysocki, who also has had some ideas on how to make the
> > > > models fit together.
> > > > * Grant Likely, since he's in the intersection as well.
> > > > * Greg K-H would be much appreciated as well, since he'd have to deal
> > > > with some of the resulting mess.
> > > > * Dave Woodhouse would also be good to have there.
> > 
> > BTW, that's a topic of high interest to me as well (as arm64 maintainer
> > and lots of ACPI patches coming my way ;)).
> 
> Sure. :-)
> 
> > > > All solutions above have trade-offs, and neither is an obvious choice.
> > > > We could likely spend between now and KS arguing this every day on the
> > > > lists if we wanted to. Getting the people into the same room for a
> > > > couple of hours is likely to be a much better way to resolve it.
> > > 
> > > For what it's worth, we are working on extending ACPI to allow DT-style
> > > information to be included into ACPI tables.
> > 
> > That's good as long as it's covered by some future ACPI spec.
> 
> There are three levels of this.  First, we need an ACPI configuration object
> to put the information into and getting this part into the spec is one of
> the goals.  Second, the format of the information has to be specified and
> that will probably require an auxiliary document the creation of which is
> the next goal.  Finally, we need a specification of the DT bindings for the
> IP blocks in question, but that's necessary for entirely DT-based firmware too.

Some of these things are simple, and some of them can get really really messy:

How are you anticipating handling power management? On x86, will you need to be
able to handle controlling regulators and clocks through common frameworks? If
so, do you have any proposed solutions for how to handle references to those
since firmware usually keeps ownership of those hardware blocks in your
environments?

Same for pin control, where we have frameworks in the kernel on ARM, but
x86/ACPI tends to let firmware handle it all...

> > My biggest worry on the ARM(64) side is hw vendors being inventive and coming
> > up with their own (less than standard) ACPI+DT mix.
> 
> That's everyone's worry so to speak.  It would be good if we could point them
> in the right direction sooner rather than later.


-Olof

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

[Rafael J. Wysocki]

On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:
> On Sun, May 04, 2014 at 02:19:55PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, May 04, 2014 11:56:12 AM Catalin Marinas wrote:

[cut]

> > > > For what it's worth, we are working on extending ACPI to allow DT-style
> > > > information to be included into ACPI tables.
> > > 
> > > That's good as long as it's covered by some future ACPI spec.
> > 
> > There are three levels of this.  First, we need an ACPI configuration object
> > to put the information into and getting this part into the spec is one of
> > the goals.  Second, the format of the information has to be specified and
> > that will probably require an auxiliary document the creation of which is
> > the next goal.  Finally, we need a specification of the DT bindings for the
> > IP blocks in question, but that's necessary for entirely DT-based firmware too.
> 
> Some of these things are simple, and some of them can get really really messy:
> 
> How are you anticipating handling power management? On x86, will you need to be
> able to handle controlling regulators and clocks through common frameworks? If
> so, do you have any proposed solutions for how to handle references to those
> since firmware usually keeps ownership of those hardware blocks in your
> environments?

There is no one simple answer here I'm afraid.

First, there is firmware and there are ACPI tables.  Technically, the ACPI tables
are provided by firware and used by the kernel.  If the kernel chooses not to use
and PM methods from the ACPI tables, it may very well decide to go for controlling
regulators and clocks directly if it knows how to do that.  [Note that the problem
arises only if the ACPI tables contain information on clocks and voltage regulators
*along* *with* ACPI PM methods for devices.]

On some platforms, however, ther is firware in addition to the ACPI tables (that
is, SMM on x86, for example) and *that* firmware may touch those things too in
which case it is better to use the ACPI methods for PM after all.

In my opinion the general rule should be that if ACPI PM methods are used, we
don't manipulate clocks and voltage regulators directly at the same time, because
that may lead to conflicts.  Moreover, the decision whether or not to use ACPI PM
methods cannot be made by individual drivers, because those methods for different
devices may not be mutually independent.  So there needs to be a way to determine
which approach to use upfront and to communicate that to all drivers.

So drivers should not refuse to work if certain PM-related controls are not
available to them and they should not blindly try to use those controls even if
they appear to be available.  If that is assured, things should work.

> Same for pin control, where we have frameworks in the kernel on ARM, but
> x86/ACPI tends to let firmware handle it all...

I would say if pin control information is made available to us by the firmware,
we can use it.  If it is not, we need to live without it.

> > > My biggest worry on the ARM(64) side is hw vendors being inventive and coming
> > > up with their own (less than standard) ACPI+DT mix.
> > 
> > That's everyone's worry so to speak.  It would be good if we could point them
> > in the right direction sooner rather than later.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Linus Walleij]

On Sun, May 4, 2014 at 2:58 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:

>> Same for pin control, where we have frameworks in the kernel on ARM, but
>> x86/ACPI tends to let firmware handle it all...
>
> I would say if pin control information is made available to us by the firmware,
> we can use it.  If it is not, we need to live without it.

I would like to know *how* it will be made available in that case.

What I think will actually happen is this:

- Handling pin control is deemed unnecessary for the kernel in the same
way that early reviews of the subsystem was received: "well we only set
up this once at boot and never touch it, ideally the boot loader/ROM/BIOS
do this and we need not care"

- Further down the road a "uh oh" moment - we *need* to screw around
with pin control - usually due to firmware bugs and power savings - "we
only need to augment this or these pins a little bit here ..."

- Ugliness threatens to invade, pin control subsystem maintainer get
angry.

The thing is: with things like BayTrail I already *know* the pin control
registers are there, they are just not implemented any handling of.
I know very well how much the HW implementers think that a kernel
"should never touch" these registers, and I know it will invariably happen
sooner or later but like to be proven wrong.

Yours,
Linus Walleij

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

[Rafael J. Wysocki]

On Monday, May 05, 2014 07:41:04 PM Linus Walleij wrote:
> On Sun, May 4, 2014 at 2:58 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:
> 
> >> Same for pin control, where we have frameworks in the kernel on ARM, but
> >> x86/ACPI tends to let firmware handle it all...
> >
> > I would say if pin control information is made available to us by the firmware,
> > we can use it.  If it is not, we need to live without it.
> 
> I would like to know *how* it will be made available in that case.
> 
> What I think will actually happen is this:
> 
> - Handling pin control is deemed unnecessary for the kernel in the same
> way that early reviews of the subsystem was received: "well we only set
> up this once at boot and never touch it, ideally the boot loader/ROM/BIOS
> do this and we need not care"
> 
> - Further down the road a "uh oh" moment - we *need* to screw around
> with pin control - usually due to firmware bugs and power savings - "we
> only need to augment this or these pins a little bit here ..."
> 
> - Ugliness threatens to invade, pin control subsystem maintainer get
> angry.
> 
> The thing is: with things like BayTrail I already *know* the pin control
> registers are there, they are just not implemented any handling of.
> I know very well how much the HW implementers think that a kernel
> "should never touch" these registers, and I know it will invariably happen
> sooner or later but like to be proven wrong.

First of all, I have a little influence on people who decide what to expose
and how.

That said, my personal intention is to work towards exposing things that ACPI
has no support for in such a way that the existing code in the kernel can use
them with as few modifications as reasonably possible.

That doesn't mean that we can switch x86 to over DTs (that currently is not an
option for various reasons, not necessarily techical), but we may be able to put
DT-style information that the current code expects to be there into the ACPI
tables.  And if that doesn't happen, for example because vendors don't choose
to do that in their firmware, we still can make it possible to read that
information from an ACPI definition block supplied along with the kernel
(kind of like a dts) and add it to the ACPI namespace during initialization. 

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Linus Walleij]

On Tue, May 6, 2014 at 1:41 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, May 05, 2014 07:41:04 PM Linus Walleij wrote:
(...)
>> The thing is: with things like BayTrail I already *know* the pin control
>> registers are there, they are just not implemented any handling of.
>> I know very well how much the HW implementers think that a kernel
>> "should never touch" these registers, and I know it will invariably happen
>> sooner or later but like to be proven wrong.
(...)

> That doesn't mean that we can switch x86 to over DTs (that currently is not an
> option for various reasons, not necessarily techical), but we may be able to put
> DT-style information that the current code expects to be there into the ACPI
> tables.

In this case I don't care so much about DT or ACPI or whatever, what
I would like to see is that the hardware is adequately described to
the kernel, and the subsystem has a pretty good idea about how to
describe such hardware, and the idea is *not* per-pin properties
tied to some "GPIO" like I have seen, but concepts like groups and
functions and per-pin configuration tied in to a certain use case.

I know DT is doing it right but that is just because the person who
did the heavy lifting, Stephen Warren, was also a co-author of the
pin control subsystem.

Yours,
Linus Walleij

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

[Rafael J. Wysocki]

On Thursday, May 08, 2014 01:36:03 PM Linus Walleij wrote:
> On Tue, May 6, 2014 at 1:41 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, May 05, 2014 07:41:04 PM Linus Walleij wrote:
> (...)
> >> The thing is: with things like BayTrail I already *know* the pin control
> >> registers are there, they are just not implemented any handling of.
> >> I know very well how much the HW implementers think that a kernel
> >> "should never touch" these registers, and I know it will invariably happen
> >> sooner or later but like to be proven wrong.
> (...)
> 
> > That doesn't mean that we can switch x86 to over DTs (that currently is not an
> > option for various reasons, not necessarily techical), but we may be able to put
> > DT-style information that the current code expects to be there into the ACPI
> > tables.
> 
> In this case I don't care so much about DT or ACPI or whatever, what
> I would like to see is that the hardware is adequately described to
> the kernel, and the subsystem has a pretty good idea about how to
> describe such hardware, and the idea is *not* per-pin properties
> tied to some "GPIO" like I have seen, but concepts like groups and
> functions and per-pin configuration tied in to a certain use case.
> 
> I know DT is doing it right but that is just because the person who
> did the heavy lifting, Stephen Warren, was also a co-author of the
> pin control subsystem.

I haven't been following the development of the pin control subsystem and
I'm not familiar with those things, so I'm not sure how I can aswer this.

>From the firmware interface perspective, though, ACPI has no means of
exposing pin control to the OS today and they way for it I can see,
personally, would be to re-use what is done in the DT space.

That's why I was asking the questions about pin control in the other LKML
thread.  [Thanks for you reply BTW, sorry for not responding there, but
I haven't had a chance to read it carefully yet.]

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Darren Vincent Hart]

On Mon, 2014-05-05 at 19:41 -0700, Linus Walleij wrote:
> On Sun, May 4, 2014 at 2:58 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:
> 
> >> Same for pin control, where we have frameworks in the kernel on ARM, but
> >> x86/ACPI tends to let firmware handle it all...
> >
> > I would say if pin control information is made available to us by the firmware,
> > we can use it.  If it is not, we need to live without it.
> 
> I would like to know *how* it will be made available in that case.
> 
> What I think will actually happen is this:
> 
> - Handling pin control is deemed unnecessary for the kernel in the same
> way that early reviews of the subsystem was received: "well we only set
> up this once at boot and never touch it, ideally the boot loader/ROM/BIOS
> do this and we need not care"
> 
> - Further down the road a "uh oh" moment - we *need* to screw around
> with pin control - usually due to firmware bugs and power savings - "we
> only need to augment this or these pins a little bit here ..."
> 
> - Ugliness threatens to invade, pin control subsystem maintainer get
> angry.
> 
> The thing is: with things like BayTrail I already *know* the pin control
> registers are there, they are just not implemented any handling of.
> I know very well how much the HW implementers think that a kernel
> "should never touch" these registers, and I know it will invariably happen
> sooner or later but like to be proven wrong.

I agree with you on this Linus, see my response to Rafael just a minute
ago. I think perhaps we can discuss this separately from this thread? I
have a few other people I'd like to loop in - but it would be a very
specific discussion perhaps rat-holing in this context.

Or possibly you have an LKML thread I need to go find and pick this up
there?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Darren Vincent Hart]

On Sun, 2014-05-04 at 23:58 +0200, Rafael J. Wysocki wrote:
> > Same for pin control, where we have frameworks in the kernel on ARM,
> but
> > x86/ACPI tends to let firmware handle it all...
> 
> I would say if pin control information is made available to us by the
> firmware,
> we can use it.  If it is not, we need to live without it.

This is particularly a problem for designs intended to enable innovation
and spawn derivative products, like the MinnowBoard-Max. While we can
(and do) allow the end-user to toggle between native and GPIO modes for
functional blocks of pins, that's still more limiting than I (speaking
personally here) think it should be.

It made some sense to bury this in firmware when the board was static
and the product had no significant use case where these might need to
change.

On embedded boards though, Pinctrl (or the pins/buses it typically
controls rather) is on par with PCI and USB in terms of how the platform
is expanded to create the product. In my opinion, we will need greater
control at the OS level.

What does that mean for this discussion? The point of the ACPI spec
change is to allow for describing things not currently in the
specification without having to add that specific device type to the
spec. This can apply to pinctrl too, and we can update the
pinctrl-baytrail.c driver (for example) to make use of this new data (or
to use the default behavior if it is absent).

In order to make use of these properties, the driver would of course
need the ability to make such changes in kernel space, and it's a short
step from there to making that available more generally.

This is something I've only recently starting discussing with people.

Perhaps this is too specific an example and Olof had something more
general purpose in mind? 
 
-- 
Darren Hart
Intel Open Source Technology Center

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

[Darren Hart]

On Fri, May 2, 2014 at 2:42 PM, Olof Johansson <olof@lixom.net> wrote:
> I'm about as tired of this as everybody else, but that won't make the
> issues go away...
>
> I think we resolved a bunch of stuff around DT last year (and since),
> but there are still things left to figure out and agree on in these
> areas. In particular in the intersection of Intel platforms with ACPI
> and embedded are where there are issues and model mismatches, and
> doing it in person might be much easier than doing centithreads.
> There's been some various hallway talk at conferences about proposals
> to make this work better, but the full set of people have never been
> in the same room at the same time.
>
> I labelled this as a tech topic. Feel free to upgrade it to a workshop
> or relabel it if needed. Base set of people I'd like to see involved
> are:
>
> * Darren Hart, who is doing things to make ACPI more DT-like for
> embedded use cases.
> * Rafael Wysocki, who also has had some ideas on how to make the
> models fit together.
> * Grant Likely, since he's in the intersection as well.
> * Greg K-H would be much appreciated as well, since he'd have to deal
> with some of the resulting mess.
> * Dave Woodhouse would also be good to have there.

+ Al Stone

-- 
Darren Hart

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

[Linus Walleij]

On this topic I need to add:

how are the ACPI HW descriptions really happening?

I as subsystem maintainer have no real contact with these people,
I can only get a *vague* feeling that sometimes, they live in an ancient
world of assumptions that do not hold.

Specifically I am worried when seeing some ACPI stuff that their idea
of pin control is "some sort of fancy GPIO-bolt on" and I fear they will
attempt to model and implement this with an ugly interface that we
will have to account for later, instead of reading say
Documentation/pinctrl.txt and learn something about how software
engineers go about handling such hardware.

Where is the communication entry port for a driver subsystem
maintainer that want to bring a message to the ACPI HW bindings
people?

Yours,
Linus Walleij

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

[Darren Hart]

On Mon, May 5, 2014 at 9:58 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On this topic I need to add:
>
> how are the ACPI HW descriptions really happening?
>
> I as subsystem maintainer have no real contact with these people,
> I can only get a *vague* feeling that sometimes, they live in an ancient
> world of assumptions that do not hold.
>
> Specifically I am worried when seeing some ACPI stuff that their idea
> of pin control is "some sort of fancy GPIO-bolt on" and I fear they will
> attempt to model and implement this with an ugly interface that we
> will have to account for later, instead of reading say
> Documentation/pinctrl.txt and learn something about how software
> engineers go about handling such hardware.

I was talking with someone just last week about how this might be
done. I'll see if I can get the person looking into it to reach out to
you.

> Where is the communication entry port for a driver subsystem
> maintainer that want to bring a message to the ACPI HW bindings
> people?

Rafael and I would be a good start. He and I, along with others, have
been spending some time lately in the ACPI Specification Working Group
and have some idea of how this stuff works. Matthew Garrett is another
good contact for how to get involved.


-- 
Darren Hart

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

[Darren Vincent Hart]

On Fri, 2014-05-02 at 14:42 -0700, Olof Johansson wrote:
> I'm about as tired of this as everybody else, but that won't make the
> issues go away...
> 
> I think we resolved a bunch of stuff around DT last year (and since),
> but there are still things left to figure out and agree on in these
> areas. In particular in the intersection of Intel platforms with ACPI
> and embedded are where there are issues and model mismatches, and
> doing it in person might be much easier than doing centithreads.
> There's been some various hallway talk at conferences about proposals
> to make this work better, but the full set of people have never been
> in the same room at the same time.
> 
> I labelled this as a tech topic. Feel free to upgrade it to a workshop
> or relabel it if needed. Base set of people I'd like to see involved
> are:
> 
> * Darren Hart, who is doing things to make ACPI more DT-like for
> embedded use cases.

I've been buried, so I apologize for not being able to respond until
now. I'm very interested in participating, and will start catching up
and responding now.

> * Rafael Wysocki, who also has had some ideas on how to make the
> models fit together.

Maybe this is obvious, but Rafael and I are working very closely
together on this from the Intel perspective.

> * Grant Likely, since he's in the intersection as well.
> * Greg K-H would be much appreciated as well, since he'd have to deal
> with some of the resulting mess.
> * Dave Woodhouse would also be good to have there.

David as well as H. Peter Anvin have also been working closely with
Rafael and I.

> 
> .. I'm probably missing names but they're bound to reply to this email
> anyway with opinions.

I saw Al Stone and Linus W. later in the dialog, so I think you have a
good list.

Matthew Garrett offered some valuable insight here in Edinburgh last
year, I imagine he would still want to be involved, although has been
fairly quiet on the subject. 

> 
> 
> Some of the ideas I have heard discussed are:
> * Adding a new common API for resource management which will have
> backends for ACPI or DT depending on platform
> * Adding ACPI and DT probing to drivers that lack on or the other
> today (giving them a total of three probe methods: platform_device,
> DT, ACPI).

Both of the above are the direction we have been exploring.

We should of course include the ACPI Device Properties (_PRP -> now
_DSD) mechanism in here, which I'm sure Rafael and others have already
brought up. I'll follow-up with any technical discussion under those
responses.

> * Converting either of them to use platform device model
> (platform_data) to register drivers, and leave them unaware of either
> hardware description

I've heard this proposed elsewhere and while the platform device model
can certainly be used, if we want to have self-enumerating
hardware/firmware, that would mean moving the parameterization outside
of the driver - which doesn't make sense to me from an encapsulation
perspective. Board files are what they are, but if we are going to
create pdata structures from firmware descriptions, that translation
should occur in the driver where the domain knowledge is.

That's my high-level interest / position here. I'll follow-up now on the
already very active discussion :-)


> * [... I'm likely missing something here as well]
> 
> All solutions above have trade-offs, and neither is an obvious choice.
> We could likely spend between now and KS arguing this every day on the
> lists if we wanted to. Getting the people into the same room for a
> couple of hours is likely to be a much better way to resolve it.
> 
> 
> -Olof

Thank you for proposing this Olof.

-- 
Darren Hart
Intel Open Source Technology Center