headers
Peter Pan | 1 Apr 2010 02:56
Picon

Re: I can not get my MII working on MPC8247 with Linux 2.6.32.6

Yes, the PHY address is correct, I've checked the schematics, and
2.6.22 is also using this PHY address.
The different between 2.6.22 and 2.6.32.6 is that:
In 2.6.22, we use arch/ppc/8260_io/fcc_enet.c as the driver. IMMR
address 0xf0000000 is directly used.
In 2.6.32.6, cpm2-fcc-enet driver is used. In that driver, the
register address is ioremaped and used. The others are the same.
I've tried to use the dir and data register address directly in
mii-bitbang.c, but that leads to kernel oops.
I've wrote a low level gpio driver for our processor MPC8247, and I
used that for our external hardware watchdog, it works fine. Then I
use the low level driver in the mii-bitbang.c, it still works
incorrect, all I get from MDIO is 1.
I'm really confused.

2010/3/31 Scott Wood <scottwood <at> freescale.com>:
> Peter Pan wrote:
>>
>> Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based
>> board. Everything is fine out except my ethernets. I uses
>> cpm2-scc-enet and cpm2-fcc-enet drivers.
>> My ethernet works fine in U-Boot with the same setting, and our
>> previous Linux 2.6.22 is also working, so there should be nothing
>> wrong with the hardware.
>> The boot log of the MII part is:
>>
>> CPM2 Bitbanged MII: probed
>> mdio_bus f0010d00: error probing PHY at address 0
>> mdio_bus f0010d00: error probing PHY at address 1
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
gshan | 1 Apr 2010 03:59
Favicon

spin_lock_irqsave and multi-core

I got a question when reading source code. Hope somebody can give me the 
answer.
On multi-core system, spin_lock_irqsave() can stop all CPU cores 
receiving interrupts?
If the answer is no, what we can do to disable external interrupt for 
all CPU cores?

Thanks,
Gavin
Permalink | Reply | 10 comments |
headers
Benjamin Herrenschmidt | 1 Apr 2010 04:39

Re: spin_lock_irqsave and multi-core

On Thu, 2010-04-01 at 09:59 +0800, gshan wrote:
> On multi-core system, spin_lock_irqsave() can stop all CPU cores 
> receiving interrupts?

No.

> If the answer is no, what we can do to disable external interrupt for 
> all CPU cores?

You don't :-)

Really, you generally don't. Why would you want to do that ?

Cheers,
Ben.
Permalink | Reply | 8 comments |
headers
Benjamin Herrenschmidt | 1 Apr 2010 04:56

Re: spin_lock_irqsave and multi-core

On Thu, 2010-04-01 at 10:41 +0800, gshan wrote:

> One of my private driver need it. I don't know how to do it.

Then your driver is most certainly doing something wrong :-) No driver
needs that. Ever.

What is it trying to do more precisely ? I might be able to explain what
the right approach is if you can tell me what the driver is trying to
disable all system IRQs for ? Keep in mind that local_irq_save() does a
lot more than just masking external interrupts from your device. It
masks them from -all- devices, including timer interrupts, perfmon
interrupts, etc... Doing so on all cores is generally a big no-no and
almost never really necessary.

Cheers,
Ben.
Permalink | Reply | 4 comments |
headers
gshan | 1 Apr 2010 04:41
Favicon

Re: spin_lock_irqsave and multi-core

Benjamin Herrenschmidt wrote:
On Thu, 2010-04-01 at 09:59 +0800, gshan wrote:
On multi-core system, spin_lock_irqsave() can stop all CPU cores receiving interrupts?
No.
Thanks a lot for your answer.
If the answer is no, what we can do to disable external interrupt for all CPU cores?
You don't :-) Really, you generally don't. Why would you want to do that ?
One of my private driver need it. I don't know how to do it.
Cheers, Ben. 

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Permalink | Reply | 6 comments |
headers
gshan | 1 Apr 2010 05:18
Favicon

Re: spin_lock_irqsave and multi-core


>
> Then your driver is most certainly doing something wrong :-) No driver
> needs that. Ever.
>
> What is it trying to do more precisely ? I might be able to explain what
> the right approach is if you can tell me what the driver is trying to
> disable all system IRQs for ? Keep in mind that local_irq_save() does a
> lot more than just masking external interrupts from your device. It
> masks them from -all- devices, including timer interrupts, perfmon
> interrupts, etc... Doing so on all cores is generally a big no-no and
> almost never really necessary.
>   
I agree with you. Actually, I can disable the individual interrupt via 
disable_irq_sync() to make sure
system cooherence. It's just my concern when reading kernel source. 
Anyway, thanks a lot
for your kindly answer.

Thanks,
Gavin
> Cheers,
> Ben.
>
>
>
Permalink | Reply | 2 comments |
headers
Benjamin Herrenschmidt | 1 Apr 2010 06:45

Re: spin_lock_irqsave and multi-core

On Thu, 2010-04-01 at 11:18 +0800, gshan wrote:
> I agree with you. Actually, I can disable the individual interrupt via
> disable_irq_sync() to make sure
> system cooherence. 

This is also a very heavy hammer and not recommended at all. In most
case, you don't need that either. Also don't forget that if your system
has shared interrupts, you'll also disable whoever else interrupt you
are sharing with. You also cannot call that within a spinlock region for
example.

You don't normally need any of that if you use spinlocks properly, but
again, without more understanding of what your driver is trying to do,
it's hard to explain properly what you should do.

Normally tho, you synchronize your interrupt handler with your other
driver parts using simply a spinlock. You take it with spin_lock/unlock
from the interrupt handler and you use spin_lock_irqsave/restore from
the non-irq path. You don't normally need more. You only need the
irqsave/restore in fact on one CPU because it's goal is purely to avoid
a spin deadlock if your interrupt happens on that same CPU at the same
time.

Only if you want to disable interrupts for an extended period of time
should you consider using disable_irq_* and even then, as I mentioned,
it has drawbacks and is generally not recommended.

Alternatively, most devices have the ability to disable interrupt
emission on the device itself using some kind of MMIO register (though
you still need to synchronize things properly in your driver as the
interrupt might have already been emitted and on its way to the
processor when you whack that register.

But again, without more detailed knowledge of what you driver is
actually doing, it's hard to give you more precise advice.

Cheers,
Ben.

> It's just my concern when reading kernel source. 
> Anyway, thanks a lot
> for your kindly answer.
> 
>
Permalink | Reply | 0 comments |
headers
Vaidyanathan Srinivasan | 1 Apr 2010 09:39
Picon

[PATCH v2 repost] powerpc: export data from new hcall H_EM_GET_PARMS

Hi Ben,

Previous post: http://patchwork.ozlabs.org/patch/47249/

I have cleaned up the code from the v1:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080630.html

Changes from v1:
* Removed redundant return statements and rearranged code

Description:

A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from the platform.  This data can be used by user space administrative
tools for better power management.

The following patch add data from this new hcall into the lparcfg
driver and exports to user space along with other existing lpar data
in /proc/powerpc/lparcfg

Please review and include in powerpc -next tree.

Thanks,
Vaidy

---
	powerpc: export data from new hcall H_EM_GET_PARMS

	Add support for H_EM_GET_PARMS hcall that will return data
	related to power modes from the platform.  Export the data
	directly to user space for administrative tools to interpret
	and use.

	cat /proc/powerpc/lparcfg will export power mode data

Signed-off-by: Vaidyanathan Srinivasan <svaidy <at> linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/hvcall.h |    1 +
 arch/powerpc/kernel/lparcfg.c     |   12 +++++++++++-
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index f027581..ebe7493 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
 <at>  <at>  -228,6 +228,7  <at>  <at> 
 #define H_JOIN			0x298
 #define H_VASI_STATE            0x2A4
 #define H_ENABLE_CRQ		0x2B0
+#define H_GET_EM_PARMS		0x2B8
 #define H_SET_MPP		0x2D0
 #define H_GET_MPP		0x2D4
 #define MAX_HCALL_OPCODE	H_GET_MPP
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d09d1c6..ff698fb 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
 <at>  <at>  -37,7 +37,7  <at>  <at> 
 #include <asm/vio.h>
 #include <asm/mmu.h>

-#define MODULE_VERS "1.8"
+#define MODULE_VERS "1.9"
 #define MODULE_NAME "lparcfg"

 /* #define LPARCFG_DEBUG */
 <at>  <at>  -486,6 +486,14  <at>  <at>  static void splpar_dispatch_data(struct seq_file *m)
 	seq_printf(m, "dispatch_dispersions=%lu\n", dispatch_dispersions);
 }

+static void parse_em_data(struct seq_file *m)
+{
+	unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+	if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+		seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
+}
+
 static int pseries_lparcfg_data(struct seq_file *m, void *v)
 {
 	int partition_potential_processors;
 <at>  <at>  -540,6 +548,8  <at>  <at>  static int pseries_lparcfg_data(struct seq_file *m, void *v)

 	seq_printf(m, "slb_size=%d\n", mmu_slb_size);

+	parse_em_data(m);
+
 	return 0;
 }
Permalink | Reply | 0 comments |
headers
Roman Fietze | 1 Apr 2010 12:04
Picon
Favicon

Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down

Hallo Wolfgang,

On Wednesday 31 March 2010 12:15:47 Wolfgang Grandegger wrote:

> I just sent out the patch.

Thanks a lot.

> Would be nice if you, or somebody else, could do some testing and
> provide some feedback.

I tested the patches with the following setup:

- DENX 2.6.33 plus NAPI patch, kernel config with and w/o NAPI enabled

- Own Icecube based board using MPC5200B

- Two different hard drives (because the Toshiba gave my headaches),
  ext3 default settings of mkfs.ext3, MWDMA2

- FPGA on LPC receiving high bandwidth MOST150 data in PIO mode (for
  the test: generating them internally), small app writing the data to
  disk. Why PIO? SCLPC FIFO gave 

- netcat receving data optionally writing the data to HD, sender is a
  Gigabit Intel NIC feeded using netcat (and /dev/zero) as well via a
  100MBit/s switch

And now the first and preliminary results of the tests (see legend and
description of the results below the table):

NAPI	MOST	HD		   load		bw	rx_irq		rfifo
------+-------+---------------+---------------+-------+---------------+-------
				nc	most
======+=======+===============+===============+=======+===============+=======

on	off	MK4036GA	93		5.15	32000-35000
		-		99		10.5	72000-74000

	on	MK4036GA	49	46	crash	15000-17500	none seen
	on	HEJ421010G9AT00	48	47		15000-17500	~100-500, recovers

------+-------+---------------+-----------------------+-------+---------------+-------

off	off	MK4036GA	90		5.15	34000-36000
		-		99		10.5	76000-77000

	on	MK4036GA	48	47	crash	17500-19000	~200, network down

Legend:
-------

MOST:		PIO mode access to FPGA receiving generated MOST150 data
		very high data rates possible
HD:		used disk type
load/nc:	load netcat, %
load/most:	load MOST receiver app, %
load/idle:	was always 0%
bw:		netcat network band width, MB/s
rx_irq:		FEX RX IRQ, rate in Hz
rfifo:		RX FIFO errors, time in between in seconds

Results:
--------

Using the MK4036GA HD always crashes IDE after a few seconds. A reboot
does not recover the disk, I always need a power cycle. That's why I
switched to a HEJ421010G9AT00.

NAPI reduces the FEC RX interrupt rate (/proc/interrupts) "somewhat".
Could not detect an increase of the maximum bandwidth, but that's not
the "problem" of NAPI.

NAPI nicely recovers more or less nicely from link down (link down to
up about 1 second), without NAPI I have to do that manually (e.g. ip
set link down/up). That's something I was looking for since the
modular PHY drivers.

Some network applications (e.g. our Car Head Unit GN Protocol Logger)
break up their connection when the link goes down (e.g. due to
internal timeouts? Probably fixable). Ssh and netcat connections stay
up.

Transferred many GiB of data to the MPC w/o any problems except those
recoverable FEC_IEVENT_RFIFO_ERRORs.

This patch really looks good to me.

I will run some additional tests e.g. with mixed RX and TX, different
and varying data rates, etc.

> FYI, I will be out of office next week.

Lucky Guy

Roman

--

-- 
Roman Fietze                Telemotive AG Büro Mühlhausen
Breitwiesen                              73347 Mühlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de
Permalink | Reply | 2 comments |
headers
Bolko Maass | 1 Apr 2010 14:56
Picon
Picon

poweroff/suspend problems on PowerMac G5

Hi everybody!

Hope this list is even the right place to bring this up, but I've exhausted everything else I could think of,
so here it goes.

The problem is that my PowerMac G5 Quad machine ("PowerMac 11,2", Gentoo, linux-2.6.34-rc2) will not
power down if suspend infrastructure (CONFIG_HIBERNATION) is in the kernel. It will stop all services
and halt, but never power down. This is when actually trying to suspend as well as when just trying to shut
down the machine. Reboot works fine, so I suspect that the kernel doesn't actually crash.

At least one other person on the #gentoo-powerpc channel on freenode has reported the same problem and that
unsetting CONFIG_HIBERNATION will fix it.

Please advise on how to debug something like this, as this is really beyond my expertise.

Thanks!
Permalink | Reply | 6 comments |

Gmane