On Wed, 2013-05-29 at 22:47 -0700, Hugh Dickins wrote:
Running my favourite swapping load (repeated make -j20 kernel builds
in tmpfs in parallel with repeated make -j20 kernel builds in ext4 on
loop on tmpfs file, all limited by mem=700M and swap 1.5G) on 3.10-rc
on PowerMac G5, the test dies
On Thu, 2013-05-30 at 15:07 +0800, liguang wrote:
orderly_poweroff is expecting a bool parameter, so
use 'ture' instead '1'
[]
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
[]
@@ -162,7 +162,7 @@ void rtas_parse_epow_errlog(struct rtas_error_log
hi, tiejun.chen:
Thanks for replying.
I tried to use ioremap too, but it doesn't work. The ioport_map method
succeeded
under mpc8641d which is also a ppc.
In fact, I also tried using pci_iomap by imitating rtl8139's codes. The
rtl8139's BAR0
is also a I/O mapped register and its code
(continued)
I traced the 8139too.c when it uses pci_iomap, the pci_iomap called the
ioport_map. The difference between 8139 and my PCIe card lies in the
port value :
void __iomem *ioport_map(unsigned long port, unsigned int len)
{
return (void __iomem *) (port + _IO_BASE);
}
in
Hi, Anthony Foiani,
I found a MPC8315ERDB rev1.0 board and did some tests.
First there is no limit speed issue on the board, so it seems it may only
happen on the MPC8315DS board.
Second, the SATA can work well with NOR write operation on the ERDB board.
So the two issues happened to you should
The following simplifies the denorm code by using macros to generate the long
stream of almost identical instructions.
This patch results in no changes to the output binary, but removes a lot of
lines of code.
Signed-off-by: Michael Neuling mi...@neuling.org
---
POWER8 can take a denormalisation exception on any VSX registers.
This does the extra 32 VSX registers we don't currently handle.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/exceptions-64s.S | 10 ++
1 file changed, 10 insertions(+)
diff --git
Initially, the series of patches is built based on 3.10.RC1 and the patchset
doesn't intend to enable EEH functionality for PHB3 for now. Obviously, PHB3
EEH support on PowerNV platform is something to do in future.
The series of patches intends to support EEH for PowerNV platform. The EEH
core
Under some special circumstances, the EEH device doesn't have the
associated device tree node or PCI device. The patch enhances those
functions converting EEH device to device tree node or PCI device
accordingly to avoid unnecessary system crash.
Signed-off-by: Gavin Shan
While processing EEH event interrupt from P7IOC, we need function
to retrieve the PE according to the indicated EEH device. The patch
makes function eeh_pe_get() public so that other source files can call
it for that purpose. Also, the patch fixes referring to wrong BDF
(Bus/Device/Function)
While processing EEH event interrupt from P7IOC, we need function
to retrieve the PE according to the indicated PCI host controller
(struct pci_controller). The patch makes function eeh_phb_pe_get()
public so that other source files can call it for that purpose.
Signed-off-by: Gavin Shan
There're several types of PEs can be supported for now: PHB, Bus
and Device dependent PE. For PCI bus dependent PE, tracing the
corresponding PCI bus from PE (struct eeh_pe) would make the code
more efficient. The patch also enables the retrieval of PCI bus based
on the PCI device dependent PE.
For EEH on PowerNV platform, we will do EEH probe based on the
real PCI devices. The PCI devices are available after PCI probe.
So we have to call eeh_init() explicitly on PowerNV platform
after PCI probe. The patch also does EEH probe for PowerNV platform
in eeh_init().
Signed-off-by: Gavin Shan
The patch adds new EEH operation post_init. It's used to notify
the platform that EEH core has completed the EEH probe. By that,
PowerNV platform starts to use the services supplied by EEH
functionality.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h
The patch synchronizes OPAL APIs between kernel and firmware.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h| 116 +++-
arch/powerpc/platforms/powernv/opal-wrappers.S |2 +
arch/powerpc/platforms/powernv/pci.c
While doing EEH recovery, the PCI devices of the problematic PE
should be removed and then added to the system again. During the
so-called hotplug event, the PCI devices of the problematic PE
will be probed through early/late phase. We would delay EEH probe
on late point for PowerNV platform since
The EEH event is usually produced because of 0xFF's returned from
PCI config or I/O registers. PowerNV platform also can produce EEH
event through interrupts. The patch differentiates the EEH events
produced for different cases in order to process them differently
in future.
Signed-off-by: Gavin
The patch changes the criteria used to judge if the PE has been
resetted successfully. We needn't the PE status is exactly equal
to the combo: (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE).
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh.c |4 ++--
The post initialization (struct eeh_ops::post_init) is called after
the EEH probe is done. On the other hand, the EEH core post initialization
is designed to call platform and then I/O chip backend on PowerNV
platform.
The patch adds the backend for I/O chip to notify the platform
the specific
The patch adds the backend to enable or disable EEH functionality
for the specified PE. The backend is also used to enable MMIO or
DMA path for the problematic PE. It's notable that all PEs on
PowerNV platform support EEH functionality by default, and we
disallow to disable EEH for the specific
For EEH on PowerNV platform, the overall architecture is a bit
different from that on pSeries platform. In order to support multiple
I/O chips in future, we split EEH to 3 layers for PowerNV platform:
EEH core, platform layer, I/O layer. It would give EEH implementation
on PowerNV much more
The patch adds the I/O chip backend to do PE reset. For now, we
focus on PCI bus dependent PE. If PHB PE has been put into error
state, the PHB will take complete reset. Besides, the root bridge
will take fundamental or hot reset accordingly if the indicated
PE locates at the toppest of PCI
The patch adds EEH backends for PowerNV platform. It's notable that
part of those EEH backends call to the I/O chip dependent backends.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/Makefile |2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c |
The patch adds I/O chip backend to retrieve the state for the
indicated PE. While the PE state is temperarily unavailable,
we return the default wait time (1000ms).
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 104
The patch enables EEH check and let EEH core to process the EEH
errors for PowerNV platform while accessing config space. Originally,
the implementation already had mechanism to check EEH errors and
tried to recover from them. However, we never let EEH core to handle
the EEH errors.
The patch adds backends to retrieve error log and configure p2p
bridges for the indicated PE.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 59 -
1 files changed, 57 insertions(+), 2 deletions(-)
diff --git
The EEH error interrupts should have been exported by firmware
through device tree. The OS already installed the interrupt
handler (opal_interrupt()) for them. The patch checks if we have
any existing EEH errors and wakes the kernel thread up to process
that if possible.
Signed-off-by: Gavin Shan
The patch initializes EEH for PowerNV platform. Because the OPAL
APIs requires HUB ID, we need trace that through struct pnv_phb.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 16 +---
The patch intends to add debugfs entry powerpc/EEH/PHBx so that
the administrator can inject EEH errors to specified PCI host
bridge for testing purpose.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 36 -
1
On PowerNV platform, the EEH event is produced either by detect
on accessing config or I/O registers, or by interrupts dedicated
for EEH report. The patch adds support to process the interrupts
dedicated for EEH report.
Firstly, the kernel thread will be waken up to process incoming
interrupt.
On Thu, 2013-05-30 at 13:57 +0530, Aneesh Kumar K.V wrote:
+ /* FIXME!!, will fail with when we enable hugepage
support */
Just fix that to say Transparent huge pages as normal huge pages
should work fine unless I'm missing something.
Hugh, any chance you can give that a spin ?
Benjamin Herrenschmidt b...@au1.ibm.com writes:
On Wed, 2013-05-29 at 22:47 -0700, Hugh Dickins wrote:
Running my favourite swapping load (repeated make -j20 kernel builds
in tmpfs in parallel with repeated make -j20 kernel builds in ext4 on
loop on tmpfs file, all limited by mem=700M and
On 05/30/2013 03:19 PM, wolfking wrote:
hi, tiejun.chen:
Thanks for replying.
I tried to use ioremap too, but it doesn't work. The ioport_map method
What happened?
Tiejun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On 05/30/13 11:06, Arnaud Ebalard wrote:
Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:
With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.
hi, tiejun.chen:
When I use ioremap, the card seems to work fine. That is, I can access
part of all register. My PCIe card is a rs232 expand card, it has some
standard UART register, for example the SCR(scratch register). My driver
can access the SCR(write and read) normally, but the other
On 05/30/2013 05:15 PM, wolfking wrote:
hi, tiejun.chen:
When I use ioremap, the card seems to work fine. That is, I can access
Yes, ioremap() should work for MMIO.
part of all register. My PCIe card is a rs232 expand card, it has some
standard UART register, for example the SCR(scratch
I tried several R/W functions: inb/outb and ioread8/iowrite8. The inb/outb
doesn't report any error while the ioread8 freeze. The load/storage sync
code that I have used include mb and something else.
--
View this message in context:
On 05/30/2013 06:02 PM, wolfking wrote:
I tried several R/W functions: inb/outb and ioread8/iowrite8. The inb/outb
What about out_be32/in_be32?
Tiejun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
It also seems that we don't support ISA on all the current corenet ds
boards. So picking a primary bus seems useless, remove that function
too.
IIRC that was due to some bugs in the PPC
On 05/30/2013 03:32 PM, wolfking wrote:
(continued)
I traced the 8139too.c when it uses pci_iomap, the pci_iomap called the
ioport_map. The difference between 8139 and my PCIe card lies in the
port value :
void __iomem *ioport_map(unsigned long port, unsigned int len)
{
return (void
'system_state SYSTEM_RUNNING' will have same effect
with 'system_state == SYSTEM_BOOTING', but the later
one is more clearer.
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
arch/powerpc/platforms/cell/smp.c|2 +-
arch/powerpc/platforms/powernv/smp.c |2 +-
orderly_poweroff is expecting a bool parameter, so
use 'ture' instead '1'
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
arch/powerpc/platforms/pseries/ras.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
在 2013-05-30四的 00:14 -0700，Joe Perches写道：
On Thu, 2013-05-30 at 15:07 +0800, liguang wrote:
orderly_poweroff is expecting a bool parameter, so
use 'ture' instead '1'
[]
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
[]
@@ -162,7 +162,7 @@
orderly_poweroff is expecting a bool parameter, so
use 'true' instead '1'
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
arch/powerpc/platforms/pseries/ras.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
Hi Jason and Sebastian,
Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:
With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.
Signed-off-by: Sebastian
tiejun.chen wrote
On 05/30/2013 06:02 PM, wolfking wrote:
I tried several R/W functions: inb/outb and ioread8/iowrite8. The
inb/outb
What about out_be32/in_be32?
my PCIe card's internal register is only 8 bit. So I tried ioremap,
out_8/in_8.
It still doesn't work.
Tiejun
tiejun.chen wrote
On 05/30/2013 03:32 PM, wolfking wrote:
(continued)
I traced the 8139too.c when it uses pci_iomap, the pci_iomap called
the
ioport_map. The difference between 8139 and my PCIe card lies in the
port value :
void __iomem *ioport_map(unsigned long port, unsigned int len)
On May 28, 2013, at 5:45 PM, Scott Wood wrote:
On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
All these boards use the same configuration file p1_p2_rdb_pc.h in
u-boot. So they have the same pci bus address set by the u-boot.
But in some of these boards the bus address set in dtb don't match
On 05/30/2013 09:21:19 AM, Kumar Gala wrote:
On May 28, 2013, at 5:45 PM, Scott Wood wrote:
On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
All these boards use the same configuration file p1_p2_rdb_pc.h in
u-boot. So they have the same pci bus address set by the u-boot.
But in some of these
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit c0ffaf3655fab1909a920c8f30ba1722932d01bb:
watchdog: Remove softlockup_thresh from Documentation (2013-05-28 11:28:20
+0200)
are available in the
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Following patch added several Power7 events into /sys/devices/cpu/events.
Document those events in the testing ABI.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/105167.html
Signed-off-by: Sukadev Bhattiprolu
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
Benjamin Herrenschmidt b...@au1.ibm.com writes:
On Wed, 2013-05-29 at 22:47 -0700, Hugh Dickins wrote:
Running my favourite swapping load (repeated make -j20 kernel builds
in tmpfs in parallel with repeated make -j20 kernel builds in
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
A set of Power7 events are often used for Cycles Per Instruction (CPI) stack
analysis. Make these events available in sysfs (/sys/devices/cpu/events/) so
they can be identified using their symbolic names:
perf stat -e
On 05/30/2013 07:49:48 AM, wolfking wrote:
tiejun.chen wrote
On 05/30/2013 03:32 PM, wolfking wrote:
(continued)
I traced the 8139too.c when it uses pci_iomap, the pci_iomap
called
the
ioport_map. The difference between 8139 and my PCIe card lies in
the
port value :
void __iomem
On 05/29/2013 10:42:01 PM, wolfking wrote:
hi, all
I'm doing some developing on the windriver's sbc8548 board. The
kernel I
use
is 3.6.10 and the u-boot version is 2012-10. I changed the board's
configuration:
the board now boot from the 64MB SODIMM Flash (not the default 8MB
on-board
On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote:
Here is a set of small independent patches that clean up or fix minor things
across DMA slave drivers.
The series looks fine. I am going to wait a day more and apply, pls speak up if
you disagree and ack if you agree
--
~Vinod
On 05/30/2013 05:20:34 AM, Kevin Hao wrote:
On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
It also seems that we don't support ISA on all the current corenet
ds
boards. So picking a primary bus seems useless, remove that
function
On 05/29/2013 10:25:25 PM, Kevin Hao wrote:
On Tue, May 28, 2013 at 05:45:56PM -0500, Scott Wood wrote:
On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
All these boards use the same configuration file p1_p2_rdb_pc.h in
u-boot. So they have the same pci bus address set by the u-boot.
But in some
Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
From: Tang Yuantian yuantian.t...@freescale.com
The compatible string of clock is changed from *-2 to *-2.0
on chassis 2. So updated it accordingly.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Taken into clk-next.
Quoting Mike Turquette (2013-05-30 11:57:32)
Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
From: Tang Yuantian yuantian.t...@freescale.com
The compatible string of clock is changed from *-2 to *-2.0
on chassis 2. So updated it accordingly.
Signed-off-by: Tang Yuantian
On May 30, 2013, at 2:21 PM, Mike Turquette wrote:
Quoting Mike Turquette (2013-05-30 11:57:32)
Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
From: Tang Yuantian yuantian.t...@freescale.com
The compatible string of clock is changed from *-2 to *-2.0
on chassis 2. So updated it
On Thu, May 30, 2013 at 11:06:08AM +0200, Arnaud Ebalard wrote:
Hi Jason and Sebastian,
Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:
With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
Quoting Kumar Gala (2013-05-30 12:26:38)
On May 30, 2013, at 2:21 PM, Mike Turquette wrote:
Quoting Mike Turquette (2013-05-30 11:57:32)
Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
From: Tang Yuantian yuantian.t...@freescale.com
The compatible string of clock is changed
On Thu, May 30, 2013 at 8:47 PM, Vinod Koul vinod.k...@intel.com wrote:
On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote:
Here is a set of small independent patches that clean up or fix minor things
across DMA slave drivers.
The series looks fine. I am going to wait a day more
Hi,
Jason Cooper ja...@lakedaemon.net writes:
For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
the PCIE init routine in board-readynas.c, and yours remove ge00
init. With both applied, the whole file
hi, scott:
Thanks for replying!
In what specific way does it not work?
when I use iowrite8 to write, things seem OK, the codes continue running,
when I use ioread8 to read, the console I use freezes. The console stops
responding.
Why can't it succeed? Is there nothing mapped at
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Date: Wed, 29 May 2013 21:32:42 +0200
For the patches above I suggest to take Patches 1-6 through David
Miller's branch, and Patches 7-12 through Jason Cooper's when the
former have appeared on mainline linux. The patch set has been
On 05/31/2013 12:24 AM, Scott Wood wrote:
On 05/30/2013 07:49:48 AM, wolfking wrote:
tiejun.chen wrote
On 05/30/2013 03:32 PM, wolfking wrote:
(continued)
I traced the 8139too.c when it uses pci_iomap, the pci_iomap called
the
ioport_map. The difference between 8139 and my PCIe card
hi, tiejun:
When I don't compile my pcie card driver(in kernel or as a driver), the
kernel
auto allocate the resoures to my pcie card, here is the output:
root@generic-powerpc-e500v2:~# cat /proc/ioports
-007f : /pci@e0008000
-0fff : Legacy IO
1000-10ff :
On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
On 05/29/2013 01:35 AM, Guenter Roeck wrote:
bios_add_device(). Drop explicit calls to pcibios_setup_device();
this makes pcibios_setup_bus_devices() a noop function which could
eve
Yeah, it's more reasonable to do the
On Thu, 2013-05-30 at 22:05 -0700, Hugh Dickins wrote:
Sure, it's now under way. If all goes well, I'll give you a
progress report in about 15 hours time; but given the variance in
how long it took to hit, I won't feel fully confident until this
time tomorrow, when I'll update you again.
On Thu, 2013-05-30 at 22:14 -0700, Guenter Roeck wrote:
On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
On 05/29/2013 01:35 AM, Guenter Roeck wrote:
bios_add_device(). Drop explicit calls to pcibios_setup_device();
this makes pcibios_setup_bus_devices() a noop function
72 matches
Mail list logo
