[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b77c227a-6779-6ed7-9ce8-68b996a08caa@linux.intel.com>
Date: Fri, 10 Jan 2020 10:11:46 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Vinod Koul <vkoul@...nel.org>
Cc: alsa-devel@...a-project.org, tiwai@...e.de,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
broonie@...nel.org, srinivas.kandagatla@...aro.org,
jank@...ence.com, slawomir.blauciak@...el.com,
Sanyog Kale <sanyog.r.kale@...el.com>,
Bard liao <yung-chuan.liao@...ux.intel.com>,
Rander Wang <rander.wang@...ux.intel.com>
Subject: Re: [alsa-devel] [PATCH 4/6] soundwire: stream: do not update
parameters during DISABLED-PREPARED transition
>> + /*
>> + * when the stream is DISABLED, this means sdw_prepare_stream()
>> + * is called as a result of an underflow or a resume operation.
>> + * In this case, the bus parameters shall not be recomputed, but
>> + * still need to be re-applied
>> + */
>> + if (stream->state == SDW_STREAM_DISABLED)
>> + update_params = false;
>
> Should this not be handled by the caller..? I do not like to deduce this
> here as the info is already available in dai driver, so go ahead and
> propagate it and get it from caller when it is required..
No, this update_params boolean is used later on to modify the bandwidth
computation. These values are not accessible to the caller (and should
absolutely be kept private/opaque).
Powered by blists - more mailing lists