From: Mark Brown <broonie@kernel.org> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>, Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 10/13] ASoC: kirkwood-t5325: add DAPM links between codec and cpu DAI Date: Wed, 28 Aug 2013 02:22:15 +0100 [thread overview] Message-ID: <20130828012215.GF10783@sirena.org.uk> (raw) In-Reply-To: <20130823174505.GQ6617@n2100.arm.linux.org.uk> [-- Attachment #1.1: Type: text/plain, Size: 2659 bytes --] On Fri, Aug 23, 2013 at 06:45:05PM +0100, Russell King - ARM Linux wrote: > Look Mark, frankly, shut your fucking mouth up about DPCM. This bug has > nothing what so ever to do with DPCM, and the more times you try and > state that doesn't change that *FACT*. And it is a FACT. You must know that this and the rest of your e-mail are not an appropriate or constructive way to interact with people. I now regret that have not confronted you on this more openly and directly before but unfortunately I had hoped that stepping back would help with deescalation. I know I have needed to take a step back on several occasions myself in order to be calmer in my response. > So that's why it fails _without_ any DPCM stuff? That's why the codecs > fail to have their set_bias stuff called? So, it is true that the widgets get double created in all cases where the same struct device is used for both platform and DAI. However if DPCM is not used nothing really notices since the SoC side widgets don't do anything useful. The relevance of DPCM is that it tries to use the widgets and therefore causes practical problems in normal use, otherwise it's just a memory leak on init. As you know the issue with the DAPMless CODECs was unrelated to this, was due to poor test coverage of such devices and has been resolved by making DAPM mandatory for CODECs to eliminate the possibility of similar regressions caused by the need for special casing. > You've had this problem described by IRC, including extracts from the > ASoC code indicating where things go wrong. I've shown you the debug > I've used. I've shown you the result of that debug. You've had > descriptions of this problem via email too. Yet you refuse to acknowledge > that there could possibly be a problem here. I am fairly sure that I have agreed that there is a bug and at the very least not said that everything is fine. Just for the record there clearly is a bug with double creation of DAI widgets when the same struct device is used to register both a DAI and a platform. You will also recall that Liam said he would provide a patch when he has time. As I have told you before your generally confrontational and demanding approach is not a good one for getting help from people, it doesn't help push your problems up the priority list or generate positive attention. Especially with the more extreme examples it can actively work against engagement; at an unconscious level it makes things less fun and at a conscious level not only are breaks for calm needed but I know that I at least have no desire to encourage anyone to believe that this is a good way of getting results. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown) To: linux-arm-kernel@lists.infradead.org Subject: [alsa-devel] [PATCH RFC 10/13] ASoC: kirkwood-t5325: add DAPM links between codec and cpu DAI Date: Wed, 28 Aug 2013 02:22:15 +0100 [thread overview] Message-ID: <20130828012215.GF10783@sirena.org.uk> (raw) In-Reply-To: <20130823174505.GQ6617@n2100.arm.linux.org.uk> On Fri, Aug 23, 2013 at 06:45:05PM +0100, Russell King - ARM Linux wrote: > Look Mark, frankly, shut your fucking mouth up about DPCM. This bug has > nothing what so ever to do with DPCM, and the more times you try and > state that doesn't change that *FACT*. And it is a FACT. You must know that this and the rest of your e-mail are not an appropriate or constructive way to interact with people. I now regret that have not confronted you on this more openly and directly before but unfortunately I had hoped that stepping back would help with deescalation. I know I have needed to take a step back on several occasions myself in order to be calmer in my response. > So that's why it fails _without_ any DPCM stuff? That's why the codecs > fail to have their set_bias stuff called? So, it is true that the widgets get double created in all cases where the same struct device is used for both platform and DAI. However if DPCM is not used nothing really notices since the SoC side widgets don't do anything useful. The relevance of DPCM is that it tries to use the widgets and therefore causes practical problems in normal use, otherwise it's just a memory leak on init. As you know the issue with the DAPMless CODECs was unrelated to this, was due to poor test coverage of such devices and has been resolved by making DAPM mandatory for CODECs to eliminate the possibility of similar regressions caused by the need for special casing. > You've had this problem described by IRC, including extracts from the > ASoC code indicating where things go wrong. I've shown you the debug > I've used. I've shown you the result of that debug. You've had > descriptions of this problem via email too. Yet you refuse to acknowledge > that there could possibly be a problem here. I am fairly sure that I have agreed that there is a bug and at the very least not said that everything is fine. Just for the record there clearly is a bug with double creation of DAI widgets when the same struct device is used to register both a DAI and a platform. You will also recall that Liam said he would provide a patch when he has time. As I have told you before your generally confrontational and demanding approach is not a good one for getting help from people, it doesn't help push your problems up the priority list or generate positive attention. Especially with the more extreme examples it can actively work against engagement; at an unconscious level it makes things less fun and at a conscious level not only are breaks for calm needed but I know that I at least have no desire to encourage anyone to believe that this is a good way of getting results. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130828/eb576630/attachment.sig>
next prev parent reply other threads:[~2013-08-28 1:22 UTC|newest] Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-04 19:21 [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Russell King - ARM Linux 2013-08-04 19:21 ` Russell King - ARM Linux 2013-08-04 19:22 ` [PATCH RFC 01/13] ASoC: kirkwood: merge struct kirkwood_dma_priv with struct kirkwood_dma_data Russell King 2013-08-04 19:22 ` Russell King 2013-08-05 14:49 ` Mark Brown 2013-08-05 14:49 ` Mark Brown 2013-08-04 19:23 ` [PATCH RFC 02/13] ASoC: kirkwood: use devm_clk_get() for the external clock Russell King 2013-08-04 19:23 ` Russell King 2013-08-05 16:16 ` Mark Brown 2013-08-05 16:16 ` Mark Brown 2013-08-04 19:24 ` [PATCH RFC 03/13] ASoC: avoid duplicated DAI routes Russell King 2013-08-04 19:24 ` Russell King 2013-08-05 16:18 ` Mark Brown 2013-08-05 16:18 ` Mark Brown 2013-08-04 19:25 ` [PATCH RFC 04/13] ASoC: HACK: avoid creating duplicated widgets Russell King 2013-08-04 19:25 ` Russell King 2013-08-04 19:26 ` [PATCH RFC 05/13] ASoC: kirkwood: provide KIRKWOOD_PLAYCTL_ENABLE_MASK Russell King 2013-08-04 19:26 ` Russell King 2013-08-05 17:03 ` Mark Brown 2013-08-05 17:03 ` Mark Brown 2013-08-04 19:27 ` [PATCH RFC 06/13] ASoC: kirkwood: combine kirkwood-i2s and kirkwood-dma drivers Russell King 2013-08-04 19:27 ` Russell King 2013-08-05 10:13 ` Jean-Francois Moine 2013-08-05 10:13 ` Jean-Francois Moine 2013-08-05 10:20 ` Russell King - ARM Linux 2013-08-05 10:20 ` Russell King - ARM Linux 2013-08-05 17:04 ` Mark Brown 2013-08-05 17:04 ` Mark Brown 2013-08-04 19:28 ` [PATCH RFC 07/13] ASoC: kirkwood: move calculation of max buffer size to kirkwood.h Russell King 2013-08-04 19:28 ` Russell King 2013-08-05 17:07 ` Mark Brown 2013-08-05 17:07 ` Mark Brown 2013-08-04 19:29 ` [PATCH RFC 08/13] ASoC: kirkwood: add DAPM widgets for input and output routing Russell King 2013-08-04 19:29 ` Russell King 2013-08-04 19:30 ` [PATCH RFC 09/13] ASoC: kirkwood-openrd: add DAPM links between codec and cpu DAI Russell King 2013-08-04 19:30 ` Russell King 2013-08-04 19:31 ` [PATCH RFC 10/13] ASoC: kirkwood-t5325: " Russell King 2013-08-04 19:31 ` Russell King 2013-08-05 11:27 ` Mark Brown 2013-08-05 11:27 ` Mark Brown 2013-08-05 11:33 ` Russell King - ARM Linux 2013-08-05 11:33 ` Russell King - ARM Linux 2013-08-05 14:40 ` Mark Brown 2013-08-05 14:40 ` Mark Brown 2013-08-05 14:56 ` Russell King - ARM Linux 2013-08-05 14:56 ` Russell King - ARM Linux 2013-08-05 20:32 ` Russell King - ARM Linux 2013-08-05 20:32 ` Russell King - ARM Linux 2013-08-05 22:06 ` Mark Brown 2013-08-05 22:06 ` Mark Brown 2013-08-05 23:30 ` Russell King - ARM Linux 2013-08-05 23:30 ` Russell King - ARM Linux 2013-08-06 13:32 ` Mark Brown 2013-08-06 13:32 ` Mark Brown 2013-08-10 16:11 ` Russell King - ARM Linux 2013-08-10 16:11 ` Russell King - ARM Linux 2013-08-10 21:13 ` Russell King - ARM Linux 2013-08-10 21:13 ` Russell King - ARM Linux 2013-08-12 7:40 ` Liam Girdwood 2013-08-12 7:40 ` [alsa-devel] " Liam Girdwood 2013-08-12 8:28 ` Russell King - ARM Linux 2013-08-12 8:28 ` [alsa-devel] " Russell King - ARM Linux 2013-08-13 14:59 ` Liam Girdwood 2013-08-13 14:59 ` [alsa-devel] " Liam Girdwood 2013-08-20 10:25 ` Russell King - ARM Linux 2013-08-20 10:25 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 11:44 ` Mark Brown 2013-08-20 11:44 ` [alsa-devel] " Mark Brown 2013-08-20 11:49 ` Russell King - ARM Linux 2013-08-20 11:49 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 13:31 ` Russell King - ARM Linux 2013-08-20 13:31 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 18:50 ` Mark Brown 2013-08-20 18:50 ` [alsa-devel] " Mark Brown 2013-08-20 20:18 ` Russell King - ARM Linux 2013-08-20 20:18 ` [alsa-devel] " Russell King - ARM Linux 2013-08-22 19:22 ` Liam Girdwood 2013-08-22 19:22 ` [alsa-devel] " Liam Girdwood 2013-08-22 20:16 ` Russell King - ARM Linux 2013-08-22 20:16 ` [alsa-devel] " Russell King - ARM Linux 2013-08-23 12:13 ` Liam Girdwood 2013-08-23 12:13 ` [alsa-devel] " Liam Girdwood 2013-08-23 12:58 ` Russell King - ARM Linux 2013-08-23 12:58 ` [alsa-devel] " Russell King - ARM Linux 2013-08-23 16:58 ` Mark Brown 2013-08-23 16:58 ` [alsa-devel] " Mark Brown 2013-08-23 17:45 ` Russell King - ARM Linux 2013-08-23 17:45 ` [alsa-devel] " Russell King - ARM Linux 2013-08-28 1:22 ` Mark Brown [this message] 2013-08-28 1:22 ` Mark Brown 2013-08-29 21:12 ` Liam Girdwood 2013-08-30 11:27 ` Russell King - ARM Linux 2013-08-30 11:27 ` [alsa-devel] " Russell King - ARM Linux 2013-08-30 16:10 ` Russell King - ARM Linux 2013-08-30 16:10 ` [alsa-devel] " Russell King - ARM Linux 2013-08-11 12:36 ` Mark Brown 2013-08-11 12:36 ` Mark Brown 2013-08-04 19:32 ` [PATCH RFC 11/13] ASoC: spdif_transceiver: add output pin widget Russell King 2013-08-04 19:32 ` Russell King 2013-08-05 11:33 ` Mark Brown 2013-08-05 11:33 ` Mark Brown 2013-08-04 19:33 ` [PATCH RFC 12/13] ASoC: kirkwood: add SPDIF output support Russell King 2013-08-04 19:33 ` Russell King 2013-08-04 19:34 ` [PATCH RFC 13/13] ASoC: kirkwood: add IEC958 channel status support Russell King 2013-08-04 19:34 ` Russell King 2013-08-04 21:45 ` [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Sebastian Hesselbarth 2013-08-04 21:45 ` Sebastian Hesselbarth 2013-08-05 8:43 ` Thomas Petazzoni 2013-08-05 8:43 ` Thomas Petazzoni 2013-08-05 8:53 ` Russell King - ARM Linux 2013-08-05 8:53 ` Russell King - ARM Linux 2013-08-05 9:06 ` Thomas Petazzoni 2013-08-05 9:06 ` Thomas Petazzoni 2013-08-05 11:59 ` Mark Brown 2013-08-05 11:59 ` Mark Brown 2013-08-05 13:06 ` Sebastian Hesselbarth 2013-08-05 13:06 ` Sebastian Hesselbarth 2013-08-05 14:07 ` Mark Brown 2013-08-05 14:07 ` Mark Brown 2013-08-05 15:04 ` Sebastian Hesselbarth 2013-08-05 15:04 ` Sebastian Hesselbarth 2013-08-05 16:59 ` Mark Brown 2013-08-05 16:59 ` Mark Brown 2013-08-05 18:14 ` Sebastian Hesselbarth 2013-08-05 18:14 ` Sebastian Hesselbarth 2013-08-05 18:59 ` Mark Brown 2013-08-05 18:59 ` Mark Brown 2013-08-05 22:47 ` Stephen Warren 2013-08-05 22:47 ` [alsa-devel] " Stephen Warren 2013-08-05 14:10 ` Lars-Peter Clausen 2013-08-05 14:10 ` [alsa-devel] " Lars-Peter Clausen 2013-08-05 15:03 ` Mark Brown 2013-08-05 15:03 ` [alsa-devel] " Mark Brown 2013-08-06 0:02 ` Kuninori Morimoto 2013-08-06 0:02 ` [alsa-devel] " Kuninori Morimoto 2013-08-30 7:20 ` Kuninori Morimoto 2013-08-30 7:20 ` [alsa-devel] " Kuninori Morimoto 2013-08-30 8:26 ` Lars-Peter Clausen 2013-08-30 8:26 ` [alsa-devel] " Lars-Peter Clausen 2013-08-30 9:56 ` Mark Brown 2013-08-30 9:56 ` [alsa-devel] " Mark Brown 2013-08-05 14:59 ` Russell King - ARM Linux 2013-08-05 14:59 ` Russell King - ARM Linux
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=20130828012215.GF10783@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=lgirdwood@gmail.com \ --cc=liam.r.girdwood@linux.intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@arm.linux.org.uk \ --cc=tiwai@suse.de \ /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: linkBe 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.