On Wednesday 26 November 2008, Paul Mackerras wrote:
This fixes it by moving the clearing of CR0.SO to after the
ACCOUNT_CPU_USER_ENTRY call in the system call entry path.
Thanks for taking care of this!
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL
Roland Dreier [EMAIL PROTECTED] wrote on 26.11.2008 00:13:51:
That's too bad... I applied this patch but out of curiousity, why
doesn't the hot-remove/hot-add work? I would have thought that
re-registering all of memory after the hot-add would do the right thing.
That's right, but right now,
Hello,
AMCC PPC460EX Canyonlands development board with PCI Express x1 card
in PCIe x4 slot labeled 'PCIE-1'. The PCI Express card has a
soft-programmable PCIe end point.
Problem: The end point with only non-prefetchable BAR does not appear
behind the PPC SoC internal bridge. It does show up on
Thanks for the answer, but that's not it.
I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.
It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333
Hello,
On Wed, Nov 26, 2008 at 3:20 PM, Norbert van Bolhuis
[EMAIL PROTECTED] wrote:
Thanks for the answer, but that's not it.
I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.
It must be
On Wed, 26 Nov 2008, Norbert van Bolhuis wrote:
Thanks for the answer, but that's not it.
I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.
It must be something else, I still think 83.20
On Fri, Nov 21, 2008 at 08:09:20AM -0700, Grant Likely wrote:
Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
Hey John, have you ever seen this sort of issue?
To keep you updated: It was the PHY which would drive the lines high if
the reset signal was too long.
Add RTS/CTS-support for the PSC of the MPC5200B. Tested with a Phytec
MPC5200B-IO.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
arch/powerpc/include/asm/mpc52xx_psc.h | 11 +++-
drivers/serial/mpc52xx_uart.c | 41 ---
2 files changed, 47
Hello,
I enabled more DEBUG output, the online files have been updated. Snippets:
The detected end point boot:
pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0
PCI: Scanning bus 0001:81
pci 0001:81:00.0: found [1a0b:5331] class 00ff00 header type 00
pci 0001:81:00.0: reg 10 64bit
ok, so it depends on the decrementer frequency
(which is 4166 on my system).
Btw. the main oscillator on my board is not 83.3 mhz,
it's 66 mhz as well.
Hmmm. so by using the decrementer for the clock tick/irqs
(which perfectly makes sense) the bogoMIPS value is
nonsense now. That's a pity,
Ensure that total memory size is page-aligned, because otherwise
mark_bootmem() gets upset.
This error case was triggered by using 64 KiB pages in the kernel while
arch/powerpc/boot/4xx.c arbitrarily reduced the amount of memory by 4096 (to
work around a chip bug that affects the last 256 bytes
From: Wolfgang Grandegger [EMAIL PROTECTED]
The patch fixes following build error:
CC drivers/mtd/nand/fsl_upm.o
drivers/mtd/nand/fsl_upm.c: In function 'fun_chip_init':
drivers/mtd/nand/fsl_upm.c:168: warning: passing argument 2 of
'of_mtd_parse_partitions' from incompatible pointer
This function sets the OCR mask bits according to provided voltage
ranges. Will be used by the mmc_spi OpenFirmware bindings.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Hi Pierre,
Sorry for the delay.
On Sat, Nov 08, 2008 at 09:55:37PM +0100, Pierre Ossman wrote:
On Thu, 30 Oct 2008
On Tue, Nov 25, 2008 at 3:45 PM, David Brownell [EMAIL PROTECTED] wrote:
No comment from me on $SUBJECT beyond it seems plausible, but ...
On Tuesday 25 November 2008, David VomLehn wrote:
The important point, though, is that device tree is the only
thing approaching a standard on any
From: Steven Rostedt [EMAIL PROTECTED]
Impact: fix to PowerPC code modification
After modifying code it is essential to flush the icache. This patch
adds the missing flush.
Reported-by: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
From: Steven Rostedt [EMAIL PROTECTED]
Impact: quicken mcount calls that are not replaced by dyn ftrace
Dynamic ftrace no longer does on the fly recording of mcount locations.
The mcount locations are now found at compile time. The mcount
function no longer needs to store registers and call a
From: Steven Rostedt [EMAIL PROTECTED]
Impact: clean up
Paul Mackerras pointed out that the code to determine if the branch
can reach the destination is incorrect. Michael Ellerman suggested
to pull out the code from create_branch and use that.
Simply using create_branch is probably the best.
Paul,
This patch series addresses the issues you brought up as well as
adds some more enhancements and fixes. This series is added on
top of the previous patch series.
The new patches are: (and are posted now)
5987225... powerpc/ppc32: static ftrace fixes for PPC32
382d6db... powerpc: ftrace,
From: Steven Rostedt [EMAIL PROTECTED](none)
Impact: fix for PowerPC 32 code
There were some early init code that was not safe for static
ftrace to boot on my PowerBook. This code must only use relative
addressing, and static mcount performs a compare of the
ftrace_trace_function pointer, and
From: Steven Rostedt [EMAIL PROTECTED]
Impact: clean up and robustness addition
This patch addresses the comments made by Paul Mackerras.
It removes the type casting between unsigned int and unsigned char
pointers, and replaces them with a use of all unsigned int.
Verification that the jump is
On Thu, Nov 27, 2008 at 08:38:51AM +1100, Paul Mackerras wrote:
[...]
drivers/mtd/nand/fsl_upm.c |2 +-
drivers/net/fs_enet/fs_enet-main.c |2 +-
drivers/net/phy/mdio-ofgpio.c |4 ++--
drivers/of/gpio.c | 13 ++---
On Thu, 27 Nov 2008, Paul Mackerras wrote:
Anton Vorontsov writes:
Can we apply it? Paul, Benjamin?
The patchwork url for this patch is:
http://patchwork.ozlabs.org/patch/6650/
Thanks!
drivers/mtd/nand/fsl_upm.c |2 +-
drivers/net/fs_enet/fs_enet-main.c |2 +-
On Wed, 26 Nov 2008, Steven Rostedt wrote:
From: Steven Rostedt [EMAIL PROTECTED](none)
Ah, I need to add GIT_AUTHOR on my PowerBook. And yes, it's name
is gollum ;-)
I'll fix this and push it again.
-- Steve
Impact: fix for PowerPC 32 code
There were some early init code that was not
On Wed, 26 Nov 2008, Steven Rostedt wrote:
Paul,
This patch series addresses the issues you brought up as well as
adds some more enhancements and fixes. This series is added on
top of the previous patch series.
The new patches are: (and are posted now)
5987225... powerpc/ppc32: static
On Wed, Nov 26, 2008 at 02:35:54PM -0800, Trent Piepho wrote:
On Thu, 27 Nov 2008, Paul Mackerras wrote:
Anton Vorontsov writes:
Can we apply it? Paul, Benjamin?
The patchwork url for this patch is:
http://patchwork.ozlabs.org/patch/6650/
Thanks!
drivers/mtd/nand/fsl_upm.c
Trent Piepho writes:
Alternatively you could add a new function (called, for instance,
of_get_gpio_flags) with the extra parameter to eliminate the need to
change any drivers at this stage, since they all seem to pass NULL for
the flags argument.
But if we did this every time any
Hello Ben,
On Friday, November 14, 2008 you wrote:
My understanding was that the dma-ranges property is responsible for
setting up the inbound ranges of RAM's physical addresses, where PCI
could DMA to/from. As regarding the outbound property, this patch
doesn't change this, and there
Hello Milton,
On Friday, November 14, 2008 you wrote:
On Nov 13, 2008, at 10:32 PM, Yuri Tikhonov wrote:
On Tuesday, November 11, 2008 Milton Miller wrote:
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
+#ifdef CONFIG_PPC_256K_PAGES
+#define PTE_SHIFT (PAGE_SHIFT
I've implemented (2) (the code is below), and it works. But,
admittedly, this (working) looks strange to me because of the
following:
To be able to use 64-bit PCI mapping on PPC32 I had to replace the
'unsigned long' type of pci_dram_offset with 'resource_size_t', which
on ppc440spe is
On Thursday, November 27, 2008 you wrote:
I've implemented (2) (the code is below), and it works. But,
admittedly, this (working) looks strange to me because of the
following:
To be able to use 64-bit PCI mapping on PPC32 I had to replace the
'unsigned long' type of pci_dram_offset with
Hello Dan,
On Saturday, November 15, 2008 you wrote:
A few comments
Thanks.
1/ I don't see code for handling cases where the src_cnt exceeds the
hardware maximum.
Right, actually the ADMA devices we used (ppc440spe DMA engines) has
no limitations on the src_cnt (well, actually there
Strange... when I look at pci4xx_parse_dma_ranges() I see it
specifically avoiding PCI addresses above 4G ... That needs fixing.
Right, it avoid. I guess you haven't read my e-mail to its end,
because my work-around patch, which I referenced there, fixes this :)
Ooops, I though I did
32 matches
Mail list logo
