* Dave Gerlach <d-gerlach@xxxxxx> [150226 12:05]: > Tony, > On 01/05/2015 04:51 PM, Tony Lindgren wrote: > > * Dave Gerlach <d-gerlach@xxxxxx> [150105 14:51]: > >> Felipe, > >> On 01/02/2015 02:16 PM, Felipe Balbi wrote: > >>> On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote: > >>>> Introduce a wkup_m3_ipc driver to handle communication between the MPU > >>>> and Cortex M3 wkup_m3 present on am335x. > >>>> > >>>> This driver is responsible for actually booting the wkup_m3_rproc and > >>>> also handling all IPC which is done using the IPC registers in the control > >>>> module, a mailbox, and a separate interrupt back from the wkup_m3. A small > >>>> API is exposed for executing specific power commands, which include > >>>> configuring for low power mode, request a transition to a low power mode, > >>>> and status info on a previous transition. > >>>> > >>>> Signed-off-by: Dave Gerlach <d-gerlach@xxxxxx> > >>>> --- > >>>> drivers/soc/ti/Kconfig | 11 ++ > >>>> drivers/soc/ti/Makefile | 1 + > >>>> drivers/soc/ti/wkup_m3_ipc.c | 451 +++++++++++++++++++++++++++++++++++++++++++ > >>>> include/linux/wkup_m3_ipc.h | 33 ++++ > >>>> 4 files changed, 496 insertions(+) > >>>> create mode 100644 drivers/soc/ti/wkup_m3_ipc.c > >>>> create mode 100644 include/linux/wkup_m3_ipc.h > >>>> > >>>> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig > >>>> index 7266b21..61cda85 100644 > >>>> --- a/drivers/soc/ti/Kconfig > >>>> +++ b/drivers/soc/ti/Kconfig > >>>> @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA > >>>> > >>>> If unsure, say N. > >>>> > >>>> +config WKUP_M3_IPC > >>>> + bool "TI AM33XX Wkup-M3 IPC Driver" > >>> > >>> tristate ? > >> > >> If we want to allow this and the rproc driver to be built as modules than we can > >> change this. > > > > Yes please, the PM is never needed early, and should be optional. > > And doing that will make it a lot easier for you to do further work > > on your driver ;) > > > > And it will also make it easier to add support for other SoCs as > > it seems the same M3 is used at least on am437x. > > > > I can not build the PM code as a module at this time due to many mach-omap > function calls it uses which are not exported, so I need handles to all five > functions in this driver used in pm33xx to call from built-in PM code. Do you > have a preference on how these function handles get passed? OK, you can pass the function pointers in platform_data. Care to list those functions? That might allow us to make other omap PM code into loadable modules in drivers/* :) > I currently have added a pdata-quirks implementation that passes a function to > the wkup_m3_ipc driver through it's pdata which it then calls at probe to pass a > struct containing all used function pointers to the pm code that were previously > called directly. Is that what you would prefer or something else? I had also > looked at making the struct of function pointers in the driver global and just > picking it up from the pm code with an extern declaration or even putting a bus > notifier in the PM code and watching for the wkup_m3_ipc driver to be bound. Yeah pdata-quirks.c is probably OK for populating the function pointers. We may have already some place in the PM code to pass it too. > Thought I would see what you prefer and possibly avoid an unnecessary re-spin. Sounds like we're getting close to getting am335x/am437x PM code working :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
