On Mon, Aug 06, Benjamin Herrenschmidt wrote:
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in ohci_probe()?
---
drivers/ieee1394/ohci1394.c |2 ++
On Mon, 2007-08-06 at 15:51 +0200, Olaf Hering wrote:
On Mon, Aug 06, Benjamin Herrenschmidt wrote:
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space. (Although I don't know if there are such implementations
On Tue, 2007-08-07 at 00:22 +0200, Stefan Richter wrote:
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space.
On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
revisit this whenever an actual need arises.
Not sure this is a very good idea. This seems
Robert Hancock wrote:
Stefan Richter wrote:
So that's the story why that dma_set_mask went into sbp2: Sbp2 wants
mappings in a _subset_ of the OHCI-1394 controllers DMA range.
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the
Robert Hancock wrote:
I would agree, though, that sbp2 isn't really the place for setting
this, since the DMA mask is presently a property of the device, not of
the user..
The mask that sbp2 set was because sbp2 has (in theory, not yet in
practice) a _narrower requirement on address ranges
Benjamin Herrenschmidt wrote:
On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
revisit this whenever an actual need arises.
Not sure this is a very
Stefan Richter wrote:
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space. (Although I don't know if there are such
On Sun, 2007-08-05 at 09:54 +0200, Stefan Richter wrote:
Benjamin Herrenschmidt wrote:
If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
with the DMA implementation on that architecture. There are enough cards
out there that only support 32-bit DMA that this really needs
(Adding Cc: linuxppc-dev, olh)
Robert Hancock wrote:
Stefan Richter wrote:
Date: Wed, 1 Aug 2007 20:30:36 +0200 (CEST)
From: Stefan Richter [EMAIL PROTECTED]
Subject: ieee1394: revert sbp2: enforce 32bit DMA mapping
Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
with the DMA implementation on that architecture. There are enough cards
out there that only support 32-bit DMA that this really needs to work..
Yes, could the PPC folks please have a look at it? Thanks.
Smells like
12 matches
Mail list logo
