"Varadarajan, Charulatha" <charu@xxxxxx> writes: > > >> -----Original Message----- >> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >> Sent: Thursday, June 17, 2010 10:13 PM >> To: Varadarajan, Charulatha >> Cc: Cousson, Benoit; david-b@xxxxxxxxxxx; >> broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx; >> akpm@xxxxxxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; >> paul@xxxxxxxxx; Nayak, Rajendra; tony@xxxxxxxxxxx; Basak, Partha >> Subject: Re: [PATCH 10/13 v3] OMAP: GPIO: Add gpio dev_attr >> and correct clks in OMAP4 hwmod struct >> >> "Varadarajan, Charulatha" <charu@xxxxxx> writes: >> >> [...] >> >> >> >> >> So please, don't do that. >> >> >> >> BTW, you didn't answer the first answer, do you really need that? >> >> >> > It is used in save/restore context which would be called >> > from sram_idle path. >> >> Cleaning this up should be considered instead of keeping around the >> bank count. >> >> The save/restore should be done per-bank whenever the bank usage count >> goes to zero (or changes from zero.) > > When a GPIO is acquired in a particular gpio bank, the gpio bank can still > go to idle if it is called by omap_sram_idle(). In such a case, restore > context will be called even when bank count is not 0. If a GPIO has been requested, then it should have a non-zero usage count. and save/restore should be used. If it has a zero usage count, then save should be done when the usage count goes to zero, and restore should be done when usage count changes from zero. The way it works today is that save/restore is blindly called for all banks every idle path. This should be fixed. Kevin >> >> If you don't want to address that cleanup in this series, add it to >> the TODO list for the cleanups and use the current variable, but it's >> value should be set when iterating over the number of hwmods as >> suggested by Benoit. > > Okay. Will add these changes in my next version of patchset. > >> >> Kevin >> > >>>>>> >>>>>>> + .gpio_bank_bits = 32, >>>>>>> + .dbck_flag = true, >>>>>>> +}; >>>>>> >>>>>> Since this structure is the same than OMAP3, you should maybe consider >>>>>> sharing it. >>>>> >>>>> They are in different _data.c files. I feel that it will be good if they are >>>> kept decoupled as we need not have to mix up different SoC data. Here it's only a >>>> coincidence that OMAP3 and OMAP4 have same data >>>> >>>> No it is not a coincidence, it is because we are re-using the same IP >>>> implementation. In that case, it is not a big deal, but you should try >>>> to reuse as most as you can already existing data. >>> >>> They are in two different omap_hwmod_xxxx_data.c files. Is there a way to share this data? > >> You can use omap_hwmod_common_data.c if you want. > > It is common only for OMAP3/4 and not for OMAP2. But, omap_hwmod_common_data.c is common > for all OMAP2PLUS. Hence will maintain dev_attr for OMAP3&4 in their respective > hwmod database files. > >> Benoit -- 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
