* [PATCH v10 4/4] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
From: Loc Ho @ 2014-02-21 17:46 UTC (permalink / raw)
To: olof, tj, arnd
Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, ddutile, jcm,
patches, Loc Ho, Tuan Phan, Suman Tripathi
In-Reply-To: <1393004801-25970-4-git-send-email-lho@apm.com>
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
arch/arm64/boot/dts/apm-storm.dtsi | 75 ++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..c78ddcf 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -176,6 +176,51 @@
reg-names = "csr-reg";
clock-output-names = "eth8clk";
};
+
+ sataphy1clk: sataphy1clk@1f21c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f21c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy1clk";
+ status = "disabled";
+ csr-offset = <0x4>;
+ csr-mask = <0x00>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy2clk: sataphy1clk@1f22c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f22c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy2clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy3clk: sataphy1clk@1f23c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f23c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy3clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
};
serial0: serial@1c020000 {
@@ -187,5 +232,35 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ phy1: phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f21a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy1clk 0>;
+ status = "disabled";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy2clk 0>;
+ status = "ok";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <1 10 10 2 10 10>;
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy3clk 0>;
+ status = "ok";
+ apm,tx-boost-gain = <31 31 31 31 31 31>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
};
};
--
1.5.5
^ permalink raw reply related
* [PATCH v12 0/3] ata: Add APM X-Gene SoC AHCI SATA host controller support
From: Loc Ho @ 2014-02-21 17:47 UTC (permalink / raw)
To: olof, tj, arnd
Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, ddutile, jcm,
patches, Loc Ho, Tuan Phan, Suman Tripathi
This patch adds support for the APM X-Gene SoC AHCI SATA host controller. In
order for the host controller to work, the corresponding PHY driver
musts also be available.
v12:
* Remove function xgene_ahci_get_channel and use the ata_port field port_no
* Update comment for function xgene_ahci_read_id to function comment style
'/**'
* Update comment for multiple lines to fully-winged style
v11:
* Drop the export functions requirement with libachi
* Change CONFIG_SATA_XGENE to CONFIG_AHCI_XGENE
* Rename file sata_xgene.c to ahci_xgene.c
* Convert to use Hans De Geode version 5 ahci_platform code re-factor changes
to reduce code duplication. For extra context, use plat_data to store our
context. The probe function follows the ahci_sunxi implementation. A number
of code fragments update to reflect this change.
* Update comment for function xgene_ahci_read_id
* Minor code move around in function xgene_ahci_do_hardreset and use
ATA_BUSY instead 0x80
* Fix hardreset to use start_engine function pointer as required due to newer
kernel rebased
* Fix the set DMA mask for 32-bit as well
v10:
* Update binding documentation
v9:
* Remove ACPI/EFI include files
* Remove the IO flush support, interrupt routine, and DTS resources
* Remove function xgene_rd, xgene_wr, and xgene_wr_flush
* Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
* Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
* Clean up hardreset functions
* Require v7 of the PHY driver
v8:
* Remove _ADDR from defines
* Remove define MSTAWAUX_COHERENT_BYPASS_SET and
STARAUX_COHERENT_BYPASS_SET and use direct coding
* Remove the un-necessary check for DTS boot with built in ACPI table
* Switch to use dma_set_mask_and_coherent for setting DMA mask
* Remove ACPI table matching code
* Update clock-names for sata01clk, sata23clk, and sata45clk
v7:
* Update the clock code by toggle the clock
* Update the DTS clock mask values due to the clock spilt between host and
v5 of the PHY drivers
v6:
* Update binding documentation
* Change select PHY_XGENE_SATA to PHY_XGENE
* Add ULL to constants
* Change indentation and comments
* Clean up the probe functions a bit more
* Remove xgene_ahci_remove function
* Add the flush register to DTS
* Remove the interrupt-parent from DTS
v5:
* Sync up to v3 of the PHY driver
* Remove MSLIM wrapper functions
* Change the memory shutdown loop to use usleep_range
* Use devm_ioremap_resource instead devm_ioremap
* Remove suspend/resume functions as not needed
v4:
* Remove the ID property in DT
* Remove the temporary PHY direct function call and use PHY function
* Change printk to pr_debug
* Move the IOB flush addresses into the DT
* Remove the parameters retrieval function as no longer needed
* Remove the header file as no longer needed
* Require v2 patch of the SATA PHY driver. Require slightly modification
in the Kconfig as it is moved to folder driver/phy and use Kconfig
PHY_XGENE_SATA instead SATA_XGENE_PHY.
v3:
* Move out the SATA PHY to another driver
* Remove the clock-cells entry from DTS
* Remove debug wrapper
* Remove delay functions wrapper
* Clean up resource and IRQ query
* Remove query clock name
* Switch to use dma_set_mask/dma_coherent_mask
* Remove un-necessary devm_kfree
* Update GPL license header to v2
* Spilt up function xgene_ahci_hardreset
* Spilt up function xgene_ahci_probe
* Remove all reference of CONFIG_ARCH_MSLIM
* Clean up chip revision code
v2:
* Clean up file sata_xgene.c with Lindent and etc
* Clean up file sata_xgene_serdes.c with Lindent and etc
* Add description to each patch
v1:
* inital version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (3):
Documentation: Add documentation for APM X-Gene SoC SATA host
controller DTS binding
ata: Add APM X-Gene SoC AHCI SATA host controller driver
arm64: Add APM X-Gene SoC AHCI SATA host controller DTS entries
.../devicetree/bindings/ata/apm-xgene.txt | 70 +++
arch/arm64/boot/dts/apm-storm.dtsi | 75 +++
drivers/ata/Kconfig | 8 +
drivers/ata/Makefile | 1 +
drivers/ata/ahci_xgene.c | 540 ++++++++++++++++++++
5 files changed, 694 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
create mode 100644 drivers/ata/ahci_xgene.c
^ permalink raw reply
* [PATCH v12 1/3] Documentation: Add documentation for APM X-Gene SoC SATA host controller DTS binding
From: Loc Ho @ 2014-02-21 17:47 UTC (permalink / raw)
To: olof-nZhT3qVonbNeoWH0uzbU5w, tj-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ddutile-H+wXaHxf7aLQT0dZR+AlfA, jcm-H+wXaHxf7aLQT0dZR+AlfA,
patches-qTEPVZfXA3Y, Loc Ho, Tuan Phan, Suman Tripathi
In-Reply-To: <1393004853-25994-1-git-send-email-lho-qTEPVZfXA3Y@public.gmane.org>
Signed-off-by: Loc Ho <lho-qTEPVZfXA3Y@public.gmane.org>
Signed-off-by: Tuan Phan <tphan-qTEPVZfXA3Y@public.gmane.org>
Signed-off-by: Suman Tripathi <stripathi-qTEPVZfXA3Y@public.gmane.org>
---
.../devicetree/bindings/ata/apm-xgene.txt | 70 ++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt
new file mode 100644
index 0000000..633eb3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/apm-xgene.txt
@@ -0,0 +1,70 @@
+* APM X-Gene 6.0 Gb/s SATA host controller nodes
+
+SATA host controller nodes are defined to describe on-chip Serial ATA
+controllers. Each SATA controller (pair of ports) have its own node.
+
+Required properties:
+- compatible : Shall contain:
+ * "apm,xgene-ahci-sgmii" if mux'ed with SGMII
+ * "apm,xgene-ahci-pcie" if mux'ed with PCIe
+- reg : First memory resource shall be the AHCI memory
+ resource.
+ Second memory resource shall be the host controller
+ memory resource.
+- interrupts : Interrupt-specifier for SATA host controller IRQ.
+- clocks : Reference to the clock entry.
+- phys : A list of phandles + phy-specifiers, one for each
+ entry in phy-names.
+- phy-names : Should contain:
+ * "sata-6g" for the SATA 6.0Gbps PHY
+
+Optional properties:
+- status : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+- interrupt-parent : Interrupt controller.
+
+Example:
+ sataclk: sataclk {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <100000000>;
+ clock-output-names = "sataclk";
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>,
+ <0x0 0x1f22c000 0x0 0x100>;
+ #phy-cells = <1>;
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>,
+ <0x0 0x1f23c000 0x0 0x100>;
+ #phy-cells = <1>;
+ };
+
+ sata2: sata@1a400000 {
+ compatible = "apm,xgene-ahci-sgmii";
+ reg = <0x0 0x1a400000 0x0 0x1000>,
+ <0x0 0x1f220000 0x0 0x10000>;
+ interrupt-parent = <&gic>;
+ interrupts = <0x0 0x87 0x4>;
+ status = "ok";
+ clocks = <&sataclk 0>;
+ phys = <&phy2 0>;
+ phy-names = "sata-6g";
+ };
+
+ sata3: sata@1a800000 {
+ compatible = "apm,xgene-ahci-pcie";
+ reg = <0x0 0x1a800000 0x0 0x1000>,
+ <0x0 0x1f230000 0x0 0x10000>;
+ interrupt-parent = <&gic>;
+ interrupts = <0x0 0x88 0x4>;
+ status = "ok";
+ clocks = <&sataclk 0>;
+ phys = <&phy3 0>;
+ phy-names = "sata-6g";
+ };
--
1.5.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v12 2/3] ata: Add APM X-Gene SoC AHCI SATA host controller driver
From: Loc Ho @ 2014-02-21 17:47 UTC (permalink / raw)
To: olof, tj, arnd
Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, ddutile, jcm,
patches, Loc Ho, Tuan Phan, Suman Tripathi
In-Reply-To: <1393004853-25994-2-git-send-email-lho@apm.com>
This patch adds support for the APM X-Gene SoC AHCI SATA host controller
driver. It requires the corresponding APM X-Gene SoC PHY driver.
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
drivers/ata/Kconfig | 8 +
drivers/ata/Makefile | 1 +
drivers/ata/ahci_xgene.c | 540 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 549 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/ahci_xgene.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index cc67cc0..174e398 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -115,6 +115,14 @@ config AHCI_SUNXI
If unsure, say N.
+config AHCI_XGENE
+ tristate "APM X-Gene 6.0Gbps AHCI SATA host controller support"
+ depends on ARM64 || COMPILE_TEST
+ select SATA_AHCI_PLATFORM
+ select PHY_XGENE
+ help
+ This option enables support for APM X-Gene SoC SATA host controller.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 246050b..72b423b 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o
obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o
+obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
new file mode 100644
index 0000000..be0c4fc
--- /dev/null
+++ b/drivers/ata/ahci_xgene.c
@@ -0,0 +1,540 @@
+/*
+ * AppliedMicro X-Gene SoC SATA Host Controller Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Loc Ho <lho@apm.com>
+ * Tuan Phan <tphan@apm.com>
+ * Suman Tripathi <stripathi@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/ahci_platform.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/phy/phy.h>
+#include "ahci.h"
+
+/* Controller who PHY shared with SGMII Ethernet PHY */
+#define XGENE_AHCI_SGMII_DTS "apm,xgene-ahci-sgmii"
+
+/* Controller who PHY (internal reference clock macro) shared with PCIe */
+#define XGENE_AHCI_PCIE_DTS "apm,xgene-ahci-pcie"
+
+/* Max # of disk per a controller */
+#define MAX_AHCI_CHN_PERCTR 2
+
+#define SATA_ENET_MUX_OFFSET 0x00007000
+#define SATA_DIAG_OFFSET 0x0000D000
+#define SATA_GLB_OFFSET 0x0000D850
+#define SATA_SHIM_OFFSET 0x0000E000
+#define SATA_MASTER_OFFSET 0x0000F000
+#define SATA_PORT0_OFFSET 0x00000100
+#define SATA_PORT1_OFFSET 0x00000180
+
+/* MUX CSR */
+#define SATA_ENET_CONFIG_REG 0x00000000
+#define CFG_SATA_ENET_SELECT_MASK 0x00000001
+
+/* SATA host controller CSR */
+#define SLVRDERRATTRIBUTES 0x00000000
+#define SLVWRERRATTRIBUTES 0x00000004
+#define MSTRDERRATTRIBUTES 0x00000008
+#define MSTWRERRATTRIBUTES 0x0000000c
+#define BUSCTLREG 0x00000014
+#define IOFMSTRWAUX 0x00000018
+#define INTSTATUSMASK 0x0000002c
+#define ERRINTSTATUS 0x00000030
+#define ERRINTSTATUSMASK 0x00000034
+
+/* SATA host AHCI CSR */
+#define PORTCFG 0x000000a4
+#define PORTADDR_SET(dst, src) \
+ (((dst) & ~0x0000003f) | (((u32)(src)) & 0x0000003f))
+#define PORTPHY1CFG 0x000000a8
+#define PORTPHY1CFG_FRCPHYRDY_SET(dst, src) \
+ (((dst) & ~0x00100000) | (((u32)(src) << 0x14) & 0x00100000))
+#define PORTPHY2CFG 0x000000ac
+#define PORTPHY3CFG 0x000000b0
+#define PORTPHY4CFG 0x000000b4
+#define PORTPHY5CFG 0x000000b8
+#define SCTL0 0x0000012C
+#define PORTPHY5CFG_RTCHG_SET(dst, src) \
+ (((dst) & ~0xfff00000) | (((u32)(src) << 0x14) & 0xfff00000))
+#define PORTAXICFG_EN_CONTEXT_SET(dst, src) \
+ (((dst) & ~0x01000000) | (((u32)(src) << 0x18) & 0x01000000))
+#define PORTAXICFG 0x000000bc
+#define PORTAXICFG_OUTTRANS_SET(dst, src) \
+ (((dst) & ~0x00f00000) | (((u32)(src) << 0x14) & 0x00f00000))
+
+/* SATA host controller slave CSR */
+#define INT_SLV_TMOMASK 0x00000010
+
+/* SATA global diagnostic CSR */
+#define CFG_MEM_RAM_SHUTDOWN 0x00000070
+#define BLOCK_MEM_RDY 0x00000074
+
+#define pdata_to_ctx(x) container_of(x, struct xgene_ahci_context, plat_data)
+
+struct xgene_ahci_context {
+ struct ahci_platform_data plat_data;
+ struct ahci_host_priv *hpriv;
+ struct device *dev;
+ void __iomem *csr_base; /* CSR base address of IP */
+ struct phy *phy;
+};
+
+static int xgene_ahci_init_memram(struct xgene_ahci_context *ctx)
+{
+ void __iomem *diagcsr = ctx->csr_base + SATA_DIAG_OFFSET;
+ int try;
+ u32 val;
+
+ val = readl(diagcsr + CFG_MEM_RAM_SHUTDOWN);
+ if (val == 0) {
+ dev_dbg(ctx->dev, "memory already released from shutdown\n");
+ return 0;
+ }
+ dev_dbg(ctx->dev, "Release memory from shutdown\n");
+ /* SATA controller memory in shutdown. Remove from shutdown. */
+ writel(0x0, diagcsr + CFG_MEM_RAM_SHUTDOWN);
+ readl(diagcsr + CFG_MEM_RAM_SHUTDOWN); /* Force a barrier */
+
+ /* Check for at least ~1ms */
+ try = 1000;
+ do {
+ val = readl(diagcsr + BLOCK_MEM_RDY);
+ if (val != 0xFFFFFFFF)
+ usleep_range(1, 100);
+ } while (val != 0xFFFFFFFF && try-- > 0);
+ if (try <= 0) {
+ dev_err(ctx->dev, "failed to release memory from shutdown\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
+/**
+ * Custom Query ID command
+ *
+ * Due to HW errata, we must stop and re-start the port state machine after
+ * read ID command. Also disable support for DEVSLP as hardware don't support
+ * it.
+ */
+static unsigned int xgene_ahci_read_id(struct ata_device *dev,
+ struct ata_taskfile *tf, u16 *id)
+{
+ u32 err_mask;
+ void __iomem *port_mmio = ahci_port_base(dev->link->ap);
+
+ err_mask = ata_do_dev_read_id(dev, tf, id);
+ if (err_mask)
+ return err_mask;
+
+ /*
+ * Mask reserved area. Bit78 spec of Link Power Management
+ * bit15-8: reserved
+ * bit7: NCQ autosence
+ * bit6: Software settings preservation supported
+ * bit5: reserved
+ * bit4: In-order sata delivery supported
+ * bit3: DIPM requests supported
+ * bit2: DMA Setup FIS Auto-Activate optimization supported
+ * bit1: DMA Setup FIX non-Zero buffer offsets supported
+ * bit0: Reserved
+ *
+ * Clear reserved bit (DEVSLP bit) as we don't support DEVSLP
+ */
+ id[78] &= 0x00FF;
+
+ /* Restart the port if required due to HW errata */
+ if (!readl(port_mmio + PORT_CMD_ISSUE)) {
+ writel(PORT_CMD_FIS_RX, port_mmio + PORT_CMD);
+ readl(port_mmio + PORT_CMD); /* Force a barrier */
+ writel(PORT_CMD_FIS_RX | PORT_CMD_START, port_mmio + PORT_CMD);
+ readl(port_mmio + PORT_CMD); /* Force a barrier */
+ }
+ return 0;
+}
+
+static void xgene_ahci_force_phy_rdy(struct xgene_ahci_context *ctx,
+ int channel, int force)
+{
+ void __iomem *mmio = ctx->hpriv->mmio;
+ u32 val;
+
+ val = readl(mmio + PORTCFG);
+ val = PORTADDR_SET(val, channel == 0 ? 2 : 3);
+ writel(val, mmio + PORTCFG);
+ readl(mmio + PORTCFG); /* Force a barrier */
+ val = readl(mmio + PORTPHY1CFG);
+ val = PORTPHY1CFG_FRCPHYRDY_SET(val, force);
+ writel(val, mmio + PORTPHY1CFG);
+}
+
+static void xgene_ahci_set_phy_cfg(struct xgene_ahci_context *ctx, int channel)
+{
+ void __iomem *mmio = ctx->hpriv->mmio;
+ u32 val;
+
+ dev_dbg(ctx->dev, "port configure mmio 0x%p channel %d\n",
+ mmio, channel);
+ val = readl(mmio + PORTCFG);
+ val = PORTADDR_SET(val, channel == 0 ? 2 : 3);
+ writel(val, mmio + PORTCFG);
+ readl(mmio + PORTCFG); /* Force a barrier */
+ /* Disable fix rate */
+ writel(0x0001fffe, mmio + PORTPHY1CFG);
+ readl(mmio + PORTPHY1CFG); /* Force a barrier */
+ writel(0x5018461c, mmio + PORTPHY2CFG);
+ readl(mmio + PORTPHY2CFG); /* Force a barrier */
+ writel(0x1c081907, mmio + PORTPHY3CFG);
+ readl(mmio + PORTPHY3CFG); /* Force a barrier */
+ writel(0x1c080815, mmio + PORTPHY4CFG);
+ readl(mmio + PORTPHY4CFG); /* Force a barrier */
+ /* Set window negotiation */
+ val = readl(mmio + PORTPHY5CFG);
+ val = PORTPHY5CFG_RTCHG_SET(val, 0x300);
+ writel(val, mmio + PORTPHY5CFG);
+ readl(mmio + PORTPHY5CFG); /* Force a barrier */
+ val = readl(mmio + PORTAXICFG);
+ val = PORTAXICFG_EN_CONTEXT_SET(val, 0x1); /* Enable context mgmt */
+ val = PORTAXICFG_OUTTRANS_SET(val, 0xe); /* Set outstanding */
+ writel(val, mmio + PORTAXICFG);
+ readl(mmio + PORTAXICFG); /* Force a barrier */
+}
+
+static int xgene_ahci_phy_restart(struct ata_link *link)
+{
+ struct ata_port *port = link->ap;
+ struct ahci_host_priv *hpriv = port->host->private_data;
+ struct xgene_ahci_context *ctx = pdata_to_ctx(hpriv->plat_data);
+
+ xgene_ahci_force_phy_rdy(ctx, port->port_no, 1);
+ xgene_ahci_force_phy_rdy(ctx, port->port_no, 0);
+ return 0;
+}
+
+static int xgene_ahci_do_hardreset(struct ata_link *link,
+ unsigned long deadline, bool *online)
+{
+ const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
+ struct ata_port *ap = link->ap;
+ struct ahci_host_priv *hpriv = ap->host->private_data;
+ struct xgene_ahci_context *ctx = pdata_to_ctx(hpriv->plat_data);
+ struct ahci_port_priv *pp = ap->private_data;
+ u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+ void __iomem *port_mmio = ahci_port_base(ap);
+ struct ata_taskfile tf;
+ int first_time = 1;
+ int rc;
+ u32 val;
+ int i;
+
+hardreset_retry:
+ /* clear D2H reception area to properly wait for D2H FIS */
+ ata_tf_init(link->device, &tf);
+ tf.command = ATA_BUSY;
+ ata_tf_to_fis(&tf, 0, 0, d2h_fis);
+ rc = sata_link_hardreset(link, timing, deadline, online,
+ ahci_check_ready);
+
+ if (*online) {
+ /* Check to ensure that the disk comes up in matching speed */
+ if (first_time) {
+ u32 gen_speed;
+
+ first_time = 0;
+ sata_scr_read(link, SCR_STATUS, &gen_speed);
+ gen_speed = (gen_speed >> 4) & 0xf;
+ if (gen_speed == 1 || gen_speed == 2) {
+ /*
+ * For Gen2/1 and first time, let's check again
+ * with Gen2/1 PHY to ensure actual Gen2/1 disk.
+ */
+ phy_set_speed(ctx->phy, ap->port_no,
+ gen_speed == 2 ? 3000000000ULL :
+ 1500000000ULL);
+ xgene_ahci_phy_restart(link);
+ goto hardreset_retry;
+ }
+ }
+
+ /* Clear SER_DISPARITY/SER_10B_8B_ERR if set due to errata */
+ for (i = 0; i < 5; i++) {
+ /* Check if error bit set */
+ val = readl(port_mmio + PORT_SCR_ERR);
+ if (!(val & (SERR_DISPARITY | SERR_10B_8B_ERR)))
+ break;
+ /* Clear any error due to errata */
+ xgene_ahci_force_phy_rdy(ctx, ap->port_no, 1);
+ /* Reset the PHY Rx path */
+ phy_set_speed(ctx->phy, ap->port_no, 0);
+ xgene_ahci_force_phy_rdy(ctx, ap->port_no, 0);
+ /* Clear all errors */
+ val = readl(port_mmio + PORT_SCR_ERR);
+ writel(val, port_mmio + PORT_SCR_ERR);
+ }
+ }
+
+ /* clear all errors if any pending */
+ val = readl(port_mmio + PORT_SCR_ERR);
+ writel(val, port_mmio + PORT_SCR_ERR);
+
+ return rc;
+}
+
+static int xgene_ahci_hardreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ struct ata_port *ap = link->ap;
+ struct ahci_host_priv *hpriv = ap->host->private_data;
+ void __iomem *port_mmio = ahci_port_base(ap);
+ bool online;
+ int rc;
+ int portcmd_saved;
+ u32 portclb_saved;
+ u32 portclbhi_saved;
+ u32 portrxfis_saved;
+ u32 portrxfishi_saved;
+
+ /* As hardreset reset these CSR, let save it to restore later */
+ portcmd_saved = readl(port_mmio + PORT_CMD);
+ portclb_saved = readl(port_mmio + PORT_LST_ADDR);
+ portclbhi_saved = readl(port_mmio + PORT_LST_ADDR_HI);
+ portrxfis_saved = readl(port_mmio + PORT_FIS_ADDR);
+ portrxfishi_saved = readl(port_mmio + PORT_FIS_ADDR_HI);
+
+ ahci_stop_engine(ap);
+
+ rc = xgene_ahci_do_hardreset(link, deadline, &online);
+
+ /* As controller hardreset clear them, let restore them */
+ writel(portcmd_saved, port_mmio + PORT_CMD);
+ writel(portclb_saved, port_mmio + PORT_LST_ADDR);
+ writel(portclbhi_saved, port_mmio + PORT_LST_ADDR_HI);
+ writel(portrxfis_saved, port_mmio + PORT_FIS_ADDR);
+ writel(portrxfishi_saved, port_mmio + PORT_FIS_ADDR_HI);
+
+ hpriv->start_engine(ap);
+
+ if (online)
+ *class = ahci_dev_classify(ap);
+
+ return rc;
+}
+
+static struct ata_port_operations xgene_ahci_ops = {
+ .inherits = &ahci_ops,
+ .hardreset = xgene_ahci_hardreset,
+ .read_id = xgene_ahci_read_id,
+};
+
+static const struct ata_port_info xgene_ahci_port_info = {
+ AHCI_HFLAGS(AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ),
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &xgene_ahci_ops,
+};
+
+static int xgene_ahci_hw_init(struct ahci_host_priv *hpriv)
+{
+ struct xgene_ahci_context *ctx = pdata_to_ctx(hpriv->plat_data);
+ int i;
+ int rc;
+ u32 val;
+
+ /* Remove IP RAM out of shutdown */
+ rc = xgene_ahci_init_memram(ctx);
+ if (rc)
+ return rc;
+
+ for (i = 0; i < MAX_AHCI_CHN_PERCTR; i++)
+ xgene_ahci_set_phy_cfg(ctx, i);
+
+ /* AXI disable Mask */
+ writel(0xffffffff, hpriv->mmio + HOST_IRQ_STAT);
+ readl(hpriv->mmio + HOST_IRQ_STAT); /* Force a barrier */
+ writel(0, ctx->csr_base + INTSTATUSMASK);
+ readl(ctx->csr_base + INTSTATUSMASK); /* Force a barrier */
+ dev_dbg(ctx->dev, "top level interrupt mask 0x%X value 0x%08X\n",
+ INTSTATUSMASK, val);
+
+ writel(0x0, ctx->csr_base + ERRINTSTATUSMASK);
+ readl(ctx->csr_base + ERRINTSTATUSMASK); /* Force a barrier */
+ writel(0x0, ctx->csr_base + SATA_SHIM_OFFSET + INT_SLV_TMOMASK);
+ readl(ctx->csr_base + SATA_SHIM_OFFSET + INT_SLV_TMOMASK);
+
+ /* Enable AXI Interrupt */
+ writel(0xffffffff, ctx->csr_base + SLVRDERRATTRIBUTES);
+ writel(0xffffffff, ctx->csr_base + SLVWRERRATTRIBUTES);
+ writel(0xffffffff, ctx->csr_base + MSTRDERRATTRIBUTES);
+ writel(0xffffffff, ctx->csr_base + MSTWRERRATTRIBUTES);
+
+ /* Enable coherency */
+ val = readl(ctx->csr_base + BUSCTLREG);
+ val &= ~0x00000002; /* Enable write coherency */
+ val &= ~0x00000001; /* Enable read coherency */
+ writel(val, ctx->csr_base + BUSCTLREG);
+
+ val = readl(ctx->csr_base + IOFMSTRWAUX);
+ val |= (1 << 3); /* Enable read coherency */
+ val |= (1 << 9); /* Enable write coherency */
+ writel(val, ctx->csr_base + IOFMSTRWAUX);
+ val = readl(ctx->csr_base + IOFMSTRWAUX);
+ dev_dbg(ctx->dev, "coherency 0x%X value 0x%08X\n",
+ IOFMSTRWAUX, val);
+
+ return rc;
+}
+
+static int xgene_ahci_mux_select(struct xgene_ahci_context *ctx)
+{
+ void *mux_csr = ctx->csr_base + SATA_ENET_MUX_OFFSET;
+ u32 val;
+
+ val = readl(mux_csr + SATA_ENET_CONFIG_REG);
+ val &= ~CFG_SATA_ENET_SELECT_MASK;
+ writel(val, mux_csr + SATA_ENET_CONFIG_REG);
+ val = readl(mux_csr + SATA_ENET_CONFIG_REG);
+ return val & CFG_SATA_ENET_SELECT_MASK ? -1 : 0;
+}
+
+static int xgene_ahci_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ahci_host_priv *hpriv;
+ struct xgene_ahci_context *hplat_data;
+ struct resource *res;
+ int rc;
+
+ hpriv = ahci_platform_get_resources(pdev);
+ if (IS_ERR(hpriv))
+ return PTR_ERR(hpriv);
+
+ hplat_data = devm_kzalloc(dev, sizeof(*hplat_data), GFP_KERNEL);
+ if (!hplat_data) {
+ dev_err(dev, "can't allocate host context\n");
+ return -ENOMEM;
+ }
+ hpriv->plat_data = hplat_data;
+ hplat_data->hpriv = hpriv;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ dev_err(dev, "no csr space\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Can't use devm_ioremap_resource due to overlapping region.
+ * 0xYYYY.0000 - host core
+ * 0xYYYY.7000 - Mux (if applicable)
+ * 0xYYYY.A000 - PHY indirect access
+ * 0xYYYY.C000 - Clock
+ * 0xYYYY.D000 - RAM shutdown removal
+ * As we map the entire region as one, it overlaps with the PHY driver.
+ */
+ hplat_data->csr_base = devm_ioremap(dev, res->start,
+ resource_size(res));
+ if (!hplat_data->csr_base) {
+ dev_err(dev, "can't map %pR\n", res);
+ return -ENOMEM;
+ }
+
+ dev_dbg(dev, "VAddr 0x%p Mmio VAddr 0x%p\n", hplat_data->csr_base,
+ hpriv->mmio);
+
+ /* Select ATA */
+ if (of_device_is_compatible(pdev->dev.of_node,
+ XGENE_AHCI_SGMII_DTS)) {
+ if (xgene_ahci_mux_select(hplat_data)) {
+ dev_err(dev, "SATA mux selection failed\n");
+ return -ENODEV;
+ }
+ }
+
+ rc = ahci_platform_enable_resources(hpriv);
+ if (rc)
+ goto put_resources;
+
+ /* HW requires toggle of the clock */
+ ahci_platform_disable_clks(hpriv);
+ rc = ahci_platform_enable_clks(hpriv);
+ if (rc)
+ goto put_resources;
+
+ /* Configure the PHY */
+ hplat_data->phy = devm_phy_get(dev, "sata-6g");
+ if (!hplat_data->phy) {
+ dev_err(dev, "no PHY available\n");
+ rc = -ENODEV;
+ goto disable_resources;
+ }
+
+ rc = phy_init(hplat_data->phy);
+ if (rc) {
+ dev_err(dev, "PHY initialize failed %d\n", rc);
+ goto disable_resources;
+ }
+
+ /* Configure the host controller */
+ xgene_ahci_hw_init(hpriv);
+
+ /* Setup DMA mask - 32 for 32-bit system and 64 for 64-bit system */
+ rc = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(8*sizeof(void *)));
+ if (rc) {
+ dev_err(dev, "Unable to set dma mask\n");
+ goto disable_resources;
+ }
+
+ rc = ahci_platform_init_host(pdev, hpriv, &xgene_ahci_port_info, 0, 0);
+ if (rc)
+ goto disable_resources;
+
+ dev_dbg(dev, "X-Gene SATA host controller initialized\n");
+ return 0;
+
+disable_resources:
+ ahci_platform_disable_resources(hpriv);
+put_resources:
+ ahci_platform_put_resources(hpriv);
+ return rc;
+}
+
+static const struct of_device_id xgene_ahci_of_match[] = {
+ {.compatible = XGENE_AHCI_SGMII_DTS,},
+ {.compatible = XGENE_AHCI_PCIE_DTS,},
+ {},
+};
+MODULE_DEVICE_TABLE(of, xgene_ahci_of_match);
+
+static struct platform_driver xgene_ahci_driver = {
+ .driver = {
+ .name = "xgene-ahci",
+ .owner = THIS_MODULE,
+ .of_match_table = xgene_ahci_of_match,
+ },
+ .probe = xgene_ahci_probe,
+};
+
+module_platform_driver(xgene_ahci_driver);
+
+MODULE_DESCRIPTION("APM X-Gene AHCI SATA driver");
+MODULE_AUTHOR("Loc Ho <lho@apm.com>");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("0.4");
--
1.5.5
^ permalink raw reply related
* [PATCH v12 3/3] arm64: Add APM X-Gene SoC AHCI SATA host controller DTS entries
From: Loc Ho @ 2014-02-21 17:47 UTC (permalink / raw)
To: olof, tj, arnd
Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, ddutile, jcm,
patches, Loc Ho, Tuan Phan, Suman Tripathi
In-Reply-To: <1393004853-25994-3-git-send-email-lho@apm.com>
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
arch/arm64/boot/dts/apm-storm.dtsi | 75 ++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index c78ddcf..57b0770 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -221,6 +221,48 @@
enable-offset = <0x0>;
enable-mask = <0x06>;
};
+
+ sata01clk: sata01clk@1f21c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f21c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sata01clk";
+ csr-offset = <0x4>;
+ csr-mask = <0x05>;
+ enable-offset = <0x0>;
+ enable-mask = <0x39>;
+ };
+
+ sata23clk: sata23clk@1f22c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f22c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sata23clk";
+ csr-offset = <0x4>;
+ csr-mask = <0x05>;
+ enable-offset = <0x0>;
+ enable-mask = <0x39>;
+ };
+
+ sata45clk: sata45clk@1f23c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f23c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sata45clk";
+ csr-offset = <0x4>;
+ csr-mask = <0x05>;
+ enable-offset = <0x0>;
+ enable-mask = <0x39>;
+ };
};
serial0: serial@1c020000 {
@@ -262,5 +304,38 @@
apm,tx-boost-gain = <31 31 31 31 31 31>;
apm,tx-eye-tuning = <2 10 10 2 10 10>;
};
+
+ sata1: sata@1a000000 {
+ compatible = "apm,xgene-ahci-sgmii";
+ reg = <0x0 0x1a000000 0x0 0x1000>,
+ <0x0 0x1f210000 0x0 0x10000>;
+ interrupts = <0x0 0x86 0x4>;
+ status = "disabled";
+ clocks = <&sata01clk 0>;
+ phys = <&phy1 0>;
+ phy-names = "sata-6g";
+ };
+
+ sata2: sata@1a400000 {
+ compatible = "apm,xgene-ahci-sgmii";
+ reg = <0x0 0x1a400000 0x0 0x1000>,
+ <0x0 0x1f220000 0x0 0x10000>;
+ interrupts = <0x0 0x87 0x4>;
+ status = "ok";
+ clocks = <&sata23clk 0>;
+ phys = <&phy2 0>;
+ phy-names = "sata-6g";
+ };
+
+ sata3: sata@1a800000 {
+ compatible = "apm,xgene-ahci-pcie";
+ reg = <0x0 0x1a800000 0x0 0x1000>,
+ <0x0 0x1f230000 0x0 0x10000>;
+ interrupts = <0x0 0x88 0x4>;
+ status = "ok";
+ clocks = <&sata45clk 0>;
+ phys = <&phy3 0>;
+ phy-names = "sata-6g";
+ };
};
};
--
1.5.5
^ permalink raw reply related
* Re: [PATCH v4 02/10] Documentation: dt: Add DT binding documentation for S5C73M3 camera
From: Sylwester Nawrocki @ 2014-02-21 17:52 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org,
galak@codeaurora.org, kyungmin.park@samsung.com,
kgene.kim@samsung.com, a.hajda@samsung.com
In-Reply-To: <20140221154240.GE20449@e106331-lin.cambridge.arm.com>
On 21/02/14 16:42, Mark Rutland wrote:
[...]
>> +++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
>> @@ -0,0 +1,97 @@
>> +Samsung S5C73M3 8Mp camera ISP
>> +------------------------------
>> +
>> +The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video
>> +data busses. The I2C bus is the main control bus and additionally the SPI bus
>> +is used, mostly for transferring the firmware to and from the device. Two
>> +slave device nodes corresponding to these control bus interfaces are required
>> +and should be placed under respective bus controller nodes.
>
> So this has both an I2C interface and an SPI interface that are used at
> the same time?
Yes, both are needed. AFAIU SPI is added so the firmware upload is faster.
>> +I2C slave device node
>> +---------------------
>> +
>> +Required properties:
>> +
>> +- compatible : "samsung,s5c73m3";
>> +- reg : I2C slave address of the sensor;
>> +- vdd-int-supply : digital power supply (1.2V);
>> +- vdda-supply : analog power supply (1.2V);
>> +- vdd-reg-supply : regulator input power supply (2.8V);
>> +- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
>> +- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V);
>> +- vdd-af-supply : lens power supply (2.8V);
>> +- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin;
>> +- standby-gpios : specifier of GPIO connected to the STANDBY pin;
>> +- clocks : should contain list of phandle and clock specifier pairs
>> + according to common clock bindings for the clocks described
>> + in the clock-names property;
>> +- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock;
>> +
>> +Optional properties:
>> +
>> +- clock-frequency : the frequency at which the "cis_extclk" clock should be
>> + configured to operate, in Hz; if this property is not
>> + specified default 24 MHz value will be used.
>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be used
>> +to specify link from the S5C73M3 to an external image data receiver. The S5C73M3
>> +device node should contain one 'port' child node with an 'endpoint' subnode for
>> +this purpose. The data link from a raw image sensor to the S5C73M3 can be
>> +similarly specified, but it is optional since the S5C73M3 ISP and a raw image
>> +sensor are usually inseparable and form a hybrid module.
>> +
>> +Following properties are valid for the endpoint node(s):
>> +
>> +endpoint subnode
>> +----------------
>> +
>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>> + video-interfaces.txt. This sensor doesn't support data lane remapping
>> + and physical lane indexes in subsequent elements of the array should
>> + be only consecutive ascending values.
>> +
>> +SPI device node
>> +---------------
>> +
>> +Required properties:
>> +
>> +- compatible : "samsung,s5c73m3";
>
> It might make sense to explicitly link these two nodes somehow, in case
> multiple instances appear somewhere. However, that can come later in the
> case of a multi-instance device, and isn't necessary now.
I guess a phandle at the I2C slave device node, pointing to the SPI node
and/or the other way around would do. I don't expect these devices to be
used in multiple instances though and would prefer to address that when
necessary.
We could try and create a root node for this device with an interesting
structure, if we wanted to go much into details. But it could get a bit
complicated given the scheme the I2C/SPI bus binding are structured now.
Presumably that's something that could be handled later with a different
compatible string if required.
>> +For more details see description of the SPI busses bindings
>> +(../spi/spi-bus.txt) and bindings of a specific bus controller.
>> +
>> +Example:
>> +
>> +i2c@138A000000 {
>> + ...
>> + s5c73m3@3c {
>> + compatible = "samsung,s5c73m3";
>> + reg = <0x3c>;
>> + vdd-int-supply = <&buck9_reg>;
>> + vdda-supply = <&ldo17_reg>;
>> + vdd-reg-supply = <&cam_io_reg>;
>> + vddio-host-supply = <&ldo18_reg>;
>> + vddio-cis-supply = <&ldo9_reg>;
>> + vdd-af-supply = <&cam_af_reg>;
>> + clock-frequency = <24000000>;
>> + clocks = <&clk 0>;
>> + clock-names = "cis_extclk";
>> + reset-gpios = <&gpf1 3 1>;
>> + standby-gpios = <&gpm0 1 1>;
>> + port {
>> + s5c73m3_ep: endpoint {
>> + remote-endpoint = <&csis0_ep>;
>> + data-lanes = <1 2 3 4>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +spi@1392000 {
>> + ...
>> + s5c73m3_spi: s5c73m3 {
>
> Nit: this should have a 0 unit-address to match the reg.
OK, I'll correct that.
>> + compatible = "samsung,s5c73m3";
>> + reg = <0>;
>> + ...
>> + };
>> +};
>
> Otherwise I don't see anything problematic about the binding.
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks for the review.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH v12 2/3] ata: Add APM X-Gene SoC AHCI SATA host controller driver
From: Tejun Heo @ 2014-02-21 17:55 UTC (permalink / raw)
To: Loc Ho
Cc: olof, arnd, linux-scsi, linux-ide, devicetree, linux-arm-kernel,
ddutile, jcm, patches, Tuan Phan, Suman Tripathi
In-Reply-To: <1393004853-25994-3-git-send-email-lho@apm.com>
Hello, Loc.
On Fri, Feb 21, 2014 at 10:47:32AM -0700, Loc Ho wrote:
> +/**
> + * Custom Query ID command
> + *
> + * Due to HW errata, we must stop and re-start the port state machine after
> + * read ID command. Also disable support for DEVSLP as hardware don't support
> + * it.
> + */
Sorry about not being clear before but /** function comment means
something like
/**
* ata_scsi_port_error_handler - recover the port after the commands
* @host: SCSI host containing the port
* @ap: the ATA port
*
* Handle the recovery of the port @ap after all the commands have
* been recovered.
*/
> +static int xgene_ahci_do_hardreset(struct ata_link *link,
> + unsigned long deadline, bool *online)
> +{
> + const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
> + struct ata_port *ap = link->ap;
> + struct ahci_host_priv *hpriv = ap->host->private_data;
> + struct xgene_ahci_context *ctx = pdata_to_ctx(hpriv->plat_data);
> + struct ahci_port_priv *pp = ap->private_data;
> + u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
> + void __iomem *port_mmio = ahci_port_base(ap);
> + struct ata_taskfile tf;
> + int first_time = 1;
> + int rc;
> + u32 val;
> + int i;
> +
> +hardreset_retry:
> + /* clear D2H reception area to properly wait for D2H FIS */
> + ata_tf_init(link->device, &tf);
> + tf.command = ATA_BUSY;
> + ata_tf_to_fis(&tf, 0, 0, d2h_fis);
> + rc = sata_link_hardreset(link, timing, deadline, online,
> + ahci_check_ready);
> +
> + if (*online) {
> + /* Check to ensure that the disk comes up in matching speed */
> + if (first_time) {
> + u32 gen_speed;
> +
> + first_time = 0;
> + sata_scr_read(link, SCR_STATUS, &gen_speed);
> + gen_speed = (gen_speed >> 4) & 0xf;
> + if (gen_speed == 1 || gen_speed == 2) {
> + /*
> + * For Gen2/1 and first time, let's check again
> + * with Gen2/1 PHY to ensure actual Gen2/1 disk.
> + */
Can you please go back two reviews and re-read what I requested?
Also, if you're unsure, please don't hesitate to ask back. It's
usually a lot easier for both parties than iterating through patchsets
without properly understanding each other.
Thanks.
--
tejun
^ permalink raw reply
* Re: SPDX-License-Identifier
From: Greg Kroah-Hartman @ 2014-02-21 17:57 UTC (permalink / raw)
To: Michal Simek
Cc: Felipe Balbi, Subbaraya Sundeep Bhatta,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Subbaraya Sundeep Bhatta,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wolfgang Denk
In-Reply-To: <53078C30.7060703-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
On Fri, Feb 21, 2014 at 06:26:08PM +0100, Michal Simek wrote:
> On 02/21/2014 05:56 PM, Greg Kroah-Hartman wrote:
> > On Fri, Feb 21, 2014 at 10:20:45AM -0600, Felipe Balbi wrote:
> >> Hi,
> >>
> >> On Fri, Feb 21, 2014 at 05:18:39PM +0100, Michal Simek wrote:
> >>> On 02/21/2014 05:12 PM, Felipe Balbi wrote:
> >>>> On Fri, Feb 21, 2014 at 05:04:26PM +0100, Michal Simek wrote:
> >>>>> On 02/21/2014 05:04 PM, Greg Kroah-Hartman wrote:
> >>>>>> On Fri, Feb 21, 2014 at 07:38:16AM +0100, Michal Simek wrote:
> >>>>>>> BTW: u-boot started to use SPDX-License-Identifier
> >>>>>>> which will be nice to start to use.
> >>>>>>
> >>>>>> I agree, feel free to start sending patches to use this type of
> >>>>>> identifier for drivers.
> >>>>>
> >>>>> But we probably need to add that Licenses to one location.
> >>>>> Documentation/Licenses?
> >>>>
> >>>> Just add to the drivers themselves, just like u-boot is doing. A simple:
> >>>>
> >>>> $ git grep -e SPDX-License-Identifier
> >>>>
> >>>> will tell you filename and license. Or did I misunderstand your question ?
> >>>
> >>> But for doing this it is probably necessary to have location where
> >>> you will place that licenses and you will explain what it is how
> >>> it is done by Wolfgang in this commit.
> >>>
> >>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=eca3aeb352c964bdb28b8e191d6326370245e03f
> >>>
> >>> Then yes, adding one line is enough.
> >>
> >> spdx.org has all licenses, why don't we just rely on that instead of
> >> adding every other license to the kernel source ?
> >
> > Yes, all that will be acceptable is a one-line identifier in the file.
> > No need to have all the different licenses in the kernel source, that's
> > crazy and not needed at all.
> >
> > I've told the SPDX people this in the past, and they keep promising that
> > they will do the comment work, but it's been months and I have yet to
> > see a single patch...
>
> But shouldn't we at least write somewhere
> that it has connection to spdx.org where you can find out that licenses.
Why? Are these licenses so unknown that no one knows what they are?
And, as part of the kernel-as-a-whole-work, they all resolve to GPLv2
anyway, and we have that license in the source tree, so nothing else
should be needed.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 17/18] ARM: sun4i: dt: Add ahci / sata support
From: Maxime Ripard @ 2014-02-21 18:15 UTC (permalink / raw)
To: Hans de Goede
Cc: Tejun Heo, Oliver Schinagl, Richard Zhu, Roger Quadros, Lee Jones,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1392811320-3132-18-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]
Hi Hans,
On Wed, Feb 19, 2014 at 01:01:59PM +0100, Hans de Goede wrote:
> From: Oliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
>
> This patch adds sunxi sata support to A10 boards that have such a connector.
> Some boards also feature a regulator via a GPIO and support for this is also
> added.
>
> Signed-off-by: Olliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/sun4i-a10-a1000.dts | 4 ++++
> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +++++
> arch/arm/boot/dts/sun4i-a10.dtsi | 8 +++++++
> arch/arm/boot/dts/sunxi-ahci-reg.dtsi | 36 ++++++++++++++++++++++++++++++
> 4 files changed, 54 insertions(+)
> create mode 100644 arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> index cbd2e13..d6ec839 100644
> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> @@ -35,6 +35,10 @@
> };
> };
>
> + ahci: sata@01c18000 {
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> emac_power_pin_a1000: emac_power_pin@0 {
> allwinner,pins = "PH15";
> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> index b139ee6..6df237d8 100644
> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> @@ -12,6 +12,7 @@
>
> /dts-v1/;
> /include/ "sun4i-a10.dtsi"
> +/include/ "sunxi-ahci-reg.dtsi"
>
> / {
> model = "Cubietech Cubieboard";
> @@ -33,6 +34,11 @@
> };
> };
>
> + ahci: sata@01c18000 {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> led_pins_cubieboard: led_pins@0 {
> allwinner,pins = "PH20", "PH21";
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 336dbec..454077a 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -338,6 +338,14 @@
> #size-cells = <0>;
> };
>
> + ahci: sata@01c18000 {
> + compatible = "allwinner,sun4i-a10-ahci";
> + reg = <0x01c18000 0x1000>;
> + interrupts = <56>;
> + clocks = <&pll6 0>, <&ahb_gates 25>;
> + status = "disabled";
> + };
> +
> intc: interrupt-controller@01c20400 {
> compatible = "allwinner,sun4i-ic";
> reg = <0x01c20400 0x400>;
> diff --git a/arch/arm/boot/dts/sunxi-ahci-reg.dtsi b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> new file mode 100644
> index 0000000..7072af1
> --- /dev/null
> +++ b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> @@ -0,0 +1,36 @@
> +/*
> + * sunxi boards sata target power supply common code
Since IIRC we have pretty much the same needs for the USB, can't we
just drop the SATA specific mention and use it as the common DTSI for
the usual regulators?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-21 18:22 UTC (permalink / raw)
To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w
Cc: Grant Likely, Sascha Hauer, Tim Bird, Olof Johansson,
Jason Cooper, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <53058B69.4040502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Feb 19, 2014, at 9:58 PM, Frank Rowand wrote:
> On 2/19/2014 1:15 PM, Grant Likely wrote:
>> On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 2/19/2014 1:08 AM, Sascha Hauer wrote:
>>>> On Tue, Feb 18, 2014 at 02:44:15PM -0800, Tim Bird wrote:
>>>>> I'm not in favor of separating the device tree information from the kernel.
>>>>>
>>>>> If we switch, then whatever synchronization issues other projects
>>>>> are having now with synching with the device tree info from the kernel will
>>>>> just then become the problem of the kernel developers, who will then
>>>>> have to sync with the device tree info from another repository. If the
>>>>> sync issues can't be solved now for them, why or how would it be solved
>>>>> post-separation for us? (It sounds like a zero-sum game of pain transfer
>>>>> to me.)
>>>>>
>>>>> I'm relatively unfamiliar with the arguments. Can someone provide
>>>>> a brief list of reasons this is needed, and how the inconvenience to Linux
>>>>> kernel developers will be minimized, should it proceed?
>>>>
>>>
>>>
>>>> One of the reasons for doing devicetrees is to separate the hardware
>>>> description from the code so that:
>>>> - Other OSes (and bootloaders) can use the same description to start on
>>>> a given hardware
>>>> - A generic Kernel can be started on any hardware
>>>> - A hardware describes itself, makes itself more introspecitve so we can
>>>> go away from very specialized kernels
>>>
>>> Tim knows this ^^^^. He was asking for the arguments for moving dts files
>>> out of the linux kernel source tree.
>>
>> We've made the decision that devicetree bindings need to be treated as
>> ABI, but as long as the .dts files live in the kernel there will
>> always be the temptation to just tweak things in lock-step and nobody
>> will notice. Splitting the files out gives that extra push to think
>> about whether changes to a binding will backwards compatible with a
>> tree that doesn't have those changes because the chances are a lot
>> higher that someone will hit that combination.
>>
>> The other argument is shared source between
>> BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there
>> is no good way to share the database of hardware descriptions.
>
> We could provide an easy export (see below). What do you think?
So what would the process be to get changes to those files upstream if you did this? It would make it marginally easier to USE, but once disconnected from the git world, a lot harder to track and fix.
Also, you should export the device tree docs too, since they are, in theory, a set. And honestly, the device tree doc files need more work than the .dts and .dtsi files.
Warner
> -Frank
>
>
>
> Proof of concept: export devicetree source and header files
>
> Not-signed-off-by: Frank Rowand <frank.rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
>
>
> ---
> Makefile | 27 26 + 1 - 0 !
> scripts/Makefile.dtsexport | 19 19 + 0 - 0 !
> scripts/dts.sh | 11 11 + 0 - 0 !
> 3 files changed, 56 insertions(+), 1 deletion(-)
>
> Index: b/Makefile
> ===================================================================
> --- a/Makefile
> +++ b/Makefile
> @@ -234,6 +234,9 @@ endif
> # Where to locate arch specific headers
> hdr-arch := $(SRCARCH)
>
> +# Where to locate arch specific dts
> +dts-arch := $(SRCARCH)
> +
> KCONFIG_CONFIG ?= .config
> export KCONFIG_CONFIG
>
> @@ -463,7 +466,7 @@ version_h := include/generated/uapi/linu
> no-dot-config-targets := clean mrproper distclean \
> cscope gtags TAGS tags help %docs check% coccicheck \
> $(version_h) headers_% archheaders archscripts \
> - kernelversion %src-pkg
> + kernelversion %src-pkg dts_export%
>
> config-targets := 0
> mixed-targets := 0
> @@ -933,6 +936,26 @@ firmware_install: FORCE
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
>
> # ---------------------------------------------------------------------------
> +# devicetree source and headers export
> +
> +#Default location for installed headers
> +export EXPORT_DTS_PATH = $(KBUILD_OUTPUT)/usr/dts
> +
> +PHONY += dts_export_headers
> +dts_export_headers: scripts_basic
> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.dtsexport obj=include/dt-bindings
> + @echo $(KERNELRELEASE) >$(EXPORT_DTS_PATH)/linux_version
> +
> +PHONY += dts_export_all
> +dts_export_all: dts_export_headers
> + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/dts.sh
> +
> +PHONY += dts_export
> +dts_export:
> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.dtsexport obj=arch/$(dts-arch)/boot/dts
> +
> +
> +# ---------------------------------------------------------------------------
> # Kernel headers
>
> #Default location for installed headers
> @@ -1160,6 +1183,8 @@ help:
> @echo ' modules_prepare - Set up for building external modules'
> @echo ' tags/TAGS - Generate tags file for editors'
> @echo ' cscope - Generate cscope index'
> + @echo ' dts_export_all - Export devicetree source and headers to EXPORT_DTS_PATH'
> + @echo ' (default: $(EXPORT_DTS_PATH))'
> @echo ' gtags - Generate GNU GLOBAL index'
> @echo ' kernelrelease - Output the release version string'
> @echo ' kernelversion - Output the version stored in Makefile'
> Index: b/scripts/Makefile.dtsexport
> ===================================================================
> --- /dev/null
> +++ b/scripts/Makefile.dtsexport
> @@ -0,0 +1,19 @@
> +# ==========================================================================
> +# Exporting dts source and header files
> +#
> +# ==========================================================================
> +
> +srcpath := $(srctree)/$(obj)/*
> +dstpath := $(EXPORT_DTS_PATH)/$(obj)
> +
> +include scripts/Kbuild.include
> +
> +
> +quiet_cmd_install = EXPORT $(subst $(srctree)/,,$(srcpath))
> + cmd_install = mkdir -p $(dstpath); cp -a $(srcpath) $(dstpath)
> +
> +
> +.PHONY: export
> +export:
> + $(call cmd,install)
> +
> Index: b/scripts/dts.sh
> ===================================================================
> --- /dev/null
> +++ b/scripts/dts.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +# Run dts_export command for all architectures
> +
> +# Stop on error
> +set -e
> +
> +for arch in $(ls ${srctree}/arch); do
> + if [ -d ${srctree}/arch/${arch}/boot/dts ]; then
> + make ARCH=${arch} dts_export
> + fi
> +done
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-21 18:27 UTC (permalink / raw)
To: Grant Likely
Cc: Olof Johansson, Rob Herring, Tim Bird, Jason Cooper, Sascha Hauer,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140220113832.D9E13C4050F-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On Feb 20, 2014, at 4:38 AM, Grant Likely wrote:
> On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> One way to minimize the inconvenience is keep versioning and dev
>>> cycles in sync with the kernel. We could also start doing things to
>>> align the kernel workflow with how things will work when we do have a
>>> separate repository.
>>
>> I don't think aligning development cycles is what we want most here it
>> might be useful for us in Linux but it'll make things difficult for
>> other projects since they're not aware of our release cycles. The
>> device tree bindings and DT contents in that repo should be "always
>> stable", i.e. no merge window / rc concept. As soon as something goes
>> in it's live, and from then out only fixes to the DTS files (or
>> appending the binding).
>>
>> For example, I don't want to have to track two trees to test against
>> -- I'll want to keep one repo of the very latest DT files and always
>> use those to boot any and all boards.
>
> This approach does have the subtle side effect that differs from what we
> discussed in Edinburgh. We've talked about always being able to boot a
> new kernel on an old devicetree, but not a new devicetree on an old
> kernel. With a separate board database repo we are going to hit both
> cases. At least to a limited extent we're going to need older kernels
> booting with the latest devicetree, and we'll need some rules about how
> that gets applied.
I wasn't in Edinburgh... Was this at the binary level or at the source level? I'm thinking specifically about the move to cpp in the back of my mind...
> The alternative is that binding changes land in .dts files after a
> kernel release, and I don't think we want that situation at all.
>
> This is an issue for new bindings, only when a binding is getting
> extended or replaced. If the change is merely adding new properties then
> there shouldn't be a problem (the old kernel will ignore the new
> properties). If it removes properties or creates a new compatible string
> (dropping the one supported by an older kernel) then it won't boot.
Versioning here wouldn't save you either...
> Ultimately this is probably the right thing to do, but it will be
> difficult. Keeping a staging process for new bindings in lock step
> with the kernel is probably the way to mitigate this.
You could have a property like linux,version-min="3.22" if that becomes an issue...
Warner
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-21 18:28 UTC (permalink / raw)
To: Grant Likely
Cc: Jason Cooper, Sascha Hauer, Rob Herring, Ian Campbell,
Paweł Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140220113951.612DDC4050F-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On Feb 20, 2014, at 4:39 AM, Grant Likely wrote:
> On Wed, 19 Feb 2014 14:43:58 -0700, Warner Losh <wlosh-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> On Feb 19, 2014, at 2:09 PM, Grant Likely wrote:
>>
>>> On Tue, Feb 18, 2014 at 6:18 PM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
>>>> On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote:
>>>>> It will be interesting to see which rules should apply for merging new
>>>>> bindings. I know that devicetrees should be OS agnostic, but sometimes
>>>>> they are modelled after how Linux currently works. What happens when the
>>>>> *BSD guys have different ideas how a good binding looks like? How will
>>>>> such conflicts be resolved?
>>>>
>>>> That's more a question for Grant. I assume we'll all put on our big-boy
>>>> pants and pick the best technical solution based on their merits. :)
>>>
>>> I think you've answered it pretty competently.
>>
>> What, the BSDs don't get a free pass to dump junk into the process. I'm shocked :)
>>
>> But we have bug-boy pants over in BSD land, so that shouldn't be a problem.
>
> Bug-boy pants? Sounds sticky.
Yea, gotta those accidental typos...
Warner
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Olof Johansson @ 2014-02-21 18:47 UTC (permalink / raw)
To: Sascha Hauer
Cc: Frank Rowand, Jason Cooper, Grant Likely, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140221141136.GI17250-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Feb 21, 2014 at 6:11 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Thu, Feb 20, 2014 at 05:07:12PM -0800, Frank Rowand wrote:
>> Why are the changes not submitted upstream? (Or if they were submitted, why
>> were they not accepted?)
>
> The descriptions where to find the environment are obviously barebox
> specific and not acceptable upstream.
Why not? Wouldn't it be useful if you could find where the environment
is from the running Linux image so that you can change variables
without rebooting into Barebox first?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 5/8] ARM: dts: sun7i: Add support for mmc
From: Maxime Ripard @ 2014-02-21 18:54 UTC (permalink / raw)
To: Hans de Goede
Cc: David Lanzendörfer, devicetree-u79uwXL29TY76Z2rM5mHXA,
Ulf Hansson, Laurent Pinchart, Mike Turquette, Simon Baatz,
Emilio López, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <530377EE.8010909-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5518 bytes --]
On Tue, Feb 18, 2014 at 04:10:38PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02/18/2014 03:22 PM, Maxime Ripard wrote:
> >On Mon, Feb 17, 2014 at 11:02:41AM +0100, David Lanzendörfer wrote:
> >>Signed-off-by: David Lanzendörfer <david.lanzendoerfer-Z7Kmv9EsliU@public.gmane.org>
> >>Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>---
> >> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 8 +++
> >> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8 +++
> >> arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 23 +++++++++
> >> arch/arm/boot/dts/sun7i-a20.dtsi | 61 +++++++++++++++++++++++
> >> 4 files changed, 100 insertions(+)
> >>
> >
> >I'd prefer to have three patches here:
> > - One that add the controllers
> > - One that add the pin muxing options
> > - One that enable the controllers on the various boards.
> >
> >>diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> >>index 5c51cb8..ae800b6 100644
> >>--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> >>+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> >>@@ -34,6 +34,14 @@
> >> };
> >> };
> >>
> >>+ mmc0: mmc@01c0f000 {
> >>+ pinctrl-names = "default", "default";
> >>+ pinctrl-0 = <&mmc0_pins_a>;
> >>+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
> >
> >This can be made a single pinctrl group, you don't need the pinctrl-1
> >stuff, it only complicates the node.
>
> Then how do we deal with boards which use a different gpio for card-detect ?
>
> In that case we don't want to change the mux setting of the reference
> design cd pin. IOW I believe that having 2 separate pinctrl settings for
> this is the rigt thing todo. I would prefer using just mmc0_cd_pin_a instead
> of _reference_design though.
>
> Oh wait, you're probably talking about using:
> pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
>
> Yes that would be better.
Yep, exactly :)
> >
> >>+ cd-gpios = <&pio 7 1 0>; /* PH1 */
> >>+ status = "okay";
> >>+ };
> >>+
> >> pinctrl@01c20800 {
> >> led_pins_cubieboard2: led_pins@0 {
> >> allwinner,pins = "PH20", "PH21";
> >>diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> >>index f9dcb61..370cef84 100644
> >>--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> >>+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> >>@@ -19,6 +19,14 @@
> >> compatible = "cubietech,cubietruck", "allwinner,sun7i-a20";
> >>
> >> soc@01c00000 {
> >>+ mmc0: mmc@01c0f000 {
> >>+ pinctrl-names = "default", "default";
> >>+ pinctrl-0 = <&mmc0_pins_a>;
> >>+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
> >>+ cd-gpios = <&pio 7 1 0>; /* PH1 */
> >>+ status = "okay";
> >>+ };
> >>+
> >> pinctrl@01c20800 {
> >> led_pins_cubietruck: led_pins@0 {
> >> allwinner,pins = "PH7", "PH11", "PH20", "PH21";
> >>diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> >>index ead3013..685ec06 100644
> >>--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> >>+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> >>@@ -34,7 +34,30 @@
> >> };
> >> };
> >>
> >>+ mmc0: mmc@01c0f000 {
> >>+ pinctrl-names = "default", "default";
> >>+ pinctrl-0 = <&mmc0_pins_a>;
> >>+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
> >>+ cd-gpios = <&pio 7 1 0>; /* PH1 */
> >>+ status = "okay";
> >>+ };
> >>+
> >>+ mmc3: mmc@01c12000 {
> >>+ pinctrl-names = "default", "default";
> >>+ pinctrl-0 = <&mmc3_pins_a>;
> >>+ pinctrl-1 = <&mmc3_cd_pin_olinuxinom>;
> >>+ cd-gpios = <&pio 7 11 0>; /* PH11 */
> >>+ status = "okay";
> >>+ };
> >>+
> >> pinctrl@01c20800 {
> >>+ mmc3_cd_pin_olinuxinom: mmc3_cd_pin@0 {
> >>+ allwinner,pins = "PH11";
> >>+ allwinner,function = "gpio_in";
> >>+ allwinner,drive = <0>;
> >>+ allwinner,pull = <1>;
> >>+ };
> >>+
> >> led_pins_olinuxino: led_pins@0 {
> >> allwinner,pins = "PH2";
> >> allwinner,function = "gpio_out";
> >>diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >>index 9ff0948..5b55414 100644
> >>--- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >>+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >>@@ -355,6 +355,46 @@
> >> #size-cells = <0>;
> >> };
> >>
> >>+ mmc0: mmc@01c0f000 {
> >>+ compatible = "allwinner,sun5i-a13-mmc";
> >>+ reg = <0x01c0f000 0x1000>;
> >>+ clocks = <&ahb_gates 8>, <&mmc0_clk>;
> >>+ clock-names = "ahb", "mod";
> >>+ interrupts = <0 32 4>;
> >>+ bus-width = <4>;
> >
> >This belongs to the board, the controller itself is able to handle
> >several bus width.
>
> I believe that providing some form of default in the dtsi makes sense
> here and all boards we've seen sofar always use 4 bits, we can always
> override this from the dts file itself.
There's already a documented default that is 1. Plus, I still believe
in a strict separation between what's in the SoC being in the DTSI and
what's in the board being in the DTS.
Apart from being more rigorous, it also has the advantage of being
*much* clearer whenever your read a board DTS, since you don't have to
actually open several DTS(I) to get what's going on.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Olof Johansson @ 2014-02-21 18:57 UTC (permalink / raw)
To: Grant Likely
Cc: Rob Herring, Tim Bird, Jason Cooper, Sascha Hauer, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140220113832.D9E13C4050F-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On Thu, Feb 20, 2014 at 3:38 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > One way to minimize the inconvenience is keep versioning and dev
>> > cycles in sync with the kernel. We could also start doing things to
>> > align the kernel workflow with how things will work when we do have a
>> > separate repository.
>>
>> I don't think aligning development cycles is what we want most here it
>> might be useful for us in Linux but it'll make things difficult for
>> other projects since they're not aware of our release cycles. The
>> device tree bindings and DT contents in that repo should be "always
>> stable", i.e. no merge window / rc concept. As soon as something goes
>> in it's live, and from then out only fixes to the DTS files (or
>> appending the binding).
>>
>> For example, I don't want to have to track two trees to test against
>> -- I'll want to keep one repo of the very latest DT files and always
>> use those to boot any and all boards.
>
> This approach does have the subtle side effect that differs from what we
> discussed in Edinburgh. We've talked about always being able to boot a
> new kernel on an old devicetree, but not a new devicetree on an old
> kernel. With a separate board database repo we are going to hit both
> cases. At least to a limited extent we're going to need older kernels
> booting with the latest devicetree, and we'll need some rules about how
> that gets applied.
That's true. For the most part this should work well as we enable IP
for DT, since before then we'll fall back on old configuration ways.
Where it gets complicated is if we deprecate a whole binding and make
a new one, or if we change the meaning of properties. Due to the ABI
properties, we shouldn't be doing the latter anyway. The former is
obviously a problem but we might just have to live with it. I don't
think we're likely to hit it much in reality once bindings stabilize
-- main case would be if we want to rewrite some of the very old and
maybe not so good bindings (like the mtd driver binding that the at91
guys came up with early). But in reality we're likely to just stick
with them and not bother.
So, yes, it does change the formality but in reality I don't expect
that much of a difference.
> The alternative is that binding changes land in .dts files after a
> kernel release, and I don't think we want that situation at all.
Nope.
> This is an issue for new bindings, only when a binding is getting
s/is/isn't/, which I think was your intent.
> extended or replaced. If the change is merely adding new properties then
> there shouldn't be a problem (the old kernel will ignore the new
> properties). If it removes properties or creates a new compatible string
> (dropping the one supported by an older kernel) then it won't boot.
Yes, I think I said the same thing above in my reply now. :-)
> Ultimately this is probably the right thing to do, but it will be
> difficult. Keeping a staging process for new bindings in lock step
> with the kernel is probably the way to mitigate this.
This might work with the mirroring case, but it'll get awkward if we
have completely separate repos and thus potentially separate
reviewers/approvers, if things get additional scrutiny between the
staging phase in the kernel and when it gets merged upstream,
especially if the DTS has already been moved out. I'm not quite sure
how that would work, really.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 2/3] ata: Add APM X-Gene SoC AHCI SATA host controller driver
From: Tejun Heo @ 2014-02-21 19:00 UTC (permalink / raw)
To: Loc Ho
Cc: Olof Johansson, Arnd Bergmann, Linux SCSI List,
linux-ide@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Don Dutile, Jon Masters,
patches@apm.com, Tuan Phan, Suman Tripathi
In-Reply-To: <CAPw-ZTkWbYfCKs+4ZJ7_zuuFZy5RH51319Pj=3i5kdg162UVXg@mail.gmail.com>
Hello, Loc.
On Fri, Feb 21, 2014 at 10:43:52AM -0800, Loc Ho wrote:
> Do you want this for all functions or only one that with comment? Also,
> for both drivers - host and PHY drivres?
Oh, no need to do that for every function. It's just customary to use
function comment when there's sufficient amount to explain for the
whole function.
> > Can you please go back two reviews and re-read what I requested?
> > Also, if you're unsure, please don't hesitate to ask back. It's
> > usually a lot easier for both parties than iterating through patchsets
> > without properly understanding each other.
> >
>
> Before posting this morning, I had gone over all response email from you
> since we first interacted. I am not quite follow what you want here. Are
> you suggesting that I should move this out as an errata patch?
Hmmm... maybe I was too ambiguous. Because the behavior is quite
unusual and can make the error handling behavior deviate, I think it
deserves to explain 1. why such behavior is necessary and 2. what the
implications are (e.g. in corner cases, how long it could add to reset
timeout) and preferably 3. rationale for choosing this specific
approach given #1 and #2, so that when someone else reads the code
later on [s]he doesn't have to second-guess the original intention of
the workaround.
Thanks.
--
tejun
^ permalink raw reply
* Re: SPDX-License-Identifier
From: Theodore Ts'o @ 2014-02-21 19:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Michal Simek, Felipe Balbi, Subbaraya Sundeep Bhatta, linux-usb,
linux-kernel, Subbaraya Sundeep Bhatta, devicetree, Wolfgang Denk
In-Reply-To: <20140221175720.GA21660@kroah.com>
On Fri, Feb 21, 2014 at 09:57:20AM -0800, Greg Kroah-Hartman wrote:
> > But shouldn't we at least write somewhere
> > that it has connection to spdx.org where you can find out that licenses.
>
> Why? Are these licenses so unknown that no one knows what they are?
> And, as part of the kernel-as-a-whole-work, they all resolve to GPLv2
> anyway, and we have that license in the source tree, so nothing else
> should be needed.
Note that not all lawyers are in agreement about this, so if this is a
driver being developed by a company, you may want to ask your
corporate counsel if they have an opinion about this. I've received
advice of the form that it's not obvious that regardless of whether or
not us *engineers* understand what all of the licensing terms mean,
what's important is whether someone who is accused of "borrowing"
GPL'ed code and dropping it in a driver for some other OS can convince
a judge whether or not it's considered "obvious" from a legal
perspective what an SPDX header means, and what is implied by an SPDX
license identifer.
Also note that with the advent of web sites that allow people to do
web searches and turn up a singleton file via some gitweb interface,
the fact that the full license text is distributed alongside the
tarball might or might have as much legal significance as it once had.
But of course, I'm not a lawyer, and if your company has is paying for
the development of the driver, the Golden Rule applies (he who has the
Gold, makes the Rules), and each of our respective corporate lawyers
may have different opinions about what might happen if the question
was ever to be adjudicated in court.
Cheers,
- Ted
^ permalink raw reply
* Re: [Patch v6 1/2] dmaengine: qcom_bam_dma: Add device tree binding
From: Andy Gross @ 2014-02-21 19:02 UTC (permalink / raw)
To: Mark Rutland
Cc: Vinod Koul, Dan Williams, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20140221173647.GC28555@e106331-lin.cambridge.arm.com>
On Fri, Feb 21, 2014 at 05:36:47PM +0000, Mark Rutland wrote:
[snip]
> >
> > Yes only a single interrupt. I can remove the s.
>
> Please don't, the interrupts proeprty is standard and shouldn't change.
>
> I was only asking to ensure that all interrupts were described in the
> binding, which they are. :)
>
Responding to emails before coffee is bad.....
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module
From: Benjamin Herrenschmidt @ 2014-02-21 20:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Alistair Popple, linuxppc-dev, linux-kernel, devicetree
In-Reply-To: <1574137.lzDhNaVqIe@wuerfel>
On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:
> > @@ -242,8 +264,10 @@
> > ranges = <0x02000000 0x00000000 0x80000000 0x00000110 0x80000000 0x0 0x80000000
> > 0x01000000 0x0 0x0 0x00000140 0x0 0x0 0x00010000>;
> >
> > - /* Inbound starting at 0 to memsize filled in by zImage */
> > - dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x0>;
> > + /* Inbound starting at 0x0 to 0x40000000000. In order to use MSI
> > + * PCI devices must be able to write to the HSTA module.
> > + */
> > + dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x400 0x0>;
Should we (provided it's possible in HW) create two ranges instead ? One
covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
HW registers in the chip ...
> > /* This drives busses 0 to 0xf */
> > bus-range = <0x0 0xf>;
>
> Ah, I first only saw the line you are removing and was about
> to suggest what you do anyway. Great!
>
> > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> > index 54ec1d5..7cc3acc 100644
> > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > @@ -176,8 +176,12 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> > return -ENXIO;
> > }
> >
> > - /* Check that we are fully contained within 32 bits space */
> > - if (res->end > 0xffffffff) {
> > + /* Check that we are fully contained within 32 bits space if we are not
> > + * running on a 460sx or 476fpe which have 64 bit bus addresses.
> > + */
> > + if (res->end > 0xffffffff &&
> > + !(of_device_is_compatible(hose->dn, "ibm,plb-pciex-460sx")
> > + || of_device_is_compatible(hose->dn, "ibm,plb-pciex-476fpe"))) {
> > printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
> > hose->dn->full_name);
> > return -ENXIO;
>
> A more general question for BenH: Apparently this PCI implementation is
> getting reused on arm64 for APM X-Gene. Do you see any value in trying to
> share host controller drivers like this one across powerpc and arm64?
I would start duplicating, and see how much common code remains... Then
eventually merge.
> It's possible we are going to see the same situation with fsl_pci in the
> future, if arm and powerpc qoriq chips use the same peripherals. My
> plan for arm64 right now is to make PCI work without any code in arch/,
> just using new helper functions in drivers/pci and sticking the host
> drivers into drivers/pci/host as we started doing for arm32, but it
> can require significant work to make those drivers compatible with
> the powerpc pci-common.c.
powerpc pci-common.c is shrinking :-) At least the address remapping is
all in the core now, we could move more over I suppose...
Cheers,
Ben.
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Frank Rowand @ 2014-02-21 21:04 UTC (permalink / raw)
To: Warner Losh
Cc: Grant Likely, Sascha Hauer, Tim Bird, Olof Johansson,
Jason Cooper, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7F6C2FEA-D330-4CFA-8DC2-554DB8908EC6-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
On 2/21/2014 10:22 AM, Warner Losh wrote:
>
> On Feb 19, 2014, at 9:58 PM, Frank Rowand wrote:
>
>> On 2/19/2014 1:15 PM, Grant Likely wrote:
>>> On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On 2/19/2014 1:08 AM, Sascha Hauer wrote:
>>>>> On Tue, Feb 18, 2014 at 02:44:15PM -0800, Tim Bird wrote:
>>>>>> I'm not in favor of separating the device tree information from the kernel.
>>>>>>
>>>>>> If we switch, then whatever synchronization issues other projects
>>>>>> are having now with synching with the device tree info from the kernel will
>>>>>> just then become the problem of the kernel developers, who will then
>>>>>> have to sync with the device tree info from another repository. If the
>>>>>> sync issues can't be solved now for them, why or how would it be solved
>>>>>> post-separation for us? (It sounds like a zero-sum game of pain transfer
>>>>>> to me.)
>>>>>>
>>>>>> I'm relatively unfamiliar with the arguments. Can someone provide
>>>>>> a brief list of reasons this is needed, and how the inconvenience to Linux
>>>>>> kernel developers will be minimized, should it proceed?
>>>>>
>>>>
>>>>
>>>>> One of the reasons for doing devicetrees is to separate the hardware
>>>>> description from the code so that:
>>>>> - Other OSes (and bootloaders) can use the same description to start on
>>>>> a given hardware
>>>>> - A generic Kernel can be started on any hardware
>>>>> - A hardware describes itself, makes itself more introspecitve so we can
>>>>> go away from very specialized kernels
>>>>
>>>> Tim knows this ^^^^. He was asking for the arguments for moving dts files
>>>> out of the linux kernel source tree.
>>>
>>> We've made the decision that devicetree bindings need to be treated as
>>> ABI, but as long as the .dts files live in the kernel there will
>>> always be the temptation to just tweak things in lock-step and nobody
>>> will notice. Splitting the files out gives that extra push to think
>>> about whether changes to a binding will backwards compatible with a
>>> tree that doesn't have those changes because the chances are a lot
>>> higher that someone will hit that combination.
>>>
>>> The other argument is shared source between
>>> BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there
>>> is no good way to share the database of hardware descriptions.
>>
>> We could provide an easy export (see below). What do you think?
>
> So what would the process be to get changes to those files upstream if you did this? It would make it marginally easier to USE, but once disconnected from the git world, a lot harder to track and fix.
Changes would be through the normal upstream project (the Linux kernel). Just like when
the Linux kernel uses a driver from BSD, any changes to the upstream are done through
the BSD process.
>
> Also, you should export the device tree docs too, since they are, in theory, a set.
Yes, absolutely. And the kbuild docs need to be updated. And .... The patch was
just a proof of concept to show the scope of the changes that would be required and
that it was possible.
> And honestly, the device tree doc files need more work than the .dts and .dtsi files.
>
> Warner
>
>> -Frank
>>
>>
>>
>> Proof of concept: export devicetree source and header files
>>
>> Not-signed-off-by: Frank Rowand <frank.rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
>>
>>
>> ---
>> Makefile | 27 26 + 1 - 0 !
>> scripts/Makefile.dtsexport | 19 19 + 0 - 0 !
>> scripts/dts.sh | 11 11 + 0 - 0 !
>> 3 files changed, 56 insertions(+), 1 deletion(-)
>>
>> Index: b/Makefile
>> ===================================================================
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -234,6 +234,9 @@ endif
>> # Where to locate arch specific headers
>> hdr-arch := $(SRCARCH)
>>
>> +# Where to locate arch specific dts
>> +dts-arch := $(SRCARCH)
>> +
>> KCONFIG_CONFIG ?= .config
>> export KCONFIG_CONFIG
>>
>> @@ -463,7 +466,7 @@ version_h := include/generated/uapi/linu
>> no-dot-config-targets := clean mrproper distclean \
>> cscope gtags TAGS tags help %docs check% coccicheck \
>> $(version_h) headers_% archheaders archscripts \
>> - kernelversion %src-pkg
>> + kernelversion %src-pkg dts_export%
>>
>> config-targets := 0
>> mixed-targets := 0
>> @@ -933,6 +936,26 @@ firmware_install: FORCE
>> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
>>
>> # ---------------------------------------------------------------------------
>> +# devicetree source and headers export
>> +
>> +#Default location for installed headers
>> +export EXPORT_DTS_PATH = $(KBUILD_OUTPUT)/usr/dts
>> +
>> +PHONY += dts_export_headers
>> +dts_export_headers: scripts_basic
>> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.dtsexport obj=include/dt-bindings
>> + @echo $(KERNELRELEASE) >$(EXPORT_DTS_PATH)/linux_version
>> +
>> +PHONY += dts_export_all
>> +dts_export_all: dts_export_headers
>> + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/dts.sh
>> +
>> +PHONY += dts_export
>> +dts_export:
>> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.dtsexport obj=arch/$(dts-arch)/boot/dts
>> +
>> +
>> +# ---------------------------------------------------------------------------
>> # Kernel headers
>>
>> #Default location for installed headers
>> @@ -1160,6 +1183,8 @@ help:
>> @echo ' modules_prepare - Set up for building external modules'
>> @echo ' tags/TAGS - Generate tags file for editors'
>> @echo ' cscope - Generate cscope index'
>> + @echo ' dts_export_all - Export devicetree source and headers to EXPORT_DTS_PATH'
>> + @echo ' (default: $(EXPORT_DTS_PATH))'
>> @echo ' gtags - Generate GNU GLOBAL index'
>> @echo ' kernelrelease - Output the release version string'
>> @echo ' kernelversion - Output the version stored in Makefile'
>> Index: b/scripts/Makefile.dtsexport
>> ===================================================================
>> --- /dev/null
>> +++ b/scripts/Makefile.dtsexport
>> @@ -0,0 +1,19 @@
>> +# ==========================================================================
>> +# Exporting dts source and header files
>> +#
>> +# ==========================================================================
>> +
>> +srcpath := $(srctree)/$(obj)/*
>> +dstpath := $(EXPORT_DTS_PATH)/$(obj)
>> +
>> +include scripts/Kbuild.include
>> +
>> +
>> +quiet_cmd_install = EXPORT $(subst $(srctree)/,,$(srcpath))
>> + cmd_install = mkdir -p $(dstpath); cp -a $(srcpath) $(dstpath)
>> +
>> +
>> +.PHONY: export
>> +export:
>> + $(call cmd,install)
>> +
>> Index: b/scripts/dts.sh
>> ===================================================================
>> --- /dev/null
>> +++ b/scripts/dts.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +# Run dts_export command for all architectures
>> +
>> +# Stop on error
>> +set -e
>> +
>> +for arch in $(ls ${srctree}/arch); do
>> + if [ -d ${srctree}/arch/${arch}/boot/dts ]; then
>> + make ARCH=${arch} dts_export
>> + fi
>> +done
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module
From: Arnd Bergmann @ 2014-02-21 21:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1393015286.6771.110.camel@pasglop>
On Friday 21 February 2014, Benjamin Herrenschmidt wrote:
> On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:
>
> > > @@ -242,8 +264,10 @@
> > > ranges = <0x02000000 0x00000000 0x80000000 0x00000110 0x80000000 0x0 0x80000000
> > > 0x01000000 0x0 0x0 0x00000140 0x0 0x0 0x00010000>;
> > >
> > > - /* Inbound starting at 0 to memsize filled in by zImage */
> > > - dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x0>;
> > > + /* Inbound starting at 0x0 to 0x40000000000. In order to use MSI
> > > + * PCI devices must be able to write to the HSTA module.
> > > + */
> > > + dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x400 0x0>;
>
> Should we (provided it's possible in HW) create two ranges instead ? One
> covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
> HW registers in the chip ...
>
> > > /* This drives busses 0 to 0xf */
> > > bus-range = <0x0 0xf>;
> >
> > Ah, I first only saw the line you are removing and was about
> > to suggest what you do anyway. Great!
> >
> > > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> > > index 54ec1d5..7cc3acc 100644
> > > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > > @@ -176,8 +176,12 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> > > return -ENXIO;
> > > }
> > >
> > > - /* Check that we are fully contained within 32 bits space */
> > > - if (res->end > 0xffffffff) {
> > > + /* Check that we are fully contained within 32 bits space if we are not
> > > + * running on a 460sx or 476fpe which have 64 bit bus addresses.
> > > + */
> > > + if (res->end > 0xffffffff &&
> > > + !(of_device_is_compatible(hose->dn, "ibm,plb-pciex-460sx")
> > > + || of_device_is_compatible(hose->dn, "ibm,plb-pciex-476fpe"))) {
> > > printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
> > > hose->dn->full_name);
> > > return -ENXIO;
> >
> > A more general question for BenH: Apparently this PCI implementation is
> > getting reused on arm64 for APM X-Gene. Do you see any value in trying to
> > share host controller drivers like this one across powerpc and arm64?
>
> I would start duplicating, and see how much common code remains... Then
> eventually merge.
Ok.
> > It's possible we are going to see the same situation with fsl_pci in the
> > future, if arm and powerpc qoriq chips use the same peripherals. My
> > plan for arm64 right now is to make PCI work without any code in arch/,
> > just using new helper functions in drivers/pci and sticking the host
> > drivers into drivers/pci/host as we started doing for arm32, but it
> > can require significant work to make those drivers compatible with
> > the powerpc pci-common.c.
>
> powerpc pci-common.c is shrinking :-) At least the address remapping is
> all in the core now, we could move more over I suppose...
Ah, good. We're currently trying to work out a generic way to parse
the DT and ioremap the I/O windows. That could probably be shared
and while I hope what we need on arm64 is compatible with what you
need on powerpc, I may always miss something. I'll make sure to add
you to the discussions.
Some parts are easier because we assume that we always scan the
entire PCI bus ourselves and don't do PCI_PROBE_DEVTREE.
Other parts are harder because for the generic case we actually
want to support loading and unloading host bridge drivers,
as well as supporting any combination of host bridges in the
same system without platform specific code.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] Device tree bug fix on compatible order
From: Grant Likely @ 2014-02-21 22:11 UTC (permalink / raw)
To: Linus Torvalds,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Linux Kernel Mailing List
Hi Linus,
Please pull the following tag for a devicetree bug fix (description below)
Thanks,
g.
The following changes since commit 60f76eab19e3903e810bdc3ec846c158efcd2e21:
Merge tag 'dma-buf-for-3.14' of
git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf
(2014-02-17 12:42:45 -0800)
are available in the git repository at:
git://git.secretlab.ca/git/linux tags/dt-for-linus
for you to fetch changes up to 1f42e5dd5065963979bb53daadf5d4f1e71f0c5f:
of: Add self test for of_match_node() (2014-02-20 11:52:09 +0000)
----------------------------------------------------------------
Device tree compatible match order bug fix
This branch contains a bug fix for the way devicetree code identifies
the type of device. Device drivers can contain a list of of_device_ids,
but it more than one entry will match, then the device driver may choose
the wrong one. Commit 105353145e, "match each node compatible against
all given matches first", was queued for v3.14 but ended up causing
other bugs. Commit 06b29e76a7 attempted to fix it but it had other bugs.
Merely reverting the fix and waiting until v3.15 isn't a good option
because there is code in v3.14 that depends on the revised behaviour to
boot.
This branch should finally fixes the problem correctly. This time
instead of just hoping that the patch is correct, this branch also adds
new testcases that validate the behaviour.
The changes in this branch are larger than I would like for a -rc pull,
but moving the test case data out of out of arch/arm so that it could be
validated on other architectures was important.
----------------------------------------------------------------
Grant Likely (2):
of: Move testcase FDT data into drivers/of
of: Add self test for of_match_node()
Kevin Hao (2):
Revert "of: search the best compatible match first in __of_match_node()"
of: reimplement the matching method for __of_match_node()
arch/arm/boot/dts/testcases/tests.dtsi | 2 -
arch/arm/boot/dts/versatile-pb.dts | 4 +-
drivers/of/base.c | 150 ++++++++++-----------
drivers/of/selftest.c | 67 +++++++++
drivers/of/testcase-data/testcases.dtsi | 3 +
.../of/testcase-data}/tests-interrupts.dtsi | 0
drivers/of/testcase-data/tests-match.dtsi | 19 +++
.../of/testcase-data}/tests-phandle.dtsi | 0
scripts/Makefile.lib | 1 +
9 files changed, 166 insertions(+), 80 deletions(-)
delete mode 100644 arch/arm/boot/dts/testcases/tests.dtsi
create mode 100644 drivers/of/testcase-data/testcases.dtsi
rename {arch/arm/boot/dts/testcases =>
drivers/of/testcase-data}/tests-interrupts.dtsi (100%)
create mode 100644 drivers/of/testcase-data/tests-match.dtsi
rename {arch/arm/boot/dts/testcases =>
drivers/of/testcase-data}/tests-phandle.dtsi (100%)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 2/4] Power: Reset: Generalize qnap-poweroff to work on Synology devices.
From: Jason Cooper @ 2014-02-22 1:39 UTC (permalink / raw)
To: klightspeed-aslSrjg9ejhWX4hkXwHRhw
Cc: Andrew Lunn, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Pawel Moll, Ian Campbell, Dmitry Eremin-Solenikov,
Anton Vorontsov, Rob Herring, Kumar Gala, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1392840157-31072-3-git-send-email-klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
Dmitry, David,
On Thu, Feb 20, 2014 at 06:02:35AM +1000, klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org wrote:
> From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>
> The Synology NAS devices use a very similar mechanism to QNAP NAS
> devices to power off. Both send a single charactor command to a PIC,
> over the second serial port. However the baud rate and the command
> differ. Generalize the driver to support this.
>
> Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
> Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> Cc: Anton Vorontsov <anton-9xeibp6oKSgdnm+yROfE0A@public.gmane.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> ---
> .../bindings/power_supply/qnap-poweroff.txt | 5 ++-
> drivers/power/reset/qnap-poweroff.c | 49 ++++++++++++++++------
> 2 files changed, 41 insertions(+), 13 deletions(-)
Do you guys want to take this, or me? I'm fine either way, there's no
dependencies.
thx,
Jason.
> diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> index 0347d83..af25e77 100644
> --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> @@ -6,8 +6,11 @@ Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
> microcontroller to turn the power off. This driver adds a handler to
> pm_power_off which is called to turn the power off.
>
> +Synology NAS devices use a similar scheme, but a different baud rate,
> +9600, and a different character, '1'.
> +
> Required Properties:
> -- compatible: Should be "qnap,power-off"
> +- compatible: Should be "qnap,power-off" or "synology,power-off"
>
> - reg: Address and length of the register set for UART1
> - clocks: tclk clock
> diff --git a/drivers/power/reset/qnap-poweroff.c b/drivers/power/reset/qnap-poweroff.c
> index 37f56f7..a75db7f 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -1,5 +1,5 @@
> /*
> - * QNAP Turbo NAS Board power off
> + * QNAP Turbo NAS Board power off. Can also be used on Synology devices.
> *
> * Copyright (C) 2012 Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> *
> @@ -25,17 +25,43 @@
>
> #define UART1_REG(x) (base + ((UART_##x) << 2))
>
> +struct power_off_cfg {
> + u32 baud;
> + char cmd;
> +};
> +
> +static const struct power_off_cfg qnap_power_off_cfg = {
> + .baud = 19200,
> + .cmd = 'A',
> +};
> +
> +static const struct power_off_cfg synology_power_off_cfg = {
> + .baud = 9600,
> + .cmd = '1',
> +};
> +
> +static const struct of_device_id qnap_power_off_of_match_table[] = {
> + { .compatible = "qnap,power-off",
> + .data = &qnap_power_off_cfg,
> + },
> + { .compatible = "synology,power-off",
> + .data = &synology_power_off_cfg,
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, qnap_power_off_of_match_table);
> +
> static void __iomem *base;
> static unsigned long tclk;
> +static const struct power_off_cfg *cfg;
>
> static void qnap_power_off(void)
> {
> - /* 19200 baud divisor */
> - const unsigned divisor = ((tclk + (8 * 19200)) / (16 * 19200));
> + const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>
> pr_err("%s: triggering power-off...\n", __func__);
>
> - /* hijack UART1 and reset into sane state (19200,8n1) */
> + /* hijack UART1 and reset into sane state */
> writel(0x83, UART1_REG(LCR));
> writel(divisor & 0xff, UART1_REG(DLL));
> writel((divisor >> 8) & 0xff, UART1_REG(DLM));
> @@ -44,16 +70,21 @@ static void qnap_power_off(void)
> writel(0x00, UART1_REG(FCR));
> writel(0x00, UART1_REG(MCR));
>
> - /* send the power-off command 'A' to PIC */
> - writel('A', UART1_REG(TX));
> + /* send the power-off command to PIC */
> + writel(cfg->cmd, UART1_REG(TX));
> }
>
> static int qnap_power_off_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> struct resource *res;
> struct clk *clk;
> char symname[KSYM_NAME_LEN];
>
> + const struct of_device_id *match =
> + of_match_node(qnap_power_off_of_match_table, np);
> + cfg = match->data;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(&pdev->dev, "Missing resource");
> @@ -94,12 +125,6 @@ static int qnap_power_off_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id qnap_power_off_of_match_table[] = {
> - { .compatible = "qnap,power-off", },
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, qnap_power_off_of_match_table);
> -
> static struct platform_driver qnap_power_off_driver = {
> .probe = qnap_power_off_probe,
> .remove = qnap_power_off_remove,
> --
> 1.8.3.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 0/4] DT support for kirkwood based Synology NAS boxes
From: Jason Cooper @ 2014-02-22 1:56 UTC (permalink / raw)
To: klightspeed
Cc: Mark Rutland, Andrew Lunn, Pawel Moll, Ian Campbell, devicetree,
Rob Herring, Kumar Gala, linux-arm-kernel
In-Reply-To: <1392840157-31072-1-git-send-email-klightspeed@killerwolves.net>
Ben,
On Thu, Feb 20, 2014 at 06:02:33AM +1000, klightspeed@killerwolves.net wrote:
> This patchset adds support for around 30 kirkwood bases Synology NAS
> boxes. Patch #1 documents vendor prefixes. Patch #2 generalizes the qnap
> power off driver so that it can also be used for Synology devices.
> Patch #3 adds sii,s35390a to i2c trivial devices. Patch #4 adds the
> synology DT files.
...
> Andrew Lunn (3):
> DT: Vendor prefixes: Add ricoh, qnap, sii and synology
> Power: Reset: Generalize qnap-poweroff to with on Synology devices.
> DT: i2c: Trivial: Add sii,s35390a
>
> Ben Peddell (1):
> ARM: Kirkwood: Add support for many Synology NAS devices
>
> .../devicetree/bindings/i2c/trivial-devices.txt | 1 +
> .../bindings/power_supply/qnap-poweroff.txt | 5 +-
> .../devicetree/bindings/vendor-prefixes.txt | 4 +
> arch/arm/boot/dts/Makefile | 15 +
> arch/arm/boot/dts/kirkwood-ds109.dts | 41 +
> arch/arm/boot/dts/kirkwood-ds110jv10.dts | 41 +
> arch/arm/boot/dts/kirkwood-ds111.dts | 44 ++
> arch/arm/boot/dts/kirkwood-ds112.dts | 48 ++
> arch/arm/boot/dts/kirkwood-ds209.dts | 44 ++
> arch/arm/boot/dts/kirkwood-ds210.dts | 46 ++
> arch/arm/boot/dts/kirkwood-ds212.dts | 47 ++
> arch/arm/boot/dts/kirkwood-ds212j.dts | 41 +
> arch/arm/boot/dts/kirkwood-ds409.dts | 48 ++
> arch/arm/boot/dts/kirkwood-ds409slim.dts | 40 +
> arch/arm/boot/dts/kirkwood-ds411.dts | 52 ++
> arch/arm/boot/dts/kirkwood-ds411j.dts | 48 ++
> arch/arm/boot/dts/kirkwood-ds411slim.dts | 48 ++
> arch/arm/boot/dts/kirkwood-rs212.dts | 48 ++
> arch/arm/boot/dts/kirkwood-rs409.dts | 44 ++
> arch/arm/boot/dts/kirkwood-rs411.dts | 44 ++
> arch/arm/boot/dts/kirkwood-synology.dtsi | 871 +++++++++++++++++++++
> drivers/power/reset/qnap-poweroff.c | 49 +-
> 22 files changed, 1656 insertions(+), 13 deletions(-)
> create mode 100644 arch/arm/boot/dts/kirkwood-ds109.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds110jv10.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds111.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds112.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds209.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds210.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds212.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds212j.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds409.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds409slim.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds411.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds411j.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ds411slim.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-rs212.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-rs409.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-rs411.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-synology.dtsi
I applied patches 1, 3, and 4 to mvebu/dt.
Thanks and good work!
Jason.
^ permalink raw reply
* Re: [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver
From: Tony Prisk @ 2014-02-22 2:32 UTC (permalink / raw)
To: Mark Rutland, Alistair Popple
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20140221114803.GB8783-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On 22/02/14 00:48, Mark Rutland wrote:
> [Adding Tony Prisk to Cc]
>
> On Fri, Feb 21, 2014 at 06:31:30AM +0000, Alistair Popple wrote:
>> Currently the ppc-of driver uses the compatibility string
>> "usb-ehci". This means platforms that use device-tree and implement an
>> EHCI compatible interface have to either use the ppc-of driver or add
>> a compatible line to the ehci-platform driver. It would be more
>> appropriate for the platform driver to be compatible with "usb-ehci"
>> as non-powerpc platforms are also beginning to utilise device-tree.
>>
>> This patch merges the device tree property parsing from ehci-ppc-of
>> into the platform driver and adds a "usb-ehci" compatibility
>> string. The existing ehci-ppc-of driver is removed and the 440EPX
>> specific quirks are added to the ehci-platform driver.
>>
>> Signed-off-by: Alistair Popple <alistair-Y4h6yKqj69EXC2x5gXVKYQ@public.gmane.org>
>> ---
>> drivers/usb/host/Kconfig | 7 +-
>> drivers/usb/host/ehci-hcd.c | 5 -
>> drivers/usb/host/ehci-platform.c | 87 +++++++++++++-
>> drivers/usb/host/ehci-ppc-of.c | 238 --------------------------------------
>> 4 files changed, 89 insertions(+), 248 deletions(-)
>> delete mode 100644 drivers/usb/host/ehci-ppc-of.c
> Please use of_property_read_bool for these.
>
> This driver already handles "via,vt8500-ehci" and "wm,prizm-ehci" which
> aren't documented to handle these properties, but now gain support for
> them. It might be worth unifying the binding documents if there's
> nothing special about those two host controllers.
>
> We seem to have two binding documents for "via,vt8500-ehci", so some
> cleanup is definitely in order.
>
> Tony, you seem to have written both documents judging by 95e9fd10f06c
> and 8ad551d150e3. Do you have any issue with merging both of these into
> a common usb-ehci document?
......
> Cheers,
> Mark.
I'm not sure how we ended up with two bindings for the driver anyway. I
think this was an error on my part somewhere.
None of the in-tree dts files use "wm,prizm-ehci".
I have no issue with merging all the documentation into a single
usb-ehci binding.
Regards
Tony Prisk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox