From: Liam Girdwood <lrg@slimlogic.co.uk>
To: Manuel Lauss <manuel.lauss@googlemail.com>
Cc: alsa-devel@alsa-project.org,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
alsa-devel@vger.kernel.org,
Ian Lartey <ian@opensource.wolfsonmicro.com>
Subject: Re: [PATCH v5] ASoC/2.6.37: fix au1x platform
Date: Fri, 27 Aug 2010 13:51:24 +0100 [thread overview]
Message-ID: <1282913484.3025.25.camel@odin> (raw)
In-Reply-To: <1282827231-17323-1-git-send-email-manuel.lauss@googlemail.com>
On Thu, 2010-08-26 at 14:53 +0200, Manuel Lauss wrote:
> This patch fixes up the au1x audio platform after the multi-component
> merge:
> - compile fixes and updates to get DB1200 platform audio working again,
> - removal of global variables in AC97/I2S/DMA(PCM) modules.
>
> The AC97 part is limited to one instance only for now due to issues
> with getting at driver data in the soc_ac97_ops.
>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
> ---
> v5: smaller patch
> v4: fixed a bug in the previous bugfix, and added DAI drvdata accessors.
> v3: fixed a bug which caused cat /proc/iomem to loop endlessly.
> v2: prepare PCM,I2S for multiple card operation, use dev_name() for DAI name.
>
> Against Liam's asoc/for-2.6.37 branch.
>
> Tested on DB1200 and DB1300 (here both I2S and AC97 operate as
> independent cards), please fold this into the other Au1x multi-component
> patches.
>
This all looks fine
> Issues I observed with AC97:
> * AC97 is limited to a single instance since I cannot get at the driver
> data in the AC97 callbacks at all time (or did I miss anything?):
> when the AC97 codec calls snd_ac97_mixer(), it calls into the soc_ac97_ops
> callbacks; however ac97->bus->card->private_data (suggested by Mark)
> is _always_ NULL, so no way to get at the dai and ultimately driver data.
>
> * generic AC97 codec use spits out this kobject warning, which is caused by the
> "device_register()" in soc-core.c::soc_ac97_dev_register():
>
Although I'm curious about these issues. I didn't see them when testing
on my now non working Zylonite with WM9713 (AC97), so I'm suspecting
it's related to the generic AC97 somehow.
Unfortunately, this will need someone with working AC97 hardware to fix
this issue.
Is the AC97 DAI being probed before the generic AC97 codec driver in
this case ?
Liam
next prev parent reply other threads:[~2010-08-27 12:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 12:53 [PATCH v5] ASoC/2.6.37: fix au1x platform Manuel Lauss
2010-08-27 12:51 ` Liam Girdwood [this message]
2010-08-27 13:07 ` Mark Brown
2010-08-27 13:32 ` Manuel Lauss
2010-08-27 19:14 ` Mark Brown
2010-08-27 22:43 ` Manuel Lauss
2010-08-27 23:43 ` Mark Brown
2010-08-31 11:01 ` Mark Brown
2010-09-10 15:00 ` Manuel Lauss
2010-09-10 15:03 ` Mark Brown
2010-10-13 9:33 ` 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=1282913484.3025.25.camel@odin \
--to=lrg@slimlogic.co.uk \
--cc=alsa-devel@alsa-project.org \
--cc=alsa-devel@vger.kernel.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=ian@opensource.wolfsonmicro.com \
--cc=manuel.lauss@googlemail.com \
/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.