* [PATCH] arm64: dts: allwinner: h5: NanoPi NEO Plus2 : add EMAC support
From: Antony Antony @ 2017-11-29 14:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antony Antony,
devicetree
add arm64 H5 dwmac-sun8i support for this board
Signed-off-by: Antony Antony <antony-AVhj06Q78b5AfugRpC6u6w@public.gmane.org>
---
.../boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
index 7c028af..01dace4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
@@ -53,6 +53,7 @@
compatible = "friendlyarm,nanopi-neo-plus2", "allwinner,sun50i-h5";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -133,6 +134,22 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_rgmii_pins>;
+ phy-supply = <®_gmac_3v3>;
+ phy-handle = <&ext_rgmii_phy>;
+ phy-mode = "rgmii";
+ status = "okay";
+};
+
+&external_mdio {
+ ext_rgmii_phy: ethernet-phy@7 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <7>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.7.4
--
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 v10 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
From: Shameer Kolothum @ 2017-11-29 14:14 UTC (permalink / raw)
To: lorenzo.pieralisi, will.deacon, robin.murphy, marc.zyngier, joro
Cc: john.garry, xuwei5, guohanjun, iommu, linux-arm-kernel,
linux-acpi, devicetree, linuxarm, Shameer Kolothum
In-Reply-To: <20171129141449.120316-1-shameerali.kolothum.thodi@huawei.com>
The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.
PCIe controller on these platforms has to differentiate the
MSI payload against other DMA payload and has to modify the
MSI payload. This makes it difficult for these platforms to
have SMMU translation for MSI. In order to workaround this,
ARM SMMUv3 driver requires a quirk to treat the MSI regions
separately. Such a quirk is currently missing for DT based
systems and therefore we need to explicitly disable the
hip06/hip07 smmu entries in dts.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 55 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 24 ++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..d0d5933 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,13 @@
#interrupt-cells = <2>;
num-pins = <128>;
};
+
+ mbigen_pcie0: intc_pcie0 {
+ msi-parent = <&its_dsa 0x40085>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <10>;
+ };
};
mbigen_dsa@c0080000 {
@@ -312,6 +319,30 @@
};
};
+ /** HiSilicon erratum 161010801: This describes the limitation
+ * of HiSilicon platforms hip06/hip07 to support the SMMUv3
+ * mappings for PCIe MSI transactions.
+ * PCIe controller on these platforms has to differentiate the
+ * MSI payload against other DMA payload and has to modify the
+ * MSI payload. This makes it difficult for these platforms to
+ * have a SMMU translation for MSI. In order to workaround this,
+ * ARM SMMUv3 driver requires a quirk to treat the MSI regions
+ * separately. Such a quirk is currently missing for DT based
+ * systems. Hence please make sure that the smmu pcie node on
+ * hip06 is disabled as this will break the PCIe functionality
+ * when iommu-map entry is used along with the PCIe node.
+ * Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+ */
+ smmu0: smmu_pcie {
+ compatible = "arm,smmu-v3";
+ reg = <0x0 0xa0040000 0x0 0x20000>;
+ #iommu-cells = <1>;
+ dma-coherent;
+ smmu-cb-memtype = <0x0 0x1>;
+ hisilicon,broken-prefetch-cmd;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -676,6 +707,30 @@
<637 1>,<638 1>,<639 1>;
status = "disabled";
};
+
+ pcie0: pcie@a0090000 {
+ compatible = "hisilicon,hip06-pcie-ecam";
+ reg = <0 0xb0000000 0 0x2000000>,
+ <0 0xa0090000 0 0x10000>;
+ bus-range = <0 31>;
+ msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+ msi-map-mask = <0xffff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0
+ 0x5ff0000 0x01000000 0 0 0 0xb7ff0000
+ 0 0x10000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+ 0x0 0 0 2 &mbigen_pcie0 650 4
+ 0x0 0 0 3 &mbigen_pcie0 650 4
+ 0x0 0 0 4 &mbigen_pcie0 650 4>;
+ status = "disabled";
+ };
+
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..58fe013 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,30 @@
};
};
+ /** HiSilicon erratum 161010801: This describes the limitation
+ * of HiSilicon platforms hip06/hip07 to support the SMMUv3
+ * mappings for PCIe MSI transactions.
+ * PCIe controller on these platforms has to differentiate the
+ * MSI payload against other DMA payload and has to modify the
+ * MSI payload. This makes it difficult for these platforms to
+ * have a SMMU translation for MSI. In order to workaround this,
+ * ARM SMMUv3 driver requires a quirk to treat the MSI regions
+ * separately. Such a quirk is currently missing for DT based
+ * systems. Hence please make sure that the smmu pcie node on
+ * hip06 is disabled as this will break the PCIe functionality
+ * when iommu-map entry is used along with the PCIe node.
+ * Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+ */
+ smmu0: smmu_pcie {
+ compatible = "arm,smmu-v3";
+ reg = <0x0 0xa0040000 0x0 0x20000>;
+ #iommu-cells = <1>;
+ dma-coherent;
+ smmu-cb-memtype = <0x0 0x1>;
+ hisilicon,broken-prefetch-cmd;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
^ permalink raw reply related
* [PATCH v10 2/3] iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
From: Shameer Kolothum @ 2017-11-29 14:14 UTC (permalink / raw)
To: lorenzo.pieralisi, will.deacon, robin.murphy, marc.zyngier, joro
Cc: devicetree, john.garry, linuxarm, xuwei5, linux-acpi, iommu,
Shameer Kolothum, guohanjun, linux-arm-kernel
In-Reply-To: <20171129141449.120316-1-shameerali.kolothum.thodi@huawei.com>
Modified iommu_dma_get_resv_regions() to include GICv3 ITS
region on ACPI based ARM platfiorms which may require HW MSI
reservations.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
drivers/iommu/dma-iommu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 25914d3..f05f3cf 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi_iort.h>
#include <linux/device.h>
#include <linux/dma-iommu.h>
#include <linux/gfp.h>
@@ -167,13 +168,18 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
*
* IOMMU drivers can use this to implement their .get_resv_regions callback
* for general non-IOMMU-specific reservations. Currently, this covers host
- * bridge windows for PCI devices.
+ * bridge windows for PCI devices and GICv3 ITS region reservation on ACPI
+ * based ARM platforms that may require HW MSI reservation.
*/
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
{
struct pci_host_bridge *bridge;
struct resource_entry *window;
+ if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+ iort_iommu_msi_get_resv_regions(dev, list) < 0)
+ return;
+
if (!dev_is_pci(dev))
return;
--
1.9.1
^ permalink raw reply related
* [PATCH v10 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Shameer Kolothum @ 2017-11-29 14:14 UTC (permalink / raw)
To: lorenzo.pieralisi-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robin.murphy-5wv7dgnIgG8, marc.zyngier-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Shameer Kolothum, guohanjun-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171129141449.120316-1-shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.
Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations. The function checks for the smmu model number and
only applies the msi reservation if the platform requires it.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
drivers/acpi/arm64/iort.c | 133 ++++++++++++++++++++++++++++++++++++++-
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 ++-
3 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 95255ec..1c5fc36 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
struct iort_its_msi_chip {
struct list_head list;
struct fwnode_handle *fw_node;
+ phys_addr_t base_addr;
u32 translation_id;
};
@@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
static DEFINE_SPINLOCK(iort_msi_chip_lock);
/**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
* @trans_id: ITS ID.
+ * @base: ITS base address.
* @fw_node: Domain token.
*
* Returns: 0 on success, -ENOMEM if no memory when allocating list element
*/
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+ struct fwnode_handle *fw_node)
{
struct iort_its_msi_chip *its_msi_chip;
@@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
its_msi_chip->fw_node = fw_node;
its_msi_chip->translation_id = trans_id;
+ its_msi_chip->base_addr = base;
spin_lock(&iort_msi_chip_lock);
list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
return -ENODEV;
}
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+ struct iort_its_msi_chip *its_msi_chip;
+ bool match = false;
+
+ spin_lock(&iort_msi_chip_lock);
+ list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+ if (its_msi_chip->translation_id == its_id) {
+ *base = its_msi_chip->base_addr;
+ match = true;
+ break;
+ }
+ }
+ spin_unlock(&iort_msi_chip_lock);
+
+ return match ? 0 : -ENODEV;
+}
+
/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
@@ -740,6 +762,38 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
return 0;
}
+static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
+ struct acpi_iort_node *node)
+{
+ struct iort_fwnode *curr;
+ struct acpi_iort_node *iommu = NULL;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ if (WARN_ON(!fwspec || !fwspec->iommu_fwnode))
+ return false;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+ if (curr->fwnode == fwspec->iommu_fwnode) {
+ iommu = curr->iort_node;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+ struct acpi_iort_smmu_v3 *smmu;
+
+ smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+ if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
+ dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
struct fwnode_handle *fwnode,
const struct iommu_ops *ops)
@@ -782,6 +836,77 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
return err;
}
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of msi reserved regions on success (0 if platform
+ * doesn't require the reservation or no associated msi regions),
+ * appropriate error value otherwise. The ITS interrupt translation
+ * space (ITS_base + 0x010000) associated with the device are the
+ * msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct acpi_iort_its_group *its;
+ struct acpi_iort_node *node, *its_node = NULL;
+ int i, resv = 0;
+
+ node = iort_find_dev_node(dev);
+ if (!node)
+ return -ENODEV;
+
+ if (!iort_hw_msi_resv_enable(dev, node))
+ return 0;
+
+ /*
+ * Current logic to reserve ITS regions relies on HW topologies
+ * where a given PCI or named component maps its IDs to only one
+ * ITS group; if a PCI or named component can map its IDs to
+ * different ITS groups through IORT mappings this function has
+ * to be reworked to ensure we reserve regions for all ITS groups
+ * a given PCI or named component may map IDs to.
+ */
+ if (dev_is_pci(dev)) {
+ u32 rid;
+
+ pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+ its_node = iort_node_map_id(node, rid, NULL, IORT_MSI_TYPE);
+ } else {
+ for (i = 0; i < node->mapping_count; i++) {
+ its_node = iort_node_map_platform_id(node, NULL,
+ IORT_MSI_TYPE, i);
+ if (its_node)
+ break;
+ }
+ }
+
+ if (!its_node)
+ return 0;
+
+ /* Move to ITS specific data */
+ its = (struct acpi_iort_its_group *)its_node->node_data;
+
+ for (i = 0; i < its->its_count; i++) {
+ phys_addr_t base;
+
+ if (!iort_find_its_base(its->identifiers[i], &base)) {
+ int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ struct iommu_resv_region *region;
+
+ region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+ prot, IOMMU_RESV_MSI);
+ if (region) {
+ list_add_tail(®ion->list, head);
+ resv++;
+ }
+ }
+ }
+
+ return (resv == its->its_count) ? resv : -ENODEV;
+}
#else
static inline const struct iommu_ops *iort_fwspec_iommu_ops(
struct iommu_fwspec *fwspec)
@@ -789,6 +914,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
static inline int iort_add_device_replay(const struct iommu_ops *ops,
struct device *dev)
{ return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
#endif
static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4039e64..d4cff12 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
return -ENOMEM;
}
- err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+ err = iort_register_domain_token(its_entry->translation_id, res.start,
+ dom_handle);
if (err) {
pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
&res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 2f7a292..38cd77b 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
#define IORT_IRQ_MASK(irq) (irq & 0xffffffffULL)
#define IORT_IRQ_TRIGGER_MASK(irq) ((irq >> 32) & 0xffffffffULL)
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+ struct fwnode_handle *fw_node);
void iort_deregister_domain_token(int trans_id);
struct fwnode_handle *iort_find_domain_token(int trans_id);
#ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
/* IOMMU interface */
void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
#else
static inline void acpi_iort_init(void) { }
static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
static inline const struct iommu_ops *iort_iommu_configure(
struct device *dev)
{ return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return 0; }
#endif
#endif /* __ACPI_IORT_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH v10 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
From: Shameer Kolothum @ 2017-11-29 14:14 UTC (permalink / raw)
To: lorenzo.pieralisi-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robin.murphy-5wv7dgnIgG8, marc.zyngier-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Shameer Kolothum, guohanjun-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.
This patch implements an ACPI based quirk to reserve the hw msi regions
in the smmu-v3 driver which means these address regions will not be
translated and will be excluded from iova allocations.
To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve and reserve
the associated ITS base address from a device IORT node. The function
has a check for smmu model to determine whether the platform requires
the HW MSI reservation or not.
2. Added smmu node entries and explicitly disabled them in hip06/hip07
dts files so that users are warned about the non-DT support for this
erratum.
Changelog:
v9 --> v10
Addressed comments:
-Moved smmu model check to iort helper function to selectively apply
the msi reservation which will make the fn call generic from iommu-dma.
-Removed PCI blacklisting patch, instead added smmu nodes(disabled)
with comments to hip06/hip07 dts file.
v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS
translater region only.
-Removed the DT support for MSI reservation and blacklisted
HiSilicon PCIe controllers on DT based systems when SMMUv3 is
enabled.
v7 --> v8
Addressed comments from Rob and Lorenzo:
-Modified to use DT compatible string for errata.
-Changed logic to retrieve the msi-parent for DT case.
v6 --> v7
Addressed request from Will to add DT support for the erratum:
- added bt binding
- add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions
v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
is not applicable. Provided a generic function in iommu code and added
back the quirk implementation in SMMU v3 driver(patch#3)
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward
HW topologies are handled while reserving ITS regions(patch #1).
v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into
iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).
v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
iort helper function.
v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.
RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead of vendor specific CSRT table.
Shameer Kolothum (3):
ACPI/IORT: Add msi address regions reservation helper
iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 55 +++++++++++++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 24 ++++++
drivers/acpi/arm64/iort.c | 133 ++++++++++++++++++++++++++++++-
drivers/iommu/dma-iommu.c | 8 +-
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 +-
6 files changed, 224 insertions(+), 6 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller
From: Lorenzo Pieralisi @ 2017-11-29 14:14 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Cyrille Pitchen, bhelgaas, kishon, linux-pci, adouglas, stelford,
dgary, kgopi, eandrews, thomas.petazzoni, sureshp, nsekhar,
linux-kernel, robh, devicetree
In-Reply-To: <20171128204114.GE11228@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Nov 28, 2017 at 02:41:14PM -0600, Bjorn Helgaas wrote:
[...]
> > +static int cdns_pcie_parse_request_of_pci_ranges(struct device *dev,
> > + struct list_head *resources,
> > + struct resource **bus_range)
> > +{
> > + int err, res_valid = 0;
> > + struct device_node *np = dev->of_node;
> > + resource_size_t iobase;
> > + struct resource_entry *win, *tmp;
> > +
> > + err = of_pci_get_host_bridge_resources(np, 0, 0xff, resources, &iobase);
> > + if (err)
> > + return err;
> > +
> > + err = devm_request_pci_bus_resources(dev, resources);
> > + if (err)
> > + return err;
> > +
> > + resource_list_for_each_entry_safe(win, tmp, resources) {
> > + struct resource *res = win->res;
> > +
> > + switch (resource_type(res)) {
> > + case IORESOURCE_IO:
> > + err = pci_remap_iospace(res, iobase);
> > + if (err) {
> > + dev_warn(dev, "error %d: failed to map resource %pR\n",
> > + err, res);
> > + resource_list_destroy_entry(win);
> > + }
> > + break;
> > + case IORESOURCE_MEM:
> > + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > + break;
> > + case IORESOURCE_BUS:
> > + *bus_range = res;
> > + break;
> > + }
> > + }
> > +
> > + if (res_valid)
> > + return 0;
> > +
> > + dev_err(dev, "non-prefetchable memory resource required\n");
> > + return -EINVAL;
> > +}
>
> The code above is starting to look awfully familiar. I wonder if it's
> time to think about some PCI-internal interface that can encapsulate
> this. In this case, there's really nothing Cadence-specific here.
> There are other callers where there *is* vendor-specific code, but
> possibly that could be handled by returning pointers to bus number,
> I/O port, and MMIO resources so the caller could do the
> vendor-specific stuff?
Yes and that's not the only one, pattern below is duplicated
(with some minor differences across host bridges that I think
can be managed through function parameters), it is probably worth
moving them both into a core code helper.
list_splice_init(&resources, &bridge->windows);
bridge->dev.parent = dev;
bridge->busnr = bus;
bridge->ops = &pci_ops;
bridge->map_irq = of_irq_parse_and_map_pci;
bridge->swizzle_irq = pci_common_swizzle;
ret = pci_scan_root_bus_bridge(bridge);
if (ret < 0) {
dev_err(dev, "Scanning root bridge failed");
goto err_init;
}
bus = bridge->bus;
pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
list_for_each_entry(child, &bus->children, node)
pcie_bus_configure_settings(child);
pci_bus_add_devices(bus);
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAK8P3a2d2_jxXehE3xP_G9Tzp6jP4hFmS4CJkh=6bePLEDcdGw@mail.gmail.com>
2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> Hi Arnd,
>>>>
>>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>>>> +config CPU_CACHE_NONALIASING
>>>>>>>> + bool "Non-aliasing cache"
>>>>>>>> + help
>>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>>>> +
>>>>>>>> + If unsure, say Y.
>>>>>>>
>>>>>>> Can you determine this from the CPU type?
>>>>>>
>>>>>> There is no cpu register to determine it. It also depeneds on page
>>>>>> size and way size however page size is configurable by software.
>>>>>> These codes are determined at compile time will be benefit to code
>>>>>> size and performance.
>>>>>> IMHO, I think it would be better to be determined here.
>>>>>
>>>>> I meant determining it at compile time from other Kconfig symbols,
>>>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>>>> If they do, it could be done like
>>>>>
>>>>> menu "CPU selection"
>>>>>
>>>>> config CPU_N15
>>>>> bool "AndesCore N15"
>>>>> select CPU_CACHE_NONALIASING
>>>>>
>>>>> config CPU_N13
>>>>> bool "AndesCore N15"
>>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>>>
>>>>> ...
>>>>>
>>>>> endmenu
>>>>>
>>>>> and then you can use the same CPU_... symbols to make other decisions
>>>>> as well, e.g. CPU specific compiler optimizations.
>>>>
>>>> Do you want to support multiple CPU types in a single kernel image
>>>> (I see no "choice" statement above)?
>>>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>>>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>>>> instead.
>>>
>>> Right, my mistake.
>>>
>>
>> Thanks to Arnd and Geert!
>>
>> How about this?
>>
>> choice
>> prompt "CPU type"
>> default CPU_N13
>> config CPU_N15
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING
>> config CPU_N13
>> bool "AndesCore N13"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> config CPU_N10
>> bool "AndesCore N10"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> config CPU_D15
>> bool "AndesCore D15"
>> select CPU_CACHE_NONALIASING
>> select HWZOL
>> config CPU_D10
>> bool "AndesCore D10"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> endchoice
>
> With a 'choice' statement this works, but I would consider that
> suboptimal for another reason: now you cannot build a kernel that
> works on e.g. both N13 and N15.
>
> This is what we had on ARM a long time ago and on MIPS not so long
> ago, but it's really a burden for testing and distribution once you get
> support for more than a handful of machines supported in the mainline
> kernel: If each CPU core is mutually incompatible with the other ones,
> this means you likely end up having one defconfig per CPU core,
> or even one defconfig per SoC or board.
>
> I would always try to get the largest amount of hardware to work
> in the same kernel concurrently.
>
> One way of of this would be to define the "CPU type" as the minimum
> supported CPU, e.g. selecting D15 would result in a kernel that
> only works on D15, while selecting N15 would work on both N15 and
> D15, and selecting D10 would work on both D10 and D15.
>
Hi, Arnd:
Maybe we should keep the original implementation for this reason.
The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is
available for all CPU types for now.
User can use these configs built kernel to boot on almost all nds32 CPUs.
It might be a little bit weird if we config CPU_N10 but run on a N13 CPU.
This might confuse our users.
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-11-29 13:58 UTC (permalink / raw)
To: Rob Herring
Cc: Simon Horman, Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Magnus Damm, Arnd Bergmann, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqKffs+5s92kWFeDivdgk2mVBmHrKuNDCfR9Lb=te5k33A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Wed, Nov 29, 2017 at 2:35 PM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Nov 28, 2017 at 3:04 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>> On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
>>>> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>>> > I just noticed that with this patch applied I now see:
>>>> >
>>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
>>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53
>>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
>>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
>>>> >
>>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
>>>>
>>>> Right, the "interrupt-parent = <&gic>;" inside the /soc node applies to child
>>>> nodes of the /soc node only.
>>>>
>>>> You can find this in two ways:
>>
>> s/find/fix/
>>
>>>>
>>>> 1. Add "interrupt-parent = <&gic>;" to the /pmu_a57 and /pmu_a53 nodes.
>>>> 2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. turn
>>>>
>>>> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>>
>>>> into
>>>>
>>>> interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>>
>>>> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
>>>
>>> Thanks, I took option 1 as it seems consistent with the rest of the
>>> Renesas DT files. I also added it to the /timer node.
>>
>> Actually we recently had a discussion about this on IRC, triggered by a
>> similar issue in board files (see e.g, Ethernet PHY interrupts).
>>
>> Given the following comment:
>>
>> drivers/of/irq.c: /* Try the new-style interrupts-extended first */
>> drivers/of/irq.c: res = of_parse_phandle_with_args(device,
>> "interrupts-extended",
>>
>> I think it would be better to use interrupts-extended for individual/isolated
>> use outside the /soc node.
>
> I disagree. There's no point to use interrupts-extended unless you
> have 2 or more interrupt parents. Just set interrupt-parent in the
> root node.
The on-SoC devices (all under the /soc node, except for the weird ones without
reg properties that are now being moved out) all have "&gic" as their interrupt
parents.
Off-SoC devices use one of the on-SoC interrupt controllers for external
interrupts ("&irqc", "&irqpin", "&irqpin0", "&irqpin1"), or one of the on-SoC
GPIO controllers that can also serve external interrupts ("&gpioN").
For the latter, I think interrupts-extended definitely makes sense.
For the former (incl. the "pmu_aN" nodes discussed here), it is debatable.
But using interrupts-extended makes it easier to catch mistakes in board files,
as they will be flagged by dtc ("Missing interrupt-parent").
With interrupt-parent in the root node, they may go undetected.
If the tools can help us, I prefer to use them.
Do you agree?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 2/2] arm64: dts: orange-pi-zero-plus2: enable AP6212a WiFi/BT combo
From: Jagan Teki @ 2017-11-29 13:53 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
devicetree, linux-arm-kernel
In-Reply-To: <20171103195855.15283-3-geomatsi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Nov 4, 2017 at 1:28 AM, Sergey Matyukevich <geomatsi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Enable AP6212a WiFi/BT combo chip on orange-pi-zero-plus2 board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi REG_ON pin connected to gpio PA9: attach to mmc-pwrseq
> - WiFi HOST_WAKE pin connected to gpio PL7
> - BT is connected to UART1
>
> Signed-off-by: Sergey Matyukevich <geomatsi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../allwinner/sun50i-h5-orangepi-zero-plus2.dts | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
> index a42fd79a62a3..d415b7b67cce 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
> @@ -64,6 +64,13 @@
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + reset-gpios = <&pio 0 9 GPIO_ACTIVE_LOW>; /* PA9 */
> + post-power-on-delay-ms = <200>;
> + };
> };
>
> &mmc0 {
> @@ -75,6 +82,25 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins_a>;
> + vmmc-supply = <®_vcc3v3>;
> + vqmmc-supply = <®_vcc3v3>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&r_pio>;
> + interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>; /* PL7 */
> + interrupt-names = "host-wake";
> + };
> +};
Did you observe this issue, I'm using firmware from buildroot and
couldn't find any *.txt from brcm/ I believe we need ass text file for
firmware details, did you tried the same from BR?
Log:
[ 1.872235] mmc1: new high speed SDIO card at address 0001
[ 1.880919] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[ 1.908802] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
[ 1.927199] brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43430-sdio.txt failed with error -2
[ 2.963478] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
clkctl 0x50
[ 3.971888] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
clkctl 0x50
thanks!
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
--
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 v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: Andrew Lunn @ 2017-11-29 13:47 UTC (permalink / raw)
To: Souptick Joarder
Cc: Mark Rutland, linux-mips, devel, David Daney, netdev,
linux-kernel, ralf, Carlos Munoz, devicetree, Rob Herring,
Steven J. Hill, Greg Kroah-Hartman, Florian Fainelli, James Hogan,
David S. Miller
In-Reply-To: <CAFqt6zabdQhyjUc4WsjzJ6CxMr70H3V_JdipJVwRi8LuOG54tA@mail.gmail.com>
On Wed, Nov 29, 2017 at 04:00:01PM +0530, Souptick Joarder wrote:
Hi Souptick
Please trim the code when giving reviews. We don't want to have to
page through 8K lines of code it find a few comments mixed in. Just
keep the beginning of the function you are commented on to make the
context clear. Cut the rest.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] ARM: dts: uniphier: use macros in dt-bindings header
From: Masahiro Yamada @ 2017-11-29 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Linux Kernel Mailing List, Russell King,
Masahiro Yamada, Rob Herring
In-Reply-To: <1510896288-31212-1-git-send-email-yamada.masahiro@socionext.com>
2017-11-17 14:24 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> The dt-bindings header was applied to the driver subsystem. I had to
> wait for a merge window to use it from DT.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
Series, applied to linux-uniphier.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Rob Herring @ 2017-11-29 13:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Magnus Damm, Arnd Bergmann, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXoDNt7j-hEZmDA2BFFPUAfsi1ukZWowJ3=kTswyYMk5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 28, 2017 at 3:04 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Simon,
>
> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>> On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
>>> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>> > I just noticed that with this patch applied I now see:
>>> >
>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
>>> >
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
>>>
>>> Right, the "interrupt-parent = <&gic>;" inside the /soc node applies to child
>>> nodes of the /soc node only.
>>>
>>> You can find this in two ways:
>
> s/find/fix/
>
>>>
>>> 1. Add "interrupt-parent = <&gic>;" to the /pmu_a57 and /pmu_a53 nodes.
>>> 2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. turn
>>>
>>> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>
>>> into
>>>
>>> interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>
>>> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
>>
>> Thanks, I took option 1 as it seems consistent with the rest of the
>> Renesas DT files. I also added it to the /timer node.
>
> Actually we recently had a discussion about this on IRC, triggered by a
> similar issue in board files (see e.g, Ethernet PHY interrupts).
>
> Given the following comment:
>
> drivers/of/irq.c: /* Try the new-style interrupts-extended first */
> drivers/of/irq.c: res = of_parse_phandle_with_args(device,
> "interrupts-extended",
>
> I think it would be better to use interrupts-extended for individual/isolated
> use outside the /soc node.
I disagree. There's no point to use interrupts-extended unless you
have 2 or more interrupt parents. Just set interrupt-parent in the
root node.
Rob
--
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: [RFC 0/2] of: Add whitelist
From: Rob Herring @ 2017-11-29 13:31 UTC (permalink / raw)
To: Frank Rowand
Cc: Alan Tull, Pantelis Antoniou, Moritz Fischer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fpga-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <da4c9b29-eccc-6a67-291a-73a36c1598b5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 11/27/17 15:58, Alan Tull wrote:
>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>
>> For an overlay to be accepted, all of its targets are required to be
>> on a target node whitelist.
>>
>> Currently the only way I have to get on the whitelist is calling a
>> function to add a node. That works for fpga regions, but I think
>> other uses will need a way of having adding specific nodes from the
>> base device tree, such as by adding a property like 'allow-overlay;'
>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>> advice on where that particular code should go.
>>
>> Alan
>>
>> Alan Tull (2):
>> of: overlay: add whitelist
>> fpga: of region: add of-fpga-region to whitelist
>>
>> drivers/fpga/of-fpga-region.c | 9 ++++++
>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/of.h | 12 +++++++
>> 3 files changed, 94 insertions(+)
>>
>
> The plan was to use connectors to restrict where an overlay could be applied.
> I would prefer not to have multiple methods for accomplishing the same thing
> unless there is a compelling reason to do so.
Connector nodes need a mechanism to enable themselves, too. I don't
think connector nodes are going to solve every usecase.
Rob
--
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 v2 1/2] pinctrl: Allow a device to indicate when to force a state
From: Linus Walleij @ 2017-11-29 13:06 UTC (permalink / raw)
To: Florian Fainelli, ext Tony Lindgren
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Charles Keepax, Charles Keepax, Stephen Warren,
Andy Shevchenko, Al Cooper, bcm-kernel-feedback-list
In-Reply-To: <20171102231551.16220-2-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> It may happen that a device needs to force applying a state, e.g:
> because it only defines one state of pin states (default) but loses
> power/register contents when entering low power modes. Add a
> pinctrl_dev::flags bitmask to help describe future quirks and define
> PINCTRL_FLG_FORCE_STATE as such a settable flag.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
So if I understand correctly, the state is lost across
suspend/resume, correct?
Or are we even talking runtime PM runtime_suspend
and runtime_resume here?
> @@ -1197,9 +1197,21 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
> {
> struct pinctrl_setting *setting, *setting2;
> struct pinctrl_state *old_state = p->state;
> + bool force = false;
> int ret;
>
> - if (p->state == state)
> + if (p->state) {
> + list_for_each_entry(setting, &p->state->settings, node) {
> + if (setting->pctldev->flags & PINCTRL_FLG_FORCE_STATE)
> + force = true;
> + }
> + }
> +
> + /* Some controllers may want to force this operation when they define
> + * only one set of functions and lose power state, e.g: pinctrl-single
> + * with its pinctrl-single,low-power-state-loss property.
> + */
> + if (p->state == state && !force)
> return 0;
So the idea is we go and change the state even if we are in the right
state already, I understand that much.
But how is pinctrl_select_state() being called in the first place under
these circumstances?
If this comes from the resume() callback in .pm of the device driver,
would not the same thing be achived if you just set some mock
"sleep" state in suspend()? It could even have exactly the same settings
as the "default" state, as long as it is another state, the register
will be reprogrammed.
See further include/linux/pinctrl/pinctrl-state.h
Yours,
Linus Walleij
--
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 v2 2/2] pinctrl: Allow indicating loss of pin states during low-power
From: Linus Walleij @ 2017-11-29 13:01 UTC (permalink / raw)
To: Florian Fainelli, ext Tony Lindgren
Cc: linux-gpio, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Charles Keepax, Charles Keepax, Stephen Warren,
Andy Shevchenko, Al Cooper, bcm-kernel-feedback-list
In-Reply-To: <20171102231551.16220-3-f.fainelli@gmail.com>
On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose
> their register contents when entering their lower power state. In such a
> case, the pinctrl-single driver that is used will not be able to restore
> the power states without telling the core about it and having
> pinctrl_select_state() check for that.
>
> This patch adds a new optional boolean property that Device Tree can
> define in order to obtain exactly that and having the core pinctrl code
> take that into account.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Florian, I'm really sorry for losing track of this patch set, it's
important stuff and I see why systems are dependent on something
like this.
Tony: can you look at this from a pinctrl-single point of view?
This is the intended consumer: pinctrl-single users that lose the
hardware state over suspend/resume.
How do you see this working with other pinctrl-single users?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
From: Linus Walleij @ 2017-11-29 12:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171105234831.GA24822-g2DYL2Zd6BY@public.gmane.org>
On Mon, Nov 6, 2017 at 12:48 AM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>> This interrupt construction is similar to how we handle
>> interrupt controllers inside PCI bridges etc.
>
> Hi Linus
>
> Your interrupt handling is going in the right direction, but needs
> further work. The PHY interrupt is a phy property, so should be in the
> PHY node in device tree.
>
> The Marvell driver gives an example of this, and
> vf610-zii-dev-rev-c.dts is an example DT blob you can look at.
>
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> + port@0 {
>> + reg = <0>;
>> + label = "lan0";
>
> So here, you should have a
>
> phy-handle = <&phy0>;
>
> linking this MAC to the PHY connected to it.
I have the phy-handle in the ethernet controller. This RTL8366RB
thing is just one big PHY as far as I know. So to give the complete picture
this is what I have in my tree right now with the RTL8366RB as PHY
and Gemini ethernet (yeah I'm upstreaming that too...) as the ethernet
controller:
/* This is a RealTek RTL8366RB switch and PHY using SMI over GPIO */
switch {
compatible = "realtek,rtl8366rb";
reg = <0>;
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
realtek,disable-leds;
switch_intc: interrupt-controller {
/* GPIO 15 provides the interrupt */
interrupt-parent = <&gpio0>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
interrupt-parent = <&switch_intc>;
interrupts = <0>;
};
port@1 {
reg = <1>;
label = "lan1";
interrupt-parent = <&switch_intc>;
interrupts = <1>;
};
port@2 {
reg = <2>;
label = "lan2";
interrupt-parent = <&switch_intc>;
interrupts = <2>;
};
port@3 {
reg = <3>;
label = "lan3";
interrupt-parent = <&switch_intc>;
interrupts = <3>;
};
port@4 {
reg = <4>;
label = "wan";
interrupt-parent = <&switch_intc>;
interrupts = <12>;
};
phy0: port@5 {
reg = <5>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
ethernet@60000000 {
compatible = "cortina,gemini-ethernet";
reg = <0x60000000 0x4000>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
gmac0: port0 {
compatible = "cortina,gemini-ethernet-port";
reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */
<0x6000a000 0x2000>; /* Port 0 GMAC */
interrupt-parent = <&intcon>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
resets = <&syscon GEMINI_RESET_GMAC0>;
clocks = <&syscon GEMINI_CLK_GATE_GMAC0>;
clock-names = "PCLK";
phy-mode = "rgmii";
phy-handle = <&phy0>;
};
};
> And then an MDIO bus, listing the PHYs
>
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy0: phy@0 {
> reg = <0>;
> interrupt-parent = <&switch_intc>;
> interrupts = <0>;
> };
>
> It is here you list the interrupts. And the PHY subsystem will link
> the interrupt to the PHY when it enumerate the MDIO bus.
I do get that to work with a lot of standard PHY drivers
in drivers/net/phy, that assume they have an IRQ line from
device tree or board files.
However when PHY slave children are spawn from the
internal DSA MDIO bus interrupts are not assigned from the
device tree, so that is why I have a separate patch for that.
> You have most of the code already for implementing the MDIO bus. The
> rest you can probably borrow from the mv88e6xxx driver.
I have a working MDIO bus coming out directly from the SDA core,
so that part is fine. I also patched in the corresponding PHY driver
(a Realtek derivative for this DSA only, so just a few lines add
in the Realtek PHY driver) and it works fine.
I will repost the series as a non-RFC when I have all parts working
and illustrate with a few examples so you see how I set it up.
I hope I didn't turn the entire subsystem on its head or something...
Yours,
Linus Walleij
--
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 V2 8/9] PCI: tegra: Broadcast PME_turn_Off message before link goes to L2
From: Mikko Perttunen @ 2017-11-29 12:18 UTC (permalink / raw)
To: Manikanta Maddireddy, thierry.reding, jonathanh, robh+dt,
frowand.list, bhelgaas, rjw, tglx
Cc: vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm
In-Reply-To: <1511638333-22951-9-git-send-email-mmaddireddy@nvidia.com>
On 25.11.2017 21:32, Manikanta Maddireddy wrote:
> Per PCIe r3.0, sec 5.3.3.2.1, PCIe root port shoould broadcast PME_turn_Off
> message before PCIe link goes to L2. PME_turn_Off broadcast mechanism is
> implemented in AFI module. Each Tegra PCIe root port has its own
> PME_turn_Off and PME_TO_Ack bitmap in AFI_PME register, program this
> register to broadcast PME_turn_Off message.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> V2:
> * no change in this patch
>
> drivers/pci/host/pci-tegra.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index bbc2807bcd4a..b380958a3deb 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -155,6 +155,8 @@
> #define AFI_INTR_EN_FPCI_TIMEOUT (1 << 7)
> #define AFI_INTR_EN_PRSNT_SENSE (1 << 8)
>
> +#define AFI_PCIE_PME 0xf0
> +
> #define AFI_PCIE_CONFIG 0x0f8
> #define AFI_PCIE_CONFIG_PCIE_DISABLE(x) (1 << ((x) + 1))
> #define AFI_PCIE_CONFIG_PCIE_DISABLE_ALL 0xe
> @@ -315,6 +317,7 @@
> #define PADS_REFCLK_CFG_DRVI_SHIFT 12 /* 15:12 */
>
> #define LINK_RETRAIN_TIMEOUT 100000
> +#define PME_ACK_TIMEOUT 10000
>
> struct tegra_msi {
> struct msi_controller chip;
> @@ -1503,6 +1506,76 @@ static int tegra_pcie_put_resources(struct tegra_pcie *pcie)
> return 0;
> }
>
> +static inline u32 get_pme_turnoff_bitmap(struct tegra_pcie_port *port)
> +{
> + struct device *dev = port->pcie->dev;
> + struct device_node *np = dev->of_node;
> + int ret = 0;
> +
> + switch (port->index) {
> + case 0:
> + ret = 0;
> + case 1:
> + ret = 8;
> + case 2:
> + if (of_device_is_compatible(np, "nvidia,tegra30-pcie"))
> + ret = 16;
> + else
> + ret = 12;
> + }
> + return ret;
> +}
> +
> +static inline u32 get_pme_ack_bitmap(struct tegra_pcie_port *port)
> +{
> + struct device *dev = port->pcie->dev;
> + struct device_node *np = dev->of_node;
> + int ret = 0;
> +
> + switch (port->index) {
> + case 0:
> + ret = 5;
> + case 1:
> + ret = 10;
> + case 2:
> + if (of_device_is_compatible(np, "nvidia,tegra30-pcie"))
> + ret = 18;
> + else
> + ret = 14;
> + }
> + return ret;
> +}
From what I can tell, the port 2 bit is 12/14 on everything after
Tegra30 as well, so I don't think this actually works?
I think simpler would be to add a SoC data fields 'u8
pme_turnoff_bit[3]' and 'u8 pme_ack_bit[3]' and then set that
to '.pme_turnoff_bit = { 0, 8, 16 }' and so on.
> +
> +static void tegra_pcie_pme_turnoff(struct tegra_pcie_port *port)
> +{
> + struct tegra_pcie *pcie = port->pcie;
> + ktime_t deadline;
> + unsigned int data;
> +
> + data = afi_readl(pcie, AFI_PCIE_PME);
> + data |= (0x1 << get_pme_turnoff_bitmap(port));
> + afi_writel(pcie, data, AFI_PCIE_PME);
> +
> + deadline = ktime_add_us(ktime_get(), PME_ACK_TIMEOUT);
> + do {
> + data = afi_readl(pcie, AFI_PCIE_PME);
> + data &= (0x1 << get_pme_ack_bitmap(port));
> + udelay(1);
> + if (ktime_after(ktime_get(), deadline))
> + break;
> + } while (!data);
Since this is a normal MMIO read, we could replace the whole loop with a
call to readl_poll_timeout (or readl_relaxed_poll_timeout, or if we
really must delay and not sleep, readl_poll_timeout_atomic etc.) from
iopoll.h
int err;
u32 val;
err = readl_poll_timeout(pcie->afi + AFI_PCIE_PME, val,
val & (0x1 << pcie->soc->pme_ack_bit[port]),
1, PME_ACK_TIMEOUT);
if (err)
...
> +
> + if (data)
> + dev_err(pcie->dev, "PME Ack is not receieved on port: %d\n",
> + port->index);
> +
Typo here, s/receieved/received/
Cheers,
Mikko
> + usleep_range(10000, 11000);
> +
> + data = afi_readl(pcie, AFI_PCIE_PME);
> + data &= ~(0x1 << get_pme_turnoff_bitmap(port));
> + afi_writel(pcie, data, AFI_PCIE_PME);
> +}
> +
> static int tegra_msi_alloc(struct tegra_msi *chip)
> {
> int msi;
> @@ -2828,6 +2901,7 @@ static int tegra_pcie_remove(struct platform_device *pdev)
> {
> struct tegra_pcie *pcie = platform_get_drvdata(pdev);
> struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> + struct tegra_pcie_port *port, *tmp;
>
> if (IS_ENABLED(CONFIG_DEBUG_FS))
> tegra_pcie_debugfs_exit(pcie);
> @@ -2835,6 +2909,8 @@ static int tegra_pcie_remove(struct platform_device *pdev)
> pci_remove_root_bus(host->bus);
> if (IS_ENABLED(CONFIG_PCI_MSI))
> tegra_pcie_disable_msi(pcie);
> + list_for_each_entry_safe(port, tmp, &pcie->ports, list)
> + tegra_pcie_pme_turnoff(port);
> tegra_pcie_disable_ports(pcie);
> tegra_pcie_free_resources(pcie);
> tegra_pcie_disable_controller(pcie);
>
^ permalink raw reply
* Re: [PATCH V2 7/9] PCI: tegra: Add loadable kernel module support
From: Mikko Perttunen @ 2017-11-29 12:01 UTC (permalink / raw)
To: Manikanta Maddireddy, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511638333-22951-8-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 25.11.2017 21:32, Manikanta Maddireddy wrote:
> Implement remove callback function for Tegra PCIe driver to add
> loadable kernel module support. Change PCI_TEGRA config to tristate to
> allow pci-tegra driver to be build as a module.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> V2:
> * no change in this patch
>
> drivers/pci/host/Kconfig | 2 +-
> drivers/pci/host/pci-tegra.c | 31 ++++++++++++++++++++++++++++++-
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 38d12980db0f..6fd2a5937804 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -34,7 +34,7 @@ config PCI_FTPCI100
> default ARCH_GEMINI
>
> config PCI_TEGRA
> - bool "NVIDIA Tegra PCIe controller"
> + tristate "NVIDIA Tegra PCIe controller"
> depends on ARCH_TEGRA
> help
> Say Y here if you want support for the PCIe host controller found
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 7f7b8c9c1e84..bbc2807bcd4a 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -35,6 +35,7 @@
> #include <linux/irqdomain.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> +#include <linux/module.h>
> #include <linux/msi.h>
> #include <linux/of_address.h>
> #include <linux/of_pci.h>
> @@ -2720,6 +2721,12 @@ static int tegra_pcie_debugfs_init(struct tegra_pcie *pcie)
> return -ENOMEM;
> }
>
> +static void tegra_pcie_debugfs_exit(struct tegra_pcie *pcie)
> +{
> + debugfs_remove_recursive(pcie->debugfs);
> + pcie->debugfs = NULL;
> +}
> +
I think it's unnecessary to have a helper function for this - just
inline it in the remove function.
> static int tegra_pcie_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -2734,6 +2741,7 @@ static int tegra_pcie_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> pcie = pci_host_bridge_priv(host);
> + platform_set_drvdata(pdev, pcie);
>
> pcie->soc = of_device_get_match_data(dev);
> INIT_LIST_HEAD(&pcie->buses);
> @@ -2816,6 +2824,25 @@ static int tegra_pcie_probe(struct platform_device *pdev)
> return err;
> }
>
> +static int tegra_pcie_remove(struct platform_device *pdev)
> +{
> + struct tegra_pcie *pcie = platform_get_drvdata(pdev);
> + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> +
> + if (IS_ENABLED(CONFIG_DEBUG_FS))
> + tegra_pcie_debugfs_exit(pcie);
> + pci_stop_root_bus(host->bus);
> + pci_remove_root_bus(host->bus);
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + tegra_pcie_disable_msi(pcie);
> + tegra_pcie_disable_ports(pcie);
> + tegra_pcie_free_resources(pcie);
> + tegra_pcie_disable_controller(pcie);
> + tegra_pcie_put_resources(pcie);
> +
> + return 0;
> +}
> +
> static struct platform_driver tegra_pcie_driver = {
> .driver = {
> .name = "tegra-pcie",
> @@ -2823,5 +2850,7 @@ static struct platform_driver tegra_pcie_driver = {
> .suppress_bind_attrs = true,
> },
> .probe = tegra_pcie_probe,
> + .remove = tegra_pcie_remove,
> };
> -builtin_platform_driver(tegra_pcie_driver);
> +module_platform_driver(tegra_pcie_driver);
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH V2 6/9] PCI: tegra: free resources on probe failure
From: Mikko Perttunen @ 2017-11-29 11:59 UTC (permalink / raw)
To: Manikanta Maddireddy, thierry.reding, jonathanh, robh+dt,
frowand.list, bhelgaas, rjw, tglx
Cc: vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm
In-Reply-To: <1511638333-22951-7-git-send-email-mmaddireddy@nvidia.com>
On 25.11.2017 21:32, Manikanta Maddireddy wrote:
> tegra_pcie_probe() can fail in multiple instances, this patch takes care
> of freeing the resources which are allocated before probe fail.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> V2:
> * no change in this patch
>
> drivers/pci/host/pci-tegra.c | 102 ++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 86 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index e9b3ff95e259..7f7b8c9c1e84 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -701,14 +701,25 @@ static int tegra_pcie_request_resources(struct tegra_pcie *pcie)
> pci_add_resource(windows, &pcie->busn);
>
> err = devm_request_pci_bus_resources(dev, windows);
> - if (err < 0)
> + if (err < 0) {
> + pci_free_resource_list(windows);
> return err;
> + }
>
> pci_remap_iospace(&pcie->pio, pcie->io.start);
>
> return 0;
> }
>
> +static void tegra_pcie_free_resources(struct tegra_pcie *pcie)
> +{
> + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> + struct list_head *windows = &host->windows;
> +
> + pci_unmap_iospace(&pcie->pio);
> + pci_free_resource_list(windows);
> +}
> +
> static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
> {
> struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus);
> @@ -1109,29 +1120,40 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
> return 0;
> }
>
> -static void tegra_pcie_power_off(struct tegra_pcie *pcie)
> +static void tegra_pcie_disable_controller(struct tegra_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> const struct tegra_pcie_soc *soc = pcie->soc;
> int err;
>
> - /* TODO: disable and unprepare clocks? */
> -
> if (soc->program_uphy) {
> err = tegra_pcie_phy_power_off(pcie);
> if (err < 0)
> dev_err(dev, "failed to power off PHY(s): %d\n", err);
> }
> +}
> +
> +static void tegra_pcie_power_off(struct tegra_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + const struct tegra_pcie_soc *soc = pcie->soc;
> + int err;
>
> reset_control_assert(pcie->afi_rst);
> reset_control_assert(pcie->pex_rst);
>
> - if (!dev->pm_domain)
> - tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
> + clk_disable_unprepare(pcie->pll_e);
> + if (soc->has_cml_clk)
> + clk_disable_unprepare(pcie->cml_clk);
> + clk_disable_unprepare(pcie->afi_clk);
> + clk_disable_unprepare(pcie->pex_clk);
>
> err = regulator_bulk_disable(pcie->num_supplies, pcie->supplies);
> if (err < 0)
> dev_warn(dev, "failed to disable regulators: %d\n", err);
> +
> + if (!dev->pm_domain)
> + tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
> }
>
> static int tegra_pcie_power_on(struct tegra_pcie *pcie)
> @@ -1262,6 +1284,15 @@ static int tegra_pcie_phys_get_legacy(struct tegra_pcie *pcie)
> return 0;
> }
>
> +static void tegra_pcie_phys_put_legacy(struct tegra_pcie *pcie)
> +{
> + int err;
> +
> + err = phy_exit(pcie->phy);
> + if (err < 0)
> + dev_err(pcie->dev, "failed to teardown PHY: %d\n", err);
> +}
> +
> static struct phy *devm_of_phy_optional_get_index(struct device *dev,
> struct device_node *np,
> const char *consumer,
> @@ -1315,6 +1346,19 @@ static int tegra_pcie_port_get_phys(struct tegra_pcie_port *port)
> return 0;
> }
>
> +static void tegra_pcie_port_put_phys(struct tegra_pcie_port *port)
> +{
> + struct device *dev = port->pcie->dev;
> + unsigned int i;
> + int err;
> +
> + for (i = 0; i < port->lanes; i++) {
> + err = phy_exit(port->phys[i]);
> + if (err < 0)
> + dev_err(dev, "failed to teardown PHY#%u: %d\n", i, err);
> + }
> +}
> +
> static int tegra_pcie_phys_get(struct tegra_pcie *pcie)
> {
> const struct tegra_pcie_soc *soc = pcie->soc;
> @@ -1334,6 +1378,19 @@ static int tegra_pcie_phys_get(struct tegra_pcie *pcie)
> return 0;
> }
>
> +static void tegra_pcie_phys_put(struct tegra_pcie *pcie)
> +{
> + const struct tegra_pcie_soc *soc = pcie->soc;
> + struct device_node *np = pcie->dev->of_node;
> + struct tegra_pcie_port *port;
> +
> + if (!soc->has_gen2 || of_find_property(np, "phys", NULL) != NULL)
> + tegra_pcie_phys_put_legacy(pcie);
I think it would be nicer to just check if legacy_phy is true, since
tegra_pcie_phys_get_legacy sets it. That way we don't need to have the
complicated check in two places.
Mikko
> +
> + list_for_each_entry(port, &pcie->ports, list)
> + tegra_pcie_port_put_phys(port);
> +}
> +
> static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> @@ -1366,7 +1423,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
> err = tegra_pcie_power_on(pcie);
> if (err) {
> dev_err(dev, "failed to power up: %d\n", err);
> - return err;
> + goto phys_put;
> }
>
> pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
> @@ -1424,25 +1481,23 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
>
> poweroff:
> tegra_pcie_power_off(pcie);
> +phys_put:
> + if (soc->program_uphy)
> + tegra_pcie_phys_put(pcie);
> return err;
> }
>
> static int tegra_pcie_put_resources(struct tegra_pcie *pcie)
> {
> - struct device *dev = pcie->dev;
> const struct tegra_pcie_soc *soc = pcie->soc;
> - int err;
>
> if (pcie->irq > 0)
> free_irq(pcie->irq, pcie);
>
> tegra_pcie_power_off(pcie);
>
> - if (soc->program_uphy) {
> - err = phy_exit(pcie->phy);
> - if (err < 0)
> - dev_err(dev, "failed to teardown PHY: %d\n", err);
> - }
> + if (soc->program_uphy)
> + tegra_pcie_phys_put(pcie);
>
> return 0;
> }
> @@ -2371,6 +2426,16 @@ static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
> }
> }
>
> +static void tegra_pcie_disable_ports(struct tegra_pcie *pcie)
> +{
> + struct tegra_pcie_port *port, *tmp;
> +
> + reset_control_assert(pcie->pcie_xrst);
> +
> + list_for_each_entry_safe(port, tmp, &pcie->ports, list)
> + tegra_pcie_port_disable(port);
> +}
> +
> static void tegra_pcie_change_link_speed(struct tegra_pcie *pcie,
> struct pci_dev *pci_dev)
> {
> @@ -2691,7 +2756,7 @@ static int tegra_pcie_probe(struct platform_device *pdev)
>
> err = tegra_pcie_request_resources(pcie);
> if (err)
> - goto put_resources;
> + goto disable_controller;
>
> /* setup the AFI address translations */
> tegra_pcie_setup_translations(pcie);
> @@ -2700,7 +2765,7 @@ static int tegra_pcie_probe(struct platform_device *pdev)
> err = tegra_pcie_enable_msi(pcie);
> if (err < 0) {
> dev_err(dev, "failed to enable MSI support: %d\n", err);
> - goto put_resources;
> + goto free_resources;
> }
> }
>
> @@ -2741,6 +2806,11 @@ static int tegra_pcie_probe(struct platform_device *pdev)
> disable_msi:
> if (IS_ENABLED(CONFIG_PCI_MSI))
> tegra_pcie_disable_msi(pcie);
> + tegra_pcie_disable_ports(pcie);
> +free_resources:
> + tegra_pcie_free_resources(pcie);
> +disable_controller:
> + tegra_pcie_disable_controller(pcie);
> put_resources:
> tegra_pcie_put_resources(pcie);
> return err;
>
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 11:57 UTC (permalink / raw)
To: Greentime Hu
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAEbi=3cc8e__DnFKmTSMm9xQMx7CGu+1v3e55w8UekwnTTkw5Q@mail.gmail.com>
On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> Hi Arnd,
>>>
>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>>> +config CPU_CACHE_NONALIASING
>>>>>>> + bool "Non-aliasing cache"
>>>>>>> + help
>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>>> +
>>>>>>> + If unsure, say Y.
>>>>>>
>>>>>> Can you determine this from the CPU type?
>>>>>
>>>>> There is no cpu register to determine it. It also depeneds on page
>>>>> size and way size however page size is configurable by software.
>>>>> These codes are determined at compile time will be benefit to code
>>>>> size and performance.
>>>>> IMHO, I think it would be better to be determined here.
>>>>
>>>> I meant determining it at compile time from other Kconfig symbols,
>>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>>> If they do, it could be done like
>>>>
>>>> menu "CPU selection"
>>>>
>>>> config CPU_N15
>>>> bool "AndesCore N15"
>>>> select CPU_CACHE_NONALIASING
>>>>
>>>> config CPU_N13
>>>> bool "AndesCore N15"
>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>>
>>>> ...
>>>>
>>>> endmenu
>>>>
>>>> and then you can use the same CPU_... symbols to make other decisions
>>>> as well, e.g. CPU specific compiler optimizations.
>>>
>>> Do you want to support multiple CPU types in a single kernel image
>>> (I see no "choice" statement above)?
>>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>>> instead.
>>
>> Right, my mistake.
>>
>
> Thanks to Arnd and Geert!
>
> How about this?
>
> choice
> prompt "CPU type"
> default CPU_N13
> config CPU_N15
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING
> config CPU_N13
> bool "AndesCore N13"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> config CPU_N10
> bool "AndesCore N10"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> config CPU_D15
> bool "AndesCore D15"
> select CPU_CACHE_NONALIASING
> select HWZOL
> config CPU_D10
> bool "AndesCore D10"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> endchoice
With a 'choice' statement this works, but I would consider that
suboptimal for another reason: now you cannot build a kernel that
works on e.g. both N13 and N15.
This is what we had on ARM a long time ago and on MIPS not so long
ago, but it's really a burden for testing and distribution once you get
support for more than a handful of machines supported in the mainline
kernel: If each CPU core is mutually incompatible with the other ones,
this means you likely end up having one defconfig per CPU core,
or even one defconfig per SoC or board.
I would always try to get the largest amount of hardware to work
in the same kernel concurrently.
One way of of this would be to define the "CPU type" as the minimum
supported CPU, e.g. selecting D15 would result in a kernel that
only works on D15, while selecting N15 would work on both N15 and
D15, and selecting D10 would work on both D10 and D15.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: kernel @ 2017-11-29 11:55 UTC (permalink / raw)
To: Rob Herring
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Mark Rutland, linux-can,
devicetree
In-Reply-To: <20171126222528.i6quueqdmuj6le6g@rob-hp-laptop>
Hi Rob!
Thanks for all the effort - I shall incorporate those changes into V2.
> s/Microcip/Microchip/
> s/_/-/
>
>> + 0 = Start of Frame output
>> + default: 10
>> + - microchip,clock_div = <1|2>: internal clock divider - default 1
>> + - microchip,gpio_opendrain: gpio (int0,1) in open drain mode
>> + instead of default push/pull
>> + - microchip,int_opendrain: int pin in open drain mode
>> + instead of default push/pull
>
> IIRC, we have a standard property for this.
Would you know what that could be - I did a quick search for
standard properties, but could not find a definitive list…
The only thing I found in:
Documentation/devicetree/bindings/w1/w1-gpio.txt
is:
linux,open-drain
But there is also:
nvidia,open-drain
open_drain
open-drain
drive-open-drain (pinctrl)
st,irq-open-drain
Only the last is specific to the interrupt line and none to the other
GPIOs of the chip (txcan, GPIO) - and each can get set differently.
So how shall I implement that?
Thanks,
Martin
^ permalink raw reply
* Re: [PATCH v2 19/35] nds32: L2 cache support
From: Greentime Hu @ 2017-11-29 11:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAK8P3a2P+A55TyC_1bCj=sDjLZmpQoMptbZ59yd191fqdUstSA@mail.gmail.com>
Hi, Arnd:
2017-11-27 22:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> +
>> +#define L2C_R_REG(offset) __raw_readl(atl2c_base + offset)
>> +#define L2C_W_REG(offset, value) __raw_writel(value, atl2c_base + offset)
>
> __raw_readl() is generally not endian-safe, and might not have the barriers you
> require here. Could you use readl/writel here, and only fall back to
> readl_relaxed()/writel_relaxed() when you absolutely must avoid the barriers?
Thanks for your suggestions.
We will changed it to readl/writel
>> diff --git a/arch/nds32/kernel/atl2c.c b/arch/nds32/kernel/atl2c.c
>> new file mode 100644
>> index 0000000..dd87fc9
>> --- /dev/null
>> +++ b/arch/nds32/kernel/atl2c.c
>> +#include <linux/compiler.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_fdt.h>
>> +#include <linux/of_platform.h>
>> +#include <asm/l2_cache.h>
>
> If this is the only file that includes asm/l2_cache.h, then I'd simply
> move the entire
> contents in here, rather than having a separate file in the global namespace.
>
arch/nds32/mm/proc.c also includes this file so I will keep it.
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 11:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAK8P3a3yk7ww+LdQdL+wgz2wYrzXLSsj1PTdfK-qx013jdg4SQ@mail.gmail.com>
2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Arnd,
>>
>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>> +config CPU_CACHE_NONALIASING
>>>>>> + bool "Non-aliasing cache"
>>>>>> + help
>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>> +
>>>>>> + If unsure, say Y.
>>>>>
>>>>> Can you determine this from the CPU type?
>>>>
>>>> There is no cpu register to determine it. It also depeneds on page
>>>> size and way size however page size is configurable by software.
>>>> These codes are determined at compile time will be benefit to code
>>>> size and performance.
>>>> IMHO, I think it would be better to be determined here.
>>>
>>> I meant determining it at compile time from other Kconfig symbols,
>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>> If they do, it could be done like
>>>
>>> menu "CPU selection"
>>>
>>> config CPU_N15
>>> bool "AndesCore N15"
>>> select CPU_CACHE_NONALIASING
>>>
>>> config CPU_N13
>>> bool "AndesCore N15"
>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>
>>> ...
>>>
>>> endmenu
>>>
>>> and then you can use the same CPU_... symbols to make other decisions
>>> as well, e.g. CPU specific compiler optimizations.
>>
>> Do you want to support multiple CPU types in a single kernel image
>> (I see no "choice" statement above)?
>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>> instead.
>
> Right, my mistake.
>
Thanks to Arnd and Geert!
How about this?
choice
prompt "CPU type"
default CPU_N13
config CPU_N15
bool "AndesCore N15"
select CPU_CACHE_NONALIASING
config CPU_N13
bool "AndesCore N13"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
config CPU_N10
bool "AndesCore N10"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
config CPU_D15
bool "AndesCore D15"
select CPU_CACHE_NONALIASING
select HWZOL
config CPU_D10
bool "AndesCore D10"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
endchoice
^ permalink raw reply
* Re: [PATCH v6 03/17] mfd: madera: Add common support for Cirrus Logic Madera codecs
From: Richard Fitzgerald @ 2017-11-29 11:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, alsa-devel, Jason Cooper, devicetree,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring, linux-gpio, Mark Brown,
Thomas Gleixner, Lee Jones, Charles Keepax, Nikesh Oswal
In-Reply-To: <CACRpkdaxKjPd_k8tuO3R4+5LFT4_37zn6ruDRPd5j9xNAH4+Dw@mail.gmail.com>
On 29/11/17 10:18, Linus Walleij wrote:
> On Thu, Nov 23, 2017 at 6:13 PM, Richard Fitzgerald
> <rf@opensource.wolfsonmicro.com> wrote:
>
>> +config MFD_MADERA_I2C
>> + bool "Cirrus Logic Madera codecs with I2C"
>> + select MFD_MADERA
>> + select REGMAP_I2C
>> + depends on I2C
>> + depends on PINCTRL
>> + help
>> + Support for the Cirrus Logic Madera platform audio SoC
>> + core functionality controlled via I2C.
>> +
>> +config MFD_MADERA_SPI
>> + bool "Cirrus Logic Madera codecs with SPI"
>> + select MFD_MADERA
>> + select REGMAP_SPI
>> + depends on SPI_MASTER
>> + depends on PINCTRL
>> + help
>> + Support for the Cirrus Logic Madera platform audio SoC
>> + core functionality controlled via SPI.
>
> Why do the I2C and SPI subdrivers depend on PINCTRL?
>
> They sure don't seem to be using any pinctrl-specific APIs.
>
They require PINCTRL even if they don't call any functions on it because
the chip won't work correctly if there isn't a PINCTRL driver to apply
the correct pinmux configuration.
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH 2/2][RESEND] arm: dts: ls1021aqds: Add nand node for ifc controller
From: Prabhakar Kushwaha @ 2017-11-29 11:31 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Prabhakar Kushwaha, Jagdish Gediya
LS1021AQDS support NAND flash on IFC chip-select 2.
So add NAND node in device tree for IFC controller.
Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 9408753..2b37d04 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -239,6 +239,11 @@
device-width = <1>;
};
+ nand@2,0 {
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
fpga: board-control@3,0 {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
--
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
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