Re: [PATCH] watchdog: omap_wdt: fix null pointer dereference
On Wednesday 04 November 2015 02:20:20, Peter Robinson wrote:
> Fix issue from two patches overlapping causing a kernel oops
>
> [ 3569.297449] Unable to handle kernel NULL pointer dereference at virtual
> address 0088 [ 3569.306272] pgd = dc894000
> [ 3569.309287] [0088] *pgd=
> [ 3569.313104] Internal error: Oops: 5 [#1] SMP ARM
> [ 3569.317986] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack ebtable_filter ebtable_nat ebtable_broute bridge stp llc
> ebtables ip6table_security ip6table_raw ip6table_nat nf_conntrack_ipv6
> nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_filter ip6_tables
> iptable_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle musb_dsps cppi41 musb_hdrc
> phy_am335x udc_core phy_generic phy_am335x_control omap_sham omap_aes
> omap_rng omap_hwspinlock omap_mailbox hwspinlock_core musb_am335x omap_wdt
> at24 8250_omap leds_gpio cpufreq_dt smsc davinci_mdio mmc_block ti_cpsw
> cpsw_common ptp pps_core cpsw_ale davinci_cpdma omap_hsmmc omap_dma
> mmc_core i2c_dev [ 3569.386293] CPU: 0 PID: 1429 Comm: wdctl Not tainted
> 4.3.0-0.rc7.git0.1.fc24.armv7hl #1 [ 3569.394740] Hardware name: Generic
> AM33XX (Flattened Device Tree) [ 3569.401179] task: dbd11a00 ti: dbaac000
> task.ti: dbaac000
> [ 3569.406917] PC is at omap_wdt_get_timeleft+0xc/0x20 [omap_wdt]
> [ 3569.413106] LR is at watchdog_ioctl+0x3cc/0x42c
> [ 3569.417902] pc : []lr : []psr: 600f0013
> [ 3569.417902] sp : dbaadf18 ip : 0003 fp : 7f5d3bbe
> [ 3569.430014] r10: r9 : 0003 r8 : bef21ab8
> [ 3569.435535] r7 : dbbc0f7c r6 : dbbc0f18 r5 : bef21ab8 r4 :
> [ 3569.442427] r3 : r2 : r1 : 8004570a r0 : dbbc0f18
> [ 3569.449323] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> none [ 3569.456858] Control: 10c5387d Table: 9c894019 DAC: 0051
> [ 3569.462927] Process wdctl (pid: 1429, stack limit = 0xdbaac220)
> [ 3569.469179] Stack: (0xdbaadf18 to 0xdbaae000)
> [ 3569.473790] df00:
> bef21ab8 dbf60e38 [ 3569.482441] df20: dc91b840 8004570a bef21ab8 c03988a4
> dbaadf48 dc854000 dd313850 [ 3569.491092] df40: ddf033b8 570a
> dc91b80b dbaadf3c dbf60e38 0020 c0df9250 c0df6c48 [ 3569.499741] df60:
> dc91b840 8004570a dc91b840 dc91b840 8004570a bef21ab8 0003 [
> 3569.508389] df80: c03989d4 bef21b74 7f5d3bad 0003 0036
> c020fcc4 dbaac000 [ 3569.517037] dfa0: c020fb00 bef21b74 7f5d3bad
> 0003 8004570a bef21ab8 0001 [ 3569.525685] dfc0: bef21b74 7f5d3bad
> 0003 0036 0001 7f5e4eb0 7f5d3bbe [ 3569.534334] dfe0:
> 7f5e4f10 bef21a3c 7f5d0a54 b6e97e0c a00f0010 0003 [
> 3569.543038] [] (omap_wdt_get_timeleft [omap_wdt]) from
> [] (watchdog_ioctl+0x3cc/0x42c) [ 3569.553266] []
> (watchdog_ioctl) from [] (do_vfs_ioctl+0x5bc/0x698) [
> 3569.561648] [] (do_vfs_ioctl) from []
> (SyS_ioctl+0x54/0x7c) [ 3569.569400] [] (SyS_ioctl) from
> [] (ret_fast_syscall+0x0/0x3c) [ 3569.577413] Code: e12fff1e
> e52de004 e8bd4000 e5903060 (e5933088) [ 3569.584089] ---[ end trace
> cec3039bd3ae610a ]---
>
> Cc: <sta...@vger.kernel.org> # v4.2+
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: Lars Poeschel <poesc...@lemonage.de>
> Signed-off-by: Peter Robinson <pbrobin...@gmail.com>
Peter, thank you for catching this one.
Acked-by: Lars Poeschel <poesc...@lemonage.de>
> ---
> drivers/watchdog/omap_wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index d96bee0..6f17c93 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -205,7 +205,7 @@ static int omap_wdt_set_timeout(struct watchdog_device
> *wdog,
>
> static unsigned int omap_wdt_get_timeleft(struct watchdog_device *wdog)
> {
> - struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
> + struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
> void __iomem *base = wdev->base;
> u32 value;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On Friday 27 September 2013 02:36:52, Javier Martinez Canillas wrote: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk For both patches: Tested-by: Lars Poeschel poesc...@lemonage.de on an am3359 (which is DT booting). -- 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: am33xx: Correct gpio #interrupt-cells property
Hi Tony! On Wednesday 21 August 2013 at 09:50:16, Tony Lindgren wrote: Benoit, Care to take a look at this too? Benoit already applied this with Mark Rutlands Acked-By and Javier Martinez Canillas Reviewed-by. Regards, Lars * Lars Poeschel la...@wh2.tu-dresden.de [130807 04:14]: From: Lars Poeschel poesc...@lemonage.de Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 38b446b..033c5dd 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -102,7 +102,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x44e07000 0x1000; interrupts = 96; }; @@ -113,7 +113,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x4804c000 0x1000; interrupts = 98; }; @@ -124,7 +124,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ac000 0x1000; interrupts = 32; }; @@ -135,7 +135,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ae000 0x1000; interrupts = 62; }; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am Mittwoch, 31. Juli 2013, 01:44:53 schrieb Linus Walleij: On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org wrote: To solve this dilemma, perform an interrupt consistency check when adding a GPIO chip: if the chip is both gpio-controller and interrupt-controller, walk all children of the device tree, check if these in turn reference the interrupt-controller, and if they do, loop over the interrupts used by that child and perform gpio_reques() and gpio_direction_input() on these, making them unreachable from the GPIO side. Ugh, that's pretty awful, and it doesn't actually solve the root problem of the GPIO and IRQ subsystems not cooperating. It's also a very DT-centric solution even though we're going to see the exact same issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... I fully agree. I spent many time understanding the problem and reading mails to see what happend so far. This is by far the best way to solve the problem that was proposed until now. I support that approach. Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? Is requesting GPIOs directly common in the ACPI world? Does ACPI allow to use GPIOs for interrupts? And even if ACPI had the same problems than device tree, finding a common solution seems very difficult to me. I also prefer Linus' way here. This can be fixes in gpiolib for the device tree path and this is ok. We have to solve the problem in a better way than that. Linus asked for real solutions more than once. Can anybody propose a better way ? This has the following undesired effects: - The GPIOlib subsystem is not aware that the line is in use and willingly lets some other consumer perform gpio_request() on it, leading to a complex resource conflict if it occurs. If a gpio line is being both requested as a gpio and used as an interrupt line, then either a) it's a bug, or b) the gpio line needs to be used as input only so it is compatible with irq usage. b) should be supportable. Yes this is what I'm saying too I think... The bug in (a) manifested itself in the OMAP patch with no real solution in sight. - The GPIO debugfs file claims this GPIO line is free. Surely we can fix this. I still don't see a problem of having the controller request the gpio when it is claimed as an irq if we can get around the problem of another user performing a /valid/ request on the same GPIO line. The solution may be to have a special form of request or flag that allows it to be shared. I don't see how sharing works here, or how another user, i.e. another one than the user wanting to recieve the IRQ, can validly request such a line? What would the usecase for that valid request be? I also don't see the usecase for that. Sure, that can be done, but it is of no use. If it shows, that someone really needs this, it can be implemented later. Basically I believe these two things need to be exclusive in the DT world: A: request_irq(a resource passed from interrupts); - core implicitly performs gpio_request() gpio_direction_input() B: gpio_request(a resource passed from gpios); gpio_direction_input() request_irq(gpio_to_irq()) Never both. And IIUC that was what happened in the OMAP case. ACK. - The line direction of the interrupt GPIO line is not explicitly set as input, even though it is obvious that such a line need to be set up in this way, often making the system depend on boot-on defaults for this kind of settings. Should also be solvable if the gpio request problem is solved. Agreed... To push the discussion a bit further, I took Linus patch and extended it so that it can be tested now on real world hardware. I tested it on my device tree enabled board and it works fine here. Refer to [1], [2] for version 2 of the patch. It completely scans the device tree for interrupt-controller users of the gpio_chip in question. It requests the needed gpios and sets them as input. If the gpio_chip is removed, it also frees the gpio lines. Folks please help testing! Thanks, Lars [1] http://marc.info/?l=linux-kernelm=137638745909335w=2 [2] https://patchwork.kernel.org/patch/2843525/ -- 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
Re: ARM: AM335x: Reboot broken in 3.11
Am Donnerstag, 8. August 2013, 15:50:18 schrieb Mark Jackson: Rebooting appears to have broken in 3.11 (at some point before rc1). Here is the console output:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-6-gf550793 (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #328 Thu Aug 8 14:36:16 BST 2013 ... Welcome to Buildroot nanobone login: root Password: # reboot # [ 23.867076] UBIFS: background thread ubifs_bgt0_0 stops The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 25.924496] reboot: Restarting system ... and at this point the CPU seems to just freeze. In 3v10, the board would reboot correctly back into uboot, etc. I've also noticed that some of the output LEDs light up dim when the kernel is booting on, and they come on full brightness at the reboot freeze point. There are 4 LEDs affected and they are all connected to UART transmit pins. Before I start bisecting, does anyone have any ideas ? No problem here - at least not at -rc4: Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc4-00019-g7c4368e-dirty (larsi@lem- wkst-02) (gcc version 4.4.3 (GCC) ) #90 PREEMPT Thu Aug 8 16:42:06 CEST 2013 [0.00] Machine: Generic AM33XX (Flattened Device Tree), bboxv3 login: root root@bboxv3:~# reboot Broadcast message from root@bboxv3 (ttyO2) (鈬hu May 16 16:59:11 2013): INIT: Sending processes the TERM signal INIT: SenStopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid 416) . Stopping system message bus: Stopping syslogd/klogd: stopped syslogd (pid 423) stopped klogd (pid 425) done Stopping tcf-agent: OK Stopping internet superserver: xinetd. not deconfiguring network interfaces: network file systems still mounted. Stopping Linux NFC daemon Stopping Lighttpd Web Server: stopped /usr/sbin/lighttpd (pid 440) lighttpd. Sending all processes the TERM signal... Sending all processes the KILL signal... Unmounting remote filesystems... Deactivating swap... Unmounting local filesystems... Rebooting... [ 38.285126] reboot: Restarting system U-Boot SPL 2013.04-rc2-00063-gcd27ec7-dirty (May 21 2013 - 15:14:45) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img Regards, Lars -- 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
How to use gpio-omap as interrupt-controller
Hi!
I have a device-tree-booting omap board that uses gpio-omap as gpio driver.
Kernel version is 3.11.0-rc4. I have connected a device that signals
interrupts to a gpio pin of the omap. The driver for this device fails in
request_threaded_irq.
The irq framework tries to setup the irq in __setup_irq which calls
gpio_irq_type in gpio-omap.c. This function checks if bank-mod_usage is
set and because it is not, the function fails. Looking at where bank-
mod_usage is set, I see it is only set in omap_gpio_request.
This means I have to request at least one random gpio to be able to set the
type of the irq of another pin on this bank ?
How do I correctly use the gpio-omap gpio driver in my case ?
The board is booting using device tree and does not request a gpio prior to
requesting the irq on this gpio bank. I really do not want to request a
gpio. They should stay as they are.
Or does this mean the driver of the connected device is wrong and instead
it has to request some random gpio before ?
An example of such a connected device is gpio-adnp by the way.
The device tree part looks like this:
gpioext: gpio-adnp@41 {
compatible = ad,gpio-adnp;
reg = 0x41;
interrupt-parent = gpio;
interrupts = 160 1;
gpio-controller;
#gpio-cells = 1;
interrupt-controller;
#interrupt-cells = 2;
nr-gpios = 64;
};
Regards,
Lars
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
From: Lars Poeschel poesc...@lemonage.de Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 38b446b..033c5dd 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -102,7 +102,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x44e07000 0x1000; interrupts = 96; }; @@ -113,7 +113,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x4804c000 0x1000; interrupts = 98; }; @@ -124,7 +124,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ac000 0x1000; interrupts = 32; }; @@ -135,7 +135,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ae000 0x1000; interrupts = 62; }; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
On Wednesday 07 August 2013 at 16:53:09, Mark Rutland wrote: On Wed, Aug 07, 2013 at 12:06:32PM +0100, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. I take it there are no device nodes for which any of these nodes are an interrupt parent (which would need to be updated)? As far as I know: No. Lars If so: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 38b446b..033c5dd 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -102,7 +102,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x44e07000 0x1000; interrupts = 96; }; @@ -113,7 +113,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x4804c000 0x1000; interrupts = 98; }; @@ -124,7 +124,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ac000 0x1000; interrupts = 32; }; @@ -135,7 +135,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ae000 0x1000; interrupts = 62; }; -- 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] dts: am33xx: Correct properties on gpmc node
From: Lars Poeschel poesc...@lemonage.de The gpmc driver is actually looking for gpmc,num-cs and gpmc,num-waitpins properties in DT. The binding doc also states this. Correct the properties in the dts to provide the right values for the gpmc driver. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 1460d9b..8e1248f 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -409,8 +409,8 @@ ti,hwmods = gpmc; reg = 0x5000 0x2000; interrupts = 100; - num-cs = 7; - num-waitpins = 2; + gpmc,num-cs = 7; + gpmc,num-waitpins = 2; #address-cells = 2; #size-cells = 1; status = disabled; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Hi Javier!
On Thursday 14 March 2013 at 22:54:11, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas
javier.marti...@collabora.co.uk
---
Changes since v2:
- remove optional #address-cells and #size-cells since are not
relevant for ethernet chips; suggested by Jon Hunter.
Changes since v1:
- Improve the DT binding documentation explaining that even when the
GPMC maximum bus address width is 16-bit, it supports devices with
32-bit registers address width and the device property especifying this
has to be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 97
arch/arm/mach-omap2/gpmc.c
|8 ++
2 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode
100644
index 000..24cb4e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,97 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM
devices +such as ethernet controllers to processors using the TI GPMC
as a data bus. +
+Ethernet controllers connected to TI GPMC are represented as child
nodes of +the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties
are +explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the
GPMC +refer to the binding documentation of the device. For example,
the documentation +for the SMSC 911x is
Documentation/devicetree/bindings/net/smsc911x.txt +
+Child nodes need to specify the GPMC bus address width using the
bank-width +property but is possible that an ethernet controller also
has a property to +specify the I/O registers address width. Even when
the GPMC has a maximum 16-bit +address width, it supports devices with
32-bit word registers. +For example with an SMSC LAN911x/912x
controller connected to the TI GPMC on an +OMAP2+ board, bank-width =
2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports
8-bit + and 16-bit devices and so must be either 1 or 2
bytes.
+- compatible:Compatible string property for the ethernet
child
device. +- gpmc,cs-on:Chip-select assertion time
+- gpmc,cs-rd-off:Chip-select de-assertion time for reads
+- gpmc,cs-wr-off:Chip-select de-assertion time for writes
+- gpmc,oe-on:Output-enable assertion time
+- gpmc,oe-offOutput-enable de-assertion time
+- gpmc,we-on:Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to
chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+
Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Wednesday 17 April 2013 at 14:05:58, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn; \
dn = of_find_node_by_name(dn, name))
which means that it will search for a node with name on the complete
DeviceTree and this is wrong. It should only search on GPMC childs.
Could you please test the following patch? If it works for you I'll add
a proper description and submit it as a PATCH.
I see discussion is already going on, I just want to report:
I tested the patch and it work as intended. Probing of the gpmc childs
succeeds on am335x with another ethernet node in device tree.
Lars
From d8dab9ae9a0284f17553875c2fddd806d9f6ab2e Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 17 Apr 2013 13:50:30 +0200
Subject: [PATCH] ARM: OMAP2+: only search for GPMC DT child nodes on
probe
Signed-off-by: Javier Martinez Canillas
javier.marti...@collabora.co.uk ---
arch/arm/mach-omap2/gpmc.c | 51
--- 1 files changed, 24
insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..58e2415 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,35 +1520,32 @@ static int gpmc_probe_dt(struct platform_device
*pdev) return ret;
}
- for_each_node_by_name(child, nand) {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
-
- for_each_node_by_name(child, onenand) {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev-dev.of_node, child) {
+ if (child-name) {
+ if (of_node_cmp(child-name, nand) == 0) {
+ ret = gpmc_probe_nand_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
- for_each_node_by_name(child, nor) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (of_node_cmp(child-name, onenand) == 0) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
- for_each_node_by_name(child, ethernet) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
+ if (of_node_cmp(child-name, ethernet) == 0 ||
+ of_node_cmp(child-name, nor) == 0) {
+ ret = gpmc_probe_generic_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
Hi Matt! At first thanks for you efforts on DMA Engine on AM33XX. On Friday 01 February 2013 at 22:01:17, Matt Porter wrote: This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 I cloned your github repository and did short testing with it. I get the following error when the kernel mounts my sd-card: Starting udev [5.884738] udevd[72]: starting version 182 [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 16 [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed [8.892588] omap_hsmmc mmc.3: MMC start dma failure [8.897725] mmcblk0: unknown error -1 sending read/write command, card status 0x900 [8.905889] end_request: I/O error, dev mmcblk0, sector 17039 [8.911926] end_request: I/O error, dev mmcblk0, sector 17047 [8.917934] end_request: I/O error, dev mmcblk0, sector 17055 [8.923960] end_request: I/O error, dev mmcblk0, sector 17063 [8.929967] end_request: I/O error, dev mmcblk0, sector 17071 [8.935988] end_request: I/O error, dev mmcblk0, sector 17079 [8.942010] end_request: I/O error, dev mmcblk0, sector 17087 [8.948016] end_request: I/O error, dev mmcblk0, sector 17095 [8.954037] end_request: I/O error, dev mmcblk0, sector 17103 [8.960043] end_request: I/O error, dev mmcblk0, sector 17111 [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: inode #8: block 239: comm mount: unable to read itable block [9.033514] EXT4-fs (mmcblk0p2): no journal found [9.043799] kjournald starting. Commit interval 5 seconds [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended [9.060940] EXT3-fs (mmcblk0p2): using internal journal [9.066437] EXT3-fs (mmcblk0p2): recovery complete [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode After that the filesystem on the sd-card has an error that I have to fix with e2fsck. As rootfs I use a nfsroot. In my quick tests, same setup, I don't get any error on edma-dmaengine- am33xx-v5 branch of your repository. If you need any further information, let me now. Regards, Lars -- 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 v4,03/14] ARM: edma: add AM33XX support to the private EDMA API
Hi Matt, On Friday 11 January 2013 at 06:48:39, Matt Porter wrote: diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index a3d189d..1951d63 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -24,6 +24,13 @@ #include linux/platform_device.h #include linux/io.h #include linux/slab.h +#include linux/edma.h +#include linux/err.h +#include linux/of_address.h +#include linux/of_device.h +#include linux/of_dma.h +#include linux/of_irq.h +#include linux/pm_runtime.h You add the include linux/of_dma.h here, but maybe you missed to add the file itself. It is not in Linus v3.8-rc3 tree, not in the patches yours depend on listed and not in your patchset. Regards, Lars -- 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
