Re: [PATCH v2] omap4-fb: add driver
Hi Jean-Christophe
On Tue, 2013-04-09 at 15:29 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 09:16 Tue 09 Apr , Sascha Hauer wrote:
> > On Mon, Apr 08, 2013 at 09:17:15AM +0200, Jean-Christophe PLAGNIOL-VILLARD
> > wrote:
> > > On 00:15 Mon 08 Apr , Christoph Fritz wrote:
> > > > This patch adds omap4 display controller support.
> > > >
> > > > +
> > > > +static inline void fb_write(uint32_t v, void __iomem *addr)
> > > > +{
> > > > + __raw_writel(v, addr);
> > > > +}
> > > > +
> > > > +static inline uint32_t fb_read(void const __iomem *addr)
> > > > +{
> > > > + return __raw_readl(addr);
> > > > +}
> > > what is the dif?
> >
> > Maybe Christoph understands what you mean here. I don't
> those 2 inline as useless
You want me to purge the "inline" because gcc is smart enough to use
inlining on its own?
Or are you noting that using a function here is overkill for only one
call inside?
I use functions here because it makes debugging more easy and if you
have a weird hardware config, here you can easily adapt the read and
write functions.
> > > > +
> > > > + fbi->regs.dss = dev_request_mem_region(dev,
> > > > OMAP4_FB_RESOURCE_DSS);
> > > > + fbi->regs.dispc = dev_request_mem_region(dev,
> > > > OMAP4_FB_RESOURCE_DISPC);
> > > use named dev_request
> >
> > We don't have such a function.
> yes we do
>
> dev_request_mem_region_by_name
Ok
Thanks
-- Christoph
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] dtc: remove autogenerated modules.order
Signed-off-by: Sascha Hauer --- scripts/dtc/modules.order | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 scripts/dtc/modules.order diff --git a/scripts/dtc/modules.order b/scripts/dtc/modules.order deleted file mode 100644 index e69de29..000 -- 1.8.2.rc2 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] mtd: update NAND manufacturer names from the kernel
On Wed, Apr 10, 2013 at 05:31:37PM +0200, Jan Luebbe wrote:
> Signed-off-by: Jan Luebbe
Applied, thanks
Sascha
> ---
> drivers/mtd/nand/nand_ids.c | 4 +++-
> include/linux/mtd/nand.h| 20 +++-
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index 72593d4..4f8fb02 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -178,7 +178,9 @@ struct nand_manufacturers nand_manuf_ids[] = {
> {NAND_MFR_STMICRO, __NANDSTR("ST Micro")},
> {NAND_MFR_HYNIX, __NANDSTR("Hynix")},
> {NAND_MFR_MICRON, __NANDSTR("Micron")},
> - {NAND_MFR_AMD, __NANDSTR("AMD")},
> + {NAND_MFR_AMD, __NANDSTR("AMD/Spansion")},
> + {NAND_MFR_MACRONIX, __NANDSTR("Macronix")},
> + {NAND_MFR_EON, __NANDSTR("Eon")},
> {0x0, "Unknown"}
> };
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index d2f8648..1df1a7b 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -497,15 +497,17 @@ struct nand_chip {
> /*
> * NAND Flash Manufacturer ID Codes
> */
> -#define NAND_MFR_TOSHIBA 0x98
> -#define NAND_MFR_SAMSUNG 0xec
> -#define NAND_MFR_FUJITSU 0x04
> -#define NAND_MFR_NATIONAL0x8f
> -#define NAND_MFR_RENESAS 0x07
> -#define NAND_MFR_STMICRO 0x20
> -#define NAND_MFR_HYNIX 0xad
> -#define NAND_MFR_MICRON 0x2c
> -#define NAND_MFR_AMD 0x01
> +#define NAND_MFR_TOSHIBA0x98
> +#define NAND_MFR_SAMSUNG0xec
> +#define NAND_MFR_FUJITSU0x04
> +#define NAND_MFR_NATIONAL 0x8f
> +#define NAND_MFR_RENESAS0x07
> +#define NAND_MFR_STMICRO0x20
> +#define NAND_MFR_HYNIX 0xad
> +#define NAND_MFR_MICRON 0x2c
> +#define NAND_MFR_AMD0x01
> +#define NAND_MFR_MACRONIX 0xc2
> +#define NAND_MFR_EON0x92
>
> /**
> * struct nand_flash_dev - NAND Flash Device ID Structure
> --
> 1.8.2.rc2
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/2] mx53-loco: provide the right header for serial downloader
Hi Eric,
On Wed, Apr 10, 2013 at 04:10:57PM +0200, Eric Bénard wrote:
> this patch allows barebox to run when loaded on the iMX53QSB
> using the serial downloader.
What serial downloader do you use? We have a serial downloader here:
git://git.pengutronix.de/git/tools/imx-usb-loader.git
This one works by parsing the flash headers from the images and
executing them manually by doing register writes. It works with
the currently generated images just fine.
I though about integrating this tool into barebox. Part of the reason
for doing this is that this repository also contains a image generation
tool which could replace the compiler/linker mechanism we currently use
to generate i.MX images. Using a dedicated tool for this job seems more
flexible.
>
> Signed-off-by: Eric Bénard
> ---
> arch/arm/boards/freescale-mx53-loco/flash_header.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boards/freescale-mx53-loco/flash_header.c
> b/arch/arm/boards/freescale-mx53-loco/flash_header.c
> index dc1162b..5358f0b 100644
> --- a/arch/arm/boards/freescale-mx53-loco/flash_header.c
> +++ b/arch/arm/boards/freescale-mx53-loco/flash_header.c
> @@ -34,10 +34,17 @@ struct imx_flash_header_v2 __flash_header_section
> flash_header = {
> .header.length = cpu_to_be16(32),
> .header.version = IVT_VERSION,
>
> +#ifdef CONFIG_ARCH_IMX_INTERNAL_BOOT_SERIAL
> + .entry = APP_DEST + 0x400,
> + .dcd_ptr= APP_DEST + offsetof(struct
> imx_flash_header_v2, dcd),
> + .boot_data_ptr = APP_DEST + offsetof(struct
> imx_flash_header_v2, boot_data),
> + .self = APP_DEST,
> +#else
> .entry = APP_DEST + 0x1000,
> .dcd_ptr= APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, dcd),
> .boot_data_ptr = APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, boot_data),
> .self = APP_DEST + 0x400,
> +#endif
We already have a FLASH_HEADER_OFFSET define which seems to solve half
of the problem. Extending the ifdefs already present int the header
file should work better.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/2] mx53-loco: provide the right header for serial downloader
Hi Sascha, Le Thu, 11 Apr 2013 10:02:53 +0200, Sascha Hauer a écrit : > On Wed, Apr 10, 2013 at 04:10:57PM +0200, Eric Bénard wrote: > > this patch allows barebox to run when loaded on the iMX53QSB > > using the serial downloader. > > What serial downloader do you use? We have a serial downloader here: > > git://git.pengutronix.de/git/tools/imx-usb-loader.git > > This one works by parsing the flash headers from the images and > executing them manually by doing register writes. It works with > the currently generated images just fine. > OK I'll give it a try here. I was using a home made tool which works fine on i.MX25/35/51 and that I just adapted to i.MX53 so the problem may be in my tool ;-) Thanks Eric ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[RFC] omap4-fb: use uncached screen_base
If the buffer is cached the image on the LCD is broken. Only some small
lines on the last rows. Flushing the cache "repairs" the image.
Is remap_range the right way to get a non cached buffer?
This patch only covers prealloc_screen, not dynamic
If the buffer is dynamic, is the use of dma_alloc_coherent right? Or should
the buffer remaped again if freed?
---
drivers/video/omap4.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap4.c b/drivers/video/omap4.c
index 5642f25..1ade988 100644
--- a/drivers/video/omap4.c
+++ b/drivers/video/omap4.c
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#include "omap4.h"
struct omap4fb_device {
@@ -489,6 +491,9 @@ static int omap4fb_probe(struct device_d *dev)
fbi->prealloc_screen.addr =
(void __iomem *)pdata->screen->start;
fbi->prealloc_screen.size = resource_size(pdata->screen);
+ remap_range(fbi->prealloc_screen.addr,
+ fbi->prealloc_screen.size,
+ mmu_get_pte_uncached_flags());
}
omap4fb_reset(fbi);
--
1.7.0.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] mtdraw: fix oob read and write
actually ops.ooboffs is not defaulted so when its value gets added to chip->oob_poi in nand_fill_oob or nand_transfer_oob the respective memcpy is using a wrong address. With this patch, both md -s /dev/nandraw0 and cp xyz /dev/nandraw0.sb are working fine on an i.MX28 target (instead of crashing the board). Signed-off-by: Eric Bénard --- drivers/mtd/mtdraw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/mtdraw.c b/drivers/mtd/mtdraw.c index 384104e..c289e8d 100644 --- a/drivers/mtd/mtdraw.c +++ b/drivers/mtd/mtdraw.c @@ -98,6 +98,7 @@ static ssize_t mtdraw_read_unaligned(struct mtd_info *mtd, void *dst, if (!tmp) return -ENOMEM; ops.mode = MTD_OOB_RAW; + ops.ooboffs = 0; ops.datbuf = tmp; ops.len = mtd->writesize; ops.oobbuf = tmp + mtd->writesize; @@ -152,6 +153,7 @@ static ssize_t mtdraw_blkwrite(struct mtd_info *mtd, const void *buf, int ret; ops.mode = MTD_OOB_RAW; + ops.ooboffs = 0; ops.datbuf = (void *)buf; ops.len = mtd->writesize; ops.oobbuf = (void *)buf + mtd->writesize; -- 1.7.11.7 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] OMAP4: add command to select next boot device priority
On Tue, Apr 09, 2013 at 11:48:19PM +0200, Vicente Bergas wrote: > On OMAP4 SoC there is a SAR memory region (Save & Rescue) > where the ROM code reads the device to boot from. > This patch adds a way to set this. > > Signed-off-by: Vicente Bergas Applied, thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v2] nand_base: detect more ONFI flash
On Wed, Apr 10, 2013 at 06:04:52PM +0200, Eric Bénard wrote: > if the flash has a known type, the ONFI detection won't occur > and thus we may not detect the right parameters. > By testing both namd and pagesize, as done in the kernel, we > can detect ONFI flash with know IDs. > > As an example on an i.MX53 board : > - without the patch : > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 > (Micron NAND 1GiB 3,3V 8-bit), page size: 4096, OOB size: 128 > > - with the patch : > ONFI flash detected ... ONFI param page 0 valid > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 > (Micron MT29F8G08ABACAWP), page size: 4096, OOB size: 224 > > in the first case the OOB size is wrong. > > Signed-off-by: Eric Bénard Applied, thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
