From: Kevin Hilman <khilman@linaro.org> To: balbi@ti.com Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.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: Tue, 19 Feb 2013 11:50:37 -0800 [thread overview] Message-ID: <8738wsw0aa.fsf@linaro.org> (raw) In-Reply-To: <20130219193237.GA8978@arwen.pp.htv.fi> (Felipe Balbi's message of "Tue, 19 Feb 2013 21:32:37 +0200") Felipe Balbi <balbi@ti.com> writes: > Hi, > > On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote: > > [ ... ] > >> The other problem is the where reset is need during runtime. Again, >> what are the specific examples here? The one I can think of off the top >> of my head is I2C, where it's needed in certain error recovery >> scenarios. > > right, I still have a theory that it's not needed in that case either, > though I haven't had time to try that out. Great, I hope it's not needed. I've asked several times in past as this driver was converted to runtime PM, but was told it was required for various reasons (which I can't remember anymore.) >> Here, we need a way for the driver itself to initiate a full reset. >> Maybe a new runtime PM hook like ->runtime_reset() as Felipe has >> suggested (though I'm not yet sure runtime PM is the right place for >> this, since it's not strictly related to runtime PM). Or, if these are > > right, I agree with you but I couldn't think of a better place. Maybe we > need a reset hook in struct device itself (as I suggested on another > mail) but I'm not sure Greg would take it, unless we have a damn good > reason. I'm starting to think a ->hardreset() method in struct dev_pm_ops is the place to put this. IMO, it needs to be in dev_pm_ops, so it can be selectively overridden by PM domains. On OMAP, we'd just hook it up to omap_device_shutdown() for all omap_devices, and we'd be done. >> mostly corner-case, error recovery scenarios, maybe a a way force the >> driver to remove itself and re-probe (which would trigger the >> bus-notifier based reset) as Tony has suggested is the better approach. > > I don't think so. We certainly don't need to go through all memory > allocations again. That will just cause unnecessary memory > fragmentation. > >> The OMAP I2C driver is doing a reset and fully re-initializing itself, >> so it seems the forced remove/probe is the right approach there. Any > > I must disagree here. Doing a reprobe of I2C every time there's an error > condition is overkill. It means freeing struct omap_i2c_dev, freeing its > IRQ, freeing the ioremapped area, changing mux configuration (due to > pinctrl calls) just to do it all over again. Besides omap_i2c_probe() > calls omap_i2c_init() which will do the full IP reset anyway. > > The difference is that calling omap_i2c_init() directly doesn't force us > to free and reallocate all resources all over again. I agree, that would be a lot of churn. >> one have the other use cases handy? > > dwc3 gets reset during probe() too, but that has an IP specific reset > which doesn't need SYSCONFIG register for that. OK, but that's still an init-time reset issue Do you know of any other runtime reset cases? If I2C is the only one, then maybe seeing if it can be removed is the right first step. If that works, we don't need any of this. 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: Tue, 19 Feb 2013 11:50:37 -0800 [thread overview] Message-ID: <8738wsw0aa.fsf@linaro.org> (raw) In-Reply-To: <20130219193237.GA8978@arwen.pp.htv.fi> (Felipe Balbi's message of "Tue, 19 Feb 2013 21:32:37 +0200") Felipe Balbi <balbi@ti.com> writes: > Hi, > > On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote: > > [ ... ] > >> The other problem is the where reset is need during runtime. Again, >> what are the specific examples here? The one I can think of off the top >> of my head is I2C, where it's needed in certain error recovery >> scenarios. > > right, I still have a theory that it's not needed in that case either, > though I haven't had time to try that out. Great, I hope it's not needed. I've asked several times in past as this driver was converted to runtime PM, but was told it was required for various reasons (which I can't remember anymore.) >> Here, we need a way for the driver itself to initiate a full reset. >> Maybe a new runtime PM hook like ->runtime_reset() as Felipe has >> suggested (though I'm not yet sure runtime PM is the right place for >> this, since it's not strictly related to runtime PM). Or, if these are > > right, I agree with you but I couldn't think of a better place. Maybe we > need a reset hook in struct device itself (as I suggested on another > mail) but I'm not sure Greg would take it, unless we have a damn good > reason. I'm starting to think a ->hardreset() method in struct dev_pm_ops is the place to put this. IMO, it needs to be in dev_pm_ops, so it can be selectively overridden by PM domains. On OMAP, we'd just hook it up to omap_device_shutdown() for all omap_devices, and we'd be done. >> mostly corner-case, error recovery scenarios, maybe a a way force the >> driver to remove itself and re-probe (which would trigger the >> bus-notifier based reset) as Tony has suggested is the better approach. > > I don't think so. We certainly don't need to go through all memory > allocations again. That will just cause unnecessary memory > fragmentation. > >> The OMAP I2C driver is doing a reset and fully re-initializing itself, >> so it seems the forced remove/probe is the right approach there. Any > > I must disagree here. Doing a reprobe of I2C every time there's an error > condition is overkill. It means freeing struct omap_i2c_dev, freeing its > IRQ, freeing the ioremapped area, changing mux configuration (due to > pinctrl calls) just to do it all over again. Besides omap_i2c_probe() > calls omap_i2c_init() which will do the full IP reset anyway. > > The difference is that calling omap_i2c_init() directly doesn't force us > to free and reallocate all resources all over again. I agree, that would be a lot of churn. >> one have the other use cases handy? > > dwc3 gets reset during probe() too, but that has an IP specific reset > which doesn't need SYSCONFIG register for that. OK, but that's still an init-time reset issue Do you know of any other runtime reset cases? If I2C is the only one, then maybe seeing if it can be removed is the right first step. If that works, we don't need any of this. Kevin
next prev parent reply other threads:[~2013-02-19 19:50 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 [this message] 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 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=8738wsw0aa.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=paul@pwsan.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.