[meta-ti] [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.