On Oct 14, 2008, at 7:05 AM, Benjamin Herrenschmidt wrote:
On Tue, 2008-10-14 at 06:24 -0400, Josh Boyer wrote:
I pointed out to Stephen that kisskb.ellerman.id.au hasn't been
updating.. there is a chrp32 defconfig in there that would
normally
catch something like this.
Except if kissb cat
On Tue, 2008-10-14 at 06:24 -0400, Josh Boyer wrote:
> > I pointed out to Stephen that kisskb.ellerman.id.au hasn't been
> > updating.. there is a chrp32 defconfig in there that would
> normally
> > catch something like this.
>
> Except if kissb catches it, it's already committed in tree. Bet
On Mon, 13 Oct 2008 20:52:25 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Oct 13, 2008, at 6:30 PM, Benjamin Herrenschmidt wrote:
>
> > On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote:
> >>> I don't think it matters much when it gets fixed, pre or post -rc1.
> >>> But
> >>> it should p
On Oct 13, 2008, at 6:30 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote:
I don't think it matters much when it gets fixed, pre or post -rc1.
But
it should probably get fixed. My hack was to pull isa_bridge_pcidev
into pci-common.c and export it from ther
On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote:
> > I don't think it matters much when it gets fixed, pre or post -rc1.
> > But
> > it should probably get fixed. My hack was to pull isa_bridge_pcidev
> > into pci-common.c and export it from there. The 64-bit PCI code can
> > initialized i
On Mon, 2008-10-13 at 14:21 -0400, Josh Boyer wrote:
> I don't think it matters much when it gets fixed, pre or post -rc1. But
> it should probably get fixed. My hack was to pull isa_bridge_pcidev
> into pci-common.c and export it from there. The 64-bit PCI code can
> initialized it, and the 32-
While doing a buildall this morning, I notice chrp32_defconfig
fails
to build with:
drivers/built-in.o: In function `hard_dma_setup':
floppy.c:(.text+0x6e40e): undefined reference to
`isa_bridge_pcidev'
floppy.c:(.text+0x6e412): undefined reference to
`isa_bridge_pcidev'
floppy.c:(.text+0
On Mon, 13 Oct 2008 13:06:36 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Oct 13, 2008, at 10:41 AM, Josh Boyer wrote:
>
> > On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:
> >> On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
> >>> We essentially adopt the 64-bit d
On Oct 13, 2008, at 10:41 AM, Josh Boyer wrote:
On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:
On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
We essentially adopt the 64-bit dma code, with some changes to
support
32-bit systems, including HIGHMEM. dma functions o
On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:
>On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
>>We essentially adopt the 64-bit dma code, with some changes to support
>>32-bit systems, including HIGHMEM. dma functions on 32-bit are now
>>invoked via accessor functions w
On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
>We essentially adopt the 64-bit dma code, with some changes to support
>32-bit systems, including HIGHMEM. dma functions on 32-bit are now
>invoked via accessor functions which call the correct op for a device based
>on archdata dma_ops
We essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a device based
on archdata dma_ops. If there is no archdata dma_ops, this defaults
to dma_direct_o
12 matches
Mail list logo
