* [PATCH v3 08/15] watchdog: orion: Introduce per-compatible of_device_id data
From: Ezequiel Garcia @ 2014-01-22 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121163547.GB3311@roeck-us.net>
On Tue, Jan 21, 2014 at 08:35:47AM -0800, Guenter Roeck wrote:
> On Tue, Jan 21, 2014 at 10:26:07AM -0300, Ezequiel Garcia wrote:
> > This commit adds an orion_watchdog_data structure to holda compatible-data
>
> s/holda/hold/
>
Yup.
> > information. This allows to remove the driver-wide definition and to
> > future add support for multiple compatible-strings.
>
> Maybe "and to be able to add support for multiple compatible-strings in the
> future" ?
>
Yes, sounds better.
[..]
> >
> > #define WDT_MAX_CYCLE_COUNT 0xffffffff
> > #define WDT_IN_USE 0
> > #define WDT_OK_TO_CLOSE 1
> >
> While looking at the new defines below, I noticed that WDT_IN_USE and
> WDT_OK_TO_CLOSE are not used (anymore ?) and thus should be removed
> (separate patch, though).
>
OK, let's clean this.
> > -#define WDT_RESET_OUT_EN BIT(1)
> > +#define WDT_A370_RATIO_MASK(v) ((v) << 16)
> > +#define WDT_A370_RATIO_SHIFT 5
> > +#define WDT_A370_RATIO (1 << WDT_A370_RATIO_SHIFT)
> > +
> > +#define WDT_AXP_FIXED_ENABLE_BIT BIT(10)
> >
> Those new defines are not used. They should be introduced if and when used.
>
Hm... maybe after dozens and dozens of rebases these macros sneaked here?
[..]
> >
> > + match = of_match_device(orion_wdt_of_match_table, &pdev->dev);
> > + if (!match)
> > + /* Default legacy match */
> > + match = &orion_wdt_of_match_table[0];
> > +
> > dev->wdt.info = &orion_wdt_info;
> > dev->wdt.ops = &orion_wdt_ops;
> > dev->wdt.min_timeout = 1;
> > + dev->data = (struct orion_watchdog_data *)match->data;
>
> match->data is a void *, so the typecast should not be needed here.
> You might want to declare 'data' to be of type
> 'const struct orion_watchdog_data *' because otherwise you loose the
> 'const' attribute of match->data (which may be the reason for the typecast ?).
>
Done.
Thanks a lot for reviewing!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCHv14][ 1/4] video: imxfb: Introduce regulator support.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
This commit is based on the following commit by Fabio Estevam:
4344429 video: mxsfb: Introduce regulator support
Cc: Eric B?nard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v13->v14:
- Remove people not concerned by this patch from the Cc list.
- Simplified the regulator handling: The regulator-core now supplies
a dummy regulator if one hasn't been hooked up explicitely.
So we don't need to handle that case in the driver.
The code has been updated to do that, and the error messages
were updated accordingly.
ChangeLog v9->v10:
- Added a return 0; at the end of imxfb_disable_controller.
ChangeLog v8->v9:
- return an error if regulator_{enable,disable} fails in
imxfb_{enable,disable}_controller, and use it.
---
drivers/video/imxfb.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 44ee678..dd8a35d 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -28,6 +28,7 @@
#include <linux/cpufreq.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/math64.h>
@@ -145,6 +146,7 @@ struct imxfb_info {
struct clk *clk_ipg;
struct clk *clk_ahb;
struct clk *clk_per;
+ struct regulator *reg_lcd;
enum imxfb_type devtype;
bool enabled;
@@ -561,14 +563,16 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
}
#endif
-static void imxfb_enable_controller(struct imxfb_info *fbi)
+static int imxfb_enable_controller(struct imxfb_info *fbi)
{
-
if (fbi->enabled)
- return;
+ return 0;
pr_debug("Enabling LCD controller\n");
+ if (regulator_enable(fbi->reg_lcd))
+ dev_err(&fbi->pdev->dev, "Failed to enable regulator.\n");
+
writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
/* panning offset 0 (0 pixel offset) */
@@ -593,12 +597,14 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
fbi->backlight_power(1);
if (fbi->lcd_power)
fbi->lcd_power(1);
+
+ return 0;
}
-static void imxfb_disable_controller(struct imxfb_info *fbi)
+static int imxfb_disable_controller(struct imxfb_info *fbi)
{
if (!fbi->enabled)
- return;
+ return 0;
pr_debug("Disabling LCD controller\n");
@@ -613,6 +619,11 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
fbi->enabled = false;
writel(0, fbi->regs + LCDC_RMCR);
+
+ if(regulator_disable(fbi->reg_lcd))
+ dev_err(&fbi->pdev->dev, "Failed to disable regulator.\n");
+
+ return 0;
}
static int imxfb_blank(int blank, struct fb_info *info)
@@ -626,13 +637,12 @@ static int imxfb_blank(int blank, struct fb_info *info)
case FB_BLANK_VSYNC_SUSPEND:
case FB_BLANK_HSYNC_SUSPEND:
case FB_BLANK_NORMAL:
- imxfb_disable_controller(fbi);
- break;
+ return imxfb_disable_controller(fbi);
case FB_BLANK_UNBLANK:
- imxfb_enable_controller(fbi);
- break;
+ return imxfb_enable_controller(fbi);
}
+
return 0;
}
@@ -734,8 +744,7 @@ static int imxfb_suspend(struct platform_device *dev, pm_message_t state)
pr_debug("%s\n", __func__);
- imxfb_disable_controller(fbi);
- return 0;
+ return imxfb_disable_controller(fbi);
}
static int imxfb_resume(struct platform_device *dev)
@@ -745,8 +754,7 @@ static int imxfb_resume(struct platform_device *dev)
pr_debug("%s\n", __func__);
- imxfb_enable_controller(fbi);
- return 0;
+ return imxfb_enable_controller(fbi);
}
#else
#define imxfb_suspend NULL
@@ -1020,6 +1028,10 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_register;
}
+ fbi->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
+ if (IS_ERR(fbi->reg_lcd))
+ return PTR_ERR(fbi->reg_lcd);
+
imxfb_enable_controller(fbi);
fbi->pdev = pdev;
#ifdef PWMR_BACKLIGHT_AVAILABLE
--
1.7.9.5
^ permalink raw reply related
* [PATCHv14][ 3/4] video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390410577-22073-1-git-send-email-denis@eukrea.com>
Without that patch, a user can't select the imxfb driver when the i.MX25 and/or
the i.MX27 device tree board are selected and that no boards that selects
IMX_HAVE_PLATFORM_IMX_FB are compiled in.
Cc: Eric B?nard <eric@eukrea.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
ChangeLog v11->v14:
- Remove people not concerned by this patch from the Cc list.
ChangeLog v10->v11:
- moved my signed-off-by.
ChangeLog v8->v9:
- Added Jean-Christophe PLAGNIOL-VILLARD's ACK.
---
drivers/video/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 22262a3..dade5b7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -364,7 +364,7 @@ config FB_SA1100
config FB_IMX
tristate "Freescale i.MX1/21/25/27 LCD support"
- depends on FB && IMX_HAVE_PLATFORM_IMX_FB
+ depends on FB && ARCH_MXC
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.9.5
^ permalink raw reply related
* [PATCHv14][ 4/4] ARM: dts: imx25: mbimxsd25: Add displays support.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390410577-22073-1-git-send-email-denis@eukrea.com>
The CMO-QVGA(With backlight), DVI-VGA and DVI-SVGA displays
were added.
Cc: Eric B?nard <eric@eukrea.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v13->v14:
- Remove people not concerned by this patch from the Cc list.
- changed the fsl,pwmr lcdc property to fsl,lpccr,
to match the previous patches in that serie.
ChangeLog v10->v13:
- This patch is the display part splitted out from the patch adding
support for the cpuimx25(and its baseboard).
- Shawn Guo was added to the Cc list.
- The regulator part was updated to match the current style.
- The new GPIO defines are now used in the dts(i).
---
.../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 72 ++++++++++++++++++++
.../imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts | 45 ++++++++++++
.../imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts | 45 ++++++++++++
3 files changed, 162 insertions(+)
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
new file mode 100644
index 0000000..9de68de
--- /dev/null
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * 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 option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx25-eukrea-mbimxsd25-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD25 with the CMO-QVGA Display";
+ compatible = "eukrea,mbimxsd25-baseboard-cmo-qvga", "eukrea,mbimxsd25-baseboard", "eukrea,cpuimx25", "fsl,imx25";
+
+ cmo_qvga: display {
+ model = "CMO-QVGA";
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xcad08b80>;
+ bus-width = <18>;
+ native-mode = <&qvga_timings>;
+ display-timings {
+ qvga_timings: 320x240 {
+ clock-frequency = <6500000>;
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <30>;
+ hfront-porch = <38>;
+ vback-porch = <20>;
+ vfront-porch = <3>;
+ hsync-len = <15>;
+ vsync-len = <4>;
+ };
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_lcd_3v3: regulator at 0 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+};
+
+&iomuxc {
+ imx25-eukrea-mbimxsd25-baseboard-cmo-qvga {
+ pinctrl_reg_lcd_3v3: reg_lcd_3v3 {
+ fsl,pins = <MX25_PAD_PWM__GPIO_1_26 0x80000000>;
+ };
+ };
+};
+
+&lcdc {
+ display = <&cmo_qvga>;
+ fsl,lpccr = <0x00a903ff>;
+ lcd-supply = <®_lcd_3v3>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
new file mode 100644
index 0000000..8eee2f6
--- /dev/null
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * 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 option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx25-eukrea-mbimxsd25-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD25 with the DVI-SVGA Display";
+ compatible = "eukrea,mbimxsd25-baseboard-dvi-svga", "eukrea,mbimxsd25-baseboard", "eukrea,cpuimx25", "fsl,imx25";
+
+ dvi_svga: display {
+ model = "DVI-SVGA";
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xfa208b80>;
+ bus-width = <18>;
+ native-mode = <&dvi_svga_timings>;
+ display-timings {
+ dvi_svga_timings: 800x600 {
+ clock-frequency = <40000000>;
+ hactive = <800>;
+ vactive = <600>;
+ hback-porch = <75>;
+ hfront-porch = <75>;
+ vback-porch = <7>;
+ vfront-porch = <75>;
+ hsync-len = <7>;
+ vsync-len = <7>;
+ };
+ };
+ };
+};
+
+&lcdc {
+ display = <&dvi_svga>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
new file mode 100644
index 0000000..447da62
--- /dev/null
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * 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 option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx25-eukrea-mbimxsd25-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD25 with the DVI-VGA Display";
+ compatible = "eukrea,mbimxsd25-baseboard-dvi-vga", "eukrea,mbimxsd25-baseboard", "eukrea,cpuimx25", "fsl,imx25";
+
+ dvi_vga: display {
+ model = "DVI-VGA";
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xfa208b80>;
+ bus-width = <18>;
+ native-mode = <&dvi_vga_timings>;
+ display-timings {
+ dvi_vga_timings: 640x480 {
+ clock-frequency = <31250000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <100>;
+ hfront-porch = <100>;
+ vback-porch = <7>;
+ vfront-porch = <100>;
+ hsync-len = <7>;
+ vsync-len = <7>;
+ };
+ };
+ };
+};
+
+&lcdc {
+ display = <&dvi_vga>;
+ status = "okay";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] arm64: Add macros to manage processor debug state
From: Will Deacon @ 2014-01-22 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390401773-12100-2-git-send-email-vijay.kilari@gmail.com>
Hello,
On Wed, Jan 22, 2014 at 02:42:48PM +0000, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>
> Add macros to enable and disable to manage PSTATE.D
> for debugging. The macros local_dbg_save and local_dbg_restore
> are moved to irqflags.h file
>
> KGDB boot tests fail because of PSTATE.D is masked.
> unmask it for debugging support
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
> arch/arm64/include/asm/debug-monitors.h | 18 ++----------------
> arch/arm64/include/asm/irqflags.h | 22 ++++++++++++++++++++++
> arch/arm64/kernel/debug-monitors.c | 3 ++-
> 3 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> index 6231479..bc48880 100644
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -43,22 +43,8 @@ enum debug_el {
> #ifndef __ASSEMBLY__
> struct task_struct;
>
> -#define local_dbg_save(flags) \
> - do { \
> - typecheck(unsigned long, flags); \
> - asm volatile( \
> - "mrs %0, daif // local_dbg_save\n" \
> - "msr daifset, #8" \
> - : "=r" (flags) : : "memory"); \
> - } while (0)
> -
> -#define local_dbg_restore(flags) \
> - do { \
> - typecheck(unsigned long, flags); \
> - asm volatile( \
> - "msr daif, %0 // local_dbg_restore\n" \
> - : : "r" (flags) : "memory"); \
> - } while (0)
> +#define local_dbg_enable() asm("msr daifclr, #8" : : : "memory")
> +#define local_dbg_disable() asm("msr daifset, #8" : : : "memory")
Any reason not to move these to irqflags.h too?
> #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
>
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index b2fcfbc..f163b11 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -90,5 +90,27 @@ static inline int arch_irqs_disabled_flags(unsigned long flags)
> return flags & PSR_I_BIT;
> }
>
> +/*
> + * save and restore debug state
> + */
> +static inline unsigned long local_dbg_save(void)
> +{
> + unsigned long flags;
> + asm volatile(
> + "mrs %0, daif // local_dbg_save"
> + "msr daifset, #8"
> + : "=r" (flags) : : "memory");
> + return flags;
> +}
> +
> +static inline void local_dbg_restore(unsigned long flags)
> +{
> + asm volatile(
> + "msr daif, %0 // local_dbg_restore"
> + :
> + : "r" (flags)
> + : "memory");
> +}
> +
> #endif
> #endif
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 23586bd..774ad04 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -51,7 +51,7 @@ u8 debug_monitors_arch(void)
> static void mdscr_write(u32 mdscr)
> {
> unsigned long flags;
> - local_dbg_save(flags);
> + flags = local_dbg_save();
Why are you changing the API? This is now pointlessly different to irqs.
Will
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Jason Gunthorpe @ 2014-01-22 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122164904.GB27273@localhost>
On Wed, Jan 22, 2014 at 01:49:05PM -0300, Ezequiel Garcia wrote:
> > Looking at this patch in isolation it looks to me like the clear
> > bridge lines should be replaced with a request_irq (as that does the
> > clear) - is the request_irq in the wrong spot?
>
> First of all, it seems to me that the first item "Disable WDT" is not
> currently true on this driver. orion_wdt_start() seem to reset the
> counter, but doesn't clear the WDT_EN bit. Do you think we should
> enforce a "true" disable?
I think so.
> Regarding the sequence. Let me see if I got this problem right. The
> concern here is about the bootloader leaving the registers in a
> weird-state, right?
It isn't just bootloaders to worry about, but also things like kexec..
> In that case, I thought that requesting the IRQ at probe time was enough
> to ensure the BRIDGE_CAUSE would be cleared by the time the watchdog is
> started. However, after reading through the irqchip code again, I'm no longer
> sure this is the case.
The watchdog should ideally be fully stopped before request_irq so
there is no possible race.
> It looks like the BRIDGE_CAUSE register is cleared when the interruption
> is acked (which happens in the handler if I understood the code right).
> So requesting the IRQ is useless...
IMHO, the IRQ stuff should clear out pending edge triggered interrupts
at request_irq time. It makes no sense to take an interrupt for a
stale edge event.
I had always assumed the core code did this via irq_gc_ack_clr_bit -
but I don't see an obvious path..
> Sebastian: If the above is correct, do you think we can add a cause clear to
> the orion irqchip? (supposing it's harmful) Something like this:
Hrm, irq_startup looks like the right hook to put something like this
in.
Jason
^ permalink raw reply
* alloc priv buffer for s5p-mfc
From: randy @ 2014-01-22 17:37 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello
When I was try v4l2-mfc-encoder from samsung, I got the problem below
In my kernel config, mfc buffer is in
samsung,mfc-r = <0x43000000 0x800000>;
samsung,mfc-l = <0x51000000 0x800000>;
Shall I change CONFIG_CMA_SIZE_MBYTES to bigger size?
Or I shall alloc mfc's buffer in the other place, which area of ram
can be used as a replacement?
======================logs begin==============================
root at kagami:~/v4l2-mfc-encoder# ./mfc-encode -m /dev/video1 -c h264
mfc codec encoding example application
Andrzej Hajda <a.hajda@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.
195.444284217:args.c:parse_args:187: codec: H264
195.459693300:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3
195.475634300:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16
buffers for device 3:0
195.475773925:func_dev.c:func_req_bufs:42: Succesfully requested 16
buffers for device -1:1
195.475943092:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1
195.476096592:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1
195.476259925:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1
195.476402425:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1
195.476548800:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1
195.476736300:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1
195.476903508:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1
195.477073675:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1
195.477238675:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1
195.477391550:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1
195.477559758:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1
195.477722842:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1
195.477901092:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1
195.478065717:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1
195.478253383:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1
195.478427675:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1
v4l_dev.c:v4l_req_bufs:111: error: Failed to request 4 buffers for
device 3:1)
the dmesg show
[ 195.525000] (null): dma_alloc_coherent of size 2097152 failed
[ 195.525000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[ 195.525000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
Bank1 temporary buffer
[ 195.525000] vidioc_reqbufs:1117: Failed to allocate encoding buffers
When I tried program which is written by me(request 16 buffers, but
eacho on is for 640*480, much bigger than mfc-encode)
I got the below in dmesg
[ 230.245000] (null): dma_alloc_coherent of size 155648 failed
[ 230.245000] vidioc_querybuf:1178: error in vb2_querybuf() for E(S)
[ 230.280000] (null): dma_alloc_coherent of size 2097152 failed
[ 230.285000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[ 230.285000] s5p_mfc_alloc_codec_buffers_v5:186: Failed to allocate
Bank2 temporary buffer
[ 230.285000] vidioc_reqbufs:1117: Failed to allocate encoding buffers
Then when I was trying mfc-encode again, I got
root at kagami:~/v4l2-mfc-encoder# ./mfc-encode -m /dev/video1 -c h264
mfc codec encoding example application
Andrzej Hajda <a.hajda@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.
265.245904000:args.c:parse_args:187: codec: H264
265.260920417:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3
265.276771750:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16
buffers for device 3:0
265.276913708:func_dev.c:func_req_bufs:42: Succesfully requested 16
buffers for device -1:1
265.277080750:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1
265.277237833:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1
265.277381833:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1
265.277526708:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1
265.277673000:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1
265.277816542:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1
265.277962375:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1
265.278109792:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1
265.278253917:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1
265.278404958:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1
265.278548417:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1
265.278701792:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1
265.278846542:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1
265.278993708:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1
265.279142042:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1
265.279294542:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1
265.315370875:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 4
buffers for device 3:1
265.315490750:func_dev.c:func_req_bufs:42: Succesfully requested 2
buffers for device 4:0
265.315692417:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 0/2 to 3:1
265.315892667:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 1/2 to 3:1
State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/250] [Off 0 0/0|Off 2 0/0]
[Off 0 0/0|Off 0 0/0]
State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/250] [Off 0 0/0|Off 2 0/0]
[Off 0 0/0|Off 0 0/0]
265.316897875:func_dev.c:func_deq_buf:79: Dequeued buffer 0/16 from
- -1:1 ret=25344
v4l_dev.c:v4l_enq_buf:207: error: Error 22 enq buffer 0/16 to 3:0
265.317128125:io_dev.c:process_chain:165: pair 0:1 ret=-1
Then dmesg show that
[ 265.310000] (null): dma_alloc_coherent of size 2097152 failed
====================logs end======================================
Thank you
ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJS4AHBAAoJEPb4VsMIzTziGbMIAMYuuY4SNIczIn4PmmbjRjcQ
NhaeOqjtbSaeLJWfpKiPBe8yDKgSklCEuddhIcJh1Y9v1GsjpUD5BmTerObGNHWM
jWUvfMpxD7hrbjvqqrwAEWZ7U9lgyAPip2SdPLsEThkIaj0l1IreNvPzYKlXzr59
JGyP155QjIWlZiOoR5yH79s60ZOZoiQnO5d7z0ECyPyIgt3GBAXEBkqksO333O1C
PeeGxDYnZc8zB60tbP+nWIJ0NRH9fxp7J8/9ULt9OwCFcZPDLuEMXMucfszicxXo
TK/C47JdUPnBWmZ5Dz+v2siyL8ubWAzkgk89WB4qtWDejndVcRy9r264va5Z0Ng=
=odW8
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 2/6] arm64: Add function to create identity mappings
From: Catalin Marinas @ 2014-01-22 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389392950-22457-3-git-send-email-msalter@redhat.com>
On Fri, Jan 10, 2014 at 10:29:06PM +0000, Mark Salter wrote:
> +void __init create_id_mapping(phys_addr_t addr, phys_addr_t size)
> +{
> + pgd_t *pgd = &idmap_pg_dir[pgd_index(addr)];
> +
> + if (pgd >= &idmap_pg_dir[ARRAY_SIZE(idmap_pg_dir)]) {
> + pr_warn("BUG: not creating id mapping for 0x%016llx\n", addr);
> + return;
> + }
The condition above is always false since pgd_index() already ands the
index with (PTRS_PER_PGD - 1). Better check addr against something like
(PTRS_PER_PGD * PGDIR_SIZE) (for clarity, you could do other shifts,
doesn't really matter).
--
Catalin
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-22 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122173417.GT18269@obsidianresearch.com>
On Wed, Jan 22, 2014 at 10:34:17AM -0700, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 01:49:05PM -0300, Ezequiel Garcia wrote:
> > > Looking at this patch in isolation it looks to me like the clear
> > > bridge lines should be replaced with a request_irq (as that does the
> > > clear) - is the request_irq in the wrong spot?
> >
> > First of all, it seems to me that the first item "Disable WDT" is not
> > currently true on this driver. orion_wdt_start() seem to reset the
> > counter, but doesn't clear the WDT_EN bit. Do you think we should
> > enforce a "true" disable?
>
> I think so.
>
> > Regarding the sequence. Let me see if I got this problem right. The
> > concern here is about the bootloader leaving the registers in a
> > weird-state, right?
>
> It isn't just bootloaders to worry about, but also things like kexec..
>
> > In that case, I thought that requesting the IRQ at probe time was enough
> > to ensure the BRIDGE_CAUSE would be cleared by the time the watchdog is
> > started. However, after reading through the irqchip code again, I'm no longer
> > sure this is the case.
>
> The watchdog should ideally be fully stopped before request_irq so
> there is no possible race.
>
Agreed. So, let's assume we can guarantee that request_irq() does the
job of clearing the cause register (clearing pending irqs).
So, your suggestion is to put request_irq() in the watchdog start()?
Otherwise, we can ensure a watchdog full stop at probe(), before
requesting the IRQ. Both solutions should work, uh?
I don't have a strong opinion. It's not like the watchdog is going to be
frequently started/stopped (right?) so we can easily do the
request_irq() in the start() without worrying.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Jason Gunthorpe @ 2014-01-22 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122174539.GD27273@localhost>
On Wed, Jan 22, 2014 at 02:45:40PM -0300, Ezequiel Garcia wrote:
> Agreed. So, let's assume we can guarantee that request_irq() does the
> job of clearing the cause register (clearing pending irqs).
>
> So, your suggestion is to put request_irq() in the watchdog start()?
>
> Otherwise, we can ensure a watchdog full stop at probe(), before
> requesting the IRQ. Both solutions should work, uh?
Right, I would keep the request_irq in probe, just because that feels
more idiomatic..
Jason
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: John Tobias @ 2014-01-22 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122164100.GE15937@n2100.arm.linux.org.uk>
I ran the kernel in our custom board and I've seen the error after
(sometimes 10 minutes after) the reboot and sometimes my board ran for
an hour or so before it happened.
I will try the 3.13-rc8 today and will see if the said bug still exist or not.
Regards,
john
On Wed, Jan 22, 2014 at 8:41 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>> Hello all,
>>
>> I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>> eMMC running SDR50.
>> Is anyone here encountered these problem and if there's any existing
>> patch that I can get?.
>
> How reproducable is this? I notice you're using 3.13-rc1 too, it could
> be the bug has already been fixed in a later kernel version. -rc1
> kernels are really the "fresh after lots of new feature merging" kernels
> which should always be expected to be rather buggy.
>
> Linux kernel "release candidates" are not "we think this is going to be
> a final kernel, please test it" but -rc1 marks the end of the new
> feature merging and the beginning of the stablisation phase.
>
> --
> FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
> in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
> Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: Stephen Boyd @ 2014-01-22 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEjAshrxXLJ-zFsTO9TnewYBBEPzFR1cixbLnD6U-U1EKdByxg@mail.gmail.com>
On 01/21/14 21:23, SeongJae Park wrote:
> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>> Dear Greg, Mike,
>>>
>>> May I ask your answer or other opinion, please?
>> It's the middle of the merge window, it's not time for new development,
>> or much time for free-time for me, sorry. Feel free to fix it the best
>> way you know how.
> Oops, I've forgot about the merge window. Thank you very much for your
> kind answer.
> Sorry if I bothered you while you're in busy time.
> Because the build problem is not a big deal because it exists only in
> -next tree,
> I will wait until merge window be closed and then fix it again if it
> still exist.
>
I've already sent a patch that exports this and other clock provider
functions. Please use this one:
https://patchwork.kernel.org/patch/3507921/
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Ezequiel Garcia @ 2014-01-22 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122162136.GA27273@localhost>
On Wed, Jan 22, 2014 at 01:21:36PM -0300, Ezequiel Garcia wrote:
> > I don't see a good way out that would preserve backwards compatibility,
> > other than hardcoding the physical address in the driver, which seems
> > just as bad as breaking compatibility. That said, it is always the
> > same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
> > Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
> > a fallback would technically work, but we should print a fat warning at
> > boot time if we actually fall back to that.
> >
>
> Yes, I was thinking just about this. Namely:
>
[..]
How about something like this?
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index a861b88..0014d23 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -26,6 +26,9 @@
#include <linux/of.h>
#include <mach/bridge-regs.h>
+/* RSTOUT mask register physical address for Orion5x, Kirkwood and Dove */
+#define ORION_RSTOUT_MASK 0xf1020108
+
/*
* Watchdog timer block registers.
*/
@@ -119,6 +122,30 @@ static irqreturn_t orion_wdt_irq(int irq, void *devid)
return IRQ_HANDLED;
}
+/*
+ * The original devicetree binding for this driver specified only
+ * one memory resource, so in order to keep DT backwards compatibility
+ * we try to fallback to a hardcoded register address, if the resource
+ * is missing from the devicetree.
+ */
+static void __iomem * try_compat_rstout_ioremap(struct platform_device *pdev)
+{
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (res)
+ return devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
+
+ /* This workaround works only for "orion-wdt", DT-enabled */
+ if (!of_device_is_compatible(pdev->dev.of_node, "marvell,orion-wdt"))
+ return NULL;
+
+ dev_warn(&pdev->dev, "falling back to harcoded RSTOUT reg 0x%x\n",
+ ORION_RSTOUT_MASK);
+ return devm_ioremap(&pdev->dev, ORION_RSTOUT_MASK, 0x4);
+}
+
static int orion_wdt_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -139,10 +166,7 @@ static int orion_wdt_probe(struct platform_device *pdev)
if (!wdt_reg)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res)
- return -ENODEV;
- wdt_rstout = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ wdt_rstout = try_compat_rstout_ioremap(pdev);
if (!wdt_rstout)
return -ENOMEM;
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply related
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-22 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122175030.GU18269@obsidianresearch.com>
On Wed, Jan 22, 2014 at 10:50:30AM -0700, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 02:45:40PM -0300, Ezequiel Garcia wrote:
>
> > Agreed. So, let's assume we can guarantee that request_irq() does the
> > job of clearing the cause register (clearing pending irqs).
> >
> > So, your suggestion is to put request_irq() in the watchdog start()?
> >
> > Otherwise, we can ensure a watchdog full stop at probe(), before
> > requesting the IRQ. Both solutions should work, uh?
>
> Right, I would keep the request_irq in probe, just because that feels
> more idiomatic..
>
Done. Baking v4...
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/6] arm64: add EFI stub
From: Catalin Marinas @ 2014-01-22 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389392950-22457-5-git-send-email-msalter@redhat.com>
On Fri, Jan 10, 2014 at 10:29:08PM +0000, Mark Salter wrote:
> +ENTRY(efi_stub_entry)
> + stp x29, x30, [sp, #-32]!
> +
> + /*
> + * Call efi_entry to do the real work.
> + * x0 and x1 are already set up by firmware. Current runtime
> + * address of image is calculated and passed via *image_addr.
> + *
> + * unsigned long efi_entry(void *handle,
> + * efi_system_table_t *sys_table,
> + * unsigned long *image_addr) ;
> + */
> + adrp x8, _text
> + add x8, x8, #:lo12:_text
Possibly some minor whitespace corruption (or it's our email server).
--
Catalin
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: Mike Turquette @ 2014-01-22 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E00703.5080001@codeaurora.org>
On Wed, Jan 22, 2014 at 9:59 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 01/21/14 21:23, SeongJae Park wrote:
>> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>>> Dear Greg, Mike,
>>>>
>>>> May I ask your answer or other opinion, please?
>>> It's the middle of the merge window, it's not time for new development,
>>> or much time for free-time for me, sorry. Feel free to fix it the best
>>> way you know how.
>> Oops, I've forgot about the merge window. Thank you very much for your
>> kind answer.
>> Sorry if I bothered you while you're in busy time.
>> Because the build problem is not a big deal because it exists only in
>> -next tree,
>> I will wait until merge window be closed and then fix it again if it
>> still exist.
>>
>
> I've already sent a patch that exports this and other clock provider
> functions. Please use this one:
>
> https://patchwork.kernel.org/patch/3507921/
I'm going to take Stephen's patch into a fixes branch and send it as
part of a pull request. Maybe -rc1 or -rc2 at the latest.
Thanks all.
Regards,
Mike
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Mark Brown @ 2014-01-22 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122163322.GF24288@e102568-lin.cambridge.arm.com>
On Wed, Jan 22, 2014 at 04:33:22PM +0000, Lorenzo Pieralisi wrote:
> On Wed, Jan 22, 2014 at 11:42:32AM +0000, Mark Brown wrote:
> > Would it not be sensible to define a PSCI binding that extends this and
> > other bindings - ISTR some other properties getting scattered into
> > bindings for it?
> You mean adding the properties in the PSCI bindings instead of defining
> them here ? Let me think about this, I really reckon these are C-state
Yes.
> specific properties that belong in here (but actually I have to add
> a statement related to PSCI - ie bindings require a PSCI node to be
> present and valid), I will look into this.
It depends how you think about it - something like PSCI is going to to
define properties used in a bunch of different parts of the low level
code, it seems reasonable for things like this to say that the user
should refer to the binding for the firmware to find out what options
that firmware requires and can support rather than having to refer to
each individual place and have those places enumerate the options for
each firmware.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/6f4b6644/attachment.sig>
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Jason Gunthorpe @ 2014-01-22 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122180100.GE27273@localhost>
On Wed, Jan 22, 2014 at 03:01:01PM -0300, Ezequiel Garcia wrote:
> On Wed, Jan 22, 2014 at 01:21:36PM -0300, Ezequiel Garcia wrote:
> > > I don't see a good way out that would preserve backwards compatibility,
> > > other than hardcoding the physical address in the driver, which seems
> > > just as bad as breaking compatibility. That said, it is always the
> > > same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
> > > Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
> > > a fallback would technically work, but we should print a fat warning at
> > > boot time if we actually fall back to that.
> > >
> >
> > Yes, I was thinking just about this. Namely:
> >
> [..]
>
> How about something like this?
I liked Arnd's idea to use an offset from the first register. With the
mbus driver we can now actually change the 0xF1.. prefix via the DT.
> + dev_warn(&pdev->dev, "falling back to harcoded RSTOUT reg 0x%x\n",
> + ORION_RSTOUT_MASK);
Maybe:
dev_warn(&pdev->dev, FW_BUG "falling back to harcoded RSTOUT reg 0x%x\n",
?
> @@ -139,10 +166,7 @@ static int orion_wdt_probe(struct platform_device *pdev)
> if (!wdt_reg)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - if (!res)
> - return -ENODEV;
> - wdt_rstout = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + wdt_rstout = try_compat_rstout_ioremap(pdev);
> if (!wdt_rstout)
> return -ENOMEM;
ENOMEM is probably not the right errno? Is there a standard errno for
malformed DT?
Jason
^ permalink raw reply
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-22 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122112847.GG1621@mudshark.cambridge.arm.com>
On 1/22/2014 3:28 AM, Will Deacon wrote:
> Hi Laura,
>
> On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
>> arm64 currently lacks support for -fstack-protector. Add
>> similar functionality to arm to detect stack corruption.
>>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> ---
>> arch/arm64/Kconfig | 12 +++++++++
>> arch/arm64/Makefile | 4 +++
>> arch/arm64/include/asm/stackprotector.h | 38 +++++++++++++++++++++++++++++++
>> arch/arm64/kernel/process.c | 9 +++++++
>> 4 files changed, 63 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm64/include/asm/stackprotector.h
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 6d4dd22..4f86874 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -168,6 +168,18 @@ config HOTPLUG_CPU
>> Say Y here to experiment with turning CPUs off and on. CPUs
>> can be controlled through /sys/devices/system/cpu.
>>
>> +config CC_STACKPROTECTOR
>> + bool "Enable -fstack-protector buffer overflow detection"
>> + help
>> + This option turns on the -fstack-protector GCC feature. This
>> + feature puts, at the beginning of functions, a canary value on
>> + the stack just before the return address, and validates
>> + the value just before actually returning. Stack based buffer
>> + overflows (that need to overwrite this return address) now also
>> + overwrite the canary, which gets detected and the attack is then
>> + neutralized via a kernel panic.
>> + This feature requires gcc version 4.2 or above.
>
> You can remove that bit about GCC -- GCC 4.2 doesn't support AArch64.
>
Yeah, copied and pasted from ARM
>> +
>> source kernel/Kconfig.preempt
>>
>> config HZ
>> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
>> index 2fceb71..1ce221e 100644
>> --- a/arch/arm64/Makefile
>> +++ b/arch/arm64/Makefile
>> @@ -48,6 +48,10 @@ core-$(CONFIG_XEN) += arch/arm64/xen/
>> libs-y := arch/arm64/lib/ $(libs-y)
>> libs-y += $(LIBGCC)
>>
>> +ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
>> +KBUILD_CFLAGS +=-fstack-protector
>> +endif
>> +
>> # Default target when executing plain make
>> KBUILD_IMAGE := Image.gz
>> KBUILD_DTBS := dtbs
>> diff --git a/arch/arm64/include/asm/stackprotector.h b/arch/arm64/include/asm/stackprotector.h
>> new file mode 100644
>> index 0000000..de00332
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/stackprotector.h
>> @@ -0,0 +1,38 @@
>> +/*
>> + * GCC stack protector support.
>> + *
>> + * Stack protector works by putting predefined pattern at the start of
>> + * the stack frame and verifying that it hasn't been overwritten when
>> + * returning from the function. The pattern is called stack canary
>> + * and gcc expects it to be defined by a global variable called
>> + * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
>> + * we cannot have a different canary value per task.
>> + */
>> +
>> +#ifndef _ASM_STACKPROTECTOR_H
>
> __ASM_ for consistency.
>
>> +#define _ASM_STACKPROTECTOR_H 1
>
> Why #define explicitly to 1?
>
Again, borrowed from ARM. I'll remove it.
>> +
>> +#include <linux/random.h>
>> +#include <linux/version.h>
>> +
>> +extern unsigned long __stack_chk_guard;
>> +
>> +/*
>> + * Initialize the stackprotector canary value.
>> + *
>> + * NOTE: this must only be called from functions that never return,
>> + * and it must always be inlined.
>> + */
>> +static __always_inline void boot_init_stack_canary(void)
>> +{
>> + unsigned long canary;
>> +
>> + /* Try to get a semi random initial value. */
>> + get_random_bytes(&canary, sizeof(canary));
>> + canary ^= LINUX_VERSION_CODE;
>> +
>> + current->stack_canary = canary;
>> + __stack_chk_guard = current->stack_canary;
>> +}
>> +
>> +#endif /* _ASM_STACKPROTECTOR_H */
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index de17c89..592d630 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -50,6 +50,12 @@
>> #include <asm/processor.h>
>> #include <asm/stacktrace.h>
>>
>> +#ifdef CONFIG_CC_STACKPROTECTOR
>> +#include <linux/stackprotector.h>
>> +unsigned long __stack_chk_guard __read_mostly;
>> +EXPORT_SYMBOL(__stack_chk_guard);
>> +#endif
>> +
>> static void setup_restart(void)
>> {
>> /*
>> @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct *prev,
>> {
>> struct task_struct *last;
>>
>> +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
>> + __stack_chk_guard = next->stack_canary;
>> +#endif
>
> I don't get the dependency on !SMP. Assumedly, the update of
> __stack_chk_guard would be racy otherwise, but that sounds solvable with
> atomics. Is the stack_canary updated periodically somewhere else?
>
It has nothing to do with atomics, it's the fact that __stack_chk_guard
is a global variable and with SMP you can have n different processes
running each with a different canary (see kernel/fork.c,
dup_task_struct) . c.f the commit added by Nicolas Pitre:
commit df0698be14c6683606d5df2d83e3ae40f85ed0d9
Author: Nicolas Pitre <nico@fluxnic.net>
Date: Mon Jun 7 21:50:33 2010 -0400
ARM: stack protector: change the canary value per task
A new random value for the canary is stored in the task struct whenever
a new task is forked. This is meant to allow for different canary
values
per task. On ARM, GCC expects the canary value to be found in a global
variable called __stack_chk_guard. So this variable has to be updated
with the value stored in the task struct whenever a task switch occurs.
Because the variable GCC expects is global, this cannot work on SMP
unfortunately. So, on SMP, the same initial canary value is kept
throughout, making this feature a bit less effective although it is
still
useful.
One way to overcome this GCC limitation would be to locate the
__stack_chk_guard variable into a memory page of its own for each CPU,
and then use TLB locking to have each CPU see its own page at the same
virtual address for each of them.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Will
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Mark Brown @ 2014-01-22 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122162313.GE24288@e102568-lin.cambridge.arm.com>
On Wed, Jan 22, 2014 at 04:23:14PM +0000, Lorenzo Pieralisi wrote:
> On Wed, Jan 22, 2014 at 11:52:14AM +0000, Mark Brown wrote:
> > Actually looking at the OPP binding I do wonder if it might not be
> > better to have a v2/rich binding for them which is extensible - the fact
> > that it's not possible to add additional information seems like an
> > issue, this can't be the only thing anyone might want to add and lining
> > up multiple tables is never fun.
> On one hand OPP bindings need improvement and that's on the cards. I am not
> really following what you mean by "extensible", I only want to make sure
> that the C-state bindings do not become too complex.
By extensible I guess I mostly mean not just a list of numbers we can't
add additional information to without breaking compatibility. Having to
look through tables and make sure they all use the same indexes gets
error prone and generally miserable.
> Do you mean extending OPP bindings to add eg C-state information there
> (or whatever piece of information that is OPP dependent) ?
> It seems a bit of a stretch but I can think about that.
> I think that C-state properties are better defined in the C-state bindings
> that was the idea but I am open to suggestions.
I think defining in these bindings makes total sense, it's just
providing an extension to the OPP binding (which is already being looked
at anyway). The exensibility issue I see is that with the current OPP
binding it's inelegant for another binding to add extra information
about an operating point relevant to that binding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/8bda54c7/attachment.sig>
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Arnd Bergmann @ 2014-01-22 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122181409.GV18269@obsidianresearch.com>
On Wednesday 22 January 2014 11:14:09 Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 03:01:01PM -0300, Ezequiel Garcia wrote:
> > On Wed, Jan 22, 2014 at 01:21:36PM -0300, Ezequiel Garcia wrote:
> > > > I don't see a good way out that would preserve backwards compatibility,
> > > > other than hardcoding the physical address in the driver, which seems
> > > > just as bad as breaking compatibility. That said, it is always the
> > > > same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
> > > > Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
> > > > a fallback would technically work, but we should print a fat warning at
> > > > boot time if we actually fall back to that.
> > > >
> > >
> > > Yes, I was thinking just about this. Namely:
> > >
> > [..]
> >
> > How about something like this?
>
> I liked Arnd's idea to use an offset from the first register. With the
> mbus driver we can now actually change the 0xF1.. prefix via the DT.
That wasn't actually my idea, but it does sound reasonable.
> > + dev_warn(&pdev->dev, "falling back to harcoded RSTOUT reg 0x%x\n",
> > + ORION_RSTOUT_MASK);
>
> Maybe:
> dev_warn(&pdev->dev, FW_BUG "falling back to harcoded RSTOUT reg 0x%x\n",
I was thinking of WARN_ON(), i.e. something that users will actually notice ;-)
> > @@ -139,10 +166,7 @@ static int orion_wdt_probe(struct platform_device *pdev)
> > if (!wdt_reg)
> > return -ENOMEM;
> >
> > - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > - if (!res)
> > - return -ENODEV;
> > - wdt_rstout = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> > + wdt_rstout = try_compat_rstout_ioremap(pdev);
> > if (!wdt_rstout)
> > return -ENOMEM;
>
> ENOMEM is probably not the right errno? Is there a standard errno for
> malformed DT?
I don't think so. I'd probably use ENODEV, but it's not ideal.
Arnd
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Ezequiel Garcia @ 2014-01-22 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122181409.GV18269@obsidianresearch.com>
On Wed, Jan 22, 2014 at 11:14:09AM -0700, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 03:01:01PM -0300, Ezequiel Garcia wrote:
> > On Wed, Jan 22, 2014 at 01:21:36PM -0300, Ezequiel Garcia wrote:
> > > > I don't see a good way out that would preserve backwards compatibility,
> > > > other than hardcoding the physical address in the driver, which seems
> > > > just as bad as breaking compatibility. That said, it is always the
> > > > same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
> > > > Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
> > > > a fallback would technically work, but we should print a fat warning at
> > > > boot time if we actually fall back to that.
> > > >
> > >
> > > Yes, I was thinking just about this. Namely:
> > >
> > [..]
> >
> > How about something like this?
>
> I liked Arnd's idea to use an offset from the first register. With the
> mbus driver we can now actually change the 0xF1.. prefix via the DT.
>
Good idea. Maybe extracting the base address from the timer control
register: wdt_reg & 0xff000000 ?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: Add ARMv8 support
From: Christopher Covington @ 2014-01-22 18:29 UTC (permalink / raw)
To: linux-arm-kernel
Add the trivial support necessary to get hardware breakpoints
working for GDB on ARMv8 simulators running in AArch32 mode.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm/include/asm/hw_breakpoint.h | 1 +
arch/arm/kernel/hw_breakpoint.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
index eef55ea..8e427c7 100644
--- a/arch/arm/include/asm/hw_breakpoint.h
+++ b/arch/arm/include/asm/hw_breakpoint.h
@@ -51,6 +51,7 @@ static inline void decode_ctrl_reg(u32 reg,
#define ARM_DEBUG_ARCH_V7_ECP14 3
#define ARM_DEBUG_ARCH_V7_MM 4
#define ARM_DEBUG_ARCH_V7_1 5
+#define ARM_DEBUG_ARCH_V8 6
/* Breakpoint */
#define ARM_BREAKPOINT_EXECUTE 0
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 3d44660..45fbcaf 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -257,6 +257,7 @@ static int enable_monitor_mode(void)
break;
case ARM_DEBUG_ARCH_V7_ECP14:
case ARM_DEBUG_ARCH_V7_1:
+ case ARM_DEBUG_ARCH_V8:
ARM_DBG_WRITE(c0, c2, 2, (dscr | ARM_DSCR_MDBGEN));
isb();
break;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply related
* [PATCH RFC 0/4] reserved-memory regions/CMA in devicetree, again
From: Josh Cartwright @ 2014-01-22 18:58 UTC (permalink / raw)
To: linux-arm-kernel
Hey Marek-
What is the current status of the reserved-memory/CMA device tree support
series? It looks like it's stalled out a bit since the revert[2]. Hopefully
this series is a push in the right direction?
---
This set is an adaptation of Marek's original patchset posted here[1],
and then subsequently reverted here[2]. In [3], Grant proposed a new
set of bindings after discussion in Edinburgh.
This is a partially complete implementation of these proposed bindings.
It's functionality is now split into two pieces, the first of which
implements a default/fallback behavior for reserved-memory nodes; that
is, reserved memory nodes describing fixed-address static regions will
be unconditionally reserved, regardless of their intended use. In
addition, it provides an interface for adding additional reserved-memory
types, using a method similar to CLOCKSOURCE_OF_DECLARE().
The second piece uses the above method to provide support for
reserved-memory nodes whose compatible = "shared-dma-pool". It makes
use of CMA when available, and when a describing node has the 'reusable'
property.
There is basic support for dynamic allocation of memory reserved
regions, however, noticeably missing is support for additional
restrictions (use of alignment and alloc-ranges properties).
[1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski at samsung.com
[2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski at samsung.com
[3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0 at trevor.secretlab.ca
Grant Likely (1):
of: document bindings for reserved-memory nodes
Josh Cartwright (1):
drivers: of: implement reserved-memory handling for dma
Marek Szyprowski (2):
drivers: of: add initialization code for reserved memory
ARM: init: add support for reserved memory defined by device tree
.../bindings/reserved-memory/reserved-memory.txt | 137 +++++++++++++++
arch/arm/mm/init.c | 3 +
drivers/of/Kconfig | 13 ++
drivers/of/Makefile | 2 +
drivers/of/of_reserved_mem.c | 188 +++++++++++++++++++++
drivers/of/of_reserved_mem_dma.c | 178 +++++++++++++++++++
drivers/of/platform.c | 4 +
include/asm-generic/vmlinux.lds.h | 11 ++
include/linux/of_reserved_mem.h | 61 +++++++
9 files changed, 597 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
create mode 100644 drivers/of/of_reserved_mem.c
create mode 100644 drivers/of/of_reserved_mem_dma.c
create mode 100644 include/linux/of_reserved_mem.h
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RFC 1/4] drivers: of: add initialization code for reserved memory
From: Josh Cartwright @ 2014-01-22 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390417133-6650-1-git-send-email-joshc@codeaurora.org>
From: Marek Szyprowski <m.szyprowski@samsung.com>
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>
---
drivers/of/Kconfig | 6 ++
drivers/of/Makefile | 1 +
drivers/of/of_reserved_mem.c | 188 ++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 4 +
include/asm-generic/vmlinux.lds.h | 11 +++
include/linux/of_reserved_mem.h | 61 +++++++++++++
6 files changed, 271 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 c6973f1..aba13df 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 efd0510..ed9660a 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 0000000..9fcafb5
--- /dev/null
+++ b/drivers/of/of_reserved_mem.c
@@ -0,0 +1,188 @@
+/*
+ * 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;
+
+static int __init rmem_default_early_setup(struct reserved_mem *rmem,
+ unsigned long node,
+ const char *uname)
+{
+ unsigned long len;
+ __be32 *prop;
+ int err;
+
+ prop = of_get_flat_dt_prop(node, "reg", &len);
+ if (!prop) {
+ pr_err("reg property missing for reserved-memory node '%s'\n",
+ uname);
+ err = -EINVAL;
+ goto out;
+ }
+
+ if (len < (dt_root_size_cells + dt_root_addr_cells) * sizeof(__be32)) {
+ pr_err("invalid reg property for reserved-memory node '%s'\n",
+ uname);
+ err = -EINVAL;
+ goto out;
+ }
+
+ rmem->base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ rmem->size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ if (of_get_flat_dt_prop(node, "no-map", NULL))
+ err = memblock_remove(rmem->base, rmem->size);
+ else
+ err = memblock_reserve(rmem->base, rmem->size);
+
+ pr_info("Reserved mem: found '%s', memory base %pa, size %ld MiB\n",
+ uname, &rmem->base, (unsigned long)rmem->size / SZ_1M);
+
+out:
+ return err;
+}
+
+static const struct of_device_id rmem_default_id
+ __used __section(__reservedmem_of_table_end) = {
+ .data = rmem_default_early_setup,
+};
+
+static int __init fdt_scan_reserved_mem(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
+ extern const struct of_device_id __reservedmem_of_table[];
+ reservedmem_of_init_fn initfn;
+ const struct of_device_id *id;
+ const char *status;
+
+ if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+ pr_err("Not enough space for reserved-memory regions.\n");
+ return -ENOSPC;
+ }
+
+ status = of_get_flat_dt_prop(node, "status", NULL);
+ if (status && strcmp(status, "okay") != 0)
+ return 0;
+
+ /*
+ * The default handler above ensures this section is terminated with a
+ * id whose compatible string is empty
+ */
+ for (id = __reservedmem_of_table; ; id++) {
+ const char *compat = id->compatible;
+
+ if (!compat[0] || of_flat_dt_is_compatible(node, compat)) {
+ initfn = id->data;
+ break;
+ }
+ }
+
+ if (!initfn(rmem, node, uname)) {
+ strlcpy(rmem->name, uname, sizeof(rmem->name));
+ reserved_mem_count++;
+ }
+
+ return 0;
+}
+
+static struct reserved_mem *find_rmem(struct device_node *np)
+{
+ const char *name;
+ unsigned int i;
+
+ name = kbasename(np->full_name);
+
+ for (i = 0; i < reserved_mem_count; i++)
+ if (strcmp(name, reserved_mem[i].name) == 0)
+ return &reserved_mem[i];
+
+ return NULL;
+}
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given device
+ *
+ * This function assign memory region pointed by "memory-region" device tree
+ * property to the given device.
+ */
+void of_reserved_mem_device_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct reserved_mem *rmem;
+ struct of_phandle_args s;
+ unsigned int i;
+
+ for (i = 0; of_parse_phandle_with_args(np, "memory-region",
+ "#memory-region-cells", i, &s) == 0; i++) {
+
+ rmem = find_rmem(s.np);
+ of_node_put(s.np);
+
+ if (!rmem || !rmem->ops || !rmem->ops->device_init)
+ continue;
+
+ rmem->ops->device_init(rmem, pdev, &s);
+ }
+}
+
+/**
+ * of_reserved_mem_device_release() - release reserved memory device structures
+ *
+ * This function releases structures allocated for memory region handling for
+ * the given device.
+ */
+void of_reserved_mem_device_release(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct reserved_mem *rmem;
+ struct of_phandle_args s;
+ unsigned int i;
+
+ for (i = 0; of_parse_phandle_with_args(np, "memory-region",
+ "#memory-region-cells", i, &s) == 0; i++) {
+
+ rmem = find_rmem(s.np);
+ of_node_put(s.np);
+
+ if (!rmem || !rmem->ops || !rmem->ops->device_release)
+ continue;
+
+ rmem->ops->device_release(rmem, pdev);
+ }
+}
+
+/**
+ * early_init_dt_scan_reserved_mem() - create reserved memory regions
+ *
+ * This function grabs memory from early allocator for device exclusive use
+ * defined in device tree structures. It should be called by arch specific code
+ * once the early allocator (memblock) has been activated and all other
+ * subsystems have already allocated/reserved memory.
+ */
+void __init early_init_dt_scan_reserved_mem(void)
+{
+ of_scan_flat_dt_by_path("/reserved-memory", fdt_scan_reserved_mem,
+ NULL);
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..b6d3cea 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -21,6 +21,7 @@
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
#include <linux/platform_device.h>
const struct of_device_id of_default_bus_match_table[] = {
@@ -220,6 +221,8 @@ static struct platform_device *of_platform_device_create_pdata(
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
+ of_reserved_mem_device_init(dev);
+
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
@@ -227,6 +230,7 @@ static struct platform_device *of_platform_device_create_pdata(
if (of_device_add(dev) != 0) {
platform_device_put(dev);
+ of_reserved_mem_device_release(dev);
return NULL;
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bc2121f..f10f64f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -167,6 +167,16 @@
#define CLK_OF_TABLES()
#endif
+#ifdef CONFIG_OF_RESERVED_MEM
+#define RESERVEDMEM_OF_TABLES() \
+ . = ALIGN(8); \
+ VMLINUX_SYMBOL(__reservedmem_of_table) = .; \
+ *(__reservedmem_of_table) \
+ *(__reservedmem_of_table_end)
+#else
+#define RESERVEDMEM_OF_TABLES()
+#endif
+
#define KERNEL_DTB() \
STRUCT_ALIGN(); \
VMLINUX_SYMBOL(__dtb_start) = .; \
@@ -490,6 +500,7 @@
TRACE_SYSCALLS() \
MEM_DISCARD(init.rodata) \
CLK_OF_TABLES() \
+ RESERVEDMEM_OF_TABLES() \
CLKSRC_OF_TABLES() \
KERNEL_DTB() \
IRQCHIP_OF_MATCH_TABLE()
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
new file mode 100644
index 0000000..a2de510
--- /dev/null
+++ b/include/linux/of_reserved_mem.h
@@ -0,0 +1,61 @@
+#ifndef __OF_RESERVED_MEM_H
+#define __OF_RESERVED_MEM_H
+
+struct cma;
+struct platform_device;
+struct of_phandle_args;
+struct reserved_mem_ops;
+
+struct reserved_mem {
+ const struct reserved_mem_ops *ops;
+ char name[32];
+ union {
+ struct cma *cma;
+ struct {
+ phys_addr_t base;
+ phys_addr_t size;
+ };
+ };
+};
+
+struct reserved_mem_ops {
+ void (*device_init)(struct reserved_mem *rmem,
+ struct platform_device *pdev,
+ struct of_phandle_args *args);
+ void (*device_release)(struct reserved_mem *rmem,
+ struct platform_device *pdev);
+};
+
+typedef int (*reservedmem_of_init_fn)(struct reserved_mem *rmem,
+ unsigned long node, const char *uname);
+
+#ifdef CONFIG_OF_RESERVED_MEM
+void of_reserved_mem_device_init(struct platform_device *pdev);
+void of_reserved_mem_device_release(struct platform_device *pdev);
+void early_init_dt_scan_reserved_mem(void);
+
+#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
+ static const struct of_device_id __reservedmem_of_table_##name \
+ __used __section(__reservedmem_of_table) \
+ = { .compatible = compat, \
+ .data = (init == (reservedmem_of_init_fn)NULL) ? \
+ init : init }
+
+#else
+static inline void of_reserved_mem_device_init(struct platform_device *pdev) { }
+
+static inline
+void of_reserved_mem_device_release(struct platform_device *pdev) { }
+
+static inline void early_init_dt_scan_reserved_mem(void) { }
+
+#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
+ static const struct of_device_id __reservedmem_of_table_##name \
+ __attribute__((unused)) \
+ = { .compatible = compat, \
+ .data = (init == (reservedmem_of_init_fn)NULL) ? \
+ init : init }
+
+#endif
+
+#endif /* __OF_RESERVED_MEM_H */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox