From: Ian Munsie
This patch adds mappings from the register numbers from DWARF to the
register names used in the PowerPC Regs and Stack Access API. This
allows perf probe to be used to record variable contents on PowerPC.
This patch depends on functionality in the powerpc/next tree, though it
wi
From: Ian Munsie
The perf userspace tool included some architecture specific code to map
registers from the DWARF register number into the names used by the regs
and stack access API.
This patch moves the architecture specific code out into a seperate
arch/x86 directory along with the infrastruc
These patches add the required mappings to use perf probe on PowerPC.
Functionality wise it requires patch 359e4284a3f37aba7fd06d993863de2509d86f54
from the powerpc-next tree to provide the HAVE_REGS_AND_STACK_ACCESS_API
required for CONFIG_KPROBE_EVENT. The code will still compile cleanly without
> >
> > It's checking to see if the following bits of DSISR are set:
> > 0 - set by DTLB miss if no hash table entry group is found
>
> No. 0 means we hit a direct store segment. This is a historical feature
> of the architecture which we don't use, so should not happen.
>
Sorry, would have hel
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so tha
On Fri, Apr 2, 2010 at 12:49 AM, Benjamin Herrenschmidt
wrote:
> On Thu, 2010-04-01 at 19:14 +0400, Anton Vorontsov wrote:
>
>> So CONFIG_HIBERNATION breaks suspend? Hm. How do you try
>> to suspend? echo mem > /sys/power/state?
>
> Nah, suspend isn't supported on these ( ... yet, I suppose I coul
On Thu, 2010-04-08 at 12:33 -0700, bruce_leon...@selinc.com wrote:
(CC'ing Paulus who wrote that code ages ago)
> > 616 DataAddressInvalid:
> > 617 mfspr r3,SPRN_SRR1
> > 618 rlwinm r1,r3,9,6,6 /* Get load/store bit */
> > 619 addis r1,r1,0x2000
> > 620
On Sat, 2010-04-10 at 20:31 -0500, Bill Gatliff wrote:
> Right now I'm thinking mostly about GPIO devices which need to register
> before things like gpio-leds can use them. Sometimes the GPIO expansion
> chip of interest is on i2c, other times it's spi, and still others it's
> a platform or USB d
On Sun, 2010-04-11 at 08:39 +0900, Paul Mundt wrote:
> This is a common problem for drivers that are all stuck on the same
> initcall level and as a result are entirely dependent on link order. Some
> more intelligent logic via the bus notifiers would help with some of
> this, but it wouldn't help
> The general problem with your approach is that the module in question
> might not know what services it needs to wait for.
The device-tree could provide a lot of help here, by providing a way to
wait for a service attached to a given device-node since -that- at least
contains the linkage we need
10 matches
Mail list logo
