From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754162AbbJNOd1 (ORCPT ); Wed, 14 Oct 2015 10:33:27 -0400 Received: from lucky1.263xmail.com ([211.157.147.132]:46508 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753402AbbJNOdY (ORCPT ); Wed, 14 Oct 2015 10:33:24 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-SENDER-IP: 220.200.5.74 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [alsa-devel] [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk To: Vinod Koul , Lars-Peter Clausen References: <1442187923-5736-1-git-send-email-shawn.lin@rock-chips.com> <1442188139-6017-1-git-send-email-shawn.lin@rock-chips.com> <20151005153746.GG13501@vkoul-mobl.iind.intel.com> <56139289.7000005@rock-chips.com> <561629D6.9010702@metafoo.de> <20151014105310.GQ27370@localhost> Cc: shawn.lin@rock-chips.com, Addy Ke , Heiko Stuebner , alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Doug Anderson , Takashi Iwai , dmaengine@vger.kernel.org, Mark Brown , Olof Johansson , Sonny Rao , linux-arm-kernel@lists.infradead.org From: Shawn Lin Message-ID: <561E67A2.7080602@rock-chips.com> Date: Wed, 14 Oct 2015 22:33:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151014105310.GQ27370@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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