All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 2/7] ASoC: DAPM: Pass snd_dapm_soc_update as parameter
Date: Thu, 28 Apr 2011 22:39:08 +0200	[thread overview]
Message-ID: <4DB9D06C.5090006@metafoo.de> (raw)
In-Reply-To: <20110428194054.GB16837@opensource.wolfsonmicro.com>

On 04/28/2011 09:40 PM, Mark Brown wrote:
> On Thu, Apr 28, 2011 at 06:46:08PM +0200, Lars-Peter Clausen wrote:
>> Pass the snd_dapm_soc_update struct as parameter to dapm_widget_update instead
>> of passing it indirectly as a field of the snd_soc_dapm_context struct.
>> This should make it more obvious were the struct is coming from and make the
>> code easier to comprehend.
> 
> If we're going to do something like this it would be better to make the
> update a more complex object so we weren't passing the stream update
> separately.  The update should be "what we're doing right now" which
> includes the stream operation. [...]

Hm... the current update struct only contains information on register updates,
since we don't not always want to update a register when we sent a stream event
and vice versa it does make sense to keep them separate.
If we end up adding more context information later we might want to reconsider,
but currently keeping them separate is fine in my opinion.

> 
> TBH I'm not sure how much of a help I find this, it's nice to not have
> to pass the operation we're doing about all the time especially if we
> end up using more context information in the middle of the operation
> (which I suspect we may end up doing).  You still have to work back
> through the call chain to find where the data came from.

Well, but you know that it is a parameter to the function call. With the
current scheme you don't know this immediately. Right now dapm->update is some
random global variable and it is not quite clear that it is only valid for the
time dapm_power_widgets is called.

- Lars

  reply	other threads:[~2011-04-28 20:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28 16:46 [PATCH 1/7] ASoC: Fix cards getting stuck in a powered state Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 2/7] ASoC: DAPM: Pass snd_dapm_soc_update as parameter Lars-Peter Clausen
2011-04-28 19:40   ` Mark Brown
2011-04-28 20:39     ` Lars-Peter Clausen [this message]
2011-04-28 20:58       ` Mark Brown
2011-04-28 21:24         ` Lars-Peter Clausen
2011-04-28 21:48           ` Mark Brown
2011-04-28 22:04             ` Lars-Peter Clausen
2011-04-28 22:18               ` Mark Brown
2011-04-28 22:23                 ` Mark Brown
2011-04-28 22:34                   ` Lars-Peter Clausen
2011-04-28 22:48                     ` Mark Brown
2011-04-28 22:58                       ` Lars-Peter Clausen
2011-04-28 22:59                         ` Mark Brown
2011-04-28 16:46 ` [PATCH 3/7] ASoC: Drop unused parameter from dapm_seq_run Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 4/7] ASoC: Pass snd_soc_card instead of snd_soc_dapm_context were appropriate Lars-Peter Clausen
2011-04-28 19:47   ` Mark Brown
2011-04-28 20:13     ` Mark Brown
2011-04-28 16:46 ` [PATCH 5/7] ASoC: Move DAPM debugfs directory creation to snd_soc_dapm_debugfs_init Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 6/7] ASoC: Move DAPM widget debugfs entry creation to snd_soc_dapm_new_widgets Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 7/7] ASoC: Instantiate all DAPM widgets at once Lars-Peter Clausen
2011-04-28 20:07   ` Mark Brown
2011-04-28 20:25     ` Lars-Peter Clausen
2011-04-28 21:18       ` Mark Brown
2011-04-28 19:15 ` [PATCH 1/7] ASoC: Fix cards getting stuck in a powered state Mark Brown
2011-04-28 19:47   ` Lars-Peter Clausen
2011-04-28 19:52     ` Mark Brown
2011-04-28 23:14       ` Lars-Peter Clausen
2011-04-28 23:17         ` Mark Brown
2011-04-28 23:40           ` Lars-Peter Clausen

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=4DB9D06C.5090006@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@slimlogic.co.uk \
    /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.