Re: [RFC 0/5] PM / clock_ops: provide default runtime ops and cleanup users
Rajendra Nayak rna...@codeaurora.org writes: Most users of PM clocks do the exact same thing in runtime callbacks. Probably because they were all copied from mach-davinci. ;) Provide default callbacks and cleanup the existing users (keystone/davinci/omap1/sh) Very nice cleanup, Thanks! For the series: Reviewed-by: Kevin Hilman khil...@linaro.org 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 V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- Changes in v2: - minor typo fix in comments - merged up code that I missed committing in V1: https://patchwork.kernel.org/patch/6245041/ drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..3cd4783375a5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programmed */ + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP794XX_BIT_ALM0_EN; + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) -- 1.7.9.5 -- 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: ARM errata 430973 on multi platform kernels
* Sebastian Reichel s...@kernel.org [150417 11:43]: On Thu, Apr 16, 2015 at 09:08:58AM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@kernel.org [150415 09:32]: Hi, On Thu, Apr 09, 2015 at 02:48:43PM +0100, Russell King - ARM Linux wrote: On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote: On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote: Works for me. The above needs the following fix folded in to build: --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -532,7 +532,7 @@ __v7_ca9mp_proc_info: __v7_ca8_proc_info: .long 0x410fc080 .long 0xff00 - __v7_proc __v7_ca8mp_proc_info, proc_fns = ca8_processor_functions + __v7_proc __v7_ca8_proc_info, __v7_setup, proc_fns = ca8_processor_functions .size __v7_ca8_proc_info, . - __v7_ca8_proc_info #endif /* CONFIG_ARM_LPAE */ Thanks, merged into the original patch. Do you want to give me an ack for this, thanks? I tried to test this together with Tony's follow up patch, but I get this after applying the patch to v4.0: sre@earth ~/src/linux [430973-fix] % make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: 'include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h AS arch/arm/mm/proc-v7.o arch/arm/mm/proc-v7.S: Assembler messages: arch/arm/mm/proc-v7.S:535: Error: invalid operands (*ABS* and .text sections) for `|' arch/arm/mm/proc-v7.S:535: Error: invalid operands (*ABS* and .text sections) for `|' scripts/Makefile.build:294: recipe for target 'arch/arm/mm/proc-v7.o' failed make[1]: *** [arch/arm/mm/proc-v7.o] Error 1 Makefile:947: recipe for target 'arch/arm/mm' failed make: *** [arch/arm/mm] Error 2 make: *** Waiting for unfinished jobs Maybe test the version in Linux next: a6d746789825 (ARM: proc-v7: avoid errata 430973 workaround for non-Cortex A8 CPUs) DONE with your your patch added on top: Tested-By: Sebastian Reichel s...@kernel.org (on N900) OK thanks, patch now uploaded to Russell's patch system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8345/1 I guess we should also drop the CONFIG_ARM_ERRATA_430973 check from pdata-quirks' nokia_n900_legacy_init() and just enable it unconditionally. Yeah makes sense to me. Regards, Tony -- 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/20/2015 06:55 PM, Nishanth Menon wrote: Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occurring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Of course, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..59f9ecf323d5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programed */ ^^ typo here. s/programed/programmed + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP7941X_BIT_ALM0_EN; ^^ messed up git commit --amend :( + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) will repost a rev2 - apologies on the noise. -- Regards, Nishanth Menon -- 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: [RFC 0/5] PM / clock_ops: provide default runtime ops and cleanup users
On 4/20/2015 4:21 PM, Kevin Hilman wrote: Rajendra Nayak rna...@codeaurora.org writes: Most users of PM clocks do the exact same thing in runtime callbacks. Probably because they were all copied from mach-davinci. ;) Yep. ;-) Provide default callbacks and cleanup the existing users (keystone/davinci/omap1/sh) Very nice cleanup, Thanks! Indeed !! I can't test it out but from the series, I don't expect anything to break. So looks good to me as well. For the series: Reviewed-by: Kevin Hilman khil...@linaro.org Acked-by: Santosh Shilimkar ssant...@kernel.org -- 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occurring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Of course, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..59f9ecf323d5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programed */ + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP7941X_BIT_ALM0_EN; + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) -- 1.7.9.5 -- 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: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
Hi Peter, On 20/04/15 06:05, Peter Chen wrote: On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote: This is an attempt to centralize OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm. xhci side of things for OTG/DRD use are fixed in http://thread.gmane.org/gmane.linux.kernel/1923161 Hi Roger, Currently, there are two main problems for DRD/OTG framework. - For multi-platform supports, we may define CONFIG_USB_OTG, but the gadget should not add its otg descriptor to its configuration descriptors if it does not support one of otg features (SRP/HNP/ADP). Macpaul Lin's patch set [1] is the right way to do it. Agreed. That check (whether OTG descriptor can be added and which version of it) has to be done at runtime and it must be added only if hardware supports OTG _and_ kernel OTG support is enabled. - We are lack of framework to handle OTG (DRD) switch, it is great you are designing it. The main problem for this framework is how to handle DRD/OTG FSM unify. My thought is we add two paths for them separate. For easy, I suggest if the platform supports one of otg features, then it goes to fully otg fsm, else it goes to simply otg fsm (like your drd fsm). If you agree with it too, you may not need to add another dr_mode value. It would be nice that way but unfortunately it does't work in all cases. e.g. What if the SoC itself supports all OTG features but the board is not designed for OTG. Or the product designer simply is not interested in full OTG support but just dual-role. So we need some flexibility for the device tree/platform-data to specify that. This is where a new dr_mode == dual-role is needed. cheers, -roger -- 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: [RFC][PATCH v2 06/13] usb: hcd: Add hcd add/remove functions for OTG use
On Mon, 20 Apr 2015, Roger Quadros wrote: I don't understand this. Why do you want to defer the add/remove if the device is OTG? Don't host controller drivers expect these things to execute synchronously? Sorry for the wrong information. We actually defer only the add as the OTG state machine might not yet be in Host ready mode. The remove is always synchronous and we ensure that the HCD is removed when usb_otg_unregister_hcd() returns. That's okay then, but it does leave one potential hole. What happens if usb_add_hcd() is deferred for so long that usb_remove_hcd() gets called before the add can complete? Alan Stern -- 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: Fscking OMAP
On Mon, Apr 20, 2015 at 04:49:13PM +0100, Russell King - ARM Linux wrote: Guys, If you're going to introduce a dependency on some infrastructure which you absolutely require for booting, then _please_ ensure that the configuration system is updated such that pre-existing kernel configurations continue to work. Don't leave it such that the infrastructure ends up returning -ENOSYS, which then filters down into your SoC specific code, and aborts the initialisation of critical infrastructure, leaving you with a totally silent boot failure. In this case, it's the addition of syscon to OMAP internals, specifically in omap_control_init(). This is explicitly targetted at OMAP people, who have wasted much of my day today investigating why their platforms no longer boot in DT mode. Let's be clear about how this needs to be fixed: 1. OMAP must select MFD_SYSCON in its Kconfig when DT is enabled, since OMAP silently fails to boot when this symbol is not enabled. 2. omap_clk_init() really needs to have some diagnostic printk()s in it to indicate when something like omap_control_init() fails. 3. omap_clk_init() probably should _not_ return immediately when one of the children (such as omap_control_init) fails to initialise, as omitting the clocks pretty much ensures that the kernel will BUG() a few moments later in the timer code. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: Fscking OMAP
* Russell King - ARM Linux li...@arm.linux.org.uk [150420 10:15]: On Mon, Apr 20, 2015 at 09:25:16AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150420 08:50]: Guys, If you're going to introduce a dependency on some infrastructure which you absolutely require for booting, then _please_ ensure that the configuration system is updated such that pre-existing kernel configurations continue to work. Don't leave it such that the infrastructure ends up returning -ENOSYS, which then filters down into your SoC specific code, and aborts the initialisation of critical infrastructure, leaving you with a totally silent boot failure. In this case, it's the addition of syscon to OMAP internals, specifically in omap_control_init(). This is explicitly targetted at OMAP people, who have wasted much of my day today investigating why their platforms no longer boot in DT mode. Ouch, yeah missing dependencies are a pain to debug. Looks like we get MFD_SYSCON selected with omap2plus_defconfig, but that's not always the case like you pointed out. Does the patch below fix the issue for you? Yes, that fixes it, thanks. OK let's get this merged immediately and then Tero can add some more checks to the init code like you suggested with a follow-up patch. Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Mon, 20 Apr 2015 09:23:25 -0700 Subject: [PATCH] ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON With the recent changes omaps have developed a dependency to MFD_SYSCON. This is used for system control module generic register area and some clocks. We do have it selected in omap2plus_defconfig, but targeted config files may not have it selected. Let's make sure it's selected like few other ARM platforms are already doing. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -81,6 +81,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC select MEMORY + select MFD_SYSCON select OMAP_DM_TIMER select OMAP_GPMC select PINCTRL -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: Fscking OMAP
On Mon, Apr 20, 2015 at 09:25:16AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150420 08:50]: Guys, If you're going to introduce a dependency on some infrastructure which you absolutely require for booting, then _please_ ensure that the configuration system is updated such that pre-existing kernel configurations continue to work. Don't leave it such that the infrastructure ends up returning -ENOSYS, which then filters down into your SoC specific code, and aborts the initialisation of critical infrastructure, leaving you with a totally silent boot failure. In this case, it's the addition of syscon to OMAP internals, specifically in omap_control_init(). This is explicitly targetted at OMAP people, who have wasted much of my day today investigating why their platforms no longer boot in DT mode. Ouch, yeah missing dependencies are a pain to debug. Looks like we get MFD_SYSCON selected with omap2plus_defconfig, but that's not always the case like you pointed out. Does the patch below fix the issue for you? Yes, that fixes it, thanks. 8 --- From: Tony Lindgren t...@atomide.com Date: Mon, 20 Apr 2015 09:23:25 -0700 Subject: [PATCH] ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON With the recent changes omaps have developed a dependency to MFD_SYSCON. This is used for system control module generic register area and some clocks. We do have it selected in omap2plus_defconfig, but targeted config files may not have it selected. Let's make sure it's selected like few other ARM platforms are already doing. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -81,6 +81,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC select MEMORY + select MFD_SYSCON select OMAP_DM_TIMER select OMAP_GPMC select PINCTRL -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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
Fscking OMAP
Guys, If you're going to introduce a dependency on some infrastructure which you absolutely require for booting, then _please_ ensure that the configuration system is updated such that pre-existing kernel configurations continue to work. Don't leave it such that the infrastructure ends up returning -ENOSYS, which then filters down into your SoC specific code, and aborts the initialisation of critical infrastructure, leaving you with a totally silent boot failure. In this case, it's the addition of syscon to OMAP internals, specifically in omap_control_init(). This is explicitly targetted at OMAP people, who have wasted much of my day today investigating why their platforms no longer boot in DT mode. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: Fscking OMAP
* Russell King - ARM Linux li...@arm.linux.org.uk [150420 08:50]: Guys, If you're going to introduce a dependency on some infrastructure which you absolutely require for booting, then _please_ ensure that the configuration system is updated such that pre-existing kernel configurations continue to work. Don't leave it such that the infrastructure ends up returning -ENOSYS, which then filters down into your SoC specific code, and aborts the initialisation of critical infrastructure, leaving you with a totally silent boot failure. In this case, it's the addition of syscon to OMAP internals, specifically in omap_control_init(). This is explicitly targetted at OMAP people, who have wasted much of my day today investigating why their platforms no longer boot in DT mode. Ouch, yeah missing dependencies are a pain to debug. Looks like we get MFD_SYSCON selected with omap2plus_defconfig, but that's not always the case like you pointed out. Does the patch below fix the issue for you? Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Mon, 20 Apr 2015 09:23:25 -0700 Subject: [PATCH] ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON With the recent changes omaps have developed a dependency to MFD_SYSCON. This is used for system control module generic register area and some clocks. We do have it selected in omap2plus_defconfig, but targeted config files may not have it selected. Let's make sure it's selected like few other ARM platforms are already doing. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -81,6 +81,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC select MEMORY + select MFD_SYSCON select OMAP_DM_TIMER select OMAP_GPMC select PINCTRL -- 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
[GIT PULL] urgent omap boot fix for v4.1 if MFD_SYSCON is not set
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.1/prcm-dts-mfd-syscon-fix for you to fetch changes up to da4d81453cf1eedfcd8b2cd1e7bfab230084bd87: ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON (2015-04-20 10:36:31 -0700) Urgent pull request for v4.1 to booting for custom kernel .config files that do not have MFD_SYSCON set. Omaps now have a dependency to MFD_SYSCON for system control module generic register area and some clocks with the changes done in omap-for-v4.1/prcm-dts branch. This can be pulled on top of omap-for-v4.1/prcm-dts, or into fixes for v4.1. We already do have a slight MFD_SYSCON dependency for REGULATOR_PBIAS for dual voltage MMC cards on the first MMC bus for many devices, so from that point of view this can also be merged separately from omap-for-v4.1/prcm-dts. Tony Lindgren (1): ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) -- 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
[GIT PULL] remoteproc for 4.1
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git tags/remoteproc-4.1-next for you to fetch changes up to 315491e5d6ee66838a18a8ca0c14e6ffb376e48c: remoteproc: add IOMMU hardware capability flag (2015-03-12 10:43:26 +0200) Suman Anna is adding remoteproc support for processors not behind IOMMUs. Suman Anna (1): remoteproc: add IOMMU hardware capability flag drivers/remoteproc/da8xx_remoteproc.c | 1 + drivers/remoteproc/omap_remoteproc.c | 2 ++ drivers/remoteproc/remoteproc_core.c | 15 ++- drivers/remoteproc/ste_modem_rproc.c | 1 + include/linux/remoteproc.h| 2 ++ 5 files changed, 8 insertions(+), 13 deletions(-) -- 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: [RFC][PATCH v2 06/13] usb: hcd: Add hcd add/remove functions for OTG use
On 17/04/15 17:03, Alan Stern wrote: On Fri, 17 Apr 2015, Roger Quadros wrote: On 17/04/15 05:18, Peter Chen wrote: On Tue, Apr 14, 2015 at 01:41:53PM +0300, Roger Quadros wrote: The existing usb_add/remove_hcd() functionality remains unchanged for non-OTG devices. For OTG devices they only register the HCD with the OTG core. Introduce _usb_add/remove_hcd() for use by OTG core. These functions actually add/remove the HCD. Would you please explain why additional _usb_add/remove_hcd are needed? It is to differentiate if the add/remove_hcd was called by the HCD drivers or by the OTG core as we want to behave a bit differently in both cases. When called by HCD drivers, we want to defer the add/remove if it is an OTG device. When called by OTG core, we don't want to defer the add/remove. I don't understand this. Why do you want to defer the add/remove if the device is OTG? Don't host controller drivers expect these things to execute synchronously? Sorry for the wrong information. We actually defer only the add as the OTG state machine might not yet be in Host ready mode. The remove is always synchronous and we ensure that the HCD is removed when usb_otg_unregister_hcd() returns. For example, what happens if you rmmod the HCD? If the remove call gets deferred, then when it finally runs it will try to call back into HCD code that has already been unloaded from memory! HCD drivers use usb_add/remove_hcd() OTG core uses _usb_add/remove_hcd() How about a more explicit naming scheme? HC drivers use usb_add/remove_hcd() OTG core uses usb_otg_add/remove_hcd() Yes, this is better. cheers, -roger -- 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
