* [PATCH 0/7] Add USB remote wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun@mediatek.com>
On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
> These patches introduce the SSUSB and SPM glue layer driver which is
> used to support usb remote wakeup. Usually the glue layer is put into
> a system controller, such as PERICFG module.
> The old way to support usb wakeup is put into SSUSB controller drivers,
> including xhci-mtk driver and mtu3 driver, but there are some problems:
> 1. can't disdinguish the relation between glue layer and SSUSB IP
> when SoCs supports multi SSUSB IPs;
> 2. duplicated code for wakeup are put into both xhci-mtk and mtu3
> drivers;
> 3. the glue layer may vary on different SoCs with SSUSB IP, and will
> make SSUSB controller drivers complicated;
> In order to resolve these problems, it's useful to make the glue layer
> transparent by extracting a seperated driver, meanwhile to reduce the
> duplicated code and simplify SSUSB controller drivers.
Both the driver and binding look overly complicated to me when it looks
like you just have 2 versions of enable/disable functions which modify
a single register. The complexity may be justified if this was a common
binding and driver, but it is not.
You already have a phandle to the system controller. Can't you add cells
to it to handle any differences between instances? That and SoC specific
compatible strings should be enough to handle differences.
Rob
^ permalink raw reply
* [PATCH 1/7] soc: mediatek: Add USB wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512809136-2779-2-git-send-email-chunfeng.yun@mediatek.com>
On Sat, Dec 09, 2017 at 04:45:30PM +0800, Chunfeng Yun wrote:
> This driver is used to support usb wakeup which is controlled by
> the glue layer between SSUSB and SPM. Usually the glue layer is put
> into a system controller, such as pericfg module, which is
> represented by a syscon node in DTS.
> Due to the glue layer may vary on different SoCs, it's useful to
> extract a separated driver to simplify usb controller drivers.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/soc/mediatek/Kconfig | 8 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++++++++++++++++++++++++++
> include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
This belongs in the binding patch and that should come first.
> include/linux/soc/mediatek/usb-wakeup.h | 88 +++++
> 5 files changed, 631 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
> create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
> create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
> +++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
> @@ -0,0 +1,519 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
This should be the first line of the file and use a // style comment.
[...]
> diff --git a/include/dt-bindings/soc/mediatek,usb-wakeup.h b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> new file mode 100644
> index 0000000..2461795
> --- /dev/null
> +++ b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
ditto. Except headers use /* */ comments...
^ permalink raw reply
* [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Frank Rowand @ 2017-12-15 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214151240.14555-1-a.heider@gmail.com>
On 12/14/17 07:12, Andre Heider wrote:
> The overlay feature requires the base dtb to be built with symbols, so
> lets build the dtbs with symbols when overlay support was explicitly
> enabled.
>
> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
> average.
>
> Totals in bytes with the 3 biggest ones:
>
> Before:
> 90471 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
> 90521 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
> 92639 arch/arm/boot/dts/dra7-evm.dtb
> 25731296 total
>
> After:
> 133203 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
> 133237 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
> 134545 arch/arm/boot/dts/dra7-evm.dtb
> 35464440 total
>
> Signed-off-by: Andre Heider <a.heider@gmail.com>
> ---
>
> Hi,
>
> while playing around with overlays I noticed that I needed to rebuilt
> my distro's device trees because they didn't come with symbols.
>
> Is that for a reason, maybe the not so minor increase in size?
Yes, size is the issue.
>
> Thanks,
> Andre
>
> drivers/of/unittest-data/Makefile | 7 -------
> scripts/Makefile.lib | 5 +++++
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
> index 32389acfa616..b65061013512 100644
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
> targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
> targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
> targets += overlay_base.dtb overlay_base.dtb.S
> -
> -# enable creation of __symbols__ node
> -DTC_FLAGS_overlay := -@
> -DTC_FLAGS_overlay_bad_phandle := -@
> -DTC_FLAGS_overlay_bad_symbol := -@
> -DTC_FLAGS_overlay_base := -@
> -
> endif
>
> .PRECIOUS: \
No. The unittests require these to be set unconditionally.
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1ca4dcd2d500..c7ba4aa8a07a 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
> -Wproperty_name_chars_strict
> endif
>
> +ifeq ($(CONFIG_OF_OVERLAY),y)
> +# enable creation of __symbols__ node
> +DTC_FLAGS += -@
> +endif
> +
> DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>
> # Generate an assembly file to wrap the output of the device tree compiler
>
Not needed. Instead set DTC_FLAGS in the make command. For example:
DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
There are a few architecture Makefiles that need to be fixed to not unconditionally
set DTC_FLAGS.
-Frank
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-15 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C2Mo4VQ2WNDqcXbsu=uP=3suAhPzXd3-LSwbir38A22g@mail.gmail.com>
On Fri, Dec 15, 2017 at 06:36:49PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Fri, Dec 15, 2017 at 4:23 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > How about this one, also untested etc.?
>
> This one gives a build warning:
>
> arch/arm/kernel/smp.c: In function ?__cpu_die?:
> arch/arm/kernel/smp.c:262:5: warning: ?ret? may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> if (!ret) {
> ^
That would be me being stupid. Please see below for an updated patch.
> but when I run suspend/resume I don't see the RCU warning with this
> patch applied.
So some progress, at least! Thank you for your testing efforts!!!
Thanx, Paul
------------------------------------------------------------------------
commit e1bb1ddc3402220eba1138322fedd520801ee510
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Dec 11 09:40:58 2017 -0800
ARM: CPU hotplug: Delegate complete() to surviving CPU
The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
does so after RCU has stopped watching the outgoing CPU, which results
in lockdep complaints because complete() invokes functions containing RCU
readers. In addition, if the outgoing CPU really were to consume several
seconds of its five-second allotted time, multiple RCU updates could
complete, possibly giving the outgoing CPU an inconsistent view of the
scheduler data structures on which complete() relies.
This (untested, probably does not build) commit avoids this problem by
polling the outgoing CPU. The polling strategy in this prototype patch
is quite naive, with one jiffy between each poll and without any sort
of adaptive spin phase. The key point is that the polling CPU uses
atomic_dec_and_test(), which evicts the flag from the outgoing CPU's
cache. The outgoing CPU simply does an atomic_set() of the value 1 which
causes the next atomic_dec_and_test() to return true, and which also
minimizes opportunities for other data to get pulled into the outgoing
CPU's cache. This pulling of values from the outgoing CPU's cache is
important because the outgoing CPU might be unceremoniously powered off
before it has time to execute any code after the atomic_set().
Underflow is avoided because there can be at most 5,000 invocations of
atomic_dec_and_test() for a given offline operation, and the counter is
set back to zero each time.
Reported-by: Peng Fan <van.freenix@gmail.com>
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: <linux-arm-kernel@lists.infradead.org>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00ee4ad..f9a4990689f3 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -241,7 +241,7 @@ int __cpu_disable(void)
return 0;
}
-static DECLARE_COMPLETION(cpu_died);
+static atomic_t cpu_died;
/*
* called on the thread which is asking for a CPU to be shutdown -
@@ -249,7 +249,17 @@ static DECLARE_COMPLETION(cpu_died);
*/
void __cpu_die(unsigned int cpu)
{
- if (!wait_for_completion_timeout(&cpu_died, msecs_to_jiffies(5000))) {
+ unsigned long deadline = jiffies + msecs_to_jiffies(5000);
+ char ret = 0;
+
+ while (time_before(jiffies, deadline)) {
+ ret = atomic_dec_and_test(&cpu_died);
+ if (ret)
+ break;
+ schedule_timeout_interruptible(1);
+ }
+ atomic_set(&cpu_died, 0);
+ if (!ret) {
pr_err("CPU%u: cpu didn't die\n", cpu);
return;
}
@@ -295,7 +305,7 @@ void arch_cpu_idle_dead(void)
* this returns, power and/or clocks can be removed at any point
* from this CPU and its cache by platform_cpu_kill().
*/
- complete(&cpu_died);
+ atomic_set(&cpu_died, 1);
/*
* Ensure that the cache lines associated with that completion are
^ permalink raw reply related
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215213403.GG7829@linux.vnet.ibm.com>
Hi Paul,
On Fri, Dec 15, 2017 at 7:34 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> That would be me being stupid. Please see below for an updated patch.
This one builds cleanly and works fine on my imx6q board. Thanks
^ permalink raw reply
* [PATCH net-next 1/2 v8] net: ethernet: Add DT bindings for the Gemini ethernet
From: Rob Herring @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171210224558.27122-1-linus.walleij@linaro.org>
On Sun, Dec 10, 2017 at 11:45:57PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v7->v8:
> - Use ethernet-port at 0 and ethernet-port at 1 with unit names
> and following OF graph requirements.
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] arm: kirkwood: dts: Use lower case for bindings notation
From: Andrew Lunn @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215170711.8212-1-malat@debian.org>
On Fri, Dec 15, 2017 at 06:07:11PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Thanks for fixing up the commit message.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 1/5] dt-bindings: pinctrl: Add st,stm32f769-pinctrl compatible to stm32-pinctrl
From: Rob Herring @ 2017-12-15 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue@st.com>
On Mon, Dec 11, 2017 at 09:54:31AM +0100, Alexandre Torgue wrote:
> Add new compatible for stm32f769 MCU.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: bcm2836-l1-intc: add interrupt polarity support
From: Eric Anholt @ 2017-12-15 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-2-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> This increases the interrupt cells for the 1st level interrupt controller
> binding in order to describe the polarity like on the other ARM platforms.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
I'm happy with this. Any DT maintainer concerns?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/46a79d48/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Rob Herring @ 2017-12-15 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3BB206AB2B1BD448954845CE6FF69A8E01CB53233C@NT-Mail07.beckhoff.com>
On Mon, Dec 11, 2017 at 1:08 AM, Patrick Br?nn <P.Bruenn@beckhoff.com> wrote:
>>From: Rob Herring [mailto:robh at kernel.org]
>>Sent: Mittwoch, 6. Dezember 2017 22:55
>>On Tue, Dec 05, 2017 at 03:06:42PM +0100, linux-kernel-dev at beckhoff.com
>>wrote:
>>> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>>>
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
>>> @@ -0,0 +1,17 @@
>>> +* i.MX53 Real Time Clock controller
>>> +
>>> +Required properties:
>>> +- compatible: should be: "fsl,imx53-rtc"
>>> +- reg: physical base address of the controller and length of memory
>>mapped
>>> + region.
>>> +- clocks: should contain the phandle for the rtc clock
>>
>>Shouldn't there be more than 1 here. From what I remember, the ipg clock
>>and the 32k clock?
> Yes, you are right. But if I am reading the original Freescale driver and the
> reference manual correctly, the second clock is always active.
> Section "72.3.1.1 Clocks" from the reference manual [1] reads:
> "SRTC runs on two clock sources, high frequency peripherals clock and low frequency
> timers clock. The high frequency peripheral IP clock is used by the SRTC peripheral bus
> interface, control and status registers. The low frequency 32.768 kHz clock is the
> always-active clock used by the SRTC timers..."
>
> That's why I would only include one clock . Should I change this?
Some chips supported 32.0kHz and 32.768kHz low freq clocks, so you'd
need to be able to query what the frequency is even if you don't need
to enable the clock, but maybe that may be gone in MX53. I don't
remember.
>>> +- interrupts: rtc alarm interrupt
>>> +
>>> +Example:
>>> +
>>> +srtc at 53fa4000 {
>>
>>rtc at ...
>>
> The rtc for which this series adds support is embedded within a function block called
> "Secure Real Time Clock". This driver doesn't utilize all of the hardware features by
> now. But maybe someone else wants to extend the functionalities, later.
> For that possibility I wanted to name the node "srtc". Should I still change this?
>
> I believe you have a much better understanding of what should be done here. I don't
> want to argue with you, just thought you might not had that information. So if I am
> wrong just tell me and I will change it without further "complaining".
Node names should be generic for the class of h/w they are. So yes, it
should be "rtc".
Rob
^ permalink raw reply
* [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-12-15 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215190140.d4df71b202b9803baa6a1e10@magewell.com>
Hi,
On Fri, Dec 15, 2017 at 07:01:40PM +0800, Yong wrote:
> Hi Maxime,
>
> On Fri, 15 Dec 2017 11:50:47 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi Yong,
> >
> > On Mon, Dec 04, 2017 at 05:45:11PM +0800, Yong wrote:
> > > I just noticed that you are using the second iteration?
> > > Have you received my third iteration?
> >
> > Sorry for the late reply, and for not coming back to you yet about
> > that test. No, this is still in your v2. I've definitely received your
> > v3, I just didn't have time to update to it yet.
> >
> > But don't worry, my mail was mostly to know if you had tested that
> > setup on your side to try to nail down the issue on my end, not really
> > a review or comment that would prevent your patch from going in.
>
> I mean,
> The v2 exactly has a bug which may cause the CSI writing frame to
> a wrong memory address.
Ah, sorry I misunderstood you then. I'll definitely test your v3..
> BTW, should I send a new version. I have made some improve sine v3.
.. or your v4 :)
Yes, please send a new version.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] dt-bindings: bcm2836-l1-intc: add interrupt polarity support
From: Rob Herring @ 2017-12-15 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-2-git-send-email-stefan.wahren@i2se.com>
On Mon, Dec 11, 2017 at 09:39:10PM +0100, Stefan Wahren wrote:
> This increases the interrupt cells for the 1st level interrupt controller
> binding in order to describe the polarity like on the other ARM platforms.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> .../devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
From: Rob Herring @ 2017-12-15 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb93acdb07a0205e9d3089058b45aee1a6c04d50.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 02:24:18PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
> ---
> .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 351 +++++++++++++++++++++
> 1 file changed, 351 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 10/12] arm64: vdso: replace gettimeofday.S with global vgettimeofday.C
From: Jeffrey Bastian @ 2017-12-15 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171121180319.tawkc42jjx4ow3hg@tarantula.localdomain>
On Tue, Nov 21, 2017 at 13:28:13 PST, Mark Salyzyn wrote:
> I ran the test (32 and 64 bit) on my latest work (but back-ported to
> 4.9) and it passes. I did not change __vdso_clock_getres or the fallback
> (syscall) handler in the patch series though, so the failure has me
> wondering. Could you re-run the test with latest to be sure, and I will
> look into setting up to test with a ToT kernel (after the thanksgiving
> break).
I applied your patch set to a 4.14 kernel and ran LTP clock_getres01
(64-bit) and it still passed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[root at localhost ~]# uname -r
4.14.0-vdsogtod.aarch64
[root at localhost ~]# ./ltp-full-20170929/testcases/kernel/syscalls/clock_getres/clock_getres01
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
clock_getres01.c:79: PASS: clock_getres(REALTIME, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(MONOTONIC, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(PROCESS_CPUTIME_ID, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(THREAD_CPUTIME_ID, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(REALTIME, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(CLOCK_MONOTONIC_RAW, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(CLOCK_REALTIME_COARSE, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(CLOCK_MONOTONIC_COARSE, ...) succeeded
clock_getres01.c:79: PASS: clock_getres(CLOCK_BOOTTIME, ...) succeeded
clock_getres01.c:64: CONF: clock_getres(CLOCK_REALTIME_ALARM, ...) NO SUPPORTED
clock_getres01.c:64: CONF: clock_getres(CLOCK_BOOTTIME_ALARM, ...) NO SUPPORTED
clock_getres01.c:79: PASS: clock_getres(-1, ...) succeeded
Summary:
passed 10
failed 0
skipped 2
warnings 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I also tried another test (see source below) which sleeps for 0.5
seconds and then verifies that approximately 0.5 seconds passed. With
the original gettimeofday-in-C patches, it would often fail with weird
elapsed times like 0.1 seconds or 1.1 seconds:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 1207, tv_nsec = 6403566
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 1207, tv_nsec = 16512476
Elapsed: 0.10108910
FAIL: elapsed time is not approximately 0.5 seconds
255
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 1215, tv_nsec = 9784545
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 1216, tv_nsec = 9898595
Elapsed: 1.114050
FAIL: elapsed time is not approximately 0.5 seconds
255
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 1225, tv_nsec = 13710370
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 1225, tv_nsec = 13819740
Elapsed: 0.109370
FAIL: elapsed time is not approximately 0.5 seconds
255
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The elapsed time matches the expected 0.5 seconds with the latest patch
version:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 2077, tv_nsec = 989623095
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 2078, tv_nsec = 489728070
Elapsed: 0.500104975
PASS
0
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 2079, tv_nsec = 519625035
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 2080, tv_nsec = 19726365
Elapsed: 0.500101330
PASS
0
[root at localhost ~]# ./a.out ; echo $?
1: clock_gettime: tv_sec = 2080, tv_nsec = 684894725
Sleeping 0.5 seconds
2: clock_gettime: tv_sec = 2081, tv_nsec = 184994605
Elapsed: 0.500099880
PASS
0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source for the elapsed time test:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <time.h>
int main(void)
{
int ret;
clockid_t clk_id = CLOCK_MONOTONIC_RAW;
struct timespec tp1, tp2, elapsed;
struct timespec req, rem;
ret = clock_gettime(clk_id, &tp1);
if (ret) {
perror("ERROR: clock_gettime:");
}
printf("1: clock_gettime: tv_sec = %ld, tv_nsec = %lld\n",
tp1.tv_sec, tp1.tv_nsec);
printf("Sleeping 0.5 seconds\n");
req.tv_sec = 0;
req.tv_nsec = 500000000;
ret = nanosleep(&req, &rem);
if (ret) {
perror("ERROR: nanosleep:");
printf(" Remaining sleep: tv_sec = %ld, tv_nsec = %lld\n",
rem.tv_sec, rem.tv_nsec);
}
ret = clock_gettime(clk_id, &tp2);
if (ret) {
perror("ERROR: clock_gettime:");
}
printf("2: clock_gettime: tv_sec = %ld, tv_nsec = %lld\n",
tp2.tv_sec, tp2.tv_nsec);
if ((tp2.tv_nsec - tp1.tv_nsec) < 0) {
elapsed.tv_sec = tp2.tv_sec - tp1.tv_sec - 1;
elapsed.tv_nsec = 1000000000 + tp2.tv_nsec - tp1.tv_nsec;
} else {
elapsed.tv_sec = tp2.tv_sec - tp1.tv_sec;
elapsed.tv_nsec = tp2.tv_nsec - tp1.tv_nsec;
}
printf("Elapsed: %ld.%lld\n", elapsed.tv_sec, elapsed.tv_nsec);
if (elapsed.tv_sec != 0 ||
elapsed.tv_nsec < 490000000 ||
elapsed.tv_nsec > 510000000) {
printf("FAIL: elapsed time is not approximately 0.5 seconds\n");
return -1;
}
printf("PASS\n");
return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Jeff Bastian
Kernel QE - Hardware Enablement
Red Hat
^ permalink raw reply
* [PATCH 04/10] clk: qcom: Add CPU clock driver for msm8996
From: Rob Herring @ 2017-12-15 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513081897-31612-5-git-send-email-ilialin@codeaurora.org>
On Tue, Dec 12, 2017 at 02:31:31PM +0200, Ilia Lin wrote:
> From: Rajendra Nayak <rnayak@codeaurora.org>
>
> Each of the CPU clusters (Power and Perf) on msm8996 are
> clocked via 2 PLLs, a primary and alternate. There are also
> 2 Mux'es, a primary and secondary all connected together
> as shown below
>
> +-------+
> XO | |
> +------------------>0 |
> | |
> PLL/2 | SMUX +----+
> +------->1 | |
> | | | |
> | +-------+ | +-------+
> | +---->0 |
> | | |
> +---------------+ | +----------->1 | CPU clk
> |Primary PLL +----+ PLL_EARLY | | +------>
> | +------+-----------+ +------>2 PMUX |
> +---------------+ | | | |
> | +------+ | +-->3 |
> +--^+ ACD +-----+ | +-------+
> +---------------+ +------+ |
> |Alt PLL | |
> | +---------------------------+
> +---------------+ PLL_EARLY
>
> The primary PLL is what drives the CPU clk, except for times
> when we are reprogramming the PLL itself (for rate changes) when
> we temporarily switch to an alternate PLL. A subsequent patch adds
> support to switch between primary and alternate PLL during rate
> changes.
>
> The primary PLL operates on a single VCO range, between 600Mhz
> and 3Ghz. However the CPUs do support OPPs with frequencies
> between 300Mhz and 600Mhz. In order to support running the CPUs
> at those frequencies we end up having to lock the PLL at twice
> the rate and drive the CPU clk via the PLL/2 output and SMUX.
>
> So for frequencies above 600Mhz we follow the following path
> Primary PLL --> PLL_EARLY --> PMUX(1) --> CPU clk
> and for frequencies between 300Mhz and 600Mhz we follow
> Primary PLL --> PLL/2 --> SMUX(1) --> PMUX(0) --> CPU clk
> Support for this is added in a subsequent patch as well.
>
> ACD stands for Adaptive Clock Distribution and is used to
> detect voltage droops. We do not add support for ACD as yet.
> This can be added at a later point as needed.
>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,kryocc.txt | 17 +
If you respin, please make bindings a separate patch. In any case,
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 8 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-cpu-8996.c | 388 +++++++++++++++++++++
> 4 files changed, 414 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,kryocc.txt
> create mode 100644 drivers/clk/qcom/clk-cpu-8996.c
^ permalink raw reply
* [arm:phy 46/61] drivers/net//ethernet/marvell/mvneta.c:3425:12: error: too few arguments to function 'phylink_of_phy_connect'
From: kbuild test robot @ 2017-12-15 22:38 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git phy
head: ed4a36b32c63ac8a795692a49f5df6471cbf3793
commit: 3d2e7b55772fe50d021ba4af7fb487ef57c41bd9 [46/61] net: mvneta: convert to phylink
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 3d2e7b55772fe50d021ba4af7fb487ef57c41bd9
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net//ethernet/marvell/mvneta.c: In function 'mvneta_mdio_probe':
>> drivers/net//ethernet/marvell/mvneta.c:3425:12: error: too few arguments to function 'phylink_of_phy_connect'
int err = phylink_of_phy_connect(pp->phylink, pp->dn);
^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/net//ethernet/marvell/mvneta.c:31:0:
include/linux/phylink.h:191:5: note: declared here
int phylink_of_phy_connect(struct phylink *, struct device_node *, u32 flags);
^~~~~~~~~~~~~~~~~~~~~~
sparse warnings: (new ones prefixed by >>)
vim +/phylink_of_phy_connect +3425 drivers/net//ethernet/marvell/mvneta.c
3421
3422 static int mvneta_mdio_probe(struct mvneta_port *pp)
3423 {
3424 struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> 3425 int err = phylink_of_phy_connect(pp->phylink, pp->dn);
3426
3427 if (err)
3428 netdev_err(pp->dev, "could not attach PHY: %d\n", err);
3429
3430 phylink_ethtool_get_wol(pp->phylink, &wol);
3431 device_set_wakeup_capable(&pp->dev->dev, !!wol.supported);
3432
3433 return err;
3434 }
3435
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 62411 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171216/fe29fcd1/attachment-0001.gz>
^ permalink raw reply
* [PATCH 0/2] Ethernet for the Nanopi M1 & M1 plus
From: Philipp Rossak @ 2017-12-15 22:38 UTC (permalink / raw)
To: linux-arm-kernel
The first patch of this patch series, fixes a missing alias
on the nanopi m1 plus. The second patch enables the dwmac-sun8i
ethernet driver on the Nanopi M1.
Philipp Rossak (2):
ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases
ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 1 +
arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 11 +++++++++++
2 files changed, 12 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases
From: Philipp Rossak @ 2017-12-15 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215223901.14500-1-embed3d@gmail.com>
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
index 0a8b79cf5954..87509a3e6aba 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -48,6 +48,7 @@
aliases {
serial1 = &uart3;
+ ethernet0 = &emac;
ethernet1 = &sdio_wifi;
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1
From: Philipp Rossak @ 2017-12-15 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215223901.14500-1-embed3d@gmail.com>
The dwmac-sun8i hardware is present on the Nanopi M1.
It uses the internal PHY
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index 3a2ccdb28afd..c77fbca4f227 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -45,6 +45,10 @@
/ {
model = "FriendlyArm NanoPi M1";
compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
+
+ aliases {
+ ethernet0 = &emac;
+ };
};
&ehci1 {
@@ -55,6 +59,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.11.0
^ permalink raw reply related
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-15 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5ACh-idu4rharGwBnqzfA+b+29fkvruGMv17WF66h-+UQ@mail.gmail.com>
On Fri, Dec 15, 2017 at 07:43:36PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Fri, Dec 15, 2017 at 7:34 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > That would be me being stupid. Please see below for an updated patch.
>
> This one builds cleanly and works fine on my imx6q board. Thanks
Very good, thank you!
Thanx, Paul
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Rob Herring @ 2017-12-15 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215115230.6fb83cb6@xps13>
On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> Hello Baruch and Gregory,
>
> On Fri, 15 Dec 2017 09:44:19 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
> > Hi Miquel,
> >
> > On ven., d?c. 15 2017, Miquel RAYNAL
> > <miquel.raynal@free-electrons.com> wrote:
> >
> > > Hello Baruch,
> > >
> > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > Baruch Siach <baruch@tkos.co.il> wrote:
> > >
> > >> Hi Miquel
> > >>
> > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > >> > +- marvell,thermal-zone-name: The name to identify the thermal
> > >> > zone
> > >> > + within the sysfs, useful when
> > >> > multiple
> > >> > + thermal zones are registered (AP,
> > >> > CPx...).
> > >>
> > >> I don't think that would be acceptable. DT is about describing the
> > >> hardware. sysfs is a Linux implementation detail which is not tied
> > >> to any specific hardware. If this is accepted, the property should
> > >> be named 'linux,thermal-zone-name'.
> > >
> > > You are right the sysfs mention should not appear in the
> > > description.
>
> Actually, you are right for all of it, this property should not
> exist, sorry for my too quick answer.
>
> > >
> > > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > > that case.
>
> Thank you both for your explanations, I was also wrong about the prefix.
>
> >
> > Actually the choice between linux or marvell make me realize that
> > there is something wrong. Having a name associated to a device is
> > something pretty usual with the device tree, however it is as the
> > class device level, such as clock-names, line-name, or
> > regulator-name. So in my opinion if we want to support naming from
> > device tree it would be done for all the thermal device not just for
> > the Marvell one.
> >
> > However I don't think we need it. For example for the clocks we
> > created the name dynamically using of the base address of the
> > register to keep them unique.
>
> I was convinced that dev_name's would be the same but after trying it on
> a 8040-DB, using dev_name(&pdev->dev) gives:
>
> f06f808c.thermal
> f2400078.thermal
> f4400078.thermal
>
> which I found meaningful enough.
>
> I will drop the property and use dev_name instead. I still need your
> help to solve one problem though: how to make the distinction between
> using "armada_thermal" (the previous name) and dev_name() ? If I don't
> it kind of breaks userspace, doesn't it ?
No. The /sys/devices/... or /sys/bus/platform/... paths and names are
not guaranteed to be stable. These changed for every platform converted
to DT for example. Userspace should be accessing things through
/sys/class/... (or deal with changes).
Rob
^ permalink raw reply
* [PATCH 3/3] arm64: dts: meson-axg: add new reset DT node
From: Kevin Hilman @ 2017-12-16 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04b96767-2412-7242-780c-f3e1e610a62b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 10/11/2017 09:46, Yixun Lan wrote:
>> Add reset DT node for Amlogic's Meson-AXG SoC.
>>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index e0fb860e12c5..65945c6c8b65 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -123,6 +123,12 @@
>> #size-cells = <2>;
>> ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
>>
>> + reset: reset-controller at 1004 {
>> + compatible = "amlogic,meson-axg-reset";
>> + reg = <0x0 0x01004 0x0 0x9c>;
>> + #reset-cells = <1>;
>> + };
>> +
>> uart_A: serial at 24000 {
>> compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
>> reg = <0x0 0x24000 0x0 0x14>;
>>
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to v4.16/dt64,
Kevin
^ permalink raw reply
* [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Grygorii Strashko @ 2017-12-16 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213185313.20017-2-alexandre.belloni@free-electrons.com>
On 12/13/2017 12:53 PM, Alexandre Belloni wrote:
> The clocksource and clockevent timer are probed early in the boot process.
> At that time it is difficult for linux to know whether a particular timer
> can be used as the clocksource or the clockevent or by another driver,
> especially when they are all identical or have similar features.
>
> Until now, multiple strategies have been used to solve that:
> - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
> - use a kernel parameter as the "clocksource" early_param in mach-omap2
> - registering the first seen timer as a clockevent and the second one as
> a clocksource as in rk_timer_init or dw_apb_timer_init
>
> Add a linux,clocksource and a linux,clockevent node in chosen with a timer
> property pointing to the timer to use. Other properties, like the targeted
> precision may be added later.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index e3b13ea7d2ae..c7ee3ecb5276 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -120,3 +120,23 @@ e.g.
> While this property does not represent a real hardware, the address
> and the size are expressed in #address-cells and #size-cells,
> respectively, of the root node.
> +
> +linux,clocksource and linux,clockevent
> +--------------------------------------
> +
> +Those nodes have a timer property. This property is a phandle to the timer to be
> +chosen as the clocksource or clockevent. This is only useful when the platform
> +has multiple identical timers and it is not possible to let linux make the
> +correct choice.
> +
> +/ {
> + chosen {
> + linux,clocksource {
> + timer = <&timer0>;
> + };
> +
> + linux,clockevent {
> + timer = <&timer1>;
> + };
> + };
> +};
>
It'd be nice if smth. like this will actually happen, as on some OMAP
platforms can be up to 3-4 alternatives for each clocksource/clockevent and
different combination need to be selected depending on SoC and platform
(and sometime - use case) which is pain in multi-platform environment now.
But more important note from my side is clocksource and clockevent selections seems
not enough :( There are also sched clock (sched_clock_register()) and delay_timer
(register_current_timer_delay() at least on ARM).
Both above can't be unregistered (at least last time I've checked).
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: gengdongjiu @ 2017-12-16 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73019dea-3e2c-8d03-fe1a-6c54527fa401@arm.com>
Hi catalin/will,
On 2017/12/13 18:09, Suzuki K Poulose wrote:
> On 13/12/17 10:13, Dongjiu Geng wrote:
>> ARM v8.4 extensions add new neon instructions for performing a
>> multiplication of each FP16 element of one vector with the corresponding
>> FP16 element of a second vector, and to add or subtract this without an
>> intermediate rounding to the corresponding FP32 element in a third vector.
>>
>> This patch detects this feature and let the userspace know about it via a
>> HWCAP bit and MRS emulation.
>>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
>> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
>
> Looks good to me.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
hope this patch can be applied to 4.15 kernel version.
Thanks
>
> .
^ permalink raw reply
* [RFC 0/5] IR support for A83T - sunxi-ir driver update
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the sunxi A83T ir module and enhances the sunxi-ir driver.
Right now the base clock frequency for the ir driver is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3 the ir receiver needs,
a 3 MHz base clock frequency to work without problems with this driver (like in the legacy kernel).
To fix this issue I reworked the driver that this value could be set over the devicetree.
About 37 devices would have a devicetree change if this patch series would be applied.
Therfore I would like to ask you to give me some feedback about the patch series, before I finialize it.
Thanks in advance!
Philipp
Philipp Rossak (5):
[media] rc: update sunxi-ir driver to get base frequency from
devicetree
[media] dt: bindings: Update binding documentation for sunxi IR
controller
ARM: dts: sun8i: a83t: Add the ir pin for the A83T
ARM: dts: sun8i: a83t: Add support for the ir interface
ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller
Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 ++++++++------
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
drivers/media/rc/sunxi-cir.c | 20 +++++++++++---------
4 files changed, 41 insertions(+), 15 deletions(-)
--
2.11.0
^ 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