From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Gross Subject: Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format Date: Fri, 6 Nov 2015 14:15:04 -0600 Message-ID: <20151106201504.GA18276@qualcomm.com> References: <1445894712-14350-1-git-send-email-sboyd@codeaurora.org> <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Stephen Boyd Cc: devicetree@vger.kernel.org, Arnd Bergmann , Kevin Hilman , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Olof Johansson , linux-arm-kernel@lists.infradead.org List-Id: linux-arm-msm@vger.kernel.org On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote: > Some qcom based bootloaders identify the dtb blob based on a set > of device properties like SoC, platform, PMIC, and revisions of > those components. In downstream kernels, these values are added > to the different component dtsi files (i.e. pmic dtsi file, SoC > dtsi file, board dtsi file, etc.) via qcom specific DT > properties. The dtb files are parsed by a program called dtbTool > that picks out these properties and creates a table of contents > binary blob with the property information and some offsets into > the concatenation of all the dtbs (termed a QCDT image). > > The suggestion is to do this via the board compatible string > instead, because these qcom specific properties are never used by > the kernel. Add a document describing the format of the > compatible string that encodes all this information that's > currently encoded in the qcom,{msm-id,board-id,pmic-id} > properties in downstream devicetrees. Future bootloaders may be > updated to look at the compatible field instead of looking for > the table of contents image. For non-updateable bootloaders, a > new dtbTool program will parse the compatible string and generate > a QCDT image from it. > > Signed-off-by: Stephen Boyd > --- Looks workable. Reviewed-by: Andy Gross -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162947AbbKFUQG (ORCPT ); Fri, 6 Nov 2015 15:16:06 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:33450 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162891AbbKFUPH (ORCPT ); Fri, 6 Nov 2015 15:15:07 -0500 Date: Fri, 6 Nov 2015 14:15:04 -0600 From: Andy Gross To: Stephen Boyd Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Olof Johansson , Kevin Hilman , Arnd Bergmann , devicetree@vger.kernel.org Subject: Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format Message-ID: <20151106201504.GA18276@qualcomm.com> References: <1445894712-14350-1-git-send-email-sboyd@codeaurora.org> <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote: > Some qcom based bootloaders identify the dtb blob based on a set > of device properties like SoC, platform, PMIC, and revisions of > those components. In downstream kernels, these values are added > to the different component dtsi files (i.e. pmic dtsi file, SoC > dtsi file, board dtsi file, etc.) via qcom specific DT > properties. The dtb files are parsed by a program called dtbTool > that picks out these properties and creates a table of contents > binary blob with the property information and some offsets into > the concatenation of all the dtbs (termed a QCDT image). > > The suggestion is to do this via the board compatible string > instead, because these qcom specific properties are never used by > the kernel. Add a document describing the format of the > compatible string that encodes all this information that's > currently encoded in the qcom,{msm-id,board-id,pmic-id} > properties in downstream devicetrees. Future bootloaders may be > updated to look at the compatible field instead of looking for > the table of contents image. For non-updateable bootloaders, a > new dtbTool program will parse the compatible string and generate > a QCDT image from it. > > Signed-off-by: Stephen Boyd > --- Looks workable. Reviewed-by: Andy Gross -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: agross@codeaurora.org (Andy Gross) Date: Fri, 6 Nov 2015 14:15:04 -0600 Subject: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format In-Reply-To: <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> References: <1445894712-14350-1-git-send-email-sboyd@codeaurora.org> <1445894712-14350-2-git-send-email-sboyd@codeaurora.org> Message-ID: <20151106201504.GA18276@qualcomm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote: > Some qcom based bootloaders identify the dtb blob based on a set > of device properties like SoC, platform, PMIC, and revisions of > those components. In downstream kernels, these values are added > to the different component dtsi files (i.e. pmic dtsi file, SoC > dtsi file, board dtsi file, etc.) via qcom specific DT > properties. The dtb files are parsed by a program called dtbTool > that picks out these properties and creates a table of contents > binary blob with the property information and some offsets into > the concatenation of all the dtbs (termed a QCDT image). > > The suggestion is to do this via the board compatible string > instead, because these qcom specific properties are never used by > the kernel. Add a document describing the format of the > compatible string that encodes all this information that's > currently encoded in the qcom,{msm-id,board-id,pmic-id} > properties in downstream devicetrees. Future bootloaders may be > updated to look at the compatible field instead of looking for > the table of contents image. For non-updateable bootloaders, a > new dtbTool program will parse the compatible string and generate > a QCDT image from it. > > Signed-off-by: Stephen Boyd > --- Looks workable. Reviewed-by: Andy Gross -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project