Re: [RFH] Power Management mini-summit during the Kernel Summit 2011

Grant Likely
2011-10-17T03:46:22Z

On Sun, Oct 16, 2011 at 8:42 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Sunday, October 16, 2011, Grant Likely wrote:
>> Send me this list of topics that you have.  Some of them are relevant
>> to the ARM community, and we can fit them into the ARM workshop which
>> your are more than welcome to attend.
>
> My topics are, more or less:
>
> - Handling off-the-tree dependencies of devices.
> - Per-device PM QoS (most importantly, how it is supposed to interact with user
>  space).
> - Universal platform drivers idea (common bus type for ACPI, PNP and "platform"
>  devices).
> - Suspend vs wakeup events.

Okay, I think these are interesting and I've added them to the list.
I'm hoping to meet with Nicolas and Arnd tomorrow to hammer out the
schedule for Sunday. You'll be able to find it here[1] when it is
complete.

[1] http://elinux.org/Events/Kernel_Summit_2011_ARM_Subarch_Maintainership_Workshop

Also, since the topic was mentioned, I'd like to take this oportunity
to jot down my thoughts about the universal platform drivers topic. I
was talking to Matthew Garret about this exact thing in Vancouver when
we were comparing the ACPI and FDT implementations in the kernel, and
I was noticing that they use a very similar data model. However,
about a year ago the FDT-specific bus type was eliminated and we moved
to the model where an FDT node pointer can be attached to any struct
device; regardless of bus_type. It turned out to make a great deal of
sense because nodes in the device tree could be any kind of device;
i2c, spi, platform, usb, pci, etc. With this model, there doesn't
need to be a different driver for each data source (static
registration, or FDT, or whatever). A single platform_driver (or
i2c_driver, or spi_driver) could handle all data sources. I think it
is a very useful model to treat data provided by firmware as
supplemental data that can either create or be attached to any device
in the system, but does not have a 1:1 mapping from the firmware
structure to the Linux internal device hierarchy.

Also, since there are strong similarities between the ACPI and FDT
models, I'd like to investigate sharing core infrastructure code
between the subsystems. From the quick look that Matthew and I had, I
think it is certainly possible.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html