On Mon, 27 Jul 2009 16:08:46 -0500
Becky Bruce wrote:
>
> On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
>
> > Signed-off-by: FUJITA Tomonori
>
> Fujita,
>
> Since you're removing all the uses of it, you should probably remove
> PPC_NEED_DMA_SYNC_OPS from arch/powerpc/Kconfig:
>
> d
So I opened powerpc-next, and pushed the pile that was in "test" (with
an additional bug fix to one of my patches that was causing the crash
at boot that mpe reported with hugetlbfs enabled).
The pre-req patch for adding an argument to __pte_free_tlb() has already
been merged upstream by Linus.
N
On Tue, Jul 28, 2009 at 10:17:40AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-27 at 12:11 -0700, Linus Torvalds wrote:
> > On Thu, 23 Jul 2009, Benjamin Herrenschmidt wrote:
> > >
> > > Hrm... my powerpc-next branch will contain stuff that depend on it, so
> > > I'll probably have to p
On Tue, 28 Jul 2009, Paul Mundt wrote:
>
> Yup, that seems to be what happened. I've never seen a warning about this
> with any compiler version, otherwise we would have caught this much
> earlier. As soon as the addr -> a rename took place it blew up
> immediately as a redefinition. Is there a m
On Mon, 2009-07-27 at 12:11 -0700, Linus Torvalds wrote:
>
> On Thu, 23 Jul 2009, Benjamin Herrenschmidt wrote:
> >
> > Hrm... my powerpc-next branch will contain stuff that depend on it, so
> > I'll probably have to pull it in though, unless I tell all my
> > sub-maintainers to also pull from th
vijay sharma wrote:
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
> output is available.
I have found that on my MPC8272 system running 2.6.28 & cuImage, the
/chosen/linux,stdout-path node is respected by the boot wrapper, but the
main kernel alw
On Mon, Jul 20, 2009 at 09:51:03PM +1000, Mark Ware wrote:
> This is another alloc_bootmem() -> kzalloc() change, this time to
> fix the non-fatal badness caused when booting with a cpm2_uart console.
>
> Signed-Off-By: Mark Ware
>
> ---
> drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +-
> 1
On Mon, Jul 20, 2009 at 12:06:42AM +0530, vijay sharma wrote:
> 2)Built cuImage and loaded it into memory. I am not seeing any output once
> control passes from wrapper to kernel. As you can see from logs mentioned
> above.
Try enabling early udbg console output. Also, make sure that Linux is
usi
(Adding cc:devicetree-discuss)
On Mon, Jul 27, 2009 at 2:15 PM, Eddie Dawydiuk wrote:
> Thanks for the link. Although, I'm not looking for info on optimizing
> boot time. Rather I'm looking for information on what the path of least
> resistance is to boot a kernel with an initrd being loaded from
On Mon, Jul 20, 2009 at 07:40:41PM +0200, Wolfgang Denk wrote:
> > zImage starting: loaded at 0x0190 (sp: 0x0fdc3a08)
> > Allocating 0x165ca04 bytes for kernel ...
> > gunzipping (0x <- 0x0190c000:0x02f58efc)...done 0x1637b54 bytes
>
> You loaded the image at 0190, but the uncompr4
On Mon, 2009-07-27 at 12:11 -0700, Linus Torvalds wrote:
>
> On Thu, 23 Jul 2009, Benjamin Herrenschmidt wrote:
> >
> > Hrm... my powerpc-next branch will contain stuff that depend on it, so
> > I'll probably have to pull it in though, unless I tell all my
> > sub-maintainers to also pull from th
On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
Signed-off-by: FUJITA Tomonori
Fujita,
Since you're removing all the uses of it, you should probably remove
PPC_NEED_DMA_SYNC_OPS from arch/powerpc/Kconfig:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0603b6c..fb3f4
On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
This converts uses dma_map_ops struct (in include/linux/dma-mapping.h)
instead of POWERPC homegrown dma_mapping_ops.
Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce
---
arch/powerpc/include/asm/device.h |4 +-
arch/power
On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
POWERPC needs this hook. SPARC could use it too.
Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce
---
include/linux/dma-mapping.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h
On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
Now swiotlb_pci_dma_ops is identical to swiotlb_dma_ops; we can use
swiotlb_dma_ops with any devices. This removes swiotlb_pci_dma_ops.
Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce
---
arch/powerpc/include/asm/swiotlb.h
On Jul 23, 2009, at 10:24 PM, FUJITA Tomonori wrote:
This patch adds max_direct_dma_addr to struct dev_archdata to remove
addr_needs_map in struct dma_mapping_ops. It also converts
dma_capable() to use max_direct_dma_addr.
max_direct_dma_addr is initialized in pci_dma_dev_setup_swiotlb(),
call
Wolfgang,
In message <4a6ddf80@embeddedarm.com> you wrote:
I'm working on a custom board using an AMCC 440EP that is using a proprietary
bootloader(optimized for fast boot time). Currently our bootloader loads a
simpleImage.initrd into RAM and jumps into it. I originally chose to use a
si
On Thu, 23 Jul 2009, Benjamin Herrenschmidt wrote:
>
> Hrm... my powerpc-next branch will contain stuff that depend on it, so
> I'll probably have to pull it in though, unless I tell all my
> sub-maintainers to also pull from that other branch first :-)
Ok, I'll just apply the patch. It does lo
We've got some people that are currently running an older linux kernel
(from before the ppc/ppc64 merge and the conversion to device tree) on
an Emerson/Motorola cpci6115 (also known as mcpn905) compactPCI board.
They're wondering if it's possible to upgrade to a more recent kernel.
I don't see s
Dear Eddie Dawydiuk,
In message <4a6ddf80@embeddedarm.com> you wrote:
>
> I'm working on a custom board using an AMCC 440EP that is using a proprietary
> bootloader(optimized for fast boot time). Currently our bootloader loads a
> simpleImage.initrd into RAM and jumps into it. I originally
Hello,
I'm working on a custom board using an AMCC 440EP that is using a proprietary
bootloader(optimized for fast boot time). Currently our bootloader loads a
simpleImage.initrd into RAM and jumps into it. I originally chose to use a
simpleImage with an initial ramdisk embedded because it was
I found a patch for kexec on Booke in the archives:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-November/064798.html
In this pacth , we use an entry to setup a 1:1 mapping , whose size
is 1GB. However, in e500, the max mapping size for
a single entry is 256M. So I have to setup 4 entri
Linas Vepstas wrote on 07/24/2009 05:30:09 PM:
> 2009/7/24 Richard Lary :
> > Linas Vepstas wrote on 07/23/2009 07:44:33 AM:
> >
> >> 2009/7/15 Mike Mason :
> >> > By default, EEH does what's known as a "hot reset" during error
recovery
> >> > of
> >> > a PCI Express device. We've found a ca
On Jul 26, 2009, at 10:34 AM, wilbur.chan wrote:
e500 , in head_fsl_booke.S
We know,the first two steps are:
1) invalidate all entries except the entry we are in
2) setup a temp mapping and jump to it respectively:
tlbwe
bl 1f
1: mflr r9
rlwimi r7,r9,0,
On Mon, 2009-07-27 at 14:14 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> I've started collecting things for my -next branch. For now I put
> everything in -test, I'll move it over to -next in the upcoming couple
> of days if there's no major issue found.
I'm seeing this on Power 6 (Didgo3), ha
25 matches
Mail list logo
