From: "Péter Ujfalusi" <peter.ujfalusi@ti.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
"Girdwood, Liam" <lrg@ti.com>,
"Lopez Cruz, Misael" <misael.lopez@ti.com>
Subject: Re: [PATCH v2 2/2] ASoC: omap-mcpdm: Replace legacy driver
Date: Tue, 23 Aug 2011 09:49:44 +0300 [thread overview]
Message-ID: <12518591.ESZDKfh5zZ@barack> (raw)
In-Reply-To: <4E525C03.6090405@metafoo.de>
On Monday 22 August 2011 15:39:15 Lars-Peter Clausen wrote:
> omap_mcpdm_widgets is a global variable.
Yeah, as most of the snd_soc_dapm_widget.
> You assign to it in asoc_mcpdm_probe
Since at compile time I don't have the pointer for the mcpdm (it is allocated
earlier in the same function), I need to assign it somewhere.
> and read from it in omap_mcpdm_add_dapm_widget.
I don't see any reference to the omap_mcpdm_widgets in there.
> The fact that you hide your *mcpdm in a void pointer doesn't make it less
> hackish.
Well, from that point of view most of the kernel is hackish. We tend to have
void pointers for various things, like platform_data, device_data,
driver_data, private_data, etc.
You see, the point here is that this private_data for the widget can be used
for others as well, if needed. It would make no sense to put "struct
omap_mcpdm *mcpdm", just because I have this requirement first, does it?
For sure, I could have chosen to create one global pointer for this event
handler:
static struct omap_mcpdm *mcpdm_global;
Use the mcpdm_global within omap_mcpdm_interface_event function, and assign it
at asoc_mcpdm_probe time.
Would that look better? IMHO it is not.
As Mark suggested, we should have accessor for this, if we are going to have
such a thing.
The reason for this (as I described in the commit message):
OMAP McPDM has the requirement (along with the twl6040), that we need to stop
the cpu dai _after_ the DAC/ADC has been stopped on the codec side.
Now, I do not want to hard wire the twl6040, nor the omap-mcpdm with each
other.
The omap-mcpdm implements the event callback, and the machine driver is
responsible to create the DAPM route to make sure we follow the correct
sequence.
I could as well implemented these things in the machine driver (+global
pointer for mcpdm), but that can lead duplicated code in the future (new
machine driver, etc).
--
Péter
next prev parent reply other threads:[~2011-08-23 6:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 7:41 [PATCH v2 0/2] ASoC: omap-mcpdm: New McPDM driver Peter Ujfalusi
2011-08-19 7:41 ` [PATCH v2 1/2] ASoC: DAPM: Add private data pointer for DAPM widget Peter Ujfalusi
2011-08-20 7:02 ` Mark Brown
2011-08-22 13:33 ` Péter Ujfalusi
2011-08-22 22:32 ` Mark Brown
2011-08-19 7:41 ` [PATCH v2 2/2] ASoC: omap-mcpdm: Replace legacy driver Peter Ujfalusi
2011-08-19 8:38 ` Lars-Peter Clausen
2011-08-19 8:49 ` Lars-Peter Clausen
2011-08-19 12:38 ` Liam Girdwood
2011-08-19 13:13 ` Lars-Peter Clausen
2011-08-19 16:59 ` Liam Girdwood
2011-08-22 11:34 ` Péter Ujfalusi
2011-08-22 13:04 ` Mark Brown
2011-08-22 13:39 ` Lars-Peter Clausen
2011-08-23 6:49 ` Péter Ujfalusi [this message]
2011-08-23 10:14 ` Lars-Peter Clausen
2011-08-26 8:08 ` Péter Ujfalusi
2011-08-19 13:33 ` Paul Menzel
2011-08-20 7:01 ` Mark Brown
2011-08-23 7:52 ` Péter Ujfalusi
2011-08-23 10:57 ` Mark Brown
2011-08-26 8:01 ` Péter Ujfalusi
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=12518591.ESZDKfh5zZ@barack \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lars@metafoo.de \
--cc=lrg@ti.com \
--cc=misael.lopez@ti.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.