linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
	broonie@sirena.org.uk
Subject: Re: [PATCH V3 2/4] AC97 driver for mpc5200
Date: Mon, 25 May 2009 11:15:34 -0400	[thread overview]
Message-ID: <9e4733910905250815r4a6fa205s26531f08fe99131a@mail.gmail.com> (raw)
In-Reply-To: <fa686aa40905242316j3e8b46e7mcc71dc34df209003@mail.gmail.com>

On Mon, May 25, 2009 at 2:16 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> +static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned sho=
rt reg)
>> +{
>> + =A0 =A0 =A0 int timeout;
>> + =A0 =A0 =A0 unsigned int val;
>> +
>> + =A0 =A0 =A0 spin_lock(&psc_dma->lock);
>> +
>> + =A0 =A0 =A0 /* Wait for it to be ready */
>> + =A0 =A0 =A0 timeout =3D 1000;
>> + =A0 =A0 =A0 while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr.=
status) &
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_SR_CMDSEND))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>
> Holy unbounded latency Batman! =A0This code waits up to 10ms for a regist=
er read!
>
> I hate spinning, but if it must be done; I'd like to see it small.
> What is the worst case latency? 125us for 8000Hz bus speed? =A0If you
> must spin; can a cpu_relax() be used instead of the udelay() while
> watch the timebase? =A0Timur recently posted a patch which makes this
> easier.
>
> http://patchwork.ozlabs.org/patch/27414/
>
> They *should* be appearing in Ben's -next branch soon.


The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case
you wait for two frames, 42us. If it doesn't respond in 42us the codec
clock is not ticking ( a recurring problem I am running into). These
codecs may be going into a sleep mode I don't understand, but this is
not the right place to try and wake them up. I'll lower the retry
counts to 10 instead of 1000.

I played around with implementing this on a kernel thread with
interrupts. It can be done but the code is a lot more complex.

BTW, 8000Hz is implemented by slot stuffing. The link always runs at
12.288Mhz. The DACs are double buffered. When a sample is transfered
between buffers it sets a bit on the link back to the host, and the
host sends the next sample in the appropriate slot.


>
>> +
>> + =A0 =A0 =A0 if (!timeout) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("timeout on ac97 bus (rdy)\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0xffff;
>> + =A0 =A0 =A0 }
>> +
>> + =A0 =A0 =A0 /* Do the read */
>> + =A0 =A0 =A0 out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0=
x7f) << 24));
>> +
>> + =A0 =A0 =A0 /* Wait for the answer */
>> + =A0 =A0 =A0 timeout =3D 1000;
>> + =A0 =A0 =A0 while ((--timeout) && !(in_be16(&psc_dma->psc_regs->sr_csr=
.status) &
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_SR_DATA_VAL))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>
> ditto.
>
>> +static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
>> +{
>> + =A0 =A0 =A0 int max_reset, timeout;
>> + =A0 =A0 =A0 struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
>> +
>> + =A0 =A0 =A0 /* AC97 clock is generated by the codec.
>> + =A0 =A0 =A0 =A0* Ensure that it starts ticking after codec reset.
>> + =A0 =A0 =A0 =A0*/
>> + =A0 =A0 =A0 for (max_reset =3D 0; max_reset < 5; max_reset++) {
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Do a cold reset */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_8(&regs->op1, MPC52xx_PSC_OP_RES);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_8(&regs->op0, MPC52xx_PSC_OP_RES);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(50);
>
> :-/ =A0Don't like, but don't know if there is an alternative.
>
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* PSC recover from cold reset
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* (cfr user manual, not sure if useful)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(&regs->sicr, in_be32(&regs->sicr)=
);
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 psc_ac97_warm_reset(ac97);
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* first make sure AC97 clock is low */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (timeout =3D 0; ((in_8(&regs->ipcr_acr=
.ipcr) & 0x80) !=3D 0) &&
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (timeout <=
 100); timeout++)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (timeout =3D=3D 100)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* then wait for the transition to high */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (timeout =3D 0; ((in_8(&regs->ipcr_acr=
.ipcr) & 0x80) =3D=3D 0) &&
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (timeout <=
 100); timeout++)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (timeout =3D=3D 100)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>
> Using udelay makes this less accurate. =A0Only possible reason to use a
> udelay is if the register cannot be polled at full speed (which is
> possibly the case if it adds bus contention; but I don't think it is
> an issue here).
>
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>



--=20
Jon Smirl
jonsmirl@gmail.com

  reply	other threads:[~2009-05-25 15:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-25  1:38 [PATCH V3 0/4] mpc5200 audio rework for AC97 Jon Smirl
2009-05-25  1:38 ` [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code Jon Smirl
2009-05-25  6:26   ` Grant Likely
2009-05-25  9:34     ` Mark Brown
2009-05-25 13:22       ` Grant Likely
2009-05-25  1:38 ` [PATCH V3 2/4] AC97 driver for mpc5200 Jon Smirl
2009-05-25  6:16   ` Grant Likely
2009-05-25 15:15     ` Jon Smirl [this message]
2009-05-25 15:22       ` Mark Brown
2009-05-25 15:59       ` Grant Likely
2009-05-25 10:26   ` Mark Brown
2009-05-25 15:21     ` Jon Smirl
2009-05-25 16:00       ` Grant Likely
2009-05-25  1:38 ` [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board Jon Smirl
2009-05-25  6:34   ` Grant Likely
2009-05-25  9:46     ` Mark Brown
2009-05-25 14:39     ` Jon Smirl
2009-05-25  9:48   ` Mark Brown
2009-05-25  1:38 ` [PATCH V3 4/4] Fabric bindings for STAC9766 on the Efika Jon Smirl
2009-05-28 14:00   ` Peter Korsgaard
2009-05-28 18:58     ` Jon Smirl
2009-05-25 10:43 ` [PATCH V3 0/4] mpc5200 audio rework for AC97 Mark Brown

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=9e4733910905250815r4a6fa205s26531f08fe99131a@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@sirena.org.uk \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.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 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).