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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Monday, October 17, 2011, Grant Likely wrote:
> 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.

I agree and that's why I'd like to discuss those things.

Thanks,
Rafael