"ehpriv 1" instruction is used for setting software breakpoints
by user space. This patch adds support to exit to user space
with "run->debug" have relevant information.
As this is the first point we are using run->debug, also defined
the run->debug structure.
Signed-off-by: Bharat Bhushan
---
v
KVM need this function when switching from vcpu to user-space
thread. My subsequent patch will use this function.
Signed-off-by: Bharat Bhushan
---
v5->v6
- switch_booke_debug_regs() not guarded by the compiler switch
arch/powerpc/include/asm/switch_to.h |1 +
arch/powerpc/kernel/process.c
For KVM also use the "struct debug_reg" defined in asm/processor.h
Signed-off-by: Bharat Bhushan
---
v5->v6
- no changes
arch/powerpc/include/asm/kvm_host.h | 13 +
arch/powerpc/kvm/booke.c| 34 --
2 files changed, 25 insertions(+), 2
This patch adds the debug stub support on booke/bookehv.
Now QEMU debug stub can use hw breakpoint, watchpoint and
software breakpoint to debug guest.
This is how we save/restore debug register context when switching
between guest, userspace and kernel user-process:
When QEMU is running
-> threa
From: Bharat Bhushan
Note: These patches depends on https://lkml.org/lkml/2013/7/4/49.
This patchset adds the userspace debug support for booke/bookehv.
this is tested on powerpc e500v2/e500mc devices.
We are now assuming that debug resource will not be used by kernel for
its own debugging. It
> Reserved fields of the sync instruction have been used for other
> instructions (e.g. lwsync). On processors that do not support variants
> of the sync instruction, emulate it by executing a sync to subsume the
> effect of the intended instruction.
...
> + /* Emulate sync instruction variant
On Thu, 2013-07-04 at 09:31 +0100, David Laight wrote:
> Do you need to execute 'sync' here?
> It is worth checking whether the trap entry/exit doesn't
> do an implicit one for you.
Not really. It does an implicit isync (more than one even) but
not a sync.
Cheers,
Ben.
_
Hello, we're using a custom board based on mpc5200b
We are using kernel 2.6.33 and when we using ethernet, we get 80% packet loss
with ping.
Where could i find the solutions?
U-boot information:
CPU: MPC5200B v2.2, Core v1.4 at 132 MHz
Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
Board: Ran Con
On Tue, Jun 25, 2013 at 12:46:42PM -0400, Vince Weaver wrote:
> On Tue, 25 Jun 2013, Runzhen Wang wrote:
>
> > This patch makes all the POWER7 events available in sysfs.
> >
> > ...
> >
> > $ size arch/powerpc/perf/power7-pmu.o
> >textdata bss dec hex filename
> >3073
v2:
These patches are based on the Ben's next branch. In this version we choose
to do a second relocation if the PAGE_OFFSET is not mapped to the memstart_addr
and we also choose to set the tlb1 entries for the kernel space in address
space 1. With this implementation:
* We can load the kernel at
The e500v1 doesn't implement the MAS7, so we should avoid to access
this register on that implementations. Some code use the
CONFIG_PHYS_64BIT to protect these accesses, but this is not accurate.
In theory we can enable the CONFIG_PHYS_64BIT for a e500v1 board and
the CONFIG_PHYS_64BIT is also enab
Move the codes which translate a effective address to physical address
to a separate function. So it can be reused by other code.
Signed-off-by: Kevin Hao
---
A new patch in v2.
arch/powerpc/kernel/head_fsl_booke.S | 54 +---
1 file changed, 32 insertions(+), 22
This is based on the codes in the head_44x.S. Since we always align to
256M before mapping the PAGE_OFFSET for a relocatable kernel, we also
change the init tlb map to 256M size.
Signed-off-by: Kevin Hao
---
v2: Move the code to set kernstart_addr and virt_phys_offset to a c function.
So we c
We use the tlb1 entries to map low mem to the kernel space. In the
current code, it assumes that the first tlb entry would cover the
kernel image. But this is not true for some special cases, such as
when we run a relocatable kernel above the 256M or set
CONFIG_KERNEL_START above 256M. So we choose
In the current code, the data used by memblock are initialized
statically. But in some special cases we may scan the memory twice.
So we should have a way to reinitialize these data before the second
time.
Signed-off-by: Kevin Hao
---
A new patch in v2.
include/linux/memblock.h | 1 +
mm/membl
This is always true for a non-relocatable kernel. Otherwise the kernel
would get stuck. But for a relocatable kernel, it seems a little
complicated. When booting a relocatable kernel, we just align the
kernel start addr to 256M and map the PAGE_OFFSET from there. The
relocation will base on this vi
For a relocatable kernel since it can be loaded at any place, there
is no any relation between the kernel start addr and the memstart_addr.
So we can't calculate the memstart_addr from kernel start addr. And
also we can't wait to do the relocation after we get the real
memstart_addr from device tre
The RELOCATABLE is more flexible and without any alignment restriction.
And it is a superset of DYNAMIC_MEMSTART. So use it by default for
a kdump kernel.
Signed-off-by: Kevin Hao
---
A new patch in v2.
arch/powerpc/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/a
On Thu, Jul 04, 2013 at 10:52:18PM +1000, Michael Ellerman wrote:
> I don't think it even needs libpfm4, just some csv files in tools/perf
> would do the trick.
Right; I think Stephane and Jiri are in favour of creating a 'new' project that
includes just the event definitions in a plain text forma
On Wed, 3 Jul 2013 15:37:56 +0100, Grant Likely wrote:
> On Wed, Jul 3, 2013 at 3:10 PM, Rob Herring wrote:
> > On 07/03/2013 01:01 AM, Benjamin Herrenschmidt wrote:
> >> Commit:
> >>
> >> e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
> >> of/address: Handle #address-cells > 2 specially
> >>
> >>
Hi Michael,
I believe you forgot to add the cpu_user_features2 bit to announce the EBB
support
for P8, patch following:
Signed-off-by: Adhemerval Zanella
---
arch/powerpc/kernel/cputable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/
Load/store indexed instructions where the index register RA=R0, such
as "lfdx f1,0,r3", are not illegal.
Load/store indexed with update instructions where the index register
RA=R0, such as "lfdux f1,0,r3", are invalid, and, to be consistent
with existing math-emu behavior for other invalid instruc
Load/store indexed instructions where the index register RA=R0, such
as "lfdx f1,0,r3", are not illegal.
Load/store indexed with update instructions where the index register
RA=R0, such as "lfdux f1,0,r3", are invalid, and, to be consistent
with existing math-emu behavior for other invalid instruc
On Thu, 2013-07-04 at 17:18 +0100, Grant Likely wrote:
> > I'll include this in my 3.11 pull request for Linus
>
> Oops. Ben, I misread what you wrote. It would have been just fine to
> include it in your powerpc -next branch. Sorry for the confusion.
>
> Anyway, I saw your powerpc pull req and t
On Thu, 4 Jul 2013, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-04 at 09:31 +0100, David Laight wrote:
> > Do you need to execute 'sync' here?
> > It is worth checking whether the trap entry/exit doesn't
> > do an implicit one for you.
>
> Not really. It does an implicit isync (more than one
Overview of P1020RDB-PD device:
- DDR3 2GB
- NOR flash 64MB
- NAND flash 128MB
- SPI flash 16MB
- I2C EEPROM 256Kb
- eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
- eTSEC2 (SGMII PHY)
- eTSEC3 (RGMII PHY)
- SDHC
- 2 USB ports
- 4 TDM ports
- PCIe
Signed-off-by: Haijun Zhang
Signed-off-by: Jer
On Thu, Jul 04, 2013 at 03:58:01PM -0300, Adhemerval Zanella wrote:
> Hi Michael,
>
> I believe you forgot to add the cpu_user_features2 bit to announce the EBB
> support
> for P8, patch following:
Hi Adhemerval,
You're right, I haven't added it. I was wondering how best to do it.
It's possibl
The series of patches bases on linux-poerpc-next and intends to resolve
the following problems:
- On pSeries platform, the EEH doesn't work after PHB hotplug
with "drmgr". The root cause is that the EEH resources (
EEH devices, EEH caches) aren't released correctly. Fo
The patch overrides the weak function pcibios_stop_dev() to destroy
the EEH device and cache while stopping and removing the corresponding
PCI device.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/pci-hotplug.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --g
Make some functions public in order to support hotplug on either specific
PCI bus or PCI device in future.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h |9 +
arch/powerpc/kernel/eeh.c |6 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/
Currently, we're transversing EEH devices by list_for_each_entry().
That's not safe enough because the EEH devices might be removed from
its parent PE while doing iteration. The patch replaces that with
list_for_each_entry_safe().
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h |
When EEH error happens to one specific PE, the device drivers
of its attached EEH devices (PCI devices) are checked to see
the further action: reset with complete hotplug, or reset without
hotplug. However, that's not enough for those PCI devices whose
drivers can't support EEH, or those PCI device
When EEH error happens to one specific PE, some devices with drivers
supporting EEH won't except hotplug on the deivce. However, there
might have other deivces without driver, or with driver without EEH
support. For the case, we need do partial hotplug in order to make
sure that the PE becomes abso
When we do normal hotplug, the PE shouldn't be kept. However, we
need the PE if the hotplug caused by EEH errors. Since we remove
EEH device through the PCI hook pcibios_stop_dev(), the flag
"purge_pe" passed to various functions is meaningless. So the patch
removes the meaningless flag and introdu
When stopping and removing one specific PCI device, the platform
might need take some actions. One example is that EEH already had
eeh cache and eeh device attached to the PCI device, and we need
release eeh cache and device during the time. The patch introduces
hook pcibios_stop_dev() for the purp
Since pci_stop_and_remove_bus_device() has removed the EEH cache,
we needn't do that again.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Gavin Shan
---
drivers/pci/hotplug/rpadlpar_core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/hotp
On Fri, 2013-07-05 at 10:57 +0800, Gavin Shan wrote:
> When stopping and removing one specific PCI device, the platform
> might need take some actions. One example is that EEH already had
> eeh cache and eeh device attached to the PCI device, and we need
> release eeh cache and device during the ti
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/fsldma.c |5 -
drivers/dma/fsldma.h |2 +-
2 files changed, 5 insertions(+), 2 dele
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 90 +++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 90 ++
From: Hongbo Zhang
Hi Vinod, Dan, Leo and Scott, please have a look at these V2 patches.
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.
V1->v2 changes:
- removed the codes handling the register dgsr1, since it isn't used corrently
- r
40 matches
Mail list logo
