Le Mon, 9 Dec 2013 04:33:51 +,
"Gupta, Pekon" a écrit :
> Hi,
>
> >From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> [...]
>
> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
> >> fact, I think
Matthieu CASTET a écrit :
> Hi Paul,
>
> Paul Walmsley a écrit :
>> Hi Matthieu,
>>
>> On Tue, 22 Jan 2013, Paul Walmsley wrote:
>>
>>> Any progress on updating and resending your "omap3 nand : use
>>> NAND_BUSWIDTH_AUTO" patch? We&
Hi Paul,
Paul Walmsley a écrit :
> Hi Matthieu,
>
> On Tue, 22 Jan 2013, Paul Walmsley wrote:
>
>> Any progress on updating and resending your "omap3 nand : use
>> NAND_BUSWIDTH_AUTO" patch? We're in danger of missing the 3.9 merge
>> window if it takes too much longer.
>
> Could you let us
Hi,
Paul Walmsley a écrit :
> Hi
>
> On Wed, 2 Jan 2013, Matthieu CASTET wrote:
> which did not get merged because Tony requested that it should be
> based on top of his cleanup work (which takes priority over adding new
> features):
>
>
Hi Paul,
Paul Walmsley a écrit :
> Hi
>
> On Mon, 3 Dec 2012, Artem Bityutskiy wrote:
>
>> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
>>> - NAND_CMD_READID want an address that it is not scaled on x16 device (it
>>> is always 0x20)
&
Artem Bityutskiy a écrit :
> On Tue, 2012-11-06 at 10:40 -0800, Tony Lindgren wrote:
>>> Where such tree could be found ?
>> You should be able to use omap-for-v3.8/cleanup-headers-gpmc
>> branch as a base for your patches [1].
>
> Is this a stable branch which I may pull into l2-mtd.git? Then I c
Jon Hunter a écrit :
> On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
>>
>> /* caller is expected to have initialized CONFIG1 to cover
>> * at least sync vs async
>> diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
>> b/arch/arm/plat-omap/inc
Igor Grinberg a écrit :
> Cc: Tony Lindgren, Afzal Mohammed,
>
> On 11/06/12 12:51, Matthieu CASTET wrote:
>> This allow to clean the omap nand driver that were trying in x8 and x16 bits
>> mode.
>>
>> This also make work onfi detection on beagleboard :
>
If the platform data give us nand timings (in gpmc_t), we use
them and not use onfi timings.
Tested on omap 3630 (with onfi flash and mode {2, 4 , 5})
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand/omap2.c | 134 ++
1 file changed, 134
We get from onfi param the max speed supported by the chip.
A precomputed table for ONFI timings is generated.
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/nand_base.c |1 +
drivers/mtd/nand/nand_timing.c | 170
Signed-off-by: Matthieu CASTET
---
arch/arm/mach-omap2/gpmc.c |7 ++-
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..3957ffc 100644
--- a
:
[1.914825] ONFI param page 0 valid
[1.919158] ONFI flash detected
[1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
MT29F2G16ABD), page size: 2048, OOB size: 64
platform data devsize is renamed bussize. It now indicate the maximun size of
the nand bus.
Signed-off-by: Matthieu
Parameter Page commands only use the lower 8-bits of the
data bus.
The host shall not issue commands that use a word data width on x16 devices
until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand
- NAND_CMD_READID want an address that it is not scaled on x16 device (it is
always 0x20)
- NAND_CMD_PARAM want 8 bits data
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand/nand_base.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand
Hi,
Orjan Friberg a écrit :
> On 03/02/2012 06:17 PM, Grazvydas Ignotas wrote:
>> IIRC NAND in mainline was broken for very long time on OMAP3, I think
>> it was only fixed in 2.6.39.1.
>
> That seems to be the case; the 2.6.39.1 diff contains the OMAP NAND sub
> page write fix (applied locally)
Javier Martinez Canillas a écrit :
> On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET
> wrote:
>> PS : note that some OMAP ROM support a better protection than Hamming (but
>> the
>> details are not public AFAIK)
>>
>> From OMAP34xx Multimedia Device, Si
Jon Povey a écrit :
> linux-mtd-boun...@lists.infradead.org wrote:
>> I want to be able to use 1-bit ECC for the first partition where I
>> save the loader binary and has to be accessed by the ROM boot but use
>> a 4-bit ECC for my rootfs partition.
>>
>> Does anyone have this same issue?
>
> DM35
Hi,
Javier Martinez Canillas a écrit :
> Hello,
>
> I want to be able to use 1-bit ECC for the first partition where I
> save the loader binary and has to be accessed by the ROM boot but use
> a 4-bit ECC for my rootfs partition.
>
> Does anyone have this same issue?
We use raw programming and c
Abhilash K V a écrit :
> From: Vaibhav Hiremath
>
> In case of AM3517 & AM3505, Smart Reflex is not applicable so
> we must not enable it. So add check for absence of SR feature
> in omap3_twl_init() and return -ENODEV if absence, else continue.
I believe another check should be done :
you have
Hi,
Patra, Nilkesh a écrit :
> On the latest version of MUSB, DMA is not working properly if the Data in the
> packet doesn't start at 32bit aligned address. This issue was found while
> using MUSB as g_ether. The basic ping does not work, if the data in the
> Ethernet packet does not start at
Matthieu CASTET a écrit :
> Hi,
>
> Patra, Nilkesh a écrit :
>> On the latest version of MUSB, DMA is not working properly if the Data in
>> the packet doesn't start at 32bit aligned address. This issue was found
>> while using MUSB as g_ether. The basic pi
21 matches
Mail list logo
