Support for Marvell AHCI interface on Armada 38x

The ahci-platform.txt Device Tree binding documentation is gaining a growing number of compatible strings, and it will gain one more with the addition of the Marvell Armada 380 AHCI support. It is therefore time to reformat this list into a proper bullet list, and more importantly order it alphabetically;

Suggested-by Andrew Lunn <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Documentation/devicetree/bindings/ata/ahci-platform.txt +8 -4

index 48b285f..5598862 100644
@@ -4,10 +4,14 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
 Each SATA controller should have its own node.
 
 Required properties:
-- compatible        : compatible list, one of "snps,spear-ahci",
-                      "snps,exynos5440-ahci", "ibm,476gtr-ahci",
-                      "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
-                      "fsl,imx6q-ahci" or "snps,dwc-ahci"
+- compatible        : compatible string, one of:
+  - "allwinner,sun4i-a10-ahci"
+  - "fsl,imx53-ahci"
+  - "fsl,imx6q-ahci"
+  - "ibm,476gtr-ahci"
+  - "snps,dwc-ahci"
+  - "snps,exynos5440-ahci"
+  - "snps,spear-ahci"
 - interrupts        : <interrupt mapping for SATA IRQ>
 - reg               : <registers mapping>
 

Signature · 1 line

1.8.3.2

Hello,

The Marvell Armada 38x ARM processors use an AHCI compatible interface for SATA (in replacement of the Marvell-specific SATA interface, handled by the sata_mv driver). However, like all DMA-capable Marvell interfaces, some specific MBus window configuration must be done, so a small specific glue layer is needed, which relies on the recently introduced libahci_platform.c.

Changes since v1:

* Rebased on top of v3.15-rc1

* Added a preliminary patch that orders alphabetically the list of compatible strings in the DT binding document ahci-platform.txt. Suggested by Andrew Lunn.

* Made the availability of MBus DRAM window informations mandatory. Suggested by Andrew Lunn.

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Details of the patches:

* The first patch is a DT binding documentation cleanup. I believe it should be taken by the ATA maintainer, because the second patch (driver patch) depends on it.

* The second patch of this series contains the driver itself, which is fairly straight-forward. It should be taken by Tejun Heo as the ATA maintainer.

* The last three patches add the Device Tree and defconfig changes. They should be taken by the respective ARM maintainers (mvebu maintainers for the DT and mvebu_v7_defconfig, and arm-soc maintainers for the multi_v7_defconfig change).

Thanks!

Thomas

Thomas Petazzoni (5):
Documentation: dt-bindings: reformat and order list of ahci-platform
compatibles
ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces
ARM: mvebu: add Device Tree description of AHCI interfaces on Armada

    38x

ARM: configs: add ahci_mvebu to mvebu_v7_defconfig
ARM: configs: add ahci_mvebu to multi_v7_defconfig

 .../devicetree/bindings/ata/ahci-platform.txt      |  13 ++-
 arch/arm/boot/dts/armada-385-db.dts                |   8 ++
 arch/arm/boot/dts/armada-38x.dtsi                  |  16 +++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 drivers/ata/Kconfig                                |   9 ++
 drivers/ata/Makefile                               |   1 +
 drivers/ata/ahci_mvebu.c                           | 107 +++++++++++++++++++++
 8 files changed, 152 insertions(+), 4 deletions(-)
 create mode 100644 drivers/ata/ahci_mvebu.c

Signature · 1 line

1.8.3.2

Hello,

The Marvell Armada 38x ARM processors use an AHCI compatible interface for SATA (in replacement of the Marvell-specific SATA interface, handled by the sata_mv driver). However, like all DMA-capable Marvell interfaces, some specific MBus window configuration must be done, so a small specific glue layer is needed, which relies on the recently introduced libahci_platform.c.

Changes since v1:

* Rebased on top of v3.15-rc1

* Added a preliminary patch that orders alphabetically the list of compatible strings in the DT binding document ahci-platform.txt. Suggested by Andrew Lunn.

* Made the availability of MBus DRAM window informations mandatory. Suggested by Andrew Lunn.

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Details of the patches:

* The first patch is a DT binding documentation cleanup. I believe it should be taken by the ATA maintainer, because the second patch (driver patch) depends on it.

* The second patch of this series contains the driver itself, which is fairly straight-forward. It should be taken by Tejun Heo as the ATA maintainer.

* The last three patches add the Device Tree and defconfig changes. They should be taken by the respective ARM maintainers (mvebu maintainers for the DT and mvebu_v7_defconfig, and arm-soc maintainers for the multi_v7_defconfig change).

Thanks!

Thomas

Thomas Petazzoni (5):
Documentation: dt-bindings: reformat and order list of ahci-platform
compatibles
ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces
ARM: mvebu: add Device Tree description of AHCI interfaces on Armada

    38x

ARM: configs: add ahci_mvebu to mvebu_v7_defconfig
ARM: configs: add ahci_mvebu to multi_v7_defconfig

 .../devicetree/bindings/ata/ahci-platform.txt      |  13 ++-
 arch/arm/boot/dts/armada-385-db.dts                |   8 ++
 arch/arm/boot/dts/armada-38x.dtsi                  |  16 +++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 drivers/ata/Kconfig                                |   9 ++
 drivers/ata/Makefile                               |   1 +
 drivers/ata/ahci_mvebu.c                           | 107 +++++++++++++++++++++
 8 files changed, 152 insertions(+), 4 deletions(-)
 create mode 100644 drivers/ata/ahci_mvebu.c

Quoted 2 lines

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Well, you could have also added a comment explaining the lack of the Power Management support..

Anyway, all patches look OK to me.

Reviewed-by Bartlomiej Zolnierkiewicz <[email protected]>

Dear Bartlomiej Zolnierkiewicz,

On Mon, 14 Apr 2014 17:53:37 +0200, Bartlomiej Zolnierkiewicz wrote:

Quoted 5 lines

Quoted 2 lines

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Well, you could have also added a comment explaining the lack of the Power Management support..

True, sorry for this. Should I resend a new version of the patch series with an indication about this in the commit log? Or is this OK as it is?

Note that working on power management support is part of our mid-term TODO list for this platform, so it will not remain unimplemented forever.

Quoted 10 lines · Thomas Petazzoni

Dear Bartlomiej Zolnierkiewicz,

Quoted 5 lines · Bartlomiej Zolnierkiewicz

Quoted 2 lines

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Well, you could have also added a comment explaining the lack of the Power Management support..

Quoted 2 lines

True, sorry for this. Should I resend a new version of the patch series with an indication about this in the commit log? Or is this OK as it is?

Please include the comment in the next revision if this is not too much trouble (I assume that you would like to do another re-spin just to add Acked-by/Reviewed-by tags anyway).

Dear Bartlomiej Zolnierkiewicz,

Quoted 11 lines · Bartlomiej Zolnierkiewicz

Quoted 10 lines · Thomas Petazzoni

Dear Bartlomiej Zolnierkiewicz,

Quoted 5 lines · Bartlomiej Zolnierkiewicz

Quoted 2 lines

* Fixed the module alias name. Suggested by Bartlomiej Zolnierkiewicz.

Well, you could have also added a comment explaining the lack of the Power Management support..

Quoted 6 lines

Quoted 2 lines

True, sorry for this. Should I resend a new version of the patch series with an indication about this in the commit log? Or is this OK as it is?

Please include the comment in the next revision if this is not too much trouble (I assume that you would like to do another re-spin just to add Acked-by/Reviewed-by tags anyway).

Well, I wasn't planning on re-spinning just to add Acked-by/Reviewed-by tags, as those are generally added by the subsystem maintainers when applying the patches. Though if Tejun says otherwise, I can definitely re-spin without any problem.

Tejun, just let me know what you prefer.

Quoted 6 lines

Well, I wasn't planning on re-spinning just to add Acked-by/Reviewed-by tags, as those are generally added by the subsystem maintainers when applying the patches. Though if Tejun says otherwise, I can definitely re-spin without any problem.

Tejun, just let me know what you prefer.

I can collect the -by's but better patch description is always nice. Maybe just update the patch description and post that one as reply to the patch posted in this thread?

Also, how do you want the patches to be routed? Can all go through libata?

Quoted 1 line · Tejun Heo

Also, how do you want the patches to be routed? Can all go through libata?

As written in the cover letter, I'd expect patches 1 and 2 to go through libata, and then patches 3, 4 and 5 to go through arm-soc. The reason is that patches 3, 4 and 5 modifies the Device Tree files and the ARM defconfigs, which are likely to also be changed by other commits in the same cycle. However, the DT binding documentation change and the driver change are independent, so they can go through libata.

I guess Jason Cooper, who handles the patch merging for mvebu platforms, can confirm (or not?) this proposal.