On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
> Hi Philipp,
>
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> > This driver implements a reset controller device that toggle a gpio
> > connected to a reset pin of a peripheral IC. The delay between assertion
> > and d
device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup, remove
the pre-enable workaround in the MPC512x platform's clock driver
this change implements non-fatal clock lookup since not all platforms
provide device tree specs
device tree based clock lookup in the MPC512x initialization (lookup
'per' for register access), add error check in the clock setup, must
prepare clocks before they can get enabled, unprepare after disable
Signed-off-by: Gerhard Sittig
---
drivers/usb/host/fsl-mph-dr-of.c | 24 +---
make the MPC I2C driver prepare and enable the peripheral clock
('per' for register access) in the MPC512x setup routine,
make this clock setup non-fatal to allow for a migration period,
remove the pre-enabling hack in the platform's clock driver
Signed-off-by: Gerhard Sittig
---
arch/powerpc/pl
prepare and enable the FIFO clock upon PSC FIFO initialization, disable
and unprepare the FIFO clock upon PSC FIFO uninitialization, remove the
pre-enable workaround from the platform's clock driver
Signed-off-by: Gerhard Sittig
---
arch/powerpc/platforms/512x/clock-commonclk.c |2 --
driver
after the PSC drivers for UART and SPI mode got converted to device tree
based clock lookup, the former MCLK name which depends on the PSC index
isn't needed any longer -- remove the clk_register_clkdev() invocation
Signed-off-by: Gerhard Sittig
---
arch/powerpc/platforms/512x/clock-commonclk.c
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
> > It's a little bit late to register gpio-reset driver at module_init
> > time, because gpio-reset provides reset control via gpio for other
> > devices which are mostly probed at module_init time too. And it
> > becomes even worse,
On 07/15/2013 07:50 PM, Shawn Guo wrote:
> Hi Philipp,
>
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>> This driver implements a reset controller device that toggle a gpio
>> connected to a reset pin of a peripheral IC. The delay between assertion
>> and de-assertion of the re
On 07/15/2013 07:10 PM, Laurent Pinchart wrote:
> On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
...
>> I think the values for any common system-wide flags should be defined
>> once in some system-wide place, and the values for any HW-specific
>> values should be defined only in the document
On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
> From: "Mathieu J. Poirier"
>
> Adding a simple device tree binding for the specification of key sequences.
> Definition of the keys found in the sequence are located in
> 'include/uapi/linux/input.h'.
>
> For the sysrq driver, holding t
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
>
>
Hello,
On Friday 12 July 2013 11:40:44 Stephen Warren wrote:
> On 07/12/2013 11:24 AM, Thierry Reding wrote:
> > On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
> >> On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
> >>> Hi Stephen,
> >
> > [...]
> >
> >>> What about splitting it
Hi Stephen,
On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
> On 07/12/2013 05:01 AM, Laurent Pinchart wrote:
> > On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
> >> On 07/11/2013 01:32 PM, Thierry Reding wrote:
> >>> On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
>
With the introduction of the orion irqchip driver, now the BRIDGE_CAUSE
bit is cleared by it. There's no longer a need to do it in the watchdog
driver, so we can simply remove it.
Signed-off-by: Ezequiel Garcia
---
drivers/watchdog/orion_wdt.c | 7 ---
1 file changed, 7 deletions(-)
diff --
Now that the 'reg' property meaning has been changed,
this commit updates the deivce-tree binding documentation.
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/d
The mach/bridge-regs.h header is not needed anymore, so we can remove it.
This commit allows to use this driver on multiplatforms builds.
Signed-off-by: Ezequiel Garcia
---
drivers/watchdog/orion_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/orion_wdt
This is a purely cosmetic commit: we replace hardcoded values that
representing bits by BIT(), which is slightly more readable.
Signed-off-by: Ezequiel Garcia
---
drivers/watchdog/orion_wdt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/d
The watchdog driver now needs two 'reg' property cells. The first one
is for the register containing the watchdog counter, while the second
one is for the RSTOUT register.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/kirkwood.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Instead of accessing the RSTOUT register directly, this commit
adds a platform memory resource to map this register into the driver.
Note that by adding a required 2nd-cell for the reg property,
this change breaks the device-tree binding compatibility.
Signed-off-by: Ezequiel Garcia
---
arch/ar
Until now the watchdog driver was using the timer control register
to access the watchdog counter register. This is not appropriate,
given the timer control register should be controlled by the clocksource
driver alone.
Fix this by passing the correct register address to the driver and making
dire
Name this file to something a bit more judicious.
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/watchdog/{marvel.txt => orion-wdt.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/watchdog/{marvel.txt =>
orion-wdt.txt} (10
Add a header declaration to allow drivers (such as watchdog)
to access this exported API.
Signed-off-by: Ezequiel Garcia
---
include/linux/time-orion.h | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 include/linux/time-orion.h
diff --git a/include/linux/time-orion.h b/include/l
The TIMER_CTRL register allows to control timer and watchdog counters,
so it's a register shared between the clocksource and the watchdog
drivers. In order to prevent race-conditions the clocksource driver
exposed a thread-safe API. Use the API.
Signed-off-by: Ezequiel Garcia
---
drivers/watchdo
This patchset introduces a bunch of fixes that removes the direct use of
the shared timer control register, and also removes the need to include
a mach-specific header.
With this changes the driver can be included in multiplatforms builds,
and in particular be used for the Armada 370/XP SoC.
I'm
On 07/15/2013 12:59 PM, Sergei Shtylyov wrote:
> On 07/15/2013 10:40 PM, Stephen Warren wrote:
>
>> From: Stephen Warren
>
>> This is identical to of_parse_phandle_with_args(), except that the
>> number of argument cells is fixed, rather than being parsed out of the
>> node referenced by each ph
On 07/16/2013 12:51 AM, Felipe Balbi wrote:
> On Mon, Jul 15, 2013 at 09:09:02PM +0530, Kishon Vijay Abraham I wrote:
>> Modified dwc3-omap to receive connect and disconnect notification using
>> extcon framework. Also did the necessary cleanups required after
>> adapting to extcon framework.
>>
>>
On 07/15/2013 01:34 PM, Rob Herring wrote:
> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> This property is no longer required by the GPIO binding. Remove it.
>
> Won't this break compatibility with older kernel? It is one thing to
> deprecate, but removal is another
On Mon, Jul 15, 2013 at 11:46:01PM +0200, Gerhard Sittig wrote:
> with device tree based clock lookup, the MCLK name no longer
> depends on the PSC index
>
> Signed-off-by: Gerhard Sittig
> ---
> drivers/tty/serial/mpc52xx_uart.c |8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
with device tree based clock lookup, the MCLK name no longer
depends on the PSC index
Signed-off-by: Gerhard Sittig
---
drivers/tty/serial/mpc52xx_uart.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> > Based on the outcomes of the "Best practice device tree design for display
> > subsystems" discussion I have drafted a DT binding. Comments much
> > appreciated.
> >
> > At a
On Mon, Jul 15, 2013 at 4:29 PM, Jonathan Corbet wrote:
> Do we need a kernel summit discussion, or do we just need a good
> document? Or, to phrase the question another way, are we lacking a
> consensus among the clueful regarding how device tree bindings should be
> designed, or are we simply
ping ?
On 6/28/2013 4:25 PM, Rohit Vaswani wrote:
This series re-organizes the platsmp.c and adds SMP support for
MSM8660, MSM8960 and MSM8974.
We convert to using the cpus property in device tree and
add a "enable-method" property for arm32.
This helps select the appropriate release sequence fo
Hi,
On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote:
> On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> >>> I wasn't aware of
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to,
On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:
> clocks need to get prepared before they can get enabled,
> fix the MPC512x PSC SPI master's initialization
> Signed-off-by: Gerhard Sittig
> ---
> drivers/spi/spi-mpc512x-psc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deleti
On Mon, Jul 15, 2013 at 11:41:57AM -0700, Greg KH wrote:
> On Mon, Jul 15, 2013 at 06:06:00PM +0100, Mark Brown wrote:
> > At the minute it's about at the level of saying that if you're not sure
> > or don't know you should get the devicetree-discuss mailing list to
> > review it. Ideally someone
On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote:
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 6d55eb2..2c07061 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate
On 07/15/2013 01:40 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This property is no longer required by the GPIO binding. Remove it.
Won't this break compatibility with older kernel? It is one thing to
deprecate, but removal is another. If the relevant maintainers don't
care, then I gues
On Mon, 2013-07-15 at 09:56 -0700, Greg KH wrote:
> How about a hint for subsystem maintainers as to what exactly we should
> be looking for with these bindings? I for one have no idea what is
> "right" vs. "wrong" with them, so a document explaining this would be
> good to have.
>
> Or if we alr
On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
> On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
>> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
>> wrote:
>>> In order to extend the current cpu nodes bindings to newer CPUs
>>> inclusive of AArch64 and to update support for ol
adapt the DIU clock initialization to the COMMON_CLK approach: device
tree based clock lookup, prepare and unprepare for clocks, work with
frequencies not dividers, call the appropriate clk_*() routines and
don't access CCM registers, remove the pre-enable workaround in the
platform's clock driver
extend the mscan(4) driver with alternative support for the COMMON_CLK
approach which is an option in the MPC512x platform, keep the existing
clock support implementation in place since the driver is shared with
other MPC5xxx SoCs which don't have common clock support
one byproduct of this change
after PSC related clock specifiers were added to the device tree,
the former 'psc%d_mclk' isn't needed any longer to lookup clock items
Signed-off-by: Gerhard Sittig
---
drivers/spi/spi-mpc512x-psc.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/spi/spi-mpc512
this change introduces a clock infrastructure implementation for the
MPC512x PowerPC platform which follows the COMMON_CLK approach and uses
common clock drivers shared with other platforms
this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic i
add a comment about the magic of deriving an MSCAN component index
from the peripheral's physical address / register offset
Signed-off-by: Gerhard Sittig
---
drivers/net/can/mscan/mpc5xxx_can.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/mscan/mpc5x
this addresses the client side of device tree based clock lookups:
add clock specifiers to the mbx, nfc, mscan, sdhc, i2c, axe, diu,
viu, mdio, fec, usb, pata, psc, psc fifo, and pci nodes in the
shared mpc5121.dtsi include
these specs map 'clock-names' encoded in drivers to their respective
'stru
introduce a dt-bindings/ header file for MPC512x clocks,
providing symbolic identifiers for those SoC clocks which
clients will reference from their device tree nodes
Signed-off-by: Gerhard Sittig
---
include/dt-bindings/clock/mpc512x-clock.h | 59 +
1 file changed,
this addresses the clock driver aka provider's side of clocks
- prepare for future '<&clks ID>' phandle references for device tree
based clock lookup in client drivers
- introduce a 'clocks' subtree with an 'osc' node for the crystal
or oscillator SoC input (fixed frequency)
- provide default v
prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes
Signed-off-by: Gerhard Sittig
---
arch/powerpc/boot/dts/ac14xx.dts |2 +-
arch/powerpc/boot/dt
the common clock drivers were motivated/initiated by ARM development
and apparently assume little endian peripherals
wrap register/peripherals access in the common code (div, gate, mux)
in preparation of adding COMMON_CLK support for other platforms
Signed-off-by: Gerhard Sittig
---
drivers/clk
clocks need to get prepared before they can get enabled, and after
disabling them they can get unprepared
Signed-off-by: Gerhard Sittig
---
drivers/tty/serial/mpc52xx_uart.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tt
must prepare clocks before enabling them, unprepare after disable
Signed-off-by: Gerhard Sittig
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 3c9cdcb..eb7771d 100
reword the clock control module's registers declaration such that the
MCLK related registers form an array and get indexed by PSC number
this change is in preparation to COMMON_CLK support for the MPC512x
platform, the changed declaration remains neutral to existing code since
the PSC and MSCAN CC
this series introduces support for the common clock framework (CCF,
COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform, a
resulting debugfs clk_summary is at the end of the message after the
stats
although the series does touch several subsystems -- serial, spi, net
(can, fs_enet), m
clocks need to get prepared before they can get enabled,
fix the MPC512x PSC SPI master's initialization
Signed-off-by: Gerhard Sittig
---
drivers/spi/spi-mpc512x-psc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-
On Mon, Jul 15, 2013 at 06:06:00PM +0100, Mark Brown wrote:
> On Mon, Jul 15, 2013 at 09:56:20AM -0700, Greg KH wrote:
>
> > How about a hint for subsystem maintainers as to what exactly we should
> > be looking for with these bindings? I for one have no idea what is
> > "right" vs. "wrong" with
From: Stephen Warren
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren
Acked-by: Viresh Kumar
---
This should presumably be applied along with the previous changes
v2: Squash spear and mxc changes into a single patch; there's no
need to keep vf6
From: Stephen Warren
Commit bd69f73 "of: Create function for counting number of phandles in
a property" renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved, leaving it apparently
From: Stephen Warren
Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.
Signed-off-by: Stephen Warren
---
drivers/gpio/gpiolib-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/dri
From: Stephen Warren
This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS independant
where a
From: Stephen Warren
This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.
Signed-off-by: Stephen Warren
---
drivers/of/base.c | 67
On 07/15/2013 05:34:58 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt|8 +-
arch/
On 07/15/2013 08:35:07 AM, Kumar Gala wrote:
On Jul 5, 2013, at 1:27 AM,
wrote:
> +dma0: dma@100300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,elo3-dma";
why does this require a new compatible?
The binding has changed -- there is now a second reg entry.
Hi Sylwester,
On Mon, Jul 15, 2013 at 1:12 AM, Sylwester Nawrocki
wrote:
> Hi Prabhakar,
>
[Snip]
>> Something similar to fid_polarity.
>
>
> Then as I suggested earlier, let's just add 'sync-on-green-active' DT
> property for that. I wouldn't expect the DT properties to be directly
> replacing y
On Mon, Jul 15, 2013 at 09:56:20AM -0700, Greg KH wrote:
> How about a hint for subsystem maintainers as to what exactly we should
> be looking for with these bindings? I for one have no idea what is
> "right" vs. "wrong" with them, so a document explaining this would be
> good to have.
> Or if
On Sun, Jul 14, 2013 at 01:46:45AM +0200, Linus Walleij wrote:
> On Sat, Jul 13, 2013 at 10:49 PM, Guenter Roeck wrote:
> > On Sat, Jul 13, 2013 at 08:26:47PM +0100, Wolfram Sang wrote:
>
> >> I think the KS would be a good opportunity to present the status quo,
> >> show some rules of thumb and
On 07/15/2013 04:54 PM, Oleksandr Kravchenko wrote:
> I can't to find devm_iio_device_alloc() in my kernel v3.11-rc1
>
It doesn't exist yet, but it should be too hard to implement one.
- Lars
> On Mon, Jul 15, 2013 at 3:35 PM, Lars-Peter Clausen wrote:
>> On 07/15/2013 02:27 PM, Oleksandr Krav
On Mon, Jul 15, 2013 at 09:09:02PM +0530, Kishon Vijay Abraham I wrote:
> Modified dwc3-omap to receive connect and disconnect notification using
> extcon framework. Also did the necessary cleanups required after
> adapting to extcon framework.
>
> Signed-off-by: Kishon Vijay Abraham I
> Acked-by
Hello Thomas,
2013/7/15 Thomas Petazzoni :
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link", as a "fixed-link" property
> of the Ethernet device Device Tree node.
>
On Mon, Jul 15, 2013 at 05:09:48PM +0530, Srikanth Thokala wrote:
> This is the driver for AXI Traffic Generator IP. The AXI
> Traffic Generator IP is a core that stresses the AXI4
> interconnect and other AXI4 peripherals in the system.
> It generates a wide variety of AXI4 transactions based on
>
Hello Thomas,
2013/7/15 Thomas Petazzoni :
> The fixed_phy_add() function allows to register a fixed PHY. However,
> when this function gets called *after* fixed_mdio_bus_init() (which
> gets called at the module_init stage), then the fixed PHY is not
> registered into the phylib.
>
> In order to
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
This patch should be applied after all o
From: "Mathieu J. Poirier"
Adding a simple device tree binding for the specification of key sequences.
Definition of the keys found in the sequence are located in
'include/uapi/linux/input.h'.
For the sysrq driver, holding the sequence of keys down for a specific amount
of time
will reset the s
Following the introduction of of_phy_register_fixed_link(), this patch
introduces fixed link support in the mvneta driver, for Marvell Armada
370/XP SOCs.
Signed-off-by: Thomas Petazzoni
---
.../bindings/net/marvell-armada-370-neta.txt | 24 +++---
drivers/net/ethernet/marv
The fixed_phy_add() function allows to register a fixed PHY. However,
when this function gets called *after* fixed_mdio_bus_init() (which
gets called at the module_init stage), then the fixed PHY is not
registered into the phylib.
In order to address this, we add a call to mdiobus_scan() in
fixed_
Some Ethernet MACs have a "fixed link", and are not connected to a
normal MDIO-managed PHY device. For those situations, a Device Tree
binding allows to describe a "fixed link", as a "fixed-link" property
of the Ethernet device Device Tree node.
This patch adds:
* A documentation for the Device
Hello,
Following the discussion of last week with Florian Fainelli and Grant
Likely [1], this patch set introduces DT-based support for fixed PHYs
through an additional OF API, and uses it in the context of the
Marvell mvneta network driver.
Grant, Rob, your opinions as DT maintainers are welcome
On Mon, Jul 15, 2013 at 04:53:46PM +0200, Richard Genoud wrote:
> 2013/7/12 Mark Brown :
> > This isn't going to work with systems which have a variable clock as the
> > input to the CODEC. If it's imposing constraints the driver needs to
> > allow setting the clock to zero as a way of removing c
From: Thomas Petazzoni
After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.
Signed-off-by: Thomas Petazzoni
---
drivers/bus/mvebu-mbus.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff -
On Sat, Jul 13, 2013 at 12:15:12AM +0800, Robin Gong wrote:
Please fix your mail program to word wrap between paragraphs.
> On Fri, Jul 12, 2013 at 03:40:37PM +0100, Mark Brown wrote:
> > > +static const int pfuze100_swbst[] = {
> > > + 500, 505, 510, 515,
> > > +};
> > This loo
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +++
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia
---
arch/arm/
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia
---
arch/arm/mach-mvebu/platsmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/
On Mon, Jul 15, 2013 at 08:29:15AM -0600, Jonathan Corbet wrote:
> On Mon, 15 Jul 2013 10:36:22 +0200
> Linus Walleij wrote:
>
> > > Devicetree is supposed to describe the hardware, but in many cases there
> > > is
> > > an overlap between hardware description and configuration and/or use.
> >
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/arma
From: Thomas Petazzoni
These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.
Signed-off-by: Thomas Petazzoni
---
drivers/bus/mvebu-mbus.c | 14 +++---
1 file changed, 3 insertions(+),
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID
2013/7/12 Mark Brown :
> On Thu, Jul 11, 2013 at 06:15:54PM +0200, Richard Genoud wrote:
>> From: Nicolas Ferre
>>
>> Description of the Asoc machine driver for an at91sam9x5 based board
>
> ASoC.
>
>> +sam9x5 pins:
>> + * LOUT
>> + * ROUT
>> + * LHPOUT
>> + * RHPOUT
>> + * LLINEIN
>> + * RLINEIN
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behin
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts
From: Thomas Petazzoni
The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current n
From: Thomas Petazzoni
Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.
Signed-off-by: Thomas Petazzoni
---
drivers/bus/mvebu-mbus.c | 38 --
include/linux/mbus.h | 5 -
From: Thomas Petazzoni
This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.
Signed-off-by: Thomas Petazzoni
---
drivers/bus/mvebu-mbus.c | 150 +++
1 file changed,
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/b
We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.
Correspondingly, and in order to retrieve this information,
we add two new APIs.
S
From: Thomas Petazzoni
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni
---
arch/arm/mach-dove/common.c | 68 ++
From: Thomas Petazzoni
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni
---
arch/arm/mach-orion5x/common.c
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni
Si
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni
Si
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Acked-by: Greg Kroah-Hartman
Signed-of
1 - 100 of 117 matches
Mail list logo
