From: Takashi Iwai <tiwai@suse.de>
To: "Joachim Förster" <mls.JOFT@gmx.de>
Cc: alsa-devel <alsa-devel@alsa-project.org>,
Lorenz Kolb <lorenz.kolb@lkmail.de>,
"linuxppc-embedded@ozlabs.org" <linuxppc-embedded@ozlabs.org>
Subject: Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Date: Thu, 09 Aug 2007 19:13:07 +0200 [thread overview]
Message-ID: <s5hsl6sws0s.wl%tiwai@suse.de> (raw)
In-Reply-To: <1186655810.7420.26.camel@localhost>
Hi,
thanks for the patch. Here the quick review at a first glance...
At Thu, 09 Aug 2007 12:36:50 +0200,
Joachim Förster wrote:
>
> --- a/sound/ppc/Makefile
> +++ b/sound/ppc/Makefile
> @@ -4,7 +4,9 @@
> #
>
> snd-powermac-objs := powermac.o pmac.o awacs.o burgundy.o daca.o tumbler.o keywest.o beep.o
> +snd-ml403_ac97cr-objs := ml403_ac97cr.o
>
> # Toplevel Module Dependency
> obj-$(CONFIG_SND_POWERMAC) += snd-powermac.o
> obj-$(CONFIG_SND_PS3) += snd_ps3.o
> +obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403_ac97cr.o
Using both _ and - look weird. Let's choose '-' as well as others.
> --- /dev/null
> +++ b/sound/ppc/ml403_ac97cr.c
(snip)
> +static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
> +static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
> +static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
Can the driver really support multiple instances?
If not, better to avoid these arrays.
> +#define PDEBUG(fac, fmt, args...) if (fac & PDEBUG_FACILITIES) \
> + snd_printd(KERN_DEBUG SND_ML403_AC97CR_DRIVER ": " fmt, ##args)
This should be wrapped with do { } while (0)
> +struct lm4550_reg lm4550_regfile[64] = {
> + {.reg = 0x00,
> + .flag = LM4550_REG_NOSAVE | LM4550_REG_FAKEREAD,
> + .def = 0x0D50},
Better to use C99 style initialization here, e.g.
[0x00] = { .... },
[0x02] = { .... },
[0x7e] = { .... },
so you can avoid writing empty items.
The index value could be also AC97_XXX, such as [AC97_MASTER] =
{...}.
What is the purpose of reg field at all, BTW? I guess it's
superfluous.
> +#define LM4550_RF_OK(reg) ((lm4550_regfile[reg / 2].reg != 0) \
> + || (lm4550_regfile[reg / 2].flag != 0))
> +#define LM4550_RF_FLAG(reg) lm4550_regfile[reg / 2].flag
> +#define LM4550_RF_VAL(reg) lm4550_regfile[reg / 2].value
> +#define LM4550_RF_DEF(reg) lm4550_regfile[reg / 2].def
> +#define LM4550_RF_WMASK(reg) lm4550_regfile[reg / 2].wmask
> +
> +static void lm4550_regfile_init(void)
> +{
> + int i;
> + for (i = 0; i < 128; i = i + 2)
> + if (LM4550_RF_FLAG(i) & LM4550_REG_FAKEPROBE)
> + LM4550_RF_VAL(i) = LM4550_RF_DEF(i);
"MACRO(x) = XXX" looks a bit strange to me.
> +static struct snd_pcm_hardware snd_ml403_ac97cr_playback = {
> + .info = (SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_MMAP_VALID),
> + .formats = SNDRV_PCM_FMTBIT_S16_BE,
> + .rates = (SNDRV_PCM_RATE_CONTINUOUS |
> + SNDRV_PCM_RATE_8000_48000 |
> + SNDRV_PCM_RATE_KNOT),
RATE_CONTINUOUS and RATE_KNOW are usually exclusive.
> +static int
> +snd_ml403_ac97cr_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> +{
> + struct snd_ml403_ac97cr *ml403_ac97cr;
> + int err = 0;
> +
> + ml403_ac97cr = snd_pcm_substream_chip(substream);
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + if (substream == ml403_ac97cr->playback_substream) {
> + PDEBUG(WORK_INFO, "trigger(playback): START\n");
> + ml403_ac97cr->ind_rec.hw_ready = 1;
> +
> + /* clear play FIFO */
> + out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_PLAYRESET);
> +
> + /* enable play irq */
> + ml403_ac97cr->enable_irq = 1;
> + enable_irq(ml403_ac97cr->irq);
> + }
Maybe better to create two functions, one for playback and one for
capture, instead of many if's in a function?
> +static int snd_ml403_ac97cr_pcm_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_ml403_ac97cr *ml403_ac97cr;
> + struct snd_pcm_runtime *runtime;
> +
> + ml403_ac97cr = snd_pcm_substream_chip(substream);
> + runtime = substream->runtime;
> +
> + if (substream == ml403_ac97cr->playback_substream) {
Ditto.
> +static int
> +snd_ml403_ac97cr_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *hw_params)
> +{
> + PDEBUG(WORK_INFO, "hw_params(): desired buffer bytes=%d, desired "
> + "period bytes=%d\n",
> + params_buffer_bytes(hw_params), params_period_bytes(hw_params));
> + /* check period bytes, has to be multiple of CR_FIFO_SIZE / 2, don't
> + * know if ALSA takes multiples of period_bytes_min _only_ ...?!
> + */
This should be done via an additional hw_constraint at open,
snd_pcm_hw_constraint_step(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES, CR_FIFO_SIZE / 2);
> +struct snd_pcm_ops snd_ml403_ac97cr_playback_ops = {
Missing static.
> +irqreturn_t snd_ml403_ac97cr_irq(int irq, void *dev_id, struct pt_regs *regs)
Hm, this looks like an old style irq handler.
Did you test the driver with the recent kernel?
Also, missing static there.
> +static unsigned short
> +snd_ml403_ac97cr_codec_read(struct snd_ac97 *ac97, unsigned short reg)
....
> + /* if we are here, we _have_ to access the codec really, no faking */
> + spin_lock(&ml403_ac97cr->reg_lock);
....
> + do {
....
> + schedule_timeout_uninterruptible(1);
> + } while (time_after(end_time, jiffies));
Sleep in spinlock is bad.
> +static int __init
> +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev,
> + struct snd_ml403_ac97cr **rml403_ac97cr)
It's no longer __init as long as you use platform_device.
It should be __devinit instead.
> --- /dev/null
> +++ b/sound/ppc/pcm-indirect2.h
(snip)
> +#ifdef SND_PCM_INDIRECT2_STAT
> +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream *substream,
> + struct snd_pcm_indirect2 *rec)
Remove inline from the functions in this file. They are too lengthy.
sound/pcm-indirect.h contain inline functions becuase they are
relatively small, and I didn't want to add them in the core module
unconditionally.
Last but not least, the whole patch appears not following strictly the
standard kernel coding style. For example, the style
if ((err = foo()) < 0)
....
should be
err = foo();
if (err < 0)
...
Also, many lines are over 80 chars. Fold them appropriately.
At least the new patches should be like that.
In doubt, you can try $KERNEL/scripts/checkpatch.pl script, which was
added recently to linux kernel tree.
Takashi
next prev parent reply other threads:[~2007-08-09 17:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 10:36 [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver Joachim Förster
2007-08-09 17:13 ` Takashi Iwai [this message]
2007-08-09 19:44 ` [alsa-devel] " Joachim Förster
2007-08-09 22:27 ` Takashi Iwai
2007-08-10 11:50 ` Joachim Förster
2007-08-10 12:07 ` Takashi Iwai
2007-08-11 16:23 ` [PATCHv2 1/2] Xilinx " Joachim Förster
2007-08-15 18:45 ` [PATCH] [ML403-AC97CR] Fix (device/driver) name registered with platform bus Joachim Foerster
2007-08-11 16:24 ` [PATCHv2 2/2] [VIRTEX] Register AC97 Controller Reference with the " Joachim Förster
2007-08-09 17:49 ` [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver Grant Likely
2007-08-09 20:01 ` Joachim Förster
2007-08-09 20:07 ` Grant Likely
2007-08-09 22:30 ` Takashi Iwai
2007-08-09 18:17 ` Stephen Neuendorffer
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=s5hsl6sws0s.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=lorenz.kolb@lkmail.de \
--cc=mls.JOFT@gmx.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).