Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752938AbbHZVQG (ORCPT ); Wed, 26 Aug 2015 17:16:06 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:50384 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbbHZVQD (ORCPT ); Wed, 26 Aug 2015 17:16:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Wed, 26 Aug 2015 14:15:45 -0700 From: Stefan Agner To: Boris Brezillon , Bill Pringlemeir Cc: Brian Norris , dwmw2@infradead.org, sebastian@breakpoint.cc, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, shawn.guo@linaro.org, kernel@pengutronix.de, marb@ixxat.de, aaron@tastycactus.com, bpringlemeir@gmail.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr, klimov.linux@gmail.com, Bill Pringlemeir Subject: Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings In-Reply-To: <20150826173903.25479201@bbrezillon> References: <1438594050-4595-1-git-send-email-stefan@agner.ch> <1438594050-4595-4-git-send-email-stefan@agner.ch> <20150825202546.GL81844@google.com> <20150826173903.25479201@bbrezillon> Message-ID: <56589547ed623481ca2b94ff364d6434@agner.ch> User-Agent: Roundcube Webmail/1.1.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4500 Lines: 100 On 2015-08-26 08:39, Boris Brezillon wrote: > Hi Bill, > > On Wed, 26 Aug 2015 11:26:36 -0400 > Bill Pringlemeir wrote: > >> On 25 Aug 2015, computersforpeace@gmail.com wrote: >> >> > Sorry, I realized a potential issue here. >> >> > On Mon, Aug 03, 2015 at 11:27:28AM +0200, Stefan Agner wrote: >> >> Signed-off-by: Bill Pringlemeir >> >> Acked-by: Shawn Guo >> >> Reviewed-by: Brian Norris >> >> Signed-off-by: Stefan Agner >> >> --- >> >> .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++++++++++++++++++++++ >> >> 1 file changed, 45 insertions(+) create mode 100644 >> >> Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> >> >> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> >> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> >> new file mode 100644 >> >> index 0000000..cae5f25 >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> >>>> -0,0 +1,45 @@ >> >> +- nand-bus-width: see nand.txt >> >> +- nand-ecc-mode: see nand.txt >> >> +- nand-on-flash-bbt: see nand.txt >> >> > Stumbling across the "multi-CS" questions on the driver reminds me: it >> > typically makes sense to define new NAND bindings using separate NAND >> > *controller* and *flash* device nodes. The above 3 properties, at >> > least, would apply on a per-flash basis, not per-controller >> > typically. See sunxi-nand, for instance: >> >> > http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt >> >> > brcmnand had a similar pattern: >> >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> >> > (Perhaps it's time we standardized this a little more formally...) >> >> These would apply per chip, but the controller has to be configured to >> support each and every one. Every time an operation was performed, we >> would have to check the chip type and reconfigure the controller. >> Currently, the driver does not support this and it would add a lot of >> overhead in some cases unless a register cache was used. >> >> Is the flexibility of using a system with combined 8/16bit devices >> really worth all the overhead? Isn't it sort of brain dead hardware not >> to make all of the chips similar? Why would everyone have to pay for >> such a crazy setup? >> >> To separate it would at least be a lie versus the code in the current >> form. As well, there are only a few SOC which support multiple chip >> selects. The 'multi-CS' register bits of this controller varies between >> PowerPC, 68K/Coldfire and ARM platforms. The DT can be a lie versus the code. The DT should reflect how the hardware is wired, afaik, if we take shortcuts in the driver code, that is fine. If we don't support a certain configuration right now (e.g. second NAND chip), the driver can just return an appropriate error code. >> >> I looked briefly at the brcmnand.c and it seems that it is not >> supporting different ECC per chip even though the nodes are broken out >> this way. In fact, if some raw functions are called, I think it will >> put it in ECC mode even if it wasn't before? Well, I agree that this >> would be good generically, I think it puts a lot of effort in the >> drivers for not so much payoff? > > Hm, the sunxi driver supports it, and it does not add such a big > overhead... > The only thing you have to do is cache a bunch of register values > per-chip and restore/apply them when the chip is selected > (in your ->select_chip() implementation). > > Anyway, even if the suggested DT representation is a lie in regards to > your implementation, it's actually pretty accurate from an hardware > POV, and this is exactly what DT is supposed to represent. I agree with both of you. I don't see much value implementing multi-NAND chip support, especially with different configurations, at the moment. I am not aware of any hardware making use of that now. I will update the driver to parse a NAND sub node and get the ECC properties from the per flash configuration. However, I won't add chip select or multi-NAND support right now... Any objection? -- Stefan -- 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/