* Re: [PATCH v7 7/7] input: joystick: Add ADC attached joystick driver.
From: Paul Cercueil @ 2020-05-19 21:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Artur Rojek, Dmitry Torokhov, Rob Herring, Mark Rutland,
Jonathan Cameron, Heiko Stuebner, Ezequiel Garcia, linux-input,
devicetree, linux-iio, Linux Kernel Mailing List
In-Reply-To: <CAHp75VcChHOrxrqBM==-_SaTL4vSojKmRWvkNn-CHLH99pcAuQ@mail.gmail.com>
Hi Andy,
Le mar. 19 mai 2020 à 23:43, Andy Shevchenko
<andy.shevchenko@gmail.com> a écrit :
> On Sun, May 17, 2020 at 10:49 PM Artur Rojek <contact@artur-rojek.eu>
> wrote:
>>
>> Add a driver for joystick devices connected to ADC controllers
>> supporting the Industrial I/O subsystem.
>
> ...
>
>> +static int adc_joystick_handle(const void *data, void *private)
>> +{
>> + struct adc_joystick *joy = private;
>> + enum iio_endian endianness;
>> + int bytes, msb, val, i;
>> + bool sign;
>> +
>> + bytes = joy->chans[0].channel->scan_type.storagebits >> 3;
>> +
>> + for (i = 0; i < joy->num_chans; ++i) {
>> + endianness =
>> joy->chans[i].channel->scan_type.endianness;
>> + msb = joy->chans[i].channel->scan_type.realbits - 1;
>
>> + sign =
>> (tolower(joy->chans[i].channel->scan_type.sign) == 's');
>
> Do we need tolower()?
I'll answer this one:
The sign can be uppercase to specify that the value is sign-extended in
all the storage bits.
-Paul
>> +
>> + switch (bytes) {
>> + case 1:
>> + val = ((const u8 *)data)[i];
>> + break;
>> + case 2:
>> + if (endianness == IIO_BE)
>
>> + val = be16_to_cpu(((const u16
>> *)data)[i]);
>
> Yeah, you have to provide bitwise types to satisfy sparse.
> Maybe using *_to_cpup() will cure this.
>
>> + else if (endianness == IIO_LE)
>> + val = le16_to_cpu(((const u16
>> *)data)[i]);
>> + else /* IIO_CPU */
>> + val = ((const u16 *)data)[i];
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + val >>= joy->chans[i].channel->scan_type.shift;
>> + if (sign)
>> + val = sign_extend32(val, msb);
>> + else
>> + val &= GENMASK(msb, 0);
>> + input_report_abs(joy->input, joy->axes[i].code,
>> val);
>> + }
>> +
>> + input_sync(joy->input);
>> +
>> + return 0;
>> +}
>
> ...
>
>> + /* Count how many channels we got. NULL terminated. */
>> + while (joy->chans[joy->num_chans].indio_dev)
>> + joy->num_chans++;
>
> I don't see how useful this is. Why not simple do below...
>
>> + bits = joy->chans[0].channel->scan_type.storagebits;
>> + if (!bits || (bits > 16)) {
>> + dev_err(dev, "Unsupported channel storage size");
>> + return -EINVAL;
>> + }
>> + for (i = 1; i < joy->num_chans; ++i)
>> + if (joy->chans[i].channel->scan_type.storagebits !=
>> bits) {
>> + dev_err(dev, "Channels must have equal
>> storage size");
>> + return -EINVAL;
>> + }
>
> ...something like
>
> for (i = 0; joy->chans[i].indio_dev; i++) {
> bits = joy->chans[i].channel->scan_type.storagebits;
> if (bits ...) {
> ...error handling...
> }
> if (bits != joy->chans[0].channel->scan_type.storagebits) {
> ...second level of error handling...
> }
> }
>
> ...
>
>> +static const struct of_device_id adc_joystick_of_match[] = {
>> + { .compatible = "adc-joystick", },
>
>> + { },
>
> No need comma.
>
>> +};
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 7/7] input: joystick: Add ADC attached joystick driver.
From: Andy Shevchenko @ 2020-05-19 20:43 UTC (permalink / raw)
To: Artur Rojek
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Jonathan Cameron,
Paul Cercueil, Heiko Stuebner, Ezequiel Garcia, linux-input,
devicetree, linux-iio, Linux Kernel Mailing List
In-Reply-To: <20200517194904.34758-7-contact@artur-rojek.eu>
On Sun, May 17, 2020 at 10:49 PM Artur Rojek <contact@artur-rojek.eu> wrote:
>
> Add a driver for joystick devices connected to ADC controllers
> supporting the Industrial I/O subsystem.
...
> +static int adc_joystick_handle(const void *data, void *private)
> +{
> + struct adc_joystick *joy = private;
> + enum iio_endian endianness;
> + int bytes, msb, val, i;
> + bool sign;
> +
> + bytes = joy->chans[0].channel->scan_type.storagebits >> 3;
> +
> + for (i = 0; i < joy->num_chans; ++i) {
> + endianness = joy->chans[i].channel->scan_type.endianness;
> + msb = joy->chans[i].channel->scan_type.realbits - 1;
> + sign = (tolower(joy->chans[i].channel->scan_type.sign) == 's');
Do we need tolower()?
> +
> + switch (bytes) {
> + case 1:
> + val = ((const u8 *)data)[i];
> + break;
> + case 2:
> + if (endianness == IIO_BE)
> + val = be16_to_cpu(((const u16 *)data)[i]);
Yeah, you have to provide bitwise types to satisfy sparse.
Maybe using *_to_cpup() will cure this.
> + else if (endianness == IIO_LE)
> + val = le16_to_cpu(((const u16 *)data)[i]);
> + else /* IIO_CPU */
> + val = ((const u16 *)data)[i];
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + val >>= joy->chans[i].channel->scan_type.shift;
> + if (sign)
> + val = sign_extend32(val, msb);
> + else
> + val &= GENMASK(msb, 0);
> + input_report_abs(joy->input, joy->axes[i].code, val);
> + }
> +
> + input_sync(joy->input);
> +
> + return 0;
> +}
...
> + /* Count how many channels we got. NULL terminated. */
> + while (joy->chans[joy->num_chans].indio_dev)
> + joy->num_chans++;
I don't see how useful this is. Why not simple do below...
> + bits = joy->chans[0].channel->scan_type.storagebits;
> + if (!bits || (bits > 16)) {
> + dev_err(dev, "Unsupported channel storage size");
> + return -EINVAL;
> + }
> + for (i = 1; i < joy->num_chans; ++i)
> + if (joy->chans[i].channel->scan_type.storagebits != bits) {
> + dev_err(dev, "Channels must have equal storage size");
> + return -EINVAL;
> + }
...something like
for (i = 0; joy->chans[i].indio_dev; i++) {
bits = joy->chans[i].channel->scan_type.storagebits;
if (bits ...) {
...error handling...
}
if (bits != joy->chans[0].channel->scan_type.storagebits) {
...second level of error handling...
}
}
...
> +static const struct of_device_id adc_joystick_of_match[] = {
> + { .compatible = "adc-joystick", },
> + { },
No need comma.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v10] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: Doug Anderson @ 2020-05-19 20:38 UTC (permalink / raw)
To: Rakesh Pillai
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, LKML, Linux ARM
In-Reply-To: <1589914405-6674-1-git-send-email-pillair@codeaurora.org>
Hi,
On Tue, May 19, 2020 at 11:53 AM Rakesh Pillai <pillair@codeaurora.org> wrote:
>
> + wifi: wifi@18800000 {
> + compatible = "qcom,wcn3990-wifi";
> + reg = <0 0x18800000 0 0x800000>;
> + reg-names = "membase";
> + iommus = <&apps_smmu 0xc0 0x1>;
> + interrupts =
> + <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH /* CE0 */ >,
> + <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH /* CE1 */ >,
> + <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH /* CE2 */ >,
> + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH /* CE3 */ >,
> + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH /* CE4 */ >,
> + <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH /* CE5 */ >,
> + <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH /* CE6 */ >,
> + <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH /* CE7 */ >,
> + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH /* CE8 */ >,
> + <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH /* CE9 */ >,
> + <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH /* CE10 */>,
> + <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH /* CE11 */>;
> + memory-region = <&wlan_fw_mem>;
> + status = "disabled";
> + };
> +
> config_noc: interconnect@1500000 {
> compatible = "qcom,sc7180-config-noc";
> reg = <0 0x01500000 0 0x28000>;
For completeness sake, I'll also point out that the WiFi node is also
sorted incorrectly. 0x18800000 comes after 0x01500000.
-Doug
^ permalink raw reply
* [PATCH 09/15] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-19 20:34 UTC (permalink / raw)
To: james.quinlan, Nicolas Saenz Julienne
Cc: Rob Herring, Frank Rowand, Christoph Hellwig, Marek Szyprowski,
Robin Murphy, Greg Kroah-Hartman, Suzuki K Poulose,
Saravana Kannan, Heikki Krogerus, Rafael J. Wysocki, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:DMA MAPPING HELPERS
In-Reply-To: <20200519203419.12369-1-james.quinlan@broadcom.com>
The device variable 'dma_pfn_offset' is used to do a single
linear map between cpu addrs and dma addrs. The variable
'dma_map' is added to struct device to point to an array
of multiple offsets which is required for some devices.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 50 ++++++++++++++++++++++++++++++++++---
include/linux/device.h | 9 ++++++-
include/linux/dma-mapping.h | 44 ++++++++++++++++++++++++++++++++
kernel/dma/Kconfig | 12 +++++++++
4 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 96d8cfb14a60..7dfff618af6a 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -947,6 +947,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 +979,18 @@ 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;
+ dma_multi_pfn_offset = true;
+ if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
+ 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 that are using configs
+ * w/o CONFIG_DMA_PFN_OFFSET_MAP set.
+ */
+ continue;
+ }
}
dma_offset = range.cpu_addr - range.bus_addr;
@@ -991,6 +1001,40 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
dma_end = range.bus_addr + range.size;
}
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ if (dma_multi_pfn_offset) {
+ size_t r_size = (num_ranges + 1)
+ * sizeof(struct dma_pfn_offset_region);
+ struct dma_pfn_offset_region *r;
+
+ if (!dev)
+ return -EINVAL;
+
+ dma_offset = 0;
+ r = devm_kcalloc(dev, 1, r_size, GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+ dev->dma_offset_map = (const void *) 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++;
+ }
+ }
+#endif
+
if (dma_start >= dma_end) {
ret = -EINVAL;
pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..6cd916860b5f 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_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,12 @@ struct device {
allocations such descriptors. */
u64 bus_dma_limit; /* upstream dma constraint */
unsigned long dma_pfn_offset;
-
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ const void *dma_offset_map; /* Like dma_pfn_offset, but for
+ * the unlikely case of multiple
+ * offsets. If non-null, dma_pfn_offset
+ * will be 0. */
+#endif
struct device_dma_parameters *dma_parms;
struct list_head dma_pools; /* dma pools (if dma'ble) */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 330ad58fbf4d..288d8089faf7 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -256,6 +256,38 @@ 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_frm_dma_addr(const void *arr,
+ dma_addr_t dma_addr)
+{
+ const struct dma_pfn_offset_region *m;
+
+ for (m = arr; 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_frm_phys_addr(const void *arr,
+ phys_addr_t paddr)
+{
+ const struct dma_pfn_offset_region *m;
+
+ for (m = arr; m->cpu_end; m++)
+ if (paddr >= m->cpu_beg && paddr < m->cpu_end)
+ return m->pfn_offset;
+ 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)
@@ -575,6 +607,18 @@ static inline unsigned long dma_get_merge_boundary(struct device *dev)
{
return 0;
}
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+static inline unsigned long dma_pfn_offset_frm_dma_addr(const void *arr,
+ dma_addr_t dma_addr)
+{
+ return 0;
+}
+static inline unsigned long dma_pfn_offset_frm_phys_addr(const void *arr,
+ phys_addr_t paddr)
+{
+ return 0;
+}
+#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
#endif /* CONFIG_HAS_DMA */
static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4c103a24e380..b4c3de521bf9 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -195,3 +195,15 @@ 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"
+ 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 08/15] of: Include a dev param in of_dma_get_range()
From: Jim Quinlan @ 2020-05-19 20:34 UTC (permalink / raw)
To: james.quinlan, Nicolas Saenz Julienne
Cc: Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20200519203419.12369-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 03/15] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-05-19 20:34 UTC (permalink / raw)
To: james.quinlan, Nicolas Saenz Julienne
Cc: Jim Quinlan, Florian Fainelli,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Bjorn Helgaas,
Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:PCI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200519203419.12369-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 00/15] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-05-19 20:33 UTC (permalink / raw)
To: james.quinlan, Nicolas Saenz Julienne
Cc: open list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, 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, open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson
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 (15):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ahci_brcm: fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add compatibily of other chips
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Asserting PERST is different for 7278
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
dma-direct: Invoke dma offset func if needed
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 side by chip type
PCI: brcmstb: add compatilbe chips to match list
.../bindings/pci/brcm,stb-pcie.yaml | 40 +-
arch/arm/include/asm/dma-mapping.h | 17 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/of/address.c | 54 ++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 +-
drivers/pci/controller/Kconfig | 4 +-
drivers/pci/controller/pcie-brcmstb.c | 403 +++++++++++++++---
include/linux/device.h | 9 +-
include/linux/dma-direct.h | 16 +
include/linux/dma-mapping.h | 44 ++
kernel/dma/Kconfig | 12 +
12 files changed, 542 insertions(+), 81 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH] ARM64: dts: imx8mm-evk: Assigned clocks for audio plls
From: Tim Harvey @ 2020-05-19 20:29 UTC (permalink / raw)
To: S.j. Wang
Cc: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
dl-linux-imx, Anson Huang, Jacky Bai, Jun Li, Leonard Crestez,
Daniel Baluta, daniel.lezcano@linaro.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20191016103513.13088-1-shengjiu.wang@nxp.com>
On Wed, Oct 16, 2019 at 3:36 AM S.j. Wang <shengjiu.wang@nxp.com> wrote:
>
> Assign clocks and clock-rates for audio plls, that audio
> drivers can utilize them.
>
> Add dai-tdm-slot-num and dai-tdm-slot-width for sound-wm8524,
> that sai driver can generate correct bit clock.
>
> Fixes: 13f3b9fdef6c ("arm64: dts: imx8mm-evk: Enable audio codec wm8524")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 2 ++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 ++++++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> index f7a15f3904c2..13137451b438 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> @@ -62,6 +62,8 @@
>
> cpudai: simple-audio-card,cpu {
> sound-dai = <&sai3>;
> + dai-tdm-slot-num = <2>;
> + dai-tdm-slot-width = <32>;
> };
>
Shengjiu,
Can you explain the why dai-tdm-slot-width here is 32? I noticed when
I assigned that for an imx8mm board I'm working on (that uses a
tlv320aic3x codec) I ended up with the clock being off by a factor of
2 (audio playback was 2x too slow).
Best Regards,
Tim
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: r8a77980: condor/v3hsk: add QSPI flash support
From: Sergei Shtylyov @ 2020-05-19 20:14 UTC (permalink / raw)
To: Geert Uytterhoeven, devicetree, Rob Herring
Cc: linux-renesas-soc, Magnus Damm
In-Reply-To: <850d4a7b-4984-eb0f-de89-e5c39d61d19e@cogentembedded.com>
Define the Condor/V3HSK board dependent parts of the RPC-IF device node.
Add device nodes for Spansion S25FS512S SPI flash and MTD partitions on it.
Based on the original patches by Dmitry Shifrin.
Signed-off-by: Dmitry Shifrin <dmitry.shifrin@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- removed the "renesas,rpc-mode" prop from the RPC-IF device nodes;
- lowercased the hex numbers in the "reg" props and the <unit-address> parts
of the node names;
- removed the leading zeros from the <unit-address> parts of the node names;
- refreshed the patch.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 67 ++++++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 67 ++++++++++++++++++++++++
2 files changed, 134 insertions(+)
Index: renesas-devel/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas-devel.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas-devel/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -262,6 +262,11 @@
power-source = <1800>;
};
+ qspi0_pins: qspi0 {
+ groups = "qspi0_ctrl", "qspi0_data4";
+ function = "qspi0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
@@ -273,6 +278,68 @@
};
};
+&rpc {
+ pinctrl-0 = <&qspi0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "spansion,s25fs512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <4>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bootparam@0 {
+ reg = <0x00000000 0x040000>;
+ read-only;
+ };
+ cr7@40000 {
+ reg = <0x00040000 0x080000>;
+ read-only;
+ };
+ cert_header_sa3@c0000 {
+ reg = <0x000c0000 0x080000>;
+ read-only;
+ };
+ bl2@140000 {
+ reg = <0x00140000 0x040000>;
+ read-only;
+ };
+ cert_header_sa6@180000 {
+ reg = <0x00180000 0x040000>;
+ read-only;
+ };
+ bl31@1c0000 {
+ reg = <0x001c0000 0x460000>;
+ read-only;
+ };
+ uboot@640000 {
+ reg = <0x00640000 0x0c0000>;
+ read-only;
+ };
+ uboot-env@700000 {
+ reg = <0x00700000 0x040000>;
+ read-only;
+ };
+ dtb@740000 {
+ reg = <0x00740000 0x080000>;
+ };
+ kernel@7c0000 {
+ reg = <0x007c0000 0x1400000>;
+ };
+ user@1bc0000 {
+ reg = <0x01bc0000 0x2440000>;
+ };
+ };
+ };
+};
+
&rwdt {
timeout-sec = <60>;
status = "okay";
Index: renesas-devel/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas-devel.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas-devel/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -187,6 +187,11 @@
function = "i2c0";
};
+ qspi0_pins: qspi0 {
+ groups = "qspi0_ctrl", "qspi0_data4";
+ function = "qspi0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
@@ -198,6 +203,68 @@
};
};
+&rpc {
+ pinctrl-0 = <&qspi0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "spansion,s25fs512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <4>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bootparam@0 {
+ reg = <0x00000000 0x040000>;
+ read-only;
+ };
+ cr7@40000 {
+ reg = <0x00040000 0x080000>;
+ read-only;
+ };
+ cert_header_sa3@c0000 {
+ reg = <0x000c0000 0x080000>;
+ read-only;
+ };
+ bl2@140000 {
+ reg = <0x00140000 0x040000>;
+ read-only;
+ };
+ cert_header_sa6@180000 {
+ reg = <0x00180000 0x040000>;
+ read-only;
+ };
+ bl31@1c0000 {
+ reg = <0x001c0000 0x460000>;
+ read-only;
+ };
+ uboot@640000 {
+ reg = <0x00640000 0x0c0000>;
+ read-only;
+ };
+ uboot-env@700000 {
+ reg = <0x00700000 0x040000>;
+ read-only;
+ };
+ dtb@740000 {
+ reg = <0x00740000 0x080000>;
+ };
+ kernel@7c0000 {
+ reg = <0x007c0000 0x1400000>;
+ };
+ user@1bc0000 {
+ reg = <0x01bc0000 0x2440000>;
+ };
+ };
+ };
+};
+
&rwdt {
timeout-sec = <60>;
status = "okay";
^ permalink raw reply
* PATCH v2 1/2] arm64: dts: renesas: r8a77980: add RPC-IF support
From: Sergei Shtylyov @ 2020-05-19 20:13 UTC (permalink / raw)
To: Geert Uytterhoeven, devicetree, Rob Herring
Cc: linux-renesas-soc, Magnus Damm
In-Reply-To: <850d4a7b-4984-eb0f-de89-e5c39d61d19e@cogentembedded.com>
Describe RPC-IF in the R8A77980 device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- removed the R8A77970 part, renamed the patch, and updated the description;
- renamed the RPC-IF node to "spi@ee200000";
- updated the R8A77980 RPC-IF "compatible" prop to match the bindings;
- split the 1st region in the "reg"/"reg-names" props for the WBUF registers;
- refreshed the patch.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: renesas-devel/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas-devel.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas-devel/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -1344,6 +1344,23 @@
status = "disabled";
};
+ rpc: spi@ee200000 {
+ compatible = "renesas,r8a77980-rpc-if",
+ "renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee200000 0 0x200>,
+ <0 0x08000000 0 0x4000000>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f1010000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980 RPC-IF support
From: Sergei Shtylyov @ 2020-05-19 20:11 UTC (permalink / raw)
To: Geert Uytterhoeven, devicetree, Rob Herring
Cc: linux-renesas-soc, Magnus Damm
Hello!
Here's the set of 2 patches against Geert's 'renesas-devel.git' repo's
'renesas-devel-2020-06-18-v5.7-rc6' tag. I'm adding the RPC-IF device node
for R8A77980 (based on the RPC-IF driver) and describing the QSPI flashes
connected to RPC-IF on the Condor and V3H Starter Kit boards.
I've removed the R8A77970 parts in this version as the RPC-IF driver support
for that SoC isn't complete yet.
[1/2] arm64: dts: renesas: r8a77980: add RPC-IF support
[2/2] arm64: dts: renesas: r8a77980: condor/v3hsk: add QSPI flash support
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v10] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: Doug Anderson @ 2020-05-19 20:07 UTC (permalink / raw)
To: Rakesh Pillai
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, LKML, Linux ARM
In-Reply-To: <1589914405-6674-1-git-send-email-pillair@codeaurora.org>
Hi,
On Tue, May 19, 2020 at 11:53 AM Rakesh Pillai <pillair@codeaurora.org> wrote:
>
> Add device node for the ath10k SNOC platform driver probe
> and add resources required for WCN3990 on sc7180 soc.
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> ---
> Changes from v9:
> - Place the wlan_fw_mem under reserved-memory node
> ---
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 27 +++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 4e9149d..38b102e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -389,6 +389,13 @@
> };
> };
>
> +&wifi {
> + status = "okay";
> + wifi-firmware {
> + iommus = <&apps_smmu 0xc2 0x1>;
> + };
> +};
> +
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> &qspi_clk {
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index f1280e0..19bd7d0 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -106,6 +106,11 @@
> no-map;
> };
>
> + wlan_fw_mem: memory@94100000 {
> + reg = <0 0x94100000 0 0x200000>;
> + no-map;
> + };
> +
> rmtfs_mem: memory@84400000 {
> compatible = "qcom,rmtfs-mem";
> reg = <0x0 0x84400000 0x0 0x200000>;
This is less wrong than v9, but still a little wrong. You should be
keeping these ordered by unit address. 94100000 comes after 84400000.
-Doug
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: phy: dp83869: Update port-mirroring to read straps
From: Florian Fainelli @ 2020-05-19 20:03 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem; +Cc: netdev, linux-kernel, devicetree
In-Reply-To: <20200519141813.28167-2-dmurphy@ti.com>
On 5/19/2020 7:18 AM, Dan Murphy wrote:
> The device tree may not have the property set for port mirroring
> because the hardware may have it strapped. If the property is not in the
> DT then check the straps and set the port mirroring bit appropriately.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v8 09/10] dt-bindings: interconnect: Add interconnect-tags bindings
From: Saravana Kannan @ 2020-05-19 19:57 UTC (permalink / raw)
To: Rob Herring
Cc: Georgi Djakov, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rafael J. Wysocki, Sibi Sankar, Matthias Kaehlcke, Rajendra Nayak,
Bjorn Andersson, Vincent Guittot, Jordan Crouse, Evan Green,
Linux PM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML
In-Reply-To: <20200519185836.GA469006@bogus>
On Tue, May 19, 2020 at 11:58 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 12, 2020 at 03:53:26PM +0300, Georgi Djakov wrote:
> > From: Sibi Sankar <sibis@codeaurora.org>
> >
> > Add interconnect-tags bindings to enable passing of optional
> > tag information to the interconnect framework.
> >
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> > ---
> > v8:
> > * New patch, picked from here:
> > https://lore.kernel.org/r/20200504202243.5476-10-sibis@codeaurora.org
> >
> > .../devicetree/bindings/interconnect/interconnect.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > index 6f5d23a605b7..c1a226a934e5 100644
> > --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > @@ -55,6 +55,11 @@ interconnect-names : List of interconnect path name strings sorted in the same
> > * dma-mem: Path from the device to the main memory of
> > the system
> >
> > +interconnect-tags : List of interconnect path tags sorted in the same order as the
> > + interconnects property. Consumers can append a specific tag to
> > + the path and pass this information to the interconnect framework
> > + to do aggregation based on the attached tag.
>
> Why isn't this information in the 'interconnect' arg cells?
>
> We have 'interconnect-names' because strings don't mix with cells. An
> expanding list of 'interconnect-.*' is not a good pattern IMO.
Also, is there an example for interconnect-tags that I missed? Is it a
list of strings, numbers, etc?
-Saravana
^ permalink raw reply
* Re: [PATCH 01/11] ASoC: mmp-sspa: Flip SNDRV_PCM_FMTBIT_S24_3LE on
From: Mark Brown @ 2020-05-19 19:52 UTC (permalink / raw)
To: Liam Girdwood, Lubomir Rintel
Cc: Michael Turquette, linux-kernel, linux-clk, Stephen Boyd,
Rob Herring, linux-media, devicetree
In-Reply-To: <20200511210134.1224532-2-lkundrak@v3.sk>
On Mon, 11 May 2020 23:01:24 +0200, Lubomir Rintel wrote:
> The hw_params() callback handles the 3-byte format, not
> SNDRV_PCM_FMTBIT_S24_LE.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/2] ASoC: Add Marvell MMP SSPA binding
commit: d81bb8726c247c3e7719d21bf213c5400de29e03
[2/2] ASoC: mmp-sspa: Add Device Tree support
commit: a97e384ba78fd8bf7ba8c32718424d8a7536416e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v8 1/6] MIPS: JZ4780: Introduce SMP support.
From: Paul Cercueil @ 2020-05-19 19:41 UTC (permalink / raw)
To: 周琰杰
Cc: linux-mips, linux-kernel, devicetree, tsbogend, paulburton,
jiaxun.yang, chenhc, tglx, robh+dt, daniel.lezcano, keescook,
krzk, hns, ebiederm, dongsheng.qiu, yanfei.li, rick.tyliu,
sernia.zhou, zhenwenjin
In-Reply-To: <1589898923-60048-3-git-send-email-zhouyanjie@wanyeetech.com>
Hi Zhou,
Le mar. 19 mai 2020 à 22:35, 周琰杰 (Zhou Yanjie)
<zhouyanjie@wanyeetech.com> a écrit :
> Forward port smp support from kernel 3.18.3 of CI20_linux
> to upstream kernel 5.6.
>
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
> Tested-by: Paul Boddie <paul@boddie.org.uk>
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
>
> Notes:
> v1->v2:
> 1.Remove unnecessary "plat_irq_dispatch(void)" in irq-ingenic.c.
> 2.Add a timeout check for "jz4780_boot_secondary()" to avoid a
> dead loop.
> 3.Replace hard code in smp.c with macro.
>
> v2->v3:
> 1.Remove unnecessary "extern void (*r4k_blast_dcache)(void)" in
> smp.c.
> 2.Use "for_each_of_cpu_node" instead "for_each_compatible_node"
> in smp.c.
> 3.Use "of_cpu_node_to_id" instead "of_property_read_u32_index" in
> smp.c.
> 4.Move LCR related operations to jz4780-cgu.c.
>
> v3->v4:
> Rebase on top of kernel 5.6-rc1.
>
> v4->v5:
> 1.Splitting changes involving "jz4780-cgu.c" into separate commit.
> 2.Use "request_irq()" replace "setup_irq()".
>
> v5->v6:
> In order to have a kernel that works on multiple SoCs at the same
> time, use "IS_ENABLED()" replace "#ifdef".
>
> v6->v7:
> 1.SMP has be decoupled from the SoC version.
> 2.Add mailboxes 3 and 4 for XBurst.
> 3.Adjust code in "jz4780_smp_prepare_cpus()".
> 4."jz4780_smp_init()" has be marked "__init".
>
> v7->v8:
> No change.
>
> arch/mips/include/asm/mach-jz4740/smp.h | 87 +++++++++++
> arch/mips/jz4740/Kconfig | 2 +
> arch/mips/jz4740/Makefile | 5 +
> arch/mips/jz4740/prom.c | 4 +
> arch/mips/jz4740/smp-entry.S | 57 +++++++
> arch/mips/jz4740/smp.c | 258
> ++++++++++++++++++++++++++++++++
> arch/mips/kernel/idle.c | 35 ++++-
> 7 files changed, 447 insertions(+), 1 deletion(-)
> create mode 100644 arch/mips/include/asm/mach-jz4740/smp.h
> create mode 100644 arch/mips/jz4740/smp-entry.S
> create mode 100644 arch/mips/jz4740/smp.c
>
> diff --git a/arch/mips/include/asm/mach-jz4740/smp.h
> b/arch/mips/include/asm/mach-jz4740/smp.h
> new file mode 100644
> index 00000000..86f660f
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-jz4740/smp.h
> @@ -0,0 +1,87 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
> + * JZ4780 SMP definitions
> + */
> +
> +#ifndef __MIPS_ASM_MACH_JZ4740_SMP_H__
> +#define __MIPS_ASM_MACH_JZ4740_SMP_H__
> +
> +#define read_c0_corectrl() __read_32bit_c0_register($12, 2)
> +#define write_c0_corectrl(val) __write_32bit_c0_register($12, 2,
> val)
> +
> +#define read_c0_corestatus() __read_32bit_c0_register($12, 3)
> +#define write_c0_corestatus(val) __write_32bit_c0_register($12, 3,
> val)
> +
> +#define read_c0_reim() __read_32bit_c0_register($12, 4)
> +#define write_c0_reim(val) __write_32bit_c0_register($12, 4, val)
> +
> +#define read_c0_mailbox0() __read_32bit_c0_register($20, 0)
> +#define write_c0_mailbox0(val) __write_32bit_c0_register($20, 0,
> val)
> +
> +#define read_c0_mailbox1() __read_32bit_c0_register($20, 1)
> +#define write_c0_mailbox1(val) __write_32bit_c0_register($20, 1,
> val)
> +
> +#define read_c0_mailbox2() __read_32bit_c0_register($20, 2)
> +#define write_c0_mailbox2(val) __write_32bit_c0_register($20, 2,
> val)
> +
> +#define read_c0_mailbox3() __read_32bit_c0_register($20, 3)
> +#define write_c0_mailbox3(val) __write_32bit_c0_register($20, 3,
> val)
> +
> +#define smp_clr_pending(mask) do { \
> + unsigned int stat; \
> + stat = read_c0_corestatus(); \
> + stat &= ~((mask) & 0xff); \
> + write_c0_corestatus(stat); \
> + } while (0)
> +
> +/*
> + * Core Control register
> + */
> +#define CORECTRL_SLEEP1M_SHIFT 17
> +#define CORECTRL_SLEEP1M (_ULCAST_(0x1) << CORECTRL_SLEEP1M_SHIFT)
> +#define CORECTRL_SLEEP0M_SHIFT 16
> +#define CORECTRL_SLEEP0M (_ULCAST_(0x1) << CORECTRL_SLEEP0M_SHIFT)
> +#define CORECTRL_RPC1_SHIFT 9
> +#define CORECTRL_RPC1 (_ULCAST_(0x1) << CORECTRL_RPC1_SHIFT)
> +#define CORECTRL_RPC0_SHIFT 8
> +#define CORECTRL_RPC0 (_ULCAST_(0x1) << CORECTRL_RPC0_SHIFT)
> +#define CORECTRL_SWRST1_SHIFT 1
> +#define CORECTRL_SWRST1 (_ULCAST_(0x1) << CORECTRL_SWRST1_SHIFT)
> +#define CORECTRL_SWRST0_SHIFT 0
> +#define CORECTRL_SWRST0 (_ULCAST_(0x1) << CORECTRL_SWRST0_SHIFT)
> +
> +/*
> + * Core Status register
> + */
> +#define CORESTATUS_SLEEP1_SHIFT 17
> +#define CORESTATUS_SLEEP1 (_ULCAST_(0x1) << CORESTATUS_SLEEP1_SHIFT)
> +#define CORESTATUS_SLEEP0_SHIFT 16
> +#define CORESTATUS_SLEEP0 (_ULCAST_(0x1) << CORESTATUS_SLEEP0_SHIFT)
> +#define CORESTATUS_IRQ1P_SHIFT 9
> +#define CORESTATUS_IRQ1P (_ULCAST_(0x1) << CORESTATUS_IRQ1P_SHIFT)
> +#define CORESTATUS_IRQ0P_SHIFT 8
> +#define CORESTATUS_IRQ0P (_ULCAST_(0x1) << CORESTATUS_IRQ8P_SHIFT)
> +#define CORESTATUS_MIRQ1P_SHIFT 1
> +#define CORESTATUS_MIRQ1P (_ULCAST_(0x1) << CORESTATUS_MIRQ1P_SHIFT)
> +#define CORESTATUS_MIRQ0P_SHIFT 0
> +#define CORESTATUS_MIRQ0P (_ULCAST_(0x1) << CORESTATUS_MIRQ0P_SHIFT)
> +
> +/*
> + * Reset Entry & IRQ Mask register
> + */
> +#define REIM_ENTRY_SHIFT 16
> +#define REIM_ENTRY (_ULCAST_(0xffff) << REIM_ENTRY_SHIFT)
> +#define REIM_IRQ1M_SHIFT 9
> +#define REIM_IRQ1M (_ULCAST_(0x1) << REIM_IRQ1M_SHIFT)
> +#define REIM_IRQ0M_SHIFT 8
> +#define REIM_IRQ0M (_ULCAST_(0x1) << REIM_IRQ0M_SHIFT)
> +#define REIM_MBOXIRQ1M_SHIFT 1
> +#define REIM_MBOXIRQ1M (_ULCAST_(0x1) << REIM_MBOXIRQ1M_SHIFT)
> +#define REIM_MBOXIRQ0M_SHIFT 0
> +#define REIM_MBOXIRQ0M (_ULCAST_(0x1) << REIM_MBOXIRQ0M_SHIFT)
> +
> +extern void jz4780_smp_init(void);
> +extern void jz4780_secondary_cpu_entry(void);
> +
> +#endif /* __MIPS_ASM_MACH_JZ4740_SMP_H__ */
> diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
> index 412d2fa..2b88557 100644
> --- a/arch/mips/jz4740/Kconfig
> +++ b/arch/mips/jz4740/Kconfig
> @@ -34,9 +34,11 @@ config MACH_JZ4770
>
> config MACH_JZ4780
> bool
> + select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> select MIPS_CPU_SCACHE
> select SYS_HAS_CPU_MIPS32_R2
> select SYS_SUPPORTS_HIGHMEM
> + select SYS_SUPPORTS_SMP
>
> config MACH_X1000
> bool
> diff --git a/arch/mips/jz4740/Makefile b/arch/mips/jz4740/Makefile
> index 6de14c0..0a0f024 100644
> --- a/arch/mips/jz4740/Makefile
> +++ b/arch/mips/jz4740/Makefile
> @@ -12,3 +12,8 @@ CFLAGS_setup.o =
> -I$(src)/../../../scripts/dtc/libfdt
> # PM support
>
> obj-$(CONFIG_PM) += pm.o
> +
> +# SMP support
> +
> +obj-$(CONFIG_SMP) += smp.o
> +obj-$(CONFIG_SMP) += smp-entry.o
> diff --git a/arch/mips/jz4740/prom.c b/arch/mips/jz4740/prom.c
> index ff4555c..4acf5c2c 100644
> --- a/arch/mips/jz4740/prom.c
> +++ b/arch/mips/jz4740/prom.c
> @@ -8,10 +8,14 @@
>
> #include <asm/bootinfo.h>
> #include <asm/fw/fw.h>
> +#include <asm/mach-jz4740/smp.h>
>
> void __init prom_init(void)
> {
> fw_init_cmdline();
> +
> + if (IS_ENABLED(CONFIG_SMP))
> + jz4780_smp_init();
> }
>
> void __init prom_free_prom_memory(void)
> diff --git a/arch/mips/jz4740/smp-entry.S
> b/arch/mips/jz4740/smp-entry.S
> new file mode 100644
> index 00000000..20049a3
> --- /dev/null
> +++ b/arch/mips/jz4740/smp-entry.S
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
> + * JZ4780 SMP entry point
> + */
> +
> +#include <asm/addrspace.h>
> +#include <asm/asm.h>
> +#include <asm/asmmacro.h>
> +#include <asm/cacheops.h>
> +#include <asm/mipsregs.h>
> +
> +#define CACHE_SIZE (32 * 1024)
> +#define CACHE_LINESIZE 32
> +
> +.extern jz4780_cpu_entry_sp
> +.extern jz4780_cpu_entry_gp
> +
> +.section .text.smp-entry
> +.balign 0x10000
> +.set noreorder
> +LEAF(jz4780_secondary_cpu_entry)
> + mtc0 zero, CP0_CAUSE
> +
> + li t0, ST0_CU0
> + mtc0 t0, CP0_STATUS
> +
> + /* cache setup */
> + li t0, KSEG0
> + ori t1, t0, CACHE_SIZE
> + mtc0 zero, CP0_TAGLO, 0
> +1: cache Index_Store_Tag_I, 0(t0)
> + cache Index_Store_Tag_D, 0(t0)
> + bne t0, t1, 1b
> + addiu t0, t0, CACHE_LINESIZE
> +
> + /* kseg0 cache attribute */
> + mfc0 t0, CP0_CONFIG, 0
> + ori t0, t0, CONF_CM_CACHABLE_NONCOHERENT
> + mtc0 t0, CP0_CONFIG, 0
> +
> + /* pagemask */
> + mtc0 zero, CP0_PAGEMASK, 0
> +
> + /* retrieve sp */
> + la t0, jz4780_cpu_entry_sp
> + lw sp, 0(t0)
> +
> + /* retrieve gp */
> + la t0, jz4780_cpu_entry_gp
> + lw gp, 0(t0)
> +
> + /* jump to the kernel in kseg0 */
> + la t0, smp_bootstrap
> + jr t0
> + nop
> + END(jz4780_secondary_cpu_entry)
> diff --git a/arch/mips/jz4740/smp.c b/arch/mips/jz4740/smp.c
> new file mode 100644
> index 00000000..d95d22a
> --- /dev/null
> +++ b/arch/mips/jz4740/smp.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
> + * JZ4780 SMP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/sched.h>
> +#include <linux/sched/task_stack.h>
> +#include <linux/smp.h>
> +#include <linux/tick.h>
> +#include <asm/mach-jz4740/smp.h>
> +#include <asm/smp-ops.h>
> +
> +static struct clk *cpu_clock_gates[CONFIG_NR_CPUS] = { NULL };
> +
> +u32 jz4780_cpu_entry_sp;
> +u32 jz4780_cpu_entry_gp;
> +
> +static struct cpumask cpu_running;
This cpumask is written, but never read anywhere. Since it's static, I
believe it's dead code.
> +
> +static DEFINE_SPINLOCK(smp_lock);
> +
> +static irqreturn_t mbox_handler(int irq, void *dev_id)
> +{
> + int cpu = smp_processor_id();
> + u32 action, status;
> +
> + spin_lock(&smp_lock);
> +
> + switch (cpu) {
> + case 0:
> + action = read_c0_mailbox0();
> + write_c0_mailbox0(0);
> + break;
> + case 1:
> + action = read_c0_mailbox1();
> + write_c0_mailbox1(0);
> + break;
> + case 2:
> + action = read_c0_mailbox2();
> + write_c0_mailbox2(0);
> + break;
> + case 3:
> + action = read_c0_mailbox3();
> + write_c0_mailbox3(0);
> + break;
> + default:
> + panic("unhandled cpu %d!", cpu);
> + }
> +
> + /* clear pending mailbox interrupt */
> + status = read_c0_corestatus();
> + status &= ~(CORESTATUS_MIRQ0P << cpu);
> + write_c0_corestatus(status);
> +
> + spin_unlock(&smp_lock);
> +
> + if (action & SMP_RESCHEDULE_YOURSELF)
> + scheduler_ipi();
> + if (action & SMP_CALL_FUNCTION)
> + generic_smp_call_function_interrupt();
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void jz4780_smp_setup(void)
> +{
> + u32 addr, reim;
> + int cpu;
> +
> + reim = read_c0_reim();
> +
> + for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + __cpu_number_map[cpu] = cpu;
> + __cpu_logical_map[cpu] = cpu;
> + set_cpu_possible(cpu, true);
I assume if you do that, you will have num_possible_cpus() == NR_CPUS,
which is not what you want.
Correct me if I'm wrong, but I think you would need to call
set_cpu_possible() for each CPU node found.
> + }
> +
> + /* mask mailbox interrupts for this core */
> + reim &= ~REIM_MBOXIRQ0M;
> + write_c0_reim(reim);
> +
> + /* clear mailboxes & pending mailbox IRQs */
> + write_c0_mailbox0(0);
> + write_c0_mailbox1(0);
Write mailbox2/3 too.
> + write_c0_corestatus(0);
> +
> + /* set reset entry point */
> + addr = KSEG1ADDR((u32)&jz4780_secondary_cpu_entry);
> + WARN_ON(addr & ~REIM_ENTRY);
> + reim &= ~REIM_ENTRY;
> + reim |= addr & REIM_ENTRY;
> +
> + /* unmask mailbox interrupts for this core */
> + reim |= REIM_MBOXIRQ0M;
> + write_c0_reim(reim);
> + set_c0_status(STATUSF_IP3);
> + irq_enable_hazard();
> +
> + cpumask_set_cpu(cpu, &cpu_running);
> +}
> +
> +static void jz4780_smp_prepare_cpus(unsigned int max_cpus)
> +{
> + struct device_node *cpu_node;
> + unsigned cpu, ctrl;
> + int err;
> +
> + /* setup the mailbox IRQ */
> + err = request_irq(MIPS_CPU_IRQ_BASE + 3, mbox_handler,
> + IRQF_PERCPU | IRQF_NO_THREAD, "core mailbox", NULL);
Please don't hardcode the IRQ number. Instead, it should be read from
devicetree, maybe from the 'cpus' node (not sure).
> + if (err)
> + pr_err("request_irq() on core mailbox failed\n");
> +
> + ctrl = read_c0_corectrl();
> +
> + for_each_of_cpu_node(cpu_node) {
> + cpu = of_cpu_node_to_id(cpu_node);
> + if (cpu < 0) {
> + pr_err("Failed to read index of %s\n",
> + cpu_node->full_name);
> + continue;
> + }
> +
> + /* use reset entry point from REIM register */
> + ctrl |= CORECTRL_RPC0 << cpu;
> +
> + cpu_clock_gates[cpu] = of_clk_get(cpu_node, 0);
> + if (IS_ERR(cpu_clock_gates[cpu])) {
> + cpu_clock_gates[cpu] = NULL;
> + continue;
> + }
> +
> + err = clk_prepare(cpu_clock_gates[cpu]);
> + if (err)
> + pr_err("Failed to prepare CPU clock gate\n");
I'd suggest to call clk_prepare() in jz4780_boot_secondary(), since you
can't handle errors here. That would also avoid the static
cpu_clock_gates[] array which can grow quite big since its size is
given by NR_CPUS.
> + }
> +
> + write_c0_corectrl(ctrl);
> +}
> +
> +static int jz4780_boot_secondary(int cpu, struct task_struct *idle)
> +{
> + unsigned long flags;
> + u32 ctrl;
> +
> + spin_lock_irqsave(&smp_lock, flags);
> +
> + /* ensure the core is in reset */
> + ctrl = read_c0_corectrl();
> + ctrl |= CORECTRL_SWRST0 << cpu;
> + write_c0_corectrl(ctrl);
> +
> + /* ungate core clock */
> + if (cpu_clock_gates[cpu])
> + clk_enable(cpu_clock_gates[cpu]);
You should check the return value of clk_enable().
+ break;
> +
> + /* set entry sp/gp register values */
> + jz4780_cpu_entry_sp = __KSTK_TOS(idle);
> + jz4780_cpu_entry_gp = (u32)task_thread_info(idle);
> + smp_wmb();
> +
> + /* take the core out of reset */
> + ctrl &= ~(CORECTRL_SWRST0 << cpu);
> + write_c0_corectrl(ctrl);
> +
> + cpumask_set_cpu(cpu, &cpu_running);
> +
> + spin_unlock_irqrestore(&smp_lock, flags);
> +
> + return 0;
> +}
> +
> +static void jz4780_init_secondary(void)
> +{
> +}
> +
> +static void jz4780_smp_finish(void)
> +{
> + u32 reim;
> +
> + spin_lock(&smp_lock);
> +
> + /* unmask mailbox interrupts for this core */
> + reim = read_c0_reim();
> + reim |= REIM_MBOXIRQ0M << smp_processor_id();
> + write_c0_reim(reim);
> +
> + spin_unlock(&smp_lock);
> +
> + /* unmask interrupts for this core */
> + change_c0_status(ST0_IM, STATUSF_IP3 | STATUSF_IP2 |
> + STATUSF_IP1 | STATUSF_IP0);
> + irq_enable_hazard();
> +
> + /* force broadcast timer */
> + tick_broadcast_force();
> +}
> +
> +static void jz4780_send_ipi_single_locked(int cpu, unsigned int
> action)
> +{
> + u32 mbox;
> +
> + switch (cpu) {
> + case 0:
> + mbox = read_c0_mailbox0();
> + write_c0_mailbox0(mbox | action);
> + break;
> + case 1:
> + mbox = read_c0_mailbox1();
> + write_c0_mailbox1(mbox | action);
Handle mailboxes 2/3 too here.
> + default:
> + panic("unhandled cpu %d!", cpu);
> + }
> +}
> +
> +static void jz4780_send_ipi_single(int cpu, unsigned int action)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&smp_lock, flags);
> + jz4780_send_ipi_single_locked(cpu, action);
> + spin_unlock_irqrestore(&smp_lock, flags);
> +}
> +
> +static void jz4780_send_ipi_mask(const struct cpumask *mask,
> + unsigned int action)
> +{
> + unsigned long flags;
> + int cpu;
> +
> + spin_lock_irqsave(&smp_lock, flags);
> +
> + for_each_cpu(cpu, mask)
> + jz4780_send_ipi_single_locked(cpu, action);
> +
> + spin_unlock_irqrestore(&smp_lock, flags);
> +}
> +
> +static struct plat_smp_ops jz4780_smp_ops = {
> + .send_ipi_single = jz4780_send_ipi_single,
> + .send_ipi_mask = jz4780_send_ipi_mask,
> + .init_secondary = jz4780_init_secondary,
> + .smp_finish = jz4780_smp_finish,
> + .boot_secondary = jz4780_boot_secondary,
> + .smp_setup = jz4780_smp_setup,
> + .prepare_cpus = jz4780_smp_prepare_cpus,
> +};
> +
> +void __init jz4780_smp_init(void)
> +{
> + register_smp_ops(&jz4780_smp_ops);
> +}
> diff --git a/arch/mips/kernel/idle.c b/arch/mips/kernel/idle.c
> index 37f8e78..d33f2d4 100644
> --- a/arch/mips/kernel/idle.c
> +++ b/arch/mips/kernel/idle.c
> @@ -18,6 +18,7 @@
> #include <asm/cpu-type.h>
> #include <asm/idle.h>
> #include <asm/mipsregs.h>
> +#include <asm/r4kcache.h>
>
> /*
> * Not all of the MIPS CPUs have the "wait" instruction available.
> Moreover,
> @@ -88,6 +89,34 @@ static void __cpuidle rm7k_wait_irqoff(void)
> }
>
> /*
> + * The Ingenic jz4780 SMP variant has to write back dirty cache
> lines before
> + * executing wait. The CPU & cache clock will be gated until we
> return from
> + * the wait, and if another core attempts to access data from our
> data cache
> + * during this time then it will lock up.
> + */
> +void jz4780_smp_wait_irqoff(void)
> +{
> + unsigned long pending = read_c0_cause() & read_c0_status() &
> CAUSEF_IP;
> +
> + /*
> + * Going to idle has a significant overhead due to the cache flush
> so
> + * try to avoid it if we'll immediately be woken again due to an
> IRQ.
> + */
You could add a fast path here where you just call r4k_wait() if
num_online_cpus() < 2.
-Paul
> + if (!need_resched() && !pending) {
> + r4k_blast_dcache();
> +
> + __asm__(
> + " .set push \n"
> + " .set mips3 \n"
> + " sync \n"
> + " wait \n"
> + " .set pop \n");
> + }
> +
> + local_irq_enable();
> +}
> +
> +/*
> * Au1 'wait' is only useful when the 32kHz counter is used as timer,
> * since coreclock (and the cp0 counter) stops upon executing it.
> Only an
> * interrupt can wake it, so they must be enabled before entering
> idle modes.
> @@ -172,7 +201,6 @@ void __init check_wait(void)
> case CPU_CAVIUM_OCTEON_PLUS:
> case CPU_CAVIUM_OCTEON2:
> case CPU_CAVIUM_OCTEON3:
> - case CPU_XBURST:
> case CPU_LOONGSON32:
> case CPU_XLR:
> case CPU_XLP:
> @@ -246,6 +274,11 @@ void __init check_wait(void)
> cpu_wait = r4k_wait;
> */
> break;
> + case CPU_XBURST:
> + if (IS_ENABLED(CONFIG_SMP))
> + cpu_wait = jz4780_smp_wait_irqoff;
> + else
> + cpu_wait = r4k_wait;
> default:
> break;
> }
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: phy: dp83869: Set opmode from straps
From: kbuild test robot @ 2020-05-19 19:16 UTC (permalink / raw)
To: Dan Murphy, andrew, f.fainelli, hkallweit1, davem
Cc: kbuild-all, netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200519141813.28167-3-dmurphy@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3492 bytes --]
Hi Dan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on robh/for-next sparc-next/master net/master linus/master v5.7-rc6 next-20200519]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Dan-Murphy/DP83869-Enhancements/20200519-222047
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 5cdfe8306631b2224e3f81fc5a1e2721c7a1948b
config: sparc64-randconfig-s001-20200519 (attached as .config)
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-193-gb8fad4bc-dirty
# save the attached .config to linux build tree
make C=1 ARCH=sparc64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/build_bug.h:5,
from include/linux/bits.h:23,
from include/linux/bitops.h:5,
from include/linux/bitmap.h:8,
from include/linux/ethtool.h:16,
from drivers/net/phy/dp83869.c:6:
drivers/net/phy/dp83869.c: In function 'dp83869_set_strapped_mode':
drivers/net/phy/dp83869.c:171:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
171 | if (val < 0)
| ^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
| ^~~~
>> drivers/net/phy/dp83869.c:171:2: note: in expansion of macro 'if'
171 | if (val < 0)
| ^~
drivers/net/phy/dp83869.c:171:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
171 | if (val < 0)
| ^
include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
| ^~~~
>> drivers/net/phy/dp83869.c:171:2: note: in expansion of macro 'if'
171 | if (val < 0)
| ^~
drivers/net/phy/dp83869.c:171:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
171 | if (val < 0)
| ^
include/linux/compiler.h:69:3: note: in definition of macro '__trace_if_value'
69 | (cond) ? | ^~~~
include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
| ^~~~~~~~~~~~~~
>> drivers/net/phy/dp83869.c:171:2: note: in expansion of macro 'if'
171 | if (val < 0)
| ^~
vim +/if +171 drivers/net/phy/dp83869.c
164
165 static int dp83869_set_strapped_mode(struct phy_device *phydev)
166 {
167 struct dp83869_private *dp83869 = phydev->priv;
168 u16 val;
169
170 val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_STRAP_STS1);
> 171 if (val < 0)
172 return val;
173
174 dp83869->mode = val & DP83869_STRAP_OP_MODE_MASK;
175
176 return 0;
177 }
178
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29161 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpu: arm,mali-utgard: add additional properties
From: Heiko Stübner @ 2020-05-19 19:06 UTC (permalink / raw)
To: Johan Jonker
Cc: robh+dt, maxime.ripard, airlied, daniel, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20200519164425.9729-1-jbx6244@gmail.com>
Hi,
Am Dienstag, 19. Mai 2020, 18:44:25 CEST schrieb Johan Jonker:
> In the old txt situation we add/describe only properties that are used
> by the driver/hardware itself. With yaml it also filters things in a
> node that are used by other drivers like 'assigned-clocks' and
> 'assigned-clock-rates' for some older Rockchip SoCs in 'gpu' nodes,
> so add them to 'arm,mali-utgard.yaml'.
though the other option would be to just get rid assigned-clocks
in dt-node for utgard malis ;-)
Like any good gpu, lima should just use frequency scaling to achieve
suitable (fast <-> powersaving) frequencies and it looks like a set
of patches for this was posted in december already [0].
So I guess one could expect opp-based scaling to land at some point.
Heiko
[0] https://lwn.net/Articles/807444/
^ permalink raw reply
* Re: [PATCH v2 07/10] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Tomer @ 2020-05-19 19:03 UTC (permalink / raw)
To: Rob Herring
Cc: Andre Przywara, Andreas Färber, Manivannan Sadhasivam,
cristian.ciocaltea, linux-kernel, linux-arm-kernel, linux-actions,
devicetree
In-Reply-To: <20200519183345.GA434412@bogus>
Hi,
On Wed, May 20, 2020 at 12:03 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 19, 2020 at 11:49:25PM +0530, Amit Singh Tomar wrote:
> > This commit adds device tree binding reset constants for mmc controller
> > present on Actions S700 Soc.
> >
> > Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> > ---
> > Changes since v1:
> > * No change.
> > Changes since RFC:
> > * added Rob's acked-by tag
>
> And dropped??
Sorry, I just forgot to add it.
Thanks
-Amit
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: phy: dp83869: Set opmode from straps
From: Andrew Lunn @ 2020-05-19 19:03 UTC (permalink / raw)
To: Dan Murphy
Cc: Jakub Kicinski, f.fainelli, hkallweit1, davem, netdev,
linux-kernel, devicetree
In-Reply-To: <5d6d799f-f7b6-566a-5038-5901590f2e7b@ti.com>
On Tue, May 19, 2020 at 01:59:16PM -0500, Dan Murphy wrote:
> Jakub
>
> On 5/19/20 1:48 PM, Jakub Kicinski wrote:
> > On Tue, 19 May 2020 13:41:40 -0500 Dan Murphy wrote:
> > > > Is this now a standard GCC warning? Or have you turned on extra
> > > > checking?
> > > I still was not able to reproduce this warning with gcc-9.2. I would
> > > like to know the same
> > W=1 + gcc-10 here, also curious to know which one of the two makes
> > the difference :)
>
> W=1 made the difference I got the warning with gcc-9.2
I wonder if we should turn on this specific warning by default in
drivers/net/phy? I keep making the same mistake, and it would be nice
if GCC actually told me.
Andrew
^ permalink raw reply
* [PATCH v2 07/10] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Singh Tomar @ 2020-05-19 19:00 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-kernel, linux-arm-kernel, linux-actions,
devicetree
In-Reply-To: <1589912368-480-8-git-send-email-amittomer25@gmail.com>
This commit adds device tree binding reset constants for mmc controller
present on Actions S700 Soc.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v1:
* No change.
Changes since RFC:
* added Rob's acked-by tag
---
include/dt-bindings/reset/actions,s700-reset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
index 5e3b16b8ef53..a3118de6d7aa 100644
--- a/include/dt-bindings/reset/actions,s700-reset.h
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -30,5 +30,8 @@
#define RESET_UART4 20
#define RESET_UART5 21
#define RESET_UART6 22
+#define RESET_SD0 23
+#define RESET_SD1 24
+#define RESET_SD2 25
#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: nvmem: stm32: new property for data access
From: Rob Herring @ 2020-05-19 19:00 UTC (permalink / raw)
To: Etienne Carriere
Cc: linux-arm-kernel, robh+dt, alexandre.torgue, Etienne Carriere,
srinivas.kandagatla, linux-stm32, linux-kernel, fabrice.gasnier,
mcoquelin.stm32, devicetree
In-Reply-To: <20200512131334.1750-1-etienne.carriere@linaro.org>
On Tue, 12 May 2020 15:13:34 +0200, Etienne Carriere wrote:
> From: Etienne Carriere <etienne.carriere@st.com>
>
> Introduce boolean property st,non-secure-otp for OTP data located
> in a factory programmed area that only secure firmware can access
> by default and that shall be reachable from the non-secure world.
>
> This change also allows additional properties for NVMEM nodes that
> were forbidden prior this change.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
> ---
> Changes since v1:
> Change nvmem.yaml to allow additional properties in NVMEM nodes.
>
> Link to v1:
> https://lore.kernel.org/patchwork/patch/1239028/
>
> .../devicetree/bindings/nvmem/nvmem.yaml | 2 --
> .../bindings/nvmem/st,stm32-romem.yaml | 17 +++++++++++++++++
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: phy: dp83869: Set opmode from straps
From: Dan Murphy @ 2020-05-19 18:59 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200519114843.34e65bcc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Jakub
On 5/19/20 1:48 PM, Jakub Kicinski wrote:
> On Tue, 19 May 2020 13:41:40 -0500 Dan Murphy wrote:
>>> Is this now a standard GCC warning? Or have you turned on extra
>>> checking?
>> I still was not able to reproduce this warning with gcc-9.2. I would
>> like to know the same
> W=1 + gcc-10 here, also curious to know which one of the two makes
> the difference :)
W=1 made the difference I got the warning with gcc-9.2
Dan
^ permalink raw reply
* Re: [PATCH v8 09/10] dt-bindings: interconnect: Add interconnect-tags bindings
From: Rob Herring @ 2020-05-19 18:58 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-10-georgi.djakov@linaro.org>
On Tue, May 12, 2020 at 03:53:26PM +0300, Georgi Djakov wrote:
> From: Sibi Sankar <sibis@codeaurora.org>
>
> Add interconnect-tags bindings to enable passing of optional
> tag information to the interconnect framework.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> v8:
> * New patch, picked from here:
> https://lore.kernel.org/r/20200504202243.5476-10-sibis@codeaurora.org
>
> .../devicetree/bindings/interconnect/interconnect.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> index 6f5d23a605b7..c1a226a934e5 100644
> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -55,6 +55,11 @@ interconnect-names : List of interconnect path name strings sorted in the same
> * dma-mem: Path from the device to the main memory of
> the system
>
> +interconnect-tags : List of interconnect path tags sorted in the same order as the
> + interconnects property. Consumers can append a specific tag to
> + the path and pass this information to the interconnect framework
> + to do aggregation based on the attached tag.
Why isn't this information in the 'interconnect' arg cells?
We have 'interconnect-names' because strings don't mix with cells. An
expanding list of 'interconnect-.*' is not a good pattern IMO.
Rob
^ permalink raw reply
* Re: [PATCH v1 2/2] mfd: Introduce QTI I2C PMIC controller
From: Guru Das Srinagesh @ 2020-05-19 18:57 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree, linux-arm-msm, Rob Herring, Subbaraman Narayanamurthy,
David Collins, linux-kernel
In-Reply-To: <20200515104520.GK271301@dell>
On Fri, May 15, 2020 at 11:45:20AM +0100, Lee Jones wrote:
> On Thu, 30 Apr 2020, Guru Das Srinagesh wrote:
>
> > On Wed, Apr 29, 2020 at 08:50:10AM +0100, Lee Jones wrote:
> > > On Tue, 28 Apr 2020, Guru Das Srinagesh wrote:
> > >
> > > > The Qualcomm Technologies, Inc. I2C PMIC Controller is used by
> > > > multi-function PMIC devices which communicate over the I2C bus. The
> > > > controller enumerates all child nodes as platform devices, and
> > > > instantiates a regmap interface for them to communicate over the I2C
> > > > bus.
> > > >
> > > > The controller also controls interrupts for all of the children platform
> > > > devices. The controller handles the summary interrupt by deciphering
> > > > which peripheral triggered the interrupt, and which of the peripheral
> > > > interrupts were triggered. Finally, it calls the interrupt handlers for
> > > > each of the virtual interrupts that were registered.
> > > >
> > > > Nicholas Troast is the original author of this driver.
> > > >
> > > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > > ---
> > > > drivers/mfd/Kconfig | 11 +
> > > > drivers/mfd/Makefile | 1 +
> > > > drivers/mfd/qcom-i2c-pmic.c | 737 ++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > The vast majority of this driver deals with IRQ handling. Why can't
> > > this be split out into its own IRQ Chip driver and moved to
> > > drivers/irqchip?
> >
> > There appear to be quite a few in-tree MFD drivers that register IRQ
> > controllers, like this driver does:
> >
> > $ grep --exclude-dir=.git -rnE "irq_domain_(add|create).+\(" drivers/mfd | wc -l
> > 23
> >
> > As a further example, drivers/mfd/stpmic1.c closely resembles this
> > driver in that it uses both devm_regmap_add_irq_chip() as well as
> > devm_of_platform_populate().
> >
> > As such, it seems like this driver is in line with some of the
> > architectural choices that have been accepted in already-merged drivers.
> > Could you please elaborate on your concerns?
>
> It is true that *basic* IRQ domain support has been added to these
> drivers in the past. However, IMHO the support added to this driver
> goes beyond those realms such that it would justify a driver of its
> own.
I am exploring an option to see if the regmap-irq APIs may be used in
this driver, similar to stpmic1.c. Just to let you know, it might be a
few days before I am able to post my next patchset as I'll have to make
the necessary changes and test them out first.
Thank you.
Guru Das.
^ 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