Integrated Flash Controller supports various flashes like NOR, NAND
and other devices using NOR, NAND and GPCM Machine available on it.
IFC supports four chip selects.
Signed-off-by: Dipen Dudhat
Signed-off-by: Scott Wood
Signed-off-by: Li Yang
Signed-off-by: Liu Shuo
Signed-off-by: Prabhakar
1) OOB area should be updated irrespective of NAND page size. Earlier it was
updated only for 512byte NAND page.
2) During OOB update fbcr should be equal to OOB size.
Signed-off-by: Poonam Aggrwal
Signed-off-by: Prabhakar Kushwaha
---
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerp
IFC NAND Machine calculates ECC on 512byte sector. Same is taken care in
fsl_ifc_run_command() while ECC status verification. Here buffer number is
calculated assuming 512byte sector and same is passed to is_blank.
However in is_blank() buffer address is calculated using mdt->writesize which is
wro
This Patch series takes care issues with Freescale IFC driver for supporting 2K
page size NAND with ECC enabled.
[PATCH 1/2] mtd/nand:Fix wrong address read in is_blank()
Fix driver issue when ECC enabled.
[PATCH 2/2] mtd/nand: Fix IFC driver to support 2K NAND page
Fix driver during OOB upda
On Tue, 2011-12-27 at 17:39 +0530, Prabhakar Kushwaha wrote:
[...]
> +/*
> + * IFC Controller NAND Machine registers
> + */
> +struct fsl_ifc_nand {
> + __be32 ncfgr;
> + u32 res1[0x4];
> + __be32 nand_fcr0;
> + __be32 nand_fcr1;
> + u32 res2[0x8];
> + __be32 row0;
> + u
Hello,
On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote:
> On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote:
> [...]
> > > > Usually these drivers don't touch the buffer data at all, so the mapping
> > > > in kernel virtual address space is not needed. We can introduce
> > > >
On 28/12/11 11:41, Shaohui Xie wrote:
> If dma is enabled, it'll be cleared when reset all is performed, this can
> be observed on some platforms, such as P2041 which has a version 2.3
> controller, but platform like P4080 which has a version 2.2 controller,
> does not suffer this, so we will check
On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote:
> Hi ,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> kernel/built-in.o: In function `irq_dispose_mapping':
> (.opd+0x159f0): multiple definition of `irq_dispose_mapping'
> arch/p
If dma is enabled, it'll be cleared when reset all is performed, this can
be observed on some platforms, such as P2041 which has a version 2.3
controller, but platform like P4080 which has a version 2.2 controller,
does not suffer this, so we will check if the dma is enabled, we should
restore it a
When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
and doesn't touch the color map even if it has a corresponding access method
for the real hardware.
Thus it needs to set the pseudo-palette with all 3 components of the color,
like other truecolor framebuffers, not with co
When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
and doesn't touch the color map even if it has a corresponding access method
for the real hardware.
Thus it needs to set the pseudo-palette with all 3 components of the color,
like other truecolor framebuffers, not with co
>> Please check if the following commit is already in your kernel:
>> --
>> powerpc: Fix memory limits when starting at a non-zero address
>> memblock_enforce_memory_limit() takes the desired maximum quantity of
>> memory
>> to end up with, not an address above which memory will n
Hi ,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
kernel/built-in.o: In function `irq_dispose_mapping':
(.opd+0x159f0): multiple definition of `irq_dispose_mapping'
arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here
kernel/built-in.o
13 matches
Mail list logo
