All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: khc@pm.waw.pl, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?)
Date: Sat, 14 Aug 2010 19:46:05 +0100	[thread overview]
Message-ID: <20100814184605.GA1999@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20100814181306U.fujita.tomonori@lab.ntt.co.jp>

On Sat, Aug 14, 2010 at 06:30:37PM +0900, FUJITA Tomonori wrote:
> On Fri, 13 Aug 2010 22:54:13 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >  This means that when dmabounce comes to allocate the replacement
> > buffer, it gets a buffer which won't be accessible to the DMA
> > controller
> 
> Really? looks like dmabounce does nothing for coherent memory that
> dma_alloc_coherent() allocates.
> 
> The following very hacky patch works?

So what happens if you use a driver which uses dma_alloc_coherent()
directly?  Should the driver really be passed memory which is
inaccessible to the device because its outside the host bridge PCI
window?

No, this is clearly wrong, so this patch doesn't fix anything.  It's
a bodge, nothing more.  The real solution is to have _both_ masks
both reduced down according to the host bridge, as we used to do.

So I suggest 6fee48c is reverted so that these platforms don't regress
for -rc1.

As I said when you sent the originally patch, it _looked_ okay, but I
don't have any way to test it.  It seems from testing (which
unfortunately only seems to only happen after patches hit mainline)
that it is not okay after all.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?)
Date: Sat, 14 Aug 2010 19:46:05 +0100	[thread overview]
Message-ID: <20100814184605.GA1999@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20100814181306U.fujita.tomonori@lab.ntt.co.jp>

On Sat, Aug 14, 2010 at 06:30:37PM +0900, FUJITA Tomonori wrote:
> On Fri, 13 Aug 2010 22:54:13 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >  This means that when dmabounce comes to allocate the replacement
> > buffer, it gets a buffer which won't be accessible to the DMA
> > controller
> 
> Really? looks like dmabounce does nothing for coherent memory that
> dma_alloc_coherent() allocates.
> 
> The following very hacky patch works?

So what happens if you use a driver which uses dma_alloc_coherent()
directly?  Should the driver really be passed memory which is
inaccessible to the device because its outside the host bridge PCI
window?

No, this is clearly wrong, so this patch doesn't fix anything.  It's
a bodge, nothing more.  The real solution is to have _both_ masks
both reduced down according to the host bridge, as we used to do.

So I suggest 6fee48c is reverted so that these platforms don't regress
for -rc1.

As I said when you sent the originally patch, it _looked_ okay, but I
don't have any way to test it.  It seems from testing (which
unfortunately only seems to only happen after patches hit mainline)
that it is not okay after all.

  reply	other threads:[~2010-08-14 18:46 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 20:36 ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?) Krzysztof Halasa
2010-08-10 20:36 ` Krzysztof Halasa
2010-08-11  2:06 ` FUJITA Tomonori
2010-08-11  2:06   ` FUJITA Tomonori
2010-08-11  7:25   ` Russell King - ARM Linux
2010-08-11  7:25     ` Russell King - ARM Linux
2010-08-13  6:23     ` FUJITA Tomonori
2010-08-13  6:23       ` FUJITA Tomonori
2010-08-13 21:54       ` Russell King - ARM Linux
2010-08-13 21:54         ` Russell King - ARM Linux
2010-08-14  9:30         ` FUJITA Tomonori
2010-08-14  9:30           ` FUJITA Tomonori
2010-08-14 18:46           ` Russell King - ARM Linux [this message]
2010-08-14 18:46             ` Russell King - ARM Linux
2010-08-15  5:42             ` FUJITA Tomonori
2010-08-15  5:42               ` FUJITA Tomonori
2010-08-15  8:23               ` Russell King - ARM Linux
2010-08-15  8:23                 ` Russell King - ARM Linux
2010-08-15  8:23                 ` Russell King - ARM Linux
2010-08-15 15:55                 ` FUJITA Tomonori
2010-08-15 15:55                   ` FUJITA Tomonori
2010-08-16 23:29           ` Krzysztof Halasa
2010-08-16 23:29             ` Krzysztof Halasa
2010-08-19  8:51             ` FUJITA Tomonori
2010-08-19  8:51               ` FUJITA Tomonori
2010-08-19 16:56               ` Krzysztof Halasa
2010-08-19 16:56                 ` Krzysztof Halasa
2010-08-19 10:31           ` Benjamin Herrenschmidt
2010-08-19 10:31             ` Benjamin Herrenschmidt
2010-08-19 14:50             ` FUJITA Tomonori
2010-08-19 14:50               ` FUJITA Tomonori
2010-08-19 16:53               ` Krzysztof Halasa
2010-08-19 16:53                 ` Krzysztof Halasa
2010-08-19 17:20                 ` FUJITA Tomonori
2010-08-19 17:20                   ` FUJITA Tomonori
2010-08-19 21:54                   ` Benjamin Herrenschmidt
2010-08-19 21:54                     ` Benjamin Herrenschmidt
2010-08-19 21:51               ` Benjamin Herrenschmidt
2010-08-19 21:51                 ` Benjamin Herrenschmidt
2010-08-26 11:55                 ` FUJITA Tomonori
2010-08-26 11:55                   ` FUJITA Tomonori
2010-08-26 13:54                   ` FUJITA Tomonori
2010-08-26 13:54                     ` FUJITA Tomonori
2010-08-26 17:57                     ` Russell King - ARM Linux
2010-08-26 17:57                       ` Russell King - ARM Linux
2010-08-27  6:54                       ` FUJITA Tomonori
2010-08-27  6:54                         ` FUJITA Tomonori
2010-08-26 16:02                   ` Krzysztof Halasa
2010-08-26 16:02                     ` Krzysztof Halasa
2010-08-27  0:26                     ` FUJITA Tomonori
2010-08-27  0:26                       ` FUJITA Tomonori

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=20100814184605.GA1999@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=khc@pm.waw.pl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.