headers
Stephan Sürken | 1 May 2010 20:47
Picon

Re: [Bug 15836] Commit 6ad696d2cf535772dff659298ec7e7260e344595 breaks my SD card reader [197b:2381]

On Fri, 2010-04-30 at 19:06 +0200, Andi Kleen wrote:
> The mission information is which CONFIG_* option changes the behaviour.
> (or maybe it's in the bugzilla, i just skimmed it very quickly)
> 
> presumably it's either hibernation or memory hotadd that introduces
> the problem.
> 
> My patch just allowed to have both together.
> 
> Once it's determined which one it is one could do a second bisect
> with that option always on (and the other off)? Or maybe it's not a 
> regression.

Thx Andi. I now get the obvious: the way I built the kernels (using
standard Debian configs as template, having both CONFIG_MEMORY_HOTPLUG
and CONIG_HIBERNATION enabled), without your commit,
CONFIG_MEMORY_HOTPLUG was implicitly turned off. Bummer.

Enabling CONFIG_MEMORY_HOTPLUG actually enables the bug.

I explicitly confirmed this on top of 2.6.33.2:

config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohiber:CONFIG_MEMORY_HOTPLUG=y
=>"bad"
config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohotplug:# CONFIG_MEMORY_HOTPLUG is not set
=>"good"

So any code enabled by CONFIG_MEMORY_HOTPLUG is the winner, presumable
somewhere in the mmc code (?).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Williams | 2 May 2010 00:00
Picon
Favicon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux
<linux <at> arm.linux.org.uk> wrote:
> On Sat, Apr 17, 2010 at 06:58:49AM +0200, Linus Walleij wrote:
>> 2010/4/15 Dan Williams <dan.j.williams <at> intel.com>:
>>
>> > Getting closer... I have pushed out the dma40 driver (v3), 4, and 6.
>>
>> That's great!
>>
>> > The other patch in -mm I could take as well but that needs an ack from
>> > Russell.
>>
>> Nah, I'll push that in through Russells tree hopefully, it needs rebasing on
>> the latest board setup code anyway.
>>
>> > 5 is pending the review comment and 9 does not apply cleanly (does it
>> > depend on something in the spi tree?)
>>
>> OK I'm sending updated versions soon, along with a DMA40 bug fix
>> all on top of async_tx instead.
>>
>> Number 9 fails since it is based on -next where all the #include <slab.h>
>> business has taken place, I don't know how that is resolved in the end
>> but it now includes that include and applies cleanly on async_tx.
>>
>> I'll keep working on getting the PL011 and PL180 DMA tested on the
>> RealView somehow so those can also be accepted.
>
> So has this (which has now been applied to Dan's tree) been tested
> as I asked on Versatile platforms, or do we have something that could
(Continue reading)

Permalink | Reply | 10 comments |
headers
Linus Walleij | 2 May 2010 00:27
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

2010/5/2 Dan Williams <dan.j.williams <at> intel.com>:
> On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux
> <linux <at> arm.linux.org.uk> wrote:
>> So has this (which has now been applied to Dan's tree) been tested
>> as I asked on Versatile platforms, or do we have something that could
>> be incompatible with those platforms?
>>
>> I'm basically not acking or applying these patches until something
>> along those lines has happened.  (And unfortunately I don't have the
>> resources to apply to this at present.)
>
> Just to clarify are you nak'ing these patches for upstream inclusion
> until this testing occurs?  Or do we just need a !ARCH_VERSATILE
> somewhere to allow any incompatibilities to be worked out later
> in-tree?

None of the stuff you have applied is included in the objects compiled
for Versatile boards. The PL022 driver probably works with Versatile
but noone has tested it and it's not included in any defconfigs.

What I though Russell was worried about was the PL011 and PL180
drivers which *are* in use by Versatile.

So to be clear: none of the stuff that touches the Versatile platform
has been applied so far. Only the U300/U8500 specific stuff has
been patched in, and I'm suggesting also the PL022 driver which
is currently only used by U300 and U8500 to be patched.

That said I hope to bring in help, run QEMU or similar ASAP
so that also the PL011 and PL180 can be cleanly applied for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 2 May 2010 00:44
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

On Sat, May 01, 2010 at 03:00:09PM -0700, Dan Williams wrote:
> Just to clarify are you nak'ing these patches for upstream inclusion
> until this testing occurs?  Or do we just need a !ARCH_VERSATILE
> somewhere to allow any incompatibilities to be worked out later
> in-tree?

What I don't want to do is to get into the situation where we throw
this patchset into the kernel and then find that we have to invent a
whole new implementation in the various primecell drivers to support
the Versatile hardware.

Versatile has some MUXing on three of the DMA signals, so (eg) we
really don't want UARTs claiming DMAs just because they're in existence
and not in use - that would prevent DMAs from being used for (eg) AACI
or MMC.

The alternative is that we could just take the attitude that Versatile/
Realview will never have DMA support implemented, but that seems rather
silly, as they've tended to be the first platforms I get new CPU
architectures for.  (This is why DMA coherency stuff on new architectures
tends to be left for others to do...)
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 8 comments |
headers
Andi Kleen | 2 May 2010 01:04

Re: [Bug 15836] Commit 6ad696d2cf535772dff659298ec7e7260e344595 breaks my SD card reader [197b:2381]

> I explicitly confirmed this on top of 2.6.33.2:

Thanks that makes a bit more sense.

> 
> config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohiber:CONFIG_MEMORY_HOTPLUG=y
> =>"bad"
> config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohotplug:# CONFIG_MEMORY_HOTPLUG is not set
> =>"good"
> 
> So any code enabled by CONFIG_MEMORY_HOTPLUG is the winner, presumable
> somewhere in the mmc code (?).

I doubt the mmc code really knows anything about memory hotplug.
Must be some subtle side effect.

Can send the diff of two boot logs with memory hotplug on and off?
I wonder if you have the same memory layout in both cases.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Linus Walleij | 2 May 2010 01:04
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

2010/5/2 Russell King - ARM Linux <linux <at> arm.linux.org.uk>:

> Versatile has some MUXing on three of the DMA signals, so (eg) we
> really don't want UARTs claiming DMAs just because they're in existence
> and not in use - that would prevent DMAs from being used for (eg) AACI
> or MMC.

As long as Versatile doesn't specify any filter function or
data for the channel allocation function (it currently doesn't and defaults
to NULL) it won't even try to call the DMA engine to allocate a channel
for say the UART.

There is nothing blocking some other peripheral from grabbing a
muxed channel in that case.

But the implementation of the DMA engine would be better of
handling the muxing dynamically I believe, so when the PL011
driver (say) requests a DMA channel, it doesn't mean it requests the
*physical* channel and holds it (unless the driver is very naïvely
implemented) it nominally means it reserves a placeholder in the
DMA engine.

When the driver issues a request to perform a DMA transfer, it will pull
out a physical channel and use that, then return it. If there is too
much combat about the physical channels, you configure out DMA
for the least wanted PrimeCells.

Yours,
Linus Walleij
--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dan Williams | 2 May 2010 01:25
Picon
Favicon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

On Sat, May 1, 2010 at 3:44 PM, Russell King - ARM Linux
<linux <at> arm.linux.org.uk> wrote:
> On Sat, May 01, 2010 at 03:00:09PM -0700, Dan Williams wrote:
>> Just to clarify are you nak'ing these patches for upstream inclusion
>> until this testing occurs?  Or do we just need a !ARCH_VERSATILE
>> somewhere to allow any incompatibilities to be worked out later
>> in-tree?
>
> What I don't want to do is to get into the situation where we throw
> this patchset into the kernel and then find that we have to invent a
> whole new implementation in the various primecell drivers to support
> the Versatile hardware.
>
> Versatile has some MUXing on three of the DMA signals, so (eg) we
> really don't want UARTs claiming DMAs just because they're in existence
> and not in use - that would prevent DMAs from being used for (eg) AACI
> or MMC.
>
> The alternative is that we could just take the attitude that Versatile/
> Realview will never have DMA support implemented, but that seems rather
> silly, as they've tended to be the first platforms I get new CPU
> architectures for.  (This is why DMA coherency stuff on new architectures
> tends to be left for others to do...)

Ok, it will be good to have this approach vetted on a challenging
arch.  We'll see where things stand when the merge window opens.

--
Dan
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 2 May 2010 01:28
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

On Sun, May 02, 2010 at 01:04:37AM +0200, Linus Walleij wrote:
> 2010/5/2 Russell King - ARM Linux <linux <at> arm.linux.org.uk>:
> 
> > Versatile has some MUXing on three of the DMA signals, so (eg) we
> > really don't want UARTs claiming DMAs just because they're in existence
> > and not in use - that would prevent DMAs from being used for (eg) AACI
> > or MMC.
> 
> As long as Versatile doesn't specify any filter function or
> data for the channel allocation function (it currently doesn't and defaults
> to NULL) it won't even try to call the DMA engine to allocate a channel
> for say the UART.

But when we _do_ want to support DMA?

> There is nothing blocking some other peripheral from grabbing a
> muxed channel in that case.
> 
> But the implementation of the DMA engine would be better of
> handling the muxing dynamically I believe, so when the PL011
> driver (say) requests a DMA channel, it doesn't mean it requests the
> *physical* channel and holds it (unless the driver is very naïvely
> implemented) it nominally means it reserves a placeholder in the
> DMA engine.

So what happens if we try to use DMA with the PL011 but the physical
channels are already in use?  From what I can see, it assumes that it
always has access to the transmit channel, and there's no recovery if
it doesn't.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Linus Walleij | 2 May 2010 01:48
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

2010/5/2 Dan Williams <dan.j.williams <at> intel.com>:
> On Sat, May 1, 2010 at 4:04 PM, Linus Walleij

>> When the driver issues a request to perform a DMA transfer, it will pull
>> out a physical channel and use that, then return it. If there is too
>> much combat about the physical channels, you configure out DMA
>> for the least wanted PrimeCells.
>>
>
> Could you simulate this by publishing more struct dma_chans than are
> physically present, and then handle the muxing internal to the driver?
>  Or am I misunderstanding the usage model?

Yes exactly that way. What I had in mind atleast.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Linus Walleij | 2 May 2010 02:21
Picon

Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

2010/5/2 Russell King - ARM Linux <linux <at> arm.linux.org.uk>:

>> But the implementation of the DMA engine would be better of
>> handling the muxing dynamically I believe, so when the PL011
>> driver (say) requests a DMA channel, it doesn't mean it requests the
>> *physical* channel and holds it (unless the driver is very naďvely
>> implemented) it nominally means it reserves a placeholder in the
>> DMA engine.
>
> So what happens if we try to use DMA with the PL011 but the physical
> channels are already in use?  From what I can see, it assumes that it
> always has access to the transmit channel, and there's no recovery if
> it doesn't.
>
> Plus if we can't get DMA for the RX path, it _permanently_ disables
> all DMA for the device.

OK now I get it.. the point of crux is that you need the drivers to be
coded to switch seamlessly back to interrupt mode and retry with
DMA on next transaction nevertheless if possible.

That is definately possible with the current API, so it's nothing blocking
the stuff pending in Dan's tree.

However when it comes to the PL011/PL180 drivers you got me there,
it surely does assume you either have the channel and can use it
or else there is some permanent error on it.

I'll twist these patches around a bit, it shouldn't be too hard to come up
with some convincing code.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane