* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Mark Brown @ 2009-11-07 18:11 UTC (permalink / raw)
To: Grant Likely; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <20091107083448.18908.80366.stgit@angua>
On Sat, Nov 07, 2009 at 01:34:55AM -0700, Grant Likely wrote:
> ALSA playback seems to be more reliable if the .pointer() hook reports
> a value slightly into the period, rather than right on the period
> boundary. This patch adds a fudge factor of 1/4 the period size
> to better estimate the actual position of the DMA engine in the
> audio buffer.
It occurs to me that in terms of dealing with what's going on here this
probably is achieving exactly the same effect as Jon's code in that it
tells ALSA that things are a bit ahead of where the buffer started.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Grant Likely @ 2009-11-07 18:19 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <20091107181153.GA31789@sirena.org.uk>
On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Nov 07, 2009 at 01:34:55AM -0700, Grant Likely wrote:
>> ALSA playback seems to be more reliable if the .pointer() hook reports
>> a value slightly into the period, rather than right on the period
>> boundary. =A0This patch adds a fudge factor of 1/4 the period size
>> to better estimate the actual position of the DMA engine in the
>> audio buffer.
>
> It occurs to me that in terms of dealing with what's going on here this
> probably is achieving exactly the same effect as Jon's code in that it
> tells ALSA that things are a bit ahead of where the buffer started.
Possibly, but I can both reproduce and eliminate the problem Jon is
seeing regardless of whether or not this patch, so I'm not yet
convinced.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
From: Grant Likely @ 2009-11-07 18:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: John Bonesio, alsa-devel, broonie, linuxppc-dev, lrg
In-Reply-To: <9e4733910911070451y28073dbeke6ced6246f5a5c24@mail.gmail.com>
On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely <grant.likely@secretlab.ca> =
wrote:
>> Sound drivers PCM DMA is supposed to free-run until told to stop
>> by the trigger callback. =A0The current code tries to track appl_ptr,
>> to avoid stale buffer data getting played out at the end of the
>> data stream. =A0Unfortunately it also results in race conditions
>> which can cause the audio to stall.
>
> I leave in an hour and I will be off net for a week so I can't look at th=
ese.
Okay, no problem. I can be patient.
> The problem at end of stream works like this:
>
> last buffer containing music plays
> this buffer has been padded with zero to make a full sample
> interrupt occurs at end of buffer
> =A0--- at this point the next chained buffer starts playing, it is full o=
f junk
> =A0--- this chaining happens in hardware
> Alsa processes the callback and sends stop stream
> --- oops, too late, buffer full of noise has already played several sampl=
es
> --- these samples of noise are clearly audible.
> --- they are usually a fragment from earlier in the song.
I'm not yet convinced that this sequence is correct. Well, I mean,
I'm not convinced about the buffer only being filled to top up the
current period. My understanding of ALSA is that the application is
supposed to make sure there is enough silence in the buffer to handle
the lag between notification that the last period with valid data has
been played out and the stop trigger.
> Using aplay with short clips like the action sounds for pidgin, etc
> makes these noise bursts obviously visible.
Yup, I've got a bunch of clips that I can reproduce the problem with,
and I can reproduce it reliably using aplay. However, the problem I'm
seeing seems to be related to a dev_dbg() call in the trigger stop
path. When KERN_DEBUG messages get sent to the console, and the
console is one of the PSC ports, then I get the replayed sample
artifact at the end. However, if I 'tail -f /var/log/kern.log', then
I still get to see the debug output, but the audible artifact doesn't
occur. That says to me that the real problem is an unbounded latency
caused by another part of the kernel (the tty console in this case).
It seems to me that aplay doesn't silence out very many buffers past
the end of the sample, but I won't know for sure until I instrument it
to see what data is present in the buffers. I'll do that next week.
>
> To fix this you need a mechanism to determine where the valid data in
> the buffering system ends and noise starts. Once you know the extent
> of the valid data we can keep the DMA channel programmed to not play
> invalid data. You can play off the end of valid data two ways; under
> run when ALSA doesn't supply data fast enough and end of buffer.
Underrun is a realtime failure. ALSA handles it by triggering STOP
and START of the stream AFAIKT. Just about all ALSA drivers using DMA
will end up replaying buffers if the kernel cannot keep up with
hardware.
End of buffer seems to be the responsibility of userspace, but I need
to investigate this more.
My experiments to this point seems to suggest that when you hear the
artifacts it is due to both the end of buffer condition, and a
realtime failure in executing the stop trigger.
> ALSA does not provide information on where valid data ends in easily
> consumable form so I've been trying to reconstruct it from appl_ptr.
> A much cleaner solution would be for ALSA to provide a field that
> indicates the last valid address in the ring buffer system. Then in
> the driver's buffer complete callback I could get that value and
> reprogram the DMA engine not to run off the end of valid data. As each
> buffer completes I would reread the value and update the DMA stop
> address. You also need the last valid address field when DMA is first
> started.
... assuming that audio needs to stop exactly at the end of valid
data. But if the last few periods are silence, then this assumption
isn't true.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
From: Grant Likely @ 2009-11-07 18:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: alsa-devel, broonie, linuxppc-dev, lrg
In-Reply-To: <9e4733910911070504g13bce539w92120b8124e3e8e9@mail.gmail.com>
On Sat, Nov 7, 2009 at 6:04 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 7:51 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>>> Sound drivers PCM DMA is supposed to free-run until told to stop
>>> by the trigger callback. =A0The current code tries to track appl_ptr,
>>> to avoid stale buffer data getting played out at the end of the
>>> data stream. =A0Unfortunately it also results in race conditions
>>> which can cause the audio to stall.
>>
>> I leave in an hour and I will be off net for a week so I can't look at t=
hese.
>
> There is a surefire way to fix this but I have resisted doing it
> because it is fixing a symptom not a cause.
>
> Simply have the driver zero out the buffer in the completion interrupt
> before handing it back to ALSA. Then if ALSA lets us play invalid data
> the invalid data will be silence. I implemented this and it works
> every time.
>
> Downside is a big memset() in an IRQ handler.
... and then the driver may as well manually copy the audio data from
the buffer into the PSC FIFO. No win here.
The other option (which I think is how ALSA is designed) is for
userspace to insert silence at the end of playback data so that the
stop trigger lands in a safe place.
g.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Mark Brown @ 2009-11-07 19:33 UTC (permalink / raw)
To: Grant Likely; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <fa686aa40911071019y6be8283bu8d36d96420deefab@mail.gmail.com>
On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
> > It occurs to me that in terms of dealing with what's going on here this
> > probably is achieving exactly the same effect as Jon's code in that it
> > tells ALSA that things are a bit ahead of where the buffer started.
> Possibly, but I can both reproduce and eliminate the problem Jon is
> seeing regardless of whether or not this patch, so I'm not yet
> convinced.
That doesn't entirely surprise me; I'm not convinced that the original
approach entirely deals with the issue rather than just making it much
harder to see.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Grant Likely @ 2009-11-07 19:46 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <20091107193318.GB31789@sirena.org.uk>
On Sat, Nov 7, 2009 at 12:33 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
>> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
>
>> > It occurs to me that in terms of dealing with what's going on here this
>> > probably is achieving exactly the same effect as Jon's code in that it
>> > tells ALSA that things are a bit ahead of where the buffer started.
>
>> Possibly, but I can both reproduce and eliminate the problem Jon is
>> seeing regardless of whether or not this patch, so I'm not yet
>> convinced.
>
> That doesn't entirely surprise me; I'm not convinced that the original
> approach entirely deals with the issue rather than just making it much
> harder to see.
Indeed. I'm at the point where I'm far more interested in achieving
"correctness" than trying to hobble together a set of conditions that
appears to work most of the time.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
From: Mark Brown @ 2009-11-07 20:12 UTC (permalink / raw)
To: Grant Likely; +Cc: John Bonesio, alsa-devel, linuxppc-dev, lrg
In-Reply-To: <fa686aa40911071051y3cf63e55ibe7fbc65c30bd15e@mail.gmail.com>
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> current period. My understanding of ALSA is that the application is
> supposed to make sure there is enough silence in the buffer to handle
> the lag between notification that the last period with valid data has
> been played out and the stop trigger.
This is certainly the most robust approach for applications. For a
large proportion of hardware it won't matter too much since they're able
to shut down the audio very quickly but that can't be entirely relied
upon, especially at higher rates on slower machines.
> occur. That says to me that the real problem is an unbounded latency
> caused by another part of the kernel (the tty console in this case).
That's certainly not going to help anything here - if a delay is
introduced in telling the hardware to shut down the DMA then that
increases the chance for the DMA controller to start pushing valid audio
data from the buffer to the audio interface.
> > A much cleaner solution would be for ALSA to provide a field that
> > indicates the last valid address in the ring buffer system. Then in
> > the driver's buffer complete callback I could get that value and
> > reprogram the DMA engine not to run off the end of valid data. As each
> > buffer completes I would reread the value and update the DMA stop
> > address. You also need the last valid address field when DMA is first
> > started.
> ... assuming that audio needs to stop exactly at the end of valid
> data. But if the last few periods are silence, then this assumption
> isn't true.
Indeed, it makes the whole thing much more reliable.
Providing a final valid data point to the driver would possibly even
make things worse since if it were used then you'd have the equivalent
race where the application has initialised some data but not yet managed
to update the driver to tell it it's being handed over; if the driver
just carries on running through the data there's a reasonable chance
nobody will notice that case.
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Stephen Rothwell @ 2009-11-08 7:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linuxppc-dev, Thomas Gleixner, Ingo Molnar, LKML
In-Reply-To: <1257548144.13611.267.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
Hi Ben,
On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.
It should be safe as the spinlocks cannot be access until after the
following ppc_md pointer initialisations are done (and all this happens
before the secondary CPUs are started).
But, you are right that there is nothing like actually testing with
iSeries. :-)
> > void __init hpte_init_iSeries(void)
> > {
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(iSeries_hlocks); i++)
> > + spin_lock_init(&iSeries_hlocks[i]);
> > +
> > ppc_md.hpte_invalidate = iSeries_hpte_invalidate;
> > ppc_md.hpte_updatepp = iSeries_hpte_updatepp;
> > ppc_md.hpte_updateboltedpp = iSeries_hpte_updateboltedpp;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] fsl_pq_mdio: Fix compiler/sparse warnings (part 1)
From: David Miller @ 2009-11-08 8:43 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225256.GA29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:52:56 +0300
> commit 1d2397d742b7a2b39b2f09dd9da3b9d1463f55e9 ("fsl_pq_mdio: Add
> Suport for etsec2.0 devices") introduced the following warnings:
...
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] fsl_pq_mdio: Fix compiler/sparse warnings (part 2)
From: David Miller @ 2009-11-08 8:43 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225257.GB29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:52:57 +0300
> This patch fixes following warnings:
>
> fsl_pq_mdio.c:112:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:124:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:133:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:414:11: warning: cast adds address space to expression (<asn:2>)
>
> Instead of adding __force all over the place, introduce convenient
> fsl_pq_mdio_get_regs() call that does the ugly casting just once.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] gianfar: Fix compiler and sparse warnings
From: David Miller @ 2009-11-08 8:44 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225300.GC29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:53:00 +0300
> commit fba4ed030cfae7efdb6b79a57b0c5a9d72c9de83 ("gianfar: Add Multiple
> Queue Support") introduced the following warnings:
...
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
From: David Miller @ 2009-11-08 9:05 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, netdev, afleming, jason.wessel
In-Reply-To: <20091104225711.GA30844@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:57:11 +0300
> When using KGDBoE, gianfar driver spits 'Interrupt problem' messages,
> which appears to be a legitimate warning, i.e. we may end up calling
> netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled.
>
> This patch reworks the RX path so that if netpoll is enabled (the
> only case when the driver don't know from what context the polling
> may be called), we check whether IRQs are disabled, and if so we
> fall back to safe variants of skb receiving functions.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
This is bogus, I'll tell you why.
When you go into netif_receive_skb() we have a special check,
"if (netpoll_receive_skb(..." that takes care of all of the
details concerning doing a ->poll() from IRQ disabled context
via netpoll.
So this code you're adding should not be necessary.
Or, explain to me why no other driver needs special logic in their
->poll() handler like this and does not run into any kinds of netpoll
problems :-)
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: David Miller @ 2009-11-08 9:08 UTC (permalink / raw)
To: avorontsov
Cc: jdl, netdev, linuxppc-dev, afleming, jason.wessel, shemminger,
buytenh
In-Reply-To: <20091105165738.GA31923@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 19:57:38 +0300
> But that basically means that with skb recycling we can't safely
> use KGDBoE, though we can add something like this:
Please stop adding special logic only to your driver to handle these
things.
Either it's a non-issue, or it's going to potentially be an issue for
everyone using skb_recycle_check() in a NAPI driver, right?
So why not add the "in_interrupt()" or whatever check to
skb_recycle_check() and if the context is unsuitable return false (0)
ok?
^ permalink raw reply
* Re: [GIT PULL] perf_event/tracing/powerpc patches from Anton Blanchard
From: Ingo Molnar @ 2009-11-08 9:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linuxppc-dev, Paul Mackerras, linux-kernel,
Anton Blanchard
In-Reply-To: <1256882649.6372.65.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2009-10-29 at 07:55 +0100, Ingo Molnar wrote:
> > * Paul Mackerras <paulus@samba.org> wrote:
> >
> > > Here is a series of patches from Anton Blanchard that implement some
> > > nice tracing and perf_event features on powerpc. One of them is
> > > generic perf_event stuff (adding software events for alignment faults
> > > and instruction emulation faults).
> > >
> > > Since this touches the perf_event and tracing subsystems as well as
> > > the powerpc architecture code, I think the best way forward is for
> > > both Ingo and Ben to pull it into their trees. I have based it on the
> > > most recent point in Linus' tree that Ingo had pulled into his perf
> > > branches (as of yesterday or so).
> >
> > The generic perf bits look good to me - can pull it if Ben OKs the
> > PowerPC bits.
>
> Yup. Just went through all of them, they look fine. I also test built on
> a number of default configs and it seems to pass.
Pulled into tip:perf/powerpc (will keep it in a separate branch for a
few days then it can go into perf/core), thanks guys!
Ingo
^ permalink raw reply
* Allow overriding of CC in powerpc kernel build
From: David Gibson @ 2009-11-09 2:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
arch/powerpc/Makefile uses make 'override' directives to add -m32 or
-m64 depending on config to the CC variable, and matching options to
the AS, LD and AR variables to correctly use a biarch compiler.
Unfortunately this doesn't work as intended if you actually attempt to
set CC from the make command line. They correctly augment the given
CC variable in the top-level make instance, but at least some of the
second-level make invocations don't include arch/powerpc/Makefile, so
the command line override is used directly, and we attempt to compile
without the correct -m64 or similar option.
This patch alters the way we set up the biarch flags so that CC can be
overriden from the command line as expected (this is useful when using
ccontrol as a compiler wrapper). The approach is based roughly on the
way x86 handles the analagous problem for i386/x86_64 biarch
compilers, with some additional hacks to make the VDSO compilation
work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: linux-a2/arch/powerpc/Makefile
===================================================================
--- linux-a2.orig/arch/powerpc/Makefile 2009-11-06 14:17:15.000000000 +1100
+++ linux-a2/arch/powerpc/Makefile 2009-11-06 15:36:05.000000000 +1100
@@ -57,10 +57,10 @@ endif
UTS_MACHINE := $(OLDARCH)
ifeq ($(HAS_BIARCH),y)
-override AS += -a$(CONFIG_WORD_SIZE)
-override LD += -m elf$(CONFIG_WORD_SIZE)ppc
-override CC += -m$(CONFIG_WORD_SIZE)
-override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
+ KBUILD_AFLAGS += -m$(CONFIG_WORD_SIZE)
+ KBUILD_CFLAGS += -m$(CONFIG_WORD_SIZE)
+ LDFLAGS := -m elf$(CONFIG_WORD_SIZE)ppc
+ override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
endif
LDFLAGS_vmlinux-yy := -Bstatic
Index: linux-a2/arch/powerpc/kernel/vdso32/Makefile
===================================================================
--- linux-a2.orig/arch/powerpc/kernel/vdso32/Makefile 2009-11-06 15:45:36.000000000 +1100
+++ linux-a2/arch/powerpc/kernel/vdso32/Makefile 2009-11-06 15:47:03.000000000 +1100
@@ -40,10 +40,13 @@ $(obj-vdso32): %.o: %.S
$(call if_changed_dep,vdso32as)
# actual build commands
+biarch := $(call cc-option, -m32)
+c_flags_32 = $(filter-out -m64,$(c_flags)) $(biarch)
+a_flags_32 = $(filter-out -m64,$(a_flags)) $(biarch)
quiet_cmd_vdso32ld = VDSO32L $@
- cmd_vdso32ld = $(CROSS32CC) $(c_flags) -Wl,-T $^ -o $@
+ cmd_vdso32ld = $(CROSS32CC) $(c_flags_32) -Wl,-T $^ -o $@
quiet_cmd_vdso32as = VDSO32A $@
- cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
+ cmd_vdso32as = $(CROSS32CC) $(a_flags_32) -c -o $@ $<
# install commands for the unstripped file
quiet_cmd_vdso_install = INSTALL $@
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Stephen Rothwell @ 2009-11-09 5:15 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Peter Zijlstra, Ingo Molnar, LKML, linuxppc-dev
In-Reply-To: <1257548144.13611.267.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Hi Thomas,
On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2009-11-06 at 22:41 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (power-replace-old-style-lock-init.patch)
> > SPIN_LOCK_UNLOCKED is deprecated. Init the lock array at runtime
> > instead.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: linuxppc-dev@ozlabs.org
> > ---
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Benjamin Herrenschmidt @ 2009-11-09 8:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, linuxppc-dev, Thomas Gleixner, Ingo Molnar, LKML
In-Reply-To: <20091109161502.ab064092.sfr@canb.auug.org.au>
On Mon, 2009-11-09 at 16:15 +1100, Stephen Rothwell wrote:
> Hi Thomas,
>
> On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > On Fri, 2009-11-06 at 22:41 +0000, Thomas Gleixner wrote:
> > > plain text document attachment
> > > (power-replace-old-style-lock-init.patch)
> > > SPIN_LOCK_UNLOCKED is deprecated. Init the lock array at runtime
> > > instead.
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: linuxppc-dev@ozlabs.org
> > > ---
> >
> > Looks reasonable. But iseries can be a bitch, so we do need to test it
> > on monday.
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 00/11] More OF merge patches
From: Michal Simek @ 2009-11-09 10:35 UTC (permalink / raw)
To: microblaze-uclinux
Cc: sfr, monstr, devicetree-discuss, sparclinux, linuxppc-dev, davem
In-Reply-To: <20091105073728.10460.6061.stgit@angua>
Hi Grant,
Grant Likely wrote:
> Round 2. Here is my 2nd set of merging OF code between PowerPC and
> Microblaze (no SPARC changes this time). Compile tested on ppc,
> microblaze and sparc. Boot tested on MPC5200 powerpc platform.
I tested your test-device-tree branch - boot tested on ml505 for MMU and
noMMU kernels.
I expect that you will add these patches to next branch. I test it every
day - if is any problem with Microblaze, I will let you know.
Tested-by: Michal Simek <monstr@monstr.eu>
Thanks for this work,
Michal
>
> I've also pushed this series out to the test-devicetree branch on my
> git server if anyone cares to pull and test:
>
> git://git.secretlab.ca/git/linux-2.6 test-devicetree
>
> This is based on the next-devicetree branch which contains the first
> round of patches and is being pulled into linux-next.
>
> Cheers,
> g.
>
> ---
>
> Grant Likely (11):
> of/flattree: Merge early_init_dt_check_for_initrd()
> of: remove special case definition of of_read_ulong()
> of: merge prom_{add,remove,modify}_property
> of/flattree: Merge unflatten_device_tree
> of/flattree: Merge unflatten_dt_node
> of/flattree: Merge of_flat_dt_is_compatible
> of/flattree: merge of_get_flat_dt_prop
> of/flattree: remove __init annotations from the header file
> of/flattree: merge of_get_flat_dt_root
> of/flattree: merge of_scan_flat_dt
> of/flattree: merge find_flat_dt_string and initial_boot_params
>
>
> arch/microblaze/Kconfig | 1
> arch/microblaze/include/asm/prom.h | 1
> arch/microblaze/kernel/prom.c | 531 ------------------------------------
> arch/powerpc/Kconfig | 1
> arch/powerpc/kernel/prom.c | 534 ------------------------------------
> drivers/of/Kconfig | 4
> drivers/of/Makefile | 1
> drivers/of/base.c | 116 ++++++++
> drivers/of/fdt.c | 458 +++++++++++++++++++++++++++++++
> include/linux/of.h | 10 -
> include/linux/of_fdt.h | 21 +
> 11 files changed, 598 insertions(+), 1080 deletions(-)
> create mode 100644 drivers/of/fdt.c
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
From: Anton Vorontsov @ 2009-11-09 13:32 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, afleming, jason.wessel
In-Reply-To: <20091108.010533.212571001.davem@davemloft.net>
On Sun, Nov 08, 2009 at 01:05:33AM -0800, David Miller wrote:
...
> > When using KGDBoE, gianfar driver spits 'Interrupt problem' messages,
> > which appears to be a legitimate warning, i.e. we may end up calling
> > netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled.
> >
> > This patch reworks the RX path so that if netpoll is enabled (the
> > only case when the driver don't know from what context the polling
> > may be called), we check whether IRQs are disabled, and if so we
> > fall back to safe variants of skb receiving functions.
>
> This is bogus, I'll tell you why.
>
> When you go into netif_receive_skb() we have a special check,
> "if (netpoll_receive_skb(..." that takes care of all of the
> details concerning doing a ->poll() from IRQ disabled context
> via netpoll.
>
> So this code you're adding should not be necessary.
>
> Or, explain to me why no other driver needs special logic in their
> ->poll() handler like this and does not run into any kinds of netpoll
> problems :-)
Hm, I was confused by the following note:
/**
* netif_receive_skb - process receive buffer from network
* @skb: buffer to process
...
* This function may only be called from softirq context and interrupts
* should be enabled.
Looking into the code though, I can indeed see that there
are netpoll checks, and __netpoll_rx() is actually called with
irqs disabled. So, in the end it appears that we should just
remove the 'Interrupt problem' message.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Anton Vorontsov @ 2009-11-09 13:41 UTC (permalink / raw)
To: David Miller
Cc: jdl, netdev, linuxppc-dev, afleming, jason.wessel, shemminger,
buytenh
In-Reply-To: <20091108.010848.116517157.davem@davemloft.net>
On Sun, Nov 08, 2009 at 01:08:48AM -0800, David Miller wrote:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date: Thu, 5 Nov 2009 19:57:38 +0300
>
> > But that basically means that with skb recycling we can't safely
> > use KGDBoE, though we can add something like this:
>
> Please stop adding special logic only to your driver to handle these
> things.
>
> Either it's a non-issue, or it's going to potentially be an issue for
> everyone using skb_recycle_check() in a NAPI driver, right?
>
> So why not add the "in_interrupt()" or whatever check to
> skb_recycle_check() and if the context is unsuitable return false (0)
> ok?
I think the check is needed, yes. But if we add just that check,
then we'll never do skb recycling in the tx path (since gianfar
always grabs irqsave spinlock during tx ring cleanup, so the check
will always return false).
So we must add the check to keep polling with disabled IRQs safe,
but we also should get rid of irqsave spinlock in the gianfar
driver (to make the skb recycling actually work in most cases).
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ASoC/mpc5200: remove duplicate identical IRQ handler
From: Grant Likely @ 2009-11-09 16:40 UTC (permalink / raw)
To: linuxppc-dev, alsa-devel, broonie; +Cc: lrg
The TX and RX irq handlers are identical. Merge them
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Hi Mark. Here's one more cleanup patch.
sound/soc/fsl/mpc5200_dma.c | 33 +++------------------------------
1 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index ee5a606..440b749 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -66,32 +66,7 @@ static void psc_dma_bcom_enqueue_next_buffer(struct psc_dma_stream *s)
}
/* Bestcomm DMA irq handler */
-static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
-{
- struct psc_dma_stream *s = _psc_dma_stream;
-
- spin_lock(&s->psc_dma->lock);
- /* For each finished period, dequeue the completed period buffer
- * and enqueue a new one in it's place. */
- while (bcom_buffer_done(s->bcom_task)) {
- bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
-
- s->period_current = (s->period_current+1) % s->runtime->periods;
- s->period_count++;
-
- psc_dma_bcom_enqueue_next_buffer(s);
- }
- spin_unlock(&s->psc_dma->lock);
-
- /* If the stream is active, then also inform the PCM middle layer
- * of the period finished event. */
- if (s->active)
- snd_pcm_period_elapsed(s->stream);
-
- return IRQ_HANDLED;
-}
-
-static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
+static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
{
struct psc_dma_stream *s = _psc_dma_stream;
@@ -486,11 +461,9 @@ int mpc5200_audio_dma_create(struct of_device *op)
rc = request_irq(psc_dma->irq, &psc_dma_status_irq, IRQF_SHARED,
"psc-dma-status", psc_dma);
- rc |= request_irq(psc_dma->capture.irq,
- &psc_dma_bcom_irq_rx, IRQF_SHARED,
+ rc |= request_irq(psc_dma->capture.irq, &psc_dma_bcom_irq, IRQF_SHARED,
"psc-dma-capture", &psc_dma->capture);
- rc |= request_irq(psc_dma->playback.irq,
- &psc_dma_bcom_irq_tx, IRQF_SHARED,
+ rc |= request_irq(psc_dma->playback.irq, &psc_dma_bcom_irq, IRQF_SHARED,
"psc-dma-playback", &psc_dma->playback);
if (rc) {
ret = -ENODEV;
^ permalink raw reply related
* Re: Fwd: [PATCH] arch/powerpc: Improve _memcpy
From: Grant Likely @ 2009-11-09 17:06 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Dirk Eibach, Linux kernel, linuxppc-dev list
In-Reply-To: <1257358349.2489.0@antares>
On Wed, Nov 4, 2009 at 11:12 AM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> See <http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html>=
.
> =A0Any chance to get this one into the tree? =A0Grant?
Even though it is generic ppc code, I picked it up into my 5200 -next
tree because it's such a simple patch. I expect Ben will pull it into
his any day now.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: c67x00 with mpc85xx
From: Grant Likely @ 2009-11-09 19:23 UTC (permalink / raw)
To: Jeff Angielski; +Cc: Joel Lord, Linuxppc-dev
In-Reply-To: <4AD8CD30.6020003@theptrgroup.com>
On Fri, Oct 16, 2009 at 12:44 PM, Jeff Angielski <jeff@theptrgroup.com> wrote:
>
> We are using the Cypress USB Host (CY7C67300) with a Freescale MPC8544 and
> can only get it to work if we add a delay after writing to the hardware
> registers through the HPI.
>
> We tried playing with the SCY settings in the GPCM but nothing helps. It is
> only when we add usecs of delay after our write() functions that the
> hardware works.
>
> The datasheets make no mention of any write-then-read requirements and the
> FAEs are stumped right now.
>
> I was just hoping somebody had some experiencing interfacing this chip to
> the PowerPC and that they could offer some suggestions or ideas.
I've worked with the part attached to the ppc440 inside a Xilinx FPGA.
Though I ran into many problems, I haven't seen the problem that you
describe. Sorry.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Fix non-modular build
From: Hollis Blanchard @ 2009-11-09 18:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, kvmppc
In-Reply-To: <1257401928.13611.105.camel@pasglop>
On Thu, 2009-11-05 at 17:18 +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kvm/timing.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
> index 2aa371e..7037855 100644
> --- a/arch/powerpc/kvm/timing.c
> +++ b/arch/powerpc/kvm/timing.c
> @@ -23,6 +23,7 @@
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
> #include <linux/uaccess.h>
> +#include <linux/module.h>
>
> #include <asm/time.h>
> #include <asm-generic/div64.h>
FYI, Olof submitted this patch already, but Avi didn't take it or
comment. Feel free to batch it in the agraf bundle (it is required to
make that build, after all).
Acked-by: Hollis Blanchard <hollisb@us.ibm.com>
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Disable Caching for mmap() address
From: Jonathan Haws @ 2009-11-09 23:21 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I would like to disable caching for an address that was returned from a cal=
l to mmap(). I am using this address for DMA operations in user space and =
want to make sure that the data cache is turned off for that buffer.
The way this works is the driver simply takes an address I provide and begi=
ns a DMA operation to that location in RAM (I have ensured that this is a p=
hysical address I am passing already). When the DMA is complete, an interr=
upt fires and the ISR gives a semaphore that the user space application is =
pending on (RT_SEM from Xenomai). I have tried simply calling a cache inva=
lidate routine in the ISR before I give the semaphore, but the kernel crash=
es when I try to call that routine - my guess it because the kernel does no=
t have direct access to that location in memory (only my application does, =
according to the MMU).
Anyway, all I want to do is make sure that the buffer is never stored in th=
e cache and that I always fetch it from RAM. How can I specify that using =
mmap() on the /dev/mem device, or is there a better way to accomplish this?
Thanks,
Jonathan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox