* Re: RFC: MPC5200 PSC AC97 driver
From: Olaf Hering @ 2008-04-22 14:20 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804171619.56615.jbe@pengutronix.de>
On Thu, Apr 17, Juergen Beisert wrote:
> if someone is interested: Here the full patch to get sound support for
> MPC5200b and a current 2.6.25 kernel.
It misses a 'MODULE_DEVICE_TABLE(of, mpc52xx_ac97_of_match);' and a nul
termination of struct mpc52xx_ac97_of_match.
This will allow autoload of the drivers, as it is done in most other
kernel drivers.
Olaf
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Christian Ehrhardt @ 2008-04-22 14:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Detlev Zundel, Hollis Blanchard
In-Reply-To: <480DE89B.2030402@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
Sergei Shtylyov wrote:
> Hello.
>
> Christian Ehrhardt wrote:
>
[...]
>
>> The Documentation of the 440EPx core lists these spaces:
>> PCI 1 Memory 1 8000 0000 1 BFFF FFFF 1GB
>> I/O 1 E800 0000 1 E800 FFFF 64KB
>> I/O 1 E880 0000 1 EBFF FFFF 56MB
>
> Having 2 I/O spaces looks just wrong. Actually, PCs do well with only
> 64K of I/O space.
>
ok - I just wanted to be complete.
I removed the 56M section from the new dts file patch.
[...]
>> radeonfb: EDID probed
>> Parsing EDID data for panel info
>> Setting up default mode based on panel info
>> radeonfb (0000:00:0a.0): ATI Radeon Y`
>
> Hm, what's that Y`?
Thats the final message in the radeonfb driver ater initializing everything.
printk ("radeonfb (%s): %s\n", pci_name(rinfo->pdev), rinfo->name);
I wonder why that rinfo->name is clobbered - maybe another issue, I have to keep that in mind.
[...]
>
> I think you'd better use Ben's patch that he's just posted:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=18034
>
> WBR, Sergei
yep - I use Ben's patch now which reduces my patch to the actual dts fix.
Updated patch attached.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
[-- Attachment #2: fix-sequoia-pci-memory-dts --]
[-- Type: text/plain, Size: 1470 bytes --]
Subject: [PATCH][dts]: fix pci mem in sequoia dts
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
This patch is fixing the sequoia.dts device tree file to the values defined
in the 440Epx data sheet from amcc.
That fixes an issue where my graphic card could not initialize because the pci
resource space was not big enough.
The related mail thread about the backgrounds of this has the subject "pci
issue - wrong detection of pci ressources"
Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---
[diffstat]
sequoia.dts | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -344,9 +344,13 @@
/* Outbound ranges, one memory and one IO,
* later cannot be changed. Chip supports a second
* IO range but we don't use it for now
+ * From the 440EPx user manual:
+ * PCI 1 Memory 1 8000 0000 1 BFFF FFFF 1GB
+ * I/O 1 E800 0000 1 E800 FFFF 64KB
+ * I/O 1 E880 0000 1 EBFF FFFF 56MB
*/
- ranges = <02000000 0 80000000 1 80000000 0 10000000
- 01000000 0 00000000 1 e8000000 0 00100000>;
+ ranges = <02000000 0 80000000 1 80000000 0 40000000
+ 01000000 0 00000000 1 e8000000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Michel Dänzer @ 2008-04-22 14:27 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: linuxppc-dev, Hollis Blanchard, Detlev Zundel
In-Reply-To: <480DF46F.9090900@linux.vnet.ibm.com>
On Tue, 2008-04-22 at 16:21 +0200, Christian Ehrhardt wrote:
>
> >> radeonfb: EDID probed
> >> Parsing EDID data for panel info
> >> Setting up default mode based on panel info
> >> radeonfb (0000:00:0a.0): ATI Radeon Y`
> >
> > Hm, what's that Y`?
>
> Thats the final message in the radeonfb driver ater initializing everything.
> printk ("radeonfb (%s): %s\n", pci_name(rinfo->pdev), rinfo->name);
> I wonder why that rinfo->name is clobbered - maybe another issue, I
> have to keep that in mind.
It isn't clobbered, it's just the PCI device ID printed as characters.
That was a human readable string with early Radeons and thus convenient
for identifying them between humans, but that's no longer the case with
newer ones.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Scott Wood @ 2008-04-22 15:08 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804221055.09038.laurentp@cse-semaphore.com>
On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> On Monday 21 April 2008 19:56, Scott Wood wrote:
> > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > bitbanged MDIO. It might nice to keep the gpiolib bit separate to avoid
> > situations such as ep8248e where mdiobb would be the only thing requiring
> > a gpiolib binding, though -- but it shouldn't be two separate bitbang
> > drivers, just the existing bitbang driver plus some glue code that binds
> > it to gpiolib.
>
> I would be fine with that if the glue code wasn't 90% of the whole driver.
> There is really little (not to say nothing) that can be shared between the
> two drivers.
I think we're thinking of a different pair of drivers... I thought you
were talking about duplicating drivers/net/phy/mdio-bitbang.c, not
drivers/net/fs_enet/mii-bitbang.c.
-Scott
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Laurent Pinchart @ 2008-04-22 15:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080422150844.GA15474@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > > bitbanged MDIO. It might nice to keep the gpiolib bit separate to avoid
> > > situations such as ep8248e where mdiobb would be the only thing
> > > requiring a gpiolib binding, though -- but it shouldn't be two separate
> > > bitbang drivers, just the existing bitbang driver plus some glue code
> > > that binds it to gpiolib.
> >
> > I would be fine with that if the glue code wasn't 90% of the whole driver.
> > There is really little (not to say nothing) that can be shared between the
> > two drivers.
>
> I think we're thinking of a different pair of drivers... I thought you
> were talking about duplicating drivers/net/phy/mdio-bitbang.c, not
> drivers/net/fs_enet/mii-bitbang.c.
I don't plan to touch drivers/net/phy/mdio-bitbang.c at all, it does its job
well enough.
As the openfirmware + gpio + mdio driver might benefit non-powerpc platforms,
I plan to create a new driver (probably drivers/net/phy/mdio-ofgpio.c) that
mostly ports drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this replaces
around 90% of the code).
If both drivers/net/fs_enet/mii-bitbang.c and drivers/net/phy/mdio-ofgpio.c
must live together, I'll have a problem in
drivers/net/fs_enet/fs_enet-main.c. The net device probing code searches the
device tree for an associated PHY, and creates a PHY id from the PHY node. As
the id will be generated from different bus ids in the two mdio drivers (the
bus number is the register address for drivers/net/fs_enet/mii-bitbang.c, and
is the gpio index for drivers/net/phy/mdio-ofgpio.c), things will break.
Any idea regarding how to get rid of that fs_enet/mii-bitbang hardcoded
dependency ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Anton Vorontsov @ 2008-04-22 15:36 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, netdev
In-Reply-To: <200804221721.51461.laurentp@cse-semaphore.com>
On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> > On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > > > bitbanged MDIO. It might nice to keep the gpiolib bit separate to avoid
> > > > situations such as ep8248e where mdiobb would be the only thing
> > > > requiring a gpiolib binding, though -- but it shouldn't be two separate
> > > > bitbang drivers, just the existing bitbang driver plus some glue code
> > > > that binds it to gpiolib.
> > >
> > > I would be fine with that if the glue code wasn't 90% of the whole driver.
> > > There is really little (not to say nothing) that can be shared between the
> > > two drivers.
> >
> > I think we're thinking of a different pair of drivers... I thought you
> > were talking about duplicating drivers/net/phy/mdio-bitbang.c, not
> > drivers/net/fs_enet/mii-bitbang.c.
>
> I don't plan to touch drivers/net/phy/mdio-bitbang.c at all, it does its job
> well enough.
>
> As the openfirmware + gpio + mdio driver might benefit non-powerpc platforms,
> I plan to create a new driver (probably drivers/net/phy/mdio-ofgpio.c) that
> mostly ports drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this replaces
> around 90% of the code).
>
> If both drivers/net/fs_enet/mii-bitbang.c and drivers/net/phy/mdio-ofgpio.c
> must live together, I'll have a problem in
> drivers/net/fs_enet/fs_enet-main.c. The net device probing code searches the
> device tree for an associated PHY, and creates a PHY id from the PHY node. As
> the id will be generated from different bus ids in the two mdio drivers (the
> bus number is the register address for drivers/net/fs_enet/mii-bitbang.c, and
> is the gpio index for drivers/net/phy/mdio-ofgpio.c), things will break.
>
> Any idea regarding how to get rid of that fs_enet/mii-bitbang hardcoded
> dependency ?
Hm... PHYs are having bus_id equal to MDIOBUS:PHYID, for example
e0024520:02, see fs_enet-main.c find_phy() and fs_init_phy():
data = of_get_property(np, "phy-handle", &len);
phynode = of_find_node_by_phandle(*data);
mdionode = of_get_parent(phynode);
ret = of_address_to_resource(mdionode, 0, &res);
data = of_get_property(phynode, "reg", &len);
snprintf(fpi->bus_id, 16, PHY_ID_FMT, res.start, *data);
...
phydev = phy_connect(dev, fep->fpi->bus_id, &fs_adjust_link, 0,
PHY_INTERFACE_MODE_MII);
So in the device tree you could do this:
mdio@<GPIO bank addr> {
compatible = "linux,mdio-gpio";
...
phy123: ethernet-phy@2 {
reg = <2>;
device_type = "ethernet-phy";
};
};
ethernet@... {
...
compatible = "fs_enet";
...
phy-handle = <&phy123>;
};
And fs_enet will match mdio-ofgpio driver.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Scott Wood @ 2008-04-22 15:36 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804221721.51461.laurentp@cse-semaphore.com>
On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> As the openfirmware + gpio + mdio driver might benefit non-powerpc platforms,
> I plan to create a new driver (probably drivers/net/phy/mdio-ofgpio.c) that
> mostly ports drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this replaces
> around 90% of the code).
>
> If both drivers/net/fs_enet/mii-bitbang.c and drivers/net/phy/mdio-ofgpio.c
> must live together,
The only reason I can see for that would be if the gpiolib version
doesn't work on arch/ppc -- but that's not going to be a problem for very
much longer.
> I'll have a problem in drivers/net/fs_enet/fs_enet-main.c. The net
> device probing code searches the device tree for an associated PHY, and
> creates a PHY id from the PHY node. As the id will be generated from
> different bus ids in the two mdio drivers (the bus number is the
> register address for drivers/net/fs_enet/mii-bitbang.c, and is the gpio
> index for drivers/net/phy/mdio-ofgpio.c), things will break.
>
> Any idea regarding how to get rid of that fs_enet/mii-bitbang hardcoded
> dependency ?
If mii-bitbang is only used on arch/ppc, then #ifdef CONFIG_PPC_MERGE
should do it.
It'd be nice to be able to give phylib an OF node rather than a string,
though...
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
From: Sergei Shtylyov @ 2008-04-22 15:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, linux-fbdev-devel, linux-kernel,
adaplas
In-Reply-To: <20080422012726.42775DE2A3@ozlabs.org>
Benjamin Herrenschmidt wrote:
> This fixes atyfb to not truncate 64 bits resources on 32 bits
> platforms. Unfortunately, there are still issues with addresses
> returned to userspace via struct fb_fix_screeninfo. This will
> have to be dealt with separately.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[...]
> --- linux-work.orig/drivers/video/aty/atyfb_base.c 2008-04-22 11:21:46.000000000 +1000
> +++ linux-work/drivers/video/aty/atyfb_base.c 2008-04-22 11:23:58.000000000 +1000
> @@ -2842,7 +2842,7 @@ static int atyfb_setcolreg(u_int regno,
> #ifdef __sparc__
>
> static int __devinit atyfb_setup_sparc(struct pci_dev *pdev,
> - struct fb_info *info, unsigned long addr)
> + struct fb_info *info, resource_size_t addr)
Not sure what that change gives us -- this function mostly treats 'addr'
as unsigned long (casting it to char/void *), ot compares it to 'unsigned
long' 'base' variable -- which should be made 'resource_size_t' in its turn
being assigned resource's start value. So, this part of patch looks incomplete
(and yet I'm not sure if SPARC really needs all that)...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
From: Christian Ehrhardt @ 2008-04-22 15:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev-devel, Hollis Blanchard, adaplas, linux-kernel,
linuxppc-dev, Andrew Morton, Detlev Zundel
In-Reply-To: <20080422012723.BA9F2DE13F@ozlabs.org>
Benjamin Herrenschmidt wrote:
> This fixes radeonfb to not truncate 64 bits resources on 32 bits
> platforms. Unfortunately, there are still issues with addresses
> returned to userspace via struct fb_fix_screeninfo. This will
> have to be dealt with separately.
Thanks for this patch Benjamin, I use it together with what we have discussed in the "pci issue - wrong detection of pci ressources" thread.
Unfortunately I now hit exactly that issue with fb_fix_screeninfo you describe.
For everyone the fb_fix_screeninfo has two "unsigned long" vars that need to strore a IO address.
This fails in my case with a 32bit powerpc system (=sizeof(long)=4) which has paddr >4Gb and actually it should affect any 32bit platform with paddr>4Gb.
You see it e.g. when you try to initialize X11, the x11 radeon driver issues a FBIOGET_FSCREENINFO ioctl and because our address is >4Gb it get's clobbered by that unsigned long in the fb_fix_screeninfo structure (the value comes from a resource_size_t variable which has the correct 64bit).
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
[...]
unsigned long mmio_start; /* Start of Memory Mapped I/O */
[...]
I tried the stupid solution to just change the fb_fix_screeninfo structure to resource_size_t, but that changes the size ioctl transports and would require awareness in the userspace applications using that ioctl.
The X11 & Framebuffer driver work on 64bit systems, so I think it's just an issue of not cutting that data down to 32bit when transporting it (has anyone already checked the x11 drivers, I hope they don't use unsigned long too).
I wanted to ask if there are any known workarounds atm that would allow me to use my X11 for now?
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Laurent Pinchart @ 2008-04-22 15:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080422153652.GF15474@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
On Tuesday 22 April 2008 17:36, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> > As the openfirmware + gpio + mdio driver might benefit non-powerpc
> > platforms, I plan to create a new driver (probably
> > drivers/net/phy/mdio-ofgpio.c) that mostly ports
> > drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this replaces around 90%
> > of the code).
> >
> > If both drivers/net/fs_enet/mii-bitbang.c and
> > drivers/net/phy/mdio-ofgpio.c must live together,
>
> The only reason I can see for that would be if the gpiolib version
> doesn't work on arch/ppc -- but that's not going to be a problem for very
> much longer.
Didn't you mention platforms such as ep8248e as well, where mdiobb would be
the only gpiolib user ?
> > I'll have a problem in drivers/net/fs_enet/fs_enet-main.c. The net
> > device probing code searches the device tree for an associated PHY, and
> > creates a PHY id from the PHY node. As the id will be generated from
> > different bus ids in the two mdio drivers (the bus number is the
> > register address for drivers/net/fs_enet/mii-bitbang.c, and is the gpio
> > index for drivers/net/phy/mdio-ofgpio.c), things will break.
> >
> > Any idea regarding how to get rid of that fs_enet/mii-bitbang hardcoded
> > dependency ?
>
> If mii-bitbang is only used on arch/ppc, then #ifdef CONFIG_PPC_MERGE
> should do it.
Ok.
> It'd be nice to be able to give phylib an OF node rather than a string,
> though...
Doesn't phylib have non-OF users ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Scott Wood @ 2008-04-22 16:04 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804221755.16419.laurentp@cse-semaphore.com>
On Tue, Apr 22, 2008 at 05:55:13PM +0200, Laurent Pinchart wrote:
> On Tuesday 22 April 2008 17:36, Scott Wood wrote:
> > The only reason I can see for that would be if the gpiolib version
> > doesn't work on arch/ppc -- but that's not going to be a problem for very
> > much longer.
>
> Didn't you mention platforms such as ep8248e as well, where mdiobb would be
> the only gpiolib user ?
That was when I thought you were talking about changing
drivers/net/phy/mdio-bitbang.c. ep8248e doesn't use
drivers/net/fs-enet/mii-bitbang.c.
> > It'd be nice to be able to give phylib an OF node rather than a string,
> > though...
>
> Doesn't phylib have non-OF users ?
I meant as an option, not the only way to specify it.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
From: Michel Dänzer @ 2008-04-22 16:04 UTC (permalink / raw)
To: Christian Ehrhardt
Cc: linux-fbdev-devel, Hollis Blanchard, adaplas, linux-kernel,
linuxppc-dev, Andrew Morton, Detlev Zundel
In-Reply-To: <480E0A54.9010203@linux.vnet.ibm.com>
On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
>
> You see it e.g. when you try to initialize X11, the x11 radeon driver
> issues a FBIOGET_FSCREENINFO ioctl [...]
FWIW, current versions of the xf86-video-ati radeon driver no longer use
radeonfb for anything.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Question on MPC83xx interrupts
From: Andre Schwarz @ 2008-04-22 16:58 UTC (permalink / raw)
To: linux-ppc list
All,
I'm currently running a MPC8343 based board.
Looks like I'm having problems with IRQs of a PCI device.
/proc/interrupts give :
CPU0
16: 554 IPIC Level i2c-mpc
17: 11 IPIC Level i2c-mpc
18: 134 IPIC Level ath
19: 1557 IPIC Level serial
21: 341 IPIC Level mpc83xx_spi
38: 0 IPIC Level ehci_hcd:usb1
BAD: 2
I wonder if the IRQ number should match the vector of the datasheet ...
giving :
14 -> I2C1
15 -> I2C2
16 -> SPI
38 -> USB DR
The "ath" is a PCI Ath5k WiFi module connected to IRQ1, i.e. mapped to
vector 17.
Are the IRQ numbers shifted/mapped/scrambled in any way ?
Can anyone shed some light on this ?
Cheers,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: Help! mpc8247 porting kernel 2.6.25 problem.
From: Scott Wood @ 2008-04-22 17:19 UTC (permalink / raw)
To: 张世乐; +Cc: Linuxppc-embedded
In-Reply-To: <8d59c9040804212210y6abe755frba0d2c2ef0e12cd4@mail.gmail.com>
On Tue, Apr 22, 2008 at 01:10:54PM +0800, 张世乐 wrote:
> Thank you, Doctor Scott. I'm very grateful to you for you kindly help.
>
> I'll try the way you suggested soon.
>
> And, my code for light the led run as follows:
>
> void set_led_a_red(void)
> {
> /*PDIRC: 0xfc010d40*/
> /*PPARC: 0xfc010d44*/
> /*PODRC: 0xfc010d4c*/
> /*PDATC: 0xfc010d50*/
> *((unsigned long *)(0xfb010d40)) |= 0x000000d4;
> *((unsigned long *)(0xfb010d44)) &= ~0x000000d4;
> *((unsigned long *)(0xfb010d4c)) &= ~0x000000d4;
> *((unsigned long *)(0xfb010d50)) |= 0x00000004;
> *((unsigned long *)(0xfb010d50)) &= ~0x00000010;
> }
Use out_be32(), and put a dcbf at the end. If the dcbf doesn't help, try
not accessing any I/O until after the MMU is set up, and use a
cache-inhibited BAT mapping. It's usually not between enabling caches
and enabling the MMU that something goes wrong, but it is a rather
annoying debug barrier.
As for early debug output not working, another possibility besides the
descriptor address is that ppc_md.probe is failing, or that your board
file doesn't set ppc_md.progress to udbg_progress.
-Scott
^ permalink raw reply
* Re: Question on MPC83xx interrupts
From: Scott Wood @ 2008-04-22 17:23 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <480E1939.6000701@matrix-vision.de>
On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
> I wonder if the IRQ number should match the vector of the datasheet ...
> giving :
No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a
purely Linux-internal construct.
-Scott
^ permalink raw reply
* Re: Question on MPC83xx interrupts
From: Andre Schwarz @ 2008-04-22 17:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <20080422172306.GA17992@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
Scott Wood schrieb:
> On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
>
>> I wonder if the IRQ number should match the vector of the datasheet ...
>> giving :
>>
>
> No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a
> purely Linux-internal construct.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
Scott,
thanks - any Idea how to figure out where the BAD comes from ?
Is it simply an unhandled/unacked one ?
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 1390 bytes --]
^ permalink raw reply
* Re: Question on MPC83xx interrupts
From: Scott Wood @ 2008-04-22 17:42 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <480E2230.2030601@matrix-vision.de>
On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> thanks - any Idea how to figure out where the BAD comes from ?
> Is it simply an unhandled/unacked one ?
It generally happens when an interrupt is requested, and the core takes
the exception, but then the interrupt source deasserts itself.
-Scott
^ permalink raw reply
* [RFC patch 6/9] POWERPC remove -traditional
From: Mathieu Desnoyers @ 2008-04-22 17:24 UTC (permalink / raw)
To: Sam Ravnborg, akpm, Ingo Molnar, linux-kernel
Cc: paulus, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20080422172404.502954084@polymtl.ca>
Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> This is a no-no for those archs that still use -traditional.
> > I dunno if this is a problem for you at the moment and the
> > right fix is anyway to nuke -traditional.
> >
> > Sam
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Sam Ravnborg <sam@ravnborg.org>
CC: paulus@samba.org
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/boot/Makefile
===================================================================
--- linux-2.6-lttng.orig/arch/powerpc/boot/Makefile 2008-04-21 10:03:05.000000000 -0400
+++ linux-2.6-lttng/arch/powerpc/boot/Makefile 2008-04-21 10:03:17.000000000 -0400
@@ -23,7 +23,7 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict-
-fno-strict-aliasing -Os -msoft-float -pipe \
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-isystem $(shell $(CROSS32CC) -print-file-name=include)
-BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
ifdef CONFIG_DEBUG_INFO
BOOTCFLAGS += -g
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH] MTD: fix partition scan control logic in physmap_of and fsl_elbc_nand
From: David Woodhouse @ 2008-04-22 18:49 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Stefan Roese, linux-mtd
In-Reply-To: <1204201051-13107-1-git-send-email-leoli@freescale.com>
On Thu, 2008-02-28 at 20:17 +0800, Li Yang wrote:
> The generic rule for partition scan is to try all supported
> partition types before an usable partition table is found.
> However the original code returns unsuccessful when there is
> an error in any of the partition types.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> I later found that Stefan has proposed a similar patch for physmap_of
> and Peter proposed another patch to fix cmdlinepart instead.
> I'd say that even after cmdlinepart patch is applied the scan control
> logic still needs to be fixed.
I'm not convinced. I think the partition code should return an error if
it hits a hard error, like a failure to read from the device. And return
zero when it doesn't find anything.
--
dwmw2
^ permalink raw reply
* Re: Question on MPC83xx interrupts
From: Andre Schwarz @ 2008-04-22 18:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <20080422174208.GB18076@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
Scott Wood schrieb:
> On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
>
>> thanks - any Idea how to figure out where the BAD comes from ?
>> Is it simply an unhandled/unacked one ?
>>
>
> It generally happens when an interrupt is requested, and the core takes
> the exception, but then the interrupt source deasserts itself.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
So this is not bad at all if you have a device with self-clearing
interrupts ...
Thanks,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 1391 bytes --]
^ permalink raw reply
* Re: Question on MPC83xx interrupts
From: Scott Wood @ 2008-04-22 18:52 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <480E33AB.5050904@matrix-vision.de>
On Tue, Apr 22, 2008 at 08:51:23PM +0200, Andre Schwarz wrote:
> Scott Wood schrieb:
> >On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> >
> >>thanks - any Idea how to figure out where the BAD comes from ?
> >>Is it simply an unhandled/unacked one ?
> >>
> >
> >It generally happens when an interrupt is requested, and the core
> >takes
> >the exception, but then the interrupt source deasserts itself.
> >
> >-Scott
> So this is not bad at all if you have a device with self-clearing
> interrupts ...
Right, as long as you don't get too many of them I wouldn't worry.
-Scott
^ permalink raw reply
* Re: SecretLab 2.6.24 with USB
From: aaronsells @ 2008-04-22 19:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40804211109g2f7f45d0gf836be46e2c1a40b@mail.gmail.com>
Grant Likely-2 wrote:
>
> Your best bet is to use
> Xilinx's git tree and manually patch in the c67x00 driver from Peter
> Korsgaard's driver.
>
> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01907.html
> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01908.html
> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01906.html
> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01907.html
>
I've tried this on my ML403 board with no success. My Xilinx git tree is
current. I'm using Peter's most recent patches from
http://peter.korsgaard.com/patches/linux/. I'm using an OpenEmbedded
console-image mounted via nfs as my root filesystem. I don't receive any
messages when I plug USB devices into the board (keyboard, mouse, webcam).
Any ideas on how I can troubleshoot this?
--
View this message in context: http://www.nabble.com/SecretLab-2.6.24-with-USB-tp16693847p16825460.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC POWERPC] booting-without-of: bindings for FHCI USB, GPIO LEDs, MCU, and NAND on UPM
From: Anton Vorontsov @ 2008-04-22 19:41 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Here is purposed bindings draft for the new drivers that I would like to
send for this or next merge window, depending on results of this RFC. ;-)
(The new bindings needs to be in-tree or at least Acked before I could
send the drivers.)
Comments and suggestions are highly appreciated.
Thanks.
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index c350623..38fe3e9 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -59,6 +59,11 @@ Table of Contents
p) Freescale Synchronous Serial Interface
q) USB EHCI controllers
r) Freescale General-purpose Timers Module
+ s) Freescale USB Parameter RAM:
+ t) Freescale QUICC Engine USB Controller
+ u) LEDs on GPIOs
+ v) Freescale MCU with MPC8349E-mITX compatible firmware
+ w) NAND on UPM-driven Freescale Localbus
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2866,6 +2871,139 @@ platforms are moved over to use the flattened-device-tree model.
clock-frequency = <0>;
};
+ s) Freescale USB Parameter RAM:
+
+ Required properties:
+ - compatible : should be "fsl,<chip>-qe-muram-usb-pram",
+ "fsl,qe-muram-usb-pram", "fsl,cpm-muram-usb-pram".
+ - reg : should contain USB PRAM location and length.
+
+ Example:
+
+ usb-pram@8b00 {
+ compatible = "fsl,mpc8360-qe-muram-usb-pram",
+ "fsl,qe-muram-usb-pram",
+ "fsl,cpm-muram-usb-pram";
+ reg = <0x8b00 0x100>;
+ };
+
+ t) Freescale QUICC Engine USB Controller
+
+ Required properties:
+ - compatible : should be "fsl,<chip>-qe-usb", "fsl,qe-usb",
+ "fsl,usb-fhci"
+ - reg : should contain gtm registers location and length.
+ - interrupts : should contain USB interrupt.
+ - interrupt-parent : interrupt source phandle.
+ - fsl,fullspeed-clock : specifies the full speed USB clock source.
+ - fsl,lowspeed-clock : specifies the low speed USB clock source.
+ - fsl,usb-mode : should be "host".
+ - linux,hub-power-budget : optional, USB power budget for the root hub
+ in mA.
+ - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
+ USBRN, SPEED (optional), and SUSPEND (optional).
+
+ Example:
+
+ usb@6c0 {
+ compatible = "fsl,mpc8360-qe-usb", "fsl,qe-usb",
+ "fsl,usb-fhci";
+ reg = <0x6c0 0x40>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ fsl,usb-mode = "host";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+ &qe_pio_b 3 0 /* USBTP */
+ &qe_pio_b 8 0 /* USBTN */
+ &qe_pio_b 9 0 /* USBRP */
+ &qe_pio_b 11 0 /* USBRN */
+ &qe_pio_e 20 0 /* SPEED */
+ &qe_pio_e 21 0 /* SUSPN */>;
+ };
+
+ u) LEDs on GPIOs
+
+ Required properties:
+ - compatible : should be "linux,gpio-led".
+ - linux,name : LED name.
+ - linux,active-low : property should be present if LED wired as
+ active-low.
+ - linux,default-trigger : Linux default trigger for this LED.
+ - linux,brightness : default brightness.
+ - gpios : should specify LED GPIO.
+
+ Example:
+
+ led@0 {
+ compatible = "linux,gpio-led";
+ linux,name = "pwr";
+ linux,brightness = <1>;
+ linux,active-low;
+ gpios = <&mcu_pio 0>;
+ };
+
+ led@1 {
+ compatible = "linux,gpio-led";
+ linux,name = "hdd";
+ linux,default-trigger = "ide-disk";
+ linux,active-low;
+ gpios = <&mcu_pio 1>;
+ };
+
+ v) Freescale MCU with MPC8349E-mITX compatible firmware
+
+ Required properties:
+ - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx",
+ "simple-bus";
+ - reg : should specify I2C address (0x0a).
+ - #address-cells : should be 0.
+ - #size-cells : should be 0.
+ - #gpio-cells : should be 1.
+ - gpio-controller : should be present;
+
+ Example:
+
+ mcu_pio: mcu@0a {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #gpio-cells = <1>;
+ compatible = "fsl,mc9s08qg8-mpc8349emitx",
+ "fsl,mcu-mpc8349emitx",
+ "simple-bus";
+ reg = <0x0a>;
+ gpio-controller;
+ };
+
+ w) NAND on UPM-driven Freescale Localbus
+
+ Required properties:
+ - compatible : "fsl,upm-nand".
+ - reg : should specify localbus chip select and size used for the chip.
+ - width : should specify port size in bytes.
+ - fsl,upm-addr-offset : UPM pattern offset for the address latch.
+ - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+ - fsl,wait-pattern : should be present if NAND chip requires waiting
+ for Ready-Not-Busy pin after each executed pattern.
+ - fsl,wait-write : should be present if NAND chip needs waiting on
+ Ready-Not-Busy pin after each write cycle.
+ - linux,chip-delay : optional, may contain delay value in milliseconds
+ (in case when Ready-Not-Busy pin was unspecified).
+ - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
+
+ Example:
+
+ flash@1,0 {
+ compatible = "stmicro,NAND512W3A2BN6E", "fsl,upm-nand";
+ reg = <1 0 1>;
+ width = <1>;
+ fsl,upm-addr-offset = <16>;
+ fsl,upm-cmd-offset = <8>;
+ fsl,wait-pattern;
+ fsl,wait-write;
+ gpios = <&qe_pio_e 18 0>;
+ };
+
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================
^ permalink raw reply related
* Re: [RFC POWERPC] booting-without-of: bindings for FHCI USB, GPIO LEDs, MCU, and NAND on UPM
From: Grant Likely @ 2008-04-22 20:08 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080422194135.GA27822@polina.dev.rtsoft.ru>
On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> Hi all,
>
> Here is purposed bindings draft for the new drivers that I would like to
> send for this or next merge window, depending on results of this RFC. ;-)
> (The new bindings needs to be in-tree or at least Acked before I could
> send the drivers.)
>
> Comments and suggestions are highly appreciated.
Thanks for cc'ing me. Mostly looks good, comments below.
Cheers,
g.
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index c350623..38fe3e9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -59,6 +59,11 @@ Table of Contents
> p) Freescale Synchronous Serial Interface
> q) USB EHCI controllers
> r) Freescale General-purpose Timers Module
> + s) Freescale USB Parameter RAM:
> + t) Freescale QUICC Engine USB Controller
> + u) LEDs on GPIOs
> + v) Freescale MCU with MPC8349E-mITX compatible firmware
> + w) NAND on UPM-driven Freescale Localbus
>
> VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2866,6 +2871,139 @@ platforms are moved over to use the flattened-device-tree model.
> clock-frequency = <0>;
> };
>
> + s) Freescale USB Parameter RAM:
> +
> + Required properties:
> + - compatible : should be "fsl,<chip>-qe-muram-usb-pram",
> + "fsl,qe-muram-usb-pram", "fsl,cpm-muram-usb-pram".
> + - reg : should contain USB PRAM location and length.
> +
Personally, I'd leave out "fsl,qe-muram-usb-pram" and
"fsl,cpm-muram-usb-pram", but otherwise looks good to me.
> + Example:
> +
> + usb-pram@8b00 {
> + compatible = "fsl,mpc8360-qe-muram-usb-pram",
> + "fsl,qe-muram-usb-pram",
> + "fsl,cpm-muram-usb-pram";
> + reg = <0x8b00 0x100>;
> + };
> +
> + t) Freescale QUICC Engine USB Controller
> +
> + Required properties:
> + - compatible : should be "fsl,<chip>-qe-usb", "fsl,qe-usb",
> + "fsl,usb-fhci"
Again, I'd leave out "fsl,qe-usb" and "fsl,usb-fhci".
> + - reg : should contain gtm registers location and length.
> + - interrupts : should contain USB interrupt.
> + - interrupt-parent : interrupt source phandle.
> + - fsl,fullspeed-clock : specifies the full speed USB clock source.
> + - fsl,lowspeed-clock : specifies the low speed USB clock source.
What is the format of the clock properties?
> + - fsl,usb-mode : should be "host".
What other options are there? Is this something that would be better
encoded into "compatible" for driver binding? (I've seen both
approaches; I don't have a firm opinion on which is best)
> + - linux,hub-power-budget : optional, USB power budget for the root hub
> + in mA.
> + - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
> + USBRN, SPEED (optional), and SUSPEND (optional).
> +
> + Example:
> +
> + usb@6c0 {
> + compatible = "fsl,mpc8360-qe-usb", "fsl,qe-usb",
> + "fsl,usb-fhci";
> + reg = <0x6c0 0x40>;
> + interrupts = <11>;
> + interrupt-parent = <&qeic>;
> + fsl,fullspeed-clock = "clk21";
> + fsl,usb-mode = "host";
> + gpios = <&qe_pio_b 2 0 /* USBOE */
> + &qe_pio_b 3 0 /* USBTP */
> + &qe_pio_b 8 0 /* USBTN */
> + &qe_pio_b 9 0 /* USBRP */
> + &qe_pio_b 11 0 /* USBRN */
> + &qe_pio_e 20 0 /* SPEED */
> + &qe_pio_e 21 0 /* SUSPN */>;
> + };
> +
> + u) LEDs on GPIOs
> +
> + Required properties:
> + - compatible : should be "linux,gpio-led".
> + - linux,name : LED name.
> + - linux,active-low : property should be present if LED wired as
> + active-low.
> + - linux,default-trigger : Linux default trigger for this LED.
> + - linux,brightness : default brightness.
> + - gpios : should specify LED GPIO.
Looks good to me.
> +
> + Example:
> +
> + led@0 {
> + compatible = "linux,gpio-led";
> + linux,name = "pwr";
> + linux,brightness = <1>;
> + linux,active-low;
> + gpios = <&mcu_pio 0>;
> + };
> +
> + led@1 {
> + compatible = "linux,gpio-led";
> + linux,name = "hdd";
> + linux,default-trigger = "ide-disk";
> + linux,active-low;
> + gpios = <&mcu_pio 1>;
> + };
> +
> + v) Freescale MCU with MPC8349E-mITX compatible firmware
> +
> + Required properties:
> + - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx",
> + "simple-bus";
I don't think "simple-bus" is appropriate here. This device doesn't
have any sub nodes so is not a bus. (I'm talking about the binding
here; and I understand that simple-bus is convenient for causing
subnodes to be picked up into of_platform and that you'll be putting
the LED nodes as children of this one. It just shouldn't be part of
this binding documentation.)
Also, since this node describes a device+firmware instead of just a
device, then "fsl,mcu-mpc8349emitx" should uniquely identify the
device from all other possibilities. It appears to be a very board
specific thing.
> + - reg : should specify I2C address (0x0a).
> + - #address-cells : should be 0.
> + - #size-cells : should be 0.
> + - #gpio-cells : should be 1.
> + - gpio-controller : should be present;
> +
> + Example:
> +
> + mcu_pio: mcu@0a {
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #gpio-cells = <1>;
> + compatible = "fsl,mc9s08qg8-mpc8349emitx",
> + "fsl,mcu-mpc8349emitx",
> + "simple-bus";
> + reg = <0x0a>;
> + gpio-controller;
> + };
> +
> + w) NAND on UPM-driven Freescale Localbus
> +
> + Required properties:
> + - compatible : "fsl,upm-nand".
> + - reg : should specify localbus chip select and size used for the chip.
> + - width : should specify port size in bytes.
> + - fsl,upm-addr-offset : UPM pattern offset for the address latch.
> + - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
> + - fsl,wait-pattern : should be present if NAND chip requires waiting
> + for Ready-Not-Busy pin after each executed pattern.
> + - fsl,wait-write : should be present if NAND chip needs waiting on
> + Ready-Not-Busy pin after each write cycle.
> + - linux,chip-delay : optional, may contain delay value in milliseconds
> + (in case when Ready-Not-Busy pin was unspecified).
> + - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
I'm not competent to comment on this binding; I haven't spent any time
looking at NAND binding conventions.
> +
> + Example:
> +
> + flash@1,0 {
> + compatible = "stmicro,NAND512W3A2BN6E", "fsl,upm-nand";
> + reg = <1 0 1>;
> + width = <1>;
> + fsl,upm-addr-offset = <16>;
> + fsl,upm-cmd-offset = <8>;
> + fsl,wait-pattern;
> + fsl,wait-write;
> + gpios = <&qe_pio_e 18 0>;
> + };
> +
> VII - Marvell Discovery mv64[345]6x System Controller chips
> ===========================================================
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: David Woodhouse @ 2008-04-22 20:09 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803271026.51555.laurentp@cse-semaphore.com>
On Thu, 2008-03-27 at 10:26 +0100, Laurent Pinchart wrote:
> Ok. I'll submit a new patch as soon as we agree on a compatible name.
Did we?
--
dwmw2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox