> > 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
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
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_off
> 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 ppc440s
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 P
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
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
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!
> >>
>
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:
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 w
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_ene
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 ++
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
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 g
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, use
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.
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 s
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]>
---
arch/powerpc/kerne
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 +-
> > drivers/net/phy/mdio-
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 a
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 20
On Wed, Nov 26, 2008 at 4:25 PM, Leon Woestenberg
<[EMAIL PROTECTED]> wrote:
> The non-detected end point boot:
>
> pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0
> PCI: Scanning bus 0001:81
> PCI: Fixups for bus 0001:81
>
Further debugging.
drivers/pci/probe.c:
static struct pci_
All,
we're running 2.6.27 on a MPC8343 cpu - nothing special so far.
With heavy system load I get a machine check exception on some boards
within 1-3 days leading to immediate reset.
U-Boot blames "Check Stop" causing the reset - I can also observe the
check_stop_out signal of the CPU being asse
On Wed, Nov 26, 2008 at 05:09:39PM +0100, Norbert van Bolhuis wrote:
>
> 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.
66MHz is the crystal frequency, but then clock generators
use
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 ty
On Thu, Oct 30, 2008 at 07:03:09PM -0700, Trent Piepho wrote:
> The device binding spec for OF GPIOs defines a flags field, but there is
> currently no way to get it. This patch adds a parameter to of_get_gpio()
> where the flags will be returned if non-NULL. of_get_gpio() in turn passes
> the pa
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 of
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,
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
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 inserti
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"
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.
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 m
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 MH
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 t
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
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 PROT
37 matches
Mail list logo