Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 5/6] clk: renesas: r8a7796: Add Z clock
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

This patch adds Z clock for R8A7796 SoC.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index b3767472088a..82b444ac66c6 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -74,6 +74,7 @@ static const struct cpg_core_clk r8a7796_core_clks[] __initconst = {
 	DEF_FIXED(".sdsrc",     CLK_SDSRC,         CLK_PLL1_DIV2,  2, 1),
 
 	/* Core Clock Outputs */
+	DEF_BASE("z",           R8A7796_CLK_Z,     CLK_TYPE_GEN3_Z, CLK_PLL0),
 	DEF_FIXED("ztr",        R8A7796_CLK_ZTR,   CLK_PLL1_DIV2,  6, 1),
 	DEF_FIXED("ztrd2",      R8A7796_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
 	DEF_FIXED("zt",         R8A7796_CLK_ZT,    CLK_PLL1_DIV2,  4, 1),
-- 
2.11.0

^ permalink raw reply related

* [PATCH v4 6/6] clk: renesas: r8a7796: Add Z2 clock
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

This patch adds Z2 clock for R8A7796 SoC.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 82b444ac66c6..83a68e51e4ec 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -75,6 +75,7 @@ static const struct cpg_core_clk r8a7796_core_clks[] __initconst = {
 
 	/* Core Clock Outputs */
 	DEF_BASE("z",           R8A7796_CLK_Z,     CLK_TYPE_GEN3_Z, CLK_PLL0),
+	DEF_BASE("z2",          R8A7796_CLK_Z2,    CLK_TYPE_GEN3_Z2, CLK_PLL2),
 	DEF_FIXED("ztr",        R8A7796_CLK_ZTR,   CLK_PLL1_DIV2,  6, 1),
 	DEF_FIXED("ztrd2",      R8A7796_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
 	DEF_FIXED("zt",         R8A7796_CLK_ZT,    CLK_PLL1_DIV2,  4, 1),
-- 
2.11.0

^ permalink raw reply related

* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: John Garry @ 2018-01-03 12:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180102174814.GT25156@tassilo.jf.intel.com>

On 02/01/2018 17:48, Andi Kleen wrote:
>> Can you describe how you autogenerate the JSONs? Do you have some internal
>> proprietary HW file format describing events, with files supplied from HW
>> designer, which you can just translate into a JSON? Would the files support
>> deferencing events to improve scalability?
>
> For Intel JSON is an official format, which is maintained for each CPU.
> It is automatically generated from an internal database
> https://download.01.org/perfmon/
>
> I have some python scripts to convert these Intel JSONs into the perf
> format (which has some additional headers, and is split into
> different categories, and add metrics).

OK, understood.

Unfortunately I could not see such a database being maintained for ARM 
implementors.

>
> They have some Intel specifics, so may not be useful for you.
>
> There's no support for dereference, each CPU gets its own unique file.

Right.

>
> But you could do the a merge simply with the attached script which merges
> two JSON files.

I assume that you're talking about simply merging the micro architecture 
and the platform specific event JSONS at build time.

If yes, this would not work for us:
- the microarchitecture JSON would contain definitions of all events, 
but there is no architectural method to check if they are implemented
- we need to deal with scenario of non-standard event implementations

But I could update the script to deal with this and add to the build 
(Jirka looked to be ok with the same in jevents, albeit a few caveats).

All the best,
John

>
> -Andi
>

^ permalink raw reply

* Applied "spi: sirf: account for const type of of_device_id.data" to the spi tree
From: Mark Brown @ 2018-01-03 12:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1514899688-27844-4-git-send-email-Julia.Lawall@lip6.fr>

The patch

   spi: sirf: account for const type of of_device_id.data

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 9e327ce71f3894e7e6b57f5c15a0dfa5be79f44e Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Tue, 2 Jan 2018 14:27:59 +0100
Subject: [PATCH] spi: sirf: account for const type of of_device_id.data

This driver creates various const structures that it stores in the
data field of an of_device_id array.

Adding const to the declaration of the location that receives the
const value from the data field ensures that the compiler will
continue to check that the value is not modified.  Furthermore, the
const-discarding cast on the extraction from the data field is no
longer needed.

Done using Coccinelle.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-sirf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
index bbb1a275f718..f009d76f96b1 100644
--- a/drivers/spi/spi-sirf.c
+++ b/drivers/spi/spi-sirf.c
@@ -1072,7 +1072,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev)
 	struct sirfsoc_spi *sspi;
 	struct spi_master *master;
 	struct resource *mem_res;
-	struct sirf_spi_comp_data *spi_comp_data;
+	const struct sirf_spi_comp_data *spi_comp_data;
 	int irq;
 	int ret;
 	const struct of_device_id *match;
@@ -1092,7 +1092,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, master);
 	sspi = spi_master_get_devdata(master);
 	sspi->fifo_full_offset = ilog2(sspi->fifo_size);
-	spi_comp_data = (struct sirf_spi_comp_data *)match->data;
+	spi_comp_data = match->data;
 	sspi->regs = spi_comp_data->regs;
 	sspi->type = spi_comp_data->type;
 	sspi->fifo_level_chk_mask = (sspi->fifo_size / 4) - 1;
-- 
2.15.1

^ permalink raw reply related

* [PATCH 05/12] mfd: mtk-audsys: add MediaTek audio subsystem driver
From: Ryder Lee @ 2018-01-03 12:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180102163103.dqxsl4bylqwn6o5b@dell>

On Tue, 2018-01-02 at 16:31 +0000, Lee Jones wrote:
> On Tue, 02 Jan 2018, Ryder Lee wrote:
> 
> > Add a common driver for the top block of the MediaTek audio subsystem.
> > This is a wrapper which manages resources for audio components.
> > 
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>

> > diff --git a/drivers/mfd/mtk-audsys.c b/drivers/mfd/mtk-audsys.c
> > new file mode 100644
> > index 0000000..89399e1
> > --- /dev/null
> > +++ b/drivers/mfd/mtk-audsys.c
> > @@ -0,0 +1,138 @@
> > +/*
> > + * Mediatek audio subsystem core driver
> > + *
> > + *  Copyright (c) 2017 MediaTek Inc.
> > + *
> > + * Author: Ryder Lee <ryder.lee@mediatek.com>
> > + *
> > + * For licencing details see kernel-base/COPYING
> 
> You can't do that.
> 
> Grep for SPDX to see what is expected.

Okay.
> > + *
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/module.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +
> > +#define AUDSYS_MAX_CLK_NUM 3
> 
> When is this not 3?

If other subsystems have different clocks numbers.

> > +struct sys_dev {
> > +	struct device *dev;
> > +	struct regmap *regmap;
> > +	int clk_num;
> > +	struct clk *clks[];
> > +};
> > +
> > +static const struct regmap_config aud_regmap_config = {
> > +	.reg_bits = 32,
> > +	.reg_stride = 4,
> > +	.val_bits = 32,
> > +	.max_register = 0x15e0,
> > +	.cache_type = REGCACHE_NONE,
> > +};
> > +
> > +static int mtk_subsys_enable(struct sys_dev *sys)
> > +{
> > +	struct device *dev = sys->dev;
> 
> I would remove dev and regmap from the sys_dev struct and pass in pdev
> directly into this function.  Then use platform_get_drvdata() as you
> did in .remove().
> 
> > +	struct clk *clk;
> > +	int i, ret;
> > +
> > +	for (i = 0; i < sys->clk_num; i++) {
> > +		clk = of_clk_get(dev->of_node, i);
> > +		if (IS_ERR(clk)) {
> > +			if (PTR_ERR(clk) == -EPROBE_DEFER)
> > +				return -EPROBE_DEFER;
> > +			break;
> > +		}
> > +		sys->clks[i] = clk;
> > +	}
> > +
> > +	for (i = 0; i < sys->clk_num && sys->clks[i]; i++) {
> 
> Why do you need a separate loop for this?
> 
> Just prepare and enable valid clocks in the for() loop above.

Ohh, it's a mistake. Thanks for reminding me.

> > +		ret = clk_prepare_enable(sys->clks[i]);
> > +		if (ret)
> > +			goto err_enable_clks;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_enable_clks:
> > +	while (--i >= 0)
> > +		clk_disable_unprepare(sys->clks[i]);
> > +
> > +	return ret;
> > +}
> > +
> > +static int mtk_subsys_probe(struct platform_device *pdev)
> > +{
> > +	struct sys_dev *sys;
> > +	struct resource *res;
> > +	void __iomem *mmio;
> > +	int num, ret;
> > +
> > +	num = (int)of_device_get_match_data(&pdev->dev);
> > +	if (!num)
> > +		return -EINVAL;
> 
> This is a very rigid method of achieving your aim.  Please find a way
> to make this more dynamic.  You're probably better off counting the
> elements within the property, checking to ensure there aren't more
> than the maximum pre-allocated/allowed clocks, then using the number
> gleaned directly from the Device Tree.

Just in case other MTK subsystems can reuse this driver and set their
own clock numbers in SoC data table, but yes, it's too rigid.

> > +	sys = devm_kzalloc(&pdev->dev, sizeof(*sys) +
> > +			   sizeof(struct clk *) * num, GFP_KERNEL);
> 
> You need to add bracketing here for clarity.

Okay.

> > +	if (!sys)
> > +		return -ENOMEM;
> > +
> > +	sys->clk_num = num;
> > +	sys->dev = &pdev->dev;
> 
> Why are you saving the device pointer?

will remove it.

> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	mmio = devm_ioremap_resource(sys->dev, res);
> > +	if (IS_ERR(mmio))
> > +		return PTR_ERR(mmio);
> > +
> > +	sys->regmap = devm_regmap_init_mmio(sys->dev, mmio,
> > +					    &aud_regmap_config);
> 
> Why are you saving a devm'ed regmap pointer?

We don't really need this 'sys->regmap" in driver, but need to
initialize mmio so that its subnodes can obtain regmap through
dev_get_regmap().

> > +	if (IS_ERR(sys->regmap))
> > +		return PTR_ERR(sys->regmap);
> > +
> > +	platform_set_drvdata(pdev, sys);
> > +
> > +	/* Enable top level clocks */
> > +	ret = mtk_subsys_enable(sys);
> 
> mtk_subsys_enable_clks()

Okay.
> > +	if (ret)
> > +		return ret;
> > +
> > +	return devm_of_platform_populate(sys->dev);
> > +};
> > +
> > +static int mtk_subsys_remove(struct platform_device *pdev)
> > +{
> > +	struct sys_dev *sys = platform_get_drvdata(pdev);
> > +	int i;
> > +
> > +	for (i = sys->clk_num - 1; i >= 0; i--)
> > +		if (sys->clks[i])
> 
> This check is superfluous as the clk subsystem does this for you.
> 
> > +			clk_disable_unprepare(sys->clks[i]);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id of_match_audsys[] = {
> > +	{
> > +	  .compatible = "mediatek,mt2701-audsys-core",
> > +	  .data = (void *)AUDSYS_MAX_CLK_NUM,
> 
> You can remove this line.

Okay
> > +	},
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(platform, of_match_audsys);
> > +
> > +static struct platform_driver audsys_drv = {
> > +	.probe = mtk_subsys_probe,
> > +	.remove	= mtk_subsys_remove,
> > +	.driver = {
> > +		.name = "mediatek-audsys-core",
> > +		.of_match_table = of_match_ptr(of_match_audsys),
> > +	},
> > +};
> > +
> > +builtin_platform_driver(audsys_drv);
> > +
> > +MODULE_DESCRIPTION("Mediatek audio subsystem core driver");
> 
> > +MODULE_LICENSE("GPL");
> 
> <just_checking>
>   Are you sure this is what you want?
> </just_checking>
> 

The reason to add this driver is some MTK subsystem blocks expose more
than a single functionality but register those in different kernel
subsystems (e.g., AUDSYS includes audio components and clock part).

But I think I should just add a property "simple-mfd" in DTS instead of
adding this driver.

Thanks.

^ permalink raw reply

* [PATCH v3 0/3] arm64: dts: r8a779[56]: Add OPPs table for cpu devices
From: Simon Horman @ 2018-01-03 12:41 UTC (permalink / raw)
  To: linux-arm-kernel

These are dependencies for supporting CPUFreq. The remainder of that
work is being posted separately and can be found at:

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/rcar-gen3-cpufreq-v4


Patch 1: Cleanup of DTS, only related as its an apply-time conflict
Patches 2 & 3: Add OPPs

Changes since v2:
* Preserve alphabetical order of sub-nodes of root node
* Do not provide unit name for opps, they have no base address
* Describe clock dependency for all CPU cores

Changes since v1:
* Only provide one operating points node for each operating-points-v2 node
  as per the binding; other nodes were unused and have been removed

A description of steps taken to lightly exercise the same feature for the
r8a7795 the above can be found at the link below. The results are the same
for the r8a7796 with the exception that it has two active CPU cores rather
than four.

http://elinux.org/Tests:R-CAR-GEN3-CPUFreq


Dien Pham (2):
  arm64: dts: renesas: r8a7795: Add OPPs table for cpu devices
  arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices

Simon Horman (1):
  arm64: dts: renesas: r8a7795: move scif node into alphabetical order

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 71 +++++++++++++++++++++++++++++---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 62 ++++++++++++++++++++++++++++
 2 files changed, 128 insertions(+), 5 deletions(-)

-- 
2.11.0

^ permalink raw reply

* [PATCH v3 1/3] arm64: dts: renesas: r8a7795: move scif node into alphabetical order
From: Simon Horman @ 2018-01-03 12:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-1-horms+renesas@verge.net.au>

Move scif node so that sub-nodes of the root node are in
alphabetical order.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index d12df6f2ff09..24e9209ea54e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -165,13 +165,6 @@
 		clock-frequency = <0>;
 	};
 
-	/* External SCIF clock - to be overridden by boards that provide it */
-	scif_clk: scif {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <0>;
-	};
-
 	/* External PCIe clock - can be overridden by the board */
 	pcie_bus_clk: pcie_bus {
 		compatible = "fixed-clock";
@@ -208,6 +201,13 @@
 		method = "smc";
 	};
 
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+	};
+
 	soc: soc {
 		compatible = "simple-bus";
 		interrupt-parent = <&gic>;
-- 
2.11.0

^ permalink raw reply related

* [PATCH v3 2/3] arm64: dts: renesas: r8a7795: Add OPPs table for cpu devices
From: Simon Horman @ 2018-01-03 12:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-1-horms+renesas@verge.net.au>

From: Dien Pham <dien.pham.ry@rvc.renesas.com>

Define OOP tables for all CPUs.
This allows CPUFreq to function.

Based in part on work by Hien Dang.

Signed-off-by: Dien Pham <dien.pham.ry@rvc.renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3 [Simon Horman]
- Preserve alphabetical order of sub-nodes of root node
- Do not provide unit name for opps, they have no base address
- Describe clock dependency for all CPU cores

v2 [Simon Horman]
- Only provide one operating points node for each operating-points-v2 node
  as per the binding; other nodes were unused and have been removed

v1 [Simon Horman]
- consolidated several patches into one

v0 [Dien Pham]
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 61 ++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 24e9209ea54e..1485e6a8e112 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -41,6 +41,8 @@
 			power-domains = <&sysc R8A7795_PD_CA57_CPU0>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a57_1: cpu at 1 {
@@ -50,6 +52,8 @@
 			power-domains = <&sysc R8A7795_PD_CA57_CPU1>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a57_2: cpu at 2 {
@@ -59,6 +63,8 @@
 			power-domains = <&sysc R8A7795_PD_CA57_CPU2>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a57_3: cpu at 3 {
@@ -68,6 +74,8 @@
 			power-domains = <&sysc R8A7795_PD_CA57_CPU3>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a53_0: cpu at 100 {
@@ -77,6 +85,8 @@
 			power-domains = <&sysc R8A7795_PD_CA53_CPU0>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_1: cpu at 101 {
@@ -86,6 +96,8 @@
 			power-domains = <&sysc R8A7795_PD_CA53_CPU1>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_2: cpu at 102 {
@@ -95,6 +107,8 @@
 			power-domains = <&sysc R8A7795_PD_CA53_CPU2>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_3: cpu at 103 {
@@ -104,6 +118,8 @@
 			power-domains = <&sysc R8A7795_PD_CA53_CPU3>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7795_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		L2_CA57: cache-controller-0 {
@@ -165,6 +181,51 @@
 		clock-frequency = <0>;
 	};
 
+	cluster0_opp: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <830000>;
+			clock-latency-ns = <300000>;
+		};
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <830000>;
+			clock-latency-ns = <300000>;
+		};
+		opp-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-microvolt = <830000>;
+			clock-latency-ns = <300000>;
+			opp-suspend;
+		};
+		opp-1600000000 {
+			opp-hz = /bits/ 64 <1600000000>;
+			opp-microvolt = <900000>;
+			clock-latency-ns = <300000>;
+			turbo-mode;
+		};
+		opp-1700000000 {
+			opp-hz = /bits/ 64 <1700000000>;
+			opp-microvolt = <960000>;
+			clock-latency-ns = <300000>;
+			turbo-mode;
+		};
+	};
+
+	cluster1_opp: opp_table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <820000>;
+			clock-latency-ns = <300000>;
+		};
+	};
+
 	/* External PCIe clock - can be overridden by the board */
 	pcie_bus_clk: pcie_bus {
 		compatible = "fixed-clock";
-- 
2.11.0

^ permalink raw reply related

* [PATCH v3 3/3] arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices
From: Simon Horman @ 2018-01-03 12:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-1-horms+renesas@verge.net.au>

From: Dien Pham <dien.pham.ry@rvc.renesas.com>

Define OOP tables for all CPUs.
This allows CPUFreq to function.

Based in part on work by Hien Dang.

Signed-off-by: Dien Pham <dien.pham.ry@rvc.renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3 [Simon Horman]
* Do not give nodes a unit name, they have no base address
* Preserve alphabetical order of sub-nodes of root node
* Describe clock dependency for all CPU cores

v2 [Simon Horman]
- Only provide one operating points node for each operating-points-v2 node
  as per the binding; other nodes were unused and have been removed

v1 [Simon Horman]
- consolidated several patches into one

v0 [Dien Pham]
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 62 ++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c5192d513d7d..e06bde6e2853 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -71,6 +71,8 @@
 			power-domains = <&sysc R8A7796_PD_CA57_CPU0>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a57_1: cpu at 1 {
@@ -80,6 +82,8 @@
 			power-domains = <&sysc R8A7796_PD_CA57_CPU1>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z>;
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		a53_0: cpu at 100 {
@@ -89,6 +93,8 @@
 			power-domains = <&sysc R8A7796_PD_CA53_CPU0>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_1: cpu at 101 {
@@ -98,6 +104,8 @@
 			power-domains = <&sysc R8A7796_PD_CA53_CPU1>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_2: cpu at 102 {
@@ -107,6 +115,8 @@
 			power-domains = <&sysc R8A7796_PD_CA53_CPU2>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		a53_3: cpu at 103 {
@@ -116,6 +126,8 @@
 			power-domains = <&sysc R8A7796_PD_CA53_CPU3>;
 			next-level-cache = <&L2_CA53>;
 			enable-method = "psci";
+			clocks =<&cpg CPG_CORE R8A7796_CLK_Z2>;
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		L2_CA57: cache-controller-0 {
@@ -147,6 +159,56 @@
 		clock-frequency = <0>;
 	};
 
+	cluster0_opp: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <820000>;
+			clock-latency-ns = <300000>;
+		};
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <820000>;
+			clock-latency-ns = <300000>;
+		};
+		opp-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-microvolt = <820000>;
+			clock-latency-ns = <300000>;
+		};
+		opp-1600000000 {
+			opp-hz = /bits/ 64 <1600000000>;
+			opp-microvolt = <900000>;
+			clock-latency-ns = <300000>;
+			turbo-mode;
+		};
+		opp-1700000000 {
+			opp-hz = /bits/ 64 <1700000000>;
+			opp-microvolt = <900000>;
+			clock-latency-ns = <300000>;
+			turbo-mode;
+		};
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <960000>;
+			clock-latency-ns = <300000>;
+			turbo-mode;
+		};
+	};
+
+	cluster1_opp: opp_table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <820000>;
+			clock-latency-ns = <300000>;
+		};
+	};
+
 	/* External PCIe clock - can be overridden by the board */
 	pcie_bus_clk: pcie_bus {
 		compatible = "fixed-clock";
-- 
2.11.0

^ permalink raw reply related

* [PATCH V4 01/26] alpha/PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2018-01-03 12:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1513661883-28662-2-git-send-email-okaya@codeaurora.org>

On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
> 
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  arch/alpha/kernel/pci.c          | 2 +-
>  arch/alpha/kernel/sys_nautilus.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
> index 87da005..2e86ebb 100644
> --- a/arch/alpha/kernel/pci.c
> +++ b/arch/alpha/kernel/pci.c
> @@ -425,7 +425,7 @@ struct resource * __init
>  		if (bus == 0 && dfn == 0) {
>  			hose = pci_isa_hose;
>  		} else {
> -			dev = pci_get_bus_and_slot(bus, dfn);
> +			dev = pci_get_domain_bus_and_slot(0, bus, dfn);
>  			if (!dev)
>  				return -ENODEV;
>  			hose = dev->sysdata;
> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index 239dc0e..ff4f54b 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -237,7 +237,7 @@
>  	bus = hose->bus = bridge->bus;
>  	pcibios_claim_one_bus(bus);
>  
> -	irongate = pci_get_bus_and_slot(0, 0);
> +	irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
>  	bus->self = irongate;
>  	bus->resource[0] = &irongate_io;
>  	bus->resource[1] = &irongate_mem;
> 

Any feedback here? most of the remaining patches have the ACK except these.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2018-01-03 12:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1513661883-28662-6-git-send-email-okaya@codeaurora.org>

On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
> 
> Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
> and extract the domain number from struct pci_dev.
> 
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  drivers/char/agp/nvidia-agp.c | 12 +++++++++---
>  drivers/char/agp/sworks-agp.c |  3 ++-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c
> index 828b344..623205b 100644
> --- a/drivers/char/agp/nvidia-agp.c
> +++ b/drivers/char/agp/nvidia-agp.c
> @@ -340,11 +340,17 @@ static int agp_nvidia_probe(struct pci_dev *pdev,
>  	u8 cap_ptr;
>  
>  	nvidia_private.dev_1 =
> -		pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(0, 1));
> +		pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> +					    (unsigned int)pdev->bus->number,
> +					    PCI_DEVFN(0, 1));
>  	nvidia_private.dev_2 =
> -		pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(0, 2));
> +		pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> +					    (unsigned int)pdev->bus->number,
> +					    PCI_DEVFN(0, 2));
>  	nvidia_private.dev_3 =
> -		pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(30, 0));
> +		pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> +					    (unsigned int)pdev->bus->number,
> +					    PCI_DEVFN(30, 0));
>  
>  	if (!nvidia_private.dev_1 || !nvidia_private.dev_2 || !nvidia_private.dev_3) {
>  		printk(KERN_INFO PFX "Detected an NVIDIA nForce/nForce2 "
> diff --git a/drivers/char/agp/sworks-agp.c b/drivers/char/agp/sworks-agp.c
> index 03be4ac..4dbdd3b 100644
> --- a/drivers/char/agp/sworks-agp.c
> +++ b/drivers/char/agp/sworks-agp.c
> @@ -474,7 +474,8 @@ static int agp_serverworks_probe(struct pci_dev *pdev,
>  	}
>  
>  	/* Everything is on func 1 here so we are hardcoding function one */
> -	bridge_dev = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
> +	bridge_dev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> +			(unsigned int)pdev->bus->number,
>  			PCI_DEVFN(0, 1));
>  	if (!bridge_dev) {
>  		dev_info(&pdev->dev, "can't find secondary device\n");
> 

Any feedback here? most of the remaining patches have the ACK except these.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Geert Uytterhoeven @ 2018-01-03 12:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-3-horms+renesas@verge.net.au>

Hi Simon,

On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v4 [Simon Horman]
> * Rebase
> * Use __ffs as FIELD_{GET,PREP} don't not work with non-constant masks
> * Use correct mask in cpg_z_clk_recalc_rate()

Thanks for the update!

> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> @@ -63,7 +63,7 @@ static void cpg_simple_notifier_register(struct raw_notifier_head *notifiers,
>  }
>
>  /*
> - * Z Clock
> + * Z Clock & Z2 Clock
>   *
>   * Traits of this clock:
>   * prepare - clk_prepare only ensures that parents are prepared
> @@ -75,11 +75,13 @@ static void cpg_simple_notifier_register(struct raw_notifier_head *notifiers,
>  #define CPG_FRQCRB_KICK                        BIT(31)
>  #define CPG_FRQCRC                     0x000000e0
>  #define CPG_FRQCRC_ZFC_MASK            GENMASK(12, 8)
> +#define CPG_FRQCRC_Z2FC_MASK           GENMASK(4, 0)
>
>  struct cpg_z_clk {
>         struct clk_hw hw;
>         void __iomem *reg;
>         void __iomem *kick_reg;
> +       unsigned long mask;
>  };
>
>  #define to_z_clk(_hw)  container_of(_hw, struct cpg_z_clk, hw)
> @@ -89,8 +91,10 @@ static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
>  {
>         struct cpg_z_clk *zclk = to_z_clk(hw);
>         unsigned int mult;
> +       u32 val;
>
> -       mult = 32 - FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
> +       val = clk_readl(zclk->reg) & zclk->mask;
> +       mult = 32 - (val >> (__ffs(zclk->mask) - 1));

Shouldn't that be

        mult = 32 - (val >> __ffs(zclk->mask));

(same below)?

__ffs() returns 0..31, so you will shift right by 7 (Z) or -1 (Z2)?

As the CPG/MSSR driver now has suspend/resume support, do we need
a notifier to restore the Z or Z2 registers? Or is that handled automatically
by cpufreq during system resume, for both the primary and the secondary
CPU cores?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-03 12:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPv3WKcM8WWvh64A=FTtuWkEr6V_QSKjBpNpWnMpp_P=cMU9sw@mail.gmail.com>

> I already agreed with 'reg' being awkward in the later emails.
> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?

Also, how do you specify which MDIO bus the PHY is on. To fully
specify a PHY, you need both bits of information.

In DT, the phy-handle phandle can point to any PHY anywhere in the
system. This is particularly important when a Ethernet device has two
MDIO busses.

     Andrew

^ permalink raw reply

* [PATCH V4 06/26] edd: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2018-01-03 12:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1513661883-28662-7-git-send-email-okaya@codeaurora.org>

On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
> 
> Domain number is not available in struct edd_info. Hard-coding the domain
> number as 0.
> 
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  drivers/firmware/edd.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
> index e229576..60a8f13 100644
> --- a/drivers/firmware/edd.c
> +++ b/drivers/firmware/edd.c
> @@ -669,10 +669,10 @@ static void edd_release(struct kobject * kobj)
>  	struct edd_info *info = edd_dev_get_info(edev);
>  
>  	if (edd_dev_is_type(edev, "PCI") || edd_dev_is_type(edev, "XPRS")) {
> -		return pci_get_bus_and_slot(info->params.interface_path.pci.bus,
> -				     PCI_DEVFN(info->params.interface_path.pci.slot,
> -					       info->params.interface_path.pci.
> -					       function));
> +		return pci_get_domain_bus_and_slot(0,
> +				info->params.interface_path.pci.bus,
> +				PCI_DEVFN(info->params.interface_path.pci.slot,
> +				info->params.interface_path.pci.function));
>  	}
>  	return NULL;
>  }
> 

Any feedback here? most of the remaining patches have the ACK except these.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH] arm64: dirty memory check, enable soft dirty for arm64
From: Steve Capper @ 2018-01-03 13:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180102181910.gxiqaehznpw2hc6u@armageddon.cambridge.arm.com>

Hi Catalin,

On Tue, Jan 02, 2018 at 06:19:10PM +0000, Catalin Marinas wrote:
> Hi Bin,
> 
> On Thu, Nov 30, 2017 at 12:14:09AM -0800, Bin Lu wrote:
> >     pmd_dirty and pmd_mkclean for THP page MADV_FREE also were
> >     supported in this patch.
> [...]
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -306,6 +306,28 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
> >  	return __pgprot(pgprot_val(prot) & ~PTE_TABLE_BIT);
> >  }
> >  
> > +#ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY
> > +static inline bool pte_soft_dirty(pte_t pte)
> > +{
> > +        return pte_sw_dirty(pte);
> > +}
> > +
> > +static inline pte_t pte_mksoft_dirty(pte_t pte)
> > +{
> > +        return pte_mkdirty(pte);
> > +}
> > +
> > +static inline pte_t pte_clear_soft_dirty(pte_t pte)
> > +{
> > +        return pte_mkclean(pte);
> > +}
> > +
> > +#define pmd_soft_dirty(pmd)    pte_soft_dirty(pmd_pte(pmd))
> > +#define pmd_mksoft_dirty(pmd)  pte_pmd(pte_mksoft_dirty(pmd_pte(pmd)))
> > +#define pmd_clear_soft_dirty(pmd) pte_pmd(pte_clear_soft_dirty(pmd_pte(pmd)))
> 
> IIUC, a pmd_mkclean() would result in a pte_soft_dirty() == false. Is
> this the expected behaviour with MADV_FREE? The x86 code sets both
> _PAGE_DIRTY and _PAGE_SOFT_DIRTY in pmd_mkdirty() but only clears
> _PAGE_DIRTY in pmd_mkclean().
> 

For MADV_FREE, my understanding is that userspace hints to the memory
manager that pages are no longer needed and if no subsequent
modifications are made to the page then the kernel can free the pages
(and swap in a zero page should userspace attempt to read back the page
after it's been freed).

We would get a divergence in behaviour between arm64 and x86 when a
userspace program calls MADV_FREE on a soft dirty page, and where the
memory manager has not yet freed it.

So on x86 the page would be flagged as soft dirty and on arm64 this
would not be soft dirty.  I originally thought that this would be okay
as userspace has flagged the page as no longer needed. Having had
another big think about it though, I think we'd have one potential
problem with the following course of events:

 * CRIU dumps out page A from running process,
 * process subsequently modifies page A -> marked as soft dirty,
 * process calls MADV_FREE, page A no longer soft dirty,
 * CRIU does not pick up on the changes made to page A, so the other end
   gets an old page restored.

Apologies for missing this before, I neglected to make the distinction
between stale data and dropped data (userspace knows about dropped data
because the page comes back in as zeros).

The arm64 pte_dirty() checks for software and hardware dirty, thus our
pte_mkclean() should clear both states lest MADV_FREE would result in no
pages being swapped out under memory pressure.

Adding an extra dirty bit would fix this (but then we'd have effectively
three dirty bits for ptes), it is not clear to me whether or not the
HW/SW dirty bit logic could be tweaked for arm64 to give us behaviour
parity with x86.

Anyway some more thought required :-).

Cheers,
-- 
Steve

^ permalink raw reply

* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 13:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124720.GG15036@lunn.ch>

Hi Andrew,

2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> I already agreed with 'reg' being awkward in the later emails.
>> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>
> Also, how do you specify which MDIO bus the PHY is on. To fully
> specify a PHY, you need both bits of information.
>
> In DT, the phy-handle phandle can point to any PHY anywhere in the
> system. This is particularly important when a Ethernet device has two
> MDIO busses.
>

For now, my local MDIO bus description is pretty DT-like, i.e. master
bus with children PHYs:
        Device (MDIO)
        {
            Name (_HID, "MRVL0100")                             //
_HID: Hardware ID
            Name (_UID, 0x00)                                   //
_UID: Unique ID
            Name (_CRS, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite,
                    0xf212a200,                                 // Address Base
                    0x00000010,                                 //
Address Length
                    )
            })
            Device (GPHY)
            {
              Name (_ADR, 0x0)
            }
        }

        Device (XSMI)
        {
            Name (_HID, "MRVL0101")                             //
_HID: Hardware ID
            Name (_UID, 0x00)                                   //
_UID: Unique ID
            Name (_CRS, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite,
                    0xf212a600,                                 // Address Base
                    0x00000010,                                 //
Address Length
                    )
            })
            Device (PHY0)
            {
              Name (_ADR, 0x0)
              Name (_CID, "ethernet-phy-ieee802.3-c45")
            }
            Device (PHY8)
            {
              Name (_ADR, 0x8)
              Name (_CID, "ethernet-phy-ieee802.3-c45")
            }
        }

Which is referenced in the port's node:

Package () { "phy", Package (){\_SB.XSMI.PHY0}},

I'm studying an alternatives with graphs, as suggested by Tomasz
Nowicki, but to me above is pretty natural and not complicated.

Best regards,
Marcin

^ permalink raw reply

* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-03 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPv3WKfZN+=9wFJ5ct+8nttd=bikaZ=Ei741pyTVXjQz2zq2dg@mail.gmail.com>

On Wed, Jan 03, 2018 at 02:13:09PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
> 
> 2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> >> I already agreed with 'reg' being awkward in the later emails.
> >> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> >
> > Also, how do you specify which MDIO bus the PHY is on. To fully
> > specify a PHY, you need both bits of information.
> >
> > In DT, the phy-handle phandle can point to any PHY anywhere in the
> > system. This is particularly important when a Ethernet device has two
> > MDIO busses.
> >
> 
> For now, my local MDIO bus description is pretty DT-like, i.e. master
> bus with children PHYs:
>         Device (MDIO)
>         {
>             Name (_HID, "MRVL0100")                             //
> _HID: Hardware ID
>             Name (_UID, 0x00)                                   //
> _UID: Unique ID
>             Name (_CRS, ResourceTemplate ()
>             {
>                 Memory32Fixed (ReadWrite,
>                     0xf212a200,                                 // Address Base
>                     0x00000010,                                 //
> Address Length
>                     )
>             })
>             Device (GPHY)
>             {
>               Name (_ADR, 0x0)
>             }
>         }
> 
>         Device (XSMI)
>         {
>             Name (_HID, "MRVL0101")                             //
> _HID: Hardware ID
>             Name (_UID, 0x00)                                   //
> _UID: Unique ID
>             Name (_CRS, ResourceTemplate ()
>             {
>                 Memory32Fixed (ReadWrite,
>                     0xf212a600,                                 // Address Base
>                     0x00000010,                                 //
> Address Length
>                     )
>             })
>             Device (PHY0)
>             {
>               Name (_ADR, 0x0)
>               Name (_CID, "ethernet-phy-ieee802.3-c45")
>             }
>             Device (PHY8)
>             {
>               Name (_ADR, 0x8)
>               Name (_CID, "ethernet-phy-ieee802.3-c45")
>             }
>         }
> 
> Which is referenced in the port's node:
> 
> Package () { "phy", Package (){\_SB.XSMI.PHY0}},

Hi Marcin

This reference looks good, giving both the bus and the PHY on the bus.

I assume you can use references like this within the Device (PHY8)
node? You need to be able to reference a GPIO used for resetting the
PHY. And you also need to reference a GPIO at the Device (MDIO) level
for resetting all the PHYs on the MDIO bus.

    Andrew

^ permalink raw reply

* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 13:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103133341.GJ15036@lunn.ch>

2018-01-03 14:33 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Jan 03, 2018 at 02:13:09PM +0100, Marcin Wojtas wrote:
>> Hi Andrew,
>>
>> 2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> >> I already agreed with 'reg' being awkward in the later emails.
>> >> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>> >
>> > Also, how do you specify which MDIO bus the PHY is on. To fully
>> > specify a PHY, you need both bits of information.
>> >
>> > In DT, the phy-handle phandle can point to any PHY anywhere in the
>> > system. This is particularly important when a Ethernet device has two
>> > MDIO busses.
>> >
>>
>> For now, my local MDIO bus description is pretty DT-like, i.e. master
>> bus with children PHYs:
>>         Device (MDIO)
>>         {
>>             Name (_HID, "MRVL0100")                             //
>> _HID: Hardware ID
>>             Name (_UID, 0x00)                                   //
>> _UID: Unique ID
>>             Name (_CRS, ResourceTemplate ()
>>             {
>>                 Memory32Fixed (ReadWrite,
>>                     0xf212a200,                                 // Address Base
>>                     0x00000010,                                 //
>> Address Length
>>                     )
>>             })
>>             Device (GPHY)
>>             {
>>               Name (_ADR, 0x0)
>>             }
>>         }
>>
>>         Device (XSMI)
>>         {
>>             Name (_HID, "MRVL0101")                             //
>> _HID: Hardware ID
>>             Name (_UID, 0x00)                                   //
>> _UID: Unique ID
>>             Name (_CRS, ResourceTemplate ()
>>             {
>>                 Memory32Fixed (ReadWrite,
>>                     0xf212a600,                                 // Address Base
>>                     0x00000010,                                 //
>> Address Length
>>                     )
>>             })
>>             Device (PHY0)
>>             {
>>               Name (_ADR, 0x0)
>>               Name (_CID, "ethernet-phy-ieee802.3-c45")
>>             }
>>             Device (PHY8)
>>             {
>>               Name (_ADR, 0x8)
>>               Name (_CID, "ethernet-phy-ieee802.3-c45")
>>             }
>>         }
>>
>> Which is referenced in the port's node:
>>
>> Package () { "phy", Package (){\_SB.XSMI.PHY0}},
>
> Hi Marcin
>
> This reference looks good, giving both the bus and the PHY on the bus.
>
> I assume you can use references like this within the Device (PHY8)
> node?

Yes.

> You need to be able to reference a GPIO used for resetting the
> PHY. And you also need to reference a GPIO at the Device (MDIO) level
> for resetting all the PHYs on the MDIO bus.
>

Yes, for full support of PHYs the GPIO must be supported, as well as
the PHY's IRQs.

Best regards,
Marcin

^ permalink raw reply

* [kernel-hardening] [PATCH] arm: kernel: implement fast refcount checking
From: Jinbum Park @ 2018-01-03 13:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9j7YmF5UUjs0ZAVbws1jEuuoUbCwo68QgD7eAv7Uh16g@mail.gmail.com>

>> This is a nice result. However, without any insight into the presence
>> of actual refcount hot spots, it is not obvious that we need this
>> patch. This is the reason we ended up enabling CONFIG_REFCOUNT_FULL
>> for arm64. I will let others comment on whether we want this patch in
>> the first place,

Dear Ard, Dave,

I wanna hear some comment on above point.
Is CONFIG_REFCOUNT_FULL much better for arm?
If it is, I don't need to prepare v2 patch. (then, just needed to add
"select REFCOUNT_FULL")



2017-12-21 18:20 GMT+09:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> (add Dave)
>
> On 21 December 2017 at 09:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 21 December 2017 at 07:50, Jinbum Park <jinb.park7@gmail.com> wrote:
>>> This adds support to arm for fast refcount checking.
>>> It's heavily based on x86, arm64 implementation.
>>> (7a46ec0e2f48 ("locking/refcounts,
>>> x86/asm: Implement fast refcount overflow protection)
>>>
>>> This doesn't support under-ARMv6, thumb2-kernel yet.
>>>
>>> Test result of this patch is as follows.
>>>
>>> 1. LKDTM test
>>>
>>> - All REFCOUNT_* tests in LKDTM have passed.
>>>
>>> 2. Performance test
>>>
>>> - Cortex-A7, Quad Core, 450 MHz
>>> - Case with CONFIG_ARCH_HAS_REFCOUNT,
>>>
>>> perf stat -B -- echo ATOMIC_TIMING \
>>>                 >/sys/kernel/debug/provoke-crash/DIRECT
>>> 204.364247057 seconds time elapsed
>>>
>>> perf stat -B -- echo REFCOUNT_TIMING \
>>>                 >/sys/kernel/debug/provoke-crash/DIRECT
>>> 208.006062212 seconds time elapsed
>>>
>>> - Case with CONFIG_REFCOUNT_FULL,
>>>
>>> perf stat -B -- echo REFCOUNT_TIMING \
>>>                 >/sys/kernel/debug/provoke-crash/DIRECT
>>> 369.256523453 seconds time elapsed
>>>
>>
>> This is a nice result. However, without any insight into the presence
>> of actual refcount hot spots, it is not obvious that we need this
>> patch. This is the reason we ended up enabling CONFIG_REFCOUNT_FULL
>> for arm64. I will let others comment on whether we want this patch in
>> the first place, and I will give some feedback on the implementation
>> below.
>>
>>> Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
>>> ---
>>>  arch/arm/Kconfig                |  1 +
>>>  arch/arm/include/asm/atomic.h   | 82 +++++++++++++++++++++++++++++++++++++++++
>>>  arch/arm/include/asm/refcount.h | 55 +++++++++++++++++++++++++++
>>>  arch/arm/kernel/traps.c         | 44 ++++++++++++++++++++++
>>>  4 files changed, 182 insertions(+)
>>>  create mode 100644 arch/arm/include/asm/refcount.h
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 3ea00d6..e07b986 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -7,6 +7,7 @@ config ARM
>>>         select ARCH_HAS_DEBUG_VIRTUAL
>>>         select ARCH_HAS_DEVMEM_IS_ALLOWED
>>>         select ARCH_HAS_ELF_RANDOMIZE
>>> +       select ARCH_HAS_REFCOUNT if __LINUX_ARM_ARCH__ >= 6 && (!THUMB2_KERNEL)
>>>         select ARCH_HAS_SET_MEMORY
>>>         select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
>>>         select ARCH_HAS_STRICT_MODULE_RWX if MMU
>>> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
>>> index 66d0e21..b203396 100644
>>> --- a/arch/arm/include/asm/atomic.h
>>> +++ b/arch/arm/include/asm/atomic.h
>>> @@ -17,6 +17,7 @@
>>>  #include <linux/irqflags.h>
>>>  #include <asm/barrier.h>
>>>  #include <asm/cmpxchg.h>
>>> +#include <asm/opcodes.h>
>>>
>>>  #define ATOMIC_INIT(i) { (i) }
>>>
>>> @@ -32,6 +33,87 @@
>>>
>>>  #if __LINUX_ARM_ARCH__ >= 6
>>>
>>> +#ifdef CONFIG_ARCH_HAS_REFCOUNT
>>> +
>>> +#define REFCOUNT_ARM_BKPT_INSTR 0xfff001fc
>>> +
>>> +/*
>>> + * 1) encode call site that detect overflow in dummy b instruction.
>>> + * 2) overflow handler can decode dummy b, and get call site.
>>> + * 3) "(call site + 4) == strex" is always true.
>>> + * 4) the handler can get counter address via decoding strex.
>>> + */
>>> +#define REFCOUNT_TRIGGER_BKPT \
>>> +       __inst_arm(REFCOUNT_ARM_BKPT_INSTR) \
>>> +"      b       22b\n"
>>
>> In my arm64 implementation, I used a cbz instruction so I could encode
>> both a register number and a relative offset easily. In your case, you
>> only need to encode the offset, so it is much better to use '.long 22b
>> - .' instead.
>>
>>> +
>>> +/* If bkpt is triggered, skip strex routines after handling overflow */
>>> +#define REFCOUNT_CHECK_TAIL \
>>> +"      strex   %1, %0, [%3]\n" \
>>> +"      teq     %1, #0\n" \
>>> +"      bne     1b\n" \
>>> +"      .subsection     1\n" \
>>> +"33:\n" \
>>> +       REFCOUNT_TRIGGER_BKPT \
>>> +"      .previous\n"
>>> +
>>> +#define REFCOUNT_POST_CHECK_NEG \
>>> +"22:   bmi       33f\n" \
>>
>> It may be better to put the label on the 'strex' instruction directly,
>> to make things less confusing.
>>
>>> +       REFCOUNT_CHECK_TAIL
>>> +
>>> +#define REFCOUNT_POST_CHECK_NEG_OR_ZERO \
>>> +"      beq     33f\n" \
>>> +       REFCOUNT_POST_CHECK_NEG
>>> +
>>> +#define REFCOUNT_SMP_MB smp_mb()
>>> +#define REFCOUNT_SMP_NONE_MB
>>> +
>>> +#define REFCOUNT_OP(op, c_op, asm_op, post, mb) \
>>> +static inline int __refcount_##op(int i, atomic_t *v) \
>>> +{ \
>>> +       unsigned long tmp; \
>>> +       int result; \
>>> +\
>>> +       REFCOUNT_SMP_ ## mb; \
>>> +       prefetchw(&v->counter); \
>>> +       __asm__ __volatile__("@ __refcount_" #op "\n" \
>>> +"1:    ldrex   %0, [%3]\n" \
>>> +"      " #asm_op "     %0, %0, %4\n" \
>>> +       REFCOUNT_POST_CHECK_ ## post \
>>> +       : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter) \
>>> +       : "r" (&v->counter), "Ir" (i) \
>>> +       : "cc"); \
>>> +\
>>> +       REFCOUNT_SMP_ ## mb; \
>>> +       return result; \
>>> +} \
>>> +
>>> +REFCOUNT_OP(add_lt, +=, adds, NEG_OR_ZERO, NONE_MB);
>>> +REFCOUNT_OP(sub_lt, -=, subs, NEG, MB);
>>> +REFCOUNT_OP(sub_le, -=, subs, NEG_OR_ZERO, NONE_MB);
>>> +
>>> +static inline int __refcount_add_not_zero(int i, atomic_t *v)
>>> +{
>>> +       unsigned long tmp;
>>> +       int result;
>>> +
>>> +       prefetchw(&v->counter);
>>> +       __asm__ __volatile__("@ __refcount_add_not_zero\n"
>>> +"1:    ldrex   %0, [%3]\n"
>>> +"      teq             %0, #0\n"
>>> +"      beq             2f\n"
>>> +"      adds    %0, %0, %4\n"
>>> +       REFCOUNT_POST_CHECK_NEG
>>> +"2:"
>>> +       : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
>>> +       : "r" (&v->counter), "Ir" (i)
>>> +       : "cc");
>>> +
>>> +       return result;
>>> +}
>>> +
>>> +#endif /* CONFIG_ARCH_HAS_REFCOUNT */
>>> +
>>>  /*
>>>   * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
>>>   * store exclusive to ensure that these are atomic.  We may loop
>>> diff --git a/arch/arm/include/asm/refcount.h b/arch/arm/include/asm/refcount.h
>>> new file mode 100644
>>> index 0000000..300a2d5
>>> --- /dev/null
>>> +++ b/arch/arm/include/asm/refcount.h
>>> @@ -0,0 +1,55 @@
>>> +/*
>>> + * arm-specific implementation of refcount_t. Based on x86 version and
>>> + * PAX_REFCOUNT from PaX/grsecurity.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#ifndef __ASM_REFCOUNT_H
>>> +#define __ASM_REFCOUNT_H
>>> +
>>> +#include <linux/refcount.h>
>>> +
>>> +#include <asm/atomic.h>
>>> +#include <asm/uaccess.h>
>>> +
>>> +static __always_inline void refcount_add(int i, refcount_t *r)
>>> +{
>>> +       __refcount_add_lt(i, &r->refs);
>>> +}
>>> +
>>> +static __always_inline void refcount_inc(refcount_t *r)
>>> +{
>>> +       __refcount_add_lt(1, &r->refs);
>>> +}
>>> +
>>> +static __always_inline void refcount_dec(refcount_t *r)
>>> +{
>>> +       __refcount_sub_le(1, &r->refs);
>>> +}
>>> +
>>> +static __always_inline __must_check bool refcount_sub_and_test(unsigned int i,
>>> +                                                               refcount_t *r)
>>> +{
>>> +       return __refcount_sub_lt(i, &r->refs) == 0;
>>> +}
>>> +
>>> +static __always_inline __must_check bool refcount_dec_and_test(refcount_t *r)
>>> +{
>>> +       return __refcount_sub_lt(1, &r->refs) == 0;
>>> +}
>>> +
>>> +static __always_inline __must_check bool refcount_add_not_zero(unsigned int i,
>>> +                                                               refcount_t *r)
>>> +{
>>> +       return __refcount_add_not_zero(i, &r->refs) != 0;
>>> +}
>>> +
>>> +static __always_inline __must_check bool refcount_inc_not_zero(refcount_t *r)
>>> +{
>>> +       return __refcount_add_not_zero(1, &r->refs) != 0;
>>> +}
>>> +
>>> +#endif
>>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>>> index 5cf0488..a309215 100644
>>> --- a/arch/arm/kernel/traps.c
>>> +++ b/arch/arm/kernel/traps.c
>>> @@ -795,8 +795,52 @@ void abort(void)
>>>  }
>>>  EXPORT_SYMBOL(abort);
>>>
>>> +#ifdef CONFIG_ARCH_HAS_REFCOUNT
>>> +
>>> +static int refcount_overflow_handler(struct pt_regs *regs, unsigned int instr)
>>> +{
>>> +       u32 dummy_b = le32_to_cpup((__le32 *)(regs->ARM_pc + 4));
>>> +       u32 strex;
>>> +       u32 rt;
>>> +       bool zero = regs->ARM_cpsr & PSR_Z_BIT;
>>> +
>>> +       /* point pc to the branch instruction that detected the overflow */
>>> +       regs->ARM_pc += 4 + (((s32)dummy_b << 8) >> 6) + 8;
>>> +
>>
>> This would become something like
>>
>> s32 offset = *(s32 *)(regs->ARM_pc + 4);
>>
>> /* point pc to the strex instruction that will overflow the refcount */
>> regs->ARM_pc += offset + 4;
>>
>>
>>> +       /* decode strex to set refcount */
>>> +       strex = le32_to_cpup((__le32 *)(regs->ARM_pc + 4));
>>> +       rt = (strex << 12) >> 28;
>>> +
>>
>> Don't we have better ways to decode an instruction? Also, could you
>> add a Thumb2 variant here? (and for the breakpoint instruction)
>>
>>
>>> +       /* unconditionally saturate the refcount */
>>> +       *(int *)regs->uregs[rt] = INT_MIN / 2;
>>> +
>>> +       /* report error */
>>> +       refcount_error_report(regs, zero ? "hit zero" : "overflow");
>>> +
>>> +       /* advance pc and proceed, skip "strex" routine */
>>> +       regs->ARM_pc += 16;
>>
>> Please use a macro here to clarify that you are skipping the remaining
>> instructions in REFCOUNT_CHECK_TAIL
>>
>>> +       return 0;
>>> +}
>>> +
>>> +static struct undef_hook refcount_break_hook = {
>>> +       .instr_mask     = 0xffffffff,
>>> +       .instr_val      = REFCOUNT_ARM_BKPT_INSTR,
>>> +       .cpsr_mask      = 0,
>>> +       .cpsr_val       = 0,
>>> +       .fn             = refcount_overflow_handler,
>>> +};
>>> +
>>> +#define register_refcount_break_hook() register_undef_hook(&refcount_break_hook)
>>> +
>>> +#else /* !CONFIG_ARCH_HAS_REFCOUNT */
>>> +
>>> +#define register_refcount_break_hook()
>>> +
>>> +#endif /* CONFIG_ARCH_HAS_REFCOUNT */
>>> +
>>>  void __init trap_init(void)
>>>  {
>>> +       register_refcount_break_hook();
>>>         return;
>>>  }
>>>
>>> --
>>> 1.9.1
>>>

^ permalink raw reply

* Vibrations, audio, charging, radio on N9/N950
From: Pavel Machek @ 2018-01-03 13:56 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

Sebasian, you submitted patch to enable vibrations on N950. I am
trying to do the same now on N9... I guess I enabled the dts, but
.. how do I actually ask for vibrations? /dev/input/eventX does not
seem to be present.

Did anyone get audio to run on N9/N950? It is marked as supported on
https://elinux.org/N950 with dt glue missing...

Even more importantly, does battery charging work for someone? It does
not work here :-(. After USB is plugged in, it maybe tries to charge,
but gives up after 30 seconds.

Maybe least important, but... does anyone have FM radio working? I'd
like to play some music...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/d6154afd/attachment.sig>

^ permalink raw reply

* [kernel-hardening] [PATCH] arm: kernel: implement fast refcount checking
From: Ard Biesheuvel @ 2018-01-03 13:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAErMHp_zm2UbUyd=E3gKOLUbjq+t+gnphUsxbUYjCMqOQN86qA@mail.gmail.com>

On 3 January 2018 at 13:36, Jinbum Park <jinb.park7@gmail.com> wrote:
>>> This is a nice result. However, without any insight into the presence
>>> of actual refcount hot spots, it is not obvious that we need this
>>> patch. This is the reason we ended up enabling CONFIG_REFCOUNT_FULL
>>> for arm64. I will let others comment on whether we want this patch in
>>> the first place,
>
> Dear Ard, Dave,
>
> I wanna hear some comment on above point.
> Is CONFIG_REFCOUNT_FULL much better for arm?
> If it is, I don't need to prepare v2 patch. (then, just needed to add
> "select REFCOUNT_FULL")
>

Well, we should probably turn that around. Please use REFCOUNT_FULL,
until you run into a use case where the slowdown is noticeable. If
nobody ever notices, we don't need to fix anything.

^ permalink raw reply

* [PATCH v3 1/3] arm64: dts: renesas: r8a7795: move scif node into alphabetical order
From: Geert Uytterhoeven @ 2018-01-03 14:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-2-horms+renesas@verge.net.au>

On Wed, Jan 3, 2018 at 1:41 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Move scif node so that sub-nodes of the root node are in
> alphabetical order.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH v3 2/3] arm64: dts: renesas: r8a7795: Add OPPs table for cpu devices
From: Geert Uytterhoeven @ 2018-01-03 14:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-3-horms+renesas@verge.net.au>

On Wed, Jan 3, 2018 at 1:41 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> From: Dien Pham <dien.pham.ry@rvc.renesas.com>
>
> Define OOP tables for all CPUs.
> This allows CPUFreq to function.
>
> Based in part on work by Hien Dang.
>
> Signed-off-by: Dien Pham <dien.pham.ry@rvc.renesas.com>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Looks good and matches the bindings.
I cannot verify the operating point tuples, though.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH v3 3/3] arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices
From: Geert Uytterhoeven @ 2018-01-03 14:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103124105.1999-4-horms+renesas@verge.net.au>

On Wed, Jan 3, 2018 at 1:41 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> From: Dien Pham <dien.pham.ry@rvc.renesas.com>
>
> Define OOP tables for all CPUs.
> This allows CPUFreq to function.
>
> Based in part on work by Hien Dang.
>
> Signed-off-by: Dien Pham <dien.pham.ry@rvc.renesas.com>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Looks good and matches the bindings.
I cannot verify the operating point tuples, though.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCHv2] nokia N9: Add support for magnetometer
From: Pavel Machek @ 2018-01-03 14:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180102172720.ghtez4d3d2fgcmj6@earth.universe>


This adds dts support for magnetometer on Nokia N9.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 39e35f8..af321d8 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -36,6 +57,12 @@
 			};
 		};
 	};
+
+&i2c3 {
+	ak8975 at 0f {
+		compatible = "asahi-kasei,ak8975";
+		reg = <0x0f>;
+	};
 };
 
 &isp {

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/657d091d/attachment.sig>

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox