Re: [RFC 00/15] ACPI graph support

["Rafael J. Wysocki" <rafael@kernel.org>]

On Thu, Oct 6, 2016 at 10:57 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Oct 05, 2016 at 10:33:47PM +0200, Rafael J. Wysocki wrote:
>> On Wed, Oct 5, 2016 at 6:18 PM, Lorenzo Pieralisi
>> <lorenzo.pieralisi@arm.com> wrote:
>> > On Wed, Oct 05, 2016 at 06:32:29PM +0300, Mika Westerberg wrote:
>> >
>> > [...]
>> >
>> >> > FWIW I had a quick look at dts bindings with "compatible = nokia,smia"
>> >> > and related kernel driver.
>> >> >
>> >> > Those nodes require properties like clocks and power supplies, it
>> >> > seems to me that there are already ACPI PM methods to control those
>> >> > properties and therefore they should not be handled with PRP0001,
>> >> > I am happy to be corrected if I am wrong.
>> >>
>> >> Clocks and power supplies should be handled as native ACPI
>> >> PowerResources. We are not trying to represent those here.
>> >>
>> >> > When you start matching whole subsystem through PRP0001 and related
>> >> > compatible strings you can end up in a situation where DT and ACPI
>> >> > FW handling clash and that's why we were opposed to mixing them from
>> >> > the beginning, in ARM world if we need a DT we boot with a devicetree.
>> >> >
>> >> > If PRP0001 is used for leaf-nodes drivers properties it may work,
>> >> > everything else, frankly, is a bit of a gamble you are taking.
>> >>
>> >> The hardware we are describing is exactly the same, only thing that
>> >> changes is the firmware interface. So if there is a hardware property
>> >> that cannot be discovered automatically it needs to be provided by the
>> >> firmware, like ACPI.
>> >
>> > We certainly agree that HW is the same and that the firmware interfaces
>> > differ, that's why mixing them is not exactly ideal.
>> >
>> >> If it happens that the property already has an existing DT binding, why
>> >> do you think it is gambling to use it instead of inventing the same with
>> >> annother name for ACPI?
>> >
>> > Do not spin the argument. I am telling you that what I am worried
>> > about is mixing the interfaces because that might trigger kernel
>> > control paths clashing while controlling HW (DT native vs ACPI control
>> > methods).
>>
>> That would have been possible, had the *kernel* supported _DSD
>> properties that could have conflict with native ACPI stuff at the
>> framework level.  Yet, it doesn't and there are no plans to add any
>> support like that to it I'm aware of.
>>
>> So far, we have been careful enough to avoid supporting any _DSD
>> properties that may potentially conflict with ACPI-defined HW control,
>> this way or another, and as long as we continue to do that, all should
>> be fine.  So the way to go, to me, is not to reject support for any
>> kind of generic _DSD properties that follow DT bindings, but to look
>> at every case carefully and see if they conflict with ACPI-defined HW
>> control in any way.  If they don't, I see no reason for not supporting
>> them.
>
> I agree with that, I am less optimistic at how we can vet code
> once the fwnode API will allow us to handle DT in ACPI with same
> capabilities as native DT, because let's face it, by augmenting
> the fwnode API through patches like this we are reaching DT kernel
> handling equivalence.
>
> We are coming to this from opposite directions: x86, with FW people
> used to writing ACPI FW (and therefore power resources, etc. usage)
> and ARM FW developers, who could be very very tempted to reuse the
> same DT properties used for clocks/voltage and whatnot into PRP0001
> equivalent completely overriding ACPI control methods and we can't
> argue it is not ACPI standard anymore (or can we ?).

Yes and no, depending on what angle you are looking at it.

On the one hand, it is proper ASL/AML using constructs defined by the
spec and nothing else.  From that perspective, it is following the
standard.

OTOH, the interpretation of it is not defined by the spec proper and
it is Linux-specific, so other OSes won't use this information even if
it is there in your ACPI tables.

> As you said this can only happen once the fwnode API usage trickles
> into the respective subsystems. Can we prevent it ? I hope so and
> we are keeping an eye on that too (that's the reason why I asked
> Mika to widen the audience, BTW), but that's the *only* way to
> prevent this FW bindings mix-up and it is almost impossible to
> vet all code getting into subsystems IMHO.
>
> I am trying to understand why x86 wants to do this, please understand
> our point of view too, we do not want to block progress we want to
> prevent a mess.

It is not "x86" who wants to do that.

It is people who work on support for boards with ACPI firmware and
containing devices that in Linux are handled by DT-centric code.

Of course, the reason why that code is DT-centric is because it was
developed on systems using DT and there were no uses on ACPI-based
systems for it back then.  Still, it is DT-centric as a matter of fact
and *something* has to be done in order to make it work with ACPI.

Basically, there are two choices.  One would be to (a) make ACPI cover
the cases in question and (b) implement code in accordance with that,
but the problem with this approach is the timing (the boards are here
today already).  Another one is to make it possible to provide the
Linux code in question with information it expects from DT, but using
the ACPI interface, limited to information that *can* be provided this
way, and that's where this is going.

And it is not an option for those boards to use DT in the firmware.

>> > I am pretty sure this won't happen, still, if you do not mind
>> > please post this series (and drivers actually making use of it) to a
>> > wider audience (which includes devicetree and ARM mailing list) and we
>> > will restart the discussion from there.
>>
>> I think that the target subsystem (V4L in this particular case) should
>> be notified of this in the first place as they are the user of the
>> bindings in question.
>
> Exactly. This patchset should at least reach DT people and the respective
> subsystem maintainers, I do not think that's too much to ask.

Fair enough.

Thanks,
Rafael