* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-16 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ho9mz94dg.fsf@baylibre.com>
HI Kevin
On 12/16/2017 03:29 AM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> Add DT info for the stmmac ethernet MAC which found in
>> the Amlogic's Meson-AXG SoC, also describe the ethernet
>> pinctrl & clock information here.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> This patch does not apply, and dependencies are not described.
>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index d356ce74ad89..94c4972222b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -7,6 +7,7 @@
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/axg-clkc.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -148,6 +149,19 @@
>> #address-cells = <0>;
>> };
>>
>> + ethmac: ethernet at ff3f0000 {
>> + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
>> + reg = <0x0 0xff3f0000 0x0 0x10000
>> + 0x0 0xff634540 0x0 0x8>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "macirq";
>> + clocks = <&clkc CLKID_ETH>,
>> + <&clkc CLKID_FCLK_DIV2>,
>> + <&clkc CLKID_MPLL2>;
>> + clock-names = "stmmaceth", "clkin0", "clkin1";
>> + status = "disabled";
>> + };
>> +
>> hiubus: bus at ff63c000 {
>> compatible = "simple-bus";
>> reg = <0x0 0xff63c000 0x0 0x1c00>;
>
> Based on the hiubus node, presumably this depends on the patch from the
> clock series.
>
yes, it depend on clock, also the pinctrl patch
>> @@ -194,6 +208,46 @@
>> #gpio-cells = <2>;
>> gpio-ranges = <&pinctrl_periphs 0 0 86>;
>> };
>
> I'm not sure where this part is coming from, but it causes the rest of
> it to not apply.
>
> Please be sure to describe all dependencies.
>
.
exactly, it depend on pinctrl
actually, once you apply the clock & pinctrl DT patch, this one should
go fine. I will send another v4 which base on your recent v4.16/dt64
branch for your convenience.
Yixun
^ permalink raw reply
* [PATCH v4 0/2] dt: add pinctrl driver for Meson-AXG SoC
From: Yixun Lan @ 2017-12-16 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ha7yj93hu.fsf@baylibre.com>
On 12/16/2017 03:48 AM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> This is DT part patchset for adding pinctrl support for
>> the Amlogic's Meson-AXG SoC.
>>
>> Changes since v3 at [3]
>> -- rebase to khilman's v4.16/dt64 branch and re-send
>> -- add Rob's Ack
>>
>> Changes since v2 at [2]:
>> -- Resend this patch series due to fail to send patch [2/2]
>>
>> Changes since v1 at [1]:
>> -- Separate DT part patches
>> -- Add Neil Armstrong's Ack
>>
>> [3]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005392.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005393.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005394.html
>>
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005390.html
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html
>>
>> Xingyu Chen (2):
>> documentation: Add compatibles for Amlogic Meson AXG pin controllers
>> ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
>
> Applied both to v4.14/dt64
>
> Normally, the documentation patch should go with the driver, but since
> Linus has already merged the driver, this time I'll take it with the DT
> itself.
>
Hi Kevin
sorry, I just checked Linus' pinctrl tree - the for-next branch, the
documentation patch is already taken there. so probably you could drop
it here?
Yixun
^ permalink raw reply
* [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink
From: Brian Norris @ 2017-12-16 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171121082517.17233-1-jeffy.chen@rock-chips.com>
Hi,
On Tue, Nov 21, 2017 at 04:25:17PM +0800, Jeffy Chen wrote:
> The rt5514 dsp captures pcm data through spi directly, so we should not
> use rockchip-i2s as it's cpu dai like other codecs.
>
> Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again.
>
> Reported-by: Jimmy Cheng-Yi Chiang <cychiang@google.com>
> Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp)
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I didn't review this closely (and I don't know ASoC that well), but this
does fix regressions I've seen on 4.15 RCs, where
(a) the rt5514 DAI link doesn't get set up
(b) the rt5514 *always* causes my device to wake up, because we arm the
wakeup IRQ even though we never actually configured the DSP
(c) there are system crashes on resume because the rt5514-spi driver
assumes that the DAI link was correctly configured (that's the
subject of another patch I sent [1]
I believe this was working fine on 4.14? At least, I know (b) didn't
happen, and I'm not sure about (a). (c) is a new issue in 4.15-rc1.
Anyway, that's all to say:
Tested-by: Brian Norris <briannorris@chromium.org>
on the "kevin" Chromebook (Samsung Chromebook Plus).
I also suspect this might be regression-fixing material, for 4.15. Or if
not, at least something like patch [1] should be.
Thanks,
Brian
[1] https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"
^ permalink raw reply
* [PATCH] kbuild: fix dependency of dtbs targets
From: Masahiro Yamada @ 2017-12-16 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+E-fH1mN8Cxu8=8-wRZ+edF0YK5wCrKavY3frp1opbZA@mail.gmail.com>
2017-12-14 6:31 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Wed, Oct 25, 2017 at 12:40 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Hi.
>>
>>
>> 2017-10-10 0:05 GMT+09:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
>>> On Wed, Oct 04, 2017 at 01:27:20PM +0900, Masahiro Yamada wrote:
>>>> The target "dtbs" should depend on "scripts" because it needs to
>>>> build dtc. The "prepare" target is unneeded here.
>>>
>>> Looks fine for ARM, as the only thing the dtbs should depend on is
>>> the kernel configuration (to decide which to build) and DT tooling.
>>>
>>> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
>>>
>>> --
>>
>>
>> I found a potential issue on this
>> because the default DTB install path depends on $(KERNELRELEASE).
>>
>>
>> In top-level Makefile:
>> export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
>>
>>
>> The include/config/kernel.release is created by "prepare3" target.
>>
>> If the dependency on "parepare" is removed,
>> it is possible to run "make dtbs" and "make dtbs_install"
>> without creating include/config/kernel.release.
>>
>> So, the $(KERNELRELEASE) could be empty when installing DTB.
>>
>>
>> Maybe, drop this patch, or reduce the dependency to "parepare3"?
>
> I was doing some work to get dtb builds to work without depending on
> $arch cross compiler and this patch fixes some of the issues. The
> dtbs_install target has the prepare dependency,
Which line?
I checked arch/{arm,arm64,mips}/Makefile, but I did not see any
dependency.
> so that should be
> sufficient and your patch should be fine.
Generally, adding dependencies to install targets is dangerous
because install targets are often invoked in root privilege.
This is stated by, for example,
commit 19514fc665ffbce624785f76ee7ad0ea6378a527
> BTW, Based on prior
> discussion on "ARM: kbuild: Fix forced rebuild after 'make dtbs'"
> thread, prepare should not be needed just for $(KERNELRELEASE).
>
> Rob
No.
If "prepare" target is dropped, you can run dtbs_install
without include/config/kenrel.release
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155101.23505-5-james.morse@arm.com>
On 2017/12/15 23:50, James Morse wrote:
> +asmlinkage void do_serror(struct pt_regs *regs, unsigned int esr)
> +{
> + nmi_enter();
How about firstly let APEI kernel driver to handle it by adding patch[1]? if the handling is successful, do_serror() direct return;
Otherwise continue check the ESR value, for example:
if (!ghes_notify_sei())
return;
[1] https://patchwork.kernel.org/patch/10053027/
> +
> + /* non-RAS errors are not containable */
> + if (!arm64_is_ras_serror(esr) || arm64_is_fatal_ras_serror(regs, esr))
> + arm64_serror_panic(regs, esr);
>
> - panic("Asynchronous SError Interrupt");
> + nmi_exit();
> }
>
^ permalink raw reply
* [RFC 5/5] ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Other than the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index c606af3dbfed..2c92c501cd59 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -88,6 +88,13 @@
/* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
};
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ base-clk-frequency = <3000000>;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5dbf2f0891c1..679ce3a66b4b 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,7 +470,7 @@
#reset-cells = <1>;
};
- ir: ir at 01f02000 {
+ ir: ir at 1f02000 {
compatible = "allwinner,sun5i-a13-ir";
clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
clock-names = "apb", "ir";
--
2.11.0
^ permalink raw reply related
* [RFC 4/5] ARM: dts: sun8i: a83t: Add support for the ir interface
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The ir interface is like the H3 at 0x01f02000 located and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5edb645b506f..5dbf2f0891c1 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,6 +470,16 @@
#reset-cells = <1>;
};
+ ir: ir at 01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x40>;
+ status = "disabled";
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [RFC 3/5] ARM: dts: sun8i: a83t: Add the ir pin for the A83T
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The CIR Pin of the A83T is located at PL12
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..5edb645b506f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -488,6 +488,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+ ir_pins_a: ir at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.11.0
^ permalink raw reply related
* [RFC 2/5] [media] dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new requiered property for the base clock frequency.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..5f4960c61245 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,12 +1,13 @@
Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
Required properties:
-- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
-- clocks : list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names : should contain "apb" and "ir" entries;
-- interrupts : should contain IR IRQ number;
-- reg : should contain IO map address for IR.
+- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+- base-clk-frequency : should contain the base clock frequency
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
@@ -21,5 +22,6 @@ ir0: ir at 1c21800 {
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
+ base-clk-frequency = <8000000>;
linux,rc-map-name = "rc-rc6-mce";
};
--
2.11.0
^ permalink raw reply related
* [RFC 1/5] [media] rc: update sunxi-ir driver to get base frequency from devicetree
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
This patch updates the sunxi-ir driver to set the ir base clock from
devicetree.
This is neccessary since there are different ir recievers on the
market, that operate with different frequencys. So this value needs to
be set depending on the attached receiver.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..55b53d6463e9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,6 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
-#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +116,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) * ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +142,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +167,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Required frequency for IR0 or IR1 clock in CIR mode */
+ if (of_property_read_u32(dn, "base-clk-frequency", &b_clk_freq)) {
+ dev_err(dev, "failed to get ir base clock frequency.\n");
+ return -ENODATA;
+ }
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,7 +181,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
@@ -225,7 +226,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [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
* [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
* [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 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 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
* 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 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
* [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 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
* [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 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
* [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 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 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/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
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