* [PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Sergei Shtylyov @ 2018-05-28 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9c94553-be9d-0eec-a1ee-1713bb97fbab@cogentembedded.com>
Define the Condor board dependent part of the I2C0 device node.
The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
and Analog Devices ADV7511W HDMI transmitter (but we're only describing
the former chips now).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -80,6 +80,28 @@
clock-frequency = <32768>;
};
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ io_expander0: gpio at 20 {
+ compatible = "onnn,pca9654";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ io_expander1: gpio at 21 {
+ compatible = "onnn,pca9654";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
&mmc0 {
pinctrl-0 = <&mmc_pins>;
pinctrl-1 = <&mmc_pins_uhs>;
@@ -104,6 +126,11 @@
function = "canfd0";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
mmc_pins: mmc {
groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
function = "mmc";
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-28 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9c94553-be9d-0eec-a1ee-1713bb97fbab@cogentembedded.com>
Define the generic R8A77980 parts of the I2C[0-5] device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 111 ++++++++++++++++++++++++++++++
1 file changed, 111 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,108 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c at e6500000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at e6508000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 930>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at e6510000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 929>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at e66d0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 928>;
+ dmas = <&dmac1 0x97>, <&dmac1 0x96>,
+ <&dmac2 0x97>, <&dmac2 0x96>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at e66d8000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 927>;
+ dmas = <&dmac1 0x99>, <&dmac1 0x98>,
+ <&dmac2 0x99>, <&dmac2 0x98>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at e66e0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ dmas = <&dmac1 0x9b>, <&dmac1 0x9a>,
+ <&dmac2 0x9b>, <&dmac2 0x9a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
hscif0: serial at e6540000 {
compatible = "renesas,hscif-r8a77980",
"renesas,rcar-gen3-hscif",
^ permalink raw reply
* [PATCH v3 0/2] Add R8A77980/Condor I2C support
From: Sergei Shtylyov @ 2018-05-28 20:10 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180528-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
the Condor board.
[1/2] arm64: dts: renesas: r8a77980: add I2C support
[2/2] arm64: dts: renesas: condor: add I2C0 support
WBR, Sergei
^ permalink raw reply
* [GIT PULL] pxa-dt for v4.18
From: Robert Jarzmik @ 2018-05-28 20:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof,
This is the pxa pull request for 4.18 device-tree, with a couple fixes from
Daniel for pxa3xx.
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://github.com/rjarzmik/linux.git tags/pxa-dt-4.18
for you to fetch changes up to 07c8d21d08a589bc01238fe09a6edb54d24f3da0:
ARM: dts: pxa3xx: fix MMC clocks (2018-05-25 23:16:18 +0200)
----------------------------------------------------------------
This device-tree pxa update brings :
- fix pxa3xx MMC bindings
- add pxa3xx GPIOs
- add pxa3xx missing pin controller
----------------------------------------------------------------
Daniel Mack (3):
ARM: pxa: dts: add gpio-ranges to gpio controller
ARM: pxa: dts: add pin definitions for extended GPIOs
ARM: dts: pxa3xx: fix MMC clocks
arch/arm/boot/dts/pxa3xx.dtsi | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--
Robert
^ permalink raw reply
* [RFT v3 0/4] Perf script: Add python script for CoreSight trace disassembler
From: Arnaldo Carvalho de Melo @ 2018-05-28 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527497103-3593-1-git-send-email-leo.yan@linaro.org>
Em Mon, May 28, 2018 at 04:44:59PM +0800, Leo Yan escreveu:
> This patch series is to support for using 'perf script' for CoreSight
> trace disassembler, for this purpose this patch series adds a new
> python script to parse CoreSight tracing event and use command 'objdump'
> for disassembled lines, finally this can generate readable program
> execution flow for reviewing tracing data.
>
> Patch 0001 is one fixing patch to generate samples for the start packet
> and exception packets.
>
> Patch 0002 is the prerequisite to add addr into sample dict, so this
> value can be used by python script to analyze instruction range.
>
> Patch 0003 is to add python script for trace disassembler.
>
> Patch 0004 is to add doc to explain python script usage and give
> example for it.
>
> This patch series has been rebased on acme git tree [1] with the commit
> 19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and tested
> on Hikey (ARM64 octa CA53 cores).
Thanks, applied to perf/core.
- Arnaldo
^ permalink raw reply
* [GIT PULL] pxa for v4.18
From: Robert Jarzmik @ 2018-05-28 20:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof,
This is the pxa pull request for 4.18, a minor one.
Can you please consider pulling ?
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://github.com/rjarzmik/linux.git tags/pxa-for-4.18
for you to fetch changes up to c1c14f8954c6d1cb9867024618e93687d9d035ba:
ARM: pxa3xx: enable external wakeup pins (2018-05-25 22:40:17 +0200)
----------------------------------------------------------------
This is is the pxa changes for v4.18 cycle :
- change to phase out at24 eeprom platform data
- add a missing wakeup pin on pxa320 SoCs
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: pxa: stargate2: use device properties for at24 eeprom
Daniel Mack (1):
ARM: pxa3xx: enable external wakeup pins
arch/arm/mach-pxa/pxa3xx.c | 4 ++++
arch/arm/mach-pxa/stargate2.c | 10 +++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
--
Robert
^ permalink raw reply
* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Arnaldo Carvalho de Melo @ 2018-05-28 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALZQ+UMbndvogrSb0Ey3ac1vDGqtsiRTR=ee8VGzU2Ni9_s0og@mail.gmail.com>
Em Mon, May 28, 2018 at 11:13:59AM +0800, Leo Yan escreveu:
> On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
> > The tail of a queue is supposed to be pointing to the next available slot
> > in a queue. In this implementation the tail is incremented before it is
> > used and as such points to the last used element, something that has the
> > immense advantage of centralizing tail management at a single location
> > and eliminating a lot of redundant code.
> >
> > But this needs to be taken into consideration on the dequeueing side where
> > the head also needs to be incremented before it is used, or the first
> > available element of the queue will be skipped.
> >
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > ---
> > tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > index c8b98fa22997..4d5fc374e730 100644
> > --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
> > /* Nothing to do, might as well just return */
> > if (decoder->packet_count == 0)
> > return 0;
> > + /*
> > + * The queueing process in function cs_etm_decoder__buffer_packet()
> > + * increments the tail *before* using it. This is somewhat counter
> > + * intuitive but it has the advantage of centralizing tail management
> > + * at a single location. Because of that we need to follow the same
> > + * heuristic with the head, i.e we increment it before using its
> > + * value. Otherwise the first element of the packet queue is not
> > + * used.
> > + */
> > + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> >
> > *packet = decoder->packet_buffer[decoder->head];
> >
> > - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> > -
>
> I tested this patch and confirmed it can work well with python
> decoding script:
>
> Tested-by: Leo Yan <leo.yan@linaro.org>
Ok, applying this patch, after having read Mathieu's response.
- Arnaldo
> Actually, I have another idea for this fixing, seems to me
> the unchanged code has right logic for decoder->head, and I think this
> issue is more related with incorrect initialization index. So we can
> change the initialization index for decoder->head as below. How about
> you think for this?
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa..b133260 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
> cs_etm_decoder *decoder)
> {
> int i;
>
> - decoder->head = 0;
> + decoder->head = 1;
> decoder->tail = 0;
> decoder->packet_count = 0;
> for (i = 0; i < MAX_BUFFER; i++) {
>
> Thanks,
> Leo Yan
>
> > decoder->packet_count--;
> >
> > return 1;
> > --
> > 2.7.4
> >
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: add ethernet0 alias
From: Scott Branden @ 2018-05-28 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJiuCcd6Y+H0XJn+7dObiTuhSPXhefrYNh9qDi+=cs8S6-TGgw@mail.gmail.com>
On 18-05-28 01:22 AM, Cl?ment P?ron wrote:
> Could you review it, please.
> Thanks
>
> On Thu, 3 May 2018 at 17:13, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> +Ray, Scott, Eric, list
>> On 05/03/2018 02:56 AM, Cl?ment P?ron wrote:
>>> In order to avoid Linux generating a random mac address on every boot,
>>> add an ethernet0 alias that will allow u-boot to patch the dtb with
>>> the MAC address.
>>>
>>> Signed-off-by: Cl?ment P?ron <peron.clem@gmail.com>
Acked-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> index 9fe4f5a6379e..1a05b8f48b54 100644
>>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> @@ -41,6 +41,10 @@
>>> model = "Broadcom Cygnus SoC";
>>> interrupt-parent = <&gic>;
>>>
>>> + aliases {
>>> + ethernet0 = ð0;
>>> + };
>>> +
>>> cpus {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>> --
>> Florian
> Clement
^ permalink raw reply
* [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Krzysztof Kozlowski @ 2018-05-28 19:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Marek Szyprowski <m.szyprowski@samsung.com>
Samsung Exynos SoCs and boards related bindings evolved since the initial
introduction, but initially the bindings were minimal and a bit incomplete
(they never described all the hardware modules available in the SoCs).
Since then some significant (not fully compatible) changes have been
already committed a few times (like gpio replaced by pinctrl, display ddc,
mfc reserved memory, some core clocks added to various hardware modules,
added more required nodes).
On the other side there are no boards which have device tree embedded in
the bootloader. Device tree blob is always compiled from the kernel tree
and updated together with the kernel image.
Thus to avoid further adding a bunch of workarounds for old/missing
bindings, make development of new platforms easier and allow to make
cleanup of the existing code and device tree files, lets mark some
Samsung Exynos SoC platform bindings as unstable. This means that
bindings can may change at any time and users should use the dtb file
compiled from the same kernel source tree as the kernel image.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v1:
1. Rebase
2. Add specific compatibles to mark unstable.
v1 is here:
https://patchwork.kernel.org/patch/9477963/
Previous tags (not applying due to change in contents):
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
.../devicetree/bindings/arm/samsung/exynos.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos.txt b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
new file mode 100644
index 000000000000..7410cb79e4b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
@@ -0,0 +1,26 @@
+Samsung Exynos SoC Family Device Tree Bindings
+---------------------------------------------------------------
+
+Work in progress statement:
+
+Following Device Tree files and bindings applying to Samsung Exynos SoCs and
+boards are considered "unstable":
+
+ - samsung,exynos5433* (all compatibles related to Exynos5433)
+ - samsung,exynos7* (all compatibles related to Exynos7)
+ - samsung,tm2-audio
+ - samsung,mfc-v10
+ - samsung,exynos*-mipi-dsi
+ - samsung,exynos5-dp
+ - samsung,exynos*-hdmi
+ - samsung,exynos*-hdmiddc
+ - samsung,exynos*-hdmiphy
+ - samsung,exynos*-mixer
+ - samsung,exynos*-fimd
+
+Any Samsung Exynos device tree binding mentioned may change at any time. Be
+sure to use a device tree binary and a kernel image generated from the same
+source tree.
+
+Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
+stable binding/ABI.
--
2.14.1
^ permalink raw reply related
* [PATCH] dt-bindings: arm: Remove obsolete insignal-boards.txt
From: Krzysztof Kozlowski @ 2018-05-28 18:53 UTC (permalink / raw)
To: linux-arm-kernel
The compatibles mentioned in insignal-boards.txt are already documented
under devicetree/bindings/arm/samsung/samsung-boards.txt. Also the
contents of insignal-boards.txt is not accurate, e.g. does not mention
Arndale boards.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Documentation/devicetree/bindings/arm/insignal-boards.txt | 8 --------
1 file changed, 8 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt
diff --git a/Documentation/devicetree/bindings/arm/insignal-boards.txt b/Documentation/devicetree/bindings/arm/insignal-boards.txt
deleted file mode 100644
index 524c3dc5d808..000000000000
--- a/Documentation/devicetree/bindings/arm/insignal-boards.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-* Insignal's Exynos4210 based Origen evaluation board
-
-Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
-
-Required root node properties:
- - compatible = should be one or more of the following.
- (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
- (b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
--
2.14.1
^ permalink raw reply related
* [PATCH v4 6/6] arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
Enable the SP805 watchdog timer
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..3fe5eb5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -351,6 +351,7 @@ CONFIG_ROCKCHIP_THERMAL=m
CONFIG_TEGRA_BPMP_THERMAL=m
CONFIG_UNIPHIER_THERMAL=y
CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MESON_GXBB_WATCHDOG=m
CONFIG_MESON_WATCHDOG=m
--
2.1.4
^ permalink raw reply related
* [PATCH v4 5/6] arm64: dt: set initial SR watchdog timeout to 60 seconds
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
Set initial Stingray watchdog timeout to 60 seconds
By the time when the userspace watchdog daemon is ready and taking
control over, the watchdog timeout will then be reset to what's
configured in the daemon
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..1e1cf49 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -420,6 +420,7 @@
interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&hsls_25m_div2_clk>, <&hsls_div4_clk>;
clock-names = "wdogclk", "apb_pclk";
+ timeout-sec = <60>;
};
gpio_hsls: gpio at d0000 {
--
2.1.4
^ permalink raw reply related
* [PATCH v4 4/6] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should reset the watchdog and
tell the watchdog framework. As a result, ping can be generated from
the watchdog framework, until the userspace watchdog daemon takes over
control
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/watchdog/sp805_wdt.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 1484609..d662a6f 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -42,6 +42,7 @@
/* control register masks */
#define INT_ENABLE (1 << 0)
#define RESET_ENABLE (1 << 1)
+ #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
#define WDTINTCLR 0x00C
#define WDTRIS 0x010
#define WDTMIS 0x014
@@ -74,6 +75,15 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout,
"Set to 1 to keep watchdog running after device release");
+/* returns true if wdt is running; otherwise returns false */
+static bool wdt_is_running(struct watchdog_device *wdd)
+{
+ struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
+ u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
+
+ return (wdtcontrol & ENABLE_MASK) == ENABLE_MASK;
+}
+
/* This routine finds load value that will reset system in required timout */
static int wdt_setload(struct watchdog_device *wdd, unsigned int timeout)
{
@@ -239,6 +249,15 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
wdt_setload(&wdt->wdd, wdt->wdd.timeout);
+ /*
+ * If HW is already running, enable/reset the wdt and set the running
+ * bit to tell the wdt subsystem
+ */
+ if (wdt_is_running(&wdt->wdd)) {
+ wdt_enable(&wdt->wdd);
+ set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
+ }
+
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
dev_err(&adev->dev, "watchdog_register_device() failed: %d\n",
--
2.1.4
^ permalink raw reply related
* [PATCH v4 3/6] watchdog: sp805: add 'timeout-sec' DT property support
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
Add support for optional devicetree property 'timeout-sec'.
'timeout-sec' is used in the driver if specified in devicetree.
Otherwise, fall back to driver default, i.e., 60 seconds
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/watchdog/sp805_wdt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 03805bc..1484609 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -230,7 +230,14 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
spin_lock_init(&wdt->lock);
watchdog_set_nowayout(&wdt->wdd, nowayout);
watchdog_set_drvdata(&wdt->wdd, wdt);
- wdt_setload(&wdt->wdd, DEFAULT_TIMEOUT);
+
+ /*
+ * If 'timeout-sec' devicetree property is specified, use that.
+ * Otherwise, use DEFAULT_TIMEOUT
+ */
+ wdt->wdd.timeout = DEFAULT_TIMEOUT;
+ watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
+ wdt_setload(&wdt->wdd, wdt->wdd.timeout);
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/6] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
Update the SP805 binding document to add optional 'timeout-sec'
devicetree property
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
Documentation/devicetree/bindings/watchdog/arm,sp805.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
index 0fa3629..bee6f1f 100644
--- a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
+++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
@@ -19,6 +19,8 @@ Required properties:
Optional properties:
- interrupts: Should specify WDT interrupt number
+- timeout-sec: Should specify default WDT timeout in seconds. If unset, the
+ default timeout is determined by the driver
Example:
watchdog at 66090000 {
--
2.1.4
^ permalink raw reply related
* [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
Consolidate two SP805 binding documents "arm,sp805.txt" and
"sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
desired compatible string to be used
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
.../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
2 files changed, 20 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
index ca99d64..0fa3629 100644
--- a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
+++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
@@ -1,17 +1,30 @@
ARM AMBA Primecell SP805 Watchdog
+SP805 WDT is a ARM Primecell Peripheral and has a standard-id register that
+can be used to identify the peripheral type, vendor, and revision.
+This value can be used for driver matching.
+
+As SP805 WDT is a primecell IP, it follows the base bindings specified in
+'arm/primecell.txt'
+
Required properties:
-- compatible: Should be "arm,sp805" & "arm,primecell"
-- reg: Should contain location and length for watchdog timer register.
-- interrupts: Should contain the list of watchdog timer interrupts.
-- clocks: clocks driving the watchdog timer hardware. This list should be 2
- clocks. With 2 clocks, the order is wdogclk clock, apb_pclk.
+- compatible: Should be "arm,sp805" & "arm,primecell"
+- reg: Should contain location and length for watchdog timer register
+- clocks: Clocks driving the watchdog timer hardware. This list should be
+ 2 clocks. With 2 clocks, the order is wdog_clk, apb_pclk
+ wdog_clk can be equal to or be a sub-multiple of the apb_pclk
+ frequency
+- clock-names: Shall be "wdog_clk" for first clock and "apb_pclk" for the
+ second one
+
+Optional properties:
+- interrupts: Should specify WDT interrupt number
Example:
watchdog at 66090000 {
compatible = "arm,sp805", "arm,primecell";
reg = <0x66090000 0x1000>;
interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&apb_pclk>,<&apb_pclk>;
- clock-names = "wdogclk", "apb_pclk";
+ clocks = <&wdt_clk>, <&apb_pclk>;
+ clock-names = "wdog_clk", "apb_pclk";
};
diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
deleted file mode 100644
index edc4f0e..0000000
--- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* ARM SP805 Watchdog Timer (WDT) Controller
-
-SP805 WDT is a ARM Primecell Peripheral and has a standard-id register that
-can be used to identify the peripheral type, vendor, and revision.
-This value can be used for driver matching.
-
-As SP805 WDT is a primecell IP, it follows the base bindings specified in
-'arm/primecell.txt'
-
-Required properties:
-- compatible : Should be "arm,sp805-wdt", "arm,primecell"
-- reg : Base address and size of the watchdog timer registers.
-- clocks : From common clock binding.
- First clock is PCLK and the second is WDOGCLK.
- WDOGCLK can be equal to or be a sub-multiple of the PCLK frequency.
-- clock-names : From common clock binding.
- Shall be "apb_pclk" for first clock and "wdog_clk" for the
- second one.
-
-Optional properties:
-- interrupts : Should specify WDT interrupt number.
-
-Examples:
-
- cluster1_core0_watchdog: wdt at c000000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
- reg = <0x0 0xc000000 0x0 0x1000>;
- clocks = <&clockgen 4 3>, <&clockgen 4 3>;
- clock-names = "apb_pclk", "wdog_clk";
- };
-
--
2.1.4
^ permalink raw reply related
* [PATCH v4 0/6] Enhance support for the SP805 WDT
From: Ray Jui @ 2018-05-28 18:01 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enhances the support for the SP805 watchdog timer.
First of all, 'timeout-sec' devicetree property is added. In addition,
support is also added to allow the driver to reset the watchdog if it
has been detected that watchdot has been started in the bootloader. In
this case, the driver will initiate the ping service from the kernel
watchdog subsystem, before a user mode daemon takes over. This series
also enables SP805 in the default ARM64 defconfig
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sp805-wdt-v4
Changes since v3:
- Improve description of 'timeout-sec' in the binding document, per
recommendation from Guenter Roeck
Changes since v2:
- Fix indent and format to make them consistent within arm,sp805.txt
Changes since v1:
- Consolidate two duplicated SP805 binding documents into one
- Slight change of the wdt_is_running implementation per discussion
Ray Jui (6):
Documentation: DT: Consolidate SP805 binding docs
Documentation: DT: Add optional 'timeout-sec' property for sp805
watchdog: sp805: add 'timeout-sec' DT property support
watchdog: sp805: set WDOG_HW_RUNNING when appropriate
arm64: dt: set initial SR watchdog timeout to 60 seconds
arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
.../devicetree/bindings/watchdog/arm,sp805.txt | 29 +++++++++++++++-----
.../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
arch/arm64/configs/defconfig | 1 +
drivers/watchdog/sp805_wdt.c | 28 ++++++++++++++++++-
5 files changed, 51 insertions(+), 39 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
--
2.1.4
^ permalink raw reply
* [PATCH 9/9] clk: davinci: Fix link errors when not all SoCs are enabled
From: David Lechner @ 2018-05-28 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1b62396-534c-bc68-63a4-ac493690a3e7@ti.com>
On 05/28/2018 08:43 AM, Sekhar Nori wrote:
> On Friday 25 May 2018 11:41 PM, David Lechner wrote:
>> This fixes linker errors due to undefined symbols when one or more of
>> the TI DaVinci SoCs is not enabled in the kernel config.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> drivers/clk/davinci/pll.c | 16 ++++++++++++++++
>> drivers/clk/davinci/pll.h | 11 ++++++++---
>> drivers/clk/davinci/psc.c | 14 ++++++++++++++
>> drivers/clk/davinci/psc.h | 12 ++++++++++++
>> include/linux/clk/davinci.h | 19 +++++++++++++++----
>> 5 files changed, 65 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
>> index 84a343060bc8..65abd371692d 100644
>> --- a/drivers/clk/davinci/pll.c
>> +++ b/drivers/clk/davinci/pll.c
>> @@ -860,25 +860,41 @@ static struct davinci_pll_platform_data *davinci_pll_get_pdata(struct device *de
>> }
>>
>> /* needed in early boot for clocksource/clockevent */
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> CLK_OF_DECLARE(da850_pll0, "ti,da850-pll0", of_da850_pll0_init);
>> +#endif
>>
>> static const struct of_device_id davinci_pll_of_match[] = {
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> { .compatible = "ti,da850-pll1", .data = of_da850_pll1_init },
>> +#endif
>> { }
>> };
>>
>> static const struct platform_device_id davinci_pll_id_table[] = {
>> +#ifdef CONFIG_ARCH_DAVINCI_DA830
>> { .name = "da830-pll", .driver_data = (kernel_ulong_t)da830_pll_init },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> { .name = "da850-pll0", .driver_data = (kernel_ulong_t)da850_pll0_init },
>> { .name = "da850-pll1", .driver_data = (kernel_ulong_t)da850_pll1_init },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM355
>> { .name = "dm355-pll1", .driver_data = (kernel_ulong_t)dm355_pll1_init },
>> { .name = "dm355-pll2", .driver_data = (kernel_ulong_t)dm355_pll2_init },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM365
>> { .name = "dm365-pll1", .driver_data = (kernel_ulong_t)dm365_pll1_init },
>> { .name = "dm365-pll2", .driver_data = (kernel_ulong_t)dm365_pll2_init },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM644x
>> { .name = "dm644x-pll1", .driver_data = (kernel_ulong_t)dm644x_pll1_init },
>> { .name = "dm644x-pll2", .driver_data = (kernel_ulong_t)dm644x_pll2_init },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM646x
>> { .name = "dm646x-pll1", .driver_data = (kernel_ulong_t)dm646x_pll1_init },
>> { .name = "dm646x-pll2", .driver_data = (kernel_ulong_t)dm646x_pll2_init },
>> +#endif
>> { }
>> };
>>
>> diff --git a/drivers/clk/davinci/pll.h b/drivers/clk/davinci/pll.h
>> index b2e5c4496645..7cc354dd29e2 100644
>> --- a/drivers/clk/davinci/pll.h
>> +++ b/drivers/clk/davinci/pll.h
>> @@ -122,14 +122,19 @@ int of_davinci_pll_init(struct device *dev, struct device_node *node,
>>
>> /* Platform-specific callbacks */
>>
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> int da850_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip);
>> void of_da850_pll0_init(struct device_node *node);
>> int of_da850_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip);
>> -
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM355
>> int dm355_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip);
>> -
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM644x
>> int dm644x_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip);
>> -
>> +#endif
>
> The traditional way of dealing with this for functions is to provide a
> static inline stub when CONFIG_ARCH_DAVINCI_DM644x is not defined. Can
> we use that? That helps in avoiding ifdefs elsewhere.
I suppose we could. But then we would be taking function pointers to
static inline functions, which seems kind of weird to me.
>
>> +#ifdef CONFIG_ARCH_DAVINCI_DM646x
>> int dm646x_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip);
>> +#endif
>>
>> #endif /* __CLK_DAVINCI_PLL_H___ */
>> diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c
>> index 6326ba1fe3cc..fffbed5e263b 100644
>> --- a/drivers/clk/davinci/psc.c
>> +++ b/drivers/clk/davinci/psc.c
>> @@ -513,20 +513,34 @@ int of_davinci_psc_clk_init(struct device *dev,
>> }
>>
>> static const struct of_device_id davinci_psc_of_match[] = {
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> { .compatible = "ti,da850-psc0", .data = &of_da850_psc0_init_data },
>> { .compatible = "ti,da850-psc1", .data = &of_da850_psc1_init_data },
>> +#endif
>> { }
>> };
>>
>> static const struct platform_device_id davinci_psc_id_table[] = {
>> +#ifdef CONFIG_ARCH_DAVINCI_DA830
>> { .name = "da830-psc0", .driver_data = (kernel_ulong_t)&da830_psc0_init_data },
>> { .name = "da830-psc1", .driver_data = (kernel_ulong_t)&da830_psc1_init_data },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> { .name = "da850-psc0", .driver_data = (kernel_ulong_t)&da850_psc0_init_data },
>> { .name = "da850-psc1", .driver_data = (kernel_ulong_t)&da850_psc1_init_data },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM355
>> { .name = "dm355-psc", .driver_data = (kernel_ulong_t)&dm355_psc_init_data },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM365
>> { .name = "dm365-psc", .driver_data = (kernel_ulong_t)&dm365_psc_init_data },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM644x
>> { .name = "dm644x-psc", .driver_data = (kernel_ulong_t)&dm644x_psc_init_data },
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM646x
>> { .name = "dm646x-psc", .driver_data = (kernel_ulong_t)&dm646x_psc_init_data },
>> +#endif
>> { }
>> };
>>
>> diff --git a/drivers/clk/davinci/psc.h b/drivers/clk/davinci/psc.h
>> index c2a7df6413fe..6a42529d31a9 100644
>> --- a/drivers/clk/davinci/psc.h
>> +++ b/drivers/clk/davinci/psc.h
>> @@ -94,15 +94,27 @@ struct davinci_psc_init_data {
>> int (*psc_init)(struct device *dev, void __iomem *base);
>> };
>>
>> +#ifdef CONFIG_ARCH_DAVINCI_DA830
>> extern const struct davinci_psc_init_data da830_psc0_init_data;
>> extern const struct davinci_psc_init_data da830_psc1_init_data;
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>> extern const struct davinci_psc_init_data da850_psc0_init_data;
>> extern const struct davinci_psc_init_data da850_psc1_init_data;
>> extern const struct davinci_psc_init_data of_da850_psc0_init_data;
>> extern const struct davinci_psc_init_data of_da850_psc1_init_data;
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM355
>> extern const struct davinci_psc_init_data dm355_psc_init_data;
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM356
>> extern const struct davinci_psc_init_data dm365_psc_init_data;
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM644x
>> extern const struct davinci_psc_init_data dm644x_psc_init_data;
>> +#endif
>> +#ifdef CONFIG_ARCH_DAVINCI_DM646x
>> extern const struct davinci_psc_init_data dm646x_psc_init_data;
>> +#endif
>
> ifdefs around these extern declarations are not needed.
True. I guess I just prefer a compiler error to a linker error.
^ permalink raw reply
* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Mathieu Poirier @ 2018-05-28 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALZQ+UMbndvogrSb0Ey3ac1vDGqtsiRTR=ee8VGzU2Ni9_s0og@mail.gmail.com>
On 27 May 2018 at 21:13, Leo Yan <leo.yan@linaro.org> wrote:
> On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
>> The tail of a queue is supposed to be pointing to the next available slot
>> in a queue. In this implementation the tail is incremented before it is
>> used and as such points to the last used element, something that has the
>> immense advantage of centralizing tail management at a single location
>> and eliminating a lot of redundant code.
>>
>> But this needs to be taken into consideration on the dequeueing side where
>> the head also needs to be incremented before it is used, or the first
>> available element of the queue will be skipped.
>>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> ---
>> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> index c8b98fa22997..4d5fc374e730 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
>> /* Nothing to do, might as well just return */
>> if (decoder->packet_count == 0)
>> return 0;
>> + /*
>> + * The queueing process in function cs_etm_decoder__buffer_packet()
>> + * increments the tail *before* using it. This is somewhat counter
>> + * intuitive but it has the advantage of centralizing tail management
>> + * at a single location. Because of that we need to follow the same
>> + * heuristic with the head, i.e we increment it before using its
>> + * value. Otherwise the first element of the packet queue is not
>> + * used.
>> + */
>> + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>>
>> *packet = decoder->packet_buffer[decoder->head];
>>
>> - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>> -
>
> I tested this patch and confirmed it can work well with python
> decoding script:
>
> Tested-by: Leo Yan <leo.yan@linaro.org>
>
> Actually, I have another idea for this fixing, seems to me
> the unchanged code has right logic for decoder->head, and I think this
> issue is more related with incorrect initialization index. So we can
> change the initialization index for decoder->head as below. How about
> you think for this?
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa..b133260 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
> cs_etm_decoder *decoder)
> {
> int i;
>
> - decoder->head = 0;
> + decoder->head = 1;
I flirted with that idea but thought the problem is really with the
tail and as such would have done:
decoder->tail = -1;
But since both head and tail are declared as u32 it would have
required changing the types to int, necessitating modifications
everywhere other parts of the code deals with them. As such I just
decided to swap the order of events in cs_etm_decoder__get_packet().
I'm not strongly opinionated on this and can send another patch if you're keen.
Thanks for the feedback,
Mathieu
> decoder->tail = 0;
> decoder->packet_count = 0;
> for (i = 0; i < MAX_BUFFER; i++) {
>
> Thanks,
> Leo Yan
>
>> decoder->packet_count--;
>>
>> return 1;
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH 12/12] ARM: dts: exynos5250-arndale: add dsi and panel nodes
From: Krzysztof Kozlowski @ 2018-05-28 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527501347-16521-1-git-send-email-m.purski@samsung.com>
On Mon, May 28, 2018 at 11:55 AM, Maciej Purski <m.purski@samsung.com> wrote:
> The patch adds bridge and panel nodes.
> It adds also DSI properties specific for arndale board.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 39 ++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
> index 80221fa..6f0b1c4 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -71,6 +71,17 @@
> };
> };
>
> + panel: panel {
> + compatible = "boe,hv070wsa-100";
> + power-supply = <&vcc_3v3_reg>;
> + enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
> + port {
> + panel_ep: endpoint {
> + remote-endpoint = <&bridge_out_ep>;
> + };
> + };
> + };
> +
> regulators {
> compatible = "simple-bus";
> #address-cells = <1>;
> @@ -476,6 +487,34 @@
> };
> };
>
> +&dsi_0 {
Please put the node alphabetically, so before &dp.
Also this patch should be squashed with previous one (regulators),
because adding non-controllable fixed regulators on its own does not
bring benefits. Linux will not disable them. You added these
regulators for the bridge below. Without the bridge, their existence
does not have much sense.
Best regards,
Krzysztof
> + vddcore-supply = <&ldo8_reg>;
> + vddio-supply = <&ldo10_reg>;
> + samsung,pll-clock-frequency = <24000000>;
> + samsung,burst-clock-frequency = <320000000>;
> + samsung,esc-clock-frequency = <10000000>;
> + status = "okay";
> +
> + bridge at 0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddmipi-supply = <&vcc_1v2_reg>;
> + vddlvds133-supply = <&vcc_3v3_reg>;
> + vddlvds112-supply = <&vcc_1v2_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 1 {
> + reg = <1>;
> + bridge_out_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
> +};
> +
> &i2c_2 {
> status = "okay";
> /* used by HDMI DDC */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 10/12] ARM: dts: exynos5250: add DSI node
From: Krzysztof Kozlowski @ 2018-05-28 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527501272-16365-1-git-send-email-m.purski@samsung.com>
On Mon, May 28, 2018 at 11:54 AM, Maciej Purski <m.purski@samsung.com> wrote:
> The patch adds common part of DSI node for Exynos5250 platforms.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
This should be squashed with previous patch because it is logically
the same feature. The purpose of PHY is this DSI node so splitting it
is slightly too much.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Randy Dunlap @ 2018-05-28 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-9-git-send-email-m.purski@samsung.com>
On 05/28/2018 02:47 AM, Maciej Purski wrote:
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index fa2c799..58e19af 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -110,6 +110,13 @@ config DRM_THINE_THC63LVD1024
> ---help---
> Thine THC63LVD1024 LVDS/parallel converter driver.
>
> +config DRM_TOSHIBA_TC358764
> + tristate "TC358764 DSI/LVDS bridge"
> + depends on DRM && DRM_PANEL
> + depends on OF
> + select DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
Kconfig symbols with "prompt strings" should also have help text.
I expected checkpatch to catch that, but I tested it and there was no warning
from checkpatch about help text. OTOH, there was a warning that there are
2 lines in this patch that end with whitespace, so that should be fixed.
Did you use checkpatch (scripts/checkpatch.pl)?
> config DRM_TOSHIBA_TC358767
> tristate "Toshiba TC358767 eDP bridge"
> depends on OF
thanks,
--
~Randy
^ permalink raw reply
* [PATCH 09/12] ARM: dts: exynos5250: add mipi-phy node
From: Krzysztof Kozlowski @ 2018-05-28 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-10-git-send-email-m.purski@samsung.com>
On Mon, May 28, 2018 at 11:47 AM, Maciej Purski <m.purski@samsung.com> wrote:
> The patch adds phy node, required by MIPI devices.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
This have pretty small changes since original Andrzej's patch so
probably Andrzej's authorship should be preserved.
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 2daf505..a63b655 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -733,6 +733,12 @@
> #phy-cells = <0>;
> };
>
> + mipi_phy: video-phy at 10040710 {
> + compatible = "samsung,s5pv210-mipi-video-phy";
No DTC warnings (make dtbs W=1)? reg is missing so DTC should complain.
Best regards,
Krzysztof
> + #phy-cells = <1>;
> + syscon = <&pmu_system_controller>;
> + };
> +
> adc: adc at 12d10000 {
> compatible = "samsung,exynos-adc-v1";
> reg = <0x12D10000 0x100>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Nicolas Ferre @ 2018-05-28 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db31aac0-6b59-8835-2181-635670e7f176@axentia.se>
On 28/05/2018 at 17:52, Peter Rosin wrote:
> On 2018-05-28 16:27, Boris Brezillon wrote:
[..]
>> Could it just be that you're reaching the DDR bus limit. As I said
>> previously, when you go through the CPU, and assuming you're consuming
>> the data directly, you have:
>>
>> 1/ NFC SRAM -> CPU
>> 2/ CPU -> L1 data cache --write-back--> DRAM
>> 3/ L1-cache -> CPU
>>
>> While, if you use DMA you get:
>>
>> 1/ NFC SRAM -> DRAM
>> 2/ SDRAM -> L1 data cache -> CPU
>>
>> So, if you're approaching the limit of (LP)DDR bandwidth, using the CPU
>> might make things a bit better. Still, if the limitation really comes
>> from the DDR bus, my opinion is that you should maybe use a smaller
>> resolution or use a more compact pixel format (RGB565?).
>
> The issue is still there if I use a CLUT mode instead of rgb565, which is
> what I normally use (and what I would like to use, CLUT is just alien and
> a pain these days).
>
> The panels we are using only supports one resolution (each), but the issue
> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz).
>
>> Did you calculate how much of the bandwidth is taken by the HLCDC
>> block and compared it to the max (LP)DDR bandwidth?
>
> I did, but don't remember the exact details. There is some room even for
> 1920x1080 at 16bpp, but not oceans of it. We were a bit uncertain if 16bpp
> would be possible, and in fact that was the reason I worked on CLUT
> support for atmel-hlcdc last year. But since the problem persists with
> much less memory pressure as well, I don't think that's it either.
Just jumping in the conversation with another perspective (maybe already
tried actually).
Can you try to make all that you can to maximize the blanking period of
your screen (some are more tolerant than others according to that). By
doing so, you would allow the LCD FIFO to recover better after each
line. You might loose some columns on the side of your display but it
would give us a good idea of how far we are from getting rid of those
annoying LCD reset glitches (that are due to underruns on LCD FIFO).
> Admittedly I have not tested these AHB matrix tricks with a smaller
> panel (it would take a bit of work to arrange for those tests), but the
> issue was there when I last tried (using defaults).
If what I said earlier has an impact, reducing the panel size will also
make a difference. But the question is how small is "smaller" ;-)
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-05-28 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db31aac0-6b59-8835-2181-635670e7f176@axentia.se>
On Mon, 28 May 2018 17:52:53 +0200
Peter Rosin <peda@axentia.se> wrote:
> On 2018-05-28 16:27, Boris Brezillon wrote:
> > Hi Peter,
> >
> > On Mon, 28 May 2018 12:10:02 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> On 2018-05-28 00:11, Peter Rosin wrote:
> >>> On 2018-05-27 11:18, Peter Rosin wrote:
> >>>> On 2018-05-25 16:51, Tudor Ambarus wrote:
> >>>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
> >>>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
> >>>>> (7th slave).
> >>>>
> >>>> Exactly how do I accomplish that?
> >>>>
> >>>> I can see how I can move the LCD between slave DDR port 2 and 3 by
> >>>> selecting LCDC DMA master 8 or 9 (but according to the above it should
> >>>> not matter). The big question is how I control what slave the NAND flash
> >>>> is going to use? I find nothing in the datasheet, and the code is also
> >>>> non-transparent enough for me to figure it out by myself without
> >>>> throwing out this question first...
> >>>
> >>> I added this:
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> index e686fe73159e..3b33c63d2ed4 100644
> >>> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> @@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
> >>> nc->dmac = dma_request_channel(mask, NULL, NULL);
> >>> if (!nc->dmac)
> >>> dev_err(nc->dev, "Failed to request DMA channel\n");
> >>> +
> >>> + dev_info(nc->dev, "using %s for DMA transfers\n",
> >>> + dma_chan_name(nc->dmac));
> >>> }
> >>>
> >>> /* We do not retrieve the SMC syscon when parsing old DTs. */
> >>>
> >>>
> >>>
> >>> and the output is
> >>>
> >>> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
> >>>
> >>> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
> >>> or how to find out. I guess IF2 is not in use since that does not allow any
> >>> DDR2 port as slave...
> >>>
> >>> From the datasheet, DMAC0/IF0 uses DDR2 Port 2, and DMAC0/IF1 uses DDR2 Port 1.
> >>> But, by the looks of the register content in my other mail, it seems as if
> >>> DMA0/IF1 can also use DDR2 Port 3.
> >>>
> >>> So, I think I want either
> >>>
> >>> A) the NAND controller to use DMAC0/IF0 (i.e. DDR2 port 1, and possibly 3) and
> >>> the LCDC to use master 9 (i.e. DDR2 Port 2)
> >>>
> >>> or
> >>>
> >>> B) the NAND controller to use DMAC1/IF1 (i.e. DDR2 port 2) and the LCDC to use
> >>> master 8 (i.e. DDR2 Port 3)
> >>
> >> Crap, that was not what I meant to express. Sorry for the confusion. This is
> >> better.
> >>
> >> So, I think I want either
> >>
> >> A) the NAND controller to use master 1 DMAC0/IF0 (i.e. slave 8 DDR2 port 2) and
> >> the LCDC to use master 9 (i.e. slave 9 DDR2 Port 3)
> >>
> >> or
> >>
> >> B) the NAND controller to use master 2 DMAC0/IF1 (i.e. slave 7 DDR2 port 1, and
> >> possibly slave 9 DDR2 port 3 (if my previous findings are relevant) and the
> >> LCDC to use master 8 (i.e. slave 8 DDR2 Port 2)
> >>
> >>> But, again, how do I limit DMAC0 to either of IF0 or IF1 for NAND accesses?
> >>
> >> So, I added a horrid patch (attached), which mainly adds printk lines, but
> >> additionally does one more thing in atc_prep_dma_memcpy. It changes the DSCR_IF
> >> field (from 0) to 1 for DMA-memcpy for dma0chan5 (i.e. the NAND). At least I
> >> think it does that?
> >>
> >> Running with that patch gets me this:
> >>
> >> # dmesg | grep -i dma
> >> at_hdmac ffffe600.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
> >> at_hdmac ffffe800.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
> >> dma dma0chan0: xlate 0 2
> >> dma dma0chan1: xlate 0 2
> >> at91_i2c f0014000.i2c: using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
> >> dma dma1chan0: xlate 0 2
> >> dma dma1chan1: xlate 0 2
> >> at91_i2c f801c000.i2c: using dma1chan0 (tx) and dma1chan1 (rx) for DMA transfers
> >> dma dma0chan2: xlate 0 2
> >> dma dma0chan3: xlate 0 2
> >> dma dma0chan4: xlate 0 2
> >> atmel_mci f0000000.mmc: using dma0chan4 for DMA transfers
> >> dma dma1chan2: xlate 0 2
> >> dma dma1chan3: xlate 0 2
> >> atmel_aes f8038000.aes: Atmel AES - Using dma1chan2, dma1chan3 for DMA transfers
> >> dma dma1chan4: xlate 0 2
> >> atmel_sha f8034000.sha: using dma1chan4 for DMA transfers
> >> dma dma1chan5: xlate 0 2
> >> dma dma1chan6: xlate 0 2
> >> atmel_tdes f803c000.tdes: using dma1chan5, dma1chan6 for DMA transfers
> >> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
> >> dma dma0chan5: memcpy: 0
> >> dma dma0chan5: DSCR_IF: 1
> >> dma dma0chan5: memcpy: 1
> >>
> >> So, output is as expected and I believe that the patch makes the NAND DMA
> >> accesses use master 2 DMAC0/IF1 and are thus forced to use slave 7 DDR2 Port 1
> >> (and possibly 9). The LCDC is using slave 8 DDR2 Port 2. So there should be no
> >> slave conflict?
> >>
> >> But the on-screen crap remains during NAND accesses.
> >>
> >> But pressing on.
> >>
> >> I then changed the priorities for all accesses to 0 in the PRxSy registers, except
> >> the ones for masters 8/9 LCDC (slaves 8/9) which I left at priority 3.
> >>
> >> But the on-screen crap remains during NAND accesses.
> >>
> >> My guess is that the NAND DMA is doing too long bursts and that the LCDC therefore
> >> has to wait too long and simply fails to keep the pipeline from running short?
> >>
> >> So I tried to reduce the maximum SLOT_CYCLE for slaves 7 and 9 in the SCFGx
> >> registers. No noticeable effect either.
> >>
> >> I then tried to split bursts from master 2 (DMAC0/IF1) with small values in the
> >> MCFG2 register. No effect.
> >>
> >> I'm getting nowhere.
> >
> > Could it just be that you're reaching the DDR bus limit. As I said
> > previously, when you go through the CPU, and assuming you're consuming
> > the data directly, you have:
> >
> > 1/ NFC SRAM -> CPU
> > 2/ CPU -> L1 data cache --write-back--> DRAM
> > 3/ L1-cache -> CPU
> >
> > While, if you use DMA you get:
> >
> > 1/ NFC SRAM -> DRAM
> > 2/ SDRAM -> L1 data cache -> CPU
> >
> > So, if you're approaching the limit of (LP)DDR bandwidth, using the CPU
> > might make things a bit better. Still, if the limitation really comes
> > from the DDR bus, my opinion is that you should maybe use a smaller
> > resolution or use a more compact pixel format (RGB565?).
>
> The issue is still there if I use a CLUT mode instead of rgb565, which is
> what I normally use (and what I would like to use, CLUT is just alien and
> a pain these days).
>
> The panels we are using only supports one resolution (each), but the issue
> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz).
Duh! This adds to the weirdness of this issue. I'd thought that by
dividing the required bandwidth by 2 you would get a reliable setup.
>
> > Did you calculate how much of the bandwidth is taken by the HLCDC
> > block and compared it to the max (LP)DDR bandwidth?
>
> I did, but don't remember the exact details. There is some room even for
> 1920x1080 at 16bpp, but not oceans of it. We were a bit uncertain if 16bpp
> would be possible, and in fact that was the reason I worked on CLUT
> support for atmel-hlcdc last year. But since the problem persists with
> much less memory pressure as well, I don't think that's it either.
>
> Admittedly I have not tested these AHB matrix tricks with a smaller
> panel (it would take a bit of work to arrange for those tests), but the
> issue was there when I last tried (using defaults).
Okay. I think I'll take your initial patch, but I'd really like to
understand the root cause of this problem. Tudor, any idea why the
various stuff Peter tried did not work?
^ 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