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
---
arch/arm/boot/dts/armada-370-db.dts | 17 +
1 file changed, 17 insertions
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
---
arch/arm/boot/dts/armada-xp-gp.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm
: Thomas Petazzoni
---
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
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
> wrote:
> > This driver implements the support for the PCIe interfaces on the
> > Marvell Armada 370/XP ARM SoCs. In the future, it might be ext
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
__
uct pci_controller *hose,
+ struct device_node *dev, int primary);
+
#endif
But otherwise, for PATCH 1/3 and 2/3,
Tested-by: Thomas Petazzoni
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, con
' 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
ons, 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 thi
ly 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
__
ot;
> 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
> Signed-off-by: Liviu Dudau
> Reviewed-by: Rob Herr
nally 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.
m 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 Ele
ght (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
ation 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
_
ernal 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
---
Since
es and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
Signed-off-by: Thomas Petazzoni
Reviewed-by: Rob Herring
Tested-by: Thomas Petazzoni
Tested-by: Linus Walleij
Tested-by: Jingoo Han
Acked-by: Gran
ly 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:
From: Thierry Reding
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
Signed-off-by: Thomas
From: Thierry Reding
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
dif
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
Cc: Mike Turquette
---
drivers/clk
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
Cc: Mike Turquette
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4
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
Acked
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
---
arch/arm/mach-mvebu/Kconfig |2 ++
1 file changed, 2
: Thomas Petazzoni
---
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
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
> >
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
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
ernal 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
---
Since
es and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
Signed-off-by: Thomas Petazzoni
Reviewed-by: Rob Herring
Tested-by: Thomas Petazzoni
Tested-by: Linus Walleij
Tested-by: Jingoo Han
Acked-by: Gran
From: Thierry Reding
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
Signed-off-by: Thomas
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
Cc: Mike Turquette
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4
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
---
arch/arm/mach-mvebu/Kconfig |2 ++
1 file changed, 2
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
Acked
: Thomas Petazzoni
---
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
From: Thierry Reding
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
dif
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
Cc: Mike Turquette
---
drivers/clk
x27;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...
d-off-by: Wei Yongjun
Acked-by: Thomas Petazzoni
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, consul
e 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 sup
2C 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
Ker
ere 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,
ntrol 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
rcia
Acked-by: Thomas Petazzoni
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://fre
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
Acked-by: Thomas Petazzoni
I believe this one should be applied now, regardless of what happens
uot; tells you... Which by itself is a very good indicator that
you're probably not the best interlocutor for Allwinner as far as
mainline development is concerned.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development
201 - 245 of 245 matches
Mail list logo