From patchwork Thu Oct 29 12:52:30 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 55763 Delivered-To: patch@linaro.org Received: by 10.112.61.134 with SMTP id p6csp543836lbr; Thu, 29 Oct 2015 05:52:49 -0700 (PDT) X-Received: by 10.68.243.73 with SMTP id ww9mr1826771pbc.6.1446123168527; Thu, 29 Oct 2015 05:52:48 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id xc2si2331156pbc.187.2015.10.29.05.52.48; Thu, 29 Oct 2015 05:52:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dkim=neutral (body hash did not verify) header.i=@linaro_org.20150623.gappssmtp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505AbbJ2Mwq (ORCPT + 6 others); Thu, 29 Oct 2015 08:52:46 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:33127 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753363AbbJ2Mwo (ORCPT ); Thu, 29 Oct 2015 08:52:44 -0400 Received: by lfbf136 with SMTP id f136so4204457lfb.0 for ; Thu, 29 Oct 2015 05:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro_org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=Ng76mQfoAzbHWdfE8ZF3JLrN+Nurt3cWM47FJmHwzow=; b=X35ATIm/frBfQLw9xyL9itlXSoM37NqNiT2uHV1BvGLCoGOHyS9sYgYFGS0GuLGcut qz1KcCHSfTdHnqeyDXgSQoGMxO2WAQeQCnSEk+5IZQRXmG64wUOo9ipobx59Hi3FC8CE n4gFO12C9gzobfncyAxVIzfBShykVtzVUL0+qMvTFWNrbc0kbt9Hz10tw0uKl9/RVEbS hbDX+gEoZKEV46Vr1YGy+3ttbznxXG37n0RBiz1+KJB3wtPqnEV2WwZ9h0rDkkJFE1o1 q7mmA09TqXbyLDEmFlyDvw2m9Rqxkfpgd1J1q25nUufAhGWQq5GYXEEYePRmJOgQOFS7 vo7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Ng76mQfoAzbHWdfE8ZF3JLrN+Nurt3cWM47FJmHwzow=; b=SnMJOkZJZBNI92tO1xUFoIVNtn1xLVpQbietLAbjEoZurb6qrTtmV/KfuAeT1wS7vF Po6EmedvFQ+A2yFyF3wzl/MkiOvCZah14k4oczG8CrxZj4ZIUPg6m02x81OpWYnAJze0 lF22onxZGaY1Igume5EzSJuD+h24sEwq1lOMMYcdjypPniI6Qge9tEJV7LjnXi8hIe8f h7EgwAViVcusTw366srnzFwmM3l8JlafxRvHt6xMb+TO0ZRhQJ7QeAUq9dQ3lg2W/mI3 uvlxOWRxsZw3SNprLUTkR/l34A3y5n7ivAJbwp/zIKmJHhUM+Zn6zHKLTMy/LKiAf5Rc ZNyA== X-Gm-Message-State: ALoCoQkuILJqkgOlyIBrYBOxcAs8pOj+rMg9NK0gIv+kFoV7XtNH+XJVZiq6rs4PlKoXXMccWyvu X-Received: by 10.25.25.206 with SMTP id 197mr583035lfz.91.1446123163089; Thu, 29 Oct 2015 05:52:43 -0700 (PDT) Received: from localhost.localdomain ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id o197sm300467lfb.7.2015.10.29.05.52.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 05:52:42 -0700 (PDT) From: Linus Walleij To: David Woodhouse , Brian Norris , linux-mtd@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org, Linus Walleij , devicetree@vger.kernel.org, Jason Gunthorpe , Liviu Dudau Subject: [PATCH 1/3] mtd: create a partition type device tree binding Date: Thu, 29 Oct 2015 13:52:30 +0100 Message-Id: <1446123152-22666-1-git-send-email-linus.walleij@linaro.org> X-Mailer: git-send-email 2.4.3 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The Linux code in drivers/mtd/maps/physmap_of.c will optionally look for the linux,part-probe binding for hints on a partition type to look for in the MTD. It was added in commit 9d5da3a9b849 "mtd: extend physmap_of to let the device tree specify the parition probe" This solution is too Linux-specific and depend on some Linux kernel-internal naming conventions. We need a proper way of describing partition types that follow the pattern set by other device tree bindings. Create a "partition-type" binding for this, and add "my" bindings for "arm,arm-flash-structure" as a starter for others to follow. A follow-on patch adds support to the Linux kernel to handle this binding, with some infrastructure for others to use it too. Cc: devicetree@vger.kernel.org Cc: Jason Gunthorpe Cc: Liviu Dudau Reported-by: Liviu Dudau Signed-off-by: Linus Walleij --- .../devicetree/bindings/mtd/mtd-physmap.txt | 2 ++ .../devicetree/bindings/mtd/partition.txt | 35 +++++++++++++++++++--- 2 files changed, 33 insertions(+), 4 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt index 4a0a48bf4ecb..863560bdbb19 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt @@ -23,6 +23,8 @@ file systems on embedded devices. unaligned accesses as implemented in the JFFS2 code via memcpy(). By defining "no-unaligned-direct-access", the flash will not be exposed directly to the MTD users (e.g. JFFS2) any more. + - partition-type : a flash partition type to expect and probe for + on this device. See "partition.txt" for available partition types. - linux,mtd-name: allow to specify the mtd name for retro capability with physmap-flash drivers as boot loader pass the mtd partition via the old device name physmap-flash. diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt index 8e5557da1955..85d45764a4b3 100644 --- a/Documentation/devicetree/bindings/mtd/partition.txt +++ b/Documentation/devicetree/bindings/mtd/partition.txt @@ -1,9 +1,36 @@ Representing flash partitions in devicetree -Partitions can be represented by sub-nodes of an mtd device. This can be used -on platforms which have strong conventions about which portions of a flash are -used for what purposes, but which don't use an on-flash partition table such -as RedBoot. +On-device partition types: + +It is possible for some drivers to indicate an on-device partition type, i.e. +partition tables, footers or other binary pattern in the flash used to +define how the flash is partitioned. This can be done in the device tree node +of an MTD device by specifying partition-type = "foo"; This tells the operating +system to look for the partition type indicated. + +Required properties: +- partition-type : the type of partition. Only one type can be specified. + Valid types are: + "arm,arm-flash-structure" (also called AFS) + +Example: + +flash0@40000000 { + /* 2 * 32MiB NOR Flash memory */ + compatible = "arm,vexpress-flash", "cfi-flash"; + partition-type = "arm,arm-flash-structure"; + reg = <0x40000000 0x04000000>; + bank-width = <4>; +}; + + +Device Tree specified partitions: + +If there is no specified on-device binary format, partitions can be +represented by sub-nodes of an mtd device. This can be used on platforms which +have strong conventions about which portions of a flash are used for what +purposes. + NOTE: if the sub-node has a compatible string, then it is not a partition. #address-cells & #size-cells must both be present in the mtd device. There are