- 25 Sep, 2014 3 commits
-
-
Linus Walleij authored
This makes it possible to create a set of LEDs from a syscon MFD instance, which is lean mean and clean on the ARM reference designs and can replace the Versatile LEDs driver in the long run, as well as other custom syscon LEDs drivers. Cc: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> [Fixed cocinelle warnings] Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Merge tag 'intc-part2-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers Merge "part 2 of omap intc changes" from Tony Lindgren: Second part of omap intc interrupt controller changes to move it to drivers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> * tag 'intc-part2-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: irqchip: omap-intc: remove unnecessary comments irqchip: omap-intc: correct maximum number or MIR registers irqchip: omap-intc: enable TURBO idle mode irqchip: omap-intc: enable IP protection irqchip: omap-intc: remove unnecesary of_address_to_resource() call irqchip: omap-intc: comment style cleanup irqchip: omap-intc: minor improvement to omap_irq_pending() arm: omap: irq: move irq.c to drivers/irqchip/ irqchip: add irq-omap-intc.h header arm: omap2: n8x0: move i2c devices to DT
-
Arnd Bergmann authored
Merge tag 'sunxi-drivers-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into next/drivers Pull "Allwinner drivers additions for 3.18" from Maxime Ripard: Nothing major, just handling the RTC driver changes needed for the A31/A23. Signed-off-by: Arnd Bergmann <arnd@arndb.de> * tag 'sunxi-drivers-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc rtc: sun6i: Add sun6i RTC driver
-
- 24 Sep, 2014 10 commits
-
-
Olof Johansson authored
Fixes below build break by not switching to stubs when the driver is a module: drivers/soc/ti/knav_dma.c:418:7: error: redefinition of 'knav_dma_open_channel' void *knav_dma_open_channel(struct device *dev, const char *name, ^ In file included from drivers/soc/ti/knav_dma.c:26:0: include/linux/soc/ti/knav_dma.h:165:21: note: previous definition of 'knav_dma_open_channel' was here static inline void *knav_dma_open_channel(struct device *dev, const char *name, ^ Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
Merge tag 'drivers-soc-ti-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into next/drivers Merge "soc: Keystone SOC Navigator drivers for 3.18" from Santosh Shilimkar: Keystone SOC Navigator drivers for 3.18 The Keystone Multi-core Navigator contains QMSS and packet DMA subsystems which interwork together to form the Navigator cloud used by various subsystems like NetCP, SRIO, SideBand Crypto engines etc. * tag 'drivers-soc-ti-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone: MAINTAINERS: Add Keystone Multicore Navigator drivers entry soc: ti: add Keystone Navigator DMA support Documentation: dt: soc: add Keystone Navigator DMA bindings soc: ti: add Keystone Navigator QMSS driver Documentation: dt: soc: add Keystone Navigator QMSS bindings Signed-off-by: Olof Johansson <olof@lixom.net>
-
Santosh Shilimkar authored
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Santosh Shilimkar authored
The Keystone Navigator DMA driver sets up the dma channels and flows for the QMSS(Queue Manager SubSystem) who triggers the actual data movements across clients using destination queues. Every client modules like NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO Engines has its own instance of packet dma hardware. QMSS has also an internal packet DMA module which is used as an infrastructure DMA with zero copy. Initially this driver was proposed as DMA engine driver but since the hardware is not typical DMA engine and hence doesn't comply with typical DMA engine driver needs, that approach was naked. Link to that discussion - https://lkml.org/lkml/2014/3/18/340 As aligned, now we pair the Navigator DMA with its companion Navigator QMSS subsystem driver. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Santosh Shilimkar authored
The Keystone Navigator DMA driver sets up the dma channels and flows for the QMSS(Queue Manager SubSystem) who triggers the actual data movements across clients using destination queues. Every client modules like NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO Engines has its own instance of packet dma hardware. QMSS has also an internal packet DMA module which is used as an infrastructure DMA with zero copy. Initially this driver was proposed as DMA engine driver but since the hardware is not typical DMA engine and hence doesn't comply with typical DMA engine driver needs, that approach was naked. Link to that discussion - https://lkml.org/lkml/2014/3/18/340 As aligned, now we pair the Navigator DMA with its companion Navigator QMSS subsystem driver. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Sandeep Nair authored
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA. The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory. The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in: Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Sandeep Nair authored
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA. The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Olof Johansson authored
Merge tag 'mailbox-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers Mailbox related changes for omaps to get it to work with device tree. * tag 'mailbox-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: mailbox/omap: add support for parsing dt devices Documentation: dt: add omap mailbox bindings Signed-off-by: Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
Merge tag 'intc-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers Merge "omap intc changes for v3.18 merge window" from Tony Lindgren: Interrupt code related clean-up for omap2 and 3 to make it ready to move to drivers/irqchip. Note that this series does not yet move the interrupt code to drivers, that will be posted separately as a follow-up series. Note that this branch has a dependency to patches both in fixes-v3.18-not-urgent and soc-for-v3.18 and is based on a merge. Without doing the merge, off-idle would not work properly for git bisect. * tag 'intc-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (325 commits) arm: omap: intc: switch over to linear irq domain arm: omap: irq: get rid of ifdef hack arm: omap: irq: introduce omap_nr_pending arm: omap: irq: remove nr_irqs argument arm: omap: irq: remove unnecessary header arm: omap: irq: drop omap2_intc_handle_irq() arm: omap: irq: drop omap3_intc_handle_irq() arm: omap: irq: call set_handle_irq() from .init_irq arm: omap: irq: move some more code around arm: boot: dts: omap2/3/am33xx: drop ti,intc-size arm: omap: irq: drop ti,intc-size support arm: boot: dts: am33xx/omap3: fix intc compatible flag arm: omap: irq: use compatible flag to figure out number of IRQ lines arm: omap: irq: add specific compatibles for omap3 and am33xx devices arm: omap: irq: drop .handle_irq and .init_irq fields arm: omap: irq: use IRQCHIP_DECLARE macro arm: omap: irq: call set_handle_irq() from intc_of_init arm: omap: irq: make intc_of_init static arm: omap: irq: reorganize code a little bit arm: omap: irq: always define omap3 support ... Signed-off-by: Olof Johansson <olof@lixom.net>
-
git://github.com/at91linux/linux-at91Olof Johansson authored
Merge " Second drivers series for AT91/3.18" from Nicolas Ferre: - move of the PIT (basic timer) from mach-at91 to its proper location: drivers/clocksource - big cleanup of this driver along the way * tag 'at91-drivers2' of git://github.com/at91linux/linux-at91: ARM: at91: PIT: Move the driver to drivers/clocksource ARM: at91: Give the PIT irq as an argument of at91sam926x_pit_init ARM: at91: Convert the boards to the init_time callback ARM: at91: soc: Add init_time callback ARM: at91: PIT: (Almost) remove the global variables ARM: at91: PIT: use request_irq instead of setup_irq ARM: at91: PIT: Use pr_fmt ARM: at91: PIT: Use consistent exit path in probe ARM: at91: dt: Remove init_time definitions ARM: at91: PIT: Rework probe functions ARM: at91: PIT: Use of_have_populated_dt instead of CONFIG_OF ARM: at91: PIT: Use DIV_ROUND_CLOSEST to compute the cycles ARM: at91: generic.h: Add include safe guards ARM: at91: PIT: Follow the general coding rules Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 19 Sep, 2014 2 commits
-
-
Chen-Yu Tsai authored
Now that we have Kconfig options for individual sunxi platforms, let the rtc-sunxi driver depend on the platforms that actually have this hardware, sun4i and sun7i. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
-
Chen-Yu Tsai authored
This patch introduces the driver for the RTC in the Allwinner A31 and A23 SoCs. Unlike the RTC found in A10/A20 SoCs, which was part of the timer, the RTC in A31/A23 are a separate hardware block, which also contain a few controls for the RTC block hardware (a regulator and RTC block GPIO pin latches), while also having separate interrupts for the alarms. The hardware is different enough to make a different driver for it. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Varka Bhadram <varkabhadram@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
-
- 16 Sep, 2014 10 commits
-
-
Felipe Balbi authored
no fuctional changes. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
maximum number of MIR register is 4, rather than 3. Fix that. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
When TURBO bit is set in the INTC_IDLE register, the input synchronizer clock will be autogated based on activity on the INTC. Because this idle mode increases the interrupt latency by 2 clock cycles, we're only enabling it during suspend. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
When PROTECTION bit in enabled in PROTECTION register, INTC's registers are only accessible from privileged mode. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
of_iomap(), which is called from omap_init_irq_of(), already takes care of making sure we have a valid resource to deal with. Because of that, we can safely remove our explicit call to of_address_to_resource(). Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
no functional changes, just making sure comment follows Coding Style. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
We already hold the number of Pending registers in omap_nr_pending. Let's use that instead. Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
Just move the code over as it has no dependencies on arch/arm/ anymore. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
OMAP INTC irqchip driver will be moved under drivers/irqchip/ soon but we still have a dependency with mach-omap2 when it comes to idle functions. In order to make it easy to share those function prototypes with OMAP PM code, we introduce this new header. To avoid modifying several board-files and some of the PM-related code, we just include the new header from common.h which was already included by all users of IRQ-related PM code. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
By moving i2c devices to DT we can clean up i2c_board_info and fix a problem with moving INTC to irq domain where IRQs can be renumbered on each boot. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 15 Sep, 2014 2 commits
-
-
Maxime Ripard authored
Now that we don't depend on anyting in the mach-at91 directory, we can just move the driver to where it belongs. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Conflicts: arch/arm/mach-at91/Kconfig arch/arm/mach-at91/Makefile
-
Maxime Ripard authored
This allows to remove the dependency of the timer driver on mach/hardware.h and having an hardcoded interrupt number in the driver itself. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
- 11 Sep, 2014 13 commits
-
-
Felipe Balbi authored
now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
we don't need the ifdef if we have omap_nr_pending telling us how many pending registers we have on current platform. This solves a possible problem where we could try to handle bogus interrupts on OMAP2 and OMAP3 if using single zImage kernel, because we would end up reading the following pending FIQ register. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
that variable will tell us how many INTC_PENDING_IRQn registers we have. It'll be used on a following patch to cleanup omap_intc_handle_irq() a bit. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
we can set our global omap_nr_irqs early on and drop the extra argument to omap_init_irq(). Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
There's no need for that header to be included. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
that was just a no-op wrapper around omap_intc_handle_irq anyway. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
now that we're calling set_handle_irq() from init_irq(), we can safely drop all callers to omap3_intc_handle_irq() and its definition. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
the idea is that board-files won't need to set .handle_irq on their machine_descs, which lets us drop a little more pointless code. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
We want .init_irq to call set_irq_handle() for legacy platforms. Note that this code will also be dropped once omap2/3 devices are completely moved to DT. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
we are now infering number of IRQ lines based on correct compatible flag, which renders this binding completely useless. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
we don't need that anymore since specific devices are passing correct compatible flags. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
that way, our intc driver can figure out how many IRQ lines INTC has. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Felipe Balbi authored
so far, only am33xx has 128 lines, all other devices have only 96. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-