From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932465AbbIDADi (ORCPT ); Thu, 3 Sep 2015 20:03:38 -0400 Received: from lucky1.263xmail.com ([211.157.147.130]:45619 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758241AbbIDADd (ORCPT ); Thu, 3 Sep 2015 20:03:33 -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: olof@lixom.net X-SENDER-IP: 220.200.58.250 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v3 8/9] spi: rockchip: modify DMA max burst to 1 To: Mark Brown References: <1441101381-1329-1-git-send-email-shawn.lin@rock-chips.com> <1441101524-1700-1-git-send-email-shawn.lin@rock-chips.com> <20150903125429.GA12027@sirena.org.uk> <55E84E17.2090409@rock-chips.com> <20150903174502.GI5313@sirena.org.uk> Cc: shawn.lin@rock-chips.com, Vinod Koul , Heiko Stuebner , Jaroslav Kysela , Takashi Iwai , Doug Anderson , Olof Johansson , Sonny Rao , Addy Ke , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, alsa-devel@alsa-project.org, linux-spi@vger.kernel.org, Olof Johansson From: Shawn Lin Message-ID: <55E8DFCE.5040504@rock-chips.com> Date: Fri, 4 Sep 2015 08:03:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150903174502.GI5313@sirena.org.uk> 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/9/4 1:45, Mark Brown wrote: > On Thu, Sep 03, 2015 at 09:41:43PM +0800, Shawn Lin wrote: >> On 2015/9/3 20:54, Mark Brown wrote: > >>> If this is a quirk of the DMA controller why is it being fixed with a >>> property specific to the SPI controller? Can't the DMA controller just >>> override the burst size? > >> Cool...that's a good question. Actually DMA controller can't do that since >> block peripheral controller(e.g sd/emmc, they always access data by >> block-512Bytes.) can't meet the case. So It's hard for dma controller know >> who is the caller, and what should be done. > > You could take a guess based on request size, but that's going to be a > bit error prone I imagine. > yes, not always cover all cases. >> The only thing dma controller can do is avoid to execute DMAFLUSHP on its >> own. But how about peripheral controller trigger non-multiple access? So >> that's what I mentioned on covery letter that we should do "broken things" >> for both dma controller and some peripherals. > > The other thing it could do is provide the information out via some > internal Linux API which the drivers could query instead of directly > having a DT property in each client driver. That way at least the DT > only needs the quirk in one place even if the clients need to handle it > individually. Good idea. Thanks, Mark. > -- Best Regards Shawn Lin