Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Dear Andrew Lunn, On Sat, 20 Jul 2013 21:45:59 +0200, Andrew Lunn wrote: The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. For some reason I was completely sure there wasn't any DT-enabled Kirkwood boards with PCIe support. I had a quick look at Dove and Orion5x. It looks like there are none with PCIe support. So only Kirkwood is broken. There are some Dove and Orion5x with PCIe support, but none of them are using the new PCIe driver yet. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Dear Andrew Lunn, On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. This set of patches is just some preparation patches on the Orion watchdog driver, to later make it usable on Armada 370/XP. The patches enabling its usage on Armada 370/XP will follow. But Ezequiel will confirm all that, we had a discussion together about this yesterday, so I guess what I said should be the plan, but it's better if Ezequiel confirms, obviously :) Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
Dear Nicolas Ferre, On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote: Ok, that make sense. I will use compatible names for the capabilities in next version. Thanks. Hold on a little bit Josh, I know that Jean-Christophe is not in favor of the use of multiple compatible strings. So, as the code is already there, let's wait and see if we find another argument... I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
Dear Jonathan Cameron, On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote: On 07/16/2013 12:30 PM, Thomas Petazzoni wrote: I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Thanks for getting some clarity on this Thomas. So I'll ask the somewhat obvious question - how do we unwind from where we are to where we want to be wrt to the bindings? During Linaro Connect last week, there was some discussion about marking DT bindings as unstable for a little while, once they get reviewed by a group of DT experts that mark them as stable. Until they are stable, the kernel does not offer any ABI guarantees, and we are free to change the DT bindings as needed. Now, since this unstable/stable thing is not in place at the moment, deciding whether to break or not existing bindings is something to be decided by the maintainer of this platform, judging what is the best option depending on whether there are already many users of the DT for this platform or not, for example. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 0/3] Add DT support for fixed PHYs
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. Thanks! Thomas [1] http://www.spinics.net/lists/netdev/msg242766.html http://www.spinics.net/lists/netdev/msg243192.html Thomas Petazzoni (3): of: provide a binding for the 'fixed-link' property net: phy: call mdiobus_scan() after adding a fixed PHY net: mvneta: add support for fixed links .../devicetree/bindings/net/fixed-link.txt | 26 .../bindings/net/marvell-armada-370-neta.txt | 24 +-- drivers/net/ethernet/marvell/mvneta.c | 18 --- drivers/net/phy/fixed.c| 2 ++ drivers/of/of_mdio.c | 36 +++--- include/linux/of_mdio.h| 10 ++ 6 files changed, 104 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property
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 Tree property fixed-link.
* A of_phy_register_fixed_link() OF helper, which provided an OF node
that contains a fixed-link property, registers the corresponding
fixed PHY.
* Removes the warning on the of_phy_connect_fixed_link() that says
new drivers should not use it, since Grant Likely indicated that
this fixed-link property is indeed the way to go.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
.../devicetree/bindings/net/fixed-link.txt | 26
drivers/of/of_mdio.c | 36 +++---
include/linux/of_mdio.h| 10 ++
3 files changed, 68 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt
b/Documentation/devicetree/bindings/net/fixed-link.txt
new file mode 100644
index 000..25a009a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -0,0 +1,26 @@
+Fixed link Device Tree binding
+--
+
+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.
+
+Such a fixed link situation is described within an Ethernet device
+Device Tree node using a 'fixed-link' property, composed of 5
+elements:
+
+ 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
+the system.
+ 2. The duplex (1 for full-duplex, 0 for half-duplex)
+ 3. The speed (10, 100, 1000)
+ 4. The pause setting (1 for enabled, 0 for disabled)
+ 5. The asym pause setting (1 for enabled, 0 for disabled)
+
+Example:
+
+ethernet@0 {
+ ...
+ fixed-link = 1 1 1000 0 0;
+ ...
+};
+
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..66d5591 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -14,6 +14,7 @@
#include linux/netdevice.h
#include linux/err.h
#include linux/phy.h
+#include linux/phy_fixed.h
#include linux/of.h
#include linux/of_irq.h
#include linux/of_mdio.h
@@ -215,10 +216,6 @@ EXPORT_SYMBOL(of_phy_connect);
* @dev: pointer to net_device claiming the phy
* @hndlr: Link state callback for the network device
* @iface: PHY data interface type
- *
- * This function is a temporary stop-gap and will be removed soon. It is
- * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers. Do
- * not call this function from new drivers.
*/
struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
@@ -247,3 +244,34 @@ struct phy_device *of_phy_connect_fixed_link(struct
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+#if defined(CONFIG_FIXED_PHY)
+/**
+ * of_phy_register_fixed_link - Parse fixed-link property and register a dummy
phy
+ * @np: pointer to the OF device node that contains the fixed-link
+ * property for which a dummy phy should be registered.
+ */
+#define FIXED_LINK_PROPERTIES_COUNT 5
+int of_phy_register_fixed_link(struct device_node *np)
+{
+ struct fixed_phy_status status = {};
+ u32 fixed_link_props[FIXED_LINK_PROPERTIES_COUNT];
+ int ret;
+
+ ret = of_property_read_u32_array(np, fixed-link,
+fixed_link_props,
+FIXED_LINK_PROPERTIES_COUNT);
+ if (ret 0)
+ return ret;
+
+ status.link = 1;
+ status.duplex = fixed_link_props[1];
+ status.speed = fixed_link_props[2];
+ status.pause = fixed_link_props[3];
+ status.asym_pause = fixed_link_props[4];
+
+ return fixed_phy_add(PHY_POLL, fixed_link_props[0],
+status);
+}
+EXPORT_SYMBOL(of_phy_register_fixed_link);
+#endif
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..bf6efea 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -57,4 +57,14 @@ static inline struct mii_bus *of_mdio_find_bus(struct
device_node *mdio_np)
}
#endif /* CONFIG_OF */
+#if defined(CONFIG_OF) defined(CONFIG_FIXED_PHY)
+extern int of_phy_register_fixed_link(struct device_node *np);
+#else
+static inline int of_phy_register_fixed_link(struct device_node *np)
+{
+ return -ENOSYS;
+}
+#endif
+
+
#endif /* __LINUX_OF_MDIO_H */
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 2/3] net: phy: call mdiobus_scan() after adding a fixed PHY
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_phy_add() to ensure that the PHY indeed gets registered into the phylib, even if the fixed_phy_add() is called after fixed_mdio_bus_init(). This is needed because until now, the only code that was calling the fixed_add_phy() function was PowerPC-specific platform code, which could ensure that such fixed PHYs get registered before fixed_mdio_bus_init() is called. However, with the new of_phy_register_fixed_link() function, device drivers can parse their 'fixed-link' property and register a fixed PHY at -probe() time, which may happen after fixed_mdio_bus_init() is called. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- drivers/net/phy/fixed.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index ba55adf..bd1e67a 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -195,6 +195,8 @@ int fixed_phy_add(unsigned int irq, int phy_id, list_add_tail(fp-node, fmb-phys); + mdiobus_scan(fmb-mii_bus, phy_id); + return 0; err_regs: -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 3/3] net: mvneta: add support for fixed links
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 thomas.petazz...@free-electrons.com
---
.../bindings/net/marvell-armada-370-neta.txt | 24 +++---
drivers/net/ethernet/marvell/mvneta.c | 18 +++-
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 859a6fa..31e61c0 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -4,13 +4,21 @@ Required properties:
- compatible: should be marvell,armada-370-neta.
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
-- phy: A phandle to a phy node defining the PHY address (as the reg
- property, a single integer).
- phy-mode: The interface between the SoC and the PHY (a string that
of_get_phy_mode() can understand)
- clocks: a pointer to the reference clock for this device.
-Example:
+Optional properties:
+
+- phy: A phandle to a phy node defining the PHY address (as the reg
+ property, a single integer). Note: if this property isn't present,
+ then fixed link is assumed, and the 'fixed-link' property is
+ mandatory.
+- fixed-link: A 5 elements array that describe a fixed link, see
+ fixed-link.txt for details. Note: if a 'phy' property is present,
+ this 'fixed-link' property is ignored.
+
+Examples:
ethernet@d007 {
compatible = marvell,armada-370-neta;
@@ -21,3 +29,13 @@ ethernet@d007 {
phy = phy0;
phy-mode = rgmii-id;
};
+
+ethernet@d007 {
+ compatible = marvell,armada-370-neta;
+ reg = 0xd007 0x2500;
+ interrupts = 8;
+ clocks = gate_clk 4;
+ status = okay;
+ fixed-link = 1 1 1000 0 0;
+ phy-mode = rgmii-id;
+};
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 712779f..0bd1590 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2349,8 +2349,12 @@ static int mvneta_mdio_probe(struct mvneta_port *pp)
{
struct phy_device *phy_dev;
- phy_dev = of_phy_connect(pp-dev, pp-phy_node, mvneta_adjust_link, 0,
-pp-phy_interface);
+ if (pp-phy_node)
+ phy_dev = of_phy_connect(pp-dev, pp-phy_node,
mvneta_adjust_link, 0,
+pp-phy_interface);
+ else
+ phy_dev = of_phy_connect_fixed_link(pp-dev, mvneta_adjust_link,
+ pp-phy_interface);
if (!phy_dev) {
netdev_err(pp-dev, could not find the PHY\n);
return -ENODEV;
@@ -2708,9 +2712,13 @@ static int mvneta_probe(struct platform_device *pdev)
phy_node = of_parse_phandle(dn, phy, 0);
if (!phy_node) {
- dev_err(pdev-dev, no associated PHY\n);
- err = -ENODEV;
- goto err_free_irq;
+ /* No 'phy' found, see if we have a 'fixed-link'
+* property */
+ err = of_phy_register_fixed_link(dn);
+ if (err 0) {
+ dev_err(pdev-dev, no 'phy' or 'fixed-link'
properties\n);
+ goto err_free_irq;
+ }
}
phy_mode = of_get_phy_mode(dn);
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Fixed PHY Device Tree usage?
Dear Grant Likely, On Fri, 12 Jul 2013 23:44:21 +0100, Grant Likely wrote: I think this discussion is going in the wrong direction. The concept of a dummy phy is really a Linux kernel internal detail. Creating some kind of dummy MDIO bus node does not describe the hardware. This is exactly what I was suggesting in my original e-mail of this thread, see http://marc.info/?l=linux-netdevm=137338762627063w=2 : One option is to implement a Device Tree binding for the fixed PHY driver (the exact DT binding would have to be discussed), but I'm wondering whether describing a fixed PHY in the DT is actually correct, because describing a fixed PHy is not really describing the hardware, the hardware is actually a switch. There is already support in the kernel for Ethernet MACs connected directly to a switch or other device. It is far better to describe how the MAC needs to be configured than to invent a non-existent phy. Search for fixed-link in the kernel tree to see how it is used. As Florian pointed out, the of_phy_connect_fixed_link() comment indicates: * This function is a temporary stop-gap and will be removed soon. It is * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers. Do * not call this function from new drivers. Also, it would probably be good to have a few more helpers to make parsing the phy and fixed-link property easier for network drivers. Thanks for your feedback, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Fixed PHY Device Tree usage?
Dear Florian Fainelli,
On Wed, 10 Jul 2013 18:23:30 +0100, Florian Fainelli wrote:
- declare all PHY nodes in the system as sub nodes of their belonging
real hardware MDIO bus node
- flag specific PHY nodes as fixed with a fixed-link boolean for
instance
- if we see that flag, make that specific PHY node bind to the
fixed-phy driver instead
So the fixed PHY driver is going to travel through *all* nodes of the
DT, and whenever some random node has a fixed property, it's going to
say it corresponds to a fixed PHY? That doesn't seem like a good idea.
Why not? Since we are already have to scan the entire MDIO bus we are
attached to, when we encounter such a PHY node with the special
fixed properties, we just call fixed_phy_add() with the right
parameters and voila. Which is also the reason why I was suggesting to
put the fixed PHY nodes as sub-nodes of the real MDIO node such that
we have this logic only in one place.
I'm still not sure to understand you here. Scanning the *entire* DT
tree and consider all nodes having a property named fixed as fixed
PHYs is definitely not acceptable. So I suppose you have a different
idea, but I'm still not getting it. Where in the DT would the fixed PHY
driver start looking for fixed PHYs ?
So that's really what I was asking: how is the fixed PHY driver going
to know which DT nodes to look at. Is it a platform_driver, where the
corresponding DT node has sub-nodes? Is it something else? Or a
specific compatible string?
Without DT at play here, the usual way to register a fixed PHY is:
1) make your arch code or whatever runs before the fixed MDIO bus
probing to call fixed_phy_add() with the expected parameters
2) when your ethernet driver probes its PHY devices, format the phy
name to be bound to the fixed bus with the expected address by then
the fixed MDIO bus would have already been probed and would find the
fixed PHY nodes because of the first step
3) call of_phy_connect() from your driver to attach to the fixed PHY
Right, but that's still doesn't answer the question of how the fixed
PHY driver discovers from the DT which PHYs to instantiate.
For example, we would probably have something:
phys {
phy0: phy@0 {
... PHY properties ...
};
phy1: phy@1 {
... PHY properties ...
};
};
soc {
ethernet@0 {
compatible = ...;
...
phy = phy0;
};
ethernet@1 {
compatible = ...;
...
phy = phy1;
};
};
How will the fixed PHY driver know that it should instantiate
phy@0 and phy@1 as PHY devices?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Fixed PHY Device Tree usage?
Dear Florian Fainelli,
On Fri, 12 Jul 2013 13:05:59 +0100, Florian Fainelli wrote:
I am talking about scanning the MDIO bus DT nodes, not the entire DT.
That job is already done by of_mdiobus_probe() to register PHY
devices, so having a central point where the knowledge of how to treat
PHY deivces could be here I guess.
So, I guess your idea is to call of_mdiobus_register() from
drivers/net/phy/fixed.c:fixed_mdio_bus_init(). But then, what DT node
will you be passing to of_mdiobus_register() ? As a reminder, this
function takes as a second argument the DT node that contains the
various PHYs as sub-nodes.
In all the other PHY drivers, the MDIO bus node as a compatible string,
so the usual platform_driver/platform_device mechanism kicks in, and
calls the -probe() function, passing the DT node of the MDIO bus,
which is then used by the PHY driver -probe() function as the second
argument of of_mdiobus_register().
But the fixed.c PHY driver is not a platform_driver, and in our
discussion, we mentioned that it wouldn't make sense to have a
compatible string for the fixed MDIO bus DT node.
So I'm still unsure *which* DT node you'll pass as the second argument
of of_mdiobus_register() :-)
Well either we go with some specific compatible property like
ethernet-phy-fixed for instance, or we simply add a boolean property
to the node, so a fixed PHY would either look like this:
phy {
compatible = linux,ethernet-phy-fixed;
speed = 1000;
duplex = 1;
pause;
asym-pause;
};
or respectively, something like this:
phy {
fixed;
speed = 1000;
duplex = 1;
pause;
asym-pause;
};
Yeah, that's fine, I have no problem with the internal properties of
the PHY nodes themselves. My question is really the one described above.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Fixed PHY Device Tree usage?
Dear Florian Fainelli,
On Tue, 09 Jul 2013 19:02:05 +0100, Florian Fainelli wrote:
We have a case of an hardware platform that uses the mvneta network
driver, but instead of the SoC being connected to a PHY, it's connected
directly to a switch, so my understanding is that there's no MDIO bus,
and we should have a kind of a fake PHY to make the mvneta driver
believe that the link is up, at a given speed.
Good timing, I was about to post questions/suggestions about how we
should represent fixed PHYs in device tree.
Great.
Well, it does not seem to be too far from the hardware reality to
describe a link between a switch CPU port and an Ethernet MAC as a
fixed PHY because that is what it really is in fact. Once you have a
drivers for your switch you can start using this PHY along with its
corresponding driver.
Ok.
There is a helper: of_phy_connect_fixed_link() in drivers/of/of_mdio.c
is flagged as being a
temporary solution for Freescale Ethernet drivers to move to something else,
so I would like to discuss what the something else should be.
Yeah, I saw this helper function as well, and the comment you spotted.
Here what I would like to see the new fixed-link phy node look like:
ethernet-phy@0 {
reg = 0;
id = deadbeef;
speed = 1000;
full-duplex;
pause;
asym-pause;
};
It has the same properties as the binding described in:
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt but expressed in a
more explicit way instead of using an array of integers.
And so the fixed-phy driver would look for what exactly in the Device
Tree to find which fixed PHYs to create?
Should we have something like:
mdio-fixed {
compatible = generic,mdio-fixed;
phy0: ethernet-phy@0 {
... all the properties you listed ...
... maybe the id property is not needed
because of the phandle ...
};
phy1: ethernet-phy@1 {
... all the properties you listed ...
... maybe the id property is not needed
because of the phandle ...
};
};
soc {
ethernet@0 {
phy = phy0;
...
};
ethernet@1 {
phy = phy1;
...
};
};
or do you have in mind another representation?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Fixed PHY Device Tree usage?
Dear Florian Fainelli,
On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:
Should we have something like:
mdio-fixed {
compatible = generic,mdio-fixed;
phy0: ethernet-phy@0 {
... all the properties you listed ...
... maybe the id property is not needed
because of the phandle ...
In the fixed-phy terminology id is unfortunately ambiguous, the
driver internally uses phy_id which is nothing more than a PHY
address, but it also supports being assigned an id as in
Identification register 2 3. I was refering to the identification
register by id.
Hum, but your id property contained a string, so I'm not sure how it
would fit in Identification register 2 and 3. Am I missing something
obvious here? Maybe you wanted to have:
id = 0xdeadbeef;
which would make the emulated PHY return 0xdeadbeef as its PHY ID
when reading those identification registers.
};
phy1: ethernet-phy@1 {
... all the properties you listed ...
... maybe the id property is not needed
because of the phandle ...
};
};
soc {
ethernet@0 {
phy = phy0;
...
};
ethernet@1 {
phy = phy1;
...
};
};
or do you have in mind another representation?
Not really this is more or less what I had in mind. I am wondering
whether we should really declare the mdio-fixed node, or if we
should not rather make the following:
- declare all PHY nodes in the system as sub nodes of their belonging
real hardware MDIO bus node
- flag specific PHY nodes as fixed with a fixed-link boolean for instance
- if we see that flag, make that specific PHY node bind to the
fixed-phy driver instead
So the fixed PHY driver is going to travel through *all* nodes of the
DT, and whenever some random node has a fixed property, it's going to
say it corresponds to a fixed PHY? That doesn't seem like a good idea.
So that's really what I was asking: how is the fixed PHY driver going
to know which DT nodes to look at. Is it a platform_driver, where the
corresponding DT node has sub-nodes? Is it something else? Or a
specific compatible string?
What do you think? I suspect someone might rightfully say that the
fixed-mdio is not a real piece of hardware and is just a software
concept. A PHY in the real world may very well have a fixed link
speed/duplex/pause settings on the other end.
I agree that the mdio-fixed idea is clearly moving away from the
hardware representation. But see my question above: we need a way of
letting the fixed PHY driver know which DT nodes it should have a look
at. And just saying those nodes will have property 'foo' is not
sufficient.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
Dear Neil Zhang, On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote: support CLOCKSOURCE OF DECLARE for mmp timer. Signed-off-by: Neil Zhang zhan...@marvell.com --- arch/arm/mach-mmp/mmp-dt.c |5 ++--- arch/arm/mach-mmp/mmp2-dt.c |3 +-- arch/arm/mach-mmp/time.c| 15 ++- 3 files changed, 5 insertions(+), 18 deletions(-) Maybe it would be good to take this opportunity to move arch/arm/mach-mmp/time.c into drivers/clocksource/. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
Dear Jason Gunthorpe, Thanks for your quick feedback! On Fri, 5 Jul 2013 16:08:20 -0600, Jason Gunthorpe wrote: On Fri, Jul 05, 2013 at 06:39:11PM -0300, Ezequiel Garcia wrote: ranges = 0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 0x4 0 0x2000 /* Port 0.0 registers */ 0x8200 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x2000 /* Port 2.0 registers */ 0x8200 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x2000 /* Port 0.1 registers */ 0x8200 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x2000 /* Port 0.2 registers */ 0x8200 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x2000 /* Port 0.3 registers */ 0x82000800 0 0xe000 MBUS_ID(0x04, 0xe8) 0xe000 0 0x0800 /* Port 0.0 MEM */ 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe800 0 0x0010 /* Port 0.0 IO */; This is a good try, but this coding doesn't work... Recall the long discussion that came up during the original development of this binding. The OF spec says this: In particular, the phys.hi fields of the child address spaces in the ranges property for PCI does not contain the same information as reg property entries within PCI nodes. The only information that is present in ranges phys.hi entries are the non-relocatable, prefetchable and the PCI address space bits for which the en- try applies. I.e., only the n, p and ss bits are present; the , d, fff and fields are 0. When an address is to be mapped through a PCI bus bridge node, the phys.hi value of the address to be mapped and the child field of a ranges entry should be masked so that only the ss bits are compared. I.e., the only portion of phys.hi that should participate in the range determination is the address space indicator (the ss bits). Which forbids (0x82000800 .. ..) from being in a ranges Ah, right, I missed this part of the OF specification. Indeed, having the d bits non-zero was critical here to allow the PCIe driver to find which MBUS_ID(x, y) to use for a particular PCIe interface. I don't have an idea how to encode MBUS_ID in the PCI-E ranges :( Arnd? Didn't you have some idea? FWIW, I like removing the string tables from the driver, you could keep the fake MBUS-ID and retain that change by adding a marvell,target-id type property to the bridges... The problem we were trying to address here is that apparently the fake MBUS-ID was not seen by Arnd as a correct solution, if we understood correctly what Arnd said in http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg34650.html: Using 0x0002 as a placeholder for the pcie translation is definitely better than 0x as you had before, but let me ask again in case you missed it the last time (and sorry if I missed the answer): Why not just put the actual translation here the way it happens for each of the PCIe ports? With the definition here, the PCIe driver actually has no way to figure out what settings the windows need to use! We're not sure how to handle this comment properly in terms of DT binding. What the PCIe driver needs is: *) One global range of addresses for PCIe memory regions and one global range of addresses for PCIe I/O regions. Those were until the v5 of this patch set expressed using a fake MBUS_ID(0xf0, 0x02). Those are global to all PCIe interfaces. *) The target and attribute values for MEM and I/O windows, that are per-PCIe interface. As long as we can get those two informations from the DT, I believe we're open to all your suggestions on how to encode them. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
/* Port 2.0 registers */
0x8200 0 0x44000 MBUS_ID(0xf0, 0x01)
0x44000 0 0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 MBUS_ID(0xf0, 0x01)
0x48000 0 0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 MBUS_ID(0xf0, 0x01)
0x4c000 0 0x2000 /* Port 0.3 registers */
0x8200 1 0 MBUS_ID(0x04, 0xe8) 0 1 0
/* Port 0.0 MEM */
0x8100 1 0 MBUS_ID(0x04, 0xe0) 0 1 0
/* Port 0.0 IO */
0x8200 2 0 MBUS_ID(0x08, 0xe8) 0 1 0
/* Port 1.0 MEM */
0x8100 2 0 MBUS_ID(0x08, 0xe0) 0 1 0
/* Port 1.0 IO */;
pcie@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x4 0
0x2000;
reg = 0x0800 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 1 0 1 0
0x8100 0 0 0x8100 1 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 58;
marvell,pcie-port = 0;
marvell,pcie-lane = 0;
clocks = gateclk 5;
status = disabled;
};
pcie@2,0 {
device_type = pci;
assigned-addresses = 0x82002800 0 0x8 0
0x2000;
reg = 0x1000 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 2 0 1 0
0x8100 0 0 0x8100 2 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 62;
marvell,pcie-port = 1;
marvell,pcie-lane = 0;
clocks = gateclk 9;
status = disabled;
};
};
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
mbusc: mbus-controller@2 {
reg = 0x2 0x100, 0x20180 0x20;
};
interrupt-controller@2 {
reg = 0x20a00 0x2d0, 0x21070 0x58;
};
};
};
I.e, the changes are :
(1) The main soc {} node gains two new additional DT properties:
pcie-mem-aperture and pcie-io-aperture. The mvebu-mbus reads those
informations, and provides an API
mvebu_mbus_alloc_pcie_{mem,io}_aperture(phys_addr_t *base, size_t
*size) that allows the PCIe driver to get the mem and I/O
apertures for PCIe. In the future, the mvebu-mbus driver may
decide to allocate those apertures dynamically rather than have
values hardcoded in the DT: this is the private business of
mvebu-mbus. For now, the mvebu-mbus driver will use those static
values from the DT, as we don't want to do a full dynamic window
base address allocation for now. This makes sense, as mvebu-mbus
is the gake keeper of what gets mapped in terms of mbus windows.
(2) The ranges property of the main pcie-controller {} node is changed
to use 0x8200 and 0x8100 for all PCIe interfaces, as requested
by the OF spec. The second 32 bits word of the child address is used
to encode the port number (in our example 1 for the first MEM and I/O
ranges, and 2 for the next MEM and I/O ranges).
(3) A non-empty range property is added in the child pcie@x,y nodes to
translate back into regular PCIe addresses the child addresses
described in the ranges property in pcie-controller. I.e, it
simply translate (0x8200 0 0) into (0x820 port 0).
Arnd, Jason, if you could confirm that you both agree with this DT
binding soon, Ezequiel and I would quickly adapt the code accordingly,
and hopefully converge towards a final patch set.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Re: [PATCH V10 0/4] PCIe support for Samsung Exynos5440 SoC
Dear Arnd Bergmann, On Fri, 21 Jun 2013 09:31:58 +0200, Arnd Bergmann wrote: Bjorn, are you still considering to merge this for 3.11 or have you closed your tree for the merge window? I think it would be good to get it in. Note that the of/pci changes needed for this driver are merged through the arm-soc tree, with the of maintainers ACKs. They are already in arm-soc for-next, through Jason Cooper's tree. 4e23d3f505e8acfeac7cc33d4113fbb5a25c3090 of/pci: Add of_pci_parse_bus_range() function 45ab9702fb47d18dca116b3a0509efa19fbcb27a of/pci: Add of_pci_get_devfn() function 29b635c00f3ebcdaf7a52c4948f6d948ad3757d3 of/pci: Provide support for parsing PCI DT ranges property Also, it depends on the Marvell PCIe driver (but to a lesser extent), which is the one that creates the drivers/pci/host/Kconfig and drivers/pci/host/Makefile. 45361a4fe4464180815157654aabbd2afb4848ad pci: PCIe driver for Marvell Armada 370/XP systems I am by far not an expert on how to solve merge strategies and so on, but to avoid conflicts at Linus's level while merging the arm-soc and pci trees, it would be better if this Samsung PCIe driver could go through arm-soc (with Bjorn ACK, of course), so that Arnd/Olof can make sure the ordering is correct with regard to the of/pci changes and the mvebu/pci driver. I'll let you discuss that with Jason Cooper. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V6 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
Dear Jingoo Han,
On Thu, 20 Jun 2013 16:12:24 +0900, Jingoo Han wrote:
- pinctrl {
+ pin_ctrl: pinctrl {
compatible = samsung,exynos5440-pinctrl;
I know I'm nitpicking, but isn't this change completely unrelated to
PCIe support?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V6 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
Dear Jingoo Han,
On Thu, 20 Jun 2013 16:57:32 +0900, Jingoo Han wrote:
- pinctrl {
+ pin_ctrl: pinctrl {
compatible = samsung,exynos5440-pinctrl;
I know I'm nitpicking, but isn't this change completely unrelated to
PCIe support?
This change is related to PCIe support.
Without this, I cannot use gpio binding.
This change was guided by Thomas Abraham (Author of Samsung pinctrl).
Also, it was confirmed by Kukjin Kim (Maintainer of Samsung SoC).
Thank you for your caring. :)
I mean, the change is fine for sure, but it should maybe part of a
separate patch as it is more a fix than really the introduction of the
PCIe controller node, as the patch title suggests. This would also for
example allow this fix to be merged right now (for 3.11), regardless of
what happens for the rest of your PCIe patches.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding
Dear Arnd Bergmann, On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote: Using 0x0002 as a placeholder for the pcie translation is definitely better than 0x as you had before, but let me ask again in case you missed it the last time (and sorry if I missed the answer): Why not just put the actual translation here the way it happens for each of the PCIe ports? With the definition here, the PCIe driver actually has no way to figure out what settings the windows need to use! Come on Arnd, this is something we have already discussed *countless* times with you. We *cannot* define translations for each PCIe port because we don't know in advance how much I/O and memory space each PCIe device will request. This is the reason why we have *one* global range for I/O space and *one* global space for memory space, that are given to the Linux PCI core, which then dynamically assigns sub-ranges for each PCIe device into those two global ranges. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes
Dear Arnd Bergmann, On Tue, 18 Jun 2013 18:29:35 +0200, Arnd Bergmann wrote: To clarify my earlier comment, I think it would be nicer to write this as ranges = 0x8200 0 0x40x0001 0x4 0 0x2000 0x8200 0 0x80x0001 0x8 0 0x2000 0x8200 1 0 MBUS_ID(0x12, 0x34) 0 1 0 0x8200 2 0 MBUS_ID(0x13, 0x34) 0 1 0 0x8100 1 0 MBUS_ID(0x12, 0x35) 0 0 0x1; 0x8100 2 0 MBUS_ID(0x13, 0x35) 0 0 0x1; The MBUS_ID numbers above are made up since I don't know them, but this way you can describe how the entire 4GB MMIO address space of the PCI bus is mapped into the MBUS address space. This is *NOT* possible because we don't know in advance how much memory space and I/O space each PCIe device will require. Arnd, we've discussed this at length with you while getting the PCIe driver merged, and we've explained this to you numerous times. Could you please understand that *any* of your proposal that suggests writing down static windows for PCIe devices will *not* work? Does this make sense? Not at all. Please read once again the hundreds of e-mails we've exchanged about the need for dynamic windows for PCIe devices, which lead us to have the emulated PCI-to-PCI bridge stuff. I'm starting to be fed up to re-explain this to you over-and-over again. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes
Dear Arnd Bergmann, On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote: ranges = 0x8200 0 0x40x0001 0x4 0 0x2000 0x8200 0 0x80x0001 0x8 0 0x2000 0x8200 1 0 MBUS_ID(0x12, 0x34) 0 1 0 0x8200 2 0 MBUS_ID(0x13, 0x34) 0 1 0 0x8100 1 0 MBUS_ID(0x12, 0x35) 0 0 0x1; 0x8100 2 0 MBUS_ID(0x13, 0x35) 0 0 0x1; The MBUS_ID numbers above are made up since I don't know them, but this way you can describe how the entire 4GB MMIO address space of the PCI bus is mapped into the MBUS address space. This is NOT possible because we don't know in advance how much memory space and I/O space each PCIe device will require. Arnd, we've discussed this at length with you while getting the PCIe driver merged, and we've explained this to you numerous times. Could you please understand that any of your proposal that suggests writing down static windows for PCIe devices will not work? Where did I suggest static windows for PCIe devices? Where does your new proposal buys us anything useful compared to the existing PCIe DT binding that has been discussed at length with you? Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/6] ARM: kirkwood: move device tree nodes to DT irqchip and clocksource
Dear Sebastian Hesselbarth,
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;
+ interrupt-parent = bridge_intc;
+ interrupts = 3;
clocks = gate_clk 7;
status = okay;
};
The watchdog driver is mapping the same registers as the timer driver
(0x20300) and is poking into the same TIMER_CTRL register that controls
both the timers and the watchdog.
In addition to this, the watchdog driver also pokes into some other
registers, such as BRIDGE_CAUSE and RSTOUTn_MASK.
As we want to bring watchdog support for Armada 370/XP, I'm wondering
if we should fix those problems, and if yes, how:
(1) The timer driver is also responsible for handling the watchdog
(probably the easiest solution)
(2) Have some sort of 'common code' between the timer driver and the
watchdog driver to control the access to the shared TIMER_CTRL
register.
(3) Something else.
And this still does not solve the access to BRIDGE_CAUSE and
RSTOUTn_MASK.
Ideas?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/14] bus: mvebu-mbus: Use pr_fmt
Dear Ezequiel Garcia, On Fri, 7 Jun 2013 13:47:38 -0300, Ezequiel Garcia wrote: 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 Acked-by: Thomas Petazzoni thomas.petazz...@free-electrons.com I believe this one could be applied regardless of what happens to the rest of the patch series. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: mvebu: Remove device tree unused properties on A370
Dear Ezequiel Garcia, On Fri, 7 Jun 2013 13:47:49 -0300, Ezequiel Garcia wrote: These properties are not needed so it's safe to remove them. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Acked-by: Thomas Petazzoni thomas.petazz...@free-electrons.com I believe this one should be applied now, regardless of what happens to the rest of the patch series. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Dear Tomasz Figa, On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote: I don't see any other solution here than moving all the Allwinner code to DT (as it has been suggested in this thread several times already), as this is the only hardware description method supported by ARM Linux. Have you noticed that it is already the case in mainline? My colleague Maxime Ripard (Cc'ed) is the maintainer of the mainline Allwinner sunxi effort. It already supports a number of boards, has a pinctrl driver, a GPIO driver, serial port is working, network is working, I2C is working. All in mainline, completely Device Tree based. So isn't this entire discussion completely moot? The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hello, On Wed, 5 Jun 2013 16:48:27 -0400, jonsm...@gmail.com wrote: fex covers *eevvveeerrthng* - right from flipping the multiplexing for all 3 SD/MMC cards so that you can pretend that SD0 is SD2 and you can specify *different* GPIOs for each to say which is You can do all of this in device tree too. If the exact syntax doesn't exist you can use 'allwinner,' prefixes on the node names. Also check out pinctrl so that it doesn't get reinvented. Are people looking at the mainline source code? There is already a pinctrl driver for sunxi platforms (i.e Allwinner SoCs), it's at drivers/pinctrl/pinctrl-sunxi.c, and it's DT-based and allows to describe the pin muxing in the Device Tree. Cc'ing Maxime Ripard, who is the mach-sunxi maintainer in the mainline kernel. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/10] arm: add basic support for Rockchip RK3066a boards
Dear Heiko Stübner, On Mon, 3 Jun 2013 01:02:20 +0200, Heiko Stübner wrote: index 000..a2d8c70 --- /dev/null +++ b/arch/arm/mach-rockchip/Makefile.boot @@ -0,0 +1,3 @@ +zreladdr-$(CONFIG_ARCH_ROCKCHIP) := 0x60408000 +params_phys-$(CONFIG_ARCH_ROCKCHIP) := 0x60088000 +initrd_phys-$(CONFIG_ARCH_ROCKCHIP) := 0x6080 Thanks to the AUTO_ZRELADDR thing that you're using as part of the MULTIPLATFORM support, this Makefile.boot file is no longer useful. See mach-socfpga, mach-mvebu, mach-bcm2835, mach-bcm, mach-highbank, etc. Cc'ing Maxime Ripard, since I see that mach-sunxi does have a Makefile.boot, even though I believe it is not needed. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] pci: mvebu: fix return value check in mvebu_pcie_probe()
Dear Wei Yongjun, On Mon, 27 May 2013 11:38:41 +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, function of_clk_get_by_name() returns ERR_PTR() never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Jason, this needs to be in the mvebu/pcie branch, so I'll guess you would have to rebase mvebu/pcie_bridge on top of it. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
Dear Mike Turquette, On Wed, 15 May 2013 14:41:54 -0700, Mike Turquette wrote: Quoting Thomas Petazzoni (2013-05-15 06:25:19) The Armada 370 has two gatable clocks for each PCIe interface, and we want both of them to be enabled. We therefore make one of the two clocks a child of the other, as we did for the sataX and sataXlnk clocks on Armada XP. Ack for patches #5 and #6. Do you want me to take them? I don't know, I guess with your Ack, it would be easier to carry them through the Marvell maintainers and then the arm-soc tree, so 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 to let you take #5 and #6 in this patch series. That's something to be discussed with the Marvell maintainers (Jason Cooper, Andrew Lunn, Gregory Clement). Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Jason Cooper, On Thu, 16 May 2013 11:40:31 -0400, Jason Cooper wrote: +static int mvebu_pcie_init(void) Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs
Gunthorpe. * Make the allocation of address decoding windows dynamic: it's when memory accesses or I/O accesses are enabled at the PCI-to-PCI bridge level that we allocate and setup the corresponding address decoding window. Requested by Bjorn Helgaas. * Fixed the implementation of I/O accesses to use I/O addresses that fall within the normal IO_SPACE_LIMIT. This required using the remap functionality of address decoding windows, and therefore some changes in the address decoding window allocator. Follows a long discussion about I/O accesses. * Set up a correct bus number in the configuration of the PCIe interfaces so that we don't have to fake bus numbers anymore. Requested by Jason Gunthorpe. * Fix the of_pci_get_devfn() implementation according to Stephen Warren's comment. * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion include paths when building the pci-mvebu driver. This ensures that the include paths are only added when building this specific driver. Requested by Stephen Warren. * Fix the -resource_align() to only apply on bus 0 (the one on which the emulated PCI-to-PCI bridges sit), and to request an alignment on the size of the window (and not only 64 KB for I/O windows and 1 MB for memory windows). * Clarified the commit log of clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thanks, Thomas Andrew Murray (1): of/pci: Provide support for parsing PCI DT ranges property Thierry Reding (2): of/pci: Add of_pci_get_devfn() function of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni (6): arm: mvebu: fix the 'ranges' property to handle PCIe clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 clk: mvebu: add more PCIe clocks for Armada XP pci: PCIe driver for Marvell Armada 370/XP systems arm: mvebu: PCIe support is now available on mvebu arm: mvebu: update defconfig with PCI and USB support .../devicetree/bindings/pci/mvebu-pci.txt | 220 + arch/arm/boot/dts/armada-370-xp.dtsi |3 +- arch/arm/boot/dts/armada-370.dtsi |3 +- arch/arm/configs/mvebu_defconfig |3 + arch/arm/mach-mvebu/Kconfig|2 + drivers/clk/mvebu/clk-gating-ctrl.c| 18 +- drivers/of/address.c | 67 ++ drivers/of/of_pci.c| 59 +- drivers/pci/Kconfig|2 + drivers/pci/Makefile |3 + drivers/pci/host/Kconfig |8 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-mvebu.c | 880 include/linux/of_address.h | 48 ++ include/linux/of_pci.h |2 + 15 files changed, 1306 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile create mode 100644 drivers/pci/host/pci-mvebu.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 1/9] arm: mvebu: fix the 'ranges' property to handle PCIe
Since 82a682676 ('ARM: dts: mvebu: Convert all the mvebu files to use
the range property') all the device nodes of Armada 370/XP are under a
common 'ranges' property that translates the device register addresses
into their absolute address, thanks to the base address of the
internal register space.
However, beyond just the register areas, there are also PCIe I/O and
memory regions, whose addresses should be properly translated. This
patch fixes the Armada 370 and XP ranges property to take PCIe into
account properly.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Since the PCIe Device Tree description has been merged in 3.10-rc1,
this commit should go in 3.10-rc as well.
---
arch/arm/boot/dts/armada-370-xp.dtsi |3 ++-
arch/arm/boot/dts/armada-370.dtsi|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 272bbc6..550eb77 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -33,7 +33,8 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x10;
+ ranges = 0 0 0xd000 0x010 /* internal
registers */
+ 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index b2c1b5a..834c9be 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,7 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x10;
+ ranges = 0 0xd000 0x010 /* internal registers
*/
+ 0xe000 0xe000 0x810 /* PCIe */;
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser_init(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Tested-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/address.c | 67
include/linux/of_address.h | 48 +++
2 files changed, 115 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..fdd0636 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
#endif /* CONFIG_PCI */
/*
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..4c2e6f2 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
#include linux/errno.h
#include linux/of.h
+struct of_pci_range_parser {
+ struct device_node *node;
+ const __be32 *range;
+ const __be32 *end;
+ int np;
+ int pna;
+};
+
+struct of_pci_range {
+ u32 pci_space;
+ u64 pci_addr
[PATCHv10 3/9] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
#include asm/prom.h
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct
device_node *parent,
return NULL;
}
EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 8/9] arm: mvebu: PCIe support is now available on mvebu
Now that the PCIe driver for mvebu has been integrated and all its relevant dependencies, we can mark the ARCH_MVEBU platform has MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index e11acbb..381062d 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -15,6 +15,8 @@ config ARCH_MVEBU select MVEBU_CLK_GATING select MVEBU_MBUS select ZONE_DMA if ARM_LPAE + select MIGHT_HAVE_PCI + select PCI_QUIRKS if PCI if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/Kconfig|2 +
drivers/pci/Makefile |3 +
drivers/pci/host/Kconfig |8 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pci-mvebu.c | 880
6 files changed, 1114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/Kconfig
create mode 100644 drivers/pci/host/Makefile
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0 0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0
[PATCHv10 9/9] arm: mvebu: update defconfig with PCI and USB support
Now that we have the necessary drivers and Device Tree informations to support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI option. Also, since the Armada 370 Mirabox has a built-in USB XHCI controller connected on the PCIe bus, enable the corresponding options as well. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index f3e8ae0..966281e 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y CONFIG_MACH_ARMADA_XP=y # CONFIG_CACHE_L2X0 is not set # CONFIG_SWP_EMULATE is not set +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y CONFIG_SMP=y CONFIG_AEABI=y CONFIG_HIGHMEM=y @@ -60,6 +62,7 @@ CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_XHCI_HCD=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_NEW_LEDS=y -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 4/9] of/pci: Add of_pci_parse_bus_range() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) 8) 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+ const __be32 *values;
+ int len;
+
+ values = of_get_property(node, bus-range, len);
+ if (!values || len sizeof(*values) * 2)
+ return -EINVAL;
+
+ res-name = node-name;
+ res-start = be32_to_cpup(values++);
+ res-end = be32_to_cpup(values);
+ res-flags = IORESOURCE_BUS;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Jason Cooper, On Thu, 16 May 2013 11:56:17 -0400, Jason Cooper wrote: Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Dear boss, I am in desperate need of a 500GB SSD on which to do my kernel work. Thanks, Kranky Kernel Developer hehehe... Adding boss in the Cc list :-) Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 1/9] arm: mvebu: fix the 'ranges' property to handle PCIe
Since 82a682676 ('ARM: dts: mvebu: Convert all the mvebu files to use
the range property') all the device nodes of Armada 370/XP are under a
common 'ranges' property that translates the device register addresses
into their absolute address, thanks to the base address of the
internal register space.
However, beyond just the register areas, there are also PCIe I/O and
memory regions, whose addresses should be properly translated. This
patch fixes the Armada 370 and XP ranges property to take PCIe into
account properly.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Since the PCIe Device Tree description has been merged in 3.10-rc1,
this commit should go in 3.10-rc as well.
---
arch/arm/boot/dts/armada-370-xp.dtsi |3 ++-
arch/arm/boot/dts/armada-370.dtsi|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 272bbc6..550eb77 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -33,7 +33,8 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x10;
+ ranges = 0 0 0xd000 0x010 /* internal
registers */
+ 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index b2c1b5a..834c9be 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,7 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x10;
+ ranges = 0 0xd000 0x010 /* internal registers
*/
+ 0xe000 0xe000 0x810 /* PCIe */;
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 2/9] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser_init(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Tested-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/address.c | 67
include/linux/of_address.h | 48 +++
2 files changed, 115 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..fdd0636 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
#endif /* CONFIG_PCI */
/*
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..4c2e6f2 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
#include linux/errno.h
#include linux/of.h
+struct of_pci_range_parser {
+ struct device_node *node;
+ const __be32 *range;
+ const __be32 *end;
+ int np;
+ int pna;
+};
+
+struct of_pci_range {
+ u32 pci_space;
+ u64 pci_addr
[PATCHv9 0/9] PCIe support for the Armada 370 and Armada XP SoCs
address decoding window. Requested by Bjorn Helgaas. * Fixed the implementation of I/O accesses to use I/O addresses that fall within the normal IO_SPACE_LIMIT. This required using the remap functionality of address decoding windows, and therefore some changes in the address decoding window allocator. Follows a long discussion about I/O accesses. * Set up a correct bus number in the configuration of the PCIe interfaces so that we don't have to fake bus numbers anymore. Requested by Jason Gunthorpe. * Fix the of_pci_get_devfn() implementation according to Stephen Warren's comment. * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion include paths when building the pci-mvebu driver. This ensures that the include paths are only added when building this specific driver. Requested by Stephen Warren. * Fix the -resource_align() to only apply on bus 0 (the one on which the emulated PCI-to-PCI bridges sit), and to request an alignment on the size of the window (and not only 64 KB for I/O windows and 1 MB for memory windows). * Clarified the commit log of clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thanks, Thomas Andrew Murray (1): of/pci: Provide support for parsing PCI DT ranges property Thierry Reding (2): of/pci: Add of_pci_get_devfn() function of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni (6): arm: mvebu: fix the 'ranges' property to handle PCIe clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 clk: mvebu: add more PCIe clocks for Armada XP pci: PCIe driver for Marvell Armada 370/XP systems arm: mvebu: PCIe support is now available on mvebu arm: mvebu: update defconfig with PCI and USB support .../devicetree/bindings/pci/mvebu-pci.txt | 220 + arch/arm/boot/dts/armada-370-xp.dtsi |3 +- arch/arm/boot/dts/armada-370.dtsi |3 +- arch/arm/configs/mvebu_defconfig |3 + arch/arm/mach-mvebu/Kconfig|2 + drivers/clk/mvebu/clk-gating-ctrl.c| 18 +- drivers/of/address.c | 67 ++ drivers/of/of_pci.c| 59 +- drivers/pci/Kconfig|2 + drivers/pci/Makefile |3 + drivers/pci/host/Kconfig |8 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-mvebu.c | 879 include/linux/of_address.h | 48 ++ include/linux/of_pci.h |2 + 15 files changed, 1305 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile create mode 100644 drivers/pci/host/pci-mvebu.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 3/9] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
#include asm/prom.h
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct
device_node *parent,
return NULL;
}
EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 4/9] of/pci: Add of_pci_parse_bus_range() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) 8) 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+ const __be32 *values;
+ int len;
+
+ values = of_get_property(node, bus-range, len);
+ if (!values || len sizeof(*values) * 2)
+ return -EINVAL;
+
+ res-name = node-name;
+ res-start = be32_to_cpup(values++);
+ res-end = be32_to_cpup(values);
+ res-flags = IORESOURCE_BUS;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 6/9] clk: mvebu: add more PCIe clocks for Armada XP
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/Kconfig|2 +
drivers/pci/Makefile |3 +
drivers/pci/host/Kconfig |8 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pci-mvebu.c | 879
6 files changed, 1113 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/Kconfig
create mode 100644 drivers/pci/host/Makefile
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0 0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0
[PATCHv9 8/9] arm: mvebu: PCIe support is now available on mvebu
Now that the PCIe driver for mvebu has been integrated and all its relevant dependencies, we can mark the ARCH_MVEBU platform has MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index e11acbb..381062d 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -15,6 +15,8 @@ config ARCH_MVEBU select MVEBU_CLK_GATING select MVEBU_MBUS select ZONE_DMA if ARM_LPAE + select MIGHT_HAVE_PCI + select PCI_QUIRKS if PCI if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv9 9/9] arm: mvebu: update defconfig with PCI and USB support
Now that we have the necessary drivers and Device Tree informations to support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI option. Also, since the Armada 370 Mirabox has a built-in USB XHCI controller connected on the PCIe bus, enable the corresponding options as well. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index f3e8ae0..966281e 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y CONFIG_MACH_ARMADA_XP=y # CONFIG_CACHE_L2X0 is not set # CONFIG_SWP_EMULATE is not set +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y CONFIG_SMP=y CONFIG_AEABI=y CONFIG_HIGHMEM=y @@ -60,6 +62,7 @@ CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_XHCI_HCD=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_NEW_LEDS=y -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 5/7] ARM: kirkwood: remove legacy mv643xx_eth board setup
Dear Sebastian Hesselbarth, On Mon, 6 May 2013 17:33:38 +0200, Sebastian Hesselbarth wrote: 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. arch/arm/mach-kirkwood/board-dnskw.c |7 --- arch/arm/mach-kirkwood/board-dockstar.c |9 - arch/arm/mach-kirkwood/board-dreamplug.c | 14 -- arch/arm/mach-kirkwood/board-goflexnet.c |9 - arch/arm/mach-kirkwood/board-guruplug.c | 14 -- arch/arm/mach-kirkwood/board-ib62x0.c |9 - arch/arm/mach-kirkwood/board-iconnect.c |6 -- arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 16 arch/arm/mach-kirkwood/board-km_kirkwood.c|7 --- arch/arm/mach-kirkwood/board-lsxl.c | 12 arch/arm/mach-kirkwood/board-mplcec4.c| 11 --- arch/arm/mach-kirkwood/board-ns2.c| 13 - arch/arm/mach-kirkwood/board-openblocks_a6.c |9 - arch/arm/mach-kirkwood/board-readynas.c |6 -- arch/arm/mach-kirkwood/board-ts219.c | 13 - arch/arm/mach-kirkwood/board-usi_topkick.c|9 - I believe a good number of those files become empty once you've removed the registration of the Ethernet devices. Shouldn't such files be removed in this patch? Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
Dear Jason Cooper, On Tue, 16 Apr 2013 07:29:51 -0400, Jason Cooper wrote: Do not send this series upstream (or even in -next) until it has been at least build-tested and acked by the affected architectures. AFAIK it breaks microblaze build (simple missing #include) and isn't yet tested on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do it though). I added the missing include reference by Michal Simek for the branch at mvebu/drivers. Some other build issues were reported on x86 during the night (thanks to automated build tests), and Andrew Murray has just sent a new version v7 of the patch set addressing those issues, as well as the missing include. Also, please note that Andrew's patch set contains three patches, but the Marvell PCIe driver only requires PATCH 1/3 and PATCH 2/3. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
Dear Jason Cooper, On Sat, 13 Apr 2013 15:00:37 -0400, Jason Cooper wrote: So let's continue the cleanup work, conversion to DT, usage of drivers in drivers/, improvement of pinmux to support orion5x/mv78xx0, and do the move per-platform, once they are ready. What do you think? I agree completely. I was simply restating the longview goal of the work we are doing (above and beyond adding armadaXP/370). I probably should have given a time reference for This will lead to... :) Ok. I definitely agree with the long-term goal. Also, I have a feeling that not all legacy boards will get converted over. If there is no interest or no way to test, certains boards may get deprecated. I think for many of them, we can do a 'blind' conversion to DT, and ask the users who have posted patches or even submitted support for those boards to test the DT. But I don't think we should move things into mach-mvebu if there are still legacy non-DT Kirkwood platforms supported in mach-kirkwood. So either we convert them to the DT, or we remove the support for them if no-one is really interested. But I believe in most cases, converting them to DT should be quite easy. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Michal, Ben,
Would you have some time to look at this patch and give your comments
and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
need your agreement to merge this code, and quite a bit of code pending
for 3.10 depends on this patch.
Rob, alternatively, could we imagine doing a different version of the
'of/pci: Provide support for parsing PCI DT ranges property' that
introduces the new API only, leaving the PowerPC and Microblaze rework
as follow-up efforts, so that all the PCIe drivers that depend on this
patch can get in for 3.10 ? I'd find it pretty sad if the Marvell PCIe
driver that has been worked on since 4+ months does not get into 3.10
just because this patch cannot be merged.
Thanks!
Thomas
On Thu, 11 Apr 2013 16:26:07 +0100, Andrew Murray wrote:
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
drivers/of/of_pci.c | 200
++
include/linux/of_pci.h |4 +
6 files changed, 206 insertions(+), 392 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
+#include linux/of_pci.h
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller
*hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c
b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev,
int bar,
*end = rsrc-end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the ranges property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- * - We can only cope with one IO space range and up to 3 Memory space
- * ranges. However, some machines (thanks Apple !) tend to split their
- * space into lots of small contiguous ranges. So we have to coalesce.
- *
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small window which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
- * - Some busses have IO space not starting at 0, which causes trouble with
- * the way we do our IO resource renumbering. The code somewhat deals
with
- * it for 64 bits but I would expect problems on 32 bits.
- *
- * - Some 32 bits platforms such as 4xx can have physical space larger than
- * 32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna
Re: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
Dear Jason Cooper, On Mon, 15 Apr 2013 11:46:20 -0400, Jason Cooper wrote: * Patches 1-5 are awaiting a formal Acked-by from the Device Tree maintainers. Patches 1-3 are the new version of the OF PCI range parsing functions from Andrew Murray, which he worked on after the comments from Rob Herring. Patches 4 and 5 are much more trivial and have been around since many versions of this series. Applied to mvebu/drivers Patches 1-3 have a newer version that has been posted by Andrew Murray recently, see: Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing Date: Thu, 11 Apr 2013 16:26:06 +0100 Message-Id: 1365693969-23907-1-git-send-email-andrew.mur...@arm.com http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162558.html This ones are more recent than the v5 I originally used as a base for my PCIe v8. I can resend a v9 of my PCIe patch set based on the v6 of Andrew, or you can directly use PATCH 1,2,3 from Andrew series to replace PATCH 1,2,3 from my series. Andrew v6 has quite a number of changes compared to v5, so I really recommend using those ones. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
Dear Jason Cooper, On Mon, 15 Apr 2013 12:38:45 -0400, Jason Cooper wrote: This ones are more recent than the v5 I originally used as a base for my PCIe v8. I can resend a v9 of my PCIe patch set based on the v6 of Andrew, or you can directly use PATCH 1,2,3 from Andrew series to replace PATCH 1,2,3 from my series. Andrew v6 has quite a number of changes compared to v5, so I really recommend using those ones. No need to mess with v9, I'll pull AndrewM's v6. Excellent, thanks. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
Dear Jason Cooper, On Thu, 11 Apr 2013 12:53:03 -0400, Jason Cooper wrote: With this and Thomas' pci series, we will have Kirkwood fully converted to devicetree, can begin removing board files, and finally begin migrating everything over to mach-mvebu/. This will lead to the removal of five directories under arch/arm/ (plat-orion, mach-kirkwood, mach-orion5x, mach-dove, and mach-mv78xx0). No, we can't remove mach-orion5x and mach-mv78xx0 for now, they have not been converted at all in terms of gpio/pinmux support. I've started writing some pinmux code for orion5x but it's not ready. I don't think we should rush in doing this merge into mach-mvebu. I'd prefer to have the following conditions be met before a platform gets merged into mach-mvebu: * The mach-foo directory no longer depends on anything in plat-orion. For mach-kirkwood, things are OK (for the DT platforms) for GPIO, MPP and PCIe, but some work remains for the IRQ controller driver and the timer driver. * All boards have been converted to the Device Tree. For mach-kirkwood, we're getting closer. Once a given mach-foo platform meets these conditions, it will be a clean platform, and we can merge it into mach-mvebu without any problem. So let's continue the cleanup work, conversion to DT, usage of drivers in drivers/, improvement of pinmux to support orion5x/mv78xx0, and do the move per-platform, once they are ready. What do you think? Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Dear Andrew Murray, On Thu, 11 Apr 2013 13:12:42 +0100, Andrew Murray wrote: Thanks - I somehow missed this. I've included this change in my next respin - but I've put 'struct pci_controller' immediately before 'pci_process_bridge_OF_ranges' rather than above of_irq_map_pci to be consistent with the rest of the file. Right, sounds good. Do we have some news from the PowerPC and Microblaze maintainers about their acceptance of PATCH 1/3 ? This of/pci thing is the only last remaining patch for which I need a Ack to get the Marvell PCIe merged. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Ben, Michal, On Wed, 10 Apr 2013 08:13:54 -0500, Rob Herring wrote: Adding Ben H and Michal... On 04/10/2013 02:29 AM, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com One comment below. Otherwise, Reviewed-by: Rob Herring rob.herr...@calxeda.com You need also need acks from Ben and Michal. Ben, Michal, could you review/test this patch from Andrew Murray? I need it as a dependency of [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges property, which itself is used by the Marvell PCIe driver I'm hoping to get merged in 3.10. Thanks a lot for your feedback, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Dear Andrew Murray, On Wed, 10 Apr 2013 08:29:26 +0100, Andrew Murray wrote: diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index bb115de..6852481 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -11,4 +11,7 @@ struct device_node; struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn); +void pci_process_bridge_OF_ranges(struct pci_controller *hose, + struct device_node *dev, int primary); + #endif In this file, 'struct pci_controller' is not defined anywhere, and not in any header file that is included. So I get a warning at compile time when linux/of_pci.h is included, but nothing has defined 'struct pci_controller' beforehand. So I think this file should carry a change like: +struct pci_controller; In my version of the patch I added it, see: diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index bb115de..e56182f 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -4,6 +4,7 @@ #include linux/pci.h struct pci_dev; +struct pci_controller; struct of_irq; int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq); @@ -11,4 +12,7 @@ struct device_node; struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn); +void pci_process_bridge_OF_ranges(struct pci_controller *hose, + struct device_node *dev, int primary); + #endif But otherwise, for PATCH 1/3 and 2/3, Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Arnd Bergmann, On Tue, 9 Apr 2013 00:14:06 +0200, Arnd Bergmann wrote: pcie-realio.type = IORESOURCE_IO; pcie-realio.start = max(PCIBIOS_MIN_IO, range-pci_addr); pcie-realio.end = max(IO_SPACE_LIMIT, range-pci_addr + range-size); Shouldn't this last line be using min() so that we guarantee we don't have an I/O region that goes beyond IO_SPACE_LIMIT? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
to Stephen Warren's comment. * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion include paths when building the pci-mvebu driver. This ensures that the include paths are only added when building this specific driver. Requested by Stephen Warren. * Fix the -resource_align() to only apply on bus 0 (the one on which the emulated PCI-to-PCI bridges sit), and to request an alignment on the size of the window (and not only 64 KB for I/O windows and 1 MB for memory windows). * Clarified the commit log of clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thanks, Thomas Andrew Murray (3): of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC of/pci: Provide support for parsing PCI DT ranges property of/pci: mips: convert to common of_pci_range_parser Thierry Reding (2): of/pci: Add of_pci_get_devfn() function of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni (14): pci: infrastructure to add drivers in drivers/pci/host arm: pci: add a align_resource hook clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 clk: mvebu: add more PCIe clocks for Armada XP pci: PCIe driver for Marvell Armada 370/XP systems arm: mvebu: PCIe support is now available on mvebu arm: mvebu: add PCIe Device Tree informations for Armada 370 arm: mvebu: add PCIe Device Tree informations for Armada XP arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 arm: mvebu: PCIe Device Tree informations for Armada XP DB arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox arm: mvebu: PCIe Device Tree informations for Armada 370 DB arm: mvebu: PCIe Device Tree informations for Armada XP GP arm: mvebu: update defconfig with PCI and USB support .../devicetree/bindings/pci/mvebu-pci.txt | 220 + arch/arm/boot/dts/armada-370-db.dts| 17 + arch/arm/boot/dts/armada-370-mirabox.dts | 16 + arch/arm/boot/dts/armada-370.dtsi | 51 ++ arch/arm/boot/dts/armada-xp-db.dts | 33 + arch/arm/boot/dts/armada-xp-gp.dts | 21 + arch/arm/boot/dts/armada-xp-mv78230.dtsi | 104 +++ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 122 +++ arch/arm/boot/dts/armada-xp-mv78460.dtsi | 188 + arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 + arch/arm/configs/mvebu_defconfig |3 + arch/arm/include/asm/mach/pci.h| 11 + arch/arm/kernel/bios32.c |6 + arch/arm/mach-mvebu/Kconfig|2 + arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 - arch/mips/pci/pci.c| 50 +- arch/powerpc/include/asm/pci-bridge.h |5 +- arch/powerpc/kernel/pci-common.c | 192 - drivers/clk/mvebu/clk-gating-ctrl.c| 18 +- drivers/of/address.c | 63 ++ drivers/of/of_pci.c| 227 - drivers/pci/Kconfig|2 + drivers/pci/Makefile |3 + drivers/pci/host/Kconfig |8 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-mvebu.c | 879 include/linux/of_address.h | 42 + include/linux/of_pci.h |6 + 29 files changed, 2059 insertions(+), 437 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile create mode 100644 drivers/pci/host/pci-mvebu.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 01/19] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Andrew Murray andrew.mur...@arm.com
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
drivers/of/of_pci.c | 200 ++
include/linux/of_pci.h |4 +
6 files changed, 206 insertions(+), 392 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
+#include linux/of_pci.h
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int
bar,
*end = rsrc-end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the ranges property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- * - We can only cope with one IO space range and up to 3 Memory space
- * ranges. However, some machines (thanks Apple !) tend to split their
- * space into lots of small contiguous ranges. So we have to coalesce.
- *
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small window which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
- * - Some busses have IO space not starting at 0, which causes trouble with
- * the way we do our IO resource renumbering. The code somewhat deals with
- * it for 64 bits but I would expect problems on 32 bits.
- *
- * - Some 32 bits platforms such as 4xx can have physical space larger than
- * 32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
- int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
- unsigned long long isa_mb = 0;
- struct resource *res;
-
- pr_info(PCI host bridge %s %s ranges:\n,
- dev-full_name, primary ? (primary) : );
-
- /* Get ranges property */
- ranges = of_get_property(dev, ranges, rlen);
- if (ranges == NULL)
- return;
-
- /* Parse it */
- pr_debug(Parsing ranges property...\n);
- while ((rlen -= np * 4) = 0) {
- /* Read next ranges element */
- pci_space = ranges[0];
- pci_addr = of_read_number(ranges + 1, 2);
- cpu_addr = of_translate_address(dev, ranges + 3
[PATCHv8 02/19] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce
overall kernel code and provide a means for host bridge drivers to
directly obtain struct resources from the DT's ranges property without
relying on architecture specific DT handling. This will make it easier
to write archiecture independent host bridge drivers and mitigate
against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and
merges them into a single range (as was the case with powerpc and
microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
drivers/of/address.c | 63 +
drivers/of/of_pci.c| 112
include/linux/of_address.h | 42 +
3 files changed, 145 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = be32_to_cpup(parser-range);
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 9dd8a10..ebb408b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long isa_mb = 0;
struct resource *res
[PATCHv8 03/19] of/pci: mips: convert to common of_pci_range_parser
From: Andrew Murray andrew.mur...@arm.com
This patch converts the pci_load_of_ranges function to use the new
common of_pci_range_parser.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
arch/mips/pci/pci.c | 50 --
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
#ifdef CONFIG_OF
void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
{
- const __be32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(node);
- int np = pna + 5;
+ struct of_pci_range_range range;
+ struct of_pci_range_parser parser;
+ u32 res_type;
pr_info(PCI host bridge %s ranges:\n, node-full_name);
- ranges = of_get_property(node, ranges, rlen);
- if (ranges == NULL)
- return;
hose-of_node = node;
- while ((rlen -= np * 4) = 0) {
- u32 pci_space;
+ if (of_pci_range_parser(parser, node))
+ return;
+
+ for_each_of_pci_range(parser, range) {
struct resource *res = NULL;
- u64 addr, size;
-
- pci_space = be32_to_cpup(ranges[0]);
- addr = of_translate_address(node, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
- ranges += np;
- switch ((pci_space 24) 0x3) {
- case 1: /* PCI IO space */
+
+ res_type = range.flags IORESOURCE_TYPE_BITS;
+ if (res_type == IORESOURCE_IO) {
pr_info( IO 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
hose-io_map_base =
- (unsigned long)ioremap(addr, size);
+ (unsigned long)ioremap(range.addr, range.size);
res = hose-io_resource;
- res-flags = IORESOURCE_IO;
- break;
- case 2: /* PCI Memory space */
- case 3: /* PCI 64 bits Memory space */
+ } else if (res_type == IORESOURCE_MEM) {
pr_info( MEM 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
res = hose-mem_resource;
- res-flags = IORESOURCE_MEM;
- break;
- }
- if (res != NULL) {
- res-start = addr;
- res-name = node-full_name;
- res-end = res-start + size - 1;
- res-parent = NULL;
- res-sibling = NULL;
- res-child = NULL;
}
+ if (res != NULL)
+ of_pci_range_to_resource(range, node, res);
}
}
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 04/19] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index ebb408b..b77e8d8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -9,14 +9,15 @@
#endif
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -208,3 +209,26 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
}
}
#endif
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e56182f..302aca0 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,6 +11,7 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 06/19] pci: infrastructure to add drivers in drivers/pci/host
As agreed by the community, PCI host drivers will now be stored in drivers/pci/host. This commit adds this directory and the related Kconfig/Makefile changes to allow new drivers to be added in this directory. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Acked-by: Bjorn Helgaas bhelg...@google.com --- drivers/pci/Kconfig |2 ++ drivers/pci/Makefile |3 +++ drivers/pci/host/Kconfig |4 drivers/pci/host/Makefile |1 + 4 files changed, 10 insertions(+) create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 6d51aa6..ac45398 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -119,3 +119,5 @@ config PCI_IOAPIC config PCI_LABEL def_bool y if (DMI || ACPI) select NLS + +source drivers/pci/host/Kconfig diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 0c3efcf..6ebf5bf 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -67,3 +67,6 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o obj-$(CONFIG_OF) += of.o ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG + +# PCI host controller drivers +obj-y += host/ diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig new file mode 100644 index 000..cc3a1af --- /dev/null +++ b/drivers/pci/host/Kconfig @@ -0,0 +1,4 @@ +menu PCI host controller drivers + depends on PCI + +endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile new file mode 100644 index 000..636bc1a --- /dev/null +++ b/drivers/pci/host/Makefile @@ -0,0 +1 @@ +# intentionally empty -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 07/19] arm: pci: add a align_resource hook
The PCI specifications says that an I/O region must be aligned on a 4
KB boundary, and a memory region aligned on a 1 MB boundary.
However, the Marvell PCIe interfaces rely on address decoding windows
(which allow to associate a range of physical addresses with a given
device). For PCIe memory windows, those windows are defined with a 1
MB granularity (which matches the PCI specs), but PCIe I/O windows can
only be defined with a 64 KB granularity, so they have to be 64 KB
aligned. We therefore need to tell the PCI core about this special
alignement requirement.
The PCI core already calls pcibios_align_resource() in the ARM PCI
core, specifically for such purposes. So this patch extends the ARM
PCI core so that it calls a -align_resource() hook registered by the
PCI driver, exactly like the existing -map_irq() and -swizzle()
hooks.
A particular PCI driver can register a align_resource() hook, and do
its own specific alignement, depending on the specific constraints of
the underlying hardware.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/include/asm/mach/pci.h | 11 +++
arch/arm/kernel/bios32.c|6 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..7d2c3c8 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -30,6 +30,11 @@ struct hw_pci {
void(*postinit)(void);
u8 (*swizzle)(struct pci_dev *dev, u8 *pin);
int (*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
};
/*
@@ -51,6 +56,12 @@ struct pci_sys_data {
u8 (*swizzle)(struct pci_dev *, u8 *);
/* IRQ mapping
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
+ /* Resource alignement requirements
*/
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..b2ed73c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct
list_head *head)
sys-busnr = busnr;
sys-swizzle = hw-swizzle;
sys-map_irq = hw-map_irq;
+ sys-align_resource = hw-align_resource;
INIT_LIST_HEAD(sys-resources);
if (hw-private_data)
@@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
{
+ struct pci_dev *dev = data;
+ struct pci_sys_data *sys = dev-sysdata;
resource_size_t start = res-start;
if (res-flags IORESOURCE_IO start 0x300)
@@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
start = (start + align - 1) ~(align - 1);
+ if (sys-align_resource)
+ return sys-align_resource(dev, res, start, size, align);
+
return start;
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 08/19] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 09/19] clk: mvebu: add more PCIe clocks for Armada XP
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the new armada_370_xp_alloc_pcie_window()
function from mach-mvebu/addr-map.c.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/host/Kconfig |4 +
drivers/pci/host/Makefile |2 +-
drivers/pci/host/pci-mvebu.c | 879
4 files changed, 1104 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0 0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5
[PATCHv8 11/19] arm: mvebu: PCIe support is now available on mvebu
Now that the PCIe driver for mvebu has been integrated and all its relevant dependencies, we can mark the ARCH_MVEBU platform has MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index c3715a5..d353249 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -14,6 +14,8 @@ config ARCH_MVEBU select MVEBU_CLK_CPU select MVEBU_CLK_GATING select MVEBU_MBUS + select MIGHT_HAVE_PCI + select PCI_QUIRKS if PCI if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 12/19] arm: mvebu: add PCIe Device Tree informations for Armada 370
The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
necessary Device Tree informations to make these interfaces availabel.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370.dtsi | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..2d9f8d6 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -153,5 +153,56 @@
clocks = coreclk 0;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ reg = 0xd004 0x2000, 0xd008 0x2000;
+
+ reg-names = pcie0.0, pcie1.0;
+
+ ranges = 0x8200 0 0xd004 0xd004 0
0x2000 /* Port 0.0 registers */
+ 0x8200 0 0xd008 0xd008 0
0x2000 /* Port 1.0 registers */
+ 0x8200 0 0xe000 0xe000 0
0x0800 /* non-prefetchable memory */
+ 0x8100 0 0 0xe800 0
0x0010; /* downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0
0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+ status = disabled;
+ };
+
+ pcie@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82002800 0 0xd008 0
0x2000;
+ reg = 0x1000 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 62;
+ marvell,pcie-port = 1;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 9;
+ status = disabled;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 13/19] arm: mvebu: add PCIe Device Tree informations for Armada XP
The Armada XP SoCs have multiple PCIe interfaces. The MV78230 has 2
PCIe units (one 4x or quad 1x, the other 1x only), the MV78260 has 3
PCIe units (two 4x or quad 1x and one 4x/1x), the MV78460 has 4 PCIe
units (two 4x or quad 1x and two 4x/1x). We therefore add the
necessary Device Tree informations to make those PCIe interfaces
usable.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 104 +
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 122 +++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 188 ++
3 files changed, 414 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..c2c7845 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -76,5 +76,109 @@
#interrupts-cells = 2;
interrupts = 87, 88, 89;
};
+
+ /*
+* MV78230 has 2 PCIe units Gen2.0: One unit can be
+* configured as x4 or quad x1 lanes. One unit is
+* x4/x1.
+*/
+ pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0
0x2000 /* Port 0.0 registers */
+ 0x8200 0 0xd0042000 0xd0042000 0
0x2000 /* Port 2.0 registers */
+ 0x8200 0 0xd0044000 0xd0044000 0
0x2000 /* Port 0.1 registers */
+ 0x8200 0 0xd0048000 0xd0048000 0
0x2000 /* Port 0.2 registers */
+ 0x8200 0 0xd004c000 0xd004c000 0
0x2000 /* Port 0.3 registers */
+ 0x8200 0 0xe000 0xe000 0
0x0800 /* non-prefetchable memory */
+ 0x8100 0 0 0xe800 0
0x0010; /* downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0
0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+ status = disabled;
+ };
+
+ pcie@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd0044000 0
0x2000;
+ reg = 0x1000 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 59;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 1;
+ clocks = gateclk 6;
+ status = disabled;
+ };
+
+ pcie@3,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd0048000 0
0x2000;
+ reg = 0x1800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 60;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 2;
+ clocks = gateclk 7;
+ status = disabled;
+ };
+
+ pcie@4,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004c000 0
0x2000;
+ reg = 0x2000 0 0 0 0;
+ #address-cells = 3
[PATCHv8 14/19] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4
The PlatHome OpenBlocks AX3-4 has an internal mini-PCIe slot that can
be used to plug mini-PCIe devices. We therefore enable the PCIe
interface that corresponds to this slot.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..5a748bd 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,14 @@
usb@d0051000 {
status = okay;
};
+
+ pcie-controller {
+ status = okay;
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 15/19] arm: mvebu: PCIe Device Tree informations for Armada XP DB
The Marvell evaluation board (DB) for the Armada XP SoC has 6
physicals full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-db.dts | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index e83505e..54cc5bb 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -121,5 +121,38 @@
spi-max-frequency = 2000;
};
};
+
+ pcie-controller {
+ status = okay;
+
+ /*
+* All 6 slots are physically present as
+* standard PCIe slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@2,0 {
+ /* Port 0, Lane 1 */
+ status = okay;
+ };
+ pcie@3,0 {
+ /* Port 0, Lane 2 */
+ status = okay;
+ };
+ pcie@4,0 {
+ /* Port 0, Lane 3 */
+ status = okay;
+ };
+ pcie@9,0 {
+ /* Port 2, Lane 0 */
+ status = okay;
+ };
+ pcie@10,0 {
+ /* Port 3, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 16/19] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox
The Globalscale Mirabox platform uses one PCIe interface for an
available mini-PCIe slot, and the other PCIe interface for an internal
USB 3.0 controller. We add the necessary Device Tree informations to
enable those two interfaces.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..5549de6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -70,5 +70,21 @@
usb@d0051000 {
status = okay;
};
+
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 17/19] arm: mvebu: PCIe Device Tree informations for Armada 370 DB
The Marvell evaluation board (DB) for the Armada 370 SoC has 2
physical full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..6403acd 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -94,5 +94,22 @@
spi-max-frequency = 5000;
};
};
+
+ pcie-controller {
+ status = okay;
+ /*
+* The two PCIe units are accessible through
+* both standard PCIe slots and mini-PCIe
+* slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 18/19] arm: mvebu: PCIe Device Tree informations for Armada XP GP
The Marvell Armada XP GP board has 3 physical full-size PCIe slots, so
we enable the corresponding PCIe interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-gp.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e2bf6b4 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,26 @@
spi-max-frequency = 10800;
};
};
+
+ pcie-controller {
+ status = okay;
+
+ /*
+* The 3 slots are physically present as
+* standard PCIe slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@9,0 {
+ /* Port 2, Lane 0 */
+ status = okay;
+ };
+ pcie@10,0 {
+ /* Port 3, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 19/19] arm: mvebu: update defconfig with PCI and USB support
Now that we have the necessary drivers and Device Tree informations to support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI option. Also, since the Armada 370 Mirabox has a built-in USB XHCI controller connected on the PCIe bus, enable the corresponding options as well. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index 2ec8119..071a5b1 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y CONFIG_MACH_ARMADA_XP=y # CONFIG_CACHE_L2X0 is not set # CONFIG_SWP_EMULATE is not set +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y CONFIG_SMP=y CONFIG_AEABI=y CONFIG_HIGHMEM=y @@ -53,6 +55,7 @@ CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_XHCI_HCD=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_NEW_LEDS=y -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Bjorn Helgaas, On Tue, 9 Apr 2013 15:12:58 -0600, Bjorn Helgaas wrote: On Tue, Apr 9, 2013 at 3:06 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: This driver implements the support for the PCIe interfaces on the Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to cover earlier families of Marvell SoCs, such as Dove, Orion and Kirkwood. The driver implements the hw_pci operations needed by the core ARM PCI code to setup PCI devices and get their corresponding IRQs, and the pci_ops operations that are used by the PCI core to read/write the configuration space of PCI devices. Since the PCIe interfaces of Marvell SoCs are completely separate and not linked together in a bus, this driver sets up an emulated PCI host bridge, with one PCI-to-PCI bridge as child for each hardware PCIe interface. In addition, this driver enumerates the different PCIe slots, and for those having a device plugged in, it sets up the necessary address decoding windows, using the new armada_370_xp_alloc_pcie_window() function from mach-mvebu/addr-map.c. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Acked-by: Bjorn Helgaas bhelg...@google.com This and 06/19 look good to me. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Bjorn Helgaas,
On Mon, 8 Apr 2013 14:29:59 -0600, Bjorn Helgaas wrote:
Signed-off-by: Thomas Petazzoni
thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
A few trivial comments below; it's up to you whether you do anything
with them or not. It's OK with me if you ignore them :)
The only thing I saw that might be a bug is the resource_size()
question in mvebu_pcie_probe().
Thanks for the review!
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
new file mode 100644
index 000..3ad563f
--- /dev/null
+++ b/drivers/pci/host/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
+CFLAGS_pci-mvebu.o += \
+ -I$(srctree)/arch/arm/plat-orion/include \
+ -I$(srctree)/arch/arm/mach-mvebu/include
Too bad to have to adjust CFLAGS here. Seems like I remember earlier
discussion, but I didn't pay much attention, and if this is the best
we can do, I guess it's OK.
Ah, indeed! This is now longer needed. The plat-orion include was
needed to get access to some PCIe functions, which are now part of the
driver, and the mach-mvebu header was needed to access some address
decoding window related functions, that are now part of the mvebu-mbus
driver.
+#define PCIE_BAR_CTRL_OFF(n) (0x1804 + ((n - 1) * 4))
Strictly speaking, I suppose you should have (((n) - 1) ... here.
Correct, thanks.
+#define PCIE_STAT_OFF 0x1a04
+#define PCIE_STAT_DEV_OFFS20
+#define PCIE_STAT_DEV_MASK0x1f
+#define PCIE_STAT_BUS_OFFS8
+#define PCIE_STAT_BUS_MASK0xff
+#define PCIE_STAT_LINK_DOWN 1
Whoever wrote pci_regs.h came up with a style I kind of like: the bit
masks are already shifted so you can see where they are in the value,
and there are no #defines for the shifts, e.g.,
#define PCI_EXP_FLAGS_TYPE 0x00f0 /* Device/Port type */
The users of PCI_EXP_FLAGS_TYPE just have a bare 4 where
necessary. It seems like a good compromise that uses only one symbol
(good for grepping), gives good visual indication in the header file
of how the value is laid out, allows clearing bits without shifts, and
clearly shows what's happening at the uses.
But what you have is OK, too :)
Hum, ok, I'll try to think of it. Maybe too much of a 'big' change at
this point, but I'll see.
+static int mvebu_pcie_link_up(void __iomem *base)
This could return bool, I guess.
Indeed.
I think I would make
mvebu_pcie_link_up()
mvebu_pcie_set_local_bus_nr()
mvebu_pcie_setup_wins()
mvebu_pcie_setup_hw()
mvebu_pcie_hw_rd_conf()
mvebu_pcie_hw_wr_conf()
all take a struct mvebu_pcie_port *port directly rather than having
the caller pass in port-base, but maybe you have a reason for doing
otherwise.
I'll review this, I think your suggestion makes sense.
+ /*
+* First, disable and clear BARs and windows.
+*/
Typically single-line comments would be /* ... */ all on one line.
Correct.
+ for (i = 1; i = 2; i++) {
Interesting use of i = 2 rather than the typical i 3.
I must confess this code comes from plat-orion/pcie.c, and I just
copy/pasted it (note: we intentionally don't use plat-orion/pcie.c to
avoid having to have to include a header in plat-orion/include, and
this plat-orion/pcie.c should ultimately go away once all Marvell EBU
platforms are migrated to use the new PCIe driver).
+ /*
+* Enable interrupt lines A-D.
+*/
+ mask = readl(base + PCIE_MASK_OFF);
+ mask |= 0x0f00;
No #defines for these bits?
Good point.
+ writel(mask, base + PCIE_MASK_OFF);
+}
+
+static int mvebu_pcie_hw_rd_conf(void __iomem *base, struct
pci_bus *bus,
+u32 devfn, int where, int size,
u32 *val) +{
+ writel(PCIE_CONF_BUS(bus-number) |
+ PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+ PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+ PCIE_CONF_REG(where) | PCIE_CONF_ADDR_EN,
A PCIE_CONF_ADDR(busnr, devfn, where) macro would be nice here.
Right.
+static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port
*port) +{
+ phys_addr_t iobase;
+
+ /* Are the current iobase/iolimit values invalid? */
I first thought current ... values meant the values before the
change. If you used new values it might be clearer that this is
used to handle *writes* to the window base/size registers, and that
we're looking at the values being written.
Ok, makes sense indeed.
+ return mvebu_sw_pci_bridge_write(port, where, size,
val);
+ }
+
+ return PCIBIOS_SUCCESSFUL;
This last return is unreachable (I see you omitted it from the
rd_conf() path already :)). This would be slightly simpler as:
static struct mvebu_pcie_port *mvebu_find_port(struct mvebu_pcie
*pcie, struct pci_bus *bus, int devfn
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Arnd Bergmann, On Mon, 8 Apr 2013 23:31:30 +0200, Arnd Bergmann wrote: Too bad to have to adjust CFLAGS here. Seems like I remember earlier discussion, but I didn't pay much attention, and if this is the best we can do, I guess it's OK. I'm pretty sure I NAK'ed this part. I'm surprised it's still there. As I said in my reply to Bjorn, it's a mistake. I did so much efforts to get rid of the mach-mvebu and plat-orion dependencies, that in the end, I forgot that the original reason was to get rid of those special cflags. For sure, I'll send a v8 that has those cflags removed, they are unneeded. Sorry for this. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Arnd Bergmann, On Mon, 8 Apr 2013 23:34:12 +0200, Arnd Bergmann wrote: No, I'm assuming PCIBIOS_MIN_IO is always 0. So presumarly, this should be something like: pcie-realio.end = min(PCIBIOS_MIN_IO + resource_size(pcie-io), IO_SPACE_LIMIT); Normally PCIBIOS_MIN_IO is 0x1000, since the first 4096 ports are reserved for ISA and PCMCIA compatible drivers and should not be assigned to PCI devices. So the first port should get ports 0x1000 to 0x, later ones can used the entire 65536 ports e.g. 0x1 to 0x1. Then I guess it should work with the code I'm proposing here, no? Note: this pcie-realio region is global: it will be shared by all PCIe interfaces. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 06/17] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
Mike,
Could we have your opinion on this patch, and possibly a Acked-by to
pass it through arm-soc?
Thanks!
Thomas
On Wed, 27 Mar 2013 15:40:23 +0100, Thomas Petazzoni wrote:
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 07/17] clk: mvebu: add more PCIe clocks for Armada XP
Mike,
Could we have your opinion on the below patch, and possibly an Acked-by
to carry it through the arm-soc tree?
Thanks,
Thomas
On Wed, 27 Mar 2013 15:40:24 +0100, Thomas Petazzoni wrote:
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFCv1 00/11] MSI support for Marvell EBU PCIe driver
Dear Ezequiel Garcia, On Thu, 4 Apr 2013 06:16:40 -0300, Ezequiel Garcia wrote: Given the IRQ controller move to drivers/irqchip is independent of MSI work, and that we've already agreed this move is fine (Arnd has acked patch 2), may I suggest that you resend these three first patches (and perhaps the fourth?) as a separate patchset to be included in v3.10. This has the advantage that further development on IRQ controller can be done directly on its proper place, and also the MSI patchset can be simplified. What do you think? Sounds like a good idea. I'll cook a patch set later today and I'll send it. Thanks for the suggestion! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCHv1 2/5] bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
Jason (Cooper),
Do you mind taking this patch in your mvebu/drivers branch, next to the
patch adding the mvebu-mbus driver? Or do you want a new mvebu-mbus
driver patch that contains this fix and would replace the one you have
already merged in mvebu/drivers?
Thanks!
Thomas
On Wed, 27 Mar 2013 19:05:01 +0100, Thomas Petazzoni wrote:
The target and attributes for the PCIe address decoding windows were
not correct on Kirkwood for the second PCIe interface.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Note: this patch should be merged with the existing mvebu-mbus driver.
---
drivers/bus/mvebu-mbus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 586d03e..4de2c6b 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -626,7 +626,7 @@ static const struct mvebu_mbus_soc_data
armada_xp_mbus_data = {
static const struct mvebu_mbus_mapping kirkwood_map[] = {
MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
+ MAPDEF(pcie1.0, 4, 0xd0, MAPDEF_PCIMASK),
MAPDEF(sram,3, 0x01, MAPDEF_NOMASK),
MAPDEF(nand,1, 0x2f, MAPDEF_NOMASK),
{},
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCHv1 2/5] bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
Dear Jason Cooper, On Wed, 3 Apr 2013 06:57:57 -0400, Jason Cooper wrote: Thanks for pointing this out. I'll put it in mvebu/drivers as you suggested. I'll need to rebase mvebu/soc on it. But I haven't done the PR yet, so not a big deal. Ok, thanks. I'll finalize the cleanup of the kirkwood PCIe branch in order to be able to submit a version that hopefully should be acceptable. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 00/17] PCIe support for the Armada 370 and Armada XP SoCs
Bjorn, Rob, Grant, Russell, Through this e-mail, I'd like to send you a kind reminder about this patch series. The latest version has been sent a week ago, and there has been only minor changes requested since v4 sent early March, i.e a month ago. Therefore, I would hope for this series to enter 3.10. But this patch set is touching areas you are the maintainer for, so I would appreciate if you could do a formal review and give your comments or your Ack. I would especially appreciate if you do so in the very near future, so that if there are comments, I'll have the time to fix them and resubmit and updated version in time. Here are the patches, classified by maintainer area: * For Grant Likely and Rob Herring, the drivers/of patches: [PATCHv7 01/17] of/pci: Provide support for parsing PCI DT ranges property http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158556.html this patch has been around since 3 months now, and has seen a number of iterations, first from Thierry Reding, and then by Andrew Murray. It is also used by Thierry Reding's PCIe driver, and possibly by the upcoming Exynos PCIe driver as well. [PATCHv7 02/17] of/pci: Add of_pci_get_devfn() function http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158550.html this patch has been around since 3 months, with no major change since then. [PATCHv7 03/17] of/pci: Add of_pci_parse_bus_range() function http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158551.html same thing. * For Bjorn Helgaas, the drivers/pci/ patches: [PATCHv7 04/17] pci: infrastructure to add drivers in drivers/pci/host http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158552.html [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158566.html * For Russell King, the arch/arm/kernel/ patch: [PATCHv7 05/17] arm: pci: add a align_resource hook http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158553.html this patch has been around for more than two months now, and has been submitted last week to the patch tracking system, at http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7683/1. For more details, see the cover letter below, or of course, do not hesitate to request for additional ones as needed. Thanks a lot for your support, Thomas On Wed, 27 Mar 2013 15:40:17 +0100, Thomas Petazzoni wrote: Hello, This series of patches introduces PCIe support for the Marvell Armada 370 and Armada XP. In the future, we plan to extend the driver to cover Kirkwood platforms, and possibly other Marvell EBU platforms as well. As we are approaching 3.10, I would now like to get formal Acked-by, or disagreements from the following maintainers/developers : * Grant Likely, as the OF maintainer, for patches 1, 2 and 3 [PATCH v5 01/17] of/pci: Provide support for parsing PCI DT ranges [PATCH v5 02/17] of/pci: Add of_pci_get_devfn() function [PATCH v5 03/17] of/pci: Add of_pci_parse_bus_range() function * Bjorn Helgaas, as the PCI maintainer, for patches 4 and 8 [PATCH v5 04/17] pci: infrastructure to add drivers in drivers/pci/host [PATCH v5 08/17] pci: PCIe driver for Marvell Armada 370/XP systems * Russell King, as the ARM maintainer, for patch 5 [PATCH v5 05/17] arm: pci: add a align_resource hook * Arnd Bergmann, Mitch Bradley and Jason Gunthorpe, for patch 8 (the PCIe driver itself), and specifically the Device Tree binding. [PATCH v5 08/17] pci: PCIe driver for Marvell Armada 370/XP systems This patch set depends on: * The arm-soc/mvebu/cleanup branch in Arnd and Olof arm-soc tree * [PATCH v3 for 3.10] Introduce a Marvell EBU MBus driver http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/156883.html For easier testing, the code has been pushed to: git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v7 This PATCHv7 follows: * PATCHv6, sent on March, 26st 2013 * PATCHv5, sent on March, 21st 2013 * PATCHv4, sent on March, 8th 2013 * PATCHv3, sent on February, 12th 2013 * PATCHv2, sent on January, 28th 2013 * RFCv1, sent on December, 7th 2012 Changes between v6 and v7: * Use assigned-addresses in the DT subnodes for the MMIO PCIe registers, in order to align with what Thierry is doing on the Tegra PCIe driver. * Added empty 'ranges;' properties in the subnodes, as requested by Arnd. Note that due to this, it is not possible to remove the #address-cells and #size-cells properties from the subnodes, as Jason Gunthorpe requested, otherwise the DT compiler complains with: Warning (ranges_format): /soc/pcie-controller/pcie@1,0 has empty ranges property but its #address-cells (2) differs from /soc/pcie-controller (3) Warning (ranges_format
Re: [PATCHv7 04/17] pci: infrastructure to add drivers in drivers/pci/host
Dear Neil Greatorex, On Thu, 28 Mar 2013 00:28:02 +, Neil Greatorex wrote: Surely this patch should include the drivers/pci/host/Makefile or it will not build? Ah, correct. I'll fix that up in the v8. Thank you for noticing! Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2] of/pci: Provide support for parsing PCI DT ranges property
Dear Linus Walleij, On Wed, 27 Mar 2013 13:50:09 +0100, Linus Walleij wrote: Would it be possible to get this patch merged for 3.10, or get some review comments that would allow us to rework it in time for 3.10 ? Thomas can you supply a Reviewed-by/Tested-by tag? That certainly helps... Yes, I'm planning on testing RFC v3 from Andrew right now, and send a new version of the Marvell PCIe patch set that includes it. If all goes well, should happen this afternoon. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 00/17] PCIe support for the Armada 370 and Armada XP SoCs
the few common PCIe functions we were using from arch/arm/plat-orion/pcie.c. This allows to remove the inclusion of plat/pcie.h. Requested by Arnd Bergmann. * Directly set up the address decoding windows when the memory base/limit and I/O base/limit are configured in the PCI-to-PCI bridge instead of relying on the memory and I/O accesses being enabled in the PCI_COMMAND register. Suggested by Bjorn Helgaas. * Added some comments on top of the calculations of the I/O base/limit and memory base/limit. Suggested by Arnd Bergmann. * Changed a bit the way the realio resource is created, from suggestions given by Arnd Bergmann. * Updated the Device Tree binding documentation. Reported by Jason Gunthorpe. * Instead of using marvell,armada-370-xp-pcie as the DT compatible string, use two separate compatible strings: marvell,armada-370-pcie and marvell,armada-xp-pcie. For now, the driver does the same thing for both. Changes between v2 and v3: * Use of_irq_map_pci() instead of of_irq_map_raw(), as suggested by Andrew Murray. In order to do this, we moved the interrupt-map and interrupt-map-mask DT properties from the main PCIe controller node to the DT subnodes representing each PCIe interface. * Remove the usage of the emulated host bridge. * Move the emulated PCI-to-PCI bridge code into the Marvell PCI driver itself, in order to allow a tighter integration. Suggested by Bjorn Helgaas and Jason Gunthorpe. * Make the allocation of address decoding windows dynamic: it's when memory accesses or I/O accesses are enabled at the PCI-to-PCI bridge level that we allocate and setup the corresponding address decoding window. Requested by Bjorn Helgaas. * Fixed the implementation of I/O accesses to use I/O addresses that fall within the normal IO_SPACE_LIMIT. This required using the remap functionality of address decoding windows, and therefore some changes in the address decoding window allocator. Follows a long discussion about I/O accesses. * Set up a correct bus number in the configuration of the PCIe interfaces so that we don't have to fake bus numbers anymore. Requested by Jason Gunthorpe. * Fix the of_pci_get_devfn() implementation according to Stephen Warren's comment. * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion include paths when building the pci-mvebu driver. This ensures that the include paths are only added when building this specific driver. Requested by Stephen Warren. * Fix the -resource_align() to only apply on bus 0 (the one on which the emulated PCI-to-PCI bridges sit), and to request an alignment on the size of the window (and not only 64 KB for I/O windows and 1 MB for memory windows). * Clarified the commit log of clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thanks, Thomas Andrew Murray (1): of/pci: Provide support for parsing PCI DT ranges property Thierry Reding (2): of/pci: Add of_pci_get_devfn() function of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni (14): pci: infrastructure to add drivers in drivers/pci/host arm: pci: add a align_resource hook clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 clk: mvebu: add more PCIe clocks for Armada XP pci: PCIe driver for Marvell Armada 370/XP systems arm: mvebu: PCIe support is now available on mvebu arm: mvebu: add PCIe Device Tree informations for Armada 370 arm: mvebu: add PCIe Device Tree informations for Armada XP arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 arm: mvebu: PCIe Device Tree informations for Armada XP DB arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox arm: mvebu: PCIe Device Tree informations for Armada 370 DB arm: mvebu: PCIe Device Tree informations for Armada XP GP arm: mvebu: update defconfig with PCI and USB support .../devicetree/bindings/pci/mvebu-pci.txt | 220 + arch/arm/boot/dts/armada-370-db.dts| 17 + arch/arm/boot/dts/armada-370-mirabox.dts | 16 + arch/arm/boot/dts/armada-370.dtsi | 51 ++ arch/arm/boot/dts/armada-xp-db.dts | 33 + arch/arm/boot/dts/armada-xp-gp.dts | 21 + arch/arm/boot/dts/armada-xp-mv78230.dtsi | 104 +++ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 122 +++ arch/arm/boot/dts/armada-xp-mv78460.dtsi | 188 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 + arch/arm/configs/mvebu_defconfig |3 + arch/arm/include/asm/mach/pci.h| 11 + arch/arm/kernel/bios32.c |6 + arch/arm/mach-mvebu/Kconfig|2 + arch/microblaze/pci/pci-common.c | 110 +-- arch/mips/pci/pci.c| 50 +- arch/powerpc/kernel/pci-common.c | 99
[PATCHv7 01/17] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
The modifications to microblaze, mips and powerpc have not been tested.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/microblaze/pci/pci-common.c | 110 ++
arch/mips/pci/pci.c | 50 ++---
arch/powerpc/kernel/pci-common.c | 99 --
drivers/of/address.c | 63 ++
include/linux/of_address.h | 42 +++
5 files changed, 194 insertions(+), 170 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..17a7ad1 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -658,67 +658,43 @@ void pci_resource_to_user(const struct pci_dev *dev, int
bar,
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long isa_mb = 0;
struct resource *res;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ u32 res_type;
pr_info(PCI host bridge %s %s ranges:\n,
dev-full_name, primary ? (primary) : );
- /* Get ranges property */
- ranges = of_get_property(dev, ranges, rlen);
- if (ranges == NULL)
+ /* Check for ranges property */
+ if (of_pci_range_parser(parser, dev))
return;
- /* Parse it */
pr_debug(Parsing ranges property...\n);
- while ((rlen -= np * 4) = 0) {
+ for_each_of_pci_range(parser, range) {
/* Read next ranges element */
- pci_space = ranges[0];
- pci_addr = of_read_number(ranges + 1, 2);
- cpu_addr = of_translate_address(dev, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
-
- pr_debug(pci_space: 0x%08x pci_addr:0x%016llx ,
- pci_space, pci_addr);
- pr_debug(cpu_addr:0x%016llx size:0x%016llx\n,
- cpu_addr, size);
-
- ranges += np;
+ pr_debug(pci_space: 0x%08x pci_addr: 0x%016llx ,
+ range.pci_space, range.pci_addr);
+ pr_debug(cpu_addr: 0x%016llx size: 0x%016llx\n,
+ range.cpu_addr, range.size);
/* If we failed translation or got a zero-sized region
* (some FW try to feed us with non sensical zero sized regions
* such as power3 which look like some kind of attempt
* at exposing the VGA memory hole)
*/
- if (cpu_addr == OF_BAD_ADDR || size == 0)
+ if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
- /* Now consume following elements while they are contiguous */
- for (; rlen = np * sizeof(u32);
-ranges += np, rlen -= np * 4) {
- if (ranges[0] != pci_space)
- break;
- pci_next = of_read_number(ranges + 1, 2);
- cpu_next = of_translate_address(dev, ranges + 3);
- if (pci_next
[PATCHv7 02/17] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
#include asm/prom.h
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct
device_node *parent,
return NULL;
}
EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 03/17] of/pci: Add of_pci_parse_bus_range() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) 8) 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+ const __be32 *values;
+ int len;
+
+ values = of_get_property(node, bus-range, len);
+ if (!values || len sizeof(*values) * 2)
+ return -EINVAL;
+
+ res-name = node-name;
+ res-start = be32_to_cpup(values++);
+ res-end = be32_to_cpup(values);
+ res-flags = IORESOURCE_BUS;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 04/17] pci: infrastructure to add drivers in drivers/pci/host
As agreed by the community, PCI host drivers will now be stored in drivers/pci/host. This commit adds this directory and the related Kconfig/Makefile changes to allow new drivers to be added in this directory. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- drivers/pci/Kconfig |2 ++ drivers/pci/Makefile |3 +++ drivers/pci/host/Kconfig |4 3 files changed, 9 insertions(+) create mode 100644 drivers/pci/host/Kconfig diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 6d51aa6..ac45398 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -119,3 +119,5 @@ config PCI_IOAPIC config PCI_LABEL def_bool y if (DMI || ACPI) select NLS + +source drivers/pci/host/Kconfig diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 0c3efcf..6ebf5bf 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -67,3 +67,6 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o obj-$(CONFIG_OF) += of.o ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG + +# PCI host controller drivers +obj-y += host/ diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig new file mode 100644 index 000..cc3a1af --- /dev/null +++ b/drivers/pci/host/Kconfig @@ -0,0 +1,4 @@ +menu PCI host controller drivers + depends on PCI + +endmenu -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 05/17] arm: pci: add a align_resource hook
The PCI specifications says that an I/O region must be aligned on a 4
KB boundary, and a memory region aligned on a 1 MB boundary.
However, the Marvell PCIe interfaces rely on address decoding windows
(which allow to associate a range of physical addresses with a given
device). For PCIe memory windows, those windows are defined with a 1
MB granularity (which matches the PCI specs), but PCIe I/O windows can
only be defined with a 64 KB granularity, so they have to be 64 KB
aligned. We therefore need to tell the PCI core about this special
alignement requirement.
The PCI core already calls pcibios_align_resource() in the ARM PCI
core, specifically for such purposes. So this patch extends the ARM
PCI core so that it calls a -align_resource() hook registered by the
PCI driver, exactly like the existing -map_irq() and -swizzle()
hooks.
A particular PCI driver can register a align_resource() hook, and do
its own specific alignement, depending on the specific constraints of
the underlying hardware.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/include/asm/mach/pci.h | 11 +++
arch/arm/kernel/bios32.c|6 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..7d2c3c8 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -30,6 +30,11 @@ struct hw_pci {
void(*postinit)(void);
u8 (*swizzle)(struct pci_dev *dev, u8 *pin);
int (*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
};
/*
@@ -51,6 +56,12 @@ struct pci_sys_data {
u8 (*swizzle)(struct pci_dev *, u8 *);
/* IRQ mapping
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
+ /* Resource alignement requirements
*/
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..b2ed73c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct
list_head *head)
sys-busnr = busnr;
sys-swizzle = hw-swizzle;
sys-map_irq = hw-map_irq;
+ sys-align_resource = hw-align_resource;
INIT_LIST_HEAD(sys-resources);
if (hw-private_data)
@@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
{
+ struct pci_dev *dev = data;
+ struct pci_sys_data *sys = dev-sysdata;
resource_size_t start = res-start;
if (res-flags IORESOURCE_IO start 0x300)
@@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
start = (start + align - 1) ~(align - 1);
+ if (sys-align_resource)
+ return sys-align_resource(dev, res, start, size, align);
+
return start;
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 06/17] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv7 07/17] clk: mvebu: add more PCIe clocks for Armada XP
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
