Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753854AbbGSTCT (ORCPT ); Sun, 19 Jul 2015 15:02:19 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:34401 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753501AbbGSTCQ (ORCPT ); Sun, 19 Jul 2015 15:02:16 -0400 MIME-Version: 1.0 In-Reply-To: <20150715155946.GB21362@localhost> References: <20150604171547.GA1530@localhost.localdomain> <201507151352.27689.marex@denx.de> <20150715155946.GB21362@localhost> From: Michal Suchanek Date: Sun, 19 Jul 2015 21:01:34 +0200 Message-ID: Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size. To: Brian Norris Cc: 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 , Vinod Koul , =?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: 3119 Lines: 70 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? In the DT you have the information that this particular device is connected to a Samsung SPI controller connected to a pl330 dma engine. > > It is most definitely wrong to put this information solely in the slave > device DT (i.e., for the flash), when it is not a property of the flash > device at all. It's a property of the SPI master and/or its clocks and > DMA controllers. However, the clocks are set by the parameters of the device, not the parameters of the master. So the limitation applies for the master with the settings of the particular slave device. Different slave settings do impose different master limitations. 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/