On Wed, Jun 19, 2013 at 10:58:34AM -0600, Jason Gunthorpe wrote:
On Wed, Jun 19, 2013 at 07:02:00AM -0300, Ezequiel Garcia wrote:
Verifying the DT is setup this way and aborting if it is not seems
like a good idea..
I agree it's a nice idea, but I'm not too sure how to accomplish
On Wed, Jun 19, 2013 at 12:03:20PM -0600, Jason Gunthorpe wrote:
On Wed, Jun 19, 2013 at 02:58:24PM -0300, Ezequiel Garcia wrote:
I wasn't sure you wanted to panic(), to clip on available CPUs,
or to just do a pr_warn / WARN(), so here's a piece of code:
(disclaimer: non-tested, non
On Wed, Jun 19, 2013 at 3:36 PM, Jason Cooper ja...@lakedaemon.net wrote:
On Tue, Jun 18, 2013 at 04:47:57PM -0300, Ezequiel Garcia wrote:
On Tue, Jun 18, 2013 at 09:42:48PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register
Hi Arnd,
On Tue, Jun 18, 2013 at 11:45:26PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+Required properties:
+
+- compatible: Should
On Wed, Jun 19, 2013 at 09:08:30PM +0200, Arnd Bergmann wrote:
On Wednesday 19 June 2013, Ezequiel Garcia wrote:
What happens is that any decoding window that was setup by the
bootloader,
is wiped and completely new windows are allocated using the translations
in the DT
clashing when using 0x.
* Replaced the PCIe mapping with 0x.
Thanks a lot!
Ezequiel Garcia (12):
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
ARM: mvebu
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 36
include/linux/mbus.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
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 ezequiel.gar...@free
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 ezequiel.gar
...@linuxfoundation.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Greg,
I'm Ccing you, since you're carrying the mvebu-devbus driver in your trees.
This patch should be applied only after the MBus DT binding is accepted
and/or merged; although I doubt we will see that happening any
The address decoding window to access the BootROM should not be
allocated programatically, but declared in the device tree.
Instead of allocating it, we add a check to verify the DT has
declared a valid node to access the BootROM.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
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
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
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 ezequiel.gar
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 ezequiel.gar...@free
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
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.
Signed-off-by: Ezequiel Garcia
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
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
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
On Tue, Jun 18, 2013 at 08:33:54AM -0400, Jason Cooper wrote:
On Tue, Jun 18, 2013 at 02:17:31PM +0200, Thomas Petazzoni wrote:
Dear Jason Cooper,
On Tue, 18 Jun 2013 07:39:20 -0400, Jason Cooper wrote:
On Tue, Jun 18, 2013 at 08:25:31AM -0300, Ezequiel Garcia wrote:
Now that mbus
Hi Sebastian,
On Tue, Jun 18, 2013 at 01:33:37PM +0200, Sebastian Hesselbarth wrote:
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
accurately, we declare the
real 1 MiB internal register space in the ranges, and add a translation
entry for the nand node to access the 'nand' window.
This commit will make future improvements on the MBus DT binding easier.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Tested
On Tue, Jun 18, 2013 at 11:39:06AM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel
On Tue, Jun 18, 2013 at 09:42:48PM +0200, Sebastian Hesselbarth wrote:
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
On Tue, Jun 18, 2013 at 02:10:21PM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
Having the kernel enforce that the DT node is present and at the right
location, I think, is helpful for the bootloader folks to ensure they
write correct DTs
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
The forms could be:
0IAA
FK00
- K=0 - internal regs
- K=1 - PCI-E
On Tue, Jun 18, 2013 at 02:55:22PM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On 06/18
Arnd,
On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- reg
On Tue, Jun 18, 2013 at 11:20:07PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
Arnd, we've discussed this at length with you while getting the PCIe
driver merged, and we've explained
On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10400 0x8;
+ ranges
On Tue, Jun 18, 2013 at 07:09:29PM -0300, Ezequiel Garcia wrote:
On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus
: Introduce Marvell EBU Device Bus driver
Thanks a lot!
Ezequiel Garcia (12):
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
ARM: mvebu: Initialize MBus using the DT binding
ARM
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 36
include/linux/mbus.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu
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 ezequiel.gar
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 2
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.
Signed-off-by: Ezequiel Garcia
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
Jason,
On Tue, Jun 11, 2013 at 03:50:23PM -0600, 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
On Wed, Jun 12, 2013 at 10:45:55PM +0200, Arnd Bergmann wrote:
On Wednesday 12 June 2013, Grant Likely wrote:
I think we should have almost everything needed already to do this.
of_bus allows arbitrary mapping code to be used at any stage in the
translation. We might need to add some glue
On Wed, Jun 12, 2013 at 03:26:42PM -0600, Jason Gunthorpe wrote:
On Wed, Jun 12, 2013 at 06:12:22PM -0300, Ezequiel Garcia wrote:
[...]
This departs considerably from what I'm aiming right now.
Are you suggesting to not put *any* mapping in the mbus 'ranges' node in
the DT (other
on my Kirkwood Openblocks A6 using the latest
branch orion-irqchip-for-v3.11-v4. Everything works fine so:
Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
For patches 3 to 6 I'm wondering if there's any reason why the irqchip and
clocksource changes are not separated. I'm probably
Hi Arnd,
I have another question!
On Fri, Jun 07, 2013 at 09:01:44PM +0200, Arnd Bergmann wrote:
[...]
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ reg = 0xd002 0x100, 0xd0020180 0x20;
+ };
+
+** How does it work?
+
+The
Jason, Arnd:
On Sat, Jun 08, 2013 at 07:45:06PM -0600, Jason Gunthorpe wrote:
[...]
This is the mangling I was referring to. It needs to be the offset
into the target, it can't be something else.
I see both of you have explained this already, but I can't seem
to catch it yet.
Mind
On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote:
On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote:
On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
Right. I think we have two options here for laying the DT ranges.
1) This is the proposal implied
On Sat, Jun 08, 2013 at 07:45:06PM -0600, Jason Gunthorpe wrote:
On Sat, Jun 08, 2013 at 03:38:52PM -0300, Ezequiel Garcia wrote:
[...]
There are lots and lots of solutions using the pre-processor, please
take a look and find one that you feel works for you...
Ok, I will.
We can always
Hi Jason, Arnd:
Thanks for your reviews!
I agree with most of your suggestions so far. However, I'd like to discuss
one point before we move forward with the other (imo, less importants)
issues. See below.
On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
[...]
Is the ranges
In order to clean message printing, we replace pr_info with pr_fmt.
This is purely cosmetic change, with the sole purpose of making
the code a bit more readable.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 8 +---
1 file changed, 5
From: Ezequiel Garcia ezequ...@free-electrons.com
This patchset introduces the MBus DT binding.
The MBus DT binding is in charge of several different tasks:
1. Allows the MBus driver to be probed through the Device Tree.
2. Allocates statically declared decoding windows, such as those
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 ezequiel.gar...@free
programatically, whenever a decoding window is allocated.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 177 ++-
1 file changed, 160 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 36
include/linux/mbus.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu
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 ezequiel.gar
behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370.dtsi | 6
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.
Signed-off-by: Ezequiel Garcia
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 ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/platsmp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach
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 ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
These properties are not needed so it's safe to remove them.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
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.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts
On Wed, May 15, 2013 at 03:25:21PM +0200, Thomas Petazzoni wrote:
[..]
+
+static int __init mvebu_pcie_probe(struct platform_device *pdev)
+{
+ struct mvebu_pcie *pcie;
+ struct device_node *np = pdev-dev.of_node;
+ struct of_pci_range range;
+ struct of_pci_range_parser
Thomas,
On Tue, Mar 26, 2013 at 05:52:15PM +0100, Thomas Petazzoni wrote:
This set of patches introduces Message Signaled Interrupt support in
the Marvell EBU PCIe driver. It has been successfully tested on the
Armada XP GP platform and the Armada 370 DB platform with an Intel
e1000e PCIe
Hi Jon,
On Fri, Mar 15, 2013 at 10:21:00AM -0500, Jon Hunter wrote:
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect
Hi Jon,
I have some tiny nitpicks...
On Fri, Mar 15, 2013 at 10:21:08AM -0500, Jon Hunter wrote:
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
mode, burst settings, wait monitoring etc.
Therefore, to simplify the GPMC code and add device-tree support for
NOR, it was first necessary to consolidate how these settings are
programmed.
Series based upon Mark Jackson's patch [1] and Ezequiel Garcia GPMC
clean-up series [2]. Entire series
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter jon-hun...@ti.com wrote:
Yes, I full agree with that as well. The size should be purely HW
related. So we should not take any assumption about the page size /
alignment.
Ok, what is best to use? The size from hwmod structures or the size from
the
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
Yes you are correct. In general, I have been trying to stay some-what
consistent with what hwmod was doing as this was being auto-generated
On Wed, Mar 6, 2013 at 1:54 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/06/2013 05:58 AM, Ezequiel Garcia wrote:
I'll submit this driver by the end of this week, in case you want
to take a look at it.
Ok
Jon,
On Tue, Mar 5, 2013 at 6:34 PM, Jon Hunter jon-hun...@ti.com wrote:
By the way, with this version you should remove simple-bus from your
gpmc node compatible strings. I now call of_platform_device_create() to
create the child device during the GPMC probe. I think that this is a
safer
On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/06/2013 05:58 AM, Ezequiel Garcia wrote:
I'll submit this driver by the end of this week, in case you want
to take a look at it.
Ok, but this is not for omap right?
No, this is a new driver for a memory controller
Hi Jon,
On Tue, Mar 5, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
This really highlights a weakness in the GPMC driver, particularly
for NOR, where the child device can only be probed once the parent
is probed. I don't see this as being DT specific issue, because
even on older OMAP
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc, simple-bus;
I'm concern about using simple-bus, and I'm not entirely sure this will work.
AFAIK, you can't correlate a parent-child
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
[...]
+ if (!of_property_read_u32(np, gpmc,bus-turnaround, val))
+ gpmc_t-bus_turnaround = val;
+
AFAIK, you don't need to test if the property is defined.
You can just read it straightforward,
On Fri, Mar 1, 2013 at 5:11 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
[...]
+ if (!of_property_read_u32(np, gpmc,bus-turnaround, val))
+ gpmc_t-bus_turnaround = val;
+
AFAIK, you don't
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
[...]
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct gpmc_settings gpmc_s;
+ struct gpmc_timings gpmc_t;
+
Hi Anil,
On Sat, Feb 16, 2013 at 05:08:27PM +0530, Anil Kumar wrote:
Add gpmc DT node.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 1acc261... 9f36531... March/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11
Hi Jason,
On Sat, Feb 16, 2013 at 10:02:28AM -0500, Jason Cooper wrote:
On Wed, Feb 06, 2013 at 10:06:24AM -0300, Ezequiel Garcia wrote:
The Armada XP DB-MV784MP-GP board has an SPI flash device.
These options allow to access that device over MTD.
Signed-off-by: Ezequiel Garcia
On Wed, Feb 13, 2013 at 09:13:27AM -0600, Jon Hunter wrote:
On 02/13/2013 05:13 AM, Ezequiel Garcia wrote:
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network
Hi Michal,
On Thu, Jan 10, 2013 at 12:40 PM, Michal Simek mon...@monstr.eu wrote:
Hi guys,
we want to add static memory controller driver for xilinx zynq to the
linux kernel. (It will go to drivers/memory/ folder)
Just need to clear dts fragment which describe it.
I'm working on a
On Tue, Feb 12, 2013 at 02:48:47PM +0100, Michal Simek wrote:
2013/2/12 Ezequiel Garcia elezegar...@gmail.com:
Hi Michal,
On Thu, Jan 10, 2013 at 12:40 PM, Michal Simek mon...@monstr.eu wrote:
Hi guys,
we want to add static memory controller driver for xilinx zynq to the
linux
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash
: mvebu: i2c come back in defconfig
Feel free to test or provide any feedback!
Ezequiel Garcia (4):
arm: mvebu: Add support for SPI controller in Armada 370/XP
ARM: mvebu: Update defconfig to select SPI support
arm: mvebu: Add SPI flash on Armada XP-GP board
ARM: mvebu: Update defconfig
of the two.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Acked-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Register offset must be 0x28 instead of 0x50
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Acked-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/configs/mvebu_defconfig |2 ++
1 files changed, 2 insertions
: Lior Amsalem al...@marvell.com
Tested-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Depends on Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
arch/arm
The Armada XP DB-MV784MP-GP board has an SPI flash device.
These options allow to access that device over MTD.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Depends on patch: arm: mvebu: i2c come back in defconfig
arch/arm/configs/mvebu_defconfig |3 +++
1 files
101 - 200 of 242 matches
Mail list logo
