Re: fw_devlink for ACPI - need some pointers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Dec 12, 2020 at 12:19 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Sat, Dec 12, 2020 at 3:13 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
> >
> > Hi ACPI devs,
> >
> > I want to take a stab at adding fw_devlink support for ACPI.
> >
> > fw_devlink adds device links between consumer and supplier devices. It
> > finds the supplier-consumer dependencies by looking at the firmware
> > nodes of devices as they are added to driver core.
> >
> > Main benefits of fw_devlink (because it creates device links):
> > * Removes a lot of deferred probes or probe failures (due to poor
> > error handling).
> > * Makes module load order less important for things to probe successfully.
> > * Makes suspend/resume a bit more robust.
> >
> > For DT (devicetree), I know how to interpret the common properties
> > (Eg: clocks, -gpios, etc) to figure out what devices supply resources
> > for a given device. In general, I'm familiar with DT and there's also
> > Documentation/devicetree/bindings/ that I can grep for if I need to
> > know what a property means. So, I've been able to implement fw_devlink
> > for DT.
> >
> > Now, I want to add support for ACPI to get the ball rolling. However,
> > I'm fairly clueless with it comes to ACPI. So, if I can get some
> > pointers, that'd be great!
> >
> > Things I need help with:
> > 1) I don't even know how to view the ACPI data on my PC. For example,
> > in DT, /sys/firmware/devicetree/ has the entire DT represented as a
> > tree of folders and files. How do I read ACPI info that lists all the
> > devices, their properties, etc?
>
> You can look at the directory structure under
> /sys/devices/LNXSYSTM\:00/ which roughly corresponds to DT contents.

Are these struct acpi_device (the fwnode) or are they actual devices
that'll get probed?

>
> > 2) Is there documentation to look up what each of those device properties mean?
>
> Of course there is.  The docs in Documentation/firmware-guide/acpi/ to
> start with, the ACPI spec and a number of assorted additional pieces.
>
> > 3) How are some of the common device dependencies listed in ACPI? For
> > example, if a device depends on power, clock, GPIO, interrupt, etc how
> > does ACPI list the supplier devices for each of those resources?
>
> That depends.
>
> _DEP is one way to specify dependencies between devices in ACPI, but
> there are others.

What is _DEP? Is it a property? Can I find it as a property in an ACPI fwnode?

What are the other ways of specific dependencies?

> > 4) Assuming there are a few common properties that list the device
> > dependencies, how do I look up a firmware node that a property points
> > to? If this is not how it works, how does it work?
>
> The concept of "properties" as you know them from DT doesn't apply to
> ACPI in general.

Ok. What else could I look at from an ACPI fwnode that might give me
dependency info?

> While it is possible to define "properties" of a device in a way that
> is kind of analogous to DT, it really isn't used in practice.

Mmm... this is what I was wondering/suspecting. With what little I
know about ACPI, it looks like a lot of the HW details is hidden from
the OS. Are all of those details just handled by running
instructions/code that's part of ACPI info that is provisioned?

> Generally speaking, the spec defines the ways to represent various
> types of information etc.

In general, how much of it is actually used by Linux? And how much of
it is Linux just executing code that ACPI provides?

> > In general, any pointers to docs that'll answer the above questions
> > would also be appreciated.
>
> Well, you may find it less compelling than expected, but feel free to
> ask if you have any more specific questions.

So the real question is, is there enough info in ACPI to make
meaningful device links before drivers for devices are loaded? If so,
what part of the ACPI data do I need to look at?

In general, I get the sense most (90%) ACPI devices appear standalone
(no dependencies on other devices) to Linux because they hide all the
clock, power control, IOMMU, and other dependencies in the firmware
somehow. Is my intuition right? I guess TL;DR is, is fw_devlink likely
to be useful for ACPI based machines? I wonder if ACPI provides more
info in the ARM+ACPI world.

-Saravana



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux