LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Debugging kernel on mpc7448
From: Cajus Pollmeier @ 2010-11-03 15:02 UTC (permalink / raw)
  To: Linuxppc-dev

Hello there,

I'm currently trying to get a kernel upgrade from 2.6.11 to 2.6.31
working with u-boot/cuImage.c2k on a custom marvell discovery 3 board.
In the moment, the following steps work:

* u-boot (1.1.4, not changeable in the moment) runs from flash and
offers a prompt
* loading cuImage.c2k
* running the code of wrapper.c until calling vmlinux.addr
* entering __start in head_32.S and running until early_init gets called

The systems then hangs until the watchdog resets the board. In this
early stage, I've no output to the serial console - which is the only
way to see what's going on there without having a development board with
single step capabilities.

To track it until early_init, I tried to place a stupid "blr" in
head_32.S, in order to get back to wrapper.c - which writes out a
message to the serial console in case the kernel "accidently" gets back
to it.

>From now on, I'm not sure if early_init is properly called. The blr
after the call is either not reached or there's something going on which
is beyond my limited knowledge of ppc assembler. Maybe u-boot gets
overwritten, but the blr isn't even reached if I change early_init by
just returning 0U immediately. Hmm.

Any pointers to help debugging would be really appreciated ;-)

Cheers,
Cajus 

^ permalink raw reply

* Re: Problem with Infiniband adapter on IBM p550
From: Patrick Finnegan @ 2010-11-03 14:43 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: paulus, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101104003444.5fff5935@kryten>

On Wednesday, November 03, 2010, Anton Blanchard wrote:
> Firmware has the concept of "super slots" which allow larger memory
> windows and TCE tables. Section 3.4.3 explains it:
> 
> http://www.redbooks.ibm.com/redpapers/pdfs/redp4095.pdf

Aha!  I tried moving the adapter from slot C3 to C5, which is listed in 
that guide, and now it's working.

Thanks for the pointer!

Pat
-- 
Purdue University Research Computing ---  http://www.rcac.purdue.edu/
The Computer Refuge                  ---  http://computer-refuge.org

^ permalink raw reply

* Re: [PATCH 2/3 RESEND] powerpc: remove cast from void*
From: Benjamin Herrenschmidt @ 2010-11-03 14:18 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: matt mooney, linuxppc-dev, kernel-janitors, Paul Mackerras
In-Reply-To: <alpine.LNX.2.00.1011031015150.15851@pobox.suse.cz>

On Wed, 2010-11-03 at 10:15 -0400, Jiri Kosina wrote:
> On Mon, 27 Sep 2010, matt mooney wrote:
> 
> > Unnecessary cast from void* in assignment.
> > 
> > Signed-off-by: matt mooney <mfm@muteddisk.com>
> > ---
> >  arch/powerpc/platforms/pseries/hvCall_inst.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c b/arch/powerpc/platforms/pseries/hvCall_inst.c
> > index e19ff02..f106662 100644
> > --- a/arch/powerpc/platforms/pseries/hvCall_inst.c
> > +++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
> > @@ -55,7 +55,7 @@ static void hc_stop(struct seq_file *m, void *p)
> >  static int hc_show(struct seq_file *m, void *p)
> >  {
> >  	unsigned long h_num = (unsigned long)p;
> > -	struct hcall_stats *hs = (struct hcall_stats *)m->private;
> > +	struct hcall_stats *hs = m->private;
> >  
> >  	if (hs[h_num].num_calls) {
> >  		if (cpu_has_feature(CPU_FTR_PURR))
> 
> This doesn't seem to be present in 37-rc1, so I am taking it to trivial 
> queue. If this has been already merged to another tree, let me know.

Looks like I missed it, but Ack.

Cheers,
Ben.

^ permalink raw reply

* Re: [PATCH 2/3 RESEND] powerpc: remove cast from void*
From: Jiri Kosina @ 2010-11-03 14:15 UTC (permalink / raw)
  To: matt mooney; +Cc: kernel-janitors, Paul Mackerras, linuxppc-dev
In-Reply-To: <f7d601da574581e9dfdc1314a969475c73491c00.1285638395.git.mfm@muteddisk.com>

On Mon, 27 Sep 2010, matt mooney wrote:

> Unnecessary cast from void* in assignment.
> 
> Signed-off-by: matt mooney <mfm@muteddisk.com>
> ---
>  arch/powerpc/platforms/pseries/hvCall_inst.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c b/arch/powerpc/platforms/pseries/hvCall_inst.c
> index e19ff02..f106662 100644
> --- a/arch/powerpc/platforms/pseries/hvCall_inst.c
> +++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
> @@ -55,7 +55,7 @@ static void hc_stop(struct seq_file *m, void *p)
>  static int hc_show(struct seq_file *m, void *p)
>  {
>  	unsigned long h_num = (unsigned long)p;
> -	struct hcall_stats *hs = (struct hcall_stats *)m->private;
> +	struct hcall_stats *hs = m->private;
>  
>  	if (hs[h_num].num_calls) {
>  		if (cpu_has_feature(CPU_FTR_PURR))

This doesn't seem to be present in 37-rc1, so I am taking it to trivial 
queue. If this has been already merged to another tree, let me know.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

^ permalink raw reply

* Re: Problem with Infiniband adapter on IBM p550
From: Benjamin Herrenschmidt @ 2010-11-03 13:46 UTC (permalink / raw)
  To: Patrick Finnegan; +Cc: linuxppc-dev@lists.ozlabs.org, paulus
In-Reply-To: <201011022315.04291.pat@computer-refuge.org>

On Tue, 2010-11-02 at 23:15 -0400, Patrick Finnegan wrote:
> > I don't know why, but it definitely looks like a firmware bug to me.
> > On those machines, PCI resource assignment is under hypervisor
> > control and so Linux cannot re-assign missing resources itself.
> > 
> > I'll see if I can find a FW person to shed some light on this.
> > 
> > Can you provide me (privately maybe) with the FW version on the
> > machine ?
> 
> Ben,
> 
> Have you found out anything more on this (firmware) bug?

No, not yet. Let me ping some folks again.

Cheers,
Ben.

^ permalink raw reply

* Re: Problem with Infiniband adapter on IBM p550
From: Anton Blanchard @ 2010-11-03 13:34 UTC (permalink / raw)
  To: Patrick Finnegan; +Cc: paulus, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <201011022315.04291.pat@computer-refuge.org>


Hi,

> > Now, I think this is the problem.
> > 
> > The "assigned-addresses" property seems to indicate that the
> > firmware only assigned BAR 4 and didn't assign anything to the
> > other ones.
> > 
> > I don't know why, but it definitely looks like a firmware bug to me.
> > On those machines, PCI resource assignment is under hypervisor
> > control and so Linux cannot re-assign missing resources itself.
> > 
> > I'll see if I can find a FW person to shed some light on this.
> > 
> > Can you provide me (privately maybe) with the FW version on the
> > machine ?
> 
> Ben,
> 
> Have you found out anything more on this (firmware) bug?

Firmware has the concept of "super slots" which allow larger memory
windows and TCE tables. Section 3.4.3 explains it:

http://www.redbooks.ibm.com/redpapers/pdfs/redp4095.pdf

Anton

^ permalink raw reply

* Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: Frank Ch. Eigler @ 2010-11-03 12:49 UTC (permalink / raw)
  To: divya; +Cc: linuxppc-dev, systemtap
In-Reply-To: <4CB704AC.4070203@linux.vnet.ibm.com>


divya <dipraksh@linux.vnet.ibm.com> writes:

> While running systemtap tests on the p6 machine , against the kernel version 2.6.36-rc7-git3
> Oops occured , here are the call trace
>
>  BUG: spinlock bad magic on CPU#6, stapio/20398
> -- 0:conmux-control -- time-stamp -- Oct/13/10  2:49:18 --res
>  lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
> [...]

jistone committed some timing-related changes last night.  Would you
mind trying a new build on your ppc box?

It seems as through there is a concurrency problem with the timer
shutdown process.  If the problem still occurs, we might need to
instrument that part of the kernel and/or runtime code to figure it
out.

- FChE

^ permalink raw reply

* Re: [PATHC v1] PPC4xx: Adding PCI(E) MSI support
From: Josh Boyer @ 2010-11-03 12:48 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: tmarri, linuxppc-dev
In-Reply-To: <1288786293.989.65.camel@concordia>

On Wed, Nov 03, 2010 at 11:11:33PM +1100, Michael Ellerman wrote:
>> +	struct device_node *msi_dev = NULL;
>> +	const u32 *count;
>> +
>> +	msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
>> +	if (msi_dev)
>> +		return -ENODEV;
>> +

You also leak a reference to the node here, as there is never a call to
of_node_put.

josh

^ permalink raw reply

* Re: [PATCH 3/3] powerpc: Disable VPHN polling during a suspend operation
From: Michael Ellerman @ 2010-11-03 12:12 UTC (permalink / raw)
  To: Jesse Larrew; +Cc: markn, pmac, tbreeds, lkessler, mjwolf, linuxppc-dev
In-Reply-To: <20101029002921.17835.88560.sendpatchset@manic8ball.ltc.austin.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

On Thu, 2010-10-28 at 20:30 -0400, Jesse Larrew wrote: 
> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>

Hi Jesse, a few comments ...

> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
> index afe4aaa..1747d27 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -49,7 +49,7 @@ static inline int pcibus_to_node(struct pci_bus *bus)
>  {
>  	return -1;
>  }
> -#endif
> +#endif /* CONFIG_PCI */

Random change, though not a biggy I suppose.

> #define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
>  				 cpu_all_mask :				\
> @@ -93,6 +93,8 @@ extern void __init dump_numa_cpu_topology(void);
>  extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
>  extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
>  
> +extern int __init init_topology_update(void);
> +extern int stop_topology_update(void);

init_topology_update() is called repeatedly from post_suspend_work() so
it seems like it should be called start_topology_update(). And it can't
be __init because the suspend code is called after boot. You should get
a section mismatch warning if they are enabled.

> #else
>  
>  static inline void dump_numa_cpu_topology(void) {}
> @@ -107,6 +109,8 @@ static inline void sysfs_remove_device_from_node(struct sys_device *dev,
>  {
>  }
>  
> +static int __init init_topology_update(void) {}
> +static int stop_topology_update(void) {}

That doesn't look like it compiles to me, you want static inline, and
they both return int.

> #endif /* CONFIG_NUMA */
>  
>  #include <asm-generic/topology.h>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 8fe8bc6..317ff2f 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -41,6 +41,7 @@
>  #include <asm/atomic.h>
>  #include <asm/time.h>
>  #include <asm/mmu.h>
> +#include <asm/topology.h>
>  
>  struct rtas_t rtas = {
>  	.lock = __ARCH_SPIN_LOCK_UNLOCKED
> @@ -706,6 +707,18 @@ void rtas_os_term(char *str)
>  
>  static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
>  #ifdef CONFIG_PPC_PSERIES
> +static void pre_suspend_work(void)
> +{
> +	stop_topology_update();
> +	return;
> +}
> +
> +static void post_suspend_work(void)
> +{
> +	init_topology_update();
> +	return;
> +}

I'm not sure if it's worth splitting these out into "generic"
callbacks ..

> static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_when_done)
>  {
>  	u16 slb_size = mmu_slb_size;
> @@ -713,6 +726,7 @@ static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_w
>  	int cpu;
>  
>  	slb_set_size(SLB_MIN_SIZE);
> +	pre_suspend_work();
>  	printk(KERN_DEBUG "calling ibm,suspend-me on cpu %i\n", smp_processor_id());
>  
>  	while (rc == H_MULTI_THREADS_ACTIVE && !atomic_read(&data->done) &&

And isn't there an error case here where you're not re-enabling the
polling? See eg. the slb_set_size() call.

> @@ -728,6 +742,7 @@ static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_w
>  		rc = atomic_read(&data->error);
>  
>  	atomic_set(&data->error, rc);
> +	post_suspend_work();
>  
>  	if (wake_when_done) {
>  		atomic_set(&data->done, 1);

cheers



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: [PATHC v1] PPC4xx: Adding PCI(E) MSI support
From: Michael Ellerman @ 2010-11-03 12:11 UTC (permalink / raw)
  To: tmarri; +Cc: linuxppc-dev
In-Reply-To: <1288306514-9769-1-git-send-email-tmarri@apm.com>

[-- Attachment #1: Type: text/plain, Size: 12332 bytes --]

On Thu, 2010-10-28 at 15:55 -0700, tmarri@apm.com wrote:
> From: Tirumala Marri <tmarri@apm.com>
> 
> This patch adds MSI support for 440SPe, 460Ex, 460Sx and 405Ex.

Hi Marri,

I don't know anything about your hardware, but I'll try and review the
other parts of your patch.

..

> diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
> index b721764..92aeee6 100644
> --- a/arch/powerpc/platforms/40x/Kconfig
> +++ b/arch/powerpc/platforms/40x/Kconfig
> @@ -57,6 +57,8 @@ config KILAUEA
>  	select 405EX
>  	select PPC40x_SIMPLE
>  	select PPC4xx_PCI_EXPRESS
> +	select PCI_MSI
> +	select 4xx_MSI
>  	help
>  	  This option enables support for the AMCC PPC405EX evaluation board.
>  
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> index 0f979c5..3836353 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -74,6 +74,8 @@ config KATMAI
>  	select 440SPe
>  	select PCI
>  	select PPC4xx_PCI_EXPRESS
> +	select PCI_MSI
> +	select 4xx_MSI
>  	help
>  	  This option enables support for the AMCC PPC440SPe evaluation board.
>  
> @@ -119,6 +121,8 @@ config CANYONLANDS
>  	select 460EX
>  	select PCI
>  	select PPC4xx_PCI_EXPRESS
> +	select PCI_MSI
> +	select 4xx_MSI
>  	select IBM_NEW_EMAC_RGMII
>  	select IBM_NEW_EMAC_ZMII
>  	help
> @@ -145,6 +149,8 @@ config REDWOOD
>  	select 460SX
>  	select PCI
>  	select PPC4xx_PCI_EXPRESS
> +	select PCI_MSI
> +	select 4xx_MSI
>  	help
>  	  This option enables support for the AMCC PPC460SX Redwood board.
>  
> diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
> index 3965828..ec86000 100644
> --- a/arch/powerpc/sysdev/Kconfig
> +++ b/arch/powerpc/sysdev/Kconfig
> @@ -7,6 +7,12 @@ config PPC4xx_PCI_EXPRESS
>  	depends on PCI && 4xx
>  	default n
>  
> +config 4xx_MSI
> +	bool
> +	depends on PCI_MSI
> +	depends on PCI && 4xx

This can just be: depends on PCI_MSI && 4xx

Because PCI_MSI depends on PCI.

You only ever enable this via select, which ignores dependencies, but
it's probably still good to have the depends as documentation.

> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 0bef9da..30f4da4 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_XILINX_PCI)	+= xilinx_pci.o
>  obj-$(CONFIG_OF_RTC)		+= of_rtc.o
>  ifeq ($(CONFIG_PCI),y)
>  obj-$(CONFIG_4xx)		+= ppc4xx_pci.o
> +obj-$(CONFIG_4xx_MSI)		+= ppc4xx_msi.o

This needn't be inside the if PCI block, that's the whole point of
CONFIG_4xx_MSI. And you should send another patch to add a
CONFIG_4xx_PCI symbol and use that to build ppc4xx_pci.o in the same
way.

> diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
> new file mode 100644
> index 0000000..9d5e0c9
> --- /dev/null
> +++ b/arch/powerpc/sysdev/ppc4xx_msi.c
> @@ -0,0 +1,251 @@
> +/*
> + * Adding PCI-E MSI support for PPC4XX SoCs.
> + *
> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> + * Authors: 	Tirumala R Marri <tmarri@apm.com>
> + * 		Feng Kan <fkan@apm.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */

Blank line usually here.

> +#include <linux/irq.h>
> +#include <linux/bootmem.h>
> +#include <linux/pci.h>
> +#include <linux/msi.h>
> +#include <linux/of_platform.h>
> +#include <linux/interrupt.h>
> +#include <asm/prom.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +#include <boot/dcr.h>

Using headers in boot is "interesting".

> +#include <asm/msi_bitmap.h>

You don't use this, but maybe you should.

> +#define PEIH_TERMADH    0x00
> +#define PEIH_TERMADL    0x08
> +#define PEIH_MSIED      0x10
> +#define PEIH_MSIMK      0x18
> +#define PEIH_MSIASS     0x20
> +#define PEIH_FLUSH0     0x30
> +#define PEIH_FLUSH1     0x38
> +#define PEIH_CNTRST     0x48
> +
> +#define  UPPER_4BITS_OF36BIT 32
> +#define  LOWER_32BITS_OF36BIT 0xFFFFFFFF

These are badly named IMHO, it's not really clear that the first is a
shift and the second is a mask. I'd just get rid of them, everyone will
know what the code is doing.

> +struct ppc4xx_msi {
> +	u32 msi_addr_lo;
> +	u32 msi_addr_hi;
> +	void __iomem *msi_regs;
> +	u32 feature;
             ^
Unused AFAICS.

> +};
> +
> +static struct ppc4xx_msi *ppc4xx_msi;
> +struct ppc4xx_msi_feature {
> +	u32 ppc4xx_pic_ip;
> +	u32 msiir_offset;
> +};
> +
> +static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> +	struct msi_desc *entry;
> +	unsigned int virq = 0;

Don't need = 0.

> +	struct msi_msg msg;
> +	struct ppc4xx_msi *msi_data = ppc4xx_msi;

Just use the global.

> +	static int int_no = 0;	/* To remember last used interrupt */

This is a worry. There is nothing AFAIK to stop two drivers (eg. network
& scsi) calling into here at the same time, which could lead to
corrupting int_no. If you just want a global counter you need a lock.

But, AFAICS this is broken anyway. You never free the interrupt numbers,
so you're going to run out. Some of your device tree entries only have 3
(!!), so ifup/ifdown x 3 will exhaust the supply, won't it?

I realise I never replied to your mail the other week about the bitmap
code, so perhaps it's my fault :)

> +	struct device_node *msi_dev = NULL;
> +	const u32 *count;
> +
> +	msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
> +	if (msi_dev)
> +		return -ENODEV;
> +
>+
> +	count = of_get_property(msi_dev, "interrupt-count", NULL);
> +	if (!count) {
> +		dev_err(&dev->dev, "no interrupts property found \n");
> +		return -ENODEV;
> +	}

You should grab this at probe time and store it in ppc4xx_msi to save
yourself parsing it over and over.

> +	if (int_no > *count)
> +		return -EINVAL;
> +
> +	list_for_each_entry(entry, &dev->msi_list, list) {
> +		virq = irq_of_parse_and_map(msi_dev, int_no);
> +		printk("virq = 0x%x\n", virq);

Either turn into a pr_debug() or remove.

> +		if (virq == NO_IRQ) {
> +			dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
> +			return -EINVAL;
> +		} else
> +			set_irq_data(virq, (void *)int_no);

Needn't be in the else block given the code flow. And why do you do
this?

> +		dev_dbg(&dev->dev, "%s: virq = %d \n", __func__, virq);
> +
> +		/* Setup msi address space */
> +		msg.address_hi = msi_data->msi_addr_hi;
> +		msg.address_lo = msi_data->msi_addr_lo;
> +
> +		set_irq_msi(virq, entry);
> +		msg.data = int_no;
> +		int_no++;
> +		write_msi_msg(virq, &msg);
> +	}
> +
> +	return 0;
> +}
> +
> +void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +	struct msi_desc *entry;
> +
> +	dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");
> +
> +	list_for_each_entry(entry, &dev->msi_list, list) {
> +		if (entry->irq == NO_IRQ)
> +			continue;
> +		set_irq_msi(entry->irq, NULL);
> +		irq_dispose_mapping(entry->irq);

No free of int_no?!

> +	}
> +
> +	return;
> +}
> +
> +static int ppc4xx_msi_check_device(struct pci_dev *pdev, int nvec, int type)
> +{
> +	dev_dbg(&pdev->dev, "PCIE-MSI:%s called. vec %x type %d\n",
> +		__func__, nvec, type);

No constraints at all? What about MSI-X ?

> +	return 0;
> +}
> +
> +static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
> +				 struct resource res, struct ppc4xx_msi *msi)
> +{
> +	const u32 *msi_data;
> +	const u32 *msi_mask;
> +	const u32 *sdr_addr;
> +	int rc = 0;
> +	dma_addr_t msi_phys;
> +	void *msi_virt;
> +
> +	sdr_addr = of_get_property(dev->dev.of_node, "sdr-base", NULL);
> +	if (!sdr_addr)
> +		return -1;
> +
> +	SDR0_WRITE(sdr_addr, (u64)res.start >> UPPER_4BITS_OF36BIT);	/*HIGH addr */
> +	SDR0_WRITE(sdr_addr + 1, res.start & LOWER_32BITS_OF36BIT);	/* Low addr */
> +
> +	msi->msi_regs = ioremap((u64) res.start, res.end - res.start + 1);

You should be able to just use of_iomap() here.

> +	if (!msi->msi_regs) {
> +		dev_err(&dev->dev, "ioremap problem failed\n");
> +		return ENOMEM;
> +	}
> +	dev_dbg(&dev->dev, "PCIE-MSI: msi register mapped 0x%x 0x%x\n",
> +		(u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
> +
> +	msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
> +	msi->msi_addr_hi = 0x0;
> +	msi->msi_addr_lo = (u32) msi_phys;
> +	dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x \n", msi->msi_addr_lo);

So your MSI is a write to just some arbitrary address?

> +	/* Progam the Interrupt handler Termination addr registers */
> +	out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
> +	out_be32(msi->msi_regs + PEIH_TERMADL, msi->msi_addr_lo);

And the hardware detects it by catching writes to that address? But the
write still lands?

> +	msi_data = of_get_property(dev->dev.of_node, "msi-data", NULL);
> +	if (!msi_data) {
> +		rc = -1;
> +		goto error_out;
> +	}

Never used?

> +	msi_mask = of_get_property(dev->dev.of_node, "msi-mask", NULL);
> +	if (!msi_mask) {
> +		rc = -1;
> +		goto error_out;
> +	}
> +
> +	/* Program MSI Expected data and Mask bits */
> +	out_be32(msi->msi_regs + PEIH_MSIED, 0);
> +	out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
> +
> +	return 0;
> +      error_out:

Goto label should start in column 0.

> +	iounmap(msi->msi_regs);

You don't cleanup/undo any of the rest though? Ideally you'd structure
the routine so that you don't touch the hardware until you know you
can't fail.

> +	return rc;
> +}
> +static int __devinit ppc4xx_msi_probe(struct platform_device *dev,
> +				      const struct of_device_id *match)
> +{
> +	struct ppc4xx_msi *msi;
> +	struct resource res;
> +	int err = 0;
> +
> +	dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
> +
> +	msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
> +	if (!msi) {
> +		dev_err(&dev->dev, "No memory for MSI structure\n");
> +		err = -ENOMEM;
> +		goto error_out;
> +	}
> +	/* Get MSI ranges */
> +	err = of_address_to_resource(dev->dev.of_node, 0, &res);
> +	if (err) {
> +		dev_err(&dev->dev, "%s resource error!\n",
> +			dev->dev.of_node->full_name);
> +		goto error_out;
> +	}

Just use of_iomap().

> +	if (ppc4xx_setup_pcieh_hw(dev, res, msi))
> +		goto error_out;
> +
> +	ppc4xx_msi = msi;

You know there's only ever one in a system?

> +	WARN_ON(ppc_md.setup_msi_irqs);
> +	ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
> +	ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
> +	ppc_md.msi_check_device = ppc4xx_msi_check_device;

Don't bother setting check if yours does nothing.

> +	return 0;
> +
> +      error_out:
> +	kfree(msi);
> +	return err;
> +}

Blank line.

> +static const struct ppc4xx_msi_feature ppc4xx_msi_feature = {
> +	.ppc4xx_pic_ip = 0,
> +	.msiir_offset = 0x140,
> +};

This looks to be unused?

> +static const struct of_device_id ppc4xx_msi_ids[] = {
> +	{
> +	 .compatible = "amcc,ppc4xx-msi",
> +	 .data = (void *)&ppc4xx_msi_feature,

I know it's "used" here, but I don't see where you use that.

> +	 },
> +	{}
> +};
> +
> +static struct of_platform_driver ppc4xx_msi_driver = {
> +	.driver = {
> +		   .name = "ppc4xx-msi",
> +		   .owner = THIS_MODULE,
> +		   .of_match_table = ppc4xx_msi_ids,
> +		   },
> +	.probe = ppc4xx_msi_probe,
> +};
> +
> +static __init int ppc4xx_msi_init(void)
> +{
> +	return of_register_platform_driver(&ppc4xx_msi_driver);
> +}
> +
> +subsys_initcall(ppc4xx_msi_init);



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* [PATCH 4/4][v2] rapidio, powerpc/85xx: Error interrupt handler for sRIO.
From: Shaohui Xie @ 2010-11-03  9:37 UTC (permalink / raw)
  To: akpm; +Cc: Shaohui Xie, linuxppc-dev, Kumar Gala, linux-kernel,
	Alexandre Bounine

The sRIO controller reports errors to the core with one signal, it uses
register EPWISR to provides the core quick access to where the error occurred.
The EPWISR indicates that there are 4 interrupts sources, port1, port2, message
unit and port write receive, but the sRIO driver does not support port2
for now, still the handler takes care of port2.
Currently the handler only clear error status without any recovery.

Signed-off-by: Shaohui Xie <b21989@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
---
 arch/powerpc/sysdev/fsl_rio.c |   86 +++++++++++++++++++++++++++++++++++++---
 1 files changed, 79 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index a9bc1e8..8de86a8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -10,7 +10,7 @@
  * - Added Port-Write message handling
  * - Added Machine Check exception handling
  *
- * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Copyright (C) 2007, 2008, 2010 Freescale Semiconductor, Inc.
  * Zhang Wei <wei.zhang@freescale.com>
  *
  * Copyright 2005 MontaVista Software, Inc.
@@ -47,10 +47,36 @@
 #define IRQ_RIO_RX(m)		(((struct rio_priv *)(m->priv))->rxirq)
 #define IRQ_RIO_PW(m)		(((struct rio_priv *)(m->priv))->pwirq)
 
+/* EPWISR Error match value */
+#define EPWISR_ERR_PINT1	0x80000000
+#define EPWISR_ERR_PINT2	0x40000000
+#define EPWISR_ERR_MU		0x2
+#define EPWISR_ERR_PW		0x1
+
+#define IPWMR_CLEAR_QUEUE      0x00000002
+#define IPWSR_CLEAR		0x98
+#define OMSR_CLEAR		0x1cb3
+#define IMSR_CLEAR		0x491
+#define IDSR_CLEAR		0x91
+#define ODSR_CLEAR		0x1c00
+#define LTLEECSR_ENABLE_ALL	0xFFC000FC
+#define ESCSR_CLEAR		0x07120204
+
+#define RIO_EDCSR		0x0640
+#define PORT2_RIO_EDCSR	0x0680
+#define RIO_IECSR		0x10130
+#define PORT2_RIO_IECSR	0x101B0
+#define RIO_IM0SR		0x13064
+#define RIO_IM1SR		0x13164
+#define RIO_OM0SR		0x13004
+#define RIO_OM1SR		0x13104
+
+#define RIO_EPWISR_OFFSET	0x10010
 #define RIO_ATMU_REGS_OFFSET	0x10c00
 #define RIO_P_MSG_REGS_OFFSET	0x11000
 #define RIO_S_MSG_REGS_OFFSET	0x13000
 #define RIO_ESCSR		0x158
+#define PORT2_RIO_ESCSR	0x178
 #define RIO_CCSR		0x15c
 #define RIO_LTLEDCSR		0x0608
 #define  RIO_LTLEDCSR_IER	0x80000000
@@ -1003,6 +1029,40 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
 	return IRQ_HANDLED;
 }
 
+static void port_error_handler(struct rio_mport *port, int offset)
+{
+	/*XXX: Error recovery is not implemented, we just clear errors */
+	out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+	if (offset == 0) {
+		out_be32((u32 *)(rio_regs_win + RIO_EDCSR), 0);
+		out_be32((u32 *)(rio_regs_win + RIO_IECSR), 0);
+		out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
+	} else {
+		out_be32((u32 *)(rio_regs_win + PORT2_RIO_EDCSR), 0);
+		out_be32((u32 *)(rio_regs_win + PORT2_RIO_IECSR), 0);
+		out_be32((u32 *)(rio_regs_win + PORT2_RIO_ESCSR), ESCSR_CLEAR);
+	}
+}
+
+static void msg_unit_error_handler(struct rio_mport *port)
+{
+	struct rio_priv *priv = port->priv;
+
+	/*XXX: Error recovery is not implemented, we just clear errors */
+	out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+	out_be32((u32 *)(rio_regs_win + RIO_IM0SR), IMSR_CLEAR);
+	out_be32((u32 *)(rio_regs_win + RIO_IM1SR), IMSR_CLEAR);
+	out_be32((u32 *)(rio_regs_win + RIO_OM0SR), OMSR_CLEAR);
+	out_be32((u32 *)(rio_regs_win + RIO_OM1SR), OMSR_CLEAR);
+
+	out_be32(&priv->msg_regs->odsr, ODSR_CLEAR);
+	out_be32(&priv->msg_regs->dsr, IDSR_CLEAR);
+
+	out_be32(&priv->msg_regs->pwsr, IPWSR_CLEAR);
+}
+
 /**
  * fsl_rio_doorbell_init - MPC85xx doorbell interface init
  * @mport: Master port implementing the inbound doorbell unit
@@ -1082,14 +1142,24 @@ fsl_rio_port_write_handler(int irq, void *dev_instance)
 	ipwsr = in_be32(&priv->msg_regs->pwsr);
 
 	epwisr = in_be32(priv->regs_win + RIO_EPWISR);
-	if (epwisr & 0x80000000) {
+	if (epwisr & EPWISR_ERR_PINT1) {
 		tmp = in_be32(priv->regs_win + RIO_LTLEDCSR);
 		pr_info("RIO_LTLEDCSR = 0x%x\n", tmp);
-		out_be32(priv->regs_win + RIO_LTLEDCSR, 0);
+		port_error_handler(port, 0);
+	}
+
+	if (epwisr & EPWISR_ERR_PINT2) {
+		pr_info("RIO: port2 error\n");
+		port_error_handler(port, 1);
+	}
+
+	if (epwisr & EPWISR_ERR_MU) {
+		pr_info("RIO: message unit error\n");
+		msg_unit_error_handler(port);
 	}
 
-	if (!(epwisr & 0x00000001))
-		return IRQ_HANDLED;
+	if (!(epwisr & EPWISR_ERR_PW))
+		return IRQ_NONE;
 
 #ifdef DEBUG_PW
 	pr_debug("PW Int->IPWMR: 0x%08x IPWSR: 0x%08x (", ipwmr, ipwsr);
@@ -1249,12 +1319,14 @@ static int fsl_rio_port_write_init(struct rio_mport *mport)
 
 
 	/* Hook up port-write handler */
-	rc = request_irq(IRQ_RIO_PW(mport), fsl_rio_port_write_handler, 0,
-			 "port-write", (void *)mport);
+	rc = request_irq(IRQ_RIO_PW(mport), fsl_rio_port_write_handler,
+			IRQF_SHARED, "port-write", (void *)mport);
 	if (rc < 0) {
 		pr_err("MPC85xx RIO: unable to request inbound doorbell irq");
 		goto err_out;
 	}
+	/* Enable Error Interrupt */
+	out_be32((u32 *)(rio_regs_win + RIO_LTLEECSR), LTLEECSR_ENABLE_ALL);
 
 	INIT_WORK(&priv->pw_work, fsl_pw_dpc);
 	spin_lock_init(&priv->pw_fifo_lock);
-- 
1.6.4

^ permalink raw reply related

* [PATCH 3/4][v2] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
From: Shaohui Xie @ 2010-11-03  9:36 UTC (permalink / raw)
  To: akpm; +Cc: Shaohui Xie, linuxppc-dev, Kumar Gala, linux-kernel,
	Alexandre Bounine

Signed-off-by: Shaohui Xie <b21989@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
---
 arch/powerpc/kernel/traps.c   |   14 +++++++++++++-
 arch/powerpc/sysdev/fsl_rio.c |   15 +++------------
 include/linux/rio.h           |    1 +
 3 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..2a5fb9d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
 #endif
 #include <asm/kexec.h>
 #include <asm/ppc-opcode.h>
+#include <linux/rio.h>
 
 #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
 int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -500,6 +501,13 @@ int machine_check_e500mc(struct pt_regs *regs)
 		       reason & MCSR_MEA ? "Effective" : "Physical", addr);
 	}
 
+	if (reason & MCSR_BUS_RBERR) {
+		printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+		recoverable = fsl_rio_mcheck_exception(regs);
+#endif
+	}
+
 	mtspr(SPRN_MCSR, mcsr);
 	return mfspr(SPRN_MCSR) == 0 && recoverable;
 }
@@ -527,8 +535,12 @@ int machine_check_e500(struct pt_regs *regs)
 		printk("Bus - Write Address Error\n");
 	if (reason & MCSR_BUS_IBERR)
 		printk("Bus - Instruction Data Error\n");
-	if (reason & MCSR_BUS_RBERR)
+	if (reason & MCSR_BUS_RBERR) {
 		printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+		fsl_rio_mcheck_exception(regs);
+#endif
+	}
 	if (reason & MCSR_BUS_WBERR)
 		printk("Bus - Read Data Bus Error\n");
 	if (reason & MCSR_BUS_IPERR)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 1143c93..a9bc1e8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -256,9 +256,7 @@ struct rio_priv {
 static void __iomem *rio_regs_win;
 
 #ifdef CONFIG_E500
-static int (*saved_mcheck_exception)(struct pt_regs *regs);
-
-static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+int fsl_rio_mcheck_exception(struct pt_regs *regs)
 {
 	const struct exception_table_entry *entry = NULL;
 	unsigned long reason = mfspr(SPRN_MCSR);
@@ -280,11 +278,9 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
 		}
 	}
 
-	if (saved_mcheck_exception)
-		return saved_mcheck_exception(regs);
-	else
-		return cur_cpu_spec->machine_check(regs);
+	return 0;
 }
+EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
 #endif
 
 /**
@@ -1534,11 +1530,6 @@ int fsl_rio_setup(struct platform_device *dev)
 	fsl_rio_doorbell_init(port);
 	fsl_rio_port_write_init(port);
 
-#ifdef CONFIG_E500
-	saved_mcheck_exception = ppc_md.machine_check_exception;
-	ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
-#endif
-
 	return 0;
 err:
 	iounmap(priv->regs_win);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index bd6eb0e..685b18f 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -365,5 +365,6 @@ extern int rio_open_inb_mbox(struct rio_mport *, void *, int, int);
 extern void rio_close_inb_mbox(struct rio_mport *, int);
 extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
 extern void rio_close_outb_mbox(struct rio_mport *, int);
+extern int fsl_rio_mcheck_exception(struct pt_regs *);
 
 #endif				/* LINUX_RIO_H */
-- 
1.6.4

^ permalink raw reply related

* [PATCH 2/4][v2] fsl_rio: fix non-standard HID1 register access
From: Shaohui Xie @ 2010-11-03  9:36 UTC (permalink / raw)
  To: akpm; +Cc: Shaohui Xie, linuxppc-dev, Kumar Gala, linux-kernel,
	Alexandre Bounine

Signed-off-by: Shaohui Xie <b21989@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S |    6 ++++++
 arch/powerpc/sysdev/fsl_rio.c             |    2 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 0adb50a..8fd5bc6 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -63,6 +63,12 @@ _GLOBAL(__setup_cpu_e500v2)
 	bl	__e500_icache_setup
 	bl	__e500_dcache_setup
 	bl	__setup_e500_ivors
+#ifdef CONFIG_RAPIDIO
+	/* Ensure that RFXE is set */
+	mfspr	r3,SPRN_HID1
+	oris	r3,r3,HID1_RFXE@h
+	mtspr	SPRN_HID1,r3
+#endif
 	mtlr	r4
 	blr
 _GLOBAL(__setup_cpu_e500mc)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 4127636..1143c93 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1538,8 +1538,6 @@ int fsl_rio_setup(struct platform_device *dev)
 	saved_mcheck_exception = ppc_md.machine_check_exception;
 	ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
 #endif
-	/* Ensure that RFXE is set */
-	mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x20000));
 
 	return 0;
 err:
-- 
1.6.4

^ permalink raw reply related

* [PATCH 1/4][v2] powerpc: add e500 HID1 bit definition
From: Shaohui Xie @ 2010-11-03  9:35 UTC (permalink / raw)
  To: akpm; +Cc: Shaohui Xie, linuxppc-dev, Kumar Gala, linux-kernel,
	Alexandre Bounine

From: Li Yang <leoli@freescale.com>

Also make 74xx HID1 definition conditional.

Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Shaohui Xie <b21989@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
---
These patches have been send for almost one week, and has no feedback.

 arch/powerpc/include/asm/reg.h       |    2 ++
 arch/powerpc/include/asm/reg_booke.h |   14 ++++++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index ff0005e..125fc1a 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -283,6 +283,7 @@
 #define HID0_NOPTI	(1<<0)		/* No-op dcbt and dcbst instr. */
 
 #define SPRN_HID1	0x3F1		/* Hardware Implementation Register 1 */
+#ifdef CONFIG_6xx
 #define HID1_EMCP	(1<<31)		/* 7450 Machine Check Pin Enable */
 #define HID1_DFS	(1<<22)		/* 7447A Dynamic Frequency Scaling */
 #define HID1_PC0	(1<<16)		/* 7450 PLL_CFG[0] */
@@ -292,6 +293,7 @@
 #define HID1_SYNCBE	(1<<11)		/* 7450 ABE for sync, eieio */
 #define HID1_ABE	(1<<10)		/* 7450 Address Broadcast Enable */
 #define HID1_PS		(1<<16)		/* 750FX PLL selection */
+#endif
 #define SPRN_HID2	0x3F8		/* Hardware Implementation Register 2 */
 #define SPRN_HID2_GEKKO	0x398		/* Gekko HID2 Register */
 #define SPRN_IABR	0x3F2	/* Instruction Address Breakpoint Register */
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 667a498..dc6adff 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -246,6 +246,20 @@
 					store or cache line push */
 #endif
 
+/* Bit definitions for the HID1 */
+#ifdef CONFIG_E500
+/* e500v1/v2 */
+#define HID1_PLL_CFG_MASK 0xfc000000	/* PLL_CFG input pins */
+#define HID1_RFXE	0x00020000	/* Read fault exception enable */
+#define HID1_R1DPE	0x00008000	/* R1 data bus parity enable */
+#define HID1_R2DPE	0x00004000	/* R2 data bus parity enable */
+#define HID1_ASTME	0x00002000	/* Address bus streaming mode enable */
+#define HID1_ABE	0x00001000	/* Address broadcast enable */
+#define HID1_MPXTT	0x00000400	/* MPX re-map transfer type */
+#define HID1_ATS	0x00000080	/* Atomic status */
+#define HID1_MID_MASK	0x0000000f	/* MID input pins */
+#endif
+
 /* Bit definitions for the DBSR. */
 /*
  * DBSR bits which have conflicting definitions on true Book E versus IBM 40x.
-- 
1.6.4

^ permalink raw reply related

* unsubscribe
From: Roberto Mantovani @ 2010-11-03  8:21 UTC (permalink / raw)
  To: linuxppc-dev@lists.ozlabs.org



^ permalink raw reply

* Re: Problem with Infiniband adapter on IBM p550
From: Patrick Finnegan @ 2010-11-03  3:15 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1286516749.2463.408.camel@pasglop>

On Friday, October 08, 2010, Benjamin Herrenschmidt wrote:
> > Ok, so from what I can tell, the driver is unhappy because either
> > BAR 0 hasn't been assigned a memory resource or the size doesn't
> > match what the driver expects.
> 
> Ooops, accidentally sent too quickly...
> 
> >From your OF log I see:
> reg                     00c10000 00000000 00000000  00000000 00000000
>                         03c10010 00000000 00000000  00000000 00100000
>                         43c10018 00000000 00000000  00000000 00800000
>                         43c10020 00000000 00000000  00000000 08000000
> assigned-addresses      83c10020 00000000 e8000000  00000000 08000000
> 
> Now, I think this is the problem.
> 
> The "assigned-addresses" property seems to indicate that the firmware
> only assigned BAR 4 and didn't assign anything to the other ones.
> 
> I don't know why, but it definitely looks like a firmware bug to me.
> On those machines, PCI resource assignment is under hypervisor
> control and so Linux cannot re-assign missing resources itself.
> 
> I'll see if I can find a FW person to shed some light on this.
> 
> Can you provide me (privately maybe) with the FW version on the
> machine ?

Ben,

Have you found out anything more on this (firmware) bug?

Pat
-- 
Purdue University Research Computing ---  http://www.rcac.purdue.edu/
The Computer Refuge                  ---  http://computer-refuge.org

^ permalink raw reply

* Gianfar TCP checksumming broken in 2.6.35+
From: Matthew L. Creech @ 2010-11-02 22:29 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: davem

Hi,

An upgrade from 2.6.34 to 2.6.35 caused networking to stop working on
my MPC8313-based board.  It turned out that TCP checksums were
invalid, so I dug through the .35 changelog to try and isolate the
reason.  The change "tcp: Set CHECKSUM_UNNECESSARY in
tcp_init_nondata_skb" seems to be the specific one that causes
breakage - if I revert this one-liner, things work again:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e8e18ef52e7dd1af0a3bd1f7d990a1d0b249586

However, I also noticed that one of my boards was broken while a newer
prototype (which is very similar, hardware-wise) was not.  It turns
out they're using 2 different revisions of silicon, so the broken
board still has a 1.0 version microcontroller.

Therefore I'm guessing (just a hunch) that the root cause of the
problem is MPC8313 errata eTSEC12:

========
eTSEC12: Tx IP and TCP/UDP Checksum Generation not supported for some Tx FCB
         offsets
Description:
	If the Tx FCB (Frame Control Block) 32-byte offset is 0x19, 0x1A, 0x1B,
	0x1C, 0x1D, 0x1E or 0x1F, IP and TCP/UDP header checksum generation do
	not function properly. The checksum value may be inserted in the wrong
	location or not inserted at all.
	IP and TCP/UDP header checksum generation is not supported in LINUX
	and other systems in which headers are prepended to pre-aligned packet
	data, or where the alignment of the Tx FCB cannot be controlled.
	This behavior applies to pseudo-header checksum insertion as well as
	checksum generation.
Workaround:
	Align Tx FCB to a 16 or 32-byte boundary.
	If the alignment of TxFCB is not controllable, set TCTRL[TUCSEN]=0 and
	TCTRL[IPCSEN]=0 to disable IP and TCP/UDP header checksum generation.
Fix plan:
	Fixed in Rev 2.0
========

This appears to have been working previously, but doesn't work any
more.  I'm not familiar enough with Dave's checksum/sk_buff changes to
figure out whether this errata is to blame, though, or how I should
fix it if it is.  Presumably there's some alignment magic needed in
the sk_buff or gfar_add_fcb() to make sure that the microcontroller is
happy with the FCB offset?

Any tip on how I can solve this, or at least verify that this errata
is at fault?  Thanks in advance

-- 
Matthew L. Creech

^ permalink raw reply

* RE: RapidIO: git tree for tracking latest
From: Bounine, Alexandre @ 2010-11-02 12:30 UTC (permalink / raw)
  To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTi=OCEKVAh1gDYvkeoeSAbiZqyArO6+jdvPuofN6@mail.gmail.com>

Thomas Taranowski wrote:
> Is there an official maintainer's repository for RapidIO related
> changes to I should be tracking?  I've been tracking Kumar's git
> repository (off kernel.org), but I'm not clear on who the keeper of
> this stuff is.

Currently Andrew Morton's -mm tree has most of RapidIO patches (some of
them moved to 2.6.37-rc1 now). RapidIO patches usually appear in two
mailing lists LKML an this one.
  =20
Alex.
=20

^ permalink raw reply

* old MESH SCSI driver
From: kevin diggs @ 2010-11-02  6:14 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

I am trying to get 2.6.36 running on an old PowerMac 8600. It can't
seem to find the root device. There are some messages about the disks
on the bus. But they don't look quite right. It is currently running
2.6.28.

Any suggestions?

Thanks!

kevin

^ permalink raw reply

* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-02  3:20 UTC (permalink / raw)
  To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288662607.366.249.camel@Joe-Laptop>

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Mon, 2010-11-01 at 18:50 -0700, Joe Perches wrote:
> On Tue, 2010-11-02 at 11:26 +1100, Michael Ellerman wrote:
> > On Mon, 2010-11-01 at 07:41 -0700, Joe Perches wrote:
> > > Pretty much.  Format coalescing is generally preferred for grep.
> > Really? Grep doesn't work anyway because you have format specifiers, and
> > although you can try and guess them .. good luck, 0x%lx, or 0x%llx, or
> > %#lx or ..
> 
> grep "Breakpoint at .* will be disabled"

Sure. For more mundane and repeated error strings the .* can be a pain
in that it matches too much.

But whatever, I'll start writing my code with uncollapsed string
formats, and wait for the torrent of make-it-80-columns patches :)

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
From: Chris Metcalf @ 2010-11-02  2:21 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1288658108.16790.13.camel@concordia>

On 11/1/2010 8:35 PM, Michael Ellerman wrote:
> On Wed, 2010-10-27 at 12:54 -0400, Chris Metcalf wrote:
>> The tile architecture uses this framework for our serial console,
>> and our users complain that the delay of up to two seconds feels like
>> the machine has gone non-responsive and is disturbing.  By contrast,
>> a delay of up to half a second feels like just the normal sort of
>> delay caused by swapping, network lag, etc. and is not noticeable.
>> The overhead is obviously not much greater.
> It's 4 times greater.
>
> We picked 2 seconds because it gave a reasonable trade off between
> responsiveness and load. I'm not convinced that half a second is a
> better number.

Perhaps the tradeoff should be tunable, then?  I think on our architecture
we're willing to pay a higher cost on the core running this task, since we
have many cores; we often have a core that mostly just runs miscellaneous
Linux administrative tasks anyway, so adding a bit more overhead there is
not significant for us.

This issue has caused multiple reports of unresponsiveness from our users,
so I'd be interested in finding a way to strike a balance.  We could use a
config option defaulting to 2 seconds (for example), or something more
dynamic (probably unnecessary).

Let me know your preference, if this sounds plausible, and I'll write up a
proposed patch.  Thanks.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

^ permalink raw reply

* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Joe Perches @ 2010-11-02  1:50 UTC (permalink / raw)
  To: michael; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288657560.16790.8.camel@concordia>

On Tue, 2010-11-02 at 11:26 +1100, Michael Ellerman wrote:
> On Mon, 2010-11-01 at 07:41 -0700, Joe Perches wrote:
> > Pretty much.  Format coalescing is generally preferred for grep.
> Really? Grep doesn't work anyway because you have format specifiers, and
> although you can try and guess them .. good luck, 0x%lx, or 0x%llx, or
> %#lx or ..

grep "Breakpoint at .* will be disabled"

^ permalink raw reply

* Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
From: Michael Ellerman @ 2010-11-02  0:35 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <201010271659.o9RGxrMc009847@farm-0002.internal.tilera.com>

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Wed, 2010-10-27 at 12:54 -0400, Chris Metcalf wrote:
> The tile architecture uses this framework for our serial console,
> and our users complain that the delay of up to two seconds feels like
> the machine has gone non-responsive and is disturbing.  By contrast,
> a delay of up to half a second feels like just the normal sort of
> delay caused by swapping, network lag, etc. and is not noticeable.
> The overhead is obviously not much greater.

It's 4 times greater.

We picked 2 seconds because it gave a reasonable trade off between
responsiveness and load. I'm not convinced that half a second is a
better number.

cheers


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: [PATCH v3] add icswx support
From: Michael Neuling @ 2010-11-02  0:27 UTC (permalink / raw)
  To: Tseng-Hui (Frank) Lin; +Cc: tsenglin, linuxppc-dev
In-Reply-To: <1287547340.14049.25.camel@flin.austin.ibm.com>

<snip>
> +
> +#ifdef CONFIG_40x
> +#define SPRN_PID	0x3B1	/* Process ID */
> +#else
> +#define SPRN_PID	0x030	/* Process ID */
> +#ifdef CONFIG_BOOKE
> +#define SPRN_PID0	SPRN_PID/* Process ID Register 0 */
> +#endif
> +#endif
> +
>  #define SPRN_CTR	0x009	/* Count Register */
>  #define SPRN_DSCR	0x11
> +#define SPRN_ACOP	0x1F	/* Available Coprocessor Register */
>  #define SPRN_CTRLF	0x088
>  #define SPRN_CTRLT	0x098
>  #define   CTRL_CT	0xc0000000	/* current thread */
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index 667a498..5b0c781 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -150,8 +150,6 @@
>   * or IBM 40x.
>   */
>  #ifdef CONFIG_BOOKE
> -#define SPRN_PID	0x030	/* Process ID */
> -#define SPRN_PID0	SPRN_PID/* Process ID Register 0 */
>  #define SPRN_CSRR0	0x03A	/* Critical Save and Restore Register 0 */
>  #define SPRN_CSRR1	0x03B	/* Critical Save and Restore Register 1 */
>  #define SPRN_DEAR	0x03D	/* Data Error Address Register */
> @@ -168,7 +166,6 @@
>  #define SPRN_TCR	0x154	/* Timer Control Register */
>  #endif /* Book E */
>  #ifdef CONFIG_40x
> -#define SPRN_PID	0x3B1	/* Process ID */
>  #define SPRN_DBCR1	0x3BD	/* Debug Control Register 1 */		
>  #define SPRN_ESR	0x3D4	/* Exception Syndrome Register */
>  #define SPRN_DEAR	0x3D5	/* Data Error Address Register */


These PID changes should be in a separate patch.  They should be just a
cleanup that this patch can depend on.

Mikey

^ permalink raw reply

* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-02  0:26 UTC (permalink / raw)
  To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288622509.366.237.camel@Joe-Laptop>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Mon, 2010-11-01 at 07:41 -0700, Joe Perches wrote:
> On Mon, 2010-11-01 at 22:02 +1100, Michael Ellerman wrote:
> > On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> > > Coalesce long formats.
> > > Align arguments.
> > > Add missing newlines.
> > > 
> > > Signed-off-by: Joe Perches <joe@perches.com>
> > > ---
> > >  arch/powerpc/kernel/hw_breakpoint.c |    4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> > > index 5ecd040..d7343a7 100644
> > > --- a/arch/powerpc/kernel/hw_breakpoint.c
> > > +++ b/arch/powerpc/kernel/hw_breakpoint.c
> > > @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> > >  	 * message to let the user know about it.
> > >  	 */
> > >  	if (!stepped) {
> > > -		WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> > > -			"0x%lx will be disabled.", info->address);
> > > +		WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> > > +		     info->address);
> > 
> > That appears to have done nothing other than turn a short line into one
> > that is now > 80 columns.
> 
> Added '\n'.

Right.

> The series was done for a few reasons:
> 
> o to add missing newlines at the end of messages as was done here
> o to convert a couple of misuses of WARN(msg) to WARN(1, msg)
> o to remove KERN_ prefixes from WARN(test, KERN_<level> msg)

All fair enough.

> >  Is that the latest fad?
> 
> Pretty much.  Format coalescing is generally preferred for grep.

Really? Grep doesn't work anyway because you have format specifiers, and
although you can try and guess them .. good luck, 0x%lx, or 0x%llx, or
%#lx or ..

cheers



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox