| Message ID | 1359995888-2385-1-git-send-email-ezequiel.garcia@free-electrons.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, This patchset adds support for the SPI controller available in Armada 370 and Armada XP SoC. The patches are based in Jason Cooper's mvebu/dt branch. Feel free to test and/or provide feedback. Ezequiel Garcia (2): ARM: mvebu: Update defconfig to select SPI support ARM: mvebu: Add support for SPI controller in Armada 370/XP arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++++++++++++++++++++++ arch/arm/configs/mvebu_defconfig | 2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) Thanks,
Ezequiel, This series looks good. just a few comments: On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: > Hi, > > This patchset adds support for the SPI controller > available in Armada 370 and Armada XP SoC. > > The patches are based in Jason Cooper's mvebu/dt branch. It probably doesn't matter for this series (I haven't tried to apply it yet), but please base future work off of a mainline tag (eg v3.8-rc6). It makes merge conflicts easier to resolve. Feel free to test-merge against the mvebu/ branches and let me know of any conflicts. Also, your patch series appears to be out of order, did you use git send-email once per file? thx, Jason.
On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: > Hi, > > This patchset adds support for the SPI controller > available in Armada 370 and Armada XP SoC. Hi Ezequiel Do any of the boards we have with mainline support have any devices on the SPI busses? Its hard to test otherwise. Thanks Andrew
Jason, On Mon, Feb 04, 2013 at 01:37:33PM -0500, Jason Cooper wrote: > This series looks good. just a few comments: > > On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: > > Hi, > > > > This patchset adds support for the SPI controller > > available in Armada 370 and Armada XP SoC. > > > > The patches are based in Jason Cooper's mvebu/dt branch. > > It probably doesn't matter for this series (I haven't tried to apply it > yet), but please base future work off of a mainline tag (eg v3.8-rc6). > It makes merge conflicts easier to resolve. > > Feel free to test-merge against the mvebu/ branches and let me know of > any conflicts. > Ah, I see. I was mistakenly assuming you wanted against that branch; I'll base the patches on mainline in the future. Thanks for the advice. > Also, your patch series appears to be out of order, did you use git > send-email once per file? > I always send the cover letter manually. This time I did it after the patches. I'm in the process of automating this in my workflow, but feel free to make a suggestion. Thanks,
Andrew, On Mon, Feb 04, 2013 at 08:03:26PM +0100, Andrew Lunn wrote: > On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: > > Hi, > > > > This patchset adds support for the SPI controller > > available in Armada 370 and Armada XP SoC. > > Hi Ezequiel > > Do any of the boards we have with mainline support have any devices on > the SPI busses? Its hard to test otherwise. > Mmm... very true. Recently added Armada XP GP board as an SPI flash. Probably other evaluation boards also has similar SPI flashes, but I should check that. I'll prepare a patch for GP board tomorrow, based on Gregory's patches for that board, so you can test that. Also, I hope to prepare patches for the other evaluation boards soon. Regards,
Ezequiel, On Mon, Feb 04, 2013 at 04:29:15PM -0300, Ezequiel Garcia wrote: > On Mon, Feb 04, 2013 at 01:37:33PM -0500, Jason Cooper wrote: > > On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: > > > The patches are based in Jason Cooper's mvebu/dt branch. > > > > It probably doesn't matter for this series (I haven't tried to apply it > > yet), but please base future work off of a mainline tag (eg v3.8-rc6). > > It makes merge conflicts easier to resolve. > > > > Feel free to test-merge against the mvebu/ branches and let me know of > > any conflicts. > > > > Ah, I see. > > I was mistakenly assuming you wanted against that branch; > I'll base the patches on mainline in the future. Nope, the branches are organized that way to sanely merge in with all the other arm-soc code. While I make every effort to keep them stable (ie, not rebased), they may change at anytime if I need to fix things. tags are stable, and if all patches are based on tags, then merge conflicts follow a predictable pattern. Anything else devolves into chaos. > > Also, your patch series appears to be out of order, did you use git > > send-email once per file? > > I always send the cover letter manually. This time I did it after the patches. > I'm in the process of automating this in my workflow, > but feel free to make a suggestion. if format-patch is called properly (I know from experience how to call it improperly ;-) ), you can just do $ git send-email ... /path/to/patches/*.patch and it'll get the order correct. It will also ask for confirmation before sending each email. Dry-run sending a series just to yourself lets you see how it will appear once it goes out to the list. hth, Jason.
Jason, On Mon, Feb 4, 2013 at 4:47 PM, Jason Cooper <jason@lakedaemon.net> wrote: > Ezequiel, > > On Mon, Feb 04, 2013 at 04:29:15PM -0300, Ezequiel Garcia wrote: >> On Mon, Feb 04, 2013 at 01:37:33PM -0500, Jason Cooper wrote: >> > On Mon, Feb 04, 2013 at 01:51:20PM -0300, Ezequiel Garcia wrote: >> > > The patches are based in Jason Cooper's mvebu/dt branch. >> > >> > It probably doesn't matter for this series (I haven't tried to apply it >> > yet), but please base future work off of a mainline tag (eg v3.8-rc6). >> > It makes merge conflicts easier to resolve. >> > >> > Feel free to test-merge against the mvebu/ branches and let me know of >> > any conflicts. >> > >> >> Ah, I see. >> >> I was mistakenly assuming you wanted against that branch; >> I'll base the patches on mainline in the future. > > Nope, the branches are organized that way to sanely merge in with all > the other arm-soc code. While I make every effort to keep them stable > (ie, not rebased), they may change at anytime if I need to fix things. > > tags are stable, and if all patches are based on tags, then merge > conflicts follow a predictable pattern. Anything else devolves into > chaos. > Ahá... this explains why I was seeing your branches rebased! ;-) >> > Also, your patch series appears to be out of order, did you use git >> > send-email once per file? >> >> I always send the cover letter manually. This time I did it after the patches. >> I'm in the process of automating this in my workflow, >> but feel free to make a suggestion. > > if format-patch is called properly (I know from experience how to call > it improperly ;-) ), you can just do > > $ git send-email ... /path/to/patches/*.patch > > and it'll get the order correct. It will also ask for confirmation > before sending each email. > > Dry-run sending a series just to yourself lets you see how it will > appear once it goes out to the list. > Okey, great. Thanks for the advices!
Hi Ezequiel, On 02/04/2013 05:38 PM, Ezequiel Garcia wrote: > The Armada 370 and Armada XP SoC has an SPI controller. > This patch adds support for this controller in Armada 370 > and Armada XP SoC common device tree files. > > Cc: Gregory Clement <gregory.clement@free-electrons.com> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Lior Amsalem <alior@marvell.com> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > --- > arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++++++++++++++++++++++ > 1 files changed, 22 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi > index 28276fe..22340d5 100644 > --- a/arch/arm/boot/dts/armada-370-xp.dtsi > +++ b/arch/arm/boot/dts/armada-370-xp.dtsi > @@ -145,6 +145,28 @@ > clocks = <&gateclk 17>; > status = "disabled"; > }; > + > + spi0: spi@d0010600 { > + compatible = "marvell,orion-spi"; > + reg = <0xd0010600 0x50>; Currently the driver only use the 5th first register. All of the other mvebu platform declare the last register at offset 0x28. The Armada 370 SoC have also the last register at offset 0x28. Only for the Armada XP SoC there are more registers and we have a the last register at offset 0x50. Obviously the driver won't use these extra register. So I think that the best for now is to declare: reg = <0xd0010600 0x28>; > + #address-cells = <1>; > + #size-cells = <0>; > + cell-index = <0>; > + interrupts = <30>; > + clocks = <&coreclk 0>; > + status = "disabled"; > + }; > + > + spi1: spi@d0010680 { > + compatible = "marvell,orion-spi"; > + reg = <0xd0010680 0x50>; and here: reg = <0xd0010680 0x28>; > + #address-cells = <1>; > + #size-cells = <0>; > + cell-index = <1>; > + interrupts = <92>; > + clocks = <&coreclk 0>; > + status = "disabled"; > + }; > }; > }; > > Once it will be fixed, for this patch you can add my Acked-by: Gregory Clement <gregory.clement@free-electrons.com> Regards,
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi index 28276fe..22340d5 100644 --- a/arch/arm/boot/dts/armada-370-xp.dtsi +++ b/arch/arm/boot/dts/armada-370-xp.dtsi @@ -145,6 +145,28 @@ clocks = <&gateclk 17>; status = "disabled"; }; + + spi0: spi@d0010600 { + compatible = "marvell,orion-spi"; + reg = <0xd0010600 0x50>; + #address-cells = <1>; + #size-cells = <0>; + cell-index = <0>; + interrupts = <30>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + + spi1: spi@d0010680 { + compatible = "marvell,orion-spi"; + reg = <0xd0010680 0x50>; + #address-cells = <1>; + #size-cells = <0>; + cell-index = <1>; + interrupts = <92>; + clocks = <&coreclk 0>; + status = "disabled"; + }; }; };
The Armada 370 and Armada XP SoC has an SPI controller. This patch adds support for this controller in Armada 370 and Armada XP SoC common device tree files. Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Lior Amsalem <alior@marvell.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> --- arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-)