Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 2/4] ARM: imx6: gpc: Add pm clock support to PU power domain
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel@pengutronix.de>

Drivers still handle clocks themselves, we only enable pm clocks of the
GPU and VPU devices in the PU power domain temporarily during powerup
so that the reset machinery can work.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 arch/arm/mach-imx/gpc.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index c3ec2c5..e3f4492 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -18,6 +18,7 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
 #include <linux/regulator/consumer.h>
 #include <linux/irqchip/arm-gic.h>
@@ -184,6 +185,7 @@ static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
 
 static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
 {
+	struct pm_domain_data *pdd;
 	int ret;
 	u32 val;
 	int sw, sw2iso;
@@ -194,6 +196,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
 		return ret;
 	}
 
+	/* Enable PM clocks for all devices in the PU domain */
+	list_for_each_entry(pdd, &genpd->dev_list, list_node)
+		pm_clk_resume(pdd->dev);
+
 	/* Gate off PU domain when GPU/VPU when powered down */
 	writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
 
@@ -210,6 +216,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
 	/* Wait ISO + ISO2SW IPG clock cycles */
 	ndelay((sw + sw2iso) * 1000 / 66);
 
+	/* Disable PM clocks for all devices in the PU domain */
+	list_for_each_entry(pdd, &genpd->dev_list, list_node)
+		pm_clk_suspend(pdd->dev);
+
 	return 0;
 }
 
@@ -219,6 +229,68 @@ static struct generic_pm_domain imx6q_pu_domain = {
 	.power_on = imx6q_pm_pu_power_on,
 };
 
+int imx6q_pm_clk_add(struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	const char *con_id;
+	struct clk *clk;
+	int i = 0;
+
+	/* Add and prepare named clocks */
+	while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+		pm_clk_add(dev, con_id);
+		clk = of_clk_get(np, i);
+		if (!IS_ERR(clk)) {
+			clk_prepare(clk);
+			clk_put(clk);
+		}
+		i++;
+	}
+
+	/* If no named clocks are given, add and prepare unnamed clock */
+	if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+		pm_clk_add(dev, NULL);
+		clk = of_clk_get(np, 0);
+		if (!IS_ERR(clk)) {
+			clk_prepare(clk);
+			clk_put(clk);
+		}
+	}
+
+	return 0;
+}
+
+int imx6q_pm_clk_remove(struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	const char *con_id;
+	struct clk *clk;
+	int i = 0;
+
+	/* Remove and unprepare named clocks */
+	while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+		pm_clk_remove(dev, con_id);
+		clk = of_clk_get(np, i);
+		if (!IS_ERR(clk)) {
+			clk_unprepare(clk);
+			clk_put(clk);
+		}
+		i++;
+	}
+
+	/* If no named clocks are given, remove and unprepare unnamed clock */
+	if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+		pm_clk_remove(dev, NULL);
+		clk = of_clk_get(np, 0);
+		if (!IS_ERR(clk)) {
+			clk_unprepare(clk);
+			clk_put(clk);
+		}
+	}
+
+	return 0;
+}
+
 static int imx6q_pm_notifier_call(struct notifier_block *nb,
 				  unsigned long event, void *data)
 {
@@ -237,6 +309,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
 		if (ret)
 			dev_err(dev, "failed to add to power domain: %d\n",
 				ret);
+		imx6q_pm_clk_add(dev);
 		break;
 	case BUS_NOTIFY_UNBOUND_DRIVER:
 		genpd = dev_to_genpd(dev);
@@ -246,6 +319,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
 		if (ret)
 			dev_err(dev, "failed to remove from power domain: %d\n",
 				ret);
+		imx6q_pm_clk_remove(dev);
 		break;
 	}
 
-- 
1.8.5.3

^ permalink raw reply related

* [RFC PATCH 3/4] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel@pengutronix.de>

The PU regulator is enabled during boot, but not necessarily always-on.
It can be disabled by the generic pm domain framework when the PU power
domain is shut down. The ramp delay of 150 us might be a bit conservative,
the value is taken from the Freescale kernel.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..253d82c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -515,7 +515,8 @@
 					regulator-name = "vddpu";
 					regulator-min-microvolt = <725000>;
 					regulator-max-microvolt = <1450000>;
-					regulator-always-on;
+					regulator-enable-ramp-delay = <150>;
+					regulator-boot-on;
 					anatop-reg-offset = <0x140>;
 					anatop-vol-bit-shift = <9>;
 					anatop-vol-bit-width = <5>;
-- 
1.8.5.3

^ permalink raw reply related

* [RFC PATCH 4/4] ARM: dts: imx6qdl: Add PU power-domain information to gpc node
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel@pengutronix.de>

The PGC that is part of GPC controls isolation and power sequencing of the
PU power domain. The power domain will be handled by the generic pm domain
framework and needs a phandle to the PU regulator to turn off power when
the domain is disabled.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 253d82c..595750d 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -598,9 +598,17 @@
 			};
 
 			gpc: gpc at 020dc000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
 				compatible = "fsl,imx6q-gpc";
 				reg = <0x020dc000 0x4000>;
 				interrupts = <0 89 0x04 0 90 0x04>;
+				pu-supply = <&reg_pu>;
+
+				pd_pu: power-domain at 020dc260 {
+					compatible = "fsl,power-domain";
+					reg = <0x020dc260 0x10>;
+				};
 			};
 
 			gpr: iomuxc-gpr at 020e0000 {
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-11 13:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140211120645.GH13533@sirena.org.uk>

On Tue, Feb 11, 2014 at 12:06:45PM +0000, Mark Brown wrote:
> On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
> 
> > -	pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +	/*
> > +	 * For compatibility with old DTBs and platform data, fall back to the
> > +	 * first clock if there's not an explicitly named "sspclk" entry.
> > +	 */
> > +	pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > +	if (IS_ERR(pl022->clk))
> > +		pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +
> 
> I'll just have a bit of a grumble here and point out that this sort of
> stuff always worries me with the convention of using nameless clocks -
> it causes hassle adding further clocks.
>
> In any case you didn't CC me on the cover letter or any of the non-SPI
> patches so I'm not sure what the dependencies are here (if there are
> any), does the series need to go in as one?

Apologies for missing you for the cover letter (you can find a copy in
the lakml archive [1]).

The SPI patches don't depend on the rest of the series, but given
Russell's comments on the cover [2] this will probably need a v2 anyway.
I'll ensure you're Cc'd.

Cheers,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/231572.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/231594.html

^ permalink raw reply

* [PATCH v9 2/4] ehci-platform: Add support for clks and phy passed through devicetree
From: Roger Quadros @ 2014-02-11 13:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52F9F7B3.6080802@redhat.com>

On 02/11/2014 12:13 PM, Hans de Goede wrote:
> Hi,
> 
> On 02/11/2014 11:00 AM, Roger Quadros wrote:
>> On 02/11/2014 11:31 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/11/2014 10:12 AM, Roger Quadros wrote:
>>>> Hi Hans,
>>>>
>>>> On 02/07/2014 05:36 PM, Hans de Goede wrote:
>>>>> Currently ehci-platform is only used in combination with devicetree when used
>>>>> with some Via socs. By extending it to (optionally) get clks and a phy from
>>>>> devicetree, and enabling / disabling those on power_on / off, it can be used
>>>>> more generically. Specifically after this commit it can be used for the
>>>>> ehci controller on Allwinner sunxi SoCs.
>>>>>
>>>>> Since ehci-platform is intended to handle any generic enough non pci ehci
>>>>> device, add a "usb-ehci" compatibility string.
>>>>>
>>>>> There already is a usb-ehci device-tree bindings document, update this
>>>>> with clks and phy bindings info.
>>>>>
>>>>> Although actually quite generic so far the via,vt8500 compatibilty string
>>>>> had its own bindings document. Somehow we even ended up with 2 of them. Since
>>>>> these provide no extra information over the generic usb-ehci documentation,
>>>>> this patch removes them.
>>>>>
>>>>> The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
>>>>> even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
>>>>> not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
>>>>> 2 drivers claiming the same compatibility string getting build on ppc.
>>>>>
>>>>
>>>> This breaks all OMAP platforms on linux-next for the exact same reason. see [1].
>>>>
>>>> ./arch/arm/boot/dts/omap4.dtsi:				compatible = "ti,ehci-omap", "usb-ehci";
>>>> ./arch/arm/boot/dts/omap3.dtsi:				compatible = "ti,ehci-omap", "usb-ehci";
>>>> ./arch/arm/boot/dts/omap5.dtsi:				compatible = "ti,ehci-omap", "usb-ehci";
>>>
>>> That should not be the case, the driver core should try to find a driver matching
>>> the compatibility string from left to right, or in other words from most specific
>>> to least specific. This is part of the whole devicetree design.
>>>
>>> So as long as the driver claiming "ti,ehci-omap" is available at probe time that
>>> one should get used and things should work fine. Now if ehci-platform is built-in
>>> and ehci-omap is a module, then I guess one could see the described breakage.
>>>
>>> If the driver is built-in and things are not working, then we will need to do some
>>> debugging as to why the left to right matching is not working as expected.
>>
>> Both ehci_platform and ehci_omap were built-in and still the ehci_platform driver got
>> probe preference. So it looks like the left to right compatible list priority probing
>> feature doesn't work.
> 
> Oops, I guess nothing relies on it sofar. Well we could go and debug and fix this but...
> 

I think we have a misunderstanding. The compatible list priority probing is only for the
platform identification compatible. I don't think it is meant to work with driver core yet.

http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L116

>>
>>>
>>> I must admit I'm not sure what happens if both are a module, the kernel direct
>>> module load will likely fail due to lack of a rootfs at that point, and then
>>> the module will later get loaded by udev I assume, at which point there are no
>>> loading ordering guarantees.
>>>
>>> The easiest solution to ensure that "ti,ehci-omap" is available at probe time
>>> (if enabled) seems to be to change USB_EHCI_HCD_OMAP to a boolean.
>>
>> That is a limitation I don't like to have for USB_EHCI_HCD_OMAP.
> 
> I completely understand, thinking more about this I'm simply going to change the
> compatibility string for ohci- and ehci-platform to be "ohci-platform" resp.
> "ehci-platform". I know there are some people who don't like the -platform
> suffix, but though luck, as the above clearly shows using the generic "usb-ohci" /
> "usb-ehci" they were advocating for leads to a ton of issues, and we already
> have a precedent for ?hci-platform in the form of "xhci-platform".

+1

cheers,
-roger

^ permalink raw reply

* [PATCH] ARM: ux500: drop DMA channel platform data for storage
From: Ulf Hansson @ 2014-02-11 13:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392120687-12572-1-git-send-email-linus.walleij@linaro.org>

On 11 February 2014 13:11, Linus Walleij <linus.walleij@linaro.org> wrote:
> The MMC/SD interface driver (MMCI) already supports picking its
> DMA channels out of the device tree, so there is no point in
> overriding them with identical platform data as well.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---
>  arch/arm/mach-ux500/board-mop500-sdi.c | 79 ----------------------------------
>  1 file changed, 79 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
> index fcbf3a13a539..0addb1815fa6 100644
> --- a/arch/arm/mach-ux500/board-mop500-sdi.c
> +++ b/arch/arm/mach-ux500/board-mop500-sdi.c
> @@ -11,13 +11,11 @@
>  #include <linux/amba/mmci.h>
>  #include <linux/mmc/host.h>
>  #include <linux/platform_device.h>
> -#include <linux/platform_data/dma-ste-dma40.h>
>
>  #include <asm/mach-types.h>
>
>  #include "db8500-regs.h"
>  #include "board-mop500.h"
> -#include "ste-dma40-db8500.h"
>
>  /*
>   * v2 has a new version of this block that need to be forced, the number found
> @@ -29,20 +27,6 @@
>   * SDI 0 (MicroSD slot)
>   */
>
> -#ifdef CONFIG_STE_DMA40
> -struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_DEV_TO_MEM,
> -       .dev_type = DB8500_DMA_DEV29_SD_MM0,
> -};
> -
> -static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_MEM_TO_DEV,
> -       .dev_type = DB8500_DMA_DEV29_SD_MM0,
> -};
> -#endif
> -
>  struct mmci_platform_data mop500_sdi0_data = {
>         .f_max          = 100000000,
>         .capabilities   = MMC_CAP_4_BIT_DATA |
> @@ -56,30 +40,11 @@ struct mmci_platform_data mop500_sdi0_data = {
>                                 MCI_ST_CMDDIREN |
>                                 MCI_ST_DATA0DIREN |
>                                 MCI_ST_DATA2DIREN,
> -#ifdef CONFIG_STE_DMA40
> -       .dma_filter     = stedma40_filter,
> -       .dma_rx_param   = &mop500_sdi0_dma_cfg_rx,
> -       .dma_tx_param   = &mop500_sdi0_dma_cfg_tx,
> -#endif
>  };
>
>  /*
>   * SDI1 (SDIO WLAN)
>   */
> -#ifdef CONFIG_STE_DMA40
> -static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_DEV_TO_MEM,
> -       .dev_type = DB8500_DMA_DEV32_SD_MM1,
> -};
> -
> -static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_MEM_TO_DEV,
> -       .dev_type = DB8500_DMA_DEV32_SD_MM1,
> -};
> -#endif
> -
>  struct mmci_platform_data mop500_sdi1_data = {
>         .ocr_mask       = MMC_VDD_29_30,
>         .f_max          = 100000000,
> @@ -87,31 +52,12 @@ struct mmci_platform_data mop500_sdi1_data = {
>                                 MMC_CAP_NONREMOVABLE,
>         .gpio_cd        = -1,
>         .gpio_wp        = -1,
> -#ifdef CONFIG_STE_DMA40
> -       .dma_filter     = stedma40_filter,
> -       .dma_rx_param   = &sdi1_dma_cfg_rx,
> -       .dma_tx_param   = &sdi1_dma_cfg_tx,
> -#endif
>  };
>
>  /*
>   * SDI 2 (POP eMMC, not on DB8500ed)
>   */
>
> -#ifdef CONFIG_STE_DMA40
> -struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_DEV_TO_MEM,
> -       .dev_type =  DB8500_DMA_DEV28_SD_MM2,
> -};
> -
> -static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_MEM_TO_DEV,
> -       .dev_type = DB8500_DMA_DEV28_SD_MM2,
> -};
> -#endif
> -
>  struct mmci_platform_data mop500_sdi2_data = {
>         .ocr_mask       = MMC_VDD_165_195,
>         .f_max          = 100000000,
> @@ -123,31 +69,11 @@ struct mmci_platform_data mop500_sdi2_data = {
>                                 MMC_CAP_CMD23,
>         .gpio_cd        = -1,
>         .gpio_wp        = -1,
> -#ifdef CONFIG_STE_DMA40
> -       .dma_filter     = stedma40_filter,
> -       .dma_rx_param   = &mop500_sdi2_dma_cfg_rx,
> -       .dma_tx_param   = &mop500_sdi2_dma_cfg_tx,
> -#endif
>  };
>
>  /*
>   * SDI 4 (on-board eMMC)
>   */
> -
> -#ifdef CONFIG_STE_DMA40
> -struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_DEV_TO_MEM,
> -       .dev_type =  DB8500_DMA_DEV42_SD_MM4,
> -};
> -
> -static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
> -       .mode = STEDMA40_MODE_LOGICAL,
> -       .dir = DMA_MEM_TO_DEV,
> -       .dev_type = DB8500_DMA_DEV42_SD_MM4,
> -};
> -#endif
> -
>  struct mmci_platform_data mop500_sdi4_data = {
>         .f_max          = 100000000,
>         .capabilities   = MMC_CAP_4_BIT_DATA |
> @@ -158,9 +84,4 @@ struct mmci_platform_data mop500_sdi4_data = {
>                                 MMC_CAP_CMD23,
>         .gpio_cd        = -1,
>         .gpio_wp        = -1,
> -#ifdef CONFIG_STE_DMA40
> -       .dma_filter     = stedma40_filter,
> -       .dma_rx_param   = &mop500_sdi4_dma_cfg_rx,
> -       .dma_tx_param   = &mop500_sdi4_dma_cfg_tx,
> -#endif
>  };
> --
> 1.8.5.3
>

^ permalink raw reply

* [PATCH] arm64: make a single hook to syscall_trace() for all syscall features
From: Richard Guy Briggs @ 2014-02-11 13:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391767651-5296-1-git-send-email-takahiro.akashi@linaro.org>

On 14/02/07, AKASHI Takahiro wrote:
> Currently syscall_trace() is called only for ptrace.
> With additional TIF_xx flags introduced, it is now called in all the cases
> of audit, ftrace and seccomp in addition to ptrace.
> Those features will be implemented later, but it's safe to include them
> now because they can not be turned on anyway.
> 
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

Acked-by: Richard Guy Briggs <rgb@redhat.com>

> ---
>  arch/arm64/include/asm/thread_info.h |   13 +++++++++++++
>  arch/arm64/kernel/entry.S            |    5 +++--
>  arch/arm64/kernel/ptrace.c           |   11 +++++------
>  3 files changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> index 720e70b..c3df797 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -91,6 +91,9 @@ static inline struct thread_info *current_thread_info(void)
>  /*
>   * thread information flags:
>   *  TIF_SYSCALL_TRACE	- syscall trace active
> + *  TIF_SYSCALL_TRACEPOINT - syscall tracepoint for ftrace
> + *  TIF_SYSCALL_AUDIT	- syscall auditing
> + *  TIF_SECOMP		- syscall secure computing
>   *  TIF_SIGPENDING	- signal pending
>   *  TIF_NEED_RESCHED	- rescheduling necessary
>   *  TIF_NOTIFY_RESUME	- callback before returning to user
> @@ -101,6 +104,9 @@ static inline struct thread_info *current_thread_info(void)
>  #define TIF_NEED_RESCHED	1
>  #define TIF_NOTIFY_RESUME	2	/* callback before returning to user */
>  #define TIF_SYSCALL_TRACE	8
> +#define TIF_SYSCALL_AUDIT	9
> +#define TIF_SYSCALL_TRACEPOINT	10
> +#define TIF_SECCOMP		11
>  #define TIF_POLLING_NRFLAG	16
>  #define TIF_MEMDIE		18	/* is terminating due to OOM killer */
>  #define TIF_FREEZE		19
> @@ -112,10 +118,17 @@ static inline struct thread_info *current_thread_info(void)
>  #define _TIF_SIGPENDING		(1 << TIF_SIGPENDING)
>  #define _TIF_NEED_RESCHED	(1 << TIF_NEED_RESCHED)
>  #define _TIF_NOTIFY_RESUME	(1 << TIF_NOTIFY_RESUME)
> +#define _TIF_SYSCALL_TRACE	(1 << TIF_SYSCALL_TRACE)
> +#define _TIF_SYSCALL_AUDIT	(1 << TIF_SYSCALL_AUDIT)
> +#define _TIF_SYSCALL_TRACEPOINT	(1 << TIF_SYSCALL_TRACEPOINT)
> +#define _TIF_SECCOMP		(1 << TIF_SECCOMP)
>  #define _TIF_32BIT		(1 << TIF_32BIT)
>  
>  #define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
>  				 _TIF_NOTIFY_RESUME)
>  
> +#define _TIF_WORK_SYSCALL	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
> +				 _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP)
> +
>  #endif /* __KERNEL__ */
>  #endif /* __ASM_THREAD_INFO_H */
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 39ac630..c94b2ab 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -631,8 +631,9 @@ el0_svc_naked:					// compat entry point
>  	enable_irq
>  
>  	get_thread_info tsk
> -	ldr	x16, [tsk, #TI_FLAGS]		// check for syscall tracing
> -	tbnz	x16, #TIF_SYSCALL_TRACE, __sys_trace // are we tracing syscalls?
> +	ldr	x16, [tsk, #TI_FLAGS]		// check for syscall hooks
> +	tst	x16, #_TIF_WORK_SYSCALL
> +	b.ne	__sys_trace
>  	adr	lr, ret_fast_syscall		// return address
>  	cmp     scno, sc_nr                     // check upper syscall limit
>  	b.hs	ni_sys
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 6a8928b..64ce39f 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -1062,9 +1062,6 @@ asmlinkage int syscall_trace(int dir, struct pt_regs *regs)
>  {
>  	unsigned long saved_reg;
>  
> -	if (!test_thread_flag(TIF_SYSCALL_TRACE))
> -		return regs->syscallno;
> -
>  	if (is_compat_task()) {
>  		/* AArch32 uses ip (r12) for scratch */
>  		saved_reg = regs->regs[12];
> @@ -1078,10 +1075,12 @@ asmlinkage int syscall_trace(int dir, struct pt_regs *regs)
>  		regs->regs[7] = dir;
>  	}
>  
> -	if (dir)
> +	if (dir) {
>  		tracehook_report_syscall_exit(regs, 0);
> -	else if (tracehook_report_syscall_entry(regs))
> -		regs->syscallno = ~0UL;
> +	} else {
> +		if (tracehook_report_syscall_entry(regs))
> +			regs->syscallno = ~0UL;
> +	}
>  
>  	if (is_compat_task())
>  		regs->regs[12] = saved_reg;
> -- 
> 1.7.9.5
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

^ permalink raw reply

* [PATCH v4 0/3] arm64: Add audit support
From: Richard Guy Briggs @ 2014-02-11 13:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391767803-5350-1-git-send-email-takahiro.akashi@linaro.org>

On 14/02/07, AKASHI Takahiro wrote:
> This patchset adds system call audit support on arm64.
> Both 32-bit (AUDIT_ARCH_ARM) and 64-bit tasks (AUDIT_ARCH_AARCH64)
> are supported. Since arm64 has the exact same set of system calls
> on LE and BE, we don't care about endianness (or more specifically
> __AUDIT_ARCH_64BIT bit in AUDIT_ARCH_*).
> 
> There are some prerequisites for this patch to work correctly:
> * "generic compat system call audit support" patch
> * "correct a type mismatch in audit_syscall_exit()" patch
>    (already accepted and queued in 3.14)
> * "Modify a set of system calls in audit class" patch
>    (already accepted and queued in 3.14)
> * "__NR_* definitions for compat syscalls" patch from Catalin
> * "make a single hook to syscall_trace() for all syscall features" patch
> * userspace audit tool (v2.3.2 + my patch for arm64)
> 
> Please review them as well for better understandings.
> 
> This code was tested on both 32-bit and 64-bit LE userland 
> in the following two ways:
> 1) basic operations with auditctl/autrace
>   # auditctl -a exit,always -S openat -F path=/etc/inittab
>   # auditctl -a exit,always -F dir=/tmp -F perm=rw
>   # auditctl -a task,always
>   # autrace /bin/ls
>     by comparing output from autrace with one from strace
> 
> 2) audit-test-code (+ my workarounds for arm/arm64)
>   by running "audit-tool", "filter" and "syscalls" test categories.
> 
> Changes v1 -> v2:
> * Modified to utilize "generic compat system call audit" [3/6, 4/6, 5/6]
>   Please note that a required header, unistd_32.h, is automatically
>   generated from unistd32.h.
> * Refer to regs->orig_x0 instead of regs->x0 as the first argument of
>   system call in audit_syscall_entry() [6/6]
> * Include "Add regs_return_value() in syscall.h" patch [2/6],
>   which was not intentionally included in v1 because it could be added
>   by "kprobes support".
> 
> Changes v2 -> v3:
> * Remove asm/audit.h.
>   See "generic compat syscall audit support" patch v4
> * Remove endianness dependency, ie. AUDIT_ARCH_ARMEB/AARCH64EB.
> * Remove kernel/syscalls/Makefile which was used to create unistd32.h.
>   See Catalin's "Add __NR_* definitions for compat syscalls" patch
> 
> Changes v3 -> v4:
> * Modified to sync with the patch, "make a single hook to syscall_trace()
>   for all syscall features"
> 
> 
> AKASHI Takahiro (3):
>   arm64: Add regs_return_value() in syscall.h
>   arm64: Add audit support
>   arm64: audit: Add audit hook in ptrace/syscall_trace
> 
>  arch/arm64/Kconfig               |    1 +
>  arch/arm64/include/asm/ptrace.h  |    5 +++++
>  arch/arm64/include/asm/syscall.h |   15 +++++++++++++++
>  arch/arm64/kernel/ptrace.c       |    7 +++++++
>  include/uapi/linux/audit.h       |    1 +
>  5 files changed, 29 insertions(+)

Compile and regression tested on: ppc s390 x86_64 ppc64 i686 s390x.

Acked-by: Richard Guy Briggs <rgb@redhat.com>

> -- 
> 1.7.9.5
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

^ permalink raw reply

* [PATCH 0/2] Marvell Armada 375 and 38x timer support
From: Ezequiel Garcia @ 2014-02-11 13:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52FA20EF.30807@linaro.org>

Daniel,

On Tue, Feb 11, 2014 at 02:09:03PM +0100, Daniel Lezcano wrote:
> >>
> >> Applied to my tree for 3.15.
> >
> > Please hold off until we've resolved the discussion regarding adding
> > unneeded compatible strings.  It's under patch 6 in the main series
> > adding support for this new SoC.
> >

Yes, please drop it for now.

> >    [PATCH 06/11] ARM: mvebu: add Armada 380/385 support to the system-controller driver
> 
> Ok, thanks for the heads up.
> 

Ah, my bad! I should have added a warning about the discussion as I did
for the MBus patches. See:

http://www.spinics.net/lists/arm-kernel/msg306480.html

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Roger Quadros @ 2014-02-11 13:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392055835-6494-1-git-send-email-rogerq@ti.com>

On 02/10/2014 08:10 PM, Roger Quadros wrote:
> The OMAP EHCI controller is not compatible with the EHCI
> platform HCD driver so don't claim that we are.
> 
> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
> e.g. multi_v7_defconfig
> 
> Reported-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>

Please ignore this patch as Hans has agreed to do a more proper fix in

http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015

cheers,
-roger

> ---
>  arch/arm/boot/dts/omap3.dtsi | 2 +-
>  arch/arm/boot/dts/omap4.dtsi | 2 +-
>  arch/arm/boot/dts/omap5.dtsi | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index a5fc83b..6b5dbf8 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -641,7 +641,7 @@
>  			};
>  
>  			usbhsehci: ehci at 48064800 {
> -				compatible = "ti,ehci-omap", "usb-ehci";
> +				compatible = "ti,ehci-omap";
>  				reg = <0x48064800 0x400>;
>  				interrupt-parent = <&intc>;
>  				interrupts = <77>;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index d3f8a6e..f5d754b 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -706,7 +706,7 @@
>  			};
>  
>  			usbhsehci: ehci at 4a064c00 {
> -				compatible = "ti,ehci-omap", "usb-ehci";
> +				compatible = "ti,ehci-omap";
>  				reg = <0x4a064c00 0x400>;
>  				interrupt-parent = <&gic>;
>  				interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index a72813a..42fcffd 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -784,7 +784,7 @@
>  			};
>  
>  			usbhsehci: ehci at 4a064c00 {
> -				compatible = "ti,ehci-omap", "usb-ehci";
> +				compatible = "ti,ehci-omap";
>  				reg = <0x4a064c00 0x400>;
>  				interrupt-parent = <&gic>;
>  				interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> 

^ permalink raw reply

* [PATCH 0/7] primecell: make correct clock parsing possible
From: Mark Rutland @ 2014-02-11 13:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140211123356.GH26684@n2100.arm.linux.org.uk>

On Tue, Feb 11, 2014 at 12:33:56PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 11, 2014 at 11:37:05AM +0000, Mark Rutland wrote:
> > These patches attempt to harmonize the bindings and the drivers with what's in
> > use today, in a backwards compatible fashion, relieving us of our present
> > Kafkaesque nightmare. Each peripheral's clock(s) are given explicit names which
> > can be used, though code will fall back to the existing behaviour if said names
> > are not provided. Additionally the currently unmet ordering requirement of
> > apb_pclk is dropped, given all existing that code requires this to be named
> > anyway.
> 
> The reason why these clocks ended up with NULL names was to force the
> issue that clocks shall not be named solely by their connection IDs,
> which was a major problem before DT.  Now that we have DT, I'm happier
> to reinstate the names, but I think we should just reinstate the names
> we had previously.  That should be in the git history.

Good to know, that sounds fine to me.

> 
> The down-side is those names are all in capitals - but they were named
> after the signal name(s) given in the Primecell documentation.

As long as we have standardised names I'm not too worried about which
case they happen to be in, and matching the documentation seems
sensible. The pl050 driver expects "KMIREFCLK" already, so it would be
in keeping with (as far as I can tell) the only Primecell driver
currently requesting a clock by name.

I'll prepare a v2 shortly.

Cheers,
Mark.

^ permalink raw reply

* [PATCH 1/4] arm64: topology: Implement basic CPU topology support
From: Catalin Marinas @ 2014-02-11 14:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKfTPtDjF2bZsoj+tgBH-ZXYXNbXQ2mBie0FVgUy2vb_jY12FQ@mail.gmail.com>

On Tue, Feb 11, 2014 at 01:18:56PM +0000, Vincent Guittot wrote:
> On 11 February 2014 11:34, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Feb 11, 2014 at 08:15:19AM +0000, Vincent Guittot wrote:
> >> On 10 February 2014 17:46, Mark Brown <broonie@kernel.org> wrote:
> >> > On Mon, Feb 10, 2014 at 04:22:31PM +0000, Catalin Marinas wrote:
> >> >> On Mon, Feb 10, 2014 at 01:02:01PM +0000, Mark Brown wrote:
> >> >
> >> >> > +           if (cpu != cpuid)
> >> >> > +                   cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling);
> >> >> > +   }
> >> >> > +   smp_wmb();
> >> >
> >> >> I now noticed there are a couple of smp_wmb() calls in this patch. What
> >> >> are they for?
> >> >
> >> > To be honest I mostly cargo culted them from the ARM implementation; I
> >> > did look a bit but didn't fully dig into it - it seemed they were
> >> > required to ensure that the updates for the new CPU are visible over all
> >> > CPUs.  Vincent?
> >>
> >> Yes that's it. we must ensure that updates are made visible to other CPUs
> >
> > In relation to what? The smp_* barriers ensure ordering of observability
> > between a number of independent accesses, so you must be ensuring
> > ordering against something else. Also, you need to guarantee ordering on the
> > read-side too -- how is this achieved? I can't see any smp_rmb calls from a
> > quick grep, so I assume you're making use of address dependencies?
> 
> The boot sequence ensures the rmb

As Will said, smp_*mb() do not ensure absolute visibility, only relative
to subsequent memory accesses on the same processor. So just placing a
barrier at the end of a function does not mean much, it only shows half
of the problem it is trying to solve.

How are the secondary CPUs using this information? AFAICT, secondaries
call smp_store_cpu_info() which also go through each CPU in
update_siblings_mask(). Is there any race here that smp_wmb() is trying
to solve?

I guess for secondaries you could move the barrier just before
set_cpu_online(), this way it is clear that we want any previous writes
to become visible when this CPU is marked online. For the primary, any
memory writes should become visible before the CPU is started. One
synchronisation point is the pen release, depending on the smp_ops. I
think that's already covered by code like arch/arm/mach-*/platsmp.c.

So my proposal is to remove the smp_wmb() from topology.c and add it
where it is relevant as described above. If we have some race in
topology.c (like for example we may later decide to start more
secondaries at the same time), it needs to be solved using spinlocks.

-- 
Catalin

^ permalink raw reply

* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-11 14:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140211120645.GH13533@sirena.org.uk>

On Tuesday 11 February 2014, Mark Brown wrote:
> On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
> 
> > -     pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +     /*
> > +      * For compatibility with old DTBs and platform data, fall back to the
> > +      * first clock if there's not an explicitly named "sspclk" entry.
> > +      */
> > +     pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > +     if (IS_ERR(pl022->clk))
> > +             pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +
> 
> I'll just have a bit of a grumble here and point out that this sort of
> stuff always worries me with the convention of using nameless clocks -
> it causes hassle adding further clocks.

I think the best solution for this is to continue with anonymous clocks
rather than adding names after the fact. This could be done (for DT-only
drivers) using the of_clk_get() interface that takes an index, or
we could add a generic dev_clk_get_index() or similar interface that
has the same behavior but also works for clkdev.

	Arnd

^ permalink raw reply

* ohci-/ehci-platform: Change compatible string to ?hci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Greg,

Can you please add these 2 patches to usb-next, to unbreak usb on various
ARM platforms?

These 2 patches can either be squashed into the first 2 patches of my previous
set or added as is to preserve history, either way is fine with me.

The 2nd patch also fixes one of the Kconfig issues and I've a better plan
for the 2nd Kconfig issue too, so please consider this a self-nack for my
drivers/usb/host/Kconfig patches.

Here is a copy of the echi-platform commit-msg to explain the rationale of
these changes, as well as how the breakage happened in the first place:

The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
"depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
and went with the generic usb-ehci as requested.

In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ehci", ie they have:

	compatible = "ti,ehci-omap", "usb-ehci";

In theory this should not be a problem since the "ti,ehci-omap" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depend on driver registration order.

This patch changes the compatible string claimed by ehci-platform (back) to
"ehci-platform", avoiding the driver registration / module loading ordering
problems, and removes the "depends on !PPC_OF" workaround.

Note that there already is a precedent for using ?hci-platform, in the form
of xhci-platform.c using "xhci-platfrom" as compatible string.

Thanks & Regards,

Hans

^ permalink raw reply

* [PATCH 1/2] ohci-platform: Change compatible string from usb-ohci to ohci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392127826-31290-1-git-send-email-hdegoede@redhat.com>

The initial versions of the devicetree enablement patches for ohci-platform
used "ohci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up and went with
the generic usb-ohci as requested.

In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ohci", ie they have:

	compatible = "ti,ohci-omap3", "usb-ohci";

In theory this should not be a problem since the "ti,ohci-omap3" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depent on driver registration order.

This patch changes the compatible string claimed by ohci-platform (back) to
"ohci-platform", avoiding the driver registration / module loading ordering
problems. Note that there already is a precedent for using ?hci-platform, in
the form of xhci-platform.c using "xhci-platfrom" as compatible string.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 4 ++--
 drivers/usb/host/ohci-platform.c                   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 6933b0c..a8e576a 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -1,7 +1,7 @@
 USB OHCI controllers
 
 Required properties:
-- compatible : "usb-ohci"
+- compatible : "ohci-platform"
 - reg : ohci controller register range (address and length)
 - interrupts : ohci controller interrupt
 
@@ -16,7 +16,7 @@ Optional properties:
 Example:
 
 	ohci0: usb at 01c14400 {
-		compatible = "allwinner,sun4i-a10-ohci", "usb-ohci";
+		compatible = "allwinner,sun4i-a10-ohci", "ohci-platform";
 		reg = <0x01c14400 0x100>;
 		interrupts = <64>;
 		clocks = <&usb_clk 6>, <&ahb_gates 2>;
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index e2c28fd..59f3551 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -319,7 +319,7 @@ static int ohci_platform_resume(struct device *dev)
 #endif /* CONFIG_PM */
 
 static const struct of_device_id ohci_platform_ids[] = {
-	{ .compatible = "usb-ohci", },
+	{ .compatible = "ohci-platform", },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392127826-31290-1-git-send-email-hdegoede@redhat.com>

The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
"depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
and went with the generic usb-ehci as requested.

In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ehci", ie they have:

	compatible = "ti,ehci-omap", "usb-ehci";

In theory this should not be a problem since the "ti,ehci-omap" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depent on driver registration order.

This patch changes the compatible string claimed by ehci-platform (back) to
"ehci-platform", avoiding the driver registration / module loading ordering
problems, and removes the "depends on !PPC_OF" workaround.

Note that there already is a precedent for using ?hci-platform, in the form
of xhci-platform.c using "xhci-platfrom" as compatible string.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/devicetree/bindings/usb/usb-ehci.txt | 4 ++--
 drivers/usb/host/Kconfig                           | 1 -
 drivers/usb/host/ehci-platform.c                   | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index 2c1aeeb..46f428a 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -1,7 +1,7 @@
 USB EHCI controllers
 
 Required properties:
-  - compatible : should be "usb-ehci".
+  - compatible : should be "ehci-platform".
   - reg : should contain at least address and length of the standard EHCI
     register set for the device. Optional platform-dependent registers
     (debug-port or other) can be also specified here, but only after
@@ -27,7 +27,7 @@ Example (Sequoia 440EPx):
 
 Example (Allwinner sun4i A10 SoC):
    ehci0: usb at 01c14000 {
-	   compatible = "allwinner,sun4i-a10-ehci", "usb-ehci";
+	   compatible = "allwinner,sun4i-a10-ehci", "ehci-platform";
 	   reg = <0x01c14000 0x100>;
 	   interrupts = <39>;
 	   clocks = <&ahb_gates 1>;
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e28cbe0..a9707da 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -255,7 +255,6 @@ config USB_EHCI_ATH79
 
 config USB_EHCI_HCD_PLATFORM
 	tristate "Generic EHCI driver for a platform device"
-	depends on !PPC_OF
 	default n
 	---help---
 	  Adds an EHCI host driver for a generic platform device, which
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 8fde649..4f4d78f 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -333,7 +333,7 @@ static int ehci_platform_resume(struct device *dev)
 static const struct of_device_id vt8500_ehci_ids[] = {
 	{ .compatible = "via,vt8500-ehci", },
 	{ .compatible = "wm,prizm-ehci", },
-	{ .compatible = "usb-ehci", },
+	{ .compatible = "ehci-platform", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH] can: xilinx CAN controller support.
From: Arnd Bergmann @ 2014-02-11 14:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52FA2419.70102@monstr.eu>

On Tuesday 11 February 2014, Michal Simek wrote:
> >> The only remaining question is if we should create generic DT binding
> >> for fifo depth. Arnd, Rob: Any opinion about it?
> >> Definitely will be worth to have one generic binding if this is generic feature.
> >> But if this is just specific feature for us then current properties should
> >> be fine.
> >>
> >> In general all these xlnx,XXX properties just reflect all configurable options
> >> which you can setup in design tool which means that provide full hw description
> >> with all variants and they are automatically generated from tools.
> >>
> >> Please let me know what you think.
> > 
> > I like:
> > 
> >     rx-fifo-depth
> >     tx-fifo-depth
> 
> No problem with that. Let Kedar to fix it according this and he will send v2 with this.
> 

Sounds reasonable to me too.

	Arnd

^ permalink raw reply

* [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-11 14:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52FA2B4F.3010408@ti.com>

On 02/11/2014 07:53 AM, Roger Quadros wrote:
> On 02/10/2014 08:10 PM, Roger Quadros wrote:
>> The OMAP EHCI controller is not compatible with the EHCI
>> platform HCD driver so don't claim that we are.
>>
>> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
>> e.g. multi_v7_defconfig
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> 
> Please ignore this patch as Hans has agreed to do a more proper fix in
> 
> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
umm.. even then, drivers/usb/host/ehci-ppc-of.c claims compatibility
with usb,ehci -> and we wont function with that driver either.

-- 
Regards,
Nishanth Menon

^ permalink raw reply

* [PATCH RFC v3 0/3] ARM: defining idle states DT bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
  To: linux-arm-kernel

This is v3 of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226901.html

This patchset depends on the following bindings to be approved and augmented
to cater for hierarchical power domains in DT:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224928.html

Changes in v3:

- Renamed C-states to "idle states" in patches and cover letter
- Added SBSA definitions
- Added power_state parameter to PSCI
- Removed OPP dependency
- Split latency into entry/exit latencies
- Reintroduced processor and cache retention boolean
- Made power_state generic parameter for all entry methods
- Redefined idle state hierarchy

Changes in v2:

- Updated cache bindings according to review
- Added power domain phandle to cache bindings
- Added power domains to C-states bindings
- Removed useless reg property from C-states bindings
- Removed cpu-map references from C-states bindings
- Added dependency on OPP in C-states parameters
- Added C-state state hierarchy

ARM based systems embed power management HW that allows SW to enter
low-power states according to run-time criteria based on parameters (eg
power state entry/exit latency) that define how an idle state has to be
managed and its respective properties. ARM partners implement HW power
management schemes through custom HW, with power controllers and relative
control mechanisms differing on both HW implementations and the way SW can
control them. This differentiation forces PM software in the kernel to cope
with states differences in power management drivers, which cause code
fragmentation and duplication of functionality.

Most of the power control scheme HW parameters are not probeable on ARM
platforms from a SW point of view, hence, in order to tackle the drivers
fragmentation problem, this patch series defines device tree bindings to
describe idle states parameters on ARM platforms.

Device tree bindings for idle states also require the introduction of device
tree bindings for processor caches, since idle states entry/exit require
SW cache maintainance; in some ARM systems, where firmware does not
support power down interfaces, cache maintainance must be carried out in the
OS power management layer, which then requires a description of the cache
topology through device tree nodes.

Idle states device tree standardization shares most of the concepts and
definitions with the ongoing ACPI ARM C-state bindings proposal so that
both standards can contain a coherent set of parameters, simplifying the
way SW will have to handle the respective device drivers.

Lorenzo Pieralisi (3):
  Documentation: devicetree: psci: define CPU suspend parameter
  Documentation: arm: add cache DT bindings
  Documentation: arm: define DT idle states bindings

 Documentation/devicetree/bindings/arm/cache.txt       | 165 +++
 Documentation/devicetree/bindings/arm/cpus.txt        |  10 +
 Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
 Documentation/devicetree/bindings/arm/psci.txt        |   7 +
 4 files changed, 872 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
 create mode 100644 Documentation/devicetree/bindings/arm/idle-states.txt

-- 
1.8.4

^ permalink raw reply

* [PATCH RFC v3 1/3] Documentation: devicetree: psci: define CPU suspend parameter
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>

OS layers built on top of PSCI to enter low-power states require the
power_state parameter to be passed to the PSCI CPU suspend method.

This parameter is specific to a power state and platform specific,
therefore must be provided by firmware to the OS in order to enable
proper call sequence.

This patch adds a property in the PSCI bindings that describes how
the CPU suspend power_state parameter should be defined in DT in
all device nodes that rely on PSCI CPU suspend method usage.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 Documentation/devicetree/bindings/arm/psci.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index 433afe9..6fc32a5 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -42,6 +42,13 @@ Main node optional properties:
 
  - migrate       : Function ID for MIGRATE operation
 
+Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
+states bindings) must specify the following properties:
+
+- power-state
+		Value type: <u32>
+		Definition: power_state parameter to pass to the PSCI
+			    suspend call.
 
 Example:
 
-- 
1.8.4

^ permalink raw reply related

* [PATCH RFC v3 2/3] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>

On ARM systems the cache topology cannot be probed at runtime, in
particular, it is impossible to probe which CPUs share a given cache
level. Power management software requires this knowledge to implement
optimized power down sequences, hence this patch adds a document that
defines the DT cache bindings for ARM systems. The bindings supersede
cache bindings in the ePAPR (PowerPC bindings), because caches geometry for
architected caches is probeable on ARM systems. This patch also adds
properties that are specific to ARM architected caches to the existing ones
defined in the ePAPR v1.1, as bindings extensions.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 Documentation/devicetree/bindings/arm/cache.txt | 165 ++++++++++
 1 file changed, 165 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
new file mode 100644
index 0000000..bd9f3d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cache.txt
@@ -0,0 +1,165 @@
+==========================================
+ARM processors cache binding description
+==========================================
+
+Device tree bindings for cache nodes are already part of the ePAPR standard
+v1.1 ([2]) for PowerPC platforms. This document defines the cache bindings
+for caches on ARM processor systems.
+
+On ARM based systems most of the cache properties related to cache geometry
+are probeable in HW (please refer to the processor TRMs in [1] for register
+details), hence, unless otherwise stated, the properties defined in ePAPR for
+internal, multi-level and shared caches ([2], 3.7.3, 3.8) are to be considered
+superseded on ARM.
+
+On ARM, caches are either architected (directly controlled by the processor
+through coprocessor instructions and tightly coupled with the processor
+implementation) or unarchitected (controlled through a memory mapped
+interface, implemented as a stand-alone IP external to the processor
+implementation).
+
+This document provides the device tree bindings for ARM architected caches.
+
+- ARM architected cache node
+
+	Description: must be a direct child of the cpu node.
+		     A system can contain multiple architected cache nodes
+		     per cpu node, linked through the next-level-cache phandle.
+		     The next-level-cache property in the cpu node points to
+		     the first level of architected cache for the CPU.
+		     The next-level-cache links ordering must represent the
+		     system cache hierarchy in the system, with the upper
+		     cache level represented by a cache node with a missing
+		     next-level-cache property.
+
+	ARM architected cache node defines the following properties:
+
+	- compatible
+		Usage: Required
+		Value type: <string>
+		Definition: value shall be "arm,arch-cache".
+
+	- power-domain
+		Usage: Optional
+		Value type: phandle
+		Definition: A phandle and power domain specifier as defined by
+			    bindings of power domain specified by the
+			    phandle [3].
+
+Example(dual-cluster big.LITTLE system 32-bit)
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x0>;
+			next-level-cache = <&L1_0>;
+
+			L1_0: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_0>;
+			};
+
+			L2_0: l2-cache {
+				compatible = "arm,arch-cache";
+			};
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x1>;
+			next-level-cache = <&L1_1>;
+
+			L1_1: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_0>;
+			};
+		};
+
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x2>;
+			next-level-cache = <&L1_2>;
+
+			L1_2: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_0>;
+			};
+		};
+
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x3>;
+			next-level-cache = <&L1_3>;
+
+			L1_3: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_0>;
+			};
+		};
+
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			next-level-cache = <&L1_4>;
+
+			L1_4: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_1>;
+			};
+
+			L2_1: l2-cache {
+				compatible = "arm,arch-cache";
+			};
+		};
+
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			next-level-cache = <&L1_5>;
+
+			L1_5: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_1>;
+			};
+		};
+
+		cpu at 102 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x102>;
+			next-level-cache = <&L1_6>;
+
+			L1_6: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_1>;
+			};
+		};
+
+		cpu at 103 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x103>;
+			next-level-cache = <&L1_7>;
+
+			L1_7: l1-cache {
+				compatible = "arm,arch-cache";
+				next-level-cache = <&L2_1>;
+			};
+		};
+	};
+
+[1] ARM Architecture Reference Manuals
+    http://infocenter.arm.com/help/index.jsp
+[2] ePAPR standard
+    https://www.power.org/documentation/epapr-version-1-1/
+[3] Kernel documentation - power domain bindings
+    Documentation/devicetree/bindings/power/power_domain.txt
-- 
1.8.4

^ permalink raw reply related

* [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>

ARM based platforms implement a variety of power management schemes that
allow processors to enter idle states at run-time.
The parameters defining these idle states vary on a per-platform basis forcing
the OS to hardcode the state parameters in platform specific static tables
whose size grows as the number of platforms supported in the kernel increases
and hampers device drivers standardization.

Therefore, this patch aims at standardizing idle state device tree bindings for
ARM platforms. Bindings define idle state parameters inclusive of entry methods
and state latencies, to allow operating systems to retrieve the configuration
entries from the device tree and initialize the related power management
drivers, paving the way for common code in the kernel to deal with idle
states and removing the need for static data in current and previous kernel
versions.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 Documentation/devicetree/bindings/arm/cpus.txt        |  10 +
 Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
 2 files changed, 700 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..fb7f008 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,13 @@ nodes to be present and contain the properties described below.
 			  property identifying a 64-bit zero-initialised
 			  memory location.
 
+	- cpu-idle-states
+		Usage: Optional
+		Value type: <prop-encoded-array>
+		Definition:
+			# List of phandles to cpu idle state nodes supported
+			  by this cpu [1].
+
 Example 1 (dual-cluster big.LITTLE system 32-bit):
 
 	cpus {
@@ -382,3 +389,6 @@ cpus {
 		cpu-release-addr = <0 0x20000000>;
 	};
 };
+
+[1] ARM Linux kernel documentation - idle state bindings
+    Documentation/devicetree/bindings/arm/idle-states.txt
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
new file mode 100644
index 0000000..f155e70
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -0,0 +1,690 @@
+==========================================
+ARM idle states binding description
+==========================================
+
+==========================================
+1 - Introduction
+==========================================
+
+ARM systems contain HW capable of managing power consumption dynamically,
+where cores can be put in different low-power states (ranging from simple
+wfi to power gating) according to OSPM policies. The CPU states representing
+the range of dynamic idle states that a processor can enter at run-time, can be
+specified through device tree bindings representing the parameters required
+to enter/exit specific idle states on a given processor.
+
+According to the Server Base System Architecture document (SBSA, [3]), the
+power states an ARM CPU can be put into are identified by the following list:
+
+1 - Running
+2 - Idle_standby
+3 - Idle_retention
+4 - Sleep
+5 - Off
+
+ARM platforms implement the power states specified in the SBSA through power
+management schemes that allow an OS PM implementation to put the processor in
+different idle states (which include states 1 to 4 above; "off" state is not
+an idle state since it does not have wake-up capabilities, hence it is not
+considered in this document).
+
+Idle state parameters (eg entry latency) are platform specific and need to be
+characterized with bindings that provide the required information to OSPM
+code so that it can build the required tables and use them at runtime.
+
+The device tree binding definition for ARM idle states is the subject of this
+document.
+
+===========================================
+2 - cpu-idle-states node
+===========================================
+
+ARM processor idle states are defined within the cpu-idle-states node, which is
+a direct child of the cpus node and provides a container where the processor
+states, defined as device tree nodes, are listed.
+
+- cpu-idle-states node
+
+	Usage: Optional - On ARM systems, is a container of processor idle
+			  states nodes. If the system does not provide CPU
+			  power management capabilities or the processor just
+			  supports idle_standby a cpu-idle-states node is not
+			  required.
+
+	Description: cpu-idle-states node is a container node, where its
+		     subnodes describe the CPU idle states.
+
+	Node name must be "cpu-idle-states".
+
+	The cpu-idle-states node's parent node must be the cpus node.
+
+	The cpu-idle-states node's child nodes can be:
+
+	- one or more state nodes
+
+	Any other configuration is considered invalid.
+
+The nodes describing the idle states (state) can only be defined within the
+cpu-idle-states node.
+
+Any other configuration is consider invalid and therefore must be ignored.
+
+===========================================
+2 - state node
+===========================================
+
+A state node represents an idle state description and must be defined as
+follows:
+
+- state node
+
+	Description: must be child of either the cpu-idle-states node or
+		     a state node.
+
+	The state node name shall be "stateN", where N = {0, 1, ...} is
+	the node number; state nodes which are siblings within a single common
+	parent node must be given a unique and sequential N value, starting
+	from 0.
+
+	A state node can contain state child nodes. A state node with
+	children represents a hierarchical state, which is a superset of
+	the child states. Hierarchical states require all CPUs on which
+	they are valid to request the state in order for it to be entered.
+
+	A state node defines the following properties:
+
+	- compatible
+		Usage: Required
+		Value type: <stringlist>
+		Definition: Must be "arm,cpu-idle-state".
+
+	- index
+		Usage: Required
+		Value type: <u32>
+		Definition: It represents an idle state index, starting from 2.
+			    Index 0 represents the processor state "running"
+			    and index 1 represents processor mode
+			    "idle_standby", entered by executing a wfi
+			    instruction (SBSA,[3]); indexes 0 and 1 are
+			    standard ARM states that need not be described.
+
+	- entry-method
+		Usage: Required
+		Value type: <stringlist>
+		Definition: Describes the method by which a CPU enters the
+			    idle state. This property is required and must be
+			    one of:
+
+			    - "arm,psci-cpu-suspend"
+			      ARM PSCI firmware interface, CPU suspend
+			      method[2].
+
+			    - "[vendor],[method]"
+			      An implementation dependent string with
+			      format "vendor,method", where vendor is a string
+			      denoting the name of the manufacturer and
+			      method is a string specifying the mechanism
+			      used to enter the idle state.
+
+	- power-state
+		Usage: See definition.
+		Value type: <u32>
+		Definition: Depends on the entry-method property value.
+			    If entry-method is "arm,psci-cpu-suspend":
+				# Property is required and represents
+				  psci-power-state parameter. Please refer to
+				  [2] for PSCI bindings definition.
+
+	- entry-latency
+		Usage: Required
+		Value type: <prop-encoded-array>
+		Definition: u32 value representing worst case latency
+			    in microseconds required to enter the idle state.
+
+	- exit-latency
+		Usage: Required
+		Value type: <prop-encoded-array>
+		Definition: u32 value representing worst case latency
+			    in microseconds required to exit the idle state.
+
+	- min-residency
+		Usage: Required
+		Value type: <prop-encoded-array>
+		Definition: u32 value representing time in microseconds
+			    required for the CPU to be in the idle state to
+			    make up for the dynamic power consumed to
+			    enter/exit the idle state in order to break even
+			    in terms of power consumption compared to idle
+			    state index 1 (idle_standby).
+
+	- power-domains
+		Usage: Optional
+		Value type: <prop-encoded-array>
+		Definition: List of power domain specifiers ([1]) describing
+			    the power domains that are affected by the idle
+			    state entry.
+
+	- cache-state-retained
+		Usage: See definition
+		Value type: <none>
+		Definition: if present cache memory is retained on power down,
+			    otherwise it is lost.
+
+	- processor-state-retained
+		Usage: See definition
+		Value type: <none>
+		Definition: if present CPU processor logic is retained on
+			    power down, otherwise it is lost.
+
+===========================================
+3 - Examples
+===========================================
+
+Example 1 (ARM 64-bit, 16-cpu system):
+
+pd_clusters: power-domain-clusters at 80002000 {
+	compatible = "arm,power-controller";
+	reg = <0x0 0x80002000 0x0 0x1000>;
+	#power-domain-cells = <1>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	pd_cores: power-domain-cores at 80000000 {
+		compatible = "arm,power-controller";
+		reg = <0x0 0x80000000 0x0 0x1000>;
+		#power-domain-cells = <1>;
+	};
+};
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	cpu-idle-states {
+
+		STATE0: state0 {
+			compatible = "arm,cpu-idle-state";
+			index = <3>;
+			entry-method = "arm,psci-cpu-suspend";
+			psci-power-state = <0x1010000>;
+			entry-latency = <500>;
+			exit-latency = <1000>;
+			min-residency = <2500>;
+			power-domains = <&pd_clusters 0>;
+			STATE0_1: state0 {
+				compatible = "arm,cpu-idle-state";
+				index = <2>;
+				entry-method = "arm,psci-cpu-suspend";
+				psci-power-state = <0x0010000>;
+				entry-latency = <200>;
+				exit-latency = <400>;
+				min-residency = <300>;
+				power-domains = <&pd_cores 0>,
+						<&pd_cores 1>,
+						<&pd_cores 2>,
+						<&pd_cores 3>,
+						<&pd_cores 4>,
+						<&pd_cores 5>,
+						<&pd_cores 6>,
+						<&pd_cores 7>;
+			};
+		};
+
+		STATE1: state1 {
+			compatible = "arm,cpu-idle-state";
+			index = <3>;
+			entry-method = "arm,psci-cpu-suspend";
+			psci-power-state = <0x1010000>;
+			entry-latency = <1000>;
+			exit-latency = <3000>;
+			min-residency = <6500>;
+			power-domains = <&pd_clusters 1>;
+			STATE1_0: state0 {
+				compatible = "arm,cpu-idle-state";
+				index = <2>;
+				entry-method = "arm,psci-cpu-suspend";
+				psci-power-state = <0x0010000>;
+				entry-latency = <200>;
+				exit-latency = <400>;
+				min-residency = <500>;
+				power-domains = <&pd_cores 8>,
+						<&pd_cores 9>,
+						<&pd_cores 10>,
+						<&pd_cores 11>,
+						<&pd_cores 12>,
+						<&pd_cores 13>,
+						<&pd_cores 14>,
+						<&pd_cores 15>;
+			};
+		};
+	};
+
+	CPU0: cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+		enable-method = "psci";
+		next-level-cache = <&L1_0>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_0: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 0>;
+		};
+		L2_0: l2-cache {
+			compatible = "arm,arch-cache";
+			power-domain = <&pd_clusters 0>;
+		};
+	};
+
+	CPU1: cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+		enable-method = "psci";
+		next-level-cache = <&L1_1>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_1: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 1>;
+		};
+	};
+
+	CPU2: cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+		enable-method = "psci";
+		next-level-cache = <&L1_2>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_2: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 2>;
+		};
+	};
+
+	CPU3: cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+		enable-method = "psci";
+		next-level-cache = <&L1_3>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_3: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 3>;
+		};
+	};
+
+	CPU4: cpu at 10000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10000>;
+		enable-method = "psci";
+		next-level-cache = <&L1_4>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_4: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 4>;
+		};
+	};
+
+	CPU5: cpu at 10001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10001>;
+		enable-method = "psci";
+		next-level-cache = <&L1_5>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_5: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 5>;
+		};
+	};
+
+	CPU6: cpu at 10100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10100>;
+		enable-method = "psci";
+		next-level-cache = <&L1_6>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_6: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 6>;
+		};
+	};
+
+	CPU7: cpu at 10101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10101>;
+		enable-method = "psci";
+		next-level-cache = <&L1_7>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_7: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 7>;
+		};
+	};
+
+	CPU8: cpu at 100000000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x0>;
+		enable-method = "psci";
+		next-level-cache = <&L1_8>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_8: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 8>;
+		};
+		L2_1: l2-cache {
+			compatible = "arm,arch-cache";
+			power-domain = <&pd_clusters 1>;
+		};
+	};
+
+	CPU9: cpu at 100000001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x1>;
+		enable-method = "psci";
+		next-level-cache = <&L1_9>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_9: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 9>;
+		};
+	};
+
+	CPU10: cpu at 100000100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x100>;
+		enable-method = "psci";
+		next-level-cache = <&L1_10>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_10: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 10>;
+		};
+	};
+
+	CPU11: cpu at 100000101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x101>;
+		enable-method = "psci";
+		next-level-cache = <&L1_11>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_11: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 11>;
+		};
+	};
+
+	CPU12: cpu at 100010000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x10000>;
+		enable-method = "psci";
+		next-level-cache = <&L1_12>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_12: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 12>;
+		};
+	};
+
+	CPU13: cpu at 100010001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x10001>;
+		enable-method = "psci";
+		next-level-cache = <&L1_13>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_13: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 13>;
+		};
+	};
+
+	CPU14: cpu at 100010100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x10100>;
+		enable-method = "psci";
+		next-level-cache = <&L1_14>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_14: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 14>;
+		};
+	};
+
+	CPU15: cpu at 100010101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a53";
+		reg = <0x1 0x10101>;
+		enable-method = "psci";
+		next-level-cache = <&L1_15>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_15: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 15>;
+		};
+	};
+};
+
+Example 2 (ARM 32-bit, 8-cpu system, two clusters):
+
+pd_clusters: power-domain-clusters at 80002000 {
+	compatible = "arm,power-controller";
+	reg = <0x80002000 0x1000>;
+	#power-domain-cells = <1>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	pd_cores: power-domain-cores at 80000000 {
+		compatible = "arm,power-controller";
+		reg = <0x80000000 0x1000>;
+		#power-domain-cells = <1>;
+	};
+};
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <1>;
+
+	cpu-idle-states {
+
+		STATE0: state0 {
+			compatible = "arm,cpu-idle-state";
+			index = <3>;
+			entry-method = "psci";
+			psci-power-state = <0x1010000>;
+			entry-latency = <1000>;
+			exit-latency = <1500>;
+			min-residency = <1500>;
+			power-domains = <&pd_clusters 0>;
+			STATE0_1: state0 {
+				compatible = "arm,cpu-idle-state";
+				index = <2>;
+				entry-method = "psci";
+				psci-power-state = <0x0010000>;
+				entry-latency = <400>;
+				exit-latency = <500>;
+				min-residency = <300>;
+				power-domains = <&pd_cores 0>,
+						<&pd_cores 1>,
+						<&pd_cores 2>,
+						<&pd_cores 3>;
+			};
+		};
+
+		STATE1: state1 {
+			compatible = "arm,cpu-idle-state";
+			index = <3>;
+			entry-method = "psci";
+			psci-power-state = <0x1010000>;
+			entry-latency = <800>;
+			exit-latency = <2000>;
+			min-residency = <6500>;
+			power-domains = <&pd_clusters 1>;
+			STATE1_0: state0 {
+				compatible = "arm,cpu-idle-state";
+				index = <2>;
+				entry-method = "psci";
+				psci-power-state = <0x0010000>;
+				entry-latency = <300>;
+				exit-latency = <500>;
+				min-residency = <500>;
+				power-domains = <&pd_cores 4>,
+						<&pd_cores 5>,
+						<&pd_cores 6>,
+						<&pd_cores 7>;
+			};
+		};
+	};
+
+	CPU0: cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x0>;
+		next-level-cache = <&L1_0>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_0: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 0>;
+		};
+		L2_0: l2-cache {
+			compatible = "arm,arch-cache";
+			power-domain = <&pd_clusters 0>;
+		};
+	};
+
+	CPU1: cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x1>;
+		next-level-cache = <&L1_1>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_1: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 1>;
+		};
+	};
+
+	CPU2: cpu at 2 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x2>;
+		next-level-cache = <&L1_2>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_2: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 2>;
+		};
+	};
+
+	CPU3: cpu at 3 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x3>;
+		next-level-cache = <&L1_3>;
+		cpu-idle-states = <&STATE0_1 &STATE0>;
+		L1_3: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_0>;
+			power-domain = <&pd_cores 3>;
+		};
+	};
+
+	CPU4: cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x100>;
+		next-level-cache = <&L1_4>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_4: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 4>;
+		};
+		L2_1: l2-cache {
+			compatible = "arm,arch-cache";
+			power-domain = <&pd_clusters 1>;
+		};
+	};
+
+	CPU5: cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x101>;
+		next-level-cache = <&L1_5>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_5: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 5>;
+		};
+	};
+
+	CPU6: cpu at 102 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x102>;
+		next-level-cache = <&L1_6>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_6: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 6>;
+		};
+	};
+
+	CPU7: cpu at 103 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x103>;
+		next-level-cache = <&L1_7>;
+		cpu-idle-states = <&STATE1_0 &STATE1>;
+		L1_7: l1-cache {
+			compatible = "arm,arch-cache";
+			next-level-cache = <&L2_1>;
+			power-domain = <&pd_cores 7>;
+		};
+	};
+};
+
+===========================================
+4 - References
+===========================================
+
+[1] ARM Linux Kernel documentation - power domain bindings
+    Documentation/devicetree/bindings/power/power_domain.txt
+
+[2] ARM Linux Kernel documentation - PSCI bindings
+    Documentation/devicetree/bindings/arm/psci.txt
+
+[3] ARM Server Base System Architecture (SBSA)
+    http://infocenter.arm.com/help/index.jsp
-- 
1.8.4

^ permalink raw reply related

* [PATCH] clk: divider: fix rate calculation for fractional rates
From: Tomi Valkeinen @ 2014-02-11 14:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1383736008-22764-1-git-send-email-tomi.valkeinen@ti.com>

Mike, ping.

 Tomi

On 06/11/13 13:06, Tomi Valkeinen wrote:
> clk-divider.c does not calculate the rates consistently at the moment.
> 
> As an example, on OMAP3 we have a clock divider with a source clock of
> 864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:
> 
> 6: 144000000
> 7: 123428571.428571...
> 8: 108000000
> 
> Calling clk_round_rate() with the rate in the first column will give the
> rate in the second column:
> 
> 144000000 -> 144000000
> 143999999 -> 123428571
> 123428572 -> 123428571
> 123428571 -> 108000000
> 
> Note how clk_round_rate() returns 123428571 for rates from 123428572 to
> 143999999, which is mathematically correct, but when clk_round_rate() is
> called with 123428571, the returned value is surprisingly 108000000.
> 
> This means that the following code works a bit oddly:
> 
> rate = clk_round_rate(clk, 123428572);
> clk_set_rate(clk, rate);
> 
> As clk_set_rate() also does clock rate rounding, the result is that the
> clock is set to the rate of 108000000, not 123428571 returned by the
> clk_round_rate.
> 
> This patch changes the clk-divider.c to use DIV_ROUND_UP when
> calculating the rate. This gives the following behavior which fixes the
> inconsistency:
> 
> 144000000 -> 144000000
> 143999999 -> 123428572
> 123428572 -> 123428572
> 123428571 -> 108000000
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
>  drivers/clk/clk-divider.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 8d3009e..43348f3 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -24,7 +24,7 @@
>   * Traits of this clock:
>   * prepare - clk_prepare only ensures that parents are prepared
>   * enable - clk_enable only ensures that parents are enabled
> - * rate - rate is adjustable.  clk->rate = parent->rate / divisor
> + * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
>   * parent - fixed parent.  No clk_set_parent support
>   */
>  
> @@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
>  		return parent_rate;
>  	}
>  
> -	return parent_rate / div;
> +	return DIV_ROUND_UP(parent_rate, div);
>  }
>  
>  /*
> @@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
>  		}
>  		parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
>  				MULT_ROUND_UP(rate, i));
> -		now = parent_rate / i;
> +		now = DIV_ROUND_UP(parent_rate, i);
>  		if (now <= rate && now > best) {
>  			bestdiv = i;
>  			best = now;
> @@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
>  	int div;
>  	div = clk_divider_bestdiv(hw, rate, prate);
>  
> -	return *prate / div;
> +	return DIV_ROUND_UP(*prate, div);
>  }
>  
>  static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> @@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
>  	unsigned long flags = 0;
>  	u32 val;
>  
> -	div = parent_rate / rate;
> +	div = DIV_ROUND_UP(parent_rate, rate);
>  	value = _get_val(divider, div);
>  
>  	if (value > div_mask(divider))
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140211/7fadb1e8/attachment.sig>

^ permalink raw reply

* [PATCH 06/11] ARM: mvebu: add Armada 380/385 support to the system-controller driver
From: Grant Likely @ 2014-02-11 14:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140210173957.GS8533@titan.lakedaemon.net>

On Mon, Feb 10, 2014 at 5:39 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Mon, Feb 10, 2014 at 06:23:17PM +0100, Thomas Petazzoni wrote:
>> This commit adds support for the Armada 380/385 SoCs in the
>> system-controller driver. Since this SoC has the same system
>> controller registers layout than the Armada 370/XP at least for the
>> few features currently supported by the driver, this commit simply
>> adds a new compatible string that provides the same behavior than the
>> one provided for Armada 370/XP.
>>
>> Note that we intentionally do not use the same compatible string as
>> Armada 370/XP, as the current system-controller driver is far from
>> exploiting all the possibilities of the hardware, and we may in the
>> future discover differences between Armada 370/XP and Armada 380/385.
>
> I'd much prefer to add a new compatible string iff it accompanies
> incompatible changes.
>
> For now, I think it's best to use 'marvell,armada-370-xp-system-controller'
> in the dtsi file and change it when you introduce the incompatible
> features.

Actually, they are doing the right thing here. It is completely
appropriate to encode the SoC version into the compatible string, but
then to retain compatibility with the older device driver by including
the earlier compatible string in the compatible list so that no code
changes are required.

g.

>
> thx,
>
> Jason.
>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>>  Documentation/devicetree/bindings/arm/mvebu-system-controller.txt | 3 ++-
>>  arch/arm/mach-mvebu/system-controller.c                           | 8 ++++++++
>>  2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
>> index d24ab2e..3559972 100644
>> --- a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
>> +++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
>> @@ -1,6 +1,6 @@
>>  MVEBU System Controller
>>  -----------------------
>> -MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x)
>> +MVEBU (Marvell SOCs: Armada 370/375/38x/XP, Dove, mv78xx0, Kirkwood, Orion5x)
>>
>>  Required properties:
>>
>> @@ -8,6 +8,7 @@ Required properties:
>>       - "marvell,orion-system-controller"
>>       - "marvell,armada-370-xp-system-controller"
>>       - "marvell,armada-375-system-controller"
>> +     - "marvell,armada-380-system-controller"
>>  - reg: Should contain system controller registers location and length.
>>
>>  Example:
>> diff --git a/arch/arm/mach-mvebu/system-controller.c b/arch/arm/mach-mvebu/system-controller.c
>> index 1806187..b4e8bb2 100644
>> --- a/arch/arm/mach-mvebu/system-controller.c
>> +++ b/arch/arm/mach-mvebu/system-controller.c
>> @@ -71,6 +71,14 @@ static struct of_device_id of_system_controller_table[] = {
>>       }, {
>>               .compatible = "marvell,armada-375-system-controller",
>>               .data = (void *) &armada_375_system_controller,
>> +     }, {
>> +             /*
>> +              * As far as RSTOUTn and System soft reset registers
>> +              * are concerned, Armada 38x is similar to Armada
>> +              * 370/XP
>> +              */
>> +             .compatible = "marvell,armada-380-system-controller",
>> +             .data = (void *) &armada_370_xp_system_controller,

However, this would not be the right thing to do. The better solution
is to put the following into the .dts file:

compatible = "marvell,armada-380-system-controller","marvell,armada-370-system-controller"

So that the kernel has the option to override the 370 version if an
errata or extra feature support ever needs to be added.

g.

^ permalink raw reply

* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Tomasz Figa @ 2014-02-11 14:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140211121316.24032C40C4D@trevor.secretlab.ca>

Hi,

On 11.02.2014 13:13, Grant Likely wrote:
> On Tue, 11 Feb 2014 12:45:50 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> Hello,
>>
>> On 2014-02-05 12:05, Grant Likely wrote:
>>> On Tue, 04 Feb 2014 13:09:29 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>>>> This patch adds device tree support for contiguous and reserved memory
>>>> regions defined in device tree.
>>>>
>>>> Large memory blocks can be reliably reserved only during early boot.
>>>> This must happen before the whole memory management subsystem is
>>>> initialized, because we need to ensure that the given contiguous blocks
>>>> are not yet allocated by kernel. Also it must happen before kernel
>>>> mappings for the whole low memory are created, to ensure that there will
>>>> be no mappings (for reserved blocks) or mapping with special properties
>>>> can be created (for CMA blocks). This all happens before device tree
>>>> structures are unflattened, so we need to get reserved memory layout
>>>> directly from fdt.
>>>>
>>>> Later, those reserved memory regions are assigned to devices on each
>>>> device structure initialization.
>>>>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Laura Abbott <lauraa@codeaurora.org>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> [joshc: rework to implement new DT binding, provide mechanism for
>>>>   plugging in new reserved-memory node handlers via
>>>>   RESERVEDMEM_OF_DECLARE]
>>>> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
>>>> [mszyprow: little code cleanup]
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>>   drivers/of/Kconfig                |    6 +
>>>>   drivers/of/Makefile               |    1 +
>>>>   drivers/of/of_reserved_mem.c      |  219 +++++++++++++++++++++++++++++++++++++
>>>>   drivers/of/platform.c             |    7 ++
>>>>   include/asm-generic/vmlinux.lds.h |   11 ++
>>>>   include/linux/of_reserved_mem.h   |   62 +++++++++++
>>>>   6 files changed, 306 insertions(+)
>>>>   create mode 100644 drivers/of/of_reserved_mem.c
>>>>   create mode 100644 include/linux/of_reserved_mem.h
>>>>
>>>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>>>> index c6973f101a3e..aba13df56f3a 100644
>>>> --- a/drivers/of/Kconfig
>>>> +++ b/drivers/of/Kconfig
>>>> @@ -75,4 +75,10 @@ config OF_MTD
>>>>   	depends on MTD
>>>>   	def_bool y
>>>>
>>>> +config OF_RESERVED_MEM
>>>> +	depends on HAVE_MEMBLOCK
>>>> +	def_bool y
>>>> +	help
>>>> +	  Helpers to allow for reservation of memory regions
>>>> +
>>>>   endmenu # OF
>>>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>>>> index efd05102c405..ed9660adad77 100644
>>>> --- a/drivers/of/Makefile
>>>> +++ b/drivers/of/Makefile
>>>> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_MDIO)	+= of_mdio.o
>>>>   obj-$(CONFIG_OF_PCI)	+= of_pci.o
>>>>   obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
>>>>   obj-$(CONFIG_OF_MTD)	+= of_mtd.o
>>>> +obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>>>> new file mode 100644
>>>> index 000000000000..f17cd56e68d9
>>>> --- /dev/null
>>>> +++ b/drivers/of/of_reserved_mem.c
>>>> @@ -0,0 +1,219 @@
>>>> +/*
>>>> + * Device tree based initialization code for reserved memory.
>>>> + *
>>>> + * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
>>>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>>>> + *		http://www.samsung.com
>>>> + * Author: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> + * Author: Josh Cartwright <joshc@codeaurora.org>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU General Public License as
>>>> + * published by the Free Software Foundation; either version 2 of the
>>>> + * License or (at your optional) any later version of the license.
>>>> + */
>>>> +#include <linux/memblock.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_fdt.h>
>>>> +#include <linux/of_platform.h>
>>>> +#include <linux/mm.h>
>>>> +#include <linux/sizes.h>
>>>> +#include <linux/of_reserved_mem.h>
>>>> +
>>>> +#define MAX_RESERVED_REGIONS	16
>>>> +static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
>>>> +static int reserved_mem_count;
>>>> +
>>>> +int __init of_parse_flat_dt_reg(unsigned long node, const char *uname,
>>>> +				   phys_addr_t *base, phys_addr_t *size)
>>>
>>> Useful utility function; move to drivers/of/fdt.c
>>>
>>>> +{
>>>> +	unsigned long len;
>>>> +	__be32 *prop;
>>>> +
>>>> +	prop = of_get_flat_dt_prop(node, "reg", &len);
>>>> +	if (!prop)
>>>> +		return -EINVAL;
>>>> +
>>>> +	if (len < (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32)) {
>>>> +		pr_err("Reserved memory: invalid reg property in '%s' node.\n",
>>>> +				uname);
>>>> +		return -EINVAL;
>>>> +	}
>>>
>>> This is /okay/ for an initial implementation, but it is naive. While I
>>> suggested making #address-cells and #size-cells equal the root node
>>> values for the purpose of simplicity, it should still be perfectly valid
>>> to have different values if the ranges property is correctly formed.
>>>
>>>> +
>>>> +	*base = dt_mem_next_cell(dt_root_addr_cells, &prop);
>>>> +	*size = dt_mem_next_cell(dt_root_size_cells, &prop);
>>>
>>> Future enhancement; allow for parsing more than just the first reg
>>> tuple.
>>
>> One more question. Does it really makes any sense to support more than
>> one tuple for reg property? For consistency we should also allow more
>> than one entry in size, align and alloc-ranges property, but I don't
>> see any benefits for defining more than one range for a single region.
>> Same can be achieved by defining more regions instead if one really
>> needs such configuration.
>
> Yes, if only because it is an define usage of the reg property. If a
> devtree has multiple tuples in reg, then all of those tuples should be
> treated as reserved, even if the kernel doesn't know how to use them.
>
> I would not do the same for size/align/alloc-ranges unless there is a
> very specific use case that you can define. These ones are different
> from the static regions because they aren't ever used to protect
> something that already exists in the memory.

Is there a reason why multiple regions could not be used for this 
purpose, instead of adding extra complexity of having multiple reg 
entries per region?

I.e. I don't see a difference between

reg1: region at 00000000 {
	reg = <0x00000000 0x1000>;
};

reg2: region at 10000000 {
	reg = <0x10000000 0x1000>;
};

user {
	regions = <&reg1>, <&reg2>;
};

and

reg: region at 00000000 {
	reg = <0x00000000 0x1000>, <0x10000000 0x1000>;
};

user {
	regions = <&reg>;
};

except that the former IMHO better suits the definition of memory 
region, which I see as a single contiguous range of memory and can be 
simplified to have a single reg entry per region.

Best regards,
Tomasz

^ permalink raw reply


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