Re: [PATCH 2/4 v4] video, sm501: add edid and commandline support
On Mon, Jan 24, 2011 at 10:57:27AM +0100, Heiko Schocher wrote: > @@ -1884,7 +1935,6 @@ static int __devinit sm501fb_probe(struct > platform_device *pdev) > > if (info->pdata == NULL) { > dev_info(dev, "using default configuration data\n"); > - info->pdata = &sm501fb_def_pdata; > } > > /* probe for the presence of each panel */ I assume this is accidental? I don't see how you're compensating for this in any of the other patches at least, as it's orthogonal from the default mode settings. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
On Tue, Jan 25, 2011 at 08:20:31AM +0100, Heiko Schocher wrote: > @@ -1934,7 +1943,29 @@ static int __devinit sm501fb_probe(struct > platform_device *pdev) > } > > if (info->pdata == NULL) { > - dev_info(dev, "using default configuration data\n"); > + int found = 0; > +#if defined(CONFIG_OF) > + struct device_node *np = pdev->dev.parent->of_node; > + const u8 *prop; > + const char *cp; > + int len; > + > + info->pdata = &sm501fb_def_pdata; > + if (np) { > + /* Get EDID */ > + cp = of_get_property(np, "mode", &len); > + if (cp) > + strcpy(fb_mode, cp); > + prop = of_get_property(np, "edid", &len); > + if (prop && len == EDID_LENGTH) { > + info->edid_data = kmemdup(prop, EDID_LENGTH, > + GFP_KERNEL); > + found = 1; > + } > + } > +#endif > + if (!found) > + dev_info(dev, "using default configuration data\n"); > } > > /* probe for the presence of each panel */ Starting to get a bit pedantic.. but kmemdup() tries to do a kmalloc(), and so can fail. Your other patches handle the info->edid_data == NULL case, in addition to the kfree(), but you're probably going to want to chomp that found assignment incase of the allocation failing and falling back on the default mode. You also don't really have any need to keep the EDID block around after probe as far as I can tell, so you should be able to rework this in to something more like: info->edid_data = kmemdup(..); ... if (info->edid_data) { fb_edid_to_monspecs(..); kfree(info->edid_data); fb_videomode_to_modelist(..); } ... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4 v4] video, sm501: add OF binding to support SM501
- add binding to OF, compatible name "smi,sm501" Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org cc: Randy Dunlap cc: Paul Mundt --- - changes since v1: add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from Paul Mundt. - changes since v2: add comments from Randy Dunlap: - move parameter documentation to Documentation/fb/sm501.txt - changes since v3: - rebased against v2.6.38-rc2 - split in 3 patches - of support patch - get rid of "#if defined(CONFIG_PPC_MPC52xx)" usage hide this in DTS, as Paul suggested. - i/o routine patch - edid support patch - changes since v4 replace remaining CONFIG_PPC_MPC52xx with CONFIG_OF, as it is no longer MPC52xx only. ./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch total: 0 errors, 0 warnings, 117 lines checked 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission. Documentation/powerpc/dts-bindings/sm501.txt | 34 ++ drivers/mfd/sm501.c | 16 +++- drivers/video/sm501fb.c | 33 - 3 files changed, 81 insertions(+), 2 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt diff --git a/Documentation/powerpc/dts-bindings/sm501.txt b/Documentation/powerpc/dts-bindings/sm501.txt new file mode 100644 index 000..7d319fb --- /dev/null +++ b/Documentation/powerpc/dts-bindings/sm501.txt @@ -0,0 +1,34 @@ +* SM SM501 + +The SM SM501 is a LCD controller, with proper hardware, it can also +drive DVI monitors. + +Required properties: +- compatible : should be "smi,sm501". +- reg : contain two entries: +- First entry: System Configuration register +- Second entry: IO space (Display Controller register) +- interrupts : SMI interrupt to the cpu should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: +- mode : select a video mode: +x[-][@] +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. +- little-endian: availiable on big endian systems, to + set different foreign endian. +- big-endian: availiable on little endian systems, to + set different foreign endian. + +Example for MPC5200: + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x 0x0080 + 1 0x03e0 0x0020>; + interrupts = <1 1 3>; + mode = "640x480-32@60"; + edid = [edid-data]; + }; diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c index 558d5f3..5b7a8f4 100644 --- a/drivers/mfd/sm501.c +++ b/drivers/mfd/sm501.c @@ -1377,7 +1377,7 @@ static int __devinit sm501_init_dev(struct sm501_devdata *sm) sm501_register_gpio(sm); } - if (pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) { + if (pdata && pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) { if (!sm501_gpio_isregistered(sm)) dev_err(sm->dev, "no gpio available for i2c gpio.\n"); else @@ -1422,6 +1422,14 @@ static int __devinit sm501_plat_probe(struct platform_device *dev) sm->io_res = platform_get_resource(dev, IORESOURCE_MEM, 1); sm->mem_res = platform_get_resource(dev, IORESOURCE_MEM, 0); + + if (sm->mem_res) + pr_debug("sm501 mem 0x%lx, 0x%lx\n", +sm->mem_res->start, sm->mem_res->end); + if (sm->io_res) + pr_debug("sm501 io 0x%lx, 0x%lx\n", +sm->io_res->start, sm->io_res->end); + if (sm->io_res == NULL || sm->mem_res == NULL) { dev_err(&dev->dev, "failed to get IO resource\n"); ret = -ENOENT; @@ -1735,10 +1743,16 @@ static struct pci_driver sm501_pci_driver = { MODULE_ALIAS("platform:sm501"); +static struct of_device_id __devinitdata of_sm501_match_tbl[] = { + { .compatible = "smi,sm501", }, + { /* end */ } +}; + static struct platform_driver sm501_plat_driver = { .driver = { .name = "sm501", .owner = THIS_MODULE, + .of_match_table = of_sm501_match_tbl, }, .probe = sm501_plat_probe, .remove = sm501_plat_remove, diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c index 30b53ae..bbdb359 100644 --- a/drivers/video/sm501fb.c +++ b/drivers/video/sm501fb.c @@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb, FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_XPAN | FBINFO_
Re: [PATCH] e500: Erratum cpu a005 workaround
On Jan 25, 2011, at 12:02 AM, Liu Yu wrote: > This errata can occur if a single-precision floating-point, double-precision > floating-point or vector floating-point instruction on a mispredicted branch > path signals one of the floating-point data interrupts which are enabled by > the > SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits). This interrupt must be recorded > in a one-cycle window when the misprediction is resolved. If this extremely > rare event should occur, the result could be: > > The SPE Data Exception from the mispredicted path may be reported > erroneously if a single-precision floating-point, double-precision > floating-point or vector floating-point instruction is the second instruction > on the correct branch path. > > According to errata description, some efp instructions > which are not supposed to trigger SPE exceptions > can trigger the exceptions in this case. > However, as we haven't emulated these instructions here, > a signal will send to userspace, and userspace application would exit. > > This patch re-issue the efp instruction that we haven't emulated, > so that hardware can properly execute it again if this case happen. > > Signed-off-by: Liu Yu > --- > This is an erratum workaround patch. > It would be better if the patch can go into 2.6.38. > > arch/powerpc/include/asm/reg.h |2 + > arch/powerpc/math-emu/math_efp.c | 53 +- > 2 files changed, 54 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h > index 6315edc..0abfd91 100644 > --- a/arch/powerpc/include/asm/reg.h > +++ b/arch/powerpc/include/asm/reg.h > @@ -833,6 +833,8 @@ > #define PVR_7450 0x8000 > #define PVR_8540 0x8020 > #define PVR_8560 0x8020 > +#define PVR_VER_E500V1 0x8020 > +#define PVR_VER_E500V2 0x8021 > /* > * For the 8xx processors, all of them report the same PVR family for > * the PowerPC core. The various versions of these processors must be > diff --git a/arch/powerpc/math-emu/math_efp.c > b/arch/powerpc/math-emu/math_efp.c > index 41f4ef3..634830b 100644 > --- a/arch/powerpc/math-emu/math_efp.c > +++ b/arch/powerpc/math-emu/math_efp.c > @@ -1,7 +1,7 @@ > /* > * arch/powerpc/math-emu/math_efp.c > * > - * Copyright (C) 2006-2008 Freescale Semiconductor, Inc. All rights reserved. > + * Copyright (C) 2006-2008, 2010 Freescale Semiconductor, Inc. > * > * Author: Ebony Zhu, > * Yu Liu, > @@ -104,6 +104,8 @@ > #define FP_EX_MASK(FP_EX_INEXACT | FP_EX_INVALID | FP_EX_DIVZERO | \ > FP_EX_UNDERFLOW | FP_EX_OVERFLOW) > > +static int have_e500_cpu_a005_erratum; > + > union dw_union { > u64 dp[1]; > u32 wp[2]; > @@ -652,6 +654,15 @@ update_regs: > return 0; > > illegal: > + if (have_e500_cpu_a005_erratum) { > + /* according to e500 cpu a005 erratum, reissue efp inst */ > + regs->nip -= 4; > +#ifdef DEBUG > + printk(KERN_DEBUG "re-issue efp inst: %08lx\n", speinsn); > +#endif > + return 0; > + } > + > printk(KERN_ERR "\nOoops! IEEE-754 compliance handler encountered > un-supported instruction.\ninst code: %08lx\n", speinsn); > return -ENOSYS; > } > @@ -718,3 +729,43 @@ int speround_handler(struct pt_regs *regs) > > return 0; > } > + > +int __init spe_mathemu_init(void) > +{ > + u32 pvr, maj, min; > + > + pvr = mfspr(SPRN_PVR); > + > + if ((PVR_VER(pvr) == PVR_VER_E500V1) || > + (PVR_VER(pvr) == PVR_VER_E500V2)) { > + maj = PVR_MAJ(pvr); > + min = PVR_MIN(pvr); > + > + /* > + * E500 revision below 1.1, 2.3, 3.1, 4.1, 5.1 > + * need cpu a005 errata workaround > + */ This isn't the way to do this. We normally add entries in cputable.c an add a new cpu_feature_bit for the errata. Than above we'd do: if (cur_cpu_spec->cpu_features & CPU_FTR_E500_A005_ERRATUM) > + switch (maj) { > + case 1: > + if (min < 1) > + have_e500_cpu_a005_erratum = 1; > + break; > + case 2: > + if (min < 3) > + have_e500_cpu_a005_erratum = 1; > + break; > + case 3: > + case 4: > + case 5: > + if (min < 1) > + have_e500_cpu_a005_erratum = 1; > + break; > + default: > + break; > + } > + } > + > + return 0; > +} > + > +module_init(spe_mathemu_init); > -- > 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
Hello Paul, Paul Mundt wrote: > On Tue, Jan 25, 2011 at 07:45:46AM +0100, Heiko Schocher wrote: >> @@ -197,6 +198,15 @@ >> #address-cells = <1>; >> }; >> >> +display@1,0 { >> +compatible = "smi,sm501"; >> +reg = <1 0x 0x0080 >> + 1 0x03e0 0x0020>; >> +mode = "640x480-32@60"; >> +interrupts = <1 1 3>; >> +little-endian; >> +}; >> + > > The endian designation looks good, but it still doesn't explain why you > have a remaining CONFIG_PPC_MPC52xx ifdef encapsulating the property > check in the sm501fb patch. It shouldn't be needed at all. If the > platform supports OF then the property will need to be set one way or the > other, so there is no need for any board or CPU ifdeffery within the > driver itself. Argh, of course you are right, thanks! I post an update for the "sm501fb of support" patch. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
On Tue, Jan 25, 2011 at 07:45:46AM +0100, Heiko Schocher wrote: > @@ -197,6 +198,15 @@ > #address-cells = <1>; > }; > > + display@1,0 { > + compatible = "smi,sm501"; > + reg = <1 0x 0x0080 > +1 0x03e0 0x0020>; > + mode = "640x480-32@60"; > + interrupts = <1 1 3>; > + little-endian; > + }; > + The endian designation looks good, but it still doesn't explain why you have a remaining CONFIG_PPC_MPC52xx ifdef encapsulating the property check in the sm501fb patch. It shouldn't be needed at all. If the platform supports OF then the property will need to be set one way or the other, so there is no need for any board or CPU ifdeffery within the driver itself. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org cc: Paul Mundt --- - changes since v1: - no board specific defconfig file for mpc52xx based boards as suggested from Wolfram Sang - changes since v2: add Ben Dooks, Vincent Sanders and Samuel Ortiz and lkml to cc, as suggested from Paul Mundt. - changes since v3: - rebased against v2.6.38-rc2 - changes since v4: - added Paul Mundt to cc (Sorry forgot this in series v4) ./scripts/checkpatch.pl 0004-powerpc-video-add-SM501-support-for-charon-board.patch total: 0 errors, 0 warnings, 22 lines checked 0004-powerpc-video-add-SM501-support-for-charon-board.patch has no obvious style problems and is ready for submission. arch/powerpc/boot/dts/charon.dts | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts index 9776889..0e00e50 100644 --- a/arch/powerpc/boot/dts/charon.dts +++ b/arch/powerpc/boot/dts/charon.dts @@ -186,6 +186,7 @@ #address-cells = <2>; #size-cells = <1>; ranges = < 0 0 0xfc00 0x0200 + 1 0 0xe000 0x0400 // CS1 range, SM501 3 0 0xe800 0x0008>; flash@0,0 { @@ -197,6 +198,15 @@ #address-cells = <1>; }; + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x 0x0080 + 1 0x03e0 0x0020>; + mode = "640x480-32@60"; + interrupts = <1 1 3>; + little-endian; + }; + mram0@3,0 { compatible = "mtd-ram"; reg = <3 0x0 0x8>; -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] e500: Erratum cpu a005 workaround
This errata can occur if a single-precision floating-point, double-precision floating-point or vector floating-point instruction on a mispredicted branch path signals one of the floating-point data interrupts which are enabled by the SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits). This interrupt must be recorded in a one-cycle window when the misprediction is resolved. If this extremely rare event should occur, the result could be: The SPE Data Exception from the mispredicted path may be reported erroneously if a single-precision floating-point, double-precision floating-point or vector floating-point instruction is the second instruction on the correct branch path. According to errata description, some efp instructions which are not supposed to trigger SPE exceptions can trigger the exceptions in this case. However, as we haven't emulated these instructions here, a signal will send to userspace, and userspace application would exit. This patch re-issue the efp instruction that we haven't emulated, so that hardware can properly execute it again if this case happen. Signed-off-by: Liu Yu --- This is an erratum workaround patch. It would be better if the patch can go into 2.6.38. arch/powerpc/include/asm/reg.h |2 + arch/powerpc/math-emu/math_efp.c | 53 +- 2 files changed, 54 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 6315edc..0abfd91 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -833,6 +833,8 @@ #define PVR_7450 0x8000 #define PVR_8540 0x8020 #define PVR_8560 0x8020 +#define PVR_VER_E500V1 0x8020 +#define PVR_VER_E500V2 0x8021 /* * For the 8xx processors, all of them report the same PVR family for * the PowerPC core. The various versions of these processors must be diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c index 41f4ef3..634830b 100644 --- a/arch/powerpc/math-emu/math_efp.c +++ b/arch/powerpc/math-emu/math_efp.c @@ -1,7 +1,7 @@ /* * arch/powerpc/math-emu/math_efp.c * - * Copyright (C) 2006-2008 Freescale Semiconductor, Inc. All rights reserved. + * Copyright (C) 2006-2008, 2010 Freescale Semiconductor, Inc. * * Author: Ebony Zhu, * Yu Liu, @@ -104,6 +104,8 @@ #define FP_EX_MASK (FP_EX_INEXACT | FP_EX_INVALID | FP_EX_DIVZERO | \ FP_EX_UNDERFLOW | FP_EX_OVERFLOW) +static int have_e500_cpu_a005_erratum; + union dw_union { u64 dp[1]; u32 wp[2]; @@ -652,6 +654,15 @@ update_regs: return 0; illegal: + if (have_e500_cpu_a005_erratum) { + /* according to e500 cpu a005 erratum, reissue efp inst */ + regs->nip -= 4; +#ifdef DEBUG + printk(KERN_DEBUG "re-issue efp inst: %08lx\n", speinsn); +#endif + return 0; + } + printk(KERN_ERR "\nOoops! IEEE-754 compliance handler encountered un-supported instruction.\ninst code: %08lx\n", speinsn); return -ENOSYS; } @@ -718,3 +729,43 @@ int speround_handler(struct pt_regs *regs) return 0; } + +int __init spe_mathemu_init(void) +{ + u32 pvr, maj, min; + + pvr = mfspr(SPRN_PVR); + + if ((PVR_VER(pvr) == PVR_VER_E500V1) || + (PVR_VER(pvr) == PVR_VER_E500V2)) { + maj = PVR_MAJ(pvr); + min = PVR_MIN(pvr); + + /* +* E500 revision below 1.1, 2.3, 3.1, 4.1, 5.1 +* need cpu a005 errata workaround +*/ + switch (maj) { + case 1: + if (min < 1) + have_e500_cpu_a005_erratum = 1; + break; + case 2: + if (min < 3) + have_e500_cpu_a005_erratum = 1; + break; + case 3: + case 4: + case 5: + if (min < 1) + have_e500_cpu_a005_erratum = 1; + break; + default: + break; + } + } + + return 0; +} + +module_init(spe_mathemu_init); -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
On Mon, Jan 24, 2011 at 10:57:38AM +0100, Heiko Schocher wrote: > - changes since v1: > add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from > Paul Mundt. > - changes since v2: > add comments from Randy Dunlap: > - move parameter documentation to Documentation/fb/sm501.txt > - changes since v3: > - rebased against v2.6.38-rc2 > - split in 3 patches > - of support patch > - get rid of "#if defined(CONFIG_PPC_MPC52xx)" usage > hide this in DTS, as Paul suggested. > - i/o routine patch > - edid support patch > [snip] > diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c > index 30b53ae..2ae57aa 100644 > --- a/drivers/video/sm501fb.c > +++ b/drivers/video/sm501fb.c > @@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb, > FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | > FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN; > > +#if defined(CONFIG_PPC_MPC52xx) > +#ifdef __BIG_ENDIAN > + if (of_get_property(info->dev->parent->of_node, "little-endian", NULL)) > + fb->flags |= FBINFO_FOREIGN_ENDIAN; > +#else > + if (of_get_property(info->dev->parent->of_node, "big-endian", NULL)) > + fb->flags |= FBINFO_FOREIGN_ENDIAN; > +#endif > +#endif > /* fixed data */ > > fb->fix.type= FB_TYPE_PACKED_PIXELS; Missed one? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, 4.2.4 does NOT work. 4.1.2 DOES work. Is there some magic PowerPC specific gcc patch somewhere? Should I reorient the computer relative to the planet's magnetic field when I compile with newer gcc? A magic handshake? what? Is anyone using a compiler newer than 4.1.2? Sorry, but I do not know where to go from here? kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs wrote: > Hi, > > If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that > WILL boot on the PowerMac8600 (single 750GX). The previously mentioned > G4 that runs is a dual cpu beast and thus also runs SMP. > > I at least know this (ok, I THINK I know): > > For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS > present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so > much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28 > spinlock safari. > > Don't some funky, optimizery things happen to spinlocks for the NON-smp case? > > I'll see what the 4.2.x gcc does. > > Thanks! > > kevin > > P.S.: There is one other difference for the SMP 4.3.5 compiled > 2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated > code though. Should not be able to nuke the spinlock in kernel/acct.c > > On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs wrote: >> Hi, >> >> Anyone familiar with BootX? Could my problems with the 8600 be related >> to some interaction with BootX? >> >> kevin >> > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: About mpc85xx flash memory allocation
On Tue, Jan 25, 2011 at 11:05 AM, tiejun.chen wrote: > Mitsutaka Amano wrote: >> On Mon, Jan 24, 2011 at 3:48 PM, tiejun.chen >> wrote: >>> Mitsutaka Amano wrote: Hi all, I'm testing the ppc platform is based on mpc85xx. 256MB Flash memory has been installed. Then I found this entries. /proc/vmallocinfo ~~~ 0xc910-0xd9101000 268439552 of_flash_probe+0x290/0x814 ioremap physmap_of allocated 268MB over to the vmalloc. vmalloc space is tight. Why does we need mpc platforms to flash memory allocation? I know >>> This should not be dedicated to so-called mpc platform. And we always use >>> ioremap() to map the device space. And on PPC ioremap also use the same >>> space as >>> vmalloc(). While bootstrap you also can see this associated message like the >>> follows, >>> -- >>> .. >>> * 0xd100..0xffbe9000 : vmalloc & ioremap >> Yeah. My platform says the follow message. >> >> * 0xc900..0xdf00 : vmalloc & ioremap > > Any reason why you don't access > 0xdf00? Higher than 0xdf00 has to map TLB for using other peripherals. it's 400MB over. > >> >> The default vmalloc & ioremap space was about 200MB. so I increased >> that by decreasing lowmem. >> But If possible, I hope to keep default maps. So I don't want to use >> vmalloc & ioremap >> other architectures don't allocate to the vmalloc. The design of the hardware? or Is there the way to use the flash >>> You can open /dev/mem then mmap() with a appropriate offset to access the >>> device >>> space including flash. >> I use the device tree(dts) and define flash partitions. Also I use CFI >> driver and CFI_PHYSMAP_OF for device tree. >> Is there the reference driver in what uses mmap() kernel tree? I think >> I have to write a driver what can support dts and mmap() with a >> appropriate offset to access the device. > > You should not write anything again. And you can access any physical address > directly via /dev/mem from the user space like the following: > > fd = open(/dev/mem,); > mmap(fd + offset); Thanks for letting me know. I want to use in combination with device tree. So I'll write a driver based on physmap_of.c(such as mmap_of.c) Thanks, Mitsutaka > > Tiejun > >> >> Thanks, >> Mitsutaka >> >>> Tiejun >>> memory without vmalloc? Thanks, Mitsutaka > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
On Tue, Jan 25, 2011 at 01:39:39AM +0200, Felix Radensky wrote: > Hi Ira, Scott > > On 01/25/2011 12:26 AM, Ira W. Snyder wrote: > > On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote: > >> Hi, > >> > >> I'm trying to use FSL DMA engine to perform DMA transfer from > >> memory buffer obtained by kmalloc() to PCI memory. This is on > >> custom board based on P2020 running linux-2.6.35. The PCI > >> device is Altera FPGA, connected directly to SoC PCI-E controller. > >> > >> 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device > >> 0004 (rev 01) > >> Subsystem: Altera Corporation Unknown device 0004 > >> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > >> ParErr- Stepping- SERR- FastB2B- > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast > >> >TAbort-SERR- >> Interrupt: pin A routed to IRQ 16 > >> Region 0: Memory at c000 (32-bit, non-prefetchable) > >> [size=128K] > >> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ > >> Queue=0/0 Enable- > >> Address: Data: > >> Capabilities: [78] Power Management version 3 > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > >> PME(D0-,D1-,D2-,D3hot-,D3cold-) > >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- > >> Capabilities: [80] Express Endpoint IRQ 0 > >> Device: Supported: MaxPayload 256 bytes, PhantFunc 0, > >> ExtTag- > >> Device: Latency L0s<64ns, L1<1us > >> Device: AtnBtn- AtnInd- PwrInd- > >> Device: Errors: Correctable- Non-Fatal- Fatal- > >> Unsupported- > >> Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > >> Device: MaxPayload 128 bytes, MaxReadReq 512 bytes > >> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1 > >> Link: Latency L0s unlimited, L1 unlimited > >> Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- > >> Link: Speed 2.5Gb/s, Width x1 > >> Capabilities: [100] Virtual Channel > >> > >> > >> I can successfully writel() to PCI memory via address obtained from > >> pci_ioremap_bar(). > >> Here's my DMA transfer routine > >> > >> static int dma_transfer(struct dma_chan *chan, void *dst, void *src, > >> size_t len) > >> { > >> int rc = 0; > >> dma_addr_t dma_src; > >> dma_addr_t dma_dst; > >> dma_cookie_t cookie; > >> struct completion cmp; > >> enum dma_status status; > >> enum dma_ctrl_flags flags = 0; > >> struct dma_device *dev = chan->device; > >> struct dma_async_tx_descriptor *tx = NULL; > >> unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS); > >> > >> dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE); > >> if (dma_mapping_error(dev->dev, dma_src)) { > >> printk(KERN_ERR "Failed to map src for DMA\n"); > >> return -EIO; > >> } > >> > >> dma_dst = (dma_addr_t)dst; > >> > >> flags = DMA_CTRL_ACK | > >> DMA_COMPL_SRC_UNMAP_SINGLE | > >> DMA_COMPL_SKIP_DEST_UNMAP | > >> DMA_PREP_INTERRUPT; > >> > >> tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); > >> if (!tx) { > >> printk(KERN_ERR "%s: Failed to prepare DMA transfer\n", > >> __FUNCTION__); > >> dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE); > >> return -ENOMEM; > >> } > >> > >> init_completion(&cmp); > >> tx->callback = dma_callback; > >> tx->callback_param =&cmp; > >> cookie = tx->tx_submit(tx); > >> > >> if (dma_submit_error(cookie)) { > >> printk(KERN_ERR "%s: Failed to start DMA transfer\n", > >> __FUNCTION__); > >> return -ENOMEM; > >> } > >> > >> dma_async_issue_pending(chan); > >> > >> tmo = wait_for_completion_timeout(&cmp, tmo); > >> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL); > >> > >> if (tmo == 0) { > >> printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__); > >> rc = -ETIMEDOUT; > >> } else if (status != DMA_SUCCESS) { > >> printk(KERN_ERR "%s: Transfer failed: status is %s\n", > >> __FUNCTION__, > >> status == DMA_ERROR ? "error" : "in progress"); > >> > >> dev->device_control(chan, DMA_TERMINATE_ALL, 0); > >> rc = -EIO; > >> } > >> > >> return rc; > >> } > >> > >> The destination address is PCI memory address returned by > >> pci_ioremap_bar(). > >> The transfer silently fails, destination buffer doesn't change > >> contents, but no > >> error condition is reported. > >> > >> What am I doing wrong ? > >> > >> Thanks a lot in advance. > >> > > Your destination address is wrong. The device_prep_dma
Re: FSL DMA engine transfer to PCI memory
Hi Ira, Scott On 01/25/2011 12:26 AM, Ira W. Snyder wrote: On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote: Hi, I'm trying to use FSL DMA engine to perform DMA transfer from memory buffer obtained by kmalloc() to PCI memory. This is on custom board based on P2020 running linux-2.6.35. The PCI device is Altera FPGA, connected directly to SoC PCI-E controller. 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device 0004 (rev 01) Subsystem: Altera Corporation Unknown device 0004 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-SERR-device; struct dma_async_tx_descriptor *tx = NULL; unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS); dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE); if (dma_mapping_error(dev->dev, dma_src)) { printk(KERN_ERR "Failed to map src for DMA\n"); return -EIO; } dma_dst = (dma_addr_t)dst; flags = DMA_CTRL_ACK | DMA_COMPL_SRC_UNMAP_SINGLE | DMA_COMPL_SKIP_DEST_UNMAP | DMA_PREP_INTERRUPT; tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); if (!tx) { printk(KERN_ERR "%s: Failed to prepare DMA transfer\n", __FUNCTION__); dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE); return -ENOMEM; } init_completion(&cmp); tx->callback = dma_callback; tx->callback_param =&cmp; cookie = tx->tx_submit(tx); if (dma_submit_error(cookie)) { printk(KERN_ERR "%s: Failed to start DMA transfer\n", __FUNCTION__); return -ENOMEM; } dma_async_issue_pending(chan); tmo = wait_for_completion_timeout(&cmp, tmo); status = dma_async_is_tx_complete(chan, cookie, NULL, NULL); if (tmo == 0) { printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__); rc = -ETIMEDOUT; } else if (status != DMA_SUCCESS) { printk(KERN_ERR "%s: Transfer failed: status is %s\n", __FUNCTION__, status == DMA_ERROR ? "error" : "in progress"); dev->device_control(chan, DMA_TERMINATE_ALL, 0); rc = -EIO; } return rc; } The destination address is PCI memory address returned by pci_ioremap_bar(). The transfer silently fails, destination buffer doesn't change contents, but no error condition is reported. What am I doing wrong ? Thanks a lot in advance. Your destination address is wrong. The device_prep_dma_memcpy() routine works in physical addresses only (dma_addr_t type). Your source address looks fine: you're using the result of dma_map_single(), which returns a physical address. Your destination address should be something that comes from struct pci_dev.resource[x].start + offset if necessary. In your lspci output above, that will be 0xc000. Another possible problem: AFAIK you must use the _ONSTACK() variants from include/linux/completion.h for struct completion which are on the stack. Hope it helps, Ira Thanks for your help. I'm now passing the result of pci_resource_start(pdev, 0) as destination address, and destination buffer changes after the transfer. But the contents of source and destination buffers are different. What else could be wrong ? Thanks. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote: > Hi, > > I'm trying to use FSL DMA engine to perform DMA transfer from > memory buffer obtained by kmalloc() to PCI memory. This is on > custom board based on P2020 running linux-2.6.35. The PCI > device is Altera FPGA, connected directly to SoC PCI-E controller. > > 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device > 0004 (rev 01) > Subsystem: Altera Corporation Unknown device 0004 > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast > >TAbort- SERR- Interrupt: pin A routed to IRQ 16 > Region 0: Memory at c000 (32-bit, non-prefetchable) > [size=128K] > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Address: Data: > Capabilities: [78] Power Management version 3 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [80] Express Endpoint IRQ 0 > Device: Supported: MaxPayload 256 bytes, PhantFunc 0, > ExtTag- > Device: Latency L0s <64ns, L1 <1us > Device: AtnBtn- AtnInd- PwrInd- > Device: Errors: Correctable- Non-Fatal- Fatal- > Unsupported- > Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > Device: MaxPayload 128 bytes, MaxReadReq 512 bytes > Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1 > Link: Latency L0s unlimited, L1 unlimited > Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- > Link: Speed 2.5Gb/s, Width x1 > Capabilities: [100] Virtual Channel > > > I can successfully writel() to PCI memory via address obtained from > pci_ioremap_bar(). > Here's my DMA transfer routine > > static int dma_transfer(struct dma_chan *chan, void *dst, void *src, > size_t len) > { > int rc = 0; > dma_addr_t dma_src; > dma_addr_t dma_dst; > dma_cookie_t cookie; > struct completion cmp; > enum dma_status status; > enum dma_ctrl_flags flags = 0; > struct dma_device *dev = chan->device; > struct dma_async_tx_descriptor *tx = NULL; > unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS); > > dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE); > if (dma_mapping_error(dev->dev, dma_src)) { > printk(KERN_ERR "Failed to map src for DMA\n"); > return -EIO; > } > > dma_dst = (dma_addr_t)dst; > > flags = DMA_CTRL_ACK | > DMA_COMPL_SRC_UNMAP_SINGLE | > DMA_COMPL_SKIP_DEST_UNMAP | > DMA_PREP_INTERRUPT; > > tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); > if (!tx) { > printk(KERN_ERR "%s: Failed to prepare DMA transfer\n", > __FUNCTION__); > dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE); > return -ENOMEM; > } > > init_completion(&cmp); > tx->callback = dma_callback; > tx->callback_param = &cmp; > cookie = tx->tx_submit(tx); > > if (dma_submit_error(cookie)) { > printk(KERN_ERR "%s: Failed to start DMA transfer\n", > __FUNCTION__); > return -ENOMEM; > } > > dma_async_issue_pending(chan); > > tmo = wait_for_completion_timeout(&cmp, tmo); > status = dma_async_is_tx_complete(chan, cookie, NULL, NULL); > > if (tmo == 0) { > printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__); > rc = -ETIMEDOUT; > } else if (status != DMA_SUCCESS) { > printk(KERN_ERR "%s: Transfer failed: status is %s\n", > __FUNCTION__, > status == DMA_ERROR ? "error" : "in progress"); > > dev->device_control(chan, DMA_TERMINATE_ALL, 0); > rc = -EIO; > } > > return rc; > } > > The destination address is PCI memory address returned by > pci_ioremap_bar(). > The transfer silently fails, destination buffer doesn't change > contents, but no > error condition is reported. > > What am I doing wrong ? > > Thanks a lot in advance. > Your destination address is wrong. The device_prep_dma_memcpy() routine works in physical addresses only (dma_addr_t type). Your source address looks fine: you're using the result of dma_map_single(), which returns a physical address. Your destination address should be something that comes from struct pci_dev.resource[x].start + offset if necessary. In your lspci output above, that will be 0xc000. Another possible problem: AFAIK you must use the _ONSTACK() variants from include/linux/completion.h for struct completion which are on the stack. Hope it helps, Ira _
Re: FSL DMA engine transfer to PCI memory
On Mon, 24 Jan 2011 23:47:22 +0200 Felix Radensky wrote: > static int dma_transfer(struct dma_chan *chan, void *dst, void *src, > size_t len) > { > int rc = 0; > dma_addr_t dma_src; > dma_addr_t dma_dst; > dma_cookie_t cookie; > struct completion cmp; > enum dma_status status; > enum dma_ctrl_flags flags = 0; > struct dma_device *dev = chan->device; > struct dma_async_tx_descriptor *tx = NULL; > unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS); > > dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE); > if (dma_mapping_error(dev->dev, dma_src)) { > printk(KERN_ERR "Failed to map src for DMA\n"); > return -EIO; > } > > dma_dst = (dma_addr_t)dst; Why are you casting a virtual address to dma_addr_t? > The destination address is PCI memory address returned by > pci_ioremap_bar(). You need the physical address. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FSL DMA engine transfer to PCI memory
Hi, I'm trying to use FSL DMA engine to perform DMA transfer from memory buffer obtained by kmalloc() to PCI memory. This is on custom board based on P2020 running linux-2.6.35. The PCI device is Altera FPGA, connected directly to SoC PCI-E controller. 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device 0004 (rev 01) Subsystem: Altera Corporation Unknown device 0004 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 16 Region 0: Memory at c000 (32-bit, non-prefetchable) [size=128K] Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1 Link: Latency L0s unlimited, L1 unlimited Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Virtual Channel I can successfully writel() to PCI memory via address obtained from pci_ioremap_bar(). Here's my DMA transfer routine static int dma_transfer(struct dma_chan *chan, void *dst, void *src, size_t len) { int rc = 0; dma_addr_t dma_src; dma_addr_t dma_dst; dma_cookie_t cookie; struct completion cmp; enum dma_status status; enum dma_ctrl_flags flags = 0; struct dma_device *dev = chan->device; struct dma_async_tx_descriptor *tx = NULL; unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS); dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE); if (dma_mapping_error(dev->dev, dma_src)) { printk(KERN_ERR "Failed to map src for DMA\n"); return -EIO; } dma_dst = (dma_addr_t)dst; flags = DMA_CTRL_ACK | DMA_COMPL_SRC_UNMAP_SINGLE | DMA_COMPL_SKIP_DEST_UNMAP | DMA_PREP_INTERRUPT; tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); if (!tx) { printk(KERN_ERR "%s: Failed to prepare DMA transfer\n", __FUNCTION__); dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE); return -ENOMEM; } init_completion(&cmp); tx->callback = dma_callback; tx->callback_param = &cmp; cookie = tx->tx_submit(tx); if (dma_submit_error(cookie)) { printk(KERN_ERR "%s: Failed to start DMA transfer\n", __FUNCTION__); return -ENOMEM; } dma_async_issue_pending(chan); tmo = wait_for_completion_timeout(&cmp, tmo); status = dma_async_is_tx_complete(chan, cookie, NULL, NULL); if (tmo == 0) { printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__); rc = -ETIMEDOUT; } else if (status != DMA_SUCCESS) { printk(KERN_ERR "%s: Transfer failed: status is %s\n", __FUNCTION__, status == DMA_ERROR ? "error" : "in progress"); dev->device_control(chan, DMA_TERMINATE_ALL, 0); rc = -EIO; } return rc; } The destination address is PCI memory address returned by pci_ioremap_bar(). The transfer silently fails, destination buffer doesn't change contents, but no error condition is reported. What am I doing wrong ? Thanks a lot in advance. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, I've never done any real kernel debugging. Can anyone give any pointers on how to do early boot debugging on an old world (buggy OF) powermac? Can I do anything using a serial console? A little reading last night suggested that spinlocks are supposed to disappear for single processor machines. I do not understand why they are present in 3.4.6 (at least the symbol anyway)? The 'acct_lock' spin lock was also missing with gcc 4.2.4. kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs wrote: > Hi, > > If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that > WILL boot on the PowerMac8600 (single 750GX). The previously mentioned > G4 that runs is a dual cpu beast and thus also runs SMP. > > I at least know this (ok, I THINK I know): > > For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS > present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so > much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28 > spinlock safari. > > Don't some funky, optimizery things happen to spinlocks for the NON-smp case? > > I'll see what the 4.2.x gcc does. > > Thanks! > > kevin > > P.S.: There is one other difference for the SMP 4.3.5 compiled > 2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated > code though. Should not be able to nuke the spinlock in kernel/acct.c > > On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs wrote: >> Hi, >> >> Anyone familiar with BootX? Could my problems with the 8600 be related >> to some interaction with BootX? >> >> kevin >> > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4 v4] powerpc, video: add SM501 support for charon board.
Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org --- - changes since v1: - no board specific defconfig file for mpc52xx based boards as suggested from Wolfram Sang - changes since v2: add Ben Dooks, Vincent Sanders and Samuel Ortiz and lkml to cc, as suggested from Paul Mundt. - changes since v3: - rebased against v2.6.38-rc2 ./scripts/checkpatch.pl 0004-powerpc-video-add-SM501-support-for-charon-board.patch total: 0 errors, 0 warnings, 22 lines checked 0004-powerpc-video-add-SM501-support-for-charon-board.patch has no obvious style problems and is ready for submission. arch/powerpc/boot/dts/charon.dts | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts index 9776889..0e00e50 100644 --- a/arch/powerpc/boot/dts/charon.dts +++ b/arch/powerpc/boot/dts/charon.dts @@ -186,6 +186,7 @@ #address-cells = <2>; #size-cells = <1>; ranges = < 0 0 0xfc00 0x0200 + 1 0 0xe000 0x0400 // CS1 range, SM501 3 0 0xe800 0x0008>; flash@0,0 { @@ -197,6 +198,15 @@ #address-cells = <1>; }; + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x 0x0080 + 1 0x03e0 0x0020>; + mode = "640x480-32@60"; + interrupts = <1 1 3>; + little-endian; + }; + mram0@3,0 { compatible = "mtd-ram"; reg = <3 0x0 0x8>; -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4 v4] video, sm501: add OF binding to support SM501
- add binding to OF, compatible name "smi,sm501" Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org cc: Randy Dunlap cc: Paul Mundt --- - changes since v1: add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from Paul Mundt. - changes since v2: add comments from Randy Dunlap: - move parameter documentation to Documentation/fb/sm501.txt - changes since v3: - rebased against v2.6.38-rc2 - split in 3 patches - of support patch - get rid of "#if defined(CONFIG_PPC_MPC52xx)" usage hide this in DTS, as Paul suggested. - i/o routine patch - edid support patch ./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch total: 0 errors, 0 warnings, 117 lines checked 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission. Documentation/powerpc/dts-bindings/sm501.txt | 34 ++ drivers/mfd/sm501.c | 16 +++- drivers/video/sm501fb.c | 33 - 3 files changed, 81 insertions(+), 2 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt diff --git a/Documentation/powerpc/dts-bindings/sm501.txt b/Documentation/powerpc/dts-bindings/sm501.txt new file mode 100644 index 000..7d319fb --- /dev/null +++ b/Documentation/powerpc/dts-bindings/sm501.txt @@ -0,0 +1,34 @@ +* SM SM501 + +The SM SM501 is a LCD controller, with proper hardware, it can also +drive DVI monitors. + +Required properties: +- compatible : should be "smi,sm501". +- reg : contain two entries: +- First entry: System Configuration register +- Second entry: IO space (Display Controller register) +- interrupts : SMI interrupt to the cpu should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: +- mode : select a video mode: +x[-][@] +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. +- little-endian: availiable on big endian systems, to + set different foreign endian. +- big-endian: availiable on little endian systems, to + set different foreign endian. + +Example for MPC5200: + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x 0x0080 + 1 0x03e0 0x0020>; + interrupts = <1 1 3>; + mode = "640x480-32@60"; + edid = [edid-data]; + }; diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c index 558d5f3..5b7a8f4 100644 --- a/drivers/mfd/sm501.c +++ b/drivers/mfd/sm501.c @@ -1377,7 +1377,7 @@ static int __devinit sm501_init_dev(struct sm501_devdata *sm) sm501_register_gpio(sm); } - if (pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) { + if (pdata && pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) { if (!sm501_gpio_isregistered(sm)) dev_err(sm->dev, "no gpio available for i2c gpio.\n"); else @@ -1422,6 +1422,14 @@ static int __devinit sm501_plat_probe(struct platform_device *dev) sm->io_res = platform_get_resource(dev, IORESOURCE_MEM, 1); sm->mem_res = platform_get_resource(dev, IORESOURCE_MEM, 0); + + if (sm->mem_res) + pr_debug("sm501 mem 0x%lx, 0x%lx\n", +sm->mem_res->start, sm->mem_res->end); + if (sm->io_res) + pr_debug("sm501 io 0x%lx, 0x%lx\n", +sm->io_res->start, sm->io_res->end); + if (sm->io_res == NULL || sm->mem_res == NULL) { dev_err(&dev->dev, "failed to get IO resource\n"); ret = -ENOENT; @@ -1735,10 +1743,16 @@ static struct pci_driver sm501_pci_driver = { MODULE_ALIAS("platform:sm501"); +static struct of_device_id __devinitdata of_sm501_match_tbl[] = { + { .compatible = "smi,sm501", }, + { /* end */ } +}; + static struct platform_driver sm501_plat_driver = { .driver = { .name = "sm501", .owner = THIS_MODULE, + .of_match_table = of_sm501_match_tbl, }, .probe = sm501_plat_probe, .remove = sm501_plat_remove, diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c index 30b53ae..2ae57aa 100644 --- a/drivers/video/sm501fb.c +++ b/drivers/video/sm501fb.c @@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb, FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN; +#if defined(CONFIG_PPC_MPC52xx) +#ifdef __BIG_ENDIAN + if (of_get_property(info->dev->p
[PATCH 2/4 v4] video, sm501: add edid and commandline support
- add commandline options: sm501fb.mode: Specify resolution as "x[-][@]" sm501fb.bpp: Specify bit-per-pixel if not specified mode - Add support for encoding display mode information in the device tree using verbatim EDID block. If the "edid" entry in the "smi,sm501" node is present, the driver will build mode database using EDID data and allow setting the display modes from this database. Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org cc: Randy Dunlap cc: Paul Mundt --- - changes since v1: add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from Paul Mundt. - changes since v2: add comments from Randy Dunlap: - move parameter documentation to Documentation/fb/sm501.txt - changes since v3: - rebased against v2.6.38-rc2 - split in 3 patches - of support patch - i/o routine patch - edid support patch ./scripts/checkpatch.pl 0002-video-sm501-add-edid-and-commandline-support.patch total: 0 errors, 0 warnings, 123 lines checked 0002-video-sm501-add-edid-and-commandline-support.patch has no obvious style problems and is ready for submission. Documentation/fb/sm501.txt | 10 ++ drivers/video/sm501fb.c| 67 2 files changed, 71 insertions(+), 6 deletions(-) create mode 100644 Documentation/fb/sm501.txt diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt new file mode 100644 index 000..8d17aeb --- /dev/null +++ b/Documentation/fb/sm501.txt @@ -0,0 +1,10 @@ +Configuration: + +You can pass the following kernel command line options to sm501 videoframebuffer: + + sm501fb.bpp=SM501 Display driver: + Specifiy bits-per-pixel if not specified by 'mode' + + sm501fb.mode= SM501 Display driver: + Specify resolution as + "x[-][@]" diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c index c5b4b95..30b53ae 100644 --- a/drivers/video/sm501fb.c +++ b/drivers/video/sm501fb.c @@ -41,6 +41,26 @@ #include #include +#include "edid.h" + +static char *fb_mode = "640x480-16@60"; +static unsigned long default_bpp = 16; + +static struct fb_videomode __devinitdata sm501_default_mode = { + .refresh= 60, + .xres = 640, + .yres = 480, + .pixclock = 20833, + .left_margin= 142, + .right_margin = 13, + .upper_margin = 21, + .lower_margin = 1, + .hsync_len = 69, + .vsync_len = 3, + .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, + .vmode = FB_VMODE_NONINTERLACED +}; + #define NR_PALETTE 256 enum sm501_controller { @@ -77,6 +97,7 @@ struct sm501fb_info { void __iomem*regs2d;/* 2d remapped registers */ void __iomem*fbmem; /* remapped framebuffer */ size_t fbmem_len; /* length of remapped region */ + u8 *edid_data; }; /* per-framebuffer private data */ @@ -1725,9 +1746,16 @@ static int sm501fb_init_fb(struct fb_info *fb, fb->var.vmode = FB_VMODE_NONINTERLACED; fb->var.bits_per_pixel = 16; + if (info->edid_data) { + /* Now build modedb from EDID */ + fb_edid_to_monspecs(info->edid_data, &fb->monspecs); + fb_videomode_to_modelist(fb->monspecs.modedb, +fb->monspecs.modedb_len, +&fb->modelist); + } + if (enable && (pd->flags & SM501FB_FLAG_USE_INIT_MODE) && 0) { /* TODO read the mode from the current display */ - } else { if (pd->def_mode) { dev_info(info->dev, "using supplied mode\n"); @@ -1737,12 +1765,34 @@ static int sm501fb_init_fb(struct fb_info *fb, fb->var.xres_virtual = fb->var.xres; fb->var.yres_virtual = fb->var.yres; } else { - ret = fb_find_mode(&fb->var, fb, + if (info->edid_data) + ret = fb_find_mode(&fb->var, fb, fb_mode, + fb->monspecs.modedb, + fb->monspecs.modedb_len, + &sm501_default_mode, default_bpp); + else + ret = fb_find_mode(&fb->var, fb, NULL, NULL, 0, NULL, 8); - if (ret == 0 || ret == 4) { - dev_err(info->dev, - "failed to get initial mode\n"); + switch (ret) { +
[PATCH 1/4 v4] video, sm501: add I/O functions for use on powerpc
- add read/write functions for using this driver also on powerpc plattforms Signed-off-by: Heiko Schocher cc: linux-fb...@vger.kernel.org cc: devicetree-disc...@ozlabs.org cc: Ben Dooks cc: Vincent Sanders cc: Samuel Ortiz cc: linux-ker...@vger.kernel.org cc: Randy Dunlap cc: Paul Mundt --- - changes since v1: add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from Paul Mundt. - changes since v2: add comments from Randy Dunlap: - move parameter documentation to Documentation/fb/sm501.txt - changes since v3: - rebased against v2.6.38-rc2 - split in 3 patches - of support patch - i/o routine patch - use ioread/write32{be} accessors instead of __do_readl/__do_writel{_be} - edid support patch ./scripts/checkpatch.pl 0001-video-sm501-add-I-O-functions-for-use-on-powerpc.patch total: 0 errors, 0 warnings, 841 lines checked 0001-video-sm501-add-I-O-functions-for-use-on-powerpc.patch has no obvious style problems and is ready for submission. drivers/mfd/sm501.c | 125 +- drivers/video/sm501fb.c | 172 -- include/linux/sm501.h |8 ++ 3 files changed, 161 insertions(+), 144 deletions(-) diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c index 5de3a76..558d5f3 100644 --- a/drivers/mfd/sm501.c +++ b/drivers/mfd/sm501.c @@ -133,10 +133,10 @@ static unsigned long decode_div(unsigned long pll2, unsigned long val, static void sm501_dump_clk(struct sm501_devdata *sm) { - unsigned long misct = readl(sm->regs + SM501_MISC_TIMING); - unsigned long pm0 = readl(sm->regs + SM501_POWER_MODE_0_CLOCK); - unsigned long pm1 = readl(sm->regs + SM501_POWER_MODE_1_CLOCK); - unsigned long pmc = readl(sm->regs + SM501_POWER_MODE_CONTROL); + unsigned long misct = smc501_readl(sm->regs + SM501_MISC_TIMING); + unsigned long pm0 = smc501_readl(sm->regs + SM501_POWER_MODE_0_CLOCK); + unsigned long pm1 = smc501_readl(sm->regs + SM501_POWER_MODE_1_CLOCK); + unsigned long pmc = smc501_readl(sm->regs + SM501_POWER_MODE_CONTROL); unsigned long sdclk0, sdclk1; unsigned long pll2 = 0; @@ -193,29 +193,29 @@ static void sm501_dump_regs(struct sm501_devdata *sm) void __iomem *regs = sm->regs; dev_info(sm->dev, "System Control %08x\n", - readl(regs + SM501_SYSTEM_CONTROL)); + smc501_readl(regs + SM501_SYSTEM_CONTROL)); dev_info(sm->dev, "Misc Control %08x\n", - readl(regs + SM501_MISC_CONTROL)); + smc501_readl(regs + SM501_MISC_CONTROL)); dev_info(sm->dev, "GPIO Control Low %08x\n", - readl(regs + SM501_GPIO31_0_CONTROL)); + smc501_readl(regs + SM501_GPIO31_0_CONTROL)); dev_info(sm->dev, "GPIO Control Hi %08x\n", - readl(regs + SM501_GPIO63_32_CONTROL)); + smc501_readl(regs + SM501_GPIO63_32_CONTROL)); dev_info(sm->dev, "DRAM Control %08x\n", - readl(regs + SM501_DRAM_CONTROL)); + smc501_readl(regs + SM501_DRAM_CONTROL)); dev_info(sm->dev, "Arbitration Ctrl %08x\n", - readl(regs + SM501_ARBTRTN_CONTROL)); + smc501_readl(regs + SM501_ARBTRTN_CONTROL)); dev_info(sm->dev, "Misc Timing %08x\n", - readl(regs + SM501_MISC_TIMING)); + smc501_readl(regs + SM501_MISC_TIMING)); } static void sm501_dump_gate(struct sm501_devdata *sm) { dev_info(sm->dev, "CurrentGate %08x\n", - readl(sm->regs + SM501_CURRENT_GATE)); + smc501_readl(sm->regs + SM501_CURRENT_GATE)); dev_info(sm->dev, "CurrentClock %08x\n", - readl(sm->regs + SM501_CURRENT_CLOCK)); + smc501_readl(sm->regs + SM501_CURRENT_CLOCK)); dev_info(sm->dev, "PowerModeControl %08x\n", - readl(sm->regs + SM501_POWER_MODE_CONTROL)); + smc501_readl(sm->regs + SM501_POWER_MODE_CONTROL)); } #else @@ -231,7 +231,7 @@ static inline void sm501_dump_clk(struct sm501_devdata *sm) { } static void sm501_sync_regs(struct sm501_devdata *sm) { - readl(sm->regs); + smc501_readl(sm->regs); } static inline void sm501_mdelay(struct sm501_devdata *sm, unsigned int delay) @@ -261,11 +261,11 @@ int sm501_misc_control(struct device *dev, spin_lock_irqsave(&sm->reg_lock, save); - misc = readl(sm->regs + SM501_MISC_CONTROL); + misc = smc501_readl(sm->regs + SM501_MISC_CONTROL); to = (misc & ~clear) | set; if (to != misc) { - writel(to, sm->regs + SM501_MISC_CONTROL); + smc501_writel(to, sm->regs + SM501_MISC_CONTROL); sm501_sync_regs(sm);
Re: fsl-esdhc on P2020 weird endianess behavior
On 01/24/11 10:28, tiejun.chen wrote: Elie De Brauwer wrote: On 01/24/11 09:15, tiejun.chen wrote: Elie De Brauwer wrote: On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: Hello list, I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card). However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a very convincing way by the fsl-esdh driver... As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from the Kconfig to rebuild Linux since its unnecessary for your target. Well no, since this gets selected by the fsl-esdhc driver config MMC_SDHCI_OF_ESDHC bool "SDHCI OF support for the Freescale eSDHC controller" depends on MMC_SDHCI_OF select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER help This selects the Freescale eSDHC controller support. If unsure, say N. And if you look in the sdhc-of.esdhc.c (http://lxr.linux.no/#linux+v2.6.37/drivers/mmc/host/sdhci-of-esdhc.c#L75 ) you can see that this driver is very stubborn in using the sdhci_be32bs* variants, so it just won't compile without the BYTE_SWAPPER set. But the entire sdhci_esdhc struct looks odd (for example they do byteswapping for the read_b but nog for the write_b, and it gets only done for the {read|write}_l. I'll try using the 'regular' callbacks here instead of the byteswapped versions. Tiejun why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities. hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior: # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr b502 While for comparison the same value on my (x86) laptop gives: edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr 02b5 In my config I have the following set: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_OF=y CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun -- Elie De Brauwer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
Elie De Brauwer wrote: > On 01/24/11 09:15, tiejun.chen wrote: >> Elie De Brauwer wrote: >>> On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: > Hello list, > > I have a P2020 processor on a custom board which uses the embedded > fsl-esdhc controller. Hardware-wise this is functional and in u-boot > everything seems to behave (mmc part 0 gives the correct partition > table > and ext2ls/fatls are capable of reading the contents of the sd card). > > However as soon as I start Linux (2.6.36), I get all sorts of unwanted > behavior. Linux is unable to detect the partition layout (but if I > do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. >>> >>> This was already partitioned under (x86) Linux, and when I plug it into >> >> I means you should partition the disk on the PPC Linux, not x86. As >> you know x86 >> work with LE for Linux, but PPC with BE. So I think you should >> partition that on >> the same type machine. Can you try it? >> >>> my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 >>> command shows the correct partition table). And this does not explain >> >> I didn't check this implemented codes within u-boot. Maybe u-boot can do >> something to swap MMC ending problem. You can try to get the >> conclusion. Firstly >> you can re-partition that on PPC Linux then check if u-boot can >> identify it >> properly. I guess u-boot still can read that successfully. >> > > Unfortunately two wrongs don't make a right here. When I fdisk it on > target, then on target the partition gets detected, in u-boot it fails > (Unknown partition table). To be honest this was already the behavior > which I expected because the endianness swap was also seen for the card > registers. So I think something more fundamental is wrong (which in turn > smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a > very convincing way by the fsl-esdh driver... As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from the Kconfig to rebuild Linux since its unnecessary for your target. Tiejun > >> >>> why the card registers (such as the scr pasted below) also seem to have >>> their endianess swapped, which will result in other side-effects, such >>> as improper reading of card capabilities. >>> > hexdump of the MBR, I see the endianness is swapped (last 4 bytes > are aa > 55 00 00). Also when I try to obtain the card registers they show the > same behavior: > # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr > b502 > > While for comparison the same value on my (x86) laptop gives: > edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ > > > cat scr > 02b5 > > In my config I have the following set: > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_IO_ACCESSORS=y > CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y > # CONFIG_MMC_SDHCI_PCI is not set > CONFIG_MMC_SDHCI_OF=y > CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun >>> >>> >> > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
On 01/24/11 09:15, tiejun.chen wrote: Elie De Brauwer wrote: On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: Hello list, I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card). However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a very convincing way by the fsl-esdh driver... why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities. hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior: # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr b502 While for comparison the same value on my (x86) laptop gives: edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr 02b5 In my config I have the following set: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_OF=y CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun -- Elie De Brauwer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
Elie De Brauwer wrote: > On 01/24/11 04:26, tiejun.chen wrote: >> Elie De Brauwer wrote: >>> Hello list, >>> >>> I have a P2020 processor on a custom board which uses the embedded >>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot >>> everything seems to behave (mmc part 0 gives the correct partition table >>> and ext2ls/fatls are capable of reading the contents of the sd card). >>> >>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted >>> behavior. Linux is unable to detect the partition layout (but if I do a >> >> Can you re-partition that under Linux? i.e, you can use fdisk to do >> this. Then >> I'm a bit curious what it'll be happened. > > This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? > my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 > command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Tiejun > why the card registers (such as the scr pasted below) also seem to have > their endianess swapped, which will result in other side-effects, such > as improper reading of card capabilities. > >> >>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa >>> 55 00 00). Also when I try to obtain the card registers they show the >>> same behavior: >>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr >>> b502 >>> >>> While for comparison the same value on my (x86) laptop gives: >>> edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ >>> >>> cat scr >>> 02b5 >>> >>> In my config I have the following set: >>> CONFIG_MMC_SDHCI=y >>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y >>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y >>> # CONFIG_MMC_SDHCI_PCI is not set >>> CONFIG_MMC_SDHCI_OF=y >>> CONFIG_MMC_SDHCI_OF_ESDHC=y >> >> At least looks the config is fine. >> >> Tiejun >> > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev