* RE: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Zhang Wei-r63237 @ 2007-05-24 7:31 UTC (permalink / raw)
To: pterry, galak; +Cc: linuxppc-dev
In-Reply-To: <1179934657.11247.14.camel@pterry-fc6.micromemory.com>
> > > interrupts =3D <30 1 31 1 32 1 35 1 36 1=20
> 37 1 38 1>;
> > > > };
> > > >
> > > Do you really use all of this interrupts? In my test,=20
> three <32 2 35 2
> > > 36 2> are okay, and the sense is 2.
> >=20
> > I think we need to list all the interrupts possible from=20
> RIO, not just the
> > ones the driver happens to use.
> Sorry about the senses, again I just threw that in the email as a
> strawman to kick off discussion (which now seems moot as Wei has the
> patches (yippee)). The second set of interrupts 37 and 38 are for the
> second message unit which I want to use (see above). 30 is for
> port-write/error which I will be using to get interrupts from my
> switches for topology changes. 31 is the out doorbell done which the
> driver doesn't use cos of the synchronous nature of the out doorbell I
> suppose.
About this interrupts, I suggest to put the BELL, Tx, Rx to the front of
others. These three is already be used in ppc rio codes.
For example:
/* bell_irq tx_irq rx_irq */
interrupts =3D <32 2 35 2 36 2>;
Thanks!
Wei.
^ permalink raw reply
* Xilinx git tree at source.mvista.com
From: Andrei Konovalov @ 2007-05-24 8:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev
Hello,
My Xilinx Virtex Development tree is now alive again.
Please use the dev branch (master is just the ko copy):
http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
Currently it has a patch to enable the framebuffer
on ML403 and ML300 plus TEMAC driver that uses
the PHY lib (FIFO mode support only).
The TEMAC driver is work in progress.
In the queue are SGDMA TEMAC support, and SPI driver
(master only).
My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
The comments / opinions on how to get this driver (not the current incomplete
version of course) accepted into the ko tree are very welcomed.
I am not quite satisfied with how the current git repository
is structured, and may rework it completely later.
Thanks,
Andrei
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-24 9:11 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070524041625.GD20078@localhost.localdomain>
Looks okay but...
> + compatible = "bcm5461A", "bcm54xx";
... lowercase please.
Segher
^ permalink raw reply
* [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Li Yang @ 2007-05-24 9:14 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
Export symbols of qe_lib to be used by QE drivers.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index ac12a44..e8635aa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -18,6 +18,7 @@
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/stddef.h>
+#include <linux/module.h>
#include <asm/irq.h>
#include <asm/io.h>
@@ -40,6 +41,7 @@ int ucc_set_qe_mux_mii_mng(int ucc_num)
return 0;
}
+EXPORT_SYMBOL(ucc_set_qe_mux_mii_mng);
int ucc_set_type(int ucc_num, struct ucc_common *regs,
enum ucc_speed_type speed)
@@ -66,6 +68,7 @@ int ucc_set_type(int ucc_num, struct ucc_common *regs,
return 0;
}
+EXPORT_SYMBOL(ucc_set_type);
int ucc_init_guemr(struct ucc_common *regs)
{
@@ -81,6 +84,7 @@ int ucc_init_guemr(struct ucc_common *regs)
return 0;
}
+EXPORT_SYMBOL(ucc_init_guemr);
static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr, u8 * reg_num,
u8 * shift)
@@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr, u8 * reg_num,
break;
}
}
+EXPORT_SYMBOL(get_cmxucr_reg);
int ucc_mux_set_grant_tsa_bkpt(int ucc_num, int set, u32 mask)
{
@@ -142,6 +147,7 @@ int ucc_mux_set_grant_tsa_bkpt(int ucc_num, int set, u32 mask)
return 0;
}
+EXPORT_SYMBOL(ucc_mux_set_grant_tsa_bkpt);
int ucc_set_qe_mux_rxtx(int ucc_num, enum qe_clock clock, enum comm_dir mode)
{
@@ -251,3 +257,4 @@ int ucc_set_qe_mux_rxtx(int ucc_num, enum qe_clock clock, enum comm_dir mode)
return 0;
}
+EXPORT_SYMBOL(ucc_set_qe_mux_rxtx);
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 9143236..3df202e 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -19,6 +19,7 @@
#include <linux/stddef.h>
#include <linux/interrupt.h>
#include <linux/err.h>
+#include <linux/module.h>
#include <asm/io.h>
#include <asm/immap_qe.h>
@@ -70,6 +71,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x",
(u32) & uccf->uf_regs->guemr, uccf->uf_regs->guemr);
}
+EXPORT_SYMBOL(ucc_fast_dump_regs);
u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
{
@@ -85,11 +87,13 @@ u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
default: return QE_CR_SUBBLOCK_INVALID;
}
}
+EXPORT_SYMBOL(ucc_fast_get_qe_cr_subblock);
void ucc_fast_transmit_on_demand(struct ucc_fast_private * uccf)
{
out_be16(&uccf->uf_regs->utodr, UCC_FAST_TOD);
}
+EXPORT_SYMBOL(ucc_fast_transmit_on_demand);
void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
@@ -110,6 +114,7 @@ void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
}
out_be32(&uf_regs->gumr, gumr);
}
+EXPORT_SYMBOL(ucc_fast_enable);
void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
@@ -130,6 +135,7 @@ void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
}
out_be32(&uf_regs->gumr, gumr);
}
+EXPORT_SYMBOL(ucc_fast_disable);
int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** uccf_ret)
{
@@ -341,6 +347,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
*uccf_ret = uccf;
return 0;
}
+EXPORT_SYMBOL(ucc_fast_init);
void ucc_fast_free(struct ucc_fast_private * uccf)
{
@@ -355,3 +362,4 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
kfree(uccf);
}
+EXPORT_SYMBOL(ucc_fast_free);
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index 1f65c26..5618275 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -19,6 +19,7 @@
#include <linux/stddef.h>
#include <linux/interrupt.h>
#include <linux/err.h>
+#include <linux/module.h>
#include <asm/io.h>
#include <asm/immap_qe.h>
@@ -41,11 +42,13 @@ u32 ucc_slow_get_qe_cr_subblock(int uccs_num)
default: return QE_CR_SUBBLOCK_INVALID;
}
}
+EXPORT_SYMBOL(ucc_slow_get_qe_cr_subblock);
void ucc_slow_poll_transmitter_now(struct ucc_slow_private * uccs)
{
out_be16(&uccs->us_regs->utodr, UCC_SLOW_TOD);
}
+EXPORT_SYMBOL(ucc_slow_poll_transmitter_now);
void ucc_slow_graceful_stop_tx(struct ucc_slow_private * uccs)
{
@@ -56,6 +59,7 @@ void ucc_slow_graceful_stop_tx(struct ucc_slow_private * uccs)
qe_issue_cmd(QE_GRACEFUL_STOP_TX, id,
QE_CR_PROTOCOL_UNSPECIFIED, 0);
}
+EXPORT_SYMBOL(ucc_slow_graceful_stop_tx);
void ucc_slow_stop_tx(struct ucc_slow_private * uccs)
{
@@ -65,6 +69,7 @@ void ucc_slow_stop_tx(struct ucc_slow_private * uccs)
id = ucc_slow_get_qe_cr_subblock(us_info->ucc_num);
qe_issue_cmd(QE_STOP_TX, id, QE_CR_PROTOCOL_UNSPECIFIED, 0);
}
+EXPORT_SYMBOL(ucc_slow_stop_tx);
void ucc_slow_restart_tx(struct ucc_slow_private * uccs)
{
@@ -74,6 +79,7 @@ void ucc_slow_restart_tx(struct ucc_slow_private * uccs)
id = ucc_slow_get_qe_cr_subblock(us_info->ucc_num);
qe_issue_cmd(QE_RESTART_TX, id, QE_CR_PROTOCOL_UNSPECIFIED, 0);
}
+EXPORT_SYMBOL(ucc_slow_restart_tx);
void ucc_slow_enable(struct ucc_slow_private * uccs, enum comm_dir mode)
{
@@ -94,6 +100,7 @@ void ucc_slow_enable(struct ucc_slow_private * uccs, enum comm_dir mode)
}
out_be32(&us_regs->gumr_l, gumr_l);
}
+EXPORT_SYMBOL(ucc_slow_enable);
void ucc_slow_disable(struct ucc_slow_private * uccs, enum comm_dir mode)
{
@@ -114,6 +121,7 @@ void ucc_slow_disable(struct ucc_slow_private * uccs, enum comm_dir mode)
}
out_be32(&us_regs->gumr_l, gumr_l);
}
+EXPORT_SYMBOL(ucc_slow_disable);
int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** uccs_ret)
{
@@ -349,6 +357,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
*uccs_ret = uccs;
return 0;
}
+EXPORT_SYMBOL(ucc_slow_init);
void ucc_slow_free(struct ucc_slow_private * uccs)
{
@@ -368,5 +377,4 @@ void ucc_slow_free(struct ucc_slow_private * uccs)
kfree(uccs);
}
-
-
+EXPORT_SYMBOL(ucc_slow_free);
^ permalink raw reply related
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-24 9:13 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070524055909.GG20078@localhost.localdomain>
>> Is the compatible really need here? We are able to provide and bind
>> drivers based on MII_PHYSID1/2. I don't see what putting the
>> compatible proper gets us.
>
> That's a good point (except that having a node without compatible is
> kind of odd).
Not really; "compatible" is for the cases where "name"
alone isn't enough.
> At the moment the code which instantiates the platform
> device looks at compatible to enable a workaround. But actually that
> workaround is holly specific, rather than related to the PHY model,
> and so should be encoded differently.
There is no real value in encoding it in the device
tree, even.
Segher
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Arnd Bergmann @ 2007-05-24 9:19 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C307037@zch01exm26.fsl.freescale.net>
On Thursday 24 May 2007, Zhang Wei-r63237 wrote:
> Of_platform_driver is a good framework. But this RapidIO driver is not a
> device driver. It's a _bus_ driver very similar to PCI bus. So,
> of_platform_driver is not fit here.
But there is not a fundamental difference between the two. In the Linux
driver model, a bus driver is a simply device driver whose devices have
other devices as child nodes.
Your example of PCI buses fits well here. Traditionally, each platform
had its own PCI scanning code that went looking for pci host bridges.
Now we have the of_pci_phb_driver in arch/powerpc/kernel/of_platform.c
that automatically sets up the bridges, and the platform only
needs to provide a ppc_md.pci_setup_phb() callback.
Arnd <><
^ permalink raw reply
* RE: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Zhang Wei-r63237 @ 2007-05-24 9:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705241119.23793.arnd@arndb.de>
>=20
> On Thursday 24 May 2007, Zhang Wei-r63237 wrote:
> > Of_platform_driver is a good framework. But this RapidIO=20
> driver is not a
> > device driver. It's a _bus_ driver very similar to PCI bus. So,
> > of_platform_driver is not fit here.
>=20
> But there is not a fundamental difference between the two. In=20
> the Linux
> driver model, a bus driver is a simply device driver whose=20
> devices have
> other devices as child nodes.
>=20
> Your example of PCI buses fits well here. Traditionally, each platform
> had its own PCI scanning code that went looking for pci host bridges.
> Now we have the of_pci_phb_driver in arch/powerpc/kernel/of_platform.c
> that automatically sets up the bridges, and the platform only
> needs to provide a ppc_md.pci_setup_phb() callback.
>=20
Add the rio scaning code to of_platform.c such as pci is ok?
Thanks!
-wei
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: David H. Lynch Jr. @ 2007-05-24 9:57 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <46555294.6040104@ru.mvista.com>
Andrei Konovalov wrote:
> Hello,
>
> My Xilinx Virtex Development tree is now alive again.
>
> Please use the dev branch (master is just the ko copy):
> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
> Currently it has a patch to enable the framebuffer
> on ML403 and ML300 plus TEMAC driver that uses
> the PHY lib (FIFO mode support only).
> The TEMAC driver is work in progress.
> In the queue are SGDMA TEMAC support, and SPI driver
> (master only).
>
> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
> The comments / opinions on how to get this driver (not the current incomplete
> version of course) accepted into the ko tree are very welcomed.
>
I have an almost working FIFO TEMAC driver. It is similarly based.
it started out based on the Trek webserver sample
I spent probably 3-4 days de-EDKing it into something that fit into a
single source and was closer to ko norms.
It is based on approximately the EDK 8.1 stuff. You are welcome to it,
if it could be helpful in anyway.
I am all for getting an acceptable driver into the ko tree.
> I am not quite satisfied with how the current git repository
> is structured, and may rework it completely later.
>
> Thanks,
> Andrei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Arnd Bergmann @ 2007-05-24 11:27 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C307092@zch01exm26.fsl.freescale.net>
On Thursday 24 May 2007, Zhang Wei-r63237 wrote:
>
> Add the rio scaning code to of_platform.c such as pci is ok?
I think it's better to have a separate file that consolidates
all the code specific to one rio bus bridge.
There is no technical reason why the of_pci_phb code is in
of_platform.c either, it more or less ended up in there by
accident ;-)
Arnd <><
^ permalink raw reply
* [PPC] 2.6.22-rc2: badness at mm/slab.c:777
From: Andrew J. Barr @ 2007-05-23 20:25 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- ------------[ cut here ]------------
Badness at mm/slab.c:777
Call Trace:
[effd7d60] [c0008478] show_stack+0x50/0x184 (unreliable)
[effd7d80] [c00fc948] report_bug+0x84/0xc8
[effd7d90] [c0228af4] __kprobes_text_start+0x11c/0x4f0
[effd7da0] [c0010bc8] ret_from_except_full+0x0/0x4c
- --- Exception: 700 at __kmalloc+0x28/0xe8
LR = __kzalloc+0x18/0x44
[effd7e60] [c0198cc0] usb_get_descriptor+0x7c/0xc4 (unreliable)
[effd7e70] [c006ab14] __kzalloc+0x18/0x44
[effd7e90] [c019b84c] usb_get_configuration+0x7e0/0xb28
[effd7f40] [c019368c] usb_new_device+0x24/0x100
[effd7f60] [c0194630] hub_thread+0x844/0xc54
[effd7fd0] [c0042b60] kthread+0x4c/0x88
[effd7ff0] [c0011468] kernel_thread+0x44/0x60
Occurs during bootup on a Powerbook5,7 (PowerBook G4 17" post-Feb05)
dmesg and .config attached.
- --
Andrew J. Barr
X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; powerpc-unknown-linux-gnu)
Ronald Reagan: America's answer to Inspector Clouseau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGVKNEhuM+Z62a52oRAo2UAJ9lwMhAyuobAn7C1fmgh4R8iMaTUgCgrykp
/yGB5cvD0qj862eVTsiOcCI=
=7kuC
-----END PGP SIGNATURE-----
[-- Attachment #2: config-2.6.22-rc2.gz --]
[-- Type: application/x-gzip, Size: 12921 bytes --]
[-- Attachment #3: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 6031 bytes --]
^ permalink raw reply
* [PPC] 2.6.22-rc2: badness at mm/slab.c:777
From: Andrew J. Barr @ 2007-05-24 11:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- ------------[ cut here ]------------
Badness at mm/slab.c:777
Call Trace:
[effd7d60] [c0008478] show_stack+0x50/0x184 (unreliable)
[effd7d80] [c00fc948] report_bug+0x84/0xc8
[effd7d90] [c0228af4] __kprobes_text_start+0x11c/0x4f0
[effd7da0] [c0010bc8] ret_from_except_full+0x0/0x4c
- --- Exception: 700 at __kmalloc+0x28/0xe8
LR = __kzalloc+0x18/0x44
[effd7e60] [c0198cc0] usb_get_descriptor+0x7c/0xc4 (unreliable)
[effd7e70] [c006ab14] __kzalloc+0x18/0x44
[effd7e90] [c019b84c] usb_get_configuration+0x7e0/0xb28
[effd7f40] [c019368c] usb_new_device+0x24/0x100
[effd7f60] [c0194630] hub_thread+0x844/0xc54
[effd7fd0] [c0042b60] kthread+0x4c/0x88
[effd7ff0] [c0011468] kernel_thread+0x44/0x60
Occurs during bootup on a Powerbook5,7 (PowerBook G4 17" post-Feb05)
dmesg and .config attached.
- --
Andrew J. Barr
X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; powerpc-unknown-linux-gnu)
Ronald Reagan: America's answer to Inspector Clouseau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGVKNEhuM+Z62a52oRAo2UAJ9lwMhAyuobAn7C1fmgh4R8iMaTUgCgrykp
/yGB5cvD0qj862eVTsiOcCI=
=7kuC
-----END PGP SIGNATURE-----
[-- Attachment #2: config-2.6.22-rc2.gz --]
[-- Type: application/x-gzip, Size: 12921 bytes --]
[-- Attachment #3: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 6031 bytes --]
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-05-24 11:44 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Paul
In-Reply-To: <4655577F.3020801@freescale.com>
On May 24, 2007, at 4:14 AM, Li Yang wrote:
> Export symbols of qe_lib to be used by QE drivers.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
> 3 files changed, 25 insertions(+), 2 deletions(-)
A number of the EXPORT_SYMBOL() are not used by any in kernel drivers
and thus should not be added. See comments below. Also, should
these be EXPORT_SYMBOL_GPL().
> diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/
> qe_lib/ucc.c
> index ac12a44..e8635aa 100644
> --- a/arch/powerpc/sysdev/qe_lib/ucc.c
> +++ b/arch/powerpc/sysdev/qe_lib/ucc.c
> @@ -18,6 +18,7 @@
> #include <linux/errno.h>
> #include <linux/slab.h>
> #include <linux/stddef.h>
> +#include <linux/module.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> @@ -40,6 +41,7 @@ int ucc_set_qe_mux_mii_mng(int ucc_num)
> return 0;
> }
> +EXPORT_SYMBOL(ucc_set_qe_mux_mii_mng);
> int ucc_set_type(int ucc_num, struct ucc_common *regs,
> enum ucc_speed_type speed)
> @@ -66,6 +68,7 @@ int ucc_set_type(int ucc_num, struct ucc_common
> *regs,
> return 0;
> }
> +EXPORT_SYMBOL(ucc_set_type);
remove.
> int ucc_init_guemr(struct ucc_common *regs)
> {
> @@ -81,6 +84,7 @@ int ucc_init_guemr(struct ucc_common *regs)
> return 0;
> }
> +EXPORT_SYMBOL(ucc_init_guemr);
remove.
> static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr,
> u8 * reg_num,
> u8 * shift)
> @@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num,
> volatile u32 ** p_cmxucr, u8 * reg_num,
> break;
> }
> }
> +EXPORT_SYMBOL(get_cmxucr_reg);
remove, you shouldn't be exporting something marked static.
> int ucc_mux_set_grant_tsa_bkpt(int ucc_num, int set, u32 mask)
> {
> @@ -142,6 +147,7 @@ int ucc_mux_set_grant_tsa_bkpt(int ucc_num, int
> set, u32 mask)
> return 0;
> }
> +EXPORT_SYMBOL(ucc_mux_set_grant_tsa_bkpt);
remove
> int ucc_set_qe_mux_rxtx(int ucc_num, enum qe_clock clock, enum
> comm_dir mode)
> {
> @@ -251,3 +257,4 @@ int ucc_set_qe_mux_rxtx(int ucc_num, enum
> qe_clock clock, enum comm_dir mode)
> return 0;
> }
> +EXPORT_SYMBOL(ucc_set_qe_mux_rxtx);
remove.
> diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/
> sysdev/qe_lib/ucc_fast.c
> index 9143236..3df202e 100644
> --- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
> +++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
> @@ -19,6 +19,7 @@
> #include <linux/stddef.h>
> #include <linux/interrupt.h>
> #include <linux/err.h>
> +#include <linux/module.h>
> #include <asm/io.h>
> #include <asm/immap_qe.h>
> @@ -70,6 +71,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private *
> uccf)
> printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x",
> (u32) & uccf->uf_regs->guemr, uccf->uf_regs->guemr);
> }
> +EXPORT_SYMBOL(ucc_fast_dump_regs);
> u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
> {
> @@ -85,11 +87,13 @@ u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
> default: return QE_CR_SUBBLOCK_INVALID;
> }
> }
> +EXPORT_SYMBOL(ucc_fast_get_qe_cr_subblock);
> void ucc_fast_transmit_on_demand(struct ucc_fast_private * uccf)
> {
> out_be16(&uccf->uf_regs->utodr, UCC_FAST_TOD);
> }
> +EXPORT_SYMBOL(ucc_fast_transmit_on_demand);
> void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir
> mode)
> {
> @@ -110,6 +114,7 @@ void ucc_fast_enable(struct ucc_fast_private *
> uccf, enum comm_dir mode)
> }
> out_be32(&uf_regs->gumr, gumr);
> }
> +EXPORT_SYMBOL(ucc_fast_enable);
> void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir
> mode)
> {
> @@ -130,6 +135,7 @@ void ucc_fast_disable(struct ucc_fast_private *
> uccf, enum comm_dir mode)
> }
> out_be32(&uf_regs->gumr, gumr);
> }
> +EXPORT_SYMBOL(ucc_fast_disable);
> int ucc_fast_init(struct ucc_fast_info * uf_info, struct
> ucc_fast_private ** uccf_ret)
> {
> @@ -341,6 +347,7 @@ int ucc_fast_init(struct ucc_fast_info *
> uf_info, struct ucc_fast_private ** ucc
> *uccf_ret = uccf;
> return 0;
> }
> +EXPORT_SYMBOL(ucc_fast_init);
> void ucc_fast_free(struct ucc_fast_private * uccf)
> {
> @@ -355,3 +362,4 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
> kfree(uccf);
> }
> +EXPORT_SYMBOL(ucc_fast_free);
> diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/arch/powerpc/
> sysdev/qe_lib/ucc_slow.c
> index 1f65c26..5618275 100644
> --- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
> +++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
> @@ -19,6 +19,7 @@
> #include <linux/stddef.h>
> #include <linux/interrupt.h>
> #include <linux/err.h>
> +#include <linux/module.h>
> #include <asm/io.h>
> #include <asm/immap_qe.h>
> @@ -41,11 +42,13 @@ u32 ucc_slow_get_qe_cr_subblock(int uccs_num)
> default: return QE_CR_SUBBLOCK_INVALID;
> }
> }
> +EXPORT_SYMBOL(ucc_slow_get_qe_cr_subblock);
remove.
> void ucc_slow_poll_transmitter_now(struct ucc_slow_private * uccs)
> {
> out_be16(&uccs->us_regs->utodr, UCC_SLOW_TOD);
> }
> +EXPORT_SYMBOL(ucc_slow_poll_transmitter_now);
remove.
> void ucc_slow_graceful_stop_tx(struct ucc_slow_private * uccs)
> {
> @@ -56,6 +59,7 @@ void ucc_slow_graceful_stop_tx(struct
> ucc_slow_private * uccs)
> qe_issue_cmd(QE_GRACEFUL_STOP_TX, id,
> QE_CR_PROTOCOL_UNSPECIFIED, 0);
> }
> +EXPORT_SYMBOL(ucc_slow_graceful_stop_tx);
remove.
> void ucc_slow_stop_tx(struct ucc_slow_private * uccs)
> {
> @@ -65,6 +69,7 @@ void ucc_slow_stop_tx(struct ucc_slow_private *
> uccs)
> id = ucc_slow_get_qe_cr_subblock(us_info->ucc_num);
> qe_issue_cmd(QE_STOP_TX, id, QE_CR_PROTOCOL_UNSPECIFIED, 0);
> }
> +EXPORT_SYMBOL(ucc_slow_stop_tx);
remove.
> void ucc_slow_restart_tx(struct ucc_slow_private * uccs)
> {
> @@ -74,6 +79,7 @@ void ucc_slow_restart_tx(struct ucc_slow_private
> * uccs)
> id = ucc_slow_get_qe_cr_subblock(us_info->ucc_num);
> qe_issue_cmd(QE_RESTART_TX, id, QE_CR_PROTOCOL_UNSPECIFIED, 0);
> }
> +EXPORT_SYMBOL(ucc_slow_restart_tx);
remove.
> void ucc_slow_enable(struct ucc_slow_private * uccs, enum comm_dir
> mode)
> {
> @@ -94,6 +100,7 @@ void ucc_slow_enable(struct ucc_slow_private *
> uccs, enum comm_dir mode)
> }
> out_be32(&us_regs->gumr_l, gumr_l);
> }
> +EXPORT_SYMBOL(ucc_slow_enable);
remove.
> void ucc_slow_disable(struct ucc_slow_private * uccs, enum comm_dir
> mode)
> {
> @@ -114,6 +121,7 @@ void ucc_slow_disable(struct ucc_slow_private *
> uccs, enum comm_dir mode)
> }
> out_be32(&us_regs->gumr_l, gumr_l);
> }
> +EXPORT_SYMBOL(ucc_slow_disable);
remove.
> int ucc_slow_init(struct ucc_slow_info * us_info, struct
> ucc_slow_private ** uccs_ret)
> {
> @@ -349,6 +357,7 @@ int ucc_slow_init(struct ucc_slow_info *
> us_info, struct ucc_slow_private ** ucc
> *uccs_ret = uccs;
> return 0;
> }
> +EXPORT_SYMBOL(ucc_slow_init);
remove.
> void ucc_slow_free(struct ucc_slow_private * uccs)
> {
> @@ -368,5 +377,4 @@ void ucc_slow_free(struct ucc_slow_private * uccs)
> kfree(uccs);
> }
> -
> -
> +EXPORT_SYMBOL(ucc_slow_free);
^ permalink raw reply
* Re: [Patch 2/2] Kexec/Kdump support - POWER6
From: Mohan Kumar M @ 2007-05-24 12:17 UTC (permalink / raw)
To: Paul Mackerras
Cc: Milton Miller II, kexec, linuxppc-dev, Olof Johansson, ellerman
In-Reply-To: <18004.7556.311264.415721@cargo.ozlabs.ibm.com>
On Wed, May 23, 2007 at 08:55:00PM +1000, Paul Mackerras wrote:
> Sachin P. Sant writes:
>
> > On Power machines supporting VRMA, Kexec/Kdump does not work.
> > Hypervisor stores VRMA mapping used by the OS, in the hpte hash
> > tables. Make sure these hpte entries are left untouched.
>
> Surely all we need to do is to avoid clearing the VRMA entries. We
> can do this by not clearing any HPTE where the top 40 bits of the
> first dword are 0x4001ffffff (B=1 for a 1TB segment and the
> 0x0001ffffff special VSID). In fact we can avoid having to read each
> entry by doing the H_REMOVEs with H_ANDCOND and the bolted bit when we
> clear the hash table, and only reading the HPTEs for which the
> H_REMOVE returns an error.
>
Paul,
Thanks for your suggestion.
But we can not use 0x4001fffff for H_ANDCOND flag since AND'ing
0x4001ffff value with most of the HPTEs results in non-zero and most of
the HPTE entries are not removed.
>From POWER ISA 2.04 document page 425,
"Programming Note:
Software should specify PTE(B) = 0b01 for all Page
Table Entries that map the VRMA in order to be
consistent with the values in Figure 14."
So I tried 0x4000000000000000 as AVPN parameter and using that it
removes all hpte entries other than VRMA(ie non 1TB segment size PTE
entries).
Tested on POWER6/POWER5 machines.
========================
Starting from POWER5+, hypervisor stores VRMA entries in the HPTE tables
and these entries are need by OS and they should not be cleared. These
VRMA entries will be of segment size 1TB. Using H_ANDCOND flag for
H_REMOVE hypervisor call it is made sure that we will not remove any PTE
whose size is 1TB(ie VRMA entries)
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
---
arch/powerpc/platforms/pseries/lpar.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.21.1/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6.21.1.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6.21.1/arch/powerpc/platforms/pseries/lpar.c
@@ -369,6 +369,8 @@ static long pSeries_lpar_hpte_remove(uns
return -1;
}
+#define VRMA_HPTE_B_1TB ASM_CONST(0x4000000000000000)
+
static void pSeries_lpar_hptab_clear(void)
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
@@ -378,7 +380,9 @@ static void pSeries_lpar_hptab_clear(voi
/* TODO: Use bulk call */
for (i = 0; i < hpte_count; i++)
- plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ /* dont remove HPTEs of segments size 1TB (VRMA entries) */
+ plpar_pte_remove_raw(H_ANDCOND, i, VRMA_HPTE_B_1TB,
+ &dummy1, &dummy2);
}
/*
^ permalink raw reply
* adding new flash for jffs2 file system
From: Nethra @ 2007-05-24 12:28 UTC (permalink / raw)
To: linuxppc-dev
hi,
I have tested jffs2 booting on board MPC8272ADS and PQ2FADS-ZU board.
linux is 2.6.10 and boot loarder is u-boot-1.1.2.
Now we r using custom board simillar to MPC8272ADS board...
but flash we r using here is AM29LV641ML.But jffs2 booting is not working.
does kernel has support for this flash..?, if not how to add the support for
this flash?
with regards,
Nethra.
--
View this message in context: http://www.nabble.com/adding-new-flash-for-jffs2-file-system-tf3809788.html#a10782781
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: Andrei Konovalov @ 2007-05-24 13:08 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <465561A4.9020403@dlasys.net>
Hi David,
David H. Lynch Jr. wrote:
> Andrei Konovalov wrote:
>> Hello,
>>
>> My Xilinx Virtex Development tree is now alive again.
>>
>> Please use the dev branch (master is just the ko copy):
>> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
>> Currently it has a patch to enable the framebuffer
>> on ML403 and ML300 plus TEMAC driver that uses
>> the PHY lib (FIFO mode support only).
>> The TEMAC driver is work in progress.
>> In the queue are SGDMA TEMAC support, and SPI driver
>> (master only).
>>
>> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
>> The comments / opinions on how to get this driver (not the current incomplete
>> version of course) accepted into the ko tree are very welcomed.
>>
> I have an almost working FIFO TEMAC driver. It is similarly based.
> it started out based on the Trek webserver sample
Is this a reference design by Xilinx? Linux based or standalone?
> I spent probably 3-4 days de-EDKing it into something that fit into a
> single source and was closer to ko norms.
> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
> if it could be helpful in anyway.
> I am all for getting an acceptable driver into the ko tree.
You could post your driver to the list when you think it is in good enough shape.
If your driver is based on the linux TEMAC driver from EDK, it shouldn't
be very different from my version (my added value is mostly replacing the
custom PHY code with the PHY lib stuff). Then we could merge our drivers (or
whatever would make sense).
I would be interested to have a look at your current code just to see
how much has it cost to "de-EDK" the FIFO part. You could email me
your (even not quite working) driver privately if you want.
Thanks,
Andrei
^ permalink raw reply
* Problems in 2.6 memory management on 8xx
From: Detlev Zundel @ 2007-05-24 13:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi,
working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
behaviour exemplified by the simple attached demo program. An icbi
from userspace on an address that is mapped only lazily gets into an -
though interruptible - loop. Locking the icbi target in question with
mlock circumvents this problem.
I tested this code on 2.6.21 on 4xx and 82xx only to prove that those
combinations, as expected, don't have this problem. Vitaly Bordug was
kind enough to test the code on an 8xx hw supported by a recent kernel
and acknowledged it still being present.
As I don't have time to investigate this any further, I at least want
to document this problem with this post. Maybe someone else can help
out here.
Thanks
Detlev
--
-- Question authority!
-- Yeah, says who?
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: icbi.c --]
[-- Type: text/x-csrc, Size: 437 bytes --]
/* Test code to show problem with handling of icbi in userspace on
PowerPC in Linux 2.6 */
#include <stdio.h>
#include <unistd.h>
extern void test();
int main(int argc, char *argv[])
{
#if 0
/* Lock the text segment of the test routine so that the pages will
be present in RAM - otherwise the ICBI will not work */
mlock((void *)&test, 3*4096);
#endif
test();
printf("move on - there's nothing to see here\n");
return 0;
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: icbi_trigger.S --]
[-- Type: text/x-csrc, Size: 463 bytes --]
.globl test
/* Align to MMU page size, i.e. 2^12 = 4k */
.align 12
page0:
test:
mflr %r20
/* invalidate first cache line at page1 */
lis %r24, page0@h
ori %r24, %r24, page0@l
li %r23, 0x1000
icbi %r24, %r23
b test_return
.org page0+4096
/*
page1 is on a new 4k page - only fill it with "mtmq r0" (sigill)
*/
page1:
/* Ensure that page2 again is on a new 4k page */
.org page1+4096
page2:
test_return:
mtlr %r20 /* restore lr */
blr
[-- Attachment #4: Makefile --]
[-- Type: text/plain, Size: 151 bytes --]
CC=$(CROSS_COMPILE)gcc
AS=$(CROSS_COMPILE)as
CFLAGS=-g
%.o: %.S
$(CC) -c -o $@ $<
all: icbi
icbi: icbi.o icbi_trigger.o
clean:
rm -f *.o *~ icbi
^ permalink raw reply
* [PATCH] fix stolen time for SMT without LPAR
From: Michael Neuling @ 2007-05-24 13:33 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
For POWERPC, stolen time accounts for cycles lost to the hypervisor or
PURR cycles attributed to the other SMT thread. Hence, when a PURR is
available, we should still calculate stolen time, irrespective of being
virtualised.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Kudos to sfr for realizing the problem here.
arch/powerpc/kernel/time.c | 6 ++++--
include/asm-powerpc/time.h | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -244,7 +244,8 @@ void snapshot_timebases(void)
{
int cpu;
- if (!cpu_has_feature(CPU_FTR_PURR))
+ if (!cpu_has_feature(CPU_FTR_PURR) &&
+ !firmware_has_feature(FW_FEATURE_SPLPAR))
return;
for_each_possible_cpu(cpu)
spin_lock_init(&per_cpu(cpu_purr_data, cpu).lock);
@@ -257,7 +258,8 @@ void calculate_steal_time(void)
s64 stolen;
struct cpu_purr_data *pme;
- if (!cpu_has_feature(CPU_FTR_PURR))
+ if (!cpu_has_feature(CPU_FTR_PURR) &&
+ !firmware_has_feature(FW_FEATURE_SPLPAR))
return;
pme = &per_cpu(cpu_purr_data, smp_processor_id());
if (!pme->initialized)
Index: linux-2.6-ozlabs/include/asm-powerpc/time.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/time.h
+++ linux-2.6-ozlabs/include/asm-powerpc/time.h
@@ -232,7 +232,7 @@ extern void account_process_vtime(struct
#define account_process_vtime(tsk) do { } while (0)
#endif
-#if defined(CONFIG_VIRT_CPU_ACCOUNTING) && defined(CONFIG_PPC_SPLPAR)
+#if defined(CONFIG_VIRT_CPU_ACCOUNTING)
extern void calculate_steal_time(void);
extern void snapshot_timebases(void);
#else
^ permalink raw reply
* Re: Don't store a command line in the Holly device tree
From: Josh Boyer @ 2007-05-24 13:39 UTC (permalink / raw)
To: David Gibson; +Cc: Hugh Blemings, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070524040210.GC20078@localhost.localdomain>
On Thu, 2007-05-24 at 14:02 +1000, David Gibson wrote:
> Currently, the Holly device tree includes a bootargs property in
> /chosen, which gives a commandline. This is somewhat inconvenient,
> because it means an alternative default command line can't be given in
> the kernel config - the value obtained from the dts via the
> bootwrapper will always override CONFIG_CMDLINE.
>
> This patch removes the command line from the dts, and instead puts the
> same command line as a default in holly_defconfig.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-24 13:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Alexandre Bounine, David Gibson
In-Reply-To: <BB9A8C3A-0BC5-4DF0-9201-2742124A4AF5@kernel.crashing.org>
On Wed, 2007-05-23 at 23:22 -0500, Kumar Gala wrote:
> On May 23, 2007, at 11:16 PM, David Gibson wrote:
>
> > This patch fixes some problems with the way the Ethernet PHYs are
> > represented in the device tree for the Holly board. This means
> > changes to the dts itself, and to the code with instantiates the
> > tsi108 ethernet platform devices based on the device tree.
> >
> > - First, and most importantly, the PHYs are given with an
> > identical 'reg' property. This reg currently encodes the accessible
> > register used to initiate mdio interaction with the PHYs, rather than
> > a meaningful address on the parent bus (mdio in this case), which is
> > incorrect. Instead we give the address of these registers as 'reg' in
> > the mdio node itself, and encode the ID of each phy in their 'reg'
> > propertys. The PHY's unit name addresses are updated to match.
> > - Second, the PHYs give only "bcm54xx" as a compatible
> > property. This is unfortunate, because there are many bcm54xx PHY
> > models, and they have differences which can matter. We add a more
> > precise compatible string, giving the precise PHY model (bcm5461A in
> > this case).
>
> Is the compatible really need here? We are able to provide and bind
> drivers based on MII_PHYSID1/2. I don't see what putting the
> compatible proper gets us.
I think it's needed until the TSI driver switches to phylib. Right now,
it assumes that a Marvell phy is used, which is what is present on the
Taiga MPC7448HPC2 board. The Holly board uses the Broadcom phy and we
added the compatible code for that.
josh
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-24 13:45 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev list, Alexandre Bounine
In-Reply-To: <20070524041625.GD20078@localhost.localdomain>
On Thu, 2007-05-24 at 14:16 +1000, David Gibson wrote:
> This patch fixes some problems with the way the Ethernet PHYs are
> represented in the device tree for the Holly board. This means
> changes to the dts itself, and to the code with instantiates the
> tsi108 ethernet platform devices based on the device tree.
>
> - First, and most importantly, the PHYs are given with an
> identical 'reg' property. This reg currently encodes the accessible
> register used to initiate mdio interaction with the PHYs, rather than
> a meaningful address on the parent bus (mdio in this case), which is
> incorrect. Instead we give the address of these registers as 'reg' in
> the mdio node itself, and encode the ID of each phy in their 'reg'
> propertys. The PHY's unit name addresses are updated to match.
You'll need to fixup the mpc7448hpc2 board's DTS with the same change
then, as it shares the same bridge and ethernet code.
> - Second, the PHYs give only "bcm54xx" as a compatible
> property. This is unfortunate, because there are many bcm54xx PHY
> models, and they have differences which can matter. We add a more
> precise compatible string, giving the precise PHY model (bcm5461A in
> this case).
This part is fine with me.
josh
^ permalink raw reply
* Re: [Patch 2/2] Kexec/Kdump support - POWER6
From: Olof Johansson @ 2007-05-24 14:21 UTC (permalink / raw)
To: Mohan Kumar M
Cc: Milton Miller II, kexec, linuxppc-dev, Paul Mackerras, ellerman
In-Reply-To: <20070524121751.GB4547@in.ibm.com>
On Thu, May 24, 2007 at 05:47:51PM +0530, Mohan Kumar M wrote:
> On Wed, May 23, 2007 at 08:55:00PM +1000, Paul Mackerras wrote:
> > Sachin P. Sant writes:
> >
> > > On Power machines supporting VRMA, Kexec/Kdump does not work.
> > > Hypervisor stores VRMA mapping used by the OS, in the hpte hash
> > > tables. Make sure these hpte entries are left untouched.
> >
> > Surely all we need to do is to avoid clearing the VRMA entries. We
> > can do this by not clearing any HPTE where the top 40 bits of the
> > first dword are 0x4001ffffff (B=1 for a 1TB segment and the
> > 0x0001ffffff special VSID). In fact we can avoid having to read each
> > entry by doing the H_REMOVEs with H_ANDCOND and the bolted bit when we
> > clear the hash table, and only reading the HPTEs for which the
> > H_REMOVE returns an error.
>
> So I tried 0x4000000000000000 as AVPN parameter and using that it
> removes all hpte entries other than VRMA(ie non 1TB segment size PTE
> entries).
>
> Tested on POWER6/POWER5 machines.
Hi,
As Paul says above, you need to check for failures and compare the VSID
and possibly unhash it anyway in case of non-match. Otherwise if the
kernel ever starts using 1TB segments for regular use, those pages will
never be unhashed. I don't see your code doing that now.
-Olof
^ permalink raw reply
* [PATCH] IB/ehca: Refactor "maybe missed event" code
From: Joachim Fenkes @ 2007-05-24 14:51 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Cc: Stefan Roscher, Christoph Raisch
Refactored Roland's patch so the queue arithmetic is done in a little less
lines. Also, moved the spinlock inside the block it's used in.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_reqs.c | 2 +-
drivers/infiniband/hw/ehca/ipz_pt_fn.h | 28 ++++++++++------------------
2 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c b/drivers/infiniband/hw/ehca/ehca_reqs.c
index caec9de..56c4527 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -637,7 +637,6 @@ poll_cq_exit0:
int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify_flags notify_flags)
{
struct ehca_cq *my_cq = container_of(cq, struct ehca_cq, ib_cq);
- unsigned long spl_flags;
int ret = 0;
switch (notify_flags & IB_CQ_SOLICITED_MASK) {
@@ -652,6 +651,7 @@ int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify_flags notify_flags)
}
if (notify_flags & IB_CQ_REPORT_MISSED_EVENTS) {
+ unsigned long spl_flags;
spin_lock_irqsave(&my_cq->spinlock, spl_flags);
ret = ipz_qeit_is_valid(&my_cq->ipz_queue);
spin_unlock_irqrestore(&my_cq->spinlock, spl_flags);
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.h b/drivers/infiniband/hw/ehca/ipz_pt_fn.h
index 57f141a..007f088 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.h
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.h
@@ -105,7 +105,6 @@ void *ipz_qpageit_get_inc(struct ipz_queue *queue);
* step in struct ipz_queue, will wrap in ringbuffer
* returns address (kv) of Queue Entry BEFORE increment
* warning don't use in parallel with ipz_qpageit_get_inc()
- * warning unpredictable results may occur if steps>act_nr_of_queue_entries
*/
static inline void *ipz_qeit_get_inc(struct ipz_queue *queue)
{
@@ -121,31 +120,24 @@ static inline void *ipz_qeit_get_inc(struct ipz_queue *queue)
}
/*
+ * return a bool indicating whether current Queue Entry is valid
+ */
+static inline int ipz_qeit_is_valid(struct ipz_queue *queue)
+{
+ struct ehca_cqe *cqe = ipz_qeit_get(queue);
+ return ((cqe->cqe_flags >> 7) == (queue->toggle_state & 1));
+}
+
+/*
* return current Queue Entry, increment Queue Entry iterator by one
* step in struct ipz_queue, will wrap in ringbuffer
* returns address (kv) of Queue Entry BEFORE increment
* returns 0 and does not increment, if wrong valid state
* warning don't use in parallel with ipz_qpageit_get_inc()
- * warning unpredictable results may occur if steps>act_nr_of_queue_entries
*/
static inline void *ipz_qeit_get_inc_valid(struct ipz_queue *queue)
{
- struct ehca_cqe *cqe = ipz_qeit_get(queue);
- u32 cqe_flags = cqe->cqe_flags;
-
- if ((cqe_flags >> 7) != (queue->toggle_state & 1))
- return NULL;
-
- ipz_qeit_get_inc(queue);
- return cqe;
-}
-
-static inline int ipz_qeit_is_valid(struct ipz_queue *queue)
-{
- struct ehca_cqe *cqe = ipz_qeit_get(queue);
- u32 cqe_flags = cqe->cqe_flags;
-
- return cqe_flags >> 7 == (queue->toggle_state & 1);
+ return ipz_qeit_is_valid(queue) ? ipz_qeit_get_inc(queue) : NULL;
}
/*
--
1.5.2
^ permalink raw reply related
* [PATCH] IB/ehca: fix wrong number of send WRs returned
From: Joachim Fenkes @ 2007-05-24 14:51 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Cc: Stefan Roscher, Christoph Raisch
From: Stefan Roscher <stefan.roscher@de.ibm.com>
Due to a typo, the driver was reporting the wrong number of "actual send
WRs" after ehca_create_qp(). Fixed.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/hcp_if.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c b/drivers/infiniband/hw/ehca/hcp_if.c
index 7f0beec..5766ae3 100644
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -331,7 +331,7 @@ u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle adapter_handle,
0);
qp->ipz_qp_handle.handle = outs[0];
qp->real_qp_num = (u32)outs[1];
- parms->act_nr_send_sges =
+ parms->act_nr_send_wqes =
(u16)EHCA_BMASK_GET(H_ALL_RES_QP_ACT_OUTST_SEND_WR, outs[2]);
parms->act_nr_recv_wqes =
(u16)EHCA_BMASK_GET(H_ALL_RES_QP_ACT_OUTST_RECV_WR, outs[2]);
--
1.5.2
^ permalink raw reply related
* Re: [PPC] 2.6.22-rc2: badness at mm/slab.c:777
From: Geert Uytterhoeven @ 2007-05-24 15:07 UTC (permalink / raw)
To: Andrew J. Barr; +Cc: linuxppc-dev
In-Reply-To: <20070524073745.29cffa4b@powerbook.oakcourt.dyndns.org>
On Thu, 24 May 2007, Andrew J. Barr wrote:
> - ------------[ cut here ]------------
> Badness at mm/slab.c:777
> Call Trace:
> [effd7d60] [c0008478] show_stack+0x50/0x184 (unreliable)
> [effd7d80] [c00fc948] report_bug+0x84/0xc8
> [effd7d90] [c0228af4] __kprobes_text_start+0x11c/0x4f0
> [effd7da0] [c0010bc8] ret_from_except_full+0x0/0x4c
> - --- Exception: 700 at __kmalloc+0x28/0xe8
> LR = __kzalloc+0x18/0x44
> [effd7e60] [c0198cc0] usb_get_descriptor+0x7c/0xc4 (unreliable)
> [effd7e70] [c006ab14] __kzalloc+0x18/0x44
> [effd7e90] [c019b84c] usb_get_configuration+0x7e0/0xb28
> [effd7f40] [c019368c] usb_new_device+0x24/0x100
> [effd7f60] [c0194630] hub_thread+0x844/0xc54
> [effd7fd0] [c0042b60] kthread+0x4c/0x88
> [effd7ff0] [c0011468] kernel_thread+0x44/0x60
>
> Occurs during bootup on a Powerbook5,7 (PowerBook G4 17" post-Feb05)
>
> dmesg and .config attached.
I'm seeing it too on PS3 when hitting CTRL-ALT-DEL.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: Problems in 2.6 memory management on 8xx
From: Joakim Tjernlund @ 2007-05-24 15:23 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-dev
In-Reply-To: <m2fy5mcqut.fsf@sowhat.denx.de>
On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
> Hi,
>
> working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
> behaviour exemplified by the simple attached demo program. An icbi
> from userspace on an address that is mapped only lazily gets into an -
> though interruptible - loop. Locking the icbi target in question with
> mlock circumvents this problem.
8xx is buggy w.r.t cache instructions. They do not update the
DAR register in the TLB miss/TLB error handlers.
The TLB miss handler does not use the DAR reg but the TLB error
handler do. Thats why it works when you mlock the memory.
This bug isn't documented but Freescale has confirmed it.
You can search the archives some years back for more info.
Jocke
>
> I tested this code on 2.6.21 on 4xx and 82xx only to prove that those
> combinations, as expected, don't have this problem. Vitaly Bordug was
> kind enough to test the code on an 8xx hw supported by a recent kernel
> and acknowledged it still being present.
>
> As I don't have time to investigate this any further, I at least want
> to document this problem with this post. Maybe someone else can help
> out here.
>
> Thanks
> Detlev
>
> plain text document attachment (Makefile)
> CC=$(CROSS_COMPILE)gcc
> AS=$(CROSS_COMPILE)as
> CFLAGS=-g
>
> %.o: %.S
> $(CC) -c -o $@ $<
>
> all: icbi
>
> icbi: icbi.o icbi_trigger.o
>
> clean:
> rm -f *.o *~ icbi
> _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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