* [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Florian Fainelli, Bjorn Helgaas, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
- Add compatible strings for three more Broadcom STB chips: 7278, 7216,
7211 (STB version of RPi4).
- add new property 'brcm,scb-sizes'
- add new property 'resets'
- add new property 'reset-names'
- allow 'ranges' and 'dma-ranges' to have more than one item and update
the example to show this.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
.../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 8680a0f86c5a..66a7df45983d 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -14,7 +14,13 @@ allOf:
properties:
compatible:
- const: brcm,bcm2711-pcie # The Raspberry Pi 4
+ items:
+ - enum:
+ - brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm7211-pcie # Broadcom STB version of RPi4
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
+ - brcm,bcm7216-pcie # Broadcom 7216 Arm
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
reg:
maxItems: 1
@@ -34,10 +40,12 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
dma-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 6
clocks:
maxItems: 1
@@ -58,8 +66,30 @@ properties:
aspm-no-l0s: true
+ resets:
+ description: for "brcm,bcm7216-pcie", must be a valid reset
+ phandle pointing to the RESCAL reset controller provider node.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ reset-names:
+ items:
+ - const: rescal
+
+ brcm,scb-sizes:
+ description: (u32, u32) tuple giving the 64bit PCIe memory
+ viewport size of a memory controller. There may be up to
+ three controllers, and each size must be a power of two
+ with a size greater or equal to the amount of memory the
+ controller supports.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - items:
+ minItems: 2
+ maxItems: 6
+
required:
- reg
+ - ranges
- dma-ranges
- "#interrupt-cells"
- interrupts
@@ -93,7 +123,9 @@ examples:
msi-parent = <&pcie0>;
msi-controller;
ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
brcm,enable-ssc;
+ brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of multiple pfn offsets between cpu addrs and dma addrs. It is
similar to 'dma_pfn_offset' except that the offset chosen depends on the
cpu or dma address involved.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
drivers/usb/core/message.c | 3 ++
drivers/usb/core/usb.c | 3 ++
include/linux/device.h | 10 +++++-
include/linux/dma-direct.h | 10 ++++--
include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
kernel/dma/Kconfig | 13 ++++++++
7 files changed, 144 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 96d8cfb14a60..a01afffcde7d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
}
EXPORT_SYMBOL(of_io_request_and_map);
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ struct of_range_parser parser;
+ struct of_range range;
+ size_t r_size = (num_ranges + 1)
+ * sizeof(struct dma_pfn_offset_region);
+ struct dma_pfn_offset_region *r;
+
+ r = devm_kzalloc(dev, r_size, GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+ dev->dma_pfn_offset_map = r;
+ of_dma_range_parser_init(&parser, node);
+
+ /*
+ * Record all info for DMA ranges array. We could
+ * just use the of_range struct, but if we did that it
+ * would require more calculations for phys_to_dma and
+ * dma_to_phys conversions.
+ */
+ for_each_of_range(&parser, &range) {
+ r->cpu_beg = range.cpu_addr;
+ r->cpu_end = r->cpu_beg + range.size;
+ r->dma_beg = range.bus_addr;
+ r->dma_end = r->dma_beg + range.size;
+ r->pfn_offset = PFN_DOWN(range.cpu_addr)
+ - PFN_DOWN(range.bus_addr);
+ r++;
+ }
+ return 0;
+}
+#else
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ return 0;
+}
+#endif
+
/**
* of_dma_get_range - Get DMA range info
* @dev: device pointer; only needed for a corner case.
@@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
struct of_range_parser parser;
struct of_range range;
u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
+ bool dma_multi_pfn_offset = false;
+ int num_ranges = 0;
while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
@@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
+ num_ranges++;
if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) {
- pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
- /* Don't error out as we'd break some existing DTs */
- continue;
+ if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
+ pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
+ pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
+ /*
+ * Don't error out as we'd break some existing
+ * DTs that are using configs w/o
+ * CONFIG_DMA_PFN_OFFSET_MAP set.
+ */
+ continue;
+ }
+ dma_multi_pfn_offset = true;
}
dma_offset = range.cpu_addr - range.bus_addr;
@@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
dma_end = range.bus_addr + range.size;
}
+ if (dma_multi_pfn_offset) {
+ dma_offset = 0;
+ ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
+ if (ret)
+ return ret;
+ }
+
if (dma_start >= dma_end) {
ret = -EINVAL;
pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 6197938dcc2d..aaa3e58f5eb4 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
*/
intf->dev.dma_mask = dev->dev.dma_mask;
intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
+#endif
INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
intf->minor = -1;
device_initialize(&intf->dev);
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index f16c26dc079d..d2ed4d90e56e 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
*/
dev->dev.dma_mask = bus->sysdev->dma_mask;
dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
+#endif
set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
dev->state = USB_STATE_ATTACHED;
dev->lpm_disable_count = 1;
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..67a240ad4fc5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -493,6 +493,8 @@ struct dev_links_info {
* @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
* DMA limit than the device itself supports.
* @dma_pfn_offset: offset of DMA memory range relatively of RAM
+ * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are multiple
+ * pfn offsets for multiple dma-ranges.
* @dma_parms: A low level driver may set these to teach IOMMU code about
* segment limitations.
* @dma_pools: Dma pools (if dma'ble device).
@@ -578,7 +580,13 @@ struct device {
allocations such descriptors. */
u64 bus_dma_limit; /* upstream dma constraint */
unsigned long dma_pfn_offset;
-
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ const struct dma_pfn_offset_region *dma_pfn_offset_map;
+ /* Like dma_pfn_offset, but for
+ * the unlikely case of multiple
+ * offsets. If non-null, dma_pfn_offset
+ * will be set to 0. */
+#endif
struct device_dma_parameters *dma_parms;
struct list_head dma_pools; /* dma pools (if dma'ble) */
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 24b8684aa21d..03110a57eabc 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -14,15 +14,21 @@ extern unsigned int zone_dma_bits;
static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
{
dma_addr_t dev_addr = (dma_addr_t)paddr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_phys_addr(dev, paddr);
- return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
{
phys_addr_t paddr = (phys_addr_t)dev_addr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_dma_addr(dev, paddr);
- return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 330ad58fbf4d..91940bba2229 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -256,6 +256,52 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
size_t dma_direct_max_mapping_size(struct device *dev);
#ifdef CONFIG_HAS_DMA
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+struct dma_pfn_offset_region {
+ phys_addr_t cpu_beg;
+ phys_addr_t cpu_end;
+ dma_addr_t dma_beg;
+ dma_addr_t dma_end;
+ unsigned long pfn_offset;
+};
+
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (dma_addr >= m->dma_beg && dma_addr < m->dma_end)
+ return m->pfn_offset;
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (paddr >= m->cpu_beg && paddr < m->cpu_end)
+ return m->pfn_offset;
+ return 0;
+}
+#else /* CONFIG_DMA_PFN_OFFSET_MAP */
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ return 0;
+}
+#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
+
#include <asm/dma-mapping.h>
static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4c103a24e380..ceb7e5e8f501 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -195,3 +195,16 @@ config DMA_API_DEBUG_SG
is technically out-of-spec.
If unsure, say N.
+
+config DMA_PFN_OFFSET_MAP
+ bool "Uses a DMA range map to calculate PFN offset"
+ depends on PCIE_BRCMSTB
+ default n
+ help
+ Some devices have a dma-range that gets converted to
+ a dev->dma_pfn_offset value. This option is for the
+ atypical case of there being multiple dma-ranges requiring
+ multiple pfn offsets, which are selected from when
+ converting to phys to dma and vice versa.
+
+ If unsure, say N.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 08/14] of: Include a dev param in of_dma_get_range()
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
Currently there is only one caller of of_dma_get_range(). A struct device
*dev param is needed For implementing multiple dma offsets. This function
will still work if dev == NULL.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 4 +++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 ++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..96d8cfb14a60 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -920,6 +920,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
/**
* of_dma_get_range - Get DMA range info
+ * @dev: device pointer; only needed for a corner case.
* @np: device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr: pointer to store initial CPU address of DMA range
@@ -935,7 +936,8 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..ef6a741f9f0b 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -95,7 +95,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask, end;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(dev, np, &dma_addr, &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index edc682249c00..7a83d3a81ab6 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -158,11 +158,11 @@ extern int of_bus_n_addr_cells(struct device_node *np);
extern int of_bus_n_size_cells(struct device_node *np);
#ifdef CONFIG_OF_ADDRESS
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
#else
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size)
+static inline int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size)
{
return -ENODEV;
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Alan Stern, Andy Shevchenko, Corey Minyard, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:USB SUBSYSTEM, Mark Brown, Oliver Neukum,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson, Wolfram Sang
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
Jim Quinlan (14):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add bcm7278 reigister info
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Add bcm7278 PERST support
PCI: brcmstb: Add control of rescal reset
of: Include a dev param in of_dma_get_range()
device core: Add ability to handle multiple dma offsets
arm: dma-mapping: Invoke dma offset func if needed
PCI: brcmstb: Set internal memory viewport sizes
PCI: brcmstb: Accommodate MSI for older chips
PCI: brcmstb: Set bus max burst size by chip type
PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
.../bindings/pci/brcm,stb-pcie.yaml | 40 +-
arch/arm/include/asm/dma-mapping.h | 13 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/of/address.c | 69 ++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 +-
drivers/pci/controller/Kconfig | 3 +-
drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++---
drivers/usb/core/message.c | 3 +
drivers/usb/core/usb.c | 3 +
include/linux/device.h | 10 +-
include/linux/dma-direct.h | 10 +-
include/linux/dma-mapping.h | 46 ++
kernel/dma/Kconfig | 13 +
14 files changed, 559 insertions(+), 83 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v2 07/12] i2c: designware: Move Baytrail sem config to the platform if-clause
From: Serge Semin @ 2020-05-26 18:40 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Serge Semin, Alexey Malahov, Thomas Bogendoerfer, Paul Burton,
Ralf Baechle, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
Rob Herring, Frank Rowand, linux-mips, devicetree, Wolfram Sang,
Jean Delvare, Krzysztof Kozlowski, Max Staudt, Stefan Roese,
linux-i2c, linux-kernel
In-Reply-To: <f01b3082-082c-8ce9-d0f7-f9ff952a37bf@linux.intel.com>
On Mon, May 25, 2020 at 04:01:26PM +0300, Jarkko Nikula wrote:
> On 5/21/20 5:22 AM, Serge Semin wrote:
> > On Wed, May 20, 2020 at 03:16:14PM +0300, Jarkko Nikula wrote:
> > > On 5/10/20 12:50 PM, Serge Semin wrote:
> > > > Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> > > > platform driver. It's a bit confusing to see it's config in the menu at
> > > > some separated place with no reference to the platform code. Lets move the
> > > > config definition under the if-I2C_DESIGNWARE_PLATFORM clause. By doing so
> > > > the config menu will display the feature right below the DW I2C platform
> > > > driver item and will indent it to the right so signifying its belonging.
> > > >
> > > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > > > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > > > Cc: Paul Burton <paulburton@kernel.org>
> > > > Cc: Ralf Baechle <ralf@linux-mips.org>
> > > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Cc: Wolfram Sang <wsa@the-dreams.de>
> > > > Cc: Rob Herring <robh+dt@kernel.org>
> > > > Cc: Frank Rowand <frowand.list@gmail.com>
> > > > Cc: linux-mips@vger.kernel.org
> > > > Cc: devicetree@vger.kernel.org
> > > > ---
> > > > drivers/i2c/busses/Kconfig | 30 +++++++++++++++++-------------
> > > > 1 file changed, 17 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > > > index 368aa64e9266..ed6927c4c540 100644
> > > > --- a/drivers/i2c/busses/Kconfig
> > > > +++ b/drivers/i2c/busses/Kconfig
> > > > @@ -530,8 +530,8 @@ config I2C_DESIGNWARE_CORE
> > > > config I2C_DESIGNWARE_PLATFORM
> > > > tristate "Synopsys DesignWare Platform"
> > > > - select I2C_DESIGNWARE_CORE
> > > > depends on (ACPI && COMMON_CLK) || !ACPI
> > > > + select I2C_DESIGNWARE_CORE
> > > > help
> > > > If you say yes to this option, support will be included for the
> > > > Synopsys DesignWare I2C adapter.
> > > > @@ -539,6 +539,22 @@ config I2C_DESIGNWARE_PLATFORM
> > > > This driver can also be built as a module. If so, the module
> > > > will be called i2c-designware-platform.
> > > > +if I2C_DESIGNWARE_PLATFORM
> > > > +
> > > > +config I2C_DESIGNWARE_BAYTRAIL
> > > > + bool "Intel Baytrail I2C semaphore support"
> > > > + depends on ACPI
> > > > + depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> > > > + (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> > > > + help
> > > > + This driver enables managed host access to the PMIC I2C bus on select
> > > > + Intel BayTrail platforms using the X-Powers AXP288 PMIC. It allows
> > > > + the host to request uninterrupted access to the PMIC's I2C bus from
> > > > + the platform firmware controlling it. You should say Y if running on
> > > > + a BayTrail system using the AXP288.
> > > > +
> > > > +endif # I2C_DESIGNWARE_PLATFORM
> > > > +
> > >
> > > Is the added "if I2C_DESIGNWARE_PLATFORM" needed here? Should the "depends
> > > on" be enough?
> >
> > The idea was to add if-endif clause here for features possibly added sometime
> > in future. But using normal "depends on I2C_DESIGNWARE_PLATFORM" shall make
> > the config depicted as an indented sub-config as well. Would you like me to
> > remove the if-clause and use the depends on operator instead?
> >
> Yes, please remove it from this patch. Keeps this patch simpler and if some
> future feature needs it then that patch(set) is the right place to add it.
Agreed. I'll do this in v3.
-Sergey
>
> Jarkko
^ permalink raw reply
* Re: [PATCH v8 2/2] Device tree bindings for TI HDC20x0 humidity and temperature sensors
From: Rob Herring @ 2020-05-26 18:35 UTC (permalink / raw)
To: Eugene Zalkonnikov
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
development@norphonic.com, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, Mark Rutland
In-Reply-To: <3309CDF6-5DED-44E4-972B-6D741ABE541E@norphonic.com>
On Mon, May 18, 2020 at 07:22:54PM +0000, Eugene Zalkonnikov wrote:
> Device tree bindings for HDC2010/HDC2080 driver.
Bindings are for h/w devices, not drivers.
Run 'git log --oneline <path>' and follow convention for $subject lines.
(Hint: dt-bindings: iio: ...)
>
>
> Signed-off-by: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
>
> diff -uprN linux-5.3.8/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml linux-5.3.8_docs/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
> --- linux-5.3.8/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml 1970-01-01 01:00:00.000000000 +0100
> +++ linux-5.3.8_docs/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml 2020-04-24 17:50:58.213007228 +0200
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
GPL-2.0-only, not or-later please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/humidity/ti,hdc2010.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HDC2010/HDC2080 humidity and temperature iio sensors
> +
> +maintainers:
> + - Eugene Zaikonnikov <eugene.zaikonnikov@norophonic.com>
> +
> +description: |
> + Relative humidity and tempereature sensors on I2C bus
> +
> + Datasheets are available at:
> + http://www.ti.com/product/HDC2010/datasheet
> + http://www.ti.com/product/HDC2080/datasheet
> +
> +properties:
> + compatible:
> + enum:
> + - ti,hdc2010
> + - ti,hdc2080
> +
> + vdd-supply:
> + maxItems: 1
> +
> +required:
> + - compatible
> +
> +examples:
> + - |
> + i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + humidity@40 {
> + compatible = "ti,hdc2010";
> + reg = <0x40>;
Not documented.
> + };
> + };
>
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: phy: Add DT bindings for Xilinx ZynqMP PSGTR PHY
From: Rob Herring @ 2020-05-26 18:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Michal Simek, devicetree, Kishon Vijay Abraham I,
Anurag Kumar Vulisha, linux-kernel, Vinod Koul
In-Reply-To: <20200513172239.26444-2-laurent.pinchart@ideasonboard.com>
On Wed, 13 May 2020 20:22:37 +0300, Laurent Pinchart wrote:
> From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
>
> Add DT bindings for the Xilinx ZynqMP PHY. ZynqMP SoCs have a High Speed
> Processing System Gigabit Transceiver which provides PHY capabilities to
> USB, SATA, PCIE, Display Port and Ehernet SGMII controllers.
>
> Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes since v7:
>
> - Switch to GPL-2.0-only OR BSD-2-Clause
>
> Changes since v6:
>
> - Fixed specification of compatible-dependent xlnx,tx-termination-fix
> property
> - Dropped status property from example
> - Use 4 spaces to indent example
>
> Changes since v5:
>
> - Document clocks and clock-names properties
> - Document resets and reset-names properties
> - Replace subnodes with an additional entry in the PHY cells
> - Drop lane frequency PHY cell, replaced by reference clock phandle
> - Convert bindings to YAML
> - Reword the subject line
> - Drop Rob's R-b as the bindings have significantly changed
> - Drop resets and reset-names properties
> ---
> .../bindings/phy/xlnx,zynqmp-psgtr.yaml | 105 ++++++++++++++++++
> include/dt-bindings/phy/phy.h | 1 +
> 2 files changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 7/8] tpm: Add YAML schema for TPM TIS I2C options
From: Rob Herring @ 2020-05-26 18:31 UTC (permalink / raw)
To: amirmizi6
Cc: amir.mizinski, robh+dt, shmulik.hager, arnd, linux-kernel,
tmaimon77, christophe-h.richard, linux-integrity, Eyal.Cohen,
gcwilson, oshri.alkoby, oren.tanami, oshrialkoby85, jgg,
peterhuewe, kgoldman, Dan.Morav, gregkh, jarkko.sakkinen,
alexander.steffen, devicetree
In-Reply-To: <20200526141658.157801-8-amirmizi6@gmail.com>
On Tue, 26 May 2020 17:16:57 +0300, amirmizi6@gmail.com wrote:
> From: Amir Mizinski <amirmizi6@gmail.com>
>
> Added a YAML schema to support tpm tis i2c related dt-bindings for the I2c
> PTP based physical layer.
>
> This patch adds the documentation for corresponding device tree bindings of
> I2C based Physical TPM.
> Refer to the 'I2C Interface Definition' section in
> 'TCG PC Client PlatformTPMProfile(PTP) Specification' publication
> for specification.
>
> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com>
> ---
> .../bindings/security/tpm/tpm-tis-i2c.yaml | 50 ++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Rob Herring @ 2020-05-26 18:28 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
In-Reply-To: <20200523084103.31276-2-dongchun.zhu@mediatek.com>
On Sat, May 23, 2020 at 04:41:02PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 172 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..56f31b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: divider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as Digital I/O voltage supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as Analog voltage supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as Digital core voltage supply.
> +
> + powerdown-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
> + or Shutdown mode. As the line is active low, it should be
> + marked GPIO_ACTIVE_LOW.
Need to define how many GPIOs ('maxItems: 1')
> +
> + reset-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + RST_PD pin. If specified, it will be asserted during driver probe.
> + As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
Here too.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> + default: 0
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select, which is to control D-PHY
> + timing setting by adjusting MIPI clock voltage to improve the clock
> + driver capability.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # 20MHz - 30MHz
> + - 1 # 30MHz - 50MHz
> + - 2 # 50MHz - 75MHz
> + - 3 # 75MHz - 100MHz
> + - 4 # 100MHz - 130MHz
> + default: 3
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
Should have a description of what data the port has.
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + data-lanes:
> + maxItems: 1
> +
> + link-frequencies: true
> + remote-endpoint: true
> +
> + required:
> + - data-lanes
> + - link-frequencies
> + - remote-endpoint
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <4>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> +
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + data-lanes = <1>;
> + link-frequencies = /bits/ 64 <390000000>;
> + remote-endpoint = <&mipi_in_wcam>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
^ permalink raw reply
* Re: [PATCH v9 08/10] dt-bindings: ufs: Add DT binding documentation for ufs
From: Rob Herring @ 2020-05-26 18:08 UTC (permalink / raw)
To: Alim Akhtar
Cc: devicetree, linux-scsi, krzk, avri.altman, martin.petersen,
kwmad.kim, stanley.chu, cang, linux-samsung-soc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200514003914.26052-9-alim.akhtar@samsung.com>
On Thu, May 14, 2020 at 06:09:12AM +0530, Alim Akhtar wrote:
> This patch adds DT binding for samsung ufs hci
Subject should indicate this is for Samsung in some way.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> .../bindings/ufs/samsung,exynos-ufs.yaml | 91 +++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
>
> diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> new file mode 100644
> index 000000000000..eaa64cc32d52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC series UFS host controller Device Tree Bindings
> +
> +maintainers:
> + - Alim Akhtar <alim.akhtar@samsung.com>
> +
> +description: |
> + Each Samsung UFS host controller instance should have its own node.
> + This binding define Samsung specific binding other then what is used
> + in the common ufshcd bindings
> + [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +
> +properties:
> +
> + compatible:
> + enum:
> + - samsung,exynos7-ufs
> +
> + reg:
> + items:
> + - description: HCI register
> + - description: vendor specific register
> + - description: unipro register
> + - description: UFS protector register
> +
> + reg-names:
> + items:
> + - const: hci
> + - const: vs_hci
> + - const: unipro
> + - const: ufsp
> +
> + clocks:
> + maxItems: 2
maxItems is redundant.
> + items:
> + - description: ufs link core clock
> + - description: unipro main clock
> +
> + clock-names:
> + maxItems: 2
Here too.
> + items:
> + - const: core_clk
> + - const: sclk_unipro_main
> +
> + interrupts:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + maxItems: 1
What's the name? (Though a name is kind of pointless when there is only
1.)
With those fixed,
Reviewed-by: Rob Herring <robh@kernel.org>
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - phys
> + - phy-names
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/exynos7-clk.h>
> +
> + ufs: ufs@15570000 {
> + compatible = "samsung,exynos7-ufs";
> + reg = <0x15570000 0x100>,
> + <0x15570100 0x100>,
> + <0x15571000 0x200>,
> + <0x15572000 0x300>;
> + reg-names = "hci", "vs_hci", "unipro", "ufsp";
> + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clock_fsys1 ACLK_UFS20_LINK>,
> + <&clock_fsys1 SCLK_UFSUNIPRO20_USER>;
> + clock-names = "core_clk", "sclk_unipro_main";
> + pinctrl-names = "default";
> + pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
> + phys = <&ufs_phy>;
> + phy-names = "ufs-phy";
> + };
> +...
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v11 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
From: Rob Herring @ 2020-05-26 18:04 UTC (permalink / raw)
To: Xin Ji
Cc: devel, Dan Carpenter, Sam Ravnborg, Jernej Skrabec,
Nicolas Boichat, linux-kernel, Laurent Pinchart, Nicolas Boichat,
Pi-Hsun Shih, devicetree, Sheng Pan, David Airlie, Jonas Karlman,
dri-devel, Neil Armstrong, Andrzej Hajda
In-Reply-To: <393386c0a18753cb4b3f695348fe506a192ea82a.1589511894.git.xji@analogixsemi.com>
On Fri, 15 May 2020 13:49:20 +0800, Xin Ji wrote:
> anx7625: MIPI to DP transmitter DT schema
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v15 2/2] i2c: core: support bus regulator controlling in adapter
From: Grygorii Strashko @ 2020-05-26 18:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Bibby Hsieh, Wolfram Sang, Bartosz Golaszewski, linux-i2c,
Nicolas Boichat, srv_heupstream, Rob Herring, Mark Rutland,
linux-devicetree, Rafael J . Wysocki
In-Reply-To: <CAAFQd5Bx=zgsUAg7fA2jfsV_yFyPmnotTWEBEr2V3Nn5HO8qQQ@mail.gmail.com>
On 25/05/2020 14:34, Tomasz Figa wrote:
> Hi Grygorii,
>
> On Fri, May 22, 2020 at 7:59 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>>
>>
>>
>> On 19/05/2020 10:27, Bibby Hsieh wrote:
>>> Although in the most platforms, the bus power of i2c
>>> are alway on, some platforms disable the i2c bus power
>>> in order to meet low power request.
>>>
>>> We get and enable bulk regulator in i2c adapter device.
>>>
>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>>> ---
>>> drivers/i2c/i2c-core-base.c | 84 +++++++++++++++++++++++++++++++++++++
>>> include/linux/i2c.h | 2 +
>>> 2 files changed, 86 insertions(+)
>>>
>>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>>> index 5cc0b0ec5570..e1cc8d46bc51 100644
>>> --- a/drivers/i2c/i2c-core-base.c
>>> +++ b/drivers/i2c/i2c-core-base.c
>>> @@ -313,12 +313,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
>>> static int i2c_device_probe(struct device *dev)
>>> {
>>> struct i2c_client *client = i2c_verify_client(dev);
>>> + struct i2c_adapter *adap;
>>> struct i2c_driver *driver;
>>> int status;
>>>
>>> if (!client)
>>> return 0;
>>>
>>> + adap = client->adapter;
>>> driver = to_i2c_driver(dev->driver);
>>>
>>> client->irq = client->init_irq;
>>> @@ -378,6 +380,12 @@ static int i2c_device_probe(struct device *dev)
>>>
>>> dev_dbg(dev, "probe\n");
>>>
>>> + status = regulator_enable(adap->bus_regulator);
>>> + if (status < 0) {
>>> + dev_err(&adap->dev, "Failed to enable power regulator\n");
>>> + goto err_clear_wakeup_irq;
>>> + }
>>> +
>>> status = of_clk_set_defaults(dev->of_node, false);
>>> if (status < 0)
>>> goto err_clear_wakeup_irq;
>>> @@ -414,12 +422,14 @@ static int i2c_device_probe(struct device *dev)
>>> static int i2c_device_remove(struct device *dev)
>>> {
>>> struct i2c_client *client = i2c_verify_client(dev);
>>> + struct i2c_adapter *adap;
>>> struct i2c_driver *driver;
>>> int status = 0;
>>>
>>> if (!client || !dev->driver)
>>> return 0;
>>>
>>> + adap = client->adapter;
>>> driver = to_i2c_driver(dev->driver);
>>> if (driver->remove) {
>>> dev_dbg(dev, "remove\n");
>>> @@ -427,6 +437,8 @@ static int i2c_device_remove(struct device *dev)
>>> }
>>>
>>> dev_pm_domain_detach(&client->dev, true);
>>> + if (!pm_runtime_status_suspended(&client->dev))
>>> + regulator_disable(adap->bus_regulator);
>>
>> Not sure this check is correct.
>>
>> i2c_device_probe()
>> - regulator_enable - 1
>>
>> pm_runtime_get()
>> - regulator_enable - 2
>>
>
> I believe regulator_enable() wouldn't be called again, because the
> device was already active in probe. However, I've been having
> difficulties keeping track of runtime PM semantics under various
> circumstances (e.g. ACPI vs DT), so can't tell for sure anymore.
True.
I've found pretty useful:
- CONFIG_PM_ADVANCED_DEBUG
- bind/unbind
for such testing.
for regulators - num_users\x02 can be checked.
>
>> i2c_device_remove()
>> - pm_runtime_status_suspended() flase
>> - regulator_disable() - 1 --> still active?
>>
>> Sorry, I probably missing smth.
>>
>>>
>>> dev_pm_clear_wake_irq(&client->dev);
>>> device_init_wakeup(&client->dev, false);
>>> @@ -438,6 +450,72 @@ static int i2c_device_remove(struct device *dev)
>>> return status;
>>> }
>>>
>>
>> [...]
>>
>> --
>> Best regards,
>> grygorii
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH v15 02/11] dt-bindings: soc: Add MT8183 power dt-bindings
From: Rob Herring @ 2020-05-26 18:03 UTC (permalink / raw)
To: Weiyi Lu
Cc: Matthias Brugger, srv_heupstream, Fan Chen, linux-kernel,
Enric Balletbo Serra, linux-mediatek, linux-arm-kernel,
Sascha Hauer, Nicolas Boichat, devicetree, James Liao
In-Reply-To: <1590051985-29149-3-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:15 +0800, Weiyi Lu wrote:
> Add power dt-bindings of MT8183 and introduces "BASIC" and
> "SUBSYS" clock types in binding document.
> The "BASIC" type is compatible to the original power control with
> clock name [a-z]+[0-9]*, e.g. mm, vpu1.
> The "SUBSYS" type is used for bus protection control with clock
> name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
> And add an optional "mediatek,smi" property for phandle to smi-common
> node.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/soc/mediatek/scpsys.txt | 21 ++++++++++++++---
> include/dt-bindings/power/mt8183-power.h | 26 ++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 3 deletions(-)
> create mode 100644 include/dt-bindings/power/mt8183-power.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v15 01/11] dt-bindings: mediatek: Add property to mt8183 smi-common
From: Rob Herring @ 2020-05-26 18:02 UTC (permalink / raw)
To: Weiyi Lu
Cc: Matthias Brugger, devicetree, linux-kernel, Enric Balletbo Serra,
Nicolas Boichat, linux-mediatek, Fan Chen, linux-arm-kernel,
Sascha Hauer, srv_heupstream, James Liao
In-Reply-To: <1590051985-29149-2-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:14 +0800, Weiyi Lu wrote:
> For scpsys driver using regmap based syscon driver API.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ASoC: tlv320adcx140: Fix warnings when using W=1
From: Dan Murphy @ 2020-05-26 17:52 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai
Cc: alsa-devel, linux-kernel, devicetree, Dan Murphy,
kbuild test robot
Fix the warnings when using the W=1 compiler flag.
sound/soc/codecs/tlv320adcx140.c: In function ‘adcx140_reset’:
sound/soc/codecs/tlv320adcx140.c:570:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
570 | int ret = 0;
| ^~~
This was set but only used in case where the reset GPIO is not defined.
Have the function return the value of ret.
sound/soc/codecs/tlv320adcx140.c: In function ‘adcx140_codec_probe’:
sound/soc/codecs/tlv320adcx140.c:778:18: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
778 | if (bias_source < ADCX140_MIC_BIAS_VAL_VREF ||
| ^
sound/soc/codecs/tlv320adcx140.c:789:18: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
789 | if (vref_source < ADCX140_MIC_BIAS_VREF_275V ||
This condition will not occur since if the dt property is not set then
the *_source variable is set to the default value. So there is no way
that *_source can be less then 0. Which is what each #define is set to.
The code just needs to make sure that the dt property is not out of the
upper bounds.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
sound/soc/codecs/tlv320adcx140.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tlv320adcx140.c b/sound/soc/codecs/tlv320adcx140.c
index 472d759ba8a3..2fe0df3b7550 100644
--- a/sound/soc/codecs/tlv320adcx140.c
+++ b/sound/soc/codecs/tlv320adcx140.c
@@ -582,7 +582,7 @@ static int adcx140_reset(struct adcx140_priv *adcx140)
/* 8.4.2: wait >= 10 ms after entering sleep mode. */
usleep_range(10000, 100000);
- return 0;
+ return ret;
}
static int adcx140_hw_params(struct snd_pcm_substream *substream,
@@ -772,8 +772,7 @@ static int adcx140_codec_probe(struct snd_soc_component *component)
if (ret)
bias_source = ADCX140_MIC_BIAS_VAL_VREF;
- if (bias_source < ADCX140_MIC_BIAS_VAL_VREF ||
- bias_source > ADCX140_MIC_BIAS_VAL_AVDD) {
+ if (bias_source > ADCX140_MIC_BIAS_VAL_AVDD) {
dev_err(adcx140->dev, "Mic Bias source value is invalid\n");
return -EINVAL;
}
@@ -783,8 +782,7 @@ static int adcx140_codec_probe(struct snd_soc_component *component)
if (ret)
vref_source = ADCX140_MIC_BIAS_VREF_275V;
- if (vref_source < ADCX140_MIC_BIAS_VREF_275V ||
- vref_source > ADCX140_MIC_BIAS_VREF_1375V) {
+ if (vref_source > ADCX140_MIC_BIAS_VREF_1375V) {
dev_err(adcx140->dev, "Mic Bias source value is invalid\n");
return -EINVAL;
}
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v3 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-1-dmurphy@ti.com>
Add the internal delay values into the header and update the binding
with the internal delay properties.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index 5b69ef03bbf7..2971dd3fc039 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -64,6 +64,20 @@ properties:
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
+ rx-internal-delay-ps:
+ $ref: "#/properties/rx-internal-delay-ps"
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
+ tx-internal-delay-ps:
+ $ref: "#/properties/tx-internal-delay-ps"
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
required:
- reg
@@ -80,5 +94,7 @@ examples:
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance = "true";
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v3 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-1-dmurphy@ti.com>
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index ac471b60ed6a..70702a4ef5e8 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -143,6 +143,20 @@ properties:
Specifies the PHY management type. If auto is set and fixed-link
is not specified, it uses MDIO for management.
+ rx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable RX internal delays. This property is only
+ used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
+
+ tx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable TX internal delays. This property is only
+ used when the phy-mode or phy-connection-type is rgmii-id or rgmii-txid.
+
fixed-link:
allOf:
- if:
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v3 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-1-dmurphy@ti.com>
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/phy_device.c | 94 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 2 +
2 files changed, 96 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6b30d205642f..667b510c8810 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2661,6 +2661,100 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+static int phy_find_descending_delay(struct phy_device *phydev,
+ int *delay_values, int size, int int_delay)
+{
+ int i;
+
+ if (int_delay > delay_values[0] || int_delay < delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", int_delay);
+ return -EINVAL;
+ }
+
+ if (int_delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (int_delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (int_delay < delay_values[i - 1] &&
+ int_delay > delay_values[i]) {
+ if (int_delay - delay_values[i - 1] >
+ delay_values[i] - int_delay)
+ return i + 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ int_delay);
+ return -EINVAL;
+}
+
+static int phy_find_ascending_delay(struct phy_device *phydev,
+ int *delay_values, int size, int int_delay)
+{
+ int i;
+
+ if (int_delay < delay_values[0] || int_delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", int_delay);
+ return -EINVAL;
+ }
+
+ if (int_delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (int_delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (int_delay > delay_values[i - 1] &&
+ int_delay < delay_values[i]) {
+ if (int_delay - delay_values[i - 1] <
+ delay_values[i] - int_delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ int_delay);
+ return -EINVAL;
+}
+
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @int_delay: the internal delay to be looked up
+ * @descending: if the delay array is in descending order
+ *
+ * Returns the index within the array of internal delay passed in.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_delay_index(struct phy_device *phydev, int *delay_values, int size,
+ int int_delay, bool descending)
+{
+ if (int_delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return -EINVAL;
+
+ if (descending)
+ return phy_find_descending_delay(phydev, delay_values, size,
+ int_delay);
+
+ return phy_find_ascending_delay(phydev, delay_values, size, int_delay);
+}
+EXPORT_SYMBOL(phy_get_delay_index);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2bcdf19ed3b4..1ba2c132b635 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1408,6 +1408,8 @@ void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+int phy_get_delay_index(struct phy_device *phydev, int *delay_values,
+ int size, int delay, bool descending);
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v3 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-1-dmurphy@ti.com>
Add RGMII internal delay configuration for Rx and Tx.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83869.c | 91 +++++++++++++++++++++++++++++++++++++--
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..1c440e0c0d64 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,9 @@
#define DP83869_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83869_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* RGMIIDCTL */
+#define DP83869_RGMII_CLK_DELAY_SHIFT 4
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVED BIT(11)
@@ -78,9 +81,6 @@
#define DP83869_PHYCR_FIFO_DEPTH_MASK GENMASK(15, 12)
#define DP83869_PHYCR_RESERVED_MASK BIT(11)
-/* RGMIIDCTL bits */
-#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
-
/* IO_MUX_CFG bits */
#define DP83869_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
@@ -99,6 +99,10 @@
#define DP83869_OP_MODE_MII BIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500, 1750,
+ 2000, 2250, 2500, 2750, 3000, 3250,
+ 3500, 3750, 4000};
+
enum {
DP83869_PORT_MIRRORING_KEEP,
DP83869_PORT_MIRRORING_EN,
@@ -108,6 +112,8 @@ enum {
struct dp83869_private {
int tx_fifo_depth;
int rx_fifo_depth;
+ s32 rx_id_delay;
+ s32 tx_id_delay;
int io_impedance;
int port_mirroring;
bool rxctrl_strap_quirk;
@@ -218,6 +224,7 @@ static int dp83869_of_init(struct phy_device *phydev)
ret = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_STRAP_STS1);
if (ret < 0)
return ret;
+
if (ret & DP83869_STRAP_MIRROR_ENABLED)
dp83869->port_mirroring = DP83869_PORT_MIRRORING_EN;
else
@@ -232,6 +239,20 @@ static int dp83869_of_init(struct phy_device *phydev)
&dp83869->tx_fifo_depth))
dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
+ ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
+ &dp83869->rx_id_delay);
+ if (ret) {
+ dp83869->rx_id_delay = ret;
+ ret = 0;
+ }
+
+ ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
+ &dp83869->tx_id_delay);
+ if (ret) {
+ dp83869->tx_id_delay = ret;
+ ret = 0;
+ }
+
return ret;
}
#else
@@ -367,10 +388,45 @@ static int dp83869_configure_mode(struct phy_device *phydev,
return ret;
}
+static int dp83869_get_delay(struct phy_device *phydev)
+{
+ struct dp83869_private *dp83869 = phydev->priv;
+ int delay_size = ARRAY_SIZE(dp83869_internal_delay);
+ int tx_delay = 0;
+ int rx_delay = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
+ tx_delay = phy_get_delay_index(phydev,
+ &dp83869_internal_delay[0],
+ delay_size, dp83869->tx_id_delay,
+ false);
+ if (tx_delay < 0) {
+ phydev_err(phydev, "Tx internal delay is invalid\n");
+ return tx_delay;
+ }
+ }
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
+ rx_delay = phy_get_delay_index(phydev,
+ &dp83869_internal_delay[0],
+ delay_size, dp83869->rx_id_delay,
+ false);
+ if (rx_delay < 0) {
+ phydev_err(phydev, "Rx internal delay is invalid\n");
+ return rx_delay;
+ }
+ }
+
+ return rx_delay | tx_delay << DP83869_RGMII_CLK_DELAY_SHIFT;
+}
+
static int dp83869_config_init(struct phy_device *phydev)
{
struct dp83869_private *dp83869 = phydev->priv;
int ret, val;
+ int delay;
ret = dp83869_configure_mode(phydev, dp83869);
if (ret)
@@ -394,6 +450,35 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ if (phy_interface_is_rgmii(phydev)) {
+ ret = dp83869_get_delay(phydev);
+ if (ret < 0)
+ return ret;
+
+ delay = ret;
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
+ delay);
+ if (ret)
+ return ret;
+
+ val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
+ val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ val |= DP83869_RGMII_TX_CLK_DELAY_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ val |= DP83869_RGMII_RX_CLK_DELAY_EN;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,
+ val);
+ }
+
return ret;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v4 06/12] cpufreq: qcom: Update the bandwidth levels on frequency change
From: Sibi Sankar @ 2020-05-26 17:48 UTC (permalink / raw)
To: Viresh Kumar
Cc: sboyd, georgi.djakov, bjorn.andersson, saravanak, mka, nm, agross,
david.brown, robh+dt, mark.rutland, rjw, linux-arm-msm,
devicetree, linux-kernel, linux-pm, dianders, vincent.guittot,
amit.kucheria, ulf.hansson, lukasz.luba, sudeep.holla
In-Reply-To: <8fc5b72c9af6fd6a707a280cfc678677@codeaurora.org>
On 2020-05-05 12:49, Sibi Sankar wrote:
> On 2020-05-05 10:20, Viresh Kumar wrote:
>> On 05-05-20, 01:52, Sibi Sankar wrote:
>>> Add support to parse optional OPP table attached to the cpu node when
>>> the OPP bandwidth values are populated. This allows for scaling of
>>> DDR/L3 bandwidth levels with frequency change.
>>>
>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>
>> What about using opp_set_rate instead ?
>
> I can't use opp_set_rate since
> the cpu dev does not have a
> clock associated with it and the
> scaling is done through writing
> on perf state register.
Viresh,
https://patchwork.kernel.org/cover/11548479/
GPU driver uses Georgi's series
for scaling and will need a way to
remove the icc votes in the suspend
path, (this looks like a pattern
that might be used by other clients
as well) I could probably update
opp_set_bw to support removing bw
when NULL opp is specified. Similarly
opp_set_rate will need to support
set bw to 0 when set_rate is passed
0 as target freq for the same use case.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-26 17:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200523220741.GO610998@lunn.ch>
Andrew
On 5/23/20 5:07 PM, Andrew Lunn wrote:
>>> Any why is your PHY special, in that is does care about out of range
>>> delays, when others using new the new core helper don't?
>> We are not rounding to nearest here. Basically the helper works to find the
>> best match
>>
>> If the delay passed in is less than or equal to the smallest delay then
>> return the smallest delay index
>>
>> If the delay passed in is greater then the largest delay then return the max
>> delay index
> + /* Find an approximate index by looking up the table */
> + if (delay > delay_values[i - 1] &&
> + delay < delay_values[i]) {
> + if (delay - delay_values[i - 1] < delay_values[i] - delay)
> + return i - 1;
> + else
> + return i;
>
> This appears to round to the nearest value when it is not an exact
> match.
>
> The documentation is a hint to the DT developer what value to put in
> DT. By saying it rounders, the developer does not need to go digging
> through the source code to find an exact value, otherwise -EINVAL will
> be returned. They can just use the value the HW engineer suggested,
> and the PHY will pick whatever is nearest.
>
>> Not sure what you mean about this PHY being special. This helper is
>> not PHY specific.
> As you said, if out of range, the helper returns the top/bottom
> value. Your PHY is special, the top/bottom value is not good enough,
> you throw an error.
>
> The point of helpers is to give uniform behaviour. We have one line
> helpers, simply because they give uniform behaviour, rather than have
> each driver do it subtlety different. But it also means drivers should
> try to not add additional constraints over what the helper already
> has, unless it is actually required by the hardware.
>
>> After I think about this more I am thinking a helper may be over kill here
>> and the delay to setting should be done within the PHY driver itself
> The helper is useful, it will result in uniform handling of rounding
> between DT values and what the PHY can actually do. But please also
> move your range check and error message inside the helper.
I re-worked v3 to be a bit more of a helper and incorporated Florian's
and you comments
Dan
> Andrew
^ permalink raw reply
* [PATCH net-next v3 0/4] RGMII Internal delay common property
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
Hello
The RGMII internal delay is a common setting found in most RGMII capable PHY
devices. It was found that many vendor specific device tree properties exist
to do the same function. This creates a common property to be used for PHY's
that have tunable internal delays for the Rx and Tx paths.
Dan Murphy (4):
dt-bindings: net: Add tx and rx internal delays
net: phy: Add a helper to return the index for of the internal delay
dt-bindings: net: Add RGMII internal delay for DP83869
net: dp83869: Add RGMII internal delay configuration
.../bindings/net/ethernet-controller.yaml | 14 +++
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++
drivers/net/phy/dp83869.c | 91 +++++++++++++++++-
drivers/net/phy/phy_device.c | 94 +++++++++++++++++++
include/linux/phy.h | 2 +
5 files changed, 214 insertions(+), 3 deletions(-)
--
2.26.2
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mm-beacon: Fix voltages on LDO1 and LDO2
From: Daniel Baluta @ 2020-05-26 17:43 UTC (permalink / raw)
To: Adam Ford
Cc: linux-arm-kernel, aford, Rob Herring, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <20200526170939.104111-1-aford173@gmail.com>
On Tue, May 26, 2020 at 8:11 PM Adam Ford <aford173@gmail.com> wrote:
>
> LDO1 and LDO2 settings are wrong and case the voltage to go above the
> maximum level of 2.15V permitted by the SoC to 3.0V.
>
> This patch is based on work done on the i.MX8M Mini-EVK which utilizes
> the same fix.
>
> Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
No need for a new line between fixes and signed-off-by.
With that:
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* RE: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
From: Ben Levinsky @ 2020-05-26 17:40 UTC (permalink / raw)
To: Rob Herring
Cc: ohad@wizery.com, bjorn.andersson@linaro.org, Michal Simek,
Jolly Shah, Rajan Vaja, mark.rutland@arm.com,
linux-remoteproc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefano Stabellini
In-Reply-To: <20200511221755.GA13585@bogus>
Hi Rob,
The Xilinx R5 Remoteproc driver has been around for a long time -- admittedly we should have upstreamed it long ago. The driver in the current form is using an "classic" remoteproc device tree node as described here.
I am working with Stefano to come up with an appropriate System Device Tree representation but it is not going to be ready right away. Our preference would be to upstream the remoteproc node and driver in their current forms while system device tree is maturing.
Will also update as per your below comments in a v5 too.
Best Regards,
Ben Levinsky
-----Original Message-----
From: Rob Herring <robh@kernel.org>
Sent: Monday, May 11, 2020 3:18 PM
To: Ben Levinsky <BLEVINSK@xilinx.com>
Cc: ohad@wizery.com; bjorn.andersson@linaro.org; Michal Simek <michals@xilinx.com>; Jolly Shah <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>; mark.rutland@arm.com; linux-remoteproc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Jason Wu <j.wu@xilinx.com>; Jiaying Liang <jliang@xilinx.com>
Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
On Fri, Apr 24, 2020 at 10:36:09AM -0700, Ben Levinsky wrote:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
This needs to be sorted out as part of the system DT effort that Xilinx is working on. I can't see this binding co-existing with it.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@xilinx.com>
> Signed-off-by: Jason Wu <j.wu@xilinx.com>
> Signed-off-by: Wendy Liang <jliang@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> Changes since v2:
> - update zynqmp_r5 yaml parsing to not raise warnings for extra
> information in children of R5 node. The warning "node has a unit
> name, but no reg or ranges property" will still be raised though
> as this particular node is needed to describe the
> '#address-cells' and '#size-cells' information.
> Changes since 3:
> - remove warning '/example-0/rpu@ff9a0000/r5@0:
> node has a unit name, but no reg or ranges property'
> by adding reg to r5 node.
> ---
>
> .../remoteproc/xilinx,zynqmp-r5-remoteproc.yaml | 127 +++++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remotepr
> oc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> new file mode 100644
> index 0000000..41520b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-re
> +++ moteproc.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Xilinx R5 remote processor controller bindings
> +
> +description:
> + This document defines the binding for the remoteproc component that
> +loads and
> + boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> +
> +maintainers:
> + - Ed Mooring <ed.mooring@xilinx.com>
> + - Ben Levinsky <ben.levinsky@xilinx.com>
> +
> +properties:
> + compatible:
> + const: "xlnx,zynqmp-r5-remoteproc-1.0"
> +
> + core_conf:
> + description:
> + R5 core configuration (valid string - split or lock-step)
> + maxItems: 1
> +
> + interrupts:
> + description:
> + Interrupt mapping for remoteproc IPI. It is required if the
> + user uses the remoteproc driver with the RPMsg kernel driver.
> + maxItems: 6
> +
> + memory-region:
> + maxItems: 4
> + minItems: 4
> + pnode-id:
> + maxItems: 1
What is this?
[Ben Levinsky] I will description for this. This is used by the Xilinx power management code later on when configuring the RPU.
> + mboxes:
> + maxItems: 2
> + mbox-names:
> + maxItems: 2
> +
> + r5@0:
> + type: object
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + - pnode-id
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 {
> + no-map;
> + reg = <0x3ed40000 0x4000>;
> + };
> + rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
> + no-map;
> + reg = <0x3ed44000 0x4000>;
> + };
> + rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
> + no-map;
> + reg = <0x3ed48000 0x100000>;
> + };
> + rproc_0_reserved: rproc@3ed000000 {
> + no-map;
> + reg = <0x3ed00000 0x40000>;
> + };
> + };
> + rpu: rpu@ff9a0000 {
> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + core_conf = "split";
If split, then where is the 2nd core?
[Ben Levinsky] Will fix, I will add second core in v5.
> + reg = <0xFF9A0000 0x10000>;
> + r5_0: r5@0 {
Unit-addresses are based on 'reg' values.
[Ben Levinsky] Will fix this, thanks
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFF9A0100 0x1000>;
> + memory-region = <&rproc_0_reserved>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
> + pnode-id = <0x7>;
> + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
> + mbox-names = "tx", "rx";
> + tcm_0_a: tcm_0@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFFE00000 0x10000>;
> + pnode-id = <0xf>;
These nodes probably need some sort of compatible. And don't the TCMs have different addresses for R5 vs. the A cores?
[Ben Levinsky] I can add a compatible. The addressesing here is absolute (i.e. 0xffex-xxxx ) as it is used from point of view of A core here.
> + };
> + tcm_0_b: tcm_0@1 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0xFFE20000 0x10000>;
> + pnode-id = <0x10>;
> + };
> + };
> + };
> +
> +
> + zynqmp_ipi1 {
> + compatible = "xlnx,zynqmp-ipi-mailbox";
> + interrupt-parent = <&gic>;
> + interrupts = <0 29 4>;
> + xlnx,ipi-id = <7>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* APU<->RPU0 IPI mailbox controller */
> + ipi_mailbox_rpu0: mailbox@ff90000 {
> + reg = <0xff990600 0x20>,
> + <0xff990620 0x20>,
> + <0xff9900c0 0x20>,
> + <0xff9900e0 0x20>;
> + reg-names = "local_request_region",
> + "local_response_region",
> + "remote_request_region",
> + "remote_response_region";
> + #mbox-cells = <1>;
> + xlnx,ipi-id = <1>;
> + };
> + };
> +
> +...
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V7 6/7] spi: spi-qcom-qspi: Add interconnect support
From: Matthias Kaehlcke @ 2020-05-26 17:36 UTC (permalink / raw)
To: Akash Asthana
Cc: gregkh, agross, bjorn.andersson, wsa, broonie, mark.rutland,
robh+dt, linux-i2c, linux-spi, devicetree, swboyd, mgautam,
linux-arm-msm, linux-serial, dianders, msavaliy, evgreen
In-Reply-To: <1590497690-29035-7-git-send-email-akashast@codeaurora.org>
On Tue, May 26, 2020 at 06:24:49PM +0530, Akash Asthana wrote:
> Get the interconnect paths for QSPI device and vote according to the
> current bus speed of the driver.
>
> Signed-off-by: Akash Asthana <akashast@codeaurora.org>
> ---
> Changes in V2:
> - As per Bjorn's comment, introduced and using devm_of_icc_get API for getting
> path handle
> - As per Matthias comment, added error handling for icc_set_bw call
>
> Changes in V3:
> - No Change.
>
> Changes in V4:
> - As per Mark's comment move peak_bw guess as twice of avg_bw if
> nothing mentioned explicitly to ICC core.
>
> Changes in V5:
> - Add icc_enable/disable to power on/off call.
> - Save some non-zero avg/peak value to ICC core by calling geni_icc_set_bw
> from probe so that when resume/icc_enable is called NOC are running at
> some non-zero value.
>
> Changes in V6:
> - As per Matthias's comment made print statement consistent across driver
>
> Changes in V7:
> - As per Matthias's comment removed usage of peak_bw variable because we don't
> have explicit peak requirement, we were voting peak = avg and this can be
> tracked using single variable for avg bw.
> - As per Matthias's comment improved print log.
>
> drivers/spi/spi-qcom-qspi.c | 57 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c
> index 3c4f83b..092ac27 100644
> --- a/drivers/spi/spi-qcom-qspi.c
> +++ b/drivers/spi/spi-qcom-qspi.c
> @@ -2,6 +2,7 @@
> // Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
>
> #include <linux/clk.h>
> +#include <linux/interconnect.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/module.h>
> @@ -139,7 +140,9 @@ struct qcom_qspi {
> struct device *dev;
> struct clk_bulk_data *clks;
> struct qspi_xfer xfer;
> - /* Lock to protect xfer and IRQ accessed registers */
> + struct icc_path *icc_path_cpu_to_qspi;
> + unsigned int avg_bw_cpu;
I should have noticed this earlier, but the field isn't needed now that
we have icc_enable/disable(). The bandwidth is set in
qcom_qspi_transfer_one() and that's it.
From my side it would be fine to remove the field in a follow up patch,
to avoid respinning the series yet another time just for this.
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
^ 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