Nokia n900 problems in 3.18-rc1 (was Re: USB Ethernet gadget on Nokia n900)
Hi!
Here's a patch that should fix the issues for built-in USB
gadgets.
Pavel, care to see if this gets NFSroot over USB working again
for you?
It seems to have did the trick for me. (Plus I needed to add
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
to be able to control the command line, that's why testing took me a
while.)
Hmm I think I have a patch somewhere here to enable the standard
bootz command for n900 mainline u-boot.. That way you can just do
# bootz ${loadaddr} - ${fdtaddr}
Actually, I guess booting directly from ROM using 0x is easier for
testing for now.
Speaking of testing:
I'm not sure what is omap_l3_smx neccessary for, but it does not work.
[0.223297] omap_l3_smx omap_l3_smx.0: couldn't request debug irq
[0.223419] omap_l3_smx: probe of omap_l3_smx.0 failed with error
-22
There is some fun in pinmuxing:
[0.247131] irq: no irq domain found for /ocp/pinmux@48002030 !
[0.248291] irq: no irq domain found for /ocp/pinmux@48002030 !
...
[0.384826] omap_i2c 4807.i2c: could not find pctldev for node
/ocp/pinmux@48002030/pinmux_i\
2c1_pins, deferring probe
[0.384918] platform 4807.i2c: Driver omap_i2c requests probe
deferral
[0.385070] omap_i2c 48072000.i2c: could not find pctldev for node
/ocp/pinmux@48002030/pinmux_i\
2c2_pins, deferring probe
[0.385162] platform 48072000.i2c: Driver omap_i2c requests probe
deferral
[0.385284] omap_i2c 4806.i2c: could not find pctldev for node
/ocp/pinmux@48002030/pinmux_i\
2c3_pins, deferring probe
[0.385375] platform 4806.i2c: Driver omap_i2c requests probe
deferral
And serial has some problems:
[0.482208] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp/serial@4806c\
000[0]'
[0.482513] omap_uart 4806c000.serial: ttyO1 at MMIO 0x4806c000
(irq = 223, base_baud = 300)\
is a OMAP UART1
[0.484588] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp/serial@49020\
000[0]'
[0.484771] omap_uart 4902.serial: ttyO2 at MMIO 0x4902
(irq = 224, base_baud = 300)\
is a OMAP UART2
There's a lot of noise from probe defferal :-(. And it looks like mmc
properties have some problems:
[0.739349] of_get_named_gpiod_flags: can't parse 'wp-gpios'
property of node '/ocp/mmc@4809c000\
[0]'
[0.740142] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator
-517
[0.740386] platform 4809c000.mmc: Driver omap_hsmmc requests probe
deferral
[0.740661] of_get_named_gpiod_flags: can't parse 'cd-gpios'
property of node '/ocp/mmc@480b4000\
[0]'
[0.740692] of_get_named_gpiod_flags: can't parse 'wp-gpios'
property of node '/ocp/mmc@480b4000\
[0]'
omapfb reports problems, but seems to work ok:
[0.990386] omapfb omapfb: cannot parse default modes
[1.004791] Console: switching to colour frame buffer device 100x30
[1.073150] omapfb omapfb: using display 'lcd' mode 800x480
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH 1/5] ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg()
On 10/29/2014 12:23 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [141021 05:43]: Simplify set_gpmc_timing_reg() and always print error message if the requested timing cannot be achieved due to a too fast GPMC functional clock, irrespective if whether DEBUG is defined or not. This should help us debug timing configuration issues, which were otherwise simply not being displayed in the kernel log. I think some newer versions of GPMC have a divider in the GPMC_CONFIG regs somewhere but we're not currently using it. Probably does not affect this patch, just FYI. Right, we don't use it. In the future it could be a possibility that the GPMC driver scales the clock as necessary by using the GPMC_FCLK divider to accommodate slower devices. But then again, who needs slower devices? ;) cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/8] Enable L2 cache support on Exynos4210/4x12 SoCs
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
Depends on:
- [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs
(https://lkml.org/lkml/2014/8/26/445)
available in v3.19-next/pm-samsung branch in
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
Changelog:
Changes since v6:
(https://lkml.org/lkml/2014/10/27/233)
- changed PL310 to L2C-310 prefix in error messages
- added patch shortening the error message about incorrect associativity
Changes since v5:
(https://lkml.org/lkml/2014/9/24/364)
- rebased onto v3.18-rc2
- added error message about missing properties values
Changes since v4:
(https://lkml.org/lkml/2014/8/26/461)
- rewrote the code accessing l2x0_saved_regs from assembly code
- added comment and reworked unconditional call to SMC_CMD_L2X0INVALL
Patch summary:
Marek Szyprowski (1):
ARM: l2c: unify L2C-310 OF initialization error messages
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/firmware.c| 50 +
arch/arm/mach-exynos/sleep.S | 46 +
arch/arm/mm/cache-l2x0.c | 275 -
8 files changed, 312 insertions(+), 98 deletions(-)
--
1.9.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 v7 4/8] ARM: l2c: shorten warning about incorrect associativity
Warning message about missing/incorrect associativity was a bit too long, so shorten it to fit a single line. Suggested-by: Russell King - ARM Linux li...@arm.linux.org.uk Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/mm/cache-l2x0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index ad981894de73..83b36f3b415c 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -1200,8 +1200,8 @@ static void __init l2c310_of_parse(const struct device_node *np, *aux_mask = ~L2X0_AUX_CTRL_ASSOC_MASK; break; default: - pr_err(PL310 OF: cache setting yield illegal associativity\n); - pr_err(PL310 OF: %d calculated, only 8 and 16 legal\n, assoc); + pr_err(L2C-310 OF cache associativity %d invalid, only 8 or 16 permitted\n, + assoc); break; } } -- 1.9.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 v7 8/8] ARM: dts: exynos4: Add nodes for L2 cache controller
From: Tomasz Figa t.f...@samsung.com
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 536a747a8632..8b97f10f0926 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -64,6 +64,15 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 2 2 1;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 50b3c3f51e90..3e806d63e8bb 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -54,6 +54,20 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 3 2 1;
+ arm,double-linefill = 1;
+ arm,double-linefill-incr = 0;
+ arm,double-linefill-wrap = 1;
+ arm,prefetch-drop = 1;
+ arm,prefetch-offset = 7;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.9.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 v7 2/8] ARM: l2c: Add interface to ask hypervisor to configure L2C
From: Tomasz Figa t.f...@samsung.com
Because certain secure hypervisor do not allow writes to individual L2C
registers, but rather expect set of parameters to be passed as argument
to secure monitor calls, there is a need to provide an interface for the
L2C driver to ask the firmware to configure the hardware according to
specified parameters. This patch adds such.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/include/asm/outercache.h | 3 +++
arch/arm/mm/cache-l2x0.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b35bcf..563b92fc2f41 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -23,6 +23,8 @@
#include linux/types.h
+struct l2x0_regs;
+
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
@@ -36,6 +38,7 @@ struct outer_cache_fns {
/* This is an ARM L2C thing */
void (*write_sec)(unsigned long, unsigned);
+ void (*configure)(const struct l2x0_regs *);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 4286ee9bb3bd..ad981894de73 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -110,6 +110,11 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
static void l2c_configure(void __iomem *base)
{
+ if (outer_cache.configure) {
+ outer_cache.configure(l2x0_saved_regs);
+ return;
+ }
+
if (l2x0_data-configure)
l2x0_data-configure(base);
@@ -910,6 +915,7 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
fns = data-outer_cache;
fns.write_sec = outer_cache.write_sec;
+ fns.configure = outer_cache.configure;
if (data-fixup)
data-fixup(l2x0_base, cache_id, fns);
--
1.9.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 v7 6/8] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
From: Tomasz Figa t.f...@samsung.com
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec and .configure callbacks is provided by this patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[added comment and reworked unconditional call to SMC_CMD_L2X0INVALL]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index f5e626d55951..e6a052c593f2 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -17,6 +17,7 @@
#include asm/cacheflush.h
#include asm/cputype.h
#include asm/firmware.h
+#include asm/hardware/cache-l2x0.h
#include asm/suspend.h
#include mach/map.h
@@ -120,6 +121,43 @@ static const struct firmware_ops exynos_firmware_ops = {
.resume = exynos_resume,
};
+static void exynos_l2_write_sec(unsigned long val, unsigned reg)
+{
+ static int l2cache_enabled;
+
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val L2X0_CTRL_EN) {
+ /*
+* Before the cache can be enabled, due to firmware
+* design, SMC_CMD_L2X0INVALL must be called.
+*/
+ if (!l2cache_enabled) {
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ l2cache_enabled = 1;
+ }
+ } else {
+ l2cache_enabled = 0;
+ }
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ default:
+ WARN_ONCE(1, %s: ignoring write to reg 0x%x\n, __func__, reg);
+ }
+}
+
+static void exynos_l2_configure(const struct l2x0_regs *regs)
+{
+ exynos_smc(SMC_CMD_L2X0SETUP1, regs-tag_latency, regs-data_latency,
+ regs-prefetch_ctrl);
+ exynos_smc(SMC_CMD_L2X0SETUP2, regs-pwr_ctrl, regs-aux_ctrl, 0);
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -139,4 +177,16 @@ void __init exynos_firmware_init(void)
pr_info(Running under secure firmware.\n);
register_firmware_ops(exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ outer_cache.write_sec = exynos_l2_write_sec;
+ outer_cache.configure = exynos_l2_configure;
+ }
}
--
1.9.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 v7 3/8] ARM: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL
From: Tomasz Figa t.f...@samsung.com
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 7c81ec428b9b..5acb8aef6f2d 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -108,7 +108,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_CACHE_L2X0)
(machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
- outer_cache.write_sec = machine_desc-l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc-l2c_write_sec;
ret = l2x0_of_init(machine_desc-l2c_aux_val,
machine_desc-l2c_aux_mask);
if (ret)
--
1.9.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 v7 1/8] ARM: l2c: Refactor the driver to use commit-like interface
From: Tomasz Figa t.f...@samsung.com
Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.
This patch is first step to make the driver not rely on availability of
writes to individual registers. This is achieved by refactoring the
driver to use a commit-like operation scheme: all register values are
prepared first and stored in an instance of l2x0_regs struct and then a
single callback is responsible to flush those values to the hardware.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mm/cache-l2x0.c | 210 ++-
1 file changed, 115 insertions(+), 95 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 55f9d6e0cc88..4286ee9bb3bd 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -41,12 +41,14 @@ struct l2c_init_data {
void (*enable)(void __iomem *, u32, unsigned);
void (*fixup)(void __iomem *, u32, struct outer_cache_fns *);
void (*save)(void __iomem *);
+ void (*configure)(void __iomem *);
struct outer_cache_fns outer_cache;
};
#define CACHE_LINE_SIZE32
static void __iomem *l2x0_base;
+static const struct l2c_init_data *l2x0_data;
static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
@@ -106,6 +108,14 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
}
}
+static void l2c_configure(void __iomem *base)
+{
+ if (l2x0_data-configure)
+ l2x0_data-configure(base);
+
+ l2c_write_sec(l2x0_saved_regs.aux_ctrl, base, L2X0_AUX_CTRL);
+}
+
/*
* Enable the L2 cache controller. This function must only be
* called when the cache controller is known to be disabled.
@@ -114,7 +124,12 @@ static void l2c_enable(void __iomem *base, u32 aux,
unsigned num_lock)
{
unsigned long flags;
- l2c_write_sec(aux, base, L2X0_AUX_CTRL);
+ /* Do not touch the controller if already enabled. */
+ if (readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)
+ return;
+
+ l2x0_saved_regs.aux_ctrl = aux;
+ l2c_configure(base);
l2c_unlock(base, num_lock);
@@ -208,6 +223,11 @@ static void l2c_save(void __iomem *base)
l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
}
+static void l2c_resume(void)
+{
+ l2c_enable(l2x0_base, l2x0_saved_regs.aux_ctrl, l2x0_data-num_lock);
+}
+
/*
* L2C-210 specific code.
*
@@ -288,14 +308,6 @@ static void l2c210_sync(void)
__l2c210_cache_sync(l2x0_base);
}
-static void l2c210_resume(void)
-{
- void __iomem *base = l2x0_base;
-
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN))
- l2c_enable(base, l2x0_saved_regs.aux_ctrl, 1);
-}
-
static const struct l2c_init_data l2c210_data __initconst = {
.type = L2C-210,
.way_size_0 = SZ_8K,
@@ -309,7 +321,7 @@ static const struct l2c_init_data l2c210_data __initconst =
{
.flush_all = l2c210_flush_all,
.disable = l2c_disable,
.sync = l2c210_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -466,7 +478,7 @@ static const struct l2c_init_data l2c220_data = {
.flush_all = l2c220_flush_all,
.disable = l2c_disable,
.sync = l2c220_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -615,39 +627,29 @@ static void __init l2c310_save(void __iomem *base)
L310_POWER_CTRL);
}
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)) {
- unsigned revision;
-
- /* restore pl310 setup */
- writel_relaxed(l2x0_saved_regs.tag_latency,
- base + L310_TAG_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.data_latency,
- base + L310_DATA_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.filter_end,
- base + L310_ADDR_FILTER_END);
- writel_relaxed(l2x0_saved_regs.filter_start,
- base + L310_ADDR_FILTER_START);
-
- revision = readl_relaxed(base + L2X0_CACHE_ID)
- L2X0_CACHE_ID_RTL_MASK;
-
- if (revision = L310_CACHE_ID_RTL_R2P0)
- l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
-
[PATCH v7 7/8] ARM: EXYNOS: Add support for non-secure L2X0 resume
From: Tomasz Figa t.f...@samsung.com On Exynos SoCs it is necessary to resume operation of L2C early in assembly code, because otherwise certain systems will crash. This patch adds necessary code to non-secure resume handler. Signed-off-by: Tomasz Figa t.f...@samsung.com [rewrote the code accessing l2x0_saved_regs] Sigend-off-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/mach-exynos/sleep.S | 46 1 file changed, 46 insertions(+) diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S index e3c373082bbe..31d25834b9c4 100644 --- a/arch/arm/mach-exynos/sleep.S +++ b/arch/arm/mach-exynos/sleep.S @@ -16,6 +16,8 @@ */ #include linux/linkage.h +#include asm/asm-offsets.h +#include asm/hardware/cache-l2x0.h #include smc.h #define CPU_MASK 0xff00 @@ -74,6 +76,45 @@ ENTRY(exynos_cpu_resume_ns) mov r0, #SMC_CMD_C15RESUME dsb smc #0 +#ifdef CONFIG_CACHE_L2X0 + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + /* Check that the address has been initialised. */ + ldr r1, [r0, #L2X0_R_PHY_BASE] + teq r1, #0 + beq skip_l2x0 + + /* Check if controller has been enabled. */ + ldr r2, [r1, #L2X0_CTRL] + tst r2, #0x1 + bne skip_l2x0 + + ldr r1, [r0, #L2X0_R_TAG_LATENCY] + ldr r2, [r0, #L2X0_R_DATA_LATENCY] + ldr r3, [r0, #L2X0_R_PREFETCH_CTRL] + mov r0, #SMC_CMD_L2X0SETUP1 + smc #0 + + /* Reload saved regs pointer because smc corrupts registers. */ + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + ldr r1, [r0, #L2X0_R_PWR_CTRL] + ldr r2, [r0, #L2X0_R_AUX_CTRL] + mov r0, #SMC_CMD_L2X0SETUP2 + smc #0 + + mov r0, #SMC_CMD_L2X0INVALL + smc #0 + + mov r1, #1 + mov r0, #SMC_CMD_L2X0CTRL + smc #0 +skip_l2x0: +#endif /* CONFIG_CACHE_L2X0 */ skip_cp15: b cpu_resume ENDPROC(exynos_cpu_resume_ns) @@ -83,3 +124,8 @@ cp15_save_diag: .globl cp15_save_power cp15_save_power: .long 0 @ cp15 power control + +#ifdef CONFIG_CACHE_L2X0 + .align +1: .long l2x0_saved_regs - . +#endif /* CONFIG_CACHE_L2X0 */ -- 1.9.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 v7 5/8] ARM: l2c: Add support for overriding prefetch settings
From: Tomasz Figa t.f...@samsung.com
Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
settings configured in registers leading to crashes if L2C is enabled
without overriding them. This patch introduces bindings to enable
prefetch settings to be specified from DT and necessary support in the
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[mszyprow: rebased onto v3.18-rc1, added error message when prefetch related
dt property has been provided without any value]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/mm/cache-l2x0.c | 55 ++
2 files changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index 292ef7ca3058..0dbabe9a6b0a 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -57,6 +57,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 83b36f3b415c..ae417ddb05ed 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1163,6 +1163,9 @@ static void __init l2c310_of_parse(const struct
device_node *np,
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
u32 assoc;
+ u32 prefetch;
+ u32 val;
+ int ret;
of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
if (tag[0] tag[1] tag[2])
@@ -1204,6 +1207,58 @@ static void __init l2c310_of_parse(const struct
device_node *np,
assoc);
break;
}
+
+ prefetch = l2x0_saved_regs.prefetch_ctrl;
+
+ ret = of_property_read_u32(np, arm,double-linefill, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-incr, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-incr property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-wrap, val);
+ if (ret == 0) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-wrap property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-drop, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-drop property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-offset, val);
+ if (ret == 0) {
+ prefetch = ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val L310_PREFETCH_CTRL_OFFSET_MASK;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-offset property value is
missing\n);
+ }
+
+ l2x0_saved_regs.prefetch_ctrl = prefetch;
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.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 v2] mtd: omap: fix mtd devices not showing up
On Tue, Oct 28, 2014 at 11:46:57AM +0200, Roger Quadros wrote: On 10/27/2014 04:34 PM, Frans Klaver wrote: Since commit 6d178ef2fd5e (mtd: nand: Move ELM driver and rename as omap_elm), I don't have any mtd devices present on my am335x. This changes the link order of the omap_elm and omap2 objects, causing them to probe in the wrong order. To fix this, make elm_config defer probing until the omap_elm driver is actually loaded. Signed-off-by: Frans Klaver frans.kla...@xsens.com Acked-by: Roger Quadros rog...@ti.com Thanks. How about Ezequiel's remark about doing both changes? Thanks, Frans -- 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 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Johan
--
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] rtc: omap: add support for pmic_power_en
On Tue, Oct 28, 2014 at 02:18:05PM -0700, Andrew Morton wrote: On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold jo...@kernel.org wrote: But it doesn't explain *why* we want the alarm to trigger before returning. Should we really require every power-off handler to document arch behaviour (even if its inconsistent and currently undocumented); in this case that some arches return to user-space where we may oops if called from process 0 (e.g. systemd, but not if using sysvinit)? The kernel really doesn't have a problem related to excessive amounts of useful code comments :( The bottom line is: did I provide a reader with the ability to understand why the code is this way? If no then improvements beckon. This does look like one code site where an elaborate explanation is warranted. There's no way in which a reader can get to your above paragraph from the current rtc-omap.c. I agree with you that I should add a comment on why that mdelay is there to make it perfectly clear and obvious that it's purpose is to let the alarm trigger, which in turn causes the pmic to power off the system. It is a power-off handler, and any power-off handler should not return until it has at least attempted to power off the system. In this case, that mandates a two-second delay. So far, so good. I don't agree with you that every power-off handler should document what happens if it fails to power-off the system. That is, to describe what arches will happily return to user space, and under what conditions (e.g. what init system is used) that this will cause a panic. If anything that belongs in arch code or kernel/reboot.c, and is also something that is likely to change over time (consider the power-off-handler call chains). Johan -- 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] rtc: omap: add support for pmic_power_en
On Tue, Oct 28, 2014 at 09:36:33AM +0100, Johan Hovold wrote: On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote: On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold jo...@kernel.org wrote: But in general, how do you want to handle updates to a single patch in a series you already have in your tree? Do you prefer a proper incremental-fix patch (with commit message), just an updated single patch, or a resend of the whole series? How should I best send the updated patch? Can you just replace the current three incremental patches: rtc-omap-add-support-for-pmic_power_en.patch rtc-omap-add-support-for-pmic_power_en-v3.patch rtc-omap-add-support-for-pmic_power_en-v3-fix.patch that you have in your tree, with a single new v4 which adds a more elaborate comment? Thanks, Johan -- 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 00/20] rtc: omap: fixes and power-off feature
Johan:. do you really plan to use this poweroff-source property ? As
you proposed a renaming few days ago...
I don't really want to waste time to propose patches to fix things
incrementally and rename it if the old one is used...
Romain
2014-10-29 13:34 GMT+01:00 Johan Hovold jo...@kernel.org:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Johan
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 00/20] rtc: omap: fixes and power-off feature
[ Please do not top-post. ] On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote: Johan:. do you really plan to use this poweroff-source property ? As you proposed a renaming few days ago... I don't really want to waste time to propose patches to fix things incrementally and rename it if the old one is used... Why would I want to use your retracted renaming proposal for this property (i.e. poweroff-source)? These patches use ti,system-power-controller and the vendor prefix will be dropped when your patches have been merged. Johan -- 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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
If the handler has determined that it has failed, then why delay before
trying the next handler? At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Today, ARM does exactly what x86 does. If there's no power off handler
registered, machine_power_off() shuts down other CPUs and returns.
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
Well, the biggest question there is: if the power off or restart syscall
fails, what is the _generic_ non-architecture action which is supposed to
happen?
Whatever the answer is to that question, that action should be performed
by the _generic_ non-architecture code, rather than having the same
implementation spread across all 30 architectures which the kernel
supports today.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Oh, systemd calls this from PID1? I guess that's another reason to hate
systemd with vitriol. :) SysVinit and upstart implementations call it
from the halt command, which is itself normally run from a script,
which totally avoids that problem.
I'm quite sure the insane systemd lobby will scream that this is a kernel
bug and will want to change it somehow, just like they want to change the
kernel in soo many other silly ways.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
This just to be sure, nothing more. I did read that you mentionned poweroff-source earlier. However If I am wrong, my bad, everything is fine. 2014-10-29 14:00 GMT+01:00 Johan Hovold jo...@kernel.org: [ Please do not top-post. ] On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote: Johan:. do you really plan to use this poweroff-source property ? As you proposed a renaming few days ago... I don't really want to waste time to propose patches to fix things incrementally and rename it if the old one is used... Why would I want to use your retracted renaming proposal for this property (i.e. poweroff-source)? These patches use ti,system-power-controller and the vendor prefix will be dropped when your patches have been merged. Johan -- 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 00/20] rtc: omap: fixes and power-off feature
On 10/29/2014 05:34 AM, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
Good that I just replaced notifier chain with an open coded implementation.
Sure, that is possible, but I would prefer to do that as a follow-up commit,
and it should be discussed in the context of the power-off handler patch set.
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
That delay would depend on the individual power-off handler, so I think
the current implementation works just fine (where power-off handlers
implement the delay).
We could move the delay into the infrastructure, but it would have
to be configurable. I would prefer to consider that as a follow-up patch
to not overload the power-off handler patch set with too many changes
at the same time.
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Common handling of that condition - eg to call machine_halt() - might be
an option. Separate patch, though.
Guenter
--
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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 01:10:20PM +, Russell King - ARM Linux wrote:
On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
If the handler has determined that it has failed, then why delay before
trying the next handler? At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?
The current handlers we have are not expecting any other handler to be
run after they return. My question was whether all these handlers should
get a short mdelay added to them (e.g. to compensate for bus latencies)
or if this could be done in the power-off handler (e.g. before printing
the error message).
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Today, ARM does exactly what x86 does. If there's no power off handler
registered, machine_power_off() shuts down other CPUs and returns.
No, if there are no power-off handlers registered, kernel/reboot.c will
never call machine_power_off:
/* Instead of trying to make the power_off code look like
* halt when pm_power_off is not set do it the easy way.
*/
if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) !pm_power_off)
cmd = LINUX_REBOOT_CMD_HALT;
So in that case on arm, a system-halted message is printed, and we never
return to user-space.
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
Well, the biggest question there is: if the power off or restart syscall
fails, what is the _generic_ non-architecture action which is supposed to
happen?
Whatever the answer is to that question, that action should be performed
by the _generic_ non-architecture code, rather than having the same
implementation spread across all 30 architectures which the kernel
supports today.
I fully agree.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Oh, systemd calls this from PID1? I guess that's another reason to hate
systemd with vitriol. :) SysVinit and upstart implementations call it
from the halt command, which is itself normally run from a script,
which totally avoids that problem.
Yeah, that's why I never noticed the missing mdelay.
I'm quite sure the insane systemd lobby will scream that this is a kernel
bug and will want to change it somehow, just like they want to change the
kernel in soo many other silly ways.
Will be interesting to follow. :)
Johan
--
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] mtd: omap: fix mtd devices not showing up
On 10/29/2014 01:36 PM, Frans Klaver wrote: On Tue, Oct 28, 2014 at 11:46:57AM +0200, Roger Quadros wrote: On 10/27/2014 04:34 PM, Frans Klaver wrote: Since commit 6d178ef2fd5e (mtd: nand: Move ELM driver and rename as omap_elm), I don't have any mtd devices present on my am335x. This changes the link order of the omap_elm and omap2 objects, causing them to probe in the wrong order. To fix this, make elm_config defer probing until the omap_elm driver is actually loaded. Signed-off-by: Frans Klaver frans.kla...@xsens.com Acked-by: Roger Quadros rog...@ti.com Thanks. How about Ezequiel's remark about doing both changes? I don't have any strong feeling for or against it. We shouldn't be depending on module load order anyways. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mtd: omap: fix mtd devices not showing up
On 10/29/2014 10:33 AM, Roger Quadros wrote: On 10/29/2014 01:36 PM, Frans Klaver wrote: On Tue, Oct 28, 2014 at 11:46:57AM +0200, Roger Quadros wrote: On 10/27/2014 04:34 PM, Frans Klaver wrote: Since commit 6d178ef2fd5e (mtd: nand: Move ELM driver and rename as omap_elm), I don't have any mtd devices present on my am335x. This changes the link order of the omap_elm and omap2 objects, causing them to probe in the wrong order. To fix this, make elm_config defer probing until the omap_elm driver is actually loaded. Signed-off-by: Frans Klaver frans.kla...@xsens.com Acked-by: Roger Quadros rog...@ti.com Thanks. How about Ezequiel's remark about doing both changes? I don't have any strong feeling for or against it. We shouldn't be depending on module load order anyways. Agreed, feel free to disregard my suggestion. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote: On 10/29/2014 05:34 AM, Johan Hovold wrote: On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote: On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote: That's not what I was trying to refer to. But the patch set explicitly allows for multiple, prioritised power-off handlers, which can power off a board in different ways and with various degrees of success. Specifically, it allows for fallback handlers in case one or more power-off handlers fail. So if we allow for that, what is to prevent the final power-off handler from failing? And should this not be logged by arch code in the same way as failure to restart is? And how is that different from having a set of power-off handlers, and reporting when each individual one fails? Don't you want to know if your primary high priority reboot handler fails, just as much as you want to know if your final last-resort power-off handler fails? Good point. Failed power-off should probably be logged by the power-off call chain implementation (which seems to makes notifier chains a bad fit). Good that I just replaced notifier chain with an open coded implementation. Good to hear. Sure, that is possible, but I would prefer to do that as a follow-up commit, and it should be discussed in the context of the power-off handler patch set. Fine with me. And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? That delay would depend on the individual power-off handler, so I think the current implementation works just fine (where power-off handlers implement the delay). Some don't, and could possibly unknowingly have been relying on the fact that they could return to user space and be powered off at some later time. With systemd that would have caused a panic. Also consider generic power-off handlers such as gpio-poweroff. It currently hard-codes a three-second delay but the actual delay would really be board specific. We could move the delay into the infrastructure, but it would have to be configurable. I would prefer to consider that as a follow-up patch to not overload the power-off handler patch set with too many changes at the same time. Sure. Johan -- 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On 10/28/2014 05:12 PM, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]: Hi, On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote: + + if (!of_have_populated_dt()) + pr_warn(WARNING: legacy booting deprecated, please update to boot with .dts\n); + Maybe use WARN so that the warning is more verbose and kernel gets tainted? Well I was hoping to avoid annoying people with the trace. But can do that if people prefer that, what do others think? WARN is better and eye catchy. Also, could we add information on when the support will be removed since we call it deprecated? -- 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 00/20] rtc: omap: fixes and power-off feature
[ Again, please stop with the top-posting. A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? ] On Wed, Oct 29, 2014 at 02:11:02PM +0100, Romain Perier wrote: This just to be sure, nothing more. I did read that you mentionned poweroff-source earlier. However If I am wrong, my bad, everything is fine. I only mentioned that you had proposed that name in my cover letter. Johan -- 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: Nokia n900 problems in 3.18-rc1 (was Re: USB Ethernet gadget on Nokia n900)
* Pavel Machek pa...@ucw.cz [141029 01:48]: Speaking of testing: I'm not sure what is omap_l3_smx neccessary for, but it does not work. [0.223297] omap_l3_smx omap_l3_smx.0: couldn't request debug irq [0.223419] omap_l3_smx: probe of omap_l3_smx.0 failed with error -22 Hmm this should be fixed to get interrupts about invalid bus access. There is some fun in pinmuxing: [0.247131] irq: no irq domain found for /ocp/pinmux@48002030 ! [0.248291] irq: no irq domain found for /ocp/pinmux@48002030 ! ... [0.384826] omap_i2c 4807.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c1_pins, deferring probe [0.384918] platform 4807.i2c: Driver omap_i2c requests probe deferral [0.385070] omap_i2c 48072000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c2_pins, deferring probe [0.385162] platform 48072000.i2c: Driver omap_i2c requests probe deferral [0.385284] omap_i2c 4806.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c3_pins, deferring probe [0.385375] platform 4806.i2c: Driver omap_i2c requests probe deferral These are related to deferred probe and should go away when we make drivers/i2c/busses/i2c-omap.c to use regular module_init and stop using subsys_initcall. But I think legacy booting still needs it early, could be omap1 only nowadays though. And serial has some problems: [0.482208] of_get_named_gpiod_flags: can't parse 'rts-gpio' property of node '/ocp/serial@4806c\ 000[0]' [0.482513] omap_uart 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 223, base_baud = 300)\ is a OMAP UART1 [0.484588] of_get_named_gpiod_flags: can't parse 'rts-gpio' property of node '/ocp/serial@49020\ 000[0]' [0.484771] omap_uart 4902.serial: ttyO2 at MMIO 0x4902 (irq = 224, base_baud = 300)\ is a OMAP UART2 I these come from the GPIO framework when booting with debug enabled. There's a lot of noise from probe defferal :-(. And it looks like mmc properties have some problems: [0.739349] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp/mmc@4809c000\ [0]' [0.740142] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [0.740386] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [0.740661] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/ocp/mmc@480b4000\ [0]' [0.740692] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp/mmc@480b4000\ [0]' These too. But yeah, I agree, let's try to patch away some of the deferred probe noise. omapfb reports problems, but seems to work ok: [0.990386] omapfb omapfb: cannot parse default modes [1.004791] Console: switching to colour frame buffer device 100x30 [1.073150] omapfb omapfb: using display 'lcd' mode 800x480 Tomi, is the default mode warning correct here? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg()
* Roger Quadros rog...@ti.com [141029 01:51]: On 10/29/2014 12:23 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [141021 05:43]: Simplify set_gpmc_timing_reg() and always print error message if the requested timing cannot be achieved due to a too fast GPMC functional clock, irrespective if whether DEBUG is defined or not. This should help us debug timing configuration issues, which were otherwise simply not being displayed in the kernel log. I think some newer versions of GPMC have a divider in the GPMC_CONFIG regs somewhere but we're not currently using it. Probably does not affect this patch, just FYI. Right, we don't use it. In the future it could be a possibility that the GPMC driver scales the clock as necessary by using the GPMC_FCLK divider to accommodate slower devices. But then again, who needs slower devices? ;) I think some devices need such slow timings that we're already hitting the issue with 200MHz L3 on 37xx connected to a SMSC LAN9220 at least. With LAN9221 this is not an issue with faster timings. Anyways, I think the issue is out of the way now with LAN9220 and GPMC_FCLK divider support can be added later on as 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
Re: Nokia n900 problems in 3.18-rc1 (was Re: USB Ethernet gadget on Nokia n900)
On 29/10/14 16:09, Tony Lindgren wrote:
omapfb reports problems, but seems to work ok:
[0.990386] omapfb omapfb: cannot parse default modes
[1.004791] Console: switching to colour frame buffer device 100x30
[1.073150] omapfb omapfb: using display 'lcd' mode 800x480
Tomi, is the default mode warning correct here?
omapfb warns that it couldn't parse kernel cmdline parameters
('omapfb.mode' parameter). I couldn't find in the thread what actual
parameters were used in this case.
Although I don't see why N900 would need any omapfb mode parameters in
the first place, as the LCD has just one mode...
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote: On Wed, Oct 29, 2014 at 01:10:20PM +, Russell King - ARM Linux wrote: On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote: On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote: And how is that different from having a set of power-off handlers, and reporting when each individual one fails? Don't you want to know if your primary high priority reboot handler fails, just as much as you want to know if your final last-resort power-off handler fails? Good point. Failed power-off should probably be logged by the power-off call chain implementation (which seems to makes notifier chains a bad fit). And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? If the handler has determined that it has failed, then why delay before trying the next handler? At the point it has decided it has failed, surely that's after it has waited sufficient time to determine that failure? The current handlers we have are not expecting any other handler to be run after they return. My question was whether all these handlers should get a short mdelay added to them (e.g. to compensate for bus latencies) Some of them do add a delay. or if this could be done in the power-off handler (e.g. before printing the error message). That might make sense, but it would have to be configurable, since the delay is platform specific and power-off handler does not know how long to wait (the longest delay I have seen is 10 seconds). Or different from having no power-off handlers. That is actually quite different, as in that case we call machine_halt instead (via kernel_halt). Today, ARM does exactly what x86 does. If there's no power off handler registered, machine_power_off() shuts down other CPUs and returns. No, if there are no power-off handlers registered, kernel/reboot.c will never call machine_power_off: /* Instead of trying to make the power_off code look like * halt when pm_power_off is not set do it the easy way. */ if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) !pm_power_off) cmd = LINUX_REBOOT_CMD_HALT; So in that case on arm, a system-halted message is printed, and we never return to user-space. Some architectures do that, or go into an endless loop. Others do return from machine_power_off. Having a well defined behavior would be nice (such as dumping an error mesasge and calling machine_halt if machine_power_off returns). Only question would be where to put it. kernel_power_off() might be a good place; only problem is that there are direct callers of machine_power_off(). Guenter -- 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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 02:35:26PM +0100, Johan Hovold wrote: On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote: On 10/29/2014 05:34 AM, Johan Hovold wrote: On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote: On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote: That's not what I was trying to refer to. But the patch set explicitly allows for multiple, prioritised power-off handlers, which can power off a board in different ways and with various degrees of success. Specifically, it allows for fallback handlers in case one or more power-off handlers fail. So if we allow for that, what is to prevent the final power-off handler from failing? And should this not be logged by arch code in the same way as failure to restart is? And how is that different from having a set of power-off handlers, and reporting when each individual one fails? Don't you want to know if your primary high priority reboot handler fails, just as much as you want to know if your final last-resort power-off handler fails? Good point. Failed power-off should probably be logged by the power-off call chain implementation (which seems to makes notifier chains a bad fit). Good that I just replaced notifier chain with an open coded implementation. Good to hear. Sure, that is possible, but I would prefer to do that as a follow-up commit, and it should be discussed in the context of the power-off handler patch set. Fine with me. And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? That delay would depend on the individual power-off handler, so I think the current implementation works just fine (where power-off handlers implement the delay). Some don't, and could possibly unknowingly have been relying on the fact that they could return to user space and be powered off at some later time. With systemd that would have caused a panic. Agreed, but there are two cases to consider: What should be the delay before the next power-off handler is called, and what should the system do if all power-off handlers fail (or if there are none). The current behavior isn't exactly well defined. Ok, with systemd that results in a crash, but I am not really sure if one can or should blame systemd for that. The discussion about systemd and its philosophy should not cloud the fact that power-off behavior isn't exactly well defined. Also consider generic power-off handlers such as gpio-poweroff. It currently hard-codes a three-second delay but the actual delay would really be board specific. A configurable delay would address that. The actually required delay could be provided in platform data or as devicetree property. Thanks, Guenter -- 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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 08:25:02AM -0700, Guenter Roeck wrote: On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote: On Wed, Oct 29, 2014 at 01:10:20PM +, Russell King - ARM Linux wrote: On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote: On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote: And how is that different from having a set of power-off handlers, and reporting when each individual one fails? Don't you want to know if your primary high priority reboot handler fails, just as much as you want to know if your final last-resort power-off handler fails? Good point. Failed power-off should probably be logged by the power-off call chain implementation (which seems to makes notifier chains a bad fit). And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? If the handler has determined that it has failed, then why delay before trying the next handler? At the point it has decided it has failed, surely that's after it has waited sufficient time to determine that failure? The current handlers we have are not expecting any other handler to be run after they return. My question was whether all these handlers should get a short mdelay added to them (e.g. to compensate for bus latencies) Some of them do add a delay. Yes, but not all. or if this could be done in the power-off handler (e.g. before printing the error message). That might make sense, but it would have to be configurable, since the delay is platform specific and power-off handler does not know how long to wait (the longest delay I have seen is 10 seconds). We've already concluded in this thread that such delays must be encoded in the actual handler (even if it's an argument to the power-off call chain code). The only exception should be generic handlers such as gpio-poweroff, which may need to define different delays depending on board. This could of course just be an argument of the corresponding DT node. My question above was if it was reasonable to add some generic short delay after calling each power-off handler to handle short power-off latencies (e.g. bus latencies) so that not every handler needs an explicit delay. Or different from having no power-off handlers. That is actually quite different, as in that case we call machine_halt instead (via kernel_halt). Today, ARM does exactly what x86 does. If there's no power off handler registered, machine_power_off() shuts down other CPUs and returns. No, if there are no power-off handlers registered, kernel/reboot.c will never call machine_power_off: /* Instead of trying to make the power_off code look like * halt when pm_power_off is not set do it the easy way. */ if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) !pm_power_off) cmd = LINUX_REBOOT_CMD_HALT; So in that case on arm, a system-halted message is printed, and we never return to user-space. Some architectures do that, or go into an endless loop. Others do return from machine_power_off. Please re-read my comment and the code above. machine_power_off is never called if there's no handler registered. Some archs machine_power_off to spin on failed power-off (i.e. when there is a handler), something which I've mentioned a few times already in this thread. Having a well defined behavior would be nice (such as dumping an error mesasge and calling machine_halt if machine_power_off returns). Only question would be where to put it. kernel_power_off() might be a good place; only problem is that there are direct callers of machine_power_off(). Indeed. Adding an error message to the power-off handler call chain code would solve the first problem as I mentioned before. Then it's mostly a matter of whether we care about consistency, and either remove the indefinite spins from those non-x86/non-arm arches, or prevent the latter (and some others) from returning to user-space. I'm inclined to having all arches return to user space on failed power-off, even if it means systemd cannot call reboot() from PID 1. Johan -- 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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 08:36:41AM -0700, Guenter Roeck wrote: On Wed, Oct 29, 2014 at 02:35:26PM +0100, Johan Hovold wrote: On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote: On 10/29/2014 05:34 AM, Johan Hovold wrote: And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? That delay would depend on the individual power-off handler, so I think the current implementation works just fine (where power-off handlers implement the delay). Some don't, and could possibly unknowingly have been relying on the fact that they could return to user space and be powered off at some later time. With systemd that would have caused a panic. Agreed, but there are two cases to consider: What should be the delay before the next power-off handler is called, and what should the system do if all power-off handlers fail (or if there are none). The current behavior isn't exactly well defined. Ok, with systemd that results in a crash, but I am not really sure if one can or should blame systemd for that. The discussion about systemd and its philosophy should not cloud the fact that power-off behavior isn't exactly well defined. Sounds like we pretty much agree. See my response to your last mail. Also consider generic power-off handlers such as gpio-poweroff. It currently hard-codes a three-second delay but the actual delay would really be board specific. A configurable delay would address that. The actually required delay could be provided in platform data or as devicetree property. Yep, see mail mentioned above. Johan -- 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] net: smc91x: Fix gpios for device tree based booting
From: Tony Lindgren t...@atomide.com Date: Mon, 27 Oct 2014 13:25:56 -0700 +/** + * of_try_set_control_gpio - configure a gpio if it exists + */ +static int try_toggle_control_gpio(struct device *dev, +struct gpio_desc **desc, +const char *name, int index, +int value, unsigned int nsdelay) This needs to be under CONFIG_OF cpp protection just like the code that calls 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: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hi, On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote: On 10/28/2014 05:12 PM, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]: Hi, On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote: + + if (!of_have_populated_dt()) + pr_warn(WARNING: legacy booting deprecated, please update to boot with .dts\n); + Maybe use WARN so that the warning is more verbose and kernel gets tainted? Well I was hoping to avoid annoying people with the trace. But can do that if people prefer that, what do others think? WARN is better and eye catchy. Also, could we add information on when the support will be removed since we call it deprecated? I also think, that more eye catchy is better. Apart from that I wonder if we should drop support on a board-by-board basis and then drop omap3 support completly once all boards have been dropped. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v3] rtc: omap: add support for pmic_power_en
On Wed, 29 Oct 2014 13:50:05 +0100 Johan Hovold jo...@kernel.org wrote: On Tue, Oct 28, 2014 at 09:36:33AM +0100, Johan Hovold wrote: On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote: On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold jo...@kernel.org wrote: But in general, how do you want to handle updates to a single patch in a series you already have in your tree? Do you prefer a proper incremental-fix patch (with commit message), just an updated single patch, or a resend of the whole series? How should I best send the updated patch? Can you just replace the current three incremental patches: rtc-omap-add-support-for-pmic_power_en.patch rtc-omap-add-support-for-pmic_power_en-v3.patch rtc-omap-add-support-for-pmic_power_en-v3-fix.patch that you have in your tree, with a single new v4 which adds a more elaborate comment? Yep, that works. I'll almost always turn the new patch into an incremental, mainly so that I (and others) can see what was changed. -- 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Sebastian Reichel s...@ring0.de [141029 12:01]:
Hi,
On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote:
On 10/28/2014 05:12 PM, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]:
Hi,
On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
+
+ if (!of_have_populated_dt())
+ pr_warn(WARNING: legacy booting deprecated, please
update to boot with .dts\n);
+
Maybe use WARN so that the warning is more verbose and kernel gets
tainted?
Well I was hoping to avoid annoying people with the trace.
But can do that if people prefer that, what do others think?
WARN is better and eye catchy. Also, could we add information on when
the support will be removed since we call it deprecated?
Well quoting the hostage situation from a Mr. Show episode
Now Who Wants Ice Cream? the answer to that would be:
OK, you want me to guess? A hundred million days, or maybe ten more
minutes, somewhere in there, I just can't say, don't know.
I also think, that more eye catchy is better.
OK, updated patch below. I'd like to add this to the current
-rc cycle unless people have objections to that.
Apart from that I wonder if we should drop support on a
board-by-board basis and then drop omap3 support completly once all
boards have been dropped.
Yes. I'll post few patches from my old board removal branch at
omap-for-v3.14/omap3-board-removal shortly.
Regards,
Tony
8 ---
From: Tony Lindgren t...@atomide.com
Date: Mon, 27 Oct 2014 13:05:54 -0700
Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
We're moving omaps to use device tree based booting and already have
omap2, omap4, omap5, am335x and am437x booting in device tree only
mode.
Only omap3 still has legacy booting still around and we really want
to make that device tree only. So let's add a warning about deprecated
legacy booting so we get people to upgrade their boards to use device
tree based booting and find out about any remaining issues.
Note that for most boards we already have the .dts file and those can
be booted with without changing the bootloader using the appended
DTB mode.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device
*dev, void *data)
static int __init omap_device_late_init(void)
{
bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle);
+
+ WARN(!of_have_populated_dt(),
+ legacy booting deprecated, please update to boot with .dts\n);
+
return 0;
}
omap_late_initcall_sync(omap_device_late_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.html
Fix Penguin Penalty 17th October2014 ( mail-archive.com )
Dear Sir Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin Update? It is actually a code name for Google algorithm which aims at decreasing your websites search engine rankings that violate GoogleÂ’s guidelines by using black hat SEO techniques to rank your webpage by giving number of spammy links to the page. We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and Panda. Our clients have survived all the previous and present updates with ease. They have never been hit because we use 100% white hat SEO techniques to rank Webpages. Simple thing that we do to keep websites away from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers to their queries. If you are looking to increase the quality of your websites and to get more targeted traffic or save your websites from these Google penalties email us back with your interest. We will be glad to serve you and help you grow your business. Regards Vince G SEO Manager ( TOB ) B7 Green Avenue, Amritsar 143001 Punjab NO CLICK in the subject to STOP EMAILS -- 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: Nokia n900 problems in 3.18-rc1 (was Re: USB Ethernet gadget on Nokia n900)
On Wed 2014-10-29 16:18:46, Tomi Valkeinen wrote:
On 29/10/14 16:09, Tony Lindgren wrote:
omapfb reports problems, but seems to work ok:
[0.990386] omapfb omapfb: cannot parse default modes
[1.004791] Console: switching to colour frame buffer device 100x30
[1.073150] omapfb omapfb: using display 'lcd' mode 800x480
Tomi, is the default mode warning correct here?
omapfb warns that it couldn't parse kernel cmdline parameters
('omapfb.mode' parameter). I couldn't find in the thread what actual
parameters were used in this case.
I had omapfb.mode=lcd:848x480-16 on command line. I removed it now.
Although I don't see why N900 would need any omapfb mode parameters in
the first place, as the LCD has just one mode...
I don't know where I copied it from, sorry...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On 12:39-20141029, Tony Lindgren wrote: * Sebastian Reichel s...@ring0.de [141029 12:01]: Hi, On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote: On 10/28/2014 05:12 PM, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]: Hi, On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote: + + if (!of_have_populated_dt()) + pr_warn(WARNING: legacy booting deprecated, please update to boot with .dts\n); + Maybe use WARN so that the warning is more verbose and kernel gets tainted? Well I was hoping to avoid annoying people with the trace. But can do that if people prefer that, what do others think? WARN is better and eye catchy. Also, could we add information on when the support will be removed since we call it deprecated? Well quoting the hostage situation from a Mr. Show episode Now Who Wants Ice Cream? the answer to that would be: OK, you want me to guess? A hundred million days, or maybe ten more minutes, somewhere in there, I just can't say, don't know. How about ~1 year? We have been talking about dt only boot for over an year already... Can we say 3.22 kernel, platforms that are not converted to device tree only loose legacy boot support. -- 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Nishanth Menon n...@ti.com [141029 14:47]: On 12:39-20141029, Tony Lindgren wrote: * Sebastian Reichel s...@ring0.de [141029 12:01]: Hi, On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote: On 10/28/2014 05:12 PM, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]: Hi, On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote: + + if (!of_have_populated_dt()) + pr_warn(WARNING: legacy booting deprecated, please update to boot with .dts\n); + Maybe use WARN so that the warning is more verbose and kernel gets tainted? Well I was hoping to avoid annoying people with the trace. But can do that if people prefer that, what do others think? WARN is better and eye catchy. Also, could we add information on when the support will be removed since we call it deprecated? Well quoting the hostage situation from a Mr. Show episode Now Who Wants Ice Cream? the answer to that would be: OK, you want me to guess? A hundred million days, or maybe ten more minutes, somewhere in there, I just can't say, don't know. How about ~1 year? We have been talking about dt only boot for over an year already... Can we say 3.22 kernel, platforms that are not converted to device tree only loose legacy boot support. I'm hoping we can make it faster let's say over next two merge windows. Pretty much everything already works with device tree booting so now it's just a question of getting people to start using it and fix whatever issues we may encounter. 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Wed, Oct 29, 2014 at 04:45:41PM -0500, Nishanth Menon wrote: On 12:39-20141029, Tony Lindgren wrote: OK, you want me to guess? A hundred million days, or maybe ten more minutes, somewhere in there, I just can't say, don't know. How about ~1 year? We have been talking about dt only boot for over an year already... Can we say 3.22 kernel, platforms that are not converted to device tree only loose legacy boot support. If you want to define some date, it should be a calendar date instead of some kernel version based on guesswork (you cannot really predict the kernel versions for future, just remember the 2.6.39 - 3.0 change). Also, you cannot expect all kernel users to know what you have been talking about. E.g. OMAP DMA API deprecation may have been discussed before, but I only learned it after the WARN appeared in the kernel tree. So you should start counting from that. Personally I don't mind if you delete OMAP3 legacy boot support already tomorrow morning, but if you want to give ~1 year transition period it should end somewhere in the end of 2015. Of course if there are no legacy boot users you can do it faster. 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
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hi,
On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
8 ---
From: Tony Lindgren t...@atomide.com
Date: Mon, 27 Oct 2014 13:05:54 -0700
Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
We're moving omaps to use device tree based booting and already have
omap2, omap4, omap5, am335x and am437x booting in device tree only
mode.
Only omap3 still has legacy booting still around and we really want
to make that device tree only. So let's add a warning about deprecated
legacy booting so we get people to upgrade their boards to use device
tree based booting and find out about any remaining issues.
Note that for most boards we already have the .dts file and those can
be booted with without changing the bootloader using the appended
DTB mode.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device
*dev, void *data)
static int __init omap_device_late_init(void)
{
bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle);
+
+ WARN(!of_have_populated_dt(),
+ legacy booting deprecated, please update to boot with .dts\n);
+
return 0;
}
omap_late_initcall_sync(omap_device_late_init);
Acked-By: Sebastian Reichel s...@kernel.org
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Unless I'm missing something, this patch appears to have still not been
picked up. It would be nice if it can go in for 3.18 so that we have
working USB on pandaboard again at least in that release.
Tony, would you mind carrying it as OMAP maintainer since we haven't
heard anything from Kishon (the PHY maintainer) about this? It's been
acked by Roger (whose patch introduced the problem).
Thanks.
(leaving the patch intact below)
On Tue, Oct 07, 2014 at 12:02:51PM +0100, Oussama Ghorbel wrote:
The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.
Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com
---
drivers/phy/phy-omap-usb2.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 93d7835..acc13f8 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -262,14 +262,16 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg-phy= phy-phy;
platform_set_drvdata(pdev, phy);
+ pm_runtime_enable(phy-dev);
generic_phy = devm_phy_create(phy-dev, NULL, ops, NULL);
- if (IS_ERR(generic_phy))
+ if (IS_ERR(generic_phy)) {
+ pm_runtime_disable(phy-dev);
return PTR_ERR(generic_phy);
+ }
phy_set_drvdata(generic_phy, phy);
- pm_runtime_enable(phy-dev);
phy_provider = devm_of_phy_provider_register(phy-dev,
of_phy_simple_xlate);
if (IS_ERR(phy_provider)) {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
From: Tony Lindgren t...@atomide.com
Date: Mon, 27 Oct 2014 13:05:54 -0700
Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
We're moving omaps to use device tree based booting and already have
omap2, omap4, omap5, am335x and am437x booting in device tree only
mode.
Only omap3 still has legacy booting still around and we really want
to make that device tree only. So let's add a warning about deprecated
legacy booting so we get people to upgrade their boards to use device
tree based booting and find out about any remaining issues.
Note that for most boards we already have the .dts file and those can
be booted with without changing the bootloader using the appended
DTB mode.
Signed-off-by: Tony Lindgren t...@atomide.com
Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device
*dev, void *data)
static int __init omap_device_late_init(void)
{
bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle);
+
+ WARN(!of_have_populated_dt(),
+ legacy booting deprecated, please update to boot with .dts\n);
+
return 0;
}
omap_late_initcall_sync(omap_device_late_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.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hello Tony, On Thu, Oct 30, 2014 at 12:11 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote: From: Tony Lindgren t...@atomide.com Date: Mon, 27 Oct 2014 13:05:54 -0700 Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode We're moving omaps to use device tree based booting and already have omap2, omap4, omap5, am335x and am437x booting in device tree only mode. Only omap3 still has legacy booting still around and we really want to make that device tree only. So let's add a warning about deprecated legacy booting so we get people to upgrade their boards to use device tree based booting and find out about any remaining issues. Note that for most boards we already have the .dts file and those can be booted with without changing the bootloader using the appended DTB mode. Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org 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 00/10] omap gpmc and board clean-up for v3.19 merge window
Here are few patches to fix and clean up some GPMC issues and remove two board files that are no longer needed. Regards, Tony Tony Lindgren (10): ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins ARM: dts: Fix wrong GPMC size mappings for omaps ARM: dts: Add smc91x GPMC configuration for 2430sdp ARM: dts: Add GPMC timings for omap zoom serial port ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file ARM: OMAP2+: Require proper GPMC timings for devices ARM: OMAP2+: Drop legacy code for gpmc-smc91x.c ARM: OMAP2+: Drop board file for ti8168evm ARM: omap2plus: Drop board file for 3430sdp arch/arm/boot/dts/am335x-evm.dts | 4 +- arch/arm/boot/dts/am335x-igep0033.dtsi | 4 +- arch/arm/boot/dts/am43x-epos-evm.dts | 4 +- arch/arm/boot/dts/omap-zoom-common.dtsi | 62 ++- arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 +- arch/arm/boot/dts/omap2430-sdp.dts | 28 +- arch/arm/boot/dts/omap3-devkit8000.dts | 4 +- arch/arm/boot/dts/omap3-evm-37xx.dts | 4 +- arch/arm/boot/dts/omap3-gta04.dtsi | 4 +- arch/arm/boot/dts/omap3-igep0020.dts | 4 +- arch/arm/boot/dts/omap3-igep0030.dts | 4 +- arch/arm/boot/dts/omap3-ldp.dts | 2 +- arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +- arch/arm/boot/dts/omap3-n900.dts | 35 +- arch/arm/boot/dts/omap3-n950-n9.dtsi | 4 +- arch/arm/boot/dts/omap3-tao3530.dtsi | 2 +- arch/arm/boot/dts/omap3430-sdp.dts | 8 +- arch/arm/mach-omap2/Kconfig | 16 - arch/arm/mach-omap2/Makefile | 6 - arch/arm/mach-omap2/board-3430sdp.c | 632 --- arch/arm/mach-omap2/board-rx51-peripherals.c | 29 -- arch/arm/mach-omap2/board-ti8168evm.c| 62 --- arch/arm/mach-omap2/gpmc-smc91x.c| 186 arch/arm/mach-omap2/gpmc-smc91x.h| 42 -- arch/arm/mach-omap2/gpmc.c | 206 +++-- 25 files changed, 324 insertions(+), 1034 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-3430sdp.c delete mode 100644 arch/arm/mach-omap2/board-ti8168evm.c delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.c delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.h -- 2.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 05/10] ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select
There are cases where we have multiple device instances
connected to a single GPMC chip select. For example, there
are four UARTs on the Zoom debug boards that all share a
single chip select and a GPIO interrupt.
We do have support for this already in theory, but it's broken
because we're bailing out if the chip select is already taken.
To be able to provide checks on the chip select usage, let's
add new struct gpmc_cs_data so we can start using already
registered device names for checks.
Later on we probably want to start using struct gpmc_cs_data
as a wrapper for all the GPMC chipselect related data.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c | 61 +-
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5fa3755..2c5f348 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -118,6 +118,15 @@
*/
#defineGPMC_NR_IRQ 2
+struct gpmc_cs_data {
+ const char *name;
+
+#define GPMC_CS_RESERVED (1 0)
+ u32 flags;
+
+ struct resource mem;
+};
+
struct gpmc_client_irq {
unsignedirq;
u32 bitmask;
@@ -155,10 +164,9 @@ static struct irq_chip gpmc_irq_chip;
static int gpmc_irq_start;
static struct resource gpmc_mem_root;
-static struct resource gpmc_cs_mem[GPMC_CS_NUM];
+static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
-static unsigned int gpmc_cs_map = ((1 GPMC_CS_NUM) - 1);
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
@@ -460,13 +468,30 @@ static int gpmc_cs_mem_enabled(int cs)
static void gpmc_cs_set_reserved(int cs, int reserved)
{
- gpmc_cs_map = ~(1 cs);
- gpmc_cs_map |= (reserved ? 1 : 0) cs;
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+
+ gpmc-flags |= GPMC_CS_RESERVED;
}
static bool gpmc_cs_reserved(int cs)
{
- return gpmc_cs_map (1 cs);
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+
+ return gpmc-flags GPMC_CS_RESERVED;
+}
+
+static void gpmc_cs_set_name(int cs, const char *name)
+{
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+
+ gpmc-name = name;
+}
+
+const char *gpmc_cs_get_name(int cs)
+{
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+
+ return gpmc-name;
}
static unsigned long gpmc_mem_align(unsigned long size)
@@ -485,7 +510,8 @@ static unsigned long gpmc_mem_align(unsigned long size)
static int gpmc_cs_insert_mem(int cs, unsigned long base, unsigned long size)
{
- struct resource *res = gpmc_cs_mem[cs];
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+ struct resource *res = gpmc-mem;
int r;
size = gpmc_mem_align(size);
@@ -500,7 +526,8 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base,
unsigned long size)
static int gpmc_cs_delete_mem(int cs)
{
- struct resource *res = gpmc_cs_mem[cs];
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+ struct resource *res = gpmc-mem;
int r;
spin_lock(gpmc_mem_lock);
@@ -557,7 +584,8 @@ static int gpmc_cs_remap(int cs, u32 base)
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
- struct resource *res = gpmc_cs_mem[cs];
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+ struct resource *res = gpmc-mem;
int r = -1;
if (cs gpmc_cs_num) {
@@ -597,7 +625,8 @@ EXPORT_SYMBOL(gpmc_cs_request);
void gpmc_cs_free(int cs)
{
- struct resource *res = gpmc_cs_mem[cs];
+ struct gpmc_cs_data *gpmc = gpmc_cs[cs];
+ struct resource *res = gpmc-mem;
spin_lock(gpmc_mem_lock);
if (cs = gpmc_cs_num || cs 0 || !gpmc_cs_reserved(cs)) {
@@ -1511,6 +1540,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
struct gpmc_timings gpmc_t;
struct resource res;
unsigned long base;
+ const char *name;
int ret, cs;
if (of_property_read_u32(child, reg, cs) 0) {
@@ -1525,11 +1555,21 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
return -ENODEV;
}
+ /*
+* Check if we have multiple instances of the same device
+* on a single chip select. If so, use the already initialized
+* timings.
+*/
+ name = gpmc_cs_get_name(cs);
+ if (name child-name of_node_cmp(child-name, name) == 0)
+ goto no_timings;
+
ret = gpmc_cs_request(cs, resource_size(res), base);
if (ret 0) {
dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
return ret;
}
+ gpmc_cs_set_name(cs, child-name);
/*
* For some GPMC devices we still
[PATCH 04/10] ARM: dts: Add GPMC timings for omap zoom serial port
The four port serial port on the zoom debug board uses a TL16CP754C
with a single interrupt and GPMC chip select. The serial ports each
use a 8 bytes for IO registers, and are 256 bytes apart on the GPMC
line.
Let's add timings for all four ports so we can remove the GPMC
workarounds for using bootloader timings.
Not caused by this patch, but looks like u-boot only properly
initializes the fifo on the first serial port. Currently the other
ports produce garbage at least with my version of u-boot. I suspect
that TL16CP754C needs non-standard initialization added to 8250
driver to properly fix this issue.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap-zoom-common.dtsi | 58 +
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi
b/arch/arm/boot/dts/omap-zoom-common.dtsi
index 2889b50..46ef3e4 100644
--- a/arch/arm/boot/dts/omap-zoom-common.dtsi
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -23,6 +23,64 @@
interrupts = 6 IRQ_TYPE_EDGE_RISING; /* gpio102 */
clock-frequency = 1843200;
current-speed = 115200;
+ gpmc,mux-add-data = 0;
+ gpmc,device-width = 1;
+ gpmc,wait-pin = 1;
+ gpmc,cycle2cycle-samecsen = 1;
+ gpmc,cycle2cycle-diffcsen = 1;
+ gpmc,cs-on-ns = 5;
+ gpmc,cs-rd-off-ns = 155;
+ gpmc,cs-wr-off-ns = 155;
+ gpmc,adv-on-ns = 15;
+ gpmc,adv-rd-off-ns = 40;
+ gpmc,adv-wr-off-ns = 40;
+ gpmc,oe-on-ns = 45;
+ gpmc,oe-off-ns = 145;
+ gpmc,we-on-ns = 45;
+ gpmc,we-off-ns = 145;
+ gpmc,rd-cycle-ns = 155;
+ gpmc,wr-cycle-ns = 155;
+ gpmc,access-ns = 145;
+ gpmc,page-burst-access-ns = 20;
+ gpmc,bus-turnaround-ns = 20;
+ gpmc,cycle2cycle-delay-ns = 20;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 45;
+ gpmc,wr-access-ns = 145;
+ };
+ uart@3,1 {
+ compatible = ns16550a;
+ reg = 3 0x100 8; /* CS3, offset 0x100, IO size 8 */
+ bank-width = 2;
+ reg-shift = 1;
+ reg-io-width = 1;
+ interrupt-parent = gpio4;
+ interrupts = 6 IRQ_TYPE_EDGE_RISING; /* gpio102 */
+ clock-frequency = 1843200;
+ current-speed = 115200;
+ };
+ uart@3,2 {
+ compatible = ns16550a;
+ reg = 3 0x200 8; /* CS3, offset 0x200, IO size 8 */
+ bank-width = 2;
+ reg-shift = 1;
+ reg-io-width = 1;
+ interrupt-parent = gpio4;
+ interrupts = 6 IRQ_TYPE_EDGE_RISING; /* gpio102 */
+ clock-frequency = 1843200;
+ current-speed = 115200;
+ };
+ uart@3,3 {
+ compatible = ns16550a;
+ reg = 3 0x300 8; /* CS3, offset 0x300, IO size 8 */
+ bank-width = 2;
+ reg-shift = 1;
+ reg-io-width = 1;
+ interrupt-parent = gpio4;
+ interrupts = 6 IRQ_TYPE_EDGE_RISING; /* gpio102 */
+ clock-frequency = 1843200;
+ current-speed = 115200;
};
ethernet@gpmc {
--
2.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 03/10] ARM: dts: Add smc91x GPMC configuration for 2430sdp
Let's use the bootloader values except for the partially configured wait-pin that does not seem to work. Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/omap2430-sdp.dts | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap2430-sdp.dts b/arch/arm/boot/dts/omap2430-sdp.dts index 2c90d29..05eca2e 100644 --- a/arch/arm/boot/dts/omap2430-sdp.dts +++ b/arch/arm/boot/dts/omap2430-sdp.dts @@ -43,7 +43,31 @@ interrupts = 21 IRQ_TYPE_LEVEL_LOW; /* gpio149 */ reg = 5 0x300 0xf; bank-width = 2; - gpmc,mux-add-data; -}; + gpmc,sync-clk-ps = 0; + gpmc,mux-add-data = 2; + gpmc,device-width = 1; + gpmc,cycle2cycle-samecsen = 1; + gpmc,cycle2cycle-diffcsen = 1; + gpmc,cs-on-ns = 7; + gpmc,cs-rd-off-ns = 233; + gpmc,cs-wr-off-ns = 233; + gpmc,adv-on-ns = 22; + gpmc,adv-rd-off-ns = 60; + gpmc,adv-wr-off-ns = 60; + gpmc,oe-on-ns = 67; + gpmc,oe-off-ns = 210; + gpmc,we-on-ns = 67; + gpmc,we-off-ns = 210; + gpmc,rd-cycle-ns = 233; + gpmc,wr-cycle-ns = 233; + gpmc,access-ns = 233; + gpmc,page-burst-access-ns = 30; + gpmc,bus-turnaround-ns = 30; + gpmc,cycle2cycle-delay-ns = 30; + gpmc,wait-monitoring-ns = 0; + gpmc,clk-activation-ns = 0; + gpmc,wr-data-mux-bus-ns = 0; + gpmc,wr-access-ns = 0; + }; }; -- 2.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 06/10] ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file
As we still have some devices with GPMC timings missing from the
.dts files, let's make it a bit easier to use the bootloader
values and print them out.
Note that we now need to move the parsing of the device tree provided
configuration a bit earlier so we can use that for checking if anything
was configured.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c | 141 +++--
1 file changed, 137 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c5f348..023 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -291,6 +291,123 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
p-cycle2cyclediffcsen);
}
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
+ bool raw, bool noval, int shift,
+ const char *name)
+{
+ u32 l;
+ int nr_bits, max_value, mask;
+
+ l = gpmc_cs_read_reg(cs, reg);
+ nr_bits = end_bit - st_bit + 1;
+ max_value = (1 nr_bits) - 1;
+ mask = max_value st_bit;
+ l = (l mask) st_bit;
+ if (shift)
+ l = shift;
+ if (noval (l == 0))
+ return 0;
+ if (!raw) {
+ unsigned int time_ns_min, time_ns, time_ns_max;
+
+ time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
+ time_ns = gpmc_ticks_to_ns(l);
+ time_ns_max = gpmc_ticks_to_ns(l + 1 max_value ?
+ max_value : l + 1);
+ pr_info(gpmc,%s = %u (%u - %u ns, %i ticks)\n,
+ name, time_ns, time_ns_min, time_ns_max, l);
+ } else {
+ pr_info(gpmc,%s = %u\n, name, l);
+ }
+
+ return l;
+}
+
+#define GPMC_PRINT_CONFIG(cs, config) \
+ pr_info(cs%i %s: 0x%08x\n, cs, #config, \
+ gpmc_cs_read_reg(cs, config))
+#define GPMC_GET_RAW(reg, st, end, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 1, 0, 0, field)
+#define GPMC_GET_RAW_BOOL(reg, st, end, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 1, 1, 0, field)
+#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 1, 1, (shift), field)
+#define GPMC_GET_TICKS(reg, st, end, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, 0, 0, field)
+
+static void gpmc_show_regs(int cs, const char *desc)
+{
+ pr_info(gpmc cs%i %s:\n, cs, desc);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG1);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG2);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG3);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG4);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG5);
+ GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG6);
+}
+
+/*
+ * Note that gpmc,wait-pin handing wrongly assumes bit 8 is available,
+ * see commit c9fb809.
+ */
+static void gpmc_cs_show_timings(int cs, const char *desc)
+{
+ gpmc_show_regs(cs, desc);
+
+ pr_info(gpmc cs%i access configuration:\n, cs);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 4, 4, time-para-granularity);
+ GPMC_GET_RAW(GPMC_CS_CONFIG1, 8, 9, mux-add-data);
+ GPMC_GET_RAW(GPMC_CS_CONFIG1, 12, 13, device-width);
+ GPMC_GET_RAW(GPMC_CS_CONFIG1, 16, 17, wait-pin);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 21, 21, wait-on-write);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 22, 22, wait-on-read);
+ GPMC_GET_RAW_SHIFT(GPMC_CS_CONFIG1, 23, 24, 3, burst-length);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 27, 27, sync-write);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 28, 28, burst-write);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 29, 29, gpmc,sync-read);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 30, 30, burst-read);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 31, 31, burst-wrap);
+
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG2, 7, 7, cs-extra-delay);
+
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG3, 7, 7, adv-extra-delay);
+
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG4, 23, 23, we-extra-delay);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG4, 7, 7, oe-extra-delay);
+
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 7, 7, cycle2cycle-samecsen);
+ GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 6, 6, cycle2cycle-diffcsen);
+
+ pr_info(gpmc cs%i timings configuration:\n, cs);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG2, 0, 3, cs-on-ns);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG2, 8, 12, cs-rd-off-ns);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG2, 16, 20, cs-wr-off-ns);
+
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 0, 3, adv-on-ns);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 8, 12, adv-rd-off-ns);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 16, 20, adv-wr-off-ns);
+
+ GPMC_GET_TICKS(GPMC_CS_CONFIG4, 0, 3, oe-on-ns);
+ GPMC_GET_TICKS(GPMC_CS_CONFIG4, 8, 12, oe-off-ns);
+
[PATCH 01/10] ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins
Apparently some versions of nolo don't mux the necessary GPMC
pins for the smc91x probe to work properly. Let's fix this issue
by adding mux support for GPMC to the kernel.
Note that it's unclear why the GPMC clk pin has input enabled, but
let's not touch that as in general the mux settings in nolo are
correct.
Cc: Kevin Hilman khil...@kernel.org
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-n900.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..e7210d1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -142,6 +142,33 @@
;
};
+ gpmc_pins: pinmux_gpmc_pins {
+ pinctrl-single,pins =
+
+ /* address lines */
+OMAP3_CORE1_IOPAD(0x207a, PIN_OUTPUT | MUX_MODE0)
/* gpmc_a1.gpmc_a1 */
+OMAP3_CORE1_IOPAD(0x207c, PIN_OUTPUT | MUX_MODE0)
/* gpmc_a2.gpmc_a2 */
+OMAP3_CORE1_IOPAD(0x207e, PIN_OUTPUT | MUX_MODE0)
/* gpmc_a3.gpmc_a3 */
+
+ /* data lines, gpmc_d0..d7 not muxable according to TRM
*/
+OMAP3_CORE1_IOPAD(0x209e, PIN_INPUT | MUX_MODE0)
/* gpmc_d8.gpmc_d8 */
+OMAP3_CORE1_IOPAD(0x20a0, PIN_INPUT | MUX_MODE0)
/* gpmc_d9.gpmc_d9 */
+OMAP3_CORE1_IOPAD(0x20a2, PIN_INPUT | MUX_MODE0)
/* gpmc_d10.gpmc_d10 */
+OMAP3_CORE1_IOPAD(0x20a4, PIN_INPUT | MUX_MODE0)
/* gpmc_d11.gpmc_d11 */
+OMAP3_CORE1_IOPAD(0x20a6, PIN_INPUT | MUX_MODE0)
/* gpmc_d12.gpmc_d12 */
+OMAP3_CORE1_IOPAD(0x20a8, PIN_INPUT | MUX_MODE0)
/* gpmc_d13.gpmc_d13 */
+OMAP3_CORE1_IOPAD(0x20aa, PIN_INPUT | MUX_MODE0)
/* gpmc_d14.gpmc_d14 */
+OMAP3_CORE1_IOPAD(0x20ac, PIN_INPUT | MUX_MODE0)
/* gpmc_d15.gpmc_d15 */
+
+ /*
+* gpmc_ncs0, gpmc_nadv_ale, gpmc_noe, gpmc_nwe,
gpmc_wait0 not muxable
+* according to TRM. REVISIT: why does nolo set input
for gpmc_clk?
+*/
+OMAP3_CORE1_IOPAD(0x20b0, PIN_OUTPUT | MUX_MODE0)
/* gpmc_ncs1.gpmc_ncs1 */
+OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
/* gpmc_clk.gpmc_clk */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0x18a (PIN_INPUT | MUX_MODE0) /* i2c1_scl */
@@ -588,6 +615,8 @@
ranges = 0 0 0x0400 0x1000; /* 256MB */
ranges = 0 0 0x0100 0x0100, /* 16 MB for OneNAND */
1 0 0x0200 0x0100; /* 16 MB for smc91c96 */
+ pinctrl-names = default;
+ pinctrl-0 = gpmc_pins;
/* gpio-irq for dma: 65 */
--
2.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 10/10] ARM: omap2plus: Drop board file for 3430sdp
This board seems to be in use only for few automated
boot test system and has been booting in device tree
only mode for quite some time now.
So let's drop the board file for it.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 6 -
arch/arm/mach-omap2/Makefile| 1 -
arch/arm/mach-omap2/board-3430sdp.c | 604
3 files changed, 611 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-3430sdp.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7adc4f7..27ec892 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -235,12 +235,6 @@ config MACH_TOUCHBOOK
default y
select OMAP_PACKAGE_CBB
-config MACH_OMAP_3430SDP
- bool OMAP 3430 SDP board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBB
-
config MACH_NOKIA_N810
bool
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3a54671..00b35a3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -246,7 +246,6 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
-obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
deleted file mode 100644
index 9857882..000
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ /dev/null
@@ -1,604 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-3430sdp.c
- *
- * Copyright (C) 2007 Texas Instruments
- *
- * Modified from mach-omap2/board-generic.c
- *
- * Initial code: Syed Mohammed Khasim
- *
- * 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.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/input.h
-#include linux/input/matrix_keypad.h
-#include linux/spi/spi.h
-#include linux/i2c/twl.h
-#include linux/regulator/machine.h
-#include linux/io.h
-#include linux/gpio.h
-#include linux/mmc/host.h
-#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/platform_data/omap-twl4030.h
-#include linux/usb/phy.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-#include linux/omap-dma.h
-#include video/omapdss.h
-#include video/omap-panel-data.h
-
-#include gpmc.h
-
-#include soc.h
-#include board-flash.h
-#include mux.h
-#include sdram-qimonda-hyb18m512160af-6.h
-#include hsmmc.h
-#include pm.h
-#include control.h
-#include common-board-devices.h
-
-#define CONFIG_DISABLE_HFCLK 1
-
-#define SDP3430_TS_GPIO_IRQ_SDPV1 3
-#define SDP3430_TS_GPIO_IRQ_SDPV2 2
-
-#define ENABLE_VAUX3_DEDICATED 0x03
-#define ENABLE_VAUX3_DEV_GRP 0x20
-
-#define TWL4030_MSECURE_GPIO 22
-
-static uint32_t board_keymap[] = {
- KEY(0, 0, KEY_LEFT),
- KEY(0, 1, KEY_RIGHT),
- KEY(0, 2, KEY_A),
- KEY(0, 3, KEY_B),
- KEY(0, 4, KEY_C),
- KEY(1, 0, KEY_DOWN),
- KEY(1, 1, KEY_UP),
- KEY(1, 2, KEY_E),
- KEY(1, 3, KEY_F),
- KEY(1, 4, KEY_G),
- KEY(2, 0, KEY_ENTER),
- KEY(2, 1, KEY_I),
- KEY(2, 2, KEY_J),
- KEY(2, 3, KEY_K),
- KEY(2, 4, KEY_3),
- KEY(3, 0, KEY_M),
- KEY(3, 1, KEY_N),
- KEY(3, 2, KEY_O),
- KEY(3, 3, KEY_P),
- KEY(3, 4, KEY_Q),
- KEY(4, 0, KEY_R),
- KEY(4, 1, KEY_4),
- KEY(4, 2, KEY_T),
- KEY(4, 3, KEY_U),
- KEY(4, 4, KEY_D),
- KEY(5, 0, KEY_V),
- KEY(5, 1, KEY_W),
- KEY(5, 2, KEY_L),
- KEY(5, 3, KEY_S),
- KEY(5, 4, KEY_H),
- 0
-};
-
-static struct matrix_keymap_data board_map_data = {
- .keymap = board_keymap,
- .keymap_size= ARRAY_SIZE(board_keymap),
-};
-
-static struct twl4030_keypad_data sdp3430_kp_data = {
- .keymap_data= board_map_data,
- .rows = 5,
- .cols = 6,
- .rep= 1,
-};
-
-#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
-#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
-
-static void __init sdp3430_display_init(void)
-{
- int r;
-
- /*
-* the backlight GPIO doesn't directly go to the panel, it enables
-* an internal circuit on 3430sdp to create the signal V_BKL_28V,
-* this is connected to LED+ pin of the sharp panel. This GPIO
-* is left enabled in the board file, and not passed to the panel
-*
[PATCH 08/10] ARM: OMAP2+: Drop legacy code for gpmc-smc91x.c
This code was only used by 2430sdp, 3430sdp, and n900 development
boards.
The 2430sdp is already device tree only, and all the users of the
3430sdp and n900 development boards are already booting in device
tree mode, so we can drop the legacy smc91x support.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 3 -
arch/arm/mach-omap2/board-3430sdp.c | 28
arch/arm/mach-omap2/board-rx51-peripherals.c | 29 -
arch/arm/mach-omap2/gpmc-smc91x.c| 186 ---
arch/arm/mach-omap2/gpmc-smc91x.h| 42 --
5 files changed, 288 deletions(-)
delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.c
delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d9e9412..3e824f8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -284,9 +284,6 @@ obj-y += $(onenand-m)
$(onenand-y)
nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
obj-y += $(nand-m) $(nand-y)
-smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
-obj-y += $(smc91x-m) $(smc91x-y)
-
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d21a304..9857882 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,7 +38,6 @@
#include video/omap-panel-data.h
#include gpmc.h
-#include gpmc-smc91x.h
#include soc.h
#include board-flash.h
@@ -407,32 +406,6 @@ static int __init omap3430_i2c_init(void)
return 0;
}
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
-
-static struct omap_smc91x_platform_data board_smc91x_data = {
- .cs = 3,
- .flags = GPMC_MUX_ADD_DATA | GPMC_TIMINGS_SMC91C96 |
- IORESOURCE_IRQ_LOWLEVEL,
-};
-
-static void __init board_smc91x_init(void)
-{
- if (omap_rev() OMAP3430_REV_ES1_0)
- board_smc91x_data.gpio_irq = 6;
- else
- board_smc91x_data.gpio_irq = 29;
-
- gpmc_smc91x_init(board_smc91x_data);
-}
-
-#else
-
-static inline void board_smc91x_init(void)
-{
-}
-
-#endif
-
static void enable_board_wakeup_source(void)
{
/* T2 interrupt line (keypad) */
@@ -609,7 +582,6 @@ static void __init omap_3430sdp_init(void)
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
- board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ddfc8df..30e7d4c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -32,7 +32,6 @@
#include common.h
#include linux/omap-dma.h
-#include gpmc-smc91x.h
#include board-rx51.h
@@ -1146,33 +1145,6 @@ static struct omap_onenand_platform_data
board_onenand_data[] = {
};
#endif
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
-
-static struct omap_smc91x_platform_data board_smc91x_data = {
- .cs = 1,
- .gpio_irq = 54,
- .gpio_pwrdwn= 86,
- .gpio_reset = 164,
- .flags = GPMC_TIMINGS_SMC91C96 | IORESOURCE_IRQ_HIGHLEVEL,
-};
-
-static void __init board_smc91x_init(void)
-{
- omap_mux_init_gpio(54, OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_gpio(86, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(164, OMAP_PIN_OUTPUT);
-
- gpmc_smc91x_init(board_smc91x_data);
-}
-
-#else
-
-static inline void board_smc91x_init(void)
-{
-}
-
-#endif
-
static struct gpio rx51_wl1251_gpios[] __initdata = {
{ RX51_WL1251_IRQ_GPIO, GPIOF_IN, wl1251 irq},
};
@@ -1303,7 +1275,6 @@ void __init rx51_peripherals_init(void)
rx51_i2c_init();
regulator_has_full_constraints();
gpmc_onenand_init(board_onenand_data);
- board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
rx51_init_tsc2005();
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
deleted file mode 100644
index 61a0635..000
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ /dev/null
@@ -1,186 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/gpmc-smc91x.c
- *
- * Copyright (C) 2009 Nokia Corporation
- * Contact:Tony Lindgren
- *
- * 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
- *
[PATCH 07/10] ARM: OMAP2+: Require proper GPMC timings for devices
Now that we have timings in the .dts files for smc91x
and 8250, we can remove the device specific checks and
just print out the bootloader timings for devices that
may not have timings in the .dts files.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 023..0e74d1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1708,22 +1708,6 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
}
/*
-* For some GPMC devices we still need to rely on the bootloader
-* timings because the devices can be connected via FPGA. So far
-* the list is smc91x on the omap2 SDP boards, and 8250 on zooms.
-* REVISIT: Add timing support from slls644g.pdf and from the
-* lan91c96 manual.
-*/
- if (of_device_is_compatible(child, ns16550a) ||
- of_device_is_compatible(child, smsc,lan91c94) ||
- of_device_is_compatible(child, smsc,lan91c111)) {
- dev_warn(pdev-dev,
-%s using bootloader timings on CS%d\n,
-child-name, cs);
- goto no_timings;
- }
-
- /*
* FIXME: gpmc_cs_request() will map the CS to an arbitary
* location in the gpmc address space. When booting with
* device-tree we want the NOR flash to be mapped to the
--
2.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 02/10] ARM: dts: Fix wrong GPMC size mappings for omaps
The GPMC binding is obviously very confusing as the values
are all over the place. People seem to confuse the GPMC partition
size for the chip select, and the device IO size within the GPMC
partition easily.
The ranges entry contains the GPMC partition size. And the
reg entry contains the size of the IO registers of the
device connected to the GPMC.
Let's fix the issue according to the following table:
Device GPMC partition size Device IO size
connected in the ranges entry in the reg entry
NAND0x0100 (16MB) 4
16550 0x0100 (16MB) 8
smc91x 0x0100 (16MB) 0xf
smc911x 0x0100 (16MB) 0xff
OneNAND 0x0100 (16MB) 0x2 (128KB)
16MB NOR0x0100 (16MB) 0x0100 (16MB)
32MB NOR0x0200 (32MB) 0x0200 (32MB)
64MB NOR0x0400 (64MB) 0x0400 (64MB)
128MB NOR 0x0800 (128MB) 0x0800 (128MB)
256MB NOR 0x1000 (256MB) 0x1000 (256MB)
Let's also add comments to the fixed entries while at it.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-evm.dts| 4 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi | 4 ++--
arch/arm/boot/dts/am43x-epos-evm.dts| 4 ++--
arch/arm/boot/dts/omap-zoom-common.dtsi | 4 ++--
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
arch/arm/boot/dts/omap3-devkit8000.dts | 4 ++--
arch/arm/boot/dts/omap3-evm-37xx.dts| 4 ++--
arch/arm/boot/dts/omap3-gta04.dtsi | 4 ++--
arch/arm/boot/dts/omap3-igep0020.dts| 4 ++--
arch/arm/boot/dts/omap3-igep0030.dts| 4 ++--
arch/arm/boot/dts/omap3-ldp.dts | 2 +-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
arch/arm/boot/dts/omap3-n900.dts| 6 ++
arch/arm/boot/dts/omap3-n950-n9.dtsi| 4 ++--
arch/arm/boot/dts/omap3-tao3530.dtsi| 2 +-
arch/arm/boot/dts/omap3430-sdp.dts | 8
16 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a5..43a536c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -437,9 +437,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nandflash_pins_s0;
- ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ ranges = 0 0 0x0800 0x100;/* CS0: 16MB for NAND */
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ reg = 0 0 4; /* CS0, offset 0, IO size 4 */
ti,nand-ecc-opt = bch8;
ti,elm-id = elm;
nand-bus-width = 8;
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index a1a0cc5..c0e1135 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -126,10 +126,10 @@
pinctrl-names = default;
pinctrl-0 = nandflash_pins;
- ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ ranges = 0 0 0x0800 0x100;/* CS0: 16MB for NAND */
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ reg = 0 0 4; /* CS0, offset 0, IO size 4 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;
gpmc,device-width = 1;
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index ac3e485..bb4cb85 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -438,9 +438,9 @@
status = okay;/* Disable QSPI when enabling GPMC (NAND) */
pinctrl-names = default;
pinctrl-0 = nand_flash_x8;
- ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ ranges = 0 0 0x0800 0x100;/* CS0: 16MB for NAND */
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ reg = 0 0 4; /* CS0, offset 0, IO size 4 */
ti,nand-ecc-opt = bch16;
ti,elm-id = elm;
nand-bus-width = 8;
diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi
b/arch/arm/boot/dts/omap-zoom-common.dtsi
index 68221fa..2889b50 100644
--- a/arch/arm/boot/dts/omap-zoom-common.dtsi
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -5,7 +5,7 @@
#include omap-gpmc-smsc911x.dtsi
gpmc {
- ranges = 3 0 0x1000 0x0400,
+ ranges = 3 0 0x1000 0x100,/* CS3: 16MB for UART */
7 0 0x2c00 0x0100;
/*
@@ -15,7 +15,7 @@
*/
uart@3,0 {
compatible = ns16550a;
- reg = 3 0 0x100;
+ reg = 3 0 8; /* CS3, offset 0, IO size 8 */
bank-width = 2;
reg-shift = 1;
reg-io-width = 1;
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
[PATCH 09/10] ARM: OMAP2+: Drop board file for ti8168evm
The 81xx support is known to be broken for quite some
time now because of missing patches. And it should be
using device tree based booting now anyways.
So let's just drop the board file for it.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 10 --
arch/arm/mach-omap2/Makefile | 2 --
arch/arm/mach-omap2/board-ti8168evm.c | 62 ---
3 files changed, 74 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-ti8168evm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f4d06ae..7adc4f7 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -282,16 +282,6 @@ config MACH_SBC3530
default y
select OMAP_PACKAGE_CUS
-config MACH_TI8168EVM
- bool TI8168 Evaluation Module
- depends on SOC_TI81XX
- default y
-
-config MACH_TI8148EVM
- bool TI8148 Evaluation Module
- depends on SOC_TI81XX
- default y
-
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3e824f8..3a54671 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -260,8 +260,6 @@ obj-$(CONFIG_MACH_OMAP3517EVM) +=
board-am3517evm.o
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
-obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
-obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
deleted file mode 100644
index 6273c28..000
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Code for TI8168/TI8148 EVM.
- *
- * Copyright (C) 2010 Texas Instruments, Inc. - 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 as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/usb/musb.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-
-static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 500,
-};
-
-static void __init ti81xx_evm_init(void)
-{
- omap_serial_init();
- omap_sdrc_init(NULL, NULL);
- usb_musb_init(musb_board_data);
-}
-
-MACHINE_START(TI8168EVM, ti8168evm)
- /* Maintainer: Texas Instruments */
- .atag_offset= 0x100,
- .map_io = ti81xx_map_io,
- .init_early = ti81xx_init_early,
- .init_irq = ti81xx_init_irq,
- .init_time = omap3_sync32k_timer_init,
- .init_machine = ti81xx_evm_init,
- .init_late = ti81xx_init_late,
- .restart= omap44xx_restart,
-MACHINE_END
-
-MACHINE_START(TI8148EVM, ti8148evm)
- /* Maintainer: Texas Instruments */
- .atag_offset= 0x100,
- .map_io = ti81xx_map_io,
- .init_early = ti81xx_init_early,
- .init_irq = ti81xx_init_irq,
- .init_time = omap3_sync32k_timer_init,
- .init_machine = ti81xx_evm_init,
- .init_late = ti81xx_init_late,
- .restart= omap44xx_restart,
-MACHINE_END
--
2.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: [PATCH v2] mtd: omap: fix mtd devices not showing up
On Tue, Oct 28, 2014 at 11:46:57AM +0200, Roger Quadros wrote: On 10/27/2014 04:34 PM, Frans Klaver wrote: Since commit 6d178ef2fd5e (mtd: nand: Move ELM driver and rename as omap_elm), I don't have any mtd devices present on my am335x. This changes the link order of the omap_elm and omap2 objects, causing them to probe in the wrong order. To fix this, make elm_config defer probing until the omap_elm driver is actually loaded. Signed-off-by: Frans Klaver frans.kla...@xsens.com Acked-by: Roger Quadros rog...@ti.com Pushed to l2-mtd.git/for-3.18. Thanks! While this might be considered a link-order bug from long ago, it's not actually important until 3.18-rc1 where we changed the link order, right? So it doesn't need to go to -stable? Brian -- 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: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
On Thursday 30 October 2014 04:39 AM, Rabin Vincent wrote:
Unless I'm missing something, this patch appears to have still not been
picked up. It would be nice if it can go in for 3.18 so that we have
working USB on pandaboard again at least in that release.
Tony, would you mind carrying it as OMAP maintainer since we haven't
heard anything from Kishon (the PHY maintainer) about this? It's been
acked by Roger (whose patch introduced the problem).
I'll send this in this -rc cycle.
Thanks
Kishon
Thanks.
(leaving the patch intact below)
On Tue, Oct 07, 2014 at 12:02:51PM +0100, Oussama Ghorbel wrote:
The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.
Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com
---
drivers/phy/phy-omap-usb2.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 93d7835..acc13f8 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -262,14 +262,16 @@ static int omap_usb2_probe(struct platform_device
*pdev)
otg-phy= phy-phy;
platform_set_drvdata(pdev, phy);
+pm_runtime_enable(phy-dev);
generic_phy = devm_phy_create(phy-dev, NULL, ops, NULL);
-if (IS_ERR(generic_phy))
+if (IS_ERR(generic_phy)) {
+pm_runtime_disable(phy-dev);
return PTR_ERR(generic_phy);
+}
phy_set_drvdata(generic_phy, phy);
-pm_runtime_enable(phy-dev);
phy_provider = devm_of_phy_provider_register(phy-dev,
of_phy_simple_xlate);
if (IS_ERR(phy_provider)) {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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
