Re: [PATCH:v4 12/13] OMAP: GPIO: Implement GPIO as a platform device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Charulatha V <charu@xxxxxx> writes:

> This patch implements GPIO as a platform device. Also it
> implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
> This patch makes GPIO to use runtime APIs.
>
> GPIO APIs are used in machine_init functions. Hence it is
> required to complete GPIO probe before machine_init. Therefore
> GPIO device register and driver register are implemented as
> postcore_initcalls.
>
> Inorder to convert GPIO as platform device, modifications are
> required in clockxxxx_data.c file for OMAP1 so that device names
> can be used to obtain clock instead of getting clocks by
> name/NULL ptr.
>
> omap_gpio_init() does nothing now and this function would be
> removed in the next patch as it's usage is spread across most of
> the board files.
>
> TODO:
> 1. Cleanup the GPIO driver. Use function pointers and register
> offest pointers instead of using hardcoded values
> 2. Remove all cpu_is_ checks and OMAP specific macros
> 3. Remove usage of gpio_bank array so that only
> instance specific information is used in driver code
> 4. Modify save/restore context, gpio_prepare_for_idle,
> and gpio_resume_after_idle functions as instance
> specific function and not for all instances in a single call

init_gpio_info() too.

I think this item (TODO #4) needs to be done as part of this series, as
this new generic driver needs to be completely ignorant of how many
banks are on chip, or currently in use.  All operations should be on a
single device (in this case, a single GPIO bank.)

As each hwmod has its own device, it can have it's own independent
suspend/resume.  To do this, you should remove the sysdev_class and
sys_device just use the regular device.  Here's a little patch[1] on top
of your current series that shows how you would hook up the standard PM
methods.  Also, the prepare_for_idle, resume_from_idle should be handled
by the runtime PM callbacks.

With the save/restore context handled on demand (when mod_usage
transitions to/from zero), and the runtime PM calls handled from within
the driver, we could get rid of all the GPIO calls from
omap_sram_idle().  That would be a huge improvement.

Kevin

[1] compile-tested only

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 6dc5e4b..6a5a8f4 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2091,10 +2091,44 @@ void omap_gpio_restore_context(void)
 }
 #endif
 
+static int gpio_bank_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int gpio_bank_resume(struct device *dev)
+{
+	return 0;
+}
+
+static int gpio_bank_runtime_idle(struct device *dev)
+{
+	return 0;
+}
+
+static int gpio_bank_runtime_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int gpio_bank_runtime_resume(struct device *dev)
+{
+	return 0;
+}
+
+static struct dev_pm_ops gpio_pm_ops = {
+	.suspend	 = gpio_bank_suspend,
+	.resume		 = gpio_bank_resume,
+	.runtime_idle	 = gpio_bank_runtime_idle,
+	.runtime_suspend = gpio_bank_runtime_suspend,
+	.runtime_resume	 = gpio_bank_runtime_resume,
+};
+
 static struct platform_driver omap_gpio_driver = {
 	.probe		= omap_gpio_probe,
 	.driver		= {
 		.name	= "omap-gpio",
+		.pm	= &gpio_pm_ops,
 	},
 };
 


--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux