From: Anton Vorontsov <hidden> Date: 2007-10-05 17:39:25
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Anton Vorontsov <hidden> Date: 2007-10-05 17:45:42
Currently, all QE SPI controllers are almost the same comparing to
MPC83xx's, thus let's use that driver for them.
Tested to work on MPC85xx in loopback mode.
Signed-off-by: Anton Vorontsov <redacted>
---
This is respin. Hope this time it will get ack from the
PowerPC team.
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
From: Anton Vorontsov <hidden> Date: 2007-10-05 17:45:56
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <redacted>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
From: Anton Vorontsov <hidden> Date: 2007-10-05 17:46:02
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov <redacted>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
@@ -371,10 +371,10 @@/* These are the same PHYs as on*gianfar'sMDIObus*/-qe_phy0:ethernet-phy@00{+qe_phy0:ethernet-phy@07{interrupt-parent=<&mpic>;interrupts=<11>;-reg=<0>;+reg=<7>;device_type="ethernet-phy";};qe_phy1:ethernet-phy@01{
From: Anton Vorontsov <hidden> Date: 2007-10-05 17:46:39
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
To solve this problem efficiently, QEIC needs pluggable handlers,
specific to the underlaying interrupt controller.
Patch extends qe_ic_init() function to accept low and high interrupt
handlers. To avoid #ifdefs, stack of interrupt handlers specified in
the header file and functions are marked 'static inline', thus
handlers are compiled-in only if actually used (in the board file).
Another option would be to lookup for parent controller and
automatically detect handlers (will waste text size because of
never used handlers, so this option abolished).
qe_ic_init() also changed in regard to support multiplexed high/low
lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
handler implemented appropriately.
Signed-off-by: Anton Vorontsov <redacted>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 29 +++---------
include/asm-powerpc/qe_ic.h | 68 ++++++++++++++++++++++++++++-
6 files changed, 78 insertions(+), 27 deletions(-)
From: Scott Wood <hidden> Date: 2007-10-05 18:01:27
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" type node?
No -- the soc node is for immr/ccsr only, and while the PCI control
registers are there, the ranges are not. There was a lengthy discussion on
IRC about this a couple weeks ago. It'd be cleaner to split the control
node from the bus node, and connect them with phandles, but some people
didn't like that, and this is what we compromised on.
-Scott
From: Anton Vorontsov <hidden> Date: 2007-10-05 18:05:02
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" type node?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit
phys addr support to 32-bit pci" that started using of_translate_address()
for ranges, and of_translate_address() will not work if PCI placed in the
SOC node. Not sure if that patch applied or not, though.
Good luck,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Kumar Gala <hidden> Date: 2007-10-05 20:57:52
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
quoted
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc"
type node?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add
64-bit
phys addr support to 32-bit pci" that started using
of_translate_address()
for ranges, and of_translate_address() will not work if PCI placed
in the
SOC node. Not sure if that patch applied or not, though.
I'm confused, what's the actual issue with PCI that this patch
addresses?
- k
From: Kumar Gala <hidden> Date: 2007-10-05 22:09:21
On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
I've applied patches 1-5 however I'm not able to get UCC enet working
on my board. Is there something special that has to be done? (I've
got the card standalone, no MDS backplane).
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that
works w/o any issue.
- k
Hello Kumar,
On Fri, 5 Oct 2007 15:58:00 -0500
Kumar Gala wrote:
=20
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
=20
quoted
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
quoted
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" =20
type node?
Nope. PCI's ranges =3D <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add =20
64-bit
phys addr support to 32-bit pci" that started using =20
of_translate_address()
for ranges, and of_translate_address() will not work if PCI placed =20
in the
SOC node. Not sure if that patch applied or not, though.
=20
I'm confused, what's the actual issue with PCI that this patch =20
addresses?
=20
=46rom what I can see, move of the PCI node out of the SoC node, inspired by =
the recent flame talk about it :)
I guess pretty soon, we'll have "proper" ranges parsing for pci, that does =
of_translate_address() and requires
either tuned-up parent ranges, or residing outside of the SoC node, this is=
the reason...
From: Anton Vorontsov <hidden> Date: 2007-10-08 12:08:16
On Fri, Oct 05, 2007 at 03:58:00PM -0500, Kumar Gala wrote:
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
quoted
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
quoted
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" type node?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit
phys addr support to 32-bit pci" that started using of_translate_address()
for ranges, and of_translate_address() will not work if PCI placed in the
SOC node. Not sure if that patch applied or not, though.
I'm confused, what's the actual issue with PCI that this patch addresses?
Which patch? Valentine's or mine under the subject? Don't know about the
former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc node,
but you forgot to change regs = <>, thus instead of e000a000/e0008000,
kernel used a000/8000 for accessing PCI ccsr registers.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Anton Vorontsov <hidden> Date: 2007-10-08 12:16:12
On Fri, Oct 05, 2007 at 05:09:28PM -0500, Kumar Gala wrote:
On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
quoted
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
I've applied patches 1-5 however I'm not able to get UCC enet working on my
board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this patch set,
for me board hanged w/o it.
Is there something special that has to be done? (I've got the card
standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking switches
on the board might help.
Also, .config and bootlog would help.
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
1.2.0-g60174746 here.
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works
w/o any issue.
Strange enough. I'd say it's impossible with your current tree. Maybe you've
used some stale dtb? Because dts is seriously broken as now, and I can't
believe that it worked for you. ;-)
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Kumar Gala <hidden> Date: 2007-10-08 13:32:18
On Oct 8, 2007, at 7:08 AM, Anton Vorontsov wrote:
On Fri, Oct 05, 2007 at 03:58:00PM -0500, Kumar Gala wrote:
quoted
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
quoted
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
quoted
Hello.
Anton Vorontsov wrote:
quoted
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc"
type node?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC:
Add 64-bit
phys addr support to 32-bit pci" that started using
of_translate_address()
for ranges, and of_translate_address() will not work if PCI
placed in the
SOC node. Not sure if that patch applied or not, though.
I'm confused, what's the actual issue with PCI that this patch
addresses?
Which patch? Valentine's or mine under the subject? Don't know
about the
former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc
node,
but you forgot to change regs = <>, thus instead of e000a000/e0008000,
kernel used a000/8000 for accessing PCI ccsr registers.
Yeah, I see that bug now. It looks like I wasn't getting my new .dts
on the board. Will fixup that issue in my patch.
- k
From: Kumar Gala <hidden> Date: 2007-10-08 13:46:23
On Oct 8, 2007, at 7:16 AM, Anton Vorontsov wrote:
On Fri, Oct 05, 2007 at 05:09:28PM -0500, Kumar Gala wrote:
quoted
On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
quoted
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
I've applied patches 1-5 however I'm not able to get UCC enet
working on my
board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this
patch set,
for me board hanged w/o it.
quoted
Is there something special that has to be done? (I've got the card
standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking
switches
on the board might help.
Also, .config and bootlog would help.
quoted
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
1.2.0-g60174746 here.
quoted
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and
that works
w/o any issue.
Strange enough. I'd say it's impossible with your current tree.
Maybe you've
used some stale dtb? Because dts is seriously broken as now, and I
can't
believe that it worked for you. ;-)
Ignore me. Using the updated dtb makes things work. I need to double
check PCIe but UCC geth appears to function now.
- k
From: Kumar Gala <hidden> Date: 2007-10-08 18:18:46
quoted
Which patch? Valentine's or mine under the subject? Don't know
about the
former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc
node,
but you forgot to change regs = <>, thus instead of e000a000/
e0008000,
kernel used a000/8000 for accessing PCI ccsr registers.
Yeah, I see that bug now. It looks like I wasn't getting my new .dts
on the board. Will fixup that issue in my patch.
Ok, I've tested my updated tree and it works for PCIe with the fix to
the .dts
- k