On Monday, October 17, 2011, Grant Likely wrote: > 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. I agree and that's why I'd like to discuss those 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
