From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 8E614E0051B; Tue, 19 May 2015 11:10:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [192.94.94.40 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3AD71E0027F for ; Tue, 19 May 2015 11:10:38 -0700 (PDT) Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id t4JIAbc3008635 for ; Tue, 19 May 2015 13:10:37 -0500 Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t4JIAbAD027846 for ; Tue, 19 May 2015 13:10:37 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE71.ent.ti.com (157.170.170.114) with Microsoft SMTP Server id 14.3.224.2; Tue, 19 May 2015 13:10:36 -0500 Received: from [10.218.109.201] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id t4JIAarW008015; Tue, 19 May 2015 13:10:36 -0500 Message-ID: <555B7C9C.3090306@ti.com> Date: Tue, 19 May 2015 14:10:36 -0400 From: Jacob Stiffler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Denys Dmytriyenko References: <20150518191317.GN31845@edge> <555B717A.3010202@ti.com> <20150519172525.GR31845@edge> <555B722D.9090502@ti.com> <20150519173247.GS31845@edge> <555B756E.4070500@ti.com> <20150519174750.GW31845@edge> <555B786B.4070405@ti.com> <20150519175848.GX31845@edge> <555B7ACC.1060903@ti.com> <20150519180610.GZ31845@edge> In-Reply-To: <20150519180610.GZ31845@edge> Cc: meta-ti@yoctoproject.org Subject: Re: [PATCH 1/2] linux/cmem.inc: Support reserving memory for CMEM. X-BeenThere: meta-ti@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-ti layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:10:41 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 5/19/2015 2:06 PM, Denys Dmytriyenko wrote: > On Tue, May 19, 2015 at 02:02:52PM -0400, Jacob Stiffler wrote: >> >> On 5/19/2015 1:58 PM, Denys Dmytriyenko wrote: >>> On Tue, May 19, 2015 at 01:52:43PM -0400, Jacob Stiffler wrote: >>>> On 5/19/2015 1:47 PM, Denys Dmytriyenko wrote: >>>>> On Tue, May 19, 2015 at 01:39:58PM -0400, Jacob Stiffler wrote: >>>>>> On 5/19/2015 1:32 PM, Denys Dmytriyenko wrote: >>>>>>> On Tue, May 19, 2015 at 01:26:05PM -0400, Jacob Stiffler wrote: >>>>>>>> On 5/19/2015 1:25 PM, Denys Dmytriyenko wrote: >>>>>>>>> On Tue, May 19, 2015 at 01:23:06PM -0400, Jacob Stiffler wrote: >>>>>>>>>> On 5/18/2015 3:13 PM, Denys Dmytriyenko wrote: >>>>>>>>>>> On Mon, May 18, 2015 at 03:03:18PM -0400, Jacob Stiffler wrote: >>>>>>>>>>>> On 5/18/2015 2:11 PM, Denys Dmytriyenko wrote: >>>>>>>>>>>>> On Mon, May 18, 2015 at 08:20:58AM -0400, Jacob Stiffler wrote: >>>>>>>>>>>>>> To reserve contiguous memory for CMEM: >>>>>>>>>>>>>> * include the "recipes-kernel/linux/cmem.inc" >>>>>>>>>>>>>> * Set CMEM_BASE and CMEM_SIZE to the physical memory address and size, >>>>>>>>>>>>>> respectively, to reserve for CMEM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently limited to reserving a single memory region used to create >>>>>>>>>>>>>> a single buffer pool of a single buffer. >>>>>>>>>>>>> Looks good. 2 comments below. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Signed-off-by: Jacob Stiffler >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> recipes-kernel/linux/cmem.inc | 22 ++++++++++++++++++++++ >>>>>>>>>>>>>> recipes-kernel/linux/linux/cmem.dtsi | 24 ++++++++++++++++++++++++ >>>>>>>>>>>>>> 2 files changed, 46 insertions(+) >>>>>>>>>>>>>> create mode 100644 recipes-kernel/linux/cmem.inc >>>>>>>>>>>>>> create mode 100644 recipes-kernel/linux/linux/cmem.dtsi >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/recipes-kernel/linux/cmem.inc b/recipes-kernel/linux/cmem.inc >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 0000000..207bdc6 >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/recipes-kernel/linux/cmem.inc >>>>>>>>>>>>>> @@ -0,0 +1,22 @@ >>>>>>>>>>>>>> +FILESEXTRAPATHS_append := ":${THISDIR}/linux" >>>>>>>>>>>>> Move the file into standard "files" directory and drop above line. >>>>>>>>>>>>> >>>>>>>>>>>> Ok. >>>>>>>>>>>> >>>>>>>>>>>>>> +SRC_URI += "file://cmem.dtsi" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +CMEM_BASE ?= "" >>>>>>>>>>>>>> +CMEM_SIZE ?= "" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +do_compileconfigs_prepend() { >>>>>>>>>>>>> Should this be do_configure_append() instead? It would probably be safer, as >>>>>>>>>>>>> do_compileconfigs() is specific to multi-kernel.inc and some kernel recipes >>>>>>>>>>>>> may not include it... >>>>>>>>>>>>> >>>>>>>>>>>> I had noticed that do_configure() gets invoked multiple times. >>>>>>>>>>>> >>>>>>>>>>>> I'll try it as a do_configure_append() and make sure it will work. >>>>>>>>>>> Ah, you are right. Then you'd need to call this function uniquely like >>>>>>>>>>> do_setup_cmem() and then addtask it after do_patch before do_configure. It >>>>>>>>>>> looks like it should be safe to do it even before do_configure. It would be >>>>>>>>>>> nice to do it after do_configure, but it needs to be before do_compile and >>>>>>>>>>> also do_compileconfigs, while the latter one is only defined by multi-kernel >>>>>>>>>>> >>>>>>>>>> This should be called before do_create_srcipk(). But I suppose it >>>>>>>>>> should not be assumed that do_create_srcipk() will be run for a >>>>>>>>>> general kernel recipe. >>>>>>>>>> >>>>>>>>>> Should do_setup_cmem() be a postfunc of do_configure()? For example: >>>>>>>>>> >>>>>>>>>> do_configure[postfuncs] += "do_setup_cmem" >>>>>>>>> Will it be called multiple times after each do_configure? >>>>>>>>> >>>>>>>> Sorry, I had meant do_patch(). >>>>>>> BTW, are you sure you want it before create_srcipk? It won't package the >>>>>>> changes then... >>>>>>> >>>>>> I thought it would have to be done before create_srcipk, since >>>>>> create_srcipk pulls the ${S} directory into the sourceipk. If this >>>>>> is done after create_srcipk, then there will not be any way for >>>>>> these changes to be packaged, correct? >>>>> Oops, you are correct. I was thinking backwards... >>>>> So, do_create_srcipk is also being re-called in do_compile_prepend, so it >>>>> would pick up those changes. >>>>> >>>> But that is only for the case with the meta-arago bbappend, through >>>> copy-defconfig.inc. >>> And srcipk is specific to meta-arago as well... >>> >>> >>>> Any reason it would be better to make this change after do_configure()? >>> Nope, nothing specifically depending on do_configure here, AFAICS. >>> >> Then it seems that having as a do_patch() postfunc would be safest. > Or addtask between do_patch and do_configure should be fine also. > Then how can you be sure create_srcipk() will not run before before setup_cmem()? >>>>>>>>>>>>>> + if [ ! -z "${CMEM_BASE}" ] >>>>>>>>>>>>>> + then >>>>>>>>>>>>>> + cp ${WORKDIR}/cmem.dtsi ${S}/arch/arm/boot/dts/${MACHINE}-cmem.dtsi >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + sed -i -e "s|__CMEM_BASE__|${CMEM_BASE}|g" \ >>>>>>>>>>>>>> + -e "s|__CMEM_SIZE__|${CMEM_SIZE}|g" \ >>>>>>>>>>>>>> + ${S}/arch/arm/boot/dts/${MACHINE}-cmem.dtsi >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + for dts in ${KERNEL_DEVICETREE} >>>>>>>>>>>>>> + do >>>>>>>>>>>>>> + echo "#include \"${MACHINE}-cmem.dtsi\"" >> ${S}/arch/arm/boot/dts/${dts%.dtb}.dts >>> BTW, is that bashism at the end of the line ^^^^^^^^^^^ >>> >> The "${dts%.dtb}"? Yes. I am doing this to remove the .dtb extension >> and then append the .dts extension, since KERNEL_DEVICE tree >> contains the dtb extended filenames. >> >> Is this an issue? > Yes, I understand what's it's doing, but using bashisms is not safe - we've > been trying to eliminate bashisms in upstream and our layers for some time. > Shouldn't be adding more... :) > Would you suggest an dts=`echo $dtb | sed ...` form of command to change the extension? >>>>>>>>>>>>>> + done >>>>>>>>>>>>>> + fi >>>>>>>>>>>>>> +} >>>>>>>>>>>>>> diff --git a/recipes-kernel/linux/linux/cmem.dtsi b/recipes-kernel/linux/linux/cmem.dtsi >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 0000000..6b1da99 >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/recipes-kernel/linux/linux/cmem.dtsi >>>>>>>>>>>>>> @@ -0,0 +1,24 @@ >>>>>>>>>>>>>> +/ { >>>>>>>>>>>>>> + reserved-memory { >>>>>>>>>>>>>> + cmem_block_mem_0: cmem_block_mem@__CMEM_BASE__ { >>>>>>>>>>>>>> + reg = <0x__CMEM_BASE__ 0x__CMEM_SIZE__>; >>>>>>>>>>>>>> + no-map; >>>>>>>>>>>>>> + status = "okay"; >>>>>>>>>>>>>> + }; >>>>>>>>>>>>>> + }; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + cmem { >>>>>>>>>>>>>> + compatible = "ti,cmem"; >>>>>>>>>>>>>> + #address-cells = <1>; >>>>>>>>>>>>>> + #size-cells = <0>; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + status = "okay"; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + cmem_block_0: cmem_block@0 { >>>>>>>>>>>>>> + reg = <0>; >>>>>>>>>>>>>> + memory-region = <&cmem_block_mem_0>; >>>>>>>>>>>>>> + cmem-buf-pools = <1 0x__CMEM_SIZE__>; >>>>>>>>>>>>>> + }; >>>>>>>>>>>>>> + }; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +}; >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 1.7.9.5 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> meta-ti mailing list >>>>>>>>>>>>>> meta-ti@yoctoproject.org >>>>>>>>>>>>>> https://lists.yoctoproject.org/listinfo/meta-ti