On Sun, Oct 16, 2011 at 8:42 AM, Rafael J. Wysocki <rjw@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
