From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:10
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
--
1.8.3.2
From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:11
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 <andrew@lunn.ch>
Signed-off-by: Thomas Petazzoni <redacted>
---
Documentation/devicetree/bindings/ata/ahci-platform.txt | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
@@ -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>
From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:12
The Marvell Armada 380 SoC includes two AHCI compatible
interfaces. However, like all DMA-capable Marvell interface, they
require special handling to configure MBus windows. Therefore, this
commit adds a new ahci_mvebu driver, which relies on the
libahci_platform.c code recently introduced.
Signed-off-by: Thomas Petazzoni <redacted>
---
.../devicetree/bindings/ata/ahci-platform.txt | 1 +
drivers/ata/Kconfig | 9 ++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_mvebu.c | 107 +++++++++++++++++++++
4 files changed, 118 insertions(+)
create mode 100644 drivers/ata/ahci_mvebu.c
From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:13
The Marvell Armada 38x processors contain two AHCI compatible
interfaces. This commit adds the Device Tree description of those
interfaces at the SoC level, and also enables them on the Armada 385
DB platform, which allows access to both interfaces through SATA
ports.
Signed-off-by: Thomas Petazzoni <redacted>
---
arch/arm/boot/dts/armada-385-db.dts | 8 ++++++++
arch/arm/boot/dts/armada-38x.dtsi | 16 ++++++++++++++++
2 files changed, 24 insertions(+)
From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:14
The Marvell Armada 38x platform needs the ahci_mvebu driver enabled
for the AHCI interfaces, so this commit enables the corresponding
Kconfig option in mvebu_v7_defconfig.
Signed-off-by: Thomas Petazzoni <redacted>
---
arch/arm/configs/mvebu_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
From: Thomas Petazzoni <hidden> Date: 2014-04-14 14:34:15
The Marvell Armada 38x platform needs the ahci_mvebu driver enabled
for the AHCI interfaces, so this commit enables the corresponding
Kconfig option in multi_v7_defconfig.
Signed-off-by: Thomas Petazzoni <redacted>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
On Mon, Apr 14, 2014 at 04:34:11PM +0200, Thomas Petazzoni wrote:
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 <andrew@lunn.ch>
Signed-off-by: Thomas Petazzoni <redacted>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Thanks Thomas
Andrew
@@ -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>
On Mon, Apr 14, 2014 at 04:34:10PM +0200, Thomas Petazzoni wrote:
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.
Acked-by: Andrew Lunn <andrew@lunn.ch>
Andrew
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
--
1.8.3.2
Hi,
On Monday, April 14, 2014 04:34:10 PM Thomas Petazzoni wrote:
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.
Well, you could have also added a comment explaining the lack of
the Power Management support..
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).
Anyway, all patches look OK to me.
Reviewed-by: Bartlomiej Zolnierkiewicz <redacted>
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
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
* 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.
Anyway, all patches look OK to me.
Reviewed-by: Bartlomiej Zolnierkiewicz <redacted>
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
* 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?
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).
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.
OK, good to hear that.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
* 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?
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.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
* 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?
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.
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?
--
tejun
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?
Actually, Bartlomiej wanted the comment about the power management
features to be made in the code itself, rather than in the commit log,
so I guess I'll just respin the patch series. Expect a v3 tomorrow with
this change.
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.
Thanks a lot for the feedback!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
From: Jason Cooper <hidden> Date: 2014-04-16 17:07:05
On Mon, Apr 14, 2014 at 08:44:55PM +0200, Thomas Petazzoni wrote:
On Mon, 14 Apr 2014 13:46:06 -0400, Tejun Heo wrote:
quoted
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.
Yep, this is how we do it. The only caveat is if there are going to be
changes during this window that depend on the driver changes in this
series. Then we would ask to set up a topic branch.
That happens a little more frequently now that we have boards in the
boot farm testing linux-next and other trees. It means we also care
about boot-time dependencies as well as build deps.
I'll take a closer look at this series in the next few days and let you
know.
thx,
Jason.