From patchwork Tue Apr 17 09:10:02 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tero Kristo X-Patchwork-Id: 133519 Delivered-To: patch@linaro.org Received: by 10.46.84.18 with SMTP id i18csp4489433ljb; Tue, 17 Apr 2018 02:11:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/Or3PHFTZ9DtsjGG/SjQD/HVu/QPp9zvf4QNCtQPYioqSa6LjYHbHfM4MsvyOGuDt58ISa X-Received: by 2002:a17:902:bf49:: with SMTP id u9-v6mr1300870pls.133.1523956262741; Tue, 17 Apr 2018 02:11:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523956262; cv=none; d=google.com; s=arc-20160816; b=IeP/YbniltUJb4JPCKd6FtowBlpBfxKvuxGYeQRc+CNNWl058D6FETgf2uodldao0y Fv0rDohBkKrG9T5FUPgJleVbBXlOoSySqqYC/URNykxL0rSrSyWL5aRXzFF98ZzQZnyE TH7hN7Bvr6CCSfET2pfGAQqRUSbhmAvK3X3Z6Ir8M064UrmsbU8Q6m/PgL4Rx4HFKk7C vtpkDehilCkDahMIlPhztrO3sz9ww4Oc5BxunoLd2kM+7SOPoBBu3FOCa3DNpAPjAtKY ypzL+KXh/2fCc6DJqDx5ZNAJvFIZBz4e15Mswn1RhlkmU+KTiB8O9cMAo4sgPg9KRn/2 TAZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:dkim-signature:arc-authentication-results; bh=sRDu3sYpAntkW2lsRoxj669TvLev3z18hokTUEEIfuM=; b=EOAb9/NE5wYa/YAYeoAvvkUdr5F+E4aRQxeTBbxnBU5KaXU3dzADJYLzIfqLyhNkr8 /rbtEFT1uSn5le5nZX6UeBHodMHE78d9wGabVj4YUVQ9gjACyOIe1I+cUU+A29giKKmZ cernvf4roBonN01AKa9zi0+0JG388a8gV+c21tdCboQC5lBQMOkHbmNYA82IYQGatvY8 PyGN9FydBv0aP1c3mZ7V7siqimCA5F0sJ8jA5uftP9R5p1kcP7R4IMI9vZwNExsW10hs k/flY76y3Tse3Y6nnAp6n94+CvV3jfATpmAbfKa8Rdxw+O/q9CYY2bm1lPhu7xpDAYfG e/pQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@ti.com header.s=ti-com-17Q1 header.b=qS3mFDTn; 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; dmarc=fail (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r25si12132209pfh.2.2018.04.17.02.11.02; Tue, 17 Apr 2018 02:11:02 -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; dkim=neutral (body hash did not verify) header.i=@ti.com header.s=ti-com-17Q1 header.b=qS3mFDTn; 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; dmarc=fail (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751345AbeDQJLA (ORCPT + 6 others); Tue, 17 Apr 2018 05:11:00 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:28768 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbeDQJK7 (ORCPT ); Tue, 17 Apr 2018 05:10:59 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id w3H9Agrq025626; Tue, 17 Apr 2018 04:10:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1523956242; bh=10bH9VzOhjtuwJcfJRmZBPAHNhYIZ9hUH0FMWG02wio=; h=From:To:CC:Subject:Date; b=qS3mFDTnTqlIUg3LPF0mLyhS7iTy4tJ6wBc7yHkT5MUupE1//5Gxf5GwQxYXDlQLK nf8ZmWrpkOWTYjk1KLrALsSB3kUQhYKeGkJQ1pXOLdnxExsG5drBKEGZbuo72xnvOc wOR6yDR5gYrQufyhM87Qg9JEmnXKqQ4EunzSfcng= Received: from DLEE108.ent.ti.com (dlee108.ent.ti.com [157.170.170.38]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3H9Ag6L012945; Tue, 17 Apr 2018 04:10:42 -0500 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 17 Apr 2018 04:10:42 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Tue, 17 Apr 2018 04:10:42 -0500 Received: from gomoku.home (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3H9Adn5031430; Tue, 17 Apr 2018 04:10:40 -0500 From: Tero Kristo To: , , , CC: , , , Subject: [RFC 00/13] ARM: dts: DT overlay support infra + some data Date: Tue, 17 Apr 2018 12:10:02 +0300 Message-ID: <1523956215-28154-1-git-send-email-t-kristo@ti.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, This series is an attempt to start discussion on the DT overlay build time support. Basically, one can build DT overlays directly from kernel tree, and also build FIT images that contain the kernel + devicetree blobs required for specific configuration that can be booted directly with u-boot. No runtime support for overlay switching is touched by this series. What this series does, is to: 1) add subdir support under arch/arm/boot/dts 2) provide DT overlay build support to kernel tree 3) provide FIT image build support to kernel tree 4) provide a number of DT overlay + FIT image files for some TI SoCs to show the reasons why we are doing this, this is only a subset of our boards that we would want to use overlays with Main reason for TI to use DT overlays right now is the rather large amount of different displays we have around, which can be used with different boards. With the current approach one needs to write a separate .dts file for each board + display config, but with overlays, one can just create a single overlay that would apply to different boards. There are some other cases like the shown dra71-evm case in this series, where the gpmc vs. display support is mutually exclusive, as they are sharing certain pieces of the HW. The main controversy with this series is most likely where the DT overlay files should be stored at. Should they still reside with the kernel tree or someplace else? Also, the FIT image support is probably controversial, should it be part of the kernel build system like shown here, or should it be separate? The zImage dependency is pretty annoying so maybe it should be done somewhere else. Any comments welcome as this is just an RFC for now, but basically we would really want a solution to this problem. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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