From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joseph Lo Subject: Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP Date: Mon, 18 Jul 2016 15:44:44 +0800 Message-ID: <578C88EC.10706@nvidia.com> References: <20160705090431.5852-1-josephl@nvidia.com> <20160705090431.5852-4-josephl@nvidia.com> <20160711142238.GA30600@rob-hp-laptop> <5783C3DE.3080708@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5783C3DE.3080708-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stephen Warren , Rob Herring Cc: Thierry Reding , Alexandre Courbot , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Mark Rutland , Peter De Schrijver , Matthew Longnecker , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jassi Brar , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Catalin Marinas , Will Deacon List-Id: linux-tegra@vger.kernel.org Hi Rob, Thanks for your reviewing. On 07/12/2016 12:05 AM, Stephen Warren wrote: > On 07/11/2016 08:22 AM, Rob Herring wrote: >> On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: >>> The BPMP is a specific processor in Tegra chip, which is designed for >>> booting process handling and offloading the power management, clock >>> management, and reset control tasks from the CPU. The binding document >>> defines the resources that would be used by the BPMP firmware driver, >>> which can create the interprocessor communication (IPC) between the CPU >>> and BPMP. > >>> diff --git >>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt >>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt > >>> +NVIDIA Tegra Boot and Power Management Processor (BPMP) >>> + >>> +The BPMP is a specific processor in Tegra chip, which is designed for >>> +booting process handling and offloading the power management, clock >>> +management, and reset control tasks from the CPU. The binding document >>> +defines the resources that would be used by the BPMP firmware driver, >>> +which can create the interprocessor communication (IPC) between the CPU >>> +and BPMP. >>> + >>> +Required properties: >>> +- name : Should be bpmp >>> +- compatible >>> + Array of strings >>> + One of: >>> + - "nvidia,tegra186-bpmp" >>> +- mboxes : The phandle of mailbox controller and the mailbox specifier. >>> +- shmem : List of the phandle of the TX and RX shared memory area that >>> + the IPC between CPU and BPMP is based on. >> >> I think you can use memory-region here. > > Isn't memory-region intended for references into the /reserved-memory > node. If so, that isn't appropriate in this case since this property > typically points at on-chip SRAM that isn't included in the OS's view of > "system RAM". Agree with that. > > Or, should /reserved-memory be used even for (e.g. non-DRAM) memory > regions that aren't represented by the /memory/reg property? > For shmem, I follow the same concept of the binding for arm,scpi (.../arm/arm,scpi.txt) that is currently using in mainline. Do you think that is more appropriate here? >>> diff --git a/include/dt-bindings/clock/tegra186-clock.h >>> b/include/dt-bindings/clock/tegra186-clock.h > >>> +/** @file */ >>> + >>> +#ifndef _MACH_T186_CLK_T186_H >>> +#define _MACH_T186_CLK_T186_H >>> + >>> +/** >>> + * @defgroup clock_ids Clock Identifiers >> >> Aren't these doxygen markup? Does that work with docbook? If not, >> remove. > > These headers are part of the BPMP FW release. It's preferable not to > edit them when incorporating them into the Linux kernel (or any other SW > stack) to simplify integration of any updated versions of the header, by > removing the need to edit the file when doing so. Given that, do you > still object? How do you think of this, Rob? Thanks, -Joseph From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751575AbcGRHoy (ORCPT ); Mon, 18 Jul 2016 03:44:54 -0400 Received: from nat-hk.nvidia.com ([203.18.50.4]:49171 "EHLO hkmmgate102.nvidia.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751013AbcGRHov (ORCPT ); Mon, 18 Jul 2016 03:44:51 -0400 X-PGP-Universal: processed; by hkpgpgate101.nvidia.com on Mon, 18 Jul 2016 00:44:48 -0700 Subject: Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP To: Stephen Warren , Rob Herring References: <20160705090431.5852-1-josephl@nvidia.com> <20160705090431.5852-4-josephl@nvidia.com> <20160711142238.GA30600@rob-hp-laptop> <5783C3DE.3080708@wwwdotorg.org> CC: Thierry Reding , Alexandre Courbot , , , Mark Rutland , Peter De Schrijver , Matthew Longnecker , , Jassi Brar , , Catalin Marinas , Will Deacon From: Joseph Lo Message-ID: <578C88EC.10706@nvidia.com> Date: Mon, 18 Jul 2016 15:44:44 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5783C3DE.3080708@wwwdotorg.org> X-Originating-IP: [10.19.108.111] X-ClientProxiedBy: HKMAIL101.nvidia.com (10.18.16.10) To HKMAIL101.nvidia.com (10.18.16.10) Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, Thanks for your reviewing. On 07/12/2016 12:05 AM, Stephen Warren wrote: > On 07/11/2016 08:22 AM, Rob Herring wrote: >> On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: >>> The BPMP is a specific processor in Tegra chip, which is designed for >>> booting process handling and offloading the power management, clock >>> management, and reset control tasks from the CPU. The binding document >>> defines the resources that would be used by the BPMP firmware driver, >>> which can create the interprocessor communication (IPC) between the CPU >>> and BPMP. > >>> diff --git >>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt >>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt > >>> +NVIDIA Tegra Boot and Power Management Processor (BPMP) >>> + >>> +The BPMP is a specific processor in Tegra chip, which is designed for >>> +booting process handling and offloading the power management, clock >>> +management, and reset control tasks from the CPU. The binding document >>> +defines the resources that would be used by the BPMP firmware driver, >>> +which can create the interprocessor communication (IPC) between the CPU >>> +and BPMP. >>> + >>> +Required properties: >>> +- name : Should be bpmp >>> +- compatible >>> + Array of strings >>> + One of: >>> + - "nvidia,tegra186-bpmp" >>> +- mboxes : The phandle of mailbox controller and the mailbox specifier. >>> +- shmem : List of the phandle of the TX and RX shared memory area that >>> + the IPC between CPU and BPMP is based on. >> >> I think you can use memory-region here. > > Isn't memory-region intended for references into the /reserved-memory > node. If so, that isn't appropriate in this case since this property > typically points at on-chip SRAM that isn't included in the OS's view of > "system RAM". Agree with that. > > Or, should /reserved-memory be used even for (e.g. non-DRAM) memory > regions that aren't represented by the /memory/reg property? > For shmem, I follow the same concept of the binding for arm,scpi (.../arm/arm,scpi.txt) that is currently using in mainline. Do you think that is more appropriate here? >>> diff --git a/include/dt-bindings/clock/tegra186-clock.h >>> b/include/dt-bindings/clock/tegra186-clock.h > >>> +/** @file */ >>> + >>> +#ifndef _MACH_T186_CLK_T186_H >>> +#define _MACH_T186_CLK_T186_H >>> + >>> +/** >>> + * @defgroup clock_ids Clock Identifiers >> >> Aren't these doxygen markup? Does that work with docbook? If not, >> remove. > > These headers are part of the BPMP FW release. It's preferable not to > edit them when incorporating them into the Linux kernel (or any other SW > stack) to simplify integration of any updated versions of the header, by > removing the need to edit the file when doing so. Given that, do you > still object? How do you think of this, Rob? Thanks, -Joseph From mboxrd@z Thu Jan 1 00:00:00 1970 From: josephl@nvidia.com (Joseph Lo) Date: Mon, 18 Jul 2016 15:44:44 +0800 Subject: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP In-Reply-To: <5783C3DE.3080708@wwwdotorg.org> References: <20160705090431.5852-1-josephl@nvidia.com> <20160705090431.5852-4-josephl@nvidia.com> <20160711142238.GA30600@rob-hp-laptop> <5783C3DE.3080708@wwwdotorg.org> Message-ID: <578C88EC.10706@nvidia.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Rob, Thanks for your reviewing. On 07/12/2016 12:05 AM, Stephen Warren wrote: > On 07/11/2016 08:22 AM, Rob Herring wrote: >> On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: >>> The BPMP is a specific processor in Tegra chip, which is designed for >>> booting process handling and offloading the power management, clock >>> management, and reset control tasks from the CPU. The binding document >>> defines the resources that would be used by the BPMP firmware driver, >>> which can create the interprocessor communication (IPC) between the CPU >>> and BPMP. > >>> diff --git >>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt >>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt > >>> +NVIDIA Tegra Boot and Power Management Processor (BPMP) >>> + >>> +The BPMP is a specific processor in Tegra chip, which is designed for >>> +booting process handling and offloading the power management, clock >>> +management, and reset control tasks from the CPU. The binding document >>> +defines the resources that would be used by the BPMP firmware driver, >>> +which can create the interprocessor communication (IPC) between the CPU >>> +and BPMP. >>> + >>> +Required properties: >>> +- name : Should be bpmp >>> +- compatible >>> + Array of strings >>> + One of: >>> + - "nvidia,tegra186-bpmp" >>> +- mboxes : The phandle of mailbox controller and the mailbox specifier. >>> +- shmem : List of the phandle of the TX and RX shared memory area that >>> + the IPC between CPU and BPMP is based on. >> >> I think you can use memory-region here. > > Isn't memory-region intended for references into the /reserved-memory > node. If so, that isn't appropriate in this case since this property > typically points at on-chip SRAM that isn't included in the OS's view of > "system RAM". Agree with that. > > Or, should /reserved-memory be used even for (e.g. non-DRAM) memory > regions that aren't represented by the /memory/reg property? > For shmem, I follow the same concept of the binding for arm,scpi (.../arm/arm,scpi.txt) that is currently using in mainline. Do you think that is more appropriate here? >>> diff --git a/include/dt-bindings/clock/tegra186-clock.h >>> b/include/dt-bindings/clock/tegra186-clock.h > >>> +/** @file */ >>> + >>> +#ifndef _MACH_T186_CLK_T186_H >>> +#define _MACH_T186_CLK_T186_H >>> + >>> +/** >>> + * @defgroup clock_ids Clock Identifiers >> >> Aren't these doxygen markup? Does that work with docbook? If not, >> remove. > > These headers are part of the BPMP FW release. It's preferable not to > edit them when incorporating them into the Linux kernel (or any other SW > stack) to simplify integration of any updated versions of the header, by > removing the need to edit the file when doing so. Given that, do you > still object? How do you think of this, Rob? Thanks, -Joseph