Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Mon 2015-01-05 15:02:29, Tony Lindgren wrote:
Revert ARM: dts: Disable smc91x on n900 until bootloader
dependency is removed. We've now fixed the issues that
caused problems with uninitialized hardware depending on
the bootloader version. Mostly things got fixed with
the following commits:
9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900
smc91x pins)
7d2911c43815 (net: smc91x: Fix gpios for device tree based booting)
Note that this only affects the early development boards
with Ethernet that we still have in a few automated boot
test systems.
Signed-off-by: Tony Lindgren t...@atomide.com
Normally, the early development boards should have separate dts file
(then include common parts), no?
Could you at least add a note to the dts file what is it? Because I
always thought it is a bug.
[Plus of course, obviouse question is: where can I get one of those
boards? :-)]
Pavel
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -702,9 +702,6 @@
ethernet@gpmc {
compatible = smsc,lan91c94;
-
- status = disabled;
-
interrupt-parent = gpio2;
interrupts = 22 IRQ_TYPE_LEVEL_HIGH; /* gpio54 */
reg = 1 0x300 0xf;/* 16 byte IO range at offset
0x300 */
--
(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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Paul,
On Tuesday 06 January 2015 07:34 AM, Paul Walmsley wrote:
Roger, Lokesh, could you try this one instead?
Yep, the below patch works on AM437x.
Boot logs here: http://paste.ubuntu.com/9680938/
Thanks and regards,
Lokesh
It passes all the basic tests here except it does not boot on the 4460
VAR-SOM-OM - unclear why at this point - but it would be good to see if it
works on your AM4372 boards, since I don't have that one.
Test logs are here:
http://www.pwsan.com/omap/testlogs/hwmod_skip_only_remap_v3.19-rc/20150105171744/
- Paul
From 4f2e13bd2181e0ebede3aabc484aa2339830748a Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+ oh-name);
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node *np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+ * If there's no need for the hwmod code to read or write to
+ * the IP block registers, bail out early before the ioremap()
+ */
+ if (!oh-class-sysc)
+ return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
- oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+ oh-name);
r = _init_clocks(oh, NULL);
if (r 0) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA7: beagle-x15: hwmod: Fix boot crash with DEBUG_LL
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On beagle-x15, we use uart3 for console and missed enabling this flag
for uart3 hwmod, so boot fails with DEBUG_LL. Enable DEBUG_OMAP4UART3_FLAGS for
uart3 hwmod.
For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
Fixes: 90020c7 (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data)
Cc: sta...@vger.kernel.org # v3.12+
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ffd6604..b6ea88f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2017,7 +2017,7 @@ static struct omap_hwmod dra7xx_uart3_hwmod = {
.class = dra7xx_uart_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = uart3_gfclk_mux,
- .flags = HWMOD_SWSUP_SIDLE_ACT,
+ .flags = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART3_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART3_CLKCTRL_OFFSET,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1-3.19-rc2: In-band Error seen by MPU
Am 05.01.2015 um 16:43 schrieb Felipe Balbi: Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem. Perhaps this is something related to another OMAP3-only driver ? Perhaps HSI/SSI ? cheers I see a ssi error directly before the IN-Band error: [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.346893] In-band Error seen by MPU at address 0 [0.346923] [ cut here ] Peter -- 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: 3.18.1-3.19-rc2: In-band Error seen by MPU
Hi,
On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
Perhaps this is something related to another OMAP3-only driver?
Perhaps HSI/SSI ?
I see a ssi error directly before the IN-Band error:
[0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
[0.346893] In-band Error seen by MPU at address 0
[0.346923] [ cut here ]
mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
should be disabled for those SoCs:
ssi {
status = disabled;
};
From what I can see the following in-tree .dts files should be
fixed, too:
* am3517_mt_ventoux.dts
Currently includes omap34xx.dtsi instead of am3517.dtsi.
Apart from that the following boards seem to use omap36xx.dtsi
include, but are actually DM37xx, so they should disable the
ssi block:
* omap3-igep.dtsi
* omap3-lilly-a83x.dtsi
* omap3-overo-storm.dtsi
I will prepare a patch for that later.
-- Sebastian
signature.asc
Description: Digital signature
Re: 3.18.1-3.19-rc2: In-band Error seen by MPU
Am 06.01.2015 um 12:52 schrieb Sebastian Reichel:
Hi,
On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
Perhaps this is something related to another OMAP3-only driver?
Perhaps HSI/SSI ?
I see a ssi error directly before the IN-Band error:
[0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
[0.346893] In-band Error seen by MPU at address 0
[0.346923] [ cut here ]
mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
should be disabled for those SoCs:
ssi {
status = disabled;
};
Indeed, I include omap36xx.dtsi.
Disabling ssi removes ssi the error.
But the In-Band error is still there, so not related to ssi.
I also see these errors:
omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp2: cannot be enabled for reset (3)
and
irq: no irq domain found for /ocp/pinmux@48002030 !
Could these errors also be fixed by the dts.
Peter
From what I can see the following in-tree .dts files should be
fixed, too:
* am3517_mt_ventoux.dts
Currently includes omap34xx.dtsi instead of am3517.dtsi.
Apart from that the following boards seem to use omap36xx.dtsi
include, but are actually DM37xx, so they should disable the
ssi block:
* omap3-igep.dtsi
* omap3-lilly-a83x.dtsi
* omap3-overo-storm.dtsi
I will prepare a patch for that later.
-- Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: 8250: Make ISA ports optional
On Monday 05 January 2015 22:09:45 Peter Hurley wrote: Some arches have no need to create unprobed 8250 ports; these phantom ports are primarily required for ISA ports which have no probe mechanism or to provide non-operational ports for userspace to configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls). Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers probed ports (ACPI/PNP, serial8250 platform devices, PCI, etc). Cc: Sebastian Andrzej Siewior bige...@linutronix.de Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@linaro.org Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Hurley pe...@hurleysoftware.com The intent is definitely right, but I think a better approach is possible. I haven't tried it here, but how about moving the serial8250_init function into a separate module, along with all the other parts that are only used for ISA devices, but leaving the actual core (all exported symbols) in this file? At the same time, the serial8250_pnp_init/serial8250_pnp_exit calls can be removed from the serial8250_init function and become standalone initcalls. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1-3.19-rc2: In-band Error seen by MPU
Hi,
On Mon, Jan 05, 2015 at 08:01:22PM -0600, Felipe Balbi wrote:
On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote:
I did some debugging and it seems the In-band Error
occurs when omap_system_dma_probe() is being run, specifically when
the interrupt is enabled. I believe the DMA interrupt it's trying
set up is completely wrong:
28: 0 GPIO 2 DMA
GPIO 2?! Where is that coming from?
heh, it's probably the linux number used ended up mapping to another irq
domain. Can you add this debugging patch and report dmesg ?
Post-commit:
[0.208251] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216125] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 22
22: 5 INTC 13 omap-dma-engine
28: 0 GPIO 2 DMA
Pre-commit:
[0.208557] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216461] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 29
28: 0 INTC 12 DMA
29: 5 INTC 13 omap-dma-engine
Note that I need one log post commit and another log pre commit. If any
of the IRQ numbers change, if means that irq_domain_add_linear() ended
up changing IRQ start and we would need some trick to grab the correct
IRQ number again.
So looks like static OMAP_INTC_START cannot be used anymore, but hwmod
data is full of these?
mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c: { .name = 0, .irq = 12 +
OMAP_INTC_START, }, /* INT_24XX_SDMA_IRQ0 */
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: 3.18.1-3.19-rc2: In-band Error seen by MPU
Hi, On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote: On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote: Am 05.01.2015 um 16:43 schrieb Felipe Balbi: Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem. Perhaps this is something related to another OMAP3-only driver? Perhaps HSI/SSI ? I see a ssi error directly before the IN-Band error: [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.346893] In-band Error seen by MPU at address 0 [0.346923] [ cut here ] mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi. This log occurs also on 3630, because ssi hwmod stuff is missing from omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need to be added since we should get nokia-modem working also on N950/N9... Peter: if you boot with initcall_debug, you should see the error is during the DMA setup. 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] serial: 8250: Make ISA ports optional
On 01/06/2015 08:13 AM, Arnd Bergmann wrote: On Monday 05 January 2015 22:09:45 Peter Hurley wrote: Some arches have no need to create unprobed 8250 ports; these phantom ports are primarily required for ISA ports which have no probe mechanism or to provide non-operational ports for userspace to configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls). Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers probed ports (ACPI/PNP, serial8250 platform devices, PCI, etc). Cc: Sebastian Andrzej Siewior bige...@linutronix.de Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@linaro.org Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Hurley pe...@hurleysoftware.com The intent is definitely right, but I think a better approach is possible. I haven't tried it here, but how about moving the serial8250_init function into a separate module, along with all the other parts that are only used for ISA devices, but leaving the actual core (all exported symbols) in this file? Unfortunately, I don't see a way to remove the stacked initialization without risking tons of breakage. Since later probes can find an already-existing port and re-initialize it, the probe order is crucial. For example, a PCI probe can find an existing serial8250 platform device port, resulting in only one device node. And the configuration knob will be required on all arches anyway because that's how user-configurable device nodes are created. At the same time, the serial8250_pnp_init/serial8250_pnp_exit calls can be removed from the serial8250_init function and become standalone initcalls. PNP probe must occur before the phantom ports are registered. See commit 835d844d1a28efba81d5aca7385e24c29d3a6db2 (8250_pnp: do pnp probe before legacy probe). Regards, Peter Hurley -- 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: 3.18.1-3.19-rc2: In-band Error seen by MPU
Am 06.01.2015 um 13:47 schrieb Aaro Koskinen: Hi, On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote: On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote: Am 05.01.2015 um 16:43 schrieb Felipe Balbi: Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem. Perhaps this is something related to another OMAP3-only driver? Perhaps HSI/SSI ? I see a ssi error directly before the IN-Band error: [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.346893] In-band Error seen by MPU at address 0 [0.346923] [ cut here ] mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi. This log occurs also on 3630, because ssi hwmod stuff is missing from omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need to be added since we should get nokia-modem working also on N950/N9... Peter: if you boot with initcall_debug, you should see the error is during the DMA setup. DMA is not a module here thus loaded before the initcall. I've tried with CONFIG_DMADEVICES_DEBUG but then kernel didn't start at all. Absolutely no messages. 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 -- 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: DRA7: beagle-x15: hwmod: Fix boot crash with DEBUG_LL
$subject should probably need a cleanup: this is hwmod support for
DEBUG_LL on UART3 - x15 happens to be one of the platforms that uses
that, but not the only one.. I suggest removing x15 from $subject and
rephrasing accordingly.
On 13:54-20150106, Lokesh Vutla wrote:
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On beagle-x15, we use uart3 for console and missed enabling this flag
Official name of the platform is BeagleBoard-X15
for uart3 hwmod, so boot fails with DEBUG_LL. Enable DEBUG_OMAP4UART3_FLAGS
for
uart3 hwmod.
Could you align your commit message to 70 chars if possible?
For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
Fixes: 90020c7 (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data)
Fixes: 90020c7b2c5e (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data)
Cc: sta...@vger.kernel.org # v3.12+
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ffd6604..b6ea88f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2017,7 +2017,7 @@ static struct omap_hwmod dra7xx_uart3_hwmod = {
.class = dra7xx_uart_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = uart3_gfclk_mux,
- .flags = HWMOD_SWSUP_SIDLE_ACT,
+ .flags = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART3_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART3_CLKCTRL_OFFSET,
--
1.9.1
--
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: dts: Revert disabling of smc91x for n900
Hi Pali, On Tue, Jan 06, 2015 at 12:09:15AM +0100, Pali Rohár wrote: Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel... $ qemu-system-arm --machine '?' | grep n900 || echo No N900 support No N900 support Is there work going on to mainline the n900 patches for qemu? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] ARM: DRA7: beagle-x15: hwmod: Fix boot crash with DEBUG_LL
On Tue, Jan 06, 2015 at 08:05:17AM -0600, Nishanth Menon wrote: For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig. Fixes: 90020c7 (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) Fixes: 90020c7b2c5e (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) what's the difference ? why do you want that many more characters if those 7 are enough for git to find a uniq commit ? Try this: $ git show --abbrev-commit 90020c7b2c5e02200bc752c8cfeba91c4435588c -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: DRA7: beagle-x15: hwmod: Fix boot crash with DEBUG_LL
On 01/06/2015 09:08 AM, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 08:05:17AM -0600, Nishanth Menon wrote: For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig. Fixes: 90020c7 (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) Fixes: 90020c7b2c5e (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) what's the difference ? why do you want that many more characters if those 7 are enough for git to find a uniq commit ? Try this: $ git show --abbrev-commit 90020c7b2c5e02200bc752c8cfeba91c4435588c https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n160 -- 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: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 16:03:54 Sebastian Reichel wrote: Hi Pali, On Tue, Jan 06, 2015 at 12:09:15AM +0100, Pali Rohár wrote: Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel... $ qemu-system-arm --machine '?' | grep n900 || echo No N900 support No N900 support Is there work going on to mainline the n900 patches for qemu? -- Sebastian I do not know, but n900 support is part of linaro qemu version. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Aaro Koskinen aaro.koski...@iki.fi [150106 11:47]: Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi OK good to hear, thanks for testing. I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? You need to write the eeprom with ethtool from Linux, something like this: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. 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: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 20:44:43 Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? A. Should not kernel generate some random mac address if driver does not provide one? You can try to set (temporary) mac address to if with ifconfig: $ ifconfig eth0 hw ether mac -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 21:17:59 Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150106 12:01]: * Aaro Koskinen aaro.koski...@iki.fi [150106 11:47]: Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi OK good to hear, thanks for testing. I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? You need to write the eeprom with ethtool from Linux, something like this: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly.. Regards, Tony N900 uboot support is broken, see my email on uboot ML with bisected commits: http://lists.denx.de/pipermail/u-boot/2015-January/200154.html -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] net: ethernet: cpsw: ignore VLAN ID 1
Hi, On Tue, Jan 06, 2015 at 02:13:23PM -0500, David Miller wrote: From: Felipe Balbi ba...@ti.com Date: Tue, 6 Jan 2015 11:43:32 -0600 CPSW completely hangs if we add, and later remove, VLAN ID #1. What happens is that after removing VLAN ID #1, no packets will be received by CPSW rendering network unusable. In order to fix the issue, we're returning -EINVAL if anybody tries to add VLAN ID #1. While at that, also filter out any ID 4095 because we only have 12 bits for VLAN IDs. Fixes: 3b72c2f (drivers: net:ethernet: cpsw: add support for VLAN) Cc: sta...@vger.kernel.org # v3.9+ Cc: Mugunthan V N mugunthan...@ti.com Tested-by: Schuyler Patton spat...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com You can't just unilaterally make one VLAN ID unusable. A better way to handle this situation must be found, and if that means turning off hw VLAN support completely, that's a much better alternative to this. I'm not applying this patch, sorry. All other IDs work alright, it's just ID 1 which seems to be quirky. In fact when trying to add VLAN ID 1, vconfig itself dumps out a warning that VLAN ID 1 doesn't work on most switches. What you're saying here is that you prefer to drop a feature that works for all other 1023 IDs because 1 ID is quirky. Sounds like overkill to me. -- balbi signature.asc Description: Digital signature
Re: 3.19 on Nokia n900: audio quality awful
On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tue 2015-01-06 12:17:59, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150106 12:01]: * Aaro Koskinen aaro.koski...@iki.fi [150106 11:47]: Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi OK good to hear, thanks for testing. I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? You need to write the eeprom with ethtool from Linux, something like this: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly.. Nice :-). If you have u-boot working, could you try to do generic board conversion? We are a tiny bit past a deadline on that one. Thanks, 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
DT support for OMAP3 ISP
Hi, I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? Thanks for any insight, --Ash [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt-v2 [2] http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt -- 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: ethernet: cpsw: ignore VLAN ID 1
From: Felipe Balbi ba...@ti.com Date: Tue, 6 Jan 2015 11:43:32 -0600 CPSW completely hangs if we add, and later remove, VLAN ID #1. What happens is that after removing VLAN ID #1, no packets will be received by CPSW rendering network unusable. In order to fix the issue, we're returning -EINVAL if anybody tries to add VLAN ID #1. While at that, also filter out any ID 4095 because we only have 12 bits for VLAN IDs. Fixes: 3b72c2f (drivers: net:ethernet: cpsw: add support for VLAN) Cc: sta...@vger.kernel.org # v3.9+ Cc: Mugunthan V N mugunthan...@ti.com Tested-by: Schuyler Patton spat...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com You can't just unilaterally make one VLAN ID unusable. A better way to handle this situation must be found, and if that means turning off hw VLAN support completely, that's a much better alternative to this. I'm not applying this patch, sorry. -- 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: dts: Revert disabling of smc91x for n900
Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? 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] serial: 8250: Make ISA ports optional
On Tuesday 06 January 2015 09:32:02 Peter Hurley wrote: On 01/06/2015 08:13 AM, Arnd Bergmann wrote: On Monday 05 January 2015 22:09:45 Peter Hurley wrote: Some arches have no need to create unprobed 8250 ports; these phantom ports are primarily required for ISA ports which have no probe mechanism or to provide non-operational ports for userspace to configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls). Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers probed ports (ACPI/PNP, serial8250 platform devices, PCI, etc). Cc: Sebastian Andrzej Siewior bige...@linutronix.de Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@linaro.org Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Hurley pe...@hurleysoftware.com The intent is definitely right, but I think a better approach is possible. I haven't tried it here, but how about moving the serial8250_init function into a separate module, along with all the other parts that are only used for ISA devices, but leaving the actual core (all exported symbols) in this file? Unfortunately, I don't see a way to remove the stacked initialization without risking tons of breakage. Since later probes can find an already-existing port and re-initialize it, the probe order is crucial. For example, a PCI probe can find an existing serial8250 platform device port, resulting in only one device node. I'm probably missing something important, by why would that be any different if the PCI driver gets loaded first and the ISA driver second? And the configuration knob will be required on all arches anyway because that's how user-configurable device nodes are created. I think that's fine: The user-configurable ports are the same as the ISA or phantom ports we were talking about above, right? If those are part of a separate (possibly loadable) module, having a configuration knob is the obvious way to do it. A lot of architectures can just turn it off because they know exactly which ports are present and there is no need for user-configurability. The ones that don't know can load the module. At the same time, the serial8250_pnp_init/serial8250_pnp_exit calls can be removed from the serial8250_init function and become standalone initcalls. PNP probe must occur before the phantom ports are registered. See commit 835d844d1a28efba81d5aca7385e24c29d3a6db2 (8250_pnp: do pnp probe before legacy probe). Makes sense. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. No, that was actually really a good advice. You should try to bisect it. It doesn't take that long (I assume you are cross-compiling instead of doing native builds), also Linux maintainers are generally doing a very good job ensuring the tree is bisectable. I would do it myself, but so far I never have set up my N900 to play any audio and I don't have any reference points between good or bad. 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: dts: Revert disabling of smc91x for n900
* Tony Lindgren t...@atomide.com [150106 12:01]: * Aaro Koskinen aaro.koski...@iki.fi [150106 11:47]: Hi, On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150106 00:03]: On Mon 2015-01-05 15:02:29, Tony Lindgren wrote: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Normally, the early development boards should have separate dts file (then include common parts), no? In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found. Could you at least add a note to the dts file what is it? Because I always thought it is a bug. Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues? Seems to work fine with normal n900. Tested-by: Aaro Koskinen aaro.koski...@iki.fi OK good to hear, thanks for testing. I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default? You need to write the eeprom with ethtool from Linux, something like this: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] irqchip: omap-intc: fix legacy DMA regression
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.
Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().
A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.
Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Cc: sta...@vger.kernel.org # v3.18
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/irqchip/irq-omap-intc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
return ret;
}
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
{
int j, irq_base;
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
irq_base = 0;
}
- domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+ domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
irq_domain_simple_ops, NULL);
omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
{
int ret;
- if (node)
+ /*
+* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+* depends is still not ready for linear IRQ domains; because of that
+* we need to temporarily blacklist OMAP2 and OMAP3 devices from using
+* linear IRQ Domain until that driver is finally fixed.
+*/
+ if (of_device_is_compatible(node, ti,omap2-intc) ||
+ of_device_is_compatible(node, ti,omap3-intc)) {
+ struct resource res;
+
+ if (of_address_to_resource(node, 0, res))
+ return -ENOMEM;
+
+ base = res.start;
+ ret = omap_init_irq_legacy(base, node);
+ } else if (node) {
ret = omap_init_irq_of(node);
- else
- ret = omap_init_irq_legacy(base);
+ } else {
+ ret = omap_init_irq_legacy(base, NULL);
+ }
if (ret == 0)
omap_irq_enable_protection();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.19 on Nokia n900: audio quality awful
On Wed 2015-01-07 00:27:17, Aaro Koskinen wrote: On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote: On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.] u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know. I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module. Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin. But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? Yes, it works if I mount it later. It fails when done directly using root=, even with rootwait etc. Hard to believe, yes, but try it. You can watch the results on console. 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: DT support for OMAP3 ISP
* Ash Charles ashchar...@gmail.com [150106 12:45]: Hi, I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? No idea about the camera, but at least the legacy omap DMA calls need to be replaced or removed as the legacy DMA API will go away soon. For the media code, these can be viewed with: $ git grep omap_request_dma drivers/media/ Regards, Tony [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt-v2 [2] http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt -- 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] serial: 8250: Make ISA ports optional
On 01/06/2015 02:43 PM, Arnd Bergmann wrote: On Tuesday 06 January 2015 09:32:02 Peter Hurley wrote: On 01/06/2015 08:13 AM, Arnd Bergmann wrote: On Monday 05 January 2015 22:09:45 Peter Hurley wrote: Some arches have no need to create unprobed 8250 ports; these phantom ports are primarily required for ISA ports which have no probe mechanism or to provide non-operational ports for userspace to configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls). Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers probed ports (ACPI/PNP, serial8250 platform devices, PCI, etc). Cc: Sebastian Andrzej Siewior bige...@linutronix.de Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@linaro.org Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Hurley pe...@hurleysoftware.com The intent is definitely right, but I think a better approach is possible. I haven't tried it here, but how about moving the serial8250_init function into a separate module, along with all the other parts that are only used for ISA devices, but leaving the actual core (all exported symbols) in this file? Unfortunately, I don't see a way to remove the stacked initialization without risking tons of breakage. Since later probes can find an already-existing port and re-initialize it, the probe order is crucial. For example, a PCI probe can find an existing serial8250 platform device port, resulting in only one device node. I'm probably missing something important, by why would that be any different if the PCI driver gets loaded first and the ISA driver second? Well, the PCI driver would have the proper irq, for one. So, if the the platform driver re-initialized the port to the wrong irq... And the configuration knob will be required on all arches anyway because that's how user-configurable device nodes are created. I think that's fine: The user-configurable ports are the same as the ISA or phantom ports we were talking about above, right? Yes. If those are part of a separate (possibly loadable) module, having a configuration knob is the obvious way to do it. A lot of architectures can just turn it off because they know exactly which ports are present and there is no need for user-configurability. The ones that don't know can load the module. Let me give this some more thought. Regards, Peter Hurley -- 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: ethernet: cpsw: ignore VLAN ID 1
From: Felipe Balbi ba...@ti.com Date: Tue, 6 Jan 2015 14:31:19 -0600 What you're saying here is that you prefer to drop a feature that works for all other 1023 IDs because 1 ID is quirky. Sounds like overkill to me. The other option is to software fallback only for VLAN 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: DT support for OMAP3 ISP
Moikka, On Tue, Jan 06, 2015 at 01:42:18PM -0800, Tony Lindgren wrote: * Ash Charles ashchar...@gmail.com [150106 12:45]: Hi, I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? No idea about the camera, but at least the legacy omap DMA calls need to be replaced or removed as the legacy DMA API will go away soon. OMAP DMA is only used by the histogram block which can cope with PIO as well --- I think there at least was a #define for it. That's not a reason not to convert it however, it's just not as urgent it otherwise might be. I wonder if someone has patches for that already. Cc Laurent. -- Terveisin, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: DT support for OMAP3 ISP
Hi Charles, On Tue, Jan 06, 2015 at 12:42:12PM -0800, Ash Charles wrote: I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? Thanks for any insight, --Ash [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt-v2 [2] http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt Please use this one instead: It's much improved compared to what was there in the other branch: URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-046-dt That rebased on current media-tree.git doesn't work; for some reason the IOMMU doesn't get bound correctly to the ISP DT node. Something to figure out. Indeed it's not in mainline yet, although the delta is a lot smaller than it was back then, especially for the smiapp driver (which may not be relevant for you though). -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: 3.19 on Nokia n900: audio quality awful
On Wed, Jan 07, 2015 at 12:13:41AM +0100, Pavel Machek wrote: On Tue 2015-01-06 17:04:15, Felipe Balbi wrote: Hi, On Tue, Jan 06, 2015 at 11:56:14PM +0100, Pavel Machek wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.) yeah, just put a magnet or, if you have spare back covers, cut one so that you close it, but still allow you to put the thing on a development jig. Actually, it should be enough to kill a line from dts somewhere, no need to hack hardware for this. right Also, if why doesn't rootwait work ? You never have a new mmc node or is the mmc node changing names ? IIRC node and name are ok, but the mount just fails. As I don't have really weird. Specially since it works when you mount afterwards. development jig, I lack serial console and this kind of debugging is not easy. see if this helps: https://wiki.maemo.org/N900_Hardware_Hacking#Debug_ports -- balbi signature.asc Description: Digital signature
[GIT PULL] omap fixes against v3.19-rc1
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/fixes-rc1 for you to fetch changes up to 7ac72746aa9bb305fa74b44ec73eae99bbbe9b66: ARM: dts: Revert disabling of smc91x for n900 (2015-01-06 08:49:57 -0800) Fixes for omaps mostly to deal with dra7 timer issues and hypervisor mode. The other fixes are minor fixes for various boards. The summary of the fixes is: - Fix real-time counter rate typos for some frequencies - Fix counter frequency drift for am572x - Fix booting of secondary CPU in HYP mode - Fix n900 board name for legacy user space - Fix cpufreq in omap2plus_defconfig after Kconfig change - Fix dra7 qspi partitions And also, let's re-enable smc91x on some n900 boards that we have sitting in a few test boot systems after the boot loader dependencies got fixed. Lennart Sorensen (3): ARM: omap5/dra7xx: Fix frequency typos ARM: dra7xx: Fix counter frequency drift for AM572x errata i856 ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode Mugunthan V N (1): ARM: dts: dra7-evm: fix qspi device tree partition size Nishanth Menon (1): ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT Tony Lindgren (2): ARM: OMAP2+: Fix n900 board name for legacy user space ARM: dts: Revert disabling of smc91x for n900 arch/arm/boot/dts/dra7-evm.dts | 10 arch/arm/boot/dts/omap3-n900.dts | 4 +--- arch/arm/configs/omap2plus_defconfig | 2 +- arch/arm/mach-omap2/board-generic.c | 18 +++ arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/control.h| 4 arch/arm/mach-omap2/omap-headsmp.S | 21 + arch/arm/mach-omap2/omap-smp.c | 13 +-- arch/arm/mach-omap2/timer.c | 44 +++- 9 files changed, 100 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 14:28:57, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness. Now you are speaking for yourself or for TI? Thanks for your very valuable help. I know how to do a bisection, thank you. Pavel PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. -- (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: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. What issues are you seeing? 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: dts: Revert disabling of smc91x for n900
* Pali Rohár pali.ro...@gmail.com [150106 12:37]: On Tuesday 06 January 2015 21:17:59 Tony Lindgren wrote: Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly.. N900 uboot support is broken, see my email on uboot ML with bisected commits: http://lists.denx.de/pipermail/u-boot/2015-January/200154.html Oh my patches are against 2014-10 or something like that. No idea about the recent regression. 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: dts: Revert disabling of smc91x for n900
Hi, On Tue, Jan 06, 2015 at 11:54:55AM -0800, Tony Lindgren wrote: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. Does any other eeprom data need to be set? It seems to be all 0xff. I generated a mac from /dev/random and it shows up fine in those offsets and with ifconfig, but I still can't get a link up: ifconfig: SIOCSIFFLAGS: Cannot assign requested address 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: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 14:54:13, Felipe Balbi wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: On Tue 2015-01-06 14:28:57, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness. Now you are speaking for yourself or for TI? why bring my employer into the discussion ? Because you are speaking of getting help for free, and I don't remember getting any useful help from you; so I'd like to know who do you speak for. Thanks for your very valuable help. I know how to do a bisection, thank you. then please do it. No, sorry, I don't think that would be reasonable use of my time at this point. First steps are confirm it happens on other N900 boards, too, ruling out config issues at my part, and try to get verification from other development boards if they have same problems, because most other boards are easier to work with. 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: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 10:57:44PM +0100, Pavel Machek wrote: In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness. Now you are speaking for yourself or for TI? why bring my employer into the discussion ? Because you are speaking of getting help for free, and I don't are you not getting help for free ? remember getting any useful help from you; so I'd like to know who do how come ? I gave you a very helpful list of commands which will direct you at finding the root of the issue you found. you speak for. for myself. Thanks for your very valuable help. I know how to do a bisection, thank you. then please do it. No, sorry, I don't think that would be reasonable use of my time at this point. First steps are confirm it happens on other N900 boards, too, ruling out config issues at my part, and try to get verification from other development boards if they have same problems, because most other boards are easier to work with. you don't want to do due diligence with a bug *you* found, then there's no way people can help you out. Sorry. Good luck -- balbi signature.asc Description: Digital signature
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Wed, Jan 07, 2015 at 12:27:17AM +0200, Aaro Koskinen wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. -- balbi signature.asc Description: Digital signature
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: On Tue 2015-01-06 14:28:57, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness. Now you are speaking for yourself or for TI? why bring my employer into the discussion ? Thanks for your very valuable help. I know how to do a bisection, thank you. then please do it. PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. Then how do you know it changed from v3.18 to v3.19-rc ? Certainly you ran v3.18 on N900 to verify that audio quality was better with that kernel. Use the very same method during bisection. -- balbi signature.asc Description: Digital signature
Re: 3.19 on Nokia n900: audio quality awful
On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote: On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.] u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know. I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module. Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin. But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? I'm loading zImage using 0x directly from the PC. Same here. 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: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.] u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know. I'm loading zImage using 0x directly from the PC. For the audio: this should do the trick: root@n900:~# uname -a Linux n900 3.18.0-omap3-69644-g0ed746d #837 PREEMPT Sun Jan 4 22:30:24 CET 2015 armv7l GNU/Linux root@n900:~# alsactl init Found hardware: RX-51 Hardware is initialized using a generic method root@n900:~# cat /etc/debian_version 7.7 root@n900:~# mplayer /my2/* (audio actually works). I do have Pali's n900 changes applied. I guess I should try without them. Let me know if .config would help you. 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: dts: Revert disabling of smc91x for n900
* Aaro Koskinen aaro.koski...@iki.fi [150106 13:59]: Hi, On Tue, Jan 06, 2015 at 11:54:55AM -0800, Tony Lindgren wrote: Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do: # cat mac | ethtool -E eth0 offset 0x40 length 6 Then ethtool -e eth0 should show you the configuration. Does any other eeprom data need to be set? It seems to be all 0xff. I generated a mac from /dev/random and it shows up fine in those offsets and with ifconfig, but I still can't get a link up: ifconfig: SIOCSIFFLAGS: Cannot assign requested address Chances are you did not swap the mac address bits around and it's trying to use a reserved mac address now? The mac needs to be the other way around.. 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] net: ethernet: cpsw: ignore VLAN ID 1
Hi, On Tue, Jan 06, 2015 at 04:59:11PM -0500, David Miller wrote: From: Felipe Balbi ba...@ti.com Date: Tue, 6 Jan 2015 14:31:19 -0600 What you're saying here is that you prefer to drop a feature that works for all other 1023 IDs because 1 ID is quirky. Sounds like overkill to me. The other option is to software fallback only for VLAN 1. now we're talking. Keep in mind, however, that this IP runs on mere single-core cortex A8 and single-core cortex A9 devices which already have somewhat of a hard-time keeping up with the non-accelerated checksum calculations. But fair enough, if that's the way to go, it is the way to go. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
On 01/06/2015 11:27 AM, Suman Anna wrote:
Hi Paul,
On 01/06/2015 11:14 AM, Suman Anna wrote:
Hi Paul,
On 01/06/2015 02:14 AM, Lokesh Vutla wrote:
Hi Paul,
On Tuesday 06 January 2015 07:34 AM, Paul Walmsley wrote:
Roger, Lokesh, could you try this one instead?
Yep, the below patch works on AM437x.
Boot logs here: http://paste.ubuntu.com/9680938/
Thanks and regards,
Lokesh
It passes all the basic tests here except it does not boot on the 4460
VAR-SOM-OM - unclear why at this point - but it would be good to see if it
works on your AM4372 boards, since I don't have that one.
Looking at your rc3 log @
http://www.pwsan.com/omap/testlogs/test_v3.19-rc3/20150105224749/boot/4460varsomom/,
I do see a missing reg entry for mailbox, and that's the reason for your
hang because of the missing bail out in your new patch.
[0.261932] [ cut here ]
[0.261962] WARNING: CPU: 0 PID: 1 at
arch/arm/mach-omap2/omap_hwmod.c:2458 _init+0x3a0/0x3f0()
[0.261962] omap_hwmod: mailbox: doesn't have mpu register target base
...
...
[0.262329] ---[ end trace a1be72591db4662e ]---
Now that said, this is weird, since the reg property for mailbox is
defined in the base omap4.dtsi and should be inherited by the 4460
VAR-SOM-OM, unless you are booting with an old dtb.
regards
Suman
Test logs are here:
http://www.pwsan.com/omap/testlogs/hwmod_skip_only_remap_v3.19-rc/20150105171744/
- Paul
From 4f2e13bd2181e0ebede3aabc484aa2339830748a Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+ oh-name);
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node
*np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct
omap_hwmod *oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+ * If there's no need for the hwmod code to read or write to
+ * the IP block registers, bail out early before the ioremap()
+ */
+ if (!oh-class-sysc)
+ return 0;
+
Also, I am getting some additional warnings [1] w.r.t MPU hwmod when I
changed the pr_debug on the check on _init_mpu_rt_base returned value to
a WARN and return like before. These warnings seem to be because -ENXIO
is returned as MPU hwmod will be setup with _HWMOD_NO_MPU_PORT. By
moving the !oh-class-sysc check prior to the _int_flags check and
after the _save_mpu_port_index(oh) call, I get the log similar to 3.19-rc3.
Below test log is on BeagleBone black, and I have removed mailbox reg
from am33xx.dtsi as well for testing the patch.
regards
Suman
[1] http://slexy.org/view/s2bWsGSV1Y
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh,
void *data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index,
Re: DT support for OMAP3 ISP
(Fixed Laurent's e-mail.) Moikka, On Tue, Jan 06, 2015 at 01:42:18PM -0800, Tony Lindgren wrote: * Ash Charles ashchar...@gmail.com [150106 12:45]: Hi, I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? No idea about the camera, but at least the legacy omap DMA calls need to be replaced or removed as the legacy DMA API will go away soon. OMAP DMA is only used by the histogram block which can cope with PIO as well --- I think there at least was a #define for it. That's not a reason not to convert it however, it's just not as urgent it otherwise might be. I wonder if someone has patches for that already. Cc Laurent. -- Terveisin, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: 3.19 on Nokia n900: audio quality awful
* Felipe Balbi ba...@ti.com [150106 14:49]: Hi, On Wed, Jan 07, 2015 at 12:27:17AM +0200, Aaro Koskinen wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. AFAIK you need to use rootwait and make USB into loadable modules. Built in Ethernet won't work without the patch I posted earlier. 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: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 16:46:22, Felipe Balbi wrote: Hi, On Wed, Jan 07, 2015 at 12:27:17AM +0200, Aaro Koskinen wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.) 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: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 11:56:14PM +0100, Pavel Machek wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.) yeah, just put a magnet or, if you have spare back covers, cut one so that you close it, but still allow you to put the thing on a development jig. Also, if why doesn't rootwait work ? You never have a new mmc node or is the mmc node changing names ? -- balbi signature.asc Description: Digital signature
Re: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 17:04:15, Felipe Balbi wrote: Hi, On Tue, Jan 06, 2015 at 11:56:14PM +0100, Pavel Machek wrote: But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? yeah, rootwait should do it. No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.) yeah, just put a magnet or, if you have spare back covers, cut one so that you close it, but still allow you to put the thing on a development jig. Actually, it should be enough to kill a line from dts somewhere, no need to hack hardware for this. Also, if why doesn't rootwait work ? You never have a new mmc node or is the mmc node changing names ? IIRC node and name are ok, but the mount just fails. As I don't have development jig, I lack serial console and this kind of debugging is not easy. 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 v2] irqchip: omap-intc: fix legacy DMA regression
On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote: commit 55601c9f2467 (arm: omap: intc: switch over to linear irq domain) introduced a regression with SDMA legacy driver because that driver strictly depends on INTC's IRQs starting at NR_IRQs. Aparently irq_domain_add_linear() won't guarantee that, since we see a 7 IRQs difference when booting with and without the commit cited above. Until arch/arm/plat-omap/dma.c is properly fixed, we must maintain OMAP2/3 using irq_domain_add_legacy(). A FIXME note was added so people know to delete that code once that legacy DMA driver is fixed up. Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain) Cc: sta...@vger.kernel.org # v3.18 Tested-by: Aaro Koskinen aaro.koski...@iki.fi Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/irqchip/irq-omap-intc.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) Applied to irqchip/urgent. Thanks for taking care of the Fixes and stable tags! thx, Jason. -- 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: DT support for OMAP3 ISP
Thanks for the hints. I tried the suggested branch adding omap3isp data to the Overo device tree and device tree bindings for the mt9v032 device. I needed to manually modprobe omap3-isp but the camera was registered and I was able to use media-ctl to manipulate the v4l2 pipeline. I wasn't able to stream as v4l2 was reporting inappropriate ioctlold driver perhaps? I also tried changing the #define HIST_CONFIG_DMA 0 such that the histogram block uses PIO instead of using the deprecated omap_request_dma. I saw basically the same behaviour. What would be the correct/modern way to use DMA here? --Ash On Tue, Jan 6, 2015 at 2:11 PM, Sakari Ailus sakari.ai...@iki.fi wrote: (Fixed Laurent's e-mail.) Moikka, On Tue, Jan 06, 2015 at 01:42:18PM -0800, Tony Lindgren wrote: * Ash Charles ashchar...@gmail.com [150106 12:45]: Hi, I'm playing with the Caspa camera (mt9v032) and Overo on the 3.17 kernel. It looks like there has been some work on dt-bindings for the omap3isp (notably [1] and [2]) but I didn't see anything heading for mainline. What would be needed to support cameras using the omap3isp in a mainline kernel? No idea about the camera, but at least the legacy omap DMA calls need to be replaced or removed as the legacy DMA API will go away soon. OMAP DMA is only used by the histogram block which can cope with PIO as well --- I think there at least was a #define for it. That's not a reason not to convert it however, it's just not as urgent it otherwise might be. I wonder if someone has patches for that already. Cc Laurent. -- Terveisin, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: DRA7: beagle-x15: hwmod: Fix boot crash with DEBUG_LL
Hi, On Tue, Jan 06, 2015 at 09:17:59AM -0600, Nishanth Menon wrote: On 01/06/2015 09:08 AM, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 08:05:17AM -0600, Nishanth Menon wrote: For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig. Fixes: 90020c7 (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) Fixes: 90020c7b2c5e (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) what's the difference ? why do you want that many more characters if those 7 are enough for git to find a uniq commit ? Try this: $ git show --abbrev-commit 90020c7b2c5e02200bc752c8cfeba91c4435588c https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n160 alright, if it's Documented, it's best done ;-) -- balbi signature.asc Description: Digital signature
[PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
config steps except for the charge step. Previously charge step was 1 ADC
clock cycle and hence it was ignored.
TSC steps are always disabled at the end of each conversion cycle, hence
there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
Signed-off-by: Vignesh R vigne...@ti.com
---
v5:
- Remove unnecessary clearing of REG_SE
drivers/mfd/ti_am335x_tscadc.c | 13 +
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 467c80e1c4ae..e4e4b22eebc9 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
DEFINE_WAIT(wait);
u32 reg;
- /*
-* disable TSC steps so it does not run while the ADC is using it. If
-* write 0 while it is running (it just started or was already running)
-* then it completes all steps that were enabled and stops then.
-*/
- tscadc_writel(tsadc, REG_SE, 0);
reg = tscadc_readl(tsadc, REG_ADCFSM);
if (reg SEQ_STATUS) {
tsadc-adc_waiting = true;
@@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
spin_lock_irq(tsadc-reg_lock);
finish_wait(tsadc-reg_se_wait, wait);
+ /*
+* Sequencer should either be idle or
+* busy applying the charge step.
+*/
reg = tscadc_readl(tsadc, REG_ADCFSM);
- WARN_ON(reg SEQ_STATUS);
+ WARN_ON((reg SEQ_STATUS) !(reg CHARGE_STEP));
tsadc-adc_waiting = false;
}
tsadc-adc_in_use = true;
@@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
{
spin_lock_irq(tsadc-reg_lock);
- tsadc-reg_se_cache |= val;
am335x_tscadc_need_adc(tsadc);
tscadc_writel(tsadc, REG_SE, val);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 3f4e994ace2b..1fd50dcfe47c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -128,6 +128,7 @@
/* Sequencer Status */
#define SEQ_STATUS BIT(5)
+#define CHARGE_STEP0x11
#define ADC_CLK300
#define TOTAL_STEPS16
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Brad Griffis bgrif...@ti.com
TSC interrupt handler had udelay to avoid reporting of false pen-up
interrupt to user space. This patch implements workaround suggesting in
Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
and touchscreen lag. This also improves performance of touchscreen and
eliminates sudden jump of cursor at touch release.
IDLECONFIG and CHARGECONFIG registers are to be configured
with same values in order to eliminate false pen-up events. This
workaround may result in false pen-down to be detected, hence considerable
charge step delay needs to be added. The charge delay is set to 0xB000
(in terms of ADC clock cycles) by default.
TSC steps are disabled at the end of every sampling cycle and EOS bit is
set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
next sampling cycle.
Signed-off-by: Brad Griffis bgrif...@ti.com
[vigne...@ti.com: Ported the patch from v3.12 to v3.19rc1]
Signed-off-by: Vignesh R vigne...@ti.com
---
v5:
- enable TSC steps only on EOS interrup
v4:
- check for PEN_IRQ bit in ADCFSM to avoid false-pen when ADC
and TSC are used together.
- Set charge delay to 0x400 as default. Most devices function
normally at this value.
drivers/input/touchscreen/ti_am335x_tsc.c | 67 ++-
include/linux/mfd/ti_am335x_tscadc.h | 3 +-
2 files changed, 33 insertions(+), 37 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index dfbb9fe6a270..0625c102a1d0 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -173,11 +173,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- /* Charge step configuration */
- config = ts_dev-bit_xp | ts_dev-bit_yn |
- STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
- STEPCHARGE_INM_AN1 | STEPCHARGE_INP(ts_dev-inp_yp);
+ /* Make CHARGECONFIG same as IDLECONFIG */
+ config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
@@ -261,12 +259,34 @@ static irqreturn_t titsc_irq(int irq, void *dev)
{
struct titsc *ts_dev = dev;
struct input_dev *input_dev = ts_dev-input;
- unsigned int status, irqclr = 0;
+ unsigned int fsm, status, irqclr = 0;
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
- unsigned int fsm;
- status = titsc_readl(ts_dev, REG_IRQSTATUS);
+ status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
+ if (status IRQENB_HW_PEN) {
+ ts_dev-pen_down = true;
+ titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+ titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ irqclr |= IRQENB_HW_PEN;
+ }
+
+ if (status IRQENB_PENUP) {
+ fsm = titsc_readl(ts_dev, REG_ADCFSM);
+ if (fsm == ADCFSM_STEPID) {
+ ts_dev-pen_down = false;
+ input_report_key(input_dev, BTN_TOUCH, 0);
+ input_report_abs(input_dev, ABS_PRESSURE, 0);
+ input_sync(input_dev);
+ } else {
+ ts_dev-pen_down = true;
+ }
+ irqclr |= IRQENB_PENUP;
+ }
+
+ if (status IRQENB_EOS)
+ irqclr |= IRQENB_EOS;
+
/*
* ADC and touchscreen share the IRQ line.
* FIFO1 interrupts are used by ADC. Handle FIFO0 IRQs here only
@@ -297,37 +317,11 @@ static irqreturn_t titsc_irq(int irq, void *dev)
}
irqclr |= IRQENB_FIFO0THRES;
}
-
- /*
-* Time for sequencer to settle, to read
-* correct state of the sequencer.
-*/
- udelay(SEQ_SETTLE);
-
- status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
- if (status IRQENB_PENUP) {
- /* Pen up event */
- fsm = titsc_readl(ts_dev, REG_ADCFSM);
- if (fsm == ADCFSM_STEPID) {
- ts_dev-pen_down = false;
- input_report_key(input_dev, BTN_TOUCH, 0);
- input_report_abs(input_dev, ABS_PRESSURE, 0);
- input_sync(input_dev);
- } else {
- ts_dev-pen_down = true;
- }
- irqclr |= IRQENB_PENUP;
- }
-
- if (status IRQENB_HW_PEN) {
-
- titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
- titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
- }
-
if (irqclr) {
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
- am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
+ if (status IRQENB_EOS)
+
[PATCH v6 1/6] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Brad Griffis bgrif...@ti.com
This patch makes the initial changes required to workaround TSC-false
pen-up interrupts. It is required to implement these changes in order to
remove udelay in the TSC interrupt handler and false pen-up events.
The charge step is to be executed immediately after sampling X+. Hence
TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate
readouts, 4 wire TSC configuration) and ADC to use lower ones. Further
X co-ordinate readouts must be the last to be sampled, thus co-ordinates
are sampled in the order Y-Z-X.
Signed-off-by: Brad Griffis bgrif...@ti.com
[vigne...@ti.com: Ported the patch from v3.12 to v3.19rc1]
Signed-off-by: Vignesh R vigne...@ti.com
Acked-by: Jonathan Cameron ji...@kernel.org
---
drivers/iio/adc/ti_am335x_adc.c | 5 ++--
drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++-
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b730864731e8..adba23246474 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -86,19 +86,18 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
unsigned int stepconfig;
- int i, steps;
+ int i, steps = 0;
/*
* There are 16 configurable steps and 8 analog input
* lines available which are shared between Touchscreen and ADC.
*
-* Steps backwards i.e. from 16 towards 0 are used by ADC
+* Steps forwards i.e. from 0 towards 16 are used by ADC
* depending on number of input lines needed.
* Channel would represent which analog input
* needs to be given to ADC to digitalize data.
*/
- steps = TOTAL_STEPS - adc_dev-channels;
if (iio_buffer_enabled(indio_dev))
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
| STEPCONFIG_MODE_SWCNT;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 004f1346a957..dfbb9fe6a270 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
int i;
- int end_step;
+ int end_step, first_step, tsc_steps;
u32 stepenable;
config = STEPCONFIG_MODE_HWSYNC |
@@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* 1 … coordinate_readouts is for X */
- end_step = ts_dev-coordinate_readouts;
- for (i = 0; i end_step; i++) {
+ tsc_steps = ts_dev-coordinate_readouts * 2 + 2;
+ first_step = TOTAL_STEPS - tsc_steps;
+ /* Steps 16 to 16-coordinate_readouts is for X */
+ end_step = first_step + tsc_steps;
+ for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* coordinate_readouts … coordinate_readouts * 2 is for Y */
- end_step = ts_dev-coordinate_readouts * 2;
- for (i = ts_dev-coordinate_readouts; i end_step; i++) {
+ /* 1 ... coordinate_readouts is for Y */
+ end_step = first_step + ts_dev-coordinate_readouts;
+ for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
- /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
+ /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yp |
ts_dev-bit_xn | STEPCONFIG_INM_ADCREFM |
@@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
STEPCONFIG_OPENDLY);
- /* The steps1 … end and bit 0 for TS_Charge */
- stepenable = (1 (end_step + 2)) - 1;
+ /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
+ stepenable = 1;
+ for (i = 0; i tsc_steps; i++)
+ stepenable |= 1 (first_step + i + 1);
+
ts_dev-step_mask = stepenable;
am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
}
@@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
[PATCH v6 4/6] input: touchscreen: ti_am335x_tsc: Read charge delay from DT
This patch reads charge delay from tsc DT node and writes to
REG_CHARGEDELAY register. If the charge delay is not specified in DT
then default value of 0x400(CHARGEDLY_OPENDLY) is used.
Signed-off-by: Vignesh R vigne...@ti.com
---
v6:
- Move Documentation from DT patch to driver code.
v5:
- print out a warning when ti,charge-delay is not specified
v4:
- Set charge delay to 0x400 as default. Most devices function normally
at this value
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++
drivers/input/touchscreen/ti_am335x_tsc.c | 14 +-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..6c4fb34823d3 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -28,6 +28,20 @@ Required properties:
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Optional properties:
+- child tsc
+ ti,charge-delay: Length of touch screen charge delay step in terms of
+ADC clock cycles. Charge delay value should be large
+in order to avoid false pen-up events. This value
+effects the overall sampling speed, hence need to be
+kept as low as possible, while avoiding false pen-up
+event. Start from a lower value, say 0x400, and
+increase value until false pen-up events are avoided.
+The pen-up detection happens immediately after the
+charge step, so this does in fact function as a
+hardware knob for adjusting the amount of settling
+time.
+
Example:
tscadc: tscadc@44e0d000 {
compatible = ti,am3359-tscadc;
@@ -36,6 +50,7 @@ Example:
ti,x-plate-resistance = 200;
ti,coordiante-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ ti,charge-delay = 0x400;
};
adc {
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 0625c102a1d0..7c0f6b21559d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -52,6 +52,7 @@ struct titsc {
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
+ u32 charge_delay;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -177,7 +178,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
- titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
+ titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev-charge_delay);
/* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
@@ -368,6 +369,17 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err 0)
return err;
+ err = of_property_read_u32(node, ti,charge-delay,
+ ts_dev-charge_delay);
+ /*
+* If ti,charge-delay value is not specified, then use
+* CHARGEDLY_OPENDLY as the default value.
+*/
+ if (err 0) {
+ ts_dev-charge_delay = CHARGEDLY_OPENDLY;
+ dev_warn(pdev-dev, ti,charge-delay not specified\n);
+ }
+
return of_property_read_u32_array(node, ti,wire-config,
ts_dev-config_inp, ARRAY_SIZE(ts_dev-config_inp));
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/6] ARM: dts: AM335x: Make charge delay a DT parameter for TSC
The charge delay value is by default 0x400. But it can be set to lower
values on some boards, as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for TSC operation). In some boards, the value has to be
increased to avoid false pen-up events. Hence, charge delay has been
made a DT parameter.
Signed-off-by: Vignesh R vigne...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 54f118c08db8..66342515df20 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -648,6 +648,7 @@
ti,x-plate-resistance = 200;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ ti,charge-delay = 0x400;
};
adc {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/6] input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering
Previously, delta filtering was applied TSC co-ordinate readouts before
reporting a single value to user space. This patch replaces delta filtering
with median filtering. Median filtering sorts co-ordinate readouts, drops min
and max values, and reports the average of remaining values. This method is
more sensible than delta filering. Median filtering is applied only if number
of readouts is greater than 3 else just average of co-ordinate readouts is
reported.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 92 +--
1 file changed, 52 insertions(+), 40 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 7c0f6b21559d..191a1b87895f 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
#include linux/delay.h
#include linux/of.h
#include linux/of_device.h
+#include linux/sort.h
#include linux/mfd/ti_am335x_tscadc.h
@@ -204,56 +205,61 @@ static void titsc_step_config(struct titsc *ts_dev)
am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
}
+static int titsc_cmp_coord(const void *a, const void *b)
+{
+ return *(int *)a - *(int *)b;
+}
+
static void titsc_read_coordinates(struct titsc *ts_dev,
u32 *x, u32 *y, u32 *z1, u32 *z2)
{
- unsigned int fifocount = titsc_readl(ts_dev, REG_FIFO0CNT);
- unsigned int prev_val_x = ~0, prev_val_y = ~0;
- unsigned int prev_diff_x = ~0, prev_diff_y = ~0;
- unsigned int read, diff;
- unsigned int i, channel;
+ unsigned int yvals[7], xvals[7];
+ unsigned int i, xsum = 0, ysum = 0;
unsigned int creads = ts_dev-coordinate_readouts;
- unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
- *z1 = *z2 = 0;
- if (fifocount % (creads * 2 + 2))
- fifocount -= fifocount % (creads * 2 + 2);
- /*
-* Delta filter is used to remove large variations in sampled
-* values from ADC. The filter tries to predict where the next
-* coordinate could be. This is done by taking a previous
-* coordinate and subtracting it form current one. Further the
-* algorithm compares the difference with that of a present value,
-* if true the value is reported to the sub system.
-*/
- for (i = 0; i fifocount; i++) {
- read = titsc_readl(ts_dev, REG_FIFO0);
-
- channel = (read 0xf) 16;
- read = 0xfff;
- if (channel first_step + creads + 2) {
- diff = abs(read - prev_val_x);
- if (diff prev_diff_x) {
- prev_diff_x = diff;
- *x = read;
- }
- prev_val_x = read;
+ for (i = 0; i creads; i++) {
+ yvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ yvals[i] = 0xfff;
+ }
- } else if (channel == first_step + creads + 1) {
- *z1 = read;
+ *z1 = titsc_readl(ts_dev, REG_FIFO0);
+ *z1 = 0xfff;
+ *z2 = titsc_readl(ts_dev, REG_FIFO0);
+ *z2 = 0xfff;
- } else if (channel == first_step + creads + 2) {
- *z2 = read;
+ for (i = 0; i creads; i++) {
+ xvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ xvals[i] = 0xfff;
+ }
- } else if (channel first_step) {
- diff = abs(read - prev_val_y);
- if (diff prev_diff_y) {
- prev_diff_y = diff;
- *y = read;
- }
- prev_val_y = read;
+ /*
+* If co-ordinates readouts is less than 4 then
+* report the average. In case of 4 or more
+* readouts, sort the co-ordinate samples, drop
+* min and max values and report the average of
+* remaining values.
+*/
+ if (creads = 3) {
+ for (i = 0; i creads; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
}
+ ysum /= creads;
+ xsum /= creads;
+ } else {
+ sort(yvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ sort(xvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ for (i = 1; i creads - 1; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
+ }
+ ysum /= creads - 2;
+ xsum /= creads - 2;
}
+ *y = ysum;
+ *x = xsum;
}
static irqreturn_t titsc_irq(int irq, void *dev)
@@ -369,6 +375,12 @@ static int titsc_parse_dt(struct platform_device *pdev,
[PATCH v6 0/6] Touchscreen performance related fixes
This series is rebase of v4 onto v3.19-rc1. It also fixes concerns expressed on v4 wrt simultaneous use of IIO and TSC. I have tested this patch series on am335x-evm and Beaglebone black with lcd7-cape. Note that, these patches do not work as expected on Beaglebone Black with BB-View 4.3 Cape from Farnell due to a hardware issue in the cape. Change log: v6: - Reorder patch 4 and 5. v5: - Rebased onto v3.19-rc1 - minor changes in patch 2,3 and 5. v3: - Replace delta filtering logic in TSC driver with median filtering as suggested by Richard. - Addressed Lee Jones comments. v2: - Addressed comments by Hartmut Knaack - patch 2 was split into two as per Lee Jones comment Brad Griffis (2): input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler Vignesh R (4): mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save input: touchscreen: ti_am335x_tsc: Read charge delay from DT ARM: dts: AM335x: Make charge delay a DT parameter for TSC input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering .../bindings/input/touchscreen/ti-tsc-adc.txt | 15 ++ arch/arm/boot/dts/am335x-evm.dts | 1 + drivers/iio/adc/ti_am335x_adc.c| 5 +- drivers/input/touchscreen/ti_am335x_tsc.c | 197 - drivers/mfd/ti_am335x_tscadc.c | 13 +- include/linux/mfd/ti_am335x_tscadc.h | 4 +- 6 files changed, 137 insertions(+), 98 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] ARM: dts: AM335x: Make charge delay a DT parameter for TSC
On Friday 02 January 2015 10:39 PM, Tony Lindgren wrote:
* Vignesh R vigne...@ti.com [141223 23:07]:
The charge delay value is by default 0x400. But it can be set to lower
values on some boards, as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for TSC operation). In some boards, the value has to be
increased to avoid false pen-up events. Hence, charge delay has been
made a DT parameter.
Signed-off-by: Vignesh R vigne...@ti.com
Assuming this binding makes sense for the input people, there should
be no conflicts merging this patch along with the rest of the series
via the input tree.
I will post new version moving documentation to driver code and keeping
DT changes as a separate patch.
Sounds like this value probably depends on the size of the touchscreen
for the capacitance, so a numeric value is really needed here.
Its not just dependent on the size of the touchscreen. It varies based
on the individual setups.
I would personally prefer generic bindings in general, but in any case
There isn't any generic binding that corresponds to charge-delay.
Nothing as been pointed out by input maintainer either.
Regards
Vignesh
please feel free to merge along with the other input patches:
Acked-by: Tony Lindgren t...@atomide.com
---
v4:
- Set charge delay to 0x400 as default. Most devices function normally
at this value
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15
+++
arch/arm/boot/dts/am335x-evm.dts | 1 +
2 files changed, 16 insertions(+)
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..6df5028a4ad3 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -28,6 +28,20 @@ Required properties:
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Optional properties:
+- child tsc
+ti,charge-delay: Length of touch screen charge delay step in terms of
+ ADC clock cycles. Charge delay value should be large
+ in order to avoid false pen-up events. This value
+ affects the overall sampling speed, hence need to be
+ kept as low as possible, while avoiding false pen-up
+ event. Start from a lower value, say 0x400, and
+ increase value until false pen-up events are avoided.
+ The pen-up detection happens immediately after the
+ charge step, so this does in fact function as a
+ hardware knob for adjusting the amount of settling
+ time.
+
Example:
tscadc: tscadc@44e0d000 {
compatible = ti,am3359-tscadc;
@@ -36,6 +50,7 @@ Example:
ti,x-plate-resistance = 200;
ti,coordiante-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ti,charge-delay = 0x400;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 54f118c08db8..66342515df20 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -648,6 +648,7 @@
ti,x-plate-resistance = 200;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ti,charge-delay = 0x400;
};
adc {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.19 on Nokia n900: audio quality awful
On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. 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] irqchip: omap-intc: fix legacy DMA regression
* Aaro Koskinen aaro.koski...@iki.fi [150106 09:51]:
On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.
Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().
A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.
Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi ba...@ti.com
I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the In-band Error is gone.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...
Yeah this one should be cc stable. Fixes the error for me too:
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/irqchip/irq-omap-intc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c
b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node
*node)
return ret;
}
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
{
int j, irq_base;
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
irq_base = 0;
}
- domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+ domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
irq_domain_simple_ops, NULL);
omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
{
int ret;
- if (node)
+ /*
+* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+* depends is still not ready for linear IRQ domains; because of that
+* we need to temporarily blacklist OMAP2 and OMAP3 devices from using
+* linear IRQ Domain until that driver is finally fixed.
+*/
+ if (of_device_is_compatible(node, ti,omap2-intc) ||
+ of_device_is_compatible(node, ti,omap3-intc)) {
+ struct resource res;
+
+ if (of_address_to_resource(node, 0, res))
+ return -ENOMEM;
+
+ base = res.start;
+ ret = omap_init_irq_legacy(base, node);
+ } else if (node) {
ret = omap_init_irq_of(node);
- else
- ret = omap_init_irq_legacy(base);
+ } else {
+ ret = omap_init_irq_legacy(base, NULL);
+ }
if (ret == 0)
omap_irq_enable_protection();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression
On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote: + /* + * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c + * depends is still not ready for linear IRQ domains; because of that + * we need to temporarily blacklist OMAP2 and OMAP3 devices from using + * linear IRQ Domain until that driver is finally fixed. finally fixed or finally killed off like it really needs to be, once all users of it are killed. We've been trying to do this for, what, three years now... I finally pushed a WARN_ON() into that code to make it obvious to anyone who uses omap_request_dma() that they really need to update their code. Here's the list of references to that symbol which *still* need to be fixed so that we can kill the legacy DMA driver: drivers/media/platform/omap/omap_vout_vrfb.c: ret = omap_request_dma(vout-vrfb_dma_tx.dev_id, VRFB DMA TX, drivers/media/platform/omap3isp/isphist.c: ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, DMA_ISP_HIST, drivers/media/platform/soc_camera/omap1_camera.c: err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME, drivers/mtd/onenand/omap2.c:r = omap_request_dma(0, pdev-dev.driver-name, drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, drivers/usb/musb/tusb6010_omap.c: ret = omap_request_dma(chdat-sync_dev, dev_name, drivers/usb/musb/tusb6010_omap.c: ret = omap_request_dma(tusb_dma-sync_dev, TUSB shared, -- 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] irqchip: omap-intc: fix legacy DMA regression
Hi, On Tue, Jan 06, 2015 at 06:05:32PM +, Russell King - ARM Linux wrote: On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote: +* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c +* depends is still not ready for linear IRQ domains; because of that +* we need to temporarily blacklist OMAP2 and OMAP3 devices from using +* linear IRQ Domain until that driver is finally fixed. finally fixed or finally killed off like it really needs to be, once all users of it are killed. We've been trying to do this for, what, three years now... I finally pushed a WARN_ON() into that code to make it obvious to anyone who uses omap_request_dma() that they really need to update their code. Here's the list of references to that symbol which *still* need to be fixed so that we can kill the legacy DMA driver: drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, I only learned about this after the WARN_ON() appeared in 3.17 (just couple months ago), and it's on my TODO list... 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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Paul,
On 01/06/2015 02:14 AM, Lokesh Vutla wrote:
Hi Paul,
On Tuesday 06 January 2015 07:34 AM, Paul Walmsley wrote:
Roger, Lokesh, could you try this one instead?
Yep, the below patch works on AM437x.
Boot logs here: http://paste.ubuntu.com/9680938/
Thanks and regards,
Lokesh
It passes all the basic tests here except it does not boot on the 4460
VAR-SOM-OM - unclear why at this point - but it would be good to see if it
works on your AM4372 boards, since I don't have that one.
Test logs are here:
http://www.pwsan.com/omap/testlogs/hwmod_skip_only_remap_v3.19-rc/20150105171744/
- Paul
From 4f2e13bd2181e0ebede3aabc484aa2339830748a Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+ oh-name);
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node
*np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+/*
+ * If there's no need for the hwmod code to read or write to
+ * the IP block registers, bail out early before the ioremap()
+ */
+if (!oh-class-sysc)
+return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
-if (oh-class-sysc) {
-r = _init_mpu_rt_base(oh, NULL, index, np);
-if (r 0) {
-WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
- oh-name);
-return 0;
-}
-}
+r = _init_mpu_rt_base(oh, NULL, index, np);
+if (r 0)
+pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+ oh-name);
You have removed the return from the above block on failure. If any DT
entry doesn't have the reg property, this will hang the kernel boot.
Just remove the reg entry from any of the existing DT, and you will
run into the issue, this is what 6423d6df1440 (ARM: OMAP2+: hwmod:
check for module address space during init) fixed. Also, are you sure
you want to turn the WARN into a pr_debug, it won't even show during the
kernel boot log if the reg base is missing.
regards
Suman
r = _init_clocks(oh, NULL);
if (r 0) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: ethernet: cpsw: ignore VLAN ID 1
CPSW completely hangs if we add, and later remove, VLAN ID #1. What happens is that after removing VLAN ID #1, no packets will be received by CPSW rendering network unusable. In order to fix the issue, we're returning -EINVAL if anybody tries to add VLAN ID #1. While at that, also filter out any ID 4095 because we only have 12 bits for VLAN IDs. Fixes: 3b72c2f (drivers: net:ethernet: cpsw: add support for VLAN) Cc: sta...@vger.kernel.org # v3.9+ Cc: Mugunthan V N mugunthan...@ti.com Tested-by: Schuyler Patton spat...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/net/ethernet/ti/cpsw.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index e61ee8351272..028bb7f3de65 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -1669,6 +1669,13 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev, if (vid == priv-data.default_vlan) return 0; + /* NOTICE: CPSW does not support VID 1. We should +* also filter out VID 4095 as we only have 12 +* bits for VID entries +*/ + if (vid == 1 || vid = VLAN_N_VID) + return -EINVAL; + dev_info(priv-dev, Adding vlanid %d to vlan filter\n, vid); return cpsw_add_vlan_ale_entry(priv, vid); } @@ -1682,6 +1689,13 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev, if (vid == priv-data.default_vlan) return 0; + /* NOTICE: CPSW does not support VID 1. We should +* also filter out VID 4095 as we only have 12 +* bits for VID entries +*/ + if (vid == 1 || vid = VLAN_N_VID) + return -EINVAL; + dev_info(priv-dev, removing vlanid %d from vlan filter\n, vid); ret = cpsw_ale_del_vlan(priv-ale, vid, 0); if (ret != 0) -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] irqchip: omap-intc: fix legacy DMA regression
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.
Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().
A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.
Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/irqchip/irq-omap-intc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
return ret;
}
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
{
int j, irq_base;
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
irq_base = 0;
}
- domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+ domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
irq_domain_simple_ops, NULL);
omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
{
int ret;
- if (node)
+ /*
+* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+* depends is still not ready for linear IRQ domains; because of that
+* we need to temporarily blacklist OMAP2 and OMAP3 devices from using
+* linear IRQ Domain until that driver is finally fixed.
+*/
+ if (of_device_is_compatible(node, ti,omap2-intc) ||
+ of_device_is_compatible(node, ti,omap3-intc)) {
+ struct resource res;
+
+ if (of_address_to_resource(node, 0, res))
+ return -ENOMEM;
+
+ base = res.start;
+ ret = omap_init_irq_legacy(base, node);
+ } else if (node) {
ret = omap_init_irq_of(node);
- else
- ret = omap_init_irq_legacy(base);
+ } else {
+ ret = omap_init_irq_legacy(base, NULL);
+ }
if (ret == 0)
omap_irq_enable_protection();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pavel Machek pa...@ucw.cz [150106 00:03]:
On Mon 2015-01-05 15:02:29, Tony Lindgren wrote:
Revert ARM: dts: Disable smc91x on n900 until bootloader
dependency is removed. We've now fixed the issues that
caused problems with uninitialized hardware depending on
the bootloader version. Mostly things got fixed with
the following commits:
9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900
smc91x pins)
7d2911c43815 (net: smc91x: Fix gpios for device tree based booting)
Note that this only affects the early development boards
with Ethernet that we still have in a few automated boot
test systems.
Signed-off-by: Tony Lindgren t...@atomide.com
Normally, the early development boards should have separate dts file
(then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe
just fails if no smsc91x is found.
Could you at least add a note to the dts file what is it? Because I
always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on
a production n900 too to make sure it no longer causes issues?
[Plus of course, obviouse question is: where can I get one of those
boards? :-)]
Another planet a long time ago :)
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Tue, 6 Jan 2015 08:49:57 -0800
Subject: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Revert ARM: dts: Disable smc91x on n900 until bootloader
dependency is removed. We've now fixed the issues that
caused problems with uninitialized hardware depending on
the bootloader version. Mostly things got fixed with
the following commits:
9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900
smc91x pins)
7d2911c43815 (net: smc91x: Fix gpios for device tree based booting)
Note that this only affects the early development boards
with Ethernet that we still have in a few automated boot
test systems. And it's also available supposedly in some
versions of qemu.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -700,11 +700,9 @@
};
};
+ /* Ethernet is on some early development boards and qemu */
ethernet@gpmc {
compatible = smsc,lan91c94;
-
- status = disabled;
-
interrupt-parent = gpio2;
interrupts = 22 IRQ_TYPE_LEVEL_HIGH; /* gpio54 */
reg = 1 0x300 0xf;/* 16 byte IO range at offset
0x300 */
--
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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Paul,
On 01/06/2015 11:14 AM, Suman Anna wrote:
Hi Paul,
On 01/06/2015 02:14 AM, Lokesh Vutla wrote:
Hi Paul,
On Tuesday 06 January 2015 07:34 AM, Paul Walmsley wrote:
Roger, Lokesh, could you try this one instead?
Yep, the below patch works on AM437x.
Boot logs here: http://paste.ubuntu.com/9680938/
Thanks and regards,
Lokesh
It passes all the basic tests here except it does not boot on the 4460
VAR-SOM-OM - unclear why at this point - but it would be good to see if it
works on your AM4372 boards, since I don't have that one.
Looking at your rc3 log @
http://www.pwsan.com/omap/testlogs/test_v3.19-rc3/20150105224749/boot/4460varsomom/,
I do see a missing reg entry for mailbox, and that's the reason for your
hang because of the missing bail out in your new patch.
[0.261932] [ cut here ]
[0.261962] WARNING: CPU: 0 PID: 1 at
arch/arm/mach-omap2/omap_hwmod.c:2458 _init+0x3a0/0x3f0()
[0.261962] omap_hwmod: mailbox: doesn't have mpu register target base
...
...
[0.262329] ---[ end trace a1be72591db4662e ]---
Now that said, this is weird, since the reg property for mailbox is
defined in the base omap4.dtsi and should be inherited by the 4460
VAR-SOM-OM, unless you are booting with an old dtb.
regards
Suman
Test logs are here:
http://www.pwsan.com/omap/testlogs/hwmod_skip_only_remap_v3.19-rc/20150105171744/
- Paul
From 4f2e13bd2181e0ebede3aabc484aa2339830748a Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+oh-name);
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node
*np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct
omap_hwmod *oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+* If there's no need for the hwmod code to read or write to
+* the IP block registers, bail out early before the ioremap()
+*/
+ if (!oh-class-sysc)
+ return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
-oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+oh-name);
You have removed the return from the above block on failure. If any DT
entry doesn't have the reg property, this will hang the kernel boot.
Just remove the reg entry from any of the existing DT, and you will
run into the issue, this is what 6423d6df1440
Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression
On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.
Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().
A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.
Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi ba...@ti.com
I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the In-band Error is gone.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...
A.
---
drivers/irqchip/irq-omap-intc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node
*node)
return ret;
}
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
{
int j, irq_base;
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
irq_base = 0;
}
- domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+ domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
irq_domain_simple_ops, NULL);
omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
{
int ret;
- if (node)
+ /*
+ * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+ * depends is still not ready for linear IRQ domains; because of that
+ * we need to temporarily blacklist OMAP2 and OMAP3 devices from using
+ * linear IRQ Domain until that driver is finally fixed.
+ */
+ if (of_device_is_compatible(node, ti,omap2-intc) ||
+ of_device_is_compatible(node, ti,omap3-intc)) {
+ struct resource res;
+
+ if (of_address_to_resource(node, 0, res))
+ return -ENOMEM;
+
+ base = res.start;
+ ret = omap_init_irq_legacy(base, node);
+ } else if (node) {
ret = omap_init_irq_of(node);
- else
- ret = omap_init_irq_legacy(base);
+ } else {
+ ret = omap_init_irq_legacy(base, NULL);
+ }
if (ret == 0)
omap_irq_enable_protection();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/14] mfd: twl6040: Constify struct regmap_config and reg_default array
* Krzysztof Kozlowski k.kozlow...@samsung.com [150105 01:04]:
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const. Make array of
struct reg_default const as well.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
---
drivers/mfd/twl6040.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 9687645162ae..f71ee3dbc2a2 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -44,7 +44,7 @@
#define VIBRACTRL_MEMBER(reg) ((reg == TWL6040_REG_VIBCTLL) ? 0 : 1)
#define TWL6040_NUM_SUPPLIES (2)
-static struct reg_default twl6040_defaults[] = {
+static const struct reg_default twl6040_defaults[] = {
{ 0x01, 0x4B }, /* REG_ASICID (ro) */
{ 0x02, 0x00 }, /* REG_ASICREV (ro) */
{ 0x03, 0x00 }, /* REG_INTID*/
@@ -580,7 +580,7 @@ static bool twl6040_writeable_reg(struct device *dev,
unsigned int reg)
}
}
-static struct regmap_config twl6040_regmap_config = {
+static const struct regmap_config twl6040_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.19 on Nokia n900: audio quality awful
On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5] mfd: tps65218: make INT1 our status_base register
On Fri, Dec 26, 2014 at 01:28:21PM -0600, Felipe Balbi wrote:
If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
ping
---
drivers/mfd/tps65218.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 2243f75..d6b7643 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -204,6 +204,7 @@ static struct regmap_irq_chip tps65218_irq_chip = {
.num_regs = 2,
.mask_base = TPS65218_REG_INT_MASK1,
+ .status_base = TPS65218_REG_INT1,
};
static const struct of_device_id of_tps65218_match_table[] = {
--
2.2.0
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5] mfd: tps65218: make INT[12] and STATUS registers volatile
On Fri, Dec 26, 2014 at 01:28:20PM -0600, Felipe Balbi wrote:
STATUS register can be modified by the HW, so we
should bypass cache because of that.
In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
ping
---
drivers/mfd/tps65218.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 0d256cb..2243f75 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -125,10 +125,21 @@ int tps65218_clear_bits(struct tps65218 *tps, unsigned
int reg,
}
EXPORT_SYMBOL_GPL(tps65218_clear_bits);
+static const struct regmap_range tps65218_yes_ranges[] = {
+ regmap_reg_range(TPS65218_REG_INT1, TPS65218_REG_INT2),
+ regmap_reg_range(TPS65218_REG_STATUS, TPS65218_REG_STATUS),
+};
+
+static const struct regmap_access_table tps65218_volatile_table = {
+ .yes_ranges = tps65218_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tps65218_yes_ranges),
+};
+
static struct regmap_config tps65218_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.cache_type = REGCACHE_RBTREE,
+ .volatile_table = tps65218_volatile_table,
};
static const struct regmap_irq tps65218_irqs[] = {
--
2.2.0
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Tony Lindgren t...@atomide.com writes: Revert ARM: dts: Disable smc91x on n900 until bootloader dependency is removed. We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits: 9a894953a97b (ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins) 7d2911c43815 (net: smc91x: Fix gpios for device tree based booting) Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. Signed-off-by: Tony Lindgren t...@atomide.com Tested-by: Kevin Hilman khil...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.19 on Nokia n900: audio quality awful
Hi! In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? Thanks, 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
v3.18: Audio recording, Nokia N900
Hi! I tried to get latency example from ALSA to work (it basically records audio, pauses for a while, then plays it back) on N900, and all I'm getting is silence... plus now it oopsed. Any idea? Is there any version where audio recording works? What do you use for testing? Are there any mixer settings I should know about? Thanks, Pavel [ 4207.949096] omap_i2c 48072000.i2c: controller timed out [ 4207.950836] power_supply bq24150a-0: driver failed to report `status' property: -110 [ 4216.949035] omap_i2c 4807.i2c: controller timed out [ 4216.951354] twl: Write failed (mod 14, reg 0x06 count 2) [ 4216.953613] twl4030_madc 4807.i2c:twl@48:madc: unable to write sel register 0x6 [ 4216.956207] rx51-battery n900-battery: Could not read ADC: -110 [ 4217.969085] omap_i2c 4807.i2c: controller timed out [ 4217.972259] twl: Write failed (mod 14, reg 0x06 count 2) [ 4217.975372] twl4030_madc 4807.i2c:twl@48:madc: unable to write sel register 0x6 [ 4217.978790] rx51-battery n900-battery: Could not read ADC: -110 [ 4218.989135] omap_i2c 4807.i2c: controller timed out [ 4218.993164] twl: Write failed (mod 14, reg 0x06 count 2) [ 4218.997100] twl4030_madc 4807.i2c:twl@48:madc: unable to write sel register 0x6 [ 4219.959686] rx51-battery n900-battery: Could not read ADC: -110 [ 4220.959136] omap_i2c 4807.i2c: controller timed out [ 4220.963989] twl: Write failed (mod 14, reg 0x06 count 2) [ 4220.968749] twl4030_madc 4807.i2c:twl@48:madc: unable to write sel register 0x6 [ 4220.993530] rx51-battery n900-battery: Could not read ADC: -110 [ 4222.959136] omap_i2c 48072000.i2c: controller timed out [ 4226.639495] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa070004 [ 4226.645568] Internal error: : 1028 [#1] PREEMPT ARM [ 4226.651519] Modules linked in: [ 4226.657531] CPU: 0 PID: 737 Comm: irq/225-4807000 Tainted: G W 3.18.0-omap3-69644-g0ed746d #837 [ 4226.670471] task: cf000c00 ti: cf094000 task.ti: cf094000 [ 4226.677307] PC is at omap_i2c_isr_thread+0x44/0x414 [ 4226.684295] LR is at walk_stackframe+0x24/0x40 [ 4226.691375] pc : [c036dcdc]lr : [c00113d8]psr: 6093 [ 4226.691375] sp : cf095ee8 ip : cf095e80 fp : cf095f14 [ 4226.706146] r10: c0065744 r9 : cf000810 r8 : 2013 [ 4226.713409] r7 : 0002 r6 : 0004 r5 : r4 : 0065 [ 4226.720611] r3 : cf000c00 r2 : fa070004 r1 : fa07 r0 : 0001 [ 4226.727600] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 4226.734741] Control: 10c5387d Table: 8f058019 DAC: 0015 [ 4226.741821] Process irq/225-4807000 (pid: 737, stack limit = 0xcf094238) [ 4226.748870] Stack: (0xcf095ee8 to 0xcf096000) [ 4226.755859] 5ee0: c036dc98 cf027bc0 cf094000 cf8e9240 cf8e9240 cf8e9294 [ 4226.763122] 5f00: c0065744 cf095f34 cf095f18 c0065768 c036dca4 cf000c00 cf027bc0 [ 4226.770385] 5f20: cf094000 0001 cf095f64 cf095f38 c0065508 c0065750 c0065684 [ 4226.777526] 5f40: cf027c00 cf027bc0 c0065424 cf095fac cf095f68 [ 4226.784698] 5f60: c0050d2c c0065430 cf095f94 c0055854 cf027bc0 cf095f7c [ 4226.791839] 5f80: cf095f7c cf095f88 cf095f88 cf027c00 c0050c64 [ 4226.798950] 5fa0: cf095fb0 c000ebd8 c0050c70 [ 4226.805969] 5fc0: [ 4226.812896] 5fe0: 0013 edff7fff fffbfffe [ 4226.819702] Backtrace: [ 4226.826324] [c036dc98] (omap_i2c_isr_thread) from [c0065768] (irq_thread_fn+0x24/0x3c) [ 4226.833221] r10:c0065744 r9: r8:cf8e9294 r7:cf8e9240 r6:cf8e9240 r5:cf094000 [ 4226.840301] r4:cf027bc0 r3:c036dc98 [ 4226.847106] [c0065744] (irq_thread_fn) from [c0065508] (irq_thread+0xe4/0x12c) [ 4226.854034] r6:0001 r5:cf094000 r4:cf027bc0 r3:cf000c00 [ 4226.861083] [c0065424] (irq_thread) from [c0050d2c] (kthread+0xc8/0xe4) [ 4226.868072] r10: r8: r7:c0065424 r6:cf027bc0 r5:cf027c00 r4: [ 4226.875213] [c0050c64] (kthread) from [c000ebd8] (ret_from_fork+0x14/0x3c) [ 4226.882263] r7: r6: r5:c0050c64 r4:cf027c00 [ 4226.889373] Code: e599200c e5991004 e5d1 e0812210 (e1d210b0) [ 4227.101501] ---[ end trace 43582f7728e0496b ]--- [ 4227.108642] note: irq/225-4807000[737] exited with preempt_count 1 [ 4227.115905] Unable to handle kernel paging request at virtual address fff0 [ 4227.123321] pgd = c0004000 [ 4227.130584] [fff0] *pgd=8fefd821, *pte=, *ppte= [ 4227.138214] Internal error: Oops: 17 [#2] PREEMPT ARM [ 4227.145660] Modules linked in: [ 4227.152954] CPU: 0 PID: 737 Comm: irq/225-4807000 Tainted: G D W 3.18.0-omap3-69644-g0ed746d #837 [ 4227.167785] task: cf000c00 ti: cf094000 task.ti: cf094000 [ 4227.175201] PC is at kthread_data+0x10/0x18 [ 4227.182525] LR is
Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression
* Russell King - ARM Linux li...@arm.linux.org.uk [150106 10:08]: On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote: + /* +* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c +* depends is still not ready for linear IRQ domains; because of that +* we need to temporarily blacklist OMAP2 and OMAP3 devices from using +* linear IRQ Domain until that driver is finally fixed. finally fixed or finally killed off like it really needs to be, once all users of it are killed. We've been trying to do this for, what, three years now... I finally pushed a WARN_ON() into that code to make it obvious to anyone who uses omap_request_dma() that they really need to update their code. Here's the list of references to that symbol which *still* need to be fixed so that we can kill the legacy DMA driver: drivers/media/platform/omap/omap_vout_vrfb.c: ret = omap_request_dma(vout-vrfb_dma_tx.dev_id, VRFB DMA TX, drivers/media/platform/omap3isp/isphist.c: ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, DMA_ISP_HIST, drivers/media/platform/soc_camera/omap1_camera.c: err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME, drivers/mtd/onenand/omap2.c:r = omap_request_dma(0, pdev-dev.driver-name, AFAIK we should just remove DMA support from the drivers above. Nobody seems to be interested in doing anything about them. drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, OK so Aaro picked this one. drivers/usb/musb/tusb6010_omap.c: ret = omap_request_dma(chdat-sync_dev, dev_name, drivers/usb/musb/tusb6010_omap.c: ret = omap_request_dma(tusb_dma-sync_dev, TUSB shared, I'll update this one. FYI, I already have some work-in-progress MUSB DMA patches that allow building in all the MUSB DMA glue layers. I just need to finish that series for v3.20: https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=musb-dma-2014-11-25-v2 So converting tusb6010 over to the dmaengine API would be the next logical step after that series. Probably not going to happen before v3.21 though.. 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
