[RFC 0/2] Proposal for enabling CMEM

[RFC 0/2] Proposal for enabling CMEM

[Jacob Stiffler]

This is a proposal for adding a CMEM region in the device tree.

I wanted to get comments on the following:

* implementation of using an inc file to enable this.
* Whether the actual configuration belongs in the kernel recipe, or if
  this is something that should be handled at the distro or branding
  level. (RFC sets the configuration in kernel recipe).
    - I have verified that this configuration may also be set in the
       branding file using, for example,

         CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
         CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"

Jacob Stiffler (2):
  linux/cmem.inc: Support reserving memory for CMEM.
  linux-ti-staging_3.14: Add CMEM region for omap-a15.

 recipes-kernel/linux/cmem.inc                 |   22 ++++++++++++++++++++++
 recipes-kernel/linux/linux-ti-staging_3.14.bb |    6 +++++-
 recipes-kernel/linux/linux/cmem.dtsi          |   24 ++++++++++++++++++++++++
 3 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 recipes-kernel/linux/cmem.inc
 create mode 100644 recipes-kernel/linux/linux/cmem.dtsi

-- 
1.7.9.5

[RFC 1/2] linux/cmem.inc: Support reserving memory for CMEM.

[Jacob Stiffler]

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.

Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
---
 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..c23445a
--- /dev/null
+++ b/recipes-kernel/linux/cmem.inc
@@ -0,0 +1,22 @@
+FILESEXTRAPATHS_append = ":${THISDIR}/linux"
+
+SRC_URI += "file://cmem.dtsi"
+
+CMEM_BASE ?= ""
+CMEM_SIZE ?= ""
+
+do_compileconfigs_prepend() {
+    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
+        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

[RFC 2/2] linux-ti-staging_3.14: Add CMEM region for omap-a15.

[Jacob Stiffler]

* This region can be used by applications to enable shared contiguous
  memory in user space for data transfer between the ARM and DSP.

Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
---
 recipes-kernel/linux/linux-ti-staging_3.14.bb |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-ti-staging_3.14.bb b/recipes-kernel/linux/linux-ti-staging_3.14.bb
index 061faed..ee91fc1 100644
--- a/recipes-kernel/linux/linux-ti-staging_3.14.bb
+++ b/recipes-kernel/linux/linux-ti-staging_3.14.bb
@@ -8,6 +8,7 @@ inherit kernel
 require recipes-kernel/linux/linux-dtb.inc
 require recipes-kernel/linux/setup-defconfig.inc
 require recipes-kernel/linux/multi-kernel.inc
+require recipes-kernel/linux/cmem.inc
 
 # Look in the generic major.minor directory for files
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.14:"
@@ -49,7 +50,7 @@ SRCREV = "5e342e186fcd9834fff09f6335b344599042be88"
 PV = "3.14.39"
 
 # Append to the MACHINE_KERNEL_PR so that a new SRCREV will cause a rebuild
-MACHINE_KERNEL_PR_append = "a+gitr${SRCPV}"
+MACHINE_KERNEL_PR_append = "b+gitr${SRCPV}"
 PR = "${MACHINE_KERNEL_PR}"
 
 KERNEL_CONFIG_DIR = "${S}/ti_config_fragments"
@@ -57,6 +58,9 @@ KERNEL_CONFIG_DIR = "${S}/ti_config_fragments"
 KERNEL_CONFIG_FRAGMENTS_append_ti33x = " ${KERNEL_CONFIG_DIR}/am33xx_only.cfg"
 KERNEL_CONFIG_FRAGMENTS_append_ti43x = " ${KERNEL_CONFIG_DIR}/am43xx_only.cfg"
 
+CMEM_BASE_omap-a15 = "a0000000"
+CMEM_SIZE_omap-a15 = "20000000"
+
 MULTI_CONFIG_BASE_SUFFIX = ""
 
 KERNEL_GIT_URI = "git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git"
-- 
1.7.9.5

Re: [RFC 0/2] Proposal for enabling CMEM

[Denys Dmytriyenko]

On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
> This is a proposal for adding a CMEM region in the device tree.
> 
> I wanted to get comments on the following:
> 
> * implementation of using an inc file to enable this.
> * Whether the actual configuration belongs in the kernel recipe, or if
>   this is something that should be handled at the distro or branding
>   level. (RFC sets the configuration in kernel recipe).
>     - I have verified that this configuration may also be set in the
>        branding file using, for example,
> 
>          CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
>          CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"

Hmm, on one hand I don't like this change being so invasive. But on the other 
hand, I'm not sure there's a better cleaner way to do a dts injection like 
that. Let me think about it...


> Jacob Stiffler (2):
>   linux/cmem.inc: Support reserving memory for CMEM.
>   linux-ti-staging_3.14: Add CMEM region for omap-a15.
> 
>  recipes-kernel/linux/cmem.inc                 |   22 ++++++++++++++++++++++
>  recipes-kernel/linux/linux-ti-staging_3.14.bb |    6 +++++-
>  recipes-kernel/linux/linux/cmem.dtsi          |   24 ++++++++++++++++++++++++
>  3 files changed, 51 insertions(+), 1 deletion(-)
>  create mode 100644 recipes-kernel/linux/cmem.inc
>  create mode 100644 recipes-kernel/linux/linux/cmem.dtsi
> 
> -- 
> 1.7.9.5
> 
> -- 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: [RFC 0/2] Proposal for enabling CMEM

[Jacob Stiffler]

On 4/23/2015 4:15 PM, Denys Dmytriyenko wrote:
> On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
>> This is a proposal for adding a CMEM region in the device tree.
>>
>> I wanted to get comments on the following:
>>
>> * implementation of using an inc file to enable this.
>> * Whether the actual configuration belongs in the kernel recipe, or if
>>    this is something that should be handled at the distro or branding
>>    level. (RFC sets the configuration in kernel recipe).
>>      - I have verified that this configuration may also be set in the
>>         branding file using, for example,
>>
>>           CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
>>           CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"
> Hmm, on one hand I don't like this change being so invasive. But on the other
> hand, I'm not sure there's a better cleaner way to do a dts injection like
> that. Let me think about it...

Any thoughts on this yet?

>
>> Jacob Stiffler (2):
>>    linux/cmem.inc: Support reserving memory for CMEM.
>>    linux-ti-staging_3.14: Add CMEM region for omap-a15.
>>
>>   recipes-kernel/linux/cmem.inc                 |   22 ++++++++++++++++++++++
>>   recipes-kernel/linux/linux-ti-staging_3.14.bb |    6 +++++-
>>   recipes-kernel/linux/linux/cmem.dtsi          |   24 ++++++++++++++++++++++++
>>   3 files changed, 51 insertions(+), 1 deletion(-)
>>   create mode 100644 recipes-kernel/linux/cmem.inc
>>   create mode 100644 recipes-kernel/linux/linux/cmem.dtsi
>>
>> -- 
>> 1.7.9.5
>>
>> -- 
>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti

Re: [RFC 0/2] Proposal for enabling CMEM

[Denys Dmytriyenko]

On Fri, May 01, 2015 at 08:11:10AM -0400, Jacob Stiffler wrote:
> 
> 
> On 4/23/2015 4:15 PM, Denys Dmytriyenko wrote:
> >On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
> >>This is a proposal for adding a CMEM region in the device tree.
> >>
> >>I wanted to get comments on the following:
> >>
> >>* implementation of using an inc file to enable this.
> >>* Whether the actual configuration belongs in the kernel recipe, or if
> >>   this is something that should be handled at the distro or branding
> >>   level. (RFC sets the configuration in kernel recipe).
> >>     - I have verified that this configuration may also be set in the
> >>        branding file using, for example,
> >>
> >>          CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
> >>          CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"
> >Hmm, on one hand I don't like this change being so invasive. But on the other
> >hand, I'm not sure there's a better cleaner way to do a dts injection like
> >that. Let me think about it...
> 
> Any thoughts on this yet?

Jake,

After discussing this matter internally, since cmem is something that LCPD 
currently doesn't support being an out-of-tree module and so on, I can accept 
the patchset, but it will be disabled by default and not tested by us. All the 
testing will be on you to make sure it's not broken by future changes in the 
kernel. Will that be sufficient?

-- 
Denys


> >>Jacob Stiffler (2):
> >>   linux/cmem.inc: Support reserving memory for CMEM.
> >>   linux-ti-staging_3.14: Add CMEM region for omap-a15.
> >>
> >>  recipes-kernel/linux/cmem.inc                 |   22 ++++++++++++++++++++++
> >>  recipes-kernel/linux/linux-ti-staging_3.14.bb |    6 +++++-
> >>  recipes-kernel/linux/linux/cmem.dtsi          |   24 ++++++++++++++++++++++++
> >>  3 files changed, 51 insertions(+), 1 deletion(-)
> >>  create mode 100644 recipes-kernel/linux/cmem.inc
> >>  create mode 100644 recipes-kernel/linux/linux/cmem.dtsi
> >>
> >>-- 
> >>1.7.9.5
> >>
> >>-- 
> >>_______________________________________________
> >>meta-ti mailing list
> >>meta-ti@yoctoproject.org
> >>https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: [RFC 0/2] Proposal for enabling CMEM

[Jacob Stiffler]

On 5/14/2015 6:21 PM, Denys Dmytriyenko wrote:
> On Fri, May 01, 2015 at 08:11:10AM -0400, Jacob Stiffler wrote:
>>
>> On 4/23/2015 4:15 PM, Denys Dmytriyenko wrote:
>>> On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
>>>> This is a proposal for adding a CMEM region in the device tree.
>>>>
>>>> I wanted to get comments on the following:
>>>>
>>>> * implementation of using an inc file to enable this.
>>>> * Whether the actual configuration belongs in the kernel recipe, or if
>>>>    this is something that should be handled at the distro or branding
>>>>    level. (RFC sets the configuration in kernel recipe).
>>>>      - I have verified that this configuration may also be set in the
>>>>         branding file using, for example,
>>>>
>>>>           CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
>>>>           CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"
>>> Hmm, on one hand I don't like this change being so invasive. But on the other
>>> hand, I'm not sure there's a better cleaner way to do a dts injection like
>>> that. Let me think about it...
>> Any thoughts on this yet?
> Jake,
>
> After discussing this matter internally, since cmem is something that LCPD
> currently doesn't support being an out-of-tree module and so on, I can accept
> the patchset, but it will be disabled by default and not tested by us. All the
> testing will be on you to make sure it's not broken by future changes in the
> kernel. Will that be sufficient?
>
This should be fine, but to be clear, is it OK to have the kernel recipe 
include the cmem include file? And, with CMEM being disabled by default 
for core sdk builds, would the CMEM configuration go into the branding file?

Re: [RFC 0/2] Proposal for enabling CMEM

[Denys Dmytriyenko]

On Fri, May 15, 2015 at 02:16:22PM -0400, Jacob Stiffler wrote:
> 
> 
> On 5/14/2015 6:21 PM, Denys Dmytriyenko wrote:
> >On Fri, May 01, 2015 at 08:11:10AM -0400, Jacob Stiffler wrote:
> >>
> >>On 4/23/2015 4:15 PM, Denys Dmytriyenko wrote:
> >>>On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
> >>>>This is a proposal for adding a CMEM region in the device tree.
> >>>>
> >>>>I wanted to get comments on the following:
> >>>>
> >>>>* implementation of using an inc file to enable this.
> >>>>* Whether the actual configuration belongs in the kernel recipe, or if
> >>>>   this is something that should be handled at the distro or branding
> >>>>   level. (RFC sets the configuration in kernel recipe).
> >>>>     - I have verified that this configuration may also be set in the
> >>>>        branding file using, for example,
> >>>>
> >>>>          CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
> >>>>          CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"
> >>>Hmm, on one hand I don't like this change being so invasive. But on the other
> >>>hand, I'm not sure there's a better cleaner way to do a dts injection like
> >>>that. Let me think about it...
> >>Any thoughts on this yet?
> >Jake,
> >
> >After discussing this matter internally, since cmem is something that LCPD
> >currently doesn't support being an out-of-tree module and so on, I can accept
> >the patchset, but it will be disabled by default and not tested by us. All the
> >testing will be on you to make sure it's not broken by future changes in the
> >kernel. Will that be sufficient?
> >
> This should be fine, but to be clear, is it OK to have the kernel
> recipe include the cmem include file? And, with CMEM being disabled
> by default for core sdk builds, would the CMEM configuration go into
> the branding file?

Jake,

The point is to not mangle standard dts files with CMEM related setup in 
CoreSDK. The way your patch works, as long as CMEM_BASE is not set, it won't 
do that. I'm fine with recipe having that logic via cmem.inc. You are welcome 
to enable it in your SDK config/branding, yes.

In other words, patch #1 can go in w/o changes and patch #2 should rather go 
into your branding config file.

-- 
Denys

Re: [RFC 0/2] Proposal for enabling CMEM

[Jacob Stiffler]

On 5/15/2015 2:33 PM, Denys Dmytriyenko wrote:
> On Fri, May 15, 2015 at 02:16:22PM -0400, Jacob Stiffler wrote:
>>
>> On 5/14/2015 6:21 PM, Denys Dmytriyenko wrote:
>>> On Fri, May 01, 2015 at 08:11:10AM -0400, Jacob Stiffler wrote:
>>>> On 4/23/2015 4:15 PM, Denys Dmytriyenko wrote:
>>>>> On Thu, Apr 23, 2015 at 07:42:09AM -0400, Jacob Stiffler wrote:
>>>>>> This is a proposal for adding a CMEM region in the device tree.
>>>>>>
>>>>>> I wanted to get comments on the following:
>>>>>>
>>>>>> * implementation of using an inc file to enable this.
>>>>>> * Whether the actual configuration belongs in the kernel recipe, or if
>>>>>>    this is something that should be handled at the distro or branding
>>>>>>    level. (RFC sets the configuration in kernel recipe).
>>>>>>      - I have verified that this configuration may also be set in the
>>>>>>         branding file using, for example,
>>>>>>
>>>>>>           CMEM_BASE_pn-linux-ti-staging_omap-a15 = "a0000000"
>>>>>>           CMEM_SIZE_pn-linux-ti-staging_omap-a15 = "20000000"
>>>>> Hmm, on one hand I don't like this change being so invasive. But on the other
>>>>> hand, I'm not sure there's a better cleaner way to do a dts injection like
>>>>> that. Let me think about it...
>>>> Any thoughts on this yet?
>>> Jake,
>>>
>>> After discussing this matter internally, since cmem is something that LCPD
>>> currently doesn't support being an out-of-tree module and so on, I can accept
>>> the patchset, but it will be disabled by default and not tested by us. All the
>>> testing will be on you to make sure it's not broken by future changes in the
>>> kernel. Will that be sufficient?
>>>
>> This should be fine, but to be clear, is it OK to have the kernel
>> recipe include the cmem include file? And, with CMEM being disabled
>> by default for core sdk builds, would the CMEM configuration go into
>> the branding file?
> Jake,
>
> The point is to not mangle standard dts files with CMEM related setup in
> CoreSDK. The way your patch works, as long as CMEM_BASE is not set, it won't
> do that. I'm fine with recipe having that logic via cmem.inc. You are welcome
> to enable it in your SDK config/branding, yes.
>
> In other words, patch #1 can go in w/o changes and patch #2 should rather go
> into your branding config file.
>
I'm fine with that. I'll work on these changes and resubmit as an actual 
patch.

Thank you.