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