This patch makes a couple of small cleanups to parameter checking of
libfdt functions.
- In several functions which take a node offset, we use an
idiom involving fdt_next_tag() first to check that we have indeed been
given a node offset. This patch adds a helper function
_fdt_check_node_o
Binding document adding for Freescale MSI support.
Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version, per Kumar's suggestion,
Change the compatile name like "fsl,CHIP-msi", "fsl,mpic-msi"/"fsl,ipic-msi".
Documentation/powerpc/booting-without-of.txt | 43 +++
This patch enabled MSI on 8544ds and 8572ds board.
So far only one MSI interrupt can generate on 8544 board.
Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version,
Change the compatible name in dts file.
arch/powerpc/boot/dts/mpc8544ds.dts | 16
arch/powerpc/
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for
This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.
Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version,
Change the compatible name in dts.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16
Hi Stephen,
The next-20080520 kernel build fails on powerpc, when build the randconfig with
build error message
CC arch/powerpc/kernel/prom_init.o
CALLarch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'kernstart_addr' referenced from prom_ini
Hi everybody,
I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
and synchronized to a ntp server.
I noticed that my rtc chip does not get updated by the kernel, just like
it would be on all other architectures (included ppc).
Looking at the differences between ./arch/pow
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of small fixes and a defconfig update for
powerpc, plus an update to MAINTAINERS for the Cell port.
Thanks,
Paul.
MAINTAINERS|
Philippe De Muyter writes:
> I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
> and synchronized to a ntp server.
>
> I noticed that my rtc chip does not get updated by the kernel, just like
> it would be on all other architectures (included ppc).
That is now supposed t
On Tue, May 20, 2008 at 02:04:13PM +1000, Stephen Rothwell wrote:
> Hi Anton,
>
> On Mon, 19 May 2008 21:46:55 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/sysdev/qe_lib/usb.c
>
> > +#include
>
> Nothing in this file requires anything in linux/of.h or asm/of.h ...
On Mon, 19 May 2008 21:19:50 +0400
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 07:09:00PM +0200, Gary Jennejohn wrote:
[snip extraneous content]
> > My problem was, and is, that there's no generic GPIO support for powerpc.
> > At least, not that I'm aware of. Please tell
On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:
[...]
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 3934e26..e5d3366 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -538,6 +538,11 @@ config FSL_LBC
>> help
>>Freescale Localbus
On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:
>
> On May 19, 2008, at 12:46 PM, Anton Vorontsov wrote:
>
>> GTM stands for General-purpose Timers Module and able to generate
>> timer{1,2,3,4} interrupts. These timers are used by the drivers that
>> need time precise interrupts (like f
On Tue, 2008-05-20 at 16:25 +0530, Kamalesh Babulal wrote:
> Hi Stephen,
>
> The next-20080520 kernel build fails on powerpc, when build the randconfig
> with
> build error message
> CC arch/powerpc/kernel/prom_init.o
> CALLarch/powerpc/kernel/prom_init_check
Since commit "85xx: Add support for relocatable kernel (and
booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
and FLATMEM is enabled.
PHYSICAL_START is used in prom_init.c and so kernstart_addr
needs to be added to the lis
At Mon, 19 May 2008 19:23:10 +0200,
Giuseppe Coviello wrote:
>
> On mer, 14/05/2008 14.26 +0200, Takashi Iwai wrote:
> [cut]
> > OK, here is another patch for testing. Since I lost my old patch
> > somewhere (and it's not worth to dig the archive), I wrote it up
> > quickly from scratch. This ve
Hi David,
On Tuesday 20 May 2008 02:25, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> >
> > The implementation is based on the GPIO lib. Modem control lines are
> > described
On Mon, 19 May 2008 17:20:47 +0200
Giuseppe Coviello <[EMAIL PROTECTED]> wrote:
> + [EMAIL PROTECTED] {
> + compatible = "ohci-be";
> + reg = ;
> + interrupts = <8 4 9 4>;
> +
On Tuesday 20 May 2008 02:31, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > Or maybe some kind of gpio_set_option() with flags specific to the
> > controller ? This could be used to enable open-drain outputs or internal
> > pull-ups for instance.
>
> That presumes
On May 20, 2008, at 7:48 AM, Michael Ellerman wrote:
Since commit "85xx: Add support for relocatable kernel (and
booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
and FLATMEM is enabled.
PHYSICAL_START is used in prom_
+void __init fsl_gtm_init(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,gtm") {
+ int i;
+ struct gtm *gtm;
+ const u32 *clock;
+ int size;
+
+ gtm = kzalloc(sizeof(*gtm), GFP_KERNEL)
On May 20, 2008, at 7:41 AM, Anton Vorontsov wrote:
On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:
On May 19, 2008, at 12:46 PM, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the driv
On Wednesday 14 May 2008 16:48, Brian King wrote:
>
> Fixes the following use after free oops:
>
> ehea: Reboot: freeing all eHEA resources
> Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6c5b
> Faulting instruction address: 0xd0354488
> cpu 0x0: Vector: 300 (Da
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/
powerpc/platforms/86xx/mpc8610_hpcd.c
index dea1320..290d717 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
On Tue, 20 May 2008 07:50:28 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Mon, 19 May 2008 17:20:47 +0200
> Giuseppe Coviello <[EMAIL PROTECTED]> wrote:
>
>
> > + [EMAIL PROTECTED] {
> > + compatible = "ohci-be";
> > + reg
Michael Ellerman wrote:
> On Mon, 2008-05-19 at 10:56 -0500, Dave Boutcher wrote:
>> On Mon, 19 May 2008 10:27:56 -0500, Brian King <[EMAIL PROTECTED]> said:
>>> Some versions of the Virtual I/O Server on Power
>>> return 0x99 in the non-SCSI error status field as success,
>>> rather than 0. This f
On Wed, 2008-05-14 at 23:49 -0400, Steven Rostedt wrote:
> plain text document attachment (ftrace-powerpc-port.patch)
> This patch adds full support for ftrace for PowerPC (both 64 and 32 bit).
> This includes dynamic tracing and function filtering.
Hi Steven,
Just a few comments inline ..
> Ind
CCing lkml
On Tue, May 20, 2008 at 09:10:25PM +1000, Paul Mackerras wrote:
> Philippe De Muyter writes:
>
> > I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
> > and synchronized to a ntp server.
> >
> > I noticed that my rtc chip does not get updated by the kernel, ju
On Tue, May 20, 2008 at 08:15:15AM -0500, Kumar Gala wrote:
[...]
+ for_each_compatible_node(np, NULL, "fsl,gtm") {
+ int i;
+ struct gtm *gtm;
+ const u32 *clock;
+ int size;
+
+ gtm = kzalloc(sizeof(*gtm), GFP_KERNEL
>
> Why do we not want to trace early boot? Just because it's not useful?
Not running at the linked address... might be causing trouble.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
This is explained in the .c file with a kernel doc. Basically the
difference is that timer16 could silently crop the precision, while
utimer16 could not thus explicitly accepts u16 argument (max. timer
interval with usec precision fits in u16).
Maybe I'm confused what the utility is of cropping
On Tue, May 20, 2008 at 7:15 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>> There (and in the QE GPIO) was an arch_initcall, but based on
>> Grant Likely's review it was removed in favour of platform-specific
>> machine_initcalls.
>>
>> See http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg16469
Hi All,
The following patches have been added to the next branch of the 4xx
tree. I plan on letting them sit in there for a few days and then
asking Paul to pull into his tree. That way if I've screwed something
up only poor Stephen will get hit by it and I can fix things without
causing major p
On Wed, 21 May 2008, Michael Ellerman wrote:
> On Wed, 2008-05-14 at 23:49 -0400, Steven Rostedt wrote:
> > plain text document attachment (ftrace-powerpc-port.patch)
> > This patch adds full support for ftrace for PowerPC (both 64 and 32 bit).
> > This includes dynamic tracing and function filte
On Tue, May 20, 2008 at 09:20:50AM -0500, Kumar Gala wrote:
> This is explained in the .c file with a kernel doc. Basically the
difference is that timer16 could silently crop the precision, while
utimer16 could not thus explicitly accepts u16 argument (max. timer
interval with us
Thank-You Kim,
That got me beyond where I was.
It's now having problems with the SATA setup, but I will stare at
that for a while, and see if there is anything on the mailing list about
it.
It actually made it past the PCI Scan which was one of the
key things I needed to see anyw
On Tue, May 20, 2008 at 06:32:34PM +0400, Anton Vorontsov wrote:
> On Tue, May 20, 2008 at 09:20:50AM -0500, Kumar Gala wrote:
> > This is explained in the .c file with a kernel doc. Basically the
> difference is that timer16 could silently crop the precision, while
> utimer16 could n
Anton Vorontsov wrote:
> Btw, this is silent config, selected by the board's Kconfig
> (same as QE block, for example). So "depends on" here is just
> no-op, since select disregards dependencies. Still want this?
FYI, I have plans to modify the Kconfigs so that CONFIG_QUICC_ENGINE is
user-selecta
Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)
I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)
Unable to handle kernel paging request for data at address 0x00
Hi
When booting v2.6.25.4-rt1 (PREEMPT-RT) on my 8280 CPU with 1 GB RAM, I
get the following oopses.
They both are caused by a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h).
If I boot with mem=512M or mem=768M they do not appear.
Any help is greatly appreciated.
Oops: Exception in kerne
On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:
> > Why do we not want to trace early boot? Just because it's not useful?
>
> Not running at the linked address... might be causing trouble.
I figured it was something like that, so I didn't look too deep into it,
and decided that it was best ju
Rune Torgersen wrote:
> Hi
> I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
> 8280 CPU (arch/powerpc)
>
> I get the follwing oops when trying to enable ethernet:
> (looks like a null pointer dereference in
> drivers/net/fs_enet/fs_enet-main.c:106)
And if I disable NAPI I ge
On Mon, 19 May 2008, Grant Likely wrote:
> I'm not so fond of this approach. cs-parent doesn't seem to make much
> sense to me. It might be better to have a cs-handler property on the
> SPI bus node instead of on the SPI slave nodes, but even then it
> leaves a number of questions about what it
Hello,
I am trying to figure out how to configure the virtual memory layout in
the kernel.
To increase the size of the Vmalloc area, I have set KERNEL_START to
0xa000 and have left LOWMEM_SIZE at 0x3000. The other parameters
in 'Advanced setup' are unchanged.
This works fine with 512 MB of
Rune Torgersen wrote:
0xc0196d84 is in fs_enet_interrupt
(drivers/net/fs_enet/fs_enet-main.c:473).
468 if (fpi->use_napi)
469 int_clr_events &= ~fep->ev_napi_rx;
470
471 (*fep->ops->clear_int_events)(dev,
int_clr_events);
472
473
On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Mon, 19 May 2008, Grant Likely wrote:
>
>> I'm not so fond of this approach. cs-parent doesn't seem to make much
>> sense to me. It might be better to have a cs-handler property on the
>> SPI bus node instead o
Hi Mr Kumar
Sorry for replying so late.
I have tested the USB on the linux kernel 2.6.25 , but its not working.
Please suggest, Is this beacause of the PCI-Express Bug ??
With Regards
John--- On Thu, 4/17/08, John Marc <[EMAIL PROTECTED]> wrote:
From: John Marc <[EMAIL PROTECTED]>Subject: Re:
On May 20, 2008, at 10:56 AM, John Marc wrote:
Hi Mr Kumar
Sorry for replying so late.
I have tested the USB on the linux kernel 2.6.25 , but its not
working.
Please suggest, Is this beacause of the PCI-Express Bug ??
With Regards
John
Can you describe again, what doesn't work mean
Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>> 470 471 (*fep->ops->clear_int_even
Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>> 470 471 (*fep->ops->clear_int_even
Rune Torgersen wrote:
Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?
s/incomplete/nonexistent/ :-P
Try acquiring port->lock in cpm_uart_console_write.
-Scott
_
Scott Wood wrote:
> Rune Torgersen wrote:
>> Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
>> Incomplete locking between printk and userland use of ttyCPM1 as
>> console?
>
> s/incomplete/nonexistent/ :-P
>
> Try acquiring port->lock in cpm_uart_console_write.
>
> -Scott
That w
On Tue, 2008-05-20 at 11:13 +1000, David Gibson wrote:
> On Mon, May 19, 2008 at 05:00:23PM -0700, Remi Machet wrote:
> > Support for the C2K cPCI Single Board Computer from GEFanuc
> > (PowerPC MPC7448 with a Marvell MV64460 chipset)
> > All features of the board are not supported yet, but the boa
Timur Tabi wrote:
Kim Phillips wrote:
On Mon, 19 May 2008 22:57:29 + (UTC)
Gary Hannon <[EMAIL PROTECTED]> wrote:
Am I missing a flag on the dtc?
try adding -R 8 -S 0x3000 to the dtc command line.
Maybe we should be making this the default for dtc? After all, it's needed for
any moder
I am currently doing port for already working PQ2 board (MPC8270) from "ppc" to
"powerpc" architecture.
When initial port took place, the driver i2c-cpm that appeared on linuxppc list
in the beginning of 2006 was used,
and it is working perfectly all this time.
However, when I am trying to use
Scott Wood wrote:
> How about fixing u-boot's deficiencies in u-boot? It knows better than
> dtc how much extra space it's going to need.
Then what's the point of the -R and -S options if U-boot doesn't really need
them?
This sounds like another example of a bug in U-Boot that everyone knows
Kim Phillips wrote:
> On Mon, 19 May 2008 22:57:29 + (UTC)
> Gary Hannon <[EMAIL PROTECTED]> wrote:
>
>
>> Am I missing a flag on the dtc?
>
> try adding -R 8 -S 0x3000 to the dtc command line.
Maybe we should be making this the default for dtc? After all, it's needed for
any modern U-boot
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part
On May 20, 2008, at 11:31 AM, Rune Torgersen wrote:
Scott Wood wrote:
Rune Torgersen wrote:
Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?
s/incomplete/nonexistent/ :-P
Try acquiring port->lock in cpm
Kumar Gala wrote:
>> Rune Torgersen wrote:
>> That worked. Console output is sane again.
>
> I'm hoping to see some patches related to these fixes :)
Working on it.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinf
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch/powerpc/platforms/82xx/
Rune Torgersen wrote:
Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch
On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote:
> Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
> Userland usage of console, and kernel printf's were stepping on each others
> toes.
>
> Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
>
> diff --git a/drive
Update the defconfig for the Freescale MPC8610 HPCD board. Enable module
support. Disable support for all NICs except for the on-board ULI526x.
Enable support for the Freescale DIU driver. Increase the maximum zone order
to 12, so that the DIU driver can allocate physically-contiguous 5MB buffer
Scott Wood wrote:
> On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote:
>> Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
>> Userland usage of console, and kernel printf's were stepping on each
>> others toes.
>>
>
> We should bypass the lock when oops_in_progres
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Also only take lock if not in an oops.
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/d
Rune Torgersen wrote:
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Also only take lock if not in an oops.
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
Acked-by: Scott Wood <[EMAIL PRO
Update the defconfig for the Freescale MPC8610 HPCD board. Enable module
support. Disable support for all NICs except for the on-board ULI526x.
Enable support for the Freescale DIU driver. Increase the maximum zone order
to 12, so that the DIU driver can allocate physically-contiguous 5MB buffer
Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated
for the in_beXX() and out_beXX() mmio functions has been sub-optimal.
The out_leXX() family of functions are created with the macro
DEF_MMIO_OUT_LE() while the out_beXX() family are created with
DEF_MMIO_OUT_BE(). In what wa
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part
On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:
> There was some discussion on a Freescale list if the powerpc I/O accessors
> should be strictly ordered w.r.t. normal memory. Currently they are not. It
> does not appear as if any other architecture's I/O accessors are strictly
> ordered
Benjamin Herrenschmidt wrote:
On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:
There was some discussion on a Freescale list if the powerpc I/O accessors
should be strictly ordered w.r.t. normal memory. Currently they are not. It
does not appear as if any other architecture's I/O access
Trent Piepho <[EMAIL PROTECTED]> writes:
> For the LE versions, eventually they boil down to an asm that will look
> something like this:
> asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
>
> While not perfect, this appears to be the best one can do. The issue is
> that the "s
On Tue, 2008-05-20 at 16:38 -0500, Scott Wood wrote:
> It looks like we rely on -fno-strict-aliasing to prevent reordering
> ordinary memory accesses (such as to DMA descriptors) past the I/O
> access. It won't prevent reordering of memory reads around an I/O
> read,
> though, which could be a
On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:
There was some discussion on a Freescale list if the powerpc I/O accessors
should be strictly ordered w.r.t. normal memory. Currently they are not. It
does not appear as if any other arch
On Wed, 21 May 2008, Andreas Schwab wrote:
Trent Piepho <[EMAIL PROTECTED]> writes:
For the LE versions, eventually they boil down to an asm that will look
something like this:
asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
While not perfect, this appears to be the best on
On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-05-20 at 16:38 -0500, Scott Wood wrote:
It looks like we rely on -fno-strict-aliasing to prevent reordering
ordinary memory accesses (such as to DMA descriptors) past the I/O
access. It won't prevent reordering of memory reads arou
Alan Cox wrote:
It looks like we rely on -fno-strict-aliasing to prevent reordering
ordinary memory accesses (such as to DMA descriptors) past the I/O
DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviou
From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:35:56 -0500
> Alan Cox wrote:
> >> It looks like we rely on -fno-strict-aliasing to prevent reordering
> >> ordinary memory accesses (such as to DMA descriptors) past the I/O
> >
> > DMA descriptors in main memory are dependant on c
David Miller wrote:
From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:35:56 -0500
Alan Cox wrote:
It looks like we rely on -fno-strict-aliasing to prevent reordering
ordinary memory accesses (such as to DMA descriptors) past the I/O
DMA descriptors in main memory are dependant o
Trent Piepho <[EMAIL PROTECTED]> writes:
> It's the _le versions that have a problem, since we can't get gcc to just use
> the register indexed mode. It seems like an obvious thing to have a
> constraint for, but I guess there weren't enough instructions that only come
> in 'x' versions to bother
From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:43:58 -0500
> David Miller wrote:
> > The __volatile__ in the asm construct disallows movement of the
> > inline asm relative to statements surrounding it.
> >
> > The only reason barrier() in kernel.h needs a memory clobber is
> > be
> It looks like we rely on -fno-strict-aliasing to prevent reordering
> ordinary memory accesses (such as to DMA descriptors) past the I/O
DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviour.
Alan
_
On Tue, 20 May 2008, Scott Wood wrote:
Alan Cox wrote:
> It looks like we rely on -fno-strict-aliasing to prevent reordering
> ordinary memory accesses (such as to DMA descriptors) past the I/O
DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators s
On Wed, 21 May 2008, Andreas Schwab wrote:
Trent Piepho <[EMAIL PROTECTED]> writes:
It's the _le versions that have a problem, since we can't get gcc to just use
the register indexed mode. It seems like an obvious thing to have a
constraint for, but I guess there weren't enough instructions th
[POWERPC]: Uniformly use memstart_addr as the start address of RAM
The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in functions: mapin_ram(pgtable_32.c) and
cam_mapin_ram(fsl_booke_mmu.c), ho
On May 20, 2008, at 8:38 PM, Andrew Liu wrote:
[POWERPC]: Uniformly use memstart_addr as the start address of RAM
The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in functions: mapin_ram(pg
Kumar Gala wrote:
On May 20, 2008, at 8:38 PM, Andrew Liu wrote:
[POWERPC]: Uniformly use memstart_addr as the start address of RAM
The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in fun
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 20, 2008 9:24 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board
>
> > diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.
On May 20, 2008, at 10:29 PM, Jin Zhengxiong wrote:
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 20, 2008 9:24 PM
To: Jin Zhengxiong
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board
diff --git a/arc
Andrew Liu writes:
> You know we can't make sure in future the start address of all incoming
> boards' RAM is 0, especially, in AMP system, different cpu uses the different
> RAM area,
> definitely, the start address of some is not 0.
Any processor that uses ppc_mmu_32.c will have interrupt ve
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 21, 2008 11:39 AM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board
>
>
> On May 20, 2008, at 10:29 PM, Jin Zhengxiong wrote
Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in
this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/
Michael Ellerman wrote:
> Since commit "85xx: Add support for relocatable kernel (and
> booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
> PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
> and FLATMEM is enabled.
>
> PHYSICAL_START is used in prom_init.c and so kernsta
95 matches
Mail list logo
