On Tue, Oct 11, 2016 at 1:44 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > On Thu, Oct 6, 2016 at 11:37 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: >> On Thu, Oct 06, 2016 at 02:26:50PM +0200, Rafael J. Wysocki wrote: >>> On Thu, Oct 6, 2016 at 10:57 AM, Lorenzo Pieralisi >> >>> > 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. >> >> Yes, it's important to remember that there's a whole world of other >> people using ACPI on x86 who are doing different things. I have to say >> I'm not sure how DT centric we really are, there's a lot of things that >> have been around since before DT. > > When I said "DT-centric" I really meant "full of of_* calls retrieving > data from a DT". > >>> 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. >> >> Personally I don't have that big a concern around per device >> properties other than the need to go through yet another round of >> churn for them (though it is just mechanical which will make it less >> painful). I do worry when it goes to generic things and inter-device >> relationships. > > Well, that was my first reaction to this series, but then I thought > "Let's see what can go wrong with this specifically" and then I > couldn't find anything. > > If you see something like that, please let me know, because I may be > overlooking it, but otherwise I would prefer to focus on the technical > side of things instead of wast^Hspending time on theoretical worries. > >>> And it is not an option for those boards to use DT in the firmware. >> >> There's nothing stopping these systems defining a DSD that contains a >> DTB which overrides some or all of the ACPI if the system supports it >> (or otherwise providing both system descriptions). The two can coexist >> happily enough as arm64 has shown > > I'm not sure to what extent it has shown that and even so, it doesn't > mean this is a good idea. > >> and it seems like it ought to save a >> whole lot of work especially around the bits that need inter device >> links and are hence need some new ACPI bindings defining. > > There is at least one major problem with this approach. If the ACPI > part needs to point to anything in the DTB or if the DTB part needs to > point to the ACPI part outside of it, there's no clean way that could > be done. I actually am not aware of any way whatever, but if there > are some, I kind of don't expect them to be pretty. > >> I can see that removing ACPI entirely would present serious difficulties >> but it's less clear to me how much is really gained by having an >> embedded Linux specific ACPI variant over having some Linux specific >> data in ACPI that happens to be parsable as DT. The circumstances that >> the two platforms face appear to be very similar. > > I'm not really sure what you mean here. > > _DSD properties can convey the same information as DT in the same > layout. The only difference is that DT uses phandles to point to > things and _DSD properties use ACPI namespace paths for this purpose. > That actually is where code changes need to be made, the rest is > already there. In fact, from the utility perspective, _DSD properties are just like an "embedded DTB" you talked about, except that they are represented in ASL (which makes them easier to handle in a couple of ways) and use namespace paths instead of phandles to point to things. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
