* Paul Mackerras wrote:
> Here is a series of patches from Anton Blanchard that implement some
> nice tracing and perf_event features on powerpc. One of them is
> generic perf_event stuff (adding software events for alignment faults
> and instruction emulation faults).
>
> Since this touche
Dear Wolfram Sang,
In message <20091028152324.gc3...@pengutronix.de> you wrote:
>
> my MPC5121e (Rev2) has PVR/SVR: 0x8086_2010/0x8018_0020 (as mentioned in the
> manual)
...
> Does someone here have a Rev1 and can ultimately confirm and/or supply the
> complete PVR/SVR for Rev1? Couldn't find a
On Thu, 2009-10-29 at 14:08 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-28 at 15:53 -0500, Nathan Fontenot wrote:
> > + struct device_node *dn;
> > + struct device_node *first_dn = NULL;
> > + struct device_node *last_dn = NULL;
> > + struct property *property;
> > + struct pro
On Wed, 2009-10-28 at 15:59 -0500, Nathan Fontenot wrote:
> +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
> +static ssize_t cpu_probe(const char *buf, size_t count)
dlpar_cpu_probe() pls
> +static ssize_t cpu_release(const char *buf, size_t count)
> +{
Ditto.
Or else in system.map, backtraces, etc...
On Wed, 2009-10-28 at 15:58 -0500, Nathan Fontenot wrote:
> Create new probe and release sysfs files to facilitate adding and removing
> cpus from the system. This also creates the powerpc specific stubs to handle
> the arch callouts from writes to the sysfs files.
>
> The creation and use of the
On Wed, 2009-10-28 at 15:55 -0500, Nathan Fontenot wrote:
> This patch creates the release sysfs file for memory and updates the
> exisiting probe file so both make arch-specific callouts to handle removing
> and adding memory to the system. This also creates the powerpc specific stubs
> for handl
On Wed, 2009-10-28 at 15:53 -0500, Nathan Fontenot wrote:
> This patch provides the kernel DLPAR infrastructure in a new filed named
> dlpar.c. The functionality provided is for acquiring and releasing a resource
> from firmware and the parsing of information returned from the
> ibm,configure-conn
Benjamin Herrenschmidt writes:
> On Thu, 2009-10-29 at 11:56 +1100, Paul Mackerras wrote:
> > Here is a series of patches from Anton Blanchard that implement some
> > nice tracing and perf_event features on powerpc. One of them is
> > generic perf_event stuff (adding software events for alignment
Oops, there was one big, nasty, stupid bug in this patch. Corrected
patch below.
Cleanup management of kmem_caches for pagetables
Currently we have a fair bit of rather fiddly code to manage the
various kmem_caches used to store page tables of various levels. We
generally have two caches holdin
On Thu, 2009-10-29 at 11:56 +1100, Paul Mackerras wrote:
> Here is a series of patches from Anton Blanchard that implement some
> nice tracing and perf_event features on powerpc. One of them is
> generic perf_event stuff (adding software events for alignment faults
> and instruction emulation faul
Here is a series of patches from Anton Blanchard that implement some
nice tracing and perf_event features on powerpc. One of them is
generic perf_event stuff (adding software events for alignment faults
and instruction emulation faults).
Since this touches the perf_event and tracing subsystems as
> Yes, the MSR_EE is cleared before we jump to do_work. I'm OK with
> clearing the hardirqenable flag. I just assumed that the hardirq flag
> was supposed to reflect the MSR_EE state, so it looked a bit odd
> clearing the MSR_EE at one place and then reflecting the change at another.
Yeah well
Benjamin Herrenschmidt wrote:
On Thu, 2009-10-29 at 00:28 +0300, Valentine wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2009-10-28 at 22:19 +0300, Valentine wrote:
I'm just not sure that we need to clear HARDIRQEN here, since we don't
really hard-disable the the interrupts.
We do, or rather,
Benjamin Herrenschmidt wrote:
So I _think_ that the irqs on/off accounting for lockdep isn't quite
right. What do you think of this slightly modified version ? I've only
done a quick boot test on a G5 with lockdep enabled and a played a bit,
nothing shows up so far but it's definitely not conclus
On Wed, 2009-10-28 at 22:19 +0300, Valentine wrote:
> I'm just not sure that we need to clear HARDIRQEN here, since we don't
> really hard-disable the the interrupts.
We do, or rather, we come in with the interrupts hard disabled, no ?
Ben.
> Thanks,
> Val.
>
> > + TRACE_DISABLE_INTS
> > +
On Thu, 2009-10-29 at 00:28 +0300, Valentine wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-10-28 at 22:19 +0300, Valentine wrote:
> >
> >> I'm just not sure that we need to clear HARDIRQEN here, since we don't
> >> really hard-disable the the interrupts.
> >
> > We do, or rather, we co
Hiya,
my MPC5121e (Rev2) has PVR/SVR: 0x8086_2010/0x8018_0020 (as mentioned in the
manual)
I would assume that Rev1 has something like 0x8018_0010 for SVR. Seeing this
code in the Denx NFC-driver seconds that:
+ rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
+ if (rev != 2) {
+ p
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a resource
from firmware and the parsing of information returned from the
ibm,configure-connector rtas call. Additionally this exports the pSeries
reconfigu
On Wed, 2009-10-28 at 19:09 +0530, Vineeth _ wrote:
> Hi,
> we are porting Linux 2.6.30 on a ppc440x5 based board.
> when we check the kernel code in arch/powerpc/kernel/head_44x.S file @
> line number 162,
> while creating the TLB for 256MB, the cache enable/disable property is
> not set by the ke
> > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > use
> > >> the
> > >> >>>
> > >> >> address of the flash. Is there some magical function call
> > that
> > >> >> gives me access to that portion of the memor
This adds the capability to DLPAR add and remove memory from the kernel. The
patch registers handlers for the arch-specific probe and release memory
callouts to handle addition/removal of memory to the system and the associated
device tree updates.
Signed-off-by: Nathan Fontenot
---
Index:
Create new probe and release sysfs files to facilitate adding and removing
cpus from the system. This also creates the powerpc specific stubs to handle
the arch callouts from writes to the sysfs files.
The creation and use of these files is regulated by the
CONFIG_ARCH_CPU_PROBE_RELEASE option
Register the pseries specific handler for the powerpc architecture handlers
for the cpu probe and release files. This also implements the cpu DLPAR
addition and removal of CPUS from the system.
Signed-off-by: Nathan Fontenot
---
Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
===
Benjamin Herrenschmidt wrote:
On Wed, 2009-10-28 at 22:19 +0300, Valentine wrote:
I'm just not sure that we need to clear HARDIRQEN here, since we don't
really hard-disable the the interrupts.
We do, or rather, we come in with the interrupts hard disabled, no ?
Yes, looks like the interrupt
Move the definition of the of_drconf_cell struct from numa.c to prom.h. This
is needed so that we can parse the ibm,dynamic-memory device-tree property
when DLPAR adding and removing memory.
Signed-off-by: Nathan Fontenot
---
Index: powerpc/arch/powerpc/include/asm/prom.h
===
This is a re-send of the entire patch set with updates made from recent
comments received.
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a res
This patch creates the release sysfs file for memory and updates the
exisiting probe file so both make arch-specific callouts to handle removing
and adding memory to the system. This also creates the powerpc specific stubs
for handling the arch callouts.
The creation and use of these files are g
Why were these patches resent? What changed?
Everybody who is going to review these patches has already reviewed
them and now they need to review them all again?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/list
> On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote:
> > > Jonathan Haws wrote:
> > > > I had thought about using MTD, but decided against it because
> with
> > > > previous benchmarking that we did with MTD and our custom
> driver,
> > > we
> > > > found that our custom driver was about 10x f
> On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> >> >>> How can I get that pointer? Unfortunately I cannot simply
> use
> >> the
> >> >>>
> >> >> address of the flash. Is there some magical function call
> that
> >> >> gives me access to that portion of the memory space?
> >> >>
Romen,
I am sorry for the misguided statement.
I indeed had patched it .
I am copying the patch here. Hope it helps you.
diff --exclude CVS -uNr linux-2.6.30/drivers/net/phy/Kconfig
linux-2.6.30.modified/drivers/net/phy/Kconfig
--- linux-2.6.30/drivers/net/phy/Kconfig2009
Hi,
we are porting Linux 2.6.30 on a ppc440x5 based board.
when we check the kernel code in arch/powerpc/kernel/head_44x.S file @
line number 162,
while creating the TLB for 256MB, the cache enable/disable property is
not set by the kernel ? or are we missing smthing ?
when we gave that particular
On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
>> >>> How can I get that pointer? Unfortunately I cannot simply use
>> the
>> >>>
>> >> address of the flash. Is there some magical function call that
>> >> gives me access to that portion of the memory space?
>> >>
>> >> $ man 2 mma
On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote:
> > Jonathan Haws wrote:
> > > I had thought about using MTD, but decided against it because with
> > > previous benchmarking that we did with MTD and our custom driver,
> > we
> > > found that our custom driver was about 10x faster.
> >
> >
Use bitmap library and kill some unused iommu helper functions.
1. s/iommu_area_free/bitmap_clear/
2. s/iommu_area_reserve/bitmap_set/
3. Use bitmap_find_next_zero_area instead of find_next_zero_area
This cannot be simple substitution because find_next_zero_area
doesn't check the last bit o
This introduces new bitmap functions:
bitmap_set: Set specified bit area
bitmap_clear: Clear specified bit area
bitmap_find_next_zero_area: Find free bit area
These are mostly stolen from iommu helper. The differences are:
- Use find_next_bit instead of doing test_bit for each bit
- Rewrite bit
36 matches
Mail list logo
