From: Kevin Hilman <khilman@linaro.org> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Felipe Balbi <balbi@ti.com>, Tony Lindgren <tony@atomide.com>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Mon, 18 Feb 2013 06:52:35 -0800 [thread overview] Message-ID: <87vc9p4qto.fsf@linaro.org> (raw) In-Reply-To: <511F1245.60208@ti.com> (Santosh Shilimkar's message of "Sat, 16 Feb 2013 10:29:49 +0530") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote: >> Felipe Balbi <balbi@ti.com> writes: >> >>> Currently the omap-serial driver will not >>> work properly if booted via DT with CPUIDLE >>> enabled because it depends on function pointers >>> provided by hwmod to change its own SYSCONFIG >>> register. >>> >>> Remove that relyance on hwmod by moving SYSCONFIG >>> handling to driver itself. Note that this also >>> fixes a possible corner case bug where we could >>> be putting UART in Force Idle mode if we called >>> omap_serial_enable_wakeup(up, false) after setting >>> NOIDLE to the idle mode. This is because hwmod >>> has no protection against that situation. >>> >>> NYET-Signed-off-by: Felipe Balbi <balbi@ti.com> >> >> Here's another approach to getting rid of the sysconfig twiddling in the >> driver. I wrote this some time ago at my former company ;) but don't >> think I ever got around to posting it. >> >> It doesn't solve the whole problem (e.g. doesn't address the >> context_loss or enable_wakeup func pointers), but at least gets rid of >> the need for any SYSCONFIG access in the driver for the idle modes. >> >> Needs more thorough testing. >> > I posted similar patch series[1] yesterday after testing it on OMAP4/5 > devices. OMAP3 testing seems to be ok as well. AM3XXX and OMAP2 test > results is what am waiting for. Yeah, I saw yours after I posted mine. Just continue with yours, I'll be glad to have someone else take this on. > Good to know that you had similar idea in mind to get rid of > UART sysc hackery. Likewise. Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@linaro.org (Kevin Hilman) To: linux-arm-kernel@lists.infradead.org Subject: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Mon, 18 Feb 2013 06:52:35 -0800 [thread overview] Message-ID: <87vc9p4qto.fsf@linaro.org> (raw) In-Reply-To: <511F1245.60208@ti.com> (Santosh Shilimkar's message of "Sat, 16 Feb 2013 10:29:49 +0530") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote: >> Felipe Balbi <balbi@ti.com> writes: >> >>> Currently the omap-serial driver will not >>> work properly if booted via DT with CPUIDLE >>> enabled because it depends on function pointers >>> provided by hwmod to change its own SYSCONFIG >>> register. >>> >>> Remove that relyance on hwmod by moving SYSCONFIG >>> handling to driver itself. Note that this also >>> fixes a possible corner case bug where we could >>> be putting UART in Force Idle mode if we called >>> omap_serial_enable_wakeup(up, false) after setting >>> NOIDLE to the idle mode. This is because hwmod >>> has no protection against that situation. >>> >>> NYET-Signed-off-by: Felipe Balbi <balbi@ti.com> >> >> Here's another approach to getting rid of the sysconfig twiddling in the >> driver. I wrote this some time ago at my former company ;) but don't >> think I ever got around to posting it. >> >> It doesn't solve the whole problem (e.g. doesn't address the >> context_loss or enable_wakeup func pointers), but at least gets rid of >> the need for any SYSCONFIG access in the driver for the idle modes. >> >> Needs more thorough testing. >> > I posted similar patch series[1] yesterday after testing it on OMAP4/5 > devices. OMAP3 testing seems to be ok as well. AM3XXX and OMAP2 test > results is what am waiting for. Yeah, I saw yours after I posted mine. Just continue with yours, I'll be glad to have someone else take this on. > Good to know that you had similar idea in mind to get rid of > UART sysc hackery. Likewise. Kevin
next prev parent reply other threads:[~2013-02-18 14:52 UTC|newest] Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-14 11:15 [RFC/NOT FOR MERGING 1/3] arm: omap: use generic implementation if !od Felipe Balbi 2013-02-14 11:15 ` Felipe Balbi 2013-02-14 11:15 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Felipe Balbi 2013-02-14 17:12 ` Tony Lindgren 2013-02-14 17:12 ` Tony Lindgren 2013-02-14 17:56 ` Felipe Balbi 2013-02-14 17:56 ` Felipe Balbi 2013-02-14 18:12 ` Tony Lindgren 2013-02-14 18:12 ` Tony Lindgren 2013-02-14 19:27 ` Felipe Balbi 2013-02-14 19:27 ` Felipe Balbi 2013-02-14 19:39 ` Tony Lindgren 2013-02-14 19:39 ` Tony Lindgren 2013-02-14 20:47 ` Paul Walmsley 2013-02-14 20:47 ` Paul Walmsley 2013-02-14 21:40 ` Paul Walmsley 2013-02-14 21:40 ` Paul Walmsley 2013-02-14 22:47 ` Tony Lindgren 2013-02-14 22:47 ` Tony Lindgren 2013-02-15 6:46 ` Felipe Balbi 2013-02-15 6:46 ` Felipe Balbi 2013-02-15 7:29 ` Santosh Shilimkar 2013-02-15 7:29 ` Santosh Shilimkar 2013-02-19 15:30 ` Paul Walmsley 2013-02-19 15:30 ` Paul Walmsley 2013-02-19 15:45 ` Russell King - ARM Linux 2013-02-19 15:45 ` Russell King - ARM Linux 2013-02-19 16:30 ` Tony Lindgren 2013-02-19 16:30 ` Tony Lindgren 2013-02-19 18:22 ` Russell King - ARM Linux 2013-02-19 18:22 ` Russell King - ARM Linux 2013-02-19 19:31 ` Tony Lindgren 2013-02-19 19:31 ` Tony Lindgren 2013-02-19 19:43 ` hwmod data duplication (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency) Felipe Balbi 2013-02-19 19:43 ` Felipe Balbi 2013-02-19 22:09 ` Tony Lindgren 2013-02-19 22:09 ` Tony Lindgren 2013-02-19 22:22 ` Felipe Balbi 2013-02-19 22:22 ` Felipe Balbi 2013-02-19 22:31 ` Tony Lindgren 2013-02-19 22:31 ` Tony Lindgren 2013-02-19 22:51 ` Felipe Balbi 2013-02-19 22:51 ` Felipe Balbi 2013-02-15 10:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Russell King - ARM Linux 2013-02-15 10:26 ` Russell King - ARM Linux 2013-02-14 21:56 ` Paul Walmsley 2013-02-14 21:56 ` Paul Walmsley 2013-02-14 22:22 ` Tony Lindgren 2013-02-14 22:22 ` Tony Lindgren 2013-02-15 6:53 ` Felipe Balbi 2013-02-15 6:53 ` Felipe Balbi 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-19 15:27 ` Paul Walmsley 2013-02-19 15:27 ` Paul Walmsley 2013-02-19 16:38 ` Tony Lindgren 2013-02-19 16:38 ` Tony Lindgren 2013-02-19 16:57 ` Felipe Balbi 2013-02-19 16:57 ` Felipe Balbi 2013-02-19 17:43 ` Tony Lindgren 2013-02-19 17:43 ` Tony Lindgren 2013-02-19 18:34 ` Felipe Balbi 2013-02-19 18:34 ` Felipe Balbi 2013-02-19 19:16 ` Kevin Hilman 2013-02-19 19:16 ` Kevin Hilman 2013-02-19 19:32 ` Felipe Balbi 2013-02-19 19:32 ` Felipe Balbi 2013-02-19 19:50 ` Kevin Hilman 2013-02-19 19:50 ` Kevin Hilman 2013-02-19 20:10 ` OMAP reset requirements (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency) ^[:x Felipe Balbi 2013-02-19 20:10 ` OMAP reset requirements (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency)^[:x Felipe Balbi 2013-02-19 20:25 ` OMAP reset requirements Kevin Hilman 2013-02-19 20:25 ` Kevin Hilman 2013-02-20 6:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Santosh Shilimkar 2013-02-20 6:26 ` Santosh Shilimkar 2013-02-15 6:44 ` Felipe Balbi 2013-02-15 6:44 ` Felipe Balbi 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-20 17:38 ` Paul Walmsley 2013-02-20 17:38 ` Paul Walmsley 2013-02-20 19:16 ` Felipe Balbi 2013-02-20 19:16 ` Felipe Balbi 2013-02-20 20:03 ` Paul Walmsley 2013-02-20 20:03 ` Paul Walmsley 2013-02-20 20:37 ` Russell King - ARM Linux 2013-02-20 20:37 ` Russell King - ARM Linux 2013-02-21 10:16 ` Peter De Schrijver 2013-02-21 10:16 ` Peter De Schrijver 2013-02-21 12:09 ` Peter Korsgaard 2013-02-21 12:09 ` Peter Korsgaard 2013-02-15 10:16 ` Russell King - ARM Linux 2013-02-15 10:16 ` Russell King - ARM Linux 2013-02-15 13:26 ` Santosh Shilimkar 2013-02-15 13:26 ` Santosh Shilimkar 2013-02-15 13:27 ` Russell King - ARM Linux 2013-02-15 13:27 ` Russell King - ARM Linux 2013-02-15 13:31 ` Santosh Shilimkar 2013-02-15 13:31 ` Santosh Shilimkar 2013-02-15 16:30 ` Tony Lindgren 2013-02-15 16:30 ` Tony Lindgren 2013-02-15 16:42 ` Felipe Balbi 2013-02-15 16:42 ` Felipe Balbi 2013-02-16 6:01 ` Santosh Shilimkar 2013-02-16 6:01 ` Santosh Shilimkar 2013-02-16 8:55 ` Felipe Balbi 2013-02-16 8:55 ` Felipe Balbi 2013-02-16 9:17 ` Santosh Shilimkar 2013-02-16 9:17 ` Santosh Shilimkar 2013-02-16 9:22 ` Felipe Balbi 2013-02-16 9:22 ` Felipe Balbi 2013-02-16 9:31 ` Santosh Shilimkar 2013-02-16 9:31 ` Santosh Shilimkar 2013-02-18 15:27 ` Kevin Hilman 2013-02-18 15:27 ` Kevin Hilman 2013-02-16 5:31 ` Santosh Shilimkar 2013-02-16 5:31 ` Santosh Shilimkar 2013-02-16 5:36 ` Nicolas Pitre 2013-02-16 5:36 ` Nicolas Pitre 2013-02-16 5:48 ` Santosh Shilimkar 2013-02-16 5:48 ` Santosh Shilimkar 2013-02-18 8:08 ` Bedia, Vaibhav 2013-02-18 8:08 ` Bedia, Vaibhav 2013-02-18 8:28 ` Santosh Shilimkar 2013-02-18 8:28 ` Santosh Shilimkar 2013-02-15 15:40 ` Kevin Hilman 2013-02-15 15:40 ` Kevin Hilman 2013-02-15 16:03 ` Felipe Balbi 2013-02-15 16:03 ` Felipe Balbi 2013-02-16 4:59 ` Santosh Shilimkar 2013-02-16 4:59 ` Santosh Shilimkar 2013-02-18 14:52 ` Kevin Hilman [this message] 2013-02-18 14:52 ` Kevin Hilman 2013-02-14 11:15 ` [RFC/NOT FOR MERGING 3/3] arm: boot: dts: omap: remove ti_hwmods from UART ports Felipe Balbi 2013-02-14 11:20 ` [RFC/NOT FOR MERGING 1/3] arm: omap: use generic implementation if !od Russell King - ARM Linux 2013-02-14 11:20 ` Russell King - ARM Linux 2013-02-14 17:57 ` Felipe Balbi 2013-02-14 17:57 ` Felipe Balbi 2013-02-15 15:28 ` Kevin Hilman 2013-02-15 15:28 ` Kevin Hilman 2013-02-15 16:04 ` Felipe Balbi 2013-02-15 16:04 ` Felipe Balbi
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=87vc9p4qto.fsf@linaro.org \ --to=khilman@linaro.org \ --cc=balbi@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=santosh.shilimkar@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.