On Wed, 2008-05-07 at 23:31 -0700, Spence Nick wrote:
>
> In our case the memory area is reserved so that the main processor will
> not touch it except when mapped by the mem driver.
Then you should completely carve it out of the LMB's which will ensure
it's not seen as RAM by /dev/mem and not m
Chandru writes:
> When I set linux 2.6.26-rc1 as default kernel to boot in
> /etc/yaboot.conf, then the device tree in open firmware shows only one
> memory node ( the same memory node appears in /proc/device-tree/[EMAIL
> PROTECTED]
> ). But when RHEL5.2 kernel is set as default in /etc/yabo
Paul Mackerras wrote:
> This says nothing about why you want to do this---what bad
> things arise from the present code, or what good things would
> happen if the change was made. It needs to.
We found the problem when porting code from Linux 2.4 to 2.6, where a
user space application maps a 1
Kumar Gala writes:
> We'll hopefully this thread might spark either an explanation for why
> we aren't just linking libgcc in a statement that says we should and
> we can remove the code that implements libgcc functionality.
I've just reviewed the code in the 32-bit and 64-bit PowerPC version
Am Mittwoch, den 07.05.2008, 14:44 -0500 schrieb Scott Wood:
> Scott Wood wrote:
> > Sergej Stepanov wrote:
> >> Hm... it looks like the default uart_set_termios from
> >>
> >> static const struct tty_operations uart_ops in serial_core.c
> >>
> >> and not cpm_uart_set_termios(..)?..
> >>
> >> Is n
Hi,
When I set linux 2.6.26-rc1 as default kernel to boot in
/etc/yaboot.conf, then the device tree in open firmware shows only one
memory node ( the same memory node appears in /proc/device-tree/[EMAIL PROTECTED]
). But when RHEL5.2 kernel is set as default in /etc/yaboot.conf then
the devi
[EMAIL PROTECTED] writes:
> This patch re-introduces the O_SYNC flag to make DRAM non-cached, which is
> the default behavior
> for non PowerPC architectures in /drivers/char/mem.c
This says nothing about why you want to do this---what bad things
arise from the present code, or what good things
From: Nick Spence <[EMAIL PROTECTED]>
This patch re-introduces the O_SYNC flag to make DRAM non-cached, which is the
default behavior
for non PowerPC architectures in /drivers/char/mem.c
Signed-off-by: Nick Spence <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
The problem is that the tft driver currently in mainline assumes that the dcr
control registers
are accessed through mmio, and probes for a reg=<> property. Since the device
is actually a dcr device,
it can be connected via mmio through a bride, or to the native dcr bus of the
processor. For
I have attached the driver in question below. This is *not*
representative of PIKA board drivers in general. This driver was
rewritten from scratch to work in 2.6.26, but still work on the 2.6.9
kernel in RedHatES 4.
Since it was rewritten, it matches the kernel coding specs rather than
PIKA's. Em
Don't return void in pseries/iommu.c
Make mce_data_buf static in pseries/ras.c
Make things static in pseries/rtasd.c
Make things static in pseries/setup.c
vtermno may as well be static in platforms/pseries/lpar.c
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseri
The declaration for fw_feature_init() is in pseries.h and
implemented in firmware.c, so the latter should include the
former.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/firmware.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/
Make a few things static in lparcfg.c
Make init and exit routines static in rtas_flash.c
Make things static in rtas_pci.c
Make some functions static in rtas.c
Make fops static in rtas-proc.c
Remove unneeded extern for do_gtod in smp.c
Make clocksource_init() static in time.c
Make last_tick_len and
This is a little messier than I'd like because xmon.h only exists
on powerpc and we can't have a static inline and an extern declaration
visible at the same time.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/xmon/xmon.c |7 ++-
drivers/char/hvc_console.c |8 +
warning: Using plain integer as NULL pointer
warning: Using plain integer as NULL pointer
warning: symbol 'excprint' was not declared. Should it be static?
warning: symbol 'prregs' was not declared. Should it be static?
warning: symbol 'cacheflush' was not declared. Should it be static?
warni
The typdef for irqreturn_t was moved into its own header a
while back, so there's no reason we can't move xmon_irq()
into xmon.h now.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/chrp/setup.c |7 ---
arch/powerpc/platforms/powermac/pic.c |8 +---
Usually we call xmon() via debugger(), so this could be static.
Sometimes when debugging it's nice to be able to call xmon()
directly though, so add a declaration.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/asm-powerpc/xmon.h |2 ++
1 files changed, 2 insertions(+), 0 del
Some of the routines defined in mpic_msi.c are declared mpic.h,
so the former should include the latter.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/mpic_msi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msi.c b
Somewhere along the way (e28f7faf05159f1cfd564596f5e6178edba6bd49,
"Four level pagetables for ppc64") we ended up with duplicate
definitions for pte_freelist_cur and pte_freelist_force_free.
Somehow this compiles, but it would be better to just have one
definition for each.
The two definitions we
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c |2 --
include/asm-powerpc/mmu-hash64.h |1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 1a4b4b3..05f955f 10
Make two vmemmap helpers static in init_64.c.
Make stab variables static in stab.c
Make psize defs static in hash_utils_64.c
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c |4 ++--
arch/powerpc/mm/init_64.c |4 ++--
arch/powerpc/mm/stab.c
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/mm/init_32.c|3 +--
include/asm-powerpc/system.h |1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 1952b4d..4541859 100644
--- a/arch/powe
When I changed irq_alloc_host() to take an of_node
(52964f87c64e6c6ea671b5bf3030fb1494090a48: "Add an
optional device_node pointer to the irq_host"),
I botched the reference counting semantics.
Stephen pointed out that it's irq_alloc_host()'s
business if it needs to take an additional reference
to
Currently there is no irq_free_host() routine, and that's
more or less OK - because all you need to do is free it.
However the next patch needs to introduce additional
tear down so we'll need a proper free routine.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/irq.c
Adrian Bunk wrote:
> On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote:
>> While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
>> task get blocked for more 120 seconds and does not proceeds future.
>>
>> The task msgctl08 is a ipc testcase, which test the msgget(2
On Wed, May 07, 2008 at 09:46:30PM -0500, Josh Boyer wrote:
> On Thu, 8 May 2008 10:18:50 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> > > The IBM coreconnect names are pretty well defined, it appears. In
> > > addit
On Thu, 8 May 2008 10:18:50 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> > The IBM coreconnect names are pretty well defined, it appears. In
> > addition, the Xilinx versions of these IPs seem to be proliferating.
> > Henc
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of Kumar Gala
> Sent: Tuesday, May 06, 2008 3:12 AM
> To: Anton Vorontsov
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add
> support for ULI RTC
>
>
> O
On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote:
[snip]
> > > Hmmm, something doesn't quite feel right about this. The node
> > > describing the tft device is a child of the [EMAIL PROTECTED] node which
> > > is the
> > > dcr bus. However, dcr bindings use dcr-bus and dcr-re
On Tue, May 06, 2008 at 12:56:44PM +0200, Segher Boessenkool wrote:
>> Current standard practice is not to represent the DCR bus as node with
>> subnodes for the DCR-controlled devices. That's because the DCR bus
>> tends to run in addition to other on-chip busses, and some things have
>> to go on
On Wed, 7 May 2008 17:42:51 -0400
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> On Wed, 07 May 2008 16:36:30 +0200
> "Detlev Zundel" <[EMAIL PROTECTED]> wrote:
>
> > It also happened that a driver once posted for what the customer
> > thought was a completely specific device of his own today suppor
On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> The IBM coreconnect names are pretty well defined, it appears. In
> addition, the Xilinx versions of these IPs seem to be proliferating.
> Hence, in the future let's prefer to use the standard names. I've
> left the old names
On Wed, 2008-05-07 at 14:19 -0500, Timur Tabi wrote:
> Update function of_find_property() to return NULL if the device_node passed
> to it is also NULL. Otherwise, passing NULL will cause a null pointer
> dereference.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
>
> This patch allows
On Wed, 23 Apr 2008 22:55:16 +0200
Roel Kluin <[EMAIL PROTECTED]> wrote:
> mpc83xx_spi->irq is unsigned, so the test fails
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
> index be15a62..033fd51 100644
> --- a/drivers/s
Agreed... I intend the backward compatibility to be a temporary thing.
I'd rip it out now, but since we pull out all the information from the
device tree, this will result in 'it doesn't do anything', and I don't
want to be that mean. :)
Steve
> -Original Message-
> From: [EMAIL PROTECT
On Wed, May 7, 2008 at 2:47 PM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> The IBM coreconnect names are pretty well defined, it appears. In
> addition, the Xilinx versions of these IPs seem to be proliferating.
> Hence, in the future let's prefer to use the standard names. I've
> left
On Wed, 07 May 2008 16:36:30 +0200
"Detlev Zundel" <[EMAIL PROTECTED]> wrote:
> It also happened that a driver once posted for what the customer
> thought was a completely specific device of his own today supports
> lots of different boards from at least four different manufacturers."
>
> The wor
Chris Friesen wrote:
Hi,
I'm getting the following error when building 2.6.25. Has anyone else
seen anything like this? This is using gcc 3.4.3.
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a/b
On Wed, 2008-05-07 at 09:22 -0500, Timur Tabi wrote:
> Takashi Iwai wrote:
>
> > This is a mmap of the data record to be shared in realtime with apps.
> > The app updates its data pointer (appl_ptr) on the mmapped buffer
> > while the driver updates the data (e.g. DMA position, called hwptr) on
>
Hi,
I'm getting the following error when building 2.6.25. Has anyone else
seen anything like this? This is using gcc 3.4.3.
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/arch/
The IBM coreconnect names are pretty well defined, it appears. In
addition, the Xilinx versions of these IPs seem to be proliferating.
Hence, in the future let's prefer to use the standard names. I've
left the old names in for some backward compatibility for existing
device trees.
Signed-off-by:
memcpy_from/to_io() use word aligned accesses on the io side of
memory.
The MPC5200 local plus bus where our flashes are connected does not
allow unaligned accesses, so we have to use the io versions of memcpy.
But this region of flash is marked as suitable for execute-in-place,
otherwise the p
Scott Wood wrote:
Sergej Stepanov wrote:
Hm... it looks like the default uart_set_termios from
static const struct tty_operations uart_ops in serial_core.c
and not cpm_uart_set_termios(..)?..
Is not it? but why?...
tty_operations != uart_ops
Despite the unfortunate name of the instance of
Sergej Stepanov wrote:
Hm... it looks like the default uart_set_termios from
static const struct tty_operations uart_ops in serial_core.c
and not cpm_uart_set_termios(..)?..
Is not it? but why?...
tty_operations != uart_ops
-Scott
___
Linuxppc-dev
Am Mittwoch, den 07.05.2008, 14:34 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
> >> I'm not sure how it would make a difference -- the BRG should have
> >> already been set through the set_termios callback, which is called fr
Andy Fleming wrote:
> Mostly having to do with not marking things __iomem. And some failure
> to use appropriate accessors to read MMIO regs.
>
> Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
Acked-By: Timur Tabi <[EMAIL PROTECTED]>
(Not [EMAIL PROTECTED])
--
Timur Tabi
Linux kernel develop
Sergej Stepanov wrote:
Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
I'm not sure how it would make a difference -- the BRG should have
already been set through the set_termios callback, which is called from
uart_set_options.
-Scott
Yes, i thought it also, but i traced it for
On Wed, May 7, 2008 at 1:19 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Update function of_find_property() to return NULL if the device_node passed
> to it is also NULL. Otherwise, passing NULL will cause a null pointer
> dereference.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
Acked-by:
Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > My story is follow: we have mpc8247 based card.
> > The problem with smc happens due to the cpm reset.
> > Of course, if you have not CONFIG_PPC_EARLY_DEBUG_CPM with
> > CONFIG_PPC_CPM_NEW_BINDING.
> > May be
Update function of_find_property() to return NULL if the device_node passed
to it is also NULL. Otherwise, passing NULL will cause a null pointer
dereference.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch allows callers to do this:
np = of_find_compatible_node(...);
prop = of_get
So I applied this, but thinking about it further, do you (theoretically
at least) have the same problem with CQ and SRQ async events?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Sergej Stepanov wrote:
My story is follow: we have mpc8247 based card.
The problem with smc happens due to the cpm reset.
Of course, if you have not CONFIG_PPC_EARLY_DEBUG_CPM with
CONFIG_PPC_CPM_NEW_BINDING.
May be it is some kind of mistake, but i could fix the problem with the
patch i told abo
Boris Shteinbock wrote:
The second reg resource depends on where your firmware set up the SMC pram
regs. With U-boot, it's usually zero.
Note that as of 2.6.26-rc1, this is set up dynamically instead, and the
second resource should be .
Is this correct?
reg = <0x11a80 0x20 0x87fc 2>
On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> /* Monitor port/SMC1 */
> smc1: [EMAIL PROTECTED] {
>device_type = "serial";
>compatible = "fsl,mpc8260-smc-uart",
> "fsl,cpm2-smc-uart";
>reg = <0x11a80 0x20 0x1100 0x40>;
>Th
Hello Scott
Am Mittwoch, den 07.05.2008, 13:22 -0500 schrieb Scott Wood:
> On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> > /* Monitor port/SMC1 */
> > smc1: [EMAIL PROTECTED] {
> >device_type = "serial";
> >compatible = "fsl,mpc8260-smc-uart",
> >
On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> /* Monitor port/SMC1 */
> smc1: [EMAIL PROTECTED] {
>device_type = "serial";
>compatible = "fsl,mpc8260-smc-uart",
> "fsl,cpm2-smc-uart";
>reg = <0x11a80 0x20 0x1100 0x40>;
The
Mostly having to do with not marking things __iomem. And some failure
to use appropriate accessors to read MMIO regs.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/qe.c |6 +++---
arch/powerpc/sysdev/qe_lib/ucc.c |6 +++---
arch/powerpc/sysdev/
The following patch fixes the 64 bit user code backtrace
which currently may hang the system.
Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Index: linux-2.6.25.1/arch/powerpc/oprofile/backtrace.c
===
--- linux-2.6.25.1.orig/arch/p
Hallo.
I had the same problem.
The following patch can help.
diff -pruN paulus-git/drivers/serial/cpm_uart/cpm_uart_core.c
linuxppc-2.6.24-ids8247/drivers/serial/cpm_uart/cpm_uart_core.c
--- paulus-git/drivers/serial/cpm_uart/cpm_uart_core.c 2008-03-28
11:03:32.0 +0100
+++ linuxppc-2.6
> I agree, that's why I posted the driver fix first.
Glad we agree :)
I thought about it a little more and really convinced myself that there
is no good way for generic code to handle this race.
> So, will you apply it next?
Yes, will apply it shortly.
- R.
_
On Wed, 2008-05-07 at 18:54 +0200, Jochen Roth wrote:
> Carl,
>
> I applied your patch on Jeremy's latest kernel.org spufs tree.
>
> > +void oprofile_add_value(unsigned long value, int cpu) {
> > + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
>
> Shouldn't it be
> struct op
Carl,
I applied your patch on Jeremy's latest kernel.org spufs tree.
> +void oprofile_add_value(unsigned long value, int cpu) {
> + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
Shouldn't it be
struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
At least my com
I have _got_ to make CPU utilization enabled by default one of these
days :) At least for mechanisms which don't require calibration.
Heh, I've skipped the calibration chapter in the netperf manual. :-D
Should revert to it.
Under linux, the CPU utilization mechanism in netperf does not requ
On Wed, May 7, 2008 at 6:49 AM, Fabio Tosetto <[EMAIL PROTECTED]> wrote:
>
> I've tried to port my exesting configurations to the powerpc tree but some
> configurations files are missing.
First, create a new .dts file for your board in arch/powerpc/boot/dts.
(just copy the lite5200.dts file). Mo
On Wed, May 07, 2008 at 05:52:57PM +0200, André Schwarz wrote:
> Anton,
>
Much thanks for the information!
> we've just built a digital GigEVision camera based on a MPC8343 running
> at 266/400 csb/core speed.
>
> Transmission is done from a kernel module that allocates skb into which
> the i
On Wednesday 07 May 2008 17:32:03 Roland Dreier wrote:
> > We are not sure if this should be fixed in the driver or in uverbs itself.
> > Roland, what's your opinion about this?
>
> Would be nice to be able to fix it in uverbs but I don't see how. In
> particular a kernel consumer has to have t
Anton,
we've just built a digital GigEVision camera based on a MPC8343 running
at 266/400 csb/core speed.
Transmission is done from a kernel module that allocates skb into which
the image data is DMA'd by an external PCI master.
As soon as the image data is complete all buffers are sent out v
On Wed, May 7, 2008 at 8:22 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Takashi Iwai wrote:
>
> > This is a mmap of the data record to be shared in realtime with apps.
> > The app updates its data pointer (appl_ptr) on the mmapped buffer
> > while the driver updates the data (e.g. DMA position,
> We are not sure if this should be fixed in the driver or in uverbs itself.
> Roland, what's your opinion about this?
Would be nice to be able to fix it in uverbs but I don't see how. In
particular a kernel consumer has to have the same guarantee that no
async events will come in after destroy
Hi Sean,
> The code is GPLed but not currently available on the net. It is
> basically a little driver that registers a character device and
> then passes out the minor numbers to the PIKA board drivers.
>
> It was written to isolate all the character/sysfs code to one place
> since we have five d
Takashi Iwai wrote:
> This is a mmap of the data record to be shared in realtime with apps.
> The app updates its data pointer (appl_ptr) on the mmapped buffer
> while the driver updates the data (e.g. DMA position, called hwptr) on
> the fly on the mmapped record. Due to its real-time nature, it
I've tried to port my exesting configurations to the powerpc tree but
some configurations files are missing.
I need to set PSC3 - PSC4 in uart mode:
before in file *arch/ppc/platforms/lite5200.c* I added
struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
{ .id = 3,
On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote:
> While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
> task get blocked for more 120 seconds and does not proceeds future.
>
> The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
> syscalls.
On Tue, May 06, 2008 at 03:29:06PM -0500, Andy Fleming wrote:
>>>
>>> I've tried to tune gianfar driver in various ways... and it gave
>>> some positive results with this patch:
>>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>>> index fd487be..b5943f9 100644
>>> --- a/drivers/net/gi
On Tue, May 06, 2008 at 01:07:14PM -0700, Rick Jones wrote:
> Anton Vorontsov wrote:
>> Hi all,
>>
>> Down here few question regarding networking throughput, I would
>> appreciate any thoughts or ideas.
>>
>> On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
>> relatively low
While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
task get blocked for more 120 seconds and does not proceeds future.
The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
syscalls. Machine is stuck in the task, printing the following call trace
more than 50
On Wed, May 07, 2008 at 11:53:49AM +0100, David Woodhouse wrote:
> On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> > memcpy_from/to_io() use word aligned accesses on the io side of memory.
> > The MPC5200 local plus bus where our flashes are connected does not
> > allow unaligned accesses,
The eHEA driver uses the recently modified walk_memory_resource for powerpc
functionality to detect the memory layout. It further uses the memory hotplug
notifiers to catch memory hotplug events.
Signed-off-by: Hannes Hering <[EMAIL PROTECTED]>
---
diff -Nurp -X dontdiff linux-2.6.26-rc1/drivers/
The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG.
Signed-off-by: Hannes Hering <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f90a86b..181cd86 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2440,7 +2440,7 @@ config CHELSIO
This patch introduces two exports to allow modules to use memory notifiers.
Signed-off-by: Hannes Hering <[EMAIL PROTECTED]>
---
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 8ce6de5..937e825 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -53,11 +53,13 @@ int
Hi,
this patchset adds memory remove hotplug support for the ehea driver.
These patches apply against kernel 2.6.26-rc1.
Regards
Hannes
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
This is necessary because, in a multicore environment, a race between
uverbs async handler and destroy QP could occur.
Signed-off-by: Stefan Roscher
---
We are not sure if this should be fixed in the driver or in uverbs itself.
Roland, what's your opinion about this?
drivers/infiniband/hw/ehca
On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> memcpy_from/to_io() use word aligned accesses on the io side of memory.
> The MPC5200 local plus bus where our flashes are connected does not
> allow unaligned accesses, so we have to use the io versions of memcpy.
But this region of flash i
Hi.
I am doing a port from ppc to powerpc ARCH on sbc8260 based board.
The problem is, that I can't get SMC1 UART to work.
After SMC console is initialized.
cpm_uart_console_write() hangs here
/* Wait for transmitter fifo to empty.
* Ready indicates output is ready, and xmt is
> >
> > Thanks for your input. I think the name "fsl,MPIC-MSI" and
> > "fsl,IPIC-MSI"
> > is somethind specific.
>
> This is the third MSI-on-MPIC I've seen, and I doubt it will
> be the last. It is likely FSL will make some different one
> in the future, as well.
>
This is the first patch f
Hi Philippe,
On Wed, 7 May 2008 09:50:48 +0200 Philippe De Muyter <[EMAIL PROTECTED]> wrote:
>
> What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
> in the official kernel sources ? Should I send it to linuxppc-dev@ozlabs.org,
> lkml or somewhere else ?
linuxppc-dev w
Hi Andy,
On Tue, May 06, 2008 at 05:54:02PM -0500, Andy Fleming wrote:
>> Now back to the first an bigger problem :
>> currently, I have an "old" U-boot and I have written myself a dts file.
>>
>> Problem is : ethernet does not work, but that's not a mac-address problem,
>> but something else that
87 matches
Mail list logo
