Re: [PATCH] dmaengine: edma: No need save/restore interrupt flags during spin_lock in IRQ
On Thu, Apr 17, 2014 at 12:58:33AM -0500, Joel Fernandes wrote:
The vchan lock in edma_callback is acquired in hard interrupt context. As
interrupts are already disabled, there's no point in save/restoring interrupt
mask bit or cpsr flags.
Get rid of flags local variable and use spin_lock instead of
spin_lock_irqsave.
Applied, thanks
--
~Vinod
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 91849aa..25a75e2 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -638,7 +638,6 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
struct edma_chan *echan = data;
struct device *dev = echan-vchan.chan.device-dev;
struct edma_desc *edesc;
- unsigned long flags;
struct edmacc_param p;
edesc = echan-edesc;
@@ -649,7 +648,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
switch (ch_status) {
case EDMA_DMA_COMPLETE:
- spin_lock_irqsave(echan-vchan.lock, flags);
+ spin_lock(echan-vchan.lock);
if (edesc) {
if (edesc-cyclic) {
@@ -665,11 +664,11 @@ static void edma_callback(unsigned ch_num, u16
ch_status, void *data)
}
}
- spin_unlock_irqrestore(echan-vchan.lock, flags);
+ spin_unlock(echan-vchan.lock);
break;
case EDMA_DMA_CC_ERROR:
- spin_lock_irqsave(echan-vchan.lock, flags);
+ spin_lock(echan-vchan.lock);
edma_read_slot(EDMA_CHAN_SLOT(echan-slot[0]), p);
@@ -700,7 +699,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
edma_trigger_channel(echan-ch_num);
}
- spin_unlock_irqrestore(echan-vchan.lock, flags);
+ spin_unlock(echan-vchan.lock);
break;
default:
--
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
[PATCH 0/2] OMAP2+: optional clock handling fixes
The patches fix some opt clock handling in gpio and in hwmod. Rajendra Nayak (2): gpio: omap: prepare and unprepare the debounce clock ARM: OMAP2+: hwmod: Don't leave the optional clocks in clk_prepare()ed state arch/arm/mach-omap2/omap_hwmod.c | 13 ++--- drivers/gpio/gpio-omap.c | 10 +- 2 files changed, 7 insertions(+), 16 deletions(-) -- 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
[PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg,
u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
writel_relaxed(debounce, reg);
@@ -245,7 +245,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
bank-dbck_enable_mask = val;
writel_relaxed(val, reg);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
/*
* Enable debounce clock per module.
* This call is mandatory because in omap_gpio_request() when
@@ -290,7 +290,7 @@ static void _clear_gpio_debounce(struct gpio_bank *bank,
unsigned gpio)
bank-context.debounce = 0;
writel_relaxed(bank-context.debounce, bank-base +
bank-regs-debounce);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
--
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
[PATCH 2/2] ARM: OMAP2+: hwmod: Don't leave the optional clocks in clk_prepare()ed state
At hwmod init, theres no reason why optional clocks should be left in
clk_prepare()ed state as these are actually directly controlled by the
drivers themselves. Let the drivers prepare/unprepare as well as enable/
disable them.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson bcous...@baylibre.com
---
arch/arm/mach-omap2/omap_hwmod.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1f33f5d..9e3afc9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -857,15 +857,6 @@ static int _init_opt_clks(struct omap_hwmod *oh)
continue;
}
oc-_clk = c;
- /*
-* HACK: This needs a re-visit once clk_prepare() is implemented
-* to do something meaningful. Today its just a no-op.
-* If clk_prepare() is used at some point to do things like
-* voltage scaling etc, then this would have to be moved to
-* some point where subsystems like i2c and pmic become
-* available.
-*/
- clk_prepare(oc-_clk);
}
return ret;
@@ -945,7 +936,7 @@ static void _enable_optional_clocks(struct omap_hwmod *oh)
if (oc-_clk) {
pr_debug(omap_hwmod: enable %s:%s\n, oc-role,
__clk_get_name(oc-_clk));
- clk_enable(oc-_clk);
+ clk_prepare_enable(oc-_clk);
}
}
@@ -960,7 +951,7 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)
if (oc-_clk) {
pr_debug(omap_hwmod: disable %s:%s\n, oc-role,
__clk_get_name(oc-_clk));
- clk_disable(oc-_clk);
+ clk_disable_unprepare(oc-_clk);
}
}
--
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: [STLinux Kernel] [PATCH 3/4] ARM: dts: Typo s/interrupts-names/interrupt-names/g
Acked-by : Patrice Chotard patrice.chot...@st.com
Thanks
On 04/22/2014 08:40 PM, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Srinivas Kandagatla srinivas.kandaga...@st.com
Cc: linux-omap@vger.kernel.org
Cc: ker...@stlinux.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/boot/dts/am33xx.dtsi |4 ++--
arch/arm/boot/dts/am4372.dtsi |4 ++--
arch/arm/boot/dts/stih415-pinctrl.dtsi | 10 +-
arch/arm/boot/dts/stih416-pinctrl.dtsi | 10 +-
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 07f283c20eb1..cb6811e5ae5a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -802,7 +802,7 @@
0x4600 0x40;
reg-names = mpu, dat;
interrupts = 80, 81;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 8,
edma 9;
@@ -816,7 +816,7 @@
0x4640 0x40;
reg-names = mpu, dat;
interrupts = 82, 83;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 10,
edma 11;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a26831..d1f8707ff1df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -691,7 +691,7 @@
0x4600 0x40;
reg-names = mpu, dat;
interrupts = 80, 81;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 8,
edma 9;
@@ -705,7 +705,7 @@
0x4640 0x40;
reg-names = mpu, dat;
interrupts = 82, 83;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 10,
edma 11;
diff --git a/arch/arm/boot/dts/stih415-pinctrl.dtsi
b/arch/arm/boot/dts/stih415-pinctrl.dtsi
index f09fb10a3791..81df870e5ee6 100644
--- a/arch/arm/boot/dts/stih415-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih415-pinctrl.dtsi
@@ -49,7 +49,7 @@
reg = 0xfe61f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfe61 0x5000;
PIO0: gpio@fe61 {
@@ -187,7 +187,7 @@
reg = 0xfee0f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfee0 0x8000;
PIO5: gpio@fee0 {
@@ -282,7 +282,7 @@
reg = 0xfe82f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfe82 0x8000;
PIO13: gpio@fe82 {
@@ -423,7 +423,7 @@
reg = 0xfd6bf080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfd6b 0x3000;
PIO100: gpio@fd6b {
@@ -460,7 +460,7 @@
reg = 0xfd33f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfd33 0x5000;
PIO103: gpio@fd33 {
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi
b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index aeea304086eb..250d5ecc951e 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@
Re: regressions in linux-next?
Hello Nishanth and Tony, On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon n...@ti.com wrote: On 01:08-20140423, Javier Martinez Canillas wrote: [...] on AM335x-sk: So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back. Great, thanks a lot for your help and sorry for the inconvenience! Yep - If I am correct, and as we all suspected, GPIO0_7 which controls the VTT regulator for DDR is getting configured as input, instead of output. http://slexy.org/raw/s2gReMRZI6 (with diff: http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..) Anyways, the key log is [0]: gpiochip_irq_map - calls irq_set_irq_type(irq, chip-irq_default_type); which inturn triggers: gpio-omap.c's gpio_irq_type in this, logic: if (!LINE_USED(bank-mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic walks through setting every GPIO to input!). The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered. Thanks a lot for figuring out what was going on here. I think that is not correct for gpiochip_irq_map() to call this function. After all creating a mapping doesn't mean that the GPIO is actually used as an IRQ. There are probably many hacks possible, but a cleaner solution might involve gpio_irqchip knowing when to set the type and knowing which gpios not to mess with. Example hack: Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE, in gpio-omap's gpio_irq_type could do: if (type == IRQ_TYPE_NONE) return 0; boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through.. Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas javier.marti...@collabora.co.uk Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function Creating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only means that it could be used. So, calling irq_set_irq_type() is not correct since that is already done either when a driver calls request_irq() or when the OF core calls of_irq_to_resource() because a device node defined a GPIO controller phandle as its interrupt-parent. In either case irq_set_irq_type() will be called and the GPIO controller driver will take any required action for an IRQ. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/gpio/gpiolib.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index c12fe9d..b493781 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); return 0; } -- 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 v2 05/13] extcon: extcon-class: improve extcon client API
On 04/22/2014 05:03 PM, Aaro Koskinen wrote: Hi, On Tue, Apr 22, 2014 at 08:21:35AM +0200, Robert Baldyga wrote: On 04/19/2014 12:52 PM, Aaro Koskinen wrote: On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: dev_info(pdev-dev, - OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n, - (rev 4) 0xf, rev 0xf, config-extcon, otg_dev-id, + OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n, + (rev 4) 0xf, rev 0xf, otg_dev-id, otg_dev-vbus); This change is unrelated to the patch and not needed. It's related because we no longer use config-extcon since we have cable-oriented API. We can keep displaying it, but this value is actually meaningless. It's not completely meaningless, as the cable is searched using that name. Yes, I see, you're right. I have forgot that this driver doesn't use devicetree. I will restore displaying extcon name. Thanks! Robert Baldyga Samsung RD Institute Poland -- 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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode
On 04/12/2014 06:02 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [140412 02:01]:
On 04/11/2014 02:47 AM, Tony Lindgren wrote:
@@ -282,6 +283,7 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
+ omap3_vc_set_pmic_signaling(core_next_state);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
I think this implementation is sub-optimal, as it only scales
voltages if core is entering idle state. MPU only idle is possible,
however you do not scale voltages in this case.
Hmm that's same as PWRDM_POWER_RET? That's working too.
Or do you have something else in mind that I'm not aware
of?
No, I mean the case where core_next_state == PWRDM_POWER_ON, but
mpu_next_state = PWRDM_POWER_RET. You could scale MPU voltage in this
case but you don't with this implementation.
@@ -220,6 +220,78 @@ static inline u32 omap_usec_to_32k(u32 usec)
return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
}
+void omap3_vc_set_pmic_signaling(int core_next_state)
+{
+ u32 voltctrl;
+
+ voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTCTRL_OFFSET);
Just a note here, I am currently working on trying to get rid of all
the direct prm_read/write calls outside PRCM drivers, this and rest
should use voltdm-read/write.
OK, sounds like you already have a patch for that in your
3.14-rc4-cm-prm-driver-wip branch?
Yes, there is a patch for that.
Let's do the fixes first, then it's going to be a lot easier for
us to test the rest of the PRMC changes.
+ /*
+* By default let's use I2C4 signaling for retention idle
+* and sys_off_mode pin signaling for off idle. This way we
+* have sys_clk_req pin go down for retention and both
+* sys_clk_req and sys_off_mode pins will go down for off
+* idle. And we can also scale voltages to zero for off-idle.
+* Note that no actual voltage scaling will happen unless the
+* board specific twl4030 PMIC scripts are loaded.
+*/
+ val = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VOLTCTRL_OFFSET);
Why not use the I2C4 signalling for off-mode? This way the voltages
can be scaled to 0.6V even without any board specific scripts.
Using I2C4 works too, we're just missing a place to set
and clear OMAP3430_PRM_VOLTCTRL_SEL_OFF bit currently. Sounds
like eventually we should allow changing it dynamically somewhere.
You can't check the presence of the scripts here?
But for now, SEL_OFF should be enabled as it allows debugging PM
by looking at the sys_clkreq and sys_off_mode pins no matter if
there are board specific scripts or not. The sys_off_mode won't
toggle if things are configured to use I2C4, which is confusing.
You can always measure the voltage rails directly also, but yea, it is
more convenient to just look at the led.
-Tero
--
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/3] Documentation: dts: OMAP: Fix typos in DRA752 device name
On Friday 14 March 2014 02:50 PM, Rajendra Nayak wrote: DRA752 device is wrongly documented as DRA742 device. Fix the typo. Thanks to Nishanth for pointing out that the device part number is infact DRA742. The compatible sting infact seems to have a typo. I'll fix that up a post a v2 of this series soon. Signed-off-by: Rajendra Nayak rna...@ti.com --- .../devicetree/bindings/arm/omap/omap.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index af9b4a0..0491868 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -48,7 +48,7 @@ SoC Families: compatible = ti,omap4 - OMAP5 generic - defaults to OMAP5430 compatible = ti,omap5 -- DRA7 generic - defaults to DRA742 +- DRA7 generic - defaults to DRA752 compatible = ti,dra7 - AM43x generic - defaults to AM4372 compatible = ti,am43 @@ -79,7 +79,7 @@ SoCs: - OMAP5432 compatible = ti,omap5432, ti,omap5 -- DRA742 +- DRA752 compatible = ti,dra7xx, ti,dra7 - AM4372 -- 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 0/4] ARM: DRA7: Add support for DRA72x devices
DRA72x devices are single core Cortex A15 devices belonging to the DRA7 family (Similar to the DRA74x devices which are dual core Cortex A15 based) The patches (based off 3.15-rc2) add minimal DT/kernel modifications to add boot support for DRA72x devices reusing all the kernel data for DRA74x devices. Rajendra Nayak (4): ARM: dts: dra7-evm: Remove the wrong and undocumented compatible ARM: dts: Add support for DRA72x family of devices ARM: OMAP2+: Add machine entry for dra72x devices ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients .../devicetree/bindings/arm/omap/omap.txt | 12 +++-- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts |6 +-- arch/arm/boot/dts/dra7.dtsi| 27 arch/arm/boot/dts/dra72-evm.dts| 24 ++ arch/arm/boot/dts/dra72x.dtsi | 25 +++ arch/arm/boot/dts/dra74x.dtsi | 41 + arch/arm/mach-omap2/board-generic.c| 46 ++-- arch/arm/mach-omap2/soc.h |7 +++ 9 files changed, 144 insertions(+), 47 deletions(-) create mode 100644 arch/arm/boot/dts/dra72-evm.dts create mode 100644 arch/arm/boot/dts/dra72x.dtsi create mode 100644 arch/arm/boot/dts/dra74x.dtsi -- 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
[PATCH v2 1/4] ARM: dts: dra7-evm: Remove the wrong and undocumented compatible
ti,dra752 is neither documented nor correct, since the device is actually a
dra742 device as rightly documented in dt bindings.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7807429 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -11,7 +11,7 @@
/ {
model = TI DRA7;
- compatible = ti,dra7-evm, ti,dra752, ti,dra7;
+ compatible = ti,dra7-evm, ti,dra7;
memory {
device_type = memory;
--
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
[PATCH v2 3/4] ARM: OMAP2+: Add machine entry for dra72x devices
The only difference from the dra74x devices is the missing .smp entry.
While at it, also fix the use of __initdata (across the file) and replace them
with __initconst as reported by checkpatch
ERROR: Use of const init definition must use __initconst
+static const char *dra72x_boards_compat[] __initdata = {
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 46 +--
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index b8920b6..4d1222d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -43,7 +43,7 @@ static void __init omap_generic_init(void)
}
#ifdef CONFIG_SOC_OMAP2420
-static const char *omap242x_boards_compat[] __initdata = {
+static const char *omap242x_boards_compat[] __initconst = {
ti,omap2420,
NULL,
};
@@ -62,7 +62,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP2430
-static const char *omap243x_boards_compat[] __initdata = {
+static const char *omap243x_boards_compat[] __initconst = {
ti,omap2430,
NULL,
};
@@ -81,7 +81,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
-static const char *omap3_boards_compat[] __initdata = {
+static const char *omap3_boards_compat[] __initconst = {
ti,omap3430,
ti,omap3,
NULL,
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap36xx_boards_compat[] __initdata = {
+static const char *omap36xx_boards_compat[] __initconst = {
ti,omap36xx,
NULL,
};
@@ -118,7 +118,7 @@ DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap3_gp_boards_compat[] __initdata = {
+static const char *omap3_gp_boards_compat[] __initconst = {
ti,omap3-beagle,
timll,omap3-devkit8000,
NULL,
@@ -137,7 +137,7 @@ DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *am3517_boards_compat[] __initdata = {
+static const char *am3517_boards_compat[] __initconst = {
ti,am3517,
NULL,
};
@@ -157,7 +157,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
-static const char *am33xx_boards_compat[] __initdata = {
+static const char *am33xx_boards_compat[] __initconst = {
ti,am33xx,
NULL,
};
@@ -177,7 +177,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP4
-static const char *omap4_boards_compat[] __initdata = {
+static const char *omap4_boards_compat[] __initconst = {
ti,omap4460,
ti,omap4430,
ti,omap4,
@@ -199,7 +199,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP5
-static const char *omap5_boards_compat[] __initdata = {
+static const char *omap5_boards_compat[] __initconst = {
ti,omap5432,
ti,omap5430,
ti,omap5,
@@ -221,7 +221,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM43XX
-static const char *am43_boards_compat[] __initdata = {
+static const char *am43_boards_compat[] __initconst = {
ti,am4372,
ti,am43,
NULL,
@@ -240,13 +240,14 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
+static const char *dra74x_boards_compat[] __initconst = {
+ ti,dra74x,
ti,dra7xx,
ti,dra7,
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +256,26 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ ti,dra72x,
+ ti,dra7xx,
+ ti,dra7,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72X (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72x_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
#endif
--
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
[PATCH v2 2/4] ARM: dts: Add support for DRA72x family of devices
DRA72x is a single core cortex A15 device with most infrastructure IPs otherwise
same as whats on the DRA74x devices.
So move the cpu nodes into dra74x.dtsi and dra72x.dtsi respectively.
Also add a minimal dra72-evm dts file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/arm/omap/omap.txt | 12 --
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts |6 +--
arch/arm/boot/dts/dra7.dtsi| 27 -
arch/arm/boot/dts/dra72-evm.dts| 24
arch/arm/boot/dts/dra72x.dtsi | 25
arch/arm/boot/dts/dra74x.dtsi | 41
7 files changed, 104 insertions(+), 34 deletions(-)
create mode 100644 arch/arm/boot/dts/dra72-evm.dts
create mode 100644 arch/arm/boot/dts/dra72x.dtsi
create mode 100644 arch/arm/boot/dts/dra74x.dtsi
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 36ede19..88de8e0 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -79,8 +79,11 @@ SoCs:
- OMAP5432
compatible = ti,omap5432, ti,omap5
-- DRA742
- compatible = ti,dra7xx, ti,dra7
+- DRA74x
+ compatible = ti,dra74x, ti,dra7xx, ti,dra7
+
+- DRA72x
+ compatible = ti,dra72x, ti,dra7xx, ti,dra7
- AM4372
compatible = ti,am4372, ti,am43
@@ -121,4 +124,7 @@ Boards:
compatible = ti,am437x-gp-evm, ti,am4372, ti,am43
- DRA7 EVM: Software Developement Board for DRA7XX
- compatible = ti,dra7-evm, ti,dra7
+ compatible = ti,dra7-evm, ti,dra74x, ti,dra7
+
+- DRA72 EVM: Software Development Board for DRA72x
+ compatible = ti,dra72-evm, ti,dra72x, ti,dra7
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..ff98a97 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -288,7 +288,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
am437x-gp-evm.dtb \
- dra7-evm.dtb
+ dra7-evm.dtb \
+ dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcom-msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 7807429..a07fb30 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -7,11 +7,11 @@
*/
/dts-v1/;
-#include dra7.dtsi
+#include dra74x.dtsi
/ {
- model = TI DRA7;
- compatible = ti,dra7-evm, ti,dra7;
+ model = TI DRA74x;
+ compatible = ti,dra7-evm, ti,dra74x, ti,dra7;
memory {
device_type = memory;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..e27fec7 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -33,33 +33,6 @@
serial5 = uart6;
};
- cpus {
- #address-cells = 1;
- #size-cells = 0;
-
- cpu0: cpu@0 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 0;
-
- operating-points =
- /* kHzuV */
- 100 106
- 1176000 116
- ;
-
- clocks = dpll_mpu_ck;
- clock-names = cpu;
-
- clock-latency = 30; /* From omap-cpufreq driver */
- };
- cpu@1 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 1;
- };
- };
-
timer {
compatible = arm,armv7-timer;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
new file mode 100644
index 000..d105e66
--- /dev/null
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dra72x.dtsi
+
+/ {
+ model = TI DRA72x;
+ compatible = ti,dra72-evm, ti,dra72x, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1024 MB */
+ };
+};
+
+uart1 {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/dra72x.dtsi
[PATCH v2 4/4] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/soc.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 30abcc8..b8a4834 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -245,6 +245,8 @@ IS_AM_SUBCLASS(437x, 0x437) #define soc_is_omap54xx() 0 #define soc_is_omap543x() 0 #define soc_is_dra7xx()0 +#define soc_is_dra74x()0 +#define soc_is_dra72x()0 #if defined(MULTI_OMAP2) # if defined(CONFIG_ARCH_OMAP2) @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430) #if defined(CONFIG_SOC_DRA7XX) #undef soc_is_dra7xx +#undef soc_is_dra74x +#undef soc_is_dra72x #define soc_is_dra7xx()(of_machine_is_compatible(ti,dra7)) +#define soc_is_dra74x()(of_machine_is_compatible(ti,dra74x)) +#define soc_is_dra72x()(of_machine_is_compatible(ti,dra72x)) + #endif /* Various silicon revisions for omap2 */ -- 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: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com; Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe shouldn't
fail here.
+ }
+ ret = regulator_enable(exynos-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ goto err2;
+ }
+
Thanks
--
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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com; Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: OMAP2+: Add machine entry for dra72x devices
On Wednesday 23 April 2014 14:32:54 Rajendra Nayak wrote:
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
+static const char *dra74x_boards_compat[] __initconst = {
+ ti,dra74x,
ti,dra7xx,
ti,dra7,
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +256,26 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ ti,dra72x,
+ ti,dra7xx,
+ ti,dra7,
+ NULL,
+};
Now you have two lists that both match ti,dra7xx and ti,dra7, which will
cause problems if you have a new machine that doesn't match the more specific
strings.
Note that we intentionally don't allow wildcards in compatible strings
to avoid this situation.
Please remove all strings with an x in them from the dts files and from
the source, and make sure you have no duplication between the lists.
Arnd
--
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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi,
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com;
Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
--
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: regressions in linux-next?
On 04/23/2014 10:24 AM, Javier Martinez Canillas wrote: Hello Nishanth and Tony, On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon n...@ti.com wrote: On 01:08-20140423, Javier Martinez Canillas wrote: [...] on AM335x-sk: So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back. Great, thanks a lot for your help and sorry for the inconvenience! Yep - If I am correct, and as we all suspected, GPIO0_7 which controls the VTT regulator for DDR is getting configured as input, instead of output. http://slexy.org/raw/s2gReMRZI6 (with diff: http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..) Anyways, the key log is [0]: gpiochip_irq_map - calls irq_set_irq_type(irq, chip-irq_default_type); which inturn triggers: gpio-omap.c's gpio_irq_type in this, logic: if (!LINE_USED(bank-mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic walks through setting every GPIO to input!). The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered. Thanks a lot for figuring out what was going on here. I think that is not correct for gpiochip_irq_map() to call this function. After all creating a mapping doesn't mean that the GPIO is actually used as an IRQ. There are probably many hacks possible, but a cleaner solution might involve gpio_irqchip knowing when to set the type and knowing which gpios not to mess with. Example hack: Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE, in gpio-omap's gpio_irq_type could do: if (type == IRQ_TYPE_NONE) return 0; boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through.. Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas javier.marti...@collabora.co.uk Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function Creating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only means that it could be used. So, calling irq_set_irq_type() is not correct since that is already done either when a driver calls request_irq() or when the OF core calls of_irq_to_resource() because a device node defined a GPIO controller phandle as its interrupt-parent. In either case irq_set_irq_type() will be called and the GPIO controller driver will take any required action for an IRQ. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/gpio/gpiolib.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index c12fe9d..b493781 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); return 0; } Thanks, this makes am335x-evmsk boot with linux-next. Tested-by: Peter Ujfalusi peter.ujfal...@ti.com -- 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 3/4] ARM: OMAP2+: Add machine entry for dra72x devices
On Wednesday 23 April 2014 03:21 PM, Arnd Bergmann wrote:
On Wednesday 23 April 2014 14:32:54 Rajendra Nayak wrote:
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
+static const char *dra74x_boards_compat[] __initconst = {
+ ti,dra74x,
ti,dra7xx,
ti,dra7,
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +256,26 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ ti,dra72x,
+ ti,dra7xx,
+ ti,dra7,
+ NULL,
+};
Now you have two lists that both match ti,dra7xx and ti,dra7, which will
cause problems if you have a new machine that doesn't match the more specific
strings.
Note that we intentionally don't allow wildcards in compatible strings
to avoid this situation.
Please remove all strings with an x in them from the dts files and from
the source, and make sure you have no duplication between the lists.
Okay, will fix and repost. thanks.
Arnd
--
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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi,
On Wed, Apr 23, 2014 at 4:27 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hi,
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com;
Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
Yea, actually after the patch (which got merged in 3.15 rc1)
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the USB stops working, and that's because the regulators related to
usb are not turned on by default (ldo12 and ldo15 to be specific).
So we need to enable those regulators, which ofcourse the driver
should be doing, if i am not wrong.
Similar is the reason for EHCI, and OHCI exynos patches in this series.
I shall be sending the dt patch for this soon.
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
On Wednesday, April 23, 2014 8:06 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 7:58 PM, Anton Tikhomirov wrote:
On Wednesday, April 23, 2014 6:52 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 6:27 PM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
Yea, actually after the patch (which got merged in 3.15 rc1)
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the USB stops working, and that's because the regulators related to
usb are not turned on by default (ldo12 and ldo15 to be specific).
So we need to enable those regulators, which ofcourse the driver
should be doing, if i am not wrong.
Similar is the reason for EHCI, and OHCI exynos patches in this series.
Oh, I see. Thank you for your explanation.
I shall be sending the dt patch for this soon.
OK, I will wait for your patch.
Best regards,
Jingoo Han
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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/3] usb: ohci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
1.7.10.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: [PATCH 2/3] usb: ehci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ehci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1d8c47..a3ca8cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -20,6 +20,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)-priv)
@@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
exynos_ehci-otg = phy-otg;
}
+ exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ehci-vdd33)) {
+ err = PTR_ERR(exynos_ehci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ehci-vdd10)) {
+ err = PTR_ERR(exynos_ehci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ehci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -178,6 +203,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
return rc;
}
@@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
+ int ret;
+
+ ret = regulator_enable(exynos_ehci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ehci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ehci-clk);
--
1.7.10.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: regressions in linux-next?
On Wed, Apr 23, 2014 at 9:24 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas javier.marti...@collabora.co.uk Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function (...) So no setting a default type in the mapping function... - irq_set_irq_type(irq, chip-irq_default_type); But there are drivers exploiting this to set up the hardware to some default state :-( What about this: if (chip-irq_default_type != IRQ_TYPE_NONE) irq_set_irq_type(irq, chip-irq_default_type); This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping. Yours, Linus Walleij -- 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: regressions in linux-next?
On 04/23/2014 08:01 AM, Linus Walleij wrote: On Wed, Apr 23, 2014 at 9:24 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas javier.marti...@collabora.co.uk Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function (...) So no setting a default type in the mapping function... - irq_set_irq_type(irq, chip-irq_default_type); But there are drivers exploiting this to set up the hardware to some default state :-( What about this: if (chip-irq_default_type != IRQ_TYPE_NONE) irq_set_irq_type(irq, chip-irq_default_type); This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping. What if these drivers depend on IRQ_TYPE_NONE to do something for the GPIO pins? would you expect these drivers to pass IRQ_TYPE_DEFAULT? OR I wonder if we could pass some flag like -1 for platforms that dont care? -- 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
linux-next regressions (next-20140423 A15: uevm/dra7)
Hi, Will be great if someone else could confirm as well. next-20140423-multi_lpae_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2HJJ9SKzM 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2HoDCbtO0 TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-multi_v7_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2070nXdAg 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s20wKQEqGp TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-omap2plus_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2XrqUmRqz 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2gQkdoTH4 Exactly the same setup (rootfs and bootloader) as of yesterday's built image: next-20140422-omap2plus_defconfig 1: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20sRLHVgN 2: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20ZxlYWaB TOTAL = 2 boards, Booted Boards = 2, No Boot boards = 0 -- 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: [PATCH v2] gpio: omap: implement get_direction
On Tue, Apr 22, 2014 at 3:31 PM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v2: rework return value calculation
(...)
I don't see why this need to be a broken-out function? Can it not
be factored into gpio_get_direction?
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+
+ reg += bank-regs-direction;
+ l = (readl_relaxed(reg) gpio);
+
+ return (l 0x0001);
Rewrite the last two statements like this:
#include linux/bitops.h
return !!(readl_relaxed(reg) BIT(gpio));
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock_irqsave(bank-lock, flags);
+ dir = _get_gpio_direction(bank, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
So since _get_gpio_direction is never called from unlocked context,
can it not just be part of this function then?
(I make a mental note to prefix all functions in this driver
with omap_*)
Yours,
Linus Walleij
--
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: linux-next regressions (next-20140423 A15: uevm/dra7)
On 04/23/2014 04:47 PM, Nishanth Menon wrote: Hi, Will be great if someone else could confirm as well. next-20140423-multi_lpae_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2HJJ9SKzM 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2HoDCbtO0 TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-multi_v7_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2070nXdAg 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s20wKQEqGp TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-omap2plus_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2XrqUmRqz 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2gQkdoTH4 I suspect you are using ext4 as rootfs? I just sent a fix for this or similar crash (as in the OMAP5432uEVM log): http://marc.info/?l=linux-kernelm=139826085609497w=2 Exactly the same setup (rootfs and bootloader) as of yesterday's built image: next-20140422-omap2plus_defconfig 1: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20sRLHVgN 2: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20ZxlYWaB TOTAL = 2 boards, Booted Boards = 2, No Boot boards = 0 -- Péter -- 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 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
On Tue, Apr 22, 2014 at 6:10 PM, Tony Lindgren t...@atomide.com wrote: Shall I apply this patch or will you funnel it through ARM SoC due to deps? No deps except boards hanging without it.. Please feel free to take this one, prererrably as a fix for the -rc series if no objections. Yes this is -rc material. Queued for fixes. Thanks! Yours, Linus Walleij -- 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: linux-next regressions (next-20140423 A15: uevm/dra7)
On 04/23/2014 08:55 AM, Peter Ujfalusi wrote: On 04/23/2014 04:47 PM, Nishanth Menon wrote: Hi, Will be great if someone else could confirm as well. next-20140423-multi_lpae_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2HJJ9SKzM 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2HoDCbtO0 TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-multi_v7_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2070nXdAg 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s20wKQEqGp TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 next-20140423-omap2plus_defconfig 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2XrqUmRqz 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2gQkdoTH4 I suspect you are using ext4 as rootfs? I just sent a fix for this or similar crash (as in the OMAP5432uEVM log): http://marc.info/?l=linux-kernelm=139826085609497w=2 yep... I cherry-picked https://patchwork.kernel.org/patch/4041201/ https://patchwork.kernel.org/patch/4041211/ and the platforms look fine in the round of testing I did. please feel free to add Tested-by: Nishanth Menon n...@ti.com -- 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: regressions in linux-next?
On Wed, Apr 23, 2014 at 3:29 PM, Nishanth Menon n...@ti.com wrote: On 04/23/2014 08:01 AM, Linus Walleij wrote: What about this: if (chip-irq_default_type != IRQ_TYPE_NONE) irq_set_irq_type(irq, chip-irq_default_type); This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping. What if these drivers depend on IRQ_TYPE_NONE to do something for the GPIO pins? Yeah :-( would you expect these drivers to pass IRQ_TYPE_DEFAULT? Actually that sounds like a good idea. Maybe we can go over the few drivers that pass IRQ_TYPE_NONE and see what they actually want. There are not *too* many users of this call yet. OR I wonder if we could pass some flag like -1 for platforms that dont care? The flags parameter to gpiochip_irqchip_add() is unsigned... Switching to IRQ_TYPE_DEFAULT for drivers that want this is likely the sane thing to do. Yours, Linus Walleij -- 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] arm: omap: Immutable branch between MFD and ARM OMAP due for the v3.16 merge-window
Hi Tony, Sorry for the delay - I've been snowed under recently. As requested, you patch based on v3.14 ( for some reason :) ). The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-omap-3.16 for you to fetch changes up to a613b739b8c08eab811e677810045cc0522fc3e6: mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree (2014-04-23 15:31:05 +0100) Immutable branch between MFD and ARM OMAP due for v3.16 merge-window. Tony Lindgren (1): mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree arch/arm/mach-omap2/omap_twl.c | 60 drivers/mfd/twl-core.c | 15 +++ 2 files changed, 15 insertions(+), 60 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 RFC] ARM: dts: am335x: update USB DT references
* Benoit Cousson bcous...@baylibre.com [140422 07:14]:
Hi Leigh,
On 16/04/2014 13:26, Leigh Brown wrote:
In ARM: dts: am33xx: correcting dt node unit address for usb, the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses. However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.
This patch corrects the references for the affected dts files.
Thanks for the fix. BTW, why is it a RFC? Do you plan to send an updated
version?
FYI, even with this fix, the BBB still does not have a working MUSB on
3.15-rc2. Have you observed that as well?
Signed-off-by: Leigh Brown le...@solinno.co.uk
If this is a final version, I'll apply it for -rc3.
Looks like I already have this in omap-for-v3.15/fixes-v2, sorry
looks like I never replied to this one.
Regards,
Tony
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
arch/arm/boot/dts/am335x-evmsk.dts| 4 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi| 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..2e7d932 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -183,7 +183,7 @@
usb {
status = okay;
-control@44e1 {
+control@44e10620 {
status = okay;
};
@@ -204,7 +204,7 @@
dr_mode = host;
};
-dma-controller@07402000 {
+dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 28ae040..77df10d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -331,7 +331,7 @@
usb {
status = okay;
-control@44e1 {
+control@44e10620 {
status = okay;
};
@@ -352,7 +352,7 @@
dr_mode = host;
};
-dma-controller@07402000 {
+dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..ab23885 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -364,7 +364,7 @@
usb {
status = okay;
-control@44e1 {
+control@44e10620 {
status = okay;
};
@@ -385,7 +385,7 @@
dr_mode = host;
};
-dma-controller@07402000 {
+dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 7063311..5942e7d 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -202,7 +202,7 @@
usb {
status = okay;
-control@44e1 {
+control@44e10620 {
status = okay;
};
@@ -223,7 +223,7 @@
dr_mode = host;
};
-dma-controller@07402000 {
+dma-controller@47402000 {
status = okay;
};
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
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: do not set up hardware for IRQ_TYPE_NONE
Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Nishanth Menon n...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- TI folks: can you provide a Tested-by tag if this makes your OMAPs work? I am pretty sure the other platforms will be unaffected, if they aren't I will switch them over to react to IRQ_TYPE_DEFAULT. --- drivers/gpio/gpiolib.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index ee1819fdcf35..97d173e9aa2d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); + /* +* No set-up of the hardware will happen if IRQ_TYPE_NONE +* is passed as default type. +*/ + if (chip-irq_default_type != IRQ_TYPE_NONE) + irq_set_irq_type(irq, chip-irq_default_type); return 0; } @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip) * @first_irq: if not dynamically assigned, the base (first) IRQ to * allocate gpiochip irqs from * @handler: the irq handler to use (often a predefined irq core function) - * @type: the default type for IRQs on this irqchip + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE + * to have the core avoid setting up any default type in the hardware. * * This function closely associates a certain irqchip with a certain * gpiochip, providing an irq domain to translate the local IRQs to -- 1.9.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
Re: regressions in linux-next?
On Wed, Apr 23, 2014 at 4:38 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Wed, Apr 23, 2014 at 3:29 PM, Nishanth Menon n...@ti.com wrote:
On 04/23/2014 08:01 AM, Linus Walleij wrote:
What about this:
if (chip-irq_default_type != IRQ_TYPE_NONE)
irq_set_irq_type(irq, chip-irq_default_type);
This way you can pass IRQ_TYPE_NONE and nothing happens in
the mapping.
What if these drivers depend on IRQ_TYPE_NONE to do something for the
GPIO pins?
Yeah :-(
would you expect these drivers to pass IRQ_TYPE_DEFAULT?
Actually that sounds like a good idea. Maybe we can go over the few
drivers that pass IRQ_TYPE_NONE and see what they actually want.
There are not *too* many users of this call yet.
OR I wonder
if we could pass some flag like -1 for platforms that dont care?
The flags parameter to gpiochip_irqchip_add() is unsigned...
Switching to IRQ_TYPE_DEFAULT for drivers that want this is likely
the sane thing to do.
Yours,
Linus Walleij
I prefer to have an explicit way to tell gpiolib whether it has to set
a default IRQ type or not than relying on passing magic numbers like
-1.
What do you think about the following patch? Although I agree that if
we can use IRQ_TYPE_NONE as you propose then tht is a much better and
efficient solution that this patch.
Best regards,
Javier
From 8720c6798f86b71d8b11c57ecb7bae86a4ee656b Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 23 Apr 2014 16:45:05 +0200
Subject: [RFC] gpio: don't set IRQ default type unconditionally
Creating a mapping for a GPIO pin into the Linux virtual IRQ
space does not necessarily mean that the GPIO is going to be
used as an interrupt line, it only mean that it could be used.
But current gpiolib irqchip .map function handler calls to
irq_set_irq_type() for each GPIO pin in the bank. Some drivers
assume that this function is called either because a driver
has explicitly requested an IRQ with request_irq() or that a
DT device node has defined a GPIO controller phandle as its
interrupt-parent and setups the chip accordingly.
Others drivers have different semantics and expects that a
irq_set_irq_type() would setup the hardware to be some default state.
So is better to allow each driver to choose whether they want
to set a default IRQ type on the mapping function or not.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c| 1 +
drivers/gpio/gpiolib.c | 3 ++-
include/linux/gpio/driver.h | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..2e23858 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1101,6 +1101,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
gpio += bank-width;
}
bank-chip.ngpio = bank-width;
+ bank-chip.set_irq_default = false;
ret = gpiochip_add(bank-chip);
if (ret) {
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c12fe9d..f12aea3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1402,7 +1402,8 @@ static int gpiochip_irq_map(struct irq_domain
*d, unsigned int irq,
#else
irq_set_noprobe(irq);
#endif
- irq_set_irq_type(irq, chip-irq_default_type);
+ if (chip-set_irq_default)
+ irq_set_irq_type(irq, chip-irq_default_type);
return 0;
}
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 573e4f3..168c93e 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -113,6 +113,7 @@ struct gpio_chip {
unsigned int irq_base;
irq_flow_handler_t irq_handler;
unsigned int irq_default_type;
+ bool set_irq_default;
#endif
#if defined(CONFIG_OF_GPIO)
--
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: regressions in linux-next?
On Wed, Apr 23, 2014 at 4:50 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: What do you think about the following patch? Although I agree that if we can use IRQ_TYPE_NONE as you propose then tht is a much better and efficient solution that this patch. Let's try IRQ_TYPE_NONE first and if that fails we go back to this. I've pushed the current patch to linux-next. Yours, Linus Walleij -- 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 01/11] tty: serial: add missing braces
On Tue, Apr 22, 2014 at 05:28:43PM -0700, Greg KH wrote: On Tue, Apr 22, 2014 at 09:22:56AM -0500, Felipe Balbi wrote: Hi, On Thu, Mar 20, 2014 at 02:29:57PM -0500, Felipe Balbi wrote: per CodingStyle we should have those braces, no functional changes. Signed-off-by: Felipe Balbi ba...@ti.com Greg, do you want me to refresh and resend this series ? If there are conflicts with my current tree, sure, I'd love to have that. I should be trying to dig out from my patch backlog for 3.16-rc1 by the end of this week... then I'll resend rebased on -rc2, should make your life a little easier, hopefully. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: am437x-gp-evm: Boot fixes
* Dave Gerlach d-gerl...@ti.com [140422 12:53]: On 04/22/2014 02:01 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? We've been using this configuration on this board for a while without any apparent issues. Also, am335x-evmsk already uses the same idea for the VTT regulator on board from commit 6046adb6ad701026c10adeac8d6a4138895f12e5 [ARM: dts: am335x-evmsk: Do not reset gpio0] and I am unaware of any issues with that either. OK. Do you have other GPIOs in use as interrupts for devices in these banks and do they work fine? Also, can you please test to make sure this works with the most recent Javier's GPIO patches that had the issue of not booting on am335x-evmsk? 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
[PATCH 12/13] tty: serial: omap: fix Sparse warnings
Fix the following Sparse warnings:
drivers/tty/serial/omap-serial.c:1418:49: warning: incorrect \
type in argument 2 (different address spaces)
drivers/tty/serial/omap-serial.c:1418:49:expected void const \
[noderef] asn:1*from
drivers/tty/serial/omap-serial.c:1418:49:got struct serial_rs485 \
*noident
drivers/tty/serial/omap-serial.c:1426:35: warning: incorrect \
type in argument 1 (different address spaces)
drivers/tty/serial/omap-serial.c:1426:35:expected void [noderef] \
asn:1*to
drivers/tty/serial/omap-serial.c:1426:35:got struct serial_rs485 \
*noident
Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ab22dab..d017cec 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1398,7 +1398,7 @@ serial_omap_ioctl(struct uart_port *port, unsigned int
cmd, unsigned long arg)
switch (cmd) {
case TIOCSRS485:
- if (copy_from_user(rs485conf, (struct serial_rs485 *) arg,
+ if (copy_from_user(rs485conf, (void __user *) arg,
sizeof(rs485conf)))
return -EFAULT;
@@ -1406,7 +1406,7 @@ serial_omap_ioctl(struct uart_port *port, unsigned int
cmd, unsigned long arg)
break;
case TIOCGRS485:
- if (copy_to_user((struct serial_rs485 *) arg,
+ if (copy_to_user((void __user *) arg,
(to_uart_omap_port(port)-rs485),
sizeof(rs485conf)))
return -EFAULT;
--
1.9.2.459.g68773ac
--
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 13/13] serial: 8250: add OMAP glue
NOT COMPLETE
NYET-Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 233
drivers/tty/serial/8250/Kconfig | 7 ++
drivers/tty/serial/8250/Makefile| 1 +
3 files changed, 241 insertions(+)
create mode 100644 drivers/tty/serial/8250/8250_omap.c
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
new file mode 100644
index 000..e8ae479
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -0,0 +1,233 @@
+/*
+ * 8250-omap.c - OMAP adaptation for 8250 driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * Based on omap-serial.c:
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Note: This driver is made separate from 8250 driver as we cannot
+ * over load 8250 driver with omap platform specific configuration for
+ * features like DMA, it makes easier to implement features like DMA and
+ * hardware flow control and software flow control configuration with
+ * this driver as required for the omap-platform.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/serial_8250.h
+#include linux/serial_core.h
+#include linux/serial_reg.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_gpio.h
+#include linux/platform_data/serial-omap.h
+
+#include dt-bindings/gpio/gpio.h
+
+#define OMAP_MAX_HSUART_PORTS 6
+
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
+#define OMAP_UART_TX_WAKEUP_EN BIT(7)
+
+/* Feature flags */
+#define OMAP_UART_WER_HAS_TX_WAKEUPBIT(0)
+
+#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
+#define UART_ERRATA_i291_DMA_FORCEIDLE BIT(1)
+
+#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+
+/* SCR register bitmasks */
+#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
+#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
+#define OMAP_UART_SCR_TX_EMPTY (1 3)
+
+/* FCR register bitmasks */
+#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK(0x3 6)
+#define OMAP_UART_FCR_TX_FIFO_TRIG_MASK(0x3 4)
+
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f
+
+#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
+#define OMAP_UART_DMA_CH_FREE -1
+
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+#define OMAP_MODE13X_SPEED 230400
+
+/* WER = 0x7F
+ * Enable module level wakeup in WER reg
+ */
+#define OMAP_UART_WER_MOD_WKUP 0X7F
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX0x08
+
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX0x02
+
+#define OMAP_UART_SW_CLR 0xF0
+
+#define OMAP_UART_TCR_TRIG 0x0F
+
+struct uart_omap_port {
+ struct uart_8250_port uart;
+ struct device *dev;
+ int wakeirq;
+
+ unsigned char ier;
+ unsigned char lcr;
+ unsigned char mcr;
+ unsigned char fcr;
+ unsigned char efr;
+ unsigned char dll;
+ unsigned char dlh;
+ unsigned char mdr1;
+ unsigned char scr;
+ unsigned char wer;
+
+ int line;
+
+ /*
+* Some bits in registers are cleared on a read, so they must
+* be saved whenever the register is read but the bits will not
+* be immediately processed.
+*/
+ unsigned intlsr_break_flag;
+ unsigned char msr_saved_flags;
+ charname[20];
+ unsigned long port_activity;
+ int context_loss_cnt;
+ u32 errata;
+ u8 wakeups_enabled;
+ u32 features;
+};
+
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
+
+static int serial_omap_probe(struct platform_device *pdev)
+{
+ struct uart_omap_port *up;
+ struct resource *mem;
+ void __iomem *base;
+ int
Re: [PATCH] gpio: do not set up hardware for IRQ_TYPE_NONE
Hello Linus, On Wed, Apr 23, 2014 at 4:50 PM, Linus Walleij linus.wall...@linaro.org wrote: Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Nishanth Menon n...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- TI folks: can you provide a Tested-by tag if this makes your OMAPs work? I am pretty sure the other platforms will be unaffected, if they aren't I will switch them over to react to IRQ_TYPE_DEFAULT. --- drivers/gpio/gpiolib.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index ee1819fdcf35..97d173e9aa2d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); + /* +* No set-up of the hardware will happen if IRQ_TYPE_NONE +* is passed as default type. +*/ + if (chip-irq_default_type != IRQ_TYPE_NONE) + irq_set_irq_type(irq, chip-irq_default_type); return 0; } @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip) * @first_irq: if not dynamically assigned, the base (first) IRQ to * allocate gpiochip irqs from * @handler: the irq handler to use (often a predefined irq core function) - * @type: the default type for IRQs on this irqchip + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE + * to have the core avoid setting up any default type in the hardware. * * This function closely associates a certain irqchip with a certain * gpiochip, providing an irq domain to translate the local IRQs to -- 1.9.0 I just tested on my DM3730 IGEPv2 board and GPIO are working correctly (GPIO LED and GPIO IRQ used by the ethernet controller) Thanks a lot for your help! Tested-by: Javier Martinez Canillas jav...@dowhile0.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 07/13] tty: serial: omap: cleanup variable declarations
cleanup only, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 07d4273..3813740 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1641,10 +1641,13 @@ static int serial_omap_probe_rs485(struct
uart_omap_port *up,
static int serial_omap_probe(struct platform_device *pdev)
{
- struct uart_omap_port *up;
- struct resource *mem, *irq;
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
- int ret, uartirq = 0, wakeirq = 0;
+ struct uart_omap_port *up;
+ struct resource *mem;
+ struct resource *irq;
+ int uartirq = 0;
+ int wakeirq = 0;
+ int ret;
/* The optional wakeirq may be specified in the board dts file */
if (pdev-dev.of_node) {
--
1.9.2.459.g68773ac
--
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 09/13] tty: serial: omap: switch over to devm_ioremap_resource
just using helper function to remove some duplicated
code a bit. While at that, also move allocation of
struct uart_omap_port higher in the code so that
we return much earlier in case of no memory.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index cb45e88..b46aaf3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1644,6 +1644,7 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
struct uart_omap_port *up;
struct resource *mem;
+ void __iomem *base;
int uartirq = 0;
int wakeirq = 0;
int ret;
@@ -1662,17 +1663,14 @@ static int serial_omap_probe(struct platform_device
*pdev)
return -EPROBE_DEFER;
}
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, no mem resource?\n);
- return -ENODEV;
- }
+ up = devm_kzalloc(pdev-dev, sizeof(*up), GFP_KERNEL);
+ if (!up)
+ return -ENOMEM;
- if (!devm_request_mem_region(pdev-dev, mem-start, resource_size(mem),
- pdev-dev.driver-name)) {
- dev_err(pdev-dev, memory region already claimed\n);
- return -EBUSY;
- }
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(pdev-dev, mem);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
if (gpio_is_valid(omap_up_info-DTR_gpio)
omap_up_info-DTR_present) {
@@ -1686,10 +1684,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
return ret;
}
- up = devm_kzalloc(pdev-dev, sizeof(*up), GFP_KERNEL);
- if (!up)
- return -ENOMEM;
-
if (gpio_is_valid(omap_up_info-DTR_gpio)
omap_up_info-DTR_present) {
up-DTR_gpio = omap_up_info-DTR_gpio;
@@ -1732,14 +1726,7 @@ static int serial_omap_probe(struct platform_device
*pdev)
sprintf(up-name, OMAP UART%d, up-port.line);
up-port.mapbase = mem-start;
- up-port.membase = devm_ioremap(pdev-dev, mem-start,
- resource_size(mem));
- if (!up-port.membase) {
- dev_err(pdev-dev, can't ioremap UART\n);
- ret = -ENOMEM;
- goto err_ioremap;
- }
-
+ up-port.membase = base;
up-port.flags = omap_up_info-flags;
up-port.uartclk = omap_up_info-uartclk;
if (!up-port.uartclk) {
@@ -1786,7 +1773,6 @@ static int serial_omap_probe(struct platform_device *pdev)
err_add_port:
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
-err_ioremap:
err_rs485:
err_port_line:
dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
--
1.9.2.459.g68773ac
--
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 11/13] tty: serial: omap: remove unneeded singlethread workqueue
it wasn't used by anything, just remove it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6654682..ab22dab 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -180,8 +180,6 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
-static struct workqueue_struct *serial_omap_uart_wq;
-
static inline unsigned int serial_in(struct uart_omap_port *up, int offset)
{
offset = up-port.regshift;
@@ -1701,7 +1699,6 @@ static int serial_omap_probe(struct platform_device *pdev)
up-calc_latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
pm_qos_add_request(up-pm_qos_request,
PM_QOS_CPU_DMA_LATENCY, up-latency);
- serial_omap_uart_wq = create_singlethread_workqueue(up-name);
INIT_WORK(up-qos_work, serial_omap_uart_qos_work);
platform_set_drvdata(pdev, up);
--
1.9.2.459.g68773ac
--
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 10/13] tty: serial: omap: remove some dead code
nobody passes a DTR_gpio to this driver, so
this code is not necessary.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b46aaf3..6654682 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -163,10 +163,6 @@ struct uart_omap_port {
u8 wakeups_enabled;
u32 features;
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
-
struct serial_rs485 rs485;
int rts_gpio;
@@ -694,16 +690,6 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
- if (gpio_is_valid(up-DTR_gpio)
- !!(mctrl TIOCM_DTR) != up-DTR_active) {
- up-DTR_active = !up-DTR_active;
- if (gpio_cansleep(up-DTR_gpio))
- schedule_work(up-qos_work);
- else
- gpio_set_value(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
- }
}
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -847,9 +833,6 @@ static void serial_omap_uart_qos_work(struct work_struct
*work)
qos_work);
pm_qos_update_request(up-pm_qos_request, up-latency);
- if (gpio_is_valid(up-DTR_gpio))
- gpio_set_value_cansleep(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
}
static void
@@ -1672,28 +1655,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
- omap-serial);
- if (ret 0)
- return ret;
- ret = gpio_direction_output(omap_up_info-DTR_gpio,
- omap_up_info-DTR_inverted);
- if (ret 0)
- return ret;
- }
-
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- up-DTR_gpio = omap_up_info-DTR_gpio;
- up-DTR_inverted = omap_up_info-DTR_inverted;
- } else {
- up-DTR_gpio = -EINVAL;
- }
-
- up-DTR_active = 0;
-
up-dev = pdev-dev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
--
1.9.2.459.g68773ac
--
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 RFC] ARM: dts: am335x: update USB DT references
On Apr 23, Tony Lindgren wrote: * Benoit Cousson bcous...@baylibre.com [140422 07:14]: Hi Leigh, On 16/04/2014 13:26, Leigh Brown wrote: In ARM: dts: am33xx: correcting dt node unit address for usb, the usb_ctrl_mod and cppi41dma nodes were updated with the correct register addresses. However, the dts files that reference these nodes were not updated, and those devices are no longer being enabled. This patch corrects the references for the affected dts files. Maybe someone can take care of using phandles instead? This way, the board's dts files would be immune to such .dtsi changes. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 03/13] Revert serial: omap: unlock the port lock
This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
That commit tried to fix a deadlock problem when using
hci_ldisc, but it turns out the bug was in hci_ldsic
all along where it was calling -write() from within
-write_wakeup() callback.
The problem is that -write_wakeup() was called with
port lock held and -write() tried to grab the same
port lock.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 08b6b94..837f6c1 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -398,11 +398,8 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
break;
} while (--count 0);
- if (uart_circ_chars_pending(xmit) WAKEUP_CHARS) {
- spin_unlock(up-port.lock);
+ if (uart_circ_chars_pending(xmit) WAKEUP_CHARS)
uart_write_wakeup(up-port);
- spin_lock(up-port.lock);
- }
if (uart_circ_empty(xmit))
serial_omap_stop_tx(up-port);
--
1.9.2.459.g68773ac
--
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 02/13] bluetooth: hci_ldisc: fix deadlock condition
LDISCs shouldn't call tty-ops-write() from within
-write_wakeup().
-write_wakeup() is called with port lock taken and
IRQs disabled, tty-ops-write() will try to acquire
the same port lock and we will deadlock.
Acked-by: Marcel Holtmann mar...@holtmann.org
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Huang Shijie b32...@freescale.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/bluetooth/hci_ldisc.c | 24 +++-
drivers/bluetooth/hci_uart.h | 1 +
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index f1fbf4f..e00f8f5 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -118,10 +118,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- struct tty_struct *tty = hu-tty;
- struct hci_dev *hdev = hu-hdev;
- struct sk_buff *skb;
-
if (test_and_set_bit(HCI_UART_SENDING, hu-tx_state)) {
set_bit(HCI_UART_TX_WAKEUP, hu-tx_state);
return 0;
@@ -129,6 +125,22 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
BT_DBG();
+ schedule_work(hu-write_work);
+
+ return 0;
+}
+
+static void hci_uart_write_work(struct work_struct *work)
+{
+ struct hci_uart *hu = container_of(work, struct hci_uart, write_work);
+ struct tty_struct *tty = hu-tty;
+ struct hci_dev *hdev = hu-hdev;
+ struct sk_buff *skb;
+
+ /* REVISIT: should we cope with bad skbs or -write() returning
+* and error value ?
+*/
+
restart:
clear_bit(HCI_UART_TX_WAKEUP, hu-tx_state);
@@ -153,7 +165,6 @@ restart:
goto restart;
clear_bit(HCI_UART_SENDING, hu-tx_state);
- return 0;
}
static void hci_uart_init_work(struct work_struct *work)
@@ -282,6 +293,7 @@ static int hci_uart_tty_open(struct tty_struct *tty)
tty-receive_room = 65536;
INIT_WORK(hu-init_ready, hci_uart_init_work);
+ INIT_WORK(hu-write_work, hci_uart_write_work);
spin_lock_init(hu-rx_lock);
@@ -319,6 +331,8 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
+ cancel_work_sync(hu-write_work);
+
if (test_and_clear_bit(HCI_UART_PROTO_SET, hu-flags)) {
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, hu-flags))
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index fffa61f..12df101 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -68,6 +68,7 @@ struct hci_uart {
unsigned long hdev_flags;
struct work_struct init_ready;
+ struct work_struct write_work;
struct hci_uart_proto *proto;
void*priv;
--
1.9.2.459.g68773ac
--
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 08/13] tty: serial: omap: switch over to platform_get_resource
this way we can remove one pointer declaration.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 3813740..cb45e88 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1644,7 +1644,6 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
struct uart_omap_port *up;
struct resource *mem;
- struct resource *irq;
int uartirq = 0;
int wakeirq = 0;
int ret;
@@ -1658,12 +1657,9 @@ static int serial_omap_probe(struct platform_device
*pdev)
omap_up_info = of_get_uart_port_info(pdev-dev);
pdev-dev.platform_data = omap_up_info;
} else {
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
- dev_err(pdev-dev, no irq resource?\n);
- return -ENODEV;
- }
- uartirq = irq-start;
+ uartirq = platform_get_irq(pdev, 0);
+ if (uartirq 0)
+ return -EPROBE_DEFER;
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.9.2.459.g68773ac
--
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] gpio: do not set up hardware for IRQ_TYPE_NONE
On 04/23/2014 09:50 AM, Linus Walleij wrote: Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Nishanth Menon n...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- TI folks: can you provide a Tested-by tag if this makes your OMAPs work? I am pretty sure the other platforms will be unaffected, if they aren't I will switch them over to react to IRQ_TYPE_DEFAULT. Tested-by: Nishanth Menon n...@ti.com AM335x-sk (which fails to boot previously), now with this patch: http://slexy.org/raw/s20dMOz3ke Discussion thread: http://marc.info/?t=139817273800014r=1w=2 --- drivers/gpio/gpiolib.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index ee1819fdcf35..97d173e9aa2d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); + /* + * No set-up of the hardware will happen if IRQ_TYPE_NONE + * is passed as default type. + */ + if (chip-irq_default_type != IRQ_TYPE_NONE) + irq_set_irq_type(irq, chip-irq_default_type); return 0; } @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip) * @first_irq: if not dynamically assigned, the base (first) IRQ to * allocate gpiochip irqs from * @handler: the irq handler to use (often a predefined irq core function) - * @type: the default type for IRQs on this irqchip + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE + * to have the core avoid setting up any default type in the hardware. * * This function closely associates a certain irqchip with a certain * gpiochip, providing an irq domain to translate the local IRQs to Acked-by: Nishanth Menon n...@ti.com -- 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 04/13] serial: fix UART_IIR_ID
UART IRQ Identification bitfield is 3 bits long (bits 3:1) but current mask only masks 2 bits. Fix it. Signed-off-by: Felipe Balbi ba...@ti.com --- include/uapi/linux/serial_reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h index e632260..99b4705 100644 --- a/include/uapi/linux/serial_reg.h +++ b/include/uapi/linux/serial_reg.h @@ -32,7 +32,7 @@ #define UART_IIR 2 /* In: Interrupt ID Register */ #define UART_IIR_NO_INT0x01 /* No interrupts pending */ -#define UART_IIR_ID0x06 /* Mask for the interrupt ID */ +#define UART_IIR_ID0x0e /* Mask for the interrupt ID */ #define UART_IIR_MSI 0x00 /* Modem status interrupt */ #define UART_IIR_THRI 0x02 /* Transmitter holding register empty */ #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ -- 1.9.2.459.g68773ac -- 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 01/13] tty_ldisc: add more limits to the @write_wakeup
From: Huang Shijie b32...@freescale.com In the uart_handle_cts_change(), uart_write_wakeup() is called after we call @uart_port-ops-start_tx(). The Documentation/serial/driver tells us: --- start_tx(port) Start transmitting characters. Locking: port-lock taken. Interrupts: locally disabled. --- So when the uart_write_wakeup() is called, the port-lock is taken by the upper. See the following callstack: |_ uart_write_wakeup |_ tty_wakeup |_ ld-ops-write_wakeup With the port-lock held, we call the @write_wakeup. Some implemetation of the @write_wakeup does not notice that the port-lock is held, and it still tries to send data with uart_write() which will try to grab the prot-lock. A dead lock occurs, see the following log caught in the Bluetooth by uart: BUG: spinlock lockup suspected on CPU#0, swapper/0/0 lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW3.10.17-16839-ge4a1bef #1320 [80014cbc] (unwind_backtrace+0x0/0x138) from [8001251c] (show_stack+0x10/0x14) [8001251c] (show_stack+0x10/0x14) from [802816ac] (do_raw_spin_lock+0x108/0x184) [802816ac] (do_raw_spin_lock+0x108/0x184) from [806a22b0] (_raw_spin_lock_irqsave+0x54/0x60) [806a22b0] (_raw_spin_lock_irqsave+0x54/0x60) from [802f5754] (uart_write+0x38/0xe0) [802f5754] (uart_write+0x38/0xe0) from [80455270] (hci_uart_tx_wakeup+0xa4/0x168) [80455270] (hci_uart_tx_wakeup+0xa4/0x168) from [802dab18] (tty_wakeup+0x50/0x5c) [802dab18] (tty_wakeup+0x50/0x5c) from [802f81a4] (imx_rtsint+0x50/0x80) [802f81a4] (imx_rtsint+0x50/0x80) from [802f88f4] (imx_int+0x158/0x17c) [802f88f4] (imx_int+0x158/0x17c) from [8007abe0] (handle_irq_event_percpu+0x50/0x194) [8007abe0] (handle_irq_event_percpu+0x50/0x194) from [8007ad60] (handle_irq_event+0x3c/0x5c) This patch adds more limits to the @write_wakeup, the one who wants to implemet the @write_wakeup should follow the limits which avoid the deadlock. Signed-off-by: Huang Shijie b32...@freescale.com Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/tty_ldisc.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/tty_ldisc.h b/include/linux/tty_ldisc.h index add26da..00c9d68 100644 --- a/include/linux/tty_ldisc.h +++ b/include/linux/tty_ldisc.h @@ -92,7 +92,10 @@ * This function is called by the low-level tty driver to signal * that line discpline should try to send more characters to the * low-level driver for transmission. If the line discpline does - * not have any more data to send, it can just return. + * not have any more data to send, it can just return. If the line + * discipline does have some data to send, please arise a tasklet + * or workqueue to do the real data transfer. Do not send data in + * this hook, it may leads to a deadlock. * * int (*hangup)(struct tty_struct *) * -- 1.9.2.459.g68773ac -- 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 05/13] tty: serial: add missing braces
per CodingStyle we should have those braces, no
functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 837f6c1..f456f46 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1694,8 +1694,10 @@ static int serial_omap_probe(struct platform_device
*pdev)
omap_up_info-DTR_present) {
up-DTR_gpio = omap_up_info-DTR_gpio;
up-DTR_inverted = omap_up_info-DTR_inverted;
- } else
+ } else {
up-DTR_gpio = -EINVAL;
+ }
+
up-DTR_active = 0;
up-dev = pdev-dev;
@@ -1757,6 +1759,7 @@ static int serial_omap_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, up);
if (omap_up_info-autosuspend_timeout == 0)
omap_up_info-autosuspend_timeout = -1;
+
device_init_wakeup(up-dev, true);
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev,
--
1.9.2.459.g68773ac
--
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 08/13] tty: serial: omap: switch over to platform_get_resource
On Wed, Apr 23, 2014 at 11:58 AM, Felipe Balbi ba...@ti.com wrote:
@@ -1658,12 +1657,9 @@ static int serial_omap_probe(struct platform_device
*pdev)
omap_up_info = of_get_uart_port_info(pdev-dev);
pdev-dev.platform_data = omap_up_info;
} else {
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
- dev_err(pdev-dev, no irq resource?\n);
- return -ENODEV;
- }
- uartirq = irq-start;
+ uartirq = platform_get_irq(pdev, 0);
+ if (uartirq 0)
+ return -EPROBE_DEFER;
Maybe you could just do a 'return uartirq' here instead.
--
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 10/13] tty: serial: omap: remove some dead code
+Neil
On Wed, Apr 23, 2014 at 09:58:34AM -0500, Felipe Balbi wrote:
nobody passes a DTR_gpio to this driver, so
this code is not necessary.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index b46aaf3..6654682 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -163,10 +163,6 @@ struct uart_omap_port {
u8 wakeups_enabled;
u32 features;
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
-
struct serial_rs485 rs485;
int rts_gpio;
@@ -694,16 +690,6 @@ static void serial_omap_set_mctrl(struct uart_port
*port, unsigned int mctrl)
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
- if (gpio_is_valid(up-DTR_gpio)
- !!(mctrl TIOCM_DTR) != up-DTR_active) {
- up-DTR_active = !up-DTR_active;
- if (gpio_cansleep(up-DTR_gpio))
- schedule_work(up-qos_work);
- else
- gpio_set_value(up-DTR_gpio,
-up-DTR_active != up-DTR_inverted);
- }
}
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -847,9 +833,6 @@ static void serial_omap_uart_qos_work(struct work_struct
*work)
qos_work);
pm_qos_update_request(up-pm_qos_request, up-latency);
- if (gpio_is_valid(up-DTR_gpio))
- gpio_set_value_cansleep(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
}
static void
@@ -1672,28 +1655,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
- omap-serial);
- if (ret 0)
- return ret;
- ret = gpio_direction_output(omap_up_info-DTR_gpio,
- omap_up_info-DTR_inverted);
- if (ret 0)
- return ret;
- }
-
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- up-DTR_gpio = omap_up_info-DTR_gpio;
- up-DTR_inverted = omap_up_info-DTR_inverted;
- } else {
- up-DTR_gpio = -EINVAL;
- }
-
- up-DTR_active = 0;
-
up-dev = pdev-dev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
--
1.9.2.459.g68773ac
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RFC] ARM: dts: am335x: update USB DT references
Hi Tony,
On 23/04/2014 16:48, Tony Lindgren wrote:
* Benoit Cousson bcous...@baylibre.com [140422 07:14]:
Hi Leigh,
On 16/04/2014 13:26, Leigh Brown wrote:
In ARM: dts: am33xx: correcting dt node unit address for usb, the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses. However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.
This patch corrects the references for the affected dts files.
Thanks for the fix. BTW, why is it a RFC? Do you plan to send an updated
version?
FYI, even with this fix, the BBB still does not have a working MUSB on
3.15-rc2. Have you observed that as well?
Signed-off-by: Leigh Brown le...@solinno.co.uk
If this is a final version, I'll apply it for -rc3.
Looks like I already have this in omap-for-v3.15/fixes-v2, sorry
looks like I never replied to this one.
:-)
OK, I'll let you handle this one.
Thanks,
Benoit
Regards,
Tony
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
arch/arm/boot/dts/am335x-evmsk.dts| 4 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi| 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..2e7d932 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -183,7 +183,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -204,7 +204,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 28ae040..77df10d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -331,7 +331,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -352,7 +352,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..ab23885 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -364,7 +364,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -385,7 +385,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 7063311..5942e7d 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -202,7 +202,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -223,7 +223,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
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 10/13] tty: serial: omap: remove some dead code
On 04/23/2014 09:58 AM, Felipe Balbi wrote:
nobody passes a DTR_gpio to this driver, so
this code is not necessary.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Niel,
this seems to revert the functionality introduced in
commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100
(OMAP/serial: Add support for driving a GPIO as DTR.)
would you like to Ack this change?
drivers/tty/serial/omap-serial.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index b46aaf3..6654682 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -163,10 +163,6 @@ struct uart_omap_port {
u8 wakeups_enabled;
u32 features;
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
-
struct serial_rs485 rs485;
int rts_gpio;
@@ -694,16 +690,6 @@ static void serial_omap_set_mctrl(struct uart_port
*port, unsigned int mctrl)
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
- if (gpio_is_valid(up-DTR_gpio)
- !!(mctrl TIOCM_DTR) != up-DTR_active) {
- up-DTR_active = !up-DTR_active;
- if (gpio_cansleep(up-DTR_gpio))
- schedule_work(up-qos_work);
- else
- gpio_set_value(up-DTR_gpio,
-up-DTR_active != up-DTR_inverted);
- }
}
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -847,9 +833,6 @@ static void serial_omap_uart_qos_work(struct work_struct
*work)
qos_work);
pm_qos_update_request(up-pm_qos_request, up-latency);
- if (gpio_is_valid(up-DTR_gpio))
- gpio_set_value_cansleep(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
}
static void
@@ -1672,28 +1655,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
- omap-serial);
- if (ret 0)
- return ret;
- ret = gpio_direction_output(omap_up_info-DTR_gpio,
- omap_up_info-DTR_inverted);
- if (ret 0)
- return ret;
- }
-
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- up-DTR_gpio = omap_up_info-DTR_gpio;
- up-DTR_inverted = omap_up_info-DTR_inverted;
- } else {
- up-DTR_gpio = -EINVAL;
- }
-
- up-DTR_active = 0;
-
up-dev = pdev-dev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
--
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] usb: musb_dsps: fix the exit routine for debugfs
The following commit introduced the debugfs : 40f099e32c2a06bad7d75683421e30fcc74924cd Author: Markus Pargmann m...@pengutronix.de Date: Fri Jan 17 10:22:35 2014 +0100 usb: musb: dsps, debugfs files Unfortunately, a forgotten call to a cleanup function prevents the probing of musb in case of deferred probe. Because musb_init_controller() often retries and creates a new debugfs directory each time it is called, we need to remove that directory in case the initialization fails. Otherwise, the debugfs_create_dir() fails at subsequent calls because the directory already exists. Fixed by calling debugfs_remove_recursive() in the exit function. Signed-off-by: Olivier Gayot oga...@baylibre.com Cc: Markus Pargmann m...@pengutronix.de --- drivers/usb/musb/musb_dsps.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..c3de0a5 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -471,6 +471,8 @@ static int dsps_musb_exit(struct musb *musb) del_timer_sync(glue-timer); + debugfs_remove_recursive(glue-dbgfs_root); + usb_phy_shutdown(musb-xceiv); return 0; } -- 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: [PATCH RFC] ARM: dts: am335x: update USB DT references
Hi Ezequiel, On 23/04/2014 17:17, Ezequiel Garcia wrote: On Apr 23, Tony Lindgren wrote: * Benoit Cousson bcous...@baylibre.com [140422 07:14]: Hi Leigh, On 16/04/2014 13:26, Leigh Brown wrote: In ARM: dts: am33xx: correcting dt node unit address for usb, the usb_ctrl_mod and cppi41dma nodes were updated with the correct register addresses. However, the dts files that reference these nodes were not updated, and those devices are no longer being enabled. This patch corrects the references for the affected dts files. Maybe someone can take care of using phandles instead? This way, the board's dts files would be immune to such .dtsi changes. Indeed, that will avoid such issues. Are you volunteer for that cleanup ? :-) Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- 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 06/13] tty: serial: omap: switch over to devm_request_gpio
this will make sure gpio gets freed automatically
when this device is destroyed.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f456f46..07d4273 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1611,7 +1611,7 @@ static int serial_omap_probe_rs485(struct uart_omap_port
*up,
/* check for tx enable gpio */
up-rts_gpio = of_get_named_gpio_flags(np, rts-gpio, 0, flags);
if (gpio_is_valid(up-rts_gpio)) {
- ret = gpio_request(up-rts_gpio, omap-serial);
+ ret = devm_gpio_request(up-dev, up-rts_gpio, omap-serial);
if (ret 0)
return ret;
ret = gpio_direction_output(up-rts_gpio,
@@ -1677,7 +1677,8 @@ static int serial_omap_probe(struct platform_device *pdev)
if (gpio_is_valid(omap_up_info-DTR_gpio)
omap_up_info-DTR_present) {
- ret = gpio_request(omap_up_info-DTR_gpio, omap-serial);
+ ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
+ omap-serial);
if (ret 0)
return ret;
ret = gpio_direction_output(omap_up_info-DTR_gpio,
--
1.9.2.459.g68773ac
--
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 08/13] tty: serial: omap: switch over to platform_get_resource
On Wed, Apr 23, 2014 at 12:27:59PM -0300, Fabio Estevam wrote:
On Wed, Apr 23, 2014 at 11:58 AM, Felipe Balbi ba...@ti.com wrote:
@@ -1658,12 +1657,9 @@ static int serial_omap_probe(struct platform_device
*pdev)
omap_up_info = of_get_uart_port_info(pdev-dev);
pdev-dev.platform_data = omap_up_info;
} else {
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
- dev_err(pdev-dev, no irq resource?\n);
- return -ENODEV;
- }
- uartirq = irq-start;
+ uartirq = platform_get_irq(pdev, 0);
+ if (uartirq 0)
+ return -EPROBE_DEFER;
Maybe you could just do a 'return uartirq' here instead.
I don't mind either way, I'm only returning -EPROBE_DEFER because that's
what the other branch of this conditional returns. Tony, what do you
prefer ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: musb_dsps: fix the exit routine for debugfs
On Wed, Apr 23, 2014 at 05:39:43PM +0200, Olivier Gayot wrote: The following commit introduced the debugfs : 40f099e32c2a06bad7d75683421e30fcc74924cd Author: Markus Pargmann m...@pengutronix.de Date: Fri Jan 17 10:22:35 2014 +0100 usb: musb: dsps, debugfs files Unfortunately, a forgotten call to a cleanup function prevents the probing of musb in case of deferred probe. Because musb_init_controller() often retries and creates a new debugfs directory each time it is called, we need to remove that directory in case the initialization fails. Otherwise, the debugfs_create_dir() fails at subsequent calls because the directory already exists. Fixed by calling debugfs_remove_recursive() in the exit function. Signed-off-by: Olivier Gayot oga...@baylibre.com Cc: Markus Pargmann m...@pengutronix.de --- drivers/usb/musb/musb_dsps.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..c3de0a5 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -471,6 +471,8 @@ static int dsps_musb_exit(struct musb *musb) del_timer_sync(glue-timer); + debugfs_remove_recursive(glue-dbgfs_root); + usb_phy_shutdown(musb-xceiv); return 0; First of all this commit is wrong, second of all I already have the proper commit: commit 0fca91b8a446d4a38b8f3d4772c4a8665ebcd7b2 Author: Daniel Mack zon...@gmail.com Date: Wed Apr 2 11:46:51 2014 +0200 usb: musb: dsps: move debugfs_remove_recursive() When the platform initialization fails due to missing resources, it will return -EPROBE_DEFER after dsps_musb_init() has been called. dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs nodes. At a later point in time, the probe will be retried, and dsps_musb_dbg_init() will be called again. debugfs_create_dir() will fail this time, as the node already exists, and so the entire device probe will fail with -ENOMEM. Fix this by moving debugfs_remove_recursive() from dsps_remove() to the plaform's exit function, so it will be cleanly torn down when the probe fails. It also feels more natural this way, as .exit is the counterpart to .init. Signed-off-by: Daniel Mack zon...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); + debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); - debugfs_remove_recursive(glue-dbgfs_root); - return 0; } a pull request has already been sent to Greg, should be in v3.15-rc3 -- balbi signature.asc Description: Digital signature
[PATCH 1/1] drivers/video/fbdev/omap2/dss/dss.c: add __exit to dss_uninit_ports
dss_uninit_ports is only called by __exit omap_dsshw_remove
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/video/fbdev/omap2/dss/dss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..a1c1cc2 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -813,7 +813,7 @@ static int __init dss_init_ports(struct platform_device
*pdev)
return 0;
}
-static void dss_uninit_ports(void)
+static void __exit dss_uninit_ports(void)
{
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_uninit_port();
--
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 RFC] ARM: dts: am335x: update USB DT references
On Apr 23, Benoit Cousson wrote: Hi Ezequiel, On 23/04/2014 17:17, Ezequiel Garcia wrote: On Apr 23, Tony Lindgren wrote: * Benoit Cousson bcous...@baylibre.com [140422 07:14]: Hi Leigh, On 16/04/2014 13:26, Leigh Brown wrote: In ARM: dts: am33xx: correcting dt node unit address for usb, the usb_ctrl_mod and cppi41dma nodes were updated with the correct register addresses. However, the dts files that reference these nodes were not updated, and those devices are no longer being enabled. This patch corrects the references for the affected dts files. Maybe someone can take care of using phandles instead? This way, the board's dts files would be immune to such .dtsi changes. Indeed, that will avoid such issues. Are you volunteer for that cleanup ? :-) Sure, I've already done that for my custom dts. It's a simple change. If someone feels like doing this before I get to send the patches, be my guest :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 0/5] mmc: host: omap_hsmmc: a few improvements
On Tue, Apr 22, 2014 at 10:48:58AM -0500, Felipe Balbi wrote: Hi, On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote: On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote: this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly Got mislead by your reply to this series, about the alternative way of reading memory size from CAPA register sure, we can do that if you prefer, I just felt I wouldn't touch platforms I can't really test :-s any comments ? do you prefer to change max_blk_size to read CAPA for the other platforms ? -- balbi signature.asc Description: Digital signature
extcon-next regression ?
Hi Chanwoo, I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [2.224357] [c05426b4] (dump_stack) from [c02d5c28] (kobject_add+0x88/0x98) [2.232014] [c02d5c28] (kobject_add) from [c0350250] (device_add+0xe0/0x520) [2.239758] [c0350250] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [2.248235] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [2.257901] [c0462b44]
Re: extcon-next regression ?
Hi, On Wed, Apr 23, 2014 at 11:40:33AM -0500, Felipe Balbi wrote: Hi Chanwoo, I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [2.224357] [c05426b4] (dump_stack) from [c02d5c28] (kobject_add+0x88/0x98) [2.232014] [c02d5c28] (kobject_add) from [c0350250] (device_add+0xe0/0x520) [2.239758] [c0350250] (device_add) from
Re: [PATCH] ARM: dts: am437x-gp-evm: Boot fixes
On 04/23/2014 09:59 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 12:53]: On 04/22/2014 02:01 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? We've been using this configuration on this board for a while without any apparent issues. Also, am335x-evmsk already uses the same idea for the VTT regulator on board from commit 6046adb6ad701026c10adeac8d6a4138895f12e5 [ARM: dts: am335x-evmsk: Do not reset gpio0] and I am unaware of any issues with that either. OK. Do you have other GPIOs in use as interrupts for devices in these banks and do they work fine? I dont see any interrupts in use from gpio5 bank but as a quick test if I add ti,no-reset-on-init to gpio3 and gpio4 I see no issue with matrix-keypad operation which uses gpios from each of those banks. Also, can you please test to make sure this works with the most recent Javier's GPIO patches that had the issue of not booting on am335x-evmsk? Yes, when using Javier's patches in addition to this patch [1], which was found to be necessary through this discussion [2], the AM437x GP EVM boots fine with linux-next with my regulator patch and gpio5 no reset patch applied. Regards, Dave [1] https://patchwork.kernel.org/patch/4041881/ [2] http://marc.info/?t=139817273800014r=1w=2 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
[PATCH v4 0/4] ARM: OMAP: SATA support for OMAP5 DRA7
Hi Tony, These are the pending HWMOD and DTS patches to get SATA working on OMAP5-uevm and DRA7-evm. Please queue them for -next. Thanks. cheers, -roger --- Balaji T K (2): ARM: dts: omap5: add sata node ARM: dts: dra7: add OCP2SCP3 and SATA nodes Keshava Munegowda (1): ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods Nikhil Devshatwar (1): ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods arch/arm/boot/dts/dra7.dtsi| 39 arch/arm/boot/dts/omap5.dtsi | 40 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31 +++-- 4 files changed, 178 insertions(+), 5 deletions(-) -- 1.8.3.2 -- 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 v4 1/4] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 8923172..e169f90 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1791,6 +1791,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2482,6 +2553,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.8.3.2
--
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 v4 4/4] ARM: dts: dra7: add OCP2SCP3 and SATA nodes
From: Balaji T K balaj...@ti.com
Add nodes for OCP2SCP3 bus, SATA controller and SATA PHY.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..084f42e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,45 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ omap_control_sata: control-phy@4a002374 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002374 0x4;
+ reg-names = power;
+ clocks = sys_clkin1;
+ clock-names = sysclk;
+ };
+
+ /* OCP2SCP3 */
+ ocp2scp@4a09 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0x4a09 0x20;
+ ti,hwmods = ocp2scp3;
+ sata_phy: phy@4A096000 {
+ compatible = ti,phy-pipe3-sata;
+ reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_sata;
+ clocks = sys_clkin1;
+ clock-names = sysclk;
+ #phy-cells = 0;
+ };
+ };
+
+ sata: sata@4a141100 {
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100, 0x4a141100 0x7;
+ interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+ phys = sata_phy;
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ ti,hwmods = sata;
+ };
};
};
--
1.8.3.2
--
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 v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
From: Nikhil Devshatwar nikhil...@ti.com
Add hwmods for ocp2scp3 and sata modules.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..b02a4ab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
+
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -1268,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = ref_clk, .clk = sata_ref_clk },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = sata,
@@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = l3init_clkdm,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
@@ -2682,6 +2702,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__mmc4,
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
+ dra7xx_l4_cfg__ocp2scp3,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
--
1.8.3.2
--
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 v4 2/4] ARM: dts: omap5: add sata node
From: Balaji T K balaj...@ti.com
Add support for sata.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6f3de22..8ab6721 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -863,6 +863,46 @@
#thermal-sensor-cells = 1;
};
+
+ omap_control_sata: control-phy@4a002374 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002374 0x4;
+ reg-names = power;
+ clocks = sys_clkin;
+ clock-names = sysclk;
+ };
+
+ /* OCP2SCP3 */
+ ocp2scp@4a09 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x4a09 0x20;
+ ranges;
+ ti,hwmods = ocp2scp3;
+ sata_phy: phy@4a096000 {
+ compatible = ti,phy-pipe3-sata;
+ reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_sata;
+ clocks = sys_clkin;
+ clock-names = sysclk;
+ #phy-cells = 0;
+ };
+ };
+
+ sata: sata@4a141100 {
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100, 0x4a141100 0x7;
+ interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+ phys = sata_phy;
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ ti,hwmods = sata;
+ };
+
};
};
--
1.8.3.2
--
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 0/2] Fix few omap gpmc regressions when booted with device tree
* Tony Lindgren t...@atomide.com [140422 17:01]:
* Tony Lindgren t...@atomide.com [140422 08:24]:
* Javier Martinez Canillas jav...@dowhile0.org [140421 23:55]:
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren t...@atomide.com wrote:
2. There seems to be some timing issues with smc911x where
rsync of larger files and apt-get dist-upgrade can produce
strange errors. This seems to work reliably when booted in
legacy mode.
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
Yes it seems to have two LAN9220s, so this could be the reason.
I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
timings initially.
This is on a sbc-t3730 that I'm using as a gateway that was behaving
reliably before I upgraded it to DT based booting. It's currently
at v3.13-rc3 something, but I don't think we've much GPMC changes
since then.
I'll try upgrading the kernel today and running some tests with
rsync. Looks like we can also remove quite a bit of duplicate
timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
like the patch below.
In any case, I suggest others run some tests on their GPMC Ethernet
too.
+#include omap-gpmc-smsc9221.dtsi
+
The 9221 timings won't work at all on 9220, it requires a 9221.
I'll post a better clean-up patch to use the 911x timings.
Upgraded the kernel and the occasional corruption is still
there. I guess I need to test also the same kernel in legacy
mode to try to narrow it down.
OK hopefully got it figured out now. For legacy booting we were
always using just the bootloader timings. With device tree, we
started using the timings with your commit d72b4415 (ARM: dts:
omap3-igep0020: Add SMSC911x LAN chip support) that was probably
actually tested on a LAN9221 instead of LAN9220?
In any case, I've patched omap-gpmc-smsc911x.dtsi so the values
match the u-boot values, and so far that seems to be working just
fine. Will post few patches shortly.
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 v3 0/3] ARM: OMAP2+: AM437x: L2 cache support
On Tue, Apr 22, 2014 at 02:20:43PM -0400, Santosh Shilimkar wrote: On Tuesday 22 April 2014 04:28 AM, Sekhar Nori wrote: This patch series adds L2 cache support for AM437x and does some clean-ups for existing OMAP4 support along the way (no functional changes). On OMAP4 Panda, the Aux control value remains 0x7e47 before and after the series. Tested on OMAP4 Panda and AM437x EPOS EVMs. It is based on RMK's 75 patch series titled l2c series + the patch contained in https://www.mail-archive.com/linux-omap@vger.kernel.org/msg103439.html Sekhar Nori (3): ARM: OMAP2+: L2 cache: get rid of init call ARM: OMAP2+: L2 cache: git rid of redundant cache replacement policy setting ARM: OMAP2+: AM43x: L2 cache support For the whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Okay, as these depend on my series, I'll take them into my l2c branch, which I'll be pushing into linux-next from this evening. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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: extcon-next regression ?
Hi, On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [2.224357] [c05426b4] (dump_stack) from [c02d5c28] (kobject_add+0x88/0x98) [2.232014] [c02d5c28] (kobject_add)
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
Hello Tony,
On Wed, Apr 23, 2014 at 8:08 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [140422 17:01]:
* Tony Lindgren t...@atomide.com [140422 08:24]:
* Javier Martinez Canillas jav...@dowhile0.org [140421 23:55]:
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren t...@atomide.com wrote:
2. There seems to be some timing issues with smc911x where
rsync of larger files and apt-get dist-upgrade can produce
strange errors. This seems to work reliably when booted in
legacy mode.
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
Yes it seems to have two LAN9220s, so this could be the reason.
I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
timings initially.
This is on a sbc-t3730 that I'm using as a gateway that was behaving
reliably before I upgraded it to DT based booting. It's currently
at v3.13-rc3 something, but I don't think we've much GPMC changes
since then.
I'll try upgrading the kernel today and running some tests with
rsync. Looks like we can also remove quite a bit of duplicate
timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
like the patch below.
In any case, I suggest others run some tests on their GPMC Ethernet
too.
+#include omap-gpmc-smsc9221.dtsi
+
The 9221 timings won't work at all on 9220, it requires a 9221.
I'll post a better clean-up patch to use the 911x timings.
Upgraded the kernel and the occasional corruption is still
there. I guess I need to test also the same kernel in legacy
mode to try to narrow it down.
OK hopefully got it figured out now. For legacy booting we were
always using just the bootloader timings. With device tree, we
started using the timings with your commit d72b4415 (ARM: dts:
omap3-igep0020: Add SMSC911x LAN chip support) that was probably
actually tested on a LAN9221 instead of LAN9220?
Right, since the same driver (drivers/net/ethernet/smsc/smsc911x.c) is
used for both SMSC families I assumed that the same timings could be
used by both chips.
So I took the timings from IGEP board support in u-boot but then you
did the refactoring and later Florian added another .dtsi for SMSC
9221 in commit aac9aa3 (ARM: dts: omap: Add common file for
SMSC9221).
I didn't notice about this new .dtsi file until you reported your
issue and the IGEPv2 does indeed have a SMSC LAN9221i ethernet chip so
it is wrongly including omap-gpmc-smsc911x.dtsi and should include
omap-gpmc-smsc9221.dtsi instead.
In any case, I've patched omap-gpmc-smsc911x.dtsi so the values
match the u-boot values, and so far that seems to be working just
fine. Will post few patches shortly.
Great, I'll patch the IGEPv2 DTS file too to use
omap-gpmc-smsc9221.dtsi, do some testing and post a patch.
Regards,
Tony
Thanks a lot and best regards,
Javier
--
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/3] Fix LAN9220 caused memory corruption noticed on cm-t3730
Hi all, I noticed some occasional memory corruption issues on transferring data over LAN9220 after upgrading my gateway machine. Please test if you have a board with LAN9220 on GPMC, this should not affect boards with LAN9221. As these fix memory corruption using LAN9220 at least on cm-t3730, I'm planning to send these ASAP after some testing. Regards, Tony Tony Lindgren (3): ARM: dts: Fix bad OTG muxing for cm-t boards ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree ARM: dts: Fix GPMC timings for LAN9220 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 19 - arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 66 +++ arch/arm/boot/dts/omap3-sb-t35.dtsi | 37 + arch/arm/boot/dts/omap3-sbc-t3517.dts | 13 ++ 4 files changed, 46 insertions(+), 89 deletions(-) -- 1.8.1.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
[PATCH 1/3] ARM: dts: Fix bad OTG muxing for cm-t boards
Looks like the OTG pins are off by 2 and we get this:
pinctrl-single 48002030.pinmux: pin 480021a0.0 already requested by
4902.serial; cannot claim for 480ab000.usb_otg_hs
pinctrl-single 48002030.pinmux: pin-184 (480ab000.usb_otg_hs) status -22
pinctrl-single 48002030.pinmux: could not request pin 184 (480021a0.0) from
group pinmux_hsusb0_pins on device pinctrl-single
musb-omap2430 480ab000.usb_otg_hs: Error applying setting, reverse things back
That's probably because the TRM lists the values as
32-bit registers so every second needs 2 added to the
address. The OTG pin start range must start from
0x21a2, not 0x21a0.
Cc: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
index d000558..75e0a1f 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -35,18 +35,18 @@
hsusb0_pins: pinmux_hsusb0_pins {
pinctrl-single,pins =
- OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* hsusb0_clk.hsusb0_clk */
- OMAP3_CORE1_IOPAD(0x21a2, PIN_OUTPUT | MUX_MODE0)
/* hsusb0_stp.hsusb0_stp */
- OMAP3_CORE1_IOPAD(0x21a4, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_dir.hsusb0_dir */
- OMAP3_CORE1_IOPAD(0x21a6, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_nxt.hsusb0_nxt */
- OMAP3_CORE1_IOPAD(0x21a8, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data0.hsusb2_data0 */
- OMAP3_CORE1_IOPAD(0x21aa, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data1.hsusb0_data1 */
- OMAP3_CORE1_IOPAD(0x21ac, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data2.hsusb0_data2 */
- OMAP3_CORE1_IOPAD(0x21ae, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data3 */
- OMAP3_CORE1_IOPAD(0x21b0, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data4 */
- OMAP3_CORE1_IOPAD(0x21b2, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data5 */
- OMAP3_CORE1_IOPAD(0x21b4, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data6 */
- OMAP3_CORE1_IOPAD(0x21b6, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */
+ OMAP3_CORE1_IOPAD(0x21a2, PIN_OUTPUT | MUX_MODE0)
/* hsusb0_clk.hsusb0_clk */
+ OMAP3_CORE1_IOPAD(0x21a4, PIN_OUTPUT | MUX_MODE0)
/* hsusb0_stp.hsusb0_stp */
+ OMAP3_CORE1_IOPAD(0x21a6, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_dir.hsusb0_dir */
+ OMAP3_CORE1_IOPAD(0x21a8, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_nxt.hsusb0_nxt */
+ OMAP3_CORE1_IOPAD(0x21aa, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data0.hsusb2_data0 */
+ OMAP3_CORE1_IOPAD(0x21ac, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data1.hsusb0_data1 */
+ OMAP3_CORE1_IOPAD(0x21ae, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data2.hsusb0_data2 */
+ OMAP3_CORE1_IOPAD(0x21b0, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data3 */
+ OMAP3_CORE1_IOPAD(0x21b2, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data4 */
+ OMAP3_CORE1_IOPAD(0x21b4, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data5 */
+ OMAP3_CORE1_IOPAD(0x21b6, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data6 */
+ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */
;
};
};
--
1.8.1.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
[PATCH 3/3] ARM: dts: Fix GPMC timings for LAN9220
I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz chf.fr...@googlemail.com Cc: Dmitry Lifshitz lifsh...@compulab.co.il Cc: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 19 --- arch/arm/boot/dts/omap3-sb-t35.dtsi | 19 --- 2 files changed, 16 insertions(+), 22 deletions(-) diff --git a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi index f577b7d..521c587 100644 --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi @@ -24,11 +24,10 @@ compatible = smsc,lan9221, smsc,lan9115; bank-width = 2; gpmc,mux-add-data; - gpmc,cs-on-ns = 0; - gpmc,cs-rd-off-ns = 186; - gpmc,cs-wr-off-ns = 186; - gpmc,adv-on-ns = 12; - gpmc,adv-rd-off-ns = 48; + gpmc,cs-on-ns = 1; + gpmc,cs-rd-off-ns = 180; + gpmc,cs-wr-off-ns = 180; + gpmc,adv-rd-off-ns = 18; gpmc,adv-wr-off-ns = 48; gpmc,oe-on-ns = 54; gpmc,oe-off-ns = 168; @@ -36,12 +35,10 @@ gpmc,we-off-ns = 168; gpmc,rd-cycle-ns = 186; gpmc,wr-cycle-ns = 186; - gpmc,access-ns = 114; - gpmc,page-burst-access-ns = 6; - gpmc,bus-turnaround-ns = 12; - gpmc,cycle2cycle-delay-ns = 18; - gpmc,wr-data-mux-bus-ns = 90; - gpmc,wr-access-ns = 186; + gpmc,access-ns = 144; + gpmc,page-burst-access-ns = 24; + gpmc,bus-turnaround-ns = 90; + gpmc,cycle2cycle-delay-ns = 90; gpmc,cycle2cycle-samecsen; gpmc,cycle2cycle-diffcsen; vddvario-supply = vddvario; diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi b/arch/arm/boot/dts/omap3-sb-t35.dtsi index b3b6e43..d59e3de 100644 --- a/arch/arm/boot/dts/omap3-sb-t35.dtsi +++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi @@ -23,11 +23,10 @@ reg = 4 0 0xff; bank-width = 2; gpmc,mux-add-data; - gpmc,cs-on-ns = 0; - gpmc,cs-rd-off-ns = 186; - gpmc,cs-wr-off-ns = 186; - gpmc,adv-on-ns = 12; - gpmc,adv-rd-off-ns = 48; + gpmc,cs-on-ns = 1; + gpmc,cs-rd-off-ns = 180; + gpmc,cs-wr-off-ns = 180; + gpmc,adv-rd-off-ns = 18; gpmc,adv-wr-off-ns = 48; gpmc,oe-on-ns = 54; gpmc,oe-off-ns = 168; @@ -35,12 +34,10 @@ gpmc,we-off-ns = 168; gpmc,rd-cycle-ns = 186; gpmc,wr-cycle-ns = 186; - gpmc,access-ns = 114; - gpmc,page-burst-access-ns = 6; - gpmc,bus-turnaround-ns = 12; - gpmc,cycle2cycle-delay-ns = 18; - gpmc,wr-data-mux-bus-ns = 90; - gpmc,wr-access-ns = 186; + gpmc,access-ns = 144; + gpmc,page-burst-access-ns = 24; + gpmc,bus-turnaround-ns = 90; + gpmc,cycle2cycle-delay-ns = 90; gpmc,cycle2cycle-samecsen; gpmc,cycle2cycle-diffcsen; vddvario-supply = vddvario; -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a
[PATCH 2/3] ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree
Looks like we have wrong GPMC timings we have for the cm-t and
sbc-t boards. This can cause occasional strange errors with at
least doing an rsync of large files or doing apt-get dist-upgrade.
Let's fix the issue in two phases. First let's simplify cm-t and
sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing
the issue in multiple places. Then we can fix the timings in
a single place with a follow-up patch.
Cc: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 42 +++
arch/arm/boot/dts/omap3-sb-t35.dtsi | 18 ++-
arch/arm/boot/dts/omap3-sbc-t3517.dts | 13 +++
3 files changed, 18 insertions(+), 55 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
index 75e0a1f..25ba083 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -10,18 +10,6 @@
cpu0-supply = vcc;
};
};
-
- vddvario: regulator-vddvario {
- compatible = regulator-fixed;
- regulator-name = vddvario;
- regulator-always-on;
- };
-
- vdd33a: regulator-vdd33a {
- compatible = regulator-fixed;
- regulator-name = vdd33a;
- regulator-always-on;
- };
};
omap3_pmx_core {
@@ -51,42 +39,18 @@
};
};
+#include omap-gpmc-smsc911x.dtsi
+
gpmc {
ranges = 5 0 0x2c00 0x0100;
- smsc1: ethernet@5,0 {
+ smsc1: ethernet@gpmc {
compatible = smsc,lan9221, smsc,lan9115;
pinctrl-names = default;
pinctrl-0 = smsc1_pins;
interrupt-parent = gpio6;
interrupts = 3 IRQ_TYPE_LEVEL_LOW;
reg = 5 0 0xff;
- bank-width = 2;
- gpmc,mux-add-data;
- gpmc,cs-on-ns = 0;
- gpmc,cs-rd-off-ns = 186;
- gpmc,cs-wr-off-ns = 186;
- gpmc,adv-on-ns = 12;
- gpmc,adv-rd-off-ns = 48;
- gpmc,adv-wr-off-ns = 48;
- gpmc,oe-on-ns = 54;
- gpmc,oe-off-ns = 168;
- gpmc,we-on-ns = 54;
- gpmc,we-off-ns = 168;
- gpmc,rd-cycle-ns = 186;
- gpmc,wr-cycle-ns = 186;
- gpmc,access-ns = 114;
- gpmc,page-burst-access-ns = 6;
- gpmc,bus-turnaround-ns = 12;
- gpmc,cycle2cycle-delay-ns = 18;
- gpmc,wr-data-mux-bus-ns = 90;
- gpmc,wr-access-ns = 186;
- gpmc,cycle2cycle-samecsen;
- gpmc,cycle2cycle-diffcsen;
- vddvario-supply = vddvario;
- vdd33a-supply = vdd33a;
- reg-io-width = 4;
- smsc,save-mac-address;
};
};
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi
b/arch/arm/boot/dts/omap3-sb-t35.dtsi
index 7909c51..b3b6e43 100644
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -2,20 +2,6 @@
* Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
SBC-T3730
*/
-/ {
- vddvario_sb_t35: regulator-vddvario-sb-t35 {
- compatible = regulator-fixed;
- regulator-name = vddvario;
- regulator-always-on;
- };
-
- vdd33a_sb_t35: regulator-vdd33a-sb-t35 {
- compatible = regulator-fixed;
- regulator-name = vdd33a;
- regulator-always-on;
- };
-};
-
omap3_pmx_core {
smsc2_pins: pinmux_smsc2_pins {
pinctrl-single,pins =
@@ -57,8 +43,8 @@
gpmc,wr-access-ns = 186;
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;
- vddvario-supply = vddvario_sb_t35;
- vdd33a-supply = vdd33a_sb_t35;
+ vddvario-supply = vddvario;
+ vdd33a-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
diff --git a/arch/arm/boot/dts/omap3-sbc-t3517.dts
b/arch/arm/boot/dts/omap3-sbc-t3517.dts
index 024c9c6..42189b6 100644
--- a/arch/arm/boot/dts/omap3-sbc-t3517.dts
+++ b/arch/arm/boot/dts/omap3-sbc-t3517.dts
@@ -8,6 +8,19 @@
/ {
model = CompuLab SBC-T3517 with CM-T3517;
compatible = compulab,omap3-sbc-t3517, compulab,omap3-cm-t3517,
ti,am3517, ti,omap3;
+
+ /* Only one GPMC smsc9220 on SBC-T3517, CM-T3517 uses am35x Ethernet */
+ vddvario: regulator-vddvario-sb-t35 {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a-sb-t35 {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
omap3_pmx_core {
Re: [PATCH v2 00/13] extcon: major rework
Hi, On Mon, Apr 14, 2014 at 01:46:11PM +0200, Robert Baldyga wrote: This patchset adds many improvements to extcon class driver and extcon provider drivers. It changes extcon API to faster and safer by replaceing function taking extcon and cable names with functions working with structures representing this objects. Given the first patch series broke even compilation on OMAP1, I think you should provide some test results with the next resend. You should at least compile-test the drivers you modify, or even better, ask people to test your changes if you don't have the HW available. Thanks, A. -- 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] ARM: dts: dra7-evm: keep TPS core control signals active
SYSEN1, 2 control DDR voltages and REGEN2 actually controls PLLEN
(without which platform cannot function). We need to mark in dts that
these are supposed to be always on.
Palmas REGEN1 and REGEN3(called REGEN2) are unused on the platform. So
we let them auto disable themselves by not defining them.
Cc: J Keerthy j-keer...@ti.com
Signed-off-by: Subramaniam Chanderashekarapuram subramaniam...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Patch based on v3.15-rc2, also tested on next-20140423 tag:
Tested by applying [1] (auto disable unused regulator for regulators that are
deferred):
Without [1]: http://slexy.org/raw/s21MCHgeJo (no regulators are disabled)
with [1]: http://slexy.org/raw/s21c99YY8n (unused regulators auto disabled).
- DDR and board shuts off :(
With fix: http://slexy.org/raw/s2TH36cThR
[1] https://patchwork.kernel.org/patch/2545061/
arch/arm/boot/dts/dra7-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..3f94f75 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -209,6 +209,27 @@
regulator-max-microvolt = 330;
regulator-boot-on;
};
+
+ sysen1: sysen1 {
+ /* SYSEN1 -... EVM_3V3_SW - DDR VTT */
+ regulator-name = sysen1;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sysen2: sysen2 {
+ /* SYSEN2 - ... TPS57112 1v35DDR */
+ regulator-name = sysen2;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ regen2: regen2 {
+ /* Internal REGEN2 is PLLEN */
+ regulator-name = regen2;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
};
};
--
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: [GIT PULL] arm: omap: Immutable branch between MFD and ARM OMAP due for the v3.16 merge-window
* Lee Jones lee.jo...@linaro.org [140423 07:47]: Hi Tony, Sorry for the delay - I've been snowed under recently. As requested, you patch based on v3.14 ( for some reason :) ). Thanks, I just got tired of chasing regressions with the -rc cycle while trying to work on some PM changes :) Regards, Tony The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-omap-3.16 for you to fetch changes up to a613b739b8c08eab811e677810045cc0522fc3e6: mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree (2014-04-23 15:31:05 +0100) Immutable branch between MFD and ARM OMAP due for v3.16 merge-window. Tony Lindgren (1): mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree arch/arm/mach-omap2/omap_twl.c | 60 drivers/mfd/twl-core.c | 15 +++ 2 files changed, 15 insertions(+), 60 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode
* Tero Kristo t-kri...@ti.com [140423 00:51]:
On 04/12/2014 06:02 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [140412 02:01]:
On 04/11/2014 02:47 AM, Tony Lindgren wrote:
@@ -282,6 +283,7 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
+ omap3_vc_set_pmic_signaling(core_next_state);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
I think this implementation is sub-optimal, as it only scales
voltages if core is entering idle state. MPU only idle is possible,
however you do not scale voltages in this case.
Hmm that's same as PWRDM_POWER_RET? That's working too.
Or do you have something else in mind that I'm not aware
of?
No, I mean the case where core_next_state == PWRDM_POWER_ON, but
mpu_next_state = PWRDM_POWER_RET. You could scale MPU voltage in this case
but you don't with this implementation.
OK makes sense to pass both mpu_next_state and core_next_state
to the function then.
@@ -220,6 +220,78 @@ static inline u32 omap_usec_to_32k(u32 usec)
return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
}
+void omap3_vc_set_pmic_signaling(int core_next_state)
+{
+ u32 voltctrl;
+
+ voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VOLTCTRL_OFFSET);
Just a note here, I am currently working on trying to get rid of all
the direct prm_read/write calls outside PRCM drivers, this and rest
should use voltdm-read/write.
OK, sounds like you already have a patch for that in your
3.14-rc4-cm-prm-driver-wip branch?
Yes, there is a patch for that.
OK I'll pick it from there.
Let's do the fixes first, then it's going to be a lot easier for
us to test the rest of the PRMC changes.
+ /*
+ * By default let's use I2C4 signaling for retention idle
+ * and sys_off_mode pin signaling for off idle. This way we
+ * have sys_clk_req pin go down for retention and both
+ * sys_clk_req and sys_off_mode pins will go down for off
+ * idle. And we can also scale voltages to zero for off-idle.
+ * Note that no actual voltage scaling will happen unless the
+ * board specific twl4030 PMIC scripts are loaded.
+ */
+ val = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTCTRL_OFFSET);
Why not use the I2C4 signalling for off-mode? This way the voltages
can be scaled to 0.6V even without any board specific scripts.
Using I2C4 works too, we're just missing a place to set
and clear OMAP3430_PRM_VOLTCTRL_SEL_OFF bit currently. Sounds
like eventually we should allow changing it dynamically somewhere.
You can't check the presence of the scripts here?
I guess we could eventually add something for that :)
But for now, SEL_OFF should be enabled as it allows debugging PM
by looking at the sys_clkreq and sys_off_mode pins no matter if
there are board specific scripts or not. The sys_off_mode won't
toggle if things are configured to use I2C4, which is confusing.
You can always measure the voltage rails directly also, but yea, it is more
convenient to just look at the led.
And works for making sure we don't get new PM kernel regressions
even if twl4030 is not working properly :)
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 07/11] ARM: dts: Enable N900 keybaord sleep leds by default
* Aaro Koskinen aaro.koski...@iki.fi [140411 16:39]:
Hi,
On Thu, Apr 10, 2014 at 04:47:15PM -0700, Tony Lindgren wrote:
+leds {
+compatible = gpio-leds;
+heartbeat {
+label = debug::sleep;
+gpios = gpio6 2 GPIO_ACTIVE_HIGH; /* gpio162 */
+linux,default-trigger = default-on;
Just some very minor nits, spaces should be converted to TABs here
for indent, and patch title should say keyboard instead of keybaord.
Acked-by: Aaro Koskinen aaro.koski...@iki.fi
Thanks and sorry for the delay, got sidetracked with some GPMC bugs.
Here's the updated version of this patch.
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Wed, 23 Apr 2014 13:59:24 -0700
Subject: [PATCH] ARM: dts: Enable N900 keyboard sleep leds by default
On N900 there are nice LEDs that show the state of the
sys_clkreq and sys_off_mode pins.
These LEDs go low when the system enters deeper idle
states. The left LED shows the state of the sys_clkreq
pin, and goes off during retention idle. The right LED
shows the state of sys_off_mode pin and both go off
during off idle.
As N900 is a battery operated device, these LEDs should
be off most of the time. So let's enable them by default
so we can make sure the system is mostly idle.
This allows the maintainers to also immediately test
patches for PM regressions by looking at the LEDs,
which certainly makes my life easier.
The LED can naturally be disabled during runtime with:
# echo none /sys/class/leds/debug::sleep/trigger
Note that we don't currently have support for omap3
errata 1.158 that remuxes GPIO pins to INPUT_PULLUP |
MUX_MODE7 for the duration of idle. This means that the
GPIO pins set high will go down during off idle. In this
case it does not matter as the sys_off_mode goes down
too, but there's still a slim chance of false off idle
LED signals. If in doubt, false LED signals can be
verified by the sys_off_mode or vdd_core values.
Also note that to allow the UARTs to autoidle, the
following needs to be run on N900 to enable off idle:
#!/bin/sh
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d)
for uart in $uarts; do
echo 3000 $uart/autosuspend_delay_ms
done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d)
for uart in $uarts; do
echo enabled $uart/wakeup
echo auto $uart/control
done
echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
For retention idle, change the above to set 0 to
enable_off_mode.
Also note that without the twl4030 PM scripts the actual
voltage scaling won't happen for off idle so we only get
voltage scaling over I2C4 for retention idle. I'll do
some device tree patches for those also a bit later on.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Pali Rohár pali.ro...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Sebastian Reichel s...@kernel.org
Cc: Tero Kristo t-kri...@ti.com
Acked-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -21,6 +21,17 @@
};
};
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = debug::sleep;
+ gpios = gpio6 2 GPIO_ACTIVE_HIGH; /* gpio162 */
+ linux,default-trigger = default-on;
+ pinctrl-names = default;
+ pinctrl-0 = debug_leds;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
@@ -114,6 +125,12 @@
;
};
+ debug_leds: pinmux_debug_led_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)
/* mcbsp1_clkx.gpio_162 */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc1_clk */
--
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 0/5] GPIO OMAP driver changes for v3.16
Hello Aaro, On Thu, Apr 10, 2014 at 11:22 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Thu, Apr 10, 2014 at 10:17:44PM +0200, Javier Martinez Canillas wrote: The same happens also on Nokia 770: [0.118896] genirq: Setting trigger mode 0 for irq 128 failed (gpio_irq_type+0x0/0x220) I don't have those errors when booting on my DM3730 IGEPv2 board but it seems that for some reason on omap1 __irq_set_trigger() complains when IRQ_TYPE_NONE is used as a default flag when calling gpiochip_irqchip_add() Could you please test the following patch and tell me if your board still works and makes the errors go away? Now it complains about mode 8... [0.118835] genirq: Setting trigger mode 8 for irq 128 failed (gpio_irq_type +0x0/0x220) A. On thread [1] was reported a regression on a Sitara AM335x board because the irq .map function handler used on the gpiolib called irq_set_type() for each pin on the bank. In the case of that board, a GPIO pin is used to control the SDRAM termination regulator and calling irq_set_type() sets the GPIO as input thus making the board to fail on boot. But this may also explain why you had those error logs on your OMAP1 board when applying these patches since that changes GPIO OMAP semantics when the driver expected irq_set_type() to only be called when a IRQ is requested. After some discussion Linus proposed a patch [2] which I think should also fix your issue. Can you please give it a try and provide your Tested-by for that patch? Thanks a lot and best regards, Javier [1]: http://marc.info/?t=139817273800014r=1w=2 [2] https://patchwork.kernel.org/patch/4041881/ -- 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] omap fixes against v3.15-rc1
Hi, Apologies if you see a duplicate of this pull request, looks like my scripts have become flakey with sending out the mails since I updated them. The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/fixes-v2-signed for you to fetch changes up to fb677ef70b65e22cd4401d31b700a8b4041efae1: ARM: OMAP2+: Fix GPMC remap for devices using an offset (2014-04-23 11:09:22 -0700) Fixes for omaps, mostly to fix some GPMC, DSS and USB issues for device tree based booting. And turns out BeagleBoard xM A/B needs it's own minimal dts in addition to the related u-boot changes. Also few minor documentation and typo fixes are merged to get them out of the way. Geert Uytterhoeven (2): ARM: dts: Grammar /is uses/ is used/ ARM: dts: Grammar /that will/it will/ Johan Hovold (1): ARM: dts: OMAP2+: remove uses of obsolete gpmc,device-nand Kishon Vijay Abraham I (1): ARM: OMAP2+: Fix config name for USB3 PHY Leigh Brown (1): ARM: dts: am335x: update USB DT references Peter Ujfalusi (1): ARM: dts: dra7xx-clocks: Correct mcasp2_ahclkx_mux bit-shift Robert Nelson (1): ARM: dts: Add support for the BeagleBoard xM A/B Roger Quadros (2): ARM: OMAP3: hwmod data: Correct clock domains for USB modules ARM: dts: omap5: Add clocks to USB3 PHY node Sebastian Reichel (1): ARM: OMAP2+: N900: remove omapdss init for DT boot Suman Anna (1): ARM: OMAP2+: hwmod: fix missing braces in _init() Tero Kristo (1): ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register Tomi Valkeinen (1): ARM: AM43xx: fix dpll init in bypass mode Tony Lindgren (4): Merge branch 'fixes-v3.15-rc1'; commit '390403fd79821bbd0c3a0d83307df2be87047b36' into omap-for-v3.15/fixes Merge tag 'for-v3.15-rc/omap-fixes-a' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.15/fixes ARM: OMAP2+: Fix oops for GPMC free ARM: OMAP2+: Fix GPMC remap for devices using an offset Wolfram Sang (1): ARM: AM335X: EVM: fix pinmux documentation in devicetree arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++-- arch/arm/boot/dts/am335x-evm.dts | 8 arch/arm/boot/dts/am335x-evmsk.dts | 4 ++-- arch/arm/boot/dts/am335x-igep0033.dtsi | 5 ++--- arch/arm/boot/dts/am33xx.dtsi | 6 +++--- arch/arm/boot/dts/dra7.dtsi| 4 ++-- arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +- arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 16 arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 1 - arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/boot/dts/omap4.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 10 -- arch/arm/configs/omap2plus_defconfig | 2 +- arch/arm/mach-omap2/board-rx51-video.c | 2 +- arch/arm/mach-omap2/clkt_dpll.c| 4 ++-- arch/arm/mach-omap2/gpmc.c | 15 +-- arch/arm/mach-omap2/omap_hwmod.c | 3 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++-- arch/arm/mach-omap2/pm34xx.c | 4 21 files changed, 65 insertions(+), 37 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts -- 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 10/13] tty: serial: omap: remove some dead code
On Wed, 23 Apr 2014 10:35:04 -0500 Nishanth Menon n...@ti.com wrote:
On 04/23/2014 09:58 AM, Felipe Balbi wrote:
nobody passes a DTR_gpio to this driver, so
this code is not necessary.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Niel,
this seems to revert the functionality introduced in
commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100
(OMAP/serial: Add support for driving a GPIO as DTR.)
would you like to Ack this change?
I have a couple of out-of-tree drivers that use this support.
I hope to get back to working on that code one day and even get those drivers
upstream. So I would really prefer this code to remain if it isn't causing
any actual problems.
Of course, I can always re-submit it when I need it again, but that it just
extra work all around.
Sorry that I have pushed those drivers already, but sometimes life gets in
the way :-)
Thanks,
NeilBrown
drivers/tty/serial/omap-serial.c | 39
---
1 file changed, 39 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index b46aaf3..6654682 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -163,10 +163,6 @@ struct uart_omap_port {
u8 wakeups_enabled;
u32 features;
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
-
struct serial_rs485 rs485;
int rts_gpio;
@@ -694,16 +690,6 @@ static void serial_omap_set_mctrl(struct uart_port
*port, unsigned int mctrl)
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
- if (gpio_is_valid(up-DTR_gpio)
- !!(mctrl TIOCM_DTR) != up-DTR_active) {
- up-DTR_active = !up-DTR_active;
- if (gpio_cansleep(up-DTR_gpio))
- schedule_work(up-qos_work);
- else
- gpio_set_value(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
- }
}
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -847,9 +833,6 @@ static void serial_omap_uart_qos_work(struct
work_struct *work)
qos_work);
pm_qos_update_request(up-pm_qos_request, up-latency);
- if (gpio_is_valid(up-DTR_gpio))
- gpio_set_value_cansleep(up-DTR_gpio,
- up-DTR_active != up-DTR_inverted);
}
static void
@@ -1672,28 +1655,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
- omap-serial);
- if (ret 0)
- return ret;
- ret = gpio_direction_output(omap_up_info-DTR_gpio,
- omap_up_info-DTR_inverted);
- if (ret 0)
- return ret;
- }
-
- if (gpio_is_valid(omap_up_info-DTR_gpio)
- omap_up_info-DTR_present) {
- up-DTR_gpio = omap_up_info-DTR_gpio;
- up-DTR_inverted = omap_up_info-DTR_inverted;
- } else {
- up-DTR_gpio = -EINVAL;
- }
-
- up-DTR_active = 0;
-
up-dev = pdev-dev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
signature.asc
Description: PGP signature
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
Hi, On Thu, Apr 24, 2014 at 08:43:05AM +1000, NeilBrown wrote: On Wed, 23 Apr 2014 10:35:04 -0500 Nishanth Menon n...@ti.com wrote: On 04/23/2014 09:58 AM, Felipe Balbi wrote: nobody passes a DTR_gpio to this driver, so this code is not necessary. Signed-off-by: Felipe Balbi ba...@ti.com --- Niel, this seems to revert the functionality introduced in commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100 (OMAP/serial: Add support for driving a GPIO as DTR.) would you like to Ack this change? I have a couple of out-of-tree drivers that use this support. I hope to get back to working on that code one day and even get those drivers upstream. So I would really prefer this code to remain if it isn't causing any actual problems. it causes problem with DT (not really). That suport is only available on legacy platform_data-based boot, it's not available on DT. I hear Tony is pretty close to turning OMAP3 DT-only. Of course, I can always re-submit it when I need it again, but that it just extra work all around. I wonder how you will pass those attributes through DT considering they are *really* SW configuration. Why can't you use the real DTR pin, btw ? -- balbi signature.asc Description: Digital signature
[RESEND PATCH] regulator: core: Disable unused regulators after deferred probing is done
From: Saravana Kannan skan...@codeaurora.org regulator_init_complete does a scan of regulators which dont have always-on or consumers are automatically disabled as being unused. However, with deferred probing, late_initcall() is too soon to declare a regulator as unused as the regulator itself might not have registered due to defferal - Example: A regulator deffered due to i2bus not available which in turn is deffered due to pinctrl availability. Since deferred probing is done in late_initcall(), do the cleanup of unused regulators by regulator_init_complete in late_initcall_sync instead of late_initcall. Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Markus Pargmann m...@pengutronix.de Signed-off-by: Saravana Kannan skan...@codeaurora.org [n...@ti.com: minor rewording] Signed-off-by: Nishanth Menon n...@ti.com --- Applies on v3.15-rc2 and on next-20140423 Original post: https://patchwork.kernel.org/patch/2545061/ I rediscovered this patch many times now :(: Latest Example: https://patchwork.kernel.org/patch/4044811/ http://slexy.org/raw/s21MCHgeJo shows none of the unused regulators are disabled and with this fix: http://slexy.org/raw/s2TH36cThR (which auto disables unused regulators). Ccying Markus as author of 66fda75f47dc (regulator: core: Replace direct ops-disable usage) he might be interested as well. Btw, this might open up a lot of broken boards - like we discovered for DRA7 - so it might be a good idea for next instead of current rc cyle giving it some time to cook and get platforms fixed. drivers/regulator/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 9a09f3c..5a05de3 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -3867,4 +3867,4 @@ unlock: return 0; } -late_initcall(regulator_init_complete); +late_initcall_sync(regulator_init_complete); -- 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: [PATCH 10/13] tty: serial: omap: remove some dead code
On Wed, 23 Apr 2014 18:01:21 -0500 Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Apr 24, 2014 at 08:43:05AM +1000, NeilBrown wrote: On Wed, 23 Apr 2014 10:35:04 -0500 Nishanth Menon n...@ti.com wrote: On 04/23/2014 09:58 AM, Felipe Balbi wrote: nobody passes a DTR_gpio to this driver, so this code is not necessary. Signed-off-by: Felipe Balbi ba...@ti.com --- Niel, this seems to revert the functionality introduced in commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100 (OMAP/serial: Add support for driving a GPIO as DTR.) would you like to Ack this change? I have a couple of out-of-tree drivers that use this support. I hope to get back to working on that code one day and even get those drivers upstream. So I would really prefer this code to remain if it isn't causing any actual problems. it causes problem with DT (not really). That suport is only available on legacy platform_data-based boot, it's not available on DT. I hear Tony is pretty close to turning OMAP3 DT-only. Of course, I can always re-submit it when I need it again, but that it just extra work all around. I wonder how you will pass those attributes through DT considering they are *really* SW configuration. Why can't you use the real DTR pin, btw ? This myth that DT is only about hardware is probably one of the reasons that I haven't got these out-of-tree drivers upstream yet. There is no real DTR pin. When I open /dev/ttyWHATEVER, I need the driver for the device that is permanently connected to that serial port to be told that the serial-device has been opened so that it can power on or wake up the device. I don't much care how that happens, or how I tell DT that it has to happen. I just need it to happen. In discrete hardware devices, the DTR line is what you would use. The RS232 port would raise (or lower or whatever) DTR when /dev/ttyWHATEVER was open, and the device that was plugged in would detect the level change and do stuff. But I don't have discrete hardware. I have a bunch of stuff soldered onto a board with ad-hoc connections chosen to make the life of the hardware builder easy rather than chosen to make the life of the software developer easy (which I think is the correct choice). So I need to tell DT This device is plugged into this UART, and there is no DTR line, but when the UARTs DTR line would be asserted (if it had one), then I need that regulator of there turned on. or maybe I need to toggle this GPIO with exactly this pattern, while watching that GPIO to see if it is working. So I thought: 1/ give the UART a virtual DTR so it could drive any GPIO 2/ create a gpio-to-regulator driver which presented as a (virtual) gpio and responded to state changes on that GPIO by turning on or off the regulator 3/ create a dedicated driver which knows how to toggle the magic GPIO while watching the other GPIO to convince the silly device to wakeup, or go to sleep, as required, and have this appear as a (virtual) GPIO. Then I can just tell DT that these (virtual) GPIOs are connected together, and it will all just work. And it does. But given the whole no no, DT is for describing hardware, and you are describing software attitude, it seems that I lost motivation for a while (that wasn't the only reason, but it didn't help). I have a patch which converts the OMAP serial driver to use DT to configure these virtual DTR lines. I'm very happy to submit that if there is some chance it might be accepted and will keep the current DTR code in place. On the other hand, if you can point out to me what I'm missing, and how I can solve my problem with any virtual GPIOs, I'm all ears. To make my problem simple and explicit: I have a device attached to a UART which has a separate regulator. The regulator should be powered on if and only if the /dev/ttyXX interface to the UART is open. The device is a bluetooth transceiver. (I have another device which is a GPS receiver which has similar but more complicated requirements) Thanks, NeilBrown signature.asc Description: PGP signature
RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
--
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/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Best regards,
Jingoo Han
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
--
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/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
Thanks
--
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/4] ARM: dts: Enable twl4030 off-idle configuration for selected omaps
At least N900 now seems to shut down the external oscillator
when hitting off-idle.
OMAP37XX EVM (TMDSEVM3730) does not seem to have twl4030 clken
pin connected, so there is no point trying to enable shutting
down of the oscillator on it for the extra latency it adds.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-evm-common.dtsi | 7 +++
arch/arm/boot/dts/omap3-n900.dts| 5 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..3d25340 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -45,6 +45,13 @@
#include twl4030.dtsi
#include twl4030_omap3.dtsi
+twl {
+ twl_power: power {
+ compatible = ti,twl4030-power-idle;
+ ti,use_poweroff;
+ };
+};
+
i2c2 {
clock-frequency = 40;
};
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index bae58c0..c9ed2d4 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -269,6 +269,11 @@
compatible = ti,twl4030-audio;
ti,enable-vibra = 1;
};
+
+ twl_power: power {
+ compatible = ti,twl4030-power-idle-osc-off;
+ ti,use_poweroff;
+ };
};
twl_gpio {
--
1.8.1.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
[PATCH 0/4] mfd: twl4030-power: Enable off-idle configuration when booted with device tree
Hi all, One of the major blockers for making omap3 to boot in device tree mode has been the fact that power management has not been working as well as when booted in legacy mode. This series when applied on top of the patches in tread [PATCH 00/11] Fixes for omap PM for making omap3 DT only. This series makes the twl4030 PMIC configurations generic so that most boards can just use one of the configurations based on the compatible flag alone. This allows us to drop all the related platform data once omap3 boots in device tree only mode. Lee, if these patches look OK to you, please feel free to pick them, preferrably to the immutable branch you already have set up so I can also merge them in to be able to have things working in my branch properly for PM. Regards, Tony Tony Lindgren (4): mfd: twl4030-power: Add recommended idle configuration mfd: twl4030-power: Add support for board specific configuration mfd: twl4030power: Add a configuration to turn off oscillator during off-idle ARM: dts: Enable twl4030 off-idle configuration for selected omaps .../devicetree/bindings/mfd/twl4030-power.txt | 10 + arch/arm/boot/dts/omap3-evm-common.dtsi| 7 + arch/arm/boot/dts/omap3-n900.dts | 5 + drivers/mfd/twl4030-power.c| 205 + include/linux/i2c/twl.h| 1 + 5 files changed, 228 insertions(+) -- 1.8.1.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
[PATCH 1/4] mfd: twl4030-power: Add recommended idle configuration
These settings are based on the Recommended Sleep Sequences for
the Zoom Platform pdf at:
http://omappedia.com/wiki/File:Recommended_Sleep_Sequences_Zoom.pdf
These settings assume most of the regulators are under control of
Linux, and cuts off VDD1 and VDD2 during off-idle as Linux cannot
do it.
For any board specific changes to these, let's patch them in as
changes to the generic data in the follow-up patches. This keeps
the board specific changes small.
Note that this does not consider the twl5030 errata 27. That
can be added later on after it has been tested.
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/mfd/twl4030-power.txt | 4 +
drivers/mfd/twl4030-power.c| 165 +
2 files changed, 169 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b906116..bbd6603 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -8,10 +8,14 @@ Required properties:
- compatible : must be one of the following
ti,twl4030-power
ti,twl4030-power-reset
+ ti,twl4030-power-idle
The use of ti,twl4030-power-reset is recommended at least on
3530 that needs a special configuration for warm reset to work.
+When using ti,twl4030-power-idle, the TI recommended configuration
+for idle modes is loaded to the tlw4030 PMIC.
+
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
SLEEP-to-OFF transition when the system poweroffs.
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 1db0560..89a8528 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -595,11 +595,176 @@ static struct twl4030_power_data omap3_reset = {
.resource_config= omap3_rconfig,
};
+/* Recommended generic default idle configuration for off-idle */
+
+/* Broadcast message to put res to sleep */
+static struct twl4030_ins omap3_idle_sleep_on_seq[] = {
+ { MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_ALL,
+ 0, RES_STATE_SLEEP), 2 },
+};
+
+static struct twl4030_script omap3_idle_sleep_on_script = {
+ .script = omap3_idle_sleep_on_seq,
+ .size = ARRAY_SIZE(omap3_idle_sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/* Broadcast message to put res to active */
+static struct twl4030_ins omap3_idle_wakeup_p12_seq[] = {
+ { MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_ALL,
+ 0, RES_STATE_ACTIVE), 2 },
+ };
+
+static struct twl4030_script omap3_idle_wakeup_p12_script = {
+ .script = omap3_idle_wakeup_p12_seq,
+ .size = ARRAY_SIZE(omap3_idle_wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+/* Broadcast message to put res to active */
+static struct twl4030_ins omap3_idle_wakeup_p3_seq[] = {
+ { MSG_SINGULAR(DEV_GRP_NULL, RES_CLKEN, RES_STATE_ACTIVE), 0x37 },
+ { MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_ALL,
+ 0, RES_STATE_ACTIVE), 2 },
+};
+
+static struct twl4030_script omap3_idle_wakeup_p3_script = {
+ .script = omap3_idle_wakeup_p3_seq,
+ .size = ARRAY_SIZE(omap3_idle_wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+static struct twl4030_script omap3_idle_wrst_script = {
+ .script = omap3_wrst_seq,
+ .size = ARRAY_SIZE(omap3_wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_idle_scripts[] = {
+ omap3_idle_wakeup_p12_script,
+ omap3_idle_wakeup_p3_script,
+ omap3_idle_wrst_script,
+ omap3_idle_sleep_on_script,
+};
+
+/*
+ * Usable values for .remap_sleep and .remap_off
+ * Based on table 5.3.3 Resource Operating modes
+ */
+enum {
+ TWL_REMAP_OFF = 0,
+ TWL_REMAP_SLEEP = 8,
+ TWL_REMAP_ACTIVE = 9,
+};
+
+#define TWL_DEV_GRP_P123 (DEV_GRP_P1 | DEV_GRP_P2 | DEV_GRP_P3)
+
+/*
+ * Recommended configuration based on Recommended Sleep
+ * Sequences for the Zoom Platform:
+ * http://omappedia.com/wiki/File:Recommended_Sleep_Sequences_Zoom.pdf
+ */
+static struct twl4030_resconfig omap3_idle_rconfig[] = {
+ { .resource = RES_VAUX1, .devgroup = DEV_GRP_NULL,
+ .type = 0, .type2 = 0, .remap_off = TWL_REMAP_OFF,
+ .remap_sleep = TWL_REMAP_SLEEP, },
+ { .resource = RES_VAUX2, .devgroup = DEV_GRP_NULL,
+ .type = 0, .type2 = 0, .remap_off = TWL_REMAP_OFF,
+ .remap_sleep = TWL_REMAP_SLEEP, },
+ { .resource = RES_VAUX3, .devgroup = DEV_GRP_NULL,
+ .type = 0, .type2 = 0, .remap_off = TWL_REMAP_OFF,
+ .remap_sleep = TWL_REMAP_SLEEP, },
+ { .resource = RES_VAUX4, .devgroup =
[PATCH 2/4] mfd: twl4030-power: Add support for board specific configuration
With the recommended twl4030 configuration added, we can now add
board specific changes as modifications to the recommended
configuration.
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/mfd/twl4030-power.c | 21 +
include/linux/i2c/twl.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 89a8528..89c6b1a 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -511,13 +511,34 @@ twl4030_power_configure_scripts(const struct
twl4030_power_data *pdata)
return 0;
}
+static void twl4030_patch_rconfig(struct twl4030_resconfig *common,
+ struct twl4030_resconfig *board)
+{
+ while (common-resource) {
+ struct twl4030_resconfig *b = board;
+
+ while (b-resource) {
+ if (b-resource == common-resource) {
+ *common = *b;
+ break;
+ }
+ b++;
+ }
+ common++;
+ }
+}
+
static int
twl4030_power_configure_resources(const struct twl4030_power_data *pdata)
{
struct twl4030_resconfig *resconfig = pdata-resource_config;
+ struct twl4030_resconfig *boardconf = pdata-board_config;
int err;
if (resconfig) {
+ if (boardconf)
+ twl4030_patch_rconfig(resconfig, boardconf);
+
while (resconfig-resource) {
err = twl4030_configure_resource(resconfig);
if (err)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index ade1c06..069f78f 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -659,6 +659,7 @@ struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned num;
struct twl4030_resconfig *resource_config;
+ struct twl4030_resconfig *board_config;
#define TWL4030_RESCONFIG_UNDEF((u8)-1)
bool use_poweroff; /* Board is wired for TWL poweroff */
};
--
1.8.1.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
