Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Hi Charu, On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board How did you get some top secret samples of the ultra new *44430* device running at 16.5 GHz? That device should not be released publicly before 10 years ;-) Benoit and zoom3 board. Verified that this patch series does not break the OMAP1 build. Version History: --- v7 Series: - Use gpio iclks as main_clk in OMAP3 OMAP4 - Implement GPIO as a platform device (use hwmod FW for OMAP2+) and the implementation is similar to current GPIO code. Does not modify the gpio suspend/ resume/ prepare for odle and resume after idle code and these modifications would be done in a separate patch series. This was suggested by Kevin in another internal email thread. v6 Series: Some links for v6 series: https://patchwork.kernel.org/patch/189742/ https://patchwork.kernel.org/patch/189822/ https://patchwork.kernel.org/patch/189832/ Comments Fixed in v6: -use PM runtime APIs for gpio in cpu idle/resume after idle path when interrupts are enabled. -Do not use omap_device_* calls in the gpio driver -Use clock alias names for debounce clocks while using clock framework APIs to do clk_get. -do a kfree of pdata after doing omap_device_build() -use PM runtime APIs during probe before and after accessing gpio registers -Remove sysconfig register access from GPIO driver -Use ARRAY_SIZE instead on size_of in OMAP1 gpio_init v5 Series: Some links for v5 series: https://patchwork.kernel.org/patch/117790/ https://patchwork.kernel.org/patch/117789/ https://patchwork.kernel.org/patch/117788/ https://patchwork.kernel.org/patch/117785/ https://patchwork.kernel.org/patch/117796/ Comments Fixed in v5: - Use dev_pm_ops instead of sys_dev_class - Use runtime suspend/resume hooks for GPIO device - extend the usage of mod_usage flag to all cpu classes.(Earlier it was used only for OMAP2+) - Make gpio_context as part of gpio_bank structure v4 Series: Some links for v4 series: https://patchwork.kernel.org/patch/107411/ Comments Fixed in v4: - Remove gpio_bank_count from dev_attr field and derive it from hwmod class iteration count - Add TODOs for future omap gpio code cleanup related activity - Rename gpio's platform_data 'method' to 'bank_type' - Rename gpio's platform_data 'gpio_bank_bits' to 'gpio_bank_width' - Add 'rev' field to gpio class in hwmod datbase and get 'bank_type' based on 'rev' field - Filename removed from file description when a new file is created v3 Series: Some of the v3 links: https://patchwork.kernel.org/patch/106224/ Comments Fixed in v3: - .module_offs populated in hwmod structures - If not defined CONFIG_PM_RUNTIME is not handled in GPIO driver - No changes to mach-omap2/clock-data.c to handle clocks by dev ptr as it is taken care using clock get by name in hwmod omap_device layer - Using ick instead of arm_gpio_ck for OMAP15xx clock - SoC base addresses moved to plat-omap/omap.h that should be used only by the omap_hwmod__data.c file - OMAP2/3 hwmod structures naming convention changed as it is followed in OMAP4 - omap24xx_gpio_init() uses cpu_is_omap24xx() instead of separate checks for 2420 2430 in OMAP2 specific init call (mach-omap layer) - Reason for using postcore_initcall is added to patch description - Comments added for usage of dbck_flag and other elements in dev_attr structure - Uses dev_dbg() and dev_err() instead of pr_dbg() and pr_err() - Corrects the gpio clock details in OMAP4 hwmod database v2 series: Some important links to patch v2 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30262.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28787.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30263.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30295.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30259.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28933.html Comments Fixed in V2: - GPIO dev attr was added for SoC specific chip info (eg., gpio bank count) - Removed omap_gpio_init() usage from board files - platform_get_resource() used instead of pdata-base for OMAP2+ base addresses - postcore_initcall used for gpio init instead of making GPIO as an early platform device. SoC specific gpio_init needs to be done before machine_init functions access gpio APIs. Hence making SoC specific gpio_init as postcore_initcall. - getting gpio dbck is moved to omap_set_gpio_debounce() instead of doing it in probe v1 series: Some important links to patch v1 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26934.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27860.html
Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Varadarajan, Charulatha ch...@ti.com writes: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board and zoom3 board. Verified that this patch series does not break the OMAP1 build. Version History: --- v7 Series: - Use gpio iclks as main_clk in OMAP3 OMAP4 - Implement GPIO as a platform device (use hwmod FW for OMAP2+) and the implementation is similar to current GPIO code. Does not modify the gpio suspend/ resume/ prepare for odle and resume after idle code and these modifications would be done in a separate patch series. This was suggested by Kevin in another internal email thread. OK, I'm ready to merge this series, and we can deal with the runtime PM conversion in another series as that's where the tricky part lies. However, I'd like one more rebase/retest due to some other dependencies. Can you rebase/retest using my current pm-core branch? That includes several dependencies that are also targetted for 2.6.38: - misc. PM fixes - i2c hwmod + runtime PM conversion (my pm-hwmod-i2c branch) - several board file changes/updates (Tony's devel-board branch) - hwmod core fixes (Paul's hwmod_a_2.6.38 branch) - wdt hwmod cleanups (Paul's wdt_2.6.38 branch) Also, can you collect the acks from Benoît and update your changelogs to include them. Thanks. Please be sure your board file changes are updated for the board file changes in the devel-board branch. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
On Thu, Nov 25, 2010 at 02:28, Cousson, Benoit b-cous...@ti.com wrote: Hi Charu, On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board How did you get some top secret samples of the ultra new *44430* device running at 16.5 GHz? That device should not be released publicly before 10 years ;-) Typo!! My bad :-( !!! Thanks for finding it. But nice to know that *44430* device would be running at 16.5 GHz ;-) Benoit snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Kevin, On Thu, Nov 25, 2010 at 07:10, Kevin Hilman khil...@deeprootsystems.com wrote: Varadarajan, Charulatha ch...@ti.com writes: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board and zoom3 board. Verified that this patch series does not break the OMAP1 build. Version History: --- v7 Series: - Use gpio iclks as main_clk in OMAP3 OMAP4 - Implement GPIO as a platform device (use hwmod FW for OMAP2+) and the implementation is similar to current GPIO code. Does not modify the gpio suspend/ resume/ prepare for odle and resume after idle code and these modifications would be done in a separate patch series. This was suggested by Kevin in another internal email thread. OK, I'm ready to merge this series, and we can deal with the runtime PM conversion in another series as that's where the tricky part lies. Thanks. However, I'd like one more rebase/retest due to some other dependencies. Can you rebase/retest using my current pm-core branch? Sure I will do that. That includes several dependencies that are also targetted for 2.6.38: - misc. PM fixes - i2c hwmod + runtime PM conversion (my pm-hwmod-i2c branch) - several board file changes/updates (Tony's devel-board branch) - hwmod core fixes (Paul's hwmod_a_2.6.38 branch) - wdt hwmod cleanups (Paul's wdt_2.6.38 branch) Also, can you collect the acks from Benoît and update your changelogs to include them. Thanks. Sure. Please be sure your board file changes are updated for the board file changes in the devel-board branch. Okay. But if it is different, should I send only the board files changes on devel-board branch as a separate patch mentioning the dependencies on my patch series? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Hi Charu, [...] Please be sure your board file changes are updated for the board file changes in the devel-board branch. Okay. But if it is different, should I send only the board files changes on devel-board branch as a separate patch mentioning the dependencies on my patch series? My pm-core includes the devel-board branch since it's part of Tony's for-next, so that shouldn't be necessary. However, if you find it's easier to break it into separate series feel free, as long as the dependencies are mentioned. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
On Thu, Nov 25, 2010 at 11:49, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Charu, [...] Please be sure your board file changes are updated for the board file changes in the devel-board branch. Okay. But if it is different, should I send only the board files changes on devel-board branch as a separate patch mentioning the dependencies on my patch series? My pm-core includes the devel-board branch since it's part of Tony's for-next, so that shouldn't be necessary. However, if you find it's easier to break it into separate series feel free, as long as the dependencies are mentioned. Okay. Thanks. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board and zoom3 board. Verified that this patch series does not break the OMAP1 build. Version History: --- v7 Series: - Use gpio iclks as main_clk in OMAP3 OMAP4 - Implement GPIO as a platform device (use hwmod FW for OMAP2+) and the implementation is similar to current GPIO code. Does not modify the gpio suspend/ resume/ prepare for odle and resume after idle code and these modifications would be done in a separate patch series. This was suggested by Kevin in another internal email thread. v6 Series: Some links for v6 series: https://patchwork.kernel.org/patch/189742/ https://patchwork.kernel.org/patch/189822/ https://patchwork.kernel.org/patch/189832/ Comments Fixed in v6: -use PM runtime APIs for gpio in cpu idle/resume after idle path when interrupts are enabled. -Do not use omap_device_* calls in the gpio driver -Use clock alias names for debounce clocks while using clock framework APIs to do clk_get. -do a kfree of pdata after doing omap_device_build() -use PM runtime APIs during probe before and after accessing gpio registers -Remove sysconfig register access from GPIO driver -Use ARRAY_SIZE instead on size_of in OMAP1 gpio_init v5 Series: Some links for v5 series: https://patchwork.kernel.org/patch/117790/ https://patchwork.kernel.org/patch/117789/ https://patchwork.kernel.org/patch/117788/ https://patchwork.kernel.org/patch/117785/ https://patchwork.kernel.org/patch/117796/ Comments Fixed in v5: - Use dev_pm_ops instead of sys_dev_class - Use runtime suspend/resume hooks for GPIO device - extend the usage of mod_usage flag to all cpu classes.(Earlier it was used only for OMAP2+) - Make gpio_context as part of gpio_bank structure v4 Series: Some links for v4 series: https://patchwork.kernel.org/patch/107411/ Comments Fixed in v4: - Remove gpio_bank_count from dev_attr field and derive it from hwmod class iteration count - Add TODOs for future omap gpio code cleanup related activity - Rename gpio's platform_data 'method' to 'bank_type' - Rename gpio's platform_data 'gpio_bank_bits' to 'gpio_bank_width' - Add 'rev' field to gpio class in hwmod datbase and get 'bank_type' based on 'rev' field - Filename removed from file description when a new file is created v3 Series: Some of the v3 links: https://patchwork.kernel.org/patch/106224/ Comments Fixed in v3: - .module_offs populated in hwmod structures - If not defined CONFIG_PM_RUNTIME is not handled in GPIO driver - No changes to mach-omap2/clock-data.c to handle clocks by dev ptr as it is taken care using clock get by name in hwmod omap_device layer - Using ick instead of arm_gpio_ck for OMAP15xx clock - SoC base addresses moved to plat-omap/omap.h that should be used only by the omap_hwmod__data.c file - OMAP2/3 hwmod structures naming convention changed as it is followed in OMAP4 - omap24xx_gpio_init() uses cpu_is_omap24xx() instead of separate checks for 2420 2430 in OMAP2 specific init call (mach-omap layer) - Reason for using postcore_initcall is added to patch description - Comments added for usage of dbck_flag and other elements in dev_attr structure - Uses dev_dbg() and dev_err() instead of pr_dbg() and pr_err() - Corrects the gpio clock details in OMAP4 hwmod database v2 series: Some important links to patch v2 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30262.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28787.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30263.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30295.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30259.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28933.html Comments Fixed in V2: - GPIO dev attr was added for SoC specific chip info (eg., gpio bank count) - Removed omap_gpio_init() usage from board files - platform_get_resource() used instead of pdata-base for OMAP2+ base addresses - postcore_initcall used for gpio init instead of making GPIO as an early platform device. SoC specific gpio_init needs to be done before machine_init functions access gpio APIs. Hence making SoC specific gpio_init as postcore_initcall. - getting gpio dbck is moved to omap_set_gpio_debounce() instead of doing it in probe v1 series: Some important links to patch v1 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26934.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27860.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28183.html Highlights in v1: - Introduces SoC specific functions at mach-omap layer - Implements GPIO as a platform device - Make gpio an early device and make it implemented in Benoit Cousson (1): OMAP4: hwmod data: Add GPIO Varadarajan, Charulatha (10):
