From patchwork Wed Apr 9 17:32:49 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 3956801 Return-Path: X-Original-To: patchwork-linux-spi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B9CA9BFF02 for ; Wed, 9 Apr 2014 17:33:12 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D9CF020522 for ; Wed, 9 Apr 2014 17:33:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8E7320612 for ; Wed, 9 Apr 2014 17:33:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964922AbaDIRdJ (ORCPT ); Wed, 9 Apr 2014 13:33:09 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:58431 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964917AbaDIRdF (ORCPT ); Wed, 9 Apr 2014 13:33:05 -0400 Received: by mail-ie0-f169.google.com with SMTP id to1so2769553ieb.14 for ; Wed, 09 Apr 2014 10:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=mgvG3xB0FpOlmg1cDaR9RLSIgBdMBaz2XNDbf3fRTCE=; b=LQFep9slf87PDoEX9HvS4+DpHx0q0X2pCChKtWwXEwbPaBzrrv1OmQzOzzpLuqJamX sF2IUTheqFk7ZfW4F4MwhyWKY2d9TUNOfhIv0gg99bSVYd24BmHQUgj7SvCD7aGcpGXl n8zTH4u/YFIXIeXolihYCMTRBUCPc9aJ8VFa37oTy13AXz3yyu4iA2g/LtWw5EFT2muP g8ptjCI9fu1RltZD6SqdbFq5AZrMNiObvE1l+MgVYT3rj7ITqXdDaux9EefInWWVCzg+ +NlruXOruT4TSdgMKpKuV/qHPqhCLUS2PNgvp0aWJx3CXhiONX+2zF/vE7+PAb3hPPii 619g== X-Received: by 10.43.74.198 with SMTP id yx6mr9083563icb.40.1397064785600; Wed, 09 Apr 2014 10:33:05 -0700 (PDT) Received: from ld-irv-0074.broadcom.com (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by mx.google.com with ESMTPSA id i16sm12857323igf.11.2014.04.09.10.33.04 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 10:33:05 -0700 (PDT) From: Brian Norris To: Cc: Brian Norris , Huang Shijie , Lee Jones , , Marek Vasut Subject: [PATCH 4/9] Documentation: spi-nor: rewrite some portions Date: Wed, 9 Apr 2014 10:32:49 -0700 Message-Id: <1397064774-31784-4-git-send-email-computersforpeace@gmail.com> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1397064774-31784-1-git-send-email-computersforpeace@gmail.com> References: <1397064774-31784-1-git-send-email-computersforpeace@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Brian Norris --- WIP. This could be improved more (e.g., don't spend too much time documenting history; just document the current framework) Documentation/mtd/spi-nor.txt | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt index 294d5b06f892..bfcdeb94e053 100644 --- a/Documentation/mtd/spi-nor.txt +++ b/Documentation/mtd/spi-nor.txt @@ -1,16 +1,20 @@ SPI NOR framework ============================================ -Part I - why we need this framework? +Part I - Why do we need this framework? ------------------------------------- -The SPI bus controller only deals with the byte stream. -Some controller does not works like a SPI bus controller, it works -like a SPI NOR controller instead, such as the Freescale's QuadSPI controller. +SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus +controller operates agnostic of the specific device attached. However, some +controllers (such as Freescale's QuadSPI controller) cannot easily handle +arbitrary streams of bytes, but rather are designed specifically for SPI NOR. -The Freescale's QuadSPI controller should know the NOR commands to -find the right LUT sequence. Unfortunately, the old code can not meet -this requirement. +Specifically, Freescale's QuadSPI controller must know the NOR commands to +find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of +opcodes, addresses, or data payloads; a SPI controller simply knows to send or +receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under +which the controller driver is aware of the opcodes, addressing, and other +details of the SPI NOR protocol. Part II - How does the framework work? ------------------------------------- @@ -40,7 +44,7 @@ m25p80 code anymore. ------------------------ SPI NOR chip - With the SPI NOR controller driver(Freescale QuadSPI), it looks like: + With the SPI NOR controller driver (Freescale QuadSPI), it looks like: MTD ------------------------ SPI NOR framework @@ -53,7 +57,6 @@ Part III - How can the drivers use the framework ------------------------------------- The main API is the spi_nor_scan(). Before you call the hook, you should -initialize the necessary fields for spi_nor{}. -Please see the drivers/mtd/spi-nor/spi-nor.c for detail. -Please also reference to the fsl-quadspi.c when you want to write a new driver -for a SPI NOR controller. +initialize the necessary fields for spi_nor{}. Please see the +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to the fsl-quadspi.c +when you want to write a new driver for a SPI NOR controller.