Re: [PATCH v6] SATA: OCTEON: support SATA on OCTEON platform
From: Arnd Bergmann <arnd@arndb.de>
Date: 2016-02-02 20:49:08
Also in:
linux-devicetree, lkml
On Tuesday 02 February 2016 18:24:45 Zubair Lutfullah Kakakhel wrote:
quoted hunk ↗ jump to hunk
diff --git a/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt new file mode 100644 index 0000000..3bd3c2f --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt@@ -0,0 +1,42 @@ +* UCTL SATA controller glue + +UCTL is the bridge unit between the I/O interconnect (an internal bus) +and the SATA AHCI host controller (UAHC). It performs the following functions: + - provides interfaces for the applications to access the UAHC AHCI + registers on the CN71XX I/O space. + - provides a bridge for UAHC to fetch AHCI command table entries and data + buffers from Level 2 Cache. + - posts interrupts to the CIU. + - contains registers that: + - control the behavior of the UAHC + - control the clock/reset generation to UAHC + - control endian swapping for all UAHC registers and DMA accesses
Typically we treat those special registers as part of the device itself and have a single device node for the AHCI controller and that one. What is your reason for doing it differently here?
quoted hunk ↗ jump to hunk
index 04975b8..6bc1de6 100644--- a/drivers/ata/ahci_platform.c +++ b/drivers/ata/ahci_platform.c@@ -76,6 +76,8 @@ static const struct of_device_id ahci_of_match[] = { { .compatible = "ibm,476gtr-ahci", }, { .compatible = "snps,dwc-ahci", }, { .compatible = "hisilicon,hisi-ahci", }, + { .compatible = "fsl,qoriq-ahci", }, + { .compatible = "cavium,octeon-7130-ahci", }, {},
The qoriq-ahci addition seems misplaced in this patch. Maybe split that out into a separate patch?
+/**
+ * cvmx_sata_uctl_shim_cfg
+ * from cvmx-sata-defs.h
+ *
+ * Accessible by: only when A_CLKDIV_EN
+ * Reset by: IOI reset (srst_n) or SATA_UCTL_CTL[SATA_UCTL_RST]
+ * This register allows configuration of various shim (UCTL) features.
+ * Fields XS_NCB_OOB_* are captured when there are no outstanding OOB errors
+ * indicated in INTSTAT and a new OOB error arrives.
+ * Fields XS_BAD_DMA_* are captured when there are no outstanding DMA errors
+ * indicated in INTSTAT and a new DMA error arrives.
+ */
+union cvmx_sata_uctl_shim_cfg {
+ uint64_t u64;
+ struct cvmx_sata_uctl_shim_cfg_s {
+ /*
+ * Read/write error log for out-of-bound UAHC register access.
+ * 0 = read, 1 = write.
+ */
+ __BITFIELD_FIELD(uint64_t xs_ncb_oob_wrn : 1,
+ __BITFIELD_FIELD(uint64_t reserved_57_62 : 6,
+ /*Try to avoid bitfields when defining structures that interact with the hardware, bitfields often cause problems with mixed-endian environments and don't make this easier to understand.
+static int ahci_octeon_probe(struct platform_device *pdev)
+{
+ union cvmx_sata_uctl_shim_cfg shim_cfg;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct resource *res;
+ void __iomem *base;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Platform resource[0] is missing\n");
+ return -ENODEV;
+ }
+
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ /* set-up endian mode */
+ shim_cfg.u64 = cvmx_read_csr(
+ (__force uint64_t)base + CVMX_SATA_UCTL_SHIM_CFG);
+#ifdef __BIG_ENDIAN
+ shim_cfg.s.dma_endian_mode = 1;
+ shim_cfg.s.csr_endian_mode = 1;
+#else
+ shim_cfg.s.dma_endian_mode = 0;
+ shim_cfg.s.csr_endian_mode = 0;
+#endif
+ shim_cfg.s.dma_read_cmd = 1; /* No allocate L2C */
+ cvmx_write_csr(
+ (__force uint64_t)base + CVMX_SATA_UCTL_SHIM_CFG, shim_cfg.u64);
+Maybe add a helper function around cvmx_write_csr() that allows you to write to an __iomem address? Drivers should generally not need to use __force. Arnd