* [PATCH 05/16] vfs: bogus warnings in fs/namei.c
From: Jan Kara @ 2012-10-09 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091307.19225.arnd@arndb.de>
On Tue 09-10-12 13:07:19, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Arnd Bergmann wrote:
> > On Monday 08 October 2012, Jan Kara wrote:
> > > On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
> > > > The follow_link() function always initializes its *p argument,
> > > > or returns an error, but not all versions of gcc figure this
> > > > out, so we have to work around this using the uninitialized_var()
> > > > macro.
> > > Well, I'm somewhat sceptical to this approach. I agree that bogus
> > > warnings are not nice but later when the code is changed and possibly real
> > > use without initialization is added, we won't notice it. Without changing
> > > anything, we'd at least have a chance of catching it with gcc versions
> > > which were clever enough to not warn with the original code. Or
> > > alternatively if we unconditionally initialized the variable that would get
> > > rid of the warning and made the code more future-proof (that's what I
> > > usually end up doing)... I don't really care that much about the chosen
> > > solution, Al is the one to decide. But I wanted to point out there are
> > > downsides to your solution.
> >
> > I'll drop the patch for now and won't send it from my tree then. I agree
> > that uninitialized_var() is not ideal, but none of the alternatives seemed
> > better.
> >
> > With my latest compiler, I don't actually see the warnings any more, so
> > maybe someone fixed gcc instead, or this went away after another change.
> > I'll let you know if it comes back so we can discuss about a better fix then.
> >
>
> Update: I could actually reproduce the problem now, but it only happens when
> building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
> with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
> patch that would also make it go away is the variant below, but I think that's
> even worse than the first version I suggested because it makes the binary
> output slightly worse by adding an unnecessary initialization when building with
> 'make -s'.
Hum, dumb compiler... I like this patch better and since the extra
initialization is on error path only, I don't think it matters. But
whatever Al likes better.
Honza
> diff --git a/fs/namei.c b/fs/namei.c
> index aa30d19..c3612a5 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -810,6 +810,7 @@ follow_link(struct path *link, struct nameidata *nd, void **p)
> return error;
>
> out_put_nd_path:
> + *p = NULL;
> path_put(&nd->path);
> path_put(link);
> return error;
^ permalink raw reply
* [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Russell King - ARM Linux @ 2012-10-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349735823-30315-1-git-send-email-festevam@gmail.com>
On Mon, Oct 08, 2012 at 07:37:03PM -0300, Fabio Estevam wrote:
> @@ -460,7 +462,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> if (pcdev->icd)
> return -EBUSY;
>
> - ret = clk_prepare_enable(pcdev->clk_csi);
> + ret = clk_prepare_enable(pcdev->clk_csi_ahb);
> + if (ret < 0)
> + return ret;
> +
> + ret = clk_prepare_enable(pcdev->clk_csi_per);
> if (ret < 0)
> return ret;
>From the point of view of error cleanup, this looks buggy to me. If
the prepare_enable for the per clock fails, what cleans up the ahb clock?
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Sourav @ 2012-10-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
Hi,
On Saturday 06 October 2012 06:08 PM, Russell King - ARM Linux wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work properly for DMA support
> otherwise we have no way to properly pause the transmitter.
>
> This is generated against v3.6, and has been developed mainly by testing
> on the OMAP4430 SDP platform.
>
> Flow control seems to be really broken in the OMAP serial driver as things
> stand today. It just about works with software flow control because the
> generic serial core layer is inserting those characters, but only when the
> legacy DMA support is not being used. Otherwise, flow control is
> completely non-functional.
>
> Issues identified in the OMAP serial driver are:
> - set_mctrl() can only assert modem control lines, once asserted it
> is not possible to deassert them.
> - IXOFF controls sending of XON/XOFF characters, not the reception of
> these sequences.
> - IXON controls the recognition of XON/XOFF characters, not the transmission
> of the same.
> - Wrong bitmasks for hardware assisted software flow control. Bit 2
> in EFR enables sending of XON2/XOFF2 which are never set.
> - No point comparing received characters against XOFF2 ('special character
> detect') as XOFF2 is not set.
> - Fix multiple places where bits 6 and 5 of MCR are attempted to be
> altered, but because EFR ECB is unset, these bits remain unaffected.
> This effectively prevents us accessing the right XON/XOFF/TCR/TLR
> registers.
> - Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
> don't change beneath us, they are configuration registers which hold their
> values. Not only does this simplify the code, but it makes it more
> readable, and more importantly ensures that we work from a consistent
> state where ->efr never has ECB set, and ->mcr never has the TCRTLR
> bit set.
> - Fix disablement of hardware flow control and IXANY modes; once enabled
> these could never be disabled because nothing in the code ever clears
> these configuration bits.
>
> Once that lot is fixed, these patches expand serial_core to permit hardware
> assisted flow control by:
> - adding throttle/unthrottle callbacks into low level serial drivers,
> which allow them to take whatever action is necessary with hardware
> assisted flow control to throttle the remote end. In the case of
> OMAP serial, this means disabling the RX interrupts so that the FIFO
> fills to the watermark.
>
> We then have a number of cleanups to the OMAP serial code to make the
> set_termios() function clearer and less prone to the kinds of mistakes
> identified above. This results in a great simplification of the flow
> control configuration code.
>
> The OMAP serial driver hacks around with the transmit buffer allocation;
> lets clean that up so that drivers can cleanly allocate their transmitter
> buffer using coherent memory if that's what they desire.
>
> Finally, the last few patches clean up the plat/omap-serial.h header file,
> moving most of its contents into the OMAP serial driver itself. Most of
> this is private to the OMAP serial driver and should never have been
> shared with anything else.
>
> I have omitted to include the conversion of the transmit paths to DMA
> engine. Even with all the above fixed, it has issues when DMA transmit
> is in progress, and a program issues a TCSETS call (as `less' does after
> it has written its prompt.) At the moment, this causes lots of junk to
> be emitted from the serial port when issuing `dmesg | less' which sometimes
> brings the port to a complete halt.
>
> As the OMAP DMA hardware does not have a clean pause when performing a
> MEM->DEV transfer (it discards its FIFO) I do not see a solution to this,
> which probably means that we can _not_ ever support transmit DMA on OMAP
> platforms.
>
> This means the xmit buffer allocation patches are not that useful unless
> a solution to that can be found.
>
> Now, the remaining question is, how much of this patch set do we think
> about merging, and when. Given that flow control in this driver has been
> broken for a very long time, and no one has apparantly noticed, I don't
> think there's any urgency to this, so given its size, my preference would
> be to queue it up for the next merge window. The thing that would worry
> me about applying some of the initial patches is that they may change
> the behaviour today and make any problems here more visible.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Boot Tested this patch series against v3.6 tag(applied cleanly) on panda
board and
PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
Note, I also tested the patches against the current master but only
after rebasing, since the current master includes serial patches from
Felipe Balbi[1].
[1] https://lkml.org/lkml/2012/8/24/139
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Thanks,
Sourav
^ permalink raw reply
* [PATCH v3] video: imxfb: Do not crash on reboot
From: Fabio Estevam @ 2012-10-09 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Issuing a "reboot" command after the LCD times out causes the following
warnings:
Requesting system reboot
------------[ cut here ]------------
WARNING: at drivers/clk/clk.c:471 clk_disable+0x24/0x50()
Modules linked in:
[<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
[<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
[<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c03960a0>] (clk_disable+0x24/0x50)
[<c03960a0>] (clk_disable+0x24/0x50) from [<c02695a0>] (imxfb_disable_controller+0x48/0x7c)
[<c02695a0>] (imxfb_disable_controller+0x48/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
[<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
[<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
[<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
[<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
[<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c854f ]---
------------[ cut here ]------------
WARNING: at drivers/clk/clk.c:380 clk_unprepare+0x1c/0x2c()
Modules linked in:
[<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
[<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
[<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c0396338>] (clk_unprepare+0x1c/0x2c)
[<c0396338>] (clk_unprepare+0x1c/0x2c) from [<c02695a8>] (imxfb_disable_controller+0x50/0x7c)
[<c02695a8>] (imxfb_disable_controller+0x50/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
[<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
[<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
[<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
[<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
[<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c8550 ]---
------------[ cut here ]------------
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
- 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
^ permalink raw reply related
* [PATCH v2] ARM: mxs_defconfig: Improve USB related support
From: Shawn Guo @ 2012-10-09 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349630183-29297-1-git-send-email-festevam@gmail.com>
On Sun, Oct 07, 2012 at 02:16:23PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Select the following USB related options:
>
> - USB Ethernet adapter (needed for mx23-olinuxino)
> - Native language support (needed for mounting USB pen drives, for example)
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Queued for 3.8.
Per request from arm-soc folks, we will need to squash defconfig
changes into 1~2 patches before sending them to arm-soc.
Shawn
^ permalink raw reply
* [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
From: Sekhar Nori @ 2012-10-09 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507420A4.8090905@ti.com>
On 10/9/2012 6:33 PM, Sekhar Nori wrote:
> On 9/17/2012 10:07 PM, Murali Karicheri wrote:
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>>
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>
> Tested this using NAND flash on DA850 EVM.
>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
>
> Any chance this can make into the v3.7 kernel?
Just noticed another thread where Artem replied saying this patch is
pushed. Sorry about the noise.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6q-sabreauto: Add basic support
From: Shawn Guo @ 2012-10-09 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349629969-29177-1-git-send-email-festevam@gmail.com>
On Sun, Oct 07, 2012 at 02:12:49PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> mx6qsabreauto is a board based on mx6q SoC with the following features:
> - 2GB of DDR3
> - 2 USB ports
> - 1 HDMI output port
> - SPI NOR
> - 2 LVDS LCD ports
> - Gigabit Ethernet
> - Camera
> - eMMC and SD card slot
> - Multichannel Audio
> - CAN
> - SATA
> - NAND
> - PCIE
> - Video Input
>
> Add very basic support for it.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Queued for 3.8, thanks.
^ permalink raw reply
* [PATCH 05/16] vfs: bogus warnings in fs/namei.c
From: Arnd Bergmann @ 2012-10-09 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091227.46324.arnd@arndb.de>
On Tuesday 09 October 2012, Arnd Bergmann wrote:
> On Monday 08 October 2012, Jan Kara wrote:
> > On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
> > > The follow_link() function always initializes its *p argument,
> > > or returns an error, but not all versions of gcc figure this
> > > out, so we have to work around this using the uninitialized_var()
> > > macro.
> > Well, I'm somewhat sceptical to this approach. I agree that bogus
> > warnings are not nice but later when the code is changed and possibly real
> > use without initialization is added, we won't notice it. Without changing
> > anything, we'd at least have a chance of catching it with gcc versions
> > which were clever enough to not warn with the original code. Or
> > alternatively if we unconditionally initialized the variable that would get
> > rid of the warning and made the code more future-proof (that's what I
> > usually end up doing)... I don't really care that much about the chosen
> > solution, Al is the one to decide. But I wanted to point out there are
> > downsides to your solution.
>
> I'll drop the patch for now and won't send it from my tree then. I agree
> that uninitialized_var() is not ideal, but none of the alternatives seemed
> better.
>
> With my latest compiler, I don't actually see the warnings any more, so
> maybe someone fixed gcc instead, or this went away after another change.
> I'll let you know if it comes back so we can discuss about a better fix then.
>
Update: I could actually reproduce the problem now, but it only happens when
building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
patch that would also make it go away is the variant below, but I think that's
even worse than the first version I suggested because it makes the binary
output slightly worse by adding an unnecessary initialization when building with
'make -s'.
Arnd
diff --git a/fs/namei.c b/fs/namei.c
index aa30d19..c3612a5 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -810,6 +810,7 @@ follow_link(struct path *link, struct nameidata *nd, void **p)
return error;
out_put_nd_path:
+ *p = NULL;
path_put(&nd->path);
path_put(link);
return error;
^ permalink raw reply related
* [PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Gaëtan Carlier @ 2012-10-09 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349473981-15084-2-git-send-email-fabio.estevam@freescale.com>
Hi,
On 10/05/2012 11:53 PM, Fabio Estevam wrote:
> During the clock conversion for mx27 the "per4_gate" clock was missed to get
> registered as a dependency of mx2-camera driver.
>
> In the old mx27 clock driver we used to have:
>
> DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);
>
> ,so does the same in the new clock driver.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/clk-imx27.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 3b6b640..5ef0f08 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx-fb.0");
> clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx-fb.0");
> clk_register_clkdev(clk[csi_ahb_gate], "ahb", "mx2-camera.0");
> + clk_register_clkdev(clk[per4_gate], "per", "mx2-camera.0");
> clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
>
I only test detection at kernel boot not streaming using Gstreamer due
to lack of time.
On imx27_3ds board with ov2640 sensor:
ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 44333333
On clone imx27_3ds board with mt9v111 sensor (draft driver):
mt9v111 0-0048: Detected a MT9V111 chip ID 823a
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 44333333
Tested-by: Ga?tan Carlier <gcembed@gmail.com>
^ permalink raw reply
* [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
From: Sekhar Nori @ 2012-10-09 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347899860-24358-2-git-send-email-m-karicheri2@ti.com>
On 9/17/2012 10:07 PM, Murali Karicheri wrote:
> As a first step towards migrating davinci platforms to use common clock
> framework, replace all instances of clk_enable() with clk_prepare_enable()
> and clk_disable() with clk_disable_unprepare(). Until the platform is
> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
> adds a might_sleep() call and would work without any issues.
>
> This will make it easy later to switch to common clk based implementation
> of clk driver from DaVinci specific driver.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Reviewed-by: Mike Turquette <mturquette@linaro.org>
Tested this using NAND flash on DA850 EVM.
Acked-by: Sekhar Nori <nsekhar@ti.com>
Any chance this can make into the v3.7 kernel?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM : i.MX27 : split code for allocation of ressources of camera and eMMA
From: Gaëtan Carlier @ 2012-10-09 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120911111738.GU18243@pengutronix.de>
Hi Sascha,
On 09/11/2012 01:17 PM, Sascha Hauer wrote:
> On Tue, Sep 11, 2012 at 01:13:03PM +0200, javier Martin wrote:
>> Hi,
>>
>> On 11 September 2012 11:47, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>>> Hi Javier,
>>>
>>> Since you worked in this area recently, can I have your Ack on this?
>>
>> Acked-by: Javier Martin <javier.martin@vista-silicon.com>
>
> Thanks
This patch is missing in next-20121008 and seems to be never committed.
Is there any reason ?
>
>>
>>> As a side note: Please be prepared that all this should be removed in
>>> the not-so-far future. It would be good if you start converting your
>>> boards to devicetree soon. You may be doing so internally already, I
>>> don't know.
>>
>> We made some tests regarding devicetree this summer but we found that
>> there are some things missing yet:
>> - pinctrl
>> - soc-camera and video sensor
>>
>> I don't know if people from Linaro is planning to deal with pinctrl
>> for i.MX27 or not.
>
> I don't think Linaro will do anything for the older i.MX like the
> i.MX27. With soc-camera I'm optimistic that someone will come up
> with patches soon.
>
> Sascha
>
Thank you.
Best regards,
Ga?tan Carlier.
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Afzal Mohammed @ 2012-10-09 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009030126.GB12552@atomide.com>
Hi Tony,
On Tuesday 09 October 2012 08:31 AM, Tony Lindgren wrote:
> * Afzal Mohammed<afzal@ti.com> [121005 09:02]:
>> Proposed generic routine has been tested on OneNAND (async) on
>> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
>> local patch were used to test). For other cases of custom timing
>> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
>> calculation routine was verified by simulating on OMAP3EVM.
> Have you tested to make sure this works if you change the
> L3 frequency?
With changed L3 frequency it was not tested.
I do not have a single board that is supported in mainline that
calculates on the run gpmc timing from device timing. What has
been tested here is OneNAND working in asynchronous mode
on omap3evm, but it's support is not available in mainline, so
private patch had to be used to test it. All other peripherals
were tested by simulation, i.e. by comparing output from existing
custom timing routine & generic routine for particular frequencies.
> That should probably be tested as a sanity check. Maybe you
> can force the L3 for some test boots for this, I don't think
> we scale it by default.
On omap3evm, don't know whether L3 frequency can be
changed & still have a working Kernel. I am not sure whether
it is worth attempting as OneNAND on omap3evm is not
supported in mainline.
Regards
Afzal
^ permalink raw reply
* [kvmarm] [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
From: Marc Zyngier @ 2012-10-09 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKAFQgfwRuFP2WOP4Af+1Un-wuQPC8-TiGi4B+s3XB2hQ@mail.gmail.com>
On Sat, 6 Oct 2012 17:33:43 -0400, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> On Thu, Oct 4, 2012 at 10:23 PM, Min-gyu Kim <mingyu84.kim@samsung.com>
> wrote:
>>
>>
>>> -----Original Message-----
>>> From: kvm-owner at vger.kernel.org [mailto:kvm-owner at vger.kernel.org] On
>>> Behalf Of Christoffer Dall
>>> Sent: Monday, October 01, 2012 6:11 PM
>>> To: kvm at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>>> kvmarm at lists.cs.columbia.edu
>>> Cc: Marc Zyngier
>>> Subject: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
>>>
>>> +static void stage2_set_pte(struct kvm *kvm, struct
kvm_mmu_memory_cache
>>> *cache,
>>> + phys_addr_t addr, const pte_t *new_pte) {
>>> + pgd_t *pgd;
>>> + pud_t *pud;
>>> + pmd_t *pmd;
>>> + pte_t *pte, old_pte;
>>> +
>>> + /* Create 2nd stage page table mapping - Level 1 */
>>> + pgd = kvm->arch.pgd + pgd_index(addr);
>>> + pud = pud_offset(pgd, addr);
>>> + if (pud_none(*pud)) {
>>> + if (!cache)
>>> + return; /* ignore calls from kvm_set_spte_hva */
>>> + pmd = mmu_memory_cache_alloc(cache);
>>> + pud_populate(NULL, pud, pmd);
>>> + pmd += pmd_index(addr);
>>> + get_page(virt_to_page(pud));
>>> + } else
>>> + pmd = pmd_offset(pud, addr);
>>> +
>>> + /* Create 2nd stage page table mapping - Level 2 */
>>> + if (pmd_none(*pmd)) {
>>> + if (!cache)
>>> + return; /* ignore calls from kvm_set_spte_hva */
>>> + pte = mmu_memory_cache_alloc(cache);
>>> + clean_pte_table(pte);
>>> + pmd_populate_kernel(NULL, pmd, pte);
>>> + pte += pte_index(addr);
>>> + get_page(virt_to_page(pmd));
>>> + } else
>>> + pte = pte_offset_kernel(pmd, addr);
>>> +
>>> + /* Create 2nd stage page table mapping - Level 3 */
>>> + old_pte = *pte;
>>> + set_pte_ext(pte, *new_pte, 0);
>>> + if (pte_present(old_pte))
>>> + __kvm_tlb_flush_vmid(kvm);
>>> + else
>>> + get_page(virt_to_page(pte));
>>> +}
>>
>>
>> I'm not sure about the 3-level page table, but isn't it necessary to
>> clean the page table for 2nd level?
>> There are two mmu_memory_cache_alloc calls. One has following
>> clean_pte_table
>> and the other doesn't have.
>
> hmm, it probably is - I couldn't really find the common case where
> this is done in the kernel normally (except for some custom loop in
> ioremap and idmap), but I added this fix:
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 5394a52..f11ba27f 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -430,6 +430,7 @@ static void stage2_set_pte(struct kvm *kvm, struct
> kvm_mmu_memory_cache *cache,
> if (!cache)
> return; /* ignore calls from kvm_set_spte_hva */
> pmd = mmu_memory_cache_alloc(cache);
> + clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
> pud_populate(NULL, pud, pmd);
> pmd += pmd_index(addr);
> get_page(virt_to_page(pud));
There ought to be a test of ID_MMFR3[23:20] to find out whether or not it
is useful to clean the dcache. Not sure if that's a massive gain, but it is
certainly an optimisation to consider for the kernel as a whole.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: javier Martin @ 2012-10-09 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349473981-15084-2-git-send-email-fabio.estevam@freescale.com>
On 5 October 2012 23:53, Fabio Estevam <fabio.estevam@freescale.com> wrote:
> During the clock conversion for mx27 the "per4_gate" clock was missed to get
> registered as a dependency of mx2-camera driver.
>
> In the old mx27 clock driver we used to have:
>
> DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);
>
> ,so does the same in the new clock driver.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/clk-imx27.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 3b6b640..5ef0f08 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx-fb.0");
> clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx-fb.0");
> clk_register_clkdev(clk[csi_ahb_gate], "ahb", "mx2-camera.0");
> + clk_register_clkdev(clk[per4_gate], "per", "mx2-camera.0");
> clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
> --
> 1.7.9.5
>
>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply
* [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: javier Martin @ 2012-10-09 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50741D08.1060706@gmail.com>
On 9 October 2012 14:48, Ga?tan Carlier <gcembed@gmail.com> wrote:
> Hi,
>
> On 10/09/2012 12:37 AM, Fabio Estevam wrote:
>>
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> Since mx27 transitioned to the commmon clock framework in 3.5, the correct
>> way
>> to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
>>
>> By not doing so the camera sensor does not probe correctly:
>>
>> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
>> mx2-camera mx2-camera.0: Camera driver attached to camera 0
>> ov2640 0-0030: Product ID error fb:fb
>> mx2-camera mx2-camera.0: Camera driver detached from camera 0
>> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
>> 66500000
>>
>> Adapt the mx2_camera driver to the new clock framework and make it
>> functional
>> again.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> Changes since v1:
>> - Rebased against linux-next 20121008.
>>
>> drivers/media/platform/soc_camera/mx2_camera.c | 47
>> +++++++++++++++++-------
>> 1 file changed, 34 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
>> b/drivers/media/platform/soc_camera/mx2_camera.c
>> index 403d7f1..9f8c5f0 100644
>> --- a/drivers/media/platform/soc_camera/mx2_camera.c
>> +++ b/drivers/media/platform/soc_camera/mx2_camera.c
>> @@ -272,7 +272,8 @@ struct mx2_camera_dev {
>> struct device *dev;
>> struct soc_camera_host soc_host;
>> struct soc_camera_device *icd;
>> - struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
>> + struct clk *clk_emma_ahb, *clk_emma_ipg;
>> + struct clk *clk_csi_ahb, *clk_csi_per;
>>
>> void __iomem *base_csi, *base_emma;
>>
>> @@ -432,7 +433,8 @@ static void mx2_camera_deactivate(struct
>> mx2_camera_dev *pcdev)
>> {
>> unsigned long flags;
>>
>> - clk_disable_unprepare(pcdev->clk_csi);
>> + clk_disable_unprepare(pcdev->clk_csi_ahb);
>> + clk_disable_unprepare(pcdev->clk_csi_per);
>> writel(0, pcdev->base_csi + CSICR1);
>> if (cpu_is_mx27()) {
>> writel(0, pcdev->base_emma + PRP_CNTL);
>> @@ -460,7 +462,11 @@ static int mx2_camera_add_device(struct
>> soc_camera_device *icd)
>> if (pcdev->icd)
>> return -EBUSY;
>>
>> - ret = clk_prepare_enable(pcdev->clk_csi);
>> + ret = clk_prepare_enable(pcdev->clk_csi_ahb);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = clk_prepare_enable(pcdev->clk_csi_per);
>> if (ret < 0)
>> return ret;
>>
>> @@ -1725,11 +1731,18 @@ static int __devinit mx2_camera_probe(struct
>> platform_device *pdev)
>> goto exit;
>> }
>>
>> - pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
>> - if (IS_ERR(pcdev->clk_csi)) {
>> - dev_err(&pdev->dev, "Could not get csi clock\n");
>> - err = PTR_ERR(pcdev->clk_csi);
>> - goto exit;
>> + pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
>> + if (IS_ERR(pcdev->clk_csi_ahb)) {
>> + dev_err(&pdev->dev, "Could not get csi ahb clock\n");
>> + err = PTR_ERR(pcdev->clk_csi_ahb);
>> + goto exit;
>> + }
>> +
>> + pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
>> + if (IS_ERR(pcdev->clk_csi_per)) {
>> + dev_err(&pdev->dev, "Could not get csi per clock\n");
>> + err = PTR_ERR(pcdev->clk_csi_per);
>> + goto exit_csi_ahb;
>> }
>>
>> pcdev->pdata = pdev->dev.platform_data;
>> @@ -1738,14 +1751,15 @@ static int __devinit mx2_camera_probe(struct
>> platform_device *pdev)
>>
>> pcdev->platform_flags = pcdev->pdata->flags;
>>
>> - rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk *
>> 2);
>> + rate = clk_round_rate(pcdev->clk_csi_per,
>> + pcdev->pdata->clk * 2);
>> if (rate <= 0) {
>> err = -ENODEV;
>> - goto exit;
>> + goto exit_csi_per;
>> }
>> - err = clk_set_rate(pcdev->clk_csi, rate);
>> + err = clk_set_rate(pcdev->clk_csi_per, rate);
>> if (err < 0)
>> - goto exit;
>> + goto exit_csi_per;
>> }
>>
>> INIT_LIST_HEAD(&pcdev->capture);
>> @@ -1801,7 +1815,7 @@ static int __devinit mx2_camera_probe(struct
>> platform_device *pdev)
>> goto exit_free_emma;
>>
>> dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock
>> frequency: %ld\n",
>> - clk_get_rate(pcdev->clk_csi));
>> + clk_get_rate(pcdev->clk_csi_per));
>>
>> return 0;
>>
>> @@ -1812,6 +1826,10 @@ eallocctx:
>> clk_disable_unprepare(pcdev->clk_emma_ipg);
>> clk_disable_unprepare(pcdev->clk_emma_ahb);
>> }
>> +exit_csi_per:
>> + clk_disable_unprepare(pcdev->clk_csi_per);
>> +exit_csi_ahb:
>> + clk_disable_unprepare(pcdev->clk_csi_ahb);
>> exit:
>> return err;
>> }
>> @@ -1831,6 +1849,9 @@ static int __devexit mx2_camera_remove(struct
>> platform_device *pdev)
>> clk_disable_unprepare(pcdev->clk_emma_ahb);
>> }
>>
>> + clk_disable_unprepare(pcdev->clk_csi_per);
>> + clk_disable_unprepare(pcdev->clk_csi_ahb);
>> +
>> dev_info(&pdev->dev, "MX2 Camera driver unloaded\n");
>>
>> return 0;
>>
> I only test detection at kernel boot not streaming using Gstreamer due to
> lack of time.
>
> On imx27_3ds board with ov2640 sensor:
> ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
> 44333333
>
> On clone imx27_3ds board with mt9v111 sensor (draft driver):
> mt9v111 0-0048: Detected a MT9V111 chip ID 823a
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
> 44333333
>
> Tested-by: Ga?tan Carlier <gcembed@gmail.com>
Sorry I missed patch 1/2. Both patches are correct:
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply
* [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Gaëtan Carlier @ 2012-10-09 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349735823-30315-1-git-send-email-festevam@gmail.com>
Hi,
On 10/09/2012 12:37 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
> to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
>
> By not doing so the camera sensor does not probe correctly:
>
> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
> mx2-camera mx2-camera.0: Camera driver attached to camera 0
> ov2640 0-0030: Product ID error fb:fb
> mx2-camera mx2-camera.0: Camera driver detached from camera 0
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
>
> Adapt the mx2_camera driver to the new clock framework and make it functional
> again.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Rebased against linux-next 20121008.
>
> drivers/media/platform/soc_camera/mx2_camera.c | 47 +++++++++++++++++-------
> 1 file changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
> index 403d7f1..9f8c5f0 100644
> --- a/drivers/media/platform/soc_camera/mx2_camera.c
> +++ b/drivers/media/platform/soc_camera/mx2_camera.c
> @@ -272,7 +272,8 @@ struct mx2_camera_dev {
> struct device *dev;
> struct soc_camera_host soc_host;
> struct soc_camera_device *icd;
> - struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_csi_ahb, *clk_csi_per;
>
> void __iomem *base_csi, *base_emma;
>
> @@ -432,7 +433,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
> {
> unsigned long flags;
>
> - clk_disable_unprepare(pcdev->clk_csi);
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> + clk_disable_unprepare(pcdev->clk_csi_per);
> writel(0, pcdev->base_csi + CSICR1);
> if (cpu_is_mx27()) {
> writel(0, pcdev->base_emma + PRP_CNTL);
> @@ -460,7 +462,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> if (pcdev->icd)
> return -EBUSY;
>
> - ret = clk_prepare_enable(pcdev->clk_csi);
> + ret = clk_prepare_enable(pcdev->clk_csi_ahb);
> + if (ret < 0)
> + return ret;
> +
> + ret = clk_prepare_enable(pcdev->clk_csi_per);
> if (ret < 0)
> return ret;
>
> @@ -1725,11 +1731,18 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> goto exit;
> }
>
> - pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
> - if (IS_ERR(pcdev->clk_csi)) {
> - dev_err(&pdev->dev, "Could not get csi clock\n");
> - err = PTR_ERR(pcdev->clk_csi);
> - goto exit;
> + pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
> + if (IS_ERR(pcdev->clk_csi_ahb)) {
> + dev_err(&pdev->dev, "Could not get csi ahb clock\n");
> + err = PTR_ERR(pcdev->clk_csi_ahb);
> + goto exit;
> + }
> +
> + pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
> + if (IS_ERR(pcdev->clk_csi_per)) {
> + dev_err(&pdev->dev, "Could not get csi per clock\n");
> + err = PTR_ERR(pcdev->clk_csi_per);
> + goto exit_csi_ahb;
> }
>
> pcdev->pdata = pdev->dev.platform_data;
> @@ -1738,14 +1751,15 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
>
> pcdev->platform_flags = pcdev->pdata->flags;
>
> - rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk * 2);
> + rate = clk_round_rate(pcdev->clk_csi_per,
> + pcdev->pdata->clk * 2);
> if (rate <= 0) {
> err = -ENODEV;
> - goto exit;
> + goto exit_csi_per;
> }
> - err = clk_set_rate(pcdev->clk_csi, rate);
> + err = clk_set_rate(pcdev->clk_csi_per, rate);
> if (err < 0)
> - goto exit;
> + goto exit_csi_per;
> }
>
> INIT_LIST_HEAD(&pcdev->capture);
> @@ -1801,7 +1815,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> goto exit_free_emma;
>
> dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
> - clk_get_rate(pcdev->clk_csi));
> + clk_get_rate(pcdev->clk_csi_per));
>
> return 0;
>
> @@ -1812,6 +1826,10 @@ eallocctx:
> clk_disable_unprepare(pcdev->clk_emma_ipg);
> clk_disable_unprepare(pcdev->clk_emma_ahb);
> }
> +exit_csi_per:
> + clk_disable_unprepare(pcdev->clk_csi_per);
> +exit_csi_ahb:
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> exit:
> return err;
> }
> @@ -1831,6 +1849,9 @@ static int __devexit mx2_camera_remove(struct platform_device *pdev)
> clk_disable_unprepare(pcdev->clk_emma_ahb);
> }
>
> + clk_disable_unprepare(pcdev->clk_csi_per);
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> +
> dev_info(&pdev->dev, "MX2 Camera driver unloaded\n");
>
> return 0;
>
I only test detection at kernel boot not streaming using Gstreamer due
to lack of time.
On imx27_3ds board with ov2640 sensor:
ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 44333333
On clone imx27_3ds board with mt9v111 sensor (draft driver):
mt9v111 0-0048: Detected a MT9V111 chip ID 823a
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 44333333
Tested-by: Ga?tan Carlier <gcembed@gmail.com>
^ permalink raw reply
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Philip, Avinash @ 2012-10-09 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005142338.GA7199@parrot.com>
On Fri, Oct 05, 2012 at 19:53:38, Ivan Djelic wrote:
> On Fri, Oct 05, 2012 at 09:51:50AM +0100, Philip, Avinash wrote:
> > On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
> > > On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
> > > > On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> > > > > ELM module can be used for error correction of BCH 4 & 8 bit. Also
> > > > > support read & write page in one shot by adding custom read_page &
> > > > > write_page methods. This helps in optimizing code.
> > > > >
> > > > > New structure member "is_elm_used" is added to know the status of
> > > > > whether the ELM module is used for error correction or not.
> > > > >
> > > > > Note:
> > > > > ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
> > > > > with RBL ECC layout, even though the requirement was only 13 byte. This
> > > > > results a common ecc layout across RBL, U-boot & Linux.
> > > > >
> > > >
> > > > See a few comments below,
> > > >
> > > > (...)
> > > > > +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> > > > > + u_char *read_ecc, u_char *calc_ecc)
> > > > > +{
> > > > > + struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > > > > + mtd);
> > > > > + int eccsteps = info->nand.ecc.steps;
> > > > > + int i , j, stat = 0;
> > > > > + int eccsize, eccflag, size;
> > > > > + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> > > > > + u_char *ecc_vec = calc_ecc;
> > > > > + enum bch_ecc type;
> > > > > + bool is_error_reported = false;
> > > > > +
> > > > > + /* initialize elm error vector to zero */
> > > > > + memset(err_vec, 0, sizeof(err_vec));
> > > > > + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> > > > > + size = BCH8_SIZE;
> > > > > + eccsize = BCH8_ECC_OOB_BYTES;
> > > > > + type = BCH8_ECC;
> > > > > + } else {
> > > > > + size = BCH4_SIZE;
> > > > > + eccsize = BCH4_SIZE;
> > > > > + type = BCH4_ECC;
> > > > > + }
> > > > > +
> > > > > + for (i = 0; i < eccsteps ; i++) {
> > > > > + eccflag = 0; /* initialize eccflag */
> > > > > +
> > > > > + for (j = 0; (j < eccsize); j++) {
> > > > > + if (read_ecc[j] != 0xFF) {
> > > > > + eccflag = 1; /* data area is flashed */
> > > >
> > > > Just a reminder: this way of checking if a page has been programmed is not robust to bitflips,
> > > > so you may get into trouble with UBIFS on a fairly recent device.
> >
> > Sorry I missed this point.
> >
> > Here we were checking data in spare area (only in ecc layout 14*4 for BCH8) is 0xFF. If all data
> > in spare area is 0xFF, conclude that the page is erased & no need of error correction. In case
> > of bit flip present in spare area, page will be reported as uncorrectable.
> > But I am not understand understand " trouble with UBIFS on a fairly recent device".
> > Can you little elaborativ
>
> There are at least 2 potential problems when reading an erased page with bitflips:
>
> 1. bitflip in data area and no bitflip in spare area (all 0xff)
> Your code will not perform any ECC correction.
> UBIFS does not like finding bitflips in empty pages, see for instance
> http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
In case of error correction using ELM, syndrome vector calculated after reading
Data area & OOB area. So handling of erased page requires a software workaround.
I am planning something as follows.
I will first check calculated ecc, which would be zero for non error pages.
Then I would check 0xFF in OOB area (for erased page) by checking number of
bit zeros in OOB area. If it is 0xFF (number of bit zero count is zero),
set entire page as 0xFF if number of bit zeros is less than max bit flips
(8 or 4) by counting the number of bit zero's in data area.
This logic is implemented in fsmc_nand.c
See commit
mtd: fsmc: Newly erased page read algorithm implemented
>
> 2. bitflip in ECC bytes in spare area
> Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
> I guess you will lose data.
In case of uncorrectable errors due to bit flips in spare area,
I can go on checking number of bit zero's in data area + OOB area
are less than max bit flips (8 or 4), I can go on setting the entire
page as 0xFF.
Thanks
Avinash
>
> BR,
> --
> Ivan
>
^ permalink raw reply
* [PATCH 05/16] vfs: bogus warnings in fs/namei.c
From: Arnd Bergmann @ 2012-10-09 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008115116.GA9243@quack.suse.cz>
On Monday 08 October 2012, Jan Kara wrote:
> On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
> > The follow_link() function always initializes its *p argument,
> > or returns an error, but not all versions of gcc figure this
> > out, so we have to work around this using the uninitialized_var()
> > macro.
> Well, I'm somewhat sceptical to this approach. I agree that bogus
> warnings are not nice but later when the code is changed and possibly real
> use without initialization is added, we won't notice it. Without changing
> anything, we'd at least have a chance of catching it with gcc versions
> which were clever enough to not warn with the original code. Or
> alternatively if we unconditionally initialized the variable that would get
> rid of the warning and made the code more future-proof (that's what I
> usually end up doing)... I don't really care that much about the chosen
> solution, Al is the one to decide. But I wanted to point out there are
> downsides to your solution.
I'll drop the patch for now and won't send it from my tree then. I agree
that uninitialized_var() is not ideal, but none of the alternatives seemed
better.
With my latest compiler, I don't actually see the warnings any more, so
maybe someone fixed gcc instead, or this went away after another change.
I'll let you know if it comes back so we can discuss about a better fix then.
Arnd
^ permalink raw reply
* [PATCH v3 0/6] omap-am33xx rtc dt support
From: Afzal Mohammed @ 2012-10-09 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93E9BA4EB@DBDE01.ent.ti.com>
Hi Andrew,
On Monday 27 August 2012 01:05 PM, Mohammed, Afzal wrote:
> On Sat, Aug 11, 2012 at 01:27:11, Nori, Sekhar wrote:
>> On 7/27/2012 5:53 PM, Afzal Mohammed wrote:
>>> This series makes rtc-omap driver DT capable, adds AM33xx
>>> RTC DT support along with a few enchancments to the driver.
>>>
>>> rtc-omap driver is made intelligent enough to handle kicker
>>> mechanism. This helps in removing kicker mechanism support
>>> done for DaVinci at platform level.
>>>
>>> This has been tested on Beaglebone (AM33xx platform) and on
>>> DaVinci DA850 EVM.
>> I tested patches 1-5 on AM18x EVM using rtcwake and hwclock commands.
>> Also tested on DT enabled AM18x EVM using hwclock.
>>
>> For patched 1-5:
>>
>> Acked-by: Sekhar Nori<nsekhar@ti.com>
>>
>> Alessandro,
>>
>> I assume you would want me to queue 2/6 through DaVinci tree. That patch
>> depends on 1/6 being accepted and merged by you. Let me know how you
>> want to move forward here.
> Can you please help 1-5 patches in this series to get into mainline.
> 1-5 of this series is a prerequisite for adding RTC support for AM335X
> SoC's, which is present in beaglebone, AM335X EVM.
This series which adds rtc support for AM335x SoC (ARM
Cortex-A8 from TI) based boards (like beagle bone) and
in the process making omap rtc driver device tree capable
was posted after addressing review comments around
July end. It seems rtc maintainer is not active and you
are taking care of the rtc patches.
Patches 1-5 has been Acked by DaVinci maintainer.
Can you please help this series reach mainline, let me
know whether this series needs to be reposted.
I waited to see response from rtc maintainer, it seems wait went
too far and this mail should have been sent a couple of weeks
before start of merge window.
As merge window is coming to an end, I feel it may be bad to
ask you this , but still: would it be possible to get the series in
during this merge window.
A recap of what this series is about,
omap-rtc driver used by DaVinci and OMAP1 platforms is being
reused for AM335x. Kicker release mechanism that is handled
by DaVinci platform code has been moved to rtc driver. AM335x
also needs to handle kicker mechanism. DT support has been
added to omap-rtc driver, this was necessitated as AM335x
supports only DT boot (DaVinci platform is also going DT way)
Patch 6 adds AM335x DT support (this probably should go
through omap tree). This series has been tested on beagle bone
and DaVinci DA850 EVM.
Regards
Afzal
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: Hiremath, Vaibhav @ 2012-10-09 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009114326.GA4511@netboy.at.omicron.at>
On Tue, Oct 09, 2012 at 17:13:26, Richard Cochran wrote:
> On Tue, Oct 09, 2012 at 11:19:28AM +0000, Hiremath, Vaibhav wrote:
> > On Tue, Oct 09, 2012 at 16:30:50, Richard Cochran wrote:
> > > On Tue, Oct 09, 2012 at 05:57:22AM +0000, Hiremath, Vaibhav wrote:
> > > >
> > > > I use omap2plus_defconfig + CONFIG_ARM_APPENDED_DTB + CONFIG_ARM_ATAG_DTB_COMPAT and nothing more.
> > > ^
> > > -----------------------------------------+ ???
> > >
> > > But in the u-boot console example you post, you load the dtb into
> > > memory.
> > >
> >
> > Its standard mechanism to boot kernel with DT and it is nothing to do
> > with .config. as mentioned before I have already submitted patch to add dtb
> > target to 'make dtbs'.
>
> You say that you use CONFIG_ARM_APPENDED_DTB, which means:
>
> CONFIG_ARM_APPENDED_DTB:
>
> With this option, the boot code will look for a device tree binary
> (DTB) appended to zImage
> (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
>
> This is meant as a backward compatibility convenience for those
> systems with a bootloader that can't be upgraded to accommodate
> the documented boot protocol using a device tree.
>
> But in the example you gave, you seem to load the dtb in the "normal"
> way, with a dtb-aware u-boot.
>
You don't need this, I just explained what I am doing to boot it.
As I have my own old patch which enabled these two option in
omap2plus_defconfig, which I just carry-forward everytime.
I just tried with plain vanilla omap2plus_defconfig and it works for me.
Below is the log -
> So how do you boot this? With the APPENDED hack? Or just using a
> recent u-boot?
>
Just with recent u-boot.
Thanks,
Vaibhav
Log -
==========================================
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Oct 01 2012 - 11:34:06)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2012.10-rc1-00148-g4668a08 (Oct 01 2012 - 11:34:06)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 80000000 am335x-bone.dtb
reading am335x-bone.dtb
4391 bytes read
U-Boot# fatload mmc 0 81000000 uImage
reading uImage
3821560 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz
2022580 bytes read
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux-3.6.0-08931-g68ff7e3
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3821496 Bytes = 3.6 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 8fe67000, end 8fe6b126 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.6.0-08931-g68ff7e3 (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Oct 9 17:44:06 IST 2012
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0efb000 s12864 r8192 d15808 u36864
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 255MB = 255MB total
[ 0.000000] Memory: 229144k/229144k available, 33000k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06bb85c (6863 kB)
[ 0.000000] .init : 0xc06bc000 - 0xc070c240 ( 321 kB)
[ 0.000000] .data : 0xc070e000 - 0xc0798ee8 ( 556 kB)
[ 0.000000] .bss : 0xc0798f0c - 0xc0cf3ab4 (5483 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768
[ 0.000000] ... CHAINHASH_SIZE: 16384
[ 0.000000] memory used by lock dependency info: 3695 kB
[ 0.000000] per task-struct memory footprint: 1152 bytes
[ 0.001121] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[ 0.107577] pid_max: default: 32768 minimum: 301
[ 0.108250] Security Framework initialized
[ 0.108458] Mount-cache hash table entries: 512
[ 0.118652] CPU: Testing write buffer coherency: ok
[ 0.119785] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.119871] Setting up static identity map for 0x804ce298 - 0x804ce308
[ 0.123042] Brought up 1 CPUs
[ 0.123073] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[ 0.147724] pinctrl core: initialized pinctrl subsystem
[ 0.156016] regulator-dummy: no parameters
[ 0.158598] NET: Registered protocol family 16
[ 0.159557] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.188486] OMAP GPIO hardware version 0.1
[ 0.204625] No ATAGs?
[ 0.204654] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.293226] bio: create slab <bio-0> at 0
[ 0.402131] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.410001] SCSI subsystem initialized
[ 0.413623] usbcore: registered new interface driver usbfs
[ 0.414290] usbcore: registered new interface driver hub
[ 0.415345] usbcore: registered new device driver usb
[ 0.428831] omap_i2c 44e0b000.i2c: bus -1 rev2.4.0 at 400 kHz
[ 0.441955] Switching to clocksource gp_timer
[ 0.597129] NET: Registered protocol family 2
[ 0.599927] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.600427] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[ 0.605341] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.605634] TCP: reno registered
[ 0.605675] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 0.606032] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 0.607195] NET: Registered protocol family 1
[ 0.608857] RPC: Registered named UNIX socket transport module.
[ 0.608886] RPC: Registered udp transport module.
[ 0.608903] RPC: Registered tcp transport module.
[ 0.608919] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.610122] Trying to unpack rootfs image as initramfs...
[ 0.612685] rootfs image is not initramfs (no cpio magic); looks like an initrd
[ 0.770993] Freeing initrd memory: 16384K
[ 0.771185] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.771821] CPU PMU: probing PMU on CPU 0
[ 0.772051] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 0.978472] VFS: Disk quotas dquot_6.5.2
[ 0.978772] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.982461] NFS: Registering the id_resolver key type
[ 0.983116] Key type id_resolver registered
[ 0.983149] Key type id_legacy registered
[ 0.983331] jffs2: version 2.2. (NAND) (SUMMARY) (c) 2001-2006 Red Hat, Inc.
[ 0.984069] msgmni has been set to 479
[ 0.988653] io scheduler noop registered
[ 0.988684] io scheduler deadline registered
[ 0.988807] io scheduler cfq registered (default)
[ 0.992666] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 1.000595] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[ 1.001443] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[ 1.588108] console [ttyO0] enabled
[ 1.632137] brd: module loaded
[ 1.660230] loop: module loaded
[ 1.671413] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.679560] OneNAND driver initializing
[ 1.691146] usbcore: registered new interface driver asix
[ 1.697852] usbcore: registered new interface driver cdc_ether
[ 1.704944] usbcore: registered new interface driver smsc95xx
[ 1.712108] usbcore: registered new interface driver net1080
[ 1.718868] usbcore: registered new interface driver cdc_subset
[ 1.725905] usbcore: registered new interface driver zaurus
[ 1.732737] usbcore: registered new interface driver cdc_ncm
[ 1.741523] usbcore: registered new interface driver cdc_wdm
[ 1.747679] Initializing USB Mass Storage driver...
[ 1.753595] usbcore: registered new interface driver usb-storage
[ 1.760096] USB Mass Storage support registered.
[ 1.765753] usbcore: registered new interface driver usbtest
[ 1.773851] mousedev: PS/2 mouse device common for all mice
[ 1.784873] i2c /dev entries driver
[ 1.791403] Driver for 1-wire Dallas network protocol.
[ 1.801002] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 1.814741] usbcore: registered new interface driver usbhid
[ 1.820899] usbhid: USB HID core driver
[ 1.826796] oprofile: using arm/armv7
[ 1.831661] TCP: cubic registered
[ 1.835441] Initializing XFRM netlink socket
[ 1.840124] NET: Registered protocol family 17
[ 1.845000] NET: Registered protocol family 15
[ 1.850236] Key type dns_resolver registered
[ 1.854894] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 1.863150] ThumbEE CPU extension supported.
[ 1.880211] clock: disabling unused clocks to save power
[ 1.893851] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.904775] RAMDISK: gzip image found at block 0
[ 2.373495] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 2.380564] Freeing init memory: 320K
mount: mounting none on /var/shm failed: No such file or directory
::
:: Enabling hot-plug : [SUCCESS]
::
::
: Populating /dev : [SUCCESS]
[SUCCESS]
::
::
:: Setting PATH
::
: syslogd : [SUCCESS]
: telnetd : [SUCCESS]
^ permalink raw reply
* [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Fabio Estevam @ 2012-10-09 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACKLOr3stV-Pup_w+DwGO3z842hct4RV+_hCVpL7Pu3QRFwH0w@mail.gmail.com>
Hi Javier,
On Tue, Oct 9, 2012 at 8:16 AM, javier Martin
<javier.martin@vista-silicon.com> wrote:
> This patch doesn't fix the BUG it claims to, since I have it working
> properly in our Visstrim M10 platform without it. Look:
Yes, it does fix a real bug. Without this patch the ov2640 cannot be
probed, as it fails to read the product/vendor ID via I2C. I measure
with the scope and do not get mclk at all without this patch.
Again, camera probe does work fine on kernel 3.4.
Does the mx27 feed the mclk to your camera? Which frequency do you
get if you measure it with a scope.
>
> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
> mx2-camera mx2-camera.0: Camera driver attached to camera 0
> ov7670 0-0021: chip found @ 0x42 (imx-i2c)
> [..]
> mx2-camera mx2-camera.0: Camera driver detached from camera 0
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
> frequency: 66500000
This 66.5MHz is wrong.
>
> Furthermore, it's not correct, since there isn't such "per" clock for
> the CSI in 3.5 [1], 3.6 [2], linux-next-20121008[3], or
> next-20121009[4].
Well, you are looking to all git trees after the conversion to the
common clock framework.
Please look at 3.4 kernel instead and you will see that per4 is indeed
used for csi.
"DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);"
In fact, the mx27 reference manual is the correct source for such
information. Please check "Table 39-9. CSI Control Register 1 Field
Descriptions (continued)":
"Sensor Master Clock (MCLK) Divider. This field contains the divisor MCLK.
The MCLK is derived from the PERCLK4."
Can you let me know if this patch breaks things for you? Or what
exactly you think is wrong with it?
It seems that you are camera works by pure luck without this patch.
Maybe you are turning per4 in the bootloader or you get the clock to
your camera from somewhere else.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h
From: Arnd Bergmann @ 2012-10-09 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50726966.5010503@snapgear.com>
On Monday 08 October 2012, Greg Ungerer wrote:
> On 06/10/12 00:55, Arnd Bergmann wrote:
> > On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
> > their arguments, which may lead to harmless build warnings in some
> > code where the variables are not used otherwise. Adding a cast to void
> > gets rid of the warning and does not make any semantic changes.
> >
> > Without this patch, building at91x40_defconfig results in:
> >
> > fs/read_write.c: In function 'rw_copy_check_uvector':
> > fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Greg Ungerer <gerg@uclinux.org>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
Thanks!
> I can pick it up and push to the arm-soc tree.
Well, my idea was that I would prefer the patches go through some other tree
besides arm-soc since they are not really the main purpose for this tree.
The core ARM patches in particular should go through Russell's ARM tree.
I have a few more that come in during the merge window and plan to send
him a pull request for those.
Arnd
^ permalink raw reply
* [PATCH v4 8/8] watchdog: WatchDog Timer Driver Core - fix comment
From: Fabio Porcedda @ 2012-10-09 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349784251-28261-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
include/linux/watchdog.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index b8eec8d..8965e4a 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -174,7 +174,7 @@ static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
return wdd->driver_data;
}
-/* drivers/watchdog/core/watchdog_core.c */
+/* drivers/watchdog/watchdog_core.c */
extern void watchdog_init_timeout(struct watchdog_device *wdd,
unsigned int parm_timeout,
struct device_node *node);
--
1.7.11.3
^ permalink raw reply related
* [PATCH v4 7/8] watchdog: orion_wdt: move the min_timeout initialization
From: Fabio Porcedda @ 2012-10-09 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349784251-28261-1-git-send-email-fabio.porcedda@gmail.com>
Move the min_timeout initialization inside the orion_wdt definition.
Only compile tested.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
---
drivers/watchdog/orion_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 446a3e9..3b4e228 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -140,6 +140,7 @@ static const struct watchdog_ops orion_wdt_ops = {
static struct watchdog_device orion_wdt = {
.info = &orion_wdt_info,
.ops = &orion_wdt_ops,
+ .min_timeout = 1,
};
static int __devinit orion_wdt_probe(struct platform_device *pdev)
@@ -162,7 +163,6 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
- orion_wdt.min_timeout = 1;
orion_wdt.timeout = wdt_max_duration;
orion_wdt.max_timeout = wdt_max_duration;
watchdog_init_timeout(&orion_wdt, heartbeat, pdev->dev.of_node);
--
1.7.11.3
^ permalink raw reply related
* [PATCH v4 6/8] watchdog: at91sam9_wdt: add timeout-sec property binding
From: Fabio Porcedda @ 2012-10-09 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349784251-28261-1-git-send-email-fabio.porcedda@gmail.com>
Tested on at91sam9260 board (evk-pro3).
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/at91sam9_wdt.c | 16 +++++++++++++---
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
index 2957ebb..fcdd48f 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -7,9 +7,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
Example:
watchdog at fffffd40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffd40 0x10>;
+ timeout-sec = <10>;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..dda695f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -114,6 +114,7 @@ config AT91RM9200_WATCHDOG
config AT91SAM9X_WATCHDOG
tristate "AT91SAM9X / AT91CAP9 watchdog"
depends on ARCH_AT91 && !ARCH_AT91RM9200
+ select WATCHDOG_CORE
help
Watchdog timer embedded into AT91SAM9X and AT91CAP9 chips. This will
reboot your system when the timeout is reached.
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index dc42e44..befa369 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -57,8 +57,10 @@
#define WDT_TIMEOUT (HZ/2)
/* User land timeout */
+#define MIN_HEARTBEAT 1
+#define MAX_HEARTBEAT 16
#define WDT_HEARTBEAT 15
-static int heartbeat = WDT_HEARTBEAT;
+static int heartbeat = 0;
module_param(heartbeat, int, 0);
MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. "
"(default = " __MODULE_STRING(WDT_HEARTBEAT) ")");
@@ -255,6 +257,12 @@ static struct miscdevice at91wdt_miscdev = {
.fops = &at91wdt_fops,
};
+static struct watchdog_device at91wdt_wdd __initdata = {
+ .timeout = WDT_HEARTBEAT,
+ .min_timeout = MIN_HEARTBEAT,
+ .max_timeout = MAX_HEARTBEAT,
+};
+
static int __init at91wdt_probe(struct platform_device *pdev)
{
struct resource *r;
@@ -273,6 +281,8 @@ static int __init at91wdt_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ watchdog_init_timeout(&at91wdt_wdd, heartbeat, pdev->dev.of_node);
+
/* Set watchdog */
res = at91_wdt_settimeout(ms_to_ticks(WDT_HW_TIMEOUT * 1000));
if (res)
@@ -282,12 +292,12 @@ static int __init at91wdt_probe(struct platform_device *pdev)
if (res)
return res;
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
+ at91wdt_private.next_heartbeat = jiffies + at91wdt_wdd.timeout * HZ;
setup_timer(&at91wdt_private.timer, at91_ping, 0);
mod_timer(&at91wdt_private.timer, jiffies + WDT_TIMEOUT);
pr_info("enabled (heartbeat=%d sec, nowayout=%d)\n",
- heartbeat, nowayout);
+ at91wdt_wdd.timeout, nowayout);
return 0;
}
--
1.7.11.3
^ 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