http://permalink.gmane.org/gmane.linux.ports.arm.kernel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169132 <pre>please add pmecc_ prefix when it's pmecc spefiction var or function please allocate them manage the j in the for loop please use relaxed version Best Regards, J. </pre> Jean-Christophe PLAGNIOL-VILLARD 2012-05-23T10:01:22 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169131 <pre>pmecc-sector-size as it's pmecc specific Best Regards, J. </pre> Jean-Christophe PLAGNIOL-VILLARD 2012-05-23T09:54:02 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169130 <pre>just return 0 and avoid the if else Best Regards, J. </pre> Jean-Christophe PLAGNIOL-VILLARD 2012-05-23T09:51:41 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169129 <pre>Hi Everyone,   Do you know if this newer chip is compatible with older Micrel devices (supported at mainline)? Did anyone try using it? results?   Please advise, Shmuel Yitzhaki  _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel&lt; at &gt;lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel </pre> Shmuel Yitzhaki 2012-05-22T21:08:39 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169128 <pre> If it can be handled inside the framework somehow. I would want to avoid having several places where clocks inside the same SoC are initialized. Cheers, Peter. </pre> Peter De Schrijver 2012-05-23T09:19:54 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169127 <pre> In that case the clock is actually enabled in clk_prepare and disabled in clk_unprepare I guess (and clk_enable/clk_disable are dummy functions)? What I'm trying to say is that I don't think there are clocks which can be enabled/disabled using non blocking operations, but where a parent change would require a blocking operation. Cheers, Peter. </pre> Peter De Schrijver 2012-05-23T09:16:17 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169123 <pre> I totally agree. Having to track other drivers for bug fixes to apply them on the own driver is not very convenient. As answered to Rob I do not really have a clue how to accomplish this. Oops, here it is for reference, will include it in the next round. #ifndef _IMX_DRM_H_ #define _IMX_DRM_H_ /** * User-desired buffer creation information structure. * * &lt; at &gt;size: requested size for the object. *- this size value would be page-aligned internally. * &lt; at &gt;flags: user request for setting memory type or cache attributes. * &lt; at &gt;handle: returned handle for the object. */ struct imx_drm_gem_create { unsigned int size; unsigned int flags; unsigned int handle; }; struct imx_drm_device; struct imx_drm_crtc; struct imx_drm_crtc_helper_funcs { int (*enable_vblank)(struct drm_crtc *crtc); void (*disable_vblank)(struct drm_crtc *crtc); }; int imx_drm_add_crtc(struct drm_crtc *crtc, struct imx_drm_crtc **new_crtc, const struct drm_crtc_funcs *crtc_funcs, const struct drm_crtc_helper_funcs *crtc_helper_fun</pre> Sascha Hauer 2012-05-23T08:12:53 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169121 <pre>The Programmable Multibit ECC (PMECC) controller is a programmable binary BCH(Bose, Chaudhuri and Hocquenghem) encoder and decoder. This controller can be used to support both SLC and MLC NAND Flash devices. It supports to generate ECC to correct 2, 4, 8, 12 or 24 bits of error per sector of data. To use this driver, the user needs to pass in the correction capability and the sector size. This driver has been tested on AT91SAM9X5-EK and AT91SAM9N12-EK with JFFS2, YAFFS2, UBIFS and mtd-utils. Signed-off-by: Hong Xu &lt;hong.xu&lt; at &gt;atmel.com&gt; Signed-off-by: Josh Wu &lt;josh.wu&lt; at &gt;atmel.com&gt; --- drivers/mtd/nand/atmel_nand.c | 742 ++++++++++++++++++++++++++++++++++++- drivers/mtd/nand/atmel_nand_ecc.h | 117 ++++++ 2 files changed, 856 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 937b080..83903f3 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c &lt; at &gt;&lt; at &gt; -15,6 +15,8 &lt; at &gt;&lt; at &gt; * (u-boot-1.1.5/board/atmel/at91sam9263ek/nand.c</pre> Josh Wu 2012-05-23T07:47:54 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169120 <pre>Signed-off-by: Hong Xu &lt;hong.xu&lt; at &gt;atmel.com&gt; Signed-off-by: Josh Wu &lt;josh.wu&lt; at &gt;atmel.com&gt; --- drivers/mtd/nand/atmel_nand.c | 147 ++++++++++++++++++++----------------- drivers/mtd/nand/atmel_nand_ecc.h | 8 +- 2 files changed, 85 insertions(+), 70 deletions(-) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 2165576..9723702 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c &lt; at &gt;&lt; at &gt; -42,20 +42,15 &lt; at &gt;&lt; at &gt; #include &lt;mach/cpu.h&gt; +/* Hardware ECC registers */ +#include "atmel_nand_ecc.h" + static int use_dma = 1; module_param(use_dma, int, 0); static int on_flash_bbt = 0; module_param(on_flash_bbt, int, 0); -/* Register access macros */ -#define ecc_readl(add, reg)\ -__raw_readl(add + ATMEL_ECC_##reg) -#define ecc_writel(add, reg, value)\ -__raw_writel((value), add + ATMEL_ECC_##reg) - -#include "atmel_nand_ecc.h"/* Hardware ECC registers */ - /* oob layout for large page size * bad block info is on bytes 0 and 1 * the bytes hav</pre> Josh Wu 2012-05-23T07:47:52 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169119 <pre>Signed-off-by: Hong Xu &lt;hong.xu&lt; at &gt;atmel.com&gt; Signed-off-by: Josh Wu &lt;josh.wu&lt; at &gt;atmel.com&gt; --- .../devicetree/bindings/mtd/atmel-nand.txt | 7 +++++++ drivers/mtd/nand/atmel_nand.c | 20 ++++++++++++++++++++ 2 files changed, 27 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt index a200695..895d72b 100644 --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt &lt; at &gt;&lt; at &gt; -16,6 +16,12 &lt; at &gt;&lt; at &gt; Optional properties: - nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default. Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", "soft_bch". +- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware. + Only supported by at91sam9x5 or later sam9 product. +- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC + Controller. Supported values are: 2, 4, 8, 12, 24. +- atme</pre> Josh Wu 2012-05-23T07:47:53 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169118 <pre>Code is based on 3.4-rc2 Changes since v7, add time out for PMECC status reading. modify the oobfree[0].offset to 2. fix coding style. Changes since v6, split into 3 patches. remove of_flat_dt_is_compatible() function. use additional dt parameter "has-pmecc". refine the error handling code. refine original atmel_nand_init_params() function. Changes since v5, add has_pmecc field to replace cpu_has_pmecc() function. Use compatible check in when proble. simplify the pmecc_get_ecc_bytes() function. Changes since v4, fix typo and checkpatch warnings. fix according to JC's suggestion. replace cpu_is_xxx() with DT modify dt binding atmel nand document to add pmecc support. tested in sam9263 without break hw ecc. add ecc.strength. Josh Wu (3): MTD: at91: extract hw ecc initialization to one function MTD: add dt parameters for PMECC MTD: atmel_nand: Update driver to support Programmable Multibit ECC controller .../devicetree/bindings/mtd/atmel-nand.txt | 7 + drivers/mtd/nand/atm</pre> Josh Wu 2012-05-23T07:47:51 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169117 <pre>Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: Thanks for this. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha </pre> Sascha Hauer 2012-05-23T07:47:10 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169114 <pre>Enable TPS65910 mfd, gpio and regulator drivers. This is the PMIC module for Tegra30 based cardhu platform. Signed-off-by: Laxman Dewangan &lt;ldewangan&lt; at &gt;nvidia.com&gt; --- No change from V1. arch/arm/configs/tegra_defconfig | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 1198dd6..26ad2b4 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig &lt; at &gt;&lt; at &gt; -106,16 +106,19 &lt; at &gt;&lt; at &gt; CONFIG_I2C=y CONFIG_I2C_TEGRA=y CONFIG_SPI=y CONFIG_SPI_TEGRA=y +CONFIG_GPIO_TPS65910=y CONFIG_POWER_SUPPLY=y CONFIG_BATTERY_SBS=y CONFIG_SENSORS_LM90=y CONFIG_MFD_TPS6586X=y +CONFIG_MFD_TPS65910=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_VIRTUAL_CONSUMER=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS6586X=y +CONFIG_REGULATOR_TPS65910=y CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SUPPORT_OLD_API is not set </pre> Laxman Dewangan 2012-05-23T06:12:53 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169111 <pre> I inform you my mfd driver has been confirmed by Samuel Oritz and there is no mfd private API. This situation looks unusual that we registers mfd driver and regulator driver separately. But how should we do? For corporation , i'm asking you to consider my suggestion. Thanks. Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel&lt; at &gt;lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel </pre> jonghwa3.lee< at >samsung.com 2012-05-23T05:33:28 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169108 <pre> great, thanks Mike. </pre> Rajendra Nayak 2012-05-23T04:45:29 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169104 <pre> Acked-by: Haojian Zhuang &lt;haojian.zhuang&lt; at &gt;gmail.com&gt; </pre> Haojian Zhuang 2012-05-23T02:02:24 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169095 <pre> I verified that the changes work fine after I applied the IO mem mapping and UART patches. I also briefly looked into the changes and they seems good to me. Let me know if you want me to do a review. Will these changes go to v3.5? Regards, JD </pre> Jiandong Zheng 2012-05-22T22:25:25 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169094 <pre>just a few comments from a cursory review.. I need a bit more time for a more in-depth review but that won't be tonight so I thought I'd send what I have so far.. On Fri, May 18, 2012 at 6:27 AM, Sascha Hauer &lt;s.hauer&lt; at &gt;pengutronix.de&gt; wrote: do you have something like cpu_is_imx2() type macros? It would be preferable not to have a compile time config option for building for certain hw versions. Ie. on OMAP we could do something like 'if (cpu_is_omap3xxx()) { ... }' if there was something that needed to be done different on omap3 family of devices. This way you could choose to build a kernel supporting either a single omap variants, or all omap variants. the fb probably should hold the reference to the GEM obj until it is deleted.. so you don't end up freeing the buffer you are scanning out until you are done scanning it out. Possibly this gets a bit more straightforward if you don't have to special case the default/fbcon framebuffer? IIRC, Laurent had sent a patch recently to fix the same issue i</pre> Rob Clark 2012-05-22T21:28:20 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169093 <pre> Yes, that was what I meant when I said we move everything but the *-setup.c files. Arnd </pre> Arnd Bergmann 2012-05-22T17:09:36 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169092 <pre> A few are now getting merged into v3.5: $ git grep -l [^&lt; at &gt;]mrvl, Documentation/devicetree/bindings/arm/mrvl/intc.txt Documentation/devicetree/bindings/arm/mrvl/mrvl.txt Documentation/devicetree/bindings/arm/mrvl/timer.txt Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Documentation/devicetree/bindings/mtd/orion-nand.txt Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Documentation/devicetree/bindings/serial/mrvl-serial.txt arch/arm/boot/dts/kirkwood-dns320.dts arch/arm/boot/dts/kirkwood-dns325.dts arch/arm/boot/dts/kirkwood-dreamplug.dts arch/arm/boot/dts/kirkwood-ib62x0.dts arch/arm/boot/dts/kirkwood-iconnect.dts arch/arm/boot/dts/kirkwood.dtsi arch/arm/boot/dts/mmp2-brownstone.dts arch/arm/boot/dts/mmp2.dtsi arch/arm/boot/dts/pxa168-aspenite.dts arch/arm/boot/dts/pxa168.dtsi arch/arm/boot/dts/pxa910-dkb.dts arch/arm/boot/dts/pxa910.dtsi arch/arm/mach-mmp/irq.c arch/arm/mach-mmp/mmp-dt.c arch/arm/mach-mmp/mmp2-dt.c arch/arm/mach-mmp/time.c drive</pre> Arnd Bergmann 2012-05-22T17:06:27 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/169091 <pre> Hi Rajendra, This patch looks good to me. I'll take it into my clk-next branch towards 3.6 since I'm done pulling stuff for 3.5. It's good to see CLK_DIVIDER_POWER_OF_TWO finally get used :-) Regards, Mike </pre> Mike Turquette 2012-05-22T20:26:57 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.arm.kernel