Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753468AbbGUIPE (ORCPT ); Tue, 21 Jul 2015 04:15:04 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:35772 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753195AbbGUIOw (ORCPT ); Tue, 21 Jul 2015 04:14:52 -0400 MIME-Version: 1.0 In-Reply-To: <20150721042932.GF23525@localhost> References: <20150604171547.GA1530@localhost.localdomain> <201507151352.27689.marex@denx.de> <20150715155946.GB21362@localhost> <20150721042932.GF23525@localhost> From: Michal Suchanek Date: Tue, 21 Jul 2015 10:14:11 +0200 Message-ID: Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size. To: Vinod Koul Cc: Brian Norris , Marek Vasut , Richard Cochran , Geert Uytterhoeven , Mark Rutland , Krzysztof Kozlowski , Geert Uytterhoeven , MTD Maling List , Alison Chaiken , =?UTF-8?B?QmVhbiBIdW8g6ZyN5paM5paMIChiZWFuaHVvKQ==?= , "linux-samsung-soc@vger.kernel.org" , Russell King , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Kukjin Kim , Ben Hutchings , "devicetree@vger.kernel.org" , Pawel Moll , Ian Campbell , Kumar Gala , Mark Brown , Dan Williams , "linux-arm-kernel@lists.infradead.org" , "grmoore@altera.com" , "linux-kernel@vger.kernel.org" , linux-spi , Huang Shijie , Rob Herring , Han Xu , Knut Wohlrab , dmaengine , David Woodhouse Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3688 Lines: 80 Hello, On 21 July 2015 at 06:29, Vinod Koul wrote: > On Sun, Jul 19, 2015 at 09:01:34PM +0200, Michal Suchanek wrote: >> Hello, >> >> On 15 July 2015 at 17:59, Brian Norris wrote: >> > Hi Michal, >> > >> > On Wed, Jul 15, 2015 at 01:52:27PM +0200, Marek Vasut wrote: >> >> The problem is, if you add a new DT binding, you'd have to support it >> >> forever, no matter how bad idea that binding turned out to be. >> > >> > Agreed, and a solid NAK to this patch. I could have sworn I gave such a >> > response when this was originally being discussed a month ago. >> > >> > AFAICT, you have one of two general approaches available to you: >> > >> > 1. Fix up the SPI driver so that it knows how to break large SPI >> > transfers up into smaller segments that its constituent hardware (DMA >> > controllers, fast clocks, etc.) can handle. >> > >> > 2. Utilize/create a parameter within the SPI subsystem to communicate >> > that the SPI master has a limited max transfer size (notably: NOT a >> > per-device DT property, but a SPI API property), and modify SPI device >> > drivers (like m25p80) to honor it. Mark Brown seemed open to this, and I >> > thought he suggested it somewhere. >> >> It is not known what exactly is limited here. >> >> It seems that the pl330 fails but it is not possible to transfer that >> much data over the spi bus in one go without the help of the pl330. >> >> With either approach the limit depends on the SPI transfer settings >> which are known the the SPI driver. The pl330 driver is oblivious to >> these because it just transfers data from one port to another port and >> has no idea that the port is wired to SPI in the SoC. >> >> On the other hand, AFAICT the SPI driver only allocates a DMA channel >> which it receives through DT binding and is oblivious to the fact the >> DMA channel lives on a pl330. It could probably determine that the >> channel is indeed driven by a pl330. I don't think it's a great idea >> to add device-specific handling to a generic dmaengine driver or a >> dmaengine-spiecific handling to a SPI driver. >> >> It's technically possible to pass SPI transfer parameters to the >> dmaengine driver prior to transfer and the dmaengine could impose some >> limitation based on those parameters. However, generalising this to >> drivers other than SPI might be problematic. Should this interface >> also handle i2c parameters, VE parameters, audio parameters, ethernet >> parameters, etc? > Or alternatively we could publish the limitations of the channel using > capabilities so SPI knows I have a dmaengine channel and it can transfer max N > length transfers so would be able to break rather than guessing it or coding > in DT. Yes it may come from DT but that should be dmaengine driver rather > than client driver :) > > This can be done by dma_get_slave_caps(chan, &caps) > > And we add max_length as one more parameter to existing set > > Also all this could be handled in generic SPI-dmaengine layer so that > individual drivers don't have to code it in > > Let me know if this idea is okay, I can push the dmaengine bits... > It would be ok if there was a fixed limit. However, the limit depends on SPI slave settings. Presumably for other buses using the dmaengine the limit would depend on the bus or slave settings as well. I do not see a sane way of passing this all the way to the dmaengine driver. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/