From: Shawn Lin <shawn.lin@rock-chips.com>
To: Vinod Koul <vinod.koul@intel.com>, Lars-Peter Clausen <lars@metafoo.de>
Cc: shawn.lin@rock-chips.com, Addy Ke <addy.ke@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
Doug Anderson <dianders@chromium.org>,
Takashi Iwai <tiwai@suse.com>,
dmaengine@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Olof Johansson <olof@lixom.net>,
Sonny Rao <sonnyrao@chromium.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [alsa-devel] [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk
Date: Wed, 14 Oct 2015 22:33:06 +0800 [thread overview]
Message-ID: <561E67A2.7080602@rock-chips.com> (raw)
In-Reply-To: <20151014105310.GQ27370@localhost>
On 2015/10/14 18:53, Vinod Koul wrote:
> On Thu, Oct 08, 2015 at 10:31:18AM +0200, Lars-Peter Clausen wrote:
>>> Basically I agree not to expose dma's quirk to slave controllers...But, the
>>> fact I mentioned on cover letter explain the reasons why I have to let slave
>>> controllers know that they are working with a broken dma. It's a dilemma
>>> that if we don't want that to be exposed(let slave controllers' driver get
>>> the info via a API), we have t add broken quirk for all of them ,here and
>>> there, which seems to be a disaster:(
>>
>> The problem with this API is that it transports values with device specific
>> meanings over a generic API. Which is generally speaking not a good idea
>> because the consumer witch is supposed to be generic suddenly needs to know
>> which provider it is talking to.
>>
>> A better solution in this case typically is either introduce a generic API
>> with generic values or a custom API with custom values, but don't mix the two.
>>
>>>
>>> I would appreciate it if you could give me some suggestions at your earliest
>>> convenience. :)
>>
>> In this case I think the best way to handle this is not quirks, but rather
>> expose the actual maximum burst size using the DMA capabilities API. Since
>> supporting only a certain burst depth is not really a quirk. All hardware
>> has a limit for this and for some it might be larger or smaller than for
>> others and it might be the same IP core but the maximum size depends on some
>> IP core parameters. So this should be discoverable.
>
> yes that makes more sense than adding quirks, exposing the right values
> which should be a readable property for driver will ensure it works on
> system with/without quirks
Sorry for late response in this thread.
Right, we can expose max-burst to clients by dma_slave_caps instead of
quirks. I will try it and send v6 ASAP.
Thanks Lars and Vinod.
>
--
Best Regards
Shawn Lin
next prev parent reply other threads:[~2015-10-14 14:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 23:45 [PATCH v5 0/10] Fix broken DMAFLUSHP on Rockchips platform Shawn Lin
2015-09-13 23:46 ` [PATCH v5 01/10] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit Shawn Lin
2015-09-13 23:46 ` [PATCH v5 02/10] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp Shawn Lin
2015-09-13 23:48 ` [PATCH v5 03/10] DMA: pl330: add quirk for broken no flushp Shawn Lin
2015-09-13 23:48 ` [PATCH v5 04/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform Shawn Lin
2015-09-13 23:48 ` [PATCH v5 05/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform Shawn Lin
2015-09-13 23:48 ` [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk Shawn Lin
2015-10-05 15:37 ` Vinod Koul
2015-10-06 9:21 ` Shawn Lin
2015-10-07 14:32 ` Vinod Koul
2015-10-09 11:23 ` Shawn Lin
2015-10-08 8:31 ` [alsa-devel] " Lars-Peter Clausen
2015-10-09 11:31 ` Shawn Lin
2015-10-09 11:38 ` Lars-Peter Clausen
2015-10-14 10:53 ` Vinod Koul
2015-10-14 14:33 ` Shawn Lin [this message]
2015-09-13 23:49 ` [PATCH v5 07/10] DMA: pl330: implement dmaengine_get_quirks hook Shawn Lin
2015-09-13 23:49 ` [PATCH v5 08/10] spi: rockchip: modify DMA max burst to 1 Shawn Lin
2015-09-13 23:49 ` [PATCH v5 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_quirks interface Shawn Lin
2015-09-13 23:49 ` [PATCH v5 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1 Shawn Lin
2015-09-16 19:22 ` Mark Brown
2015-09-28 1:59 ` [PATCH v5 0/10] Fix broken DMAFLUSHP on Rockchips platform Shawn Lin
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=561E67A2.7080602@rock-chips.com \
--to=shawn.lin@rock-chips.com \
--cc=addy.ke@rock-chips.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=dmaengine@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=olof@lixom.net \
--cc=sonnyrao@chromium.org \
--cc=tiwai@suse.com \
--cc=vinod.koul@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).