* [PATCH v5 3/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
From: Guillaume Tucker @ 2017-05-03 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493804968.git.guillaume.tucker@collabora.com>
Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform. Tested on a Radxa Rock2 Square board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index 1c0bbc9b928b..f694867fa46a 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -301,3 +301,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Guillaume Tucker @ 2017-05-03 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493804968.git.guillaume.tucker@collabora.com>
Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index df8a0dbe9d91..35969041eae2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -43,6 +43,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/clock/rk3288-cru.h>
+#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/thermal/thermal.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/soc/rockchip,boot-mode.h>
@@ -1117,6 +1118,48 @@
};
};
+ gpu: mali at ffa30000 {
+ compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
+ reg = <0xffa30000 0x10000>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&cru ACLK_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3288_PD_GPU>;
+ status = "disabled";
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <950000>;
+ };
+ opp at 200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <950000>;
+ };
+ opp at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1100000>;
+ };
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1200000>;
+ };
+ opp at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1250000>;
+ };
+ };
+
qos_gpu_r: qos at ffaa0000 {
compatible = "syscon";
reg = <0xffaa0000 0x20>;
--
2.11.0
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-05-03 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493804968.git.guillaume.tucker@collabora.com>
The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.
Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:
https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
Remove the copyright and GPL licence header as deemed not necessary.
Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and add vendor specific ones.
Drop the "clock-names" property as the Mali Midgard GPU uses only one
clock (the driver now needs to call clk_get with NULL).
Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".
Replace the deprecated "operating-points" optional property with
"operating-points-v2".
Omit the following optional properties in this initial version as they
are only used in very specific cases:
* snoop_enable_smc
* snoop_disable_smc
* jm_config
* power_model
* system-coherency
* ipa-model
Update the example accordingly to reflect all these changes, based on
rk3288 mali-t760.
CC: John Reitan <john.reitan@arm.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 86 ++++++++++++++++++++++
1 file changed, 86 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
new file mode 100644
index 000000000000..d3b6e1a4713a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -0,0 +1,86 @@
+ARM Mali Midgard GPU
+====================
+
+Required properties:
+
+- compatible :
+ * Must contain one of the following:
+ + "arm,mali-t604"
+ + "arm,mali-t624"
+ + "arm,mali-t628"
+ + "arm,mali-t720"
+ + "arm,mali-t760"
+ + "arm,mali-t820"
+ + "arm,mali-t830"
+ + "arm,mali-t860"
+ + "arm,mali-t880"
+ * which must be preceded by one of the following vendor specifics:
+ + "amlogic,meson-gxm-mali"
+ + "rockchip,rk3288-mali"
+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+ provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Midgard device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+ Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details.
+
+
+Example for a Mali-T760:
+
+gpu at ffa30000 {
+ compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
+ reg = <0xffa30000 0x10000>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&cru ACLK_GPU>;
+ mali-supply = <&vdd_gpu>;
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3288_PD_GPU>;
+};
+
+gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 533000000 {
+ opp-hz = /bits/ 64 <533000000>;
+ opp-microvolt = <1250000>;
+ };
+ opp at 450000000 {
+ opp-hz = /bits/ 64 <450000000>;
+ opp-microvolt = <1150000>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1125000>;
+ };
+ opp at 350000000 {
+ opp-hz = /bits/ 64 <350000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp at 266000000 {
+ opp-hz = /bits/ 64 <266000000>;
+ opp-microvolt = <1025000>;
+ };
+ opp at 160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ opp-microvolt = <925000>;
+ };
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <912500>;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
From: Guillaume Tucker @ 2017-05-03 9:56 UTC (permalink / raw)
To: linux-arm-kernel
The ARM Mali Midgard GPU kernel driver is only available
out-of-tree and is not going to be merged in its current form.
However, it would be useful to have its device tree bindings
merged. In particular, this would enable distributions to create
working driver packages (dkms...) without having to patch the
kernel.
The bindings for the earlier Mali Utgard GPU family have already
been merged, so this is essentially the same scenario but for
newer GPUs (Mali-T604 ~ Mali-T880).
This series of patches first imports the bindings from the latest
driver release with some clean-up then adds a gpu node for the
rk3288 SoC. This was successfully tested on Radxa Rock2 Square,
Firefly, Veyron Minnie and Jerry boards using Mali kernel driver
r16p0 and r12p0 user-space binary.
Changes since v1:
- enabled gpu on rk3288-veyron boards
Changes since v2:
- removed "clk-names" property and "clk_mali" name
- converted values of "interrupt-names" property to
lower-case: "job", "mmu" and "gpu"
- replaced dt compatible strings with list of all Midgard GPU variants and
optional vendors
- cleaned up gpu node example
Changes since v3:
- add "rockchip,rk3288-mali" vendor compatible string
- move gpu node at the right location in rk3288.dtsi
- use operating-points-v2 in documentation and rk3288.dtsi
Changes since v4:
- removed wildcards (mali-t60x, -t62x)
- vendor compatible strings are not optional any more
- example updated accordingly, based on rk3288
Enric Balletbo i Serra (1):
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
Guillaume Tucker (4):
dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
ARM: dts: rockchip: add ARM Mali GPU node for rk3288
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 86 ++++++++++++++++++++++
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 ++
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 ++
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 ++
arch/arm/boot/dts/rk3288.dtsi | 43 +++++++++++
5 files changed, 144 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
--
2.11.0
^ permalink raw reply
* [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Robin Murphy @ 2017-05-03 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdV05uCcVss+V1E+_OQYosJO6P95rU1WynV-G08-iHJnyg@mail.gmail.com>
Hi Geert,
On 02/05/17 19:35, Geert Uytterhoeven wrote:
> Hi Sricharan,
>
> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R <sricharan@codeaurora.org> wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>
> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
> properties in DT now fail to probe.
How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
registered then they should merely defer until we reach the point of
giving up and ignoring the IOMMU. Is it just that you have no other
late-probing drivers or post-init module loads to kick the deferred
queue after that point? I did try to find a way to explicitly kick it
from a suitably late initcall, but there didn't seem to be any obvious
public interface - anyone have any suggestions?
I think that's more of a general problem with the probe deferral
mechanism itself (I've seen the same thing happen with some of the
CoreSight stuff on Juno due to the number of inter-component
dependencies) rather than any specific fault of this series.
Robin.
> This can be fixed by either:
> - Disabling CONFIG_IPMMU_VMSA, or
> - Reverting commit 7b07cbefb68d486f (but keeping "int ret = 0;").
>
> Note that this was a bit hard to investigate, as R-Car Gen3 support wasn't
> upstreamed yet, so bisection pointed to a merge commit.
>
>> ---
>> [*] Fixed minor comment from Bjorn for removing the pci.h header inclusion
>> in of_iommu.c
>>
>> drivers/base/dma-mapping.c | 5 +++--
>> drivers/iommu/of_iommu.c | 4 ++--
>> drivers/of/device.c | 7 ++++++-
>> include/linux/of_device.h | 9 ++++++---
>> 4 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> index 449b948..82bd45c 100644
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
>> @@ -353,6 +353,7 @@ int dma_configure(struct device *dev)
>> {
>> struct device *bridge = NULL, *dma_dev = dev;
>> enum dev_dma_attr attr;
>> + int ret = 0;
>>
>> if (dev_is_pci(dev)) {
>> bridge = pci_get_host_bridge_device(to_pci_dev(dev));
>> @@ -363,7 +364,7 @@ int dma_configure(struct device *dev)
>> }
>>
>> if (dma_dev->of_node) {
>> - of_dma_configure(dev, dma_dev->of_node);
>> + ret = of_dma_configure(dev, dma_dev->of_node);
>> } else if (has_acpi_companion(dma_dev)) {
>> attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
>> if (attr != DEV_DMA_NOT_SUPPORTED)
>> @@ -373,7 +374,7 @@ int dma_configure(struct device *dev)
>> if (bridge)
>> pci_put_host_bridge_device(bridge);
>>
>> - return 0;
>> + return ret;
>> }
>>
>> void dma_deconfigure(struct device *dev)
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 1f92d98..2d04663 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -236,7 +236,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> ops = ERR_PTR(err);
>> }
>>
>> - return IS_ERR(ops) ? NULL : ops;
>> + return ops;
>> }
>>
>> static int __init of_iommu_init(void)
>> @@ -247,7 +247,7 @@ static int __init of_iommu_init(void)
>> for_each_matching_node_and_match(np, matches, &match) {
>> const of_iommu_init_fn init_fn = match->data;
>>
>> - if (init_fn(np))
>> + if (init_fn && init_fn(np))
>> pr_err("Failed to initialise IOMMU %s\n",
>> of_node_full_name(np));
>> }
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..ba51ca6 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
>> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
>> * to fix up DMA configuration.
>> */
>> -void of_dma_configure(struct device *dev, struct device_node *np)
>> +int of_dma_configure(struct device *dev, struct device_node *np)
>> {
>> u64 dma_addr, paddr, size;
>> int ret;
>> @@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> coherent ? " " : " not ");
>>
>> iommu = of_iommu_configure(dev, np);
>> + if (IS_ERR(iommu))
>> + return PTR_ERR(iommu);
>> +
>> dev_dbg(dev, "device is%sbehind an iommu\n",
>> iommu ? " " : " not ");
>>
>> arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL_GPL(of_dma_configure);
>>
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index 3cb2288..9499861 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -56,7 +56,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
>> return of_node_get(cpu_dev->of_node);
>> }
>>
>> -void of_dma_configure(struct device *dev, struct device_node *np);
>> +int of_dma_configure(struct device *dev, struct device_node *np);
>> void of_dma_deconfigure(struct device *dev);
>> #else /* CONFIG_OF */
>>
>> @@ -105,8 +105,11 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
>> {
>> return NULL;
>> }
>> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
>> -{}
>> +
>> +static inline int of_dma_configure(struct device *dev, struct device_node *np)
>> +{
>> + return 0;
>> +}
>> static inline void of_dma_deconfigure(struct device *dev)
>> {}
>> #endif /* CONFIG_OF */
>
> 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
* [RFC PATCH] mtd: spi-nor: handle signal case as failure
From: Nicholas Mc Guire @ 2017-05-03 9:53 UTC (permalink / raw)
To: linux-arm-kernel
The problem is that stm32_qspi_wait_cmd() will indicate success in case of
being interrupted. The if condition is incomplete here as
wait_for_copletion_interruptible_timeout can return -ERESTARTSYS but this
is not handled by if(!wait_for_completion_interruptible_timeout()).
While somewhat unlikely it probably would be hard to figure out what went
wrong if the signal case does occur.
Fixes: commit 0d43d7ab277a ("mtd: spi-nor: add driver for STM32 quad spi flash controller")
Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
---
Problem found by experimental coccinelle script
Its not clear if its sufficient to simply treat this case as failure or
if it might need some debug output to allow differentiation of signal
and timeout case.
Patch was compile tested with: stm32_defconfig +CONFIG_MTD=y, CONFIG_MTD_SPI_NOR=y,
CONFIG_SPI_STM32_QUADSPI=m
Patch is against v4.11-rc8 (localversion-next is next-20170503)
drivers/mtd/spi-nor/stm32-quadspi.c | 10 ++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c b/drivers/mtd/spi-nor/stm32-quadspi.c
index 1056e74..27147ad 100644
--- a/drivers/mtd/spi-nor/stm32-quadspi.c
+++ b/drivers/mtd/spi-nor/stm32-quadspi.c
@@ -159,6 +159,7 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi)
{
u32 cr;
int err = 0;
+ long timeout = 0;
if (readl_relaxed(qspi->io_base + QUADSPI_SR) & SR_TCF)
return 0;
@@ -167,8 +168,13 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi)
cr = readl_relaxed(qspi->io_base + QUADSPI_CR);
writel_relaxed(cr | CR_TCIE, qspi->io_base + QUADSPI_CR);
- if (!wait_for_completion_interruptible_timeout(&qspi->cmd_completion,
- msecs_to_jiffies(1000)))
+ timeout = wait_for_completion_interruptible_timeout(
+ &qspi->cmd_completion, msecs_to_jiffies(1000));
+
+ /* since the calling side only cares about success of failure
+ * returning -ETIMEDOUT even when interrupted should be ok here
+ */
+ if (timeout == 0 || timeout == -ERESTARTSYS)
err = -ETIMEDOUT;
writel_relaxed(cr, qspi->io_base + QUADSPI_CR);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74
From: Will Deacon @ 2017-05-03 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANHdaibvzp22XEa3NnKAKUtrHcWGc9oUcnM8KubcYCzEfOaKJg@mail.gmail.com>
Hi Geetha,
On Tue, May 02, 2017 at 12:01:15PM +0530, Geetha Akula wrote:
> SMMU_IIDR register is broken on T99, that the reason we are using MIDR.
Urgh, that's unfortunate. In what way is it broken?
> If using MIDR is not accepted, can we enable errata based on SMMU resource size?
> some thing like below.
No, you need to get your model number added to IORT after all if the IIDR
can't uniqely identify the part.
Sorry,
Will
^ permalink raw reply
* [PATCH 3/4] net: macb: Add hardware PTP support
From: Richard Cochran @ 2017-05-03 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BN3PR07MB2516757CB4EA7367F6623C06C9170@BN3PR07MB2516.namprd07.prod.outlook.com>
On Tue, May 02, 2017 at 01:57:15PM +0000, Rafal Ozieblo wrote:
> > What is the point of this wrapper function anyhow? Please remove it.
> gem_ptp_gettime() is assigned in ptp_clock_info and it has to have
> ptp_clock_info pointer as first parameter. gem_tsu_get_time() is used in
> the source code but with macb pointer.
> Do you want me to do something like:
> gem_ptp_gettime(macb->ptp, ts);
> and first would be getting macb pointer from ptp ?
> struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
Yes. Unless your sub-function is used in more than one place, then it
is wasteful and confusing to wrap the functionality for no apparent
reason.
> > > + switch (rq->type) {
> > > + case PTP_CLK_REQ_EXTTS: /* Toggle TSU match interrupt */
> > > + if (on)
> > > + macb_writel(bp, IER, MACB_BIT(TCI));
> >
> > No locking to protect IER and IDE?
> There is no need.
But what happens when the PTP_CLK_REQ_EXTTS and PTP_CLK_REQ_PPS ioctls
are called at the same time?
You need to ensure that IDR is consistent. If the bits are write
only, then you should comment this fact.
> > > + else
> > > + macb_writel(bp, IDR, MACB_BIT(TCI));
> > > + break;
> > > + case PTP_CLK_REQ_PEROUT: /* Toggle Periodic output */
> > > + return -EOPNOTSUPP;
> > > + /* break; */
> > > + case PTP_CLK_REQ_PPS: /* Toggle TSU periodic (second)
> > interrupt */
> > > + if (on)
> > > + macb_writel(bp, IER, MACB_BIT(SRI));
> > > + else
> > > + macb_writel(bp, IDR, MACB_BIT(SRI));
> > > + break;
> > > + default:
> > > + break;
> > > + }
> > > + return 0;
> > > +}
Thanks,
Richard
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6qdl-nitrogen6_max: fix rv4162 compatible
From: Shawn Guo @ 2017-05-03 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419202204.7689-1-alexandre.belloni@free-electrons.com>
On Wed, Apr 19, 2017 at 10:22:02PM +0200, Alexandre Belloni wrote:
> The rv4162 vendor is microcrystal, not ST.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> index bad3c9f9eeac..b63134e3b51a 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> @@ -408,7 +408,7 @@
> };
>
> rtc: rtc at 68 {
> - compatible = "st,rv4162";
> + compatible = "microcrystal,rv4162";
The compatible is not documented?
Shawn
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_rv4162>;
> reg = <0x68>;
> --
> 2.11.0
>
^ permalink raw reply
* [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
From: Maxime Ripard @ 2017-05-03 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67Szt9Xj+hwJD6i9X0XgXOtZBS1Jy4wWjbfSGJSDFM1NQ@mail.gmail.com>
On Wed, Apr 26, 2017 at 03:59:28PM +0800, Chen-Yu Tsai wrote:
> >> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> >> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> >> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> >> > +
> >> > + x = mode->htotal - mode->hsync_start;
> >> > + y = mode->vtotal - mode->vsync_start;
> >>
> >> I'm a bit skeptical about this one. All the other parameters are not
> >> inclusive of other, why would this one be different? Shouldn't it
> >> be "Xtotal - Xsync_end" instead?
> >
> > By the usual meaning of backporch, you're right. However, Allwinner's
> > seems to have it's own, which is actually the backporch + sync length.
> >
> > We also have that on all the other connectors (and TCON), and this was
> > confirmed at the time using a scope on an RGB signal.
>
> Yes. On the later SoCs such as the A31, the user manual actually has
> timing diagrams showing this.
>
> Unlike the TCON, the HDMI controller's timings lists the front porch
> separately, instead of an all inclusive Xtotal. This is what made me
> look twice. This should be easy to confirm though. Since the HDMI modes
> are well known and can be exactly reproduced on our hardware, we can
> just check for any distortions or refresh rate errors.
This isn't as trivial as that. Screens usually have some tolerancies
on the timings, which will probably make it go unnoticed, even though
they are wrong.
> >>
> >> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> >> > +
> >> > + x = mode->hsync_start - mode->hdisplay;
> >> > + y = mode->vsync_start - mode->vdisplay;
> >> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> >> > +
> >> > + x = mode->hsync_end - mode->hsync_start;
> >> > + y = mode->vsync_end - mode->vsync_start;
> >> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> >> > +
> >> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> >> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> >> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> >> > +
> >> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> >> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> >> > +
> >> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
> >>
> >> You don't handle the interlaced video here, even though you set
> >>
> >> hdmi->connector.interlace_allowed = true
> >>
> >> later.
> >
> > I'll fix that.
> >
> >> The double clock and double scan flags aren't handled either, though
> >> I don't understand which one is supposed to represent the need for the
> >> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> >> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
> >
> > I'm not sure about this one though. I'd like to keep things quite
> > simple for now and build up on that once the basis is working. Is it
> > common in the wild?
>
> If you drive the display at SDTV resolutions, then yes. Mode lines from
> my HDMI monitor:
>
> 720x576i 50 720 732 795 864 576 580 586 625 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
> 720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
> 720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
>
> AFAIK these are standard modes that all devices should support. Whether
> they are used daily is another thing. Maybe block modes with dblclk
> in .mode_fixup for now?
That would rather be atomic_check and / or mode_valid, but yeah, I can
do that.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170503/5a341757/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 7/7] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Shawn Guo @ 2017-05-03 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-8-andrew.smirnov@gmail.com>
On Tue, Apr 18, 2017 at 08:01:33AM -0700, Andrey Smirnov wrote:
> Enable PCIe peripheral on this board.
>
> Cc: yurovsky at gmail.com
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7d-sdb.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index d6f2dda..65dda66 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -349,6 +349,12 @@
> };
> };
>
> +&pcie {
> + pinctrl-names = "default";
No corresponding pinctrl-0 entry? In that case, there is no point to
have pinctrl-names.
Shawn
> + reset-gpio = <&extended_io 1 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> &pwm1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pwm1>;
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 6/7] ARM: dts: imx7d: Add node for PCIe controller
From: Shawn Guo @ 2017-05-03 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-7-andrew.smirnov@gmail.com>
On Tue, Apr 18, 2017 at 08:01:32AM -0700, Andrey Smirnov wrote:
> Cc: yurovsky at gmail.com
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7d.dtsi | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index f6dee41..f46814a 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -42,6 +42,7 @@
> */
>
> #include "imx7s.dtsi"
> +#include <dt-bindings/reset/imx7-reset.h>
It has dependency on imx7 reset driver, and I need to wait for
v4.12-rc1 to apply the patch.
Shawn
^ permalink raw reply
* [PATCH v2 3/7] ARM: dts: imx7s: Add node for GPC
From: Shawn Guo @ 2017-05-03 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-4-andrew.smirnov@gmail.com>
On Tue, Apr 18, 2017 at 08:01:29AM -0700, Andrey Smirnov wrote:
> Add node for GPC and specify as a parent interrupt controller for SoC bus.
>
> Cc: yurovsky at gmail.com
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7s.dtsi | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 7148eac..5ba1289 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -42,6 +42,7 @@
> */
>
> #include <dt-bindings/clock/imx7d-clock.h>
> +#include <dt-bindings/power/imx7-power.h>
It has dependency on imx7 power domain driver, and I need to wait for
v4.12-rc1 to apply the patch.
Shawn
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
^ permalink raw reply
* [PATCH v2 2/7] ARM: imx: Select GPCv2 for i.MX7
From: Shawn Guo @ 2017-05-03 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-3-andrew.smirnov@gmail.com>
On Tue, Apr 18, 2017 at 08:01:28AM -0700, Andrey Smirnov wrote:
> GPCv2 IP block is a part of i.MX7 SoC. Select it to make corresponding
> driver availible to support DT changes following this patch.
>
> Cc: yurovsky at gmail.com
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 936c59d..1a4ea3a 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -532,6 +532,7 @@ config SOC_IMX7D
> bool "i.MX7 Dual support"
> select PINCTRL_IMX7D
> select ARM_GIC
> + select IMX_GPCV2
Yes, PINCTRL_IMX7D is already out of order, but still please keep new
added one sorted in alphabetic order.
Shawn
> select HAVE_ARM_ARCH_TIMER
> select HAVE_IMX_ANATOP
> select HAVE_IMX_MMDC
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 1/7] ARM: dts: i.MX: Reintroduce 'anatop-enable-bit' where appropriate
From: Shawn Guo @ 2017-05-03 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-2-andrew.smirnov@gmail.com>
On Tue, Apr 18, 2017 at 08:01:27AM -0700, Andrey Smirnov wrote:
> Now that support for 'anatop-enable-bit' has been added to ANADIG
> driver, reintroduce 'anatop-enable-bit' for all applicable LDOs.
>
> Cc: yurovsky at gmail.com
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Please use 'imx' instead of 'i.MX' in subject prefix to make it more
consistent with other patches in the series.
Shawn
^ permalink raw reply
* [PATCH 0/9] ARM: dts: renesas: update PFC node name to pin-controller
From: Simon Horman @ 2017-05-03 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
On Wed, Apr 26, 2017 at 12:05:29PM +0200, Simon Horman wrote:
>
> The device trees for Renesas SoCs use either pfc or pin-controller as the
> node name for the PFC device. This patch is intended to take a step towards
> unifying the node name used as pin-controller which appears to be the more
> generic of the two and thus more in keeping with the DT specs.
>
> My analysis is that this is a user-visible change to the extent that kernel
> logs, and sysfs entries change from XXX.pfc and pfc at XXX to
> XXX.pin-controller and pin-controller at XXX.
>
> Boot tested on:
> r8a73a4/ape6evm
> r8a7740/armadillo800evb
> r8a7778/bockw
> r8a7790/lager
> r8a7791/koelsch
> r8a7791/porter
> r8a7793/gose
> sh73a9/kzm9g
>
> Not tested on (due to lack of hw access):
> evm2/kzm9d
> r8a7789/marzen
I have now tested this on r8a7789/marzen
^ permalink raw reply
* [PATCH v5 16/22] KVM: arm64: vgic-its: Add infrastructure for table lookup
From: Christoffer Dall @ 2017-05-03 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <303f2981-489e-ec38-ebaf-40d65429d820@redhat.com>
On Wed, May 03, 2017 at 08:53:36AM +0200, Auger Eric wrote:
> Hi Christoffer,
>
> On 30/04/2017 21:35, Christoffer Dall wrote:
> > On Fri, Apr 14, 2017 at 12:15:28PM +0200, Eric Auger wrote:
> >> Add a generic lookup_table() helper whose role consists in
> >> scanning a contiguous table located in guest RAM and applying
> >> a callback on each entry. Entries can be handled as linked lists
> >> since the callback may return an offset to the next entry and
> >> also tell that an entry is the last one.
> >>
> >> Helper functions also are added to compute the device/event ID
> >> offset to the next DTE/ITE.
> >>
> >> compute_next_devid_offset, compute_next_eventid_offset and
> >> lookup_table will become static in subsequent patches
> >>
> >> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> >>
> >> ---
> >> v4 -> v5:
> >> - use kvm_read_guest
> >>
> >> v3 -> v4:
> >> - remove static to avoid compilation warning
> >> - correct size computation in looup_table()
> >> - defines now encode the number of bits used for devid and eventid offsets
> >> - use BIT() - 1 to encode the max offets
> >> ---
> >> virt/kvm/arm/vgic/vgic-its.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 93 insertions(+)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> >> index 56c5123..c22b35d 100644
> >> --- a/virt/kvm/arm/vgic/vgic-its.c
> >> +++ b/virt/kvm/arm/vgic/vgic-its.c
> >> @@ -195,6 +195,8 @@ static struct its_ite *find_ite(struct vgic_its *its, u32 device_id,
> >>
> >> #define VITS_TYPER_IDBITS 16
> >> #define VITS_TYPER_DEVBITS 16
> >> +#define VITS_DTE_MAX_DEVID_OFFSET (BIT(14) - 1)
> >> +#define VITS_ITE_MAX_EVENTID_OFFSET (BIT(16) - 1)
> >>
> >> /*
> >> * Finds and returns a collection in the ITS collection table.
> >> @@ -1674,6 +1676,97 @@ int vgic_its_attr_regs_access(struct kvm_device *dev,
> >> return ret;
> >> }
> >>
> >> +u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
> >> +{
> >> + struct list_head *e = &dev->dev_list;
> >> + struct its_device *next;
> >> + u32 next_offset;
> >> +
> >> + if (e->next == h)
> >> + return 0;
> >> + next = list_entry(e->next, struct its_device, dev_list);
> >> + next_offset = next->device_id - dev->device_id;
> >> +
> >> + return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
> >> +}
> >> +
> >> +u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
> >> +{
> >> + struct list_head *e = &ite->ite_list;
> >> + struct its_ite *next;
> >> + u32 next_offset;
> >> +
> >> + if (e->next == h)
> >> + return 0;
> >> + next = list_entry(e->next, struct its_ite, ite_list);
> >> + next_offset = next->event_id - ite->event_id;
> >> +
> >> + return min_t(u32, next_offset, VITS_ITE_MAX_EVENTID_OFFSET);
> >> +}
> >> +
> >> +/**
> >> + * entry_fn_t - Callback called on a table entry restore path
> >> + * @its: its handle
> >> + * @id: id of the entry
> >> + * @entry: pointer to the entry
> >> + * @opaque: pointer to an opaque data
> >> + * @next_offset: minimal ID offset to the next entry. 0 if this
> >> + * entry is the last one, 1 if the entry is invalid, >= 1 if an
> >
> > eh, also, did you mean -1 if the entry is invalid?
> no in case the entry is invalid, we tell the caller that it must inspect
> the next entry, hence the next_offset = +1.
hmm, but you say aftterwards that >= 1 if an entry's next_offset field
was truly decoded, so this is confusing. Perhaps it would make more
sense to get rid of the parameter entirely and change the return value
to say:
Return: < 0 on error, 0 if the entry was the last one, and > 0 to
indicate the offset to the next entry that must be processed
when scanning a table.
Note that we return 1 for an invalid entry, because scanning a table
in this case simply requires us looking at the next entry, but we may
return >= to 1 if we found a valid entry and decoded the next field in
the entry.
What do you think?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 4/5] arm64: dts: Add ipq8074 SoC and MTP board support
From: Varadarajan Narayanan @ 2017-05-03 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428185349.GD7065@codeaurora.org>
On 4/29/2017 12:23 AM, Stephen Boyd wrote:
> On 04/28, Varadarajan Narayanan wrote:
>> diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
>> new file mode 100644
>> index 0000000..c150bea
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
>> @@ -0,0 +1,48 @@
>> +/dts-v1/;
>> +/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include "ipq8074.dtsi"
>> +
>> +/ {
>> + #address-cells = <0x2>;
>> + #size-cells = <0x2>;
>> + model = "Qualcomm Technologies, Inc. IPQ8074-HK01";
>> + compatible = "qcom,ipq8074-hk01", "qcom,ipq8074";
>> + interrupt-parent = <&intc>;
>> +
>> + chosen {
>> + bootargs = "console=ttyMSM0,115200,n8 root=/dev/ram0 rw init=/init";
>
> Add an aliases node for serial0 and use a chosen node with stdout-path = "serial0" instead please.
Ok
>
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x0 0x40000000 0x0 0x20000000>;
>> + };
>> +
>> + soc: soc {
>
> Do you need the soc label here? Please remove.
Ok
>
>> + pinctrl at 1000000 {
>> + serial_4_pins: serial4_pinmux {
>> + mux {
>> + pins = "gpio23", "gpio24";
>> + function = "blsp4_uart1";
>> + bias-disable;
>> + };
>> + };
>> + };
>> +
>> + serial at 78b3000 {
>> + pinctrl-0 = <&serial_4_pins>;
>> + pinctrl-names = "default";
>> + status = "ok";
>> + };
>> + };
>> +};
>> diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
>> new file mode 100644
>> index 0000000..f910cc0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
>> @@ -0,0 +1,153 @@
>> +/*
>> + * Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/qcom,gcc-ipq8074.h>
>> +
>> +/ {
>> + model = "Qualcomm Technologies, Inc. IPQ8074";
>> + compatible = "qcom,ipq8074";
>> +
>> + soc: soc {
>> + #address-cells = <0x1>;
>> + #size-cells = <0x1>;
>> + ranges = <0 0 0 0xffffffff>;
>> + compatible = "simple-bus";
>> +
>> + pinctrl at 1000000 {
>> + compatible = "qcom,ipq8074-pinctrl";
>> + reg = <0x1000000 0x300000>;
>> + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
>> + gpio-controller;
>> + #gpio-cells = <0x2>;
>> + interrupt-controller;
>> + #interrupt-cells = <0x2>;
>> + };
>> +
>> + intc: interrupt-controller at b000000 {
>> + compatible = "qcom,msm-qgic2";
>> + interrupt-controller;
>> + #interrupt-cells = <0x3>;
>> + reg = <0xb000000 0x1000>,
>> + <0xb002000 0x1000>;
>
> Please align this up with previous reg property.
Ok
>
>> + };
>> +
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
>> + <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
>> + <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
>> + <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
>> + };
>
> Is there an mmio timer as well? We should add it too.
Ok
>
>> +
>> + gcc: gcc at 1800000 {
>> + compatible = "qcom,gcc-ipq8074";
>> + reg = <0x1800000 0x80000>;
>
> Wow that is a huge area! Is it really that large?
Yes, per the memory map this region is 512K.
>
>> + #clock-cells = <0x1>;
>> + #reset-cells = <0x1>;
>> + };
>> +
>> + serial at 78b3000 {
>> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
>> + reg = <0x78b3000 0x200>;
>> + interrupts = <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&gcc GCC_BLSP1_UART5_APPS_CLK>,
>> + <&gcc GCC_BLSP1_AHB_CLK>;
>> + clock-names = "core", "iface";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + cpus {
>> + #address-cells = <0x1>;
>> + #size-cells = <0x0>;
>> +
>> + cpu-map {
>> +
>> + cluster0 {
>> +
>> + core0 {
>> + cpu = <&CPU0>;
>> + };
>> +
>> + core1 {
>> + cpu = <&CPU1>;
>> + };
>> +
>> + core2 {
>> + cpu = <&CPU2>;
>> + };
>> +
>> + core3 {
>> + cpu = <&CPU3>;
>> + };
>> + };
>> + };
>
> Is this needed? Looks ok, but just curious if we need to do it
> for other arm64 platforms we support.
Don't see the need for topology at this time, will add it later if needed.
>
>> +
>> + CPU0: cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + reg = <0x0>;
>> + next-level-cache = <&L2_0>;
>> + enable-method = "psci";
>> + };
>> +
>> + CPU1: cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + enable-method = "psci";
>> + reg = <0x1>;
>> + next-level-cache = <&L2_0>;
>> + };
>> +
>> + CPU2: cpu at 2 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + enable-method = "psci";
>> + reg = <0x2>;
>> + next-level-cache = <&L2_0>;
>> + };
>> +
>> + CPU3: cpu at 3 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + enable-method = "psci";
>> + reg = <0x3>;
>> + next-level-cache = <&L2_0>;
>> + };
>> +
>> + L2_0: l2-cache {
>> + compatible = "cache";
>> + cache-level = <0x2>;
>> + };
>
> This should be inside some CPU? CPU0?
There is only one L2. We followed the same convention as in msm8916.dtsi.
>
>> + };
>
> We should be able to add the performance monitor node too?
>
Ok
>> +
>> + psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> + };
>> +
>> + clocks {
>> + sleep_clk: sleep_clk {
>> + compatible = "fixed-clock";
>> + clock-frequency = <32000>;
>
> Not 32765 or 32768?
It is 32000.
>
>> + #clock-cells = <0>;
>> + };
>> +
>> + xo: xo {
>> + compatible = "fixed-clock";
>> + clock-frequency = <19200000>;
>> + #clock-cells = <0>;
>> + };
>> + };
>
-Varada
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 0/9] net: thunderx: Adds XDP support
From: Sunil Kovvuri @ 2017-05-03 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502.154744.1762061314370744901.davem@davemloft.net>
On Wed, May 3, 2017 at 1:17 AM, David Miller <davem@davemloft.net> wrote:
> From: sunil.kovvuri at gmail.com
> Date: Tue, 2 May 2017 18:36:49 +0530
>
>> From: Sunil Goutham <sgoutham@cavium.com>
>>
>> This patch series adds support for XDP to ThunderX NIC driver
>> which is used on CN88xx, CN81xx and CN83xx platforms.
>>
>> Patches 1-4 are performance improvement and cleanup patches
>> which are done keeping XDP performance bottlenecks in view.
>> Rest of the patches adds actual XDP support.
>
> Series applied, thanks for doing this work.
Thanks.
>
> Do you have any performance numbers?
Below are the forwarding numbers on a single core.
with network stack: 0.32 Mpps
with XDP (XDP_TX): 3 Mpps
and XDP_DROP: 3.8 Mpps
Thanks,
Sunil.
^ permalink raw reply
* [PATCH v2 resend] arm: dts: sun7i-a20-bananapi: name the GPIO lines
From: Oleksij Rempel @ 2017-05-03 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZcnJ1eCNW4ZF_A4zbeCt3JcAuw-1meB_Pn7ctMy99B_g@mail.gmail.com>
This names the GPIO lines on the Banana Pi board in accordance with
the A20_Banana_Pi v1.4 Specification.
This will make these line names reflect through to userspace
so that they can easily be identified and used with the new
character device ABI.
Some care has been taken to name all lines, not just those used
by the external connectors, also lines that are muxed into some
other function than GPIO: these are named "[FOO]" so that users
can see with lsgpio what all lines are used for.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 60 ++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 91f2e5f..5b3e0ee 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -178,6 +178,66 @@
};
&pio {
+ /*
+ * Legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (not routed from the SoC)
+ * "[PER]" = pin is muxed for peripheral (not GPIO)
+ * "" = no idea, schematic doesn't say, could be
+ * unrouted (not connected to any external pin)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ */
+ gpio-line-names =
+ /* PA */
+ "[ERXD3]", "[ERXD2]", "[ERXD1]", "[ERXD0]", "[ETXD3]",
+ "[ETXD2]", "[ETXD1]", "[ETXD0]",
+ "[ERXCK]", "[ERXERR]", "[ERXDV]", "[EMDC]", "[EMDIO]",
+ "[ETXEN]", "[ETXCK]", "[ECRS]",
+ "[ECOL]", "[ETXERR]", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PB */
+ "[PMU-SCK]", "[PMU-SDA]", "", "", "", "NC", "NC", "NC",
+ "NC", "[USB0-DRV]", "NC", "NC", "NC", "NC", "", "",
+ "", "", "", "", "SCL", "SDA", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PC */
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PD */
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PE */
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PF */
+ "[SD0-D1]", "[SD0-D0]", "[SD0-CLK]", "[SD0-CMD]", "[SD0-D3]",
+ "[SD0-D2]", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PG */
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ /* PH */
+ "TXD0", "RXD0", "IO-1", "PH3", "[USB0-IDDET]", "PH5", "", "",
+ "", "", "[SD0-DET]", "", "", "", "", "",
+ "NC", "", "", "", "IO-4", "IO-5", "NC", "[EMAC-PWR-EN]",
+ "[LED1]", "NC", "NC", "NC", "", "", "", "",
+ /* PI */
+ "", "", "", "IO-GCLK", "NC", "NC", "NC", "NC",
+ "NC", "NC", "[SPI-CE0]", "[SPI-CLK]", "[SPI-MOSI]",
+ "[SPI-MISO]", "[SPI-CE1]", "NC",
+ "IO-6", "IO-3", "IO-2", "IO-0", "", "", "", "",
+ "", "", "", "", "", "", "", "";
+
usb0_id_detect_pin: usb0_id_detect_pin at 0 {
pins = "PH4";
function = "gpio_in";
--
2.7.4
^ permalink raw reply related
* [PATCH v5 16/22] KVM: arm64: vgic-its: Add infrastructure for table lookup
From: Auger Eric @ 2017-05-03 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170430193555.GB1670@lvm>
Hi Christoffer,
On 30/04/2017 21:35, Christoffer Dall wrote:
> On Fri, Apr 14, 2017 at 12:15:28PM +0200, Eric Auger wrote:
>> Add a generic lookup_table() helper whose role consists in
>> scanning a contiguous table located in guest RAM and applying
>> a callback on each entry. Entries can be handled as linked lists
>> since the callback may return an offset to the next entry and
>> also tell that an entry is the last one.
>>
>> Helper functions also are added to compute the device/event ID
>> offset to the next DTE/ITE.
>>
>> compute_next_devid_offset, compute_next_eventid_offset and
>> lookup_table will become static in subsequent patches
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v4 -> v5:
>> - use kvm_read_guest
>>
>> v3 -> v4:
>> - remove static to avoid compilation warning
>> - correct size computation in looup_table()
>> - defines now encode the number of bits used for devid and eventid offsets
>> - use BIT() - 1 to encode the max offets
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 93 insertions(+)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index 56c5123..c22b35d 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -195,6 +195,8 @@ static struct its_ite *find_ite(struct vgic_its *its, u32 device_id,
>>
>> #define VITS_TYPER_IDBITS 16
>> #define VITS_TYPER_DEVBITS 16
>> +#define VITS_DTE_MAX_DEVID_OFFSET (BIT(14) - 1)
>> +#define VITS_ITE_MAX_EVENTID_OFFSET (BIT(16) - 1)
>>
>> /*
>> * Finds and returns a collection in the ITS collection table.
>> @@ -1674,6 +1676,97 @@ int vgic_its_attr_regs_access(struct kvm_device *dev,
>> return ret;
>> }
>>
>> +u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
>> +{
>> + struct list_head *e = &dev->dev_list;
>> + struct its_device *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_device, dev_list);
>> + next_offset = next->device_id - dev->device_id;
>> +
>> + return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
>> +}
>> +
>> +u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
>> +{
>> + struct list_head *e = &ite->ite_list;
>> + struct its_ite *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_ite, ite_list);
>> + next_offset = next->event_id - ite->event_id;
>> +
>> + return min_t(u32, next_offset, VITS_ITE_MAX_EVENTID_OFFSET);
>> +}
>> +
>> +/**
>> + * entry_fn_t - Callback called on a table entry restore path
>> + * @its: its handle
>> + * @id: id of the entry
>> + * @entry: pointer to the entry
>> + * @opaque: pointer to an opaque data
>> + * @next_offset: minimal ID offset to the next entry. 0 if this
>> + * entry is the last one, 1 if the entry is invalid, >= 1 if an
>
> eh, also, did you mean -1 if the entry is invalid?
no in case the entry is invalid, we tell the caller that it must inspect
the next entry, hence the next_offset = +1.
Thanks
Eric
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH v6 0/4] Broadcom SBA RAID support
From: Anup Patel @ 2017-05-03 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503045926.GV6263@localhost>
On Wed, May 3, 2017 at 10:29 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
>> Hi Vinod,
>>
>> The Broadcom FlexRM patchset have been
>> merged in v4.11.
>>
>> I think you now can take this patchset in next
>> merge window. Right??
>
> Sure, please rebase and resend after -rc1 is out
Sure, I will do that.
Regards,
Anup
^ permalink raw reply
* [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges
From: Oza Oza @ 2017-05-03 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493786795-28153-3-git-send-email-oza.oza@broadcom.com>
I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.
Regards,
Oza
^ permalink raw reply
* [PATCH 2/3] iommu/pci: reserve iova for PCI masters
From: Oza Oza @ 2017-05-03 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493786795-28153-2-git-send-email-oza.oza@broadcom.com>
I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.
Regards,
Oza
^ permalink raw reply
* [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
From: Oza Oza @ 2017-05-03 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493786795-28153-1-git-send-email-oza.oza@broadcom.com>
I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.
Regards,
Oza
^ 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