On Sat, Nov 27, 2010 at 08:36:30PM +0100, Andreas Schwab wrote:
> Why does ptrace_set_debugreg call register_user_hw_breakpoint, but
> ppc_set_hwdebug doesn't? Shouldn't ppc_set_hwdebug set the
> DABR_DATA_(READ|WRITE|TRANSLATION) bits in the dabr?
>
> Andreas.
The hw-breakpoint interfaces were
On Sun, Nov 28, 2010 at 10:55 PM, David Gibson
wrote:
> On Fri, Nov 26, 2010 at 12:34:35AM +1100, Michael Ellerman wrote:
>> Most of these are straight renames, but some have changed more
>> substantially. The routines for the flat tree have all become fdt_foo().
>
> I'm a little uneasy about usin
On Fri, Nov 26, 2010 at 12:34:35AM +1100, Michael Ellerman wrote:
> On Thu, 2010-11-25 at 01:03 +1100, Michael Ellerman wrote:
> > Hi all,
> >
> > There were some murmurings on IRC last week about renaming the of_*()
> > routines.
> ...
> > The thinking is that on many platforms that use the of_()
> I have a mostly-finished patch to do the above. I'll include it below, but
> first a few words about why it's only mostly finished.
>
> The other Pegasos workarounds are in fixup_device_tree_chrp, and I don't see
> anything like an "if(machine_is_pegasos)" around them. What keeps them from
> be
On Mon, 2010-11-29 at 15:56 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote:
> > The vmalloc code can track the physical address of a vma, when the
> > vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
> >
> > Because get_vm_area
On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote:
> The vmalloc code can track the physical address of a vma, when the
> vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
>
> Because get_vm_area_caller() doesn't know it's being called for
> ioremap() it's up to the arc
The vmalloc code can track the physical address of a vma, when the
vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
Because get_vm_area_caller() doesn't know it's being called for
ioremap() it's up to the arch code to set the phys_addr. A bunch
of other arch's do this, I'm not
On Sun, Nov 28, 2010 at 4:38 PM, Benjamin Herrenschmidt <
b...@kernel.crashing.org> wrote:
> On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> > This adds basic support for the system controller FPGA on the OVRO CARMA
> > board. This patch only adds infrastructure that will be used by late
On Tue, 2010-11-09 at 16:25 -0700, Jesse Larrew wrote:
> From: Jesse Larrew
>
> This patch sets a timer during boot that will periodically poll the
> associativity change counters in the VPA. When a change in
> associativity is detected, it retrieves the new associativity domain
> information v
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> Without this change drivers, such as ibmvscsi, fail to load with the
> previous change.
> ---
So you broke bisection... fold the patch instead or invert them
Cheers,
Ben.
> arch/powerpc/kernel/vio.c |3 +++
> 1 files changed, 3
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> The IOMMU code has been passing the dma-mask instead of the
> coherent_dma_mask to the iommu allocator. Coherent allocations should
> be made using the coherent_dma_mask.
Won't that break macio devices too ? afaik, they don't set
coh
Peter wrote:
> Hi all
>
> I got completely stuck with a network adapter problem on my
> ppc board (MPC52xx style). The ntwork adapter does not seem
> to intialize correctly when booted without 'help from uboot'
>
Looks your problem is very similar to one I replied here not long ago :) That is
al
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> The iommu_table pointer in the pci auxiliary struct of device_node has
> not been used by the iommu ops since the dma refactor of
> 12d04eef927bf61328af2c7cbe756c96f98ac3bf, however this code still uses
> it to find tables for dlpar. B
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> This adds basic support for the system controller FPGA on the OVRO CARMA
> board. This patch only adds infrastructure that will be used by later
> drivers.
Oh and another comment ...
I'm not sure about drivers/fpga ... in the end, one woul
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> This adds basic support for the system controller FPGA on the OVRO CARMA
> board. This patch only adds infrastructure that will be used by later
> drivers.
One comment I have is do you really need to create a class ? Do you
provide a specif
From: Li Yang
Date: Fri, 26 Nov 2010 17:29:58 +0800
> In commit 58933c64(ucc_geth: Fix the wrong the Rx/Tx FIFO size),
> the UCC_GETH_UTFTT_INIT is set to 512 based on the recommendation
> of the QE Reference Manual. But that will sometimes cause tx halt
> while working in half duplex mode.
>
>
Update compat_arch_ptrace to follow recent changes in
PTRACE_GET_DEBUGREG and the addition of
PPC_PTRACE_{GETHWDBGINFO|{SET|DEL}HWDEBUG}. The latter three can be
forwarded to arch_ptrace unchanged.
Signed-off-by: Andreas Schwab
---
arch/powerpc/kernel/ptrace32.c |7 +++
1 files changed,
On 11/27/2010 06:31 AM, Peter wrote:
Hi all
I got completely stuck with a network adapter problem on my
ppc board (MPC52xx style). The ntwork adapter does not seem
to intialize correctly when booted without 'help from uboot'
The adapter works properly when I first use it with uboot. E.g.
using
18 matches
Mail list logo
