Andrew, Thomas,
In the discussion about orion clocksource Russell was proposing a generic
thread-safe write. That puts a single lock around all those writes. Of
course, it will also blocked by totally unrelated thread-safe register
accesses but should prevent us from having dozens of locks
On 07/13/2013 04:25 PM, Daniel Drake wrote:
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine moin...@free.fr wrote:
I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
modules. I set 3 clocks in the DT for
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Draked...@laptop.org wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois
On 07/05/13 10:43, Grant Likely wrote:
On Wed, Jul 3, 2013 at 10:02 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible =
On 07/05/13 11:51, Grant Likely wrote:
On Fri, Jul 5, 2013 at 10:34 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
So for the discussion, I can see that there have been some voting for
super-node, some for node-to-node linking. Although I initially proposed
super-nodes, I can
On 07/04/13 10:33, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s
On 07/04/13 11:23, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
Wrong. Please read the example with the diagrams I gave. Consider
On 07/04/13 12:09, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04
On 07/03/13 08:55, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
Have you also considered how suspend/resume works in such a place,
where every driver is independent? The ChromeOS guys have bitched
before about the exynos driver which is has lots of
On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /*
On 07/03/13 11:53, Russell King wrote:
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
That's not whether we can write device driver or not. dtsi is common spot in
other subsystems. Do you think the cardX node is meaningful to other
subsystems?
Yes, because fbdev could also use it
On 07/03/13 11:52, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible =
On 07/03/13 13:43, Inki Dae wrote:
I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.
So, of course, lcd controller nodes and dcon are part of dove.dtsi
because they are physically available on every
On 07/03/13 13:32, Russell King wrote:
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention
DMA API and mv_xor driver.
The second patch fixes compilation of orion5x edmini_v2 by adding a
missing include.
devicetree-discuss is added on Cc for completeness, this is all Marvell
related and should go through Jason Cooper's branch if there are no
objections.
Sebastian Hesselbarth (2):
ARM
DMA_MEMSET support has been removed, so update the device tree files
and corresponding binding documentation for Marvell SoCs.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn
edmini_v2-setup is missing an include of linux/mbus.h which causes
compiler error because of missing reference to mvebu_mbus_add_window.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc
On 07/02/2013 09:19 PM, Russell King wrote:
On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):
- at probe time, the main driver
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them
On 06/18/13 13:25, Ezequiel Garcia wrote:
In the example below there's an extract of a device tree showing how
the internal-regs and pcie nodes can be represented:
#define MBUS_ID(target,attributes) (((target) 24) | ((attributes)
16))
soc {
compatible =
On 06/18/13 13:36, Russell King - ARM Linux wrote:
On Thu, Sep 13, 2012 at 05:41:44PM +0200, Sebastian Hesselbarth wrote:
+#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE | 0xe802C)
+#define DOVE_TWSI_ENABLE_OPTION1 BIT(7)
+#define DOVE_GLOBAL_CONFIG_2
On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
I thought we agreed to
On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
Also allows you to have up to 40b offset, which might be important
with LPAE enabled.
Not with the current generation I think, since the mbus windows are
32 bit only, but it would avoid having
On 06/18/2013 08:47 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
Yeah, I also recall Thomas or Gregory mention a 32b limitation in
remap windows. But we don't need to waste addresses here
And even if SIAA is a concern because there may
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
S = 0 means 4 bit I, 8 bit A
S = F means special
S = 1 could mean 16 bit I, etc , etc
S 0x8 == 0x0 means 7b target
S 0x8 == 0x8 means 7b special ?
No need, special
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding
On 06/12/2013 01:08 AM, Jason Gunthorpe wrote:
On Wed, Jun 12, 2013 at 12:22:29AM +0200, Sebastian Hesselbarth wrote:
sorry to kick into this thread that late but Ezequiel made me think of
address windows when asking on IRC. From what I can see from your and
Arnd's proposal the only real
On 06/11/13 14:35, Ezequiel Garcia wrote:
On Thu, Jun 06, 2013 at 06:27:08PM +0200, Sebastian Hesselbarth wrote:
This patch set introduces DT-aware irqchip and clocksource drivers for
Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
patches for Dove and Kirkwood to enable
On 06/11/13 15:30, Thomas Gleixner wrote:
On Tue, 11 Jun 2013, Thomas Gleixner wrote:
On Thu, 6 Jun 2013, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation
On 06/11/13 15:45, Thomas Gleixner wrote:
On Tue, 11 Jun 2013, Sebastian Hesselbarth wrote:
On 06/11/13 15:30, Thomas Gleixner wrote:
On Tue, 11 Jun 2013, Thomas Gleixner wrote:
On Thu, 6 Jun 2013, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt
On 06/11/13 16:13, Thomas Gleixner wrote:
On Tue, 11 Jun 2013, Sebastian Hesselbarth wrote:
On 06/11/13 15:45, Thomas Gleixner wrote:
But what about the bit in of that first irq in the cause register? If
it's set on entry you call generic_handle_irq() for that as well. So
if it's set you need
On 06/11/2013 11:50 PM, Jason Gunthorpe wrote:
On Tue, Jun 11, 2013 at 05:26:47PM +0200, Arnd Bergmann wrote:
That looks ok to me, yes. If you have just one device under some of the nodes
however, I think it's easier use an empty ranges property and do
devbus-bootcs {
@@
+/*
+ * Marvell Orion SoC timer handling.
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied
On 06/10/13 18:04, Daniel Lezcano wrote:
On 06/10/2013 11:35 AM, Sebastian Hesselbarth wrote:
This patch add a DT enabled driver for timers found on Marvell Orion SoCs
(Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free-
running clocksource on timer0 and a clockevent source
On 06/10/13 18:44, Daniel Lezcano wrote:
On 06/10/2013 06:31 PM, Sebastian Hesselbarth wrote:
On 06/10/13 18:04, Daniel Lezcano wrote:
On 06/10/2013 11:35 AM, Sebastian Hesselbarth wrote:
This patch add a DT enabled driver for timers found on Marvell Orion
SoCs
(Kirkwood, Dove, Orion5x
On 06/07/13 10:30, Thomas Petazzoni wrote:
On Thu, 6 Jun 2013 18:27:12 +0200, Sebastian Hesselbarth wrote:
- wdt@20300 {
+ wdt: watchdog-timer@20300 {
compatible = marvell,orion-wdt;
reg = 0x20300 0x28
On 06/07/13 10:30, Thomas Petazzoni wrote:
On Thu, 6 Jun 2013 18:27:12 +0200, Sebastian Hesselbarth wrote:
- wdt@20300 {
+ wdt: watchdog-timer@20300 {
compatible = marvell,orion-wdt;
reg = 0x20300 0x28
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley
-dove.git orion-irqchip-for-v3.11
and has been tested on Dove/CuBox and compile tested for Kirkwood.
Sebastian Hesselbarth (6):
irqchip: add support for Marvell Orion SoCs
clocksource: add Marvell Orion SoC timer
ARM: dove: move device tree nodes to DT irqchip and clocksource
ARM: kirkwood: move
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely
-orion.c b/drivers/clocksource/time-orion.c
new file mode 100644
index 000..4ecb2f8
--- /dev/null
+++ b/drivers/clocksource/time-orion.c
@@ -0,0 +1,143 @@
+/*
+ * Marvell Orion SoC timer handling.
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * This file is licensed under
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.
This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
where old code is moved out to and polishes DT board file a little bit.
Signed-off-by: Sebastian
On 06/04/13 22:53, Gerlando Falauto wrote:
thanks for your answer and your hard work about this whole cleanup.
Two more questions though -- the whole pulling sequence and the
mainlining process is still very confusing to me so I really have no
idea where to look or what to expect.
1) Has this
On 06/05/13 11:37, Gerlando Falauto wrote:
On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]
I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
[sorry we've moved to a different topic
On 06/04/13 12:18, Gerlando Falauto wrote:
I noticed how most of the DT-aware board-setup files only have a single
board_init() function, calling kirkwood_ge00_init() with a struct
mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this
On 05/24/2013 07:13 PM, Russell King - ARM Linux wrote:
Do you really want that on ARM? Given the fiasco with the location of
the registers, are you sure you want to place more trust in that
direction? Does it give you a warm fuzzy feeling to know that you
might have to work out some way to
On 05/20/2013 11:19 PM, Simon Baatz wrote:
On Mon, May 06, 2013 at 05:33:34PM +0200, Sebastian Hesselbarth wrote:
From: Florian Fainelliflor...@openwrt.org
...
@@ -2485,13 +2499,21 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (dram
On 05/20/2013 11:27 PM, Simon Baatz wrote:
Hi Sebastian,
On Mon, May 06, 2013 at 05:33:39PM +0200, Sebastian Hesselbarth wrote:
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis
that we
can test arm-soc and have all the pieces needed in here.
That said, Sebastian Hesselbarth has submitted a big rework of the
mvebu clock drivers, which would conflict with this patch, and
Sebastian's rework would most likely go through your tree. If that's
the case, I guess it would be better
On 05/13/2013 10:00 PM, Jason Cooper wrote:
On Tue, May 07, 2013 at 01:36:08AM +0200, Sebastian Hesselbarth wrote:
Dove power management unit can mux some special functions to mpp0-15.
This patch adds support to set/get the current PMU function mapped
to the corresponding mpp pins. The device
On 05/08/2013 09:04 AM, Valentin Longchamp wrote:
On 05/07/2013 06:36 PM, Sebastian Hesselbarth wrote:
I just checked my mails from late 2012 and there Valentin and I agreed,
that not the missing bits in clock gating control registers was the root
cause of km_kirkwood to hang. It was rather
of_mdiobus_register creates a phy_device even if get_phy_device failed
to create it previously. This causes indefinite polling on non-existent
PHYs. This fix makes of_mdio_register rely on get_phy_device to
properly create the device or fail otherwise.
Signed-off-by: Sebastian Hesselbarth
On 05/07/2013 06:11 PM, Gregory CLEMENT wrote:
On 05/07/2013 05:52 PM, Valentin Longchamp wrote:
The kirkwood device found in the Prestera SoCs does not have all the
peripherals of its the usual kirkwood SoCs. There are hence missing
clocks in the SoCs.
This patch registers another gate
mask_cache pointer also needs to be initialized for domain generic
chips.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Thomas Gleixner t...@linutronix.de
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring
by irq_alloc_domain_generic_chip.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Thomas Gleixner t...@linutronix.de
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Arnd Bergmann
conversion for Dove and Kirkwood is added. Dove has
been fully tested, while Kirkwood is compile-tested only.
Florian Fainelli (2):
net: mv643xx_eth: add Device Tree bindings
net: mv643xx_eth: update Device Tree bindings documentation
Sebastian Hesselbarth (5):
ARM: dove: remove legacy
...@openwrt.org
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v2-v3:
- rebase on top of mv643xx_eth clean-ups
- do not reparse existing platform_data
- use managed devm_kzalloc for parsed platform_data
- use of_property_read_u32 where applicable
- add phy_node
From: Florian Fainelli flor...@openwrt.org
This patch updates the Device Tree bindings documentation for the
Marvell MV643xx ethernet controller node and makes the
local-mac-address and phy properties optional instead of required.
The absence of a phy node is legal and describes a MAC to switch
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to overwrite its reg property on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards. This patch removes eth setup
for all kirkwood DT board files.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr
With all boards converted to DT enabled mv643xx_eth we can now
remove the clock alias for gbe clocks.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc
On 05/06/13 18:07, Jason Cooper wrote:
Sebastian,
Thanks for picking this up! A few comments about merging strategy:
On Mon, May 06, 2013 at 05:33:33PM +0200, Sebastian Hesselbarth wrote:
This patch set picks up work by Florian Fainelli bringing full DT
support to mv643xx_eth and Marvell
On 05/03/2013 07:06 AM, Andrew Lunn wrote:
On Fri, May 03, 2013 at 01:48:36AM +0200, Sebastian Hesselbarth wrote:
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon
-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Changes from v1-v2:
Sebastian Hesselbarth send me updated version of patch which was based
on v1. Resending with updates.
Marek,
it is ok to be a little bit more noisy about changes. But as I took
your v1 and did it, here
On 05/03/13 14:55, Russell King - ARM Linux wrote:
On Fri, May 03, 2013 at 01:48:35AM +0200, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree
On 05/03/2013 11:50 PM, Thomas Gleixner wrote:
Provide infrastructure for irq chip implementations which work on
linear irq domains.
Thomas,
I am happy that I put you into rant mode. It took me little more
than an hour to read through your patches, prepare orion irqchip
driver on top of them
On 05/03/2013 11:50 PM, Thomas Gleixner wrote:
Proof of concept patch to demonstrate the new irqdomain support for
the generic irq chip. Untested !!
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Maxime Ripard maxime.rip...@free-electrons.com
---
...
+ gc-reg_base =
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: This patch
.
Note: This patch set depends on irqchip driver for Orion SoCs patch.
Sebastian Hesselbarth (3):
ARM: dove: add DT parsing for legacy mv643xx_eth
ARM: dove: add DT parsing for legacy timer
ARM: dove: move DT boards to orion irqchip driver
arch/arm/boot/dts/dove.dtsi | 18 -
arch/arm
for mv643xx_eth.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Thomas Gleixner t...@linutronix.de
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann
timer.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Thomas Gleixner t...@linutronix.de
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann
With legacy devices mapping their irqs, we can now switch DT enabled
boards to orion irqchip driver.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove
On 05/02/13 20:56, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth
On 05/02/13 20:53, Jason Gunthorpe wrote:
On Thu, May 02, 2013 at 08:25:04PM +0200, Sebastian Hesselbarth wrote:
+
+static void __iomem *orion_irq_base[ORION_MAX_IRQREG];
+static unsigned int orion_irq_regs;
+static struct irq_domain *orion_irq_domain;
+
+asmlinkage void __exception_irq_entry
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string?
On 05/02/2013 09:34 PM, Sebastian Hesselbarth wrote:
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
relay server ;) Maybe I can turn it into a test bed for a while.
There
On 05/02/2013 11:34 PM, Thomas Gleixner wrote:
please do not take the rant below personally. You just happen to
trigger it.
Thomas,
it is okay for me - but thanks for the notice! I will comment below.
On Thu, 2 May 2013, Sebastian Hesselbarth wrote:
+static void orion_irq_mask(struct
On 05/03/2013 12:09 AM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Sebastian Hesselbarth wrote:
Just look at the various implementations in drivers/irqchip/ and find
out how similar they are. Moving code to drivers/irqchip/ does not
make an excuse for reestablishing the mess which
for
irqdomain support for generic irq and perhaps even a DT enabled generic
irq chip driver.
The patch set still can be used to port other Orion SoCs as I did with Dove.
It also merges irqchip driver patches with Dove patches to use this driver.
Sebastian Hesselbarth (5):
irqchip: add support
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: This patch
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon as there is true device tree
support for mv643xx_eth.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon as there is true device tree
support for orion timer.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
This patch adds required device tree nodes for irqchip conversion
on Dove. The nodes are named and layed out to allow seamless migration
to true DT enabled drivers as soon as they are available.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v1-v2:
- merge DT
With legacy devices mapping their irqs, we can now switch DT enabled
boards to orion irqchip driver.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v1-v2:
- split off DT changes (Suggested by Jason Cooper)
- use irqchip_init (Suggested by Jason Gunthorpe)
Cc
In clk-si5351 there was some dependency to CONFIG_OF that permitted the
use of the driver on !CONFIG_OF platforms. This patch adds proper #ifdef
around of_clk_add_provider and removes the dependency on CONFIG_OF.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note
On 04/25/2013 03:13 PM, Marek Belisko wrote:
Add devicetree support for this dummy audio soc driver.
Signed-off-by: Michal Bachratymichal.bachr...@streamunlimited.com
Signed-off-by: Marek Beliskomarek.beli...@streamunlimited.com
---
.../bindings/sound/spdif-transmitter.txt | 10
On Fri, Apr 19, 2013 at 7:36 PM, Daniel Mack zon...@gmail.com wrote:
Hi Michal,
On 19.04.2013 15:38, Michal Bachraty wrote:
Add devicetree support for this dummy audio soc driver.
I think Mark wants to see only ASoC: in the patch subjects now.
Signed-off-by: Michal Bachraty
Calling clk-si5351 driver non-OF ready was too early. This patch
makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Reported-by: Stephen Rottweil s...@canb.auug.org.au
---
Cc: Stephen Rothwell s
On 04/12/2013 08:38 PM, Mike Turquette wrote:
Quoting Michal Bachraty (2013-04-09 01:26:15)
For gapless tuning, there is no need for PLL reset and clkout power-down
when tuning output. silabs,gapless-tuning parameter enables gapless tuning
for specific clock output.
Signed-off-by: Michal
On Thu, Apr 11, 2013 at 9:44 AM, Michal Bachraty
michal.bachr...@streamunlimited.com wrote:
On Wednesday, April 10, 2013 19:27:25 Sebastian Hesselbarth wrote:
Hmm, is there any driver using the clock output? Does it
clk_prepare_enable() the clock? I tend not to mess with anything
Commit 3d604da1e9547c09c9dcc0ee443c306c9ae1a480
(net: mvmdio: get and enable optional clock)
was missing an update of the corresponding device tree binding
documentation. This patch adds the clocks property to mvmdio
binding documentation.
Signed-off-by: Sebastian Hesselbarth
1 - 100 of 141 matches
Mail list logo
