linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Robert Hancock <hancockr@shaw.ca>,
	linuxppc-dev@ozlabs.org, stable@kernel.org,
	linux-kernel@vger.kernel.org, Olaf Hering <olh@suse.de>
Subject: Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA	mapping"
Date: Mon, 06 Aug 2007 08:04:33 +1000	[thread overview]
Message-ID: <1186351473.938.21.camel@localhost.localdomain> (raw)
In-Reply-To: <46B5824B.1000103@s5r6.in-berlin.de>

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 to work..
> >> Yes, could the PPC folks please have a look at it?  Thanks.
> > 
> > Smells like we may have a bug there. No worries though, all current PPC
> > machines have an iommu that will not give out addresses above 32 bits
> > anyway, but I'll double check what's up.
> > 
> > Do you see something in dmesg when that happens ?
> 
> There was nothing in Olaf's report, except for trouble in sbp2 _after_
> the failure.  http://lkml.org/lkml/2007/8/1/344  (I don't have a PMac.)

Hrm, allright, that's a bit weird. Olaf machine has only 256M of RAM
according to that dmesg, and thus, the kernel isn't enabling the iommu,
we use the "trivial" version of the dma mapping ops.

I suspect we have a bug in our imlementation of set_dma_mask though, in
that it does the "dma_supported" check using the previous mask and not
the one passed in :-)

The implementation of dma_supported that we hit in the no-iommu case
looks like that:

static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
	/* Could be improved to check for memory though it better be
	 * done via some global so platforms can set the limit in case
	 * they have limited DMA windows
	 */
	return mask >= DMA_32BIT_MASK;
}

So that should have worked. (The comment is a bit obscure, just ignore
it for now).

However, as I said above, our dma_set_mask() wrapper uses the wrong
value (the old, not the new mask). But that still should have worked
since the default dma mask for a PCI device is 0xffffffff....

Thus at this stable, I'm a bit at a loss of why it didn't work, I'll
have to test on one of those machines with some printk's in when I
manage to get to work (dunno when, kid's sick so I may have to stay home
today).

BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?

Cheers,
Ben.

  reply	other threads:[~2007-08-05 22:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.Qn3Snqoik3hhnxcA6HqjGV0Yzck@ifi.uio.no>
     [not found] ` <46B4B3DC.7020609@shaw.ca>
2007-08-04 17:30   ` [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping" Stefan Richter
2007-08-05  0:15     ` Benjamin Herrenschmidt
2007-08-05  7:54       ` Stefan Richter
2007-08-05 22:04         ` Benjamin Herrenschmidt [this message]
2007-08-06 13:51           ` Olaf Hering
2007-08-06 21:47             ` Benjamin Herrenschmidt
2007-08-06 22:22               ` Stefan Richter
2007-08-06 22:25                 ` Robert Hancock
2007-08-06 22:32                   ` Benjamin Herrenschmidt
2007-08-06 22:35                     ` Robert Hancock
2007-08-06 22:59                       ` Stefan Richter
2007-08-06 22:48                   ` Stefan Richter
2007-08-07  2:18                     ` Andi Kleen
2007-08-06 22:29                 ` Benjamin Herrenschmidt
2007-08-06 11:58         ` Olaf Hering
2007-08-06 21:43           ` Benjamin Herrenschmidt
2007-08-06 22:05             ` [PATCH] powerpc: Fix initialization and usage of dma_mask Benjamin Herrenschmidt
2007-08-06 22:30               ` Olaf Hering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1186351473.938.21.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=olh@suse.de \
    --cc=stable@kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).