[PATCH 1/2][v3] Integrated Flash Controller support
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 Kushwaha --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next) Tested on P1010RDB Changes for v2: Incorporated Artem Bityutskiy's comment - Error handling in fsl_ifc_ctrl_probe - Use module_platform_driver() insted of module_init and module_exit Changes for v3: Incorporated Dmitry Pervushin's comments - Memory mapped structures should be defined with packet attribute arch/powerpc/Kconfig |4 + arch/powerpc/include/asm/fsl_ifc.h | 834 arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/fsl_ifc.c | 310 + 4 files changed, 1149 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/include/asm/fsl_ifc.h create mode 100644 arch/powerpc/sysdev/fsl_ifc.c diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 7c93c7e..d78cb6e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -688,6 +688,10 @@ config FSL_LBC controller. Also contains some common code used by drivers for specific local bus peripherals. +config FSL_IFC + bool +depends on FSL_SOC + config FSL_GTM bool depends on PPC_83xx || QUICC_ENGINE || CPM2 diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/arch/powerpc/include/asm/fsl_ifc.h new file mode 100644 index 000..85472e7 --- /dev/null +++ b/arch/powerpc/include/asm/fsl_ifc.h @@ -0,0 +1,834 @@ +/* Freescale Integrated Flash Controller + * + * Copyright 2011 Freescale Semiconductor, Inc + * + * Author: Dipen Dudhat + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __ASM_FSL_IFC_H +#define __ASM_FSL_IFC_H + +#include +#include +#include + +#include +#include + +#define FSL_IFC_BANK_COUNT 4 + +/* + * CSPR - Chip Select Property Register + */ +#define CSPR_BA0x +#define CSPR_BA_SHIFT 16 +#define CSPR_PORT_SIZE 0x0180 +#define CSPR_PORT_SIZE_SHIFT 7 +/* Port Size 8 bit */ +#define CSPR_PORT_SIZE_8 0x0080 +/* Port Size 16 bit */ +#define CSPR_PORT_SIZE_16 0x0100 +/* Port Size 32 bit */ +#define CSPR_PORT_SIZE_32 0x0180 +/* Write Protect */ +#define CSPR_WP0x0040 +#define CSPR_WP_SHIFT 6 +/* Machine Select */ +#define CSPR_MSEL 0x0006 +#define CSPR_MSEL_SHIFT1 +/* NOR */ +#define CSPR_MSEL_NOR 0x +/* NAND */ +#define CSPR_MSEL_NAND 0x0002 +/* GPCM */ +#define CSPR_MSEL_GPCM 0x0004 +/* Bank Valid */ +#define CSPR_V 0x0001 +#define CSPR_V_SHIFT 0 + +/* + * Address Mask Register + */ +#define IFC_AMASK_MASK 0x +#define IFC_AMASK_SHIFT16 +#define IFC_AMASK(n) (IFC_AMASK_MASK << \ + (__ilog2(n) - IFC_AMASK_SHIFT)) + +/* + * Chip Select Option Register IFC_NAND Machine + */ +/* Enable ECC Encoder */ +#define CSOR_NAND_ECC_ENC_EN 0x8000 +#define CSOR_NAND_ECC_MODE_MASK0x3000 +/* 4 bit correction per 520 Byte sector */ +#define CSOR_NAND_ECC_MODE_4 0x +/* 8 bit correction per 528 Byte sector */ +#define CSOR_NAND_ECC_MODE_8 0x1000 +/* Enable ECC Decoder */ +#define CSOR_NAND_ECC_DEC_EN 0x0400 +/* Row Address Length */ +#define CSOR_NAND_RAL_MASK 0x0180 +#define CSOR_NAND_RAL_SHIFT20 +#define CSOR_NAND_RAL_10x +#define CSOR_NAND_RAL_20x0080 +#define CSOR_NAND_RAL_30x0100 +#define CSOR_NAND_RAL_40x0180 +/* Page Size 512b, 2k, 4k */ +#define CSOR_NAND_PGS_MASK 0x0018 +#define CSOR_NAND_PGS_SHIFT16
[PATCH 2/2] mtd/nand: Fix IFC driver to support 2K NAND page
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/powerpc.git (branch next)
Tested on P1010RDB
drivers/mtd/nand/fsl_ifc_nand.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2df7206..2c02168 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -439,20 +439,16 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
out_be32(&ifc->ifc_nand.nand_fir1,
(IFC_FIR_OP_CW1 << IFC_NAND_FIR1_OP5_SHIFT));
- if (column >= mtd->writesize) {
- /* OOB area --> READOOB */
- column -= mtd->writesize;
- nand_fcr0 |= NAND_CMD_READOOB <<
- IFC_NAND_FCR0_CMD0_SHIFT;
- ifc_nand_ctrl->oob = 1;
- } else if (column < 256)
+ if (column < 256)
/* First 256 bytes --> READ0 */
nand_fcr0 |=
NAND_CMD_READ0 << IFC_NAND_FCR0_CMD0_SHIFT;
- else
- /* Second 256 bytes --> READ1 */
- nand_fcr0 |=
- NAND_CMD_READ1 << IFC_NAND_FCR0_CMD0_SHIFT;
+ }
+
+ if (column >= mtd->writesize) {
+ /* OOB area --> READOOB */
+ column -= mtd->writesize;
+ ifc_nand_ctrl->oob = 1;
}
out_be32(&ifc->ifc_nand.nand_fcr0, nand_fcr0);
@@ -465,7 +461,7 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned
int command,
int full_page;
if (ifc_nand_ctrl->oob) {
out_be32(&ifc->ifc_nand.nand_fbcr,
- ifc_nand_ctrl->index);
+ ifc_nand_ctrl->index - ifc_nand_ctrl->column);
full_page = 0;
} else {
out_be32(&ifc->ifc_nand.nand_fbcr, 0);
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] mtd/nand:Fix wrong address read in is_blank()
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
wrong. It should be calculated on basis of ecc sector size.
Also, in fsl_ifc_run_command() bufferpage is calculated on the basis of ecc
sector
size instead of hard coded value.
Signed-off-by: Poonam Aggrwal
Signed-off-by: Prabhakar Kushwaha
---
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
Tested on P1010RDB
drivers/mtd/nand/fsl_ifc_nand.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 8475b88..2df7206 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -191,7 +191,9 @@ static int is_blank(struct mtd_info *mtd, unsigned int
bufnum)
{
struct nand_chip *chip = mtd->priv;
struct fsl_ifc_mtd *priv = chip->priv;
- u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
+ int bufperpage = mtd->writesize / chip->ecc.size;
+ u8 __iomem *addr = priv->vbase + bufnum / bufperpage
+ * (mtd->writesize * 2);
u32 __iomem *mainarea = (u32 *)addr;
u8 __iomem *oob = addr + mtd->writesize;
int i;
@@ -273,7 +275,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd)
dev_err(priv->dev, "NAND Flash Write Protect Error\n");
if (nctrl->eccread) {
- int bufperpage = mtd->writesize / 512;
+ int bufperpage = mtd->writesize / chip->ecc.size;
int bufnum = (nctrl->page & priv->bufnum_mask) * bufperpage;
int bufnum_end = bufnum + bufperpage - 1;
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mtd/NAND:Fix issues with freescale IFC to support NAND 2K
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 updation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v2] Integrated Flash Controller support
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;
> + u32 res3;
> + __be32 col0;
> + u32 res4;
> + __be32 row1;
> + u32 res5;
> + __be32 col1;
> + u32 res6;
> + __be32 row2;
> + u32 res7;
> + __be32 col2;
> + u32 res8;
> + __be32 row3;
> + u32 res9;
> + __be32 col3;
> + u32 res10[0x24];
> + __be32 nand_fbcr;
> + u32 res11;
> + __be32 nand_fir0;
> + __be32 nand_fir1;
> + __be32 nand_fir2;
> + u32 res12[0x10];
> + __be32 nand_csel;
> + u32 res13;
> + __be32 nandseq_strt;
> + u32 res14;
> + __be32 nand_evter_stat;
> + u32 res15;
> + __be32 pgrdcmpl_evt_stat;
> + u32 res16[0x2];
> + __be32 nand_evter_en;
> + u32 res17[0x2];
> + __be32 nand_evter_intr_en;
> + u32 res18[0x2];
> + __be32 nand_erattr0;
> + __be32 nand_erattr1;
> + u32 res19[0x10];
> + __be32 nand_fsr;
> + u32 res20;
> + __be32 nand_eccstat[4];
> + u32 res21[0x20];
> + __be32 nanndcr;
> + u32 res22[0x2];
> + __be32 nand_autoboot_trgr;
> + u32 res23;
> + __be32 nand_mdr;
> + u32 res24[0x5C];
> +};
If you're using memory-mapped structure, shouldn't it be announced with
__attribute__(packed) ?
> +
> +/*
> + * IFC controller NOR Machine registers
> + */
> +struct fsl_ifc_nor {
> + __be32 nor_evter_stat;
> + u32 res1[0x2];
> + __be32 nor_evter_en;
> + u32 res2[0x2];
> + __be32 nor_evter_intr_en;
> + u32 res3[0x2];
> + __be32 nor_erattr0;
> + __be32 nor_erattr1;
> + __be32 nor_erattr2;
> + u32 res4[0x4];
> + __be32 norcr;
> + u32 res5[0xEF];
> +};
> +
> +/*
> + * IFC controller GPCM Machine registers
> + */
> +struct fsl_ifc_gpcm {
> + __be32 gpcm_evter_stat;
> + u32 res1[0x2];
> + __be32 gpcm_evter_en;
> + u32 res2[0x2];
> + __be32 gpcm_evter_intr_en;
> + u32 res3[0x2];
> + __be32 gpcm_erattr0;
> + __be32 gpcm_erattr1;
> + __be32 gpcm_erattr2;
> + __be32 gpcm_stat;
> + u32 res4[0x1F3];
> +};
...here too...
> +
> +/*
> + * IFC Controller Registers
> + */
> +struct fsl_ifc_regs {
> + __be32 ifc_rev;
> + u32 res1[0x3];
> + struct {
> + __be32 cspr;
> + u32 res2[0x2];
> + } cspr_cs[FSL_IFC_BANK_COUNT];
> + u32 res3[0x18];
> + struct {
> + __be32 amask;
> + u32 res4[0x2];
> + } amask_cs[FSL_IFC_BANK_COUNT];
> + u32 res5[0x18];
> + struct {
> + __be32 csor;
> + u32 res6[0x2];
> + } csor_cs[FSL_IFC_BANK_COUNT];
> + u32 res7[0x18];
> + struct {
> + __be32 ftim[4];
> + u32 res8[0x8];
> + } ftim_cs[FSL_IFC_BANK_COUNT];
> + u32 res9[0x60];
> + __be32 rb_stat;
> + u32 res10[0x2];
> + __be32 ifc_gcr;
> + u32 res11[0x2];
> + __be32 cm_evter_stat;
> + u32 res12[0x2];
> + __be32 cm_evter_en;
> + u32 res13[0x2];
> + __be32 cm_evter_intr_en;
> + u32 res14[0x2];
> + __be32 cm_erattr0;
> + __be32 cm_erattr1;
> + u32 res15[0x2];
> + __be32 ifc_ccr;
> + __be32 ifc_csr;
> + u32 res16[0x2EB];
> + struct fsl_ifc_nand ifc_nand;
> + struct fsl_ifc_nor ifc_nor;
> + struct fsl_ifc_gpcm ifc_gpcm;
> +};
...and here.
> +
> +extern unsigned int convert_ifc_address(phys_addr_t addr_base);
> +extern int fsl_ifc_find(phys_addr_t addr_base);
> +
> +/* overview of the fsl ifc controller */
> +
> +struct fsl_ifc_ctrl {
> + /* device info */
> + struct device *dev;
> + struct fsl_ifc_regs __iomem *regs;
> + int irq;
> + int nand_irq;
> + spinlock_t lock;
> + void*nand;
> +
> + u32 nand_stat;
> + wait_queue_head_t nand_wait;
> +};
> +
> +extern struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
> +
> +
> +#endif /* __ASM_FSL_IFC_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 00/14] DMA-mapping framework redesign preparation
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 > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes > > sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mmc:sdhci: restore the enabled dma when do reset all
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 if the dma is enabled, we should
> restore it after reset all.
>
> Signed-off-by: Shaohui Xie
> ---
> based on http://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git,
> branch 'for-linus'.
>
> drivers/mmc/host/sdhci.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 19ed580..22033c3 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -29,6 +29,7 @@
> #include
>
> #include "sdhci.h"
> +#include "sdhci-esdhc.h"
>
> #define DRIVER_NAME "sdhci"
>
> @@ -176,6 +177,7 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
> {
> unsigned long timeout;
> u32 uninitialized_var(ier);
> + u32 uninitialized_var(dma);
>
> if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
> if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> @@ -189,6 +191,8 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
> if (host->ops->platform_reset_enter)
> host->ops->platform_reset_enter(host, mask);
>
> + dma = sdhci_readl(host, ESDHC_DMA_SYSCTL);
You must not access eSDHC-specific registers in generic SDHCI code
> +
> sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
>
> if (mask & SDHCI_RESET_ALL)
> @@ -214,6 +218,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
>
> if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
> sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
> +
> + if ((dma & ESDHC_DMA_SNOOP) && (mask & SDHCI_RESET_ALL))
> + sdhci_writel(host, dma, ESDHC_DMA_SYSCTL);
> }
>
> static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
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/powerpc/kernel/built-in.o:(.opd+0x960): first defined here > kernel/built-in.o: In function `irq_create_of_mapping': > (.opd+0x15a20): multiple definition of `irq_create_of_mapping' > arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here > kernel/built-in.o: In function `.irq_create_of_mapping': > (.text+0x147030): multiple definition of `.irq_create_of_mapping' > arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here > kernel/built-in.o: In function `.irq_dispose_mapping': > (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' > arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here > > I am not sure what caused this. And have just left it broken. Grant, is your irq remapper misbehaving ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mmc:sdhci: restore the enabled dma when do reset all
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 after reset all.
Signed-off-by: Shaohui Xie
---
based on http://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git,
branch 'for-linus'.
drivers/mmc/host/sdhci.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 19ed580..22033c3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -29,6 +29,7 @@
#include
#include "sdhci.h"
+#include "sdhci-esdhc.h"
#define DRIVER_NAME "sdhci"
@@ -176,6 +177,7 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
unsigned long timeout;
u32 uninitialized_var(ier);
+ u32 uninitialized_var(dma);
if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
@@ -189,6 +191,8 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
if (host->ops->platform_reset_enter)
host->ops->platform_reset_enter(host, mask);
+ dma = sdhci_readl(host, ESDHC_DMA_SYSCTL);
+
sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
if (mask & SDHCI_RESET_ALL)
@@ -214,6 +218,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
+
+ if ((dma & ESDHC_DMA_SNOOP) && (mask & SDHCI_RESET_ALL))
+ sdhci_writel(host, dma, ESDHC_DMA_SYSCTL);
}
static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] offb: Fix setting of the pseudo-palette for >8bpp
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 copies of the color index like
a directcolor framebuffer would do.
This went unnoticed for a long time because it's pretty hard to get offb
to kick in with anything but 8bpp (old BootX under MacOS will do that and
qemu does it).
Signed-off-by: Benjamin Herrenschmidt
---
(resent to the right list)
BTW. Do we have a maintainer to pick up those offb patches I sent ? I'm
happy to carry them in -powerpc instead, it would actually make it easier
for me
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index cb163a5..24e1fc6 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -100,36 +100,32 @@ static int offb_setcolreg(u_int regno, u_int red, u_int
green, u_int blue,
u_int transp, struct fb_info *info)
{
struct offb_par *par = (struct offb_par *) info->par;
- int i, depth;
- u32 *pal = info->pseudo_palette;
-
- depth = info->var.bits_per_pixel;
- if (depth == 16)
- depth = (info->var.green.length == 5) ? 15 : 16;
-
- if (regno > 255 ||
- (depth == 16 && regno > 63) ||
- (depth == 15 && regno > 31))
- return 1;
-
- if (regno < 16) {
- switch (depth) {
- case 15:
- pal[regno] = (regno << 10) | (regno << 5) | regno;
- break;
- case 16:
- pal[regno] = (regno << 11) | (regno << 5) | regno;
- break;
- case 24:
- pal[regno] = (regno << 16) | (regno << 8) | regno;
- break;
- case 32:
- i = (regno << 8) | regno;
- pal[regno] = (i << 16) | i;
- break;
+
+ if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+ u32 *pal = info->pseudo_palette;
+ u32 cr = red >> (16 - info->var.red.length);
+ u32 cg = green >> (16 - info->var.green.length);
+ u32 cb = blue >> (16 - info->var.blue.length);
+ u32 value;
+
+ if (regno >= 16)
+ return -EINVAL;
+
+ value = (cr << info->var.red.offset) |
+ (cg << info->var.green.offset) |
+ (cb << info->var.blue.offset);
+ if (info->var.transp.length > 0) {
+ u32 mask = (1 << info->var.transp.length) - 1;
+ mask <<= info->var.transp.offset;
+ value |= mask;
}
+ pal[regno] = value;
+ return 0;
}
+ if (regno > 255)
+ return -EINVAL;
+
red >>= 8;
green >>= 8;
blue >>= 8;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] offb: Fix setting of the pseudo-palette for >8bpp
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 copies of the color index like
a directcolor framebuffer would do.
This went unnoticed for a long time because it's pretty hard to get offb
to kick in with anything but 8bpp (old BootX under MacOS will do that and
qemu does it).
Signed-off-by: Benjamin Herrenschmidt
---
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index cb163a5..24e1fc6 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -100,36 +100,32 @@ static int offb_setcolreg(u_int regno, u_int red, u_int
green, u_int blue,
u_int transp, struct fb_info *info)
{
struct offb_par *par = (struct offb_par *) info->par;
- int i, depth;
- u32 *pal = info->pseudo_palette;
-
- depth = info->var.bits_per_pixel;
- if (depth == 16)
- depth = (info->var.green.length == 5) ? 15 : 16;
-
- if (regno > 255 ||
- (depth == 16 && regno > 63) ||
- (depth == 15 && regno > 31))
- return 1;
-
- if (regno < 16) {
- switch (depth) {
- case 15:
- pal[regno] = (regno << 10) | (regno << 5) | regno;
- break;
- case 16:
- pal[regno] = (regno << 11) | (regno << 5) | regno;
- break;
- case 24:
- pal[regno] = (regno << 16) | (regno << 8) | regno;
- break;
- case 32:
- i = (regno << 8) | regno;
- pal[regno] = (i << 16) | i;
- break;
+
+ if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+ u32 *pal = info->pseudo_palette;
+ u32 cr = red >> (16 - info->var.red.length);
+ u32 cg = green >> (16 - info->var.green.length);
+ u32 cb = blue >> (16 - info->var.blue.length);
+ u32 value;
+
+ if (regno >= 16)
+ return -EINVAL;
+
+ value = (cr << info->var.red.offset) |
+ (cg << info->var.green.offset) |
+ (cb << info->var.blue.offset);
+ if (info->var.transp.length > 0) {
+ u32 mask = (1 << info->var.transp.length) - 1;
+ mask <<= info->var.transp.offset;
+ value |= mask;
}
+ pal[regno] = value;
+ return 0;
}
+ if (regno > 255)
+ return -EINVAL;
+
red >>= 8;
green >>= 8;
blue >>= 8;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Kernel not booting when supplying boot parameter mem
>> 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 not be used. Thanks Tiejun, This fix was not there in the kernel and with this fix my both kernels are loading when providing mem parameter in the kernel boot parmas. Regards, Farrukh Arshad -Original Message- From: tiejun.chen [mailto:tiejun.c...@windriver.com] Sent: Wednesday, December 28, 2011 11:19 AM To: Arshad, Farrukh Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: Kernel not booting when supplying boot parameter mem Arshad, Farrukh wrote: > Hi Tiejun, > > Thanks for your response. Yes, I am running two kernels one on each core in > SAMP configuration on P1022RDK board. Given is my memory partitioning. Core 0 > is loading fine but Core 1 is not loading. CONFIG_RELOCATABLE is not set. > > -- > Core | Base Address |Size > | Uboot parameters > | Kernel Configuration > | > -|---|-|--|| > Core 0 (MEL RT Kernel)| 0x, | 0x1000, - > 256 (MB)|bootm_low = 0x,, bootm_size = 0x1000, | > CONFIG_PHYSICAL_START = 0x,, CONFIG_KERNEL_START = 0xC000, > | > Core 1 (LTIB Kernel) |0x1000,| 0x0800, - > 128 (MB)|bootm_low = 0x1000,, bootm_size = 0x0800, | > CONFIG_PHYSICAL_START = 0x1000,, CONFIG_KERNEL_START = 0xC000, > | > -- > 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 not be used. Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc related)
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: In function `irq_create_of_mapping': (.opd+0x15a20): multiple definition of `irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here kernel/built-in.o: In function `.irq_create_of_mapping': (.text+0x147030): multiple definition of `.irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here kernel/built-in.o: In function `.irq_dispose_mapping': (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here I am not sure what caused this. And have just left it broken. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpx9qRLyx9F5.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
