linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: balbi@ti.com, khilman@ti.com,
	Grant Likely <grant.likely@secretlab.ca>,
	Tarun Kanti DebBarma <tarun.kanti@ti.com>,
	linux-omap@vger.kernel.org, tony@atomide.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, Charulatha V <charu@ti.com>
Subject: Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
Date: Thu, 2 Feb 2012 23:49:08 +0200	[thread overview]
Message-ID: <20120202214907.GA22888@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <4F2AF68D.1000505@ti.com>

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

Hi,

On Thu, Feb 02, 2012 at 09:48:13PM +0100, Cousson, Benoit wrote:
> On 2/2/2012 8:45 PM, Felipe Balbi wrote:
> >On Thu, Feb 02, 2012 at 12:16:30PM -0700, Grant Likely wrote:
> >>On Thu, Feb 02, 2012 at 08:41:07PM +0200, Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote:
> >>>>diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> >>>>index 0b05629..6ea7390 100644
> >>>>--- a/drivers/gpio/gpio-omap.c
> >>>>+++ b/drivers/gpio/gpio-omap.c
> >>>>@@ -28,7 +28,10 @@
> >>>>  #include<asm/gpio.h>
> >>>>  #include<asm/mach/irq.h>
> >>>>
> >>>>+static LIST_HEAD(omap_gpio_list);
> >>>
> >>>I guess it's now too late because patch is acked and everything, but I
> >>>think if you make the driver handle one bank alone and just instantiate
> >>>it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver
> >>>would be faaaaaar simpler.
> >>
> >>Is there any shared state between the banks?  On my very cursory glance it
> >>looked like banks still have some interaction between them.  If not, then
> >>yes I agree that multiple instances would be better.
> >
> >A quick glance at the TRM shows that banks have separate address spaces
> >and IRQ lines. I think it's done this way because we can handoff one (or
> >more) bank to other cores on the SoC, so they need to be pretty
> >independent.
> >
> >I could be missing something though.
> 
> In fact the driver already handled the 6 GPIOS banks as individual devices:
> 
> [    0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
> [    0.185882] OMAP GPIO hardware version 0.1
> [    0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
> [    0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
> [    0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
> [    0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
> [    0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio

yeah, but you can get all of that for free from driver core. Just add
one platform_device for each bank and make the omap-gpio.c only
understand one bank. No tricks.

What I'm trying to say is to remove the Bank array or list_head and make
probe() get called 6 times by creating 6 omap_gpio platform_devices.

From probe you cann gpiochip_add() once and only once.

> That list is only used to iterate over all the instances during CPU idle:
> 
> void omap2_gpio_prepare_for_idle(int pwr_mode)
> {
> 	struct gpio_bank *bank;
> 
> 	list_for_each_entry(bank, &omap_gpio_list, node) {
> 		if (!bank->mod_usage || !bank->loses_context)
> 			continue;
> 
> 		bank->power_mode = pwr_mode;
> 
> 		pm_runtime_put_sync_suspend(bank->dev);
> 	}
> }
> 
> void omap2_gpio_resume_after_idle(void)
> {
> 	struct gpio_bank *bank;
> 
> 	list_for_each_entry(bank, &omap_gpio_list, node) {
> 		if (!bank->mod_usage || !bank->loses_context)
> 			continue;
> 
> 		pm_runtime_get_sync(bank->dev);
> 	}
> }

that's the thing which is unnecessary, actually :-)

Why do we even have this omap2_gpio_resume_after_idle() ? Can't the gpio
driver handle its own PM or listen to cpuidle notificaitons for that ?

I would like to understand why do we need this hack for pm runtime.
Can't you just use ->prepare() and ->complete() from dev_pm_ops ?

> I don't know if there is some reason to not use driver_for_each_device.

driver_for_each_device() is already handled by driver core. So your
omap_device_build() would have a loop creating N omap_devices, one for
each gpio bank. Each bank would receive one IRQ line and one address
base. And they would only understand that. Every instance of the driver
handles the GPIOs connected on one bank.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-02-02 21:49 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 17:30 [PATCH v9 00/25] gpio/omap: driver cleanup and fixes Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count Tarun Kanti DebBarma
2012-02-02 18:41   ` Felipe Balbi
2012-02-02 19:16     ` Grant Likely
2012-02-02 19:45       ` Felipe Balbi
2012-02-02 20:48         ` Cousson, Benoit
2012-02-02 21:49           ` Felipe Balbi [this message]
2012-02-02 21:53             ` Felipe Balbi
2012-02-02 22:00               ` Cousson, Benoit
2012-02-02 22:07                 ` Felipe Balbi
2012-02-03 17:50                   ` Kevin Hilman
2012-02-04 16:08                     ` Felipe Balbi
2012-02-05  7:07                       ` Varadarajan, Charulatha
2012-02-05  9:08                         ` Felipe Balbi
2012-02-05  9:16                           ` Shilimkar, Santosh
2012-02-05 11:35                             ` Felipe Balbi
2012-02-05 12:35                               ` Shilimkar, Santosh
2012-02-06  6:40                                 ` Felipe Balbi
2012-02-06  5:18                           ` Varadarajan, Charulatha
2012-02-02 17:30 ` [PATCH v9 02/25] gpio/omap: use flag to identify wakeup domain Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 03/25] gpio/omap: make gpio_context part of gpio_bank structure Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 04/25] gpio/omap: handle save/restore context in GPIO driver Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 05/25] gpio/omap: make non-wakeup GPIO part of pdata Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 06/25] gpio/omap: avoid cpu checks during module ena/disable Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 07/25] gpio/omap: further cleanup using wkup_en register Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 08/25] gpio/omap: use level/edge detect reg offsets Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 09/25] gpio/omap: remove hardcoded offsets in context save/restore Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 10/25] gpio/omap: cleanup set_gpio_triggering function Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function Tarun Kanti DebBarma
2012-04-21 14:03   ` Janusz Krzysztofik
2012-04-23 18:54     ` DebBarma, Tarun Kanti
2012-04-24 15:36       ` DebBarma, Tarun Kanti
2012-04-24 16:04         ` Tony Lindgren
2012-04-25  4:34           ` DebBarma, Tarun Kanti
2012-04-25  6:39             ` Shilimkar, Santosh
2012-04-25 12:54               ` DebBarma, Tarun Kanti
2012-04-25 13:45                 ` Russell King - ARM Linux
2012-04-26  5:13                   ` DebBarma, Tarun Kanti
2012-04-27 21:31                     ` Kevin Hilman
2012-04-24 22:37         ` Janusz Krzysztofik
2012-02-02 17:30 ` [PATCH v9 12/25] gpio/omap: use pinctrl offset instead of macro Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 13/25] gpio/omap: remove unnecessary bit-masking for read access Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 14/25] gpio/omap: remove bank->method & METHOD_* macros Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 15/25] gpio/omap: fix bankwidth for OMAP7xx MPUIO Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 16/25] gpio/omap: use pm-runtime framework Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 17/25] gpio/omap: optimize suspend and resume functions Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 18/25] gpio/omap: cleanup prepare_for_idle and resume_after_idle Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 19/25] gpio/omap: fix debounce clock handling Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 20/25] gpio/omap: fix incorrect access of debounce module Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 21/25] gpio/omap: remove omap_gpio_save_context overhead Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 22/25] gpio/omap: save and restore debounce registers Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 23/25] gpio/omap: enable irq at the end of all configuration in restore Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 24/25] gpio/omap: restore OE only after setting the output level Tarun Kanti DebBarma
2012-02-02 17:30 ` [PATCH v9 25/25] gpio/omap: handle set_dataout reg capable IP on restore Tarun Kanti DebBarma
2012-02-02 19:42 ` [PATCH v9 00/25] gpio/omap: driver cleanup and fixes Grant Likely
2012-02-03 17:51   ` Kevin Hilman
2012-02-03 21:16     ` Grant Likely
2012-02-03  9:21 ` Hebbar, Gururaja
     [not found]   ` <CAC83ZvLoYVofH9oKXw92i-=DbP2i3NfZjLGSJwk1j0JvXcFZVQ@mail.gmail.com>
2012-02-03 12:09     ` Hebbar, Gururaja
2012-02-03 21:01 ` Kevin Hilman
2012-02-06 11:53   ` DebBarma, Tarun Kanti
2012-02-10 19:24 ` Tony Lindgren
2012-02-10 19:55   ` Kevin Hilman
2012-02-13  5:33     ` DebBarma, Tarun Kanti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120202214907.GA22888@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=b-cousson@ti.com \
    --cc=charu@ti.com \
    --cc=grant.likely@secretlab.ca \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tarun.kanti@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).