On Tue, Mar 26, 2013 at 10:27:44PM +0100, Thomas Petazzoni wrote:
[...]
> and so now the suggestions is to do:
>
> pcie-controller {
> compatible = "marvell,armada-xp-pcie";
> status = "disabled";
> device_type
Quoting Sören Brinkmann (2013-03-25 17:03:24)
> On Mon, Mar 25, 2013 at 05:33:10PM -0600, Stephen Warren wrote:
> > On 03/25/2013 12:27 PM, Sören Brinkmann wrote:
> > > Hi Stephen,
> > >
> > > On Mon, Mar 25, 2013 at 12:13:08PM -0600, Stephen Warren wrote:
> > >> On 03/20/2013 05:56 PM, Sören Brin
Dear Pavel Machek,
> Hi!
>
> > The system reset controller (SRC) on i.MX51, i.MX53, and i.MX6q controls
> > reset lines to the GPU, VPU, IPU, and OpenVG IP modules.
> >
> > The following patches add a simple API for devices to request being reset
> > by separate reset controller hardware and imp
On 03/26/2013 11:52 AM, Thomas Petazzoni wrote:
> In preparation for moving the IRQ controller driver to
> drivers/irqchip/, we don't want the IRQ controller driver to be
> responsible for initializing the L2 cache. Instead, let's initialize
> the L2 cache at the init_early() level, like mach-exyno
On Wednesday, March 27, 2013 6:33 AM, Rob Herring wrote:
>
> On 03/22/2013 11:07 PM, Jingoo Han wrote:
> > Exynos5440 has a PCIe controller which can be used as Root Complex.
> > This driver supports a PCIe controller as Root Complex mode.
> >
> > Signed-off-by: Surendranath Gurivireddy Balla
> >
Michael Grzeschik writes:
> On Thu, Mar 07, 2013 at 11:54:03PM +0100, Michael Grzeschik wrote:
>> Hey Alex,
>>
>> On Thu, Jan 24, 2013 at 11:42:53AM +0200, Alexander Shishkin wrote:
>> > Peter Chen writes:
>> >
>> > > On Tue, Nov 27, 2012 at 05:16:55PM +0100, Michael Grzeschik wrote:
>> > >> N
On 26 March 2013 17:19, Nobuhiro Iwamatsu wrote:
> On Wed, Mar 27, 2013 at 8:55 AM, Naveen Krishna Ch
> wrote:
>> On 26 March 2013 04:52, Sachin Kamat wrote:
>>> Fixes some typos in the documentation of exynos-adc.txt.
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> .../devicetree/bindings/arm
On Wed, Mar 27, 2013 at 8:55 AM, Naveen Krishna Ch
wrote:
> On 26 March 2013 04:52, Sachin Kamat wrote:
>> Fixes some typos in the documentation of exynos-adc.txt.
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> .../devicetree/bindings/arm/samsung/exynos-adc.txt |4 ++--
>> 1 files changed, 2 i
On 26 March 2013 04:52, Sachin Kamat wrote:
> Fixes some typos in the documentation of exynos-adc.txt.
>
> Signed-off-by: Sachin Kamat
> ---
> .../devicetree/bindings/arm/samsung/exynos-adc.txt |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicet
From: Stephen Warren
Audio-related clocks need to be represented in the device tree. Update
bindings to describe which clocks are needed, and DT files to include
those clocks.
Signed-off-by: Stephen Warren
---
.../devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt |8
.../
On Tue, Mar 26, 2013 at 10:27:44PM +0100, Thomas Petazzoni wrote:
> Is this correct? Thierry, Jason, if you could confirm my understanding,
> that would be great. I could then rework and resend the patch set.
It looked to me the same as what Thierry was doing, and Thierry's
looked like it include
On 03/26/2013 01:17 PM, Arun Kumar K wrote:
+Sensor sub-nodes:
+
+FIMC-IS IP supports custom built sensors to be controlled exclusively by
+the FIMC-IS firmware. These sensor properties are to be defined here.
[snip]
Defining image sensor nodes in a standard way as ISP I2C bus controller
node
On Tue, Mar 26, 2013 at 11:06:56PM +0100, Thomas Petazzoni wrote:
> > The PCIe host driver just seems to get in the way, it has no knowledge
> > it is adding to the process.
> >
> > irqchip knows:
> > - what the physical address of the doorbell is
> > - how to construct an address that is per-c
On Tuesday 26 March 2013, Heiko Stübner wrote:
> This v6 addresses more comments from Arnd Bergmann, setting the compatible
> property to the first supported SoC (s3c2410) instead of using the s3c24xx
> wildcard. It also switches the parent-irq and controller irq in the dt
> irq descriptor bringing
Add the necessary code to initialize the interrupt controller
thru devicetree data using the irqchip infrastructure.
Signed-off-by: Heiko Stuebner
---
.../interrupt-controller/samsung,s3c24xx-irq.txt | 53 +
drivers/irqchip/irq-s3c24xx.c | 231 +++-
Keep a pointer to the corresponding s3c_irq_data struct as irq_chip_data.
This removes the need to fetch the intc struct from the irq_domains
host_data, thus making it independent of the underlying irq_domain
structure.
Also keep the real register offset of the interrupt in the s3c_irq_data
struct
For dt-enabled machines we want to use a big irq_domain over all controllers
and therefore need to access not only the main controllers but the
sub-controller as well.
Signed-off-by: Heiko Stuebner
---
drivers/irqchip/irq-s3c24xx.c | 99 +
1 file changed
Enables post-init setting of the desired typehandler for the interrupt.
Signed-off-by: Heiko Stuebner
---
drivers/irqchip/irq-s3c24xx.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index a565eb8..7cb
The list in used was from the s3c2450, a close cousin of the s3c2416.
As it's not possible to distinguish between the s3c2416 and s3c2450
the additional interrupts of the s3c2450 will only be available thru
devicetree later.
Signed-off-by: Heiko Stuebner
---
drivers/irqchip/irq-s3c24xx.c |5
Might be confusing for people to read the code without having the
datasheet nearby.
Signed-off-by: Heiko Stuebner
---
drivers/irqchip/irq-s3c24xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 5
Dear Jason Gunthorpe,
On Tue, 26 Mar 2013 15:55:46 -0600, Jason Gunthorpe wrote:
> > > FWIW, MSI-X is not restricted to 16 bits, so if you can detect from
> > > the PCI layer if it is setting up MSI or MSI-X you could allocate low
> > > bits first to MSI-X and high bits first to MSI, increasing t
This move is necessary to make use of the irqchip infrastructure
for the following devicetree support for s3c24xx architectures.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/Makefile |2 +-
drivers/irqchip/Makefile
This v6 addresses more comments from Arnd Bergmann, setting the compatible
property to the first supported SoC (s3c2410) instead of using the s3c24xx
wildcard. It also switches the parent-irq and controller irq in the dt
irq descriptor bringing it to a format of
Heiko Stuebner (7):
ARM: S3C
On Tuesday 26 March 2013, Jason Gunthorpe wrote:
> > I'll let Arnd answer this one, but I'm pretty sure that using IRQ
> > domains is the way to go. The fact that a number of drivers don't yet
> > use IRQ domains is maybe just because they haven't been converted yet.
>
> Maybe, but they have irq d
On Tue, Mar 26, 2013 at 10:16:54PM +0100, Thomas Petazzoni wrote:
> > FWIW, MSI-X is not restricted to 16 bits, so if you can detect from
> > the PCI layer if it is setting up MSI or MSI-X you could allocate low
> > bits first to MSI-X and high bits first to MSI, increasing the number
> > of avail
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> On Tue, 26 Mar 2013 21:10:15 +, Arnd Bergmann wrote:
>
> > > To which children? Only to the main-intc children? If so,
> > > armada_370_xp_mpic_of_init() would be called with a 'device_node *'
> > > that points to the main-intc, correct? Then
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 21:31:45 +, Arnd Bergmann wrote:
> On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> > > FWIW, MSI-X is not restricted to 16 bits, so if you can detect from
> > > the PCI layer if it is setting up MSI or MSI-X you could allocate low
> > > bits first to
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 21:15:40 +, Arnd Bergmann wrote:
> On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> > + msimask = readl_relaxed(per_cpu_int_base +
> > + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
> > +
Dear Jason Gunthorpe,
On Tue, 26 Mar 2013 15:14:03 -0600, Jason Gunthorpe wrote:
> On Tue, Mar 26, 2013 at 09:46:13PM +0100, Thomas Petazzoni wrote:
>
> > To me, the topology of the hardware is really that a single device
> > provides two features: the main interrupt controller and the MSI
> > in
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 21:10:15 +, Arnd Bergmann wrote:
> > To which children? Only to the main-intc children? If so,
> > armada_370_xp_mpic_of_init() would be called with a 'device_node *'
> > that points to the main-intc, correct? Then it would have to go back up
> > in the
On 03/22/2013 11:07 PM, Jingoo Han wrote:
> Exynos5440 has a PCIe controller which can be used as Root Complex.
> This driver supports a PCIe controller as Root Complex mode.
>
> Signed-off-by: Surendranath Gurivireddy Balla
> Signed-off-by: Siva Reddy Kallam
> Signed-off-by: Jingoo Han
> ---
>
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> > FWIW, MSI-X is not restricted to 16 bits, so if you can detect from
> > the PCI layer if it is setting up MSI or MSI-X you could allocate low
> > bits first to MSI-X and high bits first to MSI, increasing the number
> > of available MSI/MSI-X ve
Thierry,
On Tue, 26 Mar 2013 21:16:54 +0100, Thierry Reding wrote:
> > Thierry: Did you settle on using assigned-addresses? Can you share the
> > final binding for your driver?
>
> Yes, I have the final bindings ready and I was waiting for Andrew's new
> version of the ranges parsing patch befor
On Tuesday 26 March 2013, Thierry Reding wrote:
> On Tue, Mar 26, 2013 at 08:50:12PM +, Arnd Bergmann wrote:
> > On Tuesday 26 March 2013, Thierry Reding wrote:
> > > pci@1,0 {
> > > device_type = "pci";
> > > assigned-addresses =
Dear Jason Gunthorpe,
On Tue, 26 Mar 2013 12:02:45 -0600, Jason Gunthorpe wrote:
> > This commit introduces the support for the MSI interrupts in the
> > armada-370-xp interrupt controller driver. It registers an IRQ
> > domain associated with the 'msi' node in the Device Tree, which the
> > PCI
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> + msimask = readl_relaxed(per_cpu_int_base +
> + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
> + & PCI_MSI_DOORBELL_MASK;
> +
> + writel(~PCI_MS
On Tue, Mar 26, 2013 at 09:46:13PM +0100, Thomas Petazzoni wrote:
> To me, the topology of the hardware is really that a single device
> provides two features: the main interrupt controller and the MSI
> interrupt controller. But I will adapt to whatever DT binding you
> propose.
No.. the HW is a
On Tue, Mar 26, 2013 at 08:50:12PM +, Arnd Bergmann wrote:
> On Tuesday 26 March 2013, Thierry Reding wrote:
> > pci@1,0 {
> > device_type = "pci";
> > assigned-addresses = <0x82000800 0 0x8000 0
> > 0x1000>;
> >
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Tue, 26 Mar 2013 18:38:22 +, Arnd Bergmann wrote:
>
> > > Note that both the parent and the child node need to have the
> > > 'interrupt-controller' empty property:
> > >
> > > * The interrupt-co
On Tuesday 26 March 2013, Thierry Reding wrote:
> pci@1,0 {
> device_type = "pci";
> assigned-addresses = <0x82000800 0 0x8000 0
> 0x1000>;
> reg = <0x000800 0 0 0 0>;
> status = "di
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 18:38:22 +, Arnd Bergmann wrote:
> > Note that both the parent and the child node need to have the
> > 'interrupt-controller' empty property:
> >
> > * The interrupt-controller property is needed in the main
> > interrupt controll
Wolfram,
On Wed, Mar 13, 2013 at 9:36 AM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering. This i2c-arbitrator-cros-ec driver could also
> be used in other
On 03/26/2013 10:57 AM, Graeme Gregory wrote:
> On 26/03/13 16:22, Stephen Warren wrote:
>> On 03/26/2013 03:27 AM, Graeme Gregory wrote:
>> ...
>>> If we are tightly coupling as above then using platform_irq is an extra
>>> inefficiency. You both have to populate this then parse it afterwards.
>>>
On Tue, Mar 26, 2013 at 10:34:21AM -0600, Jason Gunthorpe wrote:
[...]
> This basically looks fine to me, however, I think it is valuable if
> you and Thierry could use the same method to pass per-port registers. I
> expect others are going to reference these bindings for future work,
> and one sta
On Tue, Mar 26, 2013 at 04:16:10PM +, Grant Likely wrote:
> On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou
> wrote:
> > Hi Lee,
> >
> > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> >
> > > At the end of the line, some kind of hardware glue is going to be
> > > needed.
> >
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
>
> I've tried to explain that in the commit log of PATCH 6, which says:
>
> However, we need the driver to expose two different IRQ domains: one
> for the main interrupt controller itself, and one for the MSI
> interrupt controller.
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou
wrote:
> Hi Lee,
>
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
>
> > At the end of the line, some kind of hardware glue is going to be
> > needed.
> >
> > I just feel that drawing from a sample size of 1 (maybe 2 if I ge
On Mon, 7 Jan 2013 20:51:03 +0200, Pantelis Antoniou
wrote:
> Document the beaglebone's cape driver bindings.
>
> Signed-off-by: Pantelis Antoniou
Hi Pantelis,
I'll go back and review the driver in a minute, but I'll start here
since this is the data model that we'll be using for a long time
On Tue, Mar 26, 2013 at 05:52:22PM +0100, Thomas Petazzoni wrote:
> This commit introduces the support for the MSI interrupts in the
> armada-370-xp interrupt controller driver. It registers an IRQ domain
> associated with the 'msi' node in the Device Tree, which the PCI
> controller will refer to
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 17:18:08 +, Arnd Bergmann wrote:
> The mailing list rejects patches that have an in-reply-to header with
> pointing to a different subject as the new email.
> It also has an exception for emails that have the work PATCH in
> brackets, but not [RFC] or [
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> To the readers of LAKML: the mailing list software has, for some
> reason, decided that all the e-mails in this series had a "Suspicious
> header". They have all been generated by git format-patch and sent with
> git send-email, just like the prev
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 17:07:41 +, Arnd Bergmann wrote:
> I think the @d002 part needs to be removed for the nodes that
> have no reg property.
Sure, will fix.
> I think I did not follow the entire discussion. What has led to having
> two subnodes in the end, rather tha
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> + mpic: main-intc@d002 {
> +#interrupt-cells = <1>;
> +interrupt-controller;
> + };
> +
> + msi: msi-intc@d002 {
> +#interrupt-cells = <1>;
Hello,
On Tue, 26 Mar 2013 17:52:15 +0100, Thomas Petazzoni wrote:
> This set of patches introduces Message Signaled Interrupt support in
> the Marvell EBU PCIe driver. It has been successfully tested on the
> Armada XP GP platform and the Armada 370 DB platform with an Intel
> e1000e PCIe networ
Dear Arnd Bergmann,
On Tue, 26 Mar 2013 16:53:48 +, Arnd Bergmann wrote:
> On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> > @@ -72,6 +73,10 @@ void __init armada_370_xp_init_early(void)
> > ARMADA_370_XP_MBUS_WINS_SIZE,
> > ARMADA_370_XP_SDR
Dear Jason Gunthorpe,
On Tue, 26 Mar 2013 10:34:21 -0600, Jason Gunthorpe wrote:
> On Tue, Mar 26, 2013 at 05:18:32PM +0100, Thomas Petazzoni wrote:
>
> > + pcie-controller {
> > + compatible = "marvell,armada-370-pcie";
> > + status = "disabled";
> >
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> When the Marvell Armada 370/XP support was included in the kernel, the
> drivers/irqchip/ directory didn't exist and the minimal infrastructure
> in it also didn't exist. Now that we have those things in place, we
> move the Armada 370/XP IRQ cont
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> @@ -72,6 +73,10 @@ void __init armada_370_xp_init_early(void)
> ARMADA_370_XP_MBUS_WINS_SIZE,
> ARMADA_370_XP_SDRAM_WINS_BASE,
> ARMADA_370_XP_SDRAM_WINS_SIZE);
> +
> +#ifdef
Now that MSI support is available, both in the IRQ controller driver
and in the PCIe driver, let's enable it in the mvebu_defconfig used
for Armada 370/XP platforms.
Signed-off-by: Thomas Petazzoni
---
arch/arm/configs/mvebu_defconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/a
Now that the Marvell EBU PCIe driver supports MSI, we can adjust the
Device Tree for the Armada 370 and Armada XP SoCs so that the PCIe
controller nodes point to the MSI interrupt controller using the
'msi-parent' property.
Signed-off-by: Thomas Petazzoni
---
arch/arm/boot/dts/armada-370.dtsi
This commit adds the MSI support for the Marvell EBU PCIe driver. The
driver now looks at the 'msi-parent' property of the PCIe controller
DT node, and if it exists, it gets the associated IRQ domain, which
should be the MSI interrupt controller registered by the IRQ
controller driver.
Using this,
From: Thierry Reding
The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.
This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_m
In the Marvell hardware, MSI interrupts are supported using doorbells,
and those doorbells are handled through registers that are part of the
registers managed by the IRQ controller driver: they are the same
registers used for handling IPI interrupts. Therefore, it is clearly
the responsability of
This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an IRQ domain
associated with the 'msi' node in the Device Tree, which the PCI
controller will refer to in a followup commit.
The MSI interrupts use the 16 high doorbells, and a
The mpic alias is already defined in the common armada-370-xp.dtsi, so
there's no need to repeat it at the armada-xp.dtsi and armada-370.dtsi
level. Moreover, we're going to slightly change how the interrupt
controller is declared in the common armada-370-xp.dtsi file.
Signed-off-by: Thomas Petazz
In preparation for the introduction of MSI support in the IRQ
controller driver, we clarify the implementation of IPI using
additional defines for the manipulation of doorbells. Just like IPIs
are implemented using doorbells, MSIs will also use doorbells, so it
makes sense to do this preparatory cl
If we move the IRQ handler function above the initialization function,
we avoid a forward declaration. This wasn't done as part of the
previous commit, in order to increase the readibility of the previous
commit, who was also moving the IRQ controller driver from arch/arm to
drivers/irqchip.
Signe
When the Marvell Armada 370/XP support was included in the kernel, the
drivers/irqchip/ directory didn't exist and the minimal infrastructure
in it also didn't exist. Now that we have those things in place, we
move the Armada 370/XP IRQ controller driver from
arch/arm/mach-mvebu/irq-armada-370-xp.c
In preparation for moving the IRQ controller driver to
drivers/irqchip/, we don't want the IRQ controller driver to be
responsible for initializing the L2 cache. Instead, let's initialize
the L2 cache at the init_early() level, like mach-exynos/common.c is
doing.
Signed-off-by: Thomas Petazzoni
-
Hello,
This set of patches introduces Message Signaled Interrupt support in
the Marvell EBU PCIe driver. It has been successfully tested on the
Armada XP GP platform and the Armada 370 DB platform with an Intel
e1000e PCIe network card that supports MSI.
This is based on work done by Lior Amsalem
On 03/26/2013 05:39 PM, Sylwester Nawrocki wrote:
> Changes in this iteration include mostly adaptation to changes at the
> V4L2 OF parser lib and an addition of clocks/clock-names properties
> in the bindings of the IP blocks.
>
> If there is no more comments I intend to send a pull request inclu
Before the camera ports can be used the pinmux needs to be configured
properly. This patch adds a function to set the camera ports pinctrl
to a default state within the media driver's probe().
The camera port(s) are then configured for the video bus operation.
Signed-off-by: Sylwester Nawrocki
Si
The sensor (I2C and/or SPI client) devices are instantiated by their
corresponding control bus drivers. Since the I2C client's master clock
is often provided by a video bus receiver (host interface) or other
than I2C/SPI controller device, the drivers of those client devices
are not accessing hardw
This patch adds changes required for the main camera media device
driver corresponding to the top level 'camera' device node.
The drivers of devices corresponding to child nodes of the 'camera'
node are looked up and and registered as sub-devices to the top
level driver. The main driver's probing
This patch adds the device tree support for FIMC-LITE device
driver. The bindings include compatible property for the Exynos5
SoC series, however the actual implementation for these SoCs will
be added in a separate patch.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Change
This patch adds device tree support for FIMC driver on S5PV210
and Exynos4 SoCs.
The FIMC IP block's features and quirks encoded statically in
the driver are now parsed from the device tree. Once all relevant
platforms are converted to device tree based booting the FIMC
variant data structures wil
This patch support for binding the driver to the MIPI-CSIS
devices instantiated from device tree and parsing the SoC
and board specific properties. The MIPI CSI-2 channel is
determined by the value of reg property placed in csis'
port subnode.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyun
Changes in this iteration include mostly adaptation to changes at the
V4L2 OF parser lib and an addition of clocks/clock-names properties
in the bindings of the IP blocks.
If there is no more comments I intend to send a pull request including
the DT bindings documentation, the V4L2 OF parser and t
On 11 March 2013 12:24, Kukjin Kim wrote:
> Sachin Kamat wrote:
>>
>> Hi Kukjin,
>>
>> Can you please look into this series as it is pending since quite some time.
>>
> Applied, I have another opinion about the compatible string though...
Couldn't find this series in your latest for-next. Please
On Tue, Mar 26, 2013 at 05:18:32PM +0100, Thomas Petazzoni wrote:
> + pcie-controller {
> + compatible = "marvell,armada-370-pcie";
> + status = "disabled";
> + device_type = "pci";
> +
> + #address-cells =
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> 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.
On 03/26/2013 03:27 AM, Graeme Gregory wrote:
...
> If we are tightly coupling as above then using platform_irq is an extra
> inefficiency. You both have to populate this then parse it afterwards.
> Why not just use the regmap helper? Ill admit this code is like this as
> there was a period where p
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 indep
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/boot
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:
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(+)
dif
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
---
arch/arm/boot/dts/armada-xp-db.dts | 33 +
1 file changed, 33 ins
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
---
arch/arm/boot/dts/armada-37
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 informati
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
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 file changed, 9
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
---
arch/arm/boot/dts/armada-370.dtsi | 45 +
1 file changed, 45 insertions(+)
diff --git
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 PC
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 ins
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 tho
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 win
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/mvebu
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
---
drivers/pci/Kconfig |2 ++
drivers/pci/Ma
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
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
---
drivers/of/of_pci.c
From: Andrew Murray
This patch factors out common implementations 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
1 - 100 of 150 matches
Mail list logo
