* [PATCH 04/10] [v3] dt-bindings: qoriq-clock: update for more SoCs
From: shh.xie at gmail.com @ 2016-09-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-1-git-send-email-shh.xie@gmail.com>
From: Shaohui Xie <Shaohui.Xie@nxp.com>
Adds compatible for SoCs which use clockgen, the SoCs are LS1043A,
LS1046A, LS2080A.
Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
---
change in v3:
1. new patch.
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 16a3ec4..df9cb5a 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -32,6 +32,9 @@ Required properties:
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
* "fsl,ls1021a-clockgen"
+ * "fsl,ls1043a-clockgen"
+ * "fsl,ls1046a-clockgen"
+ * "fsl,ls2080a-clockgen"
Chassis-version clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 03/10][v3] dt-bindings: i2c: adds two more nxp devices
From: shh.xie at gmail.com @ 2016-09-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-1-git-send-email-shh.xie@gmail.com>
From: Shaohui Xie <Shaohui.Xie@nxp.com>
"nxp,pcf2127" and "nxp,pcf2129" are I2c devices, adds them to the list
of trivial i2c devices.
Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
---
changes in V3:
1. none.
changes in V2:
1. new patch.
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 5c70ce9..677b168 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -129,6 +129,8 @@ nuvoton,npct501 i2c trusted platform module (TPM)
nuvoton,npct601 i2c trusted platform module (TPM2)
nxp,pca9556 Octal SMBus and I2C registered interface
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
+nxp,pcf2127 Real-time clock
+nxp,pcf2129 Real-time clock
nxp,pcf8563 Real-time clock/calendar
nxp,pcf85063 Tiny Real-Time Clock
oki,ml86v7667 OKI ML86V7667 video decoder
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 02/10][v3] dt-bindings: fsl: updates bindings for some SoC-specific devices
From: shh.xie at gmail.com @ 2016-09-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-1-git-send-email-shh.xie@gmail.com>
From: Shaohui Xie <Shaohui.Xie@nxp.com>
SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A,
LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to
reflect more SoCs.
Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
---
changes in V3:
1. added supported <chip>s.
change in V2:
1. new patch.
Documentation/devicetree/bindings/arm/fsl.txt | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 2efbc09..a81277f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -97,7 +97,7 @@ Freescale LS1021A Platform Device Tree Bindings
Required root node compatible properties:
- compatible = "fsl,ls1021a";
-Freescale LS1021A SoC-specific Device Tree Bindings
+Freescale SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
@@ -105,7 +105,11 @@ Freescale SCFG
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- - compatible: should be "fsl,ls1021a-scfg"
+ - compatible: Should contain a chip-specific compatible string,
+ Chip-specific strings are of the form "fsl,<chip>-scfg",
+ The following <chip>s are known to be supported:
+ ls1021a, ls1043a, ls1046a, ls2080a.
+
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
@@ -119,7 +123,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: Should contain a chip-specific compatible string,
+ Chip-specific strings are of the form "fsl,<chip>-dcfg",
+ The following <chip>s are known to be supported:
+ ls1021a, ls1043a, ls1046a, ls2080a.
+
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 01/10] [v3] dt-bindings: fsl: update for more SoCs
From: shh.xie at gmail.com @ 2016-09-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-1-git-send-email-shh.xie@gmail.com>
From: Shaohui Xie <Shaohui.Xie@nxp.com>
Adds SoC compatible for LS1043A and LS2080A which are supported, and
for LS1046A which is going to be supported.
Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
---
changes in V3:
1. new patch.
Documentation/devicetree/bindings/arm/fsl.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index dbbc095..2efbc09 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -131,6 +131,10 @@ Example:
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
----------------------------------------------------------------
+LS1043A SoC
+Required root node properties:
+ - compatible = "fsl,ls1043a";
+
LS1043A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
@@ -139,6 +143,14 @@ LS1043A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
+LS1046A SoC
+Required root node properties:
+ - compatible = "fsl,ls1046a";
+
+LS2080A SoC
+Required root node properties:
+ - compatible = "fsl,ls2080a";
+
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 00/10] [v3] arm64: dts: add QorIQ LS1046A SoC and boards support
From: shh.xie at gmail.com @ 2016-09-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Shaohui Xie <Shaohui.Xie@nxp.com>
This patchest adds support for QorIQ LS1046A SoC which is based on ARMv8
architecture, also adds LS1046A-RDB and LS1046A-QDS board support.
Also, updates bindings for SoC-specific devices SCFG and DCFG,
I2C devices, qoriq-clock and ahci-fsl-qoriq.
Mingkai Hu (2):
arm64: dts: add QorIQ LS1046A SoC support
arm64: dts: add LS1046A-RDB board support
Shaohui Xie (8):
dt-bindings: fsl: update for more SoCs
dt-bindings: fsl: updates bindings for some SoC-specific devices
dt-bindings: i2c: adds two more nxp devices
dt-bindings: qoriq-clock: update for more SoCs
dt-bindings: ahci-fsl-qoriq: updated for SoC ls1046a
Documentation: DT: Add entry for QorIQ LS1046A-RDB board
Documentation: DT: Add entry for QorIQ LS1046A-QDS board
arm64: dts: add LS1046A-QDS board support
Documentation/devicetree/bindings/arm/fsl.txt | 34 +-
.../devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 +-
.../devicetree/bindings/clock/qoriq-clock.txt | 3 +
.../devicetree/bindings/i2c/trivial-devices.txt | 2 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 212 +++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 150 ++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 515 +++++++++++++++++++++
8 files changed, 916 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
--
2.1.0.27.g96db324
^ permalink raw reply
* [PATCH 0/5] ARM: dts: sun8i: Add touchscreen node to various tablets
From: Hans de Goede @ 2016-09-13 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913075953.GA9805@lukather>
Hi,
On 13-09-16 09:59, Maxime Ripard wrote:
> On Sun, Sep 11, 2016 at 08:23:22PM +0200, Hans de Goede wrote:
>> Hi Maxime,
>>
>> Now that Dmitry has queued up the firmware-name property changes
>> in his for-linus branch, these dt patches are ready for merging.
>
> I queued this for 4.10.
4.10 ? Is next already frozen ? Note either way is fine
just wondering.
Regards,
Hans
^ permalink raw reply
* [PATCH v2 0/4] ARM: amlogic: Add spifc support to Amlogic's GXBB family
From: jbrunet @ 2016-09-13 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7heg4oq2es.fsf@baylibre.com>
On Mon, 2016-09-12 at 13:38 -0700, Kevin Hilman wrote:
> Jerome Brunet <jbrunet@baylibre.com> writes:
>
> >
> > This patch series adds the necessary pins, clocks and device tree
> > nodes to
> > enable the spifc controller on the GXBB family. I had to add the
> > nand pins
> > in pintctrl as the pinmux setting left by u-boot was conflicting
> > with the
> > spifc pinmux during my test on the P200.
>
> This series seems to be missing a patch which enables the SPIfc on
> the
> P200 board for use with the on-board NOR flash.
>
> Kevin
>
Indeed, I did not provide this patch, on purpose.
The SPI-NOR at 4U2 on the P200 schematics was not present on the board
I have. I assumed this was the case for all other P200 as well.
In addition, to enable the SPI-NOR, you would also need to solder
something at 4R3 (SPI_CS signal disconnected by default)
Finally, all the SPIfc lines are shared with the NAND controller which,
like the SPI-NOR, appears on the schematics (4CCN1) but is not soldered
on the actual hardware.
Of course, I can share such patch for testing purposes if you would
like me to.
Jerome.
> >
> > Changes since v1 at : http://lkml.kernel.org/r/1473261223-15412-1-g
> > it-send-email-jbrunet at baylibre.com
> > ?* Omit patches :
> > ? - dt-bindings: spi-meson: Add GXBB Compatible string
> > ? - spi: meson: Add GXBB compatible
> > ? Sent as dedicated series
> > ?* Omit patch:
> > ? - clk: gxbb: expose spifc clock
> > ? Already applied
> > ?* Rename SPI flash controller pins from spifc_* to nor_* to keep
> > the
> > ???name aligned with the datasheet
> >
> > Jerome Brunet (3):
> > ? pinctrl: amlogic: gxbb: add spi nor pins
> > ? pinctrl: amlogic: gxbb: add nand pins
> > ? ARM64: dts: amlogic: add spi nor pins
> >
> > Neil Armstrong (1):
> > ? ARM64: dts: meson-gxbb: Add SPIFC node
> >
> > ?arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 19 +++++++++++++++
> > ?drivers/pinctrl/meson/pinctrl-meson-gxbb.c??| 37
> > +++++++++++++++++++++++++++++
> > ?2 files changed, 56 insertions(+)
^ permalink raw reply
* [PATCH 0/5] ARM: dts: sun8i: Add touchscreen node to various tablets
From: Maxime Ripard @ 2016-09-13 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911182327.824-1-hdegoede@redhat.com>
On Sun, Sep 11, 2016 at 08:23:22PM +0200, Hans de Goede wrote:
> Hi Maxime,
>
> Now that Dmitry has queued up the firmware-name property changes
> in his for-linus branch, these dt patches are ready for merging.
I queued this for 4.10.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160913/7324f5c7/attachment.sig>
^ permalink raw reply
* [PATCH v5 07/14] drivers: acpi: iort: add support for ARM SMMU platform devices creation
From: nwatters at codeaurora.org @ 2016-09-13 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909142343.13314-8-lorenzo.pieralisi@arm.com>
On 2016-09-09 10:23, Lorenzo Pieralisi wrote:
> In ARM ACPI systems, IOMMU components are specified through static
> IORT table entries. In order to create platform devices for the
> corresponding ARM SMMU components, IORT kernel code should be made
> able to parse IORT table entries and create platform devices
> dynamically.
>
> This patch adds the generic IORT infrastructure required to create
> platform devices for ARM SMMUs.
>
> ARM SMMU versions have different resources requirement therefore this
> patch also introduces an IORT specific structure (ie iort_iommu_config)
> that contains hooks (to be defined when the corresponding ARM SMMU
> driver support is added to the kernel) to be used to define the
> platform devices names, init the IOMMUs, count their resources and
> finally initialize them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/arm64/iort.c | 131
> ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index b89b3d3..e0a9b16 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -22,6 +22,7 @@
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/pci.h>
> +#include <linux/platform_device.h>
> #include <linux/slab.h>
>
> struct iort_its_msi_chip {
> @@ -424,6 +425,135 @@ struct irq_domain *iort_get_device_domain(struct
> device *dev, u32 req_id)
> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> }
>
> +struct iort_iommu_config {
> + const char *name;
> + int (*iommu_init)(struct acpi_iort_node *node);
> + bool (*iommu_is_coherent)(struct acpi_iort_node *node);
> + int (*iommu_count_resources)(struct acpi_iort_node *node);
> + void (*iommu_init_resources)(struct resource *res,
> + struct acpi_iort_node *node);
> +};
> +
> +static __init
> +const struct iort_iommu_config *iort_get_iommu_cfg(struct
> acpi_iort_node *node)
> +{
> + return NULL;
> +}
> +
> +/**
> + * iort_add_smmu_platform_device() - Allocate a platform device for
> SMMU
> + * @fwnode: IORT node associated fwnode handle
> + * @node: Pointer to SMMU ACPI IORT node
> + *
> + * Returns: 0 on success, <0 failure
> + */
> +static int __init iort_add_smmu_platform_device(struct fwnode_handle
> *fwnode,
> + struct acpi_iort_node *node)
> +{
> + struct platform_device *pdev;
> + struct resource *r;
> + enum dev_dma_attr attr;
> + int ret, count;
> + const struct iort_iommu_config *ops = iort_get_iommu_cfg(node);
> +
> + if (!ops)
> + return -ENODEV;
> +
> + pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
> + if (!pdev)
> + return PTR_ERR(pdev);
> +
> + count = ops->iommu_count_resources(node);
> +
> + r = kcalloc(count, sizeof(*r), GFP_KERNEL);
> + if (!r) {
> + ret = -ENOMEM;
> + goto dev_put;
> + }
> +
> + ops->iommu_init_resources(r, node);
> +
> + ret = platform_device_add_resources(pdev, r, count);
> + /*
> + * Resources are duplicated in platform_device_add_resources,
> + * free their allocated memory
> + */
> + kfree(r);
> +
> + if (ret)
> + goto dev_put;
> +
> + /*
> + * Add a copy of IORT node pointer to platform_data to
> + * be used to retrieve IORT data information.
> + */
> + ret = platform_device_add_data(pdev, &node, sizeof(node));
> + if (ret)
> + goto dev_put;
> +
> + pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask),
> GFP_KERNEL);
> + if (!pdev->dev.dma_mask) {
> + ret = -ENOMEM;
> + goto dev_put;
> + }
> +
> + pdev->dev.fwnode = fwnode;
> +
> + /*
> + * Set default dma mask value for the table walker,
> + * to be overridden on probing with correct value.
> + */
> + *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> + pdev->dev.coherent_dma_mask = *pdev->dev.dma_mask;
> +
> + attr = ops->iommu_is_coherent(node) ?
> + DEV_DMA_COHERENT : DEV_DMA_NON_COHERENT;
> +
> + /* Configure DMA for the page table walker */
> + acpi_dma_configure(&pdev->dev, attr);
> +
> + ret = platform_device_add(pdev);
> + if (ret)
> + goto dma_deconfigure;
> +
> + return 0;
> +
> +dma_deconfigure:
> + acpi_dma_deconfigure(&pdev->dev);
> + kfree(pdev->dev.dma_mask);
> +
> +dev_put:
> + platform_device_put(pdev);
> +
> + return ret;
> +}
> +
> +static acpi_status __init iort_match_iommu_callback(struct
> acpi_iort_node *node,
> + void *context)
> +{
> + int ret;
> + struct fwnode_handle *fwnode;
> +
> + fwnode = iort_get_fwnode(node);
> +
> + if (!fwnode)
> + return AE_NOT_FOUND;
> +
> + ret = iort_add_smmu_platform_device(fwnode, node);
> + if (ret) {
> + pr_err("Error in platform device creation\n");
> + return AE_ERROR;
> + }
> +
> + return AE_OK;
> +}
> +
> +static void __init iort_smmu_init(void)
> +{
> + iort_scan_node(ACPI_IORT_NODE_SMMU, iort_match_iommu_callback, NULL);
> + iort_scan_node(ACPI_IORT_NODE_SMMU_V3, iort_match_iommu_callback,
> NULL);
Since iort_scan_node() returns after the first successful match it
finds,
only the first SMMU_V3 in my IORT is being enumerated. I think you need
to go back to the "iterator" like approach you had been using or make
iort_match_iommu_callback() always return a non-AE_OK value so the scan
continues and has a chance to visit all of the SMMU_V3 nodes.
> +}
> +
> void __init acpi_iort_init(void)
> {
> acpi_status status;
> @@ -436,4 +566,5 @@ void __init acpi_iort_init(void)
> }
>
> acpi_probe_device_table(iort);
> + iort_smmu_init();
> }
--
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function device for legacy interrupts.
From: Marc Zyngier @ 2016-09-13 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912220241.GG23532@localhost>
On 12/09/16 23:02, Bjorn Helgaas wrote:
> On Thu, Sep 01, 2016 at 05:19:55AM +0000, Bharat Kumar Gogada wrote:
>>>>>>> Hi Bharat,
>>>>>>>> @@ -561,7 +561,7 @@ static int nwl_pcie_init_irq_domain(struct
>>>>>>>> nwl_pcie
>>>>>>> *pcie)
>>>>>>>> }
>>>>>>>>
>>>>>>>> pcie->legacy_irq_domain = irq_domain_add_linear(legacy_intc_node,
>>>>>>>> - INTX_NUM,
>>>>>>>> + INTX_NUM + 1,
>>>>>>>> &legacy_domain_ops,
>>>>>>>> pcie);
>>>>>>>
>>>>>>> This feels like the wrong thing to do. You have INTX_NUM irqs, so
>>>>>>> the domain allocation should reflect this. On the other hand, the
>>>>>>> way the driver currently deals with mappings is quite broken
>>>>>>> (consistently adding 1 to
>>>>> the HW interrupt).
>>>>>>>
>>>>>> Hi Marc,
>>>>>>
>>>>>> Without above change I get following crash in kernel while booting.
>>>>>>
>>>>>> [ 2.441684] error: hwirq 0x4 is too large for dummy
>>>>>>
>>>>>> [ 2.441694] ------------[ cut here ]------------
>>>>>>
>>>>>> [ 2.441698] WARNING: at kernel/irq/irqdomain.c:344
>>>>>>
>>>>>> [ 2.441702] Modules linked in:
>>>>>>
>>>>>> [ 2.441706]
>>>>>>
>>>>>> [ 2.441714] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.4.0 #8
>>>>>>
>>>>>> [ 2.441718] Hardware name: xlnx,zynqmp (DT)
>>>>>>
>>>>>> [ 2.441723] task: ffffffc071886b80 ti: ffffffc071888000 task.ti:
>>>>> ffffffc071888000
>>>>>>
>>>>>> [ 2.441732] PC is at irq_domain_associate+0x138/0x1c0
>>>>>>
>>>>>> [ 2.441738] LR is at irq_domain_associate+0x138/0x1c0
>>>>>>
>>>>>> In kernel/irq/irqdomain.c function irq_domain_associate
>>>>>>
>>>>>> if (WARN(hwirq >= domain->hwirq_max,
>>>>>> "error: hwirq 0x%x is too large for %s\n", (int)hwirq, domain-
>>>> name))
>>>>>> return -EINVAL;
>>>>>>
>>>>>> Here the hwirq and hwirq_max are equal to 4 without the above
>>>>>> condition
>>>>> (INTX_NUM + 1) due to which crash is coming.
>>>>>> This is happening as the legacy interrupts are starting from 1 (INTA).
>>>>>
>>>>> I understood that. I'm still persisting in saying that you have the wrong fix.
>>>>>
>>>>> Your domain should always allocate many interrupts as you have
>>>>> interrupt sources. These interrupts (hwirq) should be numbered from 0 to (n-
>>> 1).
>>>>
>>>> Agreed, but here comes the problem the hwirq for legacy interrupts
>>>> will start at 0x1 to 0x4 (INTA to INTD) and these values are as per
>>>> PCIe specification for legacy interrupts. So these cannot be numbered
>>>> from 0. So when 0x4 (INTD) for a multi-function device comes the crash
>>>> occurs.
>>>
>>> So who provides this hwirq? Who calls irq_domain_associate() with hwirq set to
>>> 4?
>>>
>> PCIe subsystem invokes pcibios_add_device function in arch/arm64/kernel/pci.c for every pci device.
>> The purpose of this function is to assign dev->irq using of_irq_parse_and_map_pci.
>> of_irq_parse_and_map_pci invokes of_irq_parse_pci where it reads PCI_INTERRUPT_PIN from configuration space and saves it
>> in parameter of struct of_phandle_args.
>> This structure is passed to irq_create_of_mapping where it invokes irq_create_fwspec_mapping.
>> irq_create_fwspec_mapping invokes irq_domain_translate and gets hwirq, here the above saved PCI_INTERRUPT_PIN value is assigned
>> to hwirq (*hwirq = fwspec->param[0]).
>> And then using this hwirq irq_create_mapping -> irq_domain_associate were invoked and mapping is created for virtual irq with this hwirq.
>> So for any end point PCI_INTERRUPT_PIN value starts from 0x1 to 0x4 and so hwirq starts from 0x1 to 0x4.
>>
>> So the values are more generic w.r.t to protocol, that's why hwirq will range from 0x1 to 0x4.
>> And then if you check pcie-altera.c they are doing this adding one in their handler and while creating legacy domain.
>
> Is this resolved yet? Marc, are you happy, or should we iterate on this
> again?
Ah, sorry to have dropped the ball on this patch.
I guess that given that the infrastructure imposes the hwirq range on
the host drivers, Bharat's approach is the only way (and a number of
other host drivers are already slightly broken). I'll try and have a
look at solving this at the generic level. In the meantime:
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/3] ARM64: dts: amlogic: Add basic support for Amlogic S905X
From: Neil Armstrong @ 2016-09-13 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2ZjDjZbUfCKwUf4PHywOZx-UiQmy37TEQhWDNYRg0BOag@mail.gmail.com>
On 09/13/2016 08:14 AM, Carlo Caione wrote:
> On Mon, Sep 12, 2016 at 11:43 PM, Andreas F?rber <afaerber@suse.de> wrote:
>
> [cut]
>> I'm not arguing over the file name, where it perfectly makes sense to
>> have a meson-gxl- prefix (already discussed), just about the compatible
>> string where we don't have "amlogic,meson-gxl-s905x-p231" either because
>> it is completely unnecessary and does _not_ add any value.
>>
>> Not that we're checking this string anywhere anyway... If you want to
>> check for the GXL family you have to use "amlogic,meson-gxl"; if you
>> want to check for the specific SoC you use "amlogic,s905x". Simple. We
>> never match partial strings, so there is no sense in a hardcoded prefix
>> that is duplicating information already available.
>
> Ok, then. Fine with me.
>
> Neil, do you want to resend my patch or you can take care of the fixes
> for the whole patchset?
>
> Thanks,
>
Ok, I still need to synchronize with kevin for when and where to rebase from.
Neil
^ permalink raw reply
* [PATCH 1/5] clk: add support for runtime pm
From: Ulf Hansson @ 2016-09-13 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908001943.GC13062@codeaurora.org>
On 8 September 2016 at 02:19, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 09/01, Marek Szyprowski wrote:
>> Registers for some clocks might be located in the SOC area, which are under the
>> power domain. To enable access to those registers respective domain has to be
>> turned on. Additionally, registers for such clocks will usually loose its
>> contents when power domain is turned off, so additional saving and restoring of
>> them might be needed in the clock controller driver.
>>
>> This patch adds basic infrastructure in the clocks core to allow implementing
>> driver for such clocks under power domains. Clock provider can supply a
>> struct device pointer, which is the used by clock core for tracking and managing
>> clock's controller runtime pm state. Each clk_prepare() operation
>> will first call pm_runtime_get_sync() on the supplied device, while
>> clk_unprepare() will do pm_runtime_put() at the end.
>>
>> Additional calls to pm_runtime_get/put functions are required to ensure that any
>> register access (like calculating/chaning clock rates) will be done with clock
>> controller in active runtime state.
>>
>> Special handling of the case when runtime pm is disabled for clock controller's
>> device is needed to let this feature work properly also during system sleep
>> suspend/resume operations (runtime pm is first disabled before entering sleep
>> state's, but controller is usually still operational until its suspend pm
>> callback is called).
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> My "knee jerk" concern is that we're going to take a runtime PM
> lock underneath the prepare lock. That seems like a situation
> where we could hit a lock inversion if the runtime PM callbacks
> themselves acquire the prepare lock by calling clk APIs? But this
> concern is false right? We release the runtime PM lock before
> calling the PM callback, so we shouldn't hit any deadlock and
> lockdep won't complain?
You assumption is correct!
Before the runtime PM core invokes a runtime PM callback it will
unlock the -">dev->power.lock" spinlock. When the callback returns it
will re-lock the spinlock.
Kind regards
Uffe
^ permalink raw reply
* [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Y.B. Lu @ 2016-09-13 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473722714.30217.196.camel@buserror.net>
> -----Original Message-----
> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> owner at vger.kernel.org] On Behalf Of Scott Wood
> Sent: Tuesday, September 13, 2016 7:25 AM
> To: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Arnd
> Bergmann
> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Mon, 2016-09-12 at 06:39 +0000, Y.B. Lu wrote:
> > Hi Scott,
> >
> > Thanks for your review :)
> > See my comment inline.
> >
> > >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss at buserror.net]
> > > Sent: Friday, September 09, 2016 11:47 AM
> > > To: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org;
> > > linux-arm- kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > linux- clk at vger.kernel.org; linux-i2c at vger.kernel.org;
> > > iommu at lists.linux- foundation.org; netdev at vger.kernel.org; Mark
> > > Rutland; Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel;
> > > Claudiu Manoil; Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh
> > > Shilimkar; Leo Li; X.B. Xie
> > > Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > > >
> > > > The global utilities block controls power management, I/O device
> > > > enabling, power-onreset(POR) configuration monitoring, alternate
> > > > function selection for multiplexed signals,and clock control.
> > > >
> > > > This patch adds a driver to manage and access global utilities
> block.
> > > > Initially only reading SVR and registering soc device are supported.
> > > > Other guts accesses, such as reading RCW, should eventually be
> > > > moved into this driver as well.
> > > >
> > > > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > > > Signed-off-by: Scott Wood <oss@buserror.net>
> > > Don't put my signoff on patches that I didn't put it on myself.
> > > Definitely don't put mine *after* yours on patches that were last
> > > modified by you.
> > >
> > > If you want to mention that the soc_id encoding was my suggestion,
> > > then do so explicitly.
> > >
> > [Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
> > http://patchwork.ozlabs.org/patch/649211/
> >
> > So, let me just change the order in next version ?
> > Signed-off-by: Scott Wood <oss@buserror.net>
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>
> No. ?This isn't my patch so my signoff shouldn't be on it.
[Lu Yangbo-B47093] Ok, will remove it.
>
> > [Lu Yangbo-B47093] It's a good idea to move die into .family I think.
> > In my opinion, it's better to keep svr and name in soc_id just like
> > your suggestion above.
> > >
> > > {
> > > .soc_id = "svr:0x85490010,name:T1023E,",
> > > .family = "QorIQ T1024",
> > > }
> > The user probably don?t like to learn the svr value. What they want is
> > just to match the soc they use.
> > It's convenient to use name+rev for them to match a soc.
>
> What the user should want 99% of the time is to match the die (plus
> revision), not the soc.
>
> > Regarding shrinking the table, I think it's hard to use svr+mask.
> > Because I find many platforms use different masks.
> > We couldn?t know the mask according svr value.
>
> The mask would be part of the table:
>
> {
> {
> .die = "T1024",
> .svr = 0x85400000,
> .mask = 0xfff00000,
> },
> {
> .die = "T1040",
> .svr = 0x85200000,
> .mask = 0xfff00000,
> },
> {
> .die = "LS1088A",
> .svr = 0x87030000,
> .mask = 0xffff0000,
> },
> ...
> }
>
> There's a small risk that we get the mask wrong and a different die is
> created that matches an existing table, but it doesn't seem too likely,
> and can easily be fixed with a kernel update if it happens.
>
[Lu Yangbo-B47093] You mean we will not define soc device attribute for each soc and we will define attribute for each die instead, right?
If so, when we want to match a specific soc we need to use its svr value in code. If it's acceptable, I can try in next version.
> BTW, aren't ls2080a and ls2085a the same die? ?And is there no non-E
> version of LS2080A/LS2040A?
[Lu Yangbo-B47093] I checked all the svr values in chip errata doc "Revision level to part marking cross-reference" table.
I found ls2080a and ls2085a were in two separate doc. And I didn?t find non-E version of LS2080A/LS2040A in chip errata doc.
Do you know is there any other doc we can confirm this?
>
> > > > + do {
> > > > + if (!matches->soc_id)
> > > > + return NULL;
> > > > + if (glob_match(svr_match, matches->soc_id))
> > > > + break;
> > > > + } while (matches++);
> > > Are you expecting "matches++" to ever evaluate as false?
> > [Lu Yangbo-B47093] Yes, this is used to match the soc we use in
> > qoriq_soc array until getting true.
> > We need to get the name and die information defined in array.
>
> I'm not asking whether the glob_match will ever return true. ?I'm saying
> that "matches++" will never become NULL.
[Lu Yangbo-B47093] The matches++ will never become NULL while it will return NULL after matching for all the members in array.
>
> > > > + /* Register soc device */
> > > > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > > > + if (!soc_dev_attr) {
> > > > + ret = -ENOMEM;
> > > > + goto out_unmap;
> > > > + }
> > > Couldn't this be statically allocated?
> > [Lu Yangbo-B47093] Do you mean we define this struct statically ?
> >
> > static struct soc_device_attribute soc_dev_attr;
>
> Yes.
>
[Lu Yangbo-B47093] It's ok to define it statically. Is there any need to do that?
> > > > +
> > > > + soc_dev = soc_device_register(soc_dev_attr);
> > > > + if (IS_ERR(soc_dev)) {
> > > > + ret = -ENODEV;
> > > Why are you changing the error code?
> > [Lu Yangbo-B47093] What error code should we use ? :)
>
> ret = PTR_ERR(soc_dev);
[Lu Yangbo-B47093] Ok.. will do that.
>
> + }
> > > > + return 0;
> > > > +out:
> > > > + kfree(soc_dev_attr->machine);
> > > > + kfree(soc_dev_attr->family);
> > > > + kfree(soc_dev_attr->soc_id);
> > > > + kfree(soc_dev_attr->revision);
> > > > + kfree(soc_dev_attr);
> > > > +out_unmap:
> > > > + iounmap(guts->regs);
> > > > +out_free:
> > > > + kfree(guts);
> > > devm
> > [Lu Yangbo-B47093] What's the devm meaning here :)
>
> If you allocate these with devm_kzalloc(), devm_kasprintf(),
> devm_kstrdup(), etc. then they will be freed automatically when the
> device is unbound.
>
> >
> > >
> > >
> > > >
> > > > +static int fsl_guts_remove(struct platform_device *dev) {
> > > > + kfree(soc_dev_attr->machine);
> > > > + kfree(soc_dev_attr->family);
> > > > + kfree(soc_dev_attr->soc_id);
> > > > + kfree(soc_dev_attr->revision);
> > > > + kfree(soc_dev_attr);
> > > > + soc_device_unregister(soc_dev);
> > > > + iounmap(guts->regs);
> > > > + kfree(guts);
> > > > + return 0;
> > > > +}
> > > Don't free the memory before you unregister the device that uses it
> > > (moot if you use devm).
> > [Lu Yangbo-B47093] The soc.c driver mentions that.
> > Ensure soc_dev->attr is freed prior to calling soc_device_unregister.
>
> That comment is wrong. ?Freeing the memory first creates a race condition
> that could result in accessing freed memory, if something accesses the
> soc device in parallel with unbinding.
>
[Lu Yangbo-B47093] Ok, will unregister the device first. Thanks.
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v5 0/3] Add ZTE ZX296718 support
From: Shawn Guo @ 2016-09-13 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473730926-1034-1-git-send-email-jun.nie@linaro.org>
On Tue, Sep 13, 2016 at 09:42:03AM +0800, Jun Nie wrote:
> Changes in version5:
> - Add GPL license to new files.
> - Unify clocks dts nodes names.
> - Move interrupt parents info to root nodes in dts, move
> pmu and timer node out of soc node.
>
> Changes in version4:
> - Change dts file name to align with compatible name.
> - Reorder dts nodes with reg address sequence.
> - Move nodes out of soc, which do not have soc simple
> bus address or share soc interrupt.
> - Change some nodes name to align with convention.
>
> Changes in version3:
> - Remove unnecessary flag of gic in dts.
>
> Changes in version2:
> - Use more precise cpu and pmu compatible name in dts.
> - fix minor coding style issue.
>
>
> Jun Nie (3):
> arm64: add ZTE ZX SoC family
> arm64: dts: Add ZTE ZX296718 SoC dts and Makefile
> arm64: defconfig: enable ZTE ZX related config
For the series,
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
Arnd, Olof,
If you like, I can help collect ZTE DTS patches to reduce your
maintenance burden, considering we have an established pull-request
work flow and I get ZTE platform on hands to test patches.
Shawn
^ permalink raw reply
* [PATCH v5 2/3] mfd: add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-09-13 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912135646.GB9789@dell>
On 12/09/2016 15:56, Lee Jones wrote:
> On Mon, 12 Sep 2016, Quentin Schulz wrote:
>> On 12/09/2016 11:59, Lee Jones wrote:
>>> On Mon, 12 Sep 2016, Quentin Schulz wrote:
>>>
>>>> On 12/09/2016 11:18, Lee Jones wrote:
>>>>> On Thu, 08 Sep 2016, Quentin Schulz wrote:
>>>>> [...]
>>>>>> +
>>>>>> +MODULE_DEVICE_TABLE(of, sun4i_gpadc_mfd_of_match);
>>>>>
>>>>> Place this directly under the table.
>>>>>
>>>>>> +static struct platform_driver sun4i_gpadc_mfd_driver = {
>>>>>> + .driver = {
>>>>>> + .name = "sun4i-adc-mfd",
>>>>>> + .of_match_table = of_match_ptr(sun4i_gpadc_mfd_of_match),
>>>>>> + },
>>>>>> + .probe = sun4i_gpadc_mfd_probe,
>>>>>
>>>>> No .remove?
>>>>>
>>>>
>>>> No, everything in probe is handled with devm functions.
>>>
>>> Don't you need to undo the register write you did?
>>>
>>
>> The regmap_write I use is there to disable all interrupts on hardware
>> side before the irq_chip handles all interrupts by itself. The
>> interrupts are not used in the MFD driver.
>>
>> Thus, I chose to disable the hardware interrupts in the remove function
>> of drivers using the interrupts (only the IIO yet but the touchscreen
>> driver later also which will be using a third interrupt). When the MFD
>> driver is removed, the MFD cells will all be removed, thus calling their
>> own remove functions, thus disabling hardware interrupts used in each
>> driver. So the hardware interrupts disabling would be called twice.
>
> This does send some little alarm bells ringing. I'd normally expect
> the .remove function to undo everything you did in .probe. So, if you
> are disabling the IRQs from within the leaf drivers, shouldn't you be
> initialising them in the leaf driver's respective .probes?
>
I use the regmap_write in the MFD driver's probe to disable all
interrupts before requesting irq_chip to guarantee the interrupts are in
a known state, being disabled. It is to insure no interrupt will occur
unwittingly before we want the leaf drivers to handle them.
The disabling of irqs in the remove is handled rather by
devm_regmap_del_irq_chip than by an explicit regmap_write in the
driver's removal function. It performs the exact same thing.
I always use devm functions for requesting either an irq_chip or the
irqs themselves. In that case, when the device is removed, the irqs are
freed on leaf drivers' (where the irqs are requested) removal while the
removal of irq_chip in the MFD driver will also free all irqs mapped to
this irq_chip thanks to devm_regmap_del_irq_chip. Therefore, the
interrupts are disabled by devm functions.
The regmap_update_bits in probe and removal of the ADC driver to disable
irqs are actually redundant because the devm functions already handle
the irqs disabling.
Thanks,
Quentin
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-09-13 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907213519.27340-23-stephen.boyd@linaro.org>
On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
>
Hi Stephen, I am a little puzzled how this driver co-work with chipidea
driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
before access portsc.pts (calling hw_phymode_configure), otherwise,
the system will hang. But I find you call hw_phymode_configure before
phy->power_on, doesn't your design have this requirement?
Besides, you read ulpi id before phy->power_on, how can read work before
phy power on?
Peter
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
> .../devicetree/bindings/phy/qcom,usb-hs-phy.txt | 83 ++++++
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qcom-usb-hs.c | 289 +++++++++++++++++++++
> 4 files changed, 381 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index 000000000000..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
> + following:
> +
> + "qcom,usb-hs-phy-apq8064"
> + "qcom,usb-hs-phy-msm8916"
> + "qcom,usb-hs-phy-msm8974"
> +
> +- #phy-cells:
> + Usage: required
> + Value type: <u32>
> + Definition: Should contain 0
> +
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain clock specifier for the reference and sleep
> + clocks
> +
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain "ref" and "sleep" for the reference and sleep
> + clocks respectively
> +
> +- resets:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain "phy" and "por" for the phy and POR resets
> + respectively
> +
> +- v3p3-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: Should contain the vbus and ID extcons in the first and second
> + cells respectively
> +
> +- qcom,init-seq:
> + Usage: optional
> + Value type: <u8 array>
> + Definition: Should contain a sequence of ULPI register and address pairs to
> + program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
> + to Device Mode Eye Diagram test.
> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <&pm8941_l24>;
> + v1p8-supply = <&pm8941_l6>;
> + extcon = <&smbb>, <&usb_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 830c443eeabf..ee0ec021a98c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
> help
> Support for UFS PHY on QCOM chipsets.
>
> +config PHY_QCOM_USB_HS
> + tristate "Qualcomm USB HS PHY module"
> + depends on USB_ULPI_BUS
> + select GENERIC_PHY
> + help
> + Support for the USB high-speed ULPI compliant phy on Qualcomm
> + chipsets.
> +
> config PHY_QCOM_USB_HSIC
> tristate "Qualcomm USB HSIC ULPI PHY module"
> depends on USB_ULPI_BUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5422f543d17d..31c84faa07fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS) += phy-qcom-usb-hs.o
> obj-$(CONFIG_PHY_QCOM_USB_HSIC) += phy-qcom-usb-hsic.o
> obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
> obj-$(CONFIG_PHY_BRCM_SATA) += phy-brcm-sata.o
> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
> new file mode 100644
> index 000000000000..73fb4b49a8e1
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-usb-hs.c
> @@ -0,0 +1,289 @@
> +/**
> + * Copyright (C) 2016 Linaro Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/module.h>
> +#include <linux/ulpi/driver.h>
> +#include <linux/ulpi/regs.h>
> +#include <linux/clk.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/of_device.h>
> +#include <linux/reset.h>
> +#include <linux/extcon.h>
> +#include <linux/notifier.h>
> +#include <linux/usb/of.h>
> +
> +#include "ulpi_phy.h"
> +
> +#define ULPI_PWR_CLK_MNG_REG 0x88
> +# define ULPI_PWR_OTG_COMP_DISABLE BIT(0)
> +
> +#define ULPI_MISC_A 0x96
> +# define ULPI_MISC_A_VBUSVLDEXTSEL BIT(1)
> +# define ULPI_MISC_A_VBUSVLDEXT BIT(0)
> +
> +
> +struct ulpi_seq {
> + u8 addr;
> + u8 val;
> +};
> +
> +struct qcom_usb_hs_phy {
> + struct ulpi *ulpi;
> + struct phy *phy;
> + struct clk *ref_clk;
> + struct clk *sleep_clk;
> + struct regulator *v1p8;
> + struct regulator *v3p3;
> + struct reset_control *reset;
> + struct ulpi_seq *init_seq;
> + struct notifier_block vbus_notify;
> + struct extcon_dev *vbus_edev;
> + struct extcon_dev *id_edev;
> + enum usb_dr_mode dr_mode;
> +};
> +
> +static int
> +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> + void *ptr)
> +{
> + struct qcom_usb_hs_phy *uphy;
> + int is_host;
> + u8 addr;
> +
> + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> + if (is_host < 0)
> + is_host = 0; /* No id event means always a peripheral */
> +
> + if (event && !is_host)
> + addr = ULPI_SET(ULPI_MISC_A);
> + else
> + addr = ULPI_CLR(ULPI_MISC_A);
> +
> + return ulpi_write(uphy->ulpi, addr,
> + ULPI_MISC_A_VBUSVLDEXTSEL | ULPI_MISC_A_VBUSVLDEXT);
> +}
> +
> +static int qcom_usb_hs_phy_power_on(struct phy *phy)
> +{
> + struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
> + struct ulpi *ulpi = uphy->ulpi;
> + const struct ulpi_seq *seq;
> + int ret, state;
> +
> + ret = clk_prepare_enable(uphy->ref_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(uphy->sleep_clk);
> + if (ret)
> + goto err_sleep;
> +
> + ret = regulator_set_voltage(uphy->v1p8, 1800000, 1800000);
> + if (ret)
> + goto err_1p8;
> +
> + ret = regulator_set_load(uphy->v1p8, 50000);
> + if (ret < 0)
> + goto err_1p8;
> +
> + ret = regulator_enable(uphy->v1p8);
> + if (ret)
> + goto err_1p8;
> +
> + ret = regulator_set_voltage_triplet(uphy->v3p3, 3050000, 3300000,
> + 3300000);
> + if (ret)
> + goto err_3p3;
> +
> + ret = regulator_set_load(uphy->v3p3, 50000);
> + if (ret < 0)
> + goto err_3p3;
> +
> + ret = regulator_enable(uphy->v3p3);
> + if (ret)
> + goto err_3p3;
> +
> + for (seq = uphy->init_seq; seq->addr; seq++) {
> + ret = ulpi_write(ulpi, seq->addr, seq->val);
> + if (ret)
> + goto err_ulpi;
> + }
> +
> + if (uphy->reset) {
> + ret = reset_control_reset(uphy->reset);
> + if (ret)
> + goto err_ulpi;
> + }
> +
> + if (uphy->vbus_edev) {
> + ulpi_write(ulpi, ULPI_SET(ULPI_PWR_CLK_MNG_REG),
> + ULPI_PWR_OTG_COMP_DISABLE);
> + state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
> + /* setup initial state */
> + qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
> + uphy->vbus_edev);
> + ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
> + &uphy->vbus_notify);
> + if (ret)
> + return ret;
> + } else {
> + u8 val;
> +
> + switch (uphy->dr_mode) {
> + case USB_DR_MODE_OTG:
> + val = ULPI_INT_IDGRD;
> + case USB_DR_MODE_PERIPHERAL:
> + val |= ULPI_INT_SESS_VALID;
> + break;
> + default:
> + val = 0;
> + }
> +
> + ret = ulpi_write(ulpi, ULPI_USB_INT_EN_RISE, val);
> + if (ret)
> + goto err_ulpi;
> + ret = ulpi_write(ulpi, ULPI_USB_INT_EN_FALL, val);
> + if (ret)
> + goto err_ulpi;
> + }
> +
> + return 0;
> +err_ulpi:
> + regulator_disable(uphy->v3p3);
> +err_3p3:
> + regulator_disable(uphy->v1p8);
> +err_1p8:
> + clk_disable_unprepare(uphy->sleep_clk);
> +err_sleep:
> + clk_disable_unprepare(uphy->ref_clk);
> + return ret;
> +}
> +
> +static int qcom_usb_hs_phy_power_off(struct phy *phy)
> +{
> + int ret;
> + struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
> +
> + if (uphy->vbus_edev) {
> + ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
> + &uphy->vbus_notify);
> + if (ret)
> + return ret;
> + }
> +
> + regulator_disable(uphy->v3p3);
> + regulator_disable(uphy->v1p8);
> + clk_disable_unprepare(uphy->sleep_clk);
> + clk_disable_unprepare(uphy->ref_clk);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops qcom_usb_hs_phy_ops = {
> + .power_on = qcom_usb_hs_phy_power_on,
> + .power_off = qcom_usb_hs_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int qcom_usb_hs_phy_probe(struct ulpi *ulpi)
> +{
> + struct qcom_usb_hs_phy *uphy;
> + struct phy_provider *p;
> + struct clk *clk;
> + struct regulator *reg;
> + struct reset_control *reset;
> + int size;
> + int ret;
> +
> + uphy = devm_kzalloc(&ulpi->dev, sizeof(*uphy), GFP_KERNEL);
> + if (!uphy)
> + return -ENOMEM;
> + ulpi_set_drvdata(ulpi, uphy);
> + uphy->ulpi = ulpi;
> + uphy->dr_mode = of_usb_get_dr_mode_by_phy(ulpi->dev.of_node, -1);
> +
> + size = of_property_count_u8_elems(ulpi->dev.of_node, "qcom,init-seq");
> + if (size < 0)
> + size = 0;
> + uphy->init_seq = devm_kmalloc_array(&ulpi->dev, (size / 2) + 1,
> + sizeof(*uphy->init_seq), GFP_KERNEL);
> + if (!uphy->init_seq)
> + return -ENOMEM;
> + ret = of_property_read_u8_array(ulpi->dev.of_node, "qcom,init-seq",
> + (u8 *)uphy->init_seq, size);
> + if (ret && size)
> + return ret;
> + /* NUL terminate */
> + uphy->init_seq[size / 2].addr = uphy->init_seq[size / 2].val = 0;
> +
> + uphy->ref_clk = clk = devm_clk_get(&ulpi->dev, "ref");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + uphy->sleep_clk = clk = devm_clk_get(&ulpi->dev, "sleep");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + uphy->v1p8 = reg = devm_regulator_get(&ulpi->dev, "v1p8");
> + if (IS_ERR(reg))
> + return PTR_ERR(reg);
> +
> + uphy->v3p3 = reg = devm_regulator_get(&ulpi->dev, "v3p3");
> + if (IS_ERR(reg))
> + return PTR_ERR(reg);
> +
> + uphy->reset = reset = devm_reset_control_get(&ulpi->dev, "por");
> + if (IS_ERR(reset)) {
> + if (PTR_ERR(reset) == -EPROBE_DEFER)
> + return PTR_ERR(reset);
> + uphy->reset = NULL;
> + }
> +
> + uphy->phy = devm_phy_create(&ulpi->dev, ulpi->dev.of_node,
> + &qcom_usb_hs_phy_ops);
> + if (IS_ERR(uphy->phy))
> + return PTR_ERR(uphy->phy);
> +
> + uphy->vbus_edev = extcon_get_edev_by_phandle(&ulpi->dev, 0);
> + if (IS_ERR(uphy->vbus_edev)) {
> + if (PTR_ERR(uphy->vbus_edev) != -ENODEV)
> + return PTR_ERR(uphy->vbus_edev);
> + uphy->vbus_edev = NULL;
> + }
> +
> + uphy->id_edev = extcon_get_edev_by_phandle(&ulpi->dev, 1);
> + if (IS_ERR(uphy->id_edev)) {
> + if (PTR_ERR(uphy->id_edev) != -ENODEV)
> + return PTR_ERR(uphy->id_edev);
> + uphy->id_edev = NULL;
> + }
> +
> + uphy->vbus_notify.notifier_call = qcom_usb_hs_phy_vbus_notifier;
> + phy_set_drvdata(uphy->phy, uphy);
> +
> + p = devm_of_phy_provider_register(&ulpi->dev, of_phy_simple_xlate);
> + return PTR_ERR_OR_ZERO(p);
> +}
> +
> +static const struct of_device_id qcom_usb_hs_phy_match[] = {
> + { .compatible = "qcom,usb-hs-phy", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, qcom_usb_hs_phy_match);
> +
> +static struct ulpi_driver qcom_usb_hs_phy_driver = {
> + .probe = qcom_usb_hs_phy_probe,
> + .driver = {
> + .name = "qcom_usb_hs_phy",
> + .of_match_table = qcom_usb_hs_phy_match,
> + },
> +};
> +module_ulpi_driver(qcom_usb_hs_phy_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm USB HS phy");
> +MODULE_LICENSE("GPL v2");
> --
> 2.9.0.rc2.8.ga28705d
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH net-next 2/2] net: mvneta: add BQL support
From: Marcin Wojtas @ 2016-09-13 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473750006-21199-1-git-send-email-mw@semihalf.com>
Tests showed that when whole bandwidth is consumed, the latency for
various kind of traffic can reach high values. With saturated
link (e.g. with iperf from target to host) simple ping could take
significant amount of time. BQL proved to improve this situation
when implemented in mvneta driver. Measurements of ping latency
for 3 link speeds:
Speed | Latency w/o BQL | Latency with BQL
10 | 7-14 ms | 3.5 ms
100 | 2-12 ms | 0.6 ms
1000 | often timeout | up to 2ms
Decreasing latency as above result in sligt performance cost - 4kpps
(-1.4%) when pushing 64B packets via two bridged interfaces of Armada 38x.
For 1500B packets in the same setup, the mpstat tool showed +8% of
CPU occupation (default affinity, second CPU idle). Even though this
cost seems reasonable to take, considering other improvements.
This commit adds byte queue limit mechanism for the mvneta driver.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
drivers/net/ethernet/marvell/mvneta.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index b9dccea..bb5df35 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1719,8 +1719,10 @@ static struct mvneta_tx_queue *mvneta_tx_done_policy(struct mvneta_port *pp,
/* Free tx queue skbuffs */
static void mvneta_txq_bufs_free(struct mvneta_port *pp,
- struct mvneta_tx_queue *txq, int num)
+ struct mvneta_tx_queue *txq, int num,
+ struct netdev_queue *nq)
{
+ unsigned int bytes_compl = 0, pkts_compl = 0;
int i;
for (i = 0; i < num; i++) {
@@ -1728,6 +1730,11 @@ static void mvneta_txq_bufs_free(struct mvneta_port *pp,
txq->txq_get_index;
struct sk_buff *skb = txq->tx_skb[txq->txq_get_index];
+ if (skb) {
+ bytes_compl += skb->len;
+ pkts_compl++;
+ }
+
mvneta_txq_inc_get(txq);
if (!IS_TSO_HEADER(txq, tx_desc->buf_phys_addr))
@@ -1738,6 +1745,8 @@ static void mvneta_txq_bufs_free(struct mvneta_port *pp,
continue;
dev_kfree_skb_any(skb);
}
+
+ netdev_tx_completed_queue(nq, pkts_compl, bytes_compl);
}
/* Handle end of transmission */
@@ -1751,7 +1760,7 @@ static void mvneta_txq_done(struct mvneta_port *pp,
if (!tx_done)
return;
- mvneta_txq_bufs_free(pp, txq, tx_done);
+ mvneta_txq_bufs_free(pp, txq, tx_done, nq);
txq->count -= tx_done;
@@ -2358,6 +2367,8 @@ out:
struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats);
struct netdev_queue *nq = netdev_get_tx_queue(dev, txq_id);
+ netdev_tx_sent_queue(nq, len);
+
txq->count += frags;
if (txq->count >= txq->tx_stop_threshold)
netif_tx_stop_queue(nq);
@@ -2385,9 +2396,10 @@ static void mvneta_txq_done_force(struct mvneta_port *pp,
struct mvneta_tx_queue *txq)
{
+ struct netdev_queue *nq = netdev_get_tx_queue(pp->dev, txq->id);
int tx_done = txq->count;
- mvneta_txq_bufs_free(pp, txq, tx_done);
+ mvneta_txq_bufs_free(pp, txq, tx_done, nq);
/* reset txq */
txq->count = 0;
@@ -2884,6 +2896,8 @@ static int mvneta_txq_init(struct mvneta_port *pp,
static void mvneta_txq_deinit(struct mvneta_port *pp,
struct mvneta_tx_queue *txq)
{
+ struct netdev_queue *nq = netdev_get_tx_queue(pp->dev, txq->id);
+
kfree(txq->tx_skb);
if (txq->tso_hdrs)
@@ -2895,6 +2909,8 @@ static void mvneta_txq_deinit(struct mvneta_port *pp,
txq->size * MVNETA_DESC_ALIGNED_SIZE,
txq->descs, txq->descs_phys);
+ netdev_tx_reset_queue(nq);
+
txq->descs = NULL;
txq->last_desc = 0;
txq->next_desc_to_proc = 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/2] net: mvneta: add xmit_more support
From: Marcin Wojtas @ 2016-09-13 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473750006-21199-1-git-send-email-mw@semihalf.com>
From: Simon Guinot <simon.guinot@sequanux.org>
Basing on xmit_more flag of the skb, TX descriptors can be concatenated
before flushing. This commit delay Tx descriptor flush if the queue is
running and if there is more skb's to send.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
drivers/net/ethernet/marvell/mvneta.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index d41c28d..b9dccea 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -512,6 +512,7 @@ struct mvneta_tx_queue {
* descriptor ring
*/
int count;
+ int pending;
int tx_stop_threshold;
int tx_wake_threshold;
@@ -802,8 +803,9 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
/* Only 255 descriptors can be added at once ; Assume caller
* process TX desriptors in quanta less than 256
*/
- val = pend_desc;
+ val = pend_desc + txq->pending;
mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
+ txq->pending = 0;
}
/* Get pointer to next TX descriptor to be processed (send) by HW */
@@ -2357,11 +2359,14 @@ out:
struct netdev_queue *nq = netdev_get_tx_queue(dev, txq_id);
txq->count += frags;
- mvneta_txq_pend_desc_add(pp, txq, frags);
-
if (txq->count >= txq->tx_stop_threshold)
netif_tx_stop_queue(nq);
+ if (!skb->xmit_more || netif_xmit_stopped(nq))
+ mvneta_txq_pend_desc_add(pp, txq, frags);
+ else
+ txq->pending += frags;
+
u64_stats_update_begin(&stats->syncp);
stats->tx_packets++;
stats->tx_bytes += len;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] mvneta xmit_more and bql support
From: Marcin Wojtas @ 2016-09-13 7:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This short patchset introduces two enhancements to mvneta driver
TX packets concatenation support using xmit_more mechanism and also
byte queue limit in order to decrease latency on saturated links.
Any comments or feedback would be welcome.
Best regards,
Marcin
Marcin Wojtas (1):
net: mvneta: add BQL support
Simon Guinot (1):
net: mvneta: add xmit_more support
drivers/net/ethernet/marvell/mvneta.c | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Geert Uytterhoeven @ 2016-09-13 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912221640.GG7243@codeaurora.org>
Hi Stephen,
On Tue, Sep 13, 2016 at 12:16 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 09/01, Geert Uytterhoeven wrote:
>> On Thu, Jun 30, 2016 at 10:14 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> > On 06/01, Geert Uytterhoeven wrote:
>> >> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> state of the mode pins either by a call from the board code, or directly
>> >> by using a hardcoded register access. This is a bit messy, and creates a
>> >> dependency between driver and platform code.
>> >>
>> >> This RFC patch series converts the various Renesas R-Car clock drivers
>> >> and support code from reading the mode pin states using a hardcoded
>> >> register access to using a new R-Car RST driver.
>> >
>> > Dumb question, can we use the nvmem reading APIs instead of an
>> > SoC specific function to read the modes?
>>
>> Thanks for your suggestion, the nvmem API indeed looks like a suitable API,
>> as it does support read-only nvmems.
>>
>> Unfortunately I also see a few disadvantages:
>> 1. nvmem_init() is a subsys_initcall(), while most of our users (except for
>> the recent renesas-cpg-mssr driver) are clock drivers using
>> CLK_OF_DECLARE(), and are thus initialized from of_clk_init() at much
>> earlier time_init() time.
>> Of course the mvmem subsystem and/or the clock drivers can be changed, if
>> deemed useful.
>
> Sounds like this is solvable.
Sure.
>> 2. Using the nvmem DT bindings means we have to add more DT glue from the
>> nvmem consumer(s) to the nvmem provider. As we need to provide backwards
>> compatibility with old DTSes, this means we need more C code or DT fixup
>> code to handle that.
>
> Ah I wasn't aware we were keeping backwards compatibility around.
>
>> 3. The nvmem subsystem may be overkill to provide access to a simple 32-bit
>> read-only register that never changes value after boot.
>
> The nvmem subsystem is designed to read values from things that
> mostly never change. Overkill may be true, but the nice thing
> about using nvmem APIs is that the driver doesn't have to use
> some platform specific function that duplicates similar
> functionality. It's unfortunate that backwards incompatibility
> limits our ability to move to common linux frameworks when they
> are created after the binding is used.
This is continuing work to support old, current, and new SoCs properly.
When the first support for R-Car Gen2 SoCs was added, many frameworks
didn't have DT support, or didn't even exist.
Unlike in the mobile market, development and life span is much larger than
6 months here...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7] i2c: imx: make bus recovery through pinctrl optional
From: Uwe Kleine-König @ 2016-09-13 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473718950-6667-1-git-send-email-leoyang.li@nxp.com>
On Mon, Sep 12, 2016 at 05:22:30PM -0500, Li Yang wrote:
> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
> driver starts to use gpio/pinctrl to support optional bus recovery
> feature. But pinctrl is not always usable. There are platforms such
> as ls1021a and ls1043a that don't support pinctrl, and it could just
> be broken due to old/broken device tree. The patch makes it really
> optional that the probe function won't bailout on pinctrl problems
> instead it just disables bus recovery and prints out notification when
> there is problem with pinctrl. Since pinctrl is only used by bus
> recovery in this driver, move pinctrl initialization into bus recovery
> init function to prevent confusion.
>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
> Cc: Gao Pan <pandy.gao@nxp.com>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Uwe Kleine-König @ 2016-09-13 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912211254.GA4637@archie.localdomain>
Hello Clemens,
On Mon, Sep 12, 2016 at 11:12:54PM +0200, Clemens Gruber wrote:
> On Mon, Sep 12, 2016 at 10:00:21PM +0200, Uwe Kleine-K?nig wrote:
> > I want that the pwm driver disables its clock on pwm_config(mypwm, 0,
> > someperiod) such that the consumer doesn't need to call
> > pwm_disable(mypwm) to save power (assuming it's safe to do so, which
> > only the pwm provider knows).
>
> I am not sure if this is such a good idea, because there are use cases
> where you want to keep the PWM driver enabled the whole time but still
> be able to change the duty cycle to 0 for some time without adding
> unnecessary delays when changing the duty cycle back to something else.
>
> We have an application where we control fluid valves in a beer
> dispensing system through PWMs and these valves are pulsed with
> different PWM duty cycles for a short time. In-between the duty cycle
> is also 0. For example: Start at 0%, 100ms 90%, 200ms 70%, 300ms 0%,
> 100ms 90%, and so on..
> There it is critical that the change from and to 0 duty cycle is not
> delayed by disabling and reenabling the clock.
> The oscillator (if there is one) should be up and running, only the duty
> cycle should be 0 for a short time.
I don't think it is sensible to map this requirement in the pwm api. The
trade-off between performance and power saving is common between all
types of devices and there are other mechanisms to handle this.
Also only some pwms are affected by this because disabling the clock
doesn't introduce a measurable overhead for all of them.
With write(2) there is also no way to define if the hard disk should
spin down after the request is completed. And this wouldn't make sense
for an ssd.
So yes, there would be no way to prohibit stopping the pwm with the pwm
API, but you could implement runtime pm for your device.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Tomasz Nowicki @ 2016-09-13 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDk0JPJYT_pqjWYwrMBvbyWkpL+6=dEDU9H9qDGMhnQvyw@mail.gmail.com>
On 13.09.2016 00:24, Duc Dang wrote:
> On Fri, Sep 9, 2016 at 12:24 PM, Tomasz Nowicki <tn@semihalf.com> wrote:
>>
>> Some platforms may not be fully compliant with generic set of PCI config
>> accessors. For these cases we implement the way to overwrite CFG accessors
>> set and configuration space range.
>>
>> In first place pci_mcfg_parse() saves machine's IDs and revision number
>> (these come from MCFG header) in order to match against known quirk entries.
>> Then the algorithm traverses available quirk list (static array),
>> matches against <oem_id, oem_table_id, rev, domain, bus number range> and
>> returns custom PCI config ops and/or CFG resource structure.
>>
>> When adding new quirk there are two possibilities:
>> 1. Override default pci_generic_ecam_ops ops but CFG resource comes from MCFG
>> { "OEM_ID", "OEM_TABLE_ID", <REV>, <DOMAIN>, <BUS_NR>, &foo_ops, MCFG_RES_EMPTY },
>> 2. Override default pci_generic_ecam_ops ops and CFG resource. For this case
>> it is also allowed get CFG resource from quirk entry w/o having it in MCFG.
>> { "OEM_ID", "OEM_TABLE_ID", <REV>, <DOMAIN>, <BUS_NR>, &boo_ops,
>> DEFINE_RES_MEM(START, SIZE) },
>>
>> pci_generic_ecam_ops and MCFG entries will be used for platforms
>> free from quirks.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> drivers/acpi/pci_mcfg.c | 80 +++++++++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 74 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index ffcc651..2b8acc7 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -32,6 +32,59 @@ struct mcfg_entry {
>> u8 bus_start;
>> u8 bus_end;
>> };
>> +struct mcfg_fixup {
>> + char oem_id[ACPI_OEM_ID_SIZE + 1];
>> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
>> + u32 oem_revision;
>> + u16 seg;
>> + struct resource bus_range;
>> + struct pci_ecam_ops *ops;
>> + struct resource cfgres;
>> +};
>> +
>> +#define MCFG_DOM_ANY (-1)
>> +#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start), \
>> + ((end) - (start) + 1), \
>> + NULL, IORESOURCE_BUS)
>> +#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
>> +#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
>> +
>> +static struct mcfg_fixup mcfg_quirks[] = {
>> +/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
>> +};
>> +
>> +static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
>> +static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
>> +static u32 mcfg_oem_revision;
>> +
>> +static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
>> + struct resource *cfgres,
>> + struct pci_ecam_ops **ecam_ops)
>> +{
>> + struct mcfg_fixup *f;
>> + int i;
>> +
>> + /*
>> + * First match against PCI topology <domain:bus> then use OEM ID, OEM
>> + * table ID, and OEM revision from MCFG table standard header.
>> + */
>> + for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
>> + if (f->seg == root->segment &&
>
> Is dropping the comparison with MCFG_DOM_ANY intended? It is useful if
> all the controllers (segs) can use the same quirk (X-Gene case).
MCFG_DOM_ANY makes sense only if we want to use the same ops for segment
range, but not for CFG range manipulation. So we can add MCFG_DOM_ANY
back here in the hope it will be used properly.
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 2/6] ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.
From: Gerd Hoffmann @ 2016-09-13 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <103847685.101383.df740dd1-92f3-4978-9442-1f1b3a81e9da.open-xchange@email.1und1.de>
Hi,
> > > + emmc_gpio48: emmc_gpio48 {
> > > + brcm,pins = <48 49 50 51 52 53>;
> > > + brcm,function = <BCM2835_FSEL_ALT3>;
> > > + };
> >
> > Sorry, i didn't notice this before. The naming of these groups suggest 3 muxes
> > for the same eMMC interface. I thought there is a eMMC interface and a SD host
> > interface with different DMA channels.
> >
> > > +
> > > ...
> > > +
> > > + sdhost_gpio48: sdhost_gpio48 {
> > > + brcm,pins = <48 49 50 51 52 53>;
> > > + brcm,function = <BCM2835_FSEL_ALT0>;
> > > + };
> >
> > I think this incorrect. There is no function ALT0 for these pins, only ALT3.
>
> please forget my last 2 comments. According to this page [1] eMMC is selected by
> ALT3 and sdhost is selected by ALT0.
>
> Do you know a reliable source where all muxes for both interface are documented?
> The datasheet isn't very helpful here.
No, I don't know any source better than the datasheet @ github.
Yes, I tried to double-check things with the sheet too.
IIRC Eric mentioned a while back in some mail or patch that he checked
something for the rpi device tree with non-public docs, not fully sure
though whenever it was emmc/sdhost or something else. But I'm basically
trusting Eric here ...
cheers,
Gerd
PS: This is exactly why I think it us useful to have all those entries
in the dt file even if unused: To serve as documentation.
^ permalink raw reply
* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Tomasz Nowicki @ 2016-09-13 6:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D76626.1050109@huawei.com>
Hi Liu,
On 13.09.2016 04:36, Dongdong Liu wrote:
> Hi Tomasz
>
> ? 2016/9/10 3:24, Tomasz Nowicki ??:
>> Some platforms may not be fully compliant with generic set of PCI config
>> accessors. For these cases we implement the way to overwrite CFG
>> accessors
>> set and configuration space range.
>>
>> In first place pci_mcfg_parse() saves machine's IDs and revision number
>> (these come from MCFG header) in order to match against known quirk
>> entries.
>> Then the algorithm traverses available quirk list (static array),
>> matches against <oem_id, oem_table_id, rev, domain, bus number range> and
>> returns custom PCI config ops and/or CFG resource structure.
>>
>> When adding new quirk there are two possibilities:
>> 1. Override default pci_generic_ecam_ops ops but CFG resource comes
>> from MCFG
>> { "OEM_ID", "OEM_TABLE_ID", <REV>, <DOMAIN>, <BUS_NR>, &foo_ops,
>> MCFG_RES_EMPTY },
>> 2. Override default pci_generic_ecam_ops ops and CFG resource. For
>> this case
>> it is also allowed get CFG resource from quirk entry w/o having it in
>> MCFG.
>> { "OEM_ID", "OEM_TABLE_ID", <REV>, <DOMAIN>, <BUS_NR>, &boo_ops,
>> DEFINE_RES_MEM(START, SIZE) },
>>
>> pci_generic_ecam_ops and MCFG entries will be used for platforms
>> free from quirks.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> drivers/acpi/pci_mcfg.c | 80
>> +++++++++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 74 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index ffcc651..2b8acc7 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -32,6 +32,59 @@ struct mcfg_entry {
>> u8 bus_start;
>> u8 bus_end;
>> };
>> +struct mcfg_fixup {
>> + char oem_id[ACPI_OEM_ID_SIZE + 1];
>> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
>> + u32 oem_revision;
>> + u16 seg;
>> + struct resource bus_range;
>> + struct pci_ecam_ops *ops;
>> + struct resource cfgres;
>> +};
>> +
>> +#define MCFG_DOM_ANY (-1)
>> +#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start), \
>> + ((end) - (start) + 1), \
>> + NULL, IORESOURCE_BUS)
>> +#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
>> +#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
>> +
>> +static struct mcfg_fixup mcfg_quirks[] = {
>> +/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
>> +};
>> +
>> +static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
>> +static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
>> +static u32 mcfg_oem_revision;
>> +
>> +static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
>> + struct resource *cfgres,
>> + struct pci_ecam_ops **ecam_ops)
>> +{
>> + struct mcfg_fixup *f;
>> + int i;
>> +
>> + /*
>> + * First match against PCI topology <domain:bus> then use OEM ID,
>> OEM
>> + * table ID, and OEM revision from MCFG table standard header.
>> + */
>> + for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++,
>> f++) {
>> + if (f->seg == root->segment &&
>
> why not use MCFG_DOM_RANGE, I think MCFG_DOM_RANGE is better.
> if drop MCFG_DOM_RANGE, mcfg_quirks[] will be more complex.
>
> static struct mcfg_fixup mcfg_quirks[] = {
> /* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> /* SoC pass1.x */
> { "CAVIUM", "THUNDERX", 2, 0, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 1, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 2, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 3, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 10, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 11, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 12, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> { "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> #endif
> .....
> };
>
> As PATCH v5 we only need define mcfg_quirks as below, It looks better.
> static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
> /* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook
> }, */
> #ifdef CONFIG_PCI_HOST_THUNDER_PEM
> /* Pass2.0 */
> { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(4, 9), MCFG_BUS_ANY, NULL,
> thunder_pem_cfg_init },
> { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY, NULL,
> thunder_pem_cfg_init },
> #endif
> #ifdef CONFIG_PCI_HISI_ACPI
> { "HISI ", "HIP05 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> NULL, hisi_pcie_acpi_hip05_init},
> { "HISI ", "HIP06 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> NULL, hisi_pcie_acpi_hip06_init},
> { "HISI ", "HIP07 ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
> NULL, hisi_pcie_acpi_hip07_init},
> #endif
> };
Note this series disallow hisi_pcie_acpi_hip07_init() call. According to
the Bjorn suggestion I rework quirk code to override ops and CFG
resources only. Giving that I do not see the way to use MCFG_DOM_RANGE
macro. For HISI you would need to get CFG range for each possible case:
#ifdef CONFIG_PCI_HISI_ACPI
{ "HISI ", "HIP05 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_ops,
DEFINE_RES_MEM(start0, size0)},
{ "HISI ", "HIP05 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_ops,
DEFINE_RES_MEM(start1, size1)},
{ "HISI ", "HIP05 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_ops,
DEFINE_RES_MEM(start2, size2)},
{ "HISI ", "HIP05 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_ops,
DEFINE_RES_MEM(start3, size3)},
[...]
#endif
Indeed there are more entries here but you do not have to define the
same resource array in driver.
Thanks,
Tomasz
^ 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