user/sven/linux.git/include/linux/of_irq.h, branch v3.17

of/irq: do irq resolution in platform_get_irq_byname()

2014-05-23T02:40:25Z

The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef "of/irq: do irq resolution in platform_get_irq" from Rob Herring - moves resolving of the interrupt resources in platform_get_irq(). But this solution isn't complete because platform_get_irq_byname() need to be modified the same way. Hence, fix it by adding interrupt resolution code at the platform_get_irq_byname() function too. Cc: Russell King Cc: Rob Herring Cc: Tony Lindgren Cc: Grant Likely Cc: Thierry Reding Signed-off-by: Grygorii Strashko Signed-off-by: Grant Likely

of/irq: do irq resolution in platform_get_irq

2014-04-24T20:40:22Z

Currently we get the following kind of errors if we try to use interrupt phandles to irqchips that have not yet initialized: irq: no irq domain found for /ocp/pinmux@48002030 ! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184() Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012 (show_stack+0x14/0x1c) (dump_stack+0x6c/0xa0) (warn_slowpath_common+0x64/0x84) (warn_slowpath_null+0x1c/0x24) (of_device_alloc+0x144/0x184) (of_platform_device_create_pdata+0x44/0x9c) (of_platform_bus_create+0xd0/0x170) (of_platform_bus_create+0x12c/0x170) (of_platform_populate+0x60/0x98) This is because we're wrongly trying to populate resources that are not yet available. It's perfectly valid to create irqchips dynamically, so let's fix up the issue by resolving the interrupt resources when platform_get_irq is called. And then we also need to accept the fact that some irqdomains do not exist that early on, and only get initialized later on. So we can make the current WARN_ON into just into a pr_debug(). We still attempt to populate irq resources when we create the devices. This allows current drivers which don't use platform_get_irq to continue to function. Once all drivers are fixed, this code can be removed. Suggested-by: Russell King Signed-off-by: Rob Herring Signed-off-by: Tony Lindgren Tested-by: Tony Lindgren Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Grant Likely

dt/irq: add empty of_irq_count for !OF_IRQ

2013-11-08T16:47:28Z

Add an empty version of of_irq_count for !OF_IRQ. This fixes build error on sparc in linux-next: drivers/gpio/gpio-bcm-kona.c:542: undefined reference to `of_irq_count' Signed-off-by: Rob Herring

of/irq: Refactor interrupt-map parsing

2013-10-24T10:43:04Z

All the users of of_irq_parse_raw pass in a raw interrupt specifier from the device tree and expect it to be returned (possibly modified) in an of_phandle_args structure. However, the primary function of of_irq_parse_raw() is to check for translations due to the presence of one or more interrupt-map properties. The actual placing of the data into an of_phandle_args structure is trivial. If it is refactored to accept an of_phandle_args structure directly, then it becomes possible to consume of_phandle_args from other sources. This is important for an upcoming patch that allows a device to be connected to more than one interrupt parent. It also simplifies the code a bit. The biggest complication with this patch is that the old version works on the interrupt specifiers in __be32 form, but the of_phandle_args structure is intended to carry it in the cpu-native version. A bit of churn was required to make this work. In the end it results in tighter code, so the churn is worth it. Signed-off-by: Grant Likely Acked-by: Tony Lindgren Cc: Benjamin Herrenschmidt

of/irq: simplify args to irq_create_of_mapping

2013-10-24T10:42:57Z

All the callers of irq_create_of_mapping() pass the contents of a struct of_phandle_args structure to the function. Since all the callers already have an of_phandle_args pointer, why not pass it directly to irq_create_of_mapping()? Signed-off-by: Grant Likely Acked-by: Michal Simek Acked-by: Tony Lindgren Cc: Thomas Gleixner Cc: Russell King Cc: Ralf Baechle Cc: Benjamin Herrenschmidt

of/irq: Replace of_irq with of_phandle_args

2013-10-24T10:42:51Z

struct of_irq and struct of_phandle_args are exactly the same structure. This patch makes the kernel use of_phandle_args everywhere. This in itself isn't a big deal, but it makes some follow-on patches simpler. Signed-off-by: Grant Likely Acked-by: Michal Simek Acked-by: Tony Lindgren Cc: Russell King Cc: Ralf Baechle Cc: Benjamin Herrenschmidt

of/irq: Rename of_irq_map_* functions to of_irq_parse_*

2013-10-24T10:40:59Z

The OF irq handling code has been overloading the term 'map' to refer to both parsing the data in the device tree and mapping it to the internal linux irq system. This is probably because the device tree does have the concept of an 'interrupt-map' function for translating interrupt references from one node to another, but 'map' is still confusing when the primary purpose of some of the functions are to parse the DT data. This patch renames all the of_irq_map_* functions to of_irq_parse_* which makes it clear that there is a difference between the parsing phase and the mapping phase. Kernel code can make use of just the parsing or just the mapping support as needed by the subsystem. The patch was generated mechanically with a handful of sed commands. Signed-off-by: Grant Likely Acked-by: Michal Simek Acked-by: Tony Lindgren Cc: Ralf Baechle Cc: Benjamin Herrenschmidt

of: clean-up ifdefs in of_irq.h

2013-09-25T02:12:32Z

Much of of_irq.h is needlessly ifdef'ed. Clean this up and minimize the amount ifdef'ed code. This fixes some build warnings when CONFIG_OF is not enabled (seen on i386 and x86_64): include/linux/of_irq.h:82:7: warning: 'struct device_node' declared inside parameter list [enabled by default] include/linux/of_irq.h:82:7: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/of_irq.h:87:47: warning: 'struct device_node' declared inside parameter list [enabled by default] Compile tested on i386, sparc and arm. Reported-by: Randy Dunlap Cc: Grant Likely Signed-off-by: Rob Herring

of/irq: sparse fixes

2012-10-17T20:53:02Z

drivers/of/irq.c:195:57: warning: restricted __be32 degrades to integer drivers/of/irq.c:196:51: warning: restricted __be32 degrades to integer drivers/of/irq.c:199:57: warning: restricted __be32 degrades to integer drivers/of/irq.c:201:58: warning: restricted __be32 degrades to integer drivers/of/irq.c:470:37: warning: incorrect type in assignment (different modifiers) drivers/of/irq.c:470:37: expected int ( *[usertype] irq_init_cb )( ... ) drivers/of/irq.c:470:37: got void const *const data drivers/of/irq.c:96:5: error: symbol 'of_irq_map_raw' redeclared with different type (originally declared at include/linux/of_irq.h:61) - incompatible argument 2 (different base types) drivers/of/of_pci_irq.c:91:40: warning: incorrect type in argument 2 (different base types) drivers/of/of_pci_irq.c:91:40: expected unsigned int const [usertype] *intspec drivers/of/of_pci_irq.c:91:40: got restricted __be32 * drivers/of/of_pci_irq.c:91:53: warning: incorrect type in argument 4 (different base types) drivers/of/of_pci_irq.c:91:53: expected unsigned int const [usertype] *addr drivers/of/of_pci_irq.c:91:53: got restricted __be32 * Signed-off-by: Kim Phillips Signed-off-by: Rob Herring

of/irq: Create stub for of_irq_find_parent when !CONFIG_OF

2012-09-20T10:32:30Z

of_irq_find_parent is a handy function to use outside the confines of the Open Firmware subsystem. One such use-case is when the IRQ Domain wishes to find an IRQ domain for a given device node. Currently it can not take any notice of the 'interrupt-parent' property. Instead it just uses the first IRQ controller as it climbs the Device Tree. If we were to use this as a precursor the resultant controller is more likely to be correct. Acked-by: Rob Herring Acked-by: Linus Walleij Signed-off-by: Lee Jones