From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id D2B65E0051B; Tue, 19 May 2015 11:02:55 -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 3F77FE0027F for ; Tue, 19 May 2015 11:02:54 -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 t4JI2q6C004166 for ; Tue, 19 May 2015 13:02:53 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t4JI2qTh021656 for ; Tue, 19 May 2015 13:02:52 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 19 May 2015 13:02:52 -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 t4JI2qKi029876; Tue, 19 May 2015 13:02:52 -0500 Message-ID: <555B7ACC.1060903@ti.com> Date: Tue, 19 May 2015 14:02:52 -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: <20150518181119.GG31845@edge> <555A3776.8090705@ti.com> <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> In-Reply-To: <20150519175848.GX31845@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:02:55 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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. >>>>>>>>>>>> + 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? >>>>>>>>>>>> + 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