On Sat, Nov 03, 2007 at 02:05:39AM +0900, FUJITA Tomonori wrote:
> This patchset convert the PPC64 IOMMU to use the iova code for free
> area management.
>
> The IOMMUs ignores low level drivers' restrictions, the maximum
> segment size and segment boundary.
>
> I fixed the former:
>
> http://t
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote:
> > I'll keep rebasing sglist and the other branches I pull into for-akpm,
> > so you can just re-enable the for-akpm pull when the a) is true.
>
> Andi's tree is very out of date and is about to be damaged (to what
> extent I don't y
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > The Xen and Calgary bits are mutually exclusive, so hopefully (a)
> > will not be held up on account of the Xen merge (or for any other
> > reason... CalIOC2 machine
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> >
> > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> >
> > > > The Xen a
OTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote:
> > FYI, here's the Calgary diff on top of the outstanding Calgary
> > changes.
>
> When are these bits being merged into mainline? I'll hang on to this
> version for helping me rebase the arch bits of chained sglists once
> that happens
On Wed, Sep 26, 2007 at 05:57:57PM +0900, FUJITA Tomonori wrote:
> iommu code merges sg lists without considering lld's restrictions so
> some llds need a workaround to split sg lists again. This patchset
> fixes iommu to handle lld's max segment size limit properly.
The patches look reasonable t
On Fri, Sep 28, 2007 at 04:55:34PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 27, 2007 at 10:33:41PM -0400, Jeff Garzik wrote:
> >
> > Unless I'm missing something, the SMP request goes /to/ the PCI device :)
> >
> > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
>
> ACK; builds ok and SMP comm
On Sun, Sep 30, 2007 at 12:13:55AM -0700, Darrick J. Wong wrote:
> Actually, SMP commands are used during device discovery to find
> things attached to expanders, so it seems likely that "it blows up
> almost immediately after loading the module" symptoms are a result
> of this bug.
>
> That said
On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
> - Introduce a new enum dma_data_direction data_dir member in struct request.
> and remove the RW bit from request->cmd_flag
Some architecture use 'enum dma_data_direction' and some 'int
dma_data_direction'. The consensus was to mov
On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
> >> +static inline int dma_uni_dir(enum dma_data_direction dir)
> >> +{
> >> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
> >> + (dir == DMA_NONE);
> >> +}
> >
> > While this doesn't look very useful. Why is
On Fri, May 11, 2007 at 01:33:41PM -0500, James Bottomley wrote:
> Right at the moment, we're planning to clean up the way SCSI drivers
> process commands. The proposals are essentially:
>
> 1. Get rid of the now unnecessary map_single path (every command is
> either zero transfer or
12 matches
Mail list logo
