* [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Wan ZongShun @ 2012-10-10 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-8-git-send-email-arnd@arndb.de>
2012/10/10 Arnd Bergmann <arnd@arndb.de>:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
>
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
>
> Without this patch, building nuc950_defconfig results in:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev at vger.kernel.org
Thanks for your patch.
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
> ---
> drivers/video/nuc900fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
> * The buffer should be a non-cached, non-buffered, memory region
> * to allow palette and pixel writes without flushing the cache.
> */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
> {
> struct nuc900fb_info *fbi = info->par;
> dma_addr_t map_dma;
> --
> 1.7.10
>
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply
* [PATCH] ARM: dts: imx28: add the `clock-names` for gpmi-nand
From: Huang Shijie @ 2012-10-10 2:44 UTC (permalink / raw)
To: linux-arm-kernel
The current DT node misses the `clocks-names` item for gpmi-nand.
So the gpmi-nand driver could not find the proper clock.
This patch fixes this issue.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
arch/arm/boot/dts/imx28.dtsi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e16d631..55c57ea 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -85,6 +85,7 @@
interrupts = <88>, <41>;
interrupt-names = "gpmi-dma", "bch";
clocks = <&clks 50>;
+ clock-names = "gpmi_io";
fsl,gpmi-dma-channel = <4>;
status = "disabled";
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH] i2c: i2c-gpio: fix issue when DT node greater than 1
From: Bo Shen @ 2012-10-10 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120919175433.3841a954@endymion.delvare>
Hi Jean Delvare,
On 9/19/2012 23:54, Jean Delvare wrote:
> On Wed, 19 Sep 2012 09:28:04 -0600, Stephen Warren wrote:
>> On 09/18/2012 07:15 PM, Bo Shen wrote:
>>> I add the debug info, and it give the following error without this patch.
>>>
>>> --<8----------------------------------
>>> adap->name = i2c-gpio-1
>>> i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
>>> adap->name = i2c-gpio-1
>>> i2c-gpio: probe of i2c.3 failed with error -16
>>> -->8----------------------------------
>>>
>>> With this patch, it successfully registered.
>>> --<8----------------------------------
>>> adap->name = i2c-gpio0
>>> i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
>>> adap->name = i2c-gpio1
>>> i2c-gpio i2c.3: using pins 90 (SDA) and 91 (SCL)
>>> -->8----------------------------------
>>
>> Yes, that explains why the registration fails, but not why this patch is
>> the correct solution to the problem.
>>
>> The problematic code appears to be:
>>
>> snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
>>
>> Instead, I think that should be something more like:
>>
>> adap->name = dev_name(&pdev->dev);
>
> strlcpy(adap->name, dev_name(&pdev->dev), sizeof(adap->name))
I am sorry for late. I have tested with DT, it works.
Please send this patch to fix the issue.
Thanks.
> if anything, as adap->name is a buffer, not a pointer.
>
>> or perhaps:
>>
>> if (pdev->dev.of_node)
>> /* named will be based on DT node name */
>> adap->name = dev_name(&pdev->dev);
>> else
>> snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
>>
>> ?
>
^ permalink raw reply
* [PATCH v4 1/3] Input: egalax_ts: get gpio from devicetree node
From: Hui Wang @ 2012-10-10 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091158.33040.arnd@arndb.de>
Arnd Bergmann wrote:
> On Friday 17 August 2012, Shawn Guo wrote:
>
>> On Thu, Aug 16, 2012 at 06:47:29PM +0800, Hui Wang wrote:
>>
>>> The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
>>> and don't support this API anymore.
>>>
>>> The i.MX6q sabrelite platform equips an egalax touchscreen controller,
>>> and this platform already transfered to GENERIC_GPIO framework, to
>>> support this driver, we use a more generic way to get gpio.
>>>
>>> Add a return value checking for waking up the controller in the probe
>>> function, this guarantee only a workable device can pass init.
>>>
>>> Signed-off-by: Hui Wang <jason77.wang@gmail.com>
>>>
>> Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
>>
>
> What's the status on this patch? I'm still getting build errors from this
> driver, so I guess it was never accepted for the 3.7 merge window.
>
> Arnd
>
>
I forgot to resend this patchset After Dmitry was back to the maillist.
I will rebase the patchset and resend them to review.
Regards,
Hui.
^ permalink raw reply
* [PATCH 1/2] ARM: mx27_3ds: Reserve memory for camera usage
From: Fabio Estevam @ 2012-10-10 3:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Reserve dedicated memory block for camera usage.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/mach-mx27_3ds.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index 05996f3..d3b9a60 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -30,6 +30,7 @@
#include <linux/spi/spi.h>
#include <linux/regulator/machine.h>
#include <linux/spi/l4f00242t03.h>
+#include <asm/memblock.h>
#include <media/soc_camera.h>
@@ -165,6 +166,9 @@ static const int mx27pdk_pins[] __initconst = {
PC19_PF_SSI4_CLK,
};
+static phys_addr_t mx2_camera_base __initdata;
+#define MX27PDK_CAM_BUF_SIZE SZ_8M
+
static struct gpio mx27_3ds_camera_gpios[] = {
{ CSI_PWRDWN, GPIOF_OUT_INIT_HIGH, "camera-power" },
{ CSI_RESET, GPIOF_OUT_INIT_HIGH, "camera-reset" },
@@ -478,6 +482,24 @@ static const struct mx2_camera_platform_data mx27_3ds_cam_pdata __initconst = {
.clk = 26000000,
};
+static void __init mx27pdk_init_camera(void)
+{
+ struct platform_device *pdev;
+ int dma;
+
+ pdev = imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
+
+ if (IS_ERR(pdev))
+ return;
+
+ dma = dma_declare_coherent_memory(&pdev->dev,
+ mx2_camera_base, mx2_camera_base,
+ MX27PDK_CAM_BUF_SIZE,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
@@ -527,7 +549,7 @@ static void __init mx27pdk_init(void)
iclink_ov2640.power = NULL;
}
- imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
+ mx27pdk_init_camera();
imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
@@ -542,6 +564,13 @@ static struct sys_timer mx27pdk_timer = {
.init = mx27pdk_timer_init,
};
+static void __init mx27pdk_reserve(void)
+{
+ /* reserve MX27_3DS_CAMERA_BUF_SIZE bytes for mx2-camera */
+ mx2_camera_base = arm_memblock_steal(MX27PDK_CAM_BUF_SIZE,
+ MX27PDK_CAM_BUF_SIZE);
+}
+
MACHINE_START(MX27_3DS, "Freescale MX27PDK")
/* maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
@@ -551,5 +580,6 @@ MACHINE_START(MX27_3DS, "Freescale MX27PDK")
.handle_irq = imx27_handle_irq,
.timer = &mx27pdk_timer,
.init_machine = mx27pdk_init,
+ .reserve = mx27pdk_reserve,
.restart = mxc_restart,
MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: mx27_3ds: Add VPU support
From: Fabio Estevam @ 2012-10-10 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349839770-13848-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
mx27 has a VPU (Video Processing Unit) block that allows doing H264/MPEG4
decoding and encoding in hardware.
Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/mach-mx27_3ds.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index d3b9a60..3ef8548 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -500,6 +500,21 @@ static void __init mx27pdk_init_camera(void)
return;
}
+static void __init mx27pdk_init_vpu(void)
+{
+ struct platform_device *pdev;
+ int dma;
+
+ pdev = imx27_add_coda();
+ dma = dma_declare_coherent_memory(&pdev->dev,
+ mx2_camera_base + MX27PDK_CAM_BUF_SIZE,
+ mx2_camera_base + MX27PDK_CAM_BUF_SIZE,
+ MX27PDK_CAM_BUF_SIZE,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
@@ -553,6 +568,7 @@ static void __init mx27pdk_init(void)
imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
+ mx27pdk_init_vpu();
}
static void __init mx27pdk_timer_init(void)
@@ -567,7 +583,7 @@ static struct sys_timer mx27pdk_timer = {
static void __init mx27pdk_reserve(void)
{
/* reserve MX27_3DS_CAMERA_BUF_SIZE bytes for mx2-camera */
- mx2_camera_base = arm_memblock_steal(MX27PDK_CAM_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(3 * MX27PDK_CAM_BUF_SIZE,
MX27PDK_CAM_BUF_SIZE);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Add McSPI devices found in AM33xx SoC to dtsi
From: Philip, Avinash @ 2012-10-10 4:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3608180472966131184@unknownmsgid>
On Tue, Oct 09, 2012 at 19:54:28, Phil Pokorny wrote:
> On Oct 9, 2012, at 3:36 AM, "Philip, Avinash" <avinashphilip@ti.com>
> wrote:
>
> > On Tue, Oct 09, 2012 at 10:40:58, Phil Pokorny wrote:
> >> We're using the BeagleBone for a project and we need the SPI devices
> >> available and configured with all available chip selects.
> >>
> >> Please accept the following patch to add these to the base .dtsi file
> >> so they can then be enabled in the beaglebone specific .dts with
> >> minimal fuss.
> >
> > Patch for adding MCSPI in am33xx.dtsi already been sent by me.
> > https://lkml.org/lkml/2012/9/18/32
>
> Thank you for responding.
>
> Was that accepted? It didn't seem to be in the Linux-omap git tree I
> cloned. I need to check the Torvalds mainline kernel.
It's not accepted.
>
> I believe the number of chip selects on spi1 is incorrect. There is
> only one (1) CS shown in the hardware documentation for AM33xx.
No, number of chip select for SPI 1 is 2. AM33xx TRM says
TRM section
24.1.2 Unsupported McSPI Features
Feature Reason
Chip selects 2 and 3 Not pinned out
Also you can see soc pin outs.
>
> Is OMAP4-McSPI the best match for the hardware?
Yes.
> The mcspi driver appears to differ only in the register offset used.
> A hard coded zero value for omap2 and a named constant for omap4.
> The hardware manual for the AM33xx shows the register map
>starting at zero.
You can see register offset for am33xx (it is defined at offset 0x100).
Hence offset is required in am33xx.
Thanks
Avinash
> Thank you,
> Phil P.
> >
>
^ permalink raw reply
* [PATCH] ARM: dts: imx28: add the `clock-names` for gpmi-nand
From: Fabio Estevam @ 2012-10-10 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349837086-21844-1-git-send-email-b32955@freescale.com>
Hi Huang,
On Tue, Oct 9, 2012 at 11:44 PM, Huang Shijie <b32955@freescale.com> wrote:
> The current DT node misses the `clocks-names` item for gpmi-nand.
> So the gpmi-nand driver could not find the proper clock.
>
> This patch fixes this issue.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
Thanks for the fix.
Could you please also fix mx23 in the same patch?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] ARM: dts: imx28: add the `clock-names` for gpmi-nand
From: Huang Shijie @ 2012-10-10 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A0UX6y3MtHdzZ8V2Z52qsH8Yy-BVtOYEN_OpBezEsvQw@mail.gmail.com>
? 2012?10?10? 12:54, Fabio Estevam ??:
> Hi Huang,
>
> On Tue, Oct 9, 2012 at 11:44 PM, Huang Shijie<b32955@freescale.com> wrote:
>> The current DT node misses the `clocks-names` item for gpmi-nand.
>> So the gpmi-nand driver could not find the proper clock.
>>
>> This patch fixes this issue.
>>
>> Signed-off-by: Huang Shijie<b32955@freescale.com>
> Thanks for the fix.
>
> Could you please also fix mx23 in the same patch?
I am just fixing it now. :)
Huang Shijie
> Regards,
>
> Fabio Estevam
>
^ permalink raw reply
* [PATCH] ARM: dts: mxs: add the `clock-names` for gpmi-nand
From: Huang Shijie @ 2012-10-10 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A0UX6y3MtHdzZ8V2Z52qsH8Yy-BVtOYEN_OpBezEsvQw@mail.gmail.com>
The current DT nodes for mx23/mx28 miss the `clocks-names` item for gpmi-nand.
So the gpmi-nand driver could not find the proper clock.
This patch fixes this issue.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
arch/arm/boot/dts/imx23.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 9ca4ca7..6d31aa3 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -69,6 +69,7 @@
interrupts = <13>, <56>;
interrupt-names = "gpmi-dma", "bch";
clocks = <&clks 34>;
+ clock-names = "gpmi_io";
fsl,gpmi-dma-channel = <4>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e16d631..55c57ea 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -85,6 +85,7 @@
interrupts = <88>, <41>;
interrupt-names = "gpmi-dma", "bch";
clocks = <&clks 50>;
+ clock-names = "gpmi_io";
fsl,gpmi-dma-channel = <4>;
status = "disabled";
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 1/3] Input: egalax_ts: get gpio from devicetree node
From: Arnd Bergmann @ 2012-10-10 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5074EAFC.1010409@gmail.com>
On Wednesday 10 October 2012, Hui Wang wrote:
> >
> > What's the status on this patch? I'm still getting build errors from this
> > driver, so I guess it was never accepted for the 3.7 merge window.
> >
> > Arnd
> >
> >
> I forgot to resend this patchset After Dmitry was back to the maillist.
> I will rebase the patchset and resend them to review.
>
Ok, thank you!
Arnd
^ permalink raw reply
* [PATCH 1/6] ARM: bcm476x: Add infrastructure
From: Arnd Bergmann @ 2012-10-10 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009225837.GA7758@glitch>
On Tuesday 09 October 2012, Domenico Andreoli wrote:
> bcm4760 is the superset (bcm4761 hasn't the gpu) but there are also other
> differences (that I know, USB phy and clocks).
>
> I can identify the SoC at runtime, does this change anything to your
> recommendation?
Not much. The rule not to have wildcards in the device tree strings
is rather universal. For device drivers, the rule should be that the
driver should only look at its own device and the information it can
get about that from the bus (or from the device tree), but should
generally not use interfaces to ask what soc the device is part of.
Otherwise you end up having to modify all device drivers every time
you want to support a new SoC, which is something we want to avoid.
If a new SoC contains some device that is identical to one on an
older SoC, you should just be able to mark it as compatible with the
original string in the device tree.
For the USB PHY and the clock setup, it should be very easy to use
different compatible strings, although for the clock controller it
may also be reasonable to call the initialization function from
platform code and pass the type of controller into it. It may also
be possible that all the differences between the clock implementations
go away once you describe all clocks in the DT itself.
Arnd
^ permalink raw reply
* [PATCH 3/3] ARM: integrator: use __iomem pointers for MMIO, part 2
From: Linus Walleij @ 2012-10-10 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796861-31164-4-git-send-email-arnd@arndb.de>
On Tue, Oct 9, 2012 at 5:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Due to some interesting merges in the integrator code, not
> all users of mmio pointers were converted before, this
> fixes all warnings that got introduced as a consequence.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Yeah I told you it was gonna collide ;-)
Thanks a lot for fixing it up and following through
on this!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/9] ARM: export set_irq_flags
From: Linus Walleij @ 2012-10-10 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-3-git-send-email-arnd@arndb.de>
On Tue, Oct 9, 2012 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
>
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
>
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.
Argh! And I cannot think of anything more elegant so
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: backtrace: avoid crash on large invalid fp value
From: Todd Poynor @ 2012-10-10 6:46 UTC (permalink / raw)
To: linux-arm-kernel
Invalid frame pointer (signed) -4 <= fp <= -1 defeats check for too high
on overflow.
Signed-off-by: Todd Poynor <toddpoynor@google.com>
---
arch/arm/kernel/stacktrace.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..6315162 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame)
high = ALIGN(low, THREAD_SIZE);
/* check current frame pointer is within bounds */
- if (fp < (low + 12) || fp + 4 >= high)
+ if (fp < (low + 12) || fp >= high - 4)
return -EINVAL;
/* restore the registers from the stack frame */
--
1.7.7.3
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Afzal Mohammed @ 2012-10-10 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349773040-8204-1-git-send-email-hvaibhav@ti.com>
On Tuesday 09 October 2012 02:27 PM, Vaibhav Hiremath wrote:
> This patch adds of_have_populated_dt() check before creating
> Signed-off-by: Vaibhav Hiremath<hvaibhav@ti.com>
> Cc: Afzal Mohammed<afzal@ti.com>
Reviewed-by: Afzal Mohammed <afzal@ti.com>
^ permalink raw reply
* [PATCH 1/2] ARM: mx27_3ds: Reserve memory for camera usage
From: Gaëtan Carlier @ 2012-10-10 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349839770-13848-1-git-send-email-festevam@gmail.com>
Hi Fabio,
On 10/10/2012 05:29 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Reserve dedicated memory block for camera usage.
Why camera need to have a dedicated memory block reserved in the
platform file ?
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/mach-mx27_3ds.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
> index 05996f3..d3b9a60 100644
> --- a/arch/arm/mach-imx/mach-mx27_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx27_3ds.c
> @@ -30,6 +30,7 @@
> #include <linux/spi/spi.h>
> #include <linux/regulator/machine.h>
> #include <linux/spi/l4f00242t03.h>
> +#include <asm/memblock.h>
>
> #include <media/soc_camera.h>
>
> @@ -165,6 +166,9 @@ static const int mx27pdk_pins[] __initconst = {
> PC19_PF_SSI4_CLK,
> };
>
> +static phys_addr_t mx2_camera_base __initdata;
> +#define MX27PDK_CAM_BUF_SIZE SZ_8M
> +
> static struct gpio mx27_3ds_camera_gpios[] = {
> { CSI_PWRDWN, GPIOF_OUT_INIT_HIGH, "camera-power" },
> { CSI_RESET, GPIOF_OUT_INIT_HIGH, "camera-reset" },
> @@ -478,6 +482,24 @@ static const struct mx2_camera_platform_data mx27_3ds_cam_pdata __initconst = {
> .clk = 26000000,
> };
>
> +static void __init mx27pdk_init_camera(void)
> +{
> + struct platform_device *pdev;
> + int dma;
> +
> + pdev = imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
> +
> + if (IS_ERR(pdev))
> + return;
> +
> + dma = dma_declare_coherent_memory(&pdev->dev,
> + mx2_camera_base, mx2_camera_base,
> + MX27PDK_CAM_BUF_SIZE,
> + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> + if (!(dma & DMA_MEMORY_MAP))
> + return;
> +}
> +
> static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
> .bitrate = 100000,
> };
> @@ -527,7 +549,7 @@ static void __init mx27pdk_init(void)
> iclink_ov2640.power = NULL;
> }
>
> - imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
> + mx27pdk_init_camera();
> imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
>
> imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
> @@ -542,6 +564,13 @@ static struct sys_timer mx27pdk_timer = {
> .init = mx27pdk_timer_init,
> };
>
> +static void __init mx27pdk_reserve(void)
> +{
> + /* reserve MX27_3DS_CAMERA_BUF_SIZE bytes for mx2-camera */
> + mx2_camera_base = arm_memblock_steal(MX27PDK_CAM_BUF_SIZE,
> + MX27PDK_CAM_BUF_SIZE);
> +}
> +
> MACHINE_START(MX27_3DS, "Freescale MX27PDK")
> /* maintainer: Freescale Semiconductor, Inc. */
> .atag_offset = 0x100,
> @@ -551,5 +580,6 @@ MACHINE_START(MX27_3DS, "Freescale MX27PDK")
> .handle_irq = imx27_handle_irq,
> .timer = &mx27pdk_timer,
> .init_machine = mx27pdk_init,
> + .reserve = mx27pdk_reserve,
> .restart = mxc_restart,
> MACHINE_END
>
Thank you.
Best regards,
Ga?tan Carlier.
^ permalink raw reply
* [PATCH] ARM: OMAP: resolve sparse warning concerning debug_card_init()
From: Igor Grinberg @ 2012-10-10 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210092028080.5736@utopia.booyaka.com>
On 10/09/12 22:29, Paul Walmsley wrote:
>
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse
> warning:
>
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static?
>
> Fix by implementing Tony's suggestion to add a "sideways include" to the
> new location of the debug-devices.h file in arch/arm/mach-omap2/.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> arch/arm/plat-omap/debug-devices.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/plat-omap/debug-devices.c b/arch/arm/plat-omap/debug-devices.c
> index c7a4c09..5a4678e 100644
> --- a/arch/arm/plat-omap/debug-devices.c
> +++ b/arch/arm/plat-omap/debug-devices.c
> @@ -16,6 +16,7 @@
> #include <linux/smc91x.h>
>
> #include <mach/hardware.h>
> +#include "../mach-omap2/debug-devices.h"
>
> /* Many OMAP development platforms reuse the same "debug board"; these
> * platforms include H2, H3, H4, and Perseus2.
--
Regards,
Igor.
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Vaibhav Hiremath @ 2012-10-10 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3430030.rKEkeKmzui@vostro.rjw.lan>
On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
> On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
>>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
>>>>>>>>
>>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
>>>>>>>>
>>>>>>>> are available in the git repository at:
>>>>>>>>
>>>>>>>>
>>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
>>>>>>>>
>>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
>>>>>>>>
>>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> pm: add suspend_mem and suspend_standby support
>>>>>>>>
>>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
>>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
>>>>>>>> suspend_standby.
>>>>>>>
>>>>>>> No way. Device drivers shouldn't be concerned about that.
>>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
>>>>>> need special handling when switching to slow_clock
>>>>>
>>>>> Well, my answer to that is: please fix your platform code instead of
>>>>> hacking the PM core to work around its problems.
>>>> how can I fix drivers pm issue when I no way to known at driver level the
>>>> real suspend, the PM core is supposed to proivde the right information to the
>>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
>>>> provide such inforation the PM core is broken as we will have to do dirty
>>>> hack.
>>>
>>> Why do you need to know the difference in your driver? We used to
>>> provide this information a long time ago, but it turned out to not be
>>> needed at all and just caused problems.
>> because on at91 I need to handle the mem standby at drviers level.
>
> This is not an answer. You're basically saying "it has to be done this way,
> because it has to be done this way".
>
>> We do it today already by a hack in different drivers at91_udc (usb device),
>> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
>> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
>> clock - this is done at soc level - but those IP have issue and need specific
>> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
>>
>> in this patch series I send the update of those 3 drivers too
>> and kill the hack
>
> Well, let's start over. What's the difference between "suspend to RAM" (mem)
> and "standby" on your platform?
>
>>>> Any generic framework is supposed to evolve for real user need here I've one
>>>> so I udpate the core to mach a need
>
> Yes, if there are more users needing a change. If there's only one, I think not
> really.
>
We came across such a need while supporting various low-power modes in
AM335x SoC. I also wanted to put similar proposal, its good that Jean
submitted patches and we are having this discussion early.
Let me try to describe the need and issue here,
In case of AM33xx device, we have different low-power modes supported
by HW, for this discussion I will just talk about DeepSleep-0 and
StandBy mode supported by HW (few other modes also described in spec)-
Below is the Spec definition of these two low-power modes,
PowerMode Application state States
========================================================================
DeepSleep0 Everything is preserved Master Oscillator = OFF
including SDRAM. VDD_MPU = 0.95v
VDD_CORE = 0.95v
PD_WKUP = ON
PD_MPU = OFF
PD_PER = OFF
PD_GFX = OFF
All IOs & RTC supplies are ON
Standby Everything is preserved Master Oscillator = ON
including SDRAM. One PLL is ON
Only required module clocks VDD_MPU = 0.95v
are enabled rest are clock VDD_CORE = OPP50
gated PD_WKUP = ON
PD_MPU = ON
PD_PER = ON
PD_GFX = OFF
All IOs & RTC supplies are ON
If more PLLs /power domains/
modules are required, the
power will increase
accordingly
Now we have two major parameters here, Power Consumption and Latency
(Sleep + Wakeup). Since DeepSleep-0 is as good as off state, it gives
very less power consumption Vs huge Latency number, whereas, in case of
standby the power consumption is more but the Latency is reduced.
In addition to that, there are certain HW related parameters and issues
contribute to these parameters. For example,
In case of LCD driver the suspend/resume latency is in the range of
10msec, which can be reduced if driver knows that he is not entering or
entered in DeepSleep-0 and choose not to do certain things.
Another example would be, USB driver, we have seen Latency numbers in
the range of 200msec, and of which 100 msec can simply be taken away if
driver knows about the sleep state.
I understand that, there is trade-off between power and latency numbers,
but for certain use-cases latency is more important and it is not
possible without telling driver about the low-power state.
Thanks,
Vaibhav
> Thanks,
> Rafael
>
>
^ permalink raw reply
* [PATCH 02/16] pinctrl: exynos: Parse wakeup-eint parameters from DT
From: Linus Walleij @ 2012-10-10 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-3-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch converts the pinctrl-exynos driver to parse wakeup interrupt
> count and register offsets from device tree. It reduces the amount of
> static platform-specific data and facilitates adding further SoC
> variants to pinctrl-samsung driver.
So these are:
> + ret = of_property_read_u32(wkup_np, "samsung,weint-count", &val);
> + ret = of_property_read_u32(wkup_np, "samsung,weint-con", &val);
> + ret = of_property_read_u32(wkup_np, "samsung,weint-mask", &val);
> + ret = of_property_read_u32(wkup_np, "samsung,weint-pend", &val);
Are these all four register offsets?
I don't think it's proper for the device tree to contain register offsets.
Base address, "regs" property, yes. Individual registers, no. That just
makes the code hard to read and compare to the datasheet.
Or what are you aiming at here?
Linus Walleij
^ permalink raw reply
* [PATCH 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes
From: Linus Walleij @ 2012-10-10 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-2-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> Seuqential patches from this series introduce SoC-specific data parsing
> from device tree.
>
> This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
> replaces them with nodes and properties required for these patches.
So to be clear:
> + pinctrl-bank-types {
> + bank_off: bank-off {
> + samsung,reg-names = "func", "dat", "pud",
> + "drv", "conpdn", "pudpdn";
> + samsung,reg-params = <0x00 4>, <0x04 1>, <0x08 2>,
> + <0x0C 2>, <0x10 2>, <0x14 2>;
> + };
This is starting to look like a firmware language, I have mixed
feelings about this. Shall this be read:
"Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08" etc?
We really need to discuss this, Grant has already NACK:ed
such approaches once.
If you're still going to do this, it is mandatory
to NOT use magic hex numbers anymore, because Stephen has
merged preprocessor support to the DTC compiler so you
can use #defined macros.
See commit:
cd296721a9645f9f28800a072490fa15458d1fb7
> + pinctrl at 11400000 {
> + gpa0: gpa0 {
> + gpio-controller;
> + samsung,pctl-offset = <0x000>;
> + samsung,pin-count = <8>;
> + samsung,bank-type = <&bank_off>;
> + #gpio-cells = <2>;
This part is OK.
> +
> + interrupt-controller;
> + samsung,eint-offset = <0x00>;
This property is *NOT* OK. IMHO the driver should know these
offsets, not the device tree. The driver only needs the offset to
the register range, what registers there are and their names
should be #defined.
> + #interrupt-cells = <2>;
> + };
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] video: imxfb: Do not crash on reboot
From: Sascha Hauer @ 2012-10-10 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349789541-5159-1-git-send-email-fabio.estevam@freescale.com>
On Tue, Oct 09, 2012 at 10:32:21AM -0300, Fabio Estevam wrote:
> Issuing a "reboot" command after the LCD times out causes the following
> warnings:
>
> This happens because "reboot" triggers imxfb_shutdown(), which calls
> imxfb_disable_controller with the clocks already disabled.
>
> To prevent this, add a clock enabled status so that we can check if the clocks
> are enabled before disabling them.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v2:
> - Use a better naming for the clk enabled variable
This is probably due to Uwes comment. At that time the enabled variable
tracked the clk state. Now it tracks the state of the whole controller,
so indeed enabled or maybe fb_enabled would be better.
Anyway, this is only nitpicking, so:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> - Return immediately in imxfb_enable_controller/imxfb_disable_controller
> if the the clocks are already enabled/disabled.
> Changes since v1:
> - Protect the whole function instead of only the clocks
> drivers/video/imxfb.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index cf2688d..e0d770f 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -134,6 +134,7 @@ struct imxfb_info {
> struct clk *clk_ipg;
> struct clk *clk_ahb;
> struct clk *clk_per;
> + int clks_enabled;
>
> /*
> * These are the addresses we mapped
> @@ -513,6 +514,9 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
>
> static void imxfb_enable_controller(struct imxfb_info *fbi)
> {
> + if (fbi->clks_enabled)
> + return;
> +
> pr_debug("Enabling LCD controller\n");
>
> writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
> @@ -533,6 +537,7 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
> clk_prepare_enable(fbi->clk_ipg);
> clk_prepare_enable(fbi->clk_ahb);
> clk_prepare_enable(fbi->clk_per);
> + fbi->clks_enabled = 1;
>
> if (fbi->backlight_power)
> fbi->backlight_power(1);
> @@ -542,6 +547,9 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
>
> static void imxfb_disable_controller(struct imxfb_info *fbi)
> {
> + if (!fbi->clks_enabled)
> + return;
> +
> pr_debug("Disabling LCD controller\n");
>
> if (fbi->backlight_power)
> @@ -552,6 +560,7 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
> clk_disable_unprepare(fbi->clk_per);
> clk_disable_unprepare(fbi->clk_ipg);
> clk_disable_unprepare(fbi->clk_ahb);
> + fbi->clks_enabled = 0;
>
> writel(0, fbi->regs + LCDC_RMCR);
> }
> --
> 1.7.9.5
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 04/16] pinctrl: samsung: Parse pin banks from DT
From: Linus Walleij @ 2012-10-10 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-5-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> Currently SoC-specific properties such as list of pin banks, register
> offsets and bitfield sizes are being taken from static data structures
> residing in pinctrl-exynos.c.
>
> This patch modifies the pinctrl-samsung driver to parse all SoC-specific
> data from device tree, which will allow to remove the static data
> structures and facilitate adding of further SoC variants to the
> pinctrl-samsung driver.
So why? Two approaches:
- Put as much info as possible into the device tree
- Put as much info as possible into the driver
The first approach is currently only used by pinctrl-single.c.
That driver is designed for the case where all info about
the hardware arrives in some description language that
can be translated into a simple DT description.
If you want to use that approach, you should use that
driver. If that driver does not work for you, then it's not
fulfilling it's purpose as a one-stop shop for simple
pin controllers entirely contained within the device tree,
and should be renamed or redesigned.
If you will end up with a hybrid approach with some
stuff in the device tree and some stuff in the code,
it's better to keep the old driver.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 03/16] pinctrl: samsung: Detect and handle unsupported configuration types
From: Linus Walleij @ 2012-10-10 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-4-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch modifies the pinctrl-samsung driver to detect when width of a
> bit field is set to zero (which means that such configuraton type is not
> supported) and return an error instead of trying to modify an inexistent
> register.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> ---
> drivers/pinctrl/pinctrl-samsung.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
> index dd108a9..c660fa5 100644
> --- a/drivers/pinctrl/pinctrl-samsung.c
> +++ b/drivers/pinctrl/pinctrl-samsung.c
> @@ -391,6 +391,9 @@ static int samsung_pinconf_rw(struct pinctrl_dev *pctldev, unsigned int pin,
> return -EINVAL;
> }
>
> + if (!width)
> + return -EINVAL;
> +
Can this patch be applied in isolation from the others?
Thomas A: can you ACK this so I can apply it in that case?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 09/16] pinctrl: exynos: Use one IRQ domain per pin bank
From: Linus Walleij @ 2012-10-10 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-10-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> Instead of registering one IRQ domain for all pin banks of a pin
> controller, this patch implements registration of per-bank domains.
>
> At a cost of a little memory overhead (~2.5KiB for all GPIO interrupts
> of Exynos4x12) it simplifies driver code and device tree sources,
> because GPIO interrupts can be now specified per banks.
>
> Example:
> device {
> /* ... */
> interrupt-parent = <&gpa1>;
> interrupts = <3 0>;
> /* ... */
> };
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
This looks like a very good patch!
Can it be applied in isolation from the other patches?
Thomas A: can you ACK this?
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox