From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
tiwai@suse.de, gregkh@linuxfoundation.org,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
broonie@kernel.org, srinivas.kandagatla@linaro.org,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
jank@cadence.com, slawomir.blauciak@intel.com,
Sanyog Kale <sanyog.r.kale@intel.com>,
Bard liao <yung-chuan.liao@linux.intel.com>,
Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH 13/14] soundwire: intel: free all resources on hw_free()
Date: Fri, 8 Nov 2019 08:39:49 -0600 [thread overview]
Message-ID: <6daf0d90-a5f9-d510-f458-879528500134@linux.intel.com> (raw)
In-Reply-To: <20191108041435.GV952516@vkoul-mobl>
On 11/7/19 10:14 PM, Vinod Koul wrote:
> On 04-11-19, 15:46, Pierre-Louis Bossart wrote:
>> On 11/4/19 2:08 PM, Cezary Rojewski wrote:
>>> On 2019-10-23 23:28, Pierre-Louis Bossart wrote:
>>>> @@ -816,6 +835,7 @@ static int
>>>> intel_hw_free(struct snd_pcm_substream *substream, struct
>>>> snd_soc_dai *dai)
>>>> {
>>>> struct sdw_cdns *cdns = snd_soc_dai_get_drvdata(dai);
>>>> + struct sdw_intel *sdw = cdns_to_intel(cdns);
>>>> struct sdw_cdns_dma_data *dma;
>>>> int ret;
>>>> @@ -823,12 +843,28 @@ intel_hw_free(struct snd_pcm_substream
>>>> *substream, struct snd_soc_dai *dai)
>>>> if (!dma)
>>>> return -EIO;
>>>> + ret = sdw_deprepare_stream(dma->stream);
>>>> + if (ret) {
>>>> + dev_err(dai->dev, "sdw_deprepare_stream: failed %d", ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>
>>> I understand that you want to be transparent to caller with failure
>>> reasons via dev_err/_warn. However, sdw_deprepare_stream already dumps
>>> all the logs we need. The same applies for most of the other calls (and
>>> not just in this patch..).
>
> I think this is a valid concern! In linux we do not do that, for example
> we ask people to not log errors on kmalloc as it will be logged on
> failures so drivers do not need to do that.
>
>>> Do we really need to be that verbose? Maybe just agree on caller -or-
>>> subject being the source for the messaging, align existing usages and
>>> thus preventing further duplication?
>>>
>>> Not forcing anything, just asking for your opinion on this.
>>
>> the sdw_prepare/deprepare_stream calls provide error logs, but they are not
>> mapped to specific devices/dais (pr_err vs. dev_dbg). I found it was easier
>> to check for which dai the error was reported.
>
> Well in that case we should fix pr_err, there are only 17 instances of
> these in core, and few of them are justified in core (no dev pointer)
> and 11 in stream (few of them valid (no stream pointer) but rest can be
> converted to use dev_err! Even then they print stream name, so checking
> error is not justified argument!
the stream has no notion of device, it can be made of multiple devices,
so which one would you choose?
>
>> We are also in the middle of integration with new hardware/boards, and
>> erring on the side of more traces will help everyone involved. We can
>> revisit later which ones are strictly necessary.
>
> Naah you are having duplicate logs, it does *not* help in debug seems
> 1000 line logs and few lines conveying duplicate info, I would rather
> have each line unique so that I dont have to skip duplicate ones while
> debugging!
They are not all duplicates.
Again, if I remove the logs in stream.c, then I do lose valuable
information on bad state machines transitions, etc. An error code is not
enough to reconstruct the issues from intel.c
If I remove the logs in intel.c, I can't know which dai had an error and
what caused it.
seriously, these are all details, you have over 50 patches to review
with a complete rework of this subsystem and we argue about dev_err
verbosity?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-11-08 15:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 21:28 [alsa-devel] [PATCH 00/14] soundwire: intel: implement new ASoC interfaces Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 01/14] soundwire: renames to prepare support for master drivers/devices Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 02/14] soundwire: rename dev_to_sdw_dev macro Pierre-Louis Bossart
2019-11-03 5:28 ` Vinod Koul
2019-10-23 21:28 ` [alsa-devel] [PATCH 03/14] soundwire: rename drv_to_sdw_slave_driver macro Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 04/14] soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv Pierre-Louis Bossart
2019-11-03 5:30 ` Vinod Koul
2019-11-04 14:34 ` Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 05/14] soundwire: intel: rename res field as link_res Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 06/14] soundwire: add support for sdw_slave_type Pierre-Louis Bossart
2019-11-03 5:32 ` Vinod Koul
2019-11-04 14:35 ` Pierre-Louis Bossart
2019-11-04 19:33 ` Cezary Rojewski
2019-11-04 19:41 ` Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 07/14] soundwire: add initial definitions for sdw_master_device Pierre-Louis Bossart
2019-11-03 6:30 ` Vinod Koul
2019-11-04 14:42 ` Pierre-Louis Bossart
2019-11-08 4:04 ` Vinod Koul
2019-11-08 14:41 ` Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 08/14] soundwire: intel: remove platform devices and provide new interface Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 09/14] soundwire: add device driver to sdw_md_driver Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 10/14] soundwire: intel: add prepare support in sdw dai driver Pierre-Louis Bossart
2019-11-04 19:45 ` Cezary Rojewski
2019-11-04 21:31 ` Pierre-Louis Bossart
2019-11-08 4:05 ` Vinod Koul
2019-10-23 21:28 ` [alsa-devel] [PATCH 11/14] soundwire: intel: add trigger " Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 12/14] soundwire: intel: add sdw_stream_setup helper for .startup callback Pierre-Louis Bossart
2019-10-23 21:28 ` [alsa-devel] [PATCH 13/14] soundwire: intel: free all resources on hw_free() Pierre-Louis Bossart
2019-11-04 20:08 ` Cezary Rojewski
2019-11-04 21:46 ` Pierre-Louis Bossart
2019-11-08 4:14 ` Vinod Koul
2019-11-08 14:39 ` Pierre-Louis Bossart [this message]
2019-10-23 21:28 ` [alsa-devel] [PATCH 14/14] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
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=6daf0d90-a5f9-d510-f458-879528500134@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jank@cadence.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rander.wang@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=slawomir.blauciak@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.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 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).