Re: ARM errata 430973 on multi platform kernels
* Russell King - ARM Linux li...@arm.linux.org.uk [150423 03:26]: On Mon, Apr 20, 2015 at 04:40:32PM -0700, Tony Lindgren wrote: * 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 have a concern with that patch. The reason that it's disabled for multiplatform is because we can't guarantee that the auxctrl register will be writable. The solution we came up with for multiplatform was to require firmware to be updated to enable this bit. Enabling it on a platform where firmware has not been updated, but runs in the non-secure world will lead to the kernel hanging in the early assembly code. I've discussed it with Catalin, and Catalin's position is that we should not remove the !multiplatform conditional. That's something which I find that I'm agreeing with Catalin on - any other non-secure Cortex A8 user who is setting this bit in firmware will instantly break if this patch is applied. However, I don't think anyone is willing to say that they have a solution to this problem - obviously, you can't build OMAP as a non-multiplatform kernel anymore, so in effect you can never have the kernel enable this errata. And you can't detect whether you're running in secure mode or not. We could do the only write the bit if it was originally clear but we still have the problem that doing so may cause other people regressions. How about we keep the bit writing part !multiplatform conditional (or even remove it) but always do the flush for ca-8? Then we could also do a warning for a misconfigured ca-8 later on. 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 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150423 04:13]:
On 04/21/2015 07:08 PM, Tony Lindgren wrote:
@@ -438,11 +447,30 @@ static void omap_enable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+
+ if (is_irq) {
+ omap_set_gpio_direction(bank, offset, 1);
+ bank-irq_usage |= BIT(offset);
+ } else {
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ bank-mod_usage |= BIT(offset);
+ }
The OMAP GPIO driver implements two Core interfaces IRQ-chip and GPIO-chip
which, in general,
more or less independent.
So, I don't think, that it's good to mix GPIO-IRQ-chip specific code with
GPIO-chip code.
And this even don't really correspond the purpose of
omap_enable_gpio_module() :( and might
introduce misunderstanding of code. The worst thing is that future fixes in
IRQ-chip may
affect on on GPIO-chip and vise versa :(
Hmm I'm thinking omap_enable/disable_gpio_module() eventually becomes
our runtime_resume/suspend(). Currently the enabling and disabling is
buggy for GPIO for some corner cases.. AFAIK the only difference between
enabling GPIO vs GPIO-IRQ is the calling of omap_set_gpio_direction
vs omap_set_gpio_triggering. Or at least that's the way it should be
unless I'm missing something?
Could we keep omap_xxx_gpio_module() functions responsible only for GPIO bank
PM and
enabling/disabling?
If you're thinking about just thinking about having separate wrappers around
it like this::
static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset,
bool is_irq)
{
...
}
static void omap_enable_gpio((struct gpio_bank *bank, unsigned offset)
{
omap_enable_gpio_module(bpio_bank, offset, 0);
}
static void omap_enable_gpio_irq((struct gpio_bank *bank, unsigned offset)
{
omap_enable_gpio_module(bpio_bank, offset, 1);
}
Then yes makes sense to me. Or do you have something else in mind?
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 V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/23/2015 04:11 PM, Nishanth Menon wrote: On 04/23/2015 05:17 AM, grygorii.stras...@linaro.org wrote: On 04/23/2015 03:00 AM, Nishanth Menon wrote: On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: Hi, On 04/21/2015 03:51 AM, 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 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. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) Also, it is recommended that the alarm registers be loaded before the alarm is enabled. Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general unlike of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst( CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet. but will include the app note for future patches - thanks for pointing it out to me. ^^ Up to you. Np, Always yours! Considering the narrow focus of the current patch (which does fix an issue that it attempts to), can I get an Ack? Reviewed-by: Grygorii Strashko grygorii.stras...@linaro.org -- regards, -grygorii -- 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
[added to the 3.18 stable tree] dmaengine: omap-dma: Fix memory leak when terminating running transfer
From: Peter Ujfalusi peter.ujfal...@ti.com
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 ]
In omap_dma_start_desc the vdesc-node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: sta...@vger.kernel.org
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/dma/omap-dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bbea824..f477f3b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -978,6 +978,7 @@ static int omap_dma_terminate_all(struct omap_chan *c)
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ omap_dma_desc_free(c-desc-vd);
c-desc = NULL;
/* Avoid stopping the dma twice */
if (!c-paused)
--
2.1.0
--
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
[added to the 3.18 stable tree] dmaengine: edma: fix memory leak when terminating running transfers
From: Petr Kulhavy p...@barix.com
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit 5ca9e7ce6eebec53362ff779264143860ccf68cd ]
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan-edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy p...@barix.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: sta...@vger.kernel.org
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/dma/edma.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4cfaaa5..abff66c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -258,6 +258,13 @@ static int edma_terminate_all(struct edma_chan *echan)
*/
if (echan-edesc) {
int cyclic = echan-edesc-cyclic;
+
+ /*
+* free the running request descriptor
+* since it is not in any of the vdesc lists
+*/
+ edma_desc_free(echan-edesc-vdesc);
+
echan-edesc = NULL;
edma_stop(echan-ch_num);
/* Move the cyclic channel back to default queue */
--
2.1.0
--
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] gpio: omap: Fix regression for MPUIO interrupts
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code trying to do the same.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 48 +---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 6553361..b59c3ca 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1023,38 +1023,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
dev_err(bank-dev, Could not get gpio dbck\n);
}
-static void
-omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start,
- unsigned int num)
-{
- struct irq_chip_generic *gc;
- struct irq_chip_type *ct;
-
- gc = irq_alloc_generic_chip(MPUIO, 1, irq_start, bank-base,
- handle_simple_irq);
- if (!gc) {
- dev_err(bank-dev, Memory alloc failed for gc\n);
- return;
- }
-
- ct = gc-chip_types;
-
- /* NOTE: No ack required, reading IRQ status clears it. */
- ct-chip.irq_mask = irq_gc_mask_set_bit;
- ct-chip.irq_unmask = irq_gc_mask_clr_bit;
- ct-chip.irq_set_type = omap_gpio_irq_type;
-
- if (bank-regs-wkup_en)
- ct-chip.irq_set_wake = omap_gpio_wake_enable;
-
- ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride;
- irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
- IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-}
-
static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
{
- int j;
static int gpio;
int irq_base = 0;
int ret;
@@ -1101,6 +1071,15 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
}
#endif
+ /* MPUIO is a bit different, reading IRQ status clears it */
+ if (bank-is_mpuio) {
+ irqc-irq_ack = dummy_irq_chip.irq_ack;
+ irqc-irq_mask = irq_gc_mask_set_bit;
+ irqc-irq_unmask = irq_gc_mask_clr_bit;
+ if (!bank-regs-wkup_en)
+ irqc-irq_set_wake = NULL;
+ }
+
ret = gpiochip_irqchip_add(bank-chip, irqc,
irq_base, omap_gpio_irq_handler,
IRQ_TYPE_NONE);
@@ -1114,15 +1093,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
- for (j = 0; j bank-width; j++) {
- int irq = irq_find_mapping(bank-chip.irqdomain, j);
- if (bank-is_mpuio) {
- omap_mpuio_alloc_gc(bank, irq, bank-width);
- irq_set_chip_and_handler(irq, NULL, NULL);
- set_irq_flags(irq, 0);
- }
- }
-
return 0;
}
--
2.1.4
--
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] gpio: omap: Allow building as a loadable module
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue by adding inline functions to the header.
Note that we can now also remove the two unused functions for
omap_set_gpio_debounce and omap_set_gpio_debounce_time.
Then doing rmmod on the module produces further warnings
because of missing exit related functions. Let's add those.
And finally, we can make the Kconfig entry just a tristate
option that's selected for omaps.
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/Kconfig| 2 +-
drivers/gpio/gpio-omap.c| 24
include/linux/platform_data/gpio-omap.h | 12 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..ff7df95 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -308,7 +308,7 @@ config GPIO_OCTEON
family of SOCs.
config GPIO_OMAP
- bool TI OMAP GPIO support if COMPILE_TEST !ARCH_OMAP2PLUS
+ tristate TI OMAP GPIO support if ARCH_OMAP2PLUS || COMPILE_TEST
default y if ARCH_OMAP
depends on ARM
select GENERIC_IRQ_CHIP
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b59c3ca..384a852 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1202,6 +1202,17 @@ static int omap_gpio_probe(struct platform_device *pdev)
return 0;
}
+static int omap_gpio_remove(struct platform_device *pdev)
+{
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+
+ list_del(bank-node);
+ gpiochip_remove(bank-chip);
+ pm_runtime_disable(bank-dev);
+
+ return 0;
+}
+
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM)
@@ -1387,6 +1398,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
#endif /* CONFIG_PM */
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
@@ -1412,6 +1424,7 @@ void omap2_gpio_resume_after_idle(void)
pm_runtime_get_sync(bank-dev);
}
}
+#endif
#if defined(CONFIG_PM)
static void omap_gpio_init_context(struct gpio_bank *p)
@@ -1567,6 +1580,7 @@ MODULE_DEVICE_TABLE(of, omap_gpio_match);
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
+ .remove = omap_gpio_remove,
.driver = {
.name = omap_gpio,
.pm = gpio_pm_ops,
@@ -1584,3 +1598,13 @@ static int __init omap_gpio_drv_reg(void)
return platform_driver_register(omap_gpio_driver);
}
postcore_initcall(omap_gpio_drv_reg);
+
+static void __exit omap_gpio_exit(void)
+{
+ platform_driver_unregister(omap_gpio_driver);
+}
+module_exit(omap_gpio_exit);
+
+MODULE_DESCRIPTION(omap gpio driver);
+MODULE_ALIAS(platform:gpio-omap);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/platform_data/gpio-omap.h
b/include/linux/platform_data/gpio-omap.h
index 5d50b25..cb26181 100644
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -208,9 +208,17 @@ struct omap_gpio_platform_data {
int (*get_context_loss_count)(struct device *dev);
};
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
extern void omap2_gpio_prepare_for_idle(int off_mode);
extern void omap2_gpio_resume_after_idle(void);
-extern void omap_set_gpio_debounce(int gpio, int enable);
-extern void omap_set_gpio_debounce_time(int gpio, int enable);
+#else
+static inline void omap2_gpio_prepare_for_idle(int off_mode)
+{
+}
+
+static inline void omap2_gpio_resume_after_idle(void)
+{
+}
+#endif
#endif
--
2.1.4
--
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 added to the 3.12 stable tree] dmaengine: omap-dma: Fix memory leak when terminating running transfer
From: Peter Ujfalusi peter.ujfal...@ti.com
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream.
In omap_dma_start_desc the vdesc-node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
drivers/dma/omap-dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index ec3fc4fd9160..b94a37630e36 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -487,6 +487,7 @@ static int omap_dma_terminate_all(struct omap_chan *c)
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ omap_dma_desc_free(c-desc-vd);
c-desc = NULL;
/* Avoid stopping the dma twice */
if (!c-paused)
--
2.3.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
On 23/04/15 04:52, Peter Chen wrote:
On Wed, Apr 22, 2015 at 03:42:32PM +0300, Roger Quadros wrote:
So we will have a separate drd fsm file, and the CONFIG_USB_OTG
and CONFIG_USB_OTG_FSM are not needed to be defined, right?
for drd case CONFIG_USB_OTG_FSM is definitely not needed.
I'm not sure if we can operate dual-role without CONFIG_USB_OTG.
I was thinking of combining the OTG core functionality
(drivers/usb/common/usb-otg.c)
with CONFIG_USB_OTG.
Ok, let's choose CONFIG_USB_OTG for both drd and usb fsm case.
And we need to patch for hcd that only hnp supported hcd needs
to request otg descriptor, etc.
Agreed. It makes things much simpler.
For yesterday's back-compatible old otg device, we can add otg
features to these drivers, the current behavior for these drivers
is: if CONFIG_USB_OTG is defined, it is an otg device, we can just
keep the behavior unchanging. If these drivers need to use OTG framework
in future, it needs to update its platform data or dts.
Right.
So, I prefer:
- For switching the role through the ID pin devices, we doesn't need any otg
features, so no otg dts properties are needed.(expect dr_mode = otg)
- For adp/srp/hnp supported devices, we need (partial) otg features, and
the fsm (hardware or software) are needed, we need some otg dts
properties we discussed before.
Agreed.
I will try to incorporate these points in v3 of this series.
cheers,
-roger
static const struct usb_descriptor_header *otg_desc_20[] = {
(struct usb_descriptor_header *) (struct usb_otg_descriptor_20){
.bLength = sizeof(struct usb_otg_descriptor_20),
.bDescriptorType = USB_DT_OTG,
/*
* REVISIT SRP-only hardware is possible, although
* it would not be called OTG ...
*/
.bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
.bcdOTG = cpu_to_le16(0x0200),
},
NULL,
};
instead of hardcoding bmAttributes field, it must be obtained from the
appropriate data structure that was set by the controller driver
by reading DT and OTG hardware info.
During bind process:
if (gadget_is_otg_13(c-cdev-gadget))
c-descriptors = otg_desc_13;
else if (gadget_is_otg_20(c-cdev-gadget))
c-descriptors = otg_desc_20;
Probably a helper utitily can do the necessary checks and build the
otg descriptor for us.
usb_otg_get_descriptor(c-descriptors);
e.g. for OTG3.0 we have a new flag USB_OTG_RSP, and this helper
can be upgraded in the future.
ok, it is the implementation detail.
--
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 V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/23/2015 05:17 AM, grygorii.stras...@linaro.org wrote: On 04/23/2015 03:00 AM, Nishanth Menon wrote: On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: Hi, On 04/21/2015 03:51 AM, 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 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. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) Also, it is recommended that the alarm registers be loaded before the alarm is enabled. Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general unlike of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst( CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet. but will include the app note for future patches - thanks for pointing it out to me. ^^ Up to you. Np, Always yours! Considering the narrow focus of the current patch (which does fix an issue that it attempts to), can I get an Ack? -- 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
[PATCH 2/5] arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-keystone/pm_domain.c | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/arch/arm/mach-keystone/pm_domain.c
b/arch/arm/mach-keystone/pm_domain.c
index 41bebfd..edea697 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -19,40 +19,9 @@
#include linux/clk-provider.h
#include linux/of.h
-#ifdef CONFIG_PM
-static int keystone_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int keystone_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
-
- return pm_generic_runtime_resume(dev);
-}
-#endif
-
static struct dev_pm_domain keystone_pm_domain = {
.ops = {
- SET_RUNTIME_PM_OPS(keystone_pm_runtime_suspend,
- keystone_pm_runtime_resume, NULL)
+ USE_PM_CLK_RUNTIME_OPS
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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 0/5] PM / clock_ops: provide default runtime ops and cleanup users
Most users of PM clocks do the exact same thing in runtime callbacks. Provide default callbacks and cleanup the existing users (keystone/davinci /omap1/sh) Rajendra Nayak (5): PM / clock_ops: Provide default runtime ops to users arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arch/arm/mach-davinci/pm_domain.c | 32 +- arch/arm/mach-keystone/pm_domain.c | 33 +- arch/arm/mach-omap1/pm_bus.c | 37 ++ drivers/base/power/clock_ops.c | 38 ++ drivers/sh/pm_runtime.c| 47 ++ include/linux/pm_clock.h | 10 6 files changed, 54 insertions(+), 143 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 3/5] arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-omap1/pm_bus.c | 37 ++---
1 file changed, 2 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index c40e209..667c163 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -21,48 +21,15 @@
#include soc.h
-#ifdef CONFIG_PM
-static int omap1_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int omap1_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain default_pm_domain = {
.ops = {
- .runtime_suspend = omap1_pm_runtime_suspend,
- .runtime_resume = omap1_pm_runtime_resume,
+ USE_PM_CLK_RUNTIME_OPS
USE_PLATFORM_PM_SLEEP_OPS
},
};
-#define OMAP1_PM_DOMAIN (default_pm_domain)
-#else
-#define OMAP1_PM_DOMAIN NULL
-#endif /* CONFIG_PM */
static struct pm_clk_notifier_block platform_bus_notifier = {
- .pm_domain = OMAP1_PM_DOMAIN,
+ .pm_domain = default_pm_domain,
.con_ids = { ick, fck, NULL, },
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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 5/5] drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/sh/pm_runtime.c | 47 ++-
1 file changed, 2 insertions(+), 45 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index cd4c293..e0fd1e0 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -20,58 +20,15 @@
#include linux/bitmap.h
#include linux/slab.h
-#ifdef CONFIG_PM
-static int sh_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret) {
- dev_err(dev, failed to suspend device\n);
- return ret;
- }
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- dev_err(dev, failed to suspend clock\n);
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int sh_pm_runtime_resume(struct device *dev)
-{
- int ret;
-
- ret = pm_clk_resume(dev);
- if (ret) {
- dev_err(dev, failed to resume clock\n);
- return ret;
- }
-
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain default_pm_domain = {
.ops = {
- .runtime_suspend = sh_pm_runtime_suspend,
- .runtime_resume = sh_pm_runtime_resume,
+ USE_PM_CLK_RUNTIME_OPS
USE_PLATFORM_PM_SLEEP_OPS
},
};
-#define DEFAULT_PM_DOMAIN_PTR (default_pm_domain)
-
-#else
-
-#define DEFAULT_PM_DOMAIN_PTR NULL
-
-#endif /* CONFIG_PM */
-
static struct pm_clk_notifier_block platform_bus_notifier = {
- .pm_domain = DEFAULT_PM_DOMAIN_PTR,
+ .pm_domain = default_pm_domain,
.con_ids = { NULL, },
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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 4/5] arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-davinci/pm_domain.c | 32 +---
1 file changed, 1 insertion(+), 31 deletions(-)
diff --git a/arch/arm/mach-davinci/pm_domain.c
b/arch/arm/mach-davinci/pm_domain.c
index 641edc3..78eac2c 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -14,39 +14,9 @@
#include linux/pm_clock.h
#include linux/platform_device.h
-#ifdef CONFIG_PM
-static int davinci_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int davinci_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-#endif
-
static struct dev_pm_domain davinci_pm_domain = {
.ops = {
- SET_RUNTIME_PM_OPS(davinci_pm_runtime_suspend,
- davinci_pm_runtime_resume, NULL)
+ USE_PM_CLK_RUNTIME_OPS
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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 1/5] PM / clock_ops: Provide default runtime ops to users
Most users of PM clocks do the extact same things in the runtime
suspend/resume callbacks. Provide them USE_PM_CLK_RUNTIME_OPS so
as to avoid/remove boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/base/power/clock_ops.c | 38 ++
include/linux/pm_clock.h | 10 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 7fdd017..8abea66 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
#include linux/clkdev.h
#include linux/slab.h
#include linux/err.h
+#include linux/pm_runtime.h
#ifdef CONFIG_PM
@@ -367,6 +368,43 @@ static int pm_clk_notify(struct notifier_block *nb,
return 0;
}
+int pm_clk_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret) {
+ dev_err(dev, failed to suspend device\n);
+ return ret;
+ }
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ dev_err(dev, failed to suspend clock\n);
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+int pm_clk_runtime_resume(struct device *dev)
+{
+ int ret;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_clk_resume(dev);
+ if (ret) {
+ dev_err(dev, failed to resume clock\n);
+ return ret;
+ }
+
+ return pm_generic_runtime_resume(dev);
+}
+
#else /* !CONFIG_PM */
/**
diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h
index 0b00396..25266c6 100644
--- a/include/linux/pm_clock.h
+++ b/include/linux/pm_clock.h
@@ -20,6 +20,16 @@ struct pm_clk_notifier_block {
struct clk;
+#ifdef CONFIG_PM
+extern int pm_clk_runtime_suspend(struct device *dev);
+extern int pm_clk_runtime_resume(struct device *dev);
+#define USE_PM_CLK_RUNTIME_OPS \
+ .runtime_suspend = pm_clk_runtime_suspend, \
+ .runtime_resume = pm_clk_runtime_resume,
+#else
+#define USE_PM_CLK_RUNTIME_OPS
+#endif
+
#ifdef CONFIG_PM_CLK
static inline bool pm_clk_no_clocks(struct device *dev)
{
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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 V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/23/2015 03:00 AM, Nishanth Menon wrote: On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: Hi, On 04/21/2015 03:51 AM, 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 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. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) Also, it is recommended that the alarm registers be loaded before the alarm is enabled. Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general unlike of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst(CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet. but will include the app note for future patches - thanks for pointing it out to me. ^^ Up to you. Np, Always yours! 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,
[PATCH] mmc: core: add missing pm event in mmc_pm_notify to fix hib restore
From: Grygorii Strashko grygorii.stras...@linaro.org
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148
l3_interrupt_handler+0x258/0x374()
4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access
in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/mmc/core/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c296bc0..92e7671 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2651,6 +2651,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
switch (mode) {
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
+ case PM_RESTORE_PREPARE:
spin_lock_irqsave(host-lock, flags);
host-rescan_disable = 1;
spin_unlock_irqrestore(host-lock, flags);
--
1.9.1
--
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
On Mon, Apr 20, 2015 at 04:40:32PM -0700, Tony Lindgren wrote: * 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 have a concern with that patch. The reason that it's disabled for multiplatform is because we can't guarantee that the auxctrl register will be writable. The solution we came up with for multiplatform was to require firmware to be updated to enable this bit. Enabling it on a platform where firmware has not been updated, but runs in the non-secure world will lead to the kernel hanging in the early assembly code. I've discussed it with Catalin, and Catalin's position is that we should not remove the !multiplatform conditional. That's something which I find that I'm agreeing with Catalin on - any other non-secure Cortex A8 user who is setting this bit in firmware will instantly break if this patch is applied. However, I don't think anyone is willing to say that they have a solution to this problem - obviously, you can't build OMAP as a non-multiplatform kernel anymore, so in effect you can never have the kernel enable this errata. And you can't detect whether you're running in secure mode or not. We could do the only write the bit if it was originally clear but we still have the problem that doing so may cause other people regressions. -- 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: [PATCH 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros
Hi Tony,
On 04/21/2015 07:08 PM, Tony Lindgren wrote:
Looks like omap_gpio_irq_type can return early at several places
leaving a GPIO bank enabled without doing pm_runtime_put if wrong
GPIO arguments are passed.
Instead of adding more complicated BANK_USED macros, let's fix the
issue properly. We can pass is_irq flag to omap_enable_gpio_module
and omap_disble_gpio_module. And with that we can remove all the
similar code elsewhere to get rid of most BANK_USED macros.
Note that the reason for the BANK_USED macro is that we need to manage
PM runtime on per GPIO bank basis. In the long run we want to move to
using PM runtime counts for each GPIO line to determine if a GPIO
bank is used. Once we have a solution for omap_enable_gpio_module
and omap_disable_gpio_module, we can remove the remaining BANK_USED
macros.
In general, this approach is ok for me - I've had not able to test this patch,
but
I'm going to take a deeper look on it on Friday or at the beginning of next
week.
But, honestly, there is one thing I really don't like :( see below pls.
Cc: Felipe Balbi ba...@ti.com
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Javier Martinez Canillas jmarti...@softcrates.net
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 111
+--
1 file changed, 40 insertions(+), 71 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d44e617..39a6312 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -86,6 +86,7 @@ struct gpio_bank {
#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
#define LINE_USED(line, offset) (line (BIT(offset)))
+static void omap_reset_gpio(struct gpio_bank *bank, unsigned offset);
static void omap_gpio_unmask_irq(struct irq_data *d);
static inline struct gpio_bank *omap_irq_data_get_bank(struct irq_data *d)
@@ -419,8 +420,16 @@ static int omap_set_gpio_triggering(struct gpio_bank
*bank, int gpio,
return 0;
}
-static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset,
+ bool is_irq)
{
+ unsigned long flags;
+
+ /* PM runtime is per bank, not per GPIO line */
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
+
+ spin_lock_irqsave(bank-lock, flags);
if (bank-regs-pinctrl) {
void __iomem *reg = bank-base + bank-regs-pinctrl;
@@ -438,11 +447,30 @@ static void omap_enable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+
+ if (is_irq) {
+ omap_set_gpio_direction(bank, offset, 1);
+ bank-irq_usage |= BIT(offset);
+ } else {
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ bank-mod_usage |= BIT(offset);
+ }
The OMAP GPIO driver implements two Core interfaces IRQ-chip and GPIO-chip
which, in general,
more or less independent.
So, I don't think, that it's good to mix GPIO-IRQ-chip specific code with
GPIO-chip code.
And this even don't really correspond the purpose of omap_enable_gpio_module()
:( and might
introduce misunderstanding of code. The worst thing is that future fixes in
IRQ-chip may
affect on on GPIO-chip and vise versa :(
Could we keep omap_xxx_gpio_module() functions responsible only for GPIO bank
PM and
enabling/disabling?
+ spin_unlock_irqrestore(bank-lock, flags);
}
-static void omap_disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+static void omap_disable_gpio_module(struct gpio_bank *bank, unsigned offset,
+ bool is_irq)
{
void __iomem *base = bank-base;
+ unsigned long flags;
+
+ spin_lock_irqsave(bank-lock, flags);
+ if (is_irq)
+ bank-irq_usage = ~(BIT(offset));
+ else
+ bank-mod_usage = ~(BIT(offset));
+
+ omap_reset_gpio(bank, offset);
if (bank-regs-wkup_en
!LINE_USED(bank-mod_usage, offset)
@@ -463,6 +491,11 @@ static void omap_disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ /* PM runtime is per bank, not per GPIO line */
+ if (!BANK_USED(bank))
+ pm_runtime_put(bank-dev);
}
static int omap_gpio_is_input(struct gpio_bank *bank, unsigned offset)
@@ -472,15 +505,6 @@ static int omap_gpio_is_input(struct gpio_bank *bank,
unsigned offset)
return readl_relaxed(reg) BIT(offset);
}
-static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned offset)
-{
- if (!LINE_USED(bank-mod_usage, offset)) {
-
Re: [PATCH] mmc: core: add missing pm event in mmc_pm_notify to fix hib restore
On 23 April 2015 at 12:43, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148
l3_interrupt_handler+0x258/0x374()
4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data
Access in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Huh, that was an old bug you found. :-)
I have applied it for fixes and added the below fixes tag.
Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card
insert/removal during suspend/resume)
Thanks and kind regards!
Uffe
---
drivers/mmc/core/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c296bc0..92e7671 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2651,6 +2651,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
switch (mode) {
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
+ case PM_RESTORE_PREPARE:
spin_lock_irqsave(host-lock, flags);
host-rescan_disable = 1;
spin_unlock_irqrestore(host-lock, flags);
--
1.9.1
--
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] omap: i2c: Add calls for pinctrl state select
On Wed, Apr 22, 2015 at 12:49:02PM +0200, Pascal Huerst wrote: On 22.04.2015 12:28, Wolfram Sang wrote: I assume you have a different kernel config where something is enabled which includes the pinctrl-stuff in another include which is included by these drivers. Although, my .config was arm-allyesconfig. Can you send yours? Sure. See below. Thanks. device.h includes pinctrl/devinfo.h which includes pinctrl/consumer.h iff CONFIG_PINCTRL is enabled. So, seems my build-system didn't pick allyesconfig but another config with PINCTRL disabled. Will fix the st driver now, thanks for reporting! signature.asc Description: Digital signature
[PATCH] ARM: OMAP1: Fix OSK5912 wake-up key by removing useless CONFIG_PM defines
The wake-up key does not depend on CONFIG_PM, that just keeps it
from getting compiled producing the following warning:
board-osk.c:513:7: warning: unused variable ‘ret’ [-Wunused-variable]
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-osk.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 7436d4c..8d65309d 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -441,13 +441,11 @@ static struct spi_board_info __initdata
mistral_boardinfo[] = { {
.chip_select= 0,
} };
-#ifdef CONFIG_PM
static irqreturn_t
osk_mistral_wake_interrupt(int irq, void *ignored)
{
return IRQ_HANDLED;
}
-#endif
static void __init osk_mistral_init(void)
{
@@ -515,7 +513,7 @@ static void __init osk_mistral_init(void)
gpio_direction_input(OMAP_MPUIO(2));
irq_set_irq_type(irq, IRQ_TYPE_EDGE_RISING);
-#ifdef CONFIG_PM
+
/* share the IRQ in case someone wants to use the
* button for more than wakeup from system sleep.
*/
@@ -529,7 +527,6 @@ static void __init osk_mistral_init(void)
ret);
} else
enable_irq_wake(irq);
-#endif
} else
printk(KERN_ERR OSK+Mistral: wakeup button is awol\n);
--
2.1.4
--
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: [BUG?] drivers: net:ethernet: cpsw: add support for VLAN
On Thursday 23 April 2015 03:58 AM, Christoph Fritz wrote: Hi, has commit 3b72c2fe0c6bbec42e (drivers: net:ethernet: cpsw: add support for VLAN) introduced a bug by defining CPSW_VLAN_AWARE as BIT(1) instead of BIT(2)? +#define CPSW_VLAN_AWARE BIT(1) snip /* switch to vlan unaware mode */ - cpsw_ale_control_set(priv-ale, 0, ALE_VLAN_AWARE, 0); + cpsw_ale_control_set(priv-ale, priv-host_port, ALE_VLAN_AWARE, + CPSW_ALE_VLAN_AWARE); + control_reg = readl(priv-regs-control); + control_reg |= CPSW_VLAN_AWARE; + writel(control_reg, priv-regs-control); See TRM [1] page 1980 (14.5.1.2 CONTROL Register), there bit CPSW_VLAN_AWARE is number 2. I didn't do any tests, just stumbled upon. [1]: http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf Its bug in TRM, will check with TRM team and update here. Regards Mugunthan V N -- 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
