Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers
Hi, On Thu, Nov 21, 2013 at 07:56:51PM -0600, Joel Fernandes wrote: [...] > New functions for OF-only boot are introduced, and we can soon delete the old > versions once we migrate all platforms. Currently only AM335x is migrated and actually, you don't need to initialize .init_timer at all in DT boot. Just use CLKSOURCE_OF_DECLARE() and pass your omap_generic_timer_init() as argument (although, I'd call it omap_of_timer_init()). That will put of_device_id structure on a special section (__clksource_of_table) and pass your function as a data argument. That function will be called automatically during init. -- balbi signature.asc Description: Digital signature
[PATCH 2/8] rc: ir-rx51: Use clk API to get clock rate
ir-rx51 tries to use struct clk directly, which is private. Go through to clk API to get the rate. Compile tested only. Signed-off-by: Joel Fernandes --- drivers/media/rc/ir-rx51.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c index 31b955b..7367122 100644 --- a/drivers/media/rc/ir-rx51.c +++ b/drivers/media/rc/ir-rx51.c @@ -26,8 +26,8 @@ #include #include -#include -#include +#include +#include #include #include @@ -209,7 +209,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51) } clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer); - lirc_rx51->fclk_khz = clk_fclk->rate / 1000; + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000; return 0; -- 1.8.1.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 0/8] OMAP: timers: Preparation for migration to clocksource
This series is in preparation to make the OMAP dmtimer a clocksource driver (moving it drivers/clocksource/). As a first step, we introduce a a generic .init_time function OMAP DT platforms that can be used across OMAP devices. Also introduced are a better separation between omap-specific code such as hwmod and the generic timer code. This will allow us to move the generic portion to drivers/clocksource/ in the future. The generic functions with the new DT bindings were tested on OMAP4 and AM33xx. Although, OMAP4 uses the local timer for clocksource by default. Lastly, this series also adds a new omap-timer.h header that allows drivers to use the public dmtimer API in MULTIPLATFORM configurations, and along with this, ir-rx51 is enabled as well, with some fixes to it. Joel Fernandes (8): ARM: OMAP: Move public portion of dmtimer.h to include/linux/omap-timer.h rc: ir-rx51: Use clk API to get clock rate rc: ir-rx51: Turn ON ir-rx51 as it should work for MULTIPLATFORM ARM: OMAP4: timer: Remove non-DT code for TWD timer ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers devicetree: doc: Document ti,timer-parent property ARM: DTS: am33xx: Provide the ti,timer-parent property ARM: AM33xx: Move to using omap_generic_timer_init for init_time .../devicetree/bindings/arm/omap/timer.txt | 17 ++ arch/arm/boot/dts/am33xx.dtsi | 2 + arch/arm/mach-omap2/board-generic.c| 2 +- arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/timer.c| 257 +++-- arch/arm/plat-omap/include/plat/dmtimer.h | 121 +- drivers/media/rc/Kconfig | 2 +- drivers/media/rc/ir-rx51.c | 6 +- include/linux/omap-timer.h | 167 + 9 files changed, 432 insertions(+), 143 deletions(-) create mode 100644 include/linux/omap-timer.h -- 1.8.1.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 4/8] ARM: OMAP4: timer: Remove non-DT code for TWD timer
OMAP4 is DT only boot and TWD local timer will be created from clocksource-of
layer. We remove OMAP4 code that creates it for non-DT.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/timer.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d42da7e..dd41f57 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -605,32 +605,17 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck",
"ti,timer-alwon",
#endif
#ifdef CONFIG_ARCH_OMAP4
-#ifdef CONFIG_HAVE_ARM_TWD
-static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
{
omap4_sync32k_timer_init();
- /* Local timers are not supprted on OMAP4430 ES1.0 */
- if (omap_rev() != OMAP4430_REV_ES1_0) {
- int err;
-
- if (of_have_populated_dt()) {
- clocksource_of_init();
- return;
- }
- err = twd_local_timer_register(&twd_local_timer);
- if (err)
- pr_err("twd_local_timer_register failed %d\n", err);
- }
-}
-#else
-void __init omap4_local_timer_init(void)
-{
- omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_HAVE_ARM_TWD */
+#ifdef CONFIG_HAVE_ARM_TWD
+ /* TWD Local timers are not supprted on OMAP4430 ES1.0 */
+ if (omap_rev() != OMAP4430_REV_ES1_0)
+ clocksource_of_init();
#endif /* CONFIG_ARCH_OMAP4 */
+}
+#endif
#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
void __init omap5_realtime_timer_init(void)
--
1.8.1.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 6/8] devicetree: doc: Document ti,timer-parent property
Timer's parent mux clocks require a parent clock alias, provide the same from device tree. Ultimately this will be provided from DT as clock node phandles but clk-mux driver DT bindings series is still under going review. So to keep things working during the timer migration, we add this property. Originally this was hardcoded in timer.c, now we do the same in DT and would be removing the hardcoded names from timer.c Signed-off-by: Joel Fernandes --- Documentation/devicetree/bindings/arm/omap/timer.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt index 6cf7a75..644bc61 100644 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt @@ -24,6 +24,11 @@ Required properties: where is the instance number of the timer from the HW spec. +Required properties for system timers (clockevents/clocksource): +- ti,timer-parent: System timer's parent mux clock needs to be setup. + This is currently hardcoded in code, for DT boot we + move this to DT. + Optional properties: - ti,timer-alwon: Indicates the timer is in an alway-on power domain. - ti,timer-dsp:Indicates the timer can interrupt the on-chip DSP in -- 1.8.1.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 7/8] ARM: DTS: am33xx: Provide the ti,timer-parent property
Provide the clock alias of the parent clock for the system timer, using the
just added ti,timer-parent property.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am33xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..3934630 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -259,6 +259,7 @@
interrupts = <67>;
ti,hwmods = "timer1";
ti,timer-alwon;
+ ti,timer-parent = "timer_sys_ck";
};
timer2: timer@4804 {
@@ -266,6 +267,7 @@
reg = <0x4804 0x400>;
interrupts = <68>;
ti,hwmods = "timer2";
+ ti,timer-parent = "timer_sys_ck";
};
timer3: timer@48042000 {
--
1.8.1.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 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers
This work is a migration effort of OMAP system timers to the
clocksource/clockevent framework. Consider this as a first-pass in this effort.
There are few cleanups that need to be done first. The HWMOD code is
intertwined with the timer code. HWMOD code cleanups in the future will
hopefully make most of this code go away, so till then we separate out the
power/clocks portion of the code from the actual timer bits. This will
facilitate near-future work of adapting the system timer as a clocksource.
New functions for OF-only boot are introduced, and we can soon delete the old
versions once we migrate all platforms. Currently only AM335x is migrated and
testedA new omap_generic_timer_init function is introduced for DT platforms.
Code required earlier for non-DT platforms such as setup of timer IDs and timer
parent clock is not required. parent clocks are automatically setup by the mux
clock driver through DT so they no longer need to be hardcoded.
The init code will try to pick the best timer for clocksource and clockevent
however bindings are added to force a particular timer as clocksource or
clockevent through DT.
Signed-off-by: Joel Fernandes
---
.../devicetree/bindings/arm/omap/timer.txt | 12 ++
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/timer.c| 235 +
3 files changed, 248 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
index d02e27c..6cf7a75 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -32,6 +32,18 @@ Optional properties:
- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
and therefore cannot be used by the kernel.
+- ti,timer-clockevent,
+ ti,timer-clocksource These properties force the system timer code to choose
+ the particular timer as a clockevent or clocksource.
+ If these properties are not specified, the timer code
+ picks up a "ti,timer-alwon" as the clocksource and a
+ timer containing one of the following properties as
+ the clockevent in the following order:
+ ti,timer-alwon
+ ti,timer-dsp
+ ti,timer-pwm
+ ti,timer-secure
+
Example:
timer12: timer@48304000 {
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 4a5684b..2a6b588 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -86,6 +86,7 @@ extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
+void omap_generic_timer_init(void);
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index dd41f57..8ee2de0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -318,6 +318,89 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
return r;
}
+static int __init omap_dmtimer_power_init(struct omap_dm_timer *timer,
+ struct device_node *np,
+ bool is_counter) {
+ struct omap_hwmod *oh;
+ const char *oh_name = NULL;
+ struct clk *src;
+ const char *parent;
+ int r;
+
+ of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ omap_hwmod_setup_one(oh_name);
+
+ if (!is_counter) {
+ if (oh->_clk)
+ timer->fclk = oh->_clk;
+ else
+ timer->fclk = clk_get(NULL,
+ omap_hwmod_get_main_clk(oh));
+ if (IS_ERR(timer->fclk))
+ return PTR_ERR(timer->fclk);
+
+ parent = of_get_property(np, "ti,timer-parent", NULL);
+ if (!parent) {
+ pr_err("ti,timer-parent required for system timer\n");
+ return -1;
+ }
+
+ src = clk_get(NULL, parent);
+ if (IS_ERR(src)) {
+ pr_err("Couldn't clk_get timer parent\n");
+ return PTR_ERR(src);
+ }
+
+ if (clk_get_parent(timer->fclk) != src) {
+ r = clk_set_parent(timer->fclk, src);
+ if (r < 0) {
+ pr_err("%s: %s cannot set source\n", __func__,
+ o
[PATCH 8/8] ARM: AM33xx: Move to using omap_generic_timer_init for init_time
Earlier patch in this series introduced a function omap_generic_timer_init for all DT platforms. Use it for AM33xx SoC. Signed-off-by: Joel Fernandes --- arch/arm/mach-omap2/board-generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 87162e1..cfda6bc 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -180,7 +180,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)") .init_irq = omap_intc_of_init, .handle_irq = omap3_intc_handle_irq, .init_machine = omap_generic_init, - .init_time = omap3_gptimer_timer_init, + .init_time = omap_generic_timer_init, .dt_compat = am33xx_boards_compat, .restart= am33xx_restart, MACHINE_END -- 1.8.1.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 1/8] ARM: OMAP: Move public portion of dmtimer.h to include/linux/omap-timer.h
Multiplatform support has made arch/arm/plat-omap/include/plat/ inaccessible to
drivers outside the plat-omap directory [1]. Due to this the following drivers
are disabled with !CONFIG_ARCH_MULTIPLATFORM:
CONFIG_IR_RX51 (drivers/media/rc/ir-rx51.c)
CONFIG_TIDSPBRIDGE (drivers/staging/tidspbridge/core/dsp-clock.c)
We move the portion of the dmtimer "API" that should be accessible to the
drivers, into include/linux/omap-timer.h
Build tested changes with IR_RX51.
[1] http://marc.info/?l=linux-omap&m=138421692332108&w=2
Signed-off-by: Joel Fernandes
---
arch/arm/plat-omap/include/plat/dmtimer.h | 121 +-
include/linux/omap-timer.h| 167 ++
2 files changed, 168 insertions(+), 120 deletions(-)
create mode 100644 include/linux/omap-timer.h
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index fb92abb..7d6cff8 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -35,130 +35,11 @@
#include
#include
#include
+#include
#ifndef __ASM_ARCH_DMTIMER_H
#define __ASM_ARCH_DMTIMER_H
-/* clock sources */
-#define OMAP_TIMER_SRC_SYS_CLK 0x00
-#define OMAP_TIMER_SRC_32_KHZ 0x01
-#define OMAP_TIMER_SRC_EXT_CLK 0x02
-
-/* timer interrupt enable bits */
-#define OMAP_TIMER_INT_CAPTURE (1 << 2)
-#define OMAP_TIMER_INT_OVERFLOW(1 << 1)
-#define OMAP_TIMER_INT_MATCH (1 << 0)
-
-/* trigger types */
-#define OMAP_TIMER_TRIGGER_NONE0x00
-#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
-#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
-
-/* posted mode types */
-#define OMAP_TIMER_NONPOSTED 0x00
-#define OMAP_TIMER_POSTED 0x01
-
-/* timer capabilities used in hwmod database */
-#define OMAP_TIMER_SECURE 0x8000
-#define OMAP_TIMER_ALWON 0x4000
-#define OMAP_TIMER_HAS_PWM 0x2000
-#define OMAP_TIMER_NEEDS_RESET 0x1000
-#define OMAP_TIMER_HAS_DSP_IRQ 0x0800
-
-/*
- * timer errata flags
- *
- * Errata i103/i767 impacts all OMAP3/4/5 devices including AM33xx. This
- * errata prevents us from using posted mode on these devices, unless the
- * timer counter register is never read. For more details please refer to
- * the OMAP3/4/5 errata documents.
- */
-#define OMAP_TIMER_ERRATA_I103_I7670x8000
-
-struct omap_timer_capability_dev_attr {
- u32 timer_capability;
-};
-
-struct timer_regs {
- u32 tidr;
- u32 tier;
- u32 twer;
- u32 tclr;
- u32 tcrr;
- u32 tldr;
- u32 ttrg;
- u32 twps;
- u32 tmar;
- u32 tcar1;
- u32 tsicr;
- u32 tcar2;
- u32 tpir;
- u32 tnir;
- u32 tcvr;
- u32 tocr;
- u32 towr;
-};
-
-struct omap_dm_timer {
- int id;
- int irq;
- struct clk *fclk;
-
- void __iomem*io_base;
- void __iomem*irq_stat; /* TISR/IRQSTATUS interrupt status */
- void __iomem*irq_ena; /* irq enable */
- void __iomem*irq_dis; /* irq disable, only on v2 ip */
- void __iomem*pend; /* write pending */
- void __iomem*func_base; /* function register base */
-
- unsigned long rate;
- unsigned reserved:1;
- unsigned posted:1;
- struct timer_regs context;
- int (*get_context_loss_count)(struct device *);
- int ctx_loss_count;
- int revision;
- u32 capability;
- u32 errata;
- struct platform_device *pdev;
- struct list_head node;
-};
-
-int omap_dm_timer_reserve_systimer(int id);
-struct omap_dm_timer *omap_dm_timer_request(void);
-struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
-struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap);
-struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np);
-int omap_dm_timer_free(struct omap_dm_timer *timer);
-void omap_dm_timer_enable(struct omap_dm_timer *timer);
-void omap_dm_timer_disable(struct omap_dm_timer *timer);
-
-int omap_dm_timer_get_irq(struct omap_dm_timer *timer);
-
-u32 omap_dm_timer_modify_idlect_mask(u32 inputmask);
-struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer);
-
-int omap_dm_timer_trigger(struct omap_dm_timer *timer);
-int omap_dm_timer_start(struct omap_dm_timer *timer);
-int omap_dm_timer_stop(struct omap_dm_timer *timer);
-
-int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source);
-int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
unsigned int value);
-int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
unsigned int value);
-int omap_dm_timer_set_match(struct omap
[PATCH 3/8] rc: ir-rx51: Turn ON ir-rx51 as it should work for MULTIPLATFORM
Previous patches moved public portion of dmtimer declaration out into include/linux/. With this, ir-rx51 compiles fine with CONFIG_ARCH_MULTIPLATFORM Signed-off-by: Joel Fernandes --- drivers/media/rc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 11e84bc..36997b6 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -292,7 +292,7 @@ config IR_TTUSBIR config IR_RX51 tristate "Nokia N900 IR transmitter diode" - depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && !ARCH_MULTIPLATFORM + depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC ---help--- Say Y or M here if you want to enable support for the IR transmitter diode built in the Nokia N900 (RX51) device. -- 1.8.1.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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
Hi, On Thu, Nov 21, 2013 at 08:50:50PM +, Mark Brown wrote: > /me notes that he'd probably have been less grumpy if the message had > a subject line that had content in it, even had it gone to the right oh cut the crap already. It contained the commit sha1 and a pretty self-explanatory "regresses MMC". You can't expect me to put everything in the subject and you're only "grumpy" because you're too lazy to move your neck 5 degrees to the right to read the rest of the line. what a long thread for such a small issue Mark, just stop it already. The issue is fixed in -next and that's what matters, everybody's happy. I know I am with my working MMC on BBB. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: OMAP2+: Fix eMMC on n900 with device tree
* Sebastian Reichel [131121 15:18]:
> Hi Tony,
>
> On Thu, Nov 21, 2013 at 10:51:06AM -0800, Tony Lindgren wrote:
> > Looks like we need to configure the regulators and use the pdata
> > quirk to make eMMC work with device tree.
> >
> > It seems that mostly vmmc2 is used, and only some earlier revisions
> > like the macro board used vaux3.
> >
> > Note that we can add support for the macro board later as needed
> > by including the common n900 .dts file and configuring the vaux3
> > instead of vmmc2, and adding support for the smc91x Ethernet.
> >
> > ---
> >
> > Can you guys please test this on production n900 devices?
> >
> > I've tested it with my old macro board where I had to patch in vaux3
> > instead of vmmc2. I think there's some confusion in the legacy code
> > comments, or else I'm confused. In any case, vaux3 works for the macro
> > board, and I suspect that the production versions have vmmc2.
> >
> > If this does not work and vaux3 as regulator works, please also dump
> > out the system_rev from your board.
>
> The good news is, that I got eMMC working :) The bad news is, that it
> did not work with your patch :( I included my DTS nodes below. The
> phone is HW/System revision 0x2101.
Oh ok, I must have parsed the revisions wrong way then, and the macro
I tried it on must be something newer than I thought :)
> I have a second N900, which has HW revision 0x2204. I did not yet test
> the patch with this phone, but legacy code also seems to use vaux3 for
> it. Seems like we need two n900.dts files?
Well let's use just vaux3 then with a comment to the .dts file if that
works also on your 0x2204. It works on my 0x0010 too.
I folded in your changes to the updated patch below. Care to reply with
your Signed-off-by too assuming it works also on your 0x2204 n900?
Regards,
Tony
From: Tony Lindgren
Date: Wed, 20 Nov 2013 18:03:39 -0800
Subject: [PATCH] ARM: OMAP2+: Fix eMMC on n900 with device tree
Looks like we need to configure the regulators and use the pdata
quirk to make eMMC work with device tree.
It seems that mostly vaux3 is used, and only some earlier revisions
used vmmc2. This has been tested to work on devices where the
system_rev passed by the bootloader has versions 0x0010 and 0x2101.
Cc: devicet...@vger.kernel.org
Cc: Pavel Machek
Cc: Aaro Koskinen
Cc: Sebastian Reichel
[t...@atomide.com: updated with pinctrl changes and comments from Sebastian]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c4f20bf..c2c306d 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -125,6 +125,21 @@
>;
};
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins = <
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat0
*/
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat1
*/
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat2
*/
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat3
*/
+ 0x134 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat4
*/
+ 0x136 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat5
*/
+ 0x138 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat6
*/
+ 0x13a (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat7
*/
+ >;
+ };
+
display_pins: pinmux_display_pins {
pinctrl-single,pins = <
0x0d4 (PIN_OUTPUT | MUX_MODE4) /*
RX51_LCD_RESET_GPIO */
@@ -358,8 +373,14 @@
cd-gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>; /* 160 */
};
+/* most boards use vaux3, only some old versions use vmmc2 instead */
&mmc2 {
- status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <&vaux3>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+ non-removable;
};
&mmc3 {
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 10c7145..39f020c 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -139,6 +139,7 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
+ { "nokia,omap3-n900", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n9", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
{ "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
--
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.ht
Re: N900 board code in 3.14
Hi Tony,
On Thu, Nov 21, 2013 at 10:58:45AM -0800, Tony Lindgren wrote:
> Also, I just posted a patch to fix the eMMC that you may want to
> try out.
Let's move eMMC diskussion to that patch :)
> > > > [...]
> > > >
> > > > My suggestion would be:
> > > > 1. Find a better workaround for omapdss to acquire the SDI
> > > > regulator. My current hack is obviously not acceptable.
> > > > 2. Load the panel driver via DT as seen above and reference
> > > > the omapdss interface with something like the above
> > > > "ti,dss-source".
> > >
> > > To me it seems that we should be able to add minimal panel entries to DT
> > > if we stick to existing standard bindings. Then the timings etc can be
> > > set up based on the compatible flag. So I would leave out the properties
> > > for ti,sdi-datapairs and ti,dss-source for now, and just set those in
> > > the driver based on the sony,acx565akm compatible flag. Or maybe it should
> > > be sony,acx565akm-n900 if there's some board specific configuration info.
> >
> > So we add reset-gpio and label to the DT data (they are panel
> > specific and independent of omapdss) and just hardcode "dsi.0"
> > with 2 data lanes into the driver? That sounds fine for me.
> >
> > If neither Tomi nor anybody else has better ideas I will cook a
> > patch for that. I'm not sure how to setup the vdds_sdi regulator for
> > omapdss, though. Is there an example for a legacy driver using a DT
> > regulator available?
>
> Not that I know of :)
Javier Martinez Canillas patch did what I was thinking of in [0].
My suggestion would be to add something like this pseudocode to
omapdss:
if(board_is_n900_dt()) {
vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "V28");
}
The problem is, that we do not want to name the regulator
"vdds_dsi", since it's not used exclusivly for omapdss.
In the future it can get the regulator via phandle of course.
> But I guess only the panel driver would need to parse the
> compatible flag and the rest of the DSS could still be initialize
> the legacy way if needed.
Yes, except of the regulator. I will try to get this working
tomorrow.
[0] http://www.spinics.net/lists/arm-kernel/msg286896.html
-- Sebastian
signature.asc
Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Thu, Nov 21, 2013 at 12:46:55PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [131120 18:22]: > > On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote: > > > > In the public documentation of the omaps all SSI related stuff is > > missing and memory areas are marked as reserved. I could not find > > out how to receive the NDA version, so the following is purely > > speculation based on the code. > > > > If I understand it right the HW looks like this: > > > > +-+ > > |GDD (DMA)| <- this one is currently called ssi-controller > > +++ > > | Port 1 | Port 2 | <- these are currently called ssi-port > > +++ > > > > I think the GDD part must be enabled while Port 1 or Port 2 is > > enabled. The last RFC driver from Carlos did not even split up the > > irq/memory areas into different platform devices, but just requested > > all of them in one ssi platform device. > > Might be worth checking. If these blocks have the revision and SYSC > register in the beginning of their address space like all omap modules, > then they are completely separate blocks and can idle independently. This does not seem to be the case. I think this is just one big IP-Core, which provides two ports. > The fact that they have separate interrutps makes me think that's the > case, otherwise there would be just interrupt(s) at the ssi-controllel > level. The original driver from Carlos had all IRQs in one big platform device. I created the ports subdevices, since it looked cleaner than naming resources "port1_mpu_irq0". -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: OMAP2+: Fix eMMC on n900 with device tree
Hi Tony,
On Thu, Nov 21, 2013 at 10:51:06AM -0800, Tony Lindgren wrote:
> Looks like we need to configure the regulators and use the pdata
> quirk to make eMMC work with device tree.
>
> It seems that mostly vmmc2 is used, and only some earlier revisions
> like the macro board used vaux3.
>
> Note that we can add support for the macro board later as needed
> by including the common n900 .dts file and configuring the vaux3
> instead of vmmc2, and adding support for the smc91x Ethernet.
>
> ---
>
> Can you guys please test this on production n900 devices?
>
> I've tested it with my old macro board where I had to patch in vaux3
> instead of vmmc2. I think there's some confusion in the legacy code
> comments, or else I'm confused. In any case, vaux3 works for the macro
> board, and I suspect that the production versions have vmmc2.
>
> If this does not work and vaux3 as regulator works, please also dump
> out the system_rev from your board.
The good news is, that I got eMMC working :) The bad news is, that it
did not work with your patch :( I included my DTS nodes below. The
phone is HW/System revision 0x2101.
I have a second N900, which has HW revision 0x2204. I did not yet test
the patch with this phone, but legacy code also seems to use vaux3 for
it. Seems like we need two n900.dts files?
--- DTS nodes working on the 0x2101 board ---
&omap3_pmx_core {
mmc2_pins: pinmux_mmc2_pins {
pinctrl-single,pins = <
0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_clk */
0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_cmd */
0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat0
*/
0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat1
*/
0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat2
*/
0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat3
*/
0x134 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat4
*/
0x136 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat5
*/
0x138 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat6
*/
0x13a (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc2_dat7
*/
>;
};
};
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
vmmc-supply = <&vaux3>;
vmmc_aux-supply = <&vsim>;
bus-width = <8>;
non-removable;
};
-- Sebastian
signature.asc
Description: Digital signature
[PATCH 0/2] ARM: dts: omap4: Fix pin muxing for wl12xx
Balaji T K (2): ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx ARM: dts: omap4-sdp: Fix pin muxing for wl12xx arch/arm/boot/dts/omap4-panda-common.dtsi | 20 ++-- arch/arm/boot/dts/omap4-sdp.dts | 12 ++-- 2 files changed, 16 insertions(+), 16 deletions(-) -- 1.7.5.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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
Hi, On Thu, Nov 21, 2013 at 10:49:11AM +, Mark Brown wrote: > On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote: > > > actually, I didn't miss you at all. your broo...@linaro.org was in Cc > > of original email thread. The same email which was used to sign-off on > > original commit. > > It's not what's advertised in MAINTAINERS, you should be sending stuff > to that address. My work account is completely separate and for various > reasons (including the fact that a lot of the mails for upstream sent > there are duplicates of mails sent here) non-automatic upstream stuff > has a good chance of getting dropped on the floor and at the very least > will be dealt with more slowly. still, your claim that I didn't Cc any maintainer is completely bogus -- balbi signature.asc Description: Digital signature
Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On Thu, Nov 21, 2013 at 12:27:06PM -0800, Olof Johansson wrote: > If you have one email address listed in MAINTAINERS, and do all your > actual work with another identity, you might want to look at your > workflow a bit. I suggest either signing off with the MAINTAINERS The only thing that uses the work address is patches and signoffs, all my e-mail traffic is done from my kernel.org address (including patch posts). > email address, or changing the entries of that file. People should > expect to be able to email you on the address you sign off with. Unfortunately my employer can't cope with that at present and I don't really want to use my work address for everything since all the stuff from upstream DoSs the stuff that pays the bills. I wouldn't mind if people mailed both, but if you're going to pick a single one then the one listed in MAINTAINERS is the way forwards (which generally is the address people manage to pick). /me notes that he'd probably have been less grumpy if the message had a subject line that had content in it, even had it gone to the right mailbox there's a good chance I'd never even have opened the mail due to that - if anything it going to the wrong place actually worked around the subject line here. signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree
* Tony Lindgren [131120 17:46]:
> * Tony Lindgren [131120 16:06]:
> >
> > They at least had interrupts listed looking at commit 3b9b10. Probably
> > the thing to do for now is to revert those changes, and see if we can
> > just remove the L3 entries from the .dtsi files.
>
> Actually the patch I posted should be able to handle also the
> ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3" property in omap4.dtsi,
> but we're not currently parsing that as we only look at the children
> and not the properties of the OCP bus. Should be fixable, will take a look
> tomorrow if this approach makes sense to you.
OK this one seems to do the right thing for me.
Tony
From: Tony Lindgren
Date: Wed, 20 Nov 2013 15:46:51 -0800
Subject: [PATCH] ARM: OMAP2+: Fix overwriting hwmod data with data from device
tree
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi:ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi:ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson"
Cc: Paul Walmsley
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e3f0eca..ee655da 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2326,38 +2326,80 @@ static int _shutdown(struct omap_hwmod *oh)
return 0;
}
+static int of_dev_find_hwmod(struct device_node *np,
+struct omap_hwmod *oh)
+{
+ int count, i, res;
+ const char *p;
+
+ count = of_property_count_strings(np, "ti,hwmods");
+ if (count < 1)
+ return -ENODEV;
+
+ for (i = 0; i < count; i++) {
+ res = of_property_read_string_index(np, "ti,hwmods",
+ i, &p);
+ if (res)
+ continue;
+ if (!strcmp(p, oh->name)) {
+ pr_debug("omap_hwmod: dt %s[%i] uses hwmod %s\n",
+np->name, i, oh->name);
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+
/**
* of_dev_hwmod_lookup - look up needed hwmod from dt blob
* @np: struct device_node *
* @oh: struct omap_hwmod *
+ * @index: index of the entry found
+ * @found: struct device_node * found or NULL
*
* Parse the dt blob and find out needed hwmod. Recursive function is
* implemented to take care hierarchical dt blob parsing.
- * Return: The device node on success or NULL on failure.
+ * Return: Returns 0 on success, -ENODEV when not found.
*/
-static struct device_node *of_dev_hwmod_lookup(struct device_node *np,
- struct omap_hwmod *oh)
+static int of_dev_hwmod_lookup(struct device_node *np,
+ struct omap_hwmod *oh,
+ int *index,
+ struct device_node **found)
{
- struct device_node *np0 = NULL, *np1 = NULL;
- const char *p;
+ struct device_node *np0 = NULL;
+ int res;
+
+ res = of_dev_find_hwmod(np, oh);
+ if (res >= 0) {
+ *found = np;
+ *index = res;
+ return 0;
+ }
for_each_child_of_node(np, np0) {
- if (of_find_property(np0, "ti,hwmods", NULL)) {
- p = of_get_property(np0, "ti,hwmo
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Sebastian Reichel [131120 18:22]: > On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote: > > In the public documentation of the omaps all SSI related stuff is > missing and memory areas are marked as reserved. I could not find > out how to receive the NDA version, so the following is purely > speculation based on the code. > > If I understand it right the HW looks like this: > > +-+ > |GDD (DMA)| <- this one is currently called ssi-controller > +++ > | Port 1 | Port 2 | <- these are currently called ssi-port > +++ > > I think the GDD part must be enabled while Port 1 or Port 2 is > enabled. The last RFC driver from Carlos did not even split up the > irq/memory areas into different platform devices, but just requested > all of them in one ssi platform device. Might be worth checking. If these blocks have the revision and SYSC register in the beginning of their address space like all omap modules, then they are completely separate blocks and can idle independently. The fact that they have separate interrutps makes me think that's the case, otherwise there would be just interrupt(s) at the ssi-controllel level. > > The other binding pieces can be added later on as they get are ready. > > Sure. They are almost finished btw. I was able to get a gsm network > scan. That's great :) 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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On Thu, Nov 21, 2013 at 2:49 AM, Mark Brown wrote: > On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote: > >> actually, I didn't miss you at all. your broo...@linaro.org was in Cc >> of original email thread. The same email which was used to sign-off on >> original commit. > > It's not what's advertised in MAINTAINERS, you should be sending stuff > to that address. My work account is completely separate and for various > reasons (including the fact that a lot of the mails for upstream sent > there are duplicates of mails sent here) non-automatic upstream stuff > has a good chance of getting dropped on the floor and at the very least > will be dealt with more slowly. If you have one email address listed in MAINTAINERS, and do all your actual work with another identity, you might want to look at your workflow a bit. I suggest either signing off with the MAINTAINERS email address, or changing the entries of that file. People should expect to be able to email you on the address you sign off with. -Olof -- 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
[RFC PATCH v3 2/8] mmc: omap_hsmmc: handle vcc and vcc_aux independently
handle vcc and vcc_aux independently to reduce indent.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 54 +++--
1 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1eb4350..342be25 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -286,11 +286,12 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- ret = mmc_regulator_set_ocr(host->mmc, host->vcc, vdd);
+ if (host->vcc)
+ ret = mmc_regulator_set_ocr(host->mmc, host->vcc, vdd);
/* Enable interface voltage rail, if needed */
if (ret == 0 && host->vcc_aux) {
ret = regulator_enable(host->vcc_aux);
- if (ret < 0)
+ if (ret < 0 && host->vcc)
ret = mmc_regulator_set_ocr(host->mmc,
host->vcc, 0);
}
@@ -298,7 +299,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
/* Shut down the rail */
if (host->vcc_aux)
ret = regulator_disable(host->vcc_aux);
- if (!ret) {
+ if (host->vcc) {
/* Then proceed to shut down the local regulator */
ret = mmc_regulator_set_ocr(host->mmc,
host->vcc, 0);
@@ -318,10 +319,10 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
reg = devm_regulator_get(host->dev, "vmmc");
if (IS_ERR(reg)) {
- dev_err(host->dev, "vmmc regulator missing\n");
+ dev_err(host->dev, "unable to get vmmc regulator %ld\n",
+ PTR_ERR(reg));
return PTR_ERR(reg);
} else {
- mmc_slot(host).set_power = omap_hsmmc_set_power;
host->vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
@@ -334,31 +335,26 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
return -EINVAL;
}
}
+ }
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
- /* Allow an aux regulator */
- reg = devm_regulator_get_optional(host->dev, "vmmc_aux");
- host->vcc_aux = IS_ERR(reg) ? NULL : reg;
+ /* Allow an aux regulator */
+ reg = devm_regulator_get_optional(host->dev, "vmmc_aux");
+ host->vcc_aux = IS_ERR(reg) ? NULL : reg;
- /* For eMMC do not power off when not in sleep state */
- if (mmc_slot(host).no_regulator_off_init)
- return 0;
- /*
- * UGLY HACK: workaround regulator framework bugs.
- * When the bootloader leaves a supply active, it's
- * initialized with zero usecount ... and we can't
- * disable it without first enabling it. Until the
- * framework is fixed, we need a workaround like this
- * (which is safe for MMC, but not in general).
- */
- if (regulator_is_enabled(host->vcc) > 0 ||
- (host->vcc_aux && regulator_is_enabled(host->vcc_aux))) {
- int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
+ /* For eMMC do not power off when not in sleep state */
+ if (mmc_slot(host).no_regulator_off_init)
+ return 0;
+ /*
+* To disable boot_on regulator, enable regulator
+* to increase usecount and then disable it.
+*/
+ if ((host->vcc && regulator_is_enabled(host->vcc) > 0) ||
+ (host->vcc_aux && regulator_is_enabled(host->vcc_aux))) {
+ int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
- mmc_slot(host).set_power(host->dev, host->slot_id,
-1, vdd);
- mmc_slot(host).set_power(host->dev, host->slot_id,
-0, 0);
- }
+ mmc_slot(host).set_power(host->dev, host->slot_id, 1, vdd);
+ mmc_slot(host).set_power(host->dev, host->slot_id, 0, 0);
}
return 0;
--
1.7.5.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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On Thu, Nov 21, 2013 at 11:44:23AM -0700, Stephen Warren wrote: > Ah yes. I also have a delivery-time filter that remembers the last n > Message-Id headers I've received, and it dumps any duplicates into a > separate folder that I ignore. It seems to work pretty well. It looks > like n==1 for me right now. Yeah, that wasn't working great - I think because I was doing it in the wrong place and it was catching lists too. signature.asc Description: Digital signature
Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On 11/21/2013 03:49 AM, Mark Brown wrote: > On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote: > >> actually, I didn't miss you at all. your broo...@linaro.org was >> in Cc of original email thread. The same email which was used to >> sign-off on original commit. > > It's not what's advertised in MAINTAINERS, you should be sending > stuff to that address. My work account is completely separate and > for various reasons (including the fact that a lot of the mails for > upstream sent there are duplicates of mails sent here) > non-automatic upstream stuff has a good chance of getting dropped > on the floor and at the very least will be dealt with more slowly. FYI, the way I deal with this is that my preferred email account subscribes to the mailing list, and I have a filter such that anything that's to/cc either *that* email address *or* any of my other email addresses gets handled the same, and dumped in my (list) inbox rather than in a mailing list folder. -- 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: N900 board code in 3.14
* Sebastian Reichel [131116 07:51]: > On Sat, Nov 16, 2013 at 06:12:26AM -0800, Tony Lindgren wrote: > > [...] > > > b) I could not get the 32GB eMMC working. For me the chip is not found > > > and I don't know how to debug it. > > > > OK the eMMC issue might be related to the control module PBIAS > > register support missing. If so, that should be fixable with the > > auxdata until we have a minimal control module device driver to > > deal with the PBIAS and expose those features as regulators to > > the omap-hsmmc driver. > > I wasn't aware, that PBIAS register support is missing for DT > boot. The existing board code uses a 2.8-3.0V regulator for mmc1, > so missing PBIAS is probably the problem. Right, sorry I was confused, looks like we don't need to worry about that. And looks like Balaji just posted patches for the PBIAS support. Also, I just posted a patch to fix the eMMC that you may want to try out. > > > [...] > > > > > > My suggestion would be: > > > 1. Find a better workaround for omapdss to acquire the SDI > > > regulator. My current hack is obviously not acceptable. > > > 2. Load the panel driver via DT as seen above and reference > > > the omapdss interface with something like the above > > > "ti,dss-source". > > > > To me it seems that we should be able to add minimal panel entries to DT > > if we stick to existing standard bindings. Then the timings etc can be > > set up based on the compatible flag. So I would leave out the properties > > for ti,sdi-datapairs and ti,dss-source for now, and just set those in > > the driver based on the sony,acx565akm compatible flag. Or maybe it should > > be sony,acx565akm-n900 if there's some board specific configuration info. > > So we add reset-gpio and label to the DT data (they are panel > specific and independent of omapdss) and just hardcode "dsi.0" > with 2 data lanes into the driver? That sounds fine for me. > > If neither Tomi nor anybody else has better ideas I will cook a > patch for that. I'm not sure how to setup the vdds_sdi regulator for > omapdss, though. Is there an example for a legacy driver using a DT > regulator available? Not that I know of :) But I guess only the panel driver would need to parse the compatible flag and the rest of the DSS could still be initialize the legacy way if needed. 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 2/3] ARM: OMAP2+: Add fixed regulator to omap2plus_defconfig
We do not have REGULATOR_FIXED selected if no boards are selected and we boot with device tree. This can cause various devices to fail. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 98a50c3..bfa80a1 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -173,6 +173,7 @@ CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y -- 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/3] Yet more fixes for booting omaps with device tree
Hi all, Hopefully this is the last set for the -rc cycle on the legacy booting vs device tree booting regressions. Regards, Tony Tony Lindgren (3): ARM: OMAP2+: Fix more missing data for omap3.dtsi file ARM: OMAP2+: Add fixed regulator to omap2plus_defconfig ARM: OMAP2+: Fix eMMC on n900 with device tree arch/arm/boot/dts/omap3-n900.dts | 6 +- arch/arm/boot/dts/omap3.dtsi | 42 arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/pdata-quirks.c | 1 + 4 files changed, 49 insertions(+), 1 deletion(-) -- 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
Re: [RFC PATCH v3 1/8] mmc: omap_hsmmc: use devm_regulator API
On 21 November 2013 15:20, Balaji T K wrote:
> Use devm_regulator API, while at it use
> devm_regulator_get_optional for optional vmmc_aux supply
>
> Signed-off-by: Balaji T K
> ---
> drivers/mmc/host/omap_hsmmc.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index dbd32ad..1eb4350 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -316,7 +316,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> struct regulator *reg;
> int ocr_value = 0;
>
> - reg = regulator_get(host->dev, "vmmc");
> + reg = devm_regulator_get(host->dev, "vmmc");
> if (IS_ERR(reg)) {
> dev_err(host->dev, "vmmc regulator missing\n");
> return PTR_ERR(reg);
> @@ -336,7 +336,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> }
>
> /* Allow an aux regulator */
> - reg = regulator_get(host->dev, "vmmc_aux");
> + reg = devm_regulator_get_optional(host->dev, "vmmc_aux");
> host->vcc_aux = IS_ERR(reg) ? NULL : reg;
>
> /* For eMMC do not power off when not in sleep state */
> @@ -366,8 +366,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
>
> static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
> {
> - regulator_put(host->vcc);
> - regulator_put(host->vcc_aux);
> mmc_slot(host).set_power = NULL;
> }
While you are touching this code I would suggest to convert to
mmc_regulator_get_supply instead. That mean the vmmc_aux change name
to vqmmc though, so you need to adapt for this as well then.
Kind regards
Ulf Hansson
>
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 3/8] regulator: add pbias regulator support
On Thu, Nov 21, 2013 at 07:50:22PM +0530, Balaji T K wrote:
> +static int pbias_regulator_set_voltage(struct regulator_dev *dev,
> + int min_uV, int max_uV, unsigned *selector)
> +{
> + struct pbias_regulator_data *data = rdev_get_drvdata(dev);
> + const struct pbias_bit_map *bmap = data->bmap;
> + int ret, vmode;
> +
> + if (min_uV <= 180)
> + vmode = 0;
> + else if (min_uV > 180)
> + vmode = bmap->vmode;
> +
> + ret = regmap_update_bits(data->syscon, data->pbias_reg,
> + bmap->vmode, vmode);
> + data->voltage = min_uV;
> +static int pbias_regulator_get_voltage(struct regulator_dev *rdev)
> +{
> + struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
> +
> + return data->voltage;
> +}
These don't match up with each other - the get and set voltage calls
should reflect what the hardware state is, not what was requested by the
caller. You should be able to use the regmap helpers I think.
> +static int pbias_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
> + const struct pbias_bit_map *bmap = data->bmap;
> + int ret;
> +
> + ret = regmap_update_bits(data->syscon, data->pbias_reg,
> + bmap->enable_mask, bmap->enable);
regulator_enable_regmap() and similarly for disable() and is_enabled().
> + supply_name = initdata->constraints.name;
> +
> + of_property_read_u32(np, "startup-delay-us", &startup_delay);
> + ret = of_property_read_u32(np, "pbias-reg-offset",
> +&drvdata->pbias_reg);
> + if (ret) {
> + dev_err(&pdev->dev, "no pbias-reg-offset property set\n");
> + return ret;
> + }
This looks like it should be added as a standard property for overridig
the regulator delay if it can't be set based on the compatible string
alone due to board dependencies. Do something like what's done for
regulator-ramp-delay.
> +err_regulator:
> + kfree(drvdata->desc.name);
> + return ret;
devm_kzalloc().
> +static int __init pbias_regulator_init(void)
> +{
> + return platform_driver_register(&pbias_regulator_driver);
> +}
> +subsys_initcall(pbias_regulator_init);
module_platform_driver().
signature.asc
Description: Digital signature
[PATCH 3/3] ARM: OMAP2+: Fix eMMC on n900 with device tree
Looks like we need to configure the regulators and use the pdata
quirk to make eMMC work with device tree.
It seems that mostly vmmc2 is used, and only some earlier revisions
like the macro board used vaux3.
Note that we can add support for the macro board later as needed
by including the common n900 .dts file and configuring the vaux3
instead of vmmc2, and adding support for the smc91x Ethernet.
Cc: devicet...@vger.kernel.org
Cc: Pavel Machek
Cc: Aaro Koskinen
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
Can you guys please test this on production n900 devices?
I've tested it with my old macro board where I had to patch in vaux3
instead of vmmc2. I think there's some confusion in the legacy code
comments, or else I'm confused. In any case, vaux3 works for the macro
board, and I suspect that the production versions have vmmc2.
If this does not work and vaux3 as regulator works, please also dump
out the system_rev from your board.
---
arch/arm/boot/dts/omap3-n900.dts | 6 +-
arch/arm/mach-omap2/pdata-quirks.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c4f20bf..392ced2 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -359,7 +359,11 @@
};
&mmc2 {
- status = "disabled";
+ /* most boards use vmmc2, only the macro boards use vaux3 */
+ vmmc-supply = <&vmmc2>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+ non-removable;
};
&mmc3 {
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 10c7145..39f020c 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -139,6 +139,7 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
+ { "nokia,omap3-n900", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n9", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
{ "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
--
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: OMAP2+: Fix more missing data for omap3.dtsi file
After dropping the duplicate data in hwmod that now should come from
the .dts files, I noticed few more entries missing. Let's add these
as otherwise devices relying on these won't work.
Looks like the side tone entries are bundled into the mcbsp1 to 3,
so that may needs some special handling in the hwmod code as it's
currently trying to look up mcbsp2_sidetone and mcbsp3_sidetone
entries.
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap3.dtsi | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f3a0c26..daabf99 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -82,6 +82,13 @@
ranges;
ti,hwmods = "l3_main";
+ aes: aes@480c5000 {
+ compatible = "ti,omap3-aes";
+ ti,hwmods = "aes";
+ reg = <0x480c5000 0x50>;
+ interrupts = <0>;
+ };
+
counter32k: counter@4832 {
compatible = "ti,omap-counter32k";
reg = <0x4832 0x20>;
@@ -260,6 +267,13 @@
ti,hwmods = "i2c3";
};
+ mailbox: mailbox@48094000 {
+ compatible = "ti,omap3-mailbox";
+ ti,hwmods = "mailbox";
+ reg = <0x48094000 0x200>;
+ interrupts = <26>;
+ };
+
mcspi1: spi@48098000 {
compatible = "ti,omap2-mcspi";
reg = <0x48098000 0x100>;
@@ -357,6 +371,13 @@
dma-names = "tx", "rx";
};
+ mmu_isp: mmu@480bd400 {
+ compatible = "ti,omap3-mmu-isp";
+ ti,hwmods = "mmu_isp";
+ reg = <0x480bd400 0x80>;
+ interrupts = <8>;
+ };
+
wdt2: wdt@48314000 {
compatible = "ti,omap3-wdt";
reg = <0x48314000 0x80>;
@@ -442,6 +463,27 @@
dma-names = "tx", "rx";
};
+ sham: sham@480c3000 {
+ compatible = "ti,omap3-sham";
+ ti,hwmods = "sham";
+ reg = <0x480c3000 0x64>;
+ interrupts = <49>;
+ };
+
+ smartreflex_core: smartreflex@480cb000 {
+ compatible = "ti,omap3-smartreflex-core";
+ ti,hwmods = "smartreflex_core";
+ reg = <0x480cb000 0x400>;
+ interrupts = <19>;
+ };
+
+ smartreflex_mpu_iva: smartreflex@480c9000 {
+ compatible = "ti,omap3-smartreflex-iva";
+ ti,hwmods = "smartreflex_mpu_iva";
+ reg = <0x480c9000 0x400>;
+ interrupts = <18>;
+ };
+
timer1: timer@48318000 {
compatible = "ti,omap3430-timer";
reg = <0x48318000 0x400>;
--
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
Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On 11/21/2013 11:36 AM, Mark Brown wrote: > On Thu, Nov 21, 2013 at 09:43:03AM -0700, Stephen Warren wrote: > >> FYI, the way I deal with this is that my preferred email account >> subscribes to the mailing list, and I have a filter such that >> anything that's to/cc either *that* email address *or* any of my >> other email addresses gets handled the same, and dumped in my >> (list) inbox rather than in a mailing list folder. > > I used to do that but I found it tended to create annoying > duplicates more often than it was helpful. It's also a bit of an > issue for me that there are other people with the same name who > work upstream so I do also find people from time to time picking > the wrong Mark Brown to e-mail. Ah yes. I also have a delivery-time filter that remembers the last n Message-Id headers I've received, and it dumps any duplicates into a separate folder that I ignore. It seems to work pretty well. It looks like n==1 for me right now. I could post the scripts on github if people think they're useful. Hopefully there aren't security bugs:-) -- 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] usb: phy: am335x: Prevent GPIO reset line request
On Thu, Nov 21, 2013 at 08:55:20AM -0300, Ezequiel Garcia wrote: > On Thu, Nov 21, 2013 at 12:44:51PM +0100, Sebastian Andrzej Siewior wrote: > > On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: > > > Ah, good to know. That patch should be picked ASAP, without it the USB > > > in AM335x is broken. Is it already too late to -rc1? > > Yes. > > > > > Who is supposed to merge that? Greg? > > > > Felipe will start collecting fixes once -rc1 is out [0] so it should be > > part of -rc2. > > > > OK, fine by me. Please note that Felipe's commit is a much bigger (and > nicer) rework of the code, and that it doesn't clearly state it fixes > the current code. > > Felipe: Maybe you should add some message stating it fixes a regression? sure, makes sense. Sebastian had already mentioned it sounded too nice of a commit log ;-) -- balbi signature.asc Description: Digital signature
[PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx
pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.
Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins
56x
SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.
Signed-off-by: Balaji T K
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 298e850..88c6a05 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -246,15 +246,6 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
-};
-
-&omap4_pmx_wkup {
- led_wkgpio_pins: pinmux_leds_wkpins {
- pinctrl-single,pins = <
- 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
- 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
- >;
- };
/*
* wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP
@@ -274,7 +265,7 @@
pinctrl-single,pins = <
0x38 (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs2.gpio_52 */
0x3a (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs3.gpio_53 */
- 0x108 (PIN_OUTPUT | MUX_MODE0) /*
sdmmc5_clk.sdmmc5_clk */
+ 0x108 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_clk.sdmmc5_clk */
0x10a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_cmd.sdmmc5_cmd */
0x10c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat0.sdmmc5_dat0 */
0x10e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat1.sdmmc5_dat1 */
@@ -284,6 +275,15 @@
};
};
+&omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ >;
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: omap4-sdp: Fix pin muxing for wl12xx
Mux mode for wlan/sdmmc5 should be MODE0 in pinmux_wl12xx_pins and
Enable Pull up on sdmmc5_clk to detect SDIO card.
Signed-off-by: Balaji T K
---
arch/arm/boot/dts/omap4-sdp.dts | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43..dbc81fb 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -300,12 +300,12 @@
wl12xx_pins: pinmux_wl12xx_pins {
pinctrl-single,pins = <
0x3a (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs3.gpio_53 */
- 0x108 (PIN_OUTPUT | MUX_MODE3) /*
sdmmc5_clk.sdmmc5_clk */
- 0x10a (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_cmd.sdmmc5_cmd */
- 0x10c (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat0.sdmmc5_dat0 */
- 0x10e (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat1.sdmmc5_dat1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat2.sdmmc5_dat2 */
- 0x112 (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat3.sdmmc5_dat3 */
+ 0x108 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_clk.sdmmc5_clk */
+ 0x10a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_cmd.sdmmc5_cmd */
+ 0x10c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat0.sdmmc5_dat0 */
+ 0x10e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat1.sdmmc5_dat1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat2.sdmmc5_dat2 */
+ 0x112 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat3.sdmmc5_dat3 */
>;
};
};
--
1.7.5.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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On Thu, Nov 21, 2013 at 09:43:03AM -0700, Stephen Warren wrote: > FYI, the way I deal with this is that my preferred email account > subscribes to the mailing list, and I have a filter such that anything > that's to/cc either *that* email address *or* any of my other email > addresses gets handled the same, and dumped in my (list) inbox rather > than in a mailing list folder. I used to do that but I found it tended to create annoying duplicates more often than it was helpful. It's also a bit of an issue for me that there are other people with the same name who work upstream so I do also find people from time to time picking the wrong Mark Brown to e-mail. signature.asc Description: Digital signature
Re: [RFC PATCH v3 6/8] ARM: dts: add pbias-supply
* Balaji T K [131121 06:21]:
> Add pbias-supply to mmc1/sd card.
...
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -261,6 +261,7 @@
> &mmc1 {
> status = "okay";
> vmmc-supply = <&ldo1_reg>;
> + pbias-supply = <&pbias_regulator>;
> bus-width = <4>;
> };
You may not need to patch this in at all. I think the PBIAS is there
only for the first slot and it's hardwired so it's always there. If
that's the case, then you can just always request it. Or use the
compatible flag if needed.
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
[RFC PATCH v3 4/8] mmc: omap_hsmmc: adapt hsmmc to use pbias regulator
In DT case, PBAIS registers are programmed via regulator,
use regulator APIs to control PBIAS.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 342be25..0a390f8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -126,6 +126,10 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAME"omap_hsmmc"
+#define VDD_1V8180 /* 18 uV */
+#define VDD_3V0300 /* 30 uV */
+#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -164,6 +168,8 @@ struct omap_hsmmc_host {
*/
struct regulator *vcc;
struct regulator *vcc_aux;
+ struct regulator *pbias;
+ boolpbias_enabled;
int pbias_disable;
void__iomem *base;
resource_size_t mapbase;
@@ -272,6 +278,15 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
+ if (host->pbias) {
+ if (host->pbias_enabled == 1) {
+ ret = regulator_disable(host->pbias);
+ if (!ret)
+ host->pbias_enabled = 0;
+ }
+ regulator_set_voltage(host->pbias, VDD_3V0, VDD_3V0);
+ }
+
/*
* Assume Vcc regulator is used only to power the card ... OMAP
* VDDS is used to power the pins, optionally with a transceiver to
@@ -306,9 +321,29 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
}
}
+ if (host->pbias) {
+ if (vdd <= VDD_165_195)
+ ret = regulator_set_voltage(host->pbias, VDD_1V8,
+ VDD_1V8);
+ else
+ ret = regulator_set_voltage(host->pbias, VDD_3V0,
+ VDD_3V0);
+ if (ret < 0)
+ goto error_set_power;
+
+ if (host->pbias_enabled == 0) {
+ ret = regulator_enable(host->pbias);
+ if (!ret) {
+ host->pbias_enabled = 1;
+ goto error_set_power;
+ }
+ }
+ }
+
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
+error_set_power:
return ret;
}
@@ -342,6 +377,9 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
reg = devm_regulator_get_optional(host->dev, "vmmc_aux");
host->vcc_aux = IS_ERR(reg) ? NULL : reg;
+ reg = devm_regulator_get_optional(host->dev, "pbias");
+ host->pbias = IS_ERR(reg) ? NULL : reg;
+
/* For eMMC do not power off when not in sleep state */
if (mmc_slot(host).no_regulator_off_init)
return 0;
@@ -1808,6 +1846,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->base = ioremap(host->mapbase, SZ_4K);
host->power_mode = MMC_POWER_OFF;
host->next_data.cookie = 1;
+ host->pbias_enabled = 0;
platform_set_drvdata(pdev, host);
--
1.7.5.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
[RFC PATCH v3 1/8] mmc: omap_hsmmc: use devm_regulator API
Use devm_regulator API, while at it use
devm_regulator_get_optional for optional vmmc_aux supply
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..1eb4350 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -316,7 +316,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
struct regulator *reg;
int ocr_value = 0;
- reg = regulator_get(host->dev, "vmmc");
+ reg = devm_regulator_get(host->dev, "vmmc");
if (IS_ERR(reg)) {
dev_err(host->dev, "vmmc regulator missing\n");
return PTR_ERR(reg);
@@ -336,7 +336,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
}
/* Allow an aux regulator */
- reg = regulator_get(host->dev, "vmmc_aux");
+ reg = devm_regulator_get_optional(host->dev, "vmmc_aux");
host->vcc_aux = IS_ERR(reg) ? NULL : reg;
/* For eMMC do not power off when not in sleep state */
@@ -366,8 +366,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
{
- regulator_put(host->vcc);
- regulator_put(host->vcc_aux);
mmc_slot(host).set_power = NULL;
}
--
1.7.5.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
[RFC PATCH v3 8/8] mmc: omap_hsmmc: remove pbias workaround
remove pbias workaround
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0a390f8..0f0aa5d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -170,7 +170,6 @@ struct omap_hsmmc_host {
struct regulator *vcc_aux;
struct regulator *pbias;
boolpbias_enabled;
- int pbias_disable;
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
@@ -267,13 +266,6 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
*/
if (!host->vcc)
return 0;
- /*
-* With DT, never turn OFF the regulator for MMC1. This is because
-* the pbias cell programming support is still missing when
-* booting with Device tree
-*/
- if (host->pbias_disable && !vdd)
- return 0;
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -1541,13 +1533,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* of external transceiver; but they all handle 1.8V.
*/
if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
- (ios->vdd == DUAL_VOLT_OCR_BIT) &&
- /*
-* With pbias cell programming missing, this
-* can't be allowed on MMC1 when booting with device
-* tree.
-*/
- !host->pbias_disable) {
+ (ios->vdd == DUAL_VOLT_OCR_BIT)) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
@@ -1880,10 +1866,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_context_save(host);
- /* This can be removed once we support PBIAS with DT */
- if (host->dev->of_node && res->start == 0x4809c000)
- host->pbias_disable = 1;
-
host->dbclk = clk_get(&pdev->dev, "mmchsdb_fck");
/*
* MMC can still work without debounce clock.
--
1.7.5.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
[RFC PATCH v3 7/8] ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig
Enable REGULATOR_PBIAS needed for SD card on most OMAPs. Signed-off-by: Balaji T K --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 98a50c3..06c6404 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -169,6 +169,7 @@ CONFIG_DRA752_THERMAL=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y @@ -179,6 +180,7 @@ CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y +CONFIG_REGULATOR_PBIAS=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 1.7.5.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
безразлично какая синьора увидит Оргазм
*This message was transferred with a trial version of CommuniGate(r) Pro* Хотите быть замечательнейшим любовником? http://goo.gl/QoAv7K -- 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/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx
* Balaji T K [131121 05:51]: > pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core > and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core. > > Fix the following error message: > pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38) > pinctrl-single 4a31e040.pinmux: could not add functions for > pinmux_wl12xx_pins 56x > > SDIO card is not detected after moving pin mux to omap4_pmx_core since > sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card. Cool, does this fix the issue with the WLAN not coming up after a warm reset on panda? 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: [PATCHv5 10/20] arm: dts: add omap4430 thermal data
On 20-11-2013 08:32, Pavel Machek wrote:
> HI!
>
>> This patch changes the dtsi entry on omap4430 to contain
>> the thermal data. This data will enable the passive
>> cooling with CPUfreq cooling device at 100C and the
>> system will do a thermal shutdown at 125C.
>>
>> Cc: "Benoît Cousson"
>> Cc: Tony Lindgren
>> Cc: Russell King
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-ker...@vger.kernel.org
>> Signed-off-by: Eduardo Valentin
>> ---
>> arch/arm/boot/dts/omap443x.dtsi | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap443x.dtsi
>> b/arch/arm/boot/dts/omap443x.dtsi
>> index bcf455e..e9c97d6 100644
>> --- a/arch/arm/boot/dts/omap443x.dtsi
>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>> @@ -12,7 +12,7 @@
>>
>> / {
>> cpus {
>> -cpu@0 {
>> +cpu0: cpu@0 {
>> /* OMAP443x variants OPP50-OPPNT */
>> operating-points = <
>> /* kHzuV */
>
> I see you also add labels to various other entries...
I think I didn't quite get your point here. Can you please elaborate?
This label has been added because it will be used in thermal zone while
referencing the cooling device.
>
>> @@ -25,9 +25,15 @@
>> };
>> };
>>
>> -bandgap {
>> +thermal-zones{
>
> You may want to include space here.
OK.
>
>> +#include "omap4-cpu-thermal.dtsi"
>> +};
>> +
>> +bandgap: bandgap {
>> reg = <0x4a002260 0x4
>> 0x4a00232C 0x4>;
>> compatible = "ti,omap4430-bandgap";
>> +
>> +#thermal-sensor-cells = <0>;
>> };
>> };
>
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx
On 11/21/2013 10:58 AM, Tony Lindgren wrote: > * Balaji T K [131121 05:51]: >> pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core >> and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core. >> >> Fix the following error message: >> pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38) >> pinctrl-single 4a31e040.pinmux: could not add functions for >> pinmux_wl12xx_pins 56x Why is the led pins moved then? >> SDIO card is not detected after moving pin mux to omap4_pmx_core since >> sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO >> card. > Cool, does this fix the issue with the WLAN not coming up after a warm reset > on panda? > > 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 -- -- Dan Murphy -- 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 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
On Thursday 21 November 2013 05:07 PM, Andreas Fenkart wrote: 2013/11/19 Tony Lindgren : * Balaji T K [131119 08:00]: On Tuesday 19 November 2013 09:19 PM, Tony Lindgren wrote: * Balaji T K [131118 08:23]: few params were passed via platform data in non-DT case and never cached in internal data structure, with non-dt support going away soon, I am planning to cleanup pdata usage in the driver when it gets to DT only support. The issue of pdata tinkering needs to be fixed first as it will cause nasty issues when the module is reprobed. Agree that pdata usage needs to be fixed, but currently module reprobe is working fine. OK. The sdio_irq should be just set in struct omap_hsmmc_host instead. agree, sdio_irq should be cached in struct omap_hsmmc_host Note that it's still possible to pass platform data in the device tree case as auxdata. And we probably need to do that for the pbias register handling until we have a driver for that. Talking of the pbias driver, any news on it? Almost there, will post the patches soon. Do you have a branch with updated board files, for me to base pbias patches on else I can base the patches on rc1 too. Great. How about make the pbias driver DT only? Let's not touch the board-*.c files any longer as those will be going away for v3.14. We can probably keep the old callback support in place also, and then remove it for v3.15. Is there a dependency on the patches from Balaji or can the SDIO IRQ patches go in already? Hi Andreas, I could get sdio interrupt working on AM335x, will do more testing and get back to you. Pbias shouldn't have create any dependency. Just add sdio_irq to struct omap_hsmmc_host as suggested by Tony. Thanks and Regards, Balaji T K And after that it would certainly make sense to rip out the platform data fomr hsmmc driver just to get rid of the legacy support for multiplexing slots that's not needed in this driver. That would allow replacing all mmc->slots[0] accesses with something more standard. rgds, Andi -- 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] usb: phy: am335x: Prevent GPIO reset line request
On Thu, Nov 21, 2013 at 12:44:51PM +0100, Sebastian Andrzej Siewior wrote: > On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: > > Ah, good to know. That patch should be picked ASAP, without it the USB > > in AM335x is broken. Is it already too late to -rc1? > Yes. > > > Who is supposed to merge that? Greg? > > Felipe will start collecting fixes once -rc1 is out [0] so it should be > part of -rc2. > OK, fine by me. Please note that Felipe's commit is a much bigger (and nicer) rework of the code, and that it doesn't clearly state it fixes the current code. Felipe: Maybe you should add some message stating it fixes a regression? Just a suggestion though... -- 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] usb: phy: am335x: Prevent GPIO reset line request
On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: > Ah, good to know. That patch should be picked ASAP, without it the USB > in AM335x is broken. Is it already too late to -rc1? Yes. > Who is supposed to merge that? Greg? Felipe will start collecting fixes once -rc1 is out [0] so it should be part of -rc2. [0] This was his work flow for the last couple cycles, I assume he will continue. Sebastian -- 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 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
2013/11/19 Tony Lindgren : > * Balaji T K [131119 08:00]: >> On Tuesday 19 November 2013 09:19 PM, Tony Lindgren wrote: >> >* Balaji T K [131118 08:23]: >> >> >> >>few params were passed via platform data in non-DT case and never cached >> >>in internal data structure, with non-dt support going away soon, I am >> >>planning to cleanup pdata usage in the driver when it gets to DT only >> >>support. >> > >> >The issue of pdata tinkering needs to be fixed first as it will cause nasty >> >issues when the module is reprobed. >> >> Agree that pdata usage needs to be fixed, but currently module >> reprobe is working fine. > > OK. The sdio_irq should be just set in struct omap_hsmmc_host instead. > >> >Note that it's still possible to pass platform data in the device tree case >> >as auxdata. And we probably need to do that for the pbias register handling >> >until we have a driver for that. >> > >> >Talking of the pbias driver, any news on it? >> >> Almost there, will post the patches soon. >> Do you have a branch with updated board files, for me to base pbias patches >> on >> else I can base the patches on rc1 too. > > Great. How about make the pbias driver DT only? Let's not touch the board-*.c > files any longer as those will be going away for v3.14. We can probably keep > the old callback support in place also, and then remove it for v3.15. Is there a dependency on the patches from Balaji or can the SDIO IRQ patches go in already? > > And after that it would certainly make sense to rip out the platform data > fomr hsmmc driver just to get rid of the legacy support for multiplexing slots > that's not needed in this driver. That would allow replacing all mmc->slots[0] > accesses with something more standard. > rgds, Andi -- 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] usb: phy: am335x: Prevent GPIO reset line request
On Thu, Nov 21, 2013 at 09:16:40AM +0100, Sebastian Andrzej Siewior wrote: > On 11/20/2013 11:02 PM, Ezequiel Garcia wrote: > > (Forgot to Cc OMAP people) > > Felipe posted a redo of this area to fix this problem a while back. See > http://www.spinics.net/lists/linux-usb/msg97286.html > Ah, good to know. That patch should be picked ASAP, without it the USB in AM335x is broken. Is it already too late to -rc1? Who is supposed to merge that? Greg? -- 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 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
> Here Tony, you can take this one. > > I will simply apply my other fixes on top of it. > > The issue is, I will most likely have to rebase it on top of -rc1 prior > to sending a request to Linus, so in that regard it's not exactly > immutable. > Ignore the above. This is what you want: The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52: Linux 3.12 (2013-11-03 15:41:51 -0800) are available in the git repository at: git://git.linaro.org/people/ljones/mfd.git tags/ib-tony for you to fetch changes up to f984370913d3ba5d13806cc8ac6fc26f8ebd1694: mfd: twl-core: Fix passing of platform data in the device tree case (2013-11-21 10:42:36 +) warning: refname 'ib-tony' is ambiguous. Immutable branch for Tony Lindgren Tony Lindgren (1): mfd: twl-core: Fix passing of platform data in the device tree case drivers/mfd/twl-core.c | 15 --- 1 file changed, 12 insertions(+), 3 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: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC
On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote: > actually, I didn't miss you at all. your broo...@linaro.org was in Cc > of original email thread. The same email which was used to sign-off on > original commit. It's not what's advertised in MAINTAINERS, you should be sending stuff to that address. My work account is completely separate and for various reasons (including the fact that a lot of the mails for upstream sent there are duplicates of mails sent here) non-automatic upstream stuff has a good chance of getting dropped on the floor and at the very least will be dealt with more slowly. signature.asc Description: Digital signature
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
On Mon, 18 Nov 2013, Tony Lindgren wrote: > * Lee Jones [131118 11:10]: > > > > Are you Acking this patch by the way? > > > > > > If this looks acceptable to you guys, I'd like to merge this via my fixes > > > branch this week with your acks if that works for you. That way I can base > > > my omap legacy platform data removal patches on my fixes branch while keep > > > things working for the drivers. Alternatively I can naturally base my > > > legacy data removal on -rc2 too if this gets merged to mainline by then > > > via the MFD tree. > > > > I can either send it up for the -rcs, or I can create an immutable > > branch for you to pull from. That way the patch can do in via ARM-SoC > > and MFD and we can let Git sort it out. > > OK great, I'd prefer an immutable branch that I can merge in too. Then > you can bundle it with other MFD fixes for the -rc series and send it > in when it suits you :) https://git.linaro.org/gitweb?p=people/ljones/mfd.git;a=shortlog;h=refs/heads/for-mfd-fixes Here Tony, you can take this one. I will simply apply my other fixes on top of it. The issue is, I will most likely have to rebase it on top of -rc1 prior to sending a request to Linus, so in that regard it's not exactly immutable. -- 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] usb: phy: am335x: Prevent GPIO reset line request
On 11/20/2013 11:02 PM, Ezequiel Garcia wrote: > (Forgot to Cc OMAP people) Felipe posted a redo of this area to fix this problem a while back. See http://www.spinics.net/lists/linux-usb/msg97286.html Sebastian -- 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
